| 1 Comment

What do Scheme, Bash, and elisp have in common?

They're infinitely flexible and infinitely customizable and, if you force two users with great libraries of customizations to swap profiles, you are a cruel, cruel person.

Programming language design has a strange dogma that minimalism of features is a greater good, that distilling the smallest possible set of elegant core axioms is both possible and profitable. From there, offering this set of axioms leaves the dirty business of making workable software to blue-collar workaday programmers.

(I helped the authors of a book of interviews with programming language designers craft interview questions. Few designers of popular languages believe this fallacy. There may be a connection.)

Minimalism by itself is no vice. The minimalism which leads to insufficiency and fragmentation becomes a vice.

For example, consider perhaps the ultimate counter example of minimalism in programming language design. PHP's multiple searching functions differ in searchtype( $needle, $haystack ) and search_type( $haystack, $needle ) and searchType( $neestack, $haydle ) and other permutations—and these are core language features.Similarly, the Java language's insistence that named classes are the only sufficient mechanism of abstraction leads to the use of XML data structures interpreted to generate code during startup time (as if XML were a sufficient programming language, much less a reasonable syntax for the bytecode generations and modifications necessary to emulate a sort of dynamic language) as well as the use of large IDEs to hide the generation of this XML from hapless workaday programmers.

Similarly, I have a wonderful ~/.aliases file sourced from my ~/.bashrc which contains aliases, aliases which use aliases, functions, functions which use functions and aliases, and other shortcuts I've distilled from repeated tasks. Someone can ask me "Hey, how do you perform memory leak analysis on that specific shared library?" and I can type a short command and confuse everyone because no one else understands my specific aliases.

(Alternately, I can do what a coworker does by refusing to customize my bash environment or my ~/.vimrc or ~/.screenrc and learning to get by with the default configuration on any decent free Unix-like box... but I'm far too impatient for that.)

If programming a large system is, at its heart, the distilling of the problem space to discover the proper terms to describe the business roles of the solution (and I believe that the Forth, Lisp, and Smalltalk people are right to describe it as such), then modern languages must provide appropriate mechanisms to devise, manage, and exploit vocabularies sufficient to solve business problems effectively.

Yet there's also a level beneath which the language of the solution is irrelevant, and that level is almost always "You can roll your own object system!" or "Exception handling is what you make it!" or "Iteration/recursion/goto/call-with-current-continuation is the only true flow control mechanism" or "The hash/cons/char * is the only true data structure!".

In other words, minimalism only works in practice when that minimum overlaps sufficiently with the necessary. Fail to provide the necessary for certain problems and you risk use-but-fragmentation or, perhaps worse, irrelevance in that problem domain.

Next time: minimalism in Perl (believe it).

1 Comment

In the middle of reading a written _very_ much appreciated, I'll have the audacity to discuss this with my own opinion.

I recently discovered the acronym DSL, thanks to Sukria++. I did not know it before, but I had the concept in my mind.

I believe that every programming language or interpreter (like bash), more or less, fits in the word "minimalism", and that the tools and function libraries, created with the "minimalism", is what can lead to DSLs.

In computer science, I would say (without being licensed) that "minimalism" is binary. One or zero. We can see from the start of hardware, through the kernel up to the user space.

Above this layer, the first born DSL, are: programming languages.

The "problem domain", for these first DSL, is to facilitate the creation and writing of software algorithms.

Over programming languages, (that are over interpreters and machine code compilers), is where born libraries and applications, that covers DSL beyond writing programs.

All this, IMHO and without many research about, just commenting :)

Really nice book !!! Greetings.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

sponsored by the How to Make a Smoothie guide



About this Entry

This page contains a single entry by chromatic published on January 3, 2011 11:08 AM.

The Best of Perl 2010 was the previous entry in this blog.

The Minimalist Object System and Your Lousy Axioms is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by the Perl programming language

what is programming?