Lambda the Ultimate

inactiveTopic How to make a FPL successful
started 8/6/2003; 7:43:13 AM - last post 8/11/2003; 10:54:55 AM
Daniel Yokomiso - How to make a FPL successful  blueArrow
8/6/2003; 7:43:13 AM (reads: 1188, responses: 31)
As Marc Hamann requested I'll post some of the ideas of how to make a FPL successful. By successful I mean popular within the "masses".

I'm a professional Java developer (whatever it means) -- doing J2EE applications pay my bills -- and there are some (I would say many) places where Java programmers have it easier than FPL users. First a list some major points of Java for newbies (i.e. Java newbies, not PL newbies):

- Sites featuring "technical" articles with code examples, like: Java World, jGuru or OnJava. After going through the language manual or a "Java for dummies"-like book, you don't know how to design programs in Java. Also you don't know how to access SQL and write XML reports in the same program (the tutorial gaves separate examples, and it's very hard to put them together ;). These places provide concrete tutorials and examples of how to use Java to solve your problems. I'm not arguing about the technical quality of these articles, but they do their work. It seems there's always an article to help you, no matter what problem you're trying to solve.
- No compiler specific features. If you compile with Jikes you can use the .class with Sun's JVM. It's very easy to get some jars, put them in your classpath and see it working. You don't need to use make-like utilities if your project is small.
- A large, documented, standard library. No, I'm not talking about a well-designed library. The java.* and javax.* libraries don't provide the best solution, there are few data structures (just sets, maps and lists), no higher-order functions, everything non-trivial needs to be reinvented, but it gives solutions to most business problems. Doing web-stuff, sending emails, accessing RDBMS, working with XML, GUI, etc.. Curiously the support for text processing is almost non-existent, just regular expressions and awful text formatting, but people don't think it's a huge problem.
- Community sites with message-boards. Most programmers don't like to use email-lists or newsgroups, I guess it's harder for them to follow threads without having to use a newsgroup provider. Web forums are very nice for them to follow threads easily and usually provide meaningful answers. The point is there are a lot of such sites and all of they are going well.
- Reflection and Class-loading capabilities. It makes tool writers lifes easier. Application servers and IDEs rely on these features to "do the right thing" with libraries and compiled applications.

Here's the way Java newbies approach a problem: think hard, go to some site trying to find articles related to, ask some forums, find a solution, read the javadocs, get the jars, put them in the classpath, try to run the code examples, tweak the example to fit their needs, code the solution in the application, run and debug it, deploy and test, deliver.

IMO most people are afraid to ask questions, you see it in schools, business meetings, workshops. Sites with articles and examples are useful for common kinds of answers. Also the standard library has a standard way to solve them, so it'll be harder to find an obsolete article or not be able to mix two libraries. Forums are usually easy to search, you don't need to try your luck with mail-list archives or the google groups.

AFAICS you don't need a huge company backing the language to be successful, only a community interested in trying to solve common problems. Get your favourite FPL and ask these questions: are there sites dedicated to publish problem solving articles?, are the compilers all equal or you need to pre-process the sources?, is in the standard library a way to solve common problems (SQL, XML, GUI, internet stuff)?, how many places there are where people can ask questions or search for answers?, how easy is for tool writers to make the compiled applications or packaged libraries "do the right thing"?

Most FPL users are proud to be able to use "fancy" and "elegant" solutions to their problems, to be able to choose which object system they want to use, or to decide between Monadic IO vs. CPS in the same language, depending on the situation. FPLs are designed for people who like that, but the "masses" want to deliver their product without trouble. If you're using scheme and you decide for a particular object system, you'll have to think on how to interact it with the object system of your library. It's not too dificult, but it's a problem that you don't have in Java. In my day job I need to access SQL and write XML reports, not use monadic parser-combinator libraries (but in my night hacking I love to use monads and I'm yet to need to use SQL and process XML ;).

As any language enthusiast I'm always thinking on how to design the "perfect language" but I know that even if I ever achieve it it'll need more than the right set of primitives + syntax + semantics. It needs to be simple to use and to solve my problems with it. Each choice/problem makes it a little bit harder, and sometime it'll be too hard to use.

Sjoerd Visscher - Re: How to make a FPL successful  blueArrow
8/6/2003; 8:09:45 AM (reads: 1190, responses: 2)
There's one more thing: A language must have something to get a community going. A big enough group of programmers has to be forced to use the language.

Java started because it was the only way to program applets. And because it had appeal to, once you had programmed an applet, you might also be thinking about doing something else with it.

Dan Shappir - Re: How to make a FPL successful  blueArrow
8/6/2003; 8:30:53 AM (reads: 1180, responses: 0)
I'm thinking of another attribute: familiarity, even if only at the syntax level. Obviously the closer a new PL is to an existing PL that is already familiar to a large group of users, the greater the likelihood they would be willing to switch.

Thus people went from C to C++ because C++ was a superset of C and they could always just fall back. And Java is so very close to C++, and OOP was already widly known when it came out. Python uses a different syntax but similar semantics, familiar to people who know OOP and have used DT PLs. And so on.

The problem with many FPLs, especially of the pure variety, as that they are just so different. And they require a whole new way of thinking. A good way but a new way. Thus experienced programmer end up feeling stupid when first they use them, and most people don't like feeling stupid, so they blame the PL instead.

Another issue is that, unlike people on this board, most programmers don't switch PLs because it's fun and they want to experiment and learn. They switch PLs because they have to. Thus people will generally only switch to PLs that provide all the tools required to "get the job done", tools that are often not a part of the PL itself, e.g. an IDE (at least a debugger), a good compiler for Windows (or for a VM that runs on Windows) or Linux (or a VM that runs on Linux), a UI designer, code sample, and the rest.

It's therefore my opinion that the best way to introduce programmers to FP is to provide FP features in imperative languages. Happily this is already happening, at least to an extent.

P.S. Obviously if a new PL is too close to an older PL there is no point in switching because they are essentially the same thing.

Also, C# is an exception to this closeness rule since it's a popular new PL that is totally unique and not similar to any existing PL ;-)

Daniel Yokomiso - Re: How to make a FPL successful  blueArrow
8/6/2003; 9:07:54 AM (reads: 1212, responses: 1)
A big enough group of programmers has to be forced to use the language.

Gasp! So people where forced to use Perl? I always thought that no one would use that language by choice ;)

Marc Hamann - Re: How to make a FPL successful  blueArrow
8/6/2003; 9:30:55 AM (reads: 1228, responses: 0)
Sjoerd: A big enough group of programmers has to be forced to use the language.

Daniel: Gasp! So people were forced to use Perl?

I think the "forced to use" aspect (and this applies to Perl) is what is often known as the "killer app" effect.

People discover that the new language makes it easy to do X, and soon that becomes "just the right way" to do X. Then everybody who wants to do X learns the language. (It helps if X is something a lot of people want to do. ;-))

For Perl, it was two things: CGI and the need to transcend the limits of UNIX shell scripting, especially for networked apps (related of course).

For Java, I don't think it was Applets, but server-side distributed computing and n-tier apps.

Pure FPLs (or rather a particular pure FPL) may have their killer app already, it is just that their X is not something with wide appeal. Or it may yet lie in the future.

If "real world" computation continues to get more complicated, the simplifying aspects of FP may win out over the perceived "more complicated" aspects.

Or maybe not. ;-)

Patrick Logan - Re: How to make a FPL successful  blueArrow
8/6/2003; 2:01:54 PM (reads: 1158, responses: 0)
I'm thinking of another attribute: familiarity, even if only at the syntax level.

I think this is a central idea. People seem to be willing to adapt to any kind of new semantics as long as they *think* they think they are in familiar territory.

Stuart Allie - Re: How to make a FPL successful  blueArrow
8/6/2003; 8:44:45 PM (reads: 1161, responses: 0)
So what would a FPL with a "familiar" syntax look like? (And wasn't this what Dylan was partly about?)

Python's lambda, map, reduce and so on make a sort-of functional style possible in a language with C-like syntax. Similarly, perl 6's new subroutne features would make it possible (albeit painful) to do FP-like code in perl.

But I guess this is the opposite of (or maybe orthogoanl to) what we are talking about here: a real FPL with familiar syntax. So, to get back to where I started, what would such a beast look like?

To start the ball rolling, how about C with a built-in type "function", and maybe "list", with lambda, map etc. No "void" type so every function returns something. Hmm, sounds like a cross between C and Python... I'll need to think some more. Can somebody else *please* make a better suggestion?

Dominic Fox - Re: How to make a FPL successful  blueArrow
8/7/2003; 1:26:34 AM (reads: 1133, responses: 2)

Nobody mentioned DrScheme yet? Righty-oh.

I remember reading a few years ago that Microsoft conducted a survey asking existing users of MS Word what features they would like to see added to the next version of that product. A large percentage of the responses identified features that were already present in the current version. I feel much the same way about DrScheme at the moment. Every time I start thinking, "yes, this is great, but what about X", it turns out that X is already available.

What FPLs need is nothing more or less than a large marketing budget, IMHO. When you look at the things VB6 programmers (that includes me, btw) or VC++ programmers using MFC have been prepared to put up with in order to Get Things Done, the obstacles to acceptance posed by "stupid parenthetical syntax" seem trivial - given sufficient marketing push.

<jocularity strength="weak">

One might start by renaming a few things:

Non-determinism sounds like something that breaks out in the office when the manager goes away for the week. Why not call it "Enterprise Intelligence" instead? "Programmers can now concentrate on defining possible scenarios, and let the language itself choose the correct outcome". Brilliant!

Higher-order functions? Sounds scary and mathematical. How about "Flexi-code"? "Programmers can now combine program features with unprecedented flexibility and power. The possibilities are endless!"

And as for those parentheses: "research has shown that curvy brackets are easier on the eye than angle brackets. Consequently, Scheme programmers need to take 15 percent fewer breaks than XML programmers. Plus, their monitors don't wear out as quickly..."

</jocularity>

Ehud Lamm - Re: How to make a FPL successful  blueArrow
8/7/2003; 1:38:38 AM (reads: 1156, responses: 0)
Non-determinism... Enterprise Intelligence

Goal Directed Evaluation is a also a good name for this.

Frank Atanassow - Re: How to make a FPL successful  blueArrow
8/7/2003; 4:22:08 AM (reads: 1118, responses: 1)
I think the differences between FP languages and conventional languages are not so great. FPLs look different largely because they are, on the whole, designed much more carefully, and because FP language designers are less afraid of abandoning cruft which has accumulated on other languages because of historical accidents.

I once had an idea to demonstrate this idea: design two languages, AntiML and CoJava. (Or was it CoML and AntiJava?)

AntiML would be a functional language, ML if it had been badly designed. It would have no type inference, or principal types property, and the type system would be unsafe. The syntax would be verbose, and it would have statement blocks rather than a binary semicolon operator. Maybe it would allow allocating values on the stack, and unsafe operations. Or maybe when a language design issue arised which looked moderately complicated, I would punt it and throw in some dynamic typing. I think the result would be a language which is largely indistinguishable from C or Objective C.

CoJava would be an object-oriented language, Java if it had been designed by an algebraist. I would base the OO semantics on coalgebras, so you would have codatatype declarations dual to ML's datatype declarations. The language would support type inference and principal types; it would be safe. There would be no inheritance. I'm not sure if I would allow subtyping; if I did it would let one type be a subtype of the other when there exists a canonical injection. Perhaps there would be a module system like ML's, or a sophisticated type system like Haskell's. It would allow user-defined infix operators, and have an `expression-based' syntax. It would allow imperative update either in an uncontrolled way like ML, or perhaps in a controlled way like Haskell, but the focus would be on pure functional computation.

And so on...

Marc Hamann - Re: How to make a FPL successful  blueArrow
8/7/2003; 6:37:25 AM (reads: 1145, responses: 0)
I think the differences between FP languages and conventional languages are not so great.

I think you are right if you consider syntax and the superficial semantics. I think that programming in the functional style, which what you mostly do even in "impure" FP languages, is quite a major change of thinking and approach.

Procedural style has a familiar mental model: everyone knows how to follow a recipe or follow instructions for an IKEA shelf (OK, maybe not... ;-) ) Step-by-step changes of state is a normal, everyday approach to complex problems solving.

Functional style has a more algebraic model which is more elegant and general in many ways, but even many computer scientists are not that comfortable with abstract algebra. (Very strangely, my local university, though quite reputable in CS, only requires calculus and linear algebra for a CS degree; abstract algebra courses seem to be optional).

The terror inspired in newbies by the words "closure", "continuation", and "monad" demonstrate this. ;-)

I would base the OO semantics on coalgebras

I've been meaning to ask you more about this. I read the first of the papers you mentioned (Jacobs), and, though I found it interesting, I kept wondering why OO really needed the co-algebraic treatment.

If I understood him correctly, his main motivation was to model information hiding, and his co-algebraic operations seem to be a "type-theoretic abstract state machine" to handle this.

I'm not so convinced that information hiding is that crucial to OO; though there are stylistic and practical reasons to keep data elements private, it is perfectly OK (and common) to have public accessors for these.

It seems to me that you could model objects much as you do tuple types, as products, with accessors as the projection morphisms. You could add a "class index" to the product to separate otherwise identical tuple types of different "classes", etc. Obviously, there is more to work out.

Am I missing something here?

Daniel Yokomiso - Re: How to make a FPL successful  blueArrow
8/7/2003; 12:17:23 PM (reads: 1111, responses: 0)
Nobody mentioned DrScheme yet? Righty-oh.
The point I was trying to make was one about languages and communities, not about an an interactive, integrated, graphical programming environment. DrScheme is a very nice tool, but that's like saying that Eclipse or jBuilder were fundamental to Java's success.

Let me illustrate my earlier post with Scheme. If Scheme had a community site, let's call it PlanetLambda (the domain is available if anyone is interested ;) posting articles on how to use libraries (e.g. "SXSLT Makes your HTML Generation Easier", "XML Performance Problems? SSAX to the Rescue!"), tips on scheme programming design and such, it would be easier for people to use the language. Several kinds of sections could be added -- "Ask the Guru", "Riddle of the Day", "Macro Tips" -- and new articles could be advertised in a weekly newsletter. Add a couple of other similar sites and people will see that parenthesis aren't so scary. You can play this game with your favourite FPL.

Smalltalk had killer IDEs, yet the "masses" never used them. IDEs are very good, I usually use them whenever I can, but they don't answer people's question. Neither tools nor papers do that job. Tools and papers help hackers, early adopters and enthusiasts. Joe Programmer searches MSDN for answers, articles and code snippets.

Isaac Gouy - Re: How to make a FPL successful  blueArrow
8/7/2003; 12:51:33 PM (reads: 1096, responses: 1)
Why would you like an FPL to be popular with the "masses"? How popular?
There is a downside.

Popularity has been a very popular theme on comp.lang.functional
- Why FP will take over the world and C will die
- The Imperative Strikes Back
- Learning from C++'s success ( was C++ briar patch )

Isaac Gouy - Re: How to make a FPL successful  blueArrow
8/7/2003; 1:04:10 PM (reads: 1076, responses: 0)
What stage of adoption have FPLs reached?

Crossing the Chasm: A S&T Transition Strategy

Daniel Yokomiso - Re: How to make a FPL successful  blueArrow
8/7/2003; 1:49:37 PM (reads: 1110, responses: 0)
Because with popular FPLs it's easier to find a job for programming with a good language, instead of having to be a Java consultant. Also popular languages tend to have more well tested and documented libraries, also more tools. Also it's easier to find developers for your projects. From a management POV mainstream languages have more case studies to improve statistical project measures, assess risk, estimate effort and budget, lower training costs and such pesky things.
More developers using safer languages means more safe applications.

c.l.f, being a usenet medium, has it's share of recurring themes. It's always interesting to read them, but in all threads I followed (not many because I read c.l.f since 2001, so it's just a couple of years) people like to mention productivity, killer applications, powerful IDEs, long rants on how imperative programmers don't get FP or don't want to learn new things, etc., but almost nobody ever mentions the solve your problems approach. Shriram Krishnamurthi did a talk on ll1 The Swine Before Perl with a wonderful example of how to use Scheme to implement a Pattern-matcher for streams (starting at page 20). That's a way to teach people how to use macros to make their life better, not a generic macro example or a really smart way of doing template meta-programming using macros.

Dominic Fox - Re: How to make a FPL successful  blueArrow
8/7/2003; 1:54:32 PM (reads: 1066, responses: 2)
DrScheme is a very nice tool, but that's like saying that Eclipse or jBuilder were fundamental to Java's success.

They certainly aren't harming it; and my first encounter with Java was in the context of an IDE with a GUI-builder, Symantec's (IIRC) Java Cafe. I thought it was pretty cool, at the time.

MzScheme, plus assorted libraries distributed with DrScheme, plus some others that are not hard to find, plus "Teach Yourself Scheme in Fixnum Days", etc., comes the nearest of any FPL I've seen to Python's full-featuredness in terms of libraries and documentation...

I don't know which has to come first: the community sites or the community. There obviously is a Scheme community; it apparently isn't the sort that has message boards where people post questions about how to do date-time manipulation in a CGI script.

But I like the idea. I'm at about the stage with Scheme where I would benefit from a reasonably broad set of "cookbook" examples and developerWorks-style articles on how to make cool stuff happen. If I persevere, I'll get over this stage without having to rely on such things; but they would still be nice to have.

Ehud Lamm - Re: How to make a FPL successful  blueArrow
8/7/2003; 2:03:35 PM (reads: 1088, responses: 0)
How to Use Scheme tries to fill this void. Does anyone know why the PLT guys stopped updating the site?

Frank Atanassow - Re: How to make a FPL successful  blueArrow
8/8/2003; 4:16:07 AM (reads: 1041, responses: 1)
Marc wrote: I think that programming in the functional style, which [is] what you mostly do even in "impure" FP languages, is quite a major change of thinking and approach. Procedural style has a familiar mental model: everyone knows how to follow a recipe or follow instructions for an IKEA shelf (OK, maybe not... ;-) ) Step-by-step changes of state is a normal, everyday approach to complex problems solving. Functional style has a more algebraic model which is more elegant and general in many ways, but even many computer scientists are not that comfortable with abstract algebra.

Boy, you just can't resist those cognitive factors, can you? :)

FWIW, I don't believe the `procedural is natural/familiar while declarative is strange/exotic' argument. Planning a task requires both procedural and declarative thinking, and indeed I think there is a duality there related to CPS transformation.

I'm not so convinced that information hiding is that crucial to OO

The problem is partly that "OO" is not very well-defined. In fact, I think people like to keep it that way because then, when they see some language feature they like, they can say, "That's so OO!", and when they see something they hate, they can remark, "The problem there is it's not OO enough." That way "OO" can always remain the rosy ideal everyone wants it to be.

As soon as you fix a particular meaning for OO, it becomes vulnerable to objective analysis, and people don't want that. (The situation reminds me of the situation with programs and program specifications.)

It seems to me that you could model objects much as you do tuple types, as products, with accessors as the projection morphisms. You could add a "class index" to the product to separate otherwise identical tuple types of different "classes", etc. Obviously, there is more to work out. Am I missing something here?

I think what you are missing is that a) products are a trivial kind of coalgebra, and b) you need something like a fixpoint to model the fact that classes can reference themselves. Put those two together and you get coalgebras in general.

Special indices are unnecessary. You can distinguish `otherwise identical tuple types' by choosing them to be distinct products (since there are in general many ways of forming the product of two types, all isomorphic).

Daniel Yokomiso - Re: How to make a FPL successful  blueArrow
8/8/2003; 7:11:49 AM (reads: 1031, responses: 0)
They certainly aren't harming it; and my first encounter with Java was in the context of an IDE with a GUI-builder, Symantec's (IIRC) Java Cafe. I thought it was pretty cool, at the time.
That's true. I always "kinda" liked Scheme, but when I first used DrScheme I though: "Hey, it's pretty cool.".

But I like the idea. I'm at about the stage with Scheme where I would benefit from a reasonably broad set of "cookbook" examples and developerWorks-style articles on how to make cool stuff happen. If I persevere, I'll get over this stage without having to rely on such things; but they would still be nice to have.
And that's the point where some people give up on FPLs. Before I tried Python I searched for articles about it, trying to get its "look and feel". The tutorials and text-books are nice but they don't show the way "real world" Python programmers code, whatever it means. I wasn't much interested in Python to make myself "persevere", different from Haskell which, unfortunately, "forces" me to work hard to find nice IO examples.

Marc Hamann - Re: How to make a FPL successful  blueArrow
8/8/2003; 7:23:00 AM (reads: 1047, responses: 0)
Boy, you just can't resist those cognitive factors, can you? :)

Well, at least I'm trying to be more principled in their use... ;-)

Part of the problem is that (as I think I failed miserably to explain in the previous threads) I think "cognitive factors" are lurking in a lot of principles that seem "solid".

For example, if we say "the primitives in a language should be few in number and orthogonal with respect to each other". Nobody is likely to argue with that (hmmm... maybe Larry Wall ;-) ), and it offers an "objective" criterion to work with, but scratch the surface of it, and it really is saying "...because it is easier to reason about", which is, if you think about it, a "cognitive factor".

I don't believe the `procedural is natural/familiar while declarative is strange/exotic' argument.

Put that way, I don't think that I do either. ;-) I do take it for granted that when I do more declarative style thinking (say reading an abstract math text) I will have to "think harder" per unit of text. I don't think it is so much a fundamental difference of kind, as one of degree, a kind of "higher density".

This also may vary across individuals. (Pretty likely, really.)

The problem is partly that "OO" is not very well-defined.

I have to agree. For me right now, it is mostly a style for organizing the solution-space rather than some profound theory. Seems useful though.

products are a trivial kind of coalgebra

I had to think about that for a bit (darn cognitive factors ;-)), but I see what you mean. The parallel with algebraic data types being expressed as sums seems pretty obvious after the fact.

you need something like a fixpoint

On this one, I'm not sure how you wouldn't need this with recursive algebraic types too.

You can distinguish `otherwise identical tuple types' by choosing them to be distinct products

Ah, of course. Some nasty non-CT thinking crept in there. ;-)

I really must take my "cognitive factors" into the shop for some repairs... ;-)

Isaac Gouy - Re: How to make a FPL successful  blueArrow
8/8/2003; 10:42:58 AM (reads: 1007, responses: 0)
it's easier to find a job programming with a good language
I believe people have emigrated to Sweden so they could work with Erlang, some came to the USA to work with Smalltalk - changing your situation (rather than changing the world) can be a practical way to follow your dream.

Some FPLs seem to have transitioned from Innovators to Early Adopters (LISP in AI days, Erlang) and some haven't (Haskell? - aren't many FPLs vehicles for language design research - why would we even expect them to be popular?)

Have any FPLs formed a base amongst Early Adopters that would allow them to make the next transition? There are scattered examples of early adopter use being eroded (Lisp at JPL, Yahoo Store). Without a base of Early Adopters is it the right time to go after Early Majority Joe Programmer?

big enough group of programmers has to be forced to use the language / most programmers... They switch PLs because they have to
Yes, unlike Innovators, even Early Adopters need a non-technical reason for adopting a new technology.

Moreover, ya gotta hype:

A primary component of successful heterogeneous engineering is to convince the world that the future is destined to be dominated by the technology. Effectively executed, this will have a profound psychological impact and will actually create a self-fulfilling prophecy. MacKenzie asserts that “if it comes to be believed that there is only one way to advance a technology, then that one way has at least a chance of becoming a reality. The others do not.”
Symbolics, Inc.: A failure of heterogeneous engineering

And Java is so very close to C++
"by designing Java’s syntax to be extremely similar to that of C++. James Gosling once joked that he tricked programmers into a paradigm shift by making the system the same" - apocryphal from a student term paper.

Niklaus Wirth was astounded that industry ignored "the elegant and powerful language", "compact and fast compiler", "modern, flexible development environment for workstations, complete with window system, network, document and graphics editor, neatly fitting into about 200 Kbytes of memory, the compiler alone taking less than 50 Kbytes" that was Oberon.
He noted that "In contrast to Pascal, Modula and Oberon did not appear at a time when computing reached new segments of the population". Perhaps we could say "In contrast to Java".

Find the New New Thing and hype your chosen FPL as the way to program it.

Isaac Gouy - Re: How to make a FPL successful  blueArrow
8/8/2003; 4:13:17 PM (reads: 981, responses: 0)
"OO" is not very well-defined. In fact, I think people like to keep it that way
If you have suitable definition, tell us!

From comp.object- "It is taboo to ask what OO is in this group, because it starts a big fat juicy battle that never seems to end :-)"

In contrast, from the clf faq- "Opinions differ, even within the functional programming community, on the precise definition of what constitutes a functional programming language. However, here is a definition that, broadly speaking, represents the kind of languages that are discussed in comp.lang.functional..."

Patrick Logan - Re: How to make a FPL successful  blueArrow
8/8/2003; 4:57:38 PM (reads: 979, responses: 0)
I don't think there has to be, nor would I expect ease in accomplishing, a single, formal definition of what OO is. Let's accept it as a vague, umbrella term applied to a variety of more or less similar languages. There is just too much variety and vaguery already applied to the term.

As for the people who "when they see some language feature they like, they can say, "That's so OO!", well, these people will never understand the formal definition anyway. Just ignore them.

Accept that "OO", like "beauty", is in the eye of the beholder.

If you want to do an objective analysis of something, define what that something is and do the analysis. But don't expect to claim that these results apply to "OO" generally. It has no meaning and is not a battle you can win.

Isaac Gouy - Re: How to make a FPL successful  blueArrow
8/9/2003; 7:15:10 PM (reads: 949, responses: 0)
Models of Software Acceptance: How Winners Win slides 32-36 have a slightly different take on the Chasm ideas of technology acceptance. For Richard Gabriel, the "gap really represents a change in the environment that renders the technology useful/desirable/hot/necessary. It turns a vitamin pill into a pain killer, a nice-to-have into a must have."

Moreover "Often the seeds for the environmental change are planted by the pioneer who plants the idea that a technological solution is possible: How necessary to the process is the failed pioneer?"

Frank Atanassow - Re: How to make a FPL successful  blueArrow
8/10/2003; 7:48:41 AM (reads: 910, responses: 1)
Marc wrote: For example, if we say "the primitives in a language should be few in number and orthogonal with respect to each other". Nobody is likely to argue with that (hmmm... maybe Larry Wall ;-) ), and it offers an "objective" criterion to work with, but scratch the surface of it, and it really is saying "...because it is easier to reason about", which is, if you think about it, a "cognitive factor".

Yes, but observing that it is a cognitive factor does not help you design (or use) a programming language.

Furthermore, almost any principle can be supported by nebulous arguments about cognitive factors. For example, no procedure should have more than seven parameters, because the average size of a person's short-term memory is seven. No, no, wait, there should be no more than five parameters, because on average (I'm guessing) there are two local variables allocated in a procedure body. No, no, wait, there should be no more than three, because there will be on average two global variables which affect a procedure's result. No, no, wait, each procedure should have as many parameters as possible, because then the total number of procedures will be less.

If you really want to make arguments based on cognitive factors, then you should be prepared to do some experimental science, like GOMS testing in HCI, or at least point to a specific experimental study.

I wrote: you need something like a fixpoint Marc wrote: On this one, I'm not sure how you wouldn't need this with recursive algebraic types too.

You do need it for algebraic datatypes. I was pointing out in the context of OO that you need some recursion to handle self-reference, and a product is not recursive, so something is missing there.

Marc Hamann - Re: How to make a FPL successful  blueArrow
8/10/2003; 1:39:09 PM (reads: 921, responses: 0)
observing that it is a cognitive factor does not help you design (or use) a programming language

So it is more helpftul to just take it as an unanalyzed axiom?

almost any principle can be supported by nebulous arguments about cognitive factors

Well almost any principle can be supported by any sort of nebulous argument. ;-) The challenge is to make the arguments less nebulous. (And I must admit, I think some of my earlier ones were too nebulous.)

For example, no procedure should have more than seven parameters

So do you think that the number of parameters is irrelevant? If not, on what grounds would your position. I know that I have a definite position about the issue, based on my prefered design criteria and experience, but I can't think of decent objective way to prove it "right".

After our previous discussion on "human factors", I did some cursory research on the topic. What I found seemed to fall mainly into two categories:

- a prescriptive approach justified either by a general learning model or "because they say so". e.g. this

- experimental approaches, though , as e.g. this site points out, of somtimes dubious or limited result.

You might feel that this proves that we don't know enough to invoke "human factors" in our study of PLs But that still leaves us with such desiderata as the "orthogonality principle" as unjustified axioms or, if we are unwilling to accept it as an axiom, a meaningless arbitrary prescription.

be prepared to do some experimental science, like GOMS testing in HCI, or at least point to a specific experimental study.

For the limitations on this, see second site mentioned above.

I wonder how many PL designers do this kind of testing on their features? Should the designers of Haskell be castigated for introducing layout, a device to make it "easier to read", without providing evidence that it in fact accomplishes this? Or do we just have to accept this, because it is "their language" to do with as they please?

It seems that in language design there are a lot of issues that might fall into this crack.

Isaac Gouy - Re: How to make a FPL successful  blueArrow
8/10/2003; 7:24:23 PM (reads: 895, responses: 1)
"orthogonality principle"... a meaningless arbitrary prescription
Not arbitrary - aesthetic.

For the limitations
Richard Gabriel (Productivity: Is there a Silver Bullet) mentioned an additional limitation - the difficulty of finding funding for this kind of research "projects aimed at economic improvement in the software area — and there was $20 million to $200 million available per year for it. However, the requirement was that there be a technological barrier to the improvement... the ultimate goal was enviable but ultimately aimed at funding the same old tinker-toy sorts of technology-busting boondoggles... sometimes it’s a people problem, not a technology problem."

how many PL designers do this kind of testing
There are tiny steps - Evaluating a new programming language. What would happen if we discovered that "what they consider important for languages is trivial or counterproductive"?

without providing evidence
A healthy dose of skepticism is required.

Marc Hamann - Re: How to make a FPL successful  blueArrow
8/11/2003; 7:04:53 AM (reads: 901, responses: 0)
Not arbitrary - aesthetic

If we are trying to put "human factors" on objective ground, aren't they the same thing? ;-)

I think though, as your comment suggests, that aesthetics plays a bigger role in PL design and evaluation than we can comfortably ignore.

What would happen if we discovered that "what they consider important for languages is trivial or counterproductive"?

I suspect that many of them would either lose interest in PL design, or stick to their guns and lose interest in objective evaluation. ;-)

Frank Atanassow - Re: How to make a FPL successful  blueArrow
8/11/2003; 8:31:24 AM (reads: 851, responses: 1)
Marc wrote: "orthogonality principle"... a meaningless arbitrary prescription Isaac wrote: Not arbitrary - aesthetic.

There is more to it than aesthetics.

In the kind of work I do, I have to do interpretations of programming languages in some semantic category. If the primitives of the language are orthogonal, than this is a lot easier than if they are overlapping, because if they overlap then either I have to ensure that the semantics agree on their intersection, or I have to find a normalization algorithm, because then the normal forms are all orthogonal.

As a simple example, consider the language of monoids. To assign a semantics to a monoid expression, I have to specify a homomorphism of monoids, which means that I have to make sure that I interpret the multiplication as an associative function, for example, else the semantics is ambiguous. Checking associativity is a proof obligation which arises because the monoid terms are not orthogonal: there are equations between them.

An alternative is to specify a set of normal forms, for example by choosing a left-associative representation. Then I only have to give what amounts to a list algebra, and there is no proof obligation because lists do not satisfy any laws.

Another example is coordinatization of vector spaces. If I pick a basis which is not orthogonal, then whenever I (syntactically) specify a linear transformation using that basis I have to check that it is consistent, i.e., that it behaves the same way on a point no matter how it is represented. A simple instance of this is integer representations on a computer. Sometimes these allow you to represent zero in two or three ways: 0, -0 (and maybe +0). So when you specify an integer function f you better make sure that f(0) = (f-0) = f(+0).

This is more than just a mathematical issue. It's actually a real issue in programming that I do every day.

I am not saying, mind you, that we should deal only with lawless or orthogonal languages. That's nonsense, because in many languages computation IS normalization, and a normal form is a value. But, if you have lots of overlapping primitives, then there better be a good reason for it, and it should not be left to users to puzzle out exactly what the nature of that overlap is.

This is precisely why languages intended for computers should be (strongly) normalizing; because then you have the best of both worlds: a convenient, non-orthogonal set of primitives (for example typed lambda-calculus); an orthogonal set of primitives (the normal forms); and an equivalence between them (the normalization algorithm).

And let me also note, that it is situations like these which make so leary of your "cognitive factors". You say orthogonality is an aesthetic issue, which implies that there is no objective reason to prefer it. Yet I just gave you an analysis which demonstrates, I hope, very clearly that there are objective reasons to prefer orthogonality, and also objective reasons not too. Furthermore, that analysis touches on very important principles of computation, such as normalization, laws and congruences.

Now, if you had convinced yourself that the orthogonality issue was completely subjective, do you think you would ever have seen its deeper relevance and all the issues it touches on? I bet not: instead you would only descend deeper and deeper into the `cognitive quagmire' as you require more and more mystical explanations to support your hypothesis. This is precisely why I think all the emphasis on cognitive factors is counterproductive.

Marc Hamann - Re: How to make a FPL successful  blueArrow
8/11/2003; 10:08:34 AM (reads: 848, responses: 0)
if they overlap then either I have to ensure that the semantics agree on their intersection <snip> you better make sure that f(0) = (f-0) = f(+0).

Let me paraphrase what I believe your argument is as a pseudo-syllogism:

- the best way to evaluate PLs is to prove properties about them. - having fewer conditions on primitives (e.g. less interdependence) makes it easier to prove properties of PLs. - therefore fewer conditions on primitives are objectively better feature of PLs.

I will agree with you this is a very reasonable and principled statement of position.

I will grant that the first statement is objective precisely in the sense that if someone else accepts this premise, and is prepared to use the same mathematical rules, they will be able to derive the same results as you.

If someone wants to substitute a different premise, such as "the best way to evaluate a PL is to see how many large production systems have been built with it", your positions will be incommensurable, i.e. subjective relative to each other.

Now for the really controversial aspect of my position ;-): I think the second statement is a "cognitive factor", for two reasons. One: is "easier to reason about" in a proof context really different from "easier to reason about" in a learning or using context?

Two: if you have lots of overlapping primitives, then there better be a good reason for it

Deciding when a reason is good enough to make an exception to the rule is subjective unless you can come up with an equally objective measure of "good reason".

Now, my goal in pointing out these weaknesses in your position is not to demolish it. I think it is a reasonable and useful position, and it has and will continue to produce valuable results in PL research.

Instead, I want to argue that some of the "cognitive factors" are no less worthy of consideration, so long as we can find similarly "objective" models with which to discuss them. (I think Ehud's work is in fact a step in this direction.)

I think our discussion so far shows that it is far harder to do this, which I think is the basis of your rejection of such reasoning, but there is a significant risk of throwing the baby out with the bath water if we reject them wholesale.

Marc Hamann - Re: How to make a FPL successful  blueArrow
8/11/2003; 10:45:16 AM (reads: 815, responses: 0)
A more principled restatement of one of my earlier claims: (as an example)

It is easier to reason formally about stateful, procedural systems (hereafter procedural)than stateless, declarative ones (hereafter declarative).

Axiom: (Thesis) It easier to reason formally about a system if it can be described with fewer elements and fewer conditions on those elements.

Claim: (Antithesis) A procedural system has fewer elements and fewer conditions at each point in time than a declarative one.

Proof: 1) at each point in time, a procedural system need only consider its current state and the conditions required to transition to its next state.

2) at each point in time, a declarative system must be able to ensure conditions across all states at all times (or, minimally, all states from the initial one up until the present time).

3) mathematicians who reason about declarative systems (e.g. algebraic structures) implicitly recognize this difficulty by "proceduralizing" declarative systems, i.e. identifying generators and simple conditions on generators that can be used to generate successive closures ("states") until the whole structure is defined.

Result: (Synthesis) It is easier for humans to reason using procedural rather than declarative systems at successive points in time.

However, if you are really concerned about the global state-space of a system independent of time, you have the same problems both ways, and you are probably better off using declarative approaches. ;-)

Isaac Gouy - Re: How to make a FPL successful  blueArrow
8/11/2003; 10:54:55 AM (reads: 813, responses: 0)
there are objective reasons to prefer orthogonality, and also objective reasons not too
Good! Utility. I can appreciate that. How broadly useful? Are there additional costs this adds to other situations? (stepping onto a "cognitive quagmire")

There is more to it than aesthetics
Maybe language designers just assert aesthetics to avoid the tedium of explaining why they really came to a decision?
Anders Hejlsberg: "Ultimately, good language design boils down to assembling a team of people who have good taste. It boils down to programming aesthetics"

the emphasis on cognitive factors
Has there been much emphasis on cognitive factors in programming language design? The weakness of "arguments based on cognitive factors" seems to stem from lack of research and lack of interest.