Lisper's first look at Haskell

62 views
Skip to first unread message

Slobodan Blazeski

unread,
Mar 9, 2008, 6:01:26 PM3/9/08
to
Sorry for spamming the group, but I wrote an article about Haskell
from Lisp point of view. So I would like to see some feedback from
all those lispers who do Haskell in case I wrote something really
stupid asI have only a week playing with Haskell. I know that I should
wait more but I just wanted this out of my mind.
http://tourdelisp.blogspot.com/2008/03/lisper-first-look-at-haskell.html

thanks
Slobodan

Jon Harrop

unread,
Mar 9, 2008, 7:28:07 PM3/9/08
to

There are many spelling mistakes: essey, togather, Unflexible, preying,
definately, Hakellers.

The vast majority of interlanguage blog posts are newbies blubbing. You have
done a better than average job in this respect but there is still a lot of
room for improvement:

You say that notepad is the best Haskell editor available for Windows. What
about Visual Studio?

You say "Big issue for someone used to full power of unification" but you
don't explain why Haskell (and all MLs) do not provide unification in their
pattern matchers.

You say "haskell looks like a family caravan against full blood racers" yet
you have no relevant and don't cite any references to substantiate your
view.

Statements like "It's like life in a monastery, full of fasting, preying and
compassion under the all seeing eye of the abbot, punishing you for every
mistake..." lend no credence to what you write. Anyone who makes serious
use of static typing will not take you seriously and anyone who doesn't
might be misguided by your opinion.

Finally, you do not appear to have sought advice from Haskell experts but,
instead, have posted directly to a Lisp newsgroup. You cannot hope to get
constructive criticism about Haskell from Lispers who, almost by
definition, don't know any modern programming languages.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u

Raffael Cavallaro

unread,
Mar 10, 2008, 12:51:59 AM3/10/08
to
On 2008-03-09 19:28:07 -0400, The Amphibian formerly known as Frog said:

> Statements like "It's like life in a monastery, full of fasting, preying and
> compassion under the all seeing eye of the abbot, punishing you for every
> mistake..." lend no credence to what you write. Anyone who makes serious
> use of static typing will not take you seriously and anyone who doesn't
> might be misguided by your opinion.

The irony of His Moistness complaining about a language being
misrepresented is truly priceless. You couldn't script this stuff -
really. Yet another data point showing that Usenet is funnier than
professional comics.

danb

unread,
Mar 10, 2008, 2:40:13 AM3/10/08
to
On Mar 9, 6:28 pm, Jon Harrop <use...@jdh30.plus.com> wrote:
> Lispers who, almost by definition,
> don't know any modern programming languages.

Lispers know tons of modern languages. We invent a new one
every time we write another application. :)

-------------------------------
Dan Bensen
http://www.prairienet.org/~dsb/

Lars Rune Nøstdal

unread,
Mar 10, 2008, 2:51:33 AM3/10/08
to
On Sun, 09 Mar 2008 23:28:07 +0000, Jon Harrop wrote:
>
> <blabla>

>
> from Lispers who, almost by definition, don't know any modern
> programming languages.

many do, few care

--
Lars Rune Nøstdal
http://nostdal.org/

Ken Tilton

unread,
Mar 10, 2008, 3:24:02 AM3/10/08
to

danb wrote:
> On Mar 9, 6:28 pm, Jon Harrop <use...@jdh30.plus.com> wrote:
>
>>Lispers who, almost by definition,
>>don't know any modern programming languages.
>
>
> Lispers know tons of modern languages. We invent a new one
> every time we write another application. :)

Good one.

Dan 1, Jon 0.

kenny

--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/

"In the morning, hear the Way;
in the evening, die content!"
-- Confucius

Slobodan Blazeski

unread,
Mar 10, 2008, 5:06:57 AM3/10/08
to

Great added to my collection of lisp quotes.

Slobodan Blazeski

unread,
Mar 10, 2008, 5:24:00 AM3/10/08
to
On Mar 10, 12:28 am, Jon Harrop <use...@jdh30.plus.com> wrote:
> Slobodan Blazeski wrote:
> > Sorry for spamming the group, but I wrote an article about Haskell
> > from Lisp point of view. So I would like to  see some feedback from
> > all those lispers who do Haskell in case I wrote something really
> > stupid asI have only a week playing with Haskell. I know that I should
> > wait more but I just wanted this out of my mind.
> >http://tourdelisp.blogspot.com/2008/03/lisper-first-look-at-haskell.html
>
> There are many spelling mistakes: essey, togather, Unflexible, preying,
> definately, Hakellers.
Thanks, your grammatical advice is invaluable.

>
> The vast majority of interlanguage blog posts are newbies blubbing. You have
> done a better than average job in this respect but there is still a lot of
> room for improvement:
>
> You say that notepad is the best Haskell editor available for Windows. What
> about Visual Studio?
Noninteractive. Forces me to install Visual Studio.

>
> You say "Big issue for someone used to full power of unification" but you
> don't explain why Haskell (and all MLs) do not provide unification in their
> pattern matchers.
I didn't designed Haskell nor ML, nor studied why they are designed as
they did.
So if you have idea why did Haskell designers decided to choose
pattern matching instead unification. Or why they didn't allow me to
repeat variable into a pattern, I'm all ears.You can use ML if you
prefer.

>
> You say "haskell looks like a family caravan against full blood racers" yet
> you have no relevant and don't cite any references to substantiate your
> view.
yes I did
Quote:
Haskell doesn't allows me to experiment. It doesn't allows me to
create modulus with some functions undefined or defined wrong. Bundle
this togather with loading file to redefine a module, the cruppiest
feature they took from Prolog and you'll start to value your lisp
listeners

Is above acceptable in your eyes that's up to you.


>
> Statements like "It's like life in a monastery, full of fasting, preying and
> compassion under the all seeing eye of the abbot, punishing you for every
> mistake..." lend no credence to what you write. Anyone who makes serious
> use of static typing will not take you seriously and anyone who doesn't
> might be misguided by your opinion.

Friend of mine suggested that I'm still in lisp mode so this might or
might not change later.


>
> Finally, you do not appear to have sought advice from Haskell experts but,
> instead, have posted directly to a Lisp newsgroup.

I seek criticism from Lispers who happens to know Haskell, that's why
the article is named like is named.
Quote
So this essey is from lisper point of view. I doubt that users of
other languages will find much use of it.


> You cannot hope to get
> constructive criticism about Haskell from Lispers who, almost by
> definition, don't know any modern programming languages.

Frog talk.

Slobodan Blazeski

unread,
Mar 10, 2008, 5:35:03 AM3/10/08
to
On Mar 10, 7:51 am, Lars Rune Nøstdal <larsnost...@gmail.com> wrote:
> On Sun, 09 Mar 2008 23:28:07 +0000, Jon Harrop wrote:
>
> > <blabla>
>
> > from Lispers who, almost by definition, don't know any modern    
> > programming languages.
>
> many do, few care

Another one for my collection of lisp quotes.

John Thingstad

unread,
Mar 10, 2008, 6:40:39 AM3/10/08
to
På Mon, 10 Mar 2008 10:24:00 +0100, skrev Slobodan Blazeski
<slobodan...@gmail.com>:

>
>> You cannot hope to get
>> constructive criticism about Haskell from Lispers who, almost by
>> definition, don't know any modern programming languages.
> Frog talk.
>>

How are your Prolog studies going?

--------------
John Thingstad

Alex Mizrahi

unread,
Mar 10, 2008, 6:56:42 AM3/10/08
to
SB>
http://tourdelisp.blogspot.com/2008/03/lisper-first-look-at-haskell.html

>Hogs a lot of brain resources. It's syntax is complex, and together with
static typing it forces me to spend more resources on dealing with language
than with dealing with the problem.

IMHO underlying semanitcs of lazy and recursive structures hogs a lot of
brain resources, syntax and types are only on surface.

my theory is that one needs a special kind of brain organization to be
comfortable with Haskell -- one needs to _think_ in logical expression,
probably this corresponds to audio thinking type. this is also a type of
thinking of hardcore mathematicians -- i mean those who prove theoremes,
rather than solving applied tasks.

but most people think in a visual way, so to understand Haskell they need to
convert these logical expressions into some visual structure -- and it's
pretty complex task, hence "Haskell hogs a lot of brain resources".

as for syntax, probably it's close to logical expressions in those wonderful
people minds, so they do not have problems deciphering it, and then
operating on these logical expressions as on first-class objects.
but again, this syntax is totally alient to "normal" people.

this does not mean that people should not learn Haskell -- it might be an
interesting challenge, brain is pretty flexible, so it can adapt to these
constructs.
but i seriously doubt that Haskell can become optimal language of choice for
people who do not find it's natural from beginning.


Slobodan Blazeski

unread,
Mar 10, 2008, 8:03:09 AM3/10/08
to
On Mar 10, 11:40 am, "John Thingstad" <jpth...@online.no> wrote:
> På Mon, 10 Mar 2008 10:24:00 +0100, skrev Slobodan Blazeski  
> <slobodan.blaze...@gmail.com>:

>
>
>
> >> You cannot hope to get
> >> constructive criticism about Haskell from Lispers who, almost by
> >> definition, don't know any modern programming languages.
> > Frog talk.
>
> How are your Prolog studies going?

They're on hold because of Haskell. I'm giving Haskell one more week
and that's this one. If I still don't like it I'm going back to
Prolog. I just hate to program and not have fun in my spare time.

Slobodan

Pertti Kellomäki

unread,
Mar 10, 2008, 8:43:40 AM3/10/08
to
Slobodan Blazeski kirjoitti:

> So I would like to see some feedback from
> all those lispers who do Haskell in case I wrote something really
> stupid asI have only a week playing with Haskell.

I would not go as far as labeling anything you wrote
stupid, but clearly you have not yet encountered your
muso when it comes to functional programming. Trying
to bring Lisp habits to Haskell is just not going to
work out. I am no expert in functional programming, but
I have dabbled in SML, Haskell, as well as Common Lisp
and Scheme.

You complain how you need to put a lot of effort into
dealing with the static typing. This is as it should be,
since in functional programming (of the ML, Haskell etc.
school), half of the action is in the types! Types in a
well designed functional program reflect the structure of
the problem, and nobody promised that analysis would be
easy.

As for the development tools, from a language point of
view it is irrelevant whether a graphical IDE exists or
not. Or would you say that the original Lisp was a crappy
language because there was no IDE?

If you have not read "What the hell are monads?", I encourage
you to do it. It is available in many places, here's the first
Google hit I got:
<http://web.cecs.pdx.edu/~antoy/Courses/TPFLP/lectures/MONADS/Noel/research/monads.html>

Monads can be difficult to wrap one's head around, but once
you see the light, they are a really powerful construct.
What one gets is referential transparency (i.e. no nasty mutable
state) even when dealing with the outside world. If you look at
some other functional languages, you will see that the impedance
mismatch between a pure functional computational world and the
mutating real world has always been a problem. So it is not
as if the Haskell designers were unaware of the problem until
they stumbled on it, and then cooked up something in a haste.
Rather, it is the invention of monads that really enables a
language such as Haskell to allow referential transparency,
laziness, and mutability to exist in harmony.

In my opinion it is the statically typed functional languages that
lispers should keep an eye on. If anything is going to drive Lisp
out of business, it is bound to come from that direction.
--
Pertti

Pertti Kellomäki

unread,
Mar 10, 2008, 8:51:32 AM3/10/08
to
Slobodan Blazeski kirjoitti:

> I'm giving Haskell one more week
> and that's this one. If I still don't like it I'm going back to
> Prolog. I just hate to program and not have fun in my spare time.

I appreciate your sentiment, but if you are only going to try out
things that you can master in a couple of weeks, you are going
to miss out on a lot of interesting stuff.
--
Pertti

Chris Barts

unread,
Mar 10, 2008, 9:10:10 AM3/10/08
to
Jon Harrop <use...@jdh30.plus.com> writes:

> Finally, you do not appear to have sought advice from Haskell experts but,
> instead, have posted directly to a Lisp newsgroup. You cannot hope to get
> constructive criticism about Haskell from Lispers who, almost by
> definition, don't know any modern programming languages.

Haskell does not qualify as a modern programming language. Neither does ML,
OCaml, or SML.

Pertti Kellomäki

unread,
Mar 10, 2008, 9:22:21 AM3/10/08
to
Chris Barts kirjoitti:

> Haskell does not qualify as a modern programming language. Neither does ML,
> OCaml, or SML.

Can you name some modern programming languages? Not that I
have anything against old fashioned languages, like CL ;-).
I'm just curious what qualifies a language as "modern".
--
Pertti

Ken Tilton

unread,
Mar 10, 2008, 9:52:05 AM3/10/08
to

Dynamic, reflective, GCed, typed data, untyped variables, absolutely
must treat code as any other kind of data, functions as first-class
objects, less than fifty <scratch scratch> sixty years old...

Slobodan Blazeski

unread,
Mar 10, 2008, 10:02:44 AM3/10/08
to
On Mar 10, 1:43 pm, Pertti Kellomäki <pertti.kellom...@tut.fi> wrote:
> Slobodan Blazeski kirjoitti:
>
> > So I would like to  see some feedback from
> > all those lispers who do Haskell in case I wrote something really
> > stupid asI have only a week playing with Haskell.
>
> I would not go as far as labeling anything you wrote
> stupid, but clearly you have not yet encountered your
> muso when it comes to functional programming. Trying
> to bring Lisp habits to Haskell is just not going to
> work out. I am no expert in functional programming, but
> I have dabbled in SML, Haskell, as well as Common Lisp
> and Scheme.
>
> You complain how you need to put a lot of effort into
> dealing with the static typing. This is as it should be,
> since in functional programming (of the ML, Haskell etc.
> school), half of the action is in the types! Types in a
> well designed functional program reflect the structure of
> the problem,
What about Erlang?

>and nobody promised that analysis would be
> easy.

I don't like to think that much. I prefer action. That's in my nature.
It's very rare to done something right the first time. Implementation
punching me in my nose every single time I make mistake is not my
friend, It's an adversary.


>
> As for the development tools, from a language point of
> view it is irrelevant whether a graphical IDE exists or
> not. Or would you say that the original Lisp was a crappy
> language because there was no IDE?

No language is living in void. In the real world it's made of :
1. Core language
2. Libraries
3. Programming tools
4. Community
5. Accumulated knowledge: books, tutorials , articles, code samples,
thesis etc


>
> If you have not read "What the hell are monads?", I encourage
> you to do it. It is available in many places, here's the first
> Google hit I got:

> <http://web.cecs.pdx.edu/~antoy/Courses/TPFLP/lectures/MONADS/Noel/res...>


>
> Monads can be difficult to wrap one's head around, but once
> you see the light, they are a really powerful construct.
> What one gets is referential transparency (i.e. no nasty mutable
> state) even when dealing with the outside world. If you look at
> some other functional languages, you will see that the impedance
> mismatch between a pure functional computational world and the
> mutating real world has always been a problem. So it is not
> as if the Haskell designers were unaware of the problem until
> they stumbled on it, and then cooked up something in a haste.
> Rather, it is the invention of monads that really enables a
> language such as Haskell to allow referential transparency,
> laziness, and mutability to exist in harmony.

I'm not ready to comment on the monads, I'll leave that for later.
Anyway thanks for the link.


>
> In my opinion it is the statically typed functional languages that
> lispers should keep an eye on. If anything is going to drive Lisp
> out of business, it is bound to come from that direction.

If you said functional we might got into some agreement about next
popular thing. Though I doubt that anybody could drive lisp out of
business. But what the hell does that has to with static typing?
Nobody is doing that now better than Erlang, and Erlang is dynamically
typed.
> --
> Pertti
While you're here could you please try to explain me what's type-
directed semantics?

thanks
Slobodan

Slobodan Blazeski

unread,
Mar 10, 2008, 10:08:32 AM3/10/08
to

My time is limited unless I see something that will justify to
continue my journey I'm not spending more time on Haskell. Even if
it's the most powerful langauge in the world, I'm not willing to
program in it if it doesn't fit my temper.

Slobodan
P.S.
Mastering takes years. Probably the better word is to learn. I agree
with you about missing lot of interesthing staff, but Quantum Physics
looks interesthing too but I'm not ready to spend years learning it.

Slobodan Blazeski

unread,
Mar 10, 2008, 10:47:38 AM3/10/08
to
On Mar 10, 2:52 pm, Ken Tilton <kennytil...@optonline.net> wrote:
> Pertti Kellomäki wrote:
> > Chris Barts kirjoitti:
>
> >> Haskell does not qualify as a modern programming language. Neither
> >> does ML,
> >> OCaml, or SML.
>
> > Can you name some modern programming languages? Not that I
> > have anything against old fashioned languages, like CL ;-).
> > I'm just curious what qualifies a language as "modern".
>
> Dynamic, reflective, GCed, typed data, untyped variables, absolutely
> must treat code as any other kind of data, functions as first-class
> objects, less than fifty <scratch scratch> sixty years old...

Wake up your Kennyness. Multicore processors are here and they're
going to stay.
Dual cores is already low end, Quads cores are coming close to
standard offer, and servers are 8 cores.
When nehalem hits the road this numbers will probably rize higher
probably to 16 cores. And there will be users hungry to utilizy all
those cores,so their app will run faster, so who will gonna developers
turn? Functional languages, where they'll get concurrency for
free.
>
> kenny
>
> --http://smuglispweeny.blogspot.com/http://www.theoryyalgebra.com/

Jon Harrop

unread,
Mar 10, 2008, 11:04:41 AM3/10/08
to
Slobodan Blazeski wrote:
> On Mar 10, 12:28 am, Jon Harrop <use...@jdh30.plus.com> wrote:
>> You say that notepad is the best Haskell editor available for Windows.
>> What about Visual Studio?
>
> Noninteractive.

I think it would be worth putting that in your article.

>> You say "Big issue for someone used to full power of unification" but you
>> don't explain why Haskell (and all MLs) do not provide unification in
>> their pattern matchers.
>
> I didn't designed Haskell nor ML, nor studied why they are designed as
> they did.
> So if you have idea why did Haskell designers decided to choose
> pattern matching instead unification. Or why they didn't allow me to
> repeat variable into a pattern, I'm all ears.You can use ML if you
> prefer.

Haskell and ML restrict pattern matching to linear patterns for two main
reasons:

. Predictable performance: linear patterns are matched in constant time.

. Checking: Haskell and ML patterns can be checked for various kinds of
correctness.

Unification provides a different set of trade-offs and, in particular, lacks
both of these features because unification can take an arbitrarily long
time and conveys no type information.

>> You say "haskell looks like a family caravan against full blood racers"
>> yet you have no relevant and don't cite any references to substantiate
>> your view.
>
> yes I did
> Quote:
> Haskell doesn't allows me to experiment. It doesn't allows me to
> create modulus with some functions undefined or defined wrong. Bundle
> this togather with loading file to redefine a module, the cruppiest
> feature they took from Prolog and you'll start to value your lisp
> listeners
>
> Is above acceptable in your eyes that's up to you.

You have only presented one side of the argument. The other side is:

. Haskell's static checking catches errors earlier in development, without
having to wait for the code to run.

. Haskell's static checking obviates 99% of unit tests.

This is why Haskell is so much faster to develop in that Lisp. The ability
to run broken code is insignificant in comparison.

>> Statements like "It's like life in a monastery, full of fasting, preying
>> and compassion under the all seeing eye of the abbot, punishing you for
>> every mistake..." lend no credence to what you write. Anyone who makes
>> serious use of static typing will not take you seriously and anyone who
>> doesn't might be misguided by your opinion.
>
> Friend of mine suggested that I'm still in lisp mode so this might or
> might not change later.

You sound like someone who has been dabbling in maths for a week and
concluded that mathematical proofs are just unnecessary "bondage and
discipline" and we should all just use our mathematical derivations to
build buildings and bridges without bothering to prove anything. Just plug
in a few numbers and make sure the answers look about right.

In practice, static typing with type inference has enormous benefits. You
get machine-verified documentation for free that is updated for you as you
develop. Performance improves enormously. Brevity improves enormousely.
Development time improves enormously...

>> Finally, you do not appear to have sought advice from Haskell experts
>> but, instead, have posted directly to a Lisp newsgroup.
>
> I seek criticism from Lispers who happens to know Haskell, that's why
> the article is named like is named.
> Quote
> So this essey is from lisper point of view. I doubt that users of
> other languages will find much use of it.

You would get more useful criticism from the Haskell community. Perhaps the
best people to ask would be former Lispers who now use Haskell.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.

http://www.ffconsultancy.com/products/?u

Pertti Kellomäki

unread,
Mar 10, 2008, 11:23:37 AM3/10/08
to
Slobodan Blazeski kirjoitti:

> On Mar 10, 1:43 pm, Pertti Kellomäki <pertti.kellom...@tut.fi> wrote:
>> in functional programming (of the ML, Haskell etc.
>> school), half of the action is in the types! Types in a
>> well designed functional program reflect the structure of
>> the problem,
> What about Erlang?

Another great language, but not in the ML, Haskell etc. school
of functional languages (see above). Erlang is also different
from Lisp and Haskell, because it is really a domain specific,
or maybe domain oriented language. And in the domain where Erlang
shines, complexity is in the interactions, not in the data.

If one could come up with the equivalent of a strong type system
for interactions, that would benefit Erlang much more than a
strong type system for data. [I know about process algebras,
but they are not quite there yet.]

> I don't like to think that much. I prefer action. That's in my nature.
> It's very rare to done something right the first time. Implementation
> punching me in my nose every single time I make mistake is not my
> friend, It's an adversary.

On the other hand, an implementation that lets you make mistakes
that blow on your face later on is a rather sloppy friend.

>> As for the development tools, from a language point of
>> view it is irrelevant whether a graphical IDE exists or
>> not. Or would you say that the original Lisp was a crappy
>> language because there was no IDE?
> No language is living in void. In the real world it's made of :
> 1. Core language
> 2. Libraries
> 3. Programming tools
> 4. Community
> 5. Accumulated knowledge: books, tutorials , articles, code samples,
> thesis etc

True, but one should be careful to distinguish between those.
By 2-5 in your list, the original Lisp would have been a poor
language, even though it was quite brilliant, especially for its
time. Likewise, one could argue that by 2-5, Java is a really good
language, even though reasonable people may disagree.

The design of the core language is in my opinion more important than
you make it appear, because it has rather profound effects on what
can be built on it. Just compare C libraries and C++ libraries.
Or Lisp libraries and Java libraries.

>> In my opinion it is the statically typed functional languages that
>> lispers should keep an eye on. If anything is going to drive Lisp
>> out of business, it is bound to come from that direction.
>
> If you said functional we might got into some agreement about next
> popular thing. Though I doubt that anybody could drive lisp out of
> business. But what the hell does that has to with static typing?
> Nobody is doing that now better than Erlang, and Erlang is dynamically
> typed.

Erlang is IMO irrelevant to this discussion. The reason why Erlang
is so good in its niche is that the model of computation is just
so right for the problem. In that domain, data (and computation)
is relatively simple compared to the complexity brought about by
distribution, that dynamic or static typing really does not matter
much.

My point is that if you look at how static typing has progressed,
type systems in more recent statically typed functional languages
are lightyears from the original "please reserve four bytes of memory
for this variable" variety. There is some information that can be
made explicit using a good type system that is left implicit in
a latently typed language.

My limited experience with Haskell has been that I only need to
explicitly write out types when it is a good idea to write them
for documentation purposes anyway. Type inference takes care of
the rest.

> While you're here could you please try to explain me what's type-
> directed semantics?

You just uncovered my ignorance there.
--
Pertti

Jochen Schmidt

unread,
Mar 10, 2008, 11:55:38 AM3/10/08
to
On 10 Mrz., 16:04, Jon Harrop <use...@jdh30.plus.com> wrote:
> . Haskell's static checking catches errors earlier in development, without
> having to wait for the code to run.

... catches a very restricted set of errors earlier in development,


without
having to wait for the code to run.

> . Haskell's static checking obviates 99% of unit tests.

Is that a proof by usenet posting? Even if you would reduce your
statistics to a more realistic value of perhaps 5-10%: It is often
easier to write the tests instead of being forced to program in a
static straitjacket.

> This is why Haskell is so much faster to develop in that Lisp. The ability
> to run broken code is insignificant in comparison.

Bzzt! Wrong. Running broken code in a debugging environment can be
very significant.

> You sound like someone who has been dabbling in maths for a week and
> concluded that mathematical proofs are just unnecessary "bondage and
> discipline" and we should all just use our mathematical derivations to
> build buildings and bridges without bothering to prove anything. Just plug
> in a few numbers and make sure the answers look about right.

Sounds to me like the perfect description of J. "Toady" Frogarrop, the
guy who tries to mislead newbies by feigning helpfulness and spreading
FUD about what he sees as the most dangerous business competition to
his very questionable and highly opinionated publications.

ciao,
Jochen

--
Jochen Schmidt
CRISPYLOGICS
Julienstr. 1, 90419 Nuremberg

Fon +49 (0)911 517 999 82
Fax +49 (0)911 517 999 83

mailto:in...@crispylogics.com
http://www.crispylogics.com

Slobodan Blazeski

unread,
Mar 10, 2008, 12:08:29 PM3/10/08
to
On Mar 10, 4:04 pm, Jon Harrop <use...@jdh30.plus.com> wrote:
> Slobodan Blazeski wrote:
> > On Mar 10, 12:28 am, Jon Harrop <use...@jdh30.plus.com> wrote:
> >> You say that notepad is the best Haskell editor available for Windows.
> >> What about Visual Studio?
>
> > Noninteractive.
>
> I think it would be worth putting that in your article.
I already did. I revised a little my article.

>
> >> You say "Big issue for someone used to full power of unification" but you
> >> don't explain why Haskell (and all MLs) do not provide unification in
> >> their pattern matchers.
>
> > I didn't designed Haskell nor ML, nor studied why they are designed as
> > they did.
> > So if you have idea why did Haskell designers decided to choose
> > pattern matching instead unification. Or why they didn't allow me to
> > repeat variable into a pattern, I'm all ears.You can use ML if you
> > prefer.
>
> Haskell and ML restrict pattern matching to linear patterns for two main
> reasons:
>
> . Predictable performance: linear patterns are matched in constant time.

Bad design. If I need performance I will code in c.


>
> . Checking: Haskell and ML patterns can be checked for various kinds of
> correctness.

Like what?


>
> Unification provides a different set of trade-offs and, in particular, lacks
> both of these features because unification can take an arbitrarily long
> time and conveys no type information.

Rubbish. I worked with Suciu algo and I could keep all the type
information I need, if I want to in the unification table.
Actually I might specify even more specific unification rules between
types.
Also there is no problem to unify in more than 2 sides in paralel.
like (unify (?x (1 2) ?z)
(2 ?y ?g)
(?g ?y 2))
The unification tables could be precompiled if you lack speed. But
unless you're doing some heavy number crunching or
game development performance is nothing to worry about.Will Ocaml be
faster. Probably but I don't care about that I want to easy on my
coding.
Oh yes occurs check is not implemented so that might brake algo for
now.


>
> >> You say "haskell looks like a family caravan against full blood racers"
> >> yet you have no relevant and don't cite any references to substantiate
> >> your view.
>
> > yes I did
> > Quote:
> > Haskell doesn't allows me to experiment. It doesn't allows me to
> > create modulus with some functions undefined or defined wrong. Bundle
> > this togather with loading file to redefine a module, the cruppiest
> > feature they took from Prolog and you'll start to value your lisp
> > listeners
>
> > Is above acceptable in your eyes that's up to you.
>
> You have only presented one side of the argument. The other side is:
>
> . Haskell's static checking catches errors earlier in development, without
> having to wait for the code to run.

No it doesn't. It catches type errors. The promise of error free code
when you finally got god damn thing to run is coming from revisiting
my code several times while trying to please the type system. I've
noticed that everytime I wrestled with type system I made changes in
my function that usually have nothing to do with the type system.


>
> . Haskell's static checking obviates 99% of unit tests.

BS I defined at least a dozen of functions this morning that were Ok
re static checking but would fail on certain inputs. Like one elements
list, negative Int, all uppercase string etc etc.
Nothing could replace writing unit tests.


>
> This is why Haskell is so much faster to develop in that Lisp.

Find better premises above two are easily found to be flowed


> The ability
> to run broken code is insignificant in comparison.

Frog talk.


>
> >> Statements like "It's like life in a monastery, full of fasting, preying
> >> and compassion under the all seeing eye of the abbot, punishing you for
> >> every mistake..." lend no credence to what you write. Anyone who makes
> >> serious use of static typing will not take you seriously and anyone who
> >> doesn't might be misguided by your opinion.
>
> > Friend of mine suggested that I'm still in lisp mode so this might or
> > might not change later.
>
> You sound like someone who has been dabbling in maths for a week and
> concluded that mathematical proofs are just unnecessary "bondage and
> discipline" and we should all just use our mathematical derivations to
> build buildings and bridges without bothering to prove anything. Just plug
> in a few numbers and make sure the answers look about right.

That's why I'm not interested in building unforgiving systems, I'll
leave them to you.
On the other side when my facebook freezes and fails to deliver
message I got little upset but nobody get kills.
When Mafia physics fails I get nervous but I reload the game. Nobody
gets hurt.


>
> In practice, static typing with type inference has enormous benefits. You
> get machine-verified documentation for free that is updated for you as you
> develop. Performance improves enormously. Brevity improves enormousely.
> Development time improves enormously...

Even more frog talk.


>
> >> Finally, you do not appear to have sought advice from Haskell experts
> >> but, instead, have posted directly to a Lisp newsgroup.
>
> > I seek criticism from Lispers who happens to know Haskell, that's why
> > the article is named like is named.
> > Quote
> > So this essey is from lisper point of view. I doubt that users of
> > other languages will find much use of it.
>
> You would get more useful criticism from the Haskell community. Perhaps the
> best people to ask would be former Lispers who now use Haskell.

I have some credit to spam c.l.l a bit, but no money on my Haskell
account.
On the other side you're in deep red.

Slobodan Blazeski

unread,
Mar 10, 2008, 12:24:40 PM3/10/08
to
On Mar 10, 4:23 pm, Pertti Kellomäki <pertti.kellom...@tut.fi> wrote:
> Slobodan Blazeski kirjoitti:
>
> > On Mar 10, 1:43 pm, Pertti Kellomäki <pertti.kellom...@tut.fi> wrote:
> >> in functional programming (of the ML, Haskell etc.
> >> school), half of the action is in the types! Types in a
> >> well designed functional program reflect the structure of
> >> the problem,
> > What about Erlang?
>
> Another great language, but not in the ML, Haskell etc. school
> of functional languages (see above). Erlang is also different
> from Lisp and Haskell, because it is really a domain specific,
> or maybe domain oriented language. And in the domain where Erlang
> shines, complexity is in the interactions, not in the data.
Having a strongest colelction of libraries in certain area doesn't
make you a domain specific language.
Erlang could be used as general purpose langauge. You could build even
OpenGL driven game engine with it if you want.

>
> If one could come up with the equivalent of a strong type system
> for interactions, that would benefit Erlang much more than a
> strong type system for data. [I know about process algebras,
> but they are not quite there yet.]
Why should they? It works great without it.

>
> > I don't like to think that much. I prefer action. That's in my nature.
> > It's very rare to done something right the first time. Implementation
> > punching me in my nose every single time I make mistake is not my
> > friend, It's an adversary.
>
> On the other hand, an implementation that lets you make mistakes
> that blow on your face later on is a rather sloppy friend.
It's usually easier to fix something than starting from scratch.
Static typing gets in my way of starting to produce anything.
If I didn't fix my mess later, than I don't worth much anyway.

>
> >> As for the development tools, from a language point of
> >> view it is irrelevant whether a graphical IDE exists or
> >> not. Or would you say that the original Lisp was a crappy
> >> language because there was no IDE?
> > No language is living in void. In the real world it's made of :
> > 1. Core language
> > 2. Libraries
> > 3. Programming tools
> > 4. Community
> > 5. Accumulated knowledge: books, tutorials , articles, code samples,
> > thesis etc
>
> True, but one should be careful to distinguish between those.
> By 2-5 in your list, the original Lisp would have been a poor
> language, even though it was quite brilliant, especially for its
> time. Likewise, one could argue that by 2-5, Java is a really good
> language, even though reasonable people may disagree.
Agreed.

>
> The design of the core language is in my opinion more important than
> you make it appear, because it has rather profound effects on what
> can be built on it.
B utthe final word would be on the full product. If you don't make
good 2-5 in your niche , people won't use it.

> Just compare C libraries and C++ libraries.
> Or Lisp libraries and Java libraries.

>
> >> In my opinion it is the statically typed functional languages that
> >> lispers should keep an eye on. If anything is going to drive Lisp
> >> out of business, it is bound to come from that direction.
>
> > If you said functional we might got into some agreement about next
> > popular thing. Though I doubt that anybody could drive lisp out of
> > business. But what the hell does that has to with static typing?
> > Nobody is doing that now better than Erlang, and Erlang is dynamically
> > typed.
>

> Erlang is IMO irrelevant to this discussion. <snipped>
Erlang is FUNCTIONAL general purpose dynamically typed programming
language . And the only thing I'm worried that could hurt lisp is
concurrency, because we're living in the age of multicore processors.
So unless your static typed languages could do FAR better than
dynamically typed Erlang in this area, I really don't why the hell
should I care about static typing.


>
> My point is that if you look at how static typing has progressed,
> type systems in more recent statically typed functional languages
> are lightyears from the original "please reserve four bytes of memory
> for this variable" variety. There is some information that can be
> made explicit using a good type system that is left implicit in
> a latently typed language.

So what? I don't give a damn about none of those.


>
> My limited experience with Haskell has been that I only need to
> explicitly write out types when it is a good idea to write them
> for documentation purposes anyway. Type inference takes care of
> the rest.

And I think you should gain more experience with it before giving
another newb advices, that goes for me too :)


>
> > While you're here could you please try to explain me what's type-
> > directed semantics?
>
> You just uncovered my ignorance there.

You've just missed the golden arrow. Next time lad.
> --
> Pertti

Ken Tilton

unread,
Mar 10, 2008, 1:01:56 PM3/10/08
to

Slobodan Blazeski wrote:
> On Mar 10, 2:52 pm, Ken Tilton <kennytil...@optonline.net> wrote:
>
>>Pertti Kellomäki wrote:
>>
>>>Chris Barts kirjoitti:
>>
>>>>Haskell does not qualify as a modern programming language. Neither
>>>>does ML,
>>>>OCaml, or SML.
>>
>>>Can you name some modern programming languages? Not that I
>>>have anything against old fashioned languages, like CL ;-).
>>>I'm just curious what qualifies a language as "modern".
>>
>>Dynamic, reflective, GCed, typed data, untyped variables, absolutely
>>must treat code as any other kind of data, functions as first-class
>>objects, less than fifty <scratch scratch> sixty years old...
>
>
> Wake up your Kennyness. Multicore processors are here and they're
> going to stay.
> Dual cores is already low end, Quads cores are coming close to
> standard offer, and servers are 8 cores.
> When nehalem hits the road this numbers will probably rize higher
> probably to 16 cores. And there will be users hungry to utilizy all

> those cores...

...in their Web 2.0 apps? Wake up Slobby and start learning Flex! I am,
as soon as I push a dinosaur desktop version of the Algebra software out
the door for laughs.

hth, kenny

--
http://smuglispweeny.blogspot.com/

Jon Harrop

unread,
Mar 10, 2008, 1:25:20 PM3/10/08
to
Jochen Schmidt wrote:
> On 10 Mrz., 16:04, Jon Harrop <use...@jdh30.plus.com> wrote:
>> . Haskell's static checking catches errors earlier in development,
>> without having to wait for the code to run.
>
> ... catches a very restricted set of errors earlier in development,
> without having to wait for the code to run.

Static type checking in these languages is widely reputed to catch "most
errors". If that were not true, unit testing would be as prevalent in
static languages like OCaml, Haskell and F# as it is in dynamic languages
like Lisp.

>> . Haskell's static checking obviates 99% of unit tests.
>
> Is that a proof by usenet posting?

That is the result of my survey of millions of lines of industrial code.
Programs written in dynamic languages like Lisp and Python devote up to 50%
of their codebase to unit testing. In contrast, OCaml and F# programs only
have 1-2% of their code devoted to tests. If you include unit testing code,
the static languages are also much more concise.

However, from my personal experience I would say that programmers using
dynamic languages like Lisp tend to be of below average ability and
productivity and choose Lisp because they don't know anything more modern.
This effect will bias the results because the quality of the code will be
different. Indeed, industrial code written in dynamic languages
(particularly Python) is typically of extremely poor quality by comparison.

Slobodan Blazeski

unread,
Mar 10, 2008, 1:36:14 PM3/10/08
to
On Mar 10, 6:01 pm, Ken Tilton <kennytil...@optonline.net> wrote:
> Slobodan Blazeski wrote:
> > On Mar 10, 2:52 pm, Ken Tilton <kennytil...@optonline.net> wrote:
>
> >>Pertti Kellomäki wrote:
>
> >>>Chris Barts kirjoitti:
>
> >>>>Haskell does not qualify as a modern programming language. Neither
> >>>>does ML,
> >>>>OCaml, or SML.
>
> >>>Can you name some modern programming languages? Not that I
> >>>have anything against old fashioned languages, like CL ;-).
> >>>I'm just curious what qualifies a language as "modern".
>
> >>Dynamic, reflective, GCed, typed data, untyped variables, absolutely
> >>must treat code as any other kind of data, functions as first-class
> >>objects, less than fifty <scratch scratch> sixty years old...
>
> > Wake up your Kennyness. Multicore processors are here and they're
> > going to stay.
> > Dual cores is already low end, Quads cores are coming close to
> > standard offer, and servers are 8 cores.
> > When nehalem hits the road this numbers will probably rize higher
> > probably to 16 cores. And there will be users hungry to utilizy all
> > those cores...
>
> ...in their Web 2.0 apps? Wake up Slobby and start learning Flex! I am,
> as soon as I push a dinosaur desktop version of the Algebra software out
> the door for laughs.


Just get out with it immediately , good software is good software.
BTW have you looked at weblocks?

Slobodan

Slobodan Blazeski

unread,
Mar 10, 2008, 1:42:27 PM3/10/08
to
On Mar 10, 6:25 pm, Jon Harrop <use...@jdh30.plus.com> wrote:
> Jochen Schmidt wrote:
> > On 10 Mrz., 16:04, Jon Harrop <use...@jdh30.plus.com> wrote:
> >> . Haskell's static checking catches errors earlier in development,
> >> without having to wait for the code to run.
>
> > ... catches a very restricted set of errors earlier in development,
> > without having to wait for the code to run.
>
> Static type checking in these languages is widely reputed to catch "most
> errors". If that were not true, unit testing would be as prevalent in
> static languages like OCaml, Haskell and F# as it is in dynamic languages
> like Lisp.
Lack of testing is certainly not something you should be proud of.

>
> >> . Haskell's static checking obviates 99% of unit tests.
>
> > Is that a proof by usenet posting?
>
> That is the result of my survey of millions of lines of industrial code.
> Programs written in dynamic languages like Lisp and Python devote up to 50%
> of their codebase to unit testing. In contrast, OCaml and F# programs only
> have 1-2% of their code devoted to tests. If you include unit testing code,
> the static languages are also much more concise.
>
> However, from my personal experience I would say that programmers using
> dynamic languages like Lisp tend to be of below average ability and
> productivity and choose Lisp because they don't know anything more modern.
> This effect will bias the results because the quality of the code will be
> different. Indeed, industrial code written in dynamic languages
> (particularly Python) is typically of extremely poor quality by comparison.

If you were such an expert as you trying to present yourself you
wouldn't have a minute reading newsgroups.
You would be busy doing your job. Here's a job add you might got
hired go get http://www.intellifactory.com/Jobs.aspx


Jon Harrop

unread,
Mar 10, 2008, 1:43:32 PM3/10/08
to
Slobodan Blazeski wrote:
> On Mar 10, 4:04 pm, Jon Harrop <use...@jdh30.plus.com> wrote:
>> . Predictable performance: linear patterns are matched in constant time.
>
> Bad design. If I need performance I will code in c.

Using C will neither improve the asymptotic complexity of your algorithm nor
make performance more predictable.

>> . Checking: Haskell and ML patterns can be checked for various kinds of
>> correctness.
>
> Like what?

Exhaustiveness, redundancy, inferred types, type correctness etc.

>> Unification provides a different set of trade-offs and, in particular,
>> lacks both of these features because unification can take an arbitrarily
>> long time and conveys no type information.
>
> Rubbish. I worked with Suciu algo and I could keep all the type
> information I need, if I want to in the unification table.

Consider this OCaml:

# function `A -> 0 | `B -> 2;;
- : [< `A | `B ] -> int = <fun>

The compiler inferred the sum type [< `A | `B ] and will check the
type-correctness of every application of this function. Unification
provides none of that.

> Actually I might specify even more specific unification rules between
> types.
> Also there is no problem to unify in more than 2 sides in paralel.
> like (unify (?x (1 2) ?z)
> (2 ?y ?g)
> (?g ?y 2))

But you won't get the warning that this is an inexhaustive match with an
example value that fails to match, e.g. (0 0 0), as you do in OCaml:

# function
| x, (1|2), z -> 0
| 2, y, g -> 1
| g, y, 2 -> 2;;
Warning P: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
(0, 0, 0)
- : int * int * int -> int = <fun>

This is exactly the kind of checking I was referring to.

>> . Haskell's static checking catches errors earlier in development,
>> without having to wait for the code to run.
>
> No it doesn't. It catches type errors. The promise of error free code
> when you finally got god damn thing to run is coming from revisiting
> my code several times while trying to please the type system. I've
> noticed that everytime I wrestled with type system I made changes in
> my function that usually have nothing to do with the type system.

Consider a list container type that must contain at least one element. You
can write such a container easily in Haskell or any ML and the compiler
will enforce the correctness (at least one element in every instance of the
container) throughout your entire program and will catch every single error
where you tried to create an empty list.

In contrast, a dynamic language provides nothing to help you whatsoever.
Leaving you on your own with a debugger to trawl stack traces after hours
or days of unit testing in an attempt to find out where you accidentally
created an empty list.

When you can leverage static checking, it is a huge win in terms of
development speed.

>> The ability to run broken code is insignificant in comparison.
>
> Frog talk.

Say you have an OCaml function:

let foo x y z =
oh no, what was I doing?!

That is a broken function, not yet completed. But I have a whole program
that references this incomplete function so it will not compile but I
believe it will not get called during my tests. What can I do?!

Actually, it is trivial. You comment out the broken code and raise an
exception instead:

let foo x y z =
raise Exit
(*
oh no, what was I doing?!
*)

The return type unifies with anything so there is no type error.

>> You sound like someone who has been dabbling in maths for a week and
>> concluded that mathematical proofs are just unnecessary "bondage and
>> discipline" and we should all just use our mathematical derivations to
>> build buildings and bridges without bothering to prove anything. Just
>> plug in a few numbers and make sure the answers look about right.
>
> That's why I'm not interested in building unforgiving systems, I'll
> leave them to you.

Assuming you work in industry, I cannot imagine a market where customers do
not demand reliability.

>> You would get more useful criticism from the Haskell community. Perhaps
>> the best people to ask would be former Lispers who now use Haskell.
>
> I have some credit to spam c.l.l a bit, but no money on my Haskell
> account.

I'm sure the Haskell community would warmly welcome a newcomer looking for
helpful advice.

Jon Harrop

unread,
Mar 10, 2008, 1:59:03 PM3/10/08
to
Slobodan Blazeski wrote:
> Lack of testing is certainly not something you should be proud of.

Only if it undermines reliability, which it does not if you are leveraging
static checking correctly.

> If you were such an expert as you trying to present yourself you
> wouldn't have a minute reading newsgroups. You would be busy doing your
> job.

On the contrary, experts find it easy to earn money and can spend more time
doing other things, like posting here. :-)

Ken Tilton

unread,
Mar 10, 2008, 2:20:33 PM3/10/08
to

Slobodan Blazeski wrote:
> Just get out with it immediately , good software is good software.

Looks like I have no choice, I sure don't want to work on it now.

> BTW have you looked at weblocks?

I am looking at OpenLaszlo, it has constraints (aka Cells). Can compile
to JS or DHTML. Or I might just do Flex, get something Interwebby on the
resume while I am at it.

Slobodan Blazeski

unread,
Mar 10, 2008, 3:33:17 PM3/10/08
to
Assuming that you know what the industry is. And it's nothing like
pond.

>
> >> You would get more useful criticism from the Haskell community. Perhaps
> >> the best people to ask would be former Lispers who now use Haskell.
>
> > I have some credit to spam c.l.l a bit, but no money on my Haskell
> > account.
>
> I'm sure the Haskell community would warmly welcome a newcomer looking for
> helpful advice.
Nope until Haskell proves worth learning I'm not interested becoming a
part of it's community

> > Lack of testing is certainly not something you should be proud of.
>
> Only if it undermines reliability, which it does not if you are leveraging
> static checking correctly.

Frog talk


>
> > If you were such an expert as you trying to present yourself you
> > wouldn't have a minute reading newsgroups. You would be busy doing your
> > job.
>
> On the contrary, experts find it easy to earn money and can spend more time
> doing other things, like posting here. :-)

Yeah and begging under the bridge

Slobodan Blazeski

unread,
Mar 10, 2008, 3:42:19 PM3/10/08
to
On Mar 10, 7:20 pm, Ken Tilton <kennytil...@optonline.net> wrote:
> Slobodan Blazeski wrote:
> > Just get out with it immediately , good software is good software.
>
> Looks like I have no choice, I sure don't want to work on it now.
>
> > BTW have you looked at weblocks?
>
> I am looking at OpenLaszlo, it has constraints (aka Cells). Can compile
> to JS or DHTML. Or I might just do Flex, get something Interwebby on the
> resume while I am at it.
>
> kenny
What's stopping you to at least look at weblocks? All your greatest
fans are there: me, Sohail, Leslie. Beside how many days you will need
to cellify it before you got bored. 4 days , 3 days, nah
I'm sure you could do it in less than 2 days. Beside you will got your
sweet revenge for the foolish lispers who ignored cells for years or
were too stupid to learn it. Now they will have to use it like it or
not to build do their pathetic Web 2.0 apps.

Slobodan
>
> --http://smuglispweeny.blogspot.com/http://www.theoryyalgebra.com/

Joost Diepenmaat

unread,
Mar 10, 2008, 3:45:37 PM3/10/08
to
Slobodan Blazeski <slobodan...@gmail.com> writes:

> What's stopping you to at least look at weblocks? All your greatest
> fans are there: me, Sohail, Leslie.

He's probably thinking of expanding his fan base ;-)

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

Slobodan Blazeski

unread,
Mar 10, 2008, 4:09:09 PM3/10/08
to
On Mar 10, 8:45 pm, Joost Diepenmaat <jo...@zeekat.nl> wrote:

> Slobodan Blazeski <slobodan.blaze...@gmail.com> writes:
> > What's stopping you to at least look at weblocks? All your greatest
> > fans are there: me, Sohail, Leslie.
>
> He's probably thinking of expanding his fan base ;-)
What for? The current ones didn't do any good.
Joke aside I hope that he will be happy with flex or OpenLaszlo. I was
wrong with pushing weblocks on him. Beside weblocks is continuations
beside, something that Kenny despises, and it's own declarative UI
building DSL. And if Kenny integrates it's cells in it it'll probably
grow into a framework with craziest flow in the world, if it ain't
already. As they say, people want technologies that are 15 minutes
before time, anything more and they'll shun them.

cheers
Slobodan

Slark

unread,
Mar 10, 2008, 4:13:14 PM3/10/08
to

"Ken Tilton" <kenny...@optonline.net> wrote in message
news:47d57c02$0$15162$607e...@cv.net...

>
>
> Slobodan Blazeski wrote:
>> Just get out with it immediately , good software is good software.
>
><snip>
>....Or I might just do Flex, get something Interwebby on the

> resume while I am at it.
>
> kenny
>
> --
> http://smuglispweeny.blogspot.com/
> http://www.theoryyalgebra.com/

Tho who's gonna replace Flex's actionscript with CL or, dare I say it...,
Ruby?...

Graham


Sohail Somani

unread,
Mar 10, 2008, 4:13:44 PM3/10/08
to
On Mon, 10 Mar 2008 12:42:19 -0700, Slobodan Blazeski wrote:

> What's stopping you to at least look at weblocks? All your greatest fans
> are there: me, Sohail, Leslie. Beside how many days you will need to
> cellify it before you got bored. 4 days , 3 days, nah I'm sure you could
> do it in less than 2 days. Beside you will got your sweet revenge for
> the foolish lispers who ignored cells for years or were too stupid to
> learn it. Now they will have to use it like it or not to build do their
> pathetic Web 2.0 apps.

Actually, I'm not currently using it but I think it is neat and novel.
Also, I think Slava has actually implemented his own CLOS dataflow hack!

--
Sohail Somani
http://uint32t.blogspot.com

Sohail Somani

unread,
Mar 10, 2008, 4:15:25 PM3/10/08
to
On Mon, 10 Mar 2008 20:13:14 +0000, Slark wrote:

> Tho who's gonna replace Flex's actionscript with CL or, dare I say
> it..., Ruby?...

I think someone needs to write a lisp->as macro. Why would you say Ruby
anyway?

Slark

unread,
Mar 10, 2008, 4:19:17 PM3/10/08
to

"Sohail Somani" <soh...@taggedtype.net> wrote in message
news:xFgBj.75265$FO1.60003@edtnps82...

Or an as repl for cl...

Graham


Ken Tilton

unread,
Mar 10, 2008, 4:36:42 PM3/10/08
to

Slobodan Blazeski wrote:
> On Mar 10, 7:20 pm, Ken Tilton <kennytil...@optonline.net> wrote:
>
>>Slobodan Blazeski wrote:
>>
>>>Just get out with it immediately , good software is good software.
>>
>>Looks like I have no choice, I sure don't want to work on it now.
>>
>>
>>>BTW have you looked at weblocks?
>>
>>I am looking at OpenLaszlo, it has constraints (aka Cells). Can compile
>>to JS or DHTML. Or I might just do Flex, get something Interwebby on the
>>resume while I am at it.
>>
>>kenny
>
> What's stopping you to at least look at weblocks?

I thought I did. Hunch yes, no mention of AServe. JS yes, AS no. And you
should know how I feel about eye candy:

http://www.tilton-technology.com/cello-shot-03.jpg

I'll might hold out for Flash. As for that list of dependencies...
impressive! But it ain't over till the fat lady ships her RIA -- I might
skimp on the jazzy webface and then Weblocks has a shot (but you'll need
an endorsement from Edi, I use what he uses.)

OpenLaszlo still gets an edge for working w/out JS, tho. But I am still
learning. The crux of the matter is MathML, and mainstream browser
support for that bites. But it looks like Flash supports it. That could
be The Decider.

kenny

--
http://smuglispweeny.blogspot.com/

Edi Weitz

unread,
Mar 10, 2008, 4:38:20 PM3/10/08
to
On Mon, 10 Mar 2008 16:36:42 -0400, Ken Tilton <kenny...@optonline.net> wrote:

> but you'll need an endorsement from Edi, I use what he uses.

LispWorks?

--

European Common Lisp Meeting, Amsterdam, April 19/20, 2008

http://weitz.de/eclm2008/

Real email: (replace (subseq "spam...@agharta.de" 5) "edi")

Sohail Somani

unread,
Mar 10, 2008, 4:43:22 PM3/10/08
to
On Mon, 10 Mar 2008 16:36:42 -0400, Ken Tilton wrote:

> OpenLaszlo still gets an edge for working w/out JS, tho. But I am still
> learning. The crux of the matter is MathML, and mainstream browser
> support for that bites. But it looks like Flash supports it. That could
> be The Decider.

Weblocks works with and without JS. But OpenLazlo looks pretty cool,
thanks for pointing it out.

William James

unread,
Mar 10, 2008, 4:47:30 PM3/10/08
to
On Mar 10, 1:40 am, danb <sogwal...@gmail.com> wrote:
> On Mar 9, 6:28 pm, Jon Harrop <use...@jdh30.plus.com> wrote:
>
> > Lispers who, almost by definition,
> > don't know any modern programming languages.
>
> Lispers know tons of modern languages. We invent a new one
> every time we write another application. :)

No, that's what Forthers do.

Message has been deleted

Jochen Schmidt

unread,
Mar 10, 2008, 5:24:24 PM3/10/08
to
On 10 Mrz., 18:25, Jon Harrop <use...@jdh30.plus.com> wrote:
> Jochen Schmidt wrote:
> > On 10 Mrz., 16:04, Jon Harrop <use...@jdh30.plus.com> wrote:
> >> . Haskell's static checking catches errors earlier in development,
> >> without having to wait for the code to run.
>
> > ... catches a very restricted set of errors earlier in development,
> > without having to wait for the code to run.
>
> Static type checking in these languages is widely reputed to catch "most
> errors". If that were not true, unit testing would be as prevalent in
> static languages like OCaml, Haskell and F# as it is in dynamic languages
> like Lisp.

Reputation doesn't impress me; C, C++ and Java are languages with a
very good reputation compared to all languages you advertise here so
often. The lack of unit testing in OCaml, Haskell and F# doesn't
necessarily mean that there is no need for it - if there is really so
much less at all and your not just making that up again. Btw:
Categorizing programming languages in a single dimension between
dynamic and static is quite naive and is usually a sign of little
experience with real life programs!

> >> . Haskell's static checking obviates 99% of unit tests.
>
> > Is that a proof by usenet posting?
>
> That is the result of my survey of millions of lines of industrial code.
> Programs written in dynamic languages like Lisp and Python devote up to 50%
> of their codebase to unit testing. In contrast, OCaml and F# programs only
> have 1-2% of their code devoted to tests. If you include unit testing code,
> the static languages are also much more concise.

Were did you actually publish the survey? I couldn't find any sources
- What kind of science is that? And what do you mean by "industrial
code"? Do you have any examples or is that just made up? Did you ever
realize that there is a big difference between Lisp and Python? Why do
you always group them together? My guess: You look at python
codebases to draw conclusions about Common Lisp. If you even look - I
actually think that all you post here and in the many other newsgroups
is just made up in your mind.

> However, from my personal experience I would say that programmers using
> dynamic languages like Lisp tend to be of below average ability and
> productivity and choose Lisp because they don't know anything more modern.
> This effect will bias the results because the quality of the code will be
> different. Indeed, industrial code written in dynamic languages
> (particularly Python) is typically of extremely poor quality by comparison.

Which experience is that? Do you only call it personal because you
cannot prove anything about it? It's just made up, is it? How many
professional Lisp programmers did you really test? And what exactly is
a "modern language"? You just use that word because you want your
readers believe that you actually know of a qualitative difference -
in reality it's just made up. In exactly what way is ML more modern
than e.g. Common Lisp, Prolog or Smalltalk? Don't you find it funny
sometimes that ML actually calls itself "Meta Language" while Common
Lisp is by far means the better "Meta Language"?

How can anyone with a healthy mind do any business with someone who
tries to earn money by misleading people. You actively fool people to
get their money; not even stopping at conscious lying. Why do you post
to Java Groups that there is nobody using it, why do you try to market
languages as "modern" or "not modern" here in Common Lisp? Why do play
the helpful guy on comp.lang.fortran before recommend buying your
books about... not fortran! The way of unethical marketing your
questionable stuff is so distasteful that I just can hope that more
people realize the hidden agenda.

Jochen Schmidt

Jochen Schmidt

unread,
Mar 10, 2008, 5:28:55 PM3/10/08
to
On 10 Mrz., 18:59, Jon Harrop <use...@jdh30.plus.com> wrote:
> On the contrary, experts find it easy to earn money and can spend more time
> doing other things, like posting here. :-)

Well - that at least means you're no expert - since you're actually
here to try to earn money (by misleading people to buy questionable
publications).

Edi Weitz

unread,
Mar 10, 2008, 5:36:57 PM3/10/08
to
On Mon, 10 Mar 2008 14:24:24 -0700 (PDT), Jochen Schmidt <j...@crispylogics.com> wrote:

> How can anyone with a healthy mind do any business with someone who
> tries to earn money by misleading people. You actively fool people
> to get their money; not even stopping at conscious lying. Why do you
> post to Java Groups that there is nobody using it, why do you try to
> market languages as "modern" or "not modern" here in Common Lisp?
> Why do play the helpful guy on comp.lang.fortran before recommend
> buying your books about... not fortran! The way of unethical
> marketing your questionable stuff is so distasteful that I just can
> hope that more people realize the hidden agenda.

BTW, if you ever wondered how our beloved little toad looks like -
here he is:

http://www.dotnetrocks.com/default.aspx?showNum=266

Charming, isn't he?

Edi.

Pertti Kellomäki

unread,
Mar 10, 2008, 6:42:16 PM3/10/08
to
Slobodan Blazeski kirjoitti:

> Having a strongest colelction of libraries in certain area doesn't
> make you a domain specific language.

No, but an execution model based on light weight processes
communicating by best effort message passing does give quite
strong hints as to where the language might be useful. The
libraries are just an added bonus.

> Erlang could be used as general purpose langauge. You could build even
> OpenGL driven game engine with it if you want.

I'm sure it would be possible, but not making a very good use
of the language. Erlang was never intended to be a general purpose
language, and it would be somewhat mediocre at that as far as
functional programming languages are concerned. You don't have to
believe me, just ask Ulf Wiger who is a regular at comp.lang.functional
and is one of the designers of Erlang. I am pretty sure he would agree.

>> If one could come up with the equivalent of a strong type system
>> for interactions, that would benefit Erlang much more than a
>> strong type system for data. [I know about process algebras,
>> but they are not quite there yet.]
> Why should they? It works great without it.

I'm not saying that they should, I'm saying that a type system
for behavioral properties would be *more useful* than a type
system for data for Erlang. For example, it would be more useful to
have a type system to express and enforce that a given set of processes
implement an atomic transaction, than to have a type system that
could express and enforce that a given list only contains integers.

> Static typing gets in my way of starting to produce anything.

It should not be a big surprise that one particular way of
thinking does not suit everyone. But then again it could just
be that you haven't quite gone native yet. Even when coming from
a functionalish language like Lisp, the purely functional way of
thinking does require some getting used to.

>>> No language is living in void. In the real world it's made of :
>>> 1. Core language
>>> 2. Libraries
>>> 3. Programming tools
>>> 4. Community
>>> 5. Accumulated knowledge: books, tutorials , articles, code samples,
>>> thesis etc

[...]


> B utthe final word would be on the full product. If you don't make
> good 2-5 in your niche , people won't use it.

I am not claiming otherwise. I just don't think it has much to do
how good or bad the *language* is. A good enough core language like
Python that is strong on the rest has a good chance of being used.
But it is entirely possible to have a brilliant core language that
just does not accumulate the rest of the critical mass. Would not
be the first time that technical merits do not win in the marketplace.

>> Erlang is IMO irrelevant to this discussion. <snipped>
> Erlang is FUNCTIONAL general purpose dynamically typed programming
> language . And the only thing I'm worried that could hurt lisp is
> concurrency, because we're living in the age of multicore processors.
> So unless your static typed languages could do FAR better than
> dynamically typed Erlang in this area, I really don't why the hell
> should I care about static typing.

They are not *my* statically typed languages. The only language
I could rightly call mine was a dynamically scoped bastard cousin
of Lisp that I implemented before I knew better.

The reason I said that Erlang is irrelevant to this discussion
is that it is targeted to a problem domain where data is simple,
and strong typing would not give much added value. Therefore the
fact that Erlang is dynamically typed does not prove anything one
way or another.

>> There is some information that can be
>> made explicit using a good type system that is left implicit in
>> a latently typed language.
> So what? I don't give a damn about none of those.

Using a good type system it might for example be possible to
express the invariant properties of a red-black tree. Then by declaring
a function be of type red_black_tree -> red_black_tree, one would
then be guaranteed _by the type system_ that the function respects
those invariants. I'm not up to speed with dependent types, so I
don't know if they are expressive enough yet to do what I described,
but that is the direction type systems are headed to. I know for fact
that you could do that by programming in the logic of the PVS theorem
prover and compiling it to Common Lisp.

>> My limited experience with Haskell has been that I only need to
>> explicitly write out types when it is a good idea to write them
>> for documentation purposes anyway. Type inference takes care of
>> the rest.
> And I think you should gain more experience with it before giving
> another newb advices, that goes for me too :)

I never said I was clueless. I've had a fair bit of experience
on Scheme and CL, and on the typed side of the fence I have spent
some time with SML, Clean and Haskell. So my opinions do have
a little bit of empirical backing.
--
Pertti

jim burton

unread,
Mar 10, 2008, 7:21:57 PM3/10/08
to
Slobodan Blazeski wrote:
> Sorry for spamming the group, but I wrote an article about Haskell
> from Lisp point of view. So I would like to see some feedback from
> all those lispers who do Haskell in case I wrote something really
> stupid asI have only a week playing with Haskell. I know that I should
> wait more but I just wanted this out of my mind.
> http://tourdelisp.blogspot.com/2008/03/lisper-first-look-at-haskell.html
>

I don't qualify as a lisper, knowing only a little CL and scheme but,
yes, you should have spent longer looking at haskell. In fact it
strikes me as ridiculous that you make such a litany of dogmatic
remarks about it after dabbling with it in a random way for such a
short time. Many of your remarks, from the wild generalisations to the
misinformed details, are badly mistaken and could be put right by
persevering for a while. Unless...this is a circle jerk for your
c.l.l. pals! OMG, I just realised I wasted my time typing this
message! Rats.

> thanks
> Slobodan

tim

unread,
Mar 10, 2008, 9:41:06 PM3/10/08
to
On Mon, 10 Mar 2008 17:25:20 +0000, Jon Harrop wrote:

> Jochen Schmidt wrote:
>> On 10 Mrz., 16:04, Jon Harrop <use...@jdh30.plus.com> wrote:
>>> . Haskell's static checking catches errors earlier in development,
>>> without having to wait for the code to run.
>>
>> ... catches a very restricted set of errors earlier in development,
>> without having to wait for the code to run.

Dead right. And a lot of the "errors" that get picked up are artifacts
that result from the presence of type declarations. The limited bugs
picked up by type checking do not go anywhere near allowing a large
reduction in unit tests.

> This effect will bias the results because the quality of the code will be
> different. Indeed, industrial code written in dynamic languages
> (particularly Python) is typically of extremely poor quality by comparison.
>

Now you've offended everyone at Google.

Were the results about code quality and unit testing you
mentioned earlier published anywhere?

Tim

jason....@gmail.com

unread,
Mar 10, 2008, 9:45:42 PM3/10/08
to

I don't understand how simply knowing that you have a correct type
significantly reduces unit testing effort. A C/C++ compiler can
determine if I have correct types, but it can't determine if my
program has correct behaviour. Unit tests are primarily about correct
_behaviour_ of isolated "units" of code e.g. behaviour under error
conditions, required pre/post conditions, does it give expected
results etc.

I'm reminded of when I was a student and I was first learning to
program using Pascal. I was ecstatic when I got something to compile
- but to claim that the static checking done by the compiler had any
bearing on correct program behaviour is a stretch in my opinion.

Jon Harrop

unread,
Mar 10, 2008, 11:53:35 PM3/10/08
to
tim wrote:
> On Mon, 10 Mar 2008 17:25:20 +0000, Jon Harrop wrote:
>> Jochen Schmidt wrote:
>>> On 10 Mrz., 16:04, Jon Harrop <use...@jdh30.plus.com> wrote:
>>>> . Haskell's static checking catches errors earlier in development,
>>>> without having to wait for the code to run.
>>>
>>> ... catches a very restricted set of errors earlier in development,
>>> without having to wait for the code to run.
>
> Dead right. And a lot of the "errors" that get picked up are artifacts
> that result from the presence of type declarations. The limited bugs
> picked up by type checking do not go anywhere near allowing a large
> reduction in unit tests.

You're assuming there are type declarations.

>> This effect will bias the results because the quality of the code will be
>> different. Indeed, industrial code written in dynamic languages
>> (particularly Python) is typically of extremely poor quality by
>> comparison.
>
> Now you've offended everyone at Google.
>
> Were the results about code quality and unit testing you
> mentioned earlier published anywhere?

No. I was going to collate some results because I found an article about
unit testing in dynamic languages that cited several significant projects
(>>10kLOC) that devoted more code to unit testing that everything else
combined.

Jon Harrop

unread,
Mar 11, 2008, 12:17:17 AM3/11/08
to
Jochen Schmidt wrote:
> And what do you mean by "industrial code"?

To understand that, you just need to compare your products page with ours:

http://www.crispylogics.com/en/products
http://www.ffconsultancy.com/products/?cl

Incidentally, you should replace "do you want an existing software to get
customized?" with "do you want existing software customized?".

One thing of interest:

http://www.crispylogics.com/en/downloads/opensource/

You are the first non-Haskell users of darcs that I've heard of...

Jon Harrop

unread,
Mar 11, 2008, 12:32:07 AM3/11/08
to
jason....@gmail.com wrote:
> I don't understand how simply knowing that you have a correct type
> significantly reduces unit testing effort.

With an expressive type system (e.g. Haskell/ML), types convey a lot of
information and checking the types buys you a lot of correctness as a
consequence.

> A C/C++ compiler can
> determine if I have correct types, but it can't determine if my
> program has correct behaviour.

Sure. C/C++ aren't even safe. Java is a step in the right direction and
addresses many of the more serious problems with C++ but it still suffers
terribly from null reference exceptions because it has only a very
rudimentary type system, e.g. cannot express non-null references. A more
expressive type system can massively increase code density (to match most
dynamic languages) and eliminate null reference exceptions as well as many
other sources of error.

> Unit tests are primarily about correct
> _behaviour_ of isolated "units" of code e.g. behaviour under error
> conditions, required pre/post conditions, does it give expected
> results etc.

In dynamic languages, unit tests also pick up type errors, e.g. one kind of
value has been passed to a function that was not expecting that kind of
value, or a function has been passed the wrong number of arguments. These
unit tests can be made almost entirely unnecessary with static typing.

> I'm reminded of when I was a student and I was first learning to
> program using Pascal. I was ecstatic when I got something to compile
> - but to claim that the static checking done by the compiler had any
> bearing on correct program behaviour is a stretch in my opinion.

Yes. Pascal has a comparatively simple type system.

tim

unread,
Mar 11, 2008, 1:30:33 AM3/11/08
to
On Tue, 11 Mar 2008 03:53:35 +0000, Jon Harrop wrote:

> tim wrote:
>> On Mon, 10 Mar 2008 17:25:20 +0000, Jon Harrop wrote:
>>> Jochen Schmidt wrote:
>>>> On 10 Mrz., 16:04, Jon Harrop <use...@jdh30.plus.com> wrote:
>>>>> . Haskell's static checking catches errors earlier in development,
>>>>> without having to wait for the code to run.
>>>>
>>>> ... catches a very restricted set of errors earlier in development,
>>>> without having to wait for the code to run.
>>
>> Dead right. And a lot of the "errors" that get picked up are artifacts
>> that result from the presence of type declarations. The limited bugs
>> picked up by type checking do not go anywhere near allowing a large
>> reduction in unit tests.
>
> You're assuming there are type declarations.
>

In SBCL it does type inference and complains of inconsistencies. This can
be a good or bad thing. ... but this is just based on what it picks up
along the way.

In Haskell it can sometimes infer the types and then you don't have to be
explicit about it. But as I understand it you need to provide the
equivalent of type declarations, though sometimes in a more indirect way.
"Haskell: the craft of functional programming" has six chapters with
"type[s]" in the chapter title.

Beyond that I'm not sure what you mean.

Tim

Stanisław Halik

unread,
Mar 11, 2008, 2:15:05 AM3/11/08
to
thus spoke tim <Ti...@internet.com>:

>> You're assuming there are type declarations.
> In SBCL it does type inference and complains of inconsistencies. This can
> be a good or bad thing. ... but this is just based on what it picks up
> along the way.

This isn't of much use anyway, as type inferences can't be reliably done
for non-inline user-defined functions due to the possibility of
redefinition. sb-impl::%fun-type can be used to check them anyway.

--
Nawet świnka wejdzie na drzewo kiedy ją chwalą.

Vagif Verdi

unread,
Mar 11, 2008, 3:38:30 AM3/11/08
to
>http://tourdelisp.blogspot.com/2008/03/lisper-first-look-at-haskell.html
>
> thanks
> Slobodan

I'm a lisper, and i spent some time with haskell. Much longer though
than you.
I love haskell and its concise and very elegant syntax. I also have no
problems with IO monads.

But as I dabbled further, I stumbled into monad transformers.
You can read my comments about them here:
http://reddit.com/info/691v1/comments/c037it9

That was a wall i hit my head on.

I hope I will eventually find time and desire to overcome this
obstacle, but my enthusiasm about haskell is severely damaged.

Aatu Koskensilta

unread,
Mar 11, 2008, 7:24:06 AM3/11/08