Live data from Hacker News

Scala – 1 Star – Would Not Program Again

overwatering.org

201–210 of 324 posts

Re: Scala – 1 Star – Would Not Program Again

#201

Earlier quoted context omitted.

Kotlin hasn't even been released yet, and it looks just like Scala.

It 'looks just like Scala'? It is not even a functional programming language. Let alone that it supports implicits, general operator overloading (operator overloading is very limited in Kotlin), existential types, etc. In fact Kotlin looks mostly like Java with some additions to make everyone's lives easier (closures, extension methods, data classes).

Kotlin is certainly in the "Java philosophy" camp (alongside Go, Dart), and yet achieves most if not all of Scala's original goals (though, unlike Scala, it is not a superset of Haskell, Lisp, Javascript and Java, so if you want to write Lisp, Haskell and Javascript, and insist on having all three compiled by the same compiler, you should stick with Scala :)). I have high hopes for Kotlin, and can certainly see my future projects being written in a combination of Kotlin and Clojure.

Re: Scala – 1 Star – Would Not Program Again

#202
post #140

Earlier quoted context omitted.

> Scala is on my "will not work with" list of languages/technologies Just curious, what are the some languages/platforms you like or enjoy using? (Mine are Python, Erlang and Go for ex).

Hobby wise: Haskell, Rust, Nimrod, Haxe Shipping code: Go, Erlang, C++11 (avoiding legacy), F# (with Xamarin) I program in many more, but those are probably my top 8 right now.

You never work with scripting languages? (i.e., why is there no Python, Ruby or Javascript in your lists? or maybe I do'nt know Haxe, does that replace them?)

Re: Scala – 1 Star – Would Not Program Again

#203
post #174

Earlier quoted context omitted.

Wait. Scala has unicode operators ? Wow.

Scala doesn't make a distinction between operators and methods, and Java has always supported unicode in method names, so they have to be possible for compatibility if nothing else. I think if used carefully, with discipline, they can make code more readable and ultimately more maintainable - e.g. for doing set algebra it's nice to be able to have ∪ and ∩ methods. But yes, if you want to shoot yourself in the foot wi…

I showed an example of using Unicode operators in a presentation I gave to the Atlanta group back in 2010. It doesn't say it in the slide, but when I gave the talk, I explained that while it sounds like a neat idea, you should probably avoid doing this. You can see the slide here, where I used a Delta as an operator slideshare.net/slideshow/embed_code/2923973?startSlide=9

Re: Scala – 1 Star – Would Not Program Again

#204
post #133

Earlier quoted context omitted.

> The only real outlier being Javascript which gets its popularity from being the only option for the browser. This is probably the reason for Javascript's popularity, but if you ignore some bad language design, Javascript is a very simple language with a very small number of concepts that you need to understand to start getting work done in it. Even Python (which I think is the simplest of the widely used dynamic la…

>> This is probably the reason for Javascript's popularity, but if you ignore some bad language design, Javascript is a very simple language with a very small number of concepts that you need to understand to start getting work done in it I hear this a lot. JavaScript is great unless you [insert example why JavaScript isn't great]. You could easily turn that statement around: JavaScript sucks, unless you don't [inser…

>>It's an empty statement that could apply to almost any development language no matter how objectively 'good' or 'bad' it is.

No, it isn't really contentless.

All really complex systems will have ... well, less than perfect parts. That goes for programming languages in (at least) a subset of their use cases.

You can either live in denial of "cruft" when choosing programming language or accept that you need to enforce a standard of best practices in your group.

Then you evaluate languages with how they works if the best practices are followed. JavaScript's "good parts" -- and bad -- are well documented and discussed, most everyone knows about this subject.

The overhead of designing/teaching and following those "best practices" needs to be factored into the equation too, of course. It might e.g. be too much of a pain for the std library of PHP (example chosen because I don't know PHP enough to have an opinion.)

Re: Scala – 1 Star – Would Not Program Again

#205
post #201

Earlier quoted context omitted.

It 'looks just like Scala'? It is not even a functional programming language. Let alone that it supports implicits, general operator overloading (operator overloading is very limited in Kotlin), existential types, etc. In fact Kotlin looks mostly like Java with some additions to make everyone's lives easier (closures, extension methods, data classes).

Kotlin is certainly in the "Java philosophy" camp (alongside Go, Dart), and yet achieves most if not all of Scala's original goals (though, unlike Scala, it is not a superset of Haskell, Lisp, Javascript and Java, so if you want to write Lisp, Haskell and Javascript, and insist on having all three compiled by the same compiler, you should stick with Scala :)). I have high hopes for Kotlin, and can certainly see my fu…

A superset of ... what the? Why do you keep trotting out this garbage thread after thread?

Every language takes influences from others, if that's what you meant. Scala is influenced by Java, C# and Haskell, in that order. Kotlin is influenced by Scala and Java, etc.

The "superset" and "Lisp, Haskell and Javascript in the same compiler" comments are unhinged from the reality of any language I recognise.

Re: Scala – 1 Star – Would Not Program Again

#206
"My theory is that it was designed to experiment with advanced type and language features first, and only secondly became a language intended to be widely used." - I have same feeling about F# sometimes - OCAML is cool but too academic to be approachable.

Re: Scala – 1 Star – Would Not Program Again

#207

Problem: author is pining for Go, and doesn't know it. Solution: author should abandon the JVM ecosystem and use Go. - Fast compiles. - Ultra simple, non extensible syntax, yet not verbose in practise. - The code you see is 100% of the code. - A culture of implementing the simple algorithm. - Stable, with version compatibility guarantees. - Nobody is trying to make the types jump through hoops, so the type inference…

You forgot to mention go-routines. I don't think I could survive another day without hearing about how amazing they are and will completely reinvent concurrency as we know it.

Re: Scala – 1 Star – Would Not Program Again

#208
post #202

Earlier quoted context omitted.

Hobby wise: Haskell, Rust, Nimrod, Haxe Shipping code: Go, Erlang, C++11 (avoiding legacy), F# (with Xamarin) I program in many more, but those are probably my top 8 right now.

You never work with scripting languages? (i.e., why is there no Python, Ruby or Javascript in your lists? or maybe I do'nt know Haxe, does that replace them?)

Both Haskell and F# have good REPLs and are adequate for writing "scripts", maybe he prefers statically typed languages?

Re: Scala – 1 Star – Would Not Program Again

#209
post #28

What is my biggest gripe theoretical gripe about Scala is that Trait order is important! Because traits can override common function. A class that is e.g. Ball with traits Shiny and Red is NOT the same as e.g. Ball with traits Red and Shiny. Why? Why complicate testing to a point where you need not only test traits for correct behavior, and not just composing of Traits, but even the order in which they are composed?…

As long as your traits are independent, the order does not matter. Anyway, how do you imagine this could be done better? For order to not matter, the linearization could not be possible and we'd end up with something much more complex and ugly like multiple inheritance in C++ with all the diamond inheritance problems, etc.

Don't have an answer right this minute, but I think eschewing/forbidding variables in trait would prevent the most obvious such collisions.

If you can't override variables, you can't silently change the structure to depend on trait order. You'd have to explicitly state order.

PS. Of course if you have several same signature methods that call super, which is generated depending on order, same problem persist. So, forbidding variables and calling super elements should deal with most "magical" interactions.

Re: Scala – 1 Star – Would Not Program Again

#210

Problem: author is pining for Go, and doesn't know it. Solution: author should abandon the JVM ecosystem and use Go. - Fast compiles. - Ultra simple, non extensible syntax, yet not verbose in practise. - The code you see is 100% of the code. - A culture of implementing the simple algorithm. - Stable, with version compatibility guarantees. - Nobody is trying to make the types jump through hoops, so the type inference…

I tried Go for the same reasons. It looked to me like a statically typed Java, but in practice it was not the best experience. The Code is not more expressive than Java, but you lose all the good libs and tools from Java. Most annoying was the in ability to create concise mocks, because you cannot implement interfaces at runtime with Go.

I wanted to say: "it looked to me like a statically typed Python"
Post reply on HN