Re^7: the disadvantages of mini-languages

Almost the only time I will rewrite Perl scripts is to translate them to Makefiles.

Ok, you've piqued my interest. Would you mind providing a simple example, either in this thread (as an example of a mini-language in action) or in another thread?

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Comment on Re^7: the disadvantages of mini-languages

Replies are listed 'Best First'.
When make trumps Perl (was: the disadvantages of mini-languages) by Aristotle (Chancellor) on Feb 19, 2005 at 01:39 UTC
Any long chain of transformations depending on each other is a good candidate. F.ex I have been meaning to write a makefile for web galleries, ie a task where you take a large bunch of pictures and generate thumbnails and a batch of index pages — but only when a thumbnail doesn't already exist or only when there's new pictures to add to an index page, so that you can toss a few more pictures into the heap and regenerate the gallery without waiting an eternity for everything to be regenerated. Doing all the necessary checks in Perl to achieve that kind of statefulness is easy, but the code turns out messy. For make, this job is just natural. A simply example would be my corefonts makefile. It was originally a nasty shell script. The makefile looks like a mouthful, but most of it amounts to “constants,” and the real code is just a few lines at the bottom and all the rest happens automagically and it won't redownlad or reextract files you already have. Note that all of this works better the more self-contained the parts of your toolchain are. The recipe for each rule shouldn't be more than 2 or 3 lines for the majority of cases and should only rarely need to be more than even one. Then you just tell make how to assemble the machinery and it makes everything happen for you. Get to understand the tool well and it's just amazing. Makeshifts last the longest.	[reply]

Replies are listed 'Best First'.

When make trumps Perl (was: the disadvantages of mini-languages)
by Aristotle (Chancellor) on Feb 19, 2005 at 01:39 UTC

Any long chain of transformations depending on each other is a good candidate. F.ex I have been meaning to write a makefile for web galleries, ie a task where you take a large bunch of pictures and generate thumbnails and a batch of index pages — but only when a thumbnail doesn't already exist or only when there's new pictures to add to an index page, so that you can toss a few more pictures into the heap and regenerate the gallery without waiting an eternity for everything to be regenerated. Doing all the necessary checks in Perl to achieve that kind of statefulness is easy, but the code turns out messy. For make, this job is just natural.

A simply example would be my corefonts makefile. It was originally a nasty shell script. The makefile looks like a mouthful, but most of it amounts to “constants,” and the real code is just a few lines at the bottom and all the rest happens automagically and it won't redownlad or reextract files you already have.

Note that all of this works better the more self-contained the parts of your toolchain are. The recipe for each rule shouldn't be more than 2 or 3 lines for the majority of cases and should only rarely need to be more than even one. Then you just tell make how to assemble the machinery and it makes everything happen for you. Get to understand the tool well and it's just amazing.

Makeshifts last the longest.

[reply]