Language Design Choices

Quick bit of background, I’ve used many programming languages over the years.  Though in general I would bias myself to being a procedural/object guy rather than a functional programmer.   Though I can say that I’ve done big projects in most of the popular languages at this point [C++, Java, JavaScript, Perl, PHP, Python, Ruby].   So, this post is more for trying to formalize a few of my thoughts, about some of what I’ve been working with/on.

One of the interesting things about languages is why they were created and then how did they evolve.  I might hold up awk as one of the first unixy interpreted languages, but I would sooner hold up Perl since it came from the open source world (you didn’t expect that AT&T was going to change awk, but Larry would change perl).  While we can look at perl and many people would happily talk about what is wrong with the language, myself included, fundamentally it was a great tool…  Most people forget that most of the original CGI programs on websites were written in perl – it got text in a way that no other tool did at the time (and most still dont).

I got into a discussion about how Ruby sucks, but realized later that this fundamentally was an origin problem.

Author Centered –

I keep on making lots of comparisons between Ruby and Perl, maybe it all started because they both have “unless” as a keyword.  But, in thinking about it deeper most of the idea is that Perl has a single parent Larry and Ruby is Matz, the majority of the design of the language came from their world view.  The challenge is that most people have a strong understanding of a specific problem set, but they miss other details due to lack of understanding.  In perl, the OO and Variable hiding (my vs. local) I think demonstrates this, while in Ruby “returning from lambda” and extending base classes show it in other ways.

Ruby Detail:  If you extend Hash with a “fizzle” method, the challenge is that in a large project you import 57 gems one of which implements a “fizzle” method and the programmer before you used it…  You now have to figure out which gem extended your Hash class and what does the fizzle method do…  Pretty much impossible.

Contribution Centered –

Just have to find a way to slip PHP in here.  It’s a kitchen sink, some of the language has OO style, some has procedural, sometimes the names change based on the phase of the  moon (look at the string functions).  It’s very clearly an open project where contributions are the primary driver, rather than strong design.

Committee Centered –

Python, Java, JavaScript, C++ all of these have a strong committee  driving the design of the language, some are more old school some are more new school (C++ vs. Python).  But, what’s interesting is that proposals for the language end up being consistent with the existing style (vs. PHP) and tend to have lots of world views taken into account.  There feels like a correctness to the idea that False/0/empty string/empty array are all “false”.

In the grand scheme of things they are all tools, they all get a job done, it’s just working through the nuances of the langues takes time.  What’s interesting is that if you spend time to really work with these you will learn something new about all of the others that you will work with now and into the future, but sometimes it’s helpful to have a framework to put the underlying design into.

A Few Final Thoughts –

  • Python – whitespace is great, but it makes adding/removing nesting hard.
  • Perl – You still rock for crunching a file quickly.
  • PHP – Visual Basic…  the early years.
  • Ruby – You’ve got more limits than you’ll admit to.
  • C – When you’re good, you’re great, when you’re not …. run.
  • C++ – Still teaching us tricks, separating the men from the boys.
  • Java – High hopes, not fulfilled.
  • JavaScript – Your second coming (nodejs) has promise
  • ActionScript – Why?