Lambda the Ultimate

Although off topic for LtU, it does help those of us who have been "enlightened" understand one reason why Java/C# are so popular and hence be a little more patient. Maybe the managers do "get it" and we're the ones that don't.

On the other hand, it would be great if there was a way to successfully create a team that could handle a more "elegant" language such as Haskell, Lisp, or O'Caml.

If this is off topic... where does one go to discuss the practical application of programming languages? Recommendations? I'm not only interested in languages for their inherent value and the things I can learn from them, but I'm also interested in "where the rubber meets the road", which is very much what this article was addressing.

I found this article to be quite interesting, in any case, it is yet another quality bit of data on why certain technologies are chosen over others.

So the topic of this thread isn't a problem, but if you don't see how to relate it to LtU threads, and none of the regulars appears here, than I guess it's time to move to comp.lang.misc or whatever.

At the moment, I think the thread can live - but personally, I think many of the idea here where discussed previously (even on LtU), and reading previous dicussions migh be helpful for the discussion.

2) A secondary issue, of course, is the feedback loop. Designs sans implementation, whether done entirely on paper or a whiteboard, or computer-assisted, are inherently untestable (let alone amenable to formal verification in any significant sense).

This may well be the case but if it is it must be fixed. A system level designer must put their design in the terms of the implementation and should provide some testing and verification on some level (ie to ensure that they are geting what they ordered). A good strategy might be to simulate their system in a fast prototyping language. Not the implementation language. If one isn't sure of the system itself it is a mistake to move on to implementation.
Edit: I would like to ammend this statement somewhat. If you are going to try to implement something you don't fully understand, (ie hack it out) do it on the side and don't confuse that with implementation. Such efforts might well lead to good understanding and be the basis of good projects.

Your hiring policy discriminates against highly-qualified people (because you think they're hard to get along with, likely to be unhappy there, or whatever)

I was invited to an interview for a programming position (they contacted me after seeing my "job wanted" ad) a couple of months ago. I think that the interview went very well and they also told me (both in person and in an e-mail) that the interview left a positive picture of me and they were impressed by my experience. Nevertheless, they told me (in the same e-mail) that they can't hire me because they don't have sufficiently demanding work for me and they can't bring in a new programmer due to their project schedules at the moment. Sounds fairly reasonable?

Well, about a month later the same company starts advertising for a "demanding" programming position. The requirements, qualifications, experience, etc... that they call for in their advertisement basically match me almost perfectly. I know how this sounds, but I'm not imagining things; the job description is virtually identical to the one I had (for 5 years, succesfully) before I went back to the university to continue my studies. I asked them whether the situation has changed. The reply I received said that they decided not to hire me due to my "interest in fairly theoretical subjects, research, and interest in getting a PhD" and can't reconsider.

Duh. Next time I just have to be silent about my interest in PLT.

Actually, it's a little more complex than you're assuming.

"they think that ten minimally-skilled programmers each earning $75k/year will collectively be more productive than three more-skilled programmers each earning $250k/year. (I'm using Silicon Valley figures here. Adjust as appropriate.) Is that true?"

No. It is not true. And I think, surprisingly, that no software manager thinks it is true. They do think, however, that the Mongolian Horde will do enough to get by on, and find it hard to justify the extra spending. When you are in numbers as low as 3 or 4, it is hard to scale linearly in productivity; each person bring expertise and experience, which overlap and overlap increasingly. The horde have no expertise to overlap. They just pile it on, and rely on the architect/manager at the top to take up the slack. The said person more often just wants to live, and not risk their career on "interesting" choices. Perhaps the trick is to eliminate the architect/manager, and replace it with a small team of crack experts? Or is that just XP?

Is that there is no problem at all. Software engineering is just that...engineering. What it is *not* is art. Thats why you hire artists to design very expensive buildings and architects to design strip malls. You simply cannot afford to hire PL divas to write your average business software. The software itself isn't worth the cost of a handful of Scheme experts writing a program in half the lines it would have taken Java programmers. In the same way, your average Midas dealer is not going to hire the pit crew of a Formula One team to change the oil on their customer's cars, no matter how qualified the mechanics. It's all simple economics. The market can only support a limited number of high quality programmers, and the rest can fend for themselves or settle for a mediocre job. Anyone who thinks the software industry is somehow unique in this area should try working a different job for a while. It's got nothing to do with complexity and everything to do with the almighty dollar. The average software produced by the software industry is no worse than the average car produced by the auto industry or the average house produced by the construction industry. It's just that people who happen to be highly qualified in their field tend to look down their noses at people who are only good enough to produce mediocre work. It's true of car designers, clothes designers, chefs, and programmers.

Actually, you hire architects to design both your fancy skyscraper and your garden-variety strip mall; but the architect you choose for your fancy skyscraper will likely be a different one (and a well-known artiste, which is what you were getting at) then the competent-but-not-famous architectural firm that will be designing the strip mall.

That said, there is a strong opinion among "star" programmers that the most economical way to design software is to hire a small team of such stars (I'll avoid the word "diva" because that term implies arrogance and unprofessionalism as much as it implies greater skill), rather than a larger team of junior programmers. The problem, as you state, is that there aren't enough star programmers to go around--they're a relatively scarce resource. Most projects can't wait while such a team is assembled. Plus, most HR departments (and even many programmers!) have a hard time telling the difference, especially after the typical job interview. After all, people don't put "code monkey" or other such pejoratives on their resumes.

The other point to me made, is that in many cases mediocre work is ''acceptable''. While the mechanics at the dealership will likely be better at changing your oil than the folks at Jiffy Lube, and everyone has heard horror stories about Jiffy Lube installing the wrong oil filter, etc... most oil changes there are uneventful.

In many cases, the difference between a star and an average programmer is not the quality of the code (the end user only cares, "does it work?"), but the chances of success.

We posted several examples of companies taking advantgae of FP, for example, to gain competitive advantage in the past.

Joel Reymont wrote a blog post about his Erlang OpenPoker server that is demonstrably superior to existing Java solutions.

All of the vendors I have spoken with are having scalability and fault-tolerance problems. None of the vendors are willing to switch to Erlang due to being heavily invested in Java.

[edit: fixed the url]

Your second link just points to LtU, so I can't follow that. But in any event, has anyone demonstrated that the languages make the difference in the products, and not the programmers? Obviously, people willing to learn Erlang have a little more motivation and patience than people who might have gone to a tech school for a few years or just learned Java on their own.

For example, in the GUI front, the .NET API follows Windows conventions: widget events are sent to their parent forms, instead of being 'signals' to the outter world.

I'm not sure what you mean when you say that "Events are sent to their parent forms". Events in C# (.NET in general) follow a publisher subscriber model. You use an overloaded operator += to subscribe to events in C# and AddHandler keyword in VB.NET. The "event" keyword is nothing more than delegates with visibility modifiers. Delegates themselves are nothing more than type-safe method references (function pointers in c).

Model-view-controller apps can not be easily done with C#, even though C# has an 'event' construct.

I'm not sure why MVC would be any harder to implement in C#. And what does an event keyword have anything to do with MVC?

Much of the code is still written inside forms, as in VB 6, thanks to that little detail.

A Windows Form is nothing more than a class file coupled with a "resource file" which is an XML file that has some basic settings information. No GUI program logic goes into the resx file. It's all defined in the class so I'm not sure what you mean when you say "code is written inside forms"

You can have a fully functional GUI program running without ever using the Visual Studio Designer. For example this is all you need to get a windows application.

using System;
using System.Windows.Forms;

public class HelloWorldForm : Form {
    [STAThread]
    public static int Main(string[] args) {
        Application.Run(new HelloWorldForm());
        return 0;
    }

    public HelloWorldForm() {
        this.Text = "Hello World";
    }
}

I'm not sure what you mean when you say that "Events are sent to their parent forms". Events in C# (.NET in general) follow a publisher subscriber model. You use an overloaded operator += to subscribe to events in C# and AddHandler keyword in VB.NET. The "event" keyword is nothing more than delegates with visibility modifiers. Delegates themselves are nothing more than type-safe method references (function pointers in c).

.Event notifications are sent to a widget's owner form.

I'm not sure why MVC would be any harder to implement in C#.

Because .NET widgets are not views of models. For example, a CheckBox is not a view of a boolean model.

And what does an event keyword have anything to do with MVC?

Because MVC depends on the publisher/subscriber model, which in turn is made easier with the existance of 'event': models expose events, views bind themselves to those events, controllers invoke those events by modifying the models.

It's all defined in the class so I'm not sure what you mean when you say "code is written inside forms"

I mean that code for a button click is written inside a form, because the button widget sends a click event to its parent.

Here is the code that is created with one form and one button from VS 2003:

using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;

namespace WindowsApplication1
{
	/// 

	/// Summary description for Form1.
	/// 
	public class Form1 : System.Windows.Forms.Form
	{
		private System.Windows.Forms.Button button1;
		/// 

		/// Required designer variable.
		/// 
		private System.ComponentModel.Container components = null;

		public Form1()
		{
			//
			// Required for Windows Form Designer support
			//
			InitializeComponent();

			//
			// TODO: Add any constructor code after InitializeComponent call
			//
		}

		/// 

		/// Clean up any resources being used.
		/// 
		protected override void Dispose( bool disposing )
		{
			if( disposing )
			{
				if (components != null) 
				{
					components.Dispose();
				}
			}
			base.Dispose( disposing );
		}

		#region Windows Form Designer generated code
		/// 

		/// Required method for Designer support - do not modify
		/// the contents of this method with the code editor.
		/// 
		private void InitializeComponent()
		{
			this.button1 = new System.Windows.Forms.Button();
			this.SuspendLayout();
			// 
			// button1
			// 
			this.button1.Location = new System.Drawing.Point(56, 88);
			this.button1.Name = "button1";
			this.button1.Size = new System.Drawing.Size(120, 64);
			this.button1.TabIndex = 0;
			this.button1.Text = "button1";
			this.button1.Click += new System.EventHandler(this.button1_Click);
			// 
			// Form1
			// 
			this.AutoScaleBaseSize = new System.Drawing.Size(5, 13);
			this.ClientSize = new System.Drawing.Size(292, 273);
			this.Controls.Add(this.button1);
			this.Name = "Form1";
			this.Text = "Form1";
			this.ResumeLayout(false);

		}
		#endregion

		/// 

		/// The main entry point for the application.
		/// 
		[STAThread]
		static void Main() 
		{
			Application.Run(new Form1());
		}

		private void button1_Click(object sender, System.EventArgs e)
		{
		
		}
	}
}

Although the button has a click event, VS sets the form as the button click handler. And since this is the default, I've seen many apps where controller code is written inside the 'button1_Click' method.

Java Swing and Windows Forms are like brothers

They aren't, really. Did you know that if you create an object, you have to create the control as well, as in MFC? here is a piece of documentation from MSDN:

The CreateControl method forces a handle to be created for the control and its child controls. This method is used when you need a handle immediately for manipulation of the control or its children; simply calling a control's constructor does not create the Handle.

You can find it here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwindowsformscontrolclasscreatecontroltopic.asp

I think there should be languages simple and unsubtle enough that the average McDonald's employee is able to use them

Yep! Languages that don't involve explicit computation. SQL, CSS, .htaccess. No explicit computation == no subtle bugs.

The hard part is factoring those languages out, and wrapping them up so that no loose ends stick out.

What if SQL was e.g. a mini-language on top of Haskell? The users would have to deal with Haskell's error messages. Better leave SQL in the string form, and write specialized parsers - heavyweight, yes, but this gets us some portability across host languages and databases.

My term for this phenomenon is "macro system". If system A is embedded in system B and can't be fully understood (errors, corner cases etc.) without first grokking system B, I call system A a "macro system". A simple example: C preprocessor macros. An even simpler example: when you construct a Regexp object in Java, you need to escape backslashes, because Java string literals use backslashes as escapes too... so, how do I match a literal backslash?

In summary, layering may be good, but layering with macro systems (and embedded DSLs) is very hard to get right. Better go all the way and separate the DSL from the host language.

The HaskellDB library for Haskell is a database 'unwrapper', meaning that it exposes more of the set theory behind databases... I wrote a long description of the good points of HaskellDB, but I'll just put that off-topic bit into my blog and stick to the subject...


I think SQL makes an excellent mini-language on top of Haskell, but I agree that doesn't make life easier for non-Haskell languages.


For the layered systems I described, I did mean DSLs that appear to be completely different languages. Look at Perl6 on top of Haskell for example.


I wonder if your point about explicit computation implies that dataflow programming might be easier for non-professional programmers? I'll have to think about that.

Kimberley Burchett summed it up pretty well:

avoid computation

avoid indirection

Maybe it's dataflow. I think not. My personal hunch is that end-user programming should avoid the notion of time; Excel, CSS and SQL are very "static" artefacts. Time is too complex even for professional programmers.

As for HaskellDB, yes, I'm well aware of that. The main point is, it doesn't make life easier for non-Haskell programmers.

*Further OT warning*

As shapr might already know, I love HaskellDB. To me, it is what SQL should have been. I still have some issues with HaskellDB, but those are more difficult to solve, and it would involve serious engineering; in particular, to do with extending the types and functions into the database layer directly. I've always thought that the biggest problem with SQL was the complete dominance that it exerted over you. You think you're using it to solve a problem, but instead you end up fitting your problem so that you use it.

But I suspect that's the Haskell in me talking; making DSLs or combinator libraries in Haskell is so much fun that I think everyone should do it. In particular, it helps you to find the fundamental pillars against which your entire system/problem field rests.

I have two issues with the concept:

Writing a good DSL is hard. Really hard. Much harder than coming up with a good library (in the sense of other languages). A DSL is imbedded, and furthermore, it needs to be extensible; the L bit of the name is a clue that it needs to do things the designer didn't think of, and that's a piece of art that I would trust very few people in the world to.

Using a (good) DSL is easy, too easy. Okay, that's just baiting and self-indulgence, but I will explain. I personally think that a DSL is usually created to do one thing, and one thing well. Most DSLs have fairly narrow uses, and it is obvious that they are designed with certain use patterns in mind. The problem is that the effort doesn't pay off. I can get lots and lots of people to use a DSL; there are plenty of people capable of being a MacDonalds employee. However, I don't have enough real problems to solve that I can use them. But to solve these problems will need 1 or even 2 or 3 DSLs -- at which point hiring one guru per DSL isn't economically sensible if I only need one Macki-D employee to use them to solve the problem. There is a numbers inversion. The tools are so good, everyone can use them; but they need too great a cost to get up and going, compared to piling on the "certified" programmers.

The case of Perl6 is far enough in the other direction (and, let's face it, it was never going to get started in Perl5...) that it is worth the effort. But, for instance, I need something to help with planning pharmaceutical QC testing -- I'm not sure that the market would be large enough to make it worthwhile.

Most DSLs have fairly narrow uses, and it is obvious that they are designed with certain use patterns in mind. The problem is that the effort doesn't pay off. I can get lots and lots of people to use a DSL; there are plenty of people capable of being a MacDonalds employee. However, I don't have enough real problems to solve that I can use them.

What about web applications? In my opinion, web applications are a great domain for the use of DSLs. They are typically short lived and yet abundant. You most certainly wouldn't want an expert programmer writing a web applications, because they are too rare and too expensive. Seems like a domain were the layered approach would work rather well.

Now, I'm young and fairly ignorant, but I'm sure there are other domains where using a layered approach, as Mr. Erisson proposed, could be very beneficial.

For example, in the domain of web programming--HTML and its follow-ons.

It's a DSL which has been so successful, that it is seldom recognized as such. It is one of the key fabrics of the Web; it's one that many non-programmers (folks who don't write code in general-purpose languages) can use, and it's also successful as a target for higher-level authoring tools.

There are many, many, many other successful DSLs out there, but many of them seem to be ignored by the PLT community, especially those whose business is DSLs and metaprogramming. Why?

The vast majority (almost all) successful DSLs out there are standalone DSLs. Such languages have no dependency on a host language--and can be implemented in any language you like. Many are commonly implemented in things like C/C++ or Java--languages considered to have poor meta capabilities--using standard PLT design techniques. In other words, they're implemented in the same fashion as a general-purpose language compiler: from scratch. None of 'em, except possibly for lex and yacc, are intimately tied to any host programming language--and none of them are typically implemented using macros, metaprogramming, or any of the other PLT features advocated for DSL construction. Virtually all of them are implemented using a separate standalone interpreter--their implementation consists of a front-end parser and a semantic engine of some sort. And parsers are FTMP a solved problem in computer science, which we've long known how to automate the construction of.

Of course, there are may be a large number of successful language-hosted DSLs out there in industry and academia; but many of them are proprietary--and intended for programmers, rather than for Web authors and such. For languages intended for domain experts rather than programmers, dependence on (or tight integration with) a host programming language is probably a disadvantage.

A second attribute of DSLs which are popular among non-programmers is that they're declarative--which is why, I suspect, that many people don't consider their use to be "programming". But that topic is largely orthogonal to how the DSL is implemented.

While the theoritician and PLT geek in me thinks languages with advanced metaprogramming capabilities are cool; the proactical industrial programmer in me realizes that nothing requires me to use my primary development language for DSL construction. So the lack of good meta-capabilities in, say, C, is not necessarily a disadvantage--I can implement the parts in C that need to be implemented in C for whatever reason, and do my DSL in something else. Whether a conveninent HLL (perl is a popular choice in industry for this sort of thing); a standalone macro processor (a good one like m4), or tools like lex/yacc--there are lots of choices.

You have a good point, what do you like or dislike about Java? Why would Haskell, OCaml, Scheme, or other oft-mentioned LtU language be a better replacement for anyone?



I'll post my own answer soon, I just have to finish some other stuff first...

Is basically that it actively stops me doing anything someone else didn't think is a good idea. C++ is almost the same, before the generics/template metaprogamming people showed us the way. Lisp and Haskell obviously excel in this area, but then they are considered too obtruse by the average programmer. With great power comes great responsibility, as a wise man once said. In my experience, responsibility is the hardest thing to master. Code which (one hopes) will do more greatness than one can imagine at the moment carries more responsibility, proportionally. Flexibility in the way that Lisp and Haskell are gives with one hand and takes away with the other. I guess a central question I have is how do we find a middle ground? Or even a gradient that will be comfortable? It may be useless for us to discuss this; if you can understand monads and transformers you probably can't feel the difference between recursion and iteration. We can, however, come up with tests and criterions, so that sampling "the masses" will come back with a conclusion. Otherwise, in the empty philosophical ranglings we will be no better than those before Galileo, who decided the laws of physics by which ones sounded more probable.

The technical criticisms of Java are well-understood by most of us. What David was pointing out, is that your post is full of flamebait phrases like:

* X "sucks"
* X (programmers are) "LoC mincers" and "monkeys"
* X is "botched and bangled"
* X is a "lowest common denominator".

None of those comments says anything constructive or useful; and the first two are rather inflammatory--especially the suggestion that most industrial programmers are "monkeys". (The industrial programmer might retort that FP advocates are "eggheads" and such; that would be equally inflammatory).

Your post does include valid technical criticisms of Java as well (as well as some personal obervations that while strictly anecdotal in nature, do not rise to the level of flamebait).

At any rate, there still remains the fact that most industrial programming shops do not consider things like Haskell, ML, or Scheme to be suitable tools for their development (whether in-house, or for software which is sold to others). Much has been said about why this state of affairs exists; ranging from accusations of widespread industrial incompetence, to accusations of poor-quality tools from the "academic" community, etc. And has been mentioned several times in the past; there is quite a bit of mutual distrust between academia and industry in our discipline, far more than is healthy. Rants about "code monkeys" and such don't help matters much.

I should note that virtually every online forum in which programming is a topic, from LtU to slashdot to cliki to c2 to comp.object, will contain similar rants. It seems to be a curse of the discipline that the vast majority of programmers consider themselves, like the children in Lake Wobegon, to be above average. And in all of these forums; it is often proposed that tool choice is an excellent way to separate wheat from chaff--the only point of disagreement is which tools are wielded by the masters, and which by the "monkeys".

As David points out earlier, there is a divide between the costs of Scheme divas and engineering projects; and, as you point out, many wish for there to be a way to seperate the classes. I disagree with David on that point, and I agree with your point (that many propose so), but disagree with them (as perhaps you yourself do, if I read your implicit critisms).

David points out that the you hire artists to build "expensive buildings" and engineers to build strip malls, in the same way that you get Scheme divas to build expensive and pretty software and Java engineers to build business software. However, I feel that there is a subtle and important distinction. In the former, the aesthetics are just that -- aesthetics. They don't affect the purpose of the building, which is presumably to house something. They are just status symbols and sociological features. In software, there is a subtle, but I think, important link. In opposition to David's point, software _is_ complex; I stand by my contention that it is more complex than other engineering fields. Part of this complexity is the need to change, and flow with the changing demands that customers and market needs. When changes are needed, an understanding of the system as a whole is needed, and understanding something so complex is difficult, if not impossible. So things like "elegance" subtly encode important features of the system, like orthogonality or symmetry. The link is thin, but I think the intuition of an "artiste" as David calls them, is the finest gauge of the dynamic potential of a software system that we have. So the first question is: does the LtU have any idea whether such a measure can be established with something more scientific than the wane and wax of the divas?

On the differentiator between the masses and the geniuses: I think there is a divide, but it is porous. I went through PL via C, asm, Prolog, Java, C++ (which, incidentally, I thought was an improvement over Java), Haskell, Python, and then just everything under the sun. No one stands still. Everyone is a dynamic entity that flows through the world. The supposed divide appears to me to be then a sort of right of passage to "adulthood"; the question is then whether this is optimal. I think that it is not. Something like Java constrains a person's development; my anecdote is getting a friend to understand C++ destructors after lots of Java experience. It took over several months for him to see how destructors are useful, for more than mere memory management. At the risk of sounding like a pounce, I hate Java because I think it kills the birds that could fly. You never know how far a person can go without letting them try. The barrier of a language change, especially the first one, is mostly syntactical, and is enough to put many off; therefore I think it is most important that there can be a gradient within a single language, one that fosters development of the developer. So the second question to LtU: is there such a language? If not, what is missing from exitsting languages such that there could be one?

"In software, there is a subtle, but I think, important link. In opposition to David's point, software _is_ complex; I stand by my contention that it is more complex than other engineering fields."

Hear, hear! So maybe we should be looking for super smart and experienced and balanced developers who at the same time have the smarts to stick to e.g.: simple Java? That way things don't get out of hand, and there's a chance that the system can be maintained by mere mortals in the future.

My entire point is that we need tools to help us manage the complexity, not that we all need a career change short of an IQ hike. This is looking from the point of someone who finds understanding usual software systems difficult, and so would be a willing client of such a technology. Limiting the workforce is limiting the number of problems that you can tackle at the same time as an industry; and it would not be feasible anyway. Maybe it is a little overbroad to state that software engineering is more complex than all other engineering fields; rather it is more complex in one specific way, and that is the layers of structure in a typical project. The very non-physicality of software means that we are not constrained by physical limits (in a practical way, short of exceeding the entropy limit of the universe). We naturally build on top of existing, tall structures, and we do so as much as possible. I would like my language to help me do that, and not be a pain that I constantly work around.

I stand by my contention that it is more complex than other engineering fields. Part of this complexity is the need to change, and flow with the changing demands that customers and market needs. When changes are needed, an understanding of the system as a whole is needed, and understanding something so complex is difficult, if not impossible.

...therefore I think it is most important that there can be a gradient within a single language, one that fosters development of the developer. So the second question to LtU: is there such a language? If not, what is missing from exitsting languages such that there could be one?

I would like to take a wild guess at what is going on here. In other forms of engineering design and implementation are separate. This is necessary because the idea (the thing as it should be) is easily separated from the thing (ie the office building). Engineers wouldn’t dare to implement anything without complete drawings of what they are going to build. This normally includes every piece of wire and what lugs to use on the ends and even nuts and bolts. Engineers traditionally do this on a drawing board but now days have wonderful computer aided tools.

It seems that software engineering has not evolved to the point where it can do the same thing. You can’t sit down and design something that has a high probability of working. I suspect that this has something to do with software itself. The idea and the implementation get completely mixed up. Using the above analogy this might be addressed by better “languages” and abstractions. Electrical engineers work with definite set of things such as resistors, capacitors, wires, transistors, etc., and they have a language of how these things go together. The same is true of other engineering fields. But software languages don’t do this. It is a bit of a puzzle actually.

Electrical engineers work with definite set of things such as resistors, capacitors, wires, transistors, etc., and they have a language of how these things go together. The same is true of other engineering fields. But software languages don’t do this. It is a bit of a puzzle actually.

It's not puzzling at all. There's nothing surprising or mysterious about Java's popularity if you have had to work in the coding trenches for any amount of time. People building Chevys go to the parts bin, grab a handful of standard-size bolts and nuts, and crank away at a manufactured car body. People using Java go to java.sql.* or javax.* or com.favlibauthor.* and grab a handful of standard components and crank away at their manufactured business app. People building Ferraris fire up the machine shop and build custom components to exacting specifications, putting everything together by hand. The product is a very fine, very fast, very high quality, and very expensive car. People using Haskell or Erlang or O'Caml fire up their algebraic types and their higher-order functions and build many things from scratch because there isn't a convenient yet mediocre quality library to do it for them. The result is beautiful, powerful, high-quality code that is also very expensive. C++ is somewhere in between. You typically build things like Camaros and Mustangs with it...they aren't always the prettiest cars on the road, but with some tweaking and getting your hands fairly dirty, you can make them pretty darned fast. Popularity has little to do with fundamental capability and a lot to do with standardized components. Nobody wants to reinvent wheels any more. The average programmer really doesn't give a rip if you can transform a loop into a foldr. What he cares about is whether you can perform a file transfer in two lines with a prefab FTP library, or pop an embedded browser with a minimum of effort. This is part of the disconnect between academia and industry. Writing a loop takes seconds, minutes if it's really tricky. Writing a library takes weeks or months.

Haskell doesn't have all the libraries Java has, that's true.

But it's fifty two lines for the tutorial version of the embedded browser and eight lines for a simple FTP transfer.


Maybe the problem is that people don't know which libraries exist?

That's soon to be fixed too, there's an apt-get style tool for Haskell that works, but isn't finished.


I won't claim to be the average programmer, but I am self-employed and self-taught. I do not have formal CS education, but I have gotten paid for a couple of Haskell contract jobs so far, and I expect to get paid for more in the future. I believe that the Haskell/Erlang/OCaml approach is the best way to deliver value to my customers, and I am putting my money where my mouth is.

That is quite possible.

I must admit that, thanks to this discussion, I'm coming to revise my prior judgement -- that is, I was believing in my superiority w.r.t. Java programmers.
Of course, in my vanity, I still consider myself superior. But now, it's because I have experience with several mindsets :)

More seriously, I'm thinking of current university students, who are being taught nothing but Java. I concur that Java is important, for pragmatic reasons, one of the, being the notion of "components" you underline. If they leave university without knowing that any other set of components exist, they stand the chance of staying code monkeys. Not that Java is any bad, mind you, just that they will lack scientific culture.