I Use Ugly Languages(connorberry.com)
connorberry.com
I Use Ugly Languages
http://connorberry.com/2012/12/21/i-use-ugly-languages/
8 comments
Sadly, there's a difference between how 'clean' or nice the language is, and the "real life" use and deployment.
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.
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.
I'm pretty sure that if Python had a slightly easier deployment option it would replace several of the other scripting languages in my toolbox. The main pain points for me right now are the Python 2 vs 3 split (only a problem because I'm frustrated by uncertainty), and insufficiently clear ways to package apps for deployment (I'd really like to be able to deploy a tool as a single file executable) without having to install a separate version of python on the target machine.
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.
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.
Prolog -> Lisp ? Prolog is a logical and Lisp is Multiparadigm/Functional, completly different.
I'd also change Erlang for Go, and maybe add Scala there too.
I'd also change Erlang for Go, and maybe add Scala there too.
Yet whenever you see prolog or datalog reimplemented (see On Lisp, PAIP, AllegroGraph, Clojure Datalog implemetation, etc) the implementers have tended to appropriate Lispy syntax rather than the original Prolog syntax.
This might also just be laziness, or perhaps simply love for lisp syntax by people using lisp.
This might also just be laziness, or perhaps simply love for lisp syntax by people using lisp.
"the implementers have tended to appropriate Lispy syntax"
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.
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 think it's the same reason that you replace Erlang with Go, because they both aim for concurrency. So in terms of writing ai programs, why can't Prolog be replaced by Lisp?
Because Prolog and Lisp are really quite different. Have you used Prolog for a significant project? Its resolution and backtracking capability can be very powerful for some problems, and you'd have to implement them in Lisp.
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 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.
The `Erlang -> Haskell` is weird, they're very different development model and systems, covering rather different "use cases". Yeah sequential erlang is a rather ugly functional language, but that's pretty much the least interesting part of erlang.
Shell -> Perl
That's what I usually do when my shell scripts get out of hand.
That's what I usually do when my shell scripts get out of hand.
(Voted down by mistake, sorry. Damn trackpad on Linux.)
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.
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.
Python is also better for Shell with this: http://amoffat.github.com/sh/ if you want to do something mildly complex
If these are the ugly languages, what are the elegant ones? Python might cover some of the items on this list, like Perl and TCL, but what is the elegant alternative to Erlang? I can't think of anything. Most of these language have a strong niche where they are simply the right tool for the job, regardless of their elegance.
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.
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.
Erlang is actually a fairly elegant language, it's just weird-looking to people who are used to C or Pascal.
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.
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.
The pro erlangers I know are mostly lisp or haskell programmers who consider erlang as a pact with the devil.
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.
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.
> Erlang is actually a fairly elegant language, it's just weird-looking
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)
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)
Why is python considered elegant where tcl is not? I find python robust rather than elegant.
I would say that the list boils down to free-form vs. structured more than anything else.
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.
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.
I thought elegance was about conciseness and freedom of expression leading to creative and "neat" solutions to problems?
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.
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.
Scala maybe? But yeah erlang has its own austere beauty.
Why would prolog be considered an ugly language? Maybe weird, but not ugly: minimalist syntax, very few special cases, isomorphic to first-order logic and almost equivalent to the pure mathematical notation. I would not recommend it for general-purpose programming, but it solves a specific set of problems better than any other language.
Agreed. Prolog as a language is about as direct and minimalist a representation of its concept as it's possible to get (along with Lisp and co). In that respect I would say it's rather a fine language as beauty goes.
"But is it better for me to get started and end up with messy code, or to not start because I want things to be correct or good?"
Ruby looks good without any effort.
Ruby looks good without any effort.
This is insecurity masquerading as insight. One does not need to invoke mental frailty in order to defend the use of a particular language. Nor is there a dichotomy between "a focus on getting things done quickly" and beauty or elegance.
In short, this is lazy writing capturing a lazy thought process. Nothing to see here.
In short, this is lazy writing capturing a lazy thought process. Nothing to see here.
Without being quite as harsh, I generally agree. I have generally found new or inexperienced developers become scarred by projects that fall behind more than projects that grow out of control, and bias more towards getting something done, fast. Totally agree that the best advice for OP is to not underestimate his own ability to perform well in a better language. I think it is folly to assume you need a less structured language to get up and running faster.
This very much reminds me of the Worse Is Better line of thinking.
This very much reminds me of the Worse Is Better line of thinking.
It's a pointless article without knowing what the project is.
I wouldn't use perl for my multi-threaded enterprise messaging solution, but I might use it for a useful text analysis tool.
I wouldn't use perl for my multi-threaded enterprise messaging solution, but I might use it for a useful text analysis tool.
>It's a pointless article without knowing what the project is.
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.
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.
I manage the maintainance of millions of lines of scripting code that's not type safe. Type safety is definitely not a significant problem, nor is speed.
"I Use Languages I Already Know" might be a better title.
I feel the same when I write in English versus French. When I write in French, I feel like I am spending much more time trying to make my text elegant. I think I've heard this from other people as well but in the end, it's probably mostly subjective.
These aren't so much my designations, as what I've seen in various references on the internet over the years.
Confer for citations of peoples elegance / cleanness opinions:
In almost every case I would face the mental blockage mentioned if I were to try to use the language to the right, compared to the one on the left side.