Hacker News Reader

Comment by MetaCosm | Hacker News Reader

Great comment. I agree with nearly everything you said, but where I end up is the polar opposite. I can't stand Scala for all the reasons you mentioned.

The poetry thing is really dead on -- when Larry Wall spoke of Perl -- he said he explicitly wanted you to be able to write poetry with it. This led to the write once, read never reputation of Perl... that Scala is quickly stealing.

Scala is on my "will not work with" list of languages/technologies -- which is generally limited to old languages/tools that I have experience with (like Progress 4GL, Mumps, etc), but don't want to touch. It is a maintainability blackhole and generally horrible (to me) to work with, despite being fairly comfortable with the core (1400 or so hours billed).

View on HN

I've developed and maintained multiple large systems in a team using various languages. I would much rather maintain a system written in Scala than either Java or various scripting languages we've used and the view is shared by the whole team. It's far less verbose than Java and very maintainable compared to other very large systems written in scripting languages.

We simply disagree on this. I would rather use almost anything else except the random DSL wasteland that is Scala. Even Ruby or Python (with the horrible GILs) is preferable.

The groups I worked with made different determinations than your team, but if you guys love it, enjoy. Seriously, if you find a technology your whole team loves, you are KILLING it.

Both companies I worked with have since dropped Scala (after literally hundreds of thousands of dollars spent on the attempts) entirely internally due to maintenance and talent acquisition issues.

I would rather use almost anything else except the random DSL wasteland that is Scala

In my experience very little Scala code uses DSLs. Learning Scala isn't that tricky for anyone who knows Java, which is a pretty big pool.

That was not my experience with Scala. Every library we used had its own DSL and that made the code really hard to read. Maybe things are different now, but I'll bet that was a lot of people's first experience with Scala. It's what turned me off to the language, even though I did like using the standard Scala library quite a bit.

Edit: It was two years ago so other than Lift and some SQL DSL I don't recall which libraries we were using. I do recall wishing I hadn't taken that job.

That's pretty odd. What libraries were you using?

My "favorite" part of Scala was half a dosen DB libraries each re-implementing SQL as a DSL.

C# does that too. It's called LINQ and it's very popular.

Are there a number of slightly different and incomplete variants of LINQ, like there are SQL DSLs in Scala? Because if not, then LINQ is "the right way" of doing this kind of thing. And if I remember correctly, LINQ is also useful outside of the DB domain, for things like filtering arrays and so forth.

I once read an article about how Java programmers can hold a conversation on the topic of upsides and downsides of multiple dependency injection containers while C# programmers only have one available and have nothing to say on this topic. That article concluded that having one "good enough" solution can often be better than having multiple slightly different and incomplete ones, even if each has its own strenghts, and I'd say the same is true when it comes to the C# LINQ vs. Scala SQL DSLs.

C# has various options (see: http://stackoverflow.com/questions/671231/linq-nhibernate-al...)

The Scala equivalent is called Slick, and it's the only SQL DSL that approaching anything near widespread use. I fail to see how incomplete projects on GitHub which happen to be written in Scala are relevent to this discussion.

It's NOT called LINQ in C#.

You are probably referring to "LINQ to SQL" which is different and significantly less popular technology than LINQ.

Or "LINQ to EF" which you can suppose it stable just when working with "MS SQL Server".

Interesting, I'm from Sydney and we are seeing a large increase in Scala developers becoming available. Several large companies have been hiring them by the truck load and the local Scala meetup regularly gets 50-80+ people.

I too suffered a bit from DSL hell, especially some of the more extreme examples like the library "dispatch" where you need a "element lookup table" to figure out which squiggly line to use. But once you have a stable set of dependencies the initial DSL influx subsides and you start to work with a fairly manageable subset of them on a day to day basis.

> Both companies I worked with have since dropped Scala (after literally hundreds of thousands of dollars spent on the attempts)

Hundreds of thousands of dollars is on the order of, what, 1 engineer-year?

There are other JVM languages that are far less verbose than Java, without the complexity of Scala, with better compile times, and better compatibility with plain-old Java. For instance, Kotlin.

Kotlin is not much simpler than Scala. It implements some of the Scala features in actually more complex and IMHO less elegant way,(pattern matching, null safety), copies some 1:1 (declaration site variance) and leaves out some of the most powerful ones (implicits, dependent types). I personally don't buy it. I like languages which offer few, but very general and powerful features / abstractions, than languages that concentrate on directly supporting special cases.

Making a language less simple/more complex, in some cases leads to an easier language.

For example, Lisp has a simple syntax, but most people would consider infix math notation easier, although more complex.

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).

It managed to copy almost every single Scala feature and is not even functional? Impressive.

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.

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.

I think I read that phrase from you before on nyc. I think it's a misleading catchprase.

For me and I think most other Scala devs Scala is a statically typed FP-OO language. So Haskell doesn't do it justice because Haskells insistence on purity makes it impractical for me in getting stuff done. And Java doesn't do it justice because Java is held back by its history. "Superset of" makes it sounds like a weakness and overwrought. In my experience it offers a sweat spot of the best features of static FP and OO.

So what about your mention of Lisp and Javascript? Unless you're deep in some framework you don't need to know about the support for macros and structural typing. I've ignored those two so far because I haven't needed them (yet?). And I haven't felt they were in my way.

So where you say "a superset of Haskell, Lisp, Javascript and Java" I say "the sweet spot of the best features of static FP and OO for the real world. Leveraging the JVM ecosystem".

>So Haskell doesn't do it justice because Haskells insistence on purity makes it impractical for me in getting stuff done

I know this will sound snarky, but I have to ask: have you tried haskell before? I only ever hear that line of reasoning from people who have never used it (and I was once one of them, using that very same reasoning to choose a multi-paradigm language). We bailed on scala for haskell precisely because it is pure and has a better type system.

"Useful for getting stuff done" is a point that Erik Meijer literally has made. F.i. you find him explaining his point of view on side effects and imperative programming here. And how he progressed from "fundamentalist" functional programming to "the real world is imperative & embrace side effects". http://youtu.be/a-RAltgH8tw?t=11m1s

You can't say that Erik Meijer doesn't know Haskell. :-)

The fact that Erik Meijer says that imperative programming is the way to go for the "real world" is deserving of attention, but it doesn't empirically mean "all 'real world' software is better created with the imperative paradigm".

From the sound of it this is his first job in the "real world"? If that's the case, perhaps he just hasn't seen patterns of applying his current functional knowledge in a way thats better than the best practices from the imperative realm.

How do we know after a few years he won't switch (provided he was a fundamentalist functional programmer) back to saying "now that I have a better understanding of 'The real world' I can see patterns applied with the functional paradigm are better than the best practices I've been using from the imperative paradigm."?

I believe this is the reason to keep an ear open for authority figures, but not to take everything they say empirically, especially when it's in contradiction with a position they've held much longer.

Apologies for the rambling, I was just typing out what came to mind.

> The fact that Erik Meijer says that imperative programming is the way to go for the "real world" is deserving of attention, but it doesn't empirically mean "all 'real world' software is better created with the imperative paradigm".

Nor is that even, I think, what I think Meijer favors. Meijir's position, from what I've seen from him in various contexts, seems to be that there are cases in real world software where the most clear expression of intent uses imperative constructs, and its better to use them -- but understand and contain their dangers -- in those cases rather than trying to avoid out of devotion to purity.

> From the sound of it this is his first job in the "real world"?

Well, if you don't count the 13 or so years at Microsoft as being "real world".I don't think he ever was a fundamentalist anything.

> I believe this is the reason to keep an ear open for authority figures, but not to take everything they say empirically

"Empirically"? Are you meaning something like "uncritically"? Because "empirically" doesn't have any meaning that makes sense in this sentence.

>You can't say that Erik Meijer doesn't know Haskell

That's true. But I can say that he is quite happy to tailor his message to his audience, If you listen to what he is saying, he is making the argument for haskell. He is just wording it for the PHP crowd. Haskell does allow side effects, which is entirely the point. But the "unwashed masses" as it were are under the misconception that it does not. So he has to take the "side effects are awesome" sales pitch, and kinda tosses haskell under the bus in the process. Unfortunate, and ironic given that haskell programmers genuinely feel that side effects are awesome, but what can you do?

>though, unlike Scala, it is not a superset of Haskell, Lisp, Javascript and Java

If you think scala is a superset of those, then you either really don't know scala at all, or you have an incredibly low opinion of all the languages you listed.

I was expecting Groovy, which is indeed less verbose than Java, less complex than Scala, and has excellent compatibility with Java. I don't know about compile times.

The main downside of Groovy is: it's not as fast. And of course the programming paradigm is less revolutionary and more pragmatic, though that could also be a big upside.

See my comment below for more downsides...

https://news.ycombinator.com/item?id=6836632

> 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?)

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

And Go compile speed combined with "go run foo.go" makes it feel like a scripting language without a REPL.

But in reality, when I need quick scripting, I mostly use ZSH.

I'm not them, but I have no scripting language in my list either. There is simply no need for one. For small sysadmin scripting, sh is nicer than a scripting language. For anything bigger than ~50 lines, I use haskell.

Fair enough, but sh is a scripting language also :)

Most of the stuff I work on is highly concurrent. GILs are the devil. Almost all the joy and ease you from GIL languages is lost as you try to go concurrent and have to use (in python for example) multiprocess and gevent ... then you start getting caught on the rough edges and poor ideas in those tools... and everything falls apart.

GIL isn't a language feature, it's an implementation feature — in Ruby, at least, this is a significant difference because there a major implementations (Jruby, most notably) without it even though it is a feature of the MRI implementation.

True, but JRuby comes with it own huge bag of rough edges (read: no C extensions for you without a bit PITA). IronPython is in a similar boat.

That said, I do prefer JRuby to Scala.

GIL is all evil. If your are dealing with CPU bound concurrency yes, GIL is there to take the fun away. But if your problem is most about IO concurrency (downloading from multiple sockets for ex) GIL is no problem. I get very nice speedup from Python's threads with a silly web crawler I wrote.

Another option is to use Cython. You can declare a function "nogil", but then you can't call any native Python functions within it. It's good enough for some purposes, but not all.

I think with macros in Haxe you can create similar readability problems which you don't like in scala.

I'm curious as to whether you have shipped or have thought about shipping code in Haskell and why or why not. Rust I'm assuming is too new for that to be an option.

4GL and MUMPS? Sounds like you've spent a bit of time in the dark corners of the healthcare industry. My condolences.

Indeed, DEEP in the east coast systems. But, it was great for me, it was literally name my own price consulting (lawyer rates) with multi-month contracts. I would guess it still is a name your own price market if you have the stomach for it. Travel and horrible tech.

I was in an odd position of having picked up 4GL and MUMPS via odd random ways when I was 19/20 -- so when everyone who used to maintain those systems vanished, I was around to step in and bill like crazy for helping them port OFF those systems onto more modern tech. Every port a MUMPS app to Erlang... I have!

I've been considering picking both up on the off chance I run into legacy systems. Any suggested reading material?

Not really, I was lucky enough to have mentor who literally just let me screw around with them. I had hundreds of real hours programming random stuff on both, as well as fixing real world problems with the safety of someone double checking. So I was very comfortable and I mostly used reference manuals for quick look-ups.

These systems are VERY different that what you are most likely used too, so having face time with them is really important.

> Ever port a MUMPS app to Erlang... I have!

Wow - that sounds like an article I'd read!

I had a brief but fascinating encounter with MUMPS back in the late 80's on some ancient Data General Nova/Eclipse kit. I kinda wish I'd persevered, if only for minting cash for the bank account.

Reply on news.ycombinator.com