Actually there are "real systems" being written in FP e.g. Clojure @ SoundCloud.
They just aren't architected the same way. Instead of a monolithic WAR you end up with a series of micro services. FP is actually more suited than OO for micro services since it naturally forces developers down the "do one thing well" approach.
So I would stop with the "OO is what real people use" nonsense if I were you. Because languages like Scala and Clojure are rapidly taking over from Java in the enterprise space and you may find yourself on the wrong side of history.
> Because languages like Scala and Clojure are rapidly taking over from Java in the enterprise space
Let's see how much of the momentum these languages keep after Java 8. Default methods, the new stream API and lamdas provide much what most developers need without introducing baroque features and orthogonal infrastructure.
Doesn't change the point. It's called JAVA but with lazy streams and closures, everything Java culture built prior that will be moot and that's what the article is pointing at. Same thing happened in PHP land, people say PHP is great now, but what is PHP ? PHP5, which is a perlish javaesque thing ? or the regex craze html implicit template system that was PHP4 ? ...
OOP is too verbose by it's essence compared to closures. I tend to see curried functions as anonymous objects (old lisp koans joke on their duality).
> Same thing happened in PHP land, people say PHP is great now, but what is PHP ? PHP5, which is a perlish javaesque thing ? or the regex craze html implicit template system that was PHP4 ? ...
Get the facts straight please.
As much as I don't like everything about PHP, PHP means PHP5 and it has been like that for a few years.
I'm talking about languages evolution. PHP5 got a Javaesque Object System, closures, generators. The idioms that will emerge will be close to other language with similar features, and what made php php is becoming less and less so.
PHP is a funny thing, started very very low (https://twitter.com/agumonkey/status/488432654577303554), and nowadays it's got a lot of very positive improvements (linguistic features, faster interpreter, principled community). Who knows how long it will survive ...
edit : I should have said closures + curryfication so you can partially augment the creation of a final callable entity that binds many parameters (similar to an object constructor arguments)
CLOS is a layer on top of CL, it's optional. Also, LISPs are as verbose as you want them too. If you identify boilerplate you macro it away. It's part of the culture. Some systems (php/symfony2, eclipse/emf) go out of their way to generate unnecessary temporary files, templates and such but it's still cumbersome.
To be honest, CL shows its age (mapc, mapl, do, dotimes, loop ...), more functional approaches like sml are very tempting, for the small size of their core in which you define all other patterns. I'd love to see a blend of lisp and ml (racket maybe?).
I find it very strange that you've thrown LOOP in there. It may not be as sexy as canned functional algorithms or simple recursion, but for complex algorithms, it's an absolute joy to use.
I couldn't count the number of times I've been writing C or C++ and wished I could express an idea more complex than "Initialize some variables (which may or may not be of the same type (but not of arbitrary different types)); run while this is true; do this thing after every iteration" without just slapping everything into and in the immediate vicinity of a while-true block. I don't have that problem with LOOP.
No, faced with the fact that CLOS is also verbose, although in a language that is all about closures, you started to present workarounds how to simplify its verbosity.
CLOS is verbose if all you're doing is encapsulating some state. If, on the other hand, you plan on doing anything remotely interesting, it's very succinct and expressive. Trying to emulate the functionality of CLOS' multiple dispatch and mixins in Java or C++ is hell beyond hell.
As for verbosity, I'll take ":accessor foo" over methods "getFoo" and "setFoo" with inane, useless autogenerated comments any day of the week.
I don't find CLOS verbose. Private slots by default, accessors as option ... I find LISPs quite succint in general, sure lots of parens, but usually the bare minimum of information is required. This contrasts with the large amount of useless code you can see in Java class definition that amount to nothing (setting fields, toString, manual get/set).
If you think those features change anything then you must have a poor understanding of FP or why people are moving to Scala/Clojure. It is a fundamentally different way of developing code that is starting to look really appealing to the enterprise.
The iterative development with a REPL approach deployed with micro services lends itself well to Agile development where big bang architecture simply doesn't work.
The secret of Scala is that it can be used in a wide variety of ways by a wide variety of teams. Yes, you can end up hiring people that would rather work in Haskell, or those that hate the type system and would rather code in Clojure. I've seen people that attempted to make Scala look like Java, or even Javascript. My current team, working in Scala, has had plenty of people like that. But the fact that you can get too academic with Scala does not mean you have to.
Some parts of our codebase really work better with said academic style, so we keep them. In others, the type system was used in ways that did not make any sense, and were rewritten.
Scala's strength is precisely that it can look like anything you want. If you are not interested in said freedom, then sure, avoid Scala at work. But for us, using the style that works better in each part of the system without actually having to change languages is extremely powerful.
I think D has a completely different of issues starting by a) small community b) reference compiler is not fully free software c) free compiler (ldc) is not finished d) very few people work on both compilers, etc.
IMHO, D is a better teaching language than Python and a better systems language than Java. I wish Android was written in D. I can't enjoy using a language with significant whitespace or extremely forced OOP.
The core language is good enough already, and better than most. They way it defines functional purity is the way it will be taught in universities in the future. It also embraces concurrency, and this will only become more important as computers get more processors.
What it lacks is libraries, therefore you are right about point a. The lack of a library like Ogre3D is an issue. The lack of an equivalent to jdbc for D is an issue. That's the reason for me to mention D here, the more exposure it gets, the better.
But about points b and c, no way. You deliberatedly ignore the third compiler GDC, which integrates the open source D front end with GCC and produces faster binaries than DMD.
GCD is still maintained basically by a single person, who replaced another person that basically stopped contributing and resulted the project stagnant for some years.
As the author of this post mentioned the culture of the Java developers, the "architect" thing and the frameworks, Scala has its own similar problems: it attracts a group of academics on type systems and creates over-engineering in a completely different direction.
Also, while I think Scala is simple at its core concepts and syntax, it gets complex because it has too many features and tries to support all features present in other programming languages. Why do you want structural typing there?.
> it gets complex because it has too many features and tries to support all features present in other programming languages
Which things do you have in mind?
> Why do you want structural typing there?
Isn't that a simplification? Instead of saying "here are types which you can use as e. g. parameter types, and here are types which you can't use (like in Java)", it says "all types work the same way".
Eh what? No. I couldn't care less about structural types.
I care about simple, consistent rules. "X is a type, you can use it wherever you want" is one.
"X is a type, but there is also Y, which you can't really express in position A and B unlike X, but can only use it if you carefully avoid doing things #1 to #4" isn't one.
I don't think it helps for consistency when you have to ask yourself why some functionality is defined in terms of a trait if it could be defined in terms of the structural type and just providing the methods would be sufficient.
Extension methods have mostly the same drawbacks as implicits, but none of the advantages.
It's not like Scala developers didn't know extension methods before designing implicits.
Instead, they tried to come up with a more useful, principled way, which also covers a lot of the stuff which is hardcoded and implemented ad-hoc in other languages (like implicit conversions in Java).
In the end, I think they made the right call:
- Implicit parameters are the basis for abstractions which unify the "strategy pattern" of OO languages with FP's typeclasses,
- implicit classes provide extension methods, but are better in pretty much every regard (higher reusability, less error prone) and
- implicit conversions cover the ad-hoc conversions everyone takes for granted, without having to hard-code these hacks into the language (e. g. don't like Java's/C#'s/... implicit convert-everything-to-String conversion? Don't import it in Scala).
I worked on Scala for two years seven or so years ago (2005-2007), and I'm not really worried about it (Scala is a great OOP language, and a soso FP language). Compared to Scala, Clojure has a minuscule user base (as one would expect for a Lisp).
Well there is an overwhelming trend towards Scala/Clojure both in the enterprise and for large internet sites. When companies like Twitter, LinkedIn, Foursquare, Netflix, eBay etc start embracing FP languages you can be sure the rest of the world takes notice.
My point was that serious companies are doing serious work with FP languages.
Scala isn't really functional, its more like a better Java that happens to include some FP abstractions (like C# does with Linq). Its actually a good OOP language, better than Java and even C#.
Clojure is a Lisp, its niche. There will always be some people around who want to program in a Lisp, and many of them are just choosing Clojure today. Nothing new really.
I'm a Clojure fan, and the syntax has nothing to do with it. The pervasive immutability, persistent data structures, ease of threading and STM mechanics are the good bits as far as I'm concerned.
The language could have a Python skin on it and still maintain much of what makes it pleasant to work in. I'd probably even prefer it.
Furthermore, the reaction to Clojure by the lisp community in general seems to be quite negative, like it's some inferior lisp that doesn't even have things like reader macros, and it makes no sense why it's getting traction when CL never did.
Which is all to say, I think the answer to what makes Clojure compelling is actually quite nuanced, and you're painting over it with a broad brush. Maybe with the wrong color.
It's unfair to call Scala 'not really functional'. Although I agree it allows for very rich OO programming, dismissing it as merely adopting "some FP abstractions" and comparing it to LINQ is bordering on FUD. To substantiate these claims, you have to at least give an example in which Scala falls short in being a functional programming language.
Interestingly, Scala's combination of OO and FP has given it (besides a lot of mockery and criticism) the title of a "postfunctional language".
Btw: I don't mean to pick on you, but you are talking a lot in absolutes on things I happen to disagree with in this thread.
Compared to the real functional languages (Haskell), the only reason I can think of that scala is called a functional language is because the community would be insecure in their smugness otherwise. You can totally use scala as a better java dipping into FP occasionally as you would in C#. It's not like say F#, which really forces you into a functional mindset.
Post functional is as vacuous as post modern, ultimately these labels are not meaningful.
Many things considered the domain of "functional" languages these days, like typeclasses and higher-kinded types are supported in Scala.
Saying that Scala is 'not really functional' is more or less denying OCaml, F#, SML (in fact, pretty much every language except Haskell, Idris, ...) the status of a functional language.
F# at least pushes you into a functional style; its support for classes is just interop; this is as opposed to Scala, which really innovates on Java OO. OCaml is specifically OO (hence the O in the name), though with lots of functional features. SML and Scheme...are SML and Scheme. They don't fit nicely into OO or FP buckets.
Would you consider C# to be a functional language? It has lazy streams, generators, and good support for list comprehensions? Or is it just an OO language with functional features?
If you consider a language to be more functional, because it forces you to use functional approaches even where it produces an inferior solution, then F# will certainly win this comparison.
Just have a look at F#'s higher-order functions for collections to see what I mean.
I consider a language "functional" if it allows me to write good functional code. Scala supports that by enabling me to choose good object-oriented code instead of bad functional code where it makes sense. (There a certainly other approaches to enable good functional code.)
I wouldn't consider C# functional, because it lacks purity, higher-kinded types, useful type inference, first-class functions, good support for immutability, dependent types and typeclasses.
(Note that I'm not saying that functional language need to support all of this. But a language which supports none of those items: I think we can make a clear call in that case.)
The point is that I can use Scala as an OOPL without ever dabbling very much in functional programming (beyond as much as I do in C#). I can't, however, do that with F#, and believe me...I really want a Scala-like language for .NET so I can move on from C#.
> I wouldn't consider C# functional, because it lacks purity, higher-kinded types, useful type inference, first-class functions, good support for immutability, dependent types and typeclasses.
C# has first class functions and has had them for a long time. C# also has real value types via structs, allowing more efficiency with FP styles, better than what Scala can provide on the JVM. Generics in C# are also reified, vs. erasure in Scala, so your run-time and static type system is the same.
Scala has better local type inference than C# (though non-determinstic...), but lacks global type inference like ML, Haskell. Scala also doesn't support general dependent types, settling for a much weaker (must still useful) path dependency. Path dependency is a very OO friendly feature, and in fact really amplifies OOP in general; whereas for FP, path dependency's benefits is limited to records.
> I really want a Scala-like language for .NET so I can move on from C#.
You can't have one because:
> Generics in C# are also reified, vs. erasure in Scala
The fact that this is true of C# vs. Java -- or perhaps more critically .NET vs. the JVM -- is why you can't have a Scala-like language on .NET (its specifically why you don't have Scala itself on .NET, which was a thing, but foundered on this problem.) Reified generics on a platform are great so long as all your (statically-typed) languages have type system just like the one assumed for the platform, but they ruin the interop story for any other type system, and a Scala-like language without a good interop story with the rest of the ecosystem would be pointless.
> The point is that I can use Scala as an OOPL without ever dabbling very much in functional programming (beyond as much as I do in C#).
So a language is automatically not functional, because other supported paradigms in that language don't suck?
So if OO in OCaml, F# wouldn't suck, they wouldn't be functional either?
> C# has first class functions and has had them for a long time.
I'd say C#'s functions are slightly better than Java's. The distinction between Action and Func is a terrible hack, and both of them are just a thin syntactic layer over delegates. Is that really first-class? They don't even provide function composition in the standard library.
> Generics in C# are also reified, vs. erasure in Scala, so your run-time and static type system is the same.
Bad luck for F#, I guess. Just ask them how much fun it is having to support two different kinds of Generics.
> Scala has [...]
As mentioned, that list wasn't a claim that Scala supports all of them (I think not even Haskell gets all the points).
They just aren't architected the same way. Instead of a monolithic WAR you end up with a series of micro services. FP is actually more suited than OO for micro services since it naturally forces developers down the "do one thing well" approach.
So I would stop with the "OO is what real people use" nonsense if I were you. Because languages like Scala and Clojure are rapidly taking over from Java in the enterprise space and you may find yourself on the wrong side of history.