Slashdot Mirror

Functional Languages are really cool in theory. However I find that for Real World development. Your code is often too tight for proper maintenance. Where Procedural and OOP is much better at fixing issues.

That's not the experience we had at Ericsson.

I can't help but think that you haven't really been involved in designing, building, fielding, and maintaining large systems based on FP. I have. With Erlang in particular we saw a four to ten fold increase in productivity.

And "too dense to fix" didn't even show up on the radar as a problem. Not by a long shot. Quite the opposite in fact, not having to wade through page after page of boiler plate (that could still trip you up, mind you) does wonders for focusing the mind on what the real problem actually was. As a colleague of mine was fond of putting it "After a day with Erlang I feel like I've solved business/domain problems, rather than 'doing programming'.

And good/competent, to half decent programmers could be retrained in a matter of days. The ones that couldn't, we didn't want anyway. And you shouldn't either.

I don't agree, however, that functional programming is an improvement. Functional programming is a migraine. In my experience, it usually causes things that are relatively trivial in procedural programming to turn into mounds of code. Everything that's bad about OOP is also bad about FP, just in different ways.

That's not necessarily true in practice. And I've seen it for myself.

But, and that's a big "but". It's been my observation that functional programming isn't "comfy" the same way that procedural programming is. With procedural languages you get to feel all warm and fuzzy inside when you've solved little problems and hurdles that the paradigm put in your way in the first place, and it feels like you've accomplished something, when you haven't actually move all that much closer to your end objective. With functional programming the easy stuff is so easy that's its over in five minutes and you very soon is exposed to either real computer science problems or the actual problem you're there to solve. There's no twiddling your thumbs while feeling and looking productive.

It's been my experience that its this effect that makes students and beginners feel like its hard, while in actual (measured) fact, it's easier and leads farther, sooner. But of course the flip side is that it weeds out poor programmers sooner, as they can only survive by only twiddling your thumbs.

P.S. And note that functional programs as measured at Ericsson tends to be equally shorter. I.e. four to ten times, for the same functionality delivered (with much better non-functionals, i.e. dependency, resilience etc.). And easier to read/maintain as well.

P.P.S. And also note that Ericsson isn't a zealot about it. There's plenty of e.g. 'C' etc. used as well. No-one is suggesting you should write a device driver in Erlang. But it's delegated to specialist tasks, as a small piece of the larger puzzle and an edge node in the architechture where it can shine, not a complex and centralised part, where it's the wrong tool for the job.

...is how Erlang started.

"Rough around the edges" is fine if you have a paradigm-shifting product. :)

http://www.erlang.se/publications/bjarnelic.pdf

MOST of the problems I've come across have been people not thinking about error conditions.. they think A = B-C but don't bother to check that B or C is a value that can be used with -. you might see them check one usable value or think that the class with handle it - but they don't honestly think about it. Yes always consider inputs as bad until proven other wise but too many people think that it only applies to user inputs ..

This philosophy leads to awful code. Yes, it is perfectly reasonable for a program core function that performs B-C to assume that B and C are valid values. This doesn't mean that programs should not take care about data integrity, but rather that data integrity checks should be segregated from problem-solving code in order to make the program easier to maintain. Otherwise, you end up with your complex computation functions being riddled with data integrity checks right in the middle, making all sorts of insanse assumptions about what should be done with invalid data. This makes the complex computational code not only harder to read, but also provides an incentive to writing that code badly.

My most hated example is folks who write functions that, upon reaching a demonstrably bad state from which the computation can no longer recover, instead of throwing an exception do something stupid and irresposible like returning 0, null, empty string, empty list or whatever to the caller, who then runs with it and then either gets an error or produces a wrong answer. Writing "defensive" code in the way you advocate basically empowers people to write code like that, since they get to assume that it's the caller's responsibility to verify that the function's output is valid.

So, the general architecture should be:

1. Front-end code that validates that the user inputs are within the valid range;
2. Internal code that assumes that input data is valid at all steps, and fails immediately if it would produce an invalid output.

See the Erlang Programming Rules and Conventions for some versions of these principles--in particular, aon't make assumptions about what the caller will do with the results of a function and do not program "defensively".

MOST of the problems I've come across have been people not thinking about error conditions.. they think A = B-C but don't bother to check that B or C is a value that can be used with -. you might see them check one usable value or think that the class with handle it - but they don't honestly think about it. Yes always consider inputs as bad until proven other wise but too many people think that it only applies to user inputs ..

This philosophy leads to awful code. Yes, it is perfectly reasonable for a program core function that performs B-C to assume that B and C are valid values. This doesn't mean that programs should not take care about data integrity, but rather that data integrity checks should be segregated from problem-solving code in order to make the program easier to maintain. Otherwise, you end up with your complex computation functions being riddled with data integrity checks right in the middle, making all sorts of insanse assumptions about what should be done with invalid data. This makes the complex computational code not only harder to read, but also provides an incentive to writing that code badly.

My most hated example is folks who write functions that, upon reaching a demonstrably bad state from which the computation can no longer recover, instead of throwing an exception do something stupid and irresposible like returning 0, null, empty string, empty list or whatever to the caller, who then runs with it and then either gets an error or produces a wrong answer. Writing "defensive" code in the way you advocate basically empowers people to write code like that, since they get to assume that it's the caller's responsibility to verify that the function's output is valid.

So, the general architecture should be:

1. Front-end code that validates that the user inputs are within the valid range;
2. Internal code that assumes that input data is valid at all steps, and fails immediately if it would produce an invalid output.

See the Erlang Programming Rules and Conventions for some versions of these principles--in particular, aon't make assumptions about what the caller will do with the results of a function and do not program "defensively".

MOST of the problems I've come across have been people not thinking about error conditions.. they think A = B-C but don't bother to check that B or C is a value that can be used with -. you might see them check one usable value or think that the class with handle it - but they don't honestly think about it. Yes always consider inputs as bad until proven other wise but too many people think that it only applies to user inputs ..

This philosophy leads to awful code. Yes, it is perfectly reasonable for a program core function that performs B-C to assume that B and C are valid values. This doesn't mean that programs should not take care about data integrity, but rather that data integrity checks should be segregated from problem-solving code in order to make the program easier to maintain. Otherwise, you end up with your complex computation functions being riddled with data integrity checks right in the middle, making all sorts of insanse assumptions about what should be done with invalid data. This makes the complex computational code not only harder to read, but also provides an incentive to writing that code badly.

My most hated example is folks who write functions that, upon reaching a demonstrably bad state from which the computation can no longer recover, instead of throwing an exception do something stupid and irresposible like returning 0, null, empty string, empty list or whatever to the caller, who then runs with it and then either gets an error or produces a wrong answer. Writing "defensive" code in the way you advocate basically empowers people to write code like that, since they get to assume that it's the caller's responsibility to verify that the function's output is valid.

So, the general architecture should be:

1. Front-end code that validates that the user inputs are within the valid range;
2. Internal code that assumes that input data is valid at all steps, and fails immediately if it would produce an invalid output.

See the Erlang Programming Rules and Conventions for some versions of these principles--in particular, aon't make assumptions about what the caller will do with the results of a function and do not program "defensively".

Most studies show that this is blatantly untrue -- programmer productivity is generally independent of language chosen.

Excuse me? Which studies?

Certainly not this one:

http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpp rt_computer2000.pdf

Nor this one:

http://www.erlang.se/publications/Ulf_Wiger.pdf

Nor even this one:

http://www.theadvisors.com/langcomparison.htm

And this well-regarded programmer certainly doesn't agree that the choice of language doesn't matter:

http://www.mindview.net/WebLog/log-0025

I tell you what -- interview a group of experienced programmers for a prospective project to write a database-backed web application with complex requirements. Tell them that they will be required to program in assembly language because "most studies show that... programmer productivity is generally independent of language chosen." Record their responses and post them to Slashdot.

You may want to take a look at Erlang before getting started on the project. Erlang is a functional programming language that already addresses fault-tolerance, modularity, distributed computing, and other problems you may need to solve. Even if you don't end up using Erlang, you could probably pick up some good design ideas from the (excellent) documentation.

Erlang does provide several mechanisms for interfacing with C code. If you wanted you could use Erlang at a system level, and C++ at a lower level where performance and interoperability with existing code is important.

What, praytell, is the difference between a functional language like Haskell and a well-designed C++ template library?

Referential transparency.
That comp.lang.functional thread is interesting because there are guys from Ericsson elaborating on some real-world aspects of referential transparency. As you know, Ericsson uses the funtional programming language Erlang for their switches. See more in: Welcome to a Smarter Way of Programming. Of course, you can't take their use of Erlang seriously, because they're from Sweden, and Sweden, being a fucked-up third-world country with no tech at all, is not an example for America. The mighty AT&T pushed C++, and now the world is better, safer place, where software errors are a thing of the past.

> If you don't understand C++, you are only liable to reinvent it. Badly.

Isn't the saying that you will reinvent Lisp, badly? Greenspun's Rule/Law? ;-)

This example is of an accumulator generator snagged from Paul Graham's website: http://www.paulgraham.com/accgen.html. Tailored to a problem that functional languages can solve more easily, but it is still interesting.

I would also recommend: For a Java/C++vs. Lisp comparison.

And for another programmers take on it where he tries the same thing: C++ hackers take

Also see another PG article: Succinctness is Power If you google for succinctness PGs article is the first result amusingly enough.

And here is a pretty famous study done on Erlang: Erlang Study

I hope we can at least agree that not all languages are created equal. I am honestly not interested in cloning or working in a langauge like C++. I am much more interested in languages like Lisp. I also freely admit that my OO experience leans heavily on Java, Lisp, and Ruby coding. And that I have little real C++ experience. I have done *basic* OO in my C++ programs. I used the STL for a couple of REALLY simple things in one of my later C++ programs but that is really about it. I try to use C++ in its more modern and usable context when I use it, but it is quite a time investment and I am really only after performance if I am using C++ so I keep it as lean and mean as possible and end up with C using objects with new and delete and a smattering of STL when it saves me time and I can easily do it without adversely affect the outcome of my program. So I base a lot of these assumptions on: a lot of C programming, a lot of OO programming, and a little C++ programming.

You might be onto something about the semantics of OO programming compared to the syntax of the language. It is relatively unimportant as long as the Syntax does not get in the way.

As for specific types of programs: Web development, simple and relatively complicated desktop applications. Pretty much anything that is not processor bound. I am being vague because I really do believe it in a very general sense. I do a lot of web development.. so in my world I am a little IO bound by network latency. You have to work around big warts like HTTP being stateless and generally you really want to maintain state. I also develop the occasional desktop application (Windows stuff ...Sigh). For Windows programs you really do need to use as little memory as you want, but you can still get away with using .NET which runs in a VM and is GCd. I really do focus on web development and network programming, though. I have written all sorts of programs such as search and data indexing stuff. It is still fast enough with hundreds of megabytes of data and it isn't C++.

So in my IO bound world I use the most productive and powerful languages I can convince my team to use without secretly wanting to murder me. There is a bigger learning curve for C++. And to be honest I am not concerned about average programmers. I only want people working for/with me that can wrap their head around any programming language even assembly. So ideally I only want to work with people that can use C++ and be good at it. Only I don't want to use C++ because I think the learning curve is not needed. That said is there REALLY a reason for every programmer to understand pointers? Is it really required. We are coming to an age where entire generations of programmers are raised on Java and GCd languages. I wasn't, but I know quite a few programmers who were/are. Do you really have to know assembly on up? Is that important for every programmer to know? You can't even talk to modern x86 processors directly these

Even the bluetooth part is not really that new. There was a company which had similar products back in 2002. They had even set up such a system in the Danish Parilament. More details here

I keep seeing this assertion, but never any evidence. A functional programming is no more or less descriptive than C++.

Check out e.g. "Four-fold Increase in Productivity and Quality" (pdf link). Erlang is freely available. Regarding C++ vs. functional programming being 'less descriptive' there's Haskell vs. Ada vs. C++ vs. Awk vs. ..., An Experiment in Software Prototyping Productivity(PS link). Now that doesn't directly address your question about what the compiler can do, there's about a metric ton of stuff about the higher level optimisations you can do with a declarative language compared to a messy one such as C++; riddled with aliasing problems etc. I haven't got any links handy, but some googling should turn them up (you could start by checking out Urban Boquist's, now quite old, PhD thesis). Plese note though that the Erlang references demonstrate that even while they may be slower on micro benchmarks, they always win in the end. Much like C beat out assembler in the eighties.

Your argument basically boils down to "the languages under discussion are all turing complete". While that's true, that's not really what we're saying. We're saying that given a declarative language the potential (and nowadays practice) for optimisation is much improved compared to e.g. Fortran or C.

Really? Which functional language has macros?

Template Haskell is an extension to Haskell 98 that allows you to do type-safe compile-time meta-programming, with Haskell both as the manipulating language and the language being manipulated.

Intuitively Template Haskell provides new language features that allow us to convert back and forth between concrete syntax, i.e. what you would type when you write normal Haskell code, and abstract syntax trees. These abstract syntax trees are represented using Haskell datatypes and, at compile time, they can be manipulated by Haskell code. This allows you to reify (convert from concrete syntax to an abstract syntax tree) some code, transform it and splice it back in (convert back again), or even to produce completely new code and splice that in, while the compiler is compiling your module.

Which functional language lets you redefine stuff in a running image?

12.3 Code Replacement

Erlang supports change of code in a running system. Code replacement is done on module level.

The code of a module can exist in two variants in a system: current and old. When a module is loaded into the system for the first time, the code becomes 'current'. If then a new instance of the module is loaded, the code of the previous instance becomes 'old' and the new instance becomes 'current'.

Both old and current code is valid, and may be evaluated concurrently. Fully qualified function calls always refer to current code. Old code may still be evaluated because of processes lingering in the old code...

What about Erlang and Ericsson?

If concurrency and running your software on multiple hosts in parallel are very important and you don't mind picking up another language, you could try Erlang. Recent conference proceedings can be found here and here.

You don't even have to write your code in Erlang. You could wrap C code with a wrapper which uses sockets to communicate with the rest of the Erlang environment. Erlang runs on *nix, Windows, BSD, VxWorks and Mac OS X.

If concurrency and running your software on multiple hosts in parallel are very important and you don't mind picking up another language, you could try Erlang. Recent conference proceedings can be found here and here.

You don't even have to write your code in Erlang. You could wrap C code with a wrapper which uses sockets to communicate with the rest of the Erlang environment. Erlang runs on *nix, Windows, BSD, VxWorks and Mac OS X.

Yet another language where it's possible to do high speed development is Erlang (and here ). (The sites seem to be down temporarily. Is the Slashdot effect that that powerful ?) It's the kind of stuff that you can use to quickly put together a working prototype - ideal for testing "proof of concept". The language + support libs also support distributed applications. So, if your prototype is good, you can try scaling it to multiple CPUs with minimum effort. Don't be fooled by the "telecom" tag that the language comes with - there's more to it than meets the eye.

The trouble is, that functional languages, while they may be more powerful, are much harder to write well in, generally taking you far longer to get to the finished state you want.

But don't take my word for it:

• Prototyping Real-Time Vision Systems: An Experiment in DSL Design (1998) Abstract: We describe the transformation of XVision, a large library of C++ code for real-time vision processing, into FVision (pronounced "fission"), a fully-featured domain-specific language embedded in Haskell. The resulting prototype system substantiates the claims of increased modularity, effective code reuse, and rapid prototyping that characterize the DSL approach to system design....
• Four-fold Increase in Productivity and Quality: Industrial-Strength Functional Programming in Telecom-Class Products (PDF) Abstract: The AXD 301 ATM Switch is the flagship in Ericsson's line of Datacom products. A fault tolerant and highly scalable backbone ATM switch, AXD 301 has enabled Ericsson to take the lead in the migration of public telephony networks to becoming true multiservice networks, offering both quality voice and broadband data services on the same backbone.... This paper demonstrates how the development of such systems is supported by the Erlang/OTP technology. The Erlang [functional] programming language was developed by Ericsson specifically for the purpose of building fault tolerant, distributed and complex systems.... The paper demonstrates how Erlang supports the characteristics mentioned, while offering unusually high productivity.
• Haskell vs. Ada vs. C++ vs. Awk vs. ... : An Experiment in Software Prototyping Productivity: Abstract: We describe the results of an experiment in which several conventional programming languages, together with the functional language Haskell, were used to prototype a Naval Surface Warfare Center (NSWC) requirement for a Geometric Region Server. The resulting programs and development metrics were reviewed by a committee chosen by the Navy. The results indicate that the Haskell prototype took significantly less time to develop and was considerably more concise and easier to understand than the corresponding prototypes written in several different imperative languages, including Ada and C++.
• Functional languages in microcode compilers (ACM Digital Library). Abstract: This paper discusses the advantages of using high-level languages in the development of microcode. It also describes reasons functional programming languages should be considered as the source language for microcode compilers. The emergence of parallel execution in microarchitectures dictates that parallelism must be extracted from the microcode programs. This paper shows how functional languages meet the needs of microprogrammers by allowing them to express their algorithms in natural ways while allowing the microcode compiler to extract the parallelism from the program.

It's called Mnesia: Mnesia

Also Visit Erlang

It's not necessarily SQL based.

But Ericsson doesn't want to be out there on its own as regards using functional languages. Therefore Ericsson has released the whole of the Erlang system as Open Source. For those who like such things, commercial support is also available.

So why haven't Functional Languages caught on? Someone once said "perception is reality", and peoples' perception of functional programming is that it is something you learn at school because it is good for you, like learning Latin. Then you forget all about it and use C++ or Java like everybody else. Popular perceptions are:

• FP is hard to learn and requires a PhD in mathematics
  This may be true for some functional languages, but Erlang is trivially easy to learn.
• FP are very inefficient
  Not true any longer. True the rely on recursion and other techniques which used to be inefficient - but implementation using tail recursion of last call optimization makes recursion is just as fast as normal iteration.
• You can't hire programmers who know FP
  Firstly if a programmer can't learned to be productive in a language like Erlang within a week, then they aren't worth hiring. Secondly, the number of people who are learning Scheme, ML etc at school is increasing day by day.
• You can't buy tools for FP
  And what's wrong with emacs then? If you are one of these people who like writing programs by clicking in funny boxes, then FP's aren't for you. But for the rest of us, functional programs are much closer to specifications than those funny boxes. Erlang, for example has a rich set of tools like debuggers available free.
• There aren't any libraries
  Wrong, yes there are. Have a look at the Erlang open source web and you will be amazed.
• Learning FP won't enhance my career prospects
  Unfortunately, probably true.

Erlang is open source. The functional programming community generally agrees that it is an excellent language for this sort of thing. Not all of the world is C.