A farewell note to a programming language

http://matthiasnehlsen.com/blog/2014/12/04/Farewell-Scala/

by fogus • 12 years ago

104 78 12 years ago

speedkills• 12 years ago

I found your experience closely mirrors mine with scala. At my current shop we write mostly ruby and scala. The ruby code between developers looks much more uniform than the scala code I believe due to the fact that while trying to please everyone scala hasn't yet developed much of "the scala way". I do hope this changes as I really enjoy scala. Currently my team is experimenting with style/punting tools like stylecop to try to bring a little consistency to our code. Too early to say how it will work out but I would love to hear from others how you try to bring a team style to a code base that will happily let a fully functional developer, a fully object oriented developer, a straight imperative developer, and someone who believes in mixing these things all work side by side. Mentally by giving up the possibility of nothing you have to learn everything which means loading a lot of the scala compiler up into your brain before even trying to read a bit of anyone else's code.

lostcolony7• 12 years ago

Mixing an imperative developer with a functional developer? That's asking for trouble. You'll have to be converting between mutable and immutable data structures anywhere the two interact. Or forcing the imperative developer to be largely functional due to the immutable data structures everywhere that prevent him from using imperative approaches. Or forcing the functional developer to write in a largely imperative style due to the mutable data structures that prevent copying from being efficient, and can be mutated any time they pass out of his/her code.

Or to put it another way; Scala as an idea may be fine; you can mix imperative and functional together, by picking which data structure and approach for a given problem is 'right'. But in a team environment? Touching someone else's code in a particular paradigm means you have to be familiar with, and expect, that paradigm. You can come up with a team that agrees on what paradigm everything must be written in (and that can be anywhere on the continuum), but you can't mix and match and expect developers to not have to learn every paradigm in use.

lmm• 12 years ago

Not "everything"; each codebase needs a particular style sure, but the great advantage of Scala is that your skanky 5-minute scripts and your carefully engineered five 9s backends can each be written in an appropriate style, and share the same libraries where that makes sense.

tel4• 12 years ago

The ST monad would like a work with you :)

tel4• 12 years ago

If you like Scala but find it too scattered then there's always Haskell* :)

(*) Not that there aren't a thousand reasons to not choose Haskell. This is merely obligatory temptation dangling.

dyeje• 12 years ago

Took me a minute to parse that triple negative.

tel4• 12 years ago

Yeah, I don't blame you. English is the worst.

    let P = 
      let S = { s ∈ Reasons | s : ¬ Choose Haskell } in (S, |S| > 1000)
    in ¬(¬∃ P)

bunderbunder• 12 years ago

Or F#, which is perhaps a more comfortable alternative for people who would otherwise be considering Scala.

Incidentally, I've finally started to sink my teeth into Scala with a larger project. So far my impression has been "Very nearly as good a language for functional programming as C#." It's got ML-ish syntax, but the Java-y OOisms are just way too front-and-center for comfort. Case classes and extractor patterns, I'm looking at you.

sixbrx2• 12 years ago

Isn't subtyping OO the principal way to do polymorphism in F#? I ask because the last time I looked, it didn't do type classes, nor ML modules, but maybe that's changed. Scala has a pretty powerful notion of type classes and this is a big part of what gives it a functional feel to me.

slm_HN• 12 years ago

It's official. Haskell has become the Beowulf cluster of Hacker News.

codygman• 12 years ago

Beowulf cluster?

waps2• 12 years ago

A programmer complains that different programmers have different styles of programming in Scala ...

and ... switches to a lisp. You know, languages that execute code by rewriting the syntax tree of the running program ...

This ought to be good.

This is not meant to be disparaging against LISPs. I'm just alluding to the fact that while there are 5-10 ways to do the same thing in Scala, all looking very different, working subtly different, there's 5000 different ways to do the same thing in LISPs.

lostcolony7• 12 years ago

Every list of best practices, for every LISP, agrees that macro use is generally a "use rarely" thing. And Clojure seems to have developed idioms around simplicity.

Scala, on the other hand, has wildly diverging sets of best practices. The feature set is huge, attempting to appeal to pure functional programmers in their academic ivory towers, and the grizzled Java developers who believe OOP is the one true way, and everyone in between.

It's easy to -say- that there are 5000 ways to do the same thing in a LISP, and only 5-10 ways to do the same thing in Scala (both statements being hyperbolic, presumably; there are infinitely many ways of doing each, after all), the meaningful variations you are likely to see in the wild are far, far lower in Clojure than Scala. And will likely be based on different understandings/expressions of the problem, rather than on different language subsets that the author prefers.

pekk2• 12 years ago

If macros are agreed by all Lisp users to be a "use rarely" thing, then why is internet Lisp advocacy so strongly focused on macros as an advantage of Lisp over the rest of the world?

lispm3• 12 years ago

Every list of best practices, for every LISP, agrees that macro use is generally a "use rarely" thing.

Not really. This best practice is for beginners and mid-level programmers. They either write macros for the wrong purpose or in problematic ways. Thus they should avoid macros. Still they need to use macros, since languages like Common Lisp provide a lot of functionality through macros.

To get past that stage a book like 'On Lisp' by Paul Graham helps.

Many, but not all, advanced programmers will use and write a lot of macros.

imanaccount247• 12 years ago

attempting to appeal to pure functional programmers in their academic ivory towers

That's not where we live.

one-more-minute• 12 years ago

This may not be true for all Lisps, but the Clojure community has developed a very specific idea of what's idiomatic in the language and what isn't. The right way to do something is always the simplest, and there's almost always a single, obvious, simple approach to the problem. IMO, YMMV etc. of course.

nickik7• 12 years ago

I would suggest to you that Clojure has a very clear "the Clojure Way" I would say, more so then almost any other language. It goes beyond syntax to a pretty deep design level. Its not even all that unique to clojure, you could do 'the clojure way' in other languages, but they usally dont.

Some of the importent keynotes from some of the early conjs are really importent, and they really went deep in the community, you can see it in almost every major library.

Another commenter has mentioned the notion of 'simple' but thats not really all that clear. I not enougth of a writer to tell you about it, but I can give you the resources:

- This classic got Clojure on the map for many people: Are We There Yet? - Rich Hickey www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey

- Simple Made Easy - Rich Hickey - http://www.infoq.com/presentations/Simple-Made-Easy-QCon-Lon...

- Simplicity Ain't Easy - Stuart Halloway - https://www.youtube.com/watch?v=cidchWg74Y4

- Ousterhout's Dichotomy Isn't (Part 2 of the Simplicity/Power/Focus Series) - Stuart Halloway - https://www.youtube.com/watch?v=cidchWg74Y4

- The Language of the System - Rich Hickey https://www.youtube.com/watch?v=ROor6_NGIWU

- Hammock Driven Development - Rich Hickey https://www.youtube.com/watch?v=f84n5oFoZBc

In addition to these, there are many talk that are about people trying to run with these ideas. Datomic is a example of taking these ideas to the max, it really standas as a nice example. You can find others in talks by David Nolan for example, but there are tons of applied talks.

- The Design of Datomic - Rich Hickey http://www.infoq.com/presentations/The-Design-of-Datomic

Sean-Der• 12 years ago

Macros in good code bases are incredibly useful to abstract things away. Usually achieving things that functions can't.

When working in large code bases with languages that don't have macros I find myself seeing people trying to accomplish the same task, but in subtly different ways. These are cases where a helper function usually would not reduce the LOC or complexity.

As with everything, macros can be bad, but I wouldn't be so quick to ban them outright.

Morgawr• 12 years ago

The main difference is that no matter how much you re-write the syntax tree, you'll still be parsing S-Expressions, and those are as unambiguous as it gets.

Keep a language simple, that's how I like it at least. It's not about how many ways are there to write X, it's more about how many times can I write the same X and have it do different things? (aka ambiguity)

The answer in Lisp is exactly one: S-Exp, obviously there are exceptions like delayed evaluation, re-binding of symbols (not really recommended, at least in Clojure) and argument parsing in macros, but those are exactly that, exceptions. Take operator overloading in many programming languages or method overriding as a comparison, way too much ambiguity.

waps2• 12 years ago

In LISP, I would argue that the syntax is defined only partially by the concept of S-Expressions, but by the number of different kinds of atoms that can occur as the first atom in a free S-Expression. Well, all functions only define a single syntax form, but all macros define a new syntax form that should be counted separately.

Because of how LISP is structured, it is extremely tempting to have dozens of them for any reasonably-sized program.

In practice, in all LISPs, this number of syntax forms is quite high. In clojure it's somewhat less, but still a lot more than in "average" programming languages.

serve_yay• 12 years ago

Well, OK.

swah3• 12 years ago

fogus, what should I read nowadays? BOOKS???

http://blog.fogus.me/2011/03/27/the-long-lost-art-of-thought...

swah3• 12 years ago

Ok found the answer http://michaelrbernste.in/2014/10/21/should-i-read-papers.ht...

emcrazyone• 12 years ago

I think the article is fundamentally flawed from this comment alone:

"In well over a year of working in Scala teams there hasn’t been a single day where I felt that there was a shared mindset about how to develop a system or even approach a problem."

So this guy expects a programming language to create a shared mindset?

I've been developing software for close to 17 years in more languages than you can shake a stick at and none of them do this for you. It's always about picking the right tool for the job and/or team.

A shared mindset comes from other planning type activities like use cases, function/non-functional specifications, and general architecture type planning before you write code. Especially for larger projects.

I think software patterns tend to help drive synergy in a team environment. It's not perfect but my experience has shown me and the folks I work with at least, that adopting patterns helps to bring us together but those patterns are usually fleshed out during architecture planning activities.

cwyers• 12 years ago

I think there's a huge contrast between a language like Perl, where There Is More Than One Way To Do It, and say Python, where "There should be one -- and preferably only one -- obvious way to do it."

RodgerTheGreat• 12 years ago

"The Zen of Python" makes a number of lofty claims like that, but the actual language design doesn't embody them well if at all. To pick an example off the top of my head, there are three syntaxes for string literals (single quote, double quote, triple quote) and three prefixes (raw, binary, unicode) which can be combined in a number of ways. As a result python offers 15 ways(!) to express a string literal.

smutticus• 12 years ago

I took that quote to mean he wanted Scala to be idiomatic. There's much mileage to be had from linguistic idiomaticity.

Like you said, "software patterns tend to help drive synergy." I don't think your opinion and the authors are all that far apart.

pjmlp6• 12 years ago

For me a good way to deal with team code was getting involved into enterprise offshoring.

Either you learn to live with code that works, regardless how it is written, in a world that doesn't care about stuff discussed in HN or better change job.

Trying to bring everyone involved, both onsite and distributed locations to follow best practices, is playing D. Quixote.

kev6168• 12 years ago

No offense to the author, but this reads like a 16 old claiming he finally find the girl who is 'the one' for life. __only two years later__, that Another girl shows up and OMG the new chick definitely is the 'true' one.

To put it another way, under extreme circumstances, Mr. Martin Odesky can use even the $&^%$#$ PHP to write safe and efficient airplane flying control software.

The point is the language is hardly matter as much as your kids think. There are far more important things for good software. But language is not only a tool but also a toy and a passion, so I can appreciate the urge to talk about it. :-)

nickik7• 12 years ago

No offense to the author, but this reads like a 16 old claiming he finally find the girl who is 'the one' for his whole life.

I think thats what he was going for.

There are far more important things for good software.

Everybody knows this, but people still like to talk about programming languages.

matthiasn• 12 years ago

Yes, I was experimenting with exactly that style of writing, guess it worked ;)

thekingofspain• 12 years ago

Additionally, I think what's key is to note that he wasn't pumping Clojure too hard in the post. It was more a post about why he's leaving Scala. And in that analogy, you can be pretty certain that the girl you're leaving is definitely not "the one".

covi• 12 years ago

There are three and only three vague points conveyed in the article: (1) Scala has "immense" syntax, (2) Scala tries to support too many paradigms, and (3) the Iteratee library is hard to grasp.

For (1): I disagree -- Scala's syntax is relatively easy to grasp. Perhaps the author meant constructs.

For (2): people keep saying this but why not just stick with the way you are comfortable with?

For (3): I don't see how this is a language issue; at the very least it shows that the author is unable to grasp a particular functional programming abstraction.

jbergens2• 12 years ago

(1) I think you can safely assume that he means constructs. If he has spent years writing Scala he has surely grasped the syntax. (2) A team may have many people with different feelings about what they are comfortable with. This raises problems in an enterprise environment. (3) I can only guess that he feels the library is so hard that many developers with struggle with it.

I think Go is an interesting language partly because they seem to keep it simple by choice.

swah3• 12 years ago

His Clojure implementation is here: https://github.com/matthiasn/BirdWatch/tree/master/Clojure-W...

noelwelsh3• 12 years ago

On Monday I'm giving a talk at Scala Exchange on my take on idiomatic Scala. For those of you who can't make it, I'll give a quick rundown. You basically need four patterns:

- algebraic data types

- structural recursion

- fold, map, and flatMap

- type classes

That, in my experience, will cover the majority of code you need to write in Scala and give a solid basis for a robust and comprehendible code base.

It's unfortunate that in Scala algebraic data types and type classes require a bit more code than in most other functional languages.

E.g.

   sealed trait Foo
   final case class Bar(...) extends Foo
   final case class Baz(...) extends Foo

vs something like

   data Foo = Bar ... | Baz ...

for an algebraic data type, but it's really not so onerous to type.

These patterns are really truly shockingly simple to use. We teach them in introductory courses and the majority of people get them.

It's true that Scala has some warts, but as software engineers we ought to make decisions based not on our personal biases but on a consideration of the problem domain and tradeoffs involved. If you want 1) static typing, 2) a modern language, and 3) JVM compatibility then Scala is the best choice at the moment IMO. Remove one of those restrictions and other choices come into the picture.

Update: If you're interested in learning more about these patterns, on Friday we're going to send a free excerpt of our "Essential Scala" book to our mailing list. The excerpt will include material on algebraic data types and structural recursion. You can sign up here: http://underscore.io/newsletter.html

lomnakkus6• 12 years ago

I think you just described Haskell in your four bullet points (which I'm sure you know, or at least know of.) Of course it comes with the baggage of pervasive laziness, so there's that potential objection...

It can't run on the JVM, but to be honest, I've never actually observed in practice what's so great about the JVM (if you're running functional code). Everyone I hear claims that the JVM is great (left & right), but I just don't see it. Maybe I'm just ignorant.

pjmlp6• 12 years ago

The JVM ecosytem is great, because of tools like this:

http://visualvm.java.net/

http://www.oracle.com/technetwork/java/javaseproducts/missio...

https://www.jetbrains.com/idea/

https://wiki.openjdk.java.net/display/Graal/Main

http://www.oracle.com/technetwork/java/javase/downloads/java...

All in one package.

Plus since JVM is actually a specification, there are JVMs for almost all CPUs and OS that matter, from embedded platforms all the way to the data center.

noelwelsh3• 12 years ago

The true benefit of the JVM is the ecosystem. There is a load of ancillary stuff like database drivers and web frameworks, to more exotic stuff like rendering PDFs, that every application needs. It doesn't add value to work on this stuff yourself but you can just about guarantee there will be on the library on the JVM that does what you want. It might not be pretty but it will exist somewhere.

This is particularly the case in the big data space, where all the major frameworks are run on the JVM.

For many people, interfacing with legacy Java code is also important.

And yes, I advocate using Scala much like Haskell.

(There is also the performance of the JVM, which is pretty good, but this is only a point worth mentioning when comparing to languages like Ruby and Python. Most functional languages have good compilers and runtimes.)

saosebastiao• 12 years ago

Interesting. I've followed Matthias' project as I've tried learning the Play framework as well as front end development, and it has been incredibly useful. Incidentally, I learned Scala after I knew Clojure reasonably well, and I feel like I could apply the same arguments in the reverse direction.

When it comes to the back end, I'll likely choose Scala 100% of the time. I really believe there is no substitute for a strongly typed ML-derivative for that type of environment. Additionally, there are a strong set of robust scala libraries (Typesafe mostly) that are completely production ready, and java interop is much more natural when you need it.

For the front end, I'm currently using Javascript, but I have toyed with the idea of both Scala.js and Clojurescript. This is where Clojure really makes me mad. I feel as though the dynamically typed Clojurescript should be a better fit as a compile-to-javascript language, but in every instance I've tried, Scala.js just works better. It compiles correctly, error messages make sense, much better documented, and there are fewer deviations from the core language. And the clojurescript libraries are mostly terrible in this regard...even the super-hyped ones like Om. My biggest pet peeve are the tutorials that force you to learn unrelated things (like Datomic, Emacs, Ring, etc) to be able to walk through them. I really feel like Clojurescript had a chance to shine here, but I find it far less inspiring than the relatively immature Scala.js. Oh well.

A farewell note to a programming language

Related Stories