4 ms·
Esoteric languages are a lot of fun. But they're not very productive, exactly for the reasons mentioned: lousy IDE support, buggy compilers, few libraries, few
by gizmo 17y ago
Esoteric languages are a lot of fun. But they're not very productive, exactly for the reasons mentioned: lousy IDE support, buggy compilers, few libraries, few bindings to existing libraries, and so on. When you work in a stable language, you can assume that when something goes wrong -you- messed up. In a new and cool language you don't have that luxury.
You'll be less productive, but you'll have more fun when you get to program in language. A good trade off? I don't think so. A few years down the road you'll have to maintain the same project. The honeymoon period is over, and the code base isn't quite as good as you'd like it to be (you designed the project back when you didn't know the language very well, and it shows). You know you could spend a few weeks refactoring, but that would probably introduce bugs and you'll drive the other people in your team crazy if you start renaming methods, and move stuff around just to make the code "nicer". And besides, you'd much rather be programming in the next-nifty-language, because it lets you extend the syntax at runtime and it has a debugger that will let you go back in time.
The bottom line is that when you pick a language that is on the cutting edge of cool right now will no longer be cool a few years from now, but it still won't have any libraries and other essentials. Languages too have to cross the chasm, and they all have to go through a period where they're neither new and exciting nor stable.
If you're serious about software, concentrate on writing something that is reliable as hell and easy to maintain and install. Want a challenge? Write your app in such a way that power can be lost at any point in time without losing any user data. Or (for desktop apps) make sure that the UI -never- hangs, even when the hard drive has to spin up. Software is never done, there are always things you can make better, more fault tolerant, faster. It's not as if we've run out of challenges.
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.
(Of course there are obvious exceptions, and that Clojure and Scala use the JVM does make the whole library thing less of an issue. But it's still a big deal.)
- shabda 17y ago> 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.
- gizmo 17y agoIf 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.
- shabda 17y ago> 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 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.
- gaius 17y agoI'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...
- gizmo 17y agoIf you were a .NET guy, would you consider building your startup on F#?
- gaius 17y agoWhy not? It's shipping with VS 2010.
- masklinn 17y ago> 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.
- jimbokun 17y agoI think you have a fairly high bar for esoteric :).
- masklinn 17y agoNo. 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.
- masklinn 17y ago> 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.
- almost 17y agoNow 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.
- masklinn 17y ago> 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.
- gizmo 17y agoI 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!
- masklinn 17y ago> I have no idea how it can be interpreted as an insult. http://esolangs.org/wiki/Esoteric_programming_language 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".
- tomjen2 17y agoI 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.
- plinkplonk 17y ago" 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. ;-)
- gizmo 17y agoGo 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.
- allending 17y agoI'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.
- anonanon 17y agoWhat 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.
- jimbokun 17y agoWhich 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.
- jimbokun 17y agoI'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.
- plinkplonk 17y ago@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!
- cema 17y agoWell, clojure is still a lisp, and java and pascal are still an algol.