I've been doing a lot of Tcl lately...
I've been doing a lot of Tcl lately on my job. I really didn't intend to. I keep coming off a some great Tcl advocate every time I mention that Tcl can meet the task. We have a 3 week deadline and I hit the ground running on my hire date.
It's not so much that Tcl could do it any better than Perl, Python, Lisp, Scheme or Lua (a new favorite of mine). But, I know Tcl so much better than many other languages that could do the task, and we really needed to get something working. It is a bit embarrassing though when they ask me how long it would take to AES encode some data I'm pushing around and I just shrug and say "a couple of minutes?".
Hopefully all of this daytime Tcl work will get my ass into gear finishing and releasing EFX 2.0. Who knows?
Permalink | Saturday, May 27 8:02 PM
AFT and software books - a tangent
I stumbled up this paper which talks about "Writing Software Books" and I was struck with an idea...
While I've tried at one time to pursue an AFT feature that would allow for literate programming (produce code or HTML/PDF at will from one document), how about just executing an AFT document? That is, an AFT document could either be published (HTML, PDF, etc) or executed (run code embedded in document). The main difference is that you don't "process" the document (like ctangle in CWEB) as much as you "run" the document... sort of interpreting versus compilation.
Now, that would be interesting... especially if embedded code could manipulate the AFT document itself! Quite an interesting take on EFX 2.0: AFT as a content management platform! ;-)
Permalink | Monday, May 08 3:45 PM
...so how would YOU build this app?
Customer: my wife
Problem: Need to easily back up quicken data files to offsite FTP storage every once in a while.
Constraints: Quicken is run on a windows laptop, so background (unattended) backups not practical. Need to keep at least a few months of backed up quicken revisions on FTP site.
Proposed Solution:
- Double click on a backup program.
- Archive the last uploaded quicken files on the FTP server.
- Upload new quicken data files.
- Upon sucess, just say so with a dialog box.
- Upon failure, say so in dialog box and email me (todd) with the failure reason.
So, let's take a quick look at what is required if done in each in Tcl, Perl or Rebol:
- Active State Tcl
- Install 10MB+ Tcl distribution on laptop.
- Write a wish script using Tcllib's smtp and ftp.
- Tclkit
- Build a custom kit or exe that includes Tcllib.
- Or write a batch file and distribute tclkit.exe, my script and what I need of Tcllib.
- Perl
- Install 20MB+ Perl distribution onto laptop.
- If a decent GUI (TkPerl?) isn't there, download the CPAN modules.
- Rebol
- Install Rebol/View binary (<1MB) onto laptop with my backup.rl script.
Yes, this is over simplifying (and I know there are other ways to do this in Perl or Tcl), but why do I have to do all of this just to get a customized backup solution to work?
Now, of course I'd still have to learn Rebol...
Permalink | Monday, May 01 10:52 AM
Open Source Heresy
At some point, when you develop software to be used by customers (paying or not), you need to figure out what is important. That is, are you developing this software for a community of developers (with the side effect that it does what the customer needs)? Or, are you trying to solve a customer's problem.
There are non-opensource language implementations and platforms out there. And they are being used. People develop useful things in VB, Allegro Common Lisp, K, etc. You may even fool yourself in thinking that as long as there is an open sourced implementation of the language (or platform) then you are safe from the lock-in scenario. But, when you start using something proprietary, you have to commit.
So, here I am thinking about EFX 2.0 (in particular, Storybot and what I'll call "blog-in-a-box"). Does it really matter that I am developing it in an open source language with open source libraries? Not really. Especially when considering that the end user doesn't care. I am also not currently collaborating with a community of developers.
Here is something interesting I've noticed: The proprietary language implementations seem slicker and sturdier... or maybe just more focused. I've been (re)looking at Rebol and I like what I see: Small footprint (under 1MB!), lots of built in stuff, and a free development and binary distribution. But, its proprietary. So what? Isn't the point of developing "end user products" to give the end user something easy to work with?
Am I fooling myself into thinking that just by using Tcl, Gawk or Ksh that I am making it any easier for the end user? Am I really making something that will be improved upon by developers? Are there that many Tcl, Gawk or Ksh developers out there who will modify, improve and support EFX? Probably not.
All of the open source languages I've been using (Perl, Tcl, Gawk, etc) have packaging issues. Some of these issues are ones of quality and integration (e.g. Tcllib's ftp, pop3 and mime packages use very different semantics). Some of these issues are bundling and installation (ugh, how do I bundle AFT if it needs CPAN stuff, or how much time do I spend reducing the Active State distribution dependency of EFX?).
Now, I am not talking about commercializing EFX or any other software I produce, but I've already limited my open source community cred by using non-trendy languages. There is not a huge Tcl, Gawk or Ksh community interested in hacking EFX. I doubt there would ever be.
A lesson: AFT has been out for around 10 years now. I've got (probably) dozens of users around the web. I know of people who install it for their students, co-workers or departments. I've had under a half-dozen code contributions in those 10 years. My Perl isn't great, so one would expect to see more "fixes" or improvements. Most of the "improvements" I've received has been to the rule files (templates), not the Perl code.
Most people just want it to install easy. They don't seem to care that it is in Perl or (perhaps) whether or not it used an open-source language.
Now, I am sure some of my user base that install AFT through Debian or FreeBSD distributions (apt-get and Ports, respectively) would not have found or bothered to install AFT if it wasn't there, but I do get quite a bit of download traffic at the AFT website.
So, if AFT was bundled as a source file and a single rebol runtime binary (for Solaris, Linux, FreeBSD, Windoze, etc), how many people would refuse to give it a try?
Permalink | Monday, May 01 10:33 AM
Natural Complexity
Minimalism is overrated. A small core is good, but richness lies in complexity. Complex software is interesting. Simple software is boring.
I want simple installs. Installing software should be simple.
I want simple configs. Configuring software should be simple.
But, I want rich software. Rich software has complex behavior. But, it shouldn't be artificially complex.
Right now, EFX is hard to install. It is also difficult to configure. There isn't enough magic. And, by magic I don't mean unexpected behavior. I mean "Oh, that was nice!", or "Cool, I'm glad I didn't have to do that!".
EFX 1.0 uses XHTML for page specification. XHTML is too rigid. You've got to line the brackets up and stuff. HTML is only a bit better (for humans). Maybe I should take a clue from AFT. It is very forgiving of humans. It doesn't expect you to construct a document. It expects you to write a document. In the case of EFX, XHMTL is artificial complexity.
EFX 2.0 should have some natural complexity.
Permalink | Friday, April 28 5:17 PM
Blog-in-a-box
Although the end-user of a typical EFX distribution is not a layperson (this ain't a Gooey APP), I'd like to see the distribution come with EFX, Storybot and a sample site template (a weblog!). It would ideally look like this:
- storybot.exe
- storybot.cfg
- efx_plugins/
- blog_template/
The user would edit storybot.cfg, modify blog_template/blog_settings.cfg to customize their site, and run "storybot.exe". This isn't what I have right now.
Now you have to install ActiveState Tcl (20+ MB), set a couple of environment variables (OS dependent!) and invoke a batch/shell file that runs storybot.tcl.
This needs to change.
Permalink | Wednesday, April 26 11:43 AM
Big Buddha!
I really like this quote:
I think about organic code as being the big Buddha. Organic code is code that grows, evolves and is a bit hackish. Architected code is like the small Buddha. It has proper packaging, structures, a clear/clean API and design patterns that dictate extension.
- EFX core is the small Buddha; EFX Storybot is the big Buddha.
- Structured Text is the small Buddha; my AFT program is the big Buddha.
In that same vein:
- Vi (editor) is the small Buddha; Emacs is the big Buddha.
- Tcl strives to be the small Buddha, but it is really a medium-sized Buddha sucking in its stomach.
- Ruby (and Python) is the small Buddha; Perl is a big Buddha that doesn't bathe often.
- (g|t)roff is the small Buddha; TeX is the big Buddha. (LaTeX is the big Buddha forced to conform to some CMMI level 5 process.)
- Bourne Shell + (g)awk is the small Buddha; Korn Shell is the big Buddha.
- Oddly, C is not the small Buddha and C++ is not the big Buddha. Maybe...
- C is a small Buddha that sneaks out during meditation to play pranks; C++ is the bureaucratic Buddha.
I've had the most fun doing EFX Storybot, AFT, Tcl, Perl, Korn Shell, TeX, C and Emacs. (Awk was fun, but definitely a small Buddha.)
Permalink | Monday, April 24 9:55 AM
I am a programmer
I am a programmer. There--I need to say that sometimes to remember what I am. No, I am not a Software Engineer; not a Software Developer; not a hacker; not a craftsman; not an artist; not an explorer; not an inventor.
I am all of these and more. There is no vocation/avocation in the world quite like programming. I won't let this joy be sucked out of me.
I am most happy when I cut code, baby. Computer Keyboard = Electric Guitar. Jimi Hendrix, Eddie Hazel, Ry Cooder, Albert Collins, and Frank Zappa must know what I mean.
Okay, why this missive?
I've misplaced my copy of Jon Bentley's "More Programming Pearls" and I miss it :-(
... back to my regularly scheduled ramblings.
Permalink | Friday, April 21 11:18 AM
Now I only have to get it working ;-)
A weekend of testing and then deploy?
Permalink | Friday, April 14 11:14 PM
EFX 1.0 is running in production!
If you can see this, then it means that EFX 1.0 is now running in production (powering this blog).
(EFX 1.0 is a 100% Tcl powered content management system)
Permalink | Friday, April 14 9:39 PM
EFX 2.0 as Paradigm Shift
I've been thinking that I don't want EFX 2.0 to use XHTML. I don't want it to use HTML either (nor any XML variant). The more I look at (X)HTML/XML, the more my head hurts.
XML is really just a syntax. I can ignore it for now. Whether or not EFX 2.0 uses XML as the syntax or not, so as long as it can produce it (XHTML) and possibly read it, everything will be okay. It's probably HTML that bothers me the most.
When I think about laying out a web page, I think about much higher level abstractions than lists, tables (as layout mechanisms), divs/spans with classes, etc. I know I want a navigational menu here, some text here, pictures here and other stuff here and here.
My AFT does this for documents, but web pages aren't documents (at least not the ones I'm talking about here).
What would EFX 2.0 page markup look like?
Permalink | Monday, April 10 8:49 PM
New Monolith is being tested
The new EFX 1.0 Monolith is being tested periodically to this blog.
Almost all the features are present. I just need to bang on this for a while!
Permalink | Friday, April 07 11:33 PM
EFX 1.0 is getting close...
Its almost here............
Nothing to see yet....
Please ignore this message.
Okay?
Permalink | Friday, April 07 11:08 PM
Coding in Tcl is like...
One thing I noticed as I started my EFX 1.0 codebase migration back to Tcl. As I started to remember the syntax my fingers started moving quite rapidly over the keyboard. The code flowed.
Now, this isn't a
This is okay, because I have quicker turnaround with Tcl, but because of the limitations of awk and ksh, I found myself thinking deeper thoughts about my design. How can I do this in awk? Is there a better representation of this data? How do you really write a mime parser?
The past few months have given me a great deal of insight into the problem domain. I don't think I would have done this if I stuck with Tcl all the way through. I think all of that experience is going to feed into making EFX 2.0 an even better release.
For now, I am hacking away in Tcl and making great progress.
Permalink | Friday, April 07 10:04 PM
The Monolith is landing (back to Tcl)
Okay, back to EFX 1.x, otherwise known as The Monolith. Its about 70% done. I'm moving the codebase to 100% Tcl (ActiveState's distribution -- at 20MB it is quite a beast).
I started the Storybot rewrite in Tcl tonight. I got about 127 lines written (which is probably around 80% current functionality). Obviously, I am relying on tcllib (pop3, mime parsing, etc).
I haven't done much Tcl in the past 6 months. It feels quite lisp-y compared to ksh and (g)awk. This is an example of the kind of stuff I missed most:
file rename $f [file join [file dirname $f] .[file tail $f]]
It felt good.
Permalink | Wednesday, April 05 11:34 PM