Related
I am wondering what are some specific questions I should keep in mind when I am comparing programming languages for use on given work projects. For instance, I am told logic programming languages like Prolog are good for natural language processing. I'm not sure why exactly; I assume it is true because experts say so, but I don't know the consideration that guides them to that conclusion. So I am looking for a simple heuristic, a checklist of questions, I can apply to evaluate programming languages and be able to explain my decisions, so that I can say "Language X is good for Y because it does Z."
The only way I know of to figure out which programming language is most appropriate for a given problem, is to know lots of programming languages. After all, if you don't know screwdrivers exist, how will you know not to use a hammer when you encounter a screw?
Unfortunately, there are thousands (maybe tens of thousands) of programming languages, so learning even a significant portion of them is just not realistic.
However, programming languages implement paradigms. And Peter van Roy's famous poster only lists about 34 of those. Although he deliberately decided to ignore several aspects, including anything related to typing, so the real number is probably higher than that. But we can expect it to be well below 100.
That's still a lot, though, but thankfully, paradigms aren't atomic either, they are composed of concepts. The poster lists about a dozen of those (again ignoring typing and a couple of other things). Significantly less than paradigms.
Learning a significant portion of concepts is entirely feasible. Once you know them, you can look at a problem and see which concepts would be useful to have to build a solution. Then you look at which paradigms contain those concepts and which languages implement those paradigms. Pick one, learn it, use it, solve the problem.
And since you already know the concepts (and thus the paradigms) the language implements, you only need to learn the syntax, not the semantics. There aren't actually that many different syntaxes in the wild (C, C++, Objective-C, Objective-C++, D, Go, Java, C#, ECMAScript, PHP, Vala and many others share a lot of syntax, for example, as do Smalltalk, Self, Newspeak and Objective-C, SML, OCaml and F#, and so on), so chances are, you'll pick that up very quickly. (Besides, with today's modern IDEs that's much less of an issue anyway.)
One small point to bear in mind: if you are an expert in language X and you are asked to develop a program in domain Y for which language Z is supposed to be ideal -- will you deliver sooner and better by writing in the language you are an expert in even if it is not (by some measures) ideal for the problem domain ? Or will you deliver better and sooner by first learning a new language ?
I think your search for a simple heuristic is in vain.
Start with what you're team is familiar with. While there's a lot to be said for the philosophy that a great developer can pick up almost any language in short order, there's a practical side that goes to the fact that if you have a ton of .Net or Java coders, you're best served in starting from that base.
Now, within both stacks you have options on things like functional programming (F#, Erlang, etc.) and other languages on the runtime your team is most familiar with. But it really does boil down to the culture, infrastructure, and (most importantly) the experience and flexibility of the individual developers on your team.
There are several factors to consider:
What is your local expertise? If you have a company full of C programmers, it's probably not worth retraining everybody to be Lisp programmers.
What are your libraries? If you have libraries that you want to use, make sure that they are compatible with your language of choice.
If you are starting a new project with a wide-open field of options, I would recommend taking a few sample problems out of the application domain. Nothing too complex, but nothing trivial either. Then, implement (or have someone from your team implement) these samples in each candidate language. Then, choose the one that is clear, easy, and appropriate.
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'm very curious about old programming languages, especially COBOL, and as Wikipedia couldn't really tell me much about this topic, I decided to ask it here:
Was COBOL the first programming language really being used in financial, stock and banking systems?
Where exactly was COBOL used?
Was it used more frequently than Fortran or BASIC, for example?
I don't know if you lived at that time, but how did people react to the rising COBOL? Did they expect it to be the future?
When has COBOL actually stopped being used to create new, big systems?
Are you sure that there are still important legacy apps written in COBOL out there? I can't believe that somehow.
Previous SO questions have gone a long way toward answering your questions. Please review:
What are Fortran and COBOL used for today
Why is COBOL still a preferred language in the business world
Reasons to start a new project in COBOL
What makes COBOL such a hated language
Was COBOL the first programming language used in financial, stock and banking systems
Well known languages that co-existed with early COBOL are
Fortran and Lisp. These languages were not much used much outside
of research and university facilities.
The landscape was highly fragmented within the world of business computing.
A number of proprietary low-to-medium level languages existed but generally
only ran on one vendors machine.
A few examples were: FLO-MATIC,
AIMACO and COMTRAN, all of
which heavily influenced the development of COBOL.
From this chaos emerged a strong desire to have a machine independent and common language for
developing business applications.
According to Jean E. Sammet (The Early History of COBOL), the
US Department of Defense spearheaded and funded the early development of COBOL.
Where is COBOL used
Largely in financial (banks/government) and insurance industries. Outside of these sectors, COBOL is pretty
much unheard of.
Is it used more frequently than Fortran or BASIC
I believe Fortran actually pre-dates COBOL by a little bit. Fortran is
primarily suited for high-performance numerical applications (astronomy, physics
and the like). COBOL is primarily suited for financial and record keeping
applications - the stuff of business and commerce (hence
the name: COmmon Business Oriented Language).
The two were never in "competition" so asking which is more frequently used
is kind of like comparing apples to oranges.
Putting the "apples" and "oranges" aside, it is hard to say how many lines of production
code exist for either of these languages. Estimates vary from billions to millions.
However, I don't think anybody would claim that the active code base is insignificant.
BASIC (excluding "Visual Basic") was largely a personal computer language.
There have been a few ports to
larger machines (eg. VAX BASIC - Oh that was fun) but I don't think this ever caught on.
I would be surprised if there are any significant production systems written in BASIC
today. Just say "BAISC" to any "old timer" and their minds will flood with fond
memories. Other than that it is pretty much gone.
When did COBOL stop being used
The COBOL legacy is huge. As such, there is a lot of legacy maintenance going on
today, and it will go on for many years to come.
Is there any new development? I would say less and less every year but it is
nowhere near coming to an end. I work in a very large shop and we actively develop new
COBOL applications. I don't believe we are alone.
Those that still actively develop systems in COBOL are not a bunch of "back woods"
idiots who don't know any better. They do it because COBOL "delivers the goods"
for the least cost per transaction processed. Believe me, if any other technology could
do it cheaper, faster and more reliably, COBOL would be gone tomorrow!
One can only get an appreciation for how wide spread COBOL is by
working in the financial, government or insurance industries - and then only
in an area where they have to push a lot of data around.
If you work outside of this environment it is like the language died a hundred yeas ago!
How did people react to the rise of COBOL?
In a couple of words: Not well.
COBOL came into existence just about the same time that the academic world made huge
breakthroughs in language theory and compiler design. COBOL missed that boat and has been
denigrated by everybody with an academic interest in computing ever since. I went through
university in the 70's and even at that time the word "COBOL" made us all cringe. The
hate for COBOL runs very deep.
Even the developers of COBOL could not have predicted the long term success of the
language. The original COBOL was specified by a "short range committee" so
that could it implemented with reasonable time and effort. The final "touches" would
be made by a "long range committee". The "long range committed" never materialized
and this is what we got!
The death of COBOL has been predicted as imminent since the 60's. It is still with
us and going strong.
Why? I think there are three big reasons:
Code stability. COBOL carries its legacy fairly well, major upgrades are rare. This
may not be a selling point if you are in the business of developing code. However,
if you are the one paying for it COBOL gets high marks on this one.
Performance. COBOL applications are generally developed where volume and/or
throughput are critical (eg. processing monthly bank statements, tax returns, etc.)
Track Record. Organizations that use COBOL generally know their track record. They
have a certain comfort level with cost/time estimates for major development projects
using COBOL and related technologies.
Taking on a new language and supporting technology to implement mission critical applications involves additional
and unknown risks (and unknown benefits).
Notice that all the reasons I have cited for COBOL's continued existence are driven by
cost and risk minimization. There is nothing from a developer's point of view that
makes developing in COBOL interesting. Blame corporate accountants for COBOL's
continued success.
On the brighter side, there are a few frameworks (eg. Bassett Frame Technology and XVCL) that can make COBOL development today tollerable, even, dare I say, interesting.
Was COBOL the first programming
language really being used in
financial, stock and banking systems?
For practical purposes this was all done in assembler, but Cobol was the first high level language to move into these domains.
Where exactly was COBOL used?
Any place where money changed hands, inventory was tracked, et al. Your use of the word "was" implies that it is not now used. Cobol is involved every time you swipe a credit card, ship a package, make a phone call...it is every where. Still.
Was it used more frequently than
Fortran or BASIC, for example?
Yes, very much so. Fortran is well geared for science geeks and engineers -- a noble calling -- but they don't exist in the numbers of the sales and marketing geeks, the Cobol domain.
Does anyone use BASIC? Doesn't that suck?
I don't know if you lived at that
time, but how did people react to the
rising COBOL? Did they expect it to be
the future?
People like credit cards. People like online access to their bank accounts. People like Voice Response Systems that give their balance and last 5 transactions. People like ATMS. People like fast airline and hotel bookings.
The only people who don't like what Cobol does for them are programmers that have never put the time and effort into understanding Cobol (but they hate it anyway).
When has COBOL actually stopped being
used to create new, big systems?
Ummm, never. Cobol is still actively developed and used all over the world. It isn't sexy and no Computer Science professor is going to tell you that it is "the next big thing" -- but if they knew what they were talking about they would be making money in the real world...
Are you sure that there are still
important legacy apps written in COBOL
out there? I can't believe that
somehow.
MasterCard. Visa. Naa...
No idea really, but LEO was used for payroll. It used a language similar to COBOL called CLEO.
COBOL is used all over the place. Mostly banks and big mainframe departments.
difficult to say. It was certainly popular back in the day.
Back in the days when COBOL had its heyday, the alternatives were for alternative niches - eg Fortran for scientific, Algol for academic, Cobol for financial. Did they expect it to be the future... possibly.
5,6. It still is used. Search for COBOL jobs, you'll get quite a few hits for banking and financial companies that are looking for programmers, architects, etc. Pays quite well too by all accounts.
Answering the last part:
Yes, there are certainly new COBOL applications being written at banks everyday. Large financial institutions usually have a mainframe or two around, as they (traditionally) have a much better uptime than standard servers, and can move a lot of data reliably.
Additionally, the people still doing COBOL are pretty darn good at what they do.
If you're dealing with billions of dollars of electronic transactions, reliably is worth paying for, even if it's not new or sexy to do so. Then again, I can't hotswap the processor out of my webserver; hotswapping any of the parts out of a mainframe is usually possible, and that's actually a pretty tech-sexy feature, if I gotta say so myself.
I managed to go almost 15 years in my career without touching a single line of COBOL, or even of seeing it. Until I got my last job, which is some enterprise middleware that links COBOL to web services and non-mainframe databases. My very first customer engagement at this new job was with a big-ass company with lots and lots of COBOL they wanted to integrate with newer systems.
Learning it has been a pain, mostly because there are few good PC-based COBOL engines left, but it's not really hard at all. And that is why it's still around. It does a job, does it well. It's showing it's age a bit in how it interacts with SOA frameworks, but even that problem is going away.
#Neal:
>
BASIC (excluding "Visual Basic") was largely a personal computer language.
There have been a few ports to
larger machines (eg. VAX BASIC - Oh that was fun) but I don't think this ever caught on.
BASIC also started on big machines. I remember programming with BASIC and a paper tape on a CDC back in 1974 in an environnement similar to this one http://www.museumwaalsdorp.nl/computer/en/comp742E.html.
RE code stability of cobol: Updates rare, but they are very disruptive, and are actively resisted by the installed base. When forced, conversions often are done in a compatibility mode and the testing alone can burn the entire SD budget for a year. OO cobol is a case in point as the real costs of conversion will exceed its benefits unless a total redesign is attempted. Consulting shops love this as they bill for time, but for the organization it has the potential to literally put them out of business. One of the great myths of this OO cobol exercise is the 'portability' of the skill set of cobol, but in fact it is the OOP/OOD skill which is lacking and must be taught to the legacy programmers. Learning a new paradigm is allays harder than learning a new tool ( language) and in point of fact the exercise makes no sense and is entertained only by that bastion of folly known as management ---as carefully mislead by the vendor community devoted as they are to the creation of 'value' for their shareholders. It is often an easy sale, and fools generally do deserve to be fleeced.
RE execution speed. This is not really worth a detailed response. Platforms are fast, and it is compilers that determine execution speed. I have examine the asm output from COBOL compilers and it is not any better than a good c compiler. More to the point classic COBOLS's lack of type safety , failure to support scope, failure to support parametrized procedures, failure to support explicit type conversion etc, leads to the mistaken impression that because it does not do any of this it is faster. In fact most of this requires only compile time support and the rest does not add much overhead ( and what little it does can be optimized out) where as it does make code reuse prohibitively expensive, make testing a nightmare, and produce brittle code.
It will only go away when it costs to much to fix. This may or may not happen, but it is more likely that the organizations will fail due to a major software issue which would have been trapped by a type safe language before then.( OOP will provide type safety but that will require that cobol programmers and business analysts learn to use types)
Let's say a tester is to do some programming to create automated tests ... is Lua really easy to learn for someone who is not a developer?
It depends on the particular non-developer in question. Some people will utterly block on any programming language at all. Some will easily grok many languages and basic programming concepts. There is no silver bullet for putting the power of programming in the hands of someone who is untested on it.
That being said, my personal feeling is that Lua is as good of a place to start as any other programming language.
The Lua language has an active and usually novice-friendly community. It has a long history of use on the boundary between non-programmers and programmers. The language reference manual and standard text book are among the best written examples I've seen in my career. The full text of the reference manual is online, and the first edition of Programming in Lua is as well, although the second edition of PiL reflects the differences in the language that happened after PiL was first published and is well worth the investment to purchase.
One of Lua's strengths is the ease with which it can be integrated into an existing system to construct a configuration and scripting interface to an application. That makes the development cost to adopt it relatively low. Its small size makes the impact on an application release remarkably low as well. Thus getting an existing system to the point where it can be scripted enough with Lua to use Lua as a basis for testing will likely be a straightforward task with few hidden obstacles.
Lua is very forgiving which many people associate with "easy". You do not have to enter semi-colons, you do not have to scope variables, you can write all of your functions in the global scope. Of course doing these things only make your life easier when writing. When debugging even a new programmer may soon see why taking these short cuts is not such a good idea.
I also believe that you can write very simple, easy to use APIs in Lua and you could also create very complex APIs, which may involve object oriented concepts (such as the difference between . and :) or functional APIs with closures and passing around functions as function arguments, etc. Whether the user is able to properly use and understand the language to do the task at hand depends largely on the API as much as or more so than the language.
I do believe Lua is an easier language to learn than many others, like Ruby and Python (and obviously Perl). Lua's grammar and syntax are more consistent than Ruby's for instance; in Ruby you have so many reserved keywords, plus all sorts of symbols (curly-brackets for blocks and pipes for local variables etc), plus it gives you too many options (you can either use curly-brackets for blocks, or you can use the keywords do and end to start and end blocks).
I believe that for non-programmers Lua is much easier especially because of the reasons outlined above. As for programmers, I've read many people say this very same thing and I agree: programming in Lua is very pleasant. I believe that's also because of what I said above.
It probably is becausee its very similar to Python:
The number of universities using Python in there introductory Comp Sci courses is probably the highest of any language (empirically through google). Second probably being Java and Scheme.
The number of Python libraries is astronomical. And the number of people that know the language is quite high thus if you hire a new person there is a good chance they have seen the language before.
Ironically I have grown to not like the language so I am not saying this because I am python fan boy.
As long as you clearly explain to the testers the pitfalls that they may face when debugging in LUA it shouldn't be harder than learning the programming basics of any other language.
What goes through my mind is the situation where the tester made a typo and wrote a different, yet almost unnoticeable, name for a variable. The new variable will be created with the given value but the old variable won't be modified. That sort of thing can be pretty hard to debug when people are not extremely aware of it.
I'm a programmer for more than ten years.
I've learned and used different programming languages.
I've heard about Lua in different occasions, but I've never used it before.
Recently, I decided to learn Lua because our customers are using it.
After spending days on reading the PiL, it turned out for me that Lua is a powerful, flexible, yet sophisticated programming language.
From a software developer point of view, I don't think it's easy for me to be a good coder in Lua in a short time.
But if you just want to 'do something' with Lua, especially if you are from a background of non-programmer, you may feel pleased with Lua, which may be much easier to write some ready-to-use code than some 'traditional' language such as Java, C/C++, Python, etc.
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.