Related
I'm architecturing a Multi Agent System (MAS) framework to describe Beliefs-Desires-Intents (BDI) agents in Haskell (i.e. agents are concurrent, communicating monadic actions).
I searched on the web throughly but I wasn't able to find any reference on similar works, apart from a technical report of an unfinished work, Specifying and Controlling Agents in Haskell.
Do you know about any existing implementation or research paper dealing with BDI agents that can be defined in Haskell or in any other functional language, please?
My aim is to find possible related works, everything that could manage a system of concurrent intelligent agents written in a functional language. I don't need anything specific, I just want to find out whether my work has something in common with existing approaches.
edit: I managed to find a reference to Clojure, a lisp dialect that supports a form of agent programming very close to the actor model, but it's not meant to directly support BDI agents (one should implement another layer on top of it to get the BDI part done I guess).
To sum up, it doesn't seem like there are proposals for BDI-style communicating agents described by means of functional languages, so together with a friend/colleague of mine we collected info about related work, put together some ideas, and we wrote a short position paper that I will present at the DALT2012 workshop. It's a really preliminary work, so do not expect too much from it, but I think in the future it may evolve in something interesting.
Alessandro Solimando, Riccardo Traverso. Designing and Implementing a Framework for BDI-style Communicating Agents in Haskell. DALT 2012, Workshop notes, pages 108--112.
EDIT:
I later found this project on GitHub, which uses free monads (whatever that means, I don't know about them) to provide a framework for multi-agent systems: https://github.com/fizruk/free-agent.
I am working on a new language, targeted for web development, embeding into applications, distributed applications, high-reliability software (but this is for distant future).
Also, it's target to reduce development expenses in long term - more time to write safer code and less support later. And finally, it enforces many things that real teams have to enforce - like one crossplatform IDE, one codestyle, one web framework.
In short, the key syntax/language features are:
Open source, non-restrictive licensing. Surely crossplatform.
Tastes like C++ but simpler, Pythonic syntax with strict & static type checking. Easier to learn, no multiple inheritance and other things which nobody know anyway :-)
LLVM bytecode/compilation backend gives near-C speed.
Is has both garbage collection & explicit object destruction.
Real OS threads, native support of multicore computers. Multithreading is part of language, not a library.
Types have the same width on any platform. int(32), long(64) e.t.c
Built in post and preconditions, asserts, tiny unit tests. You write a method - you can write all these things in 1 place, so you have related things in one place. If you worry that your class sourcecode will be bloated with this - it's IDEs work to hide what you don't need now.
Java-like exception handling (i.e. you have to handle all exceptions)
I guess I'll leave web & cluster features for now...
What you think? Are there any existing similar languages which I missed?
To summarize: You language has no real selling points. It just does what a dozen other languages already did, with syntax and semantics just slightly off, depending on where the programmer comes from. This may be a good thing, as it makes the language easier to adapt, but you also have to convince people to trouble to switch. All this stuff has to be built and debugged and documented again, tools have to be programmed, people have to learn it and convince their pointy-haired bosses to use it, etc. "So it's language X with a few features from Y and nicer syntax? But it won't make my application's code 15% shorter and cleaner, it won't free me from boilerplate X, etc - and it won't work with my IDE." The last one is important. Tools matter. If there are no good tools for a language, few people will shy away, rightfully so.
And finally, it enforces many things that real teams have to enforce - like one crossplatform IDE, one codestyle, one web framework.
Sounds like a downside! How does the language "enforce one X"? How do you convince programmers this coding style is the one true style? Why shouldn't somebody go and replace the dog slow, hardly maintained, severly limited IDE you "enforce" with something better? How could one web framework possibly fit all applications? Programmers rarely like to be forced into X, and they are sometimes right.
Also, you language will have to talk to others. So you have ready-made standard solutions for multithreading and web development in mind? Maybe you should start with a FFI instead. Python can use extensions written in C or C++, use dynamic libraries through ctypes, and with Cython it's amazingly simple to wrap any given C library with a Python interface. Do you have any idea how many important libraries are written in C? Unless your language can use these, people can hardly get (real-world) stuff done with it. Just think of GUI. Most mayor GUI toolkits are C or C++. And Java has hundreds of libraries (the other JVM languages profit much from Java interop) for many many purposes.
Finally, on performance: LLVM can give you native code generation, which is a huge plus (performance-wise, but also because the result is standalone), but the LLVM optimizers are limited, too. Don't expect it to beat C. Especially not hand-tuned C compiled via icc on Intel CPUs ;)
"Are there any existing similar
languages which I missed?"
D? Compared to your features:
The compiler has a dual license - GPL and Artistic
See example code here.
LDC targets LLVM. Support for D version 2 is under development.
Built-in garbage collection or explicit memory management.
core.thread
Types
Unit tests / Pre and Post Contracts
try/catch/finally exception handling plus scope guarantees
Responding to a few of your points individually (I've omitted what I consider either unimportant or good):
targeted for web development
Most people use php. Not because it's the best language available, that's for sure.
embeding into applications
Lua.
distributed applications, high-reliability software (but this is for distant future).
Have you carefully studied Erlang, both its design and its reference implementation?
it enforces many things that real teams have to enforce - like one crossplatform IDE, one codestyle, one web framework.
If your language becomes successful, people will make other IDEs, other code styles, other web frameworks.
Multithreading is part of language, not a library.
Really good languages for multithreading forbid side effects inside threads. Yes, in practice that pretty much means Erlang only.
Types have the same width on any platform. int(32), long(64) e.t.c
Sigh... There's only one reasonable width for integers outside of machine-level languages like C: infinite.
Designing your own language will undoubtedly teach you someting. But designing a good language is like designing a good cryptosystem: lots of amateurs try, but it takes an expert to do it well.
I suggest you read some of Norman Ramsey's answers here on programming language design, starting with this thread.
Given your interest in distributed applications, knowing Erlang is a must. As for sequential programming, the minimum is one imperative language and one functional language (ideally both Lisp/Scheme and Haskell, but F# is a good start). I also recommend knowing at least one high-level language that doesn't have objects, just so you understand that not having objects can often make the programmer's life easier (because objects are complex).
As for what could drive other people to learn your language... Good tools/libraries/frameworks can't hurt (FORTRAN, php), and a big company setting the example can't hurt (Java, C#). Good design doesn't seem to be much of a factor (a ha-ha-only-serious joke has it that what makes a language successful is using {braces} to delimit blocks: C, C++, Java, C#, php)...
What you've given us is a list of features, with no coherent philosophy, or explanation as to how they will work together. None of the features are unique. At best, you're offering incremental improvements over what's already there. I'd expect there's already languages kicking around with what you've said, it's just that they're still fairly obscure, because they didn't make it.
Languages have inertia. People have to learn new languages, and sometimes new tools. They need incentive to do so, and 20% improvement in a few features doesn't cut it.
What you need, at a minimum, is a killer app and a form of elevator pitch. (The "elevator pitch" is what you tell the higher-ups about your project when you're in the elevator with them, in current US business parlance.) You need to have your language be obviously worth learning for some purpose, and you need to be able to tell people why it's worth learning before they think "just another language by somebody who wanted to write a language" and go away.
You need to form a language community. That community needs to have some localization at first: people who work in X big company, people who want to do Y, whatever. Decide on what that community is likely to be, and come up with one big reason to switch and some reasons to believe that your language can deliver what it promises.
No.
Every buzzword you have included in your feature list is an enormous amount of work to be spec'd, implemented, documented, and tested.
How many people will be actively developing the language? I guess the web is full of failed programming language projects. (Same is true for non-mainstream OSes)
Have a look at what .Net/Visual Studio or Java/Eclipse have accomplished. That's 1000s of years of specification, development, tests, documentation, feedback, bug fixes, service packs.
During my last job I heard about somebody who wrote his own programming framework, because it was "better". The resulting program code (both in the framework and in the applications) is certainly unmaintainable once the original programmer quits, or is "hit by a bus", as the saying goes.
As the list sounds like Java++ or Mono++, you'd probably be more successful in engaging in an existing project, even if it won't have your name tag on it.
Perhaps you missed one key term. Performance.
In any case, unless this new language has some really out-of-this-world features(ex: 100% increase in performance over other web development languages), I think it will be yet another fish in the pond.
Currently I'm responsible for maintaining a framework developed/owned by my company. It's a nightmare. Unless there is a mainstream community, working on this full time, it's really an elephant. I do not appreciate my company's decision to develop its own framework(because it's supposed to be "faster") day 'n night.
The language tastes good in my opinion, I don't want use java for a simple website but I would like to have types and things like that. ASP .NET is a problem because of licensing and I can't afford those licenses for a single website... Also features looks good
Remember a lot of operator overloading: I think is the biggest thing that PHP is actually missing. It allows classes to behave much more like basic types :)
When you have something to test I'll love to help you with it! Thanks
Well, if you have to reinvent the wheel, you can go for it :)
I am not going to give you any examples of languages or language features, but I will give you one advice instead:
Supporting framework is what is the most important thing. People will tend to love it or hate it, depending on how easy is to write good code that get job done. Therefore, please do usability test before releasing it. I mean ask several people how they will do certain task and create API accordingly. Then test beta API on other coders and listen carefully to their comments.
Regards and good luck :)
There's always space for another programming language. Apart from getting the design right, I think the biggest problem is coming across as just another wannabe language. So you may want to look at your marketing, you need a big sponsor who can integrate your language into their products, or you need to generate a buzz around it, easiest way is astroturfing. Good luck.
http://en.wikipedia.org/wiki/List_of_programming_languages
NB the names G and G++ aren't taken. Oh and watch out for the patent trolls.
Edit
Oops G / G++ are taken... still there are plenty more letters left.
This sounds more like a "systems" language rather than a "web development language". The major languages in this category (other than C++/C) are D and Go.
My advice to you would be to not start from scratch but examine the possibility of creating tools or libraries for those languages, and seeing just how far you can push them.
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).
With "Polyglot" programming techniques becoming more relevant, it is almost a necessity to use the "right" PL for the problem. However, learning new languages takes time which usually most project team can't afford. What is the best way to learn a new programming language? Is there a common set of problems that can be solved to reach a certain level of competence?
Well, it depends what you want to do. (web, db, whatever).
Generally I'd want to know:
What's the library like, how do I reference it
What ORMs are there
What build/deployment platforms exist for it
How does it handle updates
How do I do general things, like:
DB Access
File things
Display UI's
and so on.
Really, learning is only by doing -- you need a project that you can use the given language for.
Project Euler is the first thing to come to mind as an oft-used set of problems to try in a new language, even if it's not something I've ever tried.
If the language is another JVM or CLR hosted one, the issues about learning the environment can be set aside -- you can use all your familiar APIs in your Clojure/Scala/F#... code -- and concentrate on the syntax and idiom.
Otherwise, you're probably using the new language because it has a good fit for the particular problem you want to solve (e.g. native code and functional -> Haskell; distributed and concurrent -> Erlang) so the fit of the feature set is known in advance but you have the extra load of learning the standard APIs. And that's what prototyping is for.
The book Programming Challenges and the associated website provide a large list of algorithmic problems, with automatic online judging in several languages (Java, C, C++). Any algorithm textbook can give you lots of examples of basic data structures and procedures to try and implement, which is often a nice way to get some practice with basic language syntax and features. My personal favourite for this is The Algorithm Design Manual, which is language agnostic, but there are plenty of good language-specific books available as well (Mastering Algorithms in Perl or Data Structures and Algorithms in Java, for example).
If you're interested in a general set of mathematical problems to try and solve, Project Euler is a great resource.
For more day to day problems, I find the cookbook approach most helpful. For example, both Perl and Python have excellent O'Reilly cookbooks, as well as online resources, which provide short examples of many common and important problems. As mentioned in another answer, the key here is to find canonical examples of basic features you will need, particularly by leveraging what's available in standard libraries. I usually try and build up my own small library of examples as I go along, e.g. a socket example, a DB access example, a file reading example, a simple numerical solver, etc, which I then pillage for ideas when it's time to write production code.
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)