"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.

Search This Blog

Friday, March 14, 2008

Erlang Criticism Not Unwarranted

Eric's post on the recent Erlang criticism and his take on the subsequent trail of mail list discussions is fairly accurate in my opinion. I posted a long response on his blog and midway realized it's a blog post of its own. Here.

I'm not going to argue too strongly for "sequential Erlang" because it's really "concurrent Erlang" that stands out. The Erlang syntax is ok by me, but then I still prefer Lisp syntax to anything else I've seen anywhere. Simple.

And I can say nothing for the erlang list, except I've been skimming it too, with not so different reactions as yours.

Anyway...

"in development, the behavior of that existing function often changes thereby affecting all the calling functions"
As with all dynamic languages (especially those unlike Lisp and Smalltalk that do no have good refactoring editors), you need good unit test coverage. Which you are doing, right?
"defining dozens of one-line functions has made flow control difficult to follow in some circumstances."
This is pretty much the same for all functional languages, and even Smalltalk, which tends to have many small methods, where other OO language programmers tend to write overlong methods.

Good tools, which again Lisp and Smalltalk tend to have, and others don't, are indispensable. Otherwise the only thing that tends to help IMHE are again many good tests to read, "Oh, so this is the thing to call, and how to call it."

I still think that's better than really long methods Java or other languages that tend not to be reusable without a good deal of pain. (For one thing, they tend not to be really well tested.)

"It shouldn't take a committee to help you write good file handling code."
I don't disagree completely except that Wide Finder pushed Erlang and its community into a new I/O situation. So most of what happened by the end of it was a core Erlang member adding some new core capabilities to the language. Then also what happened was the exposure of a development process for how to evolve concurrent algorithms generally in Erlang or maybe any concurrent system. I would think both, especially the new core I/O capabilities, will help down the road without requirement the full committee.
"the language is a DSL for networking gear."
Which essentially what it is. CouchDB, Yaws, ErlyWeb, etc. will help, but mostly Erlang and its surrounding code is not much more than what the telecom programmers were using in the mid-1990's. that is its upside and its downside.
"I can write a Scala function to make an HTTP POST in four lines of code and have it run screamingly fast"
Two points:
  • Yeah, *but* then you also have to deal with all of Scala's type system. "Oh, you need an existential type here because a mere parameterized type gets the type system all confused, even though it's fairly obvious what you are trying to do."
  • Yeah, *and* what the rest of the world should learn from Erlang is "concurrent Erlang" and how to apply *those* lessons in a distributed, multi-language way. You shouldn't need to use Erlang to get the benefits of things like OTP. OTP and basic message passing with pattern matching is missing from pretty much every system but Erlang. Scala and Java do not have an OTP although Scala addresses the latter.
(And now you see why I thought so highly of Jini and Javaspaces, because it also attempts to bring these to Java. It's the closest thing Java has to Erlang/OTP. But now, where did that go again? Dang it.)

Like you wrote...

"actors are so important, it will be amazing when the programming public realizes why we all need to do this"
You could also try Gambit Scheme, which I think is better as a sequential language (Lisp) but also has pretty much Erlang-scale thread/mailbox performance on a single CPU. Not much in the way of distributed or multi-core support yet. You get more of those, "shared nothing" threads, and functional data structures if you use the Termite package on top of Gambit. Multi-core is bubbling to the top of Gambit now that a decent package system has been released.

8 comments:

Christophe Grand said...

Patrick, did you check Clojure?

A lisp on the JVM with functional data structures, lazy lists, STM and agents. Its concurrency support targets multicores.

Patrick Logan said...

No. The name sounds familiar but I'll have to take a look. Thanks

GM said...

defining dozens of one-line functions has made flow control difficult to follow in some circumstances.

This is pretty much the same for all functional languages.


No it's not. Pure functional languages don't even really have flow-of-control in the usual sense. Flow of control can be more difficult to follow in Erlang because functions that call each other aren't necessarily near each other in the code, the one-process-one-file restriction is to blame here.

Owen Taylor said...

In reference to: "(And now you see why I thought so highly of Jini and Javaspaces, because it also attempts to bring these to Java. It's the closest thing Java has to Erlang/OTP. But now, where did that go again? Dang it.)"

Jini and JavaSpaces are alive and well, acting as the backbone for major financial, telco, national security, logistics, and gaming applications throughout the world. Check out http://www.openspaces.org to see some of the latest javaspace-related initiatives.
Cheers,
Owen Taylor (I work for GigaSpaces) : )

Anonymous said...

I think Clojure has a different approach than Erlang. Clojures support for concurrency is based on software transactional memory (processes DO share state) whereas Erlang uses message passing/no shared state.
I didn't find in Clojure features for distributed programming, this is where Erlang is really good at.

Patrick Logan said...

"Pure functional languages don't even really have flow-of-control in the usual sense."

Well, good functional programs and good semi-functional programs tend to be composed of many, small functions. For non-pure languages, many of these are actually imperative procedures, true, and that has pro's and con's.

On the other hand the more modern functional languages have monads or linear types or some mechanism that introduces imperative actions and flow. Even if these are more "neat" and less ad hoc, the actual programs can still become more challenging to follow. At least to someone like me who does not develop in that way every day, they appear to be much like the programs I write in semi-functional languages.

Patrick Logan said...

"Clojure has a different approach than Erlang"

Yeah, I was hoping Clojure would have message passing, and pattern matching, even within a JVM. But it is mostly functional, and shared-nothing to the extent a programmer chooses for specific agents.

Message passing and distributed systems would have to be implemented using Clojure and other mechanisms.

And I'm still not sure how I feel about transactional memory -- but I'm looking forward to investigating a bit in Clojure. As with Haskell, STM seems to make more sense with a (mostly) functional language. But...

Anonymous said...

All Erlang techniques for esafe-programming (FSM, "and-or" trees for control-flow, "let it crash") are available in other languages and had been used for many years ago. Async. threads + networking is available for manu languages as libraries (Tcl, Python, C, Java...). Distributive programming is available as STANDARDS and frameworks (libs) for all languages too. So WHY is need NEW language?

For distributive programming in C were created several languages similar to C and several libraries. But programmers prefers libs., not languages.

Erlang is good because of it's "all-in-one"... for newbies. But mature programmers can use all of enumerated above in own language environment (C, Java, Python...) without Erlang-language.

Blog Archive

About Me

Portland, Oregon, United States
I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.