Eighteen months ago, Audrey was looking for something challenging and started writing pugs in Haskell. After the first three weeks, were nearly every day brought a blog post like "Today was the most productive day of the pugs project ever! I doubled the number of features again!", lots of people started to notice. Not only notice Audrey and pugs, but also Haskell.
I noticed. Which is why when I was presented a project (for a previous employer) around the same time, for a parser with an unknown set of requirements and constraints, Haskell sounded like the way to go. Indeed, it was; once I got my bearings, my ability to modify the code outstripped the ability of managers to add/change/contradict requirements. In fact, it was not uncommon to spend 1-2 hours in a meeting with 3-8 people discussing a feature that took ~15 minutes to revise/implement.
Fast forward to last week, when I presented a tutorial at OSCon entitled Introduction to Haskell. Based on the feedback from attendees, it went over pretty well.
Fast forward to today, when Joel Spolsky writes about basic functional programming practices, using JavaScript for his examples. (Nothing that you haven't seen already in Dominus' HOP. What you don't have a copy? Why not?)
At this rate*, by 2010 (2015 at the latest), all programming languages that aren't functional will be obsolete; the only kinds of jobs that will be open will be for functional programming, and the only kinds of people in the market will also be functional programmers.
Functional Programming. Not just for eggheads anymore.
*: This is the same logic that noticed a sustained annual 10x increase in Perl monger groups by early 1999, and predicted that there would be more Perl mongers groups than people on the planet by 2006/2007.
Joel alludes to this, but I wonder if part of the growth of functional languages will be that they're much easier to optimize for concurrency than languages with side effects.
Re:Concurrency
ziggy on 2006-08-02T02:42:37
I can't speak for Joel, but in my experience, a big reason why the wave is hitting now instead of 10 or 20 years ago, is because Moore's law has finally crossed some barrier that makes these languages workable.
Take ghc, for example. On my 4-year old G3, ghc 6.4.2 took about 14 hours to bootstrap. gcc, by comparsion might take as much as an hour or two to do a full 3-stage bootstrap (vs. ghc's 1.5/2 stages). Also, on a "simple" Haskell program, there is a noticable amount of time to compile (either to produce.o files or load into the interpreter). Nevertheless, that's a small price to pay to get high productivity and terse programs.
Another issue that there's an expectation that as languages evolve, we get ever increasing productivity. There's little more that object-oriented languages can offer; dynamic languages have a little steam left in them, but not a 2x increase.
One of the only avenues left to pursue is functional programming, which is why dynamic languages (Perl/Python/Ruby/JavaScript) are clinging to functional features a lot moreso than, say 5-8 years ago.
Re:Cool, thanks!
ziggy on 2006-08-02T13:33:02
As for concurrency, I know Erlang-like concurrency is perfect for declarative languages, you can get a similar thing (...) in Scheme (...)Actually, you can get exactly the same thing in Scheme. Just use Termite. (Probably not ready for prime time, but under actively development.)
any easy way to use hugs w/o emacs??Um, yeah. On the command line. But I use ghc[i].
Re:Cool, thanks!
excalibor on 2006-08-03T17:06:30
Ah, that's really interesting! (Termite) I'll check it out, thanks!
Of course, having the source on a window and the CLI with readline or a similar line-editor in another (or different screen, anyway) will be all that's needed... forgot to:load *grin*
thanks!!
PS- off to try and understand Pugs!
C was being used to write operating systems 33 years ago, and it's still going strong. There will always be a call for a language that lets you be somewhat platform-independent while still giving you the ability to get very close to the bare metal.
There is a place for functional programming--many places, as a matter of fact--but to claim that it's the right tool for every job is just silly.
Re:10 years is _way_ too optimistic
ziggy on 2006-08-02T20:13:40
You honestly think that in a mere 10 years, it will be impossible to get a job as a C programmer?Um, read the footnote again. That assertion is as valid (and as plausible) as the assertion that today, August 2006, the number of Perl Monger groups is very nearly the same as the number of people on the planet (+/- ~10%), and by this time next year, the number of Perl Monger groups will exceed the human population of the Earth by roughly 10x.
Re:10 years is _way_ too optimistic
chromatic on 2006-08-03T02:57:00
It doesn't seem too far off to me. Bare metal gets further and further from the PDP-11 every day.
10 years ago, people were still using turbo pascal
Julian Morrison on 2006-08-03T09:09:00
In 10 years time, if you're programming in C, it will be because you're programming a burglar alarm or a fridge. Possibly an operating system, although I suspect l4 style microkernels will have made inroads, and most OS code will be running in "user space" and might be written in Haskell.
However, a game, a word processor, a network daemon, you'd be writing in Haskell, Perl, or perhaps Java (but by then, Java will probably look very Haskelly, and Perl 6 already does).Re:10 years ago, people were still using turbo pas
ziggy on 2006-08-03T13:16:00
However, a game, a word processor, a network daemon, you'd be writing in Haskell, Perl, or perhaps Java (but by then, Java will probably look very Haskelly, and Perl 6 already does).I'm not so sure.
First, C will never completely die. Assembly language is still useful, even if it isn't used by 99.44% of programmers. But the idea of assembly language is still very useful, and still deserves to be one of many cornerstones of any good CS degree. And, periodically, the idea of assembly is useful when it resurfaces in, say, SQLite's internal opcodes, or pasm. C is useful because it is a convenient, portable, and "user friendly" form of assembly language.
The best proof against Java/Haskell/Perl being used for high performance, low latency projects is Microsoft's experience with C# and CLR. Sure, it's good enough for their customers to write line-of-business code, but it's not good enough for them to write their operating systems or office applications. (The CLR is missing a few important primitives for OS design, and the desktop apps are too important to turn into, well, OpenOffice.)
The key point to realize is that most projects aren't operating systems, network daemons, games or word processors. C, and to some extent Java (and Perl), are really poor languages for line-of-business development. So while 10 and 20 years ago, most software was written in C, Pascal, Fortran or Assembly, that's more a statement of the then-current state of the art, not the innate suitability of those languages for every domain.
When I say (with tounge firmly in cheek) that all non-functional languages will be obsolete in 5-10 years, it's an assertion that functional languages (or at least languages with functional features used in a semi-functional manner) will be where the focus is for most projects, especially green field development. There are four main classifications of languages (imperative, functional, object oriented and declarative), and each has their use. Functional languages will never be the one true way to write all code, nor should they be.
(Note that we're seeing that change today - look at ruby, rails and the heavy reliance on blocks.)
Re:10 years ago, people were still using turbo pas
chromatic on 2006-08-04T04:54:17
Your argument against C# would be stronger if Microsoft had demonstrated that it could actually write software anymore.
:)
