On Wed, 2009-02-25 at 17:54 -0700, John A. De Goes wrote:

It's a chicken-egg thing. A Linux or OS X developer tries Haskell and finds he can write useful programs right away, with a minimum of fuss. But a Windows user tries Haskell and finds he has access to very few of the really good libraries, and even the cross-platform libraries won't build without substantial effort. As a result, I bet it's easier for a Linux or OS X developer to like Haskell than a Windows developer.

I use OS X exclusively myself, but I'll ensure my first published Haskell library is cross-platform compatible, because I think it's good for the community. The more people using Haskell, the more libraries that will be written, the more bugs that will be fixed, the more creativity that will be poured into development of libraries and the language itself.

I don't think this is founded in experience. The experience of the last 5 years is that the more people use Haskell, the more important backward-compatibility concerns become, and the harder it becomes for Haskell to continue evolving. Creativity being poured into a language doesn't do much good if the result is the language moving sideways, still less the language growing sideways. jcc

"John A. De Goes" wrote:

Personally, I'd be happy to see that explosion of innovation in the library and tool spaces, even if it means the language itself stops evolving (for the most part). It will make it a lot easier do use Haskell commercially, and the innovators in the language space will find or invent a new target to keep themselves occupied.

And this is why we must avoid success: It would mean instant failure. There are already enough hype-languages around, there's not too much of a point to add one to them. Haskell won't stop evolving and (conservatively) keeping up with PL research until that's done, or Dependent Typing is well-understood, whatever comes first. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

The problem is that PL research is probably not going to stop evolving in our lifetimes. Yes, that research needs a venue, but why should it be Haskell? Haskell is a good language and it's time to start benefiting from the research that's already gone into it. That means some tradeoffs. Haskell is already behind state-of-the art in PL research and it seems unlikely to catch up (witness the slow evolution of Haskell' and the non-existent progress on Haskell2). Of course, I could be wrong. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Feb 25, 2009, at 6:19 PM, Achim Schneider wrote:

"John A. De Goes" wrote:

...

Personally, I'd be happy to see that explosion of innovation in the library and tool spaces, even if it means the language itself stops evolving (for the most part). It will make it a lot easier do use Haskell commercially, and the innovators in the language space will find or invent a new target to keep themselves occupied.

And this is why we must avoid success: It would mean instant failure. There are already enough hype-languages around, there's not too much of a point to add one to them. Haskell won't stop evolving and (conservatively) keeping up with PL research until that's done, or Dependent Typing is well-understood, whatever comes first.

-- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Feb 25, 2009, at 7:49 PM, Achim Schneider wrote:

"John A. De Goes" wrote:

...

The problem is that PL research is probably not going to stop evolving in our lifetimes. Yes, that research needs a venue, but why should it be Haskell? Haskell is a good language and it's time to start benefiting from the research that's already gone into it. That means some tradeoffs.

Why shouldn't it be Haskell?

More, why *can't* it be Haskell. Haskell is already constrained by backwards compatibility, which limits future directions. Partial functions and dependent typing do not seem to play well together, for instance. Moreover, look at the packages being uploaded to Hackage: they're almost all trying to do useful stuff. The direction of Haskell has already changed, and I don't see it reverting to its old course.

Not really, look at e.g. type families, which give you much of the power dependently typed languages give you while saying "nah, not yet" to the question of how to deal with non-terminating typechecking.

*Some*, not *much*, and there are dependently typed languages that have guaranteed terminating type checking.

About the H' progress... It's hard to tell how many drops are needed to make a bucket overflow, especially if you've got no idea what the bucket looks like. What certainly isn't happening is people taking a house, trying to overflow a badly leaking bucket.

As far as I know, H' was supposed to be completed many years ago. Likely, it won't be completed for many more years. H2 is probably more than a decade away, if it happens at all. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101

"John A. De Goes" wrote:

Partial functions and dependent typing do not seem to play well together, for instance.

Well, sure, they do, as long as you don't expect the typechecker to terminate if some type it checks is formulated in unterminating code. GHC already has this problem if you enable UndecidableInstances, which is exactly the reason why you shouldn't enable it if you don't understand the need to enable it in great detail and clarity. I think that arguing that Haskell is _obsolete_ because it isn't yet fully dependently typed is vastly mistaken. Right now there are only a handful of dependently typed languages, Agda being the only one that seems to be at least partly usable by people without a Ph.D in logic. It is _especially_ still unknown how to properly tackle totality. Not jumping on the bleeding-edge bandwagon does not imply that Haskell's evolution grinded to a halt, but that it protects itself from possibly fatal mistakes. Maybe the first ____-calculus based languages will change the state of the art and you will see the GHC devs fighting over who is going to implement it, maybe they won't and they will be free to concentrate on other, equally important, though vastly different, topics. Like optimisations, toolchain support or finally outlawing tabs in source code. One thing is for sure: All progress will be stopped dead if the community starts to listen to people who demand "enterprise-readiness". I seriously doubt that backwards compatibility will ever be broken to the point of non-inoperation, but I certainly expect -- and do, in some sense, hope -- it to be broken, to the point where you can't mix H98 and H' source because they are mutually incompatible, either in syntax, semantics, or both, as long as you can still comparably painlessly link them. If your business is fine with that, you shouldn't have any problems. I can imagine a lot of companies currently using Haskell wouldn't be happy with freezing Haskell, at all: They don't mind updating their code to the state of the art. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

On Feb 26, 2009, at 12:12 PM, Achim Schneider wrote:

I think that arguing that Haskell is _obsolete_ because it isn't yet fully dependently typed is vastly mistaken.

I never said it was obsolete. Far from it. But I did say that choices already made and codified into H98 have implications on the future evolution of Haskell, because Haskell is unlikely to deviate in ways that significantly break backward compatibility.

One thing is for sure: All progress will be stopped dead if the community starts to listen to people who demand "enterprise- readiness".

What do you mean by "progress"? I noted before that there are tradeoffs. Constraining the evolution of the language in backward compatible ways leads to substantial improvements in tools, libraries, and the speed of compiled code. That's progress in several dimensions -- just not along the dimension of "language".

I seriously doubt that backwards compatibility will ever be broken to the point of non-inoperation, but I certainly expect -- and do, in some sense, hope -- it to be broken, to the point where you can't mix H98 and H' source because they are mutually incompatible, either in syntax, semantics, or both, as long as you can still comparably painlessly link them.

We'll see. First we have to know what H' is going to look like, which is a long ways off.

If your business is fine with that, you shouldn't have any problems. I can imagine a lot of companies currently using Haskell wouldn't be happy with freezing Haskell, at all: They don't mind updating their code to the state of the art.

The problem with completely fluid languages is that they impose arbitrarily high costs on those who choose them. That's why companies prefer well-defined standards and strong backwards compatibility. And that's why such languages eventually die, from lack of innovation -- even if 40 years later there are still developers forced to maintain software written in them. An intermediate solution is providing a source-to-source translator that flawlessly converts older source code into newer source code. Add binary compatibility, and then the only real disadvantage in language evolution becomes retraining and tools. Which are both significant costs, to be sure, but not as significant as the former. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101

Are you saying has been no progress since K&R C in the number of libraries available to C programmers? And that C programmers still have to edit files with vi and compile and link by specifying all files on the command-line? You may disagree, but the evidence points in the opposite direction. There are tens of thousands of robust C libraries available to suit any particular programming need. Many of Haskell's own libraries are based on C versions. Tool support for the C language (not for some successor you might think would exist if the language continued evolving) can detect memory leaks, detect memory overwrites, apply dozens of automatic refactorings to C large-scale C programs, etc. Library and tool support for the C language is light years beyond Haskell. It wouldn't be there if we had been through 20 iterations of C each completely breaking backward compatibility. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Feb 26, 2009, at 1:08 PM, Achim Schneider wrote:

"John A. De Goes" wrote:

...

What do you mean by "progress"? I noted before that there are tradeoffs. Constraining the evolution of the language in backward compatible ways leads to substantial improvements in tools, libraries, and the speed of compiled code. That's progress in several dimensions -- just not along the dimension of "language".

I disagree. Backwards compatibility can be the very reason no progress _can_ be made in the areas you mention. The C toolchain was and is a mess for anything but small, uniform, single-platform programs, things like valgrind of course outperform plain lint in a variety of ways, but are still hacks around the language's major flaws (And I'm speaking as a C-fan, here). Further breakthroughs in C compiler technology will require stalin-like brute force and library support... well, did you ever use yacc or libxml and compared them to Haskell solutions?

Java generics are broken by design, for the questionable benefit of backwards compatibility. Leave those Bad Decisions to language communities who don't care about Doing It Right. "Right" being a technological measure here, not how well politics sell to accountants.

-- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

No, I hate C and will never use it again in my entire life unless forced to at the point of a gun. You're point? :-P Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Feb 26, 2009, at 1:17 PM, Jonathan Cast wrote:

On Thu, 2009-02-26 at 13:18 -0700, John A. De Goes wrote:

...

Are you saying has been no progress since K&R C in the number of libraries available to C programmers? And that C programmers still have to edit files with vi and compile and link by specifying all files on the command-line?

You may disagree, but the evidence points in the opposite direction. There are tens of thousands of robust C libraries available to suit any particular programming need. Many of Haskell's own libraries are based on C versions. Tool support for the C language (not for some successor you might think would exist if the language continued evolving) can detect memory leaks, detect memory overwrites, apply dozens of automatic refactorings to C large-scale C programs, etc.

Library and tool support for the C language is light years beyond Haskell. It wouldn't be there if we had been through 20 iterations of C each completely breaking backward compatibility.

Maybe you should use C then?

jcc

Jonathan Cast wrote:

IDEs are for losers

Hell is freezing over: I'm actually agreeing with an editor heretic. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

On Thu, 2009-02-26 at 15:23 -0700, John A. De Goes wrote:

On Feb 26, 2009, at 1:36 PM, Jonathan Cast wrote:

...

On Thu, 2009-02-26 at 13:25 -0700, John A. De Goes wrote:

...

No, I hate C and will never use it again in my entire life unless forced to at the point of a gun.

Why? Its libraries are far better, its editors are far better [1], its compilers are far better, its tool support is far better, it's incomparably superior in every possible way to Haskell.

There are better languages than C with more libraries and better tools (e.g. Java). I would chose one of those over Haskell for a commercial product needing short time-to-market and a long shelf life.

OK, great. But still: if you want Java, you know where to find it.

Even though Haskell is a superior language, there are other, often more important considerations for anything but hobby coding.

...

Except the relatively narrow criterion of the *language itself*. Maybe making languages better is a worthwile pursuit, then? Or do you still think languages should be frozen in time[2] so the tools, compilers, editors, libraries, etc. can undergo vast improvements?

I think to reap the benefits of a language, it must necessarily stop evolving in ways that impose high costs on its user base.

...

[2] For the record: I'd be content to see a frozen production language, like Haskell, frozen in time; as long there's a credible other evolveable language --- preferably one with zero backward- compatibility requirements w.r.t. Haskell 98 or current or past GHC.

Let me ask you this question: If I wanted a language like Haskell, but which is "Enterprise ready", where should I turn?

My *optimal* solution (not one I actually expect): Haskell forks. One frok retains backwards-compatibility, but gives up type families and any new language developments. If that language evolves, I can *guarantee* you I will dislike any changes it makes (see Java generics for an example; see the entirety of C++ for another). The other fork continues to impose `high costs' on its user base, in the name of being the best language it can possibly be. This will eventually involve just discarding features of Haskell 98 that get in the way.

My answer: Haskell. It's maturing and its slowed rate of evolution is already having beneficial effects on other dimensions.

Beneficial as per you. Not everyone agrees/cares --- not everyone is doing Enterprise programming!

...

Re-designing a purely function research language from the ground up would be neat --- but then it wouldn't be Haskell at all, and I wouldn't use Haskell, I'd use the new language. If I thought I could realistically leave the Haskell community, I wouldn't be nearly so opposed to Haskell's continued slide into practicality.

Why do you think you'll have no where else to go if Haskell continues moving away from being a research language?

I have nowhere to go as yet. (I am actually writing my own language; when I get something usable for real work, I may very well just plain un-subscribe from haskell-cafe, even though I will continue using Haskell for bootstrapping for some time after that.)

There are plenty of people who would join you. I think you'd have far more company than you seem to believe.

Yeah, I'd have the company of everyone who argues against you in this (quite on-going) debate. At least in spirit (how long it will take for a new common research language to emerge from the mist is another matter).

And a fresh start, with absolutely zero requirements for any backward compatibility, would open up many new directions.

I agree with that. Although you're trying to argue those directions are less valuable than I think they are! In any case, I'm going to *try* not to continue this discussion any further. Best case nothing beneficial comes of it; worst case participating in it slows down Global Script development. jcc

On Fri, 2009-02-27 at 00:04 +0100, Achim Schneider wrote:

Jonathan Cast wrote:

...

(I am actually writing my own language; when I get something usable for real work, I may very well just plain un-subscribe from haskell-cafe, even though I will continue using Haskell for bootstrapping for some time after that.)

I've actually got a complete syntax (except the module system (which, for me, means mostly type classes :)), a type checker (which has lambda terms --- including higher-order ones --- but no local declarations yet), and an implementation that seems like it would mostly do what I want if the standard library were rich enough to write interesting things in. Actual documentation is more lacking: I'm partway through a syntax man page (including I think the most interesting parts of the language); unfortunately, it's written in Global Script, and uses both features of the language I haven't implemented yet and a library I haven't even started.

/me is curious.

I'm not sure what the best interface for publishing this is. Blogs seem to be somewhat standard; I should probably revive mine.

And I'm wondering whether you're aware of the stuff Luke is working on (http://lukepalmer.wordpress.com/).

I've read all those posts through Planet Haskell; I don't think they've made it into my list of interesting things to consider w.r.t. language design yet.

Personally, I've got some thoughts about a syntax, a preliminary parser and a lot of half-understood ideas.

Hmm. Today's the first day I've really given serious consideration to the viability of replacing Haskell with Global Script, even in principle. After all, trying to replace one of the most successful research languages in existence would be hubristic. (And as SPJ has said, it won't happen by someone setting out to do it explicitly). To avoid hubris (which my study of Greek tragedy tells me is the greatest danger to heroes), I've been busy convincing myself I'm really trying to replace TeX, instead. After all, TeX is clearly a much less adequate programming language... jcc

"John A. De Goes" wrote:

Are you saying has been no progress since K&R C in the number of libraries available to C programmers?

I never did, I asked you to compare usability. If you want it in plain English, library semantics still suck, hell, there isn't even name spacing.

And that C programmers still have to edit files with vi and compile and link by specifying all files on the command-line?

No, we still use some kind of make, and, believe it or not, I've written myself an omakefile that allows you to compile C with the same ease as ghc --make compiles Haskell. It makes many assumptions about the usage of imports, though: Such power will always be hackish in C-land. I am offended by the demeaning way you portray vi.

You may disagree, but the evidence points in the opposite direction. There are tens of thousands of robust C libraries available to suit any particular programming need. Many of Haskell's own libraries are based on C versions.

Semantic suckage tends to collect around those libraries that aren't pure Haskell, XHB has proven itself able to crash a _very_ mature piece of C software, the X server. You won't have to search long for security advisories exposing flaws in virtually every of those libraries, usually caused by fundamental flaws of the language. Your point?

Tool support for the C language (not for some successor you might think would exist if the language continued evolving) can detect memory leaks, detect memory overwrites, apply dozens of automatic refactorings to C large-scale C programs, etc.

Hacks, as I said. None of them are able to address the fundamental problems.

Library and tool support for the C language is light years beyond Haskell. It wouldn't be there if we had been through 20 iterations of C each completely breaking backward compatibility.

It wouldn't be there if C was younger than Haskell, either, but still suck the same. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

There's something I'm missing in all of this. Perl is in the process of rebooting itself (perl6 is syntactically very different from perl5; the closest it's ever previously gotten to this kind of radical change was the change from ' to :: as the package separator). Perl5 will continue to exist, and probably even be maintained. So why is it not possible to declare Haskell98 and Haskell10 (or whatever Haskell' becomes) as stable, maintained languages for production use, then reboot the Haskell development process? In fact, I thought that was the reason Haskell98 support is retained in Haskell compilers? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH