Slashdot Mirror

In over 40 years of working with computers, I've seen the cycle happen over and over again: Code is worthless unless it does something useful. Thre is a demand for applications, but the ability to produce these applications is deficient, so there is a demand for even the worst programmers until employers scale back their expectations. One statistic bandied about is that over 90% of all programming projects are never completed. Why? Because there are too few teams that can produce good products.

So much code is computer-generated these days that the real talent is in analyzing processes and DEFINING the functions. Once the process is defined, any generator, Foreign Programmer or first-year high school graduate can be taught to code to the requirements. Even some of the hard decisions in programming are falling to AI as long as the analyst can adequately describe inputs and outputs, or functions, or look-feel. There is a reason that some fast, cool code is developed in short lead times in Haskell. A program like Libero http://legacy.imatix.com/html/libero makes good programmers; the program works even if the code is not totally efficient, as long as the definitions are correct and complete.

Learn to design good solutions and there will always be a position for you. Remember, though, the position that makes use of these skills will probably change drastically over the years as the tools get more sophisticated. (Another statistic bandied about is that the workers my daughter's age (32) will have over 30 career upheavals during their working lifetimes.)

they want to make sure everyone is nice and compliant about upgrading when they decide to take httpd over to java like all the other java kool-aid they are selling --- Maven is Jonestown, lets all program in XML because its standard! Cultures breakdown when there is too little disent and questioning of authority, the apache foundtion is headed in that direction.

Lets move on, SOA and all that, most people don't need any of this mod_* crap and could use:
thttpd he has other servers there, too and http_load.
lighttpd I'm moving to this sweet little server for most apps and the home site runs ea php and ruby on rails
AOLServer like OpenACS runs on
Boa
fnord from our boy who did the (in)famous benchmarks
Cherokee I root for this one for some reason.
gatling
cthulhu
yaws in erlang, should support more simul. connections than the unlying OS can support.
dhttpd
Litespeed check out their php benchmarks
thy
roxen
mini-httpd never tried this one
xitami I have a intranet server running for 5 yrs (without upgrading xitami) on xitami Solaris, simple, small, easy to admin, never dies max uptime was 1000 days+.
eddiefor complex load bal and geographic distribution
hiawatha

And for the love of god, please at least design your sites to get their images from images.mysite.com if possible so that you can use a non-bloatware web server to server the images, reserving horsepower on your apache server for stuff that actually _requires_ some features of apache.

http://www.hcsw.org/awhttpd/ updated on 12-06-2004
http://www.norz.org/zawhttpd.html
http://cr.yp.to/publicfile.html

Fair and balanced.

But it's not really a war between opposing sides. It's a war between the furture and the past. And the past is doomed to failure, simply because the technology curve has progressed to the point where large chunks of the software ecology are essentially free. Microsoft and Oracle unhappily sit right in the middle of this territory. Apple, IBM do not. I wrote about this in an editorial last year.

Is GSL (aka GSLgen), part of the RealiBase OSS toolset from iMatix.

Yes, I'm biased, I use it extensively. Extensively.

Write your metamodel in XML, build code generation scripts, generate anything from interfaces to database layers to entire applications.

I took some of the examples from CGIA (which is an excellent book, I read it and I like it and I recommend it heartily) and converted them to GSL - simpler, clearer, more obvious.

If you are a professional programmer you need code generation. This is simply a basic technique, like editing text with a visual editor and not edlin. And of all the code generation tools out there, GSL is by far the most flexible and powerful, mainly because it was designed from the ground up, and has been used and evolved over about 10 years specifically as a code generation tool (unlike XSLT which does the job but with more weight and less elegance).

In my journal, I include a GSL script that generates a complete C interface layer for MySQL, turning a simple description like this:

<table name = "history" description = "Message History" >
Holds all messages received and sent. The command and body are parsed
from the smstext.
<field name = "id" domain = "recordid" >Record id</field>
<field name = "groupid" domain = "id" >Parent group</field>
<field name = "userid" domain = "id" >Parent user to/from</field>
<field name = "incoming" domain = "boolean" >Incoming message?</field>
<field name = "appl" domain = "msisdn" >Application MSISDN</field>
<field name = "text" domain = "smstext" >Message text contents</field>
<field domain = "audit" />
</table>

Into a complete abstract interface.

Whatever: code generation is a cult technique that deserves a place at the center of every serious developer's toolbox, and this book is possibly the first one that I've seent that may achieve this.

Enjoy.

Note that the original article discussed scripting as a development tool, not as an automation tool for end users. It's in this context that I like XML.

Yes, it's clunky, but it works exceedingly well if you have the tools to handle it. GSL is the "generator scripting language", a tool made by iMatix and distributed as part of their RealiBase package, a rather large and eclectic collection of OSS tools.

Personally I find GSL extraordinary, but totally outside the scope of this discussion. I simply can't imagine working without it: like I said, most of our development centres around high-level XML scripting. GSL is the engine that turns these into whatever code we actually have to run. gsl (the tool) interprets scrips in GSL (the language) which compile the XML into a target language. When we're faced with a new problem domain, we spend some time understanding it, and then we define one or more XML language that implements the highest-level scripting model we can design. We build code generators in GSL that take these models and turn them into code. GSL is beautiful for this because the language is intimately tied to XML, and very tight, and so we can build maintainable code generators of thousands of lines.

It's very close to the model described in the article to build plugins for the Sims, except that we compile, not interpret the scripting language. This is not a critical matter: the important thing is that the language exists and allows a developer to think at a higher level, so work better and faster.

You'll find various references to GSL on the web, but most people still use a very old and limited version. The more recent releases are closer to "normal" languages but still have the ability to swim in XML like penguins under the ice.

Feel free to ask me more questions on GSL. I happen to know the authors quite well. I once asked them why they did not publish the tool more widely, instead of hiding it inside RealiBase. Their answer was something like this:

"We made the tool because we needed it. We share it because we share everything we can't sell. We don't spend time publicizing it because we enjoy the vicarious pleasure of people discovering it and saying "what the heck?!" And we have other axes to grind."

So what you want (if the article is correct) is a language that will write apps for you. My company makes such a thing - an open source tool called GSL. There is an old version available online and a newer version here.
Email me if you need help. And you will.
Also, a PDF on code generation that may enlighten.

So what you want (if the article is correct) is a language that will write apps for you. My company makes such a thing - an open source tool called GSL. There is an old version available online and a newer version here.
Email me if you need help. And you will.
Also, a PDF on code generation that may enlighten.

So what you want (if the article is correct) is a language that will write apps for you. My company makes such a thing - an open source tool called GSL. There is an old version available online and a newer version here.
Email me if you need help. And you will.
Also, a PDF on code generation that may enlighten.

Such as that implemented by Libero.
State machines are very good at handling large numbers of events and treating them in context.
The biggest different over classic event-driven GUIs is that the UI states - being your different views, perhaps - are well-defined and seperated, unlike a classic CUI in which there is just one big event loop.
In my experience, using FSM models to define the UI logic (and then turn this into code automatically, like Libero does) makes it easy to build very complex UIs.
Lastly, I think the problem is the same as faced in many situations, namely that of dominating a complex problem.
The key technique is to turn the problem into a hierarchy of solutions rather than to handle it as a single large flat issue.
Abstraction is your friend.

Imatix, the makers of the awsome open source webserver Xitami, has a similar product called 'Libero'. It allows you chart and build your code as you go.

http://www.imatix.com/html/libero/

--
Well, querying the web, I found that imatix actually has something remotely related .. . Since I run their ftp+webserver for personal use for free, I might as well put up the link here.

I also found Fujitsu Cobol for the Web.

PHP's a fine choice for this; I'd probably use it myself. The only alternative that readily springs to mind would be to write a daemon in C to interface with Imatix's great open source Xitami web server, which is especially friendly for this sort of hackery.

Anyway, I look forward to playing Tradewars again. Good job!

--

I think the open source community needs to spend more time in the software design phase. Where I work, we don't code until we have TONS of diagrams/description of logic done. Overall, I think it leads to a much better product.

Documentation and DOL are extremely important... reminds me of a development tool that I have used that would compile psuedo code... haha. Funny stuff.

Have to agree. As it happens, I've been looking around lately for some higher-level design tools, and unfortunately, there's not a lot out there in the free-software realm. freshmeat lists Libero and TCM, which look good, but probably aren't the ultimate in software design.

Speaking of doc, what do you guys feel is the best tool for managing it. I mean something akin to doc++ or Doxygen. Are there any other better solutions?

I haven't really used any of the doc-generating programs out there-- but let me mention gtkdoc, which for C API's is probably the best of them all. (See here for an example-- ain't it beautiful?) It works through Docbook SGML and the Jade processor to produce HTML, TeX, man, and anything else you have a stylesheet for. Unfortunately, the whole thing is a b**** to get working. It's a huge mess of Perl scripts and weird Makefile rules, I tried it one day and barely made it out alive :-(

(But man, results like that GLib documentation would be worth it!)

Of course, however, all those tools assume that your approach to documentation is placing specially formatted comments (Javadoc-style or otherwise) above each of your module/type/function definitions. I don't know of a better way to go about it-- tying the implementation and documentation together makes it hard to neglect keeping the docs up to date-- but it surely isn't the only approach.

Oh, and a regular text-editor of course.. like vim or emacs or heck, edlin, whatever makes you feel warm and fuzzy..

There is no easy way to make webpages that rock, except copy/paste. (Which incedentally is what htmlpp is good at :-)