Language War - Scala versus Python(blog.zlemma.com) |
Language War - Scala versus Python(blog.zlemma.com) |
However, its advantages are really not the important part. Rather, I just wish you wouldn't dismiss it immediately as a crazy choice. It's no more crazy than any other less-popular language. It has a reputation for being impractical, but this reputation is rather unfair especially in the light of recent very practical developments like simpler concurrency, an improved IO manager, very good web frameworks and a fair about of strong libraries both for very specific domains and general productivity.
The main disadvantage is that many people find it hard to learn. However, this is a function (heh) of functional programming rather than the language itself. It's actually a simpler language than Scala in many ways because it tries to do one thing well--for example, it has no sub-typing, so you do not have to ever worry about covariance and contravariance.
Now, my point here is not that you should always use Haskell, just that you should seriously consider it. Too many people dismiss it out of hand almost as a joke when it is anything but.
I think these effects cancel out Haskell's relative lack of popularity unless you expect to be hiring at the enterprise Java level--something like literally thousands of developers.
Anyhow, keeping an open mind is the most important thing, and you clearly have no problems there. I just wish others would follow suit in that regard.
You might also consider a Haskell core, surrounded by a Python website. (Or any other website language/framework you like.) It strikes me as likely you have some sort of relatively small interface you can define between those two things, and then you can use the strengths of everything.
That said, It's a better choice than Scala for math. However, if the math is numerical algorithms, Python is better than either Haskell or Scala.
I'm not sure why they need to settle on one language. Seems like painting the bike shed. For better or worse, every sufficiently large web system has a number of languages being used behind the scenes.
I certainly do not think that syntax is anywhere near why some people find Haskell hard to pick up. Thanks to pattern matching, the syntax is very visual and thanks to having relatively few forms and keywords, it's much simpler than most imperative languages'.
Also, I'm not suggesting necessarily using Haskell exclusively, by any means; I just want more people to consider it at all!
I like Python for prototyping, algorithm validation, and just to hack on. I like Scala for damned near everything else. (Also, Adam is going to be open sourcing what is essentially a Scala clone of Pandas but statically typed and with comparable performance.)
Surely other considerations are more important, such as,
- encapsulation/domain partitioning
- messaging
- libraries and library maturity
- native code interoperability (likely critical for this application)
- concurrency
- performance
- JVM platform
- etc.
Maybe, as a result of this type of analysis, Python-like language is more suitable in some domains and a JVM language in others.
In my opinion, for the requirements quoted, with a deep and performant mathematical framework involved, I cannot envisage how Scala/JVM could win any "war" for the core of the business.
It looks more like an emotional kind of story than one about practical decisions.
I appreciate your pointers - as the business grows and takes shape, a fresh evaluation will be required where some of the considerations you mention will be taken into account.
Foursquare also uses Scala, as does LinkedIn. Here's a page of organizations using it:
For instance, I know compilation performance was always frustrating for developers. What's it like for teams of people dealing with a large code base?
https://github.com/twitter/commons
which has some similarities to Google's Blaze build tool.
-Ashwin
Scala vs Python: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
Also since he mentioned Haskell at first, Haskell vs Scala: is also interesting: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
Haskell vs Python is just for lolz: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
The best benchmark is always your application. All benchmarks are flawed, use your judgement and determine how flawed a benchmark is; Any flaws are relative to your application similarity to what the benchmark tests. An imperfect tool is not a useless tool, so long as you are smart about how you use it.
This is probably relevant too: http://benchmarksgame.alioth.debian.org/dont-jump-to-conclus...
That's not true, and you already know that's not true.
http://news.ycombinator.com/item?id=4599431
Please stop making this pathetic accusation.
"practicality beats purity."
I have no idea which and how many startups use Clojure, besides Datomic :) It would be interesting to know.
Unfortunately I can't share any personal experience as the core of my work is in the Enterprise so I haven't had the right opportunity to present itself. But if you're coming from a mathematical background you should check it out
People actually use it? It seems abandoned and the link to homepage broken: https://pypi.python.org/pypi/typecheck. I'm asking because I'd really like the idea of starting a project the dynamic typing way and then bolting on a (semi)-static type system on top once more new programmers join the game, preferably being able to completely disable it on production machines for best performance.
[1]: http://cython.org/
Funny. I feel exactly the opposite. Static typing is false security.
I program in JS. My coworkers in Java. They have so many bugs that make it to prod because they assume that just because it compiles it must therefore be safe.
Haskell and Scala have static typing instead (and therefore need much less unit tests).
In the former languages, you can encode many more attributes of a program into the type system, and so you can have check at compile-time many more invariants of your program - e.g. enforcing a function does no I/O, enforcing that all possibilities are handled when pattern matching, enforcing the equivalent of nullptr checking, etc.
In languages like C++, there are techniques you can apply to allow the type system to help you out a bit (see this talk by Jordan DeLong for some examples [1]), but in general, the guarantees you get from a non-HM type system are weaker than those from one, and so the notion of successfully passing type-checking is correspondingly weaker.
Good type systems can catch far more bugs than you imagine. Moreover, they can actually make writing code easier: there are some extremely valuable and expressive features like typeclasses that simply cannot be reproduced in a dynamically typed language.
The problem is not how to make something compile, regardless of how complex the types are. The problem is how to do the right thing. It is not enough to return a string - you must return the correct string, and that is not normally not something a type can solve for you. I suppose you may solve that problem too in haskell, but then you will get bugs in the type definition instead. TANSTAAFL.
I use Ruby and JavaScript professionally. I do like Ruby for a number of reasons, and JavaScript I can at least live with. But in both languages, I constantly find myself spending tons of time tracking down bugs that would have been discovered right away if I had Haskell's type system at my disposal.
Attributing your coworkers' "if it builds, it works" assumptions to static typing strikes me as incorrect. Static typing, at least in Java, ensures only a (relatively) small set of conditions are true; I don't think you can really blame that for increased/additional assumptions on the part of sub-par programmers.
I've found that debugging in a dynamic environment is great for managing types in a well architected system. It falls down in a poorly architected one, in ways that static typing would not ave allowed. However, in such systems, "it compiles so it must be correct," programmers just get stuck in deeper snow.
"These are not the only compilers and interpreters. These are not the only programs that could be written. These are not the only tasks that could be solved. These are just 10 tiny examples."
I'm even becoming more and more fond of C++ because of the constraints that you can work in with proper use of templates; my only beef there is that the error messages when you do the Wrong Thing are often not conducive to understanding what the Right Thing is.
It can, however, ensure that you have returned a legally-formatted email address instead of someone's first name, with proper use of the type system. You'd probably be surprised what you can do with a real type system, based on what you're saying here. It is not a proof of correctness, but there's a great deal more possible than in Java.
It of course can not ensure you returned the correct email address, but often that's a much less pressing problem, because the thing returning the address may very well have had only one address in hand to chose from, in which case it can't be wrong. There's a lot of logic like that you can deploy in Haskell, when scopes and inputs to functions are much more carefully controlled than a traditional language.
The key point is that a sufficiently expressive type system gets you far closer to correctness on the basis of type checking alone than does a weaker static system like Java's or a dynamic one like JS's. You should still write tests, you just won't have to write as many in order to reach the same degree of confidence in your code.
Post hoc ergo propter hoc is a well known fallacy.
Lest anyone forget that your repeated complaints don't withstand scrutiny -- http://news.ycombinator.com/item?id=4598737