Hacker News Reader

" lousy IDE support, "

This is valid in a sense, but it is also important to remember that a lot of software was built with emacs and vi or even more ancient editors.

"If you're serious about software, concentrate on writing something that is reliable as hell and easy to maintain and install. "

That is terrible advice, not so much the sentence itself as the "stay away from powerful languages" spin you give it, as in

"Messing around with unstable languages is a lot of fun. It's educational too. But don't build your business around it. "

There are profitable companies using Haskell and OCaml (and Lisp and J and .. )!

You make a decent point then spoil it by stretching it too far, to the point of farce.

One situation in which you should definitely not use advanced languages is when you know you have (or intend to hire) very dumb "programmers" who won't be able to warp their heads around the "exotic" language, which probably doesn't have a "Learn in 21 days" book to go with it.

Many companies doing outsourced software do hire these "middle of the curve" programmers and will do well to stay with "stable" languages. If you have a bunch of bright programmers doing something innovative, it is a completely different situation.

By your logic PG wouldn't have built Viaweb in Lisp, FlightCaster wouldn't be using Clojure and so on.

Taking just one example, Clojure is evolving very fast, which for you would be "unstable". I know at least 4 startups using Clojure, one using Scala and no one's yet complained of "instability" and lack of IDE support destroying their productivity. There are tradeoffs (IDE maturity being one, if you are an I-can't-program-productively-without-my-IDE kind of guy ) with any language selection, but the consequences aren't as dire as you make it out to be.

As I said, this is bad (or rather very one sided, which amounts to the same thing in practice) advice. There is an excellent rationale for building certain types of applications in powerful languages, what PG calls LFSP - languages for smart people.

PG and other people have made this argument more eloquently than I can, so I'll refrain.

"Python/Django and Ruby/Rails are only barely stable enough to work with."

heh heh! Sure, What do you use then? COBOL? Should be "stable" enough for you I guess.

Somebody should tell all the stupid programmers using RoR or Django to run companies that they are being foolish, using "barely stable" software. ;-)

Go easy on the sarcasm and ridicule; it doesn't help you make your case.

PG built Viaweb in Lisp because there was no Ruby, Python or Perl back then. When there are no libraries to chose from, you pick a language that lets you write libraries quickly. Today we boldly go where many have gone before, and that means that we can benefit from technologies others have built. Standing on the shoulders of giants, and all that.

I'm arguing that if you want to run a business you should be pragmatic about the language you pick.

The second half of your post seems to consist of mere hyperbole and strawmen (COBOL? Right). If there is excellent rationale for picking an esoteric language, I'd love to hear it.

"PG built Viaweb in Lisp because there was no Ruby, Python or Perl back then."

First, you were the one suggesting we don't use Ruby or Python, in 2009 in the name of "stability". and now you are saying PG would have used these "unstable" languages in 1995 "if they existed" which brings me to

"because there was no Ruby, Python or Perl back then."

You are wrong.

ViaWeb was started in 1995

Perl was available (and being used to build websites) in 1995. Python was available too. Do your research before making ridiculous claims!

As PG says in one of his essays (link below)

"During the years we worked on Viaweb I read a lot of job descriptions. A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers."

;-)

You go on to say,

"If there is excellent rationale for picking an esoteric language, I'd love to hear it."

Start with the PG essay I quoted above, http://www.paulgraham.com/icad.html

many nice points there, for e.g:

"In fact, choosing a more powerful language probably decreases the size of the team you need, because (a) if you use a more powerful language you probably won't need as many hackers, and (b) hackers who work in more advanced languages are likely to be smarter."

He (and others) have written a lot about this. Again, do your research. You may or may not agree with the rationale he puts forward, but you undermine your own argument when you make up things to strengthen it (like perl not existing in 1995).

"PG built Viaweb in Lisp because there was no Ruby, Python or Perl back then."

Then why did he build Hacker News in Lisp?

As a test app for his programming language, of course. Not because it's the best tool for the job. He essentially built an entire language for this website -- that won't give you a highscore in the productivity hall of fame :)

And yet, even with Python and Ruby well established, he still felt the desire to build his own language. And the language he chose to build was Lisp-like rathar than Python- or Ruby-like.

I'm not sure how true this is. I was into Java in '95 when it had "lousy IDE support, buggy compilers, few libraries, few bindings to existing libraries, and so on". Java fell far short of its potential, and the ambitions Sun had for it, but still, that wasn't a bad call. People who got into Python early on made a similarly good call.

And also, some esoteric languages, like Haskell, the ML family, Erlang and so on have deep roots, they may not be mainstream but they aren't going away anytime soon. And sometimes something funny happens; anyone who has ML experience is going to feel right at home on F# and suddenly the library problem is solved, the IDE problem is solved, the bindings problem is solved...

If you were a .NET guy, would you consider building your startup on F#?

Why not? It's shipping with VS 2010.

> some esoteric languages, like Haskell, the ML family, Erlang and so on have deep roots

None of Haskell, ML or Erlang is an esoteric language.

I think you have a fairly high bar for esoteric :).

No. Esoteric languages are a fairly clear category of languages created to test the boundaries of language design.

Esoteric languages are not created for real-world usage (or even for usage at all), examples of such languages are INTERCAL, Thue, Unlambda, Moo, Befunge or Java2K. They can be turing tarpits (languages with extremely low number of commands), funges (multi-dimensional programs), nondeterministic (from a given global state A and a current instruction f, the next state `f A` of the system can't be predicted)…

There's nothing esoteric about a language such as Erlang created very specifically to solve industrial problems, or even about languages originally created for research (ML or Haskell), especially when they've now leaked into practical, real-world programming outside of academia.

> But don't build your business around it. Python/Django and Ruby/Rails are only barely stable enough to work with.

I agree with your basic premise but,

Python and ruby both have extremely good library support. Hell, python's stated aim is batteries included. Both of them have (al least semi-)mature Jvm implementations. Django has a stated policy of not breaking backward compatibility on point releases.

I agree you need to choose stable languages to work with, but if you are selling consulting services around Java god luck competing with BigCo. If you are building your products with Struts, good luck doing xml-situps.

If you think Python and Ruby have extremely good libraries your standards are pretty low. CPython itself is stable and well documented, but it's frequently breaking backwards compatibility across versions. My production servers can't get anything newer than Python 2.4, and the servers are barely a year old. Python 2.6 libraries almost never work in 2.4, and when I do upgrade to 2.6 I know a lot of my own code is going to break. If I used Perl instead of Python this would be no issue, because Perl _is_ stable and reliable as hell.

In two years time most libraries will move to Python 3.0, and Django is unlikely to patch security issues for Python 2.4 by then. In other words, I either have to spend a week upgrading stuff that already works, or I'll have to use insecure libraries. I don't like those options at all. How can we write solid and stable software if we don't have a stable foundation to build on?

C++ code I've written a dozen years ago still compiles and runs fine. Executables still run when double-clicked. If I scpy a Django directory to a different server I'm __surprised__ if it just works. Doesn't that say enough?

Python exists 20 years now and the spec is still not stable. Any Python library written today won't run on the computers of tomorrow. That's a pretty big price to pay for a print() function.

> If you think Python and Ruby have extremely good libraries your standards are pretty low.

.Net, JVM, Perl. Apart from these, which lanngauge has better Library than Python? Python is available on two of them. Ruby one one of them at least. (I dunno if ruby is avaialble on .Net)

> CPython itself is stable and well documented, but it's frequently breaking backwards compatibility across versions.

No. Afaik, Python has never broken backward compatibility in a majot way on point releases, and even minor details are dicussed ad infintum on the mailing list. Py3K was discussed for 8 years, before being released.

> Python 2.6 libraries almost never work in 2.4

Neither do Java's library which use generics or Autoboxing work in Java 1.4. However libaries comaptible with Java 1.4 work in 1.5(or 5.0 if you will), and so do libraries which were written for Python 2.4, do in 2.5 and 2.6. Languages can only guarantee backward compatibility. I am not sure which language you work in that guarantees forward compatibility.

> and Django is unlikely to patch security issues for Python 2.4 by then. In other words, I either have to spend a week upgrading stuff that already works

Django has a stated security policy. All security bugs must be fixed for 2 point releases prior to latest release. 0.96 got official security upgrades till recently. People have backported it to 0.95 and released.

> How can we write solid and stable software if we don't have a stable foundation to build on?

Sorry, but what you are asking here is again forward compatibilty. What will you have, Django never move to 3.0?

> Python exists 20 years now and the spec is still not stable.

Define stable. Python has 1. A reference implemntation. 2. Mutiple VM implemntations, targetting the popular ones. 3. Others, (Stackless, Pypy etc). Unless you use platform specific functions, your code will run on any of these. Fyi, the reference is, http://docs.python.org/reference/introduction.html .

Probabaly you hold a problem with this philosophy, from the reference (While I am trying to be as precise as possible, I chose to use English rather than formal specifications for everything except syntax and lexical analysis. This should make the document more understandable to the average reader, but will leave room for ambiguities.) But this is a debated, and concious decision.

Aside from those three? C and C++. Those libraries are not "batteries included", but they are plentiful and very mature. I like the "batteries included" part of Python though.

- I don't know if Python on the JVM is stable. Last time I checked Ruby on the JVM and .NET was in its infancy.

- They're not big breaks, and they are, as you say, discussed on mailing lists. The difference is that with a JAR file you can upgrade Java and you _know_ that the JAR will continue to run. With Python the only guarantee you have is that one of your libraries is going to throw an exception at some point after you upgrade. Essentially, you have to keep track of every library you use, and you have to check if it's compatible with the new point release.

- Not forward. Merely backward. Backward compatibility is offered by JAR files. You compile it, and even if the language changes the JAR will stay in place. Because the Java VM is stable you don't have to worry as much about precompiled libraries. I don't think Java is the solution to the world's problems, but at least old JAR files still run on modern JVMs (afaik). You can also design a language grammar in such a way that you leave room for future extensions. That is, to only make previously illegal statements legal. To change the semantics of legal statements (except for the rarest of corner cases) is, I think, a bad (but tempting) idea. You can have forward compatibility if you guarantee that code that uses new features won't compile or even attempt to run on an older interpreter. Essentially, if it runs it works. That is a hard guarantee, and the kind of thing you can build on.

> Define stable? That the language grammar doesn't change. Or more generally, that every version of the interpreter can flawlessly execute code written for version n - 1. Take Python: print used to be a keyword, now it becomes a function. I think it's too late for that kind of change, and it's only a minor blemish in the language anyway. You can't upgrade to Python 3 until every single library on your server has been updated. The number of man-hours this will take is staggering.

When you're actively developing in a language, these changes are only a minor nuisance, and upgrades come with a bunch of goodies. 10 years down the road you just want things to run, and with Python the only way to guarantee that is by deleting aptitude.

As was said before you are arguing for forward compatibility as backwards compatibility between point releases is guaranteed.

If you have code that works fine in Python 2.4 upgrading to 2.5, 2.6, 2.7 etc won't break your program. If you write you program in Python 2.6 you have to take special care if you want it to run in 2.4. Until Django decides to bump up the minimum version required, which I believe is at 2.3 now, you have nothing to worry about.

Since Python 3.x is not a point release, compatibility is not guaranteed anymore between 2.x. The 2to3 tool will take care of all the easier but time consuming tasks. Why waste the man hours converting 'print x' to 'print(x)' and 'xrange' to 'range' if there is a free tool to do it for you?

Really you are making a mountain out of a mole-hill. If you are not updating your software/site anymore with new features let it be. Python interpreters can run side by side.

I may be making a mountain out of a mole-hill, but I think these little things do matter. Python 2.6 introduced the "with" keyword, as you probably know. That's a breaking change, because it alters the language grammar and changes the meaning of previously legitimate programs. And it's a point release. This changes the "it won't break your program" statement to "this will probably not break your program".

When I see a statement that "backwards compatibility is guaranteed", I generally take that literally. And it's really a binary thing. Either it's guaranteed, or it isn't. And with Python it most definitely isn't.

We clearly look at this from a different perspective. I think it's a big deal, and you don't.

Ruby on the JVM is production ready. Apparently Thoughtworks generally deploy on it. I've got it in production too - there's a few very very minor issues, but basically rock solid.

http://martinfowler.com/articles/rubyAtThoughtWorks.html

> Take Python: print used to be a keyword, now it becomes a function. I think it's too late for that kind of change, and it's only a minor blemish in the language anyway. You can't upgrade to Python 3 until every single library on your server has been updated.

Stop using Python 3 as an example of "python instability" damn it, it's a change known to be incompatible, it's been in preparation for 5 years, it's not an evolution one's supposed to take lightly and it does not mean the end of the 2.x branch for at least a pair of years.

Before that, here's the track record of Python backwards compatibility: you can run Python 1.6 (2000-09-05) code on Python 2.6. In fact that's exactly what ElementTree does.

You cannot run all legit Python 1.6 code on Python 2.6 (except perhaps with special flags).

If Python 2.6 would flawlessly execute all Python 1.6 code I would have no complaint.

"I am not sure which language you work in that guarantees forward compatibility."

Lisp? :-)

Trying to avoid sounding like a fan-boy but your python bashing goes a bit far, imho.

CPython itself is stable and well documented, but it's frequently breaking backwards compatibility across versions.

I think you are over-dramatizing this. The big transition to Python 3.0 is still ahead of us. I'm using python since 2.3 and the path to 2.6 has been much less troublesome here than CPAN or the jar interdependency hell have ever been.

I especially find your claim that Perl is "stable and reliable as hell" amusing. CPAN has always been hit & miss for me and I've seen much greater variance in the quality of 3rd party perl modules than in python land.

If I scpy a Django directory to a different server I'm __surprised__ if it just works. Doesn't that say enough?

I think that says more about your deployment methods than about python or django.

Any Python library written today won't run on the computers of tomorrow. That's a pretty big price to pay for a print() function.

That's simply not true. Nobody stops you from running python 2.4 or older on computers of tomorrow. Just like you don't upgrade JVM versions willy-nilly in production.

Python has it's quirks and problems like any other platform. But the particular issue you're going at here (backwards compatibility) is really far from our biggest concern.

Actually, I like Python. I think it has a lot going for it and I use it on a daily basis.

You say that you shouldn't upgrade Python or the JVM willy-nilly. I say: why not? Why do you find it acceptable that languages break existing functionality?

It's not actually about breaking functionality. Both java and python go through a long deprecation period before removing language features. Most Python 2.4 code will run on 2.6 just fine, a few warnings nonwithstanding. Just like most Jdk1.3 code will run on 1.6, again with a bunch of deprecation warnings.

The bigger problem with willy-nilly upgrades is that the new version is not the version you tested on. It might introduce new bugs, unwillingly. I have seen many more subtile problems with minor version jdk updates (e.g. changes in GC behaviour or outright segfaults) than with any python upgrade so far.

The gist is that when you upgrade your environment then you'll just naturally also update the codebase to match it anyways. Or do you upgrade your jdk1.3 project to jdk1.6 and then just ignore the 20 screens of warnings scrolling down on each build?

You don't. You either just stick with what works (for finished projects) or port it forward (for ongoing projects).

The Python community, being relatively small, seems to dig this aggressive way of making changes to libraries and the interpreter itself. It has many advantages and speaking of disdvantages, most of the ones you specify are really non-issues.

I mean, you're not forced to use the newest version of the interpreter. You're not forced to use the newest version of any library. Moreover, you're not forced to use a single specific version of the interpreter on a machine. And with the use of virtualenv or buildout, you won't complain that your application used to work, and it doesn't, because the environment evolved.

And if you're "scpying directories" between servers, relying on whatever version of the interpreter you find, you're doing it wrong.

I've been using Clojure to "sketch" solutions for a Java project, then translating the results back into Java when I'm happy with it.

This gives me a REPL I can use to type in expressions referencing my existing code base and immediately see the result. Clojure has macros that make typing in many Java expressions require even fewer parens than Java itself! PG came up with the sketching analogy to describe what its like trying things in an interactive environment, immediately seeing the results, then modifying little by little to eventually get the result you want.

When I switch back to Java, on the other hand, I feel like I'm chiseling my code in granite. I need to have all of the boiler plate just so before I can see any results at all, followed by a compile and run or debug cycle. Test driven development makes this a little better, but just a little.

@jimbokun "I've been using Clojure to "sketch" solutions for a Java project," and "When I switch back to Java, on the other hand, I feel like I'm chiseling my code in granite." remind me of this bit from SICP

"Pascal is for building pyramids -- imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms -- imposing, breathtaking, dynamic structures built by squads fitting fluctuating myriads of simpler organisms into place."

It seems that some things never change!

Well, clojure is still a lisp, and java and pascal are still an algol.

What library is it that you're missing in Haskell but have in Java? What libraries do you feel are unstable? Have you actually programmed anything in Haskell?

The Java language in its current form is from 2004. The Haskell language in its current form is from 1998. Both originally appeared in 1990. Lisp is much older.

Which shows a potential danger of using more "stable" languages. Maybe the biggest flaw of Common Lisp is that the standard lacks many features necessary for modern development, like networking, threads, and Unicode. I think that the C++ standard lacks a String class (please correct me if I'm wrong).

So sometimes "stable" can degenerate into "frozen solid." Not having new libraries is arguably as bad as not being stable.

I've found that the language (new or old) doesn't matter as much as the experience and depth of the user when it comes to well designed maintainable code. Learning times may vary, but these users try to do things well in any language.

I am not sure you will be that much less productive if you go from Java to Scala. You know most of the libraries, and so code completion is less of an issue and Scala removes many of the problems that are in Java.

> Esoteric languages are a lot of fun.

No esoteric language was mentioned in TFA.

> But they're not very productive

Esoteric languages aren't "not very productive", they're the most counter-productive langages on the planet. Productivity runs counter to the point of an esoteric language.

> Messing around with unstable languages is a lot of fun. It's educational too. But don't build your business around it. Python/Django and Ruby/Rails are only barely stable enough to work with. Thinking that using Haskell, Clean, IO or Lisp will be a net benefit to productivity is foolish.

Wow. Cocaine is one hell of a drug.

Now I don't agree with his points exactly either. But you and I know full well what he meant when he said "Esoteric Languages". Arguing with people by intentionally misinterpreting their statements just makes you look stupid and it lowers the tone of the whole discussion.

> Arguing with people by intentionally misinterpreting their statements just makes you look stupid and it lowers the tone of the whole discussion.

Yes, because purposefully using terms which don't apply to the subject just to insult other people or degrade languages you don't like clearly doesn't.

I never thought the word esoteric would raise any eyebrows. I have no idea how it can be interpreted as an insult. It's meant as the opposite of mainstream; languages you won't find at IBM. I hope you don't work there, otherwise you might feel insulted again!

> I have no idea how it can be interpreted as an insult.

http://esolangs.org/wiki/Esoteric_programming_language

> It's meant as the opposite of mainstream; languages you won't find at IBM.

Then what you're looking for is "non-mainstream". Or maybe "suit-incompatible". And FWIW IBM has a lot of Python stuff in their developerworks site and newsletter. And given Erlang comes from Ericsson, not exactly a small company, it's hardly "suit-incompatible".

Ah, I see. That definition doesn't fit the situation though. I was using the dictionary definition, and the original article used the word esoteric in the same context as I did.