HN Theater @HNTheaterMonth

Yeah, some critics about this feeling improvised, but guess what? it IS improvisation.

Remember what hickey says about improvising? (https://www.infoq.com/presentations/Design-Composition-Perfo...)

It is art and years of preparation right there performing real-time.

So that guy criticizing is only auto declaring he is incapable of improvising on this matter.. and it's ok it's only for the best ones after all. It is called a challenge for a reason.

⬐ tosh

slides & transcript: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

> So there's a sense in which improvisation is dynamic composition of prepared materials, of planned material, and that to be a great improviser means to make those smaller plans or have those kinds of prepared abilities or approaches or sensibilities that you can apply when the time comes in a live situation.

⬐ nickik

This is not really one of the real fundamental talks by him. Or at least its not very well remembered by the Clojure community.

I know that I have listened to this talk at least twice but I don't remembered the content much. Compared to some other talks like 'Are we there yet?', 'Simple Made Easy', 'Spec-ulation' where those seem to be really remembered well and referenced in other talks.

But generally any talk by Rich contains tons of great information that is timeless.

⬐ nextos

As a Lisper, I love Clojure and all Rich Hickey does.

However, Haskell and categories seem to offer quite appealing approaches to compositionality:

http://conal.net/talks/compiling-to-categories.pdf

https://arxiv.org/abs/1803.05316

⬐ nextos

Just to elaborate a bit further, the first link is a talk on the following paper:

http://conal.net/papers/compiling-to-categories/compiling-to...

It's quite interesting to see how things like automatic differentiation get expressed in this framework.

he also had another talk https://www.infoq.com/presentations/Design-Composition-Perfo...

and I would argue there's idea that simplicity of the instrument/tool is not a problem in itself and we shouldn't lose it in pursuit of 'ease'

"Design, Composition and Performance" by Rich Hickey. His view of what improvising means is brilliant.

https://www.infoq.com/presentations/Design-Composition-Perfo...

I don't know if I've ever been "slow", but I've definitely gotten faster over the years. My personal measure of how experienced I've become as a developer is the number of problems that I treat as a hash table lookup (vs those I need to actively debug). Given that, there are a few possible causes for your so-called "slowness".

If you spent 4 years on the same team, it's quite possible that rather than getting 4 years' worth of experience, you got one year of experience 4 times over - by not constantly being exposed to new classes of problems, you haven't actually expanded your ability to solve problems by a significant amount.

Another cause is that you may not put enough thought into the type of work you find yourself doing. There's a fabulous talk by Rich Hickey (http://www.infoq.com/presentations/Design-Composition-Perfor...) where he compares software developers to improvisational jazz artists. The gist is that Coltrane didn't just get up on stage and play music that magically popped into his head: he practiced, and tried stuff out, and then on stage he composed little things that he already knew worked into a single performance. Software is much the same way - by playing with new things in your spare time, reading about different patterns and libraries, and thinking about the types of problems you face day-to-day, you're building up a huge library of small solutions that you'll compose into software at work.

Reading HN every day is a good start. I like to use HN as a source of inspiration and a place to discover things to learn about. Were it not for browsing HN pretty much every day, I wouldn't have discovered most of the things to which I attribute to my growth as an engineer over the past few years. Certainly, I wouldn't have grown much if I didn't actually investigate those things, but it's great to have a constant source of new "known unknowns".

The degree to which you can put any of this advice to use, is of course, entirely dependent on how much time you're willing to devote to getting better at building software. Aside from spending time with my fiancée and son, I don't do much other than what I've described above. As a result, I'm fairly one-dimensional, but I'm more interested in writing great software than being interesting at dinner parties, so it's an acceptable tradeoff for me (the other result being that I'm told I'm pretty damn fast at writing good software).

TL;DR practice, read, practice, read, practice.

⬐ insulanian

> Reading HN every day is a good start.

Just be careful with that. It can really suck the time. I have a problem that I am reading too much and writing/working less since I discovered HN. I am almost seeing it as addiction.

⬐ notduncansmith

It absolutely is. If you're interested in why, I recommend Nir Eyal's (great) book, Hooked: How to Build Habit-Forming Products. Basically, our brain gets addicted to "variable reward systems" (Facebook, slot machines, news websites) because it gets excited when it finds something interesting/entertaining. Not everything is though (this is the key part), so when you finally do find something good your brain gives you a dopamine rush, which addicts you. I won't pretend that I don't struggle with this addiction myself, but I've found having genuinely interesting work really helps - I read HN at work quite rarely at my new job.

Actually, the quote is from Paul Graham, who does happen to know a little about painters, being one himself. Also, he wasn't claiming that Lisp is the "best" brush, only that it is analogous to a brush that will make you a better painter… somehow.

Interestingly, the "other big Lisp advocate" just happens to also advance the idea that programming against constraints is good for the same reason you mention, except that he used examples of famous composers rather than painters since he's a musician himself[1].

[1] http://www.infoq.com/presentations/Design-Composition-Perfor...

As someone who "bashed" Scala numerous times in HN comments, let me explain why, but first, a bit about my background: Nowadays I program mostly in Java and some Clojure; before that, I developed in C and C++ for many years. I like both the OO and the FP approaches, and I am all in favor of incorporating FP concepts into OO languages (Java 8 lambdas) and vice versa (Clojure protocols).

I think that as a research language Scala is very important. It meshes features found in many different languages (OO types, algebraic types, duck-typing, macros) into one compiler, and so teaches us a lot about how these features can interoperate.

But Scala wishes to be a practical language as well. As such, I think it is an exceptionally badly-designed language (which does not, in itself, merits bashing) that masquerades, or claims to be, a well designed one, and herein lies the problem.

As Rich Hickey so eloquently puts it in one of his talks[1], a programming language is like a musical instrument. Every instrument has properties that introduce constraints. A trumpet can only play one note at a time, while a piano has very limited sustain. These constraints do not limit the artistic expression of the instrument – they assist it. An instrument with no constraints is a "choose-a-phone", and as Rich Hickey says, no one wants to play a choose-a-phone. That is not to say that a rich piece of music cannot be composed for a piano-and-trumpet ensemble. In fact, the JVM, which Scala targets, is the perfect language-ensemble tool, as it offers a harmonic interoperation of different languages of different kinds.

Scala is the ultimate choose-a-phone language, with little or no constraints. When it removed the constraints by mixing all these disparate features, it lost most of their underlying justifications. It adopted JavaScript's duck-types but lost the simplicity of the language; it adopted Haskell's algebraic types, but lost the control over side-effects; it adopted Java's OO types, but again, lost their static-type simplicity. But JavaScript uses duck typing because it can keep the language itself dead-simple and easy; Haskell uses those sometimes-hard-to-grasp algebraic types because they offer safety and carefully controlled side-effects; Java has a basic OO type system because it offers some safety while keeping the language relatively simple. Scala takes these features but drops their reasoning; in the process it lost its coherence. So the challenge of programming Scala turns from the challenge of simply expressing your artistic ideas with your chosen instrument into keeping yourself in line without those helpful constraints. It makes playing a harmonious melody difficult.

Scala masquerades as a well-designed language because it includes all of these modern, cool, features. Each of these features is well designed. But putting all of them together is the opposite of good design. The whole, in this case, is much less than the sum of its parts.

All this is not purely philosophical. Languages like Clojure and Erlang tell the programmer "this is how you should write software", and if you need to do something else, you should integrate Java or C code. Scala, on the other hand, offers little guidance. Immutable and mutable variables are just as easy to declare; the "expression problem" is sometimes solved using OO and sometimes FP. As a research language - that's great; as a practical language, it can be destructive.

It is also wasted effort. While it is certainly true that sometimes "named types" are better while other times duck-typing is more convenient, or that sometimes you want simple mutability and sometimes you don't, or that sometimes pattern matching is better than polymorphism and sometimes the other way around, in 99% of the cases, either of these approaches works well. Good, working, efficient, complex software has been written in Java, Haskell, JavaScript and Lisp. Combining all those features into one language creates big, largely unnecessary, overlaps in functionality that mostly cause confusion. This wasted effort is not just a waste; it is downright harmful, because Scala has become a very complex language. So complex, in fact, that no one but veteran Scala experts can understand how Scala's linked-list is implemented.

It is also unnecessary because, as I've said, the JVM is a multi-paradigm environment. If one paradigm is better than another for different parts of your software, you can write parts of it in Java, others in Clojure, others still in Erjang, and others in Frege. Even then you'll find that one, simple, language is perfect for 98% of your project, while another simple language is the best fit for the remaining 2%.

I think Scala's designers are stuck in their PL-research point of view. It is immediately apparent that Scala is not a language that grew from developers' needs and problems (like Clojure and Erlang), but from a PL experiment. Some years ago it might have been OK to overlook much of Scala's complexity and use it as "a better Java". Now, Scala has become ever more complex, and at the same time, better designed practical languages for the JVM have shown up. Given the wide choice, I think Scala is now a particularly bad option for a practical JVM language, especially if you're working in a large team, as every complicating language feature causes compounded damage as the number of developers on your team grows.

[1]: http://www.infoq.com/presentations/Design-Composition-Perfor...

⬐ jeremyjh

There are a lot of things wrong with this, I'll just pick one.

Can you please explain more about what you think the relationship is between ADTs and monadic control of IO effects? The two are really not much related and there are languages like OCaml and F# which have ADTs but very limited use of monads - not for controlling access to IO. A monad need not be an ADT either. It really sounds like you know very little about Haskell and if you are going to criticize Scala for not getting the Haskell bits right then you really should understand it first.

⬐ pron

I am not saying one is absolutely necessary for the other. I'm just saying that Haskell uses its types for very strict type safety as well as for the control of side effects. I am no Haskell expert, but I believe side effects in Haskell are expressed in a function's return type. So the relative complexity of the Haskell type system is hopefully offset by its advantages of having fewer "type" bugs as well as fewer side-effect bugs, as well as better, more "pure", testing. There are other ways to control side effects through effect systems, but Haskell uses its ADTs for that.

⬐ asdasf

ADTs are algebraic data types. They are quite simple, and have nothing to do with the IO type which haskell uses to constrain side effects. An ADT is just a type made up of ORs and ANDs:

    data Bool = False | True
    data Tree a = Leaf a | Branch (Tree a) (Tree a)

⬐ jeremyjh

But it actually does not do so. The IO data type has a single value constructor: IO. Other monadic types do use ADTs - for example Either has both a Right and Left constructor - but ADTs are used extensively outside of any monadic type as well because the basic idea of composite types is actually very useful. So I cannot imagine how it is a bad thing that Scala has this useful feature, just because it does not also require an IO Monad? Does that mean ML is mistaken in its use of ADTs as well, even though it precedes Haskell?

⬐ eranation

Perhaps it didn't come from developer's needs, but it sure feels like it for me. What alternatives on the JVM you suggest? I will give it a try, I'm not married to Scala, and I don't get money from TypeSafe to promote it.

I tried Clojure, and other popular JVM PL, few issues making it not practical for my team at work:

1) Many people at my team for some reason don't get along with the Polish notation (me neither, and I'm of Polish heritage) - Clojure eliminated

2) Me and my team wants a static type system - Clojure, Ruby, Python, JavaScript, Groovy and such are eliminated

3) I need a JVM language (except Java) - Haskell, Nimrod, Go eliminated

4) What am I left with? let's see - Scala, Kotlin, Ceylon, Haxe, Gosu

I chose Scala because it has, for now, the wider adoption, support, and commercial backing from TypeSafe. and most importantly, which people don't seem to consider as a crucial factor in Scala adoption- I CAN USE IT AT WORK (for some reason, Java based Enterprises seem more likely to adopt Scala than Clojure, not to mention no chance of getting approval for using JRuby, Jython or such)

If you know of another statically typed JVM language that I should consider over Scala, I would ditch it without blinking. But for now, it's the best developer happiness language out there, I have no clue why it's so popular to bash it. perhaps because it's becoming Enterprise friendly, and people hate anything enterprise these days... In any case, it's good for me, I don't mind having a language with more features, I can always choose not to use them. Perhaps the core of all problems is conventions / style guides as Martin suggested, and "how Scala should be really used" projects. I'm sure you can abuse any language, especially if it has lot's of features. perhaps we need a subset of Scala, or perhaps Scala is a language for building languages?

In any case, coming from Java, I can't go back, I rather have my overly featured Scala over my verbose Java any day.

⬐ pron

My bet is on Kotlin, and if it doesn't catch on, I'm perfectly fine with Java 8 (I also use Clojure, but you say it's not your cup of tea).

⬐ trailfox

IntelliJ plugin download stats:

  Scala  883,000
  Kotlin  21,000

⬐ laureny

Age:

    Scala  - about 10 years old
    Kotlin - not yet released

⬐ pkolaczk

This is little inconsistent. Kotlin is well under development since 2010 and was published in 2011 or earlier, so it is already a 2 or 3-year-old project.

⬐ laureny

This doesn't matter much, v1.0 is a very important milestone because very little will be written about the language before then. Also, nobody will consider using a pre v1.0 language in production, no matter how many years it was in development.

⬐ virtualwhys

That's not fair, first wait for Kotlin to exist (stable release in @18 months last I checked) before making such a comparison.

Scala 2.12 and Kotlin 1.0 release points should roughly coincide. Scala's got a wee bit of a head start, but if Kotlin delivers on the promise to compile as fast as Java, then for sure they'll gain traction.

Speaking of build times, just got back from the ScalaExchange conference in London (suprisingly large turnout, a little over 400 attendees). Talking with one of the Typesafe team members, it appears that Jason Zaugg (works on the compiler) recently found a way to reduce build times by 20-30%...and that's just for 2.11, good times ahead ;-)

Should point out that incremental builds + sub projects pretty much completely mitigate the "scala is slow" argument, but for deployment Jason's recent enhancements will be a boon to all Scala teams, large and small.

⬐ eranation

Will give Kotlin another look, I sure love the IDEA ;)

Regarding Java 8, before knowing Scala well, I thought this will kill Scala for good. But I got spoiled by Scala's FP / OO mishmash, I got used to my duck typing, pimp my library, pattern matching, statically typed Frankenscala. perhaps it's not good, but once I figured out when to use which feature, and developed my own "Scala conventions" (not saying it was easy) I feel handicapped writing with other languages. Perhaps Scala needs a book named "Scala, the good parts" and a good Scala Lint as Martin suggested.

Will take a second look at Kotlin still, these guys KNOW programming langues.

EDIT: Kotlin looks great (http://kotlin-demo.jetbrains.com/), until I got to Delegated properties... not much better than Scala's invoke dynamic and lazy vals syntax IMHO. I love the compile to JS feature in any case!

EDIT2: correction, love observable, and delegate by map

http://kotlin-demo.jetbrains.com/?folder=Delegated_propertie...

http://kotlin-demo.jetbrains.com/?folder=Delegated_propertie...

⬐ cygwin98

It seems to me that what you want is a CoffeeScript for JVM, a language that is much more expressive and concise and at the same time can compile to JVM and utilize the aplenty Java libraries.

Like CoffeeScript, this language should mainly follow OOP paradigm, while allows certain kinds of FP features, such as first class functions, seq, etc. Immutability is not forced. Basically, a Scala-minus -- Scala without Haskell stuffs, and much reduced FP features.

⬐ None

None

⬐ eranation

This sounds basically like Xtend: http://www.eclipse.org/xtend/documentation.html

However, I got screwed, I now LIKE my OP / FP mishmash. Perhaps the OP is right, but too late for me, I can't work with any other language now. Haskell is too pure FP, Go doesn't have pattern matching, JavaScript is not typed (perhaps a JVM TypeScript is my ideal solution? or perhaps it's Dart?) same with Ruby and Python I'm stuck with Scala. p.s. if C# was on the JVM I would consider it as well. I'm going to give Kotlin another look though...

⬐ cygwin98

I think we share a similar background. I was coming from Ruby on Rails and C# background, and now am spreading into JVM via Clojure. Before C#, I did everything in C++, which I don't like. The past few years has seen a turmoil of battles on the web frontend, which caused a huge number of churning without much progress technically, totally waste of time and efforts in the web community.

Now, it seems to me that that turmoil is inching into the backend and JVM. A wrong selection of technology stack would cause a huge waste of time investment. That's why some of us stand up and say no to Scala, which has been aggressively marketed as Java++ for the past few years, and seems to gain some momentum. I personally consider that's a dangerous sign, as the objective of Scala (IMHO) is to replace Java as the mainstream industry language. With the complexity of Scala, can you imagine the average Java programmer starts to write libraries in Scala? That would be disastrous to the whole JVM eco system. We all know what happened to C++.

I personally would go with Clojure, which is at least philosophically coherent. I feel comfortable working in it. Even it may not become mainstream, I am OK with that. Life is short, be happy.

⬐ eranation

Well we do share the C# background, but I lastly used C# about 8 years ago, a lot has changed.

As much as I would love to have a Ruby background, Ruby (mostly on Rails) for me is a hobby language / framework, can't use it at work, sadly.

I actually come from 10 years of writing mostly Java and JavaScript. I (used to) like Java, but I will replace both Java and JavaScript with Scala in any of my new projects without hesitation. Including taking into account on-boarding new team members, including taking into account how complex people can get with Scala, trust me, bad developers make spaghetti from anything, Java included, and spaghetti is not the worse thing, bad buggy code is. you'll be shocked how many Java developers don't know the contract between hashCode and equals in Java. in Scala, if you use a case class (or data class in Kotlin) you get default equals and hashCode for you, so for you little DTO bean, you'll avoid having duplicates in a set (very common Java newbie bug). Also I tend to find that huge amount of Java bugs end up having the same 2-3 exceptions - and most notoriously the NullPointerException. With Scala options, it's diminished significantly.

p.s. I did some college projects with C++, and can read it but I can't really understand the comparison to Scala, really.

So I personally won't be worried about Scala replacing Java mainstream industry world.

1) it will take a lot of time for it to happen even if HN was full of ("Scala is even better than Go / Haskell / Clojure, my eyes are opened!"

2) even if it does, I am (very subjectively) about 10X more productive with it, and write / read code much more easily with it than with the same code written in Java, but this is only because me and my team constrain ourselves to avoid abusing the language. E.g. there is nothing wrong with if(option.isDefined) if you don't like pattern matching. or using dot notation and avoiding infix notation when not really needed. I also don't care about using vars, or using while loops when it's more readable, I always provide a named function to my operators, and only use implicit conversions when it really needed and helps code readability (for example to use it for actual CONVERSIONS and avoid method overloading hell and not just to pimp a library) I also avoid one liner terse code that no one can read (or debug) and the end result is 10X more happiness, productivity and fun than with boring old Java. I also use it with Spring, Java EE and Maven instead of sbt. Scala if used this way, is indeed a better Java. But it needs guidance, so perhaps it indeed needs a "the good parts" book / style guide / Linter

p.s. If you spent some time to learn Scala and tried it on a project, and still prefer using Clojure, I'll believe you. if you say you prefer Scala over Java, I will force myself to respect you and avoid being accused of an ad hominem attack :)

⬐ cygwin98

If you spent some time to learn Scala and tried it on a project, and still prefer using Clojure, I'll believe you. if you say you prefer Scala over Java, I will force myself to respect you and avoid being accused of an ad hominem attack :)

Thanks for the detailed reply. You're one of the HNers whose opinions I highly respect. Wish HN had the following features like Twitter.

My understanding of Scala is very superficial. So my opinion is obviously very biased at this moment. I've been immersing myself in Clojure and ClojureScript on and off for most of this year. Learning Scala will be on my todo list for the new year. Hope I will have something to share then. I may change my opinion though, should the new version of Scala rectify most of the flaws, given the fact that Rod Johnson joined TypeSafe, who tends to have the gift to simplify complexities.

And no, I don't like Java either and consider that it's reasonable that the community needs a more expressive language on JVM and leave Java as a supporting role to write underlying performance-critial JVM libraries just like C to the native libs.

⬐ eranation

:) you made my day, thanks, same goes to you!

p.s. I created http://scalatutorials.com/tour as an attempt to get the basics covered quickly, it's very early work in progress, but I got good feedback so far.

Also http://codebrew.io is a great place to start playing with the language without installing anything (it even has code completion, and runs in the browser, no installation needed)

Looking forward hearing your take on it after playing with it some more.

⬐ aklein

I think you've nailed it perfectly that Scala imposes as few constraints as possible. This leads to an oft-repeated criticism that since there are a dozen ways to accomplish the same thing, it is hard for a newcomer to be productive quickly or to know what the "best-practice" is. However, this same flexibility allows an expert user to make specific trade-offs. In coding Scala full-time for a year, and writing an open source library [1], I never found myself saying that "I wish Scala had feature X"; but more importantly, I certainly never said "I wish Scala did NOT have feature X." Indeed, it seemed to address so many deep problems with Java. One loud complaint is lack of reified generics on the JVM, but this is easily addressed in Scala using TypeTags (2.10+).

I like your musical instrument analogy, and to steal it, I would say that Scala allows you to be the composer rather than the musician. To be an effective composer, you need to know the qualities of all the musical instruments so they can work together harmoniously. You can write a beautiful symphony, or you can create horrible noise. But the power to do so lies with the developer/composer.

That said, arming your large development team of average developers with such powers might indeed be asking for trouble. That's why Rod Johnson, in his recent Scala Days address [2], challenged the Scala community to address this problem if Scala is to be the "next Java".

[1] http://saddle.github.io/ [2] http://www.youtube.com/watch?v=DBu6zmrZ_50

⬐ pron

With regards to the future of Scala, the problem is that Scala isn't even the incumbent of being "the next Java". Java (8) seems to be the next Java. Scala is already quite old to be so far behind, and there are several alternatives to Scala that don't suffer from Scala's shortcomings. My take on Scala is that it's a very interesting language that has taught us a lot; time and time again, when faced with the choice, it has taken the research-oriented route rather than the developer-oriented route, to its detriment; while gaining strides, it has failed to capture the hearts and minds of enough developers; there are languages that have learned from Scala's mistakes, are more developer oriented, and are more suited for widespread adoption.

As to the few constraints, keep in mind that my point is that those constraints are or at least directly lead to benefits. So few constraints mean few of the benefits. Scala mostly enjoys the "few lines of code" benefit that Ruby developers like, but not the more important benefits of a solid, well-considered, easy-to-maintain language.

⬐ edtechdev

To be fair, I see similar issues in many programming languages - taking features from other (earlier) programming languages out of the context where they originally made sense.

The colon in python, for example, makes sense for aiding readability (and parsing) in a case-insensitive programming language like its predecessor ABC. It's completely unnecessary for parsing today. Zero-based arrays make sense in C where you have pointers and addresses.

A lot of the features of programming languages today (including the fact that they are all text based) made perfect sense in the 1960s or 1970s, when all computers were ASCII plain text-based and had very limited memory and speed. Some languages would probably be better served by an outliner than a plain text editor, for example, but that didn't exist decades ago.

⬐ pron

Remember Sun's defunct Fortress language? You could code in ASCII and render the code in a math notation. Guy Steele was the lead designers, but the project lagged, and shortly after the Oracle acquisition it was shut down.

⬐ riquito

> Zero-based arrays make sense in C where you have pointers and addresses

Dijkstra begs to differ

http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

⬐ smrtinsert

I see no issues using Scala in a simple context. When you buy more equipment for your entertainment room you do not turn on all the devices at once, you use what you need.

From that perspective, it is very possible to right clean, maintainable, succinct, performant code in Scala with classes, case classes, pattern matching, immutable data structures and the stackable trait pattern. Scala 101 as far as I can tell is fairly obvious if you have done a lot of Java programming - you know where the pain points are and how Scala can shorten or eliminate the problem. I think something which would serve the great majority of Java developers as a better Java.

As a Scala newbie, I didn't find it hard to get there to understand how I can sunset my Java programming with Scala, and I'm having a hard time finding a reason to go back. The arguments against Scala (like yours) seem to often get lost in big ideas (being a lifelong musician myself Hickeys instrument talk was only marginally inspiring), whereas I'm looking at LOC and syntax and I really like what I see. I can do the same thing in Java, but with more effort.

I think the only benefit Java enjoys right now is better tooling. It still might be the best choice for large teams due to way it shoehorns development styles (and I actually don't mind coding it in at all, its pretty nice), but for my personal projects, I'm definitely focusing on Scala right now.

⬐ nomothete

i watched the Rich Hickey talk you referenced and one thing really jumped out at me: "choose-a-phones" have been around for a while now and, indeed, are quite popular instruments, though most of us call them "synthesizers". i enjoyed the talk and thought it was interesting and insightful, but i also think that the central argument is completely bogus. programming languages are special kinds of tools. the "specialness" is, at least in part, due to their universality. hence, by definition, programming languages more closely resemble synthesizers ("choose-a-phones") than bassoons.

⬐ shadowfiend

You make the distinction between a research language and a practical language, but I'll draw a different one. I think some of what you says makes sense, and some of it reveals the underlying issue while framing it poorly. You say “Scala takes these features but drops their reasoning; in the process it lost its coherence.” I think you can't find a coherence, but that doesn't mean it isn't there. And I don't say this as an ad hominem attack—I completely understand some approaches to problems, others don't make nearly as much sense to me.

The distinction I want to draw is between types of teams. Some teams are very very organic, they let most of their developers do their own thing and they come together relatively independently. In these teams, having the language dictate approach isn't just handy, it's critical to keep the system coherent. You can instantly say during code review “yeah, that's not how it's done in Clojure”. Scala doesn't have the same level of guidance. Style is dictated by the frameworks you choose, and even then there's room for error. I use style, by the way, not as meaning “please use two spaces instead of tabs”, but rather as “parameter order in these cases should be this, method names should be structured like this, our class names usually look like this”, etc.

The other team is the team that has a clear single or group of guiding individuals who have a vision of how they want the system to work on a stylistic level, and who can explain that vision to the rest of the team. For these types of teams, where those individuals enjoy the process of coming up with the vision, Scala can be exactly what they're looking for, because they can develop the style that fits best with the system they're building. This shouldn't be confused with architecture. Architecture is important, but style is not a subset of architecture, it's an overlapping set.

A choose-a-phone is difficult for a single instrument player who is used to constraints, but for someone who likes to push the edges of constraints and come up with just the right combination of sounds for this particular piece, a choose-a-phone gives them the freedom to do that without having to pull in seven different instruments. Indeed, if we could make a choose-a-phone, I doubt every symphony composer would shirk it—I suspect some would embrace it. Not as something for research, but as something that lets you produce a different kind of musical piece. It wouldn't work for every composer or orchestra, but for those who could establish a coherent sound from the vast range of the choose-a-phone, it would be a fantastic opportunity to create something new and, from some perspectives, better.

The way I've successfully used Scala has always been about discipline. You choose the path you want to follow through the language, and you stick to it via code review. If you discover a new corner or feature of the language, you discuss its usefulness and choose to either incorporate it into your existing processes or not. Could you just say “let's use this other language for this”? Yes. But Scala lets you explore a large set of opportunities within a similar syntax, and use them where they are appropriate. If the syntax is what bothers you, or if the particular approach to a given piece of functionality is what bothers you (this has happened at times in my experience), then you can explore a different language; Scala certainly doesn't preclude you from doing that. But your first forays and prototypes can be within the context of a language everyone on your team already knows, making for a smaller incremental step. Smaller incremental steps mean faster iteration, and faster iteration means faster decisions on whether something is a good idea or not.

Scala more than many other languages doesn't dictate approach. But that doesn't mean approach doesn't matter. It means the approach ball is in your court. Pick the wrong one, and your experience will probably suck. Let that taint your view of the language if you wish, but keep in mind that there may be an approach that will be a lot nicer. For some people and some teams, that's not what they want out of a language, and that's fine. For some people and some teams, that's exactly the kind of empowerment they want, and that's fine too.

There is no difference in practicality, only in personality.

PS: I love Clojure and Erlang, too ;)

⬐ cygwin98

Basically, you're describing C++. That's the reason why I upvoted that rant post, as I share the same opinion with that author that we don't want another complex industry-grade language.

⬐ pron

I agree with most of what you say, and obviously, some people really like Scala, and not only as "a better Java". But I think there is still an objective measure here, which is bang for the buck. Scala does let you choose different styles, but while you pay in complexity for that choice (which some people like), you don't get the same benefit as you would in an ensemble of languages. Scala really is heavier than JavaScript, and Scala doesn't really give you most of Haskell's benefits (no true type safety because of casts, no control over side effects, and easy mutability). So you pay full price for "good" ADTs, but get just a taste of their benefits. Same goes for duck typing and macros.

So you do get choice, but it's more of a choice between a Paris-style and a New York-style Las Vegas hotels rather than between Paris and New York. Scala is Las Vegas, only it runs on the JVM which offers cheap supersonic flights between Paris and New York.

Also, the kind of team you describe can't really be a big one. I might see it working for 15 people; maybe 20 if they're really good. But 50 and up? I don't think it's going to work.

⬐ shadowfiend

All I can say is that I think you're completely mistaken.

I can count on one hand the number of times I've had to do casting in Scala over the course of writing four different web applications of various sizes in it. Fine-grained control over side effects is only a benefit if you consider it a benefit, and is IMO far from the greatest benefit you can get from a strong, flexible type system. Easy mutability has little to do with type safety—indeed, type safety makes mutability marginally safer by at least holding you to a basic promise when you make mutations. I can't deny Scala is heavier than JavaScript, I suppose, for some definition of heavier that I assume means “has more features”, or means something that ends up equating to same.

To argue that writing software in both Clojure and Java (or pick 2+ other languages that all run on the JVM, of course) will leave you with an objectively lower complexity:benefit ratio than using a single language is a dubious claim indeed. I don't guarantee that just using Scala will always result in a lower such ratio, but you'd have to make a much better quantitative argument to convince me that you can have a lower ratio consistently by using different languages instead.

To deal in increasingly-divergent analogies one more time: if your work is in Las Vegas, you may not care that there are cheap supersonic flights to other cities. They will never compare to being able to do all of your work in Las Vegas, even if it means switching hotels depending on your needs on a given day.

⬐ platz

yeah, the polyglot approach is total in it's coverage, but I haven't experienced how polyglotism works on a team or set of teams.

If you look at Odersky's presentation "The Trouble with Types" [1] at Strage Loop 2013, he describes Scala as a "type it to the max language" like haskell, ocaml or F#. He seems to be aware of the complexity problem and proposes a few ways to reduce some of the type complexity.

[1] http://www.infoq.com/presentations/data-types-issues

⬐ pron

Yes, I have watched that talk, and Martin Odersky is clearly aware of Scala's problems. If he were to come up with a new language, I would certainly give it a try, but I think it's too late for Scala.

BTW, to reiterate some of what's been said in other comments, I am certainly not opposed to using Scala in "Ruby style" projects (though Clojure would be a better option for those, too, IMO); I do, however, think that it's a very bad alternative for large Java projects.

⬐ trailfox

In our experience Scala has been a superb alternative for large Java projects. Practical experience vs. your opinion/speculation?

⬐ pron

Call it educated speculation based on years of experience with similar decisions.

How big is the team? How many years of maintenance have you had on those projects? I remember C++ looked pretty awesome for a while. It was certainly great for one-man projects or small team. Then the problems started piling up. Thing is, C++ didn't have any good alternatives (maybe now we'll have Rust); Scala does.

⬐ trailfox

I think you're confusing Scala and C++.

⬐ pkolaczk

Scala is not C++. Scala has much better features to keep complex pieces of code separated from the simple pieces. Also C++ design philosophy was totally different from that of Scala's - C++ values performance over everything else, while Scala's top priorities are correctness and type-safety.

⬐ laureny

> Scala is not C++.

That was not the point. The comparison is that Scala is to Java what C++ is to C.

Powerful and flexible but with a lot of baggage that ends up making it impractical.

⬐ trailfox

> The comparison is that Scala is to Java what C++ is to C.

Which is pure opinion/speculation.

⬐ pkolaczk

Nope. C++ is almost a superset of C (there are a few minor differences, but most C programs are correct C++ programs). Even the most basic Scala program is not a valid Java program. They are just two different languages targetting the same platform.

If making analogies, a much closer analogy would be to say Scala is to Java what D or Rust is to C++.

As of lots of baggage - can you elaborate? Only null comes to my mind and it is never an issue - it was left because Scala is practical. Sure, there are some limitations imposed by the target platform like lack of TCO, lack of efficient suport for tuples/value-types, or RTTI for generics being not powerful enough, but Java-the-language has nothing to do with it. The same limitations apply to Kotlin and Ceylon.

⬐ virtualwhys

He is actually exploring the development of a new language; see the DOT (Dependent Object Types) paper: http://www.cs.uwm.edu/~boyland/fool2012/papers/fool2012_subm...

It will be based on Scala, and similar enough that, if things work out, we could have Scala.next without a Python 2 to 3 glacial transition.

Of course, Scala 2.1.x branch is making great strides as is, and AFAIK, the DOT language is still a research project, so not likely that we'll be seeing Scala.next anytime soon.

⬐ pron

Using two languages will give you a much better cost/benefit ratio, and here's why. In a team of 20 people, 18 will program in simple language A, while 2 will program in simple language B. The ones programming A know it well; those programming B know it well, and usually they would also know A well, as they would probably be your star programmers. The JVM makes integrating the two quite easy. You wouldn't need to discipline those 18 programmers to limit themselves to some subset of Scala, and they wouldn't be dumbfounded by its linked-list.

I've worked on projects that used C++, Ada and FORTRAN; on projects that used Java, C, and some homegrown DSL; on projects that used C++ and Scheme. In all circumstances, the integration of languages proved simpler than "disciplining" the C++ programmers, and on the JVM that integration is a lot simpler than what we had to put up with back then.

Also, bear in mind that team members change, as do team leaders. That proved to be a big problem for C++ projects as the discipline changed over the lifetime of the project.

⬐ pkolaczk

First, Scala is not C++. Second, you need good discipline in those simple languages, as well. I've seen too much terrible Java code to believe Java simplicity saves you from being disciplined.

⬐ efuquen

What exactly is inherit about duck typing or OO that say they can only be used in a simple language? Duck typing works great in Scala, more so then in Javascript because it's type safe and it's impossible to make the same mistakes you can easily do in Javascript. Scala's OO is vastly more powerful then Java's and IMO opinion more elegant and simple to use. I look at these features in isolation what I see are much better designed implementations of those ideas, I don't see how they can only make sense in a language that's simpler then Scala.

This notion of simple also confuses me. You mention Javascript, and while I agree Javascript is easy to write I would certainly not call it a simple language. There are a huge number of inconsistencies, gotchas, and just plain head scratches littered throughout. And let's not even get started on the hot mess that is prototypical inheritance in. Java is hardly simple, it's outdated and probably one of the main reasons there is a movement to other languages are because of the lack of new paradigms integrated into it's core, but that certainly doesn't make it simple. I can show you some pretty nasty Java code bases that can be just as if not more confusing then some of the worst Scala code I've seen out there.

In terms of focus, I think Martin and the community has been pretty clear about what Scala is about, an OO based functional language that focuses on practicality over theoretical purity. If it was meant to be an academic language why focus on Java interoperability so much? One of the beauties with Scala (though some might disagree) is you can basically write it to look just like Java, which is why it can have a leg up over a language like Clojure, whose syntax is so different. Why include mutable state at all? That certainly isn't a trend with academic languages, but it certainly is practical to allow when performance reasons dictate it. Why create Typesafe and have all this focus on strong native build tools and good IDE integration? I honestly don't think Martin just decided one day out of the blue that he wanted to make Scala a practical language, that's been part of the game plan from day one. The precursor to Scala, Funnel, was dropped specifically because he didn't feel it was a practical language and he started over and wrote Scala.

I think Scala has been finely tuned for it's purpose, to provide an elegant synthesis of functional and OO paradigms that allow developers not use to those ideas to slowly wade into that new world. That's the way I was introduced to it and that's the way I know many other developers have been introduced to it, with good results. Having worked at a few different companies of varying size, all with large code bases in Scala, all training new people with the language, I can say it's definitely possible to get large teams working on complex problems to adopt it and thrive. And I'm starting to see more and more adoption, both in the enterprise and at startups as well. I think plenty of people are jiving well with their new chosen instrument, it's fine if you don't like to play it, but I don't think it deserves to get knocked off as an unplayable mess as a result.

⬐ MetaCosm

Due to you post relating to musical instruments I will forever have this mental image (http://blog.modernmechanix.com/mags/PopularScience/7-1937/pl...) when I think of Scala -- 11 Musical Instruments at ONCE! So Elegant!

⬐ dancapo

I see some objective problems with your analysis: it looks more like you expect to be true than assertion of facts, and it is filled with misconceptions. You expect that mixing oo and fp aspects cannot work, and deduce problems from that expectation.

Here's a different premise: Scala combines fp and oo while keeping things simple because it is coherent -- more so than languages such as Java.

So, for instance, when you complain about Scala's algebraic data types, you completely miss the fact that Scala doesn't have them. There's no type in Scala that isn't a class.

Instead, various Scala features are combined to support ADT patterns through the OO type system, and these features are designed to work in concert to produce various desirable effects, instead of having stand alone features serving a single purpose, without coherent integration with the rest of the language.

Take Java, for example, and some things it has that Scala doesn't: static declarations, primitive types and arrays. Each of them are completely at odds with the rest of the language: they serve a single purpose, they have their own rules, and they cannot be combined. That is bad design.

Let's consider one of the features you mention that Scala actually has, and see how it fits: structural typing. Scala doesn't have structural typing because all the cool kids are doing it or some other non-sense: it serves a purpose in the language, and solves a number of problems in a coherent manner, with a single set of rules and in a way that combines together with other parts of the language.

Specifically, it generalizes Java's own duck typing, which, apparently, you never realized it was there (because Java is such an ad hoc language): anonymous classes extra methods. There's no explanation in Java's type system for why anonymous classes may have extra methods and use them. They are simply allowed for anonymous classes, and that's that.

Scala, on the other hand, introduced "type refinements". It is exactly the same thing: extra methods. However, it is not a standalone thing dissociated from the rest of the language: one can call these methods because they are part of the type refinement. And because they are part of the type refinement, it also means they can be visible from outside the anonymous class, and even specified as the type for parameters.

And that's where the "duck typing" comes in: it is simply the type of an anonymous class that extends Object whose extra methods are visible from outside the anonymous class itself. Not an extra feature, compared to Java, but an existing feature of Java that got integrated.

The pattern continues: while Scala has just classes with refinements, Java has classes and primitives and arrays. While Scala has just methods and assignment, Java has methods, static methods, operators, fields, assignment (of which multiple kinds exist!), and array index access and assignment.

It's not that Scala has many disparate features: it has a core of well designed features, and they are well designed because they allow use in many different ways.

Now, if one thinks a language should constrain its user, then Scala is not a language for that person. But, please, don't invent problems that don't exist because you expect them to be there: if you want to criticize it for anything other than not being to your taste, at least get to know it first.

⬐ frowaway001

Thanks a lot for your comment. This is probably one of the best explanations I have read since a long time.

⬐ laureny

> Let's consider one of the features you mention that Scala actually has, and see how it fits: structural typing. Scala doesn't have structural typing because all the cool kids are doing it or some other non-sense: it serves a purpose in the language, and solves a number of problems in a coherent manner, with a single set of rules and in a way that combines together with other parts of the language.

I'm surprised you're pointing out bad design decisions in Java (that I agree with) and point structural type as a good Scala design decision.

Structural typing is terribly designed and avoided overall for all these reasons. For example, asInstanceOf doesn't work with structural types but works fine with traits and classes. That's bad design.

Here is an example showing how broken structural types are:

    scala> type Mappable[A] = AnyRef { def map[B](f: A => B): Mappable[B] }
    <console>:7: error: recursive method map needs result type
           type Mappable[A] = AnyRef { def map[B](f: A => B): Mappable[B] }

I have about three other mystifying compiler errors due to the fact that structural types are very badly integrated in the language overall.

> It's not that Scala has many disparate features: it has a core of well designed features, and they are well designed because they allow use in many different ways.

I think you are not being very objective in the way you see Scala. A lot of its features are terribly at odds with each other, such as mixing inheritance and type classes (which one should I use and when?), the eleven ways in which the underscore character can be used, currying and its bizarre syntax, the odd rules when you can omit parentheses and when you can't, when to use parentheses and when you should use braces, etc...

Scala has tons of disparate features that don't fit very well with each other, and it's very similar to C++ in that respect.

⬐ dancapo

One of the goals of Scala was having good interoperability with Java. This might not look important today, where considering different languages is ok, but it was certainly the case years ago, when programming environments were monolingual and proud of it.

There are bad consequences arising from that, but it was a trade off that was made taking into account the failure of Scala's predecessor, Pizza.

Among these things there's asInstanceOf, which you should generally not be using in first place. That said, you can use asInstanceOf with structural types:

scala> object X {

     |   def f(a: Int, b: Int) = a + b

     | }

defined object X

scala> val y: Any = X

y: Any = X$@aebbca6

scala> val z = y.asInstanceOf[Any { def f(x: Int, y: Int): Int }]

z: Any{def f(x: Int,y: Int): Int} = X$@aebbca6

scala> z.f(2, 3)

res6: Int = 5

Your example definitely doesn't show structural types being broken: it only shows that type refinements cannot be recursive. This might be limiting, but it is not broken, and it was a necessary trade off to integrate structural types into a nominal type system -- something that was thought to be impossible.

Inheritance and type classes: type class is not a Scala feature, it is a design pattern that uses other Scala features together, so there's no "clash" here, because there's no feature.

The eleven ways in which underscore can be used is not something "at odd" either -- it's just the same symbol used in eleven different contexts to mean eleven different things. It saves on reserved keywords/characters, at the cost of making the language more difficult to learn, but there's no conflict between their uses.

There's nothing bizarre about currying syntax -- you may not like how it looks, but it's perfectly functional. Maybe you like point free programming, but that is NOT a style favored by Scala, intentionally so.

The rules for omitting parenthesis are actually rather simple: you can omit parenthesis around the parameter of a single-parameter method when that parameter is enclosed in braces itself; you can also omit parenthesis around a parameter of a single-parameter method whose parameter type is a tuple.

Now, even if I had not an answer for each case you raised, you have failed to show that they don't fit well with each other. You have criticized each one on their own, in isolation, and, in fact, failed to appreciate how they actually show their strength when combined.

Some examples of that:

* Omitting parenthesis combined with by-name method parameter passing allows for DSLs that look like native language constructs; * Implicit parameters, type inference and nominal typing can be used together to produce the type class pattern; * Abstract data types and inheritance can be used together to create a module system.

⬐ ssmoot

You keep posting this argument.

As a practicing Scala user, I think it's pretty unfounded.

You could make the same "3 unnecessary type systems" argument about Ruby with attr_ methods, duck-typing, and classes. But I've never seen that. Maybe that's because if you're a fan of Ruby, the fact that it's Strongly Typed is pretty incidental. Things have Types, but if it's not enforced in any practical way, do you care? Pretty much not. It's a dead giveaway when people misunderstand what "expressiveness" means in the context of a type-system and go on to talk about how expressive Ruby is. Next to VBScript and JavaScript it's the least expressive language I know.

Scala isn't Java++ for me. It's Ruby++.

So maybe it's a case of differing backgrounds and expectations. I don't know Haskell. I went from VBScript, to JScript, to c#, to Ruby, to a smattering of Java, to Scala.

So from my perspective this argument is as Ivory Tower as it gets (which is a bit ironic right?). It's like suggesting Ruby needs to remove attr_ methods, or Struct. It's like suggesting that all you need is eigenclasses and you shouldn't have any label following the "class" keyword. It's like suggesting Ruby must drop respond_to.

And I have to wonder: What's the point? Would it make Ruby a better language? Is it going to make Scala a better language? No. Taking away my ability to emulate c#'s using() method with Structural Typing is not a step forwards, and it's most certainly not a case of "good design".

So eliminate case-classes? Why? Limit yourself to bolting on properties, equality, hash codes, etc ad-hoc? What's the point of any of that? It's definitely a step backwards in ease-of-use.

This is the very opposite of a practical or pragmatic critique. There are problems with Scala sure. That it simplifies a lot of boiler-plate (and really enables the FP/OO bridge) with a keyword (case class) and syntax (structural typing) isn't one of them from my perspective.

⬐ eranation

> Scala isn't Java++ for me. It's Ruby++.

Exactly! I wish more people knew both Scala and Ruby well enough to notice it

⬐ pron

Ruby (in which I've written no more than maybe 100 LOC) is great for what it does, but no one in their right mind is going to build a 10 MLOC aircraft-carrier control software in Ruby. Ruby's main goal is fast prototyping and fun initial development, a goal which it accomplishes beautifully. It is not a language for big engineering undertakings. But Scala tries to compete with Java, and you would write a 10 MLOC aircraft-carrier control software in Java. Once you're dealing with big engineering efforts, out-of-the-box ease-of-use is no longer your main concern; it's not even among the top five concerns, but complexity certainly is.

I don't have a problem with Scala as a Ruby replacement. I do have a problem with it as a Java replacement.

⬐ dragonwriter

> Once you're dealing with big engineering efforts, out-of-the-box ease-of-use is no longer your main concern; it's not even among the top five concerns, but complexity certainly is.

If you are writing massive software to handle comprehensive control for an aircraft carrier, you'd better be writing it in loosely-coupled components with well-defined interfaces, or its going to be a maintainability nightmare no matter the language features.

If you are doing that, Scala's flexibility lets you, internal to each component, take the approach most suitable for the team responsible for that component addressing that components requirements.

I can see where Scala's flexibility could make a bad situation worse if you are writing an enormous piece of software but not doing it in loosely coupled components but instead doing a tightly coupled nightmare -- the OO equivalent of spaghetti code -- but, even though it might be less of a disaster, that's still going to be disaster in Java or C#, too.

Rich Hickey is a genius. I love how he connected music to software engineering [1]. He should write a book on some of these topics. He has a lot more than 45 mins talks to offer to the world.

[1] http://www.infoq.com/presentations/Design-Composition-Perfor...

⬐ kriro

I've been waiting for a book that elaborates on simple design a la Hickey (with some examples/code) ever since I saw the "simple made easy" talk. If there is one that I missed, I'd love to know.

⬐ larve

paradigms of artificial intelligence by norvig, although seemingly about something completely different, has the same "simplicity" in its code.

If you're happy, keep on truckin'.

But to answer your question. This has been said a million times, but here's another angle. In a recent talk, Rich Hickey was talking about the design of electronic music modules:

> In other words, there's a human interface and a machine interface to the same > things. And the machine interfaces were there all the time — in fact, they were > first. And then the human interfaces come. We have to remember that as a > design thing. What's wrong with SQL? What's wrong with SQL is there's no > machine interface to SQL. They only designed a human interface to SQL, and > we've suffered ever since, cause we have to send these strings around. You can > always build a human interface on top of a machine interface, but the other is > often disgusting.

http://www.infoq.com/presentations/Design-Composition-Perfor... (at about 41:00)

Emacs is built on a machine interface first (elisp). Even the mouse actions in emacs are processed with elisp. So the human interface is not hard-wired. That's why hackers like it.

⬐ jballanc

For me, the most poignant message in this talk is when Rich draws the contrast between learning an instrument, which no one pretends is an easy task, and learning a new programming language, which seems to be increasingly accompanied by "learn X in 5 days" type tutorials.

A performer who has already mastered one or more musical instruments will be better able to rapidly learn a new one, but a novice is going to need to toil away for years before they reach master-level proficiency. Similarly with programming, I think it is fine for languages to present themselves succinctly for the benefit of experienced developers, but I am highly suspicious of anyone who claims you can learn to program in less than, say, 2 years.

I also think this is something to keep in mind with the recent explosion of "alternative programming schools". You can hand someone a guitar and, in a handful of weeks, teach them all the cords for 10 popular tunes. That person can then find a street corner in the nearest city, set down their open guitar case, and play those ten songs in rotation and make some money...but have we created a new musician?

⬐ wes-exp

Favorite quotes on this:

"We should not sell humanity short by trying to solve the problem of beginners in our stuff. We need to make things for people to use, and we need to teach people and trust people to be able to learn how to do that"

"Just as we shouldn't target beginners in our designs... nor should we try to eliminate all effort. It's an anti-pattern. It's not going to yield a good instrument. It's okay for there to be effort."

⬐ tom_b

I'm particularly interested in the idea of programming practice. Hickey specifically mentions Coltrane, who apparently was famous for marathon practice.

As a workaday hacker, my own practice has been more sporadic than I want. This talk reminded me that practice needs to be structured and purposeful. And regularly done.

⬐ None

None

⬐ saraid216

> learning an instrument, which no one pretends is an easy task

Google "learn to play the guitar in 5 days".

⬐ tinco

> which seems to be increasingly accompanied by

I learned to program from a 'learn X in 24 hours' book over 10 years ago.

⬐ jfarmer

I'm one of the co-founders of Dev Bootcamp, although I'm no longer involved day-to-day. What it means to "learn to program" is nebulous. As you pointed out, a person regurgitating things they've seen is able to "program" in some sense.

What I can say that the priority is not so much teaching them X, Y, or Z framework, but teaching them what it means to "think like a programmer." You might not think that is teachable, but, well, empirically falsifiable. :)

I'd definitely call students who went through DBC "programmers." Many of them remark after graduating that they never realized how little they really knew. At the very least, we get them from unconscious incompetence to the bottom rung of conscious competence.

If all I were doing were teaching folks "cords[sic] from 10 popular tunes" I'd have no interest in doing it at all. Real programmers or bust.

I can't speak for anyone else, of course.

⬐ jballanc

I have always been a huge proponent of the concept of teaching the art of learning, as opposed to teaching a specific skill. My concern is that, as Rich discusses, truly learning to program is a slower process, at the outset, than learning how to piece together a handful of frameworks and code snippets from Stackoverflow.

A proper education lasts longer than the duration of the actual instruction, so I trust that some of these "short term" programs can still make programmers (and anecdotally, I've heard good things about Dev Bootcamp).

⬐ bchjam

I love it when musical and computational composition get paralleled. I just saw a different talk focused on this theme recently, focusing on Goldberg variations using the Overtone library in Clojure. You actually get to hear things build up as you see the code do the same in this one, really cool.

video: http://skillsmatter.com/podcast/home/functional-composition

repo: https://github.com/ctford/goldberg

(edited to add the video link)

⬐ paperwork

Also at infoq: http://www.infoq.com/presentations/music-functional-language

⬐ agentultra

Another very interesting talk. He always gets me thinking even if I don't always agree with everything he says.

I don't think programming languages should be like instruments. I find it awkward working in Haskell or Clojure because I'm a composer and not a performer. I might be writing a rock opera one day and some chamber music the next. As a composer it seems completely wrong that I should contort my expression of my music to fit the characteristics of a single instrument. I can't bring an oboe to a metal show.

The computer itself is the instrument... one capable of becoming any instrument I program it to be. One that can be programmed to generate instruments and arrange them into symphonies.

The notation we use for describing music is, in my opinion, what programming languages should be like. If what I'm trying to do is write a symphony there is a common language and notation that everyone understands. A symphony isn't written alone by a composer in a room (despite what Danny Elfman would have us believe). They're generally written by a team of people doing transpositions, arrangements, and the like. If each part is written in its own notation/language then it becomes very difficult to see the whole piece as a single composition when it's finished. And it's much more difficult to compose such a large work and turn it into something we can execute and perform.

And that's where we are today in a number of domains such as web development and other distributed systems. We have these monstrous systems that are supposed to work in harmony but the notations used to describe them are so specialized and disparate that no one person can understand the whole piece. We have bits of systems written in C, others written in a handful of scripting languages, and run-times all over the place performing redundant work and wasting resources. It's a time-consuming and expensive process developing these systems because few of our "instruments," work together.

(and the problem, I believe, is deepening as we continue to develop systems-level programming languages whose ABI's come with the baggage of run-time processes)

I don't think programming languages, environments, and tools need be reduced to single-purpose instruments. I think we need languages more like Lisp and the symbolic model of computation where we can describe our processes using a notation and form more akin to rhetoric and logic that is much closer to our intent and purpose. We need the implementation of those languages to take those programs and turn our general-purpose computers, the real instruments, into virtual machines capable of executing those processes just as we describe them.

⬐ tikhonj

Programming languages are far more than notation. Notation is just syntax, and syntax is not that important. The syntax has to be readable and pleasant and unambiguous but that is it--nothing more, nothing less.

But programming languages go well beyond this: a programming language is a combination of syntax with semantics. And semantics, by far, is the most important part!

In your musical analogy, syntax would be the notation and semantics would be music theory or composition--the music itself. Semantics pervades everything: it controls what you can express, how you can express it and even how you think about it. All this is very much a function of the programming language more than any other tool or component in a software system.

The computer is the instrument, but the instrument is just an implementation detail. It's what we use to produce the music, but it's the music itself that we create.

As you said, you are a composer not a musician: so which part, then, is important?

⬐ saraid216

Amusingly, this may be the best response I have to your comment: http://www.infoq.com/presentations/music-functional-language

⬐ agentultra

I've used and jammed on several live-programming environments for sound in Common Lisp and scheme over the years. I like the style of language particularly for those reasons because you can reach a point where you're not programming functions that operate on primitive data structures anymore (although that is what is ultimately executed); you begin to develop a language that makes sense for describing musical processes. And that's just easier to reason about.

Nice link! :)

⬐ brandonbloom

I saw this talk at Clojure/West and it was excellent!

I've got it on in the background now while I do some rather mindless tasks. Unfortunately in this version, Rich seems a little tired / low energy in the beginning, but it really picks up in the middle. The bits about instruments and players is especially both illuminating and entertaining.

Overall a great talk, well worth watching.

⬐ rartichoke

He's definitely right about how most people want a lot of choice but in the end it's going to paralyze you for most use cases. I made this realization a few months ago.

I can't count the number of months I lost trying to research things at levels of the stack that I'm not interested in but were forced to look into to get to the point where I wanted to be.

It's mostly the reason I started to use rails to build document-like web apps/sites because if I have to answer 35 questions and build a platform on top of node/express just to get to the point where I can start solving the problems I want to solve then I'm clearly at the wrong level of the design stack.

⬐ wes-exp

Is there a way to see this without compulsory registration?

⬐ badman_ting

http://bugmenot.com/view/infoq.com

⬐ gwu78

http://d1snlc0orfrhj.cloudfront.net/presentations/13-apr-des...

⬐ ludwigvan

If you change your UserAgent to iPhone, you can watch (and download) it without Flash. Not sure if it is OK to download it, but it can be done.

⬐ agumonkey

AFAIK registration isn't required on infoq, and I'm watching it right now.

⬐ wes-exp

I see. It seems that if you don't have flash enabled, nothing appears but links for the MP3 and slides, which do require registration.

⬐ agumonkey

Alright, so only downloads require registration.

⬐ frou_dh

Whenever you're denied video for not having Flash, try making your browser spoof an iPad User Agent. That works here on InfoQ and on many other sites.

⬐ hashtree

Truly a great speaker/thinker, able to communicate his thoughts well.

As a former avid Scala developer, I started down the path of watching every Rich Hickey presentation I could find one week. Every video tweaked my thinking just a tad (as I almost always agree with his line of thinking), and I came out of it a better functional programmer and a Clojure developer.

Note: I still do/love Scala, I just develop much less of it in favor of Clojure.

⬐ SkyMarshal

Both Hickey and Odersky are awesome, having to choose between Clojure and Scala is just an embarrassment of riches. The JVM ecosystem is fortunate to have both building on it.

⬐ jonahx

Would you mind sharing links to your other favorites?

⬐ sandyarmstrong

Just look down http://www.infoq.com/author/Rich-Hickey . Probably the most famous talks are "Simple Made Easy" and "The Value of Values".

I'm also a big fan of the talk on persistent data structures, simply because it was my first introduction to them.

⬐ cgag

Yes, "Simple Made Easy" is a must watch imo. http://www.infoq.com/presentations/Simple-Made-Easy

"Are we there yet" is also great: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...

I also love "Hammock Driven Development": http://www.youtube.com/watch?v=f84n5oFoZBc

⬐ gosub

I was sold the first time I saw "Clojure for lisp programmers". I consider "The language of the system" and the simple/easy talk two modern classics.