On: Why we choose Java instead of a polyglot stack

[edem]

On the contrary Scala is baroque, its syntax is not following any known pattern. For example if I want to write a recursive function I have to indicate my return parameter type otherwise not. It doesn't matter whether you come from a C background or a Java background...or any background because of this:

> def addInt( a:Int, b:Int ) : Int = {

> var sum:Int = 0

> sum = a + b

> return sum

> }

You have to relearn how a function looks like in the first place. Return types are at the end, parameter types are after the parameter name separated by a colon.

If you want a language which runs on the JVM Clojure is a way better option. You don't have to learn its syntax since there is hardly anything you can call one. It is binary compatible with itself which is not true with Scala, you can choose whether you want a type system or not since it is optional (look at clojure/core.typed). It is also interoperable with java but it has a much better functional approach to programming compared to Scala since everything is immutable but it is not wasteful because of persistent data structures and for concurrency you have the STM which IMHO is a strict upgrade to the Actor model. Writing DSLs with the powerful macros Clojure has is more usable than any non-lisp language and the result is more expressive.

So to add it all up with Scala you add a lot of complexity and a lot of pitfalls you can fall into while with Clojure you take away complexity while retaining the vast Java ecosystem for interoperability. Don't take my word for it but take a look at Uncle Bob's talk "Clojure is the new C" : http://www.infoq.com/presentations/clojure-c

[scott_s → edem]

Function declaration syntax where the return type is last is very common in functional languages. It's even allowed in C++11, because it allows one to define return types that depend on parameter types. An example taken from http://en.cppreference.com/w/cpp/language/auto,

  template<class T, class U>
  auto add(T t, U u) -> decltype(t + u) // return type is type of operator+(T, U)
  {
    return t + u;
  }

It's quite a sensible approach, and hardly an impediment to understanding. A more valid concern is that Scala introduces a lot more concepts. I don't necessarily agree with it, but I think it's a potential issue, whereas a simple syntax difference that a lot of languages have is not a big deal.

[autoreleasepool → scott_s]

I agree the syntax is sensible. I quite like it in Swift:

    protocol Numeric {
        func +(lhs: Self, rhs: Self) -> Self
    }

    func<T: Numeric>(a: T, b: T) -> T {
        return a + b
    }

[autoreleasepool → autoreleasepool]

Correction: Function name.

    func add<T: Numeric>(a: T, b: T) -> T {
        return a + b
    }

[edem → scott_s]

I see. I was not aware that this kind of syntax was present elsewhere, thanks for pointing it out!

[merb → edem]

> You have to relearn how a function looks like in the first place. Return types are at the end, parameter types are after the parameter name separated by a colon.

baroque syntax?

Like these:

- https://swift.org/getting-started - https://doc.rust-lang.org/book/functions.html - https://golang.org/doc/effective_go.html#functions - https://kotlinlang.org/docs/reference/functions.html

Sorry but you pretty much say clojure is the best, however it has a lisp syntax, which IS baroque and most people aren't use to this. These days if you want to have a functional style. You eiter use Scala or Kotlin. Clojure is too much of a unicorn. People won't learn this. Also people doesn't care how good the language is or what design patterns were used. People use these languages cause they think the language has a actual value for them (as you think about clojure)

[edem → merb]

By baroque I mean it is overly complicated. Clojure syntax or LISP syntax for that matter is everything bot overly complicated.

> People won't learn this.

Say that to Uncle Bob or the guys who maintain ClojureScript, Cursive (JetBrains based Clojure IDE) or Om which is a port of React not to mention Apache Storm which was written in Clojure.

[merb → edem]

Don't get me wrong I still think Clojure has it's place, but saying others are overly complicated when talking about Clojure is somehow awful. Lisp is near dead, without Clojure lisp would only be used to train how to implement parsers, compilers, academic stuff.

Yeah there are a few people who know lisp, you also forgotten about Walmart, which is a lisp user, however the majority of people in functional languages still won't learn Clojure.

But still don't care about, use the tool/language you are familiar with, especially if you could use it in your company. I also see a lot of pressure against scala, and I'm a scala user, but I just don't care.

[placeybordeaux → edem]

There are a lot of reasons to hate on Scala and the order of definitions of types in the functions is not a huge one.

[virtualwhys → edem]

Could just write `def add(a: Int, b: Int) = a + b`.

Not sure what the var/return business is about; have you even used Scala?

[lmm → edem]

Types on the end are very common in many languages, a lot more common (and IMO readable) than lisp-style (+ a b) which you have to learn to use clojure.

An optional type system is almost useless (believe me I spent a lot of time trying to use the checker framework in Java before switching to Scala), because libraries don't have to follow it, and you never know whether the type definitions for a given library are true or not.

Scala is generally immutable by default and has persistent data structures.

STM is great but you can do it fine in Scala. It's just not a language-level feature because it doesn't need to be - Scala is expressive enough that you can write an STM implementation in a library.

Scala's DSL support is great (look at e.g. Spray route definitions) and can usually done in ordinary code without macros, which in turn means you have full IDE and tool support for them. The trouble with lisp DSLs is that your syntax still has to look like lisp - the support for e.g. infix operator syntax is quite limited (you have to use reader macros which are more complicated and harder to work with). But for a lot of business domains the natural language of the domain uses infix operators.