I Use Ugly Languages
connorberry.com
connorberry.com
In short, this is lazy writing capturing a lazy thought process. Nothing to see here.
I wouldn't use perl for my multi-threaded enterprise messaging solution, but I might use it for a useful text analysis tool.
Exactly. I recall being assigned a small project years ago to print a route list in a particular way. I'm sure it could have been done with maybe a hundred lines of Go or Python or whatever language du jour. But it came down to a two line shell script. Which one is supposed to be the elegant one again?
Also, there is a reason that a C compiler is written in C but a Java virtual machine is not written in Java.
And anything with substantially more than a thousand lines of code that isn't written in a strongly typed language is all but guaranteed to be a maintenance catastrophe full of security vulnerabilities. (Or a pile of slow, hideous fail as a result of all the manual runtime type validation you have to do to prevent that from happening.)
Elegance is a function of adaptability to purpose. A screw driver is an elegant tool to screw in a screw but an inelegant tool to hammer a nail.
This very much reminds me of the Worse Is Better line of thinking.
Perl -> Python
PHP -> Ruby
C++ -> Java or Go
Erlang -> Haskell
Tcl -> Python or Scheme
Prolog -> Lisp
Shell -> ?
Confer for citations of peoples elegance / cleanness opinions:
Tcl war usenet posts
Perl vs Python wars
C++ - Paul Graham's article on what languages solve,
Rob Pikes reasons for creating Go.
Erlang - Damian Katz "What Sucks about Erlang"
Prolog - see above (re prolog syntax in Erlang)
Tcl - Eric Raymond's comments on Tcl and Perl vs Python
Shell - no citation, but I think defensible
I'd also change Erlang for Go, and maybe add Scala there too.
This might also just be laziness, or perhaps simply love for lisp syntax by people using lisp.
But doesn't it make sense that, once you're extending a Lisp dialect to add some Prolog implementation, you'll keep using the Lisp syntax?
I don't see it a question of lazyness or love: one of the main point so many people accept to deal with Lisp's seemingly crazy parentheses is homoiconicity.
It's not that parentheses are that great and that we love seeing: ))))))))) or )))]))]))) (in Clojure).
It's that the benefit (homoiconicity) far outweight the cost of using that syntax.
I read the sources of an algorithm-derivation system that was done in Prolog (you give it some model relationships and it pattern-matches to find a learning algorithm to fit model parameters to data). It was quite elegant and got a lot of power for free.
I understand where this comes from. Personally I sketch/think on paper/org-mode a long while, then throw code at the wall, then iterate back to paper...
Afaik, Perl/Moose has better structure and OO today than the other scripting languages. The same argument can be made for lisp, compared to most everything, but it is also a hacker's delight.
That's what I usually do when my shell scripts get out of hand.
Deploying Ruby for example is an absolute versioning and compatability disaster in my opinion. You almost immediately _require_ sandboxing, which on it's own requires using 3rd party tools. Deploying a Ruby program ends up to be quite a bit of "extra" work, more glue that can fail. I'm not saying PHP is better, although it's not as bad anymore as it used to be, but choosing Ruby as a PHP alternative? No thanks.
Choosing Java over C++ suffers from more or less the same problem, but this being that it usually relies on a server like tomcat or jboss, and even if it doesn't, it still suffers from the same problems, and requires a run-time, which is a pain in the ass to deploy properly. The other issue is that there are a LOT more stupid java developers than there are good-ones. And even good-ones apparently seem to have the illusion that memory-management and usage isn't an issue, and that you can't have memory leaks in Java. And while I prefer the java syntax and language itself over C++, the latter isn't that bad, certainly with the Boost library available, and when you keep yourself to a few strict rules, writing 'modern' C++ can be surprisingly clean and quick in both development and deployment. Not saying you can't accidentally launch a nuke and cause ww3 with C++, especially when using templates, and when using the boost libraries, link them static, you'll save yourself a whole lot of trouble :)
Anyway, for a lot of these options, I'd just say "Python", which is readily available on most systems, and mostly 'just works'. In the list, Python would be my replacement for Perl, PHP/Ruby, Tcl and Shell. Perl's problems are simple: pretty dated by now, and more 'quick hacks' ends up in production than I'd like, while nobody knows exactly anymore what they do, and nobody feels like touching the code "because it works".
Prolog and Lisp I wouldn't even touch for real-world usage, and I'm not familiar enough with functional programming languages to consider Erlang or Haskell as "the best tool for the job" for any problem I've encountered.
Disclaimer: I'm a developer writing in C/C++/Java/Python, who has more than touched Objective C/Ruby/PHP/Perl/bash scripting/C#/..., and who is also maintaining a linux server infrastructure. These opinions have been formed over years from own and other people's experiences, and oh did they change. For example, I first liked Ruby, but then it bit me in the ass. I don't understand why all these 'new' projects, which clearly show 'the way to go', like Puppet, Chef, Logstash, ... are all using Ruby for some reason.
Right now I'm considering Prolog for a project, because I just can't find anything else that does what it does as easily - essentially fact chaining and logical interferencing. But I'm just planning to use it as a part of a system rather than the entire application.
Trying to shoehorn a more elegant language into one of these niches would probably lead to awkwardness, especially if it's something the language wasn't designed to handle. In a way, I think using the right tool for the job is itself a form of elegance, regardless of the tool's superficial appearance.
Perl and PHP are ugly not because of how they look on the page but because of their bodged-together semantics, with magical variables that do magical things, keywords that don't mean what you think they mean, etc.
If I had a word to describe Ruby it would be, fittingly, "kawaii". Like a girl from a third-rate anime whom you think is adorable as a teenager, then you get older, grow some taste and it dawns on you that her nose is in completely the wrong part of her face.
It's all relative. Joe Armstrong himself said he made engineering compromises in the design of erlang because he was concerned about software useful for the telco industry, not an academic exercise.
Most of the "sequential erlang" syntax is ugly as hell, from the various separators (statement, case, function) to the (downright dreadful) records syntax or the function reference syntax (both anonymous functions and reference to named functions are pretty bad).
The language itself, as in the model and the underlying concepts and ideas, are generally neat, but the syntax isn't when compared to Haskell or even MLs derivatives.
Aside from the literal bit syntax, that part is beautiful (for the most part, the complex modifier atoms still weird me out)
All python code looks about the same due to it's structured nature. Because of this, the language appears more "elegant". I'm a devout PHP coder, and build on custom frameworks to do whatever it is that I need. I have some pretty big applications as well. My preference is entirely for free-form languages due to the fact that I can control elegance and readability. It may require more effort, but it is certainly doable. In fact, I'd like python a whole lot more if I wasn't forced into the structured paradigm.
In short, lazy coders make ugly code despite the language.
The way you describe python as a language of structured constraint is pretty much the opposite of my understanding of programming language "elegance", with lisp or haskell being some kind of ultimate to aspire to.
Ruby looks good without any effort.