Scheme went one direction, Haskell went another: Why?
Grant Rettke
into those names, no apology on my part for doing so either) is that
both groups had competing versions of the language. Scheme had
different incompatible version of Scheme, and Haskell had different
statically typed functional programming languages which were
incompatible (Gofer, Miranda...). All were vying to be the top dog.
Scheme's solution was to make a spec on which everyone agreed.
Haskell's solution was to come up with one language called Haskell.
Time moved on and now there are still competing distributions of
Scheme and basically only one version of Haskell. Haskell of course
has all of the fun because everyone writes lots of good libraries for
it and in Scheme people are always complaining about portability and
how R6RS is broken.
Why didn't Scheme follow suit of Haskell?
Is it too late to chart such a course? What good would come of it?
Bruce Stephens
[...]
> Why didn't Scheme follow suit of Haskell?
I don't know.
A couple of possibilities suggest themselves:
1. It's hard to implement a purish functional language with type inference
and everything, whereas it's not so hard to implement a lispy language
(not so easy to produce a *good* implementation, but that's probably
not obvious when you begin...)
2. The purish functional languages were syntactically (and so arguably
gratuitously, since there was a feeling that they were semantically
more or less equivalent) incompatible, whereas lispy ones tend not to
be (or at least, not very incompatible). So perhaps there was more
pressure for the Haskell crowd.
George Neuner
Why should it? The statically typed FPL world is just as fragmented
as the Scheme world. The creation of Haskell didn't stop people from
using other functional languages ... far more people use some form of
ML than use Haskell, and Miranda still has a fair sized following.
Nor did Haskell conquer languages that came after it - lots of people
prefer to use Clean or Mercury.
>Is it too late to chart such a course? What good would come of it?
It's not too late, but it isn't likely to happen. Scheme had a dual
defined purpose as an implementation experimental platform and as a
teaching language ... the fact that it can actually be used
productively is, in some sense, incidental.
Codifying Scheme to unite the warring factions would stifle much of
its use for implementation experimentation - much like the CL standard
did for Lisp. Even the R_RS method is somewhat stifling ... despite
an obvious amenity to parallel execution, most Lisps and Schemes
remain serial because too much low level behavior has been over
specified. A Scheme implementation, however, is free to ignore R_RS
when compliance interferes - a CL implementation is not free to ignore
the CL standard.
George
Dirk van Deun
: Scheme and basically only one version of Haskell. Haskell of course
: has all of the fun because everyone writes lots of good libraries for
: it and in Scheme people are always complaining about portability and
: how R6RS is broken.
Note some similarities between Haskell, Perl, Ruby and Python:
- one open source implementation drives the innovation of language
features, other implementations may exist but are toys or
testbeds for radical innovation
- the real standard of the language is the behaviour of this main
implementation
- they have a single "official" website, i.e. for the language, not
for a particular implementation, easily recognizable as such:
python.org, haskell.org, ruby-lang.org, perl.org
- that site refers to a single "official" package repository
It's a small wonder that Haskell was able to become a member of this
club, I guess. The other three languages still have an active
benevolent dictator (the inventor), who can keep the lot together.
And Haskell has a standard, but (fortunately?) it is as out of
date as it is uncontroversial.
Dirk van Deun
--
Ceterum censeo Redmond delendum
Anton van Straaten
> The simplified story of "Scheme" and "Haskell" (I am lumping a lot
> into those names, no apology on my part for doing so either) is that
> both groups had competing versions of the language. Scheme had
> different incompatible version of Scheme, and Haskell had different
> statically typed functional programming languages which were
> incompatible (Gofer, Miranda...). All were vying to be the top dog.
>
> Scheme's solution was to make a spec on which everyone agreed.
> Haskell's solution was to come up with one language called Haskell.
The Haskell 98 Report (a spec on which everyone agreed) was released at
around the same time as R5RS. The distinction you're trying to make
here isn't clear to me.
One thing which may have made a difference in the Haskell world is that
Miranda was commercial, with restrictive licensing, so there was a
strong incentive to openness and cooperation for everyone other than the
Miranda author. Perhaps Scheme could have benefited from a similarly
obvious and immediate common foe to overcome.
> Time moved on and now there are still competing distributions of
> Scheme and basically only one version of Haskell. Haskell of course
> has all of the fun because everyone writes lots of good libraries for
> it and in Scheme people are always complaining about portability and
> how R6RS is broken.
>
> Why didn't Scheme follow suit of Haskell?
How, by having a single implementation become dramatically dominant?
Perhaps we could send a Terminator back in time to assassinate key
implementors of Schemes other than the chosen one?
I agree with Bruce Stephens, that the nature of Scheme made it easier to
develop superficially credible implementations. A larger number of
competing implementations makes standardization more difficult.
There are also deep technical factors involved, related to the nature of
the two languages. For example, Haskellers showed little interest in
having a macro system until relatively recently, whereas macros were
considered an important way to bootstrap an implementation in Scheme.
Having major, unresolved, difficult technical features like this be
central to the nature of the language guaranteed that standardization
would take longer and be more difficult.
This is also a reminder that Scheme has been a research platform for
these sorts of language features, and standardization is in opposition
to the goals of such research. For many people who have worked on
Scheme, the current Haskell situation may be considered an anti-goal.
In this respect, Scheme could be considered to have done better than
Haskell -- Haskellers themselves used to use the unofficial slogan
"avoid success at all costs", something which they seem to be failing at
recently. See this article:
http://www.computerworld.com.au/article/261007/-z_programming_languages_haskell?pp=10
A relevant quote from Simon Peyton-Jones:
"I�m primarily a programming language researcher, so the fact that
Haskell has up to now been used for just university types has been
ideal. Now it�s used a lot in industry but typically by people who are
generally flexible, and they are a generally a self selected rather
bright group. What that means is that we could change the language and
they wouldn�t complain. Now, however, they�re starting to complain if
their libraries don�t work, which means that we�re beginning to get
caught in the trap of being too successful."
Why do you want Scheme to be too successful? ;-)
Anton
Grant Rettke
> Grant Rettke wrote:
> > Scheme's solution was to make a spec on which everyone agreed.
> > Haskell's solution was to come up with one language called Haskell.
>
> The Haskell 98 Report (a spec on which everyone agreed) was released at
> around the same time as R5RS. The distinction you're trying to make
> here isn't clear to me.
The distinction I am trying to make is that one decision *seemingly*
resulted in a focused, thriving community while the other resulted in
a fractured, disjoint, and frustrated community. I am wondering if it
is as
simple as having one distribution versus many.
> How, by having a single implementation become dramatically dominant?
In the same way that it happened for Python, Perl, and Ruby.
> Perhaps we could send a Terminator back in time to assassinate key
> implementors of Schemes other than the chosen one?
Could I borrow your Terminator to help me move next weekend? I will
provide it with cold beer or whatever it likes :).
> Why do you want Scheme to be too successful? ;-)
The usual: my own selfish desires :P
Andrew Reilly
> The distinction I am trying to make is that one decision *seemingly*
> resulted in a focused, thriving community while the other resulted in a
> fractured, disjoint, and frustrated community. I am wondering if it is
> as
> simple as having one distribution versus many.
Why so negative? Scheme seems to be vibrant and thriving from where I'm
sitting. Maybe you're looking at it the wrong way?
Cheers,
--
Andrew
namekuseijin
Yeah, usenet can be pretty damn depressing at times. Some vocal
trolls may convince you that Scheme is as dead as Common Lisp.
Anyway, I don't mind several implementations as long as useful real-
world Scheme code could be portably run in any of them without much
fuss.
By useful real-world Scheme code I mean pragmatic code for interfacing
with standard OS features like threads, IO, messaging etc. We don't
need those to be part of a language standard obviously, but it'd be
truly nice if there was a common interface for them that most Scheme
implementations would agree to. Kinda like SRFI, except taken
seriously.
If that would work, I wouldn't mind if implementers went berserk on
experimental features or runaway performance optimizations. From a
practical standpoint, agreement on such common interfaces would go a
long way towards true portable real-world Scheme code repositories not
specific to this or that implementation. If later I choose to bind
those to implementation-specific features, it' my problem. Better
than being implementation-bound from day 1.
Benjamin L. Russell
<an...@appsolutions.com> wrote:
>[...]
>
>This is also a reminder that Scheme has been a research platform for
>these sorts of language features, and standardization is in opposition
>to the goals of such research. For many people who have worked on
>Scheme, the current Haskell situation may be considered an anti-goal.
>
>In this respect, Scheme could be considered to have done better than
>Haskell -- Haskellers themselves used to use the unofficial slogan
>"avoid success at all costs", something which they seem to be failing at
>recently. See this article:
>
>http://www.computerworld.com.au/article/261007/-z_programming_languages_haskell?pp=10
Interestingly, this phenomenon had already been predicted in the paper
"Wearing the hair shirt: a retrospective on Haskell" (Peyton Jones,
S., 2003) (see
http://research.microsoft.com/en-us/um/people/simonpj/papers/haskell-retrospective/index.htm)
(see slide 15); viz.:
> Tony Hoare's comment "I fear that Haskell is doomed to succeed"
Nevertheless, according to the paper "A History of Haskell: Being Lazy
With Class" (Hudak, Hughes, Jones, and Wadler, 2007) (see
http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/history.pdf)
(see page 10), there are definite reasons for striving to "avoid
success at all costs," as follows:
>The fact that Haskell has, thus far, managed the tension between
>these two strands of development [as a mature language, and as a
>laboratory in which to explore advanced language design ideas] is
>perhaps due to an accidental virtue: Haskell has not become too
>successful. The trouble with runaway success, such as that of Java,
>is that you get too many users, and the language becomes bogged
>down in standards, user groups, and legacy issues. In contrast, the
>Haskell community is small enough, and agile enough, that it usually
>not only absorbs language changes but positively welcomes them:
>it’s like throwing red meat to hyenas.
Sometimes it's actually better not to be too successful.
I need to keep reminding the folks over on Haskell-Cafe of this point
occasionally, lest they forget the spirit of Haskell.
>A relevant quote from Simon Peyton-Jones:
>
>"I’m primarily a programming language researcher, so the fact that
>Haskell has up to now been used for just university types has been
>ideal. Now it’s used a lot in industry but typically by people who are
>generally flexible, and they are a generally a self selected rather
>bright group. What that means is that we could change the language and
>they wouldn’t complain. Now, however, they’re starting to complain if
>their libraries don’t work, which means that we’re beginning to get
>caught in the trap of being too successful."
>
>Why do you want Scheme to be too successful? ;-)
Indeed. No need to have Scheme get bogged down in standards, user
groups, and legacy issues; the language would then cease to evolve.
Then we'd become just a slightly cleaned-up version of Common Lisp. No
need to forget the spirit of Scheme, either.
As an interesting sidenote, according to the above-mentioned paper
(Hudak, Hughes, Jones, and Wadler, 2007) (see page 3):
>"An anonymous reviewer supplied the following: 'An interesting sidelight
>is that the Friedman and Wise paper [“Cons should not evaluate its
>arguments” (Friedman and Wise, 1976) (see
>http://www.cs.indiana.edu/pub/techreports/TR44.pdf)] inspired Sussman
>and Steele to examine lazy evaluation in Scheme, and for a time they
>weighed whether to make the revised version of Scheme call-by-name
>or call-by-value. They eventually chose to retain the original
>call-by-value design, reasoning that it seemed to be much easier to
>simulate call-by-name in a call-by-value language (using lambda-expressions
>as thunks) than to simulate call-by-value in a call-by-name language (which
>requires a separate evaluation-forcing mechanism). Whatever we might
>think of that reasoning, we can only speculate on how different the
>academic programming-language landscape might be today had they made
>the opposite decision.”
Nevertheless, Lazy Scheme has actually been implemented as both a
language level and a module in PLT Scheme (see
http://docs.plt-scheme.org/lazy/index.html). Furthermore, according
to "The Design and Implementation of Typed Scheme" (Tobin-Hochstadt,
S., and Felleisen, M., 2008) (see page 2),
>[Typed Scheme] ... provides first-class polymorphic functions, known as
>impredicative polymorphism, a feature of the Glasgow Haskell Compiler
>(Vytiniotis et al. 2006).
Still furthermore, according to (Hudak, Hughes, Jones, and Wadler,
2007) (see page 5):
>It was also agreed at this meeting [The Glasgow Meeting] that Hudak and
>Wadler would be the editors of the first Haskell Report. The name of the
>report, “Report on the Programming Language Haskell, A Non-strict, Purely
>Functional Language,” was inspired in part by the “Report on the Algorithmic
>Language Scheme,” which in turn was modelled after the “Report on the
>Algorithmic Language Algol.”
In addition, according to the same paper (ibid.) (see page 31), Scheme
compilation techniques were initially explored in one implementation
of Haskell, known as Yale Haskell (although because of lack of a T
compiler and "performance and portability issues," Common Lisp wound
up being adopted, ironically eventually causing the abandonment of the
project, circa 1995):
>In the 1980s, prior to the development of Haskell, there was an
>active research project at Yale involving Scheme and a dialect of
>Scheme called T. SeveralMS and PhD theses grew out of this work,
>supervised mostly by Hudak. The Orbit compiler, an optimising
>compiler for T, was one of the key results of this effort (Kranz et al.,
>2004; Kranz et al., 1986).
>
>So once Hudak became actively involved in the design of Haskell,
>it was only natural to apply Scheme compilation techniques in an
>implementation of Haskell. However, rather than port the ideas to a
>stand-alone Haskell compiler, it seemed easier to compile Haskell
>into Scheme or T, and then use a Scheme compiler as a back end.
>Unfortunately, the T compiler was no longer being maintained and
>had problems with compilation speed. T was then abandoned in
>favour of Common Lisp to address performance and portability
>issues. This resulted in what became known as Yale Haskell.
>
>...
>
>Ultimately, the limitations of basing a Haskell compiler on a Common
>Lisp back-end caught up with the project. Although early
>on Yale Haskell was competitive with GHC and other compilers,
>GHC programs were soon running two to three times faster than
>Yale Haskell programs. Worse, there was no real hope of making
>Yale Haskell run any faster without replacing the back-end and runtime
>system. Optimisations such as reusing the storage in a thunk
>to hold the result after evaluation were impossible with the Common
>Lisp runtime system. The imperative nature of Lisp prevented
>many other optimisations that could be done in a Haskell-specific
>garbage collector and memory manager. Every thunk introduced an
>extra level of indirection (a Lisp cons cell) that was unnecessary in
>the other Haskell implementations. While performance within the
>strict subset of Haskell was comparable with other systems, there
>was a factor of 3 to 5 in lazy code that could not be overcome due
>to the limitations of the Lisp back end. For this reason, in addition
>to the lack of funding to pursue further research in this direction,
>the Yale Haskell implementation was abandoned circa 1995.
Furthermore, according to the same paper (ibid.) (see page 37):
>... Hudak’s research group and others began a flurry of
>research strands which they collectively referred to as functional
>reactive programming, or FRP.
>
>...
>
>Researchers at Brown have more recently ported the basic ideas of FRP
>[Functional Reactive Programming] into a Scheme environment called
>“Father Time” (Cooper and Krishnamurthi, 2006).
Thus, the languages Scheme and Haskell have historically influenced
the evolution of each other.
-- Benjamin L. Russell
References
Friedman, D. and Wise, D. (1976). CONS should not evaluate its
arguments. _Automata, Languages, and Programming_, pages
257-281.
Hudak, P., Hughes, J, Peyton Jones, S., and Wadler, P. (2007). A
History of Haskell: Being Lazy With Class. In _The Third ACM SIGPLAN
History of Programming Languages Conference (HOPL-III)_, pages 12-1 -
12-55, San Diego, California. ACM.
Peyton Jones, S. (2003). Wearing the hair shirt: a retrospective on
Haskell. Invited talk at POPL 2003. ACM.
Tobin-Hochstadt, S., and Felleisen, M. (2008). The Design and
Implementation of Typed Scheme. In _The 35th Annual ACM SIGPLAN -
SIGACT Symposium on Principles of Programming Languages_, pages
395-406, San Francisco, California. ACM.
Vytiniotis, D., Weirich, S., and Peyton Jones, S. Boxy
types: inference for higher-rank types and impredicativity. In _ICFP
’06: Proceedings of the Eleventh ACM SIGPLAN International Conference
on Functional Programming_, pages 251-62, New York, NY, USA,
2006. ACM Press.
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
Nicolas Neuss
> Yeah, usenet can be pretty damn depressing at times. Some vocal
> trolls may convince you that Scheme is as dead as Common Lisp.
I'd say it is your own fault if some vocal troll convinces you that either
of Scheme or Common Lisp is dead.
Nicolas
Elena
> It's not too late, but it isn't likely to happen. Scheme had a dual
> defined purpose as an implementation experimental platform and as a
> teaching language ... the fact that it can actually be used
> productively is, in some sense, incidental.
Excellent summary.
Regarding Haskell:
"The committee's ***primary goal*** was to design a language that
satisfied these constraints:
***1***. It should be suitable for teaching, research, ***and
applications, including building large systems***..." (
http://en.wikibooks.org/wiki/Haskell/YAHT/Preamble
)
That's it. Scheme will never be in the same league as Haskell, as long
as its standard committee's (primary) goals will be different.
Dirk van Deun
: > implementors of Schemes other than the chosen one?
That would be wasteful. What you really want to send back in time is a
Linus Torvalds clone.
Sam TH
> On Apr 8, 8:37 pm, George Neuner <gneun...@comcast.net> wrote:
>
> > It's not too late, but it isn't likely to happen. Scheme had a dual
> > defined purpose as an implementation experimental platform and as a
> > teaching language ... the fact that it can actually be used
> > productively is, in some sense, incidental.
>
> Excellent summary.
>
> Regarding Haskell:
>
> "The committee's ***primary goal*** was to design a language that
> satisfied these constraints:
> ***1***. It should be suitable for teaching, research, ***and
> )
>
> That's it. Scheme will never be in the same league as Haskell, as long
> as its standard committee's (primary) goals will be different.
Why would you think that the various committees have not had this as a
goal for Scheme? If you look at the various Scheme standardization
charters, they haven't listed goals, but I don't think any member of
those committees has been opposed to "building large systems". In
fact, many of those same standards authors have built large systems in
Scheme.
sam th
Elena
Not being opposed to something is a thing, having a goal as a primary
one is a quite different thing. Written down goals are more likely to
be reached, as self improvement techniques teach.
No intention to flame here, but: GHC kicks *every* Scheme
implementation's ass when it comes to evaluating a high performance
compiler with tools and libraries support, any doubt about that? SBCL
too, any doubt about that? Both compilers have been targeting large
scale industrial development right from the beginning. Don't get me
started about people using *any* language to build complex pieces of
software. Persistent and smart people manage to build complex things
with *whatever* tool you give them.
Cheers
Grant Rettke
I am just playing devil's advocate.
Sam TH
So you think that (a) Scheme is not designed with the same thought
towards usefulness for large systems as Haskell(!) and (b) that
writing this down as a goal would have helped in this.
I think both of these claims are false, and certainly would require
more argument than you've provided.
> No intention to flame here, but: GHC kicks *every* Scheme
> implementation's ass when it comes to evaluating a high performance
> compiler with tools and libraries support, any doubt about that? SBCL
> too, any doubt about that? Both compilers have been targeting large
> scale industrial development right from the beginning. Don't get me
> started about people using *any* language to build complex pieces of
> software. Persistent and smart people manage to build complex things
> with *whatever* tool you give them.
First, it's hard to compare the performance of implementations of
radically different languages. I believe that implementations such as
Ikarus, Chez Scheme, and others are competitive with SBCL. Chez
Scheme certainly targets industrial development.
As for tools, I'll put PLT Scheme up against GHC every day of the
week, and twice on Sundays. For libraries, I think the number of
Haskell libraries is larger, but not in terms of what comes with GHC,
compared to PLT Scheme.
Finally, I'm not sure what your point is here. If the question is why
did Haskell become more unified than Scheme, then talking about why
GHC is good is really missing the point - the question is why is GHC
in the position in the Haskell community that it is.
sam th
Marek Kubica
Elena <egar...@gmail.com> wrote:
> No intention to flame here, but: GHC kicks *every* Scheme
> implementation's ass when it comes to evaluating a high performance
> compiler with tools and libraries support, any doubt about that?
Industrial usage does not mean that it has to be fast. See Ruby and
Python which aren't particularly fast or designed for high performance
applications but still popular.
And some programmers that I respect very much have admitted that it is
quite hard to write well performing Haskell code (especially when you
try to write idiomatic code).
regards,
Marek
Elena
Comparing GHC with Chez Scheme is enough? Maybe they are in the same
league when it comes to performance, but I doubt the same happens when
it comes to available libraries and tools.
>
> > No intention to flame here, but: GHC kicks *every* Scheme
> > implementation's ass when it comes to evaluating a high performance
> > compiler with tools and libraries support, any doubt about that? SBCL
> > too, any doubt about that? Both compilers have been targeting large
> > scale industrial development right from the beginning. Don't get me
> > started about people using *any* language to build complex pieces of
> > software. Persistent and smart people manage to build complex things
> > with *whatever* tool you give them.
>
> First, it's hard to compare the performance of implementations of
> radically different languages. I believe that implementations such as
> Ikarus, Chez Scheme, and others are competitive with SBCL. Chez
> Scheme certainly targets industrial development.
>
> As for tools, I'll put PLT Scheme up against GHC every day of the
> week, and twice on Sundays. For libraries, I think the number of
> Haskell libraries is larger, but not in terms of what comes with GHC,
> compared to PLT Scheme.
I'm not talking about speed alone here. It could be that Gambit-C/Chez/
Ikarus can compete with GHC speed. Gambit-C maybe kicks GHC ass when
it comes to fair threads. But Schemes lose when you consider *a whole
set* of industrial strength features at once: posix threads,
multiplatform, tools and libraries, ecc. Each Scheme shines in a few
categories, whilst GHC and SBCL score high in many categories, those
required for industrial strength applications development.
>
> Finally, I'm not sure what your point is here. If the question is why
> did Haskell become more unified than Scheme, then talking about why
> GHC is good is really missing the point - the question is why is GHC
> in the position in the Haskell community that it is.
My point is that GHC and SBCL are industrial strength tools because
Haskell and Common Lisp are industrial strength languages *by design*.
Schemes are not industrial strength tools because Scheme is not an
industrial strength language *by design*. That's it.
Sam TH
There are a bunch of claims in this paragraph. I think most of them
are false. More importantly, the term "industrial strength languages"
doesn't make sense. What definition could you come up with that
includes Fortran IV and Python, but not Scheme?
Finally, there are plenty of Schemes that are industrial strength
tools. Chez Scheme sells for thousands of dollars per seat, or so I
hear.
sam th
Aaron W. Hsu
>Comparing GHC with Chez Scheme is enough? Maybe they are in the same
>league when it comes to performance, but I doubt the same happens when
>it comes to available libraries and tools.
Okay, I'll bite, but rather than throw around terms like industrial
strength and such, could you list the libraries that you use in your
development that are not available in a Scheme that is fast enough for
you? Likewise, could you name the tools in question, particularly?
When one throws around ideas in general like this, it is sort of like
throwing around random benchmarks saying that one thing is faster,
or better than the other. "Industry" is a terribly broad term,
and likewise, if you are writing an application, you don't care what
libraries are out there, you only care if you can program what you
want without wasting effort. This translates into have libraries
of code that help you with *your individual application*. As for tools,
well, show me the tools that you find indespensible in working with
GHC and SBCL. We can argue about specific instances, but arguing over
all the possibilities of Industry isn't going to get us anywhere,
because the possibilities are so broad, and the requirements are so
different.
I for one am aware that Chez Scheme is purchased and used by "Industry"
to good effect.
--
Aaron W. Hsu <arc...@sacrideo.us> | <http://www.sacrideo.us>
"Government is the great fiction, through which everybody endeavors to
live at the expense of everybody else." -- Frederic Bastiat
+++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) ++++++++++++++
Elena
> Elena <egarr...@gmail.com> writes:
> >Comparing GHC with Chez Scheme is enough? Maybe they are in the same
> >league when it comes to performance, but I doubt the same happens when
> >it comes to available libraries and tools.
>
> Okay, I'll bite, but rather than throw around terms like industrial
> strength and such, could you list the libraries that you use in your
> development that are not available in a Scheme that is fast enough for
> you? Likewise, could you name the tools in question, particularly?
>
> When one throws around ideas in general like this, it is sort of like
> throwing around random benchmarks saying that one thing is faster,
> or better than the other. "Industry" is a terribly broad term,
> and likewise, if you are writing an application, you don't care what
> libraries are out there, you only care if you can program what you
> want without wasting effort. This translates into have libraries
> of code that help you with *your individual application*. As for tools,
> well, show me the tools that you find indespensible in working with
> GHC and SBCL. We can argue about specific instances, but arguing over
> all the possibilities of Industry isn't going to get us anywhere,
> because the possibilities are so broad, and the requirements are so
> different.
>
> I for one am aware that Chez Scheme is purchased and used by "Industry"
> to good effect.
Yep, Aaron, Chez Scheme is a general purpose "industrial strength"
compiler, but it is a niche product. If it fits your bill, fine.
OTOH, GHC and SBCL are general purpose "industrial strength" compilers
and you could call them "reference implementations". That means many
more people sharing experiences and code. It is much more likely that
they fit your bill.
What I'm arguing here is that a language's "philosophy" matters.
Haskell and CL are languages which *explicitly* target industrial
applications development, therefore compilers and environments are
more likely to be "feature complete".
As a side note, Perl, Python and Ruby were born as "toy" tools, but
then had been driven by practical needs of industrial developers.
That's why they have succeeded.
What I'm striking here is "general purpose". If you develop in a wide
range of domains (web, system, GUI, etc.) a "general purpose" tool is
more likely to help you in every task. As a professional developer,
would you choose a single tool you can learn well and accomplish your
goals, or a wide range of different tools? I'm going with the former.
I'm not denying that some Schemes shine in niches. Gambit could
compete with Erlang, PLT has a web server and a wonderful web
framework, etc.
Cheers
Sam TH
I think the CL community might be surprised to discover that they have
acquired a "reference implementation".
You still haven't defined "industrial strength".
> What I'm arguing here is that a language's "philosophy" matters.
> Haskell and CL are languages which *explicitly* target industrial
> applications development, therefore compilers and environments are
> more likely to be "feature complete".
Your repeated claims to the contrary, this just isn't true about
Haskell. What do you think "avoid success at all costs" is about?
Why didn't GHC have a debugger until 2008?
> As a side note, Perl, Python and Ruby were born as "toy" tools, but
> then had been driven by practical needs of industrial developers.
> That's why they have succeeded.
Can you name 1 way in which Perl/Python/Ruby are "driven by practical
needs of industrial developers" that, say, PLT Scheme isn't?
> What I'm striking here is "general purpose". If you develop in a wide
> range of domains (web, system, GUI, etc.) a "general purpose" tool is
> more likely to help you in every task. As a professional developer,
> would you choose a single tool you can learn well and accomplish your
> goals, or a wide range of different tools? I'm going with the former.
>
> I'm not denying that some Schemes shine in niches. Gambit could
> compete with Erlang, PLT has a web server and a wonderful web
> framework, etc.
How many of these systems have you used? Why do you think the only
useful thing about PLT is the web server? Or that the only good thing
about Gambit is the concurrency?
Pascal J. Bourguignon
> There are a bunch of claims in this paragraph. I think most of them
> are false. More importantly, the term "industrial strength languages"
> doesn't make sense. What definition could you come up with that
> includes Fortran IV and Python, but not Scheme?
A definition by extension.
--
__Pascal Bourguignon__
http://www.informatimago.com
Elena
I think they wouldn't. I'd bet that if you are using SBCL, than most
libraries are going to "just work".
>
> You still haven't defined "industrial strength".
By "industrial strength" I mean a *reliable* tool with a set of
features which appeal to developers working in *very different*
domains, thus improving chances that such a tool will work for your
needs too. Most Scheme implementations are not that feature complete,
they are niche oriented, and depending on your needs you are much more
likely to switch gears. Do you need a newbie friendly environment? Go
PLT. Do you need highly scalable concurrency? Go Gambit. And so forth.
With GHC and SBCL you are more likely to stick with them. We could
argue that that's lack of choice, but it isn't. GHC and SBCL are very
likely to be good enough.
For instance, since currently I'm interested in a productive
environment mostly for web development, I'm going the PLT route. Let's
say, sometime in the future I'll need to accomplish a different task
which requires a fast and multi(native)threaded language. Then I'll
need to switch implementation and be very likely to learn everything
but R5RS again.
> > As a side note, Perl, Python and Ruby were born as "toy" tools, but
> > then had been driven by practical needs of industrial developers.
> > That's why they have succeeded.
>
> Can you name 1 way in which Perl/Python/Ruby are "driven by practical
> needs of industrial developers" that, say, PLT Scheme isn't?
Native threads, available both in Perl and Python, and going to be
available in Ruby 2.0.
> How many of these systems have you used? Why do you think the only
> useful thing about PLT is the web server? Or that the only good thing
> about Gambit is the concurrency?
PLT is much more than its web server and Gambit is much more than
concurrency. I just highlighted domains where this implementations
shine.
Pascal Costanza
> On Apr 9, 4:06 pm, Elena <egarr...@gmail.com> wrote:
>> On 9 Apr, 19:34, Sam TH <sam...@gmail.com> wrote:
>>> Finally, I'm not sure what your point is here. If the question is why
>>> did Haskell become more unified than Scheme, then talking about why
>>> GHC is good is really missing the point - the question is why is GHC
>>> in the position in the Haskell community that it is.
>> My point is that GHC and SBCL are industrial strength tools because
>> Haskell and Common Lisp are industrial strength languages *by design*.
>> Schemes are not industrial strength tools because Scheme is not an
>> industrial strength language *by design*. That's it.
>
> There are a bunch of claims in this paragraph. I think most of them
> are false. More importantly, the term "industrial strength languages"
> doesn't make sense. What definition could you come up with that
> includes Fortran IV and Python, but not Scheme?
Who cares what "industrial strength" means when you can do this:
http://www.imagine27.com/articles/2009-04-09-010147_live_lisp_art_opengl_synth_sound.html
?
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Elena
EDIT: Everything else I can think of about PLT Scheme rocks.
Eli Barzilay
There is an active project going on to add native thread support to
PLT. Must mean it's industrial strength now.
(As a sidenote, I don't know what your experience with "native
threads" in Perl, but practically everything that I heard -- and I
heard a lot -- was very loud complaining on how bad it is.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
namekuseijin
> Who cares what "industrial strength" means when you can do this:
>
Mighty interesting! I've played around with Nyquist before, but
nothing like this at all. :) (credits just now: it's Impromptu
actually)
He seems to get variations into the music by replacing his previous
code and sending individual definitions to be reevaluated. That is,
his composition is lost afterwards, right?
I always felt Bach was a kick-ass programmer. :)
Elena
> Elena <egarr...@gmail.com> writes:
> > On Apr 10, 12:02 pm, Sam TH <sam...@gmail.com> wrote:
>
> >> Can you name 1 way in which Perl/Python/Ruby are "driven by
> >> practical needs of industrial developers" that, say, PLT Scheme
> >> isn't?
>
> > Native threads, available both in Perl and Python, and going to be
> > available in Ruby 2.0.
>
> There is an active project going on to add native thread support to
> PLT. Must mean it's industrial strength now.
Really? That rocks! Yeaaaaaaaaaaaahhhhh! :D
Yes, it does (well, according to my definition).
> (As a sidenote, I don't know what your experience with "native
> threads" in Perl, but practically everything that I heard -- and I
> heard a lot -- was very loud complaining on how bad it is.)
Very little experience, indeed, but I know they are available. What I
was pointing out is: professional developers could find themselves in
need of native threads (for instance when they have to FFI-call a
legacy blocking routine). Tools acknowledge that and make them
available. That's what happens with FFI: they address real world
needs.
Marek Kubica
Elena <egar...@gmail.com> wrote:
> Native threads, available both in Perl and Python, and going to be
> available in Ruby 2.0.
Native threads in CPython (the reference implementation) aren't that
much fun due to the locking of the interpreter. So by your definition
CPython wouldn't be industrial strength anymore (there are laternatives
like Jython and IronPython and maybe unladen-swallow, but we were
talking about reference implementations).
regards,
Marek
Pascal Costanza
Yes, so much for program 'correctness'. :-P
Eli Barzilay
Well, if the feature that is needed to make the implementation
industrial strength is so poorly implemented that programmers curse
their way into something that works, then find out a ton of bugs
because of the bad implementation, then find that they still shipped
out a buggy product with more things they missed -- if all of that
happens, then I don't see how "just having threads" contributes
anything to being industrial strength.
Aaron W. Hsu
>What I'm arguing here is that a language's "philosophy" matters.
>Haskell and CL are languages which *explicitly* target industrial
>applications development, therefore compilers and environments are
>more likely to be "feature complete".
I just don't find this to be true. Applications are designed to suit
the needs of the users that use this software. Chez Scheme is
developed both for research and as an industrial Scheme *explicitely*.
It's design was always intended so. The fact that it has
pedagogical uses is a side. The features you find in Chez Scheme
*are* because Industry wanted them. The same, I suspect, is true
for GHC and Haskell.
What you *don't* see with Chez Scheme is all the code that has been
written for it. The reason is that most of this code is hidden,
proprietary, and quietly used. You often can't see what goes on
behind the scenes in commercial development.
When you say feature complete, I am guessing that you mean lots of
libraries and extensions. These are all well and good, but again,
I think you're really just arguing about nothing here. Libraries
do exist that are well designed that do satisfy a wide range of
industrial applications in Scheme, and in other languages. Whether
they are easy to find is another question. I don't think that
the problem is Scheme not targetting industry (because their needs,
of any, are probably easiest to meet), but rather, that Scheme's
confederatory nature hasn't really lent itself to traditional
distribution solutions, with no one (until now) filling the gap
with Scomething designed for a confederacy. Thus, what you claim
is a lack of Library availability, I claim is a lack of proper
access to a wide range of available libraries.
>What I'm striking here is "general purpose". If you develop in a wide
>range of domains (web, system, GUI, etc.) a "general purpose" tool is
>more likely to help you in every task. As a professional developer,
>would you choose a single tool you can learn well and accomplish your
>goals, or a wide range of different tools? I'm going with the former.
I'm saying that this isn't inherently a problem, and is more a problem
of perception and knowledge than anything.
Aaron W. Hsu
>By "industrial strength" I mean a *reliable* tool with a set of
>features which appeal to developers working in *very different*
>domains, thus improving chances that such a tool will work for your
>needs too. Most Scheme implementations are not that feature complete,
>they are niche oriented, and depending on your needs you are much more
>likely to switch gears. Do you need a newbie friendly environment? Go
>PLT. Do you need highly scalable concurrency? Go Gambit. And so forth.
So, then, Scheme is more industrial strength than any of the languages
you mentioned. Not only do we have good coverage of many niche
markets with specific designs, we have general-purpose Scheme
implementations that have large sets of built in libraries. We also
are able to use the same implementations to teach all sorts of programming
concepts, we have a multi-paradigm language capable of scaling to
many different problem domains in a specific way that other languages
can't. We have specialties and domains for pedagogy, research,
business, and so forth.
Just take Chez Scheme as a single example:
1) It's fast.
2) It's used very effectively in teaching domains.
3) It's used very effectively in research domains.
4) It's used very effectively in business domains.
5) It has fast native threading.
6) It has additional convenciences such as profiling
and a general inspector/debugger.
7) There is a large body of existing code that runs
on Chez Scheme, and my library repository is just an
example, which includes web frameworks, databases,
compilers, parsers, GUIs, AI, reasoning libraries,
numeric libraries, &c.
8) It is small and scriptable, and thus, fits easily
into the needs of embedded scripting languages.
9) A complete documentation system has been written in it
to support documenting systems.
So . . . obviously you don't think that's enough to make something
industrial strength. Did you have something else in mind? What
exactly do you want in a Scheme implementation? Your definition
of industrial is more like general-purpose, and it's hard to find
a language that is more general purpose than Scheme. I just gave
examples for Chez, but there is more than one Scheme which would
satisfy many of these requirements.
Elena
> Your definition
> of industrial is more like general-purpose, and it's hard to find
> a language that is more general purpose than Scheme. I just gave
> examples for Chez, but there is more than one Scheme which would
> satisfy many of these requirements.
Thank you very much, Aaron :)
Now, I understand what you mean. Now, I can't think of a more general
purpose language than Scheme. Damn, it can even be compiled to
JavaScript and run in your browser! Indeed, having to learn different
environments and libraries is much easier when they share a powerful
core language instead of relying on unrelated languages (therefore
semantics). I routinely use C++, Java, Perl, Javascript... I could
just use some sort of Scheme.
Cheers
Elena
> Well, if the feature that is needed to make the implementation
> industrial strength is so poorly implemented that programmers curse
> their way into something that works, then find out a ton of bugs
> because of the bad implementation, then find that they still shipped
> out a buggy product with more things they missed -- if all of that
> happens, then I don't see how "just having threads" contributes
> anything to being industrial strength.
I agree.
Elena
That's why we call it: "Worse is better". Sometimes you choose a worse
tool over a better one because you think the latter lacks what you
need. Then you discover that the worse tool's feature doesn't work as
advertised, but now you are stuck.
I didn't know Perl's native threads were broken, I did know they were
somewhat limited. I assumed that if such a feature was advertised,
then it would work.
I've been considering adopting PLT Scheme at my job, but I gave up
because it lacked native threads. Even if I think it is an outstanding
implementation, IMO native threads, even when limited in scope, are a
must-have feature for a general purpose language. I'm very happy about
having been told that such a gap in an otherwise awesome tool as PLT
Scheme is going to be filled in the near future.
Cheers