Programmers like highly expressive programming languages, but programing managers do not.
I wrote about this on Twitter a few months ago.
Q: Why do people like Lisp so much? A: Because Lisp is so expressive.
Q: Why don’t teams use Lisp much? A: Because Lisp is so expressive.
Q: Why do programmers complain about Java? A: Because it’s not that expressive.
Q: Why do businesses use Java? A: Because it’s not that expressive.
A highly expressive programming language offers lots of options.
This can be a good thing.
It makes programming more fun, and it can lead to better code.
But it can also lead to more idiosyncratic code.
A large programming language like Perl allows developers to carve out language subsets that hardly overlap.
A team member has to learn not only the parts of the language he understands and wants to use, but also all the parts that his colleagues might use.
And those parts that he might accidentally use.
While Perl has maximal syntax, Lisp has minimal syntax.
But Lisp is also very expressive, albeit in a different way.
Lisp makes it very easy to extend the language via macros.
While Perl is a big language, Lisp is an extensible language.
This can also lead to each programmer practically having their own language.
With great expressiveness comes great responsibility.
A team using a highly expressive language needs to develop conventions for how the language will be used in order to avoid fracturing into multiple de facto languages.
But what if you’re a team of one? Now you don’t need to be as concerned how other people use your language.
You still may need to care somewhat.
You want to be able to grab sample code online, and you may want to share code or ask others for help.
It pays not to be entirely idiosyncratic, though you’re free to wander further from the mainstream.
Even when you’re working in a team, you still may have code that only you use.
If your team is producing C# code, and you secretively use a Perl script to help you find things in the code, no one needs to know.
On the other hand, there’s a tendency for personal code to become production code, and so personal tools in a team environment are tricky.
But if you’re truly working by yourself, you have great freedom in your choice of tools.
This can take a long time to sort out when you leave a team environment to strike out on your own.
You may labor under your previous restrictions for a while before realizing they’re no longer necessary.
At the same time, you may choose to stick to your old tools, not because they’re optimal for your new situation, but because it’s not worth the effort to retool.
Related posts Programming language subsets Microsoft developers need not apply The myth of the Lisp programmer (Regarding the last link, think myth as in Joseph Campbell, not myth as in Myth Busters.
).