Related
Are there any good reason to learn languages such as Ada and COBOL? Are there any future in programming in those languages? I'm interested in those languages and i'm currently learning them just for fun.
Its always worthwhile learning new languages. Even if they're never useful to you professionally chances are they'll teach you something about programming you didn't know before or at very least broaden your outlook.
As for prospects from a quick bit of reading around it seems ada is still somewhat in favour for critical systems in the aviation industry and Cobol still has its place in business. I know an engineer in his mid 20's who writes all his code in fortran77 as that's what industry wants!
While the number of employers looking for these languages might be low, because there are a limited number of people who know them the salary for developers who specialise in them can be quite high. When mission critical apps developed in them could cost millions to replace having to pay more than usual for a coder to maintain the existing system is easily accepted.
Ada is used in the aerospace/defense industry. COBOL is used in the financial industry. Fortran is used in engineering. The question "is there any future" is borderline subjective/argumentative since all of those languages are still in active use.
Fortran is old, but is used in scientific programming. Ada is the basis for VHDL, a very important language in electrical engineering. You could also say that C is "old", and it's used pretty much everywhere.
Cobol and Algol are both still in widespread use. You won't find them running on your latest and greatest tech firms, but you can bet your car insurance company process' claims on it. Your health insurance company most certainly uses it. Reports of Cobol's death have been highly exaggerated.
You will find difficulty in colleges and places that will actually teach you Cobol or Algol. So finding developers for these so-called dead languages is getting harder and harder. Very tough to tell a kid coming out of high school that has been programming in Java, iOS, and Perl for half his life that Cobol is where the money is at.
Cobol/Algol developers are becoming harder and harder to come by, so if you have that language in your back pocket, it is only going to help you out. Algol is a lot harder of a language in my opinion to get good at. You can teach anyone with half a brain how to program in Cobol.
These languages are not going away any time soon at all. As long as companies like IBM and Unisys provide compilers for them on the mainframes, they will continue to thrive. So grab a book and an open source compiler and brush up. Plenty of people out there looking for Cobol/Algol developers.
Many of these 'old' languages are actively in use today. Lisp for instance is gaining popularity again in the form Clojure. Smalltalk is becoming popular again with the Seaside MVC framework.
In addition many of the hottest development lanaguages borrow heavily from Lisp and Smalltalk, both of which pioneered Object Oriented methodologies long before C++ came along. Javascript, Ruby, Perl 6 and Perl 5 Moose (Object System) all use mixins which were first used in Lisp and Smalltalk. Metaclasses, first used in Common Lisp and Smalltalk-80, are making a resurgence in Perl 5 Moose, Objective-C (iPhone development), Python and Groovy.
Much like learning Latin, it can be intriguing to understand where and how many English and other current languages' words had their roots. Also, if you know Latin and valuable new books/papers/scrolls are found that need translation, you suddenly become valuable too.
Honestly, I'd say learning them is great for a historical perspective, especially if you're a language designer, but not very much else.
There are roles out there for COBOL programmers, but in general they are looking for experienced developers. From what I have seen you are unlikely to get a first programming role in COBOL - in general, they are looking for people experienced with similar application domains and who are familiar with building an understanding of legacy systems. Knowing the limitations of the language can be useful for understanding why certain things you are asking for when connecting to mainframes are either considered difficult or problematic.
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).
Does anybody know of any research or benchmarks of how long it takes to develop the same application in a variety of languages? Really I'm looking for Java vs. C++ but any comparisons would be useful. I have the feeling there is a section in Code Complete about this but my copy is at work.
Edit:
There are a lot of interesting answers to this question but it seems like there is a lack of really good research. I have made a proposal over at meta about this problem.
Pratt & Whitney, purveyors of jet engines for civilian and military applications, did a study on this many years ago, without actually intending to do the study.
They went on the same metrics kick everyone else went on in the 1990s. They collected a bunch of data about their jet engine controller projects, including timecard data. They crunched it. The poor sap who got to crunch the data noticed something in the results: the military projects uniformly had twice the programmer productivity and one/fourth the defect density as the civilian projects.
This, by itself, is significant. It means you only need half as many programmers, and you aren't going to spend quite as much time fixing bugs. What is even more important is that this was an apples-to-apples comparison. A jet engine controller is a jet engine controller.
He then went looking for candidate explanations. All of the usual candidates: individual experience, team size, toolsets, software processes, requirements stability, everything, were trotted out, and they were ruled out when it was seen that the story on those items was uniformly the same on both sides of the aisle. At the end of the day, only one statistically significant difference showed up.
The civilian projects were written in every language you could think of. The military projects were all written in Ada.
IN EVERY SINGLE CASE, against every other comer, for jet engine controllers at Pratt & Whitney, using Ada gave double the productivity and one/fourth the defect density.
I know what the flying code monkeys are going to say. "You can do good work in any language." In theory, that's true. In practice, however, it appears that, at least at Pratt & Whitney, language made a difference.
Last I heard about this, Pratt & Whitney upper management decreed that ALL jet engine controller projects would be done in Ada.
No, I don't have a citation. No paper was ever written. My source on this story was the poor sap who crunched the numbers. Here's a similar study from 1995:
http://archive.adaic.com/intro/ada-vs-c/cada_art.html
This, incidentally, was BEFORE Boeing did the 777, and BEFORE the 777 brake subcontractor story happened. But that's another story.
One of the few funded scientific studies that I'm aware of on cross-language productivity, from the early 90s, funded by ARPA and the ONR,
Haskell vs. Ada Vs. C++ vs Awk vs ... An Experiment in Software Prototyping Productivity, Hudak & Jones, 1994.
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..
This article(a pdf) has some benchmarks (note that it's from 2000) between C, C++, Perl, Java, Perl, Python, Rexx and Tcl.
Some common wisdom I believe holds true (also somewhere within the article):
The number of lines written per hour is independent of the language
Opinion: more important is what is faster for a given developer, for example yourself. What you are used to, will usually be faster. If you are used to 20 years of C++ pitfalls and never skip an uninitialized variable, that will be faster than Java for anybody.
If you remember all parameters of CreateWindowEx() by heart, it will be faster than MFC or winforms.
A couple of anecdotal data points:
On Project Euler, which invites programming solutions to mathematical problems,
the shortest solutions are almost invariably written in J or K, a relative of APL; there are occasionally MatLab solutions in the same range. It can be argued, though, that these languages specialized in math.
runners up were Ruby solutions. A lot of algorithm can be wrapped in very little code, and it's much more legible than J / K.
Python and Haskell solutions also did very well, LOC-wise.
The question asked about "fastest development," not "shortest code." But it's conceivable that shorter solutions are faster to come up with - certainly for slow typists!
There's an annual competition among roboticists. Contestants are given some specs for some hardware, a practical problem to solve in software, and limited time to do so. Again very domain specific, of course. Programmers have their choice of tools, including language of course. Every year, the winning team (often a single person) used Forth.
This admittedly limited sample suggests that "development speed" and "effect of language on speed" is often very dependent on the problem domain.
See also
Are there statistical studies that indicates that Python is "more productive"?
for some discussions about this kind of question.
It would make more sense to benchmark the programmers, not the languages. The time to write a program in any mainstream language depends more on the ability of the programmer in that language than on qualities of that specific language.
I think most benchmarks and statements on this topic will mean very little.
Benchmarks can always be gamed; see the history of "Pet Store".
A language that's good at solving one kind of problem might not apply as well to another.
What matters most is the skill of your team, its knowledge of a particular technology, and how well you know the domain you're trying to solve.
UPDATE: Control software for jet engines and helicopters is a very specialized subset of computing problems. It's characterized by very rigorous, complete, detailed specs and QA that means the multi-million dollar aircraft cannot crash.
I can second the (very good) citation by John Strohm of Pratt & Whitney control software written in Ada. The control software for Kaman helicopters sold to Australia was also written in Ada.
But this does not lead to the conclusion that if you decided to write your next web site in Ada that you'd have higher productivity and fewer defects than you would if you chose C# or Java or Python or Ruby. All languages are not equally good in all problem domains.
Language/framework comparison for web applications
The Plat_Forms project provides some information of this type for web applications.
There are three studies with different tasks (done in 2007, 2011, 2012), all of the following format: Several teams of three professional developers implemented the same application under controlled conditions within two days.
It covers Java, Perl, PHP, and Ruby and has multiple teams for each language.
The evaluation reports much more than only development time.
Findings of iteration one for instance included
that experience with the language and framework appeared to be more relevant than what that framework was.
that Java tended to induce teams to make laborious constructions while Perl induced them to make pragmatic (and quite handy) constructions.
Findings of iteration two included
that Ruby on Rails was more productive in this type of project (which due to its duration was more rapid prototyping than full-blown development of a mature application)
and that the one exception to the above rule was the one team using Symfony, a PHP framework that has similar concepts to Ruby on Rails (but still the very different base language underneath it).
Look under http://www.plat-forms.org or search the web for "Plat_Forms".
There is plenty more detail in the reports, in particular the thick techreport on iteration 1.
Most programs have to interface with some other framework. It tends to be a good idea to pick the language that has libraries specifically for what you are trying to do. For instance are you trying to build a distributed redundant messaging system? If so I would use Erlang. Are you trying to make a quick and dirty data driven website, use Ruby and Rails. You get the idea. Real time DirectX where performance is key, C++/C/Asm.
If you are writing something that is algorithm based I would look to a functional language like Haskell, although it has a very high learning curve.
This question is a little old fashioned. Focusing on development time solely based on the choice of language is of limited value. There are so many other factors that have equal or more impact than the language itself:
The libraries or frameworks available / used.
The level of quality required (ie. defect count).
The type of application (eg. GUI, server, driver etc...)
The level of maintainability required.
Developer experience in the language.
The platform or OS the application is built on.
As an example, many would say Java is the better choice over C++ to build enterprise (line of business) applications. This is not normally because of the language itself, but instead it is perceived that Java has better (or more mature) web server and database frameworks available to it. This may or may not be true, but that is beside the point.
You may even find that the building an application using the same language on different operating systems or platforms gives greatly differing development time. For example using C++ on Linux to build a GUI application may take longer than a Windows based GUI application using C++ because of less extensive and mature GUI libraries avaialble on Linux (once again this is debatable).
According to Norvig, Lutz Prechelt published just such an article in the October 1999 CACM: "Comparing Java vs. C/C++ Efficiency Issues to Interpersonal Issues".
Norvig includes a link to that article. Unfortunately, the ACM, despite having a bitmap graphic proclaiming their goal of "Advancing Computing as a Science & Profession", couldn't figure out how to maintain stable links on their webpage, so it's just a 404 now. Perhaps your local library could help you out.
That Ada story might be an embellished version of this: http://www.adaic.com/whyada/ada-vs-c/cada_art.html
Erlang vs C++/Corba
"... As the Erlang DCC is less than a quarter of the size of a similar C++/CORBA implementation, the product development in Erlang should be fast, and the code maintainable. We conclude that Erlang and associated libraries are suitable for the rapid development of maintainable and highly reliable distributed products."
Paper here
There's a reason why there are no real comparisons in that aspect, except for anecdotal evidence (which can be found in favor of almost any language).
Actually writing code takes relatively small portion of developer's time. Even if language lets you cut coding time in half, it will be barely noticeable by the time project ends. Design, structure of program, development process are all much more important, and then there are libraries, tools and experience with them.
Some languages are better suited for certain development processes than the others, so if you've settled on design and process you can decide which language will be more efficient - but not before.
(didn't notice there's a similar answer already, so feel free to ignore this)
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.
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.