Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In every technical publication, and on this site too, people are always comparing OO languages to Smalltalk. My experience is in Java: is Smalltalk so important that I should study it?
Smalltalk was one of the earliest object-oriented (OO) languages (with others like Simula and Eiffel) and can be said to be extremely "pure" in an OO sense:
Everything is an object and objects are only communicated with via the sending of messages
No primitives (no ints, booleans etc)
No control structures (no for, while, if etc). Sounds impossible but it's true!
No statics
It also pioneered some other, now common, stuff:
the virtual machine (and JIT compilation)
Debugging by inspection
"Hotswapping" running code
the modern IDE
Closures
Duck typing
Model-View Controller (MVC) architecture for UIs
Test-driven development (TDD) and agile methodology
And there are other things connected with Smalltalk which didn't really make it into the mainstream:
"Image"-based system rather than file-based.
Object-oriented databases
And it's fair to say that the Java collections API and the apache-commons collections API are heavily influenced by Smalltalk.
I wouldn't say that you should learn Smalltalk per se, but a familiarity with the fundamentals of these features (now present in many other languages) is surely advantageous to you.
Note that there are currently only 123 questions on here about the language, which was originally intended as an educational language (i.e. aimed at children) by its creator, Alan Kay. It is not particularly heavily used anymore. That's not to say it isn't used. JPMorgan, for example, has a large exotic derivatives risk-management system written in it.
Smalltalk has many brilliant innovations - things we're all taking for granted today, including:
being the first ever IDE
providing programmatic support for a GUI with a mouse If you learn Smalltalk GUI programming, you really will have understood MVC properly.
being built out of a small number of powerful ideas that work together extremely well
The Smalltalk way isn't to crash out on unexpected behaviour - it's to adapt. If you send a message to an object that doesn't understand it, the debugger comes up and invites you to write that method... so it provides excellent support for incremental development.
The IDE, the app that you're writing and your data are all part of the same system - so you can write your own tools and debug instrumentation far more easily.
The TDD toolset in Smalltalk is still better than any other language (see below).
Squeak Smalltalk has quite a bit of cutting-edge design research:
the morphic UI - you can get familiar with the concept of "liveness"
the seaside web framework - learn what a continuation server is and how it's radically different
Squeak has a strong connection with the OLPC software (one laptop per child) project - and could yet have a big influence on the world.
Find out what a "trait" is...
Play with the radical 3D immersive environment called Open Croquet.
Because Smalltalk is a smaller, simpler and more consistent language, with it's own built-in environment it's a much less confusing place to start teaching OOP. People who go this route end up being better Java, Ruby and C# programmers because they can learn basic OOP without all the messy inconsistencies of mainstream languages.
Some commercial Smalltalks have amazing, multi-node distributed OO database environments. I'm thinking about Gemstone.
Want to know the difference between Model-View-Controller and Model-View-Presenter - look at Dolphin Smalltalk...
The single most important reason to learn Smalltalk today is that extreme programming and scrum both got invented in the Smalltalk community... and the highly interactive style of programming you experience in Smalltalk is simpler, more powerful and direct than anything you can do with Java or C# or Ruby... and you can't really understand how well agile methods can work until you've tried to do extreme programming in Smalltalk. Few other languages (no mainstream ones anyway) have a comparable feature set.
... to really understand what TDD can be you need to use SUnit. JUnit just shows you where your tests failed. SUnit actually allows you click into the debugger at the point where the test failed and see the actual objects and how they're connected so you can see, live in the debugger how the code failed and fix it right there.
Yes, Smalltalk is so important you should study it. Why? You can understand object-oriented programming in pure, simple form. What people forget is that the Smalltalk-80 "Blue Book" has only about 90 pages devoted to the language—the language is just that simple. The other 300 pages talk about the predefined class hierarchy, which is a masterpiece of design for a class-based, object-oriented language that uses single inheritance. You will get a much deeper understanding of objects (e.g., classes are objects, and they have metaclasses, and so on off to infinity... except the knot is carefully tied to keep the system finite) than you would ever get from studying a hybrid language like Java or C++. Smalltalk matters not just because of its history but because of its simplicity:
Simple enough so you can understand the entire language and the libraries
Shows one idea (objects are all you need) pushed to its logical extreme
Everybody has something to learn from Smalltalk!
Smalltalk is one of the first two original OOP languages, the other being Simula-67. Consequently, there are two large families - the statically typed model centered around method invocation, pioneered by Simula (C++, Java, C# all belong here), and the dynamically typed model centered around message passing, pioneered by Smalltalk (Python, Ruby belong here).
Today, Smalltalk isn't particularly important on its own - there are some people still using it to write stuff, but it's definitely not mainstream. Learning it will give you some insight in how and why OOP evolved, however.
I spent about 5 minutes in a presentation at a conference last month on Smalltalk's history and influence. See Image-based development with Smalltalk. One of the more foreign concepts to today's programmers is the "image-based" development. There are some good analogies, including a DBMS and a spreadsheet.
Yes. Download the seaside one-click image, start using it with the tutorial from James Foster and you will learn at least:
how web applications should be build
how debugging is supposed to work
I agree with the others. I'm not sure if it's important per se, but it is COOL (imho).
I love that there are no loops or conditionals in the language. If-then-else is a message sent to a boolean object. Objects of type True do one thing, objects of type False do another. (Yes, True and False are subtypes of Boolean, with a single value each, true and false respectively).
It starts out being kind of counter-intuitive, but it does give you a very interesting, and deep, view of how OO programming should work...
Not only was it one of the first, Smalltalk remains to this day a paragon of OO language design. The more popular languages that came later — C++, Java, even Objective-C — all have more primitive object-orientation and are more restrictive than good old Smalltalk. Smalltalk had pervasive first-class objects, great support for runtime introspection, very natural use of duck typing and closures that worked better than I've seen in any non-functional language. I mean, we're talking about a language that had no native control structures (if, while, etc.) but was able to create them out of its object system in a way that worked seamlessly. How cool is that?
I wouldn't recommend Smalltalk for any intensive desktop app development these days (there just isn't a viable implementation IMO), but if you want to see how OO was meant to be and maybe pick up some ideas you can use in your apps, Smalltalk is a great place to look.
If you only know one object-oriented language you should consider learning a second and a third and a fourth in order to gain a broader perspective on programming with objects. Learning Smalltalk will stretch your brain because a lot of the familiar concepts we're used to in other languages (e.g. if-then-else, for(;;), while(), etc) are not there in Smalltalk. There are equivalents, obviously, but Smalltalk does things differently, and learning about different ways to do things is always a good idea.
Good luck.
I've just started to revive my interest in Smalltalk, and in my opinion, there are a few compelling things that are special about Smalltalk:
Highly productive development
environment
Built-in support for Agile/Extreme
programming methodologies
"Pure" object model
Easy to use graphics framework
None of these make it especially useful for people who are not in the software development business. My first exposure to it was when I saw a user interface for an embedded device prototyped on a PC using Smalltalk. This allowed the user interface to be modified and tested very quickly, and when completed, provided the embedded developers an "executable specification" that was far more precise than any document. I'm surprised I haven't seen this technique used far more often than I've observed in my travels during the last 20 years.
Using Smalltalk as a prototyping tool is where my interest lies: I think that given a new problem, different approaches to solving it can be tried and validated very quickly and easily in a Smalltalk environment, and once the desired solution is found it should be relatively mechanical to convert it to Java/C++/C# etc. etc. In fact, for repetitive sorts of things, it might well be possible to use Smalltalk to generate code for parts of the solution in some other target language.
The other thing about SmallTalk is that its alumni include Kent Beck and Ward Cunningham. Their work with SmallTalk spawned automated xUnit testing, software design patterns, CRC Cards and other practices which ed into XP/Agile, etc. So it could be argued that SmallTalk has been a major contributor to the modern programming landscape.
Just two comments:
Smalltalk is not object "oriented", is real objects, only objects and messages in the environment.
Smalltalk is not a language, is an environment that has a language (of the same name), but most of the "magic" here is thanks to the environment (the image).
Related
I am working on a new language, targeted for web development, embeding into applications, distributed applications, high-reliability software (but this is for distant future).
Also, it's target to reduce development expenses in long term - more time to write safer code and less support later. And finally, it enforces many things that real teams have to enforce - like one crossplatform IDE, one codestyle, one web framework.
In short, the key syntax/language features are:
Open source, non-restrictive licensing. Surely crossplatform.
Tastes like C++ but simpler, Pythonic syntax with strict & static type checking. Easier to learn, no multiple inheritance and other things which nobody know anyway :-)
LLVM bytecode/compilation backend gives near-C speed.
Is has both garbage collection & explicit object destruction.
Real OS threads, native support of multicore computers. Multithreading is part of language, not a library.
Types have the same width on any platform. int(32), long(64) e.t.c
Built in post and preconditions, asserts, tiny unit tests. You write a method - you can write all these things in 1 place, so you have related things in one place. If you worry that your class sourcecode will be bloated with this - it's IDEs work to hide what you don't need now.
Java-like exception handling (i.e. you have to handle all exceptions)
I guess I'll leave web & cluster features for now...
What you think? Are there any existing similar languages which I missed?
To summarize: You language has no real selling points. It just does what a dozen other languages already did, with syntax and semantics just slightly off, depending on where the programmer comes from. This may be a good thing, as it makes the language easier to adapt, but you also have to convince people to trouble to switch. All this stuff has to be built and debugged and documented again, tools have to be programmed, people have to learn it and convince their pointy-haired bosses to use it, etc. "So it's language X with a few features from Y and nicer syntax? But it won't make my application's code 15% shorter and cleaner, it won't free me from boilerplate X, etc - and it won't work with my IDE." The last one is important. Tools matter. If there are no good tools for a language, few people will shy away, rightfully so.
And finally, it enforces many things that real teams have to enforce - like one crossplatform IDE, one codestyle, one web framework.
Sounds like a downside! How does the language "enforce one X"? How do you convince programmers this coding style is the one true style? Why shouldn't somebody go and replace the dog slow, hardly maintained, severly limited IDE you "enforce" with something better? How could one web framework possibly fit all applications? Programmers rarely like to be forced into X, and they are sometimes right.
Also, you language will have to talk to others. So you have ready-made standard solutions for multithreading and web development in mind? Maybe you should start with a FFI instead. Python can use extensions written in C or C++, use dynamic libraries through ctypes, and with Cython it's amazingly simple to wrap any given C library with a Python interface. Do you have any idea how many important libraries are written in C? Unless your language can use these, people can hardly get (real-world) stuff done with it. Just think of GUI. Most mayor GUI toolkits are C or C++. And Java has hundreds of libraries (the other JVM languages profit much from Java interop) for many many purposes.
Finally, on performance: LLVM can give you native code generation, which is a huge plus (performance-wise, but also because the result is standalone), but the LLVM optimizers are limited, too. Don't expect it to beat C. Especially not hand-tuned C compiled via icc on Intel CPUs ;)
"Are there any existing similar
languages which I missed?"
D? Compared to your features:
The compiler has a dual license - GPL and Artistic
See example code here.
LDC targets LLVM. Support for D version 2 is under development.
Built-in garbage collection or explicit memory management.
core.thread
Types
Unit tests / Pre and Post Contracts
try/catch/finally exception handling plus scope guarantees
Responding to a few of your points individually (I've omitted what I consider either unimportant or good):
targeted for web development
Most people use php. Not because it's the best language available, that's for sure.
embeding into applications
Lua.
distributed applications, high-reliability software (but this is for distant future).
Have you carefully studied Erlang, both its design and its reference implementation?
it enforces many things that real teams have to enforce - like one crossplatform IDE, one codestyle, one web framework.
If your language becomes successful, people will make other IDEs, other code styles, other web frameworks.
Multithreading is part of language, not a library.
Really good languages for multithreading forbid side effects inside threads. Yes, in practice that pretty much means Erlang only.
Types have the same width on any platform. int(32), long(64) e.t.c
Sigh... There's only one reasonable width for integers outside of machine-level languages like C: infinite.
Designing your own language will undoubtedly teach you someting. But designing a good language is like designing a good cryptosystem: lots of amateurs try, but it takes an expert to do it well.
I suggest you read some of Norman Ramsey's answers here on programming language design, starting with this thread.
Given your interest in distributed applications, knowing Erlang is a must. As for sequential programming, the minimum is one imperative language and one functional language (ideally both Lisp/Scheme and Haskell, but F# is a good start). I also recommend knowing at least one high-level language that doesn't have objects, just so you understand that not having objects can often make the programmer's life easier (because objects are complex).
As for what could drive other people to learn your language... Good tools/libraries/frameworks can't hurt (FORTRAN, php), and a big company setting the example can't hurt (Java, C#). Good design doesn't seem to be much of a factor (a ha-ha-only-serious joke has it that what makes a language successful is using {braces} to delimit blocks: C, C++, Java, C#, php)...
What you've given us is a list of features, with no coherent philosophy, or explanation as to how they will work together. None of the features are unique. At best, you're offering incremental improvements over what's already there. I'd expect there's already languages kicking around with what you've said, it's just that they're still fairly obscure, because they didn't make it.
Languages have inertia. People have to learn new languages, and sometimes new tools. They need incentive to do so, and 20% improvement in a few features doesn't cut it.
What you need, at a minimum, is a killer app and a form of elevator pitch. (The "elevator pitch" is what you tell the higher-ups about your project when you're in the elevator with them, in current US business parlance.) You need to have your language be obviously worth learning for some purpose, and you need to be able to tell people why it's worth learning before they think "just another language by somebody who wanted to write a language" and go away.
You need to form a language community. That community needs to have some localization at first: people who work in X big company, people who want to do Y, whatever. Decide on what that community is likely to be, and come up with one big reason to switch and some reasons to believe that your language can deliver what it promises.
No.
Every buzzword you have included in your feature list is an enormous amount of work to be spec'd, implemented, documented, and tested.
How many people will be actively developing the language? I guess the web is full of failed programming language projects. (Same is true for non-mainstream OSes)
Have a look at what .Net/Visual Studio or Java/Eclipse have accomplished. That's 1000s of years of specification, development, tests, documentation, feedback, bug fixes, service packs.
During my last job I heard about somebody who wrote his own programming framework, because it was "better". The resulting program code (both in the framework and in the applications) is certainly unmaintainable once the original programmer quits, or is "hit by a bus", as the saying goes.
As the list sounds like Java++ or Mono++, you'd probably be more successful in engaging in an existing project, even if it won't have your name tag on it.
Perhaps you missed one key term. Performance.
In any case, unless this new language has some really out-of-this-world features(ex: 100% increase in performance over other web development languages), I think it will be yet another fish in the pond.
Currently I'm responsible for maintaining a framework developed/owned by my company. It's a nightmare. Unless there is a mainstream community, working on this full time, it's really an elephant. I do not appreciate my company's decision to develop its own framework(because it's supposed to be "faster") day 'n night.
The language tastes good in my opinion, I don't want use java for a simple website but I would like to have types and things like that. ASP .NET is a problem because of licensing and I can't afford those licenses for a single website... Also features looks good
Remember a lot of operator overloading: I think is the biggest thing that PHP is actually missing. It allows classes to behave much more like basic types :)
When you have something to test I'll love to help you with it! Thanks
Well, if you have to reinvent the wheel, you can go for it :)
I am not going to give you any examples of languages or language features, but I will give you one advice instead:
Supporting framework is what is the most important thing. People will tend to love it or hate it, depending on how easy is to write good code that get job done. Therefore, please do usability test before releasing it. I mean ask several people how they will do certain task and create API accordingly. Then test beta API on other coders and listen carefully to their comments.
Regards and good luck :)
There's always space for another programming language. Apart from getting the design right, I think the biggest problem is coming across as just another wannabe language. So you may want to look at your marketing, you need a big sponsor who can integrate your language into their products, or you need to generate a buzz around it, easiest way is astroturfing. Good luck.
http://en.wikipedia.org/wiki/List_of_programming_languages
NB the names G and G++ aren't taken. Oh and watch out for the patent trolls.
Edit
Oops G / G++ are taken... still there are plenty more letters left.
This sounds more like a "systems" language rather than a "web development language". The major languages in this category (other than C++/C) are D and Go.
My advice to you would be to not start from scratch but examine the possibility of creating tools or libraries for those languages, and seeing just how far you can push them.
I know the topic I started is too subjective. But I just
wanted some expert guidance learning new languages. I've
been working with .NET languages (C#, VB.NET) quite a few
years (around 4). And it's been years since I stopped
experimenting with new laguages after settling down in a job.
Few weeks back I just started working on my personal
project, which I am going to spend much time in the coming
months. During the analysis I found that I just can't
accomodate the luxuries of cost effective languages,
programs and IDEs. So I planned to move to the wide spectrum
of open source languages and tools.
And when I look at the current choices, I was just
speechless. Hundreds of promising open languages and
toolsets and I found it's hard to choose. And I can't even
think of evaluating each language myself (it's a worst
nightmare). Currently I started with Mono (for the sake of
C#).
I felt this is going to be a good chance for learning new
programming languages and models. So I am open to any
language that offers me the following:
more functional
dynamic language features
better language elegance (like lambdas, Haskel like SQL syntaxes or C# LINQ)
better community support
must be open
easy interaction with the web
support for parallelism and concurrency (easy threading)
better in performance
proven web frameworks
better IDE support (I got this ease of use syndrome after using years of MS tools)
I love the Haskel and Erlang language programming approach.
But I don't have a clue about these languages' web stack and
concurrency mechanisms.
EDIT:
i would appreciate few reasons along with your choices. It will be really helpful.
I think that all these meet your requirements:
Groovy + Grails or
Python + one of these Web Frameworks or
Ruby + Rails/Camping/Merb/Sinatra or
Scala + Lift
My bet is that you'll get the groovier IDE experience with Groovy (and it's Groovy Eclipse Plugin).
Learn OOP, DesignPatterns, understanding of Algorithms... the rest is "just" language. You will find, if You learn 5th... 8th language there are some similarities, some prons and cons... what You need learn is to move business needs to some technical platform.
Weird. I can't believe noone has suggested Python yet.
These are not new languages, but I vote that if you have experioence with them, then you will be a better programmer in whatever language you choose to use:
Smalltalk (or Objective-C), otherwise you have not experienced OOP.
Lisp for functional, reflective, meta programming.
Prolog for logic programming.
All of these are quite far from your basic C-like language, both in concept and syntax.
Alan Kay invented OOP and Smalltalk, he is quoted as "C++ is not what I intended", and C++ is what most of todays OOP-languages mimics. C++-style OOP is merely syntactic sugar ontop of structs with function pointers. OOP can be so much more. Ruby is closely related, but you would miss out on interleaved method names.
Lisp has been around since 1958, and the fans keep saying that everything that gets added to any new language is just something borrowed from Lisp. Maybe not strictly true, but somewhat accurate, Lisp had garbage collection 50 years ago. Easiest way to experience it today would be to write something in Clojure.
Prolog is based on formal logic. Prolog is declarative, where you declare facts and rules and is executed by constructing queries on these relations. Kind of like puzzle games in some magazines :).
In the .NET world sounds like you're talking either F# and IronRuby. IronPython might also suit your needs.
Personally I'm going to give a vote for Python, Ruby and Mono.NET.
Of the three you were probably on the right track when you said you looked at Mono; it's C# (which you have previous experience with), there are good, free IDEs available SharpDevelop being one which makes it cheap and there's a really solid community behind it all.
You don't really say what kind of programming you want to do. Do you already know C/C++? If not, I'd really recommend learning those instead of anything new and fancy.
However, if it's new and fancy that you want and you'd like to be able to write native apps, then I'd have a look at:
D
It's similar to C++, but hopefully better in many ways. It has the advantage of out performing most other new and fancy languages and most of the features on your wish list.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I already have a few languages under my belt (in a rough order of expertise): Python, C, C++, PHP, Javascript, Haskell, Java, MIPS, x86 assembler. But it's been almost 2 years since I learned a new one, and I'm starting to get the itch. I have a few criteria:
Must (repeat: must) have a free Linux implementation
Should be different from the languages I already know. In other words, it should have features that get me thinking about solving problems in a new way.
Should have some potential for practical use. It doesn't need to be the next Java, but this rules out Brainf* and Shakespeare :) I don't really care how many job postings does it have, but real-world apps and libraries are a plus.
Should have at least just enough free learning materials to get me started in it.
I was thinking Lisp (CL? something else?) or OCaml. I already have some experience with functional languages with Haskell (yes I know that Lisp/OCaml are multi-paradigm). I'm not an expert - e.g. parts of code from Real World Haskell can still contort my brain, but I understand the basic concepts and some advanced ones (functors, monads).
Which one to choose? Any other languages that I have overlooked? Also, could you please include some useful links to good books/tutorials etc.
Neither Lisp nor OCaml is super far afield from what you already know. Here are four suggestions chosen partly for intrinsic interest and partly to stretch your horizons.
A logic programming language, probably Prolog. I haven't found good materials online, but the book The Art of Prolog by Sterling and Shapiro is excellent. The more basic textbook by Clocksin and Mellish is also good. The main point of interest is programming with relations, not functions.
A pure object-oriented language, either
Smalltalk or Self. If you've only used hybrid object-oriented languages you'll be amazed how beautiful pure object-orientation can be. I've linked to the Squeak implementation of Smalltalk. I personally would recommend learning Smalltalk before tackling Self; there's a very large and active community and the software is well developed. Self stands on Smalltalk's shoulders and is an even more inspiring design, but the community is much smaller. For those who have access to the ACM Digital library I recommend the excellent talk by Dave Ungar at HOPL-III; the paper is also pretty good.
The Icon programming language has two great things going for it; a powerful and unusual evaluation model with implicit backtracking, and a user-extensible model of string processing that beats regular expressions all hollow. I'm sorry to say that Icon has never quite kept pace with the times, and of all my recommendations it is the least practical. In fact I fear the language is moribund. But it will stretch your mind almost as much as Haskell, and in wildly different directions. Icon is still very useful for string-processing tasks of modest size.
You can read about Icon string processing in an article by Ralph Griswold from Computer Journal.
The Lua programming language is my last and least radical suggestion. Its interest is not so much in novel language features or paradigms but in the superb engineering of the language and its implementation. Lua occupies a number of niches, including scripting, gaming, string processing, and lightweight functional programming. But its main point of interest is its seamless integration with C, and to get the full benefit, you should bind a C library into Lua.
The HOPL-III web site also contains an excellent talk and paper about Lua.
Both Common Lisp and Ocaml are certainly useful to learn. If you already know Haskell, CL might be the more different experience.
SBCL and Clozure CL are both very useful implementations of Common Lisp on Linux. (Overview about various implementations: Common Lisp survey.)
As a starting point I would recommend to use Peter Seibel's excellent book Practical Common Lisp, that is both available online and printed.
Community pointers are here: CLIKI.
Prolog may be what you are looking for.
Edit
The first commenter is right, my answer was pretty short and not very useful, so:
My preferred implementation is SWI-Prolog. I personally learned from Prolog Programming for Artificial Intelligence. It's style is pretty clear and it contains many examples, but I don't own any other book on logic programming (it's a shame, really :) so I have no basis for comparison.
Erlang is pretty interesting to learn because of its super efficient concurrency model, and the ease with which you can write distributed systems (for an example of this, CouchDB was written in Erlang). It's a dynamically typed functional language, but you can also write code in a procedural fashion. The tutorial I learned it with is called "Getting Started with Erlang", which covers just about every part of the language.
If you want to make use of your Java and functional programming knowledge, and you want to learn a Lisp, then try Clojure.
The implementation is free and cross-platform including Linux, because it runs on the JVM. Being a Lisp, it's different enough (in useful and wonderful ways) from most other languages to make things interesting. Some features such as immutable data structures, multimethods, metadata support, focus on safe concurrency, etc. are fairly novel compared to the languages you listed. Clojure is geared heavily toward being a practical and useful language rather than an academic one. It's a functional language but not "pure", which is arguably a good thing. You can also trivially make use of any Java library from within Clojure.
Clojure is a new language, so the only book out so far is Programming Clojure, but it's a pretty good one. There's also a wiki which may not be entirely up-to-date, because the language is still evolving very quickly. The mailing list and IRC channel are very friendly, welcoming places to ask questions. The official website is also a good resource, of course.
I'm going to recommend something that I haven't yet tried, but plan to, so you have to judge for yourself this one. There's this language, called IO, which is particular in that its prototype-based, like JavaScript, but also borrows concepts from many other languages. Its job market it's probably nonexistent, but I thought I mention this language.
Otherwise, a language from the Lisp family may be pretty different from what you already know. In that regard I'd recommend Scheme, which is, in my opinion, more elegant than Common Lisp. The new concept that you might found interesting in Scheme is continuations.
If you take the Scheme path, make some time to watch these videos from 1986. They're amazing.
Have a look at Smalltalk ! Either Cincom VWST or Smalltalk/X - dont bother with Squeak as the interface is terrible). VAST is good also but really only Windows centric. And dont bother about the sceptics that pore scorn on Smalltalk -- they arent using it and are stuck in the morass of edit-run-debug cycle languages and multiple dispirt linked libraries. :-)
Why these Smalltalks - well, they come complete wth excellent IDE, GUI tools builtin, best debugger you will ever see, online help, and is totally independent of the underlying OS. Eg a ST/X programming running under Linux can be transfered ( source code) to Windows ST/X and it should execute.
ST/X is free with only a very minor licience restrictions, Cincom offer a free NC ( Not Commercial ) version that is NOT restricted. I use ST/X as I prefer the default look & feel
it offers. Their IDE interfaces are very similar.
Languages without a IDE & GUI tools are just wasting your time as the world is really GUI, no matter how terrific the underlying language is. Eg Ruby is great, but with no IDE or easy GUI tools its really frustrating.
Smalltalk is not easy to get into, and its not perfect,(what language is?) but very satisfying to learn & use. And now that the hardware and operating systems have finally caught up with Smalltalks needs . very efficient.
I second Rainer's Common Lisp recommendation.
CL has all the things you're looking for and will provide a genuinely novel experience that will also make your coding efforts and approaches in other languages better.
But bring patience and persistence, you will have to grasp a lot of concepts that will seem alien at first.
You could try Tcl. It was sufficiently different to provoke an adverse reaction in my brain, so I can't really tell you how I found it different, but there's been a lot of good stuff written in it (maybe less nowadays than earlier).
C# has a free implementation in Linux under the Mono project, and it arguably is a very marketable skill unless you're completely anti-Microsoft.
My favorite C# book is Pro C# 2008 and the .NET 3.5 Platform, Fourth Edition.
If you're really want exotic, F# is an OCaml style language that runs on the .NET platform and mono, and is getting a lot of attention these days.
http://msdn.microsoft.com/en-us/fsharp/default.aspx
Books for F#:
http://www.amazon.com/s/ref=nb_ss_gw?url=search-alias%3Daps&field-keywords=f%23
Of the suggestions I've seen so far, I like Lisp (see Secko) and Smalltalk (see brett), as both will give you another view of languages. Prolog even more so.
Another language that is different is Erlang -- I haven't had a chance to learn it yet, but it handles concurrency in a different way. The best link I can give you is the main website.
In terms of recommendations, Lisp is good both because it is currently used and because it is very old. The others you will have to look at sources and see which one appeals the most.
Try FORTRAN, then? I hear it's still actively used by the scientific and mathemematical communities, plus it should be dissimilar enough to be a learning challenge.
Compilers:
http://gcc.gnu.org/wiki/GFortranBinaries
http://www.g95.org/
http://www.fortran.com/compilers.html
http://www.thefreecountry.com/compilers/fortran.shtml
IDEs:
http://www.eclipse.org/photran/
http://force.lepsch.com/ (FORTRAN 77 only)
Tutorials:
Introduction to Modern FORTRAN: http://www-uxsup.csx.cam.ac.uk/courses/Fortran/
FORTRAN 90 Tutorial: http://www.cs.mtu.edu/~shene/COURSES/cs201/NOTES/fortran.html
You could also learn Visual Basic.NET, in case you ever get forced to maintain that. Evidently mono has a working Linux implementation of it:
http://www.mono-project.com/Visual_Basic
Factor is pretty radically different from everything you said you know, and also everything else listed. It's stack-based, like Forth, but has a fairly comprehensive library and a lot of interesting features.
Ada is very practical -- there's a compiler based on gcc -- but also quite different from the other imperative languages you know. I find the type system a bit stifling, but it was worth learning something about.
Lisp is a great HLL, it has everything that other languages lack. In my opinion, this is a very good language that can "satisfy" any programmers needs.
Perl is also a HLL like Lisp, it's interesting and fun at the same time. It derives from C so you can pick it up as you go. It can be hard sometimes and some people tend to get lost while learning, but it's worth knowing.
Both languages are free of use and come with Linux.
Links
Lisp:
If Lisp is so great,
An Introduction and Tutorial for Common Lisp
Perl:
PERL -- Practical Extraction and Report Language
Books
On Lisp - Great book by Paul Graham on the Lisp language. It's free and you can download it here.
Scala has been very good for making me see programming in a new light. I haven't used it for anything worklike yet, but it's still affected how I write code in other languages - not just Java, but PHP. I recently wrote a simple parser for a WordPress plugin, and the code is vastly more functional and immutable than it would have been six months ago, and better for it, despite the lack of enforcement in PHP.
The only other language to have affected the way I work so dramatically is Perl, nearly a decade earlier. Perl has contributed a lot to the way I pseudo-code, even if I never touch the language itself.
Many people compare the functional aspects of Scala to Haskell. You may even imagine that knowing Haskell means you already know all Scala could teach you, but I don't believe that. The way Scala combines OO and function has a way of making it seem like that's actually the truest form of both of them.
Like you, I have over a dozen languages under my belt. While shopping for something to play with for writing a cross-compiler, I ran across ML and family. Many very good ideas there, and they have taught me to write code is a much different way; for example, my JavaScript now has a decidedly functional bent.
After toying with OCaml under Windows a while (and getting frustrated with stability issues), I ran across F#, an offspring of OCaml. The two are quite similar (can cross-compile a lot of code), but OCaml apparently has a really good macro system (P4) and type-classes (in support of writing "strongly typed" operators against generic types), while F# has excellent support for asynchronous and parallel operations, monads, units-of-measure for numeric types, as well as cleaner OO syntax and awesome IDE integration (VS2008 & will be released in-the-box with VS2010). I much prefer F# these days, since I have access to the whole .NET runtime and loads of 3rd party libraries. In fact, I write most of my one-off and utility code in F# now; for me, its generally much more productive than C++, JavaScript, C#, PowerShell, or anything else.
F# works fairly well under Mono on Linux, and has a good following there. The compiler and runtime will be open sourced once stable (released with VS2010), and the developers consider Mono support enough of a priority for it to be seriously considered for non-Microsoft use.
Polyglot, or multiple language, solutions allow you to apply languages to problems which they are best suited for. Yet, at least in my experience, software shops tend to want to apply a "super" language to all aspects of the problem they are trying to solve. Sticking with that language come "hell or high water" even if another language is available which solves the problem simply and naturally. Why do you or do you not implement using polyglot solutions?
I almost always advocate more than 1 language in a solution space (actually, more than 2 since SQL is part of so many projects). Even if the client likes a language with explicit typing and a large pool of talent, I advocate the use of scripting languages for administrative, testing, data scrubbing, etc.
The advantages of many-language boil down to "right tool for the job."
There are legitimate disadvantages, though:
Harder to have collective code ownership (not everyone is versed in all languages)
Integration problems (diminished in managed platforms)
Increased runtime overhead from infrastructure libraries (this is often significant)
Increased tooling costs (IDEs, analysis tools, etc.)
Cognitive "bumps" when switching from one to another. This is a double-edged sword: for those well-versed, different paradigms are complementary and when a problem arises in one there is often a "but in X I would solve this with Z!" and problems are solved rapidly. However, for those who don't quite grok the paradigms, there can be a real slow-down when trying to comprehend "What is this?"
I also think it should be said that if you're going to go with many languages, in my opinion you should go for languages with significantly different approaches. I don't think you gain much in terms of problem-solving by having, say, both C# and VB on a project. I think in addition to your mainstream language, you want to have a scripting language (high productivity for smaller and one-off tasks) and a language with a seriously different cognitive style (Haskell, Prolog, Lisp, etc.).
I've been lucky to work in small projects with the possibility to suggest a suitable language for my task. For example C as a low-level language, extending Lua for the high-level/prototyping has served very well, getting up to speed quickly on a new embedded platform. I'd always prefer two languages for any bigger project, one domain-specific fit to that particular project. It adds a lot of expressiveness for quickly trying out new features.
However probably this serves you best for agile development methods, whereas for a more traditional project the first hurdle to overcome would be choosing which language to use, when scripting languages tend to immediately seem "newcomers" with less marketing push or "seriousness" in their image.
The biggest issue with polyglot solutions is that the more languages involved, the harder it is to find programmers with the proper skill set. Particularly if any of the languages are even slightly esoteric, or hail from entirely different schools of design (e.g. - functional vs procedural vs object oriented). Yes, any good programmer should be able to learn what they need, but management often wants someone who can "hit the ground running", no matter how unrealistic that is.
Other reasons include code reuse, increased complexity interfacing between the different languages, and the inevitable turf wars over which language a particular bit of code should belong in.
All of that said, realize that many systems are polyglot by design -- anything using databases will have SQL in addition to some other language. And there's often scripting involved as well, either for actual code or for the build system.
Pretty much all of my professional programming experience has been in the above category. Generally there's a core language (C or C++), SQL of varying degrees, shell scripting, and possibly some perl or python code on the periphery.
My employer's attitude has always been to use what works.
This has meant that when we found some useful Perl modules (like the one that implements "Benford's Law", Statistics::Benford), I had to learn how to use ActiveState's PDK.
When we decided to add interval maths to our project, I had to learn Ada and how to use both GNAT and ObjectAda.
When a high-speed string library was requested, I had to relearn assembler and get used to MASM32 and WinAsm.
When we wanted to have a COM DLL of libiconv (based on Delphi Inspiration's code), I got reacquainted with Delphi.
When we wanted to use Dr. Bill Poser's libuninum, I had to relearn C, and how to use Visual C++ 6's IDE.
We still prototype things in VB6 and VBScript, because they're good at it.
Maybe sometime down the line I'll end up doing stuff in Forth, or Eiffel, or D, or, heaven help me, Haskell (I don't have anything against the language per se, it's just a very different paradigm.)
One issue that I've run into is that Visual Studio doesn't allow multiple languages to be mixed in a single project, forcing you to abstract things out into separate DLLs for each language, which isn't necessarily ideal.
I suspect the main reason, however, is the perception that switching back and forth between many different languages leads to programmer inefficiency. There is some truth to this, I switch constantly between JavaScript, C#, VBScript, and VB.NET and there is a bit of lost time as I switch from one language to another, as I mix my syntax a bit.
Still, there is definitely room for more "polyglot" solutions particularly that extend beyond using JavaScript and whatever back-end programming language.
Well, all the web is polyglot now with Java/PHP/Ruby in the back and JavaScript in the front...
Other examples that come to mind -- a flexible complex system written in a low level language (C or C++) with an embedded high level language (Python, Lua, Scheme) to provide customization and scripting interface. Microsoft Office and VBA, Blender and Python.
A project which can be done in a scripting language such as Python with performance critical or OS-dependent pieces done in C.
Both JVM and CLR are getting lots of new interesting scripting languages compatible. Java + Groovy, C# + IRonPython etc.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I see a lot of talk on here about functional languages and stuff. Why would you use one over a "traditional" language? What do they do better? What are they worse at? What's the ideal functional programming application?
Functional languages use a different paradigm than imperative and object-oriented languages. They use side-effect-free functions as a basic building block in the language. This enables lots of things and makes a lot of things more difficult (or in most cases different from what people are used to).
One of the biggest advantages with functional programming is that the order of execution of side-effect-free functions is not important. For example, in Erlang this is used to enable concurrency in a very transparent way.
And because functions in functional languages behave very similar to mathematical functions it's easy to translate those into functional languages. In some cases, this can make code more readable.
Traditionally, one of the big disadvantages of functional programming was also the lack of side effects. It's very difficult to write useful software without I/O, but I/O is hard to implement without side effects in functions. So most people never got more out of functional programming than calculating a single output from a single input. In modern mixed-paradigm languages like F# or Scala this is easier.
Lots of modern languages have elements from functional programming languages. C# 3.0 has a lot functional programming features and you can do functional programming in Python too. I think the reasons for the popularity of functional programming is mostly because of two reasons: Concurrency is getting to be a real problem in normal programming, because we're getting more and more multiprocessor computers; and the languages are getting more accessible.
I don't think that there's any question about the functional approach to programming "catching on", because it's been in use (as a style of programming) for about 40 years. Whenever an OO programmer writes clean code that favors immutable objects, that code is borrowing functional concepts.
However, languages that enforce a functional style are getting lots of virtual ink these days, and whether those languages will become dominant in the future is an open question. My own suspicion is that hybrid, multi-paradigm languages such as Scala or OCaml
will likely dominate over "purist" functional languages in the same way that pure OO language (Smalltalk, Beta, etc.) have influenced mainstream programming but haven't ended up as the most widely-used notations.
Finally, I can't resist pointing out that your comments re FP are highly parallel to the remarks I heard from procedural programmers not that many years ago:
The (mythical, IMHO) "average" programmer doesn't understand it.
It's not widely taught.
Any program you can write with it can be written another way with current techniques.
Just as graphical user interfaces and "code as a model of the business" were concepts that helped OO become more widely appreciated, I believe that increased use of immutability and simpler (massive) parallelism will help more programmers see the benefits that the functional approach offers. But as much as we've learned in the past 50 or so years that make up the entire history of digital computer programming, I think we still have much to learn. Twenty years from now, programmers will look back in amazement at the primitive nature of the tools we're currently using, including the now-popular OO and FP languages.
The main plus for me is its inherent parallelism, especially as we are now moving away from higher CPU clock frequency and towards more and more cores.
I don't think it will become the next programming paradigm and completely replace OO type methods, but I do think we will get to the point that we need to either write some of our code in a functional language, or our general purpose languages will grow to include more functional constructs.
Even if you never work in a functional language professionally, understanding functional programming will make you a better developer. It will give you a new perspective on your code and programming in general.
I say there's no reason to not learn it.
I think the languages that do a good job of mixing functional and imperative style are the most interesting and are the most likely to succeed.
I'm always skeptical about the Next Big Thing. Lots of times the Next Big Thing is pure accident of history, being there in the right place at the right time no matter whether the technology is good or not. Examples: C++, Tcl/Tk, Perl. All flawed technologies, all wildly successful because they were perceived either to solve the problems of the day or to be nearly identical to entrenched standards, or both. Functional programming may indeed be great, but that doesn't mean it will be adopted.
But I can tell you why people are excited about functional programming: many, many programmers have had a kind of "conversion experience" in which they discover that using a functional language makes them twice as productive (or maybe ten times as productive) while producing code that is more resilient to change and has fewer bugs. These people think of functional programming as a secret weapon; a good example of this mindset is Paul Graham's Beating the Averages. Oh, and his application? E-commerce web apps.
Since early 2006 there has also been some buzz about functional programming and parallelism. Since people like Simon Peyton Jones have been worrying about parallelism off and on since at least 1984, I'm not holding my breath until functional languages solve the multicore problem. But it does explain some of the additional buzz right about now.
In general, American universities are doing a poor job teaching functional programming. There's a strong core of support for teaching intro programming using Scheme, and Haskell also enjoys some support there, but there's very little in the way of teaching advanced technique for functional programmer. I've taught such a course at Harvard and will do so again this spring at Tufts. Benjamin Pierce has taught such a course at Penn. I don't know if Paul Hudak has done anything at Yale. The European universities are doing a much better job; for example, functional programming is emphasized in important places in Denmark, the Netherlands, Sweden, and the UK. I have less of a sense of what's happening in Australasia.
I don't see anyone mentioning the elephant in the room here, so I think it's up to me :)
JavaScript is a functional language. As more and more people do more advanced things with JS, especially leveraging the finer points of jQuery, Dojo, and other frameworks, FP will be introduced by the web-developer's back-door.
In conjunction with closures, FP makes JS code really light, yet still readable.
Cheers,
PS
Most applications are simple enough to be solved in normal OO ways
OO ways have not always been "normal." This decade's standard was last decade's marginalized concept.
Functional programming is math. Paul Graham on Lisp (replace Lisp by functional programming):
So the short explanation of why this
1950s language is not obsolete is that
it was not technology but math, and
math doesn’t get stale. The right
thing to compare Lisp to is not 1950s
hardware, but, say, the Quicksort
algorithm, which was discovered in
1960 and is still the fastest
general-purpose sort.
I bet you didn't know you were functional programming when you used:
Excel formulas
Quartz Composer
JavaScript
Logo (Turtle graphics)
LINQ
SQL
Underscore.js (or Lodash),
D3
The average corporate programmer, e.g.
most of the people I work with, will
not understand it and most work
environments will not let you program
in it
That one is just a matter of time though. Your average corporate programmer learns whatever the current Big Thing is. 15 years ago, they didn't understand OOP.
If functional programming catches on, your "average corporate programmers" will follow.
It's not really taught at universities
(or is it nowadays?)
It varies a lot. At my university, SML is the very first language students are introduced to.
I believe MIT teaches Lisp as a first-year course. These two examples may not be representative, of course, but I believe most universities at the very least offer some optional courses on functional programming, even if they don't make it a mandatory part of the curriculum.
Most applications are simple enough to
be solved in normal OO ways
It's not really a matter of "simple enough" though. Would a solution be simpler (or more readable, robust, elegant, performant) in functional programming? Many things are "simple enough to be solved in Java", but it still requires a godawful amount of code.
In any case, keep in mind that functional programming proponents have claimed that it was the Next Big Thing for several decades now. Perhaps they're right, but keep in mind that they weren't when they made the same claim 5, 10 or 15 years ago.
One thing that definitely counts in their favor, though, is that recently, C# has taken a sharp turn towards functional programming, to the extent that it's practically turning a generation of programmers into functional programming programmers, without them even noticing. That might just pave the way for the functional programming "revolution". Maybe. ;)
Man cannot understand the perfection and imperfections of his chosen art if he cannot see the value in other arts. Following rules only permits development up to a point in technique and then the student and artist has to learn more and seek further. It makes sense to study other arts as well as those of strategy.
Who has not learned something more about themselves by watching the activities of others? To learn the sword study the guitar. To learn the fist study commerce. To just study the sword will make you narrow-minded and will not permit you to grow outward.
-- Miyamoto Musashi, "A Book of Five Rings"
One key feature in a functional language is the concept of first-class functions. The idea is that you can pass functions as parameters to other functions and return them as values.
Functional programming involves writing code that does not change state. The primary reason for doing so is so that successive calls to a function will yield the same result. You can write functional code in any language that supports first-class functions, but there are some languages, like Haskell, which do not allow you to change state. In fact, you're not supposed to make any side effects (like printing out text) at all - which sounds like it could be completely useless.
Haskell instead employs a different approach to I/O: monads. These are objects that contain the desired I/O operation to be executed by your interpreter's toplevel. At any other level they are simply objects in the system.
What advantages does functional programming provide? Functional programming allows coding with fewer potentials for bugs because each component is completely isolated. Also, using recursion and first-class functions allows for simple proofs of correctness which typically mirror the structure of the code.
I don't think most realistic people think that functional programming will catch on (becomes the main paradigm like OO). After all, most business problems are not pretty math problems but hairy imperative rules to move data around and display them in various ways, which means it's not a good fit for pure functional programming paradigm (the learning curve of monad far exceeds OO.)
OTOH, functional programming is what makes programming fun. It makes you appreciate the inherent, timeless beauty of succinct expressions of the underlying math of the universe. People say that learning functional programming will make you a better programmer. This is of course highly subjective. I personally don't think that's completely true either.
It makes you a better sentient being.
I'd point out that everything you've said about functional languages, most people were saying about object-oriented langauges about 20 years ago. Back then it was very common to hear about OO:
* The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it
* It's not really taught at universities (or is it nowadays?)
* Most applications are simple enough to be solved in normal IMPERATIVE ways
Change has to come from somewhere. A meaningful and important change will make itself happen regardless of whether people trained in earlier technologies take the opinion that change isn't necessary. Do you think the change to OO was good despite all the people that were against it at the time?
I must be dense, but I still don't get it. Are there any actual examples of small application's written in a functional language like F# where you can look at the source code and see how and why it was better to use such an approach than, say, C#?
F# could catch on because Microsoft is pushing it.
Pro:
F# is going to be part of next version of Visual Studio
Microsoft is building community for some time now - evangelists, books, consultants that work with high profile customers, significant exposure at MS conferences.
F# is first class .NET language and it's the first functional language that comes with really big foundation (not that I say that Lisp, Haskell, Erlang, Scala, OCaml do not have lots of libraries, they are just not as complete as .NET is)
Strong support for parallelism
Contra:
F# is very hard to start even if you are good with C# and .NET - at least for me :(
it will probably be hard to find good F# developers
So, I give 50:50 chance to F# to become important. Other functional languages are not going to make it in near future.
I think one reason is that some people feel that the most important part of whether a language will be accepted is how good the language is. Unfortunately, things are rarely so simple. For example, I would argue that the biggest factor behind Python's acceptance isn't the language itself (although that is pretty important). The biggest reason why Python is so popular is its huge standard library and the even bigger community of third-party libraries.
Languages like Clojure or F# may be the exception to the rule on this considering that they're built upon the JVM/CLR. As a result, I don't have an answer for them.
It seems to me that those people who never learned Lisp or Scheme as an undergraduate are now discovering it. As with a lot of things in this field there is a tendency to hype and create high expectations...
It will pass.
Functional programming is great. However, it will not take over the world. C, C++, Java, C#, etc will still be around.
What will come of this I think is more cross-language ability - for example implementing things in a functional language and then giving access to that stuff in other languages.
When reading "The Next Mainstream Programming Language: A Game Developer’s Perspective" by Tim Sweeney, Epic Games, my first thought was - I got to learn Haskell.
PPT
Google's HTML Version
Most applications can be solved in [insert your favorite language, paradigm, etc. here].
Although, this is true, different tools can be used to solve different problems. Functional just allows another high (higher?) level abstraction that allows to do our jobs more effectively when used correctly.
Things have been moving in a functional direction for a while. The two cool new kids of the past few years, Ruby and Python, are both radically closer to functional languages than what came before them — so much so that some Lispers have started supporting one or the other as "close enough."
And with the massively parallel hardware putting evolutionary pressure on everyone — and functional languages in the best place to deal with the changes — it's not as far a leap as it once was to think that Haskell or F# will be the next big thing.
It's catching on because it's the best tool around for controlling complexity.
See:
- slides 109-116 of Simon Peyton-Jones talk "A Taste of Haskell"
- "The Next Mainstream Programming Language: A Game Developer's Perspective" by Tim Sweeney
Check out Why Functional Programming Matters.
Have you been following the evolution of programming languages lately? Every new release of all mainstream programming languages seems to borrow more and more features from functional programming.
Closures, anonymous functions, passing and returning functions as values used to be exotic features known only to Lisp and ML hackers. But gradually, C#, Delphi, Python, Perl, JavaScript, have added support for closures. It's not possible for any up-and-coming language to be taken seriously without closures.
Several languages, notably Python, C#, and Ruby have native support for list comprehensions and list generators.
pioneered generic programming in 1973, but support for generics ("parametric polymorphism") has only become an industry standard in the last 5 years or so. If I remember correctly, Fortran supported generics in 2003, followed by Java 2004, C# in 2005, Delphi in 2008. (I know C++ has supported templates since 1979, but 90% of discussions on C++'s STL start with "here there be demons".)
What makes these features appealing to programmers? It should be plainly obvious: it helps programmers write shorter code. All languages in the future are going to support—at a minimum—closures if they want to stay competitive. In this respect, functional programming is already in the mainstream.
Most applications are simple enough to
be solved in normal OO ways
Who says can't use functional programming for simple things too? Not every functional program needs to be a compiler, theorem prover, or massively parallel telecommunications switch. I regularly use F# for ad hoc throwaway scripts in addition to my more complicated projects.
Wow - this is an interesting discussion. My own thoughts on this:
FP makes some tasks relatively simple (compared to none-FP languages).
None-FP languages are already starting to take ideas from FP, so I suspect that this trend will continue and we will see more of a merge which should help people make the leap to FP easier.
I don't know whether it will catch on or not, but from my investigations, a functional language is almost certainly worth learning, and will make you a better programmer. Just understanding referential transparency makes a lot of design decisions so much easier- and the resulting programs much easier to reason about. Basically, if you run into a problem, then it tends to only be a problem with the output of a single function, rather than a problem with an inconsistant state, which could have been caused by any of the hundreds of classes/methods/functions in an imparative language with side effects.
The stateless nature of FP maps more naturally to the stateless nature of the web, and thus functional languages lend themselves more easily to more elegant, RESTFUL webapps. Contrast with JAVA and .NET frameworks that need to resort to horribly ugly HACKS like VIEWSTATE and SESSION keys to maintain application state, and maintain the (occasionally quite leaky) abstraction of a stateful imperative language, on an essentially stateless functional platform like the web.
And also, the more stateless your application, the more easily it can lend itself to parallel processing. Terribly important for the web, if your website happens to get popular. It's not always straightforward to just add more hardware to a site to get better performance.
My view is that it will catch on now that Microsoft have pushed it much further into the mainstream. For me it's attractive because of what it can do for us, because it's a new challenge and because of the job opportunities it resents for the future.
Once mastered it will be another tool to further help make us more productive as programmers.
A point missed in the discussion is that the best type systems are found in contemporary FP languages. What's more, compilers can infer all (or at least most) types automatically.
It is interesting that one spends half the time writing type names when programming Java, yet Java is by far not type safe. While you may never write types in a Haskell programm (except as a kind of compiler checked documentation) and the code is 100% type safe.
I agree with the first point, but times change. Corporations will respond, even if they're late adopters, if they see that there's an advantage to be had. Life is dynamic.
They were teaching Haskell and ML at Stanford in the late 1990s. I'm sure that places like Carnegie Mellon, MIT, Stanford, and other good schools are presenting it to students.
I agree that most "expose relational databases on the web" applications will continue in that vein for a long time. Java EE, .NET, Ruby on Rails, and PHP have evolved some pretty good solutions to that problem.
You've hit on something important: It might be the problem that can't be solved easily by other means that will boost functional programming. What would that be?
Will massive multicore hardware and cloud computing push them along?
Because functional programming has significant benefits in terms of productivity, reliability and maintainability. Many-core may be a killer application that finally gets big corporations to switch over despite large volumes of legacy code. Furthermore, even big commercial languages like C# are taking on a distinct functional flavour as a result of many-core concerns. Side effects simply don't fit well with concurrency and parallelism.
I do not agree that "normal" programmers won't understand it. They will, just like they eventually understood OOP (which is just as mysterious and weird, if not more so).
Also, most universities do teach functional programming , many even teach it as the first programming course.
In addition to the other answers, casting the solution in pure functional terms forces one to understand the problem better. Conversely, thinking in a functional style will develop better* problem solving skills.
*Either because the functional paradigm is better or because it will afford an additional angle of attack.