6 ms·

I don't get it. Scala has all the features, it's fast AND it's easier to read (no matter how much the presentation tries to play down the () issue, it's there.)

• mullr 13y ago
  Clojure is dynamically typed, homoiconic, and places a lot of emphasis on immutability and managing state. Scala has different design goals. Idiomatic Clojure code is quite different, structurally, from idiomatic Scala. You should try it, and believe it when everyone says that the parentheses fade after about a week.
  • eklavya 13y ago
    Well I just might, for now Scala seems to be doing a pretty good job though :P Is learning clojure enough if I would like to write lisp in future?
    • josteink 13y ago
      > Is learning clojure enough if I would like to write lisp in future? Since clojure is lisp (although not common lisp or any other non-clojure variation like Scheme), I would have to answer yes.
• krat0sprakhar 13y ago
  Can't agree with this more. All the plus pointed touts for FP are available in Scala without the necessary mental context-switch that is required to grok the parenthesis extravaganza. Why Clojure instead of Scala?
  • s_kilk 13y ago
    Well, first of all Clojure is a substantially simpler language than Scala, which counts for something. Secondly, I believe that Clojure does a better job of presenting the developer with a new way of thinking about problems, which (as alluded to further up the thread) can be a big source of productivity gain and inspiration.
    • jroseattle 13y ago
      Not really. There may be some larger idioms and concepts that are more expressive than scala, but simpler language? A case in point: scala if (x > 0) ... clojure if (> x 0) ... The clojure syntax here is a bit absurd, IMHO.
      • dagw 13y ago
        It's only absurd since we're so used to assuming that (some) math functions are special and deserve special notation. The notation for almost every other function you're going to use is f(x,0), why should the function '>' get a different notation? I agree that it is uncommon and take getting used to, but it does have the advantage of being consistent, and consistency and lack of special cases is a part of simplicity.
        • jroseattle 13y ago
          > why should the function '>' get a different notation? I think that the concept of standards is worthy of consideration. While '>' is an operator in scala and other languages, it's also an operator in basic mathematics. And in basic math, we're taught "if x is greater than zero" using the notation of "if x > 0" (parentheses notwithstanding.) It's only consistent in terms of how clojure presents it, but it's inconsistent with treatment elsewhere. Consistency does go to simplicity, but if it takes some "getting used to", it can't be all that simple.
          • dm3 13y ago
            I think consistency with math doesn't make "if x > 0" simpler than "> x 0". Makes it easier, as it's already ingrained in the memory, yes. For example, how would you express the "between?" in infix notation? In Clojure we can use the same function - "(> 1 x 0)". I do agree that Clojure way takes some getting used to.
            • jroseattle 13y ago
              Yes, agreed. Although, what's the point of simplicity if things aren't any easier?
  • dm3 13y ago
    The 'easier to read' part is valid maybe for the first week of working with a Lisp (commenting as a part of a team which switched from mostly-Java to only-Clojure several months ago). Pros for Clojure: * Faster code -> result cycle. No need for compilation (except for AOT-compiling releases). * Absence of static typing helps in some of the domains, e.g. web applications. We have successfully used Prismatic's Schema[1] in places where a stable data interchange format was needed. * Binary compatibility. No need to recompile libraries for different Clojure versions. * Community oriented towards simplification. People mostly try to mimic Rich Hickey and Clojure.core development approach. * Orientation towards small libraries. I haven't yet had a need to use a framework written in Clojure (although Pedestal[2] seems interesting). [1] https://github.com/Prismatic/schema https://github.com/Prismatic/schema [2] http://pedestal.io/ http://pedestal.io/
    • lmm 13y ago
      How complete is core.typed? Does it have a good story for scala type features I've come to depend on (covariance, some kind of typeclass-like functionality, higher kinds)?
      • dm3 13y ago
        Core.typed appears to have some higher kind and variance support (as seen in the user guide - https://github.com/clojure/core.typed/wiki/User-Guide https://github.com/clojure/core.typed/wiki/User-Guide). Type classes can be mimicked via multimethods or protocols.
• yummyfajitas 13y ago
  There are great reasons to use Scala (specifically Akka, static typing), but syntax is a bullshit reason. A decent programmer can adapt to normal languages like ruby, scala or lisp in about a week of use. Wacky languages like perl or k might take a bit longer. Also, syntactically Scala is a lot more complicated than lisp. It's a bit closer to Java, but that doesn't make it simpler. Just more familiar.
• jamii 13y ago
  I'm just going to copy-and-paste this old comment: When evaluating language tradeoffs the scala community values power more and the clojure community values simplicity more. Scala wants to provide you with the most powerful language possible. Clojure wants to make it easy for you to mold your own language. Scala language tooling works at compile-time and analyses the language statically. Clojure language tooling connects to a running environment and uses introspection. Scala has much better static checking and clojure has much better introspection. While both languages have a repl, the clojure community puts much more emphasis on live, interactive programming. Clojures syntactic extension mechanisms are much simpler, being based on sexps. Scalas are powerful (eg can access the lexical environment) but much more heavy-weight. Clojure has run-time eval. This makes it possible to do eg domain-specific jit (eg compiling DSLs -> clojure code -> java bytecode on the fly). Scala has a run-time interpreter which I haven't used but is reputed to be slow. I haven't yet explored non-jvm backends for scala but I suspect that clojure will eventually dominate on that front for two reasons: 1) when clojure-in-clojure is finished porting clojure to a new platform will be far easier than scala and 2) clojure was designed from the beginning to be a parasitic language and delegates many features to the underlying platform. Scala breaks backwards compatibility much more often than clojure. Whether this is a pro or con is up for debate. There are lots of small niggling things in clojure I would like to change but on the other hand maintaining scala code across compiler updates is a pain in the ass. Personally, I believe that the number one problem a language needs to address is managing complexity. The clojure community largely seems to get that and is driving for simple, orthogonal language features and libraries to an extent that I've not seen in any other community (eg http://blog.getprismatic.com/blog/2012/10/1/prismatics-graph-at-strange-loop.html http://blog.getprismatic.com/blog/2012/10/1/prismatics-graph...). In addition, the most exciting research I've seen on that front (eg http://www.vpri.org/pdf/tr2011004_steps11.pdf http://www.vpri.org/pdf/tr2011004_steps11.pdf http://boom.cs.berkeley.edu/ http://boom.cs.berkeley.edu/ ) and most of my favorite tools rely on powerful introspection and runtime code generation. I think Yegge describes this better than I can - http://steve-yegge.blogspot.co.uk/2007/01/pinocchio-problem.html http://steve-yegge.blogspot.co.uk/2007/01/pinocchio-problem....
• michaelochurch 13y ago
  I got really into Scala a couple of years ago, and then worked on a big Scala project. One of the problems is that if you throw average Java developers into it, and don't give them the time to learn the language properly-- these were smart engineers, it was a lack-of-time problem rather than an ability issue-- you get a lot of Scala-in-Java. The code is just as unreadable, "enterprisey", and unattractive as it would be in Java. I would use Scala for a personal project where I felt I needed compiler-time typing: I was writing something for the ages, or where bugs might be truly intolerable (say, high-frequency trading) but code would remain small. I wouldn't recommend it for a huge project, though. (Then again, I generally wouldn't recommend huge projects.) Scala tends to fall down on large projects, especially if the developers aren't skilled. Cyclical dependencies (yes, I know they shouldn't exist, but they will if you have a team of 25+ engineers and a wide skill spectrum) defeat incremental compilation, which matters when your compile speed is ~500LoC/second (Scala's compiler is very powerful). Also, SBT is a nightmare. I haven't used Scala's macro system but I can't imagine it being as clean as Clojure's. I like Scala on its terms alone, even if I've seen it go wrong on large codebases. (Java has the same issues, but it has tools that rescue you. It's an ugly hackish thing, to rely on tools to deal with code messes; but they're there.) I like static typing (at least, the theory that comes from it.) However, I tend to think that what most programmers really want when they say they want "static typing" is something more like Prismatic's Schema: runtime checks that can be turned on or off (performance) as needed. I think Clojure's easier to read and to write. It just looks harder, because people exaggerate the parentheses problem, which is not much of one at all. If anything, the only thing that's somewhat hard to explain to newcomers is quoting (e.g. why '(1 2 3) returns (1 2 3) at REPL but (1 2 3) is an error). The quotes were the hardest thing for me to get right when I started in Lisp.
• edoloughlin 13y ago
  no matter how much the presentation tries to play down the () issue, it's there. I'm getting tired of statements like this. I've been using Clojure for a couple of years now. I got over the () "issue" after a couple of weeks, once I discovered Counterclockwise for Eclipse (and, eventually, Emacs paredit or smartparens). You just don't notice them after a short period. In general, editors that "understand" Lisp-like syntax are more powerful than other code editors. Being able to select forms - anything enclosed in a (), {} or [] - with a key combination and move them easily around the hierarchy (also see barfage & slurpage in the paredit cheatsheet: http://www.emacswiki.org/emacs/PareditCheatsheet http://www.emacswiki.org/emacs/PareditCheatsheet) makes editing code faster than other languages. As for the "easy to read" argument, I now find Clojure easier to read than, say, Java because there's generally less of it.
  • dkersten 13y ago
    Agreed. I remember hearing the exact same about significant whitespace in Python. Its just one of those things that, after a little bit of use, simply fades away into the background and stops being an issue. Many people even grow to like significant whitespace in Python and parens in Lisps.
• bgruber 13y ago
  frankly, in the world, people are using scala instead. however, i have to differ with you completely regarding scala being easier to read. as someone who regularly works with scala code i find it incredibly difficult to read in comparison to clojure. Lisp syntax is different from what most people are used to but is very simple; scala looks more like the syntax that people are used to, but is deceptively quite different, and is quite complex.