Lisper's first look at Haskell
Slobodan Blazeski
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
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
> 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
> 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
>
> <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
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
Great added to my collection of lisp quotes.
Slobodan Blazeski
> 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.
>
> 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.
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.
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
> 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
<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
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
> På Mon, 10 Mar 2008 10:24:00 +0100, skrev Slobodan Blazeski
>
>
>
> >> 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
> 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
> 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
> 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
> 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
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
> 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.
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
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
> 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
> 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.
Pertti Kellomäki
> 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
> . 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
Slobodan Blazeski
> 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.
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
> 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.
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.]
>
> > 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.
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.
>
> 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.
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
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
> 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
> 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
> 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.
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
> 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
> 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
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
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.
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
> 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
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
> 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
> 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 ;-)
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
"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.
>
>....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
> 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
> 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
"Sohail Somani" <soh...@taggedtype.net> wrote in message
news:xFgBj.75265$FO1.60003@edtnps82...
Or an as repl for cl...
Graham
Ken Tilton
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
> but you'll need an endorsement from Edi, I use what he uses.
LispWorks?
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
Real email: (replace (subseq "spam...@agharta.de" 5) "edi")
Sohail Somani
> 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
> 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.
Jochen Schmidt
> 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
> 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
> 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
> 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
> 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
> 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
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
> 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
> 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
> 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
> 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
>> 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
>
> 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
> 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.
One of the reasons to prefer a powerful type system is precisely the
ability to encode some such conditions and information in the
types. The usefulness of a type system depends on which conditions are
expressible in it, and with what amount of effort.
> 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.
Well, Pascal is not exactly known for its powerful type system. In any
case, if one does not use the type system for anything useful it
obviously will be nothing but a burden. Learning to program in
languages such as Haskell involves learning how to use its type system
to do useful thing, just as one would learn to use macros etc. when
learning Common Lisp or Scheme. Don't think of the type system as a
straight-jacket, think of it as something to hack, a tool -- or just
continue writing your code in a dynamically typed language if that's
your thing.
--
Aatu Koskensilta (aatu.kos...@xortec.fi)
"Wovon man nicht sprechen kann, daruber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
Jochen Schmidt
> 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
I don't see any industrial code on your page - for how many years did
you try to get something done?
There is no doubt that crispylogics is a startup; can you say that
about your business? At least *I* can say that in all the years I
published as a journalist and professional software developer - I
never tried to mislead people by questionable and dissembling business
tactics!
--
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
> 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...
I think you confuse something here; I never said anything against
Haskell. Just because I criticize you about your business tactics and
your FUD about languages like Common Lisp? I've already used Haskell
for some projects and darcs is certainly an interesting piece of
software.
Jochen Schmidt
Jon Harrop
I mean that static typing does not imply the presence of type declarations.
So your statement that type declarations introduce unnecessary type errors
doesn't apply to static typing (though perhaps it applies to Haskell).
However, you are supposed to add declarations to refine types and catch more
errors. If you're adding declarations and not refining types but
introducing unnecessary problems then it is your style of coding that is
broken and that does not reflect upon static typing. One problem is that
Haskell's type system is not as powerful as OCaml's in that it requires you
to declare (sum) types.
Jon Harrop
> I don't see any industrial code on your page - for how many years did
> you try to get something done?
We've been shipping products for three years.
> There is no doubt that crispylogics is a startup; can you say that
> about your business?
Yes. We were founded in 2005 and shipped our first product (OCaml for
Scientists) within 1 month. Since then, we have built eight more product
lines covering C#, F#, OCaml and Mathematica.
>> 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...
>
> I've already used Haskell for some projects and darcs is certainly an
> interesting piece of software.
That's very interesting. The OCaml community were debating the merits of
using darcs as a package management system for a new OCaml distribution.
Two of the main points against it were:
. Nobody outside the Haskell community uses it (but you do).
. Some people said they found it extremely slow.
Slobodan Blazeski
>
> >> You are the first non-Haskell users of darcs that I've heard of...
Just visit the http://common-lisp.net and you'll see plenty of darcs
projects. I believe 95 % of their authors ever tried Haskell.
>
> > I've already used Haskell for some projects and darcs is certainly an
> > interesting piece of software.
>
> That's very interesting. The OCaml community were debating the merits of
> using darcs as a package management system for a new OCaml distribution.
> Two of the main points against it were:
>
> . Nobody outside the Haskell community uses it (but you do).
> . Some people said they found it extremely slow.
Try Mercurial. Usually darcs users convert to it where they have
performance problems.
http://changelog.complete.org/posts/588-Re-Examining-Darcs-Mercurial.html
Marco Antoniotti
wrote:
> thus spoke tim <T...@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.
>
This has always been one of the most baffling assertions about CL.
While it is true that redefinition makes "harder" to do type
inference, it does not prevent it. CL environment usually (and
traditionally) maintain a lot of information about who is calling what
and viceversa. Using a similar setup to track signature changes is
doable.
Note that this is a completely different argument than saying that CL
does not have a type system built from scratch with the specific goal
of supporting type inference. Now, this is where the fun starts.
Cheers
--
Marco
Slobodan Blazeski
> 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.
I posted those remarks because I want to be able to analyze them
later. Most of the time after certain amount of using something:
language, library, technology etc I get used to it and all those first
impressions what's wrong with it are already gone. I just take the
thing as it is. And few of those first impressions I discover far
later as a limitations of the language. So after I finish the book and
decipher thw code. I'm interested in purely functional data structures
I will post an update.
Marco Antoniotti
> > I don't see any industrial code on your page - for how many years did
> > you try to get something done?
>
> We've been shipping products for three years.
>
> > There is no doubt that crispylogics is a startup; can you say that
> > about your business?
>
> Yes. We were founded in 2005 and shipped our first product (OCaml for
> Scientists) within 1 month. Since then, we have built eight more product
> lines covering C#, F#, OCaml and Mathematica.
>
> >> 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...
>
> > I've already used Haskell for some projects and darcs is certainly an
> > interesting piece of software.
>
> That's very interesting. The OCaml community were debating the merits of
> using darcs as a package management system for a new OCaml distribution.
> Two of the main points against it were:
>
> . Nobody outside the Haskell community uses it (but you do).
There are plenty of projects on common-lisp.net that use it.
> . Some people said they found it extremely slow.
There seems to be some snag in the implementation of the patch algebra
that may make it blow up exponentially. I heard (although I have not
checked) that this has been fixed.
Cheers
--
Marco
Slobodan Blazeski
> Slobodan Blazeski kirjoitti:
> > 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.
we're pretty much Ok.
The problem is that you're mixing purely functional way with static
typing.
According to Hudak Paul:
In computer science, functional programming is a programming paradigm
that treats computation as the evaluation of mathematical functions
and avoids state and mutable data. It emphasizes the application of
functions, in contrast with the imperative programming style that
emphasizes changes in state.[1]
Where it does it mention static typing? Or you have another definition
of functional programming.
So I could program in pure functional style in common lisp or even C+
+, though it probably won't be most natural thing to do.
And I already presented Erlang as functional langauge that doesn't
incoporate static typing as example. And don't manouver with what
certain language is best suited for. If it's Touring complete I could
theoretically make every computation.
So I'm looking for a prove that purely functional way of programming
requires static typing?
Slobodan Blazeski
> >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.
the eye of the beholder.
Or I might be too attached to beauty of s-expression. There are some
other langauges that have a syntax I found elegant like forth, but
Haskell is not one of the,
>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.
Thanks I will look at it.I still didn't arrived at monads.
Pertti Kellomäki
> On Mar 10, 11:42 pm, Pertti Kellomäki <pertti.kellom...@tut.fi> wrote:
>> Even when coming from
>> a functionalish language like Lisp, the purely functional way of
>> thinking does require some getting used to.
> This is the only point we disagree too much, the rest of the post
> we're pretty much Ok.
> The problem is that you're mixing purely functional way with static
> typing.
Yes, sloppy writing from my part. Should have written "SML-Haskell
style of functional thinking" or something like that.
Much of the power of functional programming comes from higher order
functions. If you throw in lazy evaluation, it would be pretty much
impossible to reason about functions that can have side-effects.
It is not purely coincidental that expressive type systems and
functional programming often go hand in hand. If you do a lot of
stuff using higher order functions, a type system is a very useful
tool for getting things right. Compared to typical Haskell code,
the use of higher order functions in CL is usually fairly "shallow".
Things like map or apply that are conceptually simple.
If you take a look at the current functional programming landscape,
you would be hard pressed to find many languages that do not have
static typing.
--
Pertti
Pascal J. Bourguignon
> Slobodan Blazeski kirjoitti:
>> On Mar 10, 11:42 pm, Pertti Kellomäki <pertti.kellom...@tut.fi> wrote:
>>> Even when coming from
>>> a functionalish language like Lisp, the purely functional way of
>>> thinking does require some getting used to.
>> This is the only point we disagree too much, the rest of the post
>> we're pretty much Ok.
>> The problem is that you're mixing purely functional way with static
>> typing.
>
> Yes, sloppy writing from my part. Should have written "SML-Haskell
> style of functional thinking" or something like that.
>
> Much of the power of functional programming comes from higher order
> functions. If you throw in lazy evaluation, it would be pretty much
> impossible to reason about functions that can have side-effects.
>
> It is not purely coincidental that expressive type systems and
> functional programming often go hand in hand. If you do a lot of
> stuff using higher order functions, a type system is a very useful
> tool for getting things right. Compared to typical Haskell code,
> the use of higher order functions in CL is usually fairly "shallow".
> Things like map or apply that are conceptually simple.
Could you elaborate more? In what case would haskell programmer make
more intensive use of higher order functions?
In lisp, we could easily use them (closures) for data abstraction, but
since we have structures and CLOS objects, it's often more practical
to use them (even if more "stateful"). I can imagine that if we
implemented most of our data structures to functions, we'd get
mechanically more higher-order function usage.
Isn't it what happens to haskell programmers? They'd be lacking good
data structures and be implementing them with functions? Or do they
really have applications that involve naturally more higher order
functions?
--
__Pascal Bourguignon__
Jon Harrop
> According to Hudak Paul:
> In computer science, functional programming is a programming paradigm
> that treats computation as the evaluation of mathematical functions
> and avoids state and mutable data. It emphasizes the application of
> functions, in contrast with the imperative programming style that
> emphasizes changes in state.[1]
That is a Haskeller's definition of "functional programming". Most
non-Haskellers regard functional programming as a style that makes heavy
use of first-class functions.
Kaz Kylheku
That's just because the designers feel insecure in the face of
criticism from the mainstream. They think that static typing and
syntax which looks like serial line noise is the way of overcoming
popularity obstacles. (It's not working, yet they continue).
So how do you write the following under static typing?
(some-function (read-from-string "arbitrary data"))
Replace the literal "arbitrary data" with an expression that pulls a
string from the operating system.
Suppose that SOME-FUNCTION only takes integers.
Now what?
Or how about:
(funcall (compile nil arbitrary-data) 42)
How do you know that ARBITRARY-DATA, computed based on run-time
inputs, will compile to a function that can accept 42 as an argument,
and what happens if it doesn't?
Can I make a Haskell (..., etc) program out of a hundred modules, and
then edit and recompile just one of them in total isolation, and load
it into the running application? If you can do that, where is the
static typing now?
The whole idea that a program goes through three separate phases
once---compiling, loading/linking and running---is obsolete. It's a
niche technique for small embedded systems with limited resources, and
simple software like operating system utilities. Much of the software
you interact with everyday couldn't be developed with static typing
(or without static typing being defeated all over the place).
What is the Haskell equivalent of COMPILE-FILE? LOAD? I'm looking at
section 5.7 of the Haskell 98 report:
``the precise details of separate compilation are not defined by this
report''.
The module system addresses only basic semantic issues of namespace
hygiene and interface abstraction, not issues of system construction.
That's not an adequate answer, sorry. Lisp does define the precise
details of separate compilation, the effects of loading, control of
evaluation semantics that differ between compilation, loading and
execution, etc.
These features are vastly more useful for software development than a
static type system.
See, Haskell and its ilk is just a semantic gadget that assigns a
computational meaning to strings; they are not full-blown languages.
They are sublanguages that need to be embedded in a host environment
in order to make sense.
Trouble is, that host environment is missing, and things like /bin/sh
and /usr/bin/make are poor substitutes.
A compiler is nothing; it's just a subroutine for optimizing code. In
Lisp, the compiler is a library function. In thes other languages,
it's an executable that sits in your /usr/bin on a Linux box or C:
\Program Files\ on Windows. Sorry, that is dumb; I'd rather be hacking
in C.
Maybe this kind of thing is a common extension? Let's see:
Glasgow Haskell Compiler: nothing is mentioned in the description of
its extensions about dynamic compiling and loading. It's just a
compiler: that what in Lisp is just a subroutine for optimizing the
representation of a module of code.
Hugs: right on the home page, we have this: ``An almost complete
implementation of the Haskell module system.'' An /almost/ complete
implementation of something which does next to nothing?
nhc98: Nope. But it comes with something called ``hmake''. What is
hmake? Is it a build system like ASDF that is integrated into the
image? Heck no, it's another oeprating system command line utility
which controls the execution of operating system jobs.
Yhc: ``Warning, this compiler is not finished, and is not useable as a
standard Haskell Compiler.'' Enough read.
Barry Margolin
Pertti Kellomäki <pertti.k...@tut.fi> wrote:
> If you take a look at the current functional programming landscape,
> you would be hard pressed to find many languages that do not have
> static typing.
Isn't that true of programming languages in general? For as long as
there have been high-level languages, the vast majority have been
statically typed. So it's hardly a hallmark of functional programming.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Slobodan Blazeski
<snipped>
> If you take a look at the current functional programming landscape,
> you would be hard pressed to find many languages that do not have
> static typing.
> --
> Pertti
But they exist, you just have to look further than "SML-Haskell
style of functional thinking". I already found them, and they have
interesthing things, something that I've expected to learn from
Haskell. I will continue to learn some more Haskell to be able to
decipher the book code I'm interested in, than part with it. It's
just not my type of language.
Slobodan
Stanisław Halik
>>> 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.
> This has always been one of the most baffling assertions about CL.
> While it is true that redefinition makes "harder" to do type
> inference, it does not prevent it. CL environment usually (and
> traditionally) maintain a lot of information about who is calling what
> and viceversa. Using a similar setup to track signature changes is
> doable.
Even if type inference were to propagate with function redefinition, a
dynamic variable is enough to punch a hole in the whole scheme. Nothing
more specific than a type of T could be inferred unless some extension
to CL is devised.
Personally speaking, the incremental development model is more than
enough for me to compensate for the lack of "proper" type inference and
other compile-time invariants. Perhaps if the REPL was to be replaced
with compile-cycles, invariants and static code analysis would come in
handy.
Pascal Costanza
Scheme?
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Slobodan Blazeski
Pascal Costanza
The functional programming landscape doesn't consist only of pure
functional languages. It's true that higher-order functions are not used
a lot in Common Lisp, but in Scheme it's a much more common practice.
Slobodan Blazeski
at least not according to wikipedia, if that's an acceptible source.
Scheme is a multi-paradigm programming language
http://en.wikipedia.org/wiki/Scheme_(programming_language)
>It's true that higher-order functions are not used
> a lot in Common Lisp,
now I'm interested about tacit programming and non lambda calculus
based ones.
>
> Pascal
>
> --
> 1st European Lisp Symposium (ELS'08)http://prog.vub.ac.be/~pcostanza/els08/
>
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/- Hide quoted text -
>
> - Show quoted text -
Andrew Reilly
> In article <fr6258$qvi$1...@news.cc.tut.fi>,
> Pertti Kellomäki <pertti.k...@tut.fi> wrote:
>
>> If you take a look at the current functional programming landscape, you
>> would be hard pressed to find many languages that do not have static
>> typing.
>
> Isn't that true of programming languages in general? For as long as
> there have been high-level languages, the vast majority have been
> statically typed. So it's hardly a hallmark of functional programming.
Naah. Dynamic typing is a lot more general than that, and goes all the
way back to assembly language. Forth. Smalltalk. All of the dozens of
command shells and scripting languages. *any* object oriented system
worth the name (i.e., accommodates inheritance and polymorphism) is
either inherently dynamically typed or squirming towards dynamic typing
through the constraints of it's surface static typing. (Especially the
OO languages that have a single root "object" type.)
Cheers,
--
Andrew
Barry Margolin
Andrew Reilly <andrew-...@areilly.bpc-users.org> wrote:
Maybe not by the number of languages, but I suspect that by the number
of programmers, most programming is done in statically-typed languages.
From the 50's to the 70's, Fortran, COBOL, PL/I, and Algol were
predominant. From the 80's on, C and C++ took over, and in the 90's
Java started to become popular.
Except in scripting, dynamically-typed languages have generally been
"niche" languages: Lisp, Forth, Smalltalk. OO didn't really gain huge
popularity until it was grafted onto a statically typed language (C
begeting C++).
Jon Harrop
> So how do you write the following under static typing?
>
> (some-function (read-from-string "arbitrary data"))
>
> Replace the literal "arbitrary data" with an expression that pulls a
> string from the operating system.
>
> Suppose that SOME-FUNCTION only takes integers.
>
> Now what?
Either read_from_string must return an integer or you must insert an
explicit type conversion or you parse the string directly to an int:
some_function (Int.Parse "arbitrary data")
> Or how about:
>
> (funcall (compile nil arbitrary-data) 42)
>
> How do you know that ARBITRARY-DATA, computed based on run-time
> inputs, will compile to a function that can accept 42 as an argument,
> and what happens if it doesn't?
There is no difference between static and dynamic typing in this context.
> Can I make a Haskell (..., etc) program out of a hundred modules, and
> then edit and recompile just one of them in total isolation, and load
> it into the running application?
AFAIK Haskell does not support dynamic linking but that has nothing to do
with static typing.
> If you can do that, where is the static typing now?
In other languages, you parameterise over the interface and dynamically load
new code behind the interface. This is already widely done.
> The whole idea that a program goes through three separate phases
> once---compiling, loading/linking and running---is obsolete. It's a
> niche technique for small embedded systems with limited resources, and
> simple software like operating system utilities. Much of the software
> you interact with everyday couldn't be developed with static typing
Almost all of the software I interact with on a daily basis is written in
statically typed languages.
> What is the Haskell equivalent of COMPILE-FILE? LOAD? I'm looking at
> section 5.7 of the Haskell 98 report:
>
> ``the precise details of separate compilation are not defined by this
> report''.
That is a deficiency in Haskell and has nothing to do with static typing.
> That's not an adequate answer, sorry. Lisp does define the precise
> details of separate compilation, the effects of loading, control of
> evaluation semantics that differ between compilation, loading and
> execution, etc.
>
> These features are vastly more useful for software development than a
> static type system.
They are not mutually exclusive.
Jon Harrop
> True, but they don't even advertise themselves as functional language,
> at least not according to wikipedia, if that's an acceptible source.
> Scheme is a multi-paradigm programming language
> http://en.wikipedia.org/wiki/Scheme_(programming_language)
Scheme "supports a number of programming paradigms"?!
Even if you count all impure functional languages as supporting both
functional and imperative "paradigms" (which I would not), what else does
Scheme support?
Scott Burson
> 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.
Interesting that you should bring up PVS, because I was going to do so
also... to make the opposite point.
Type systems in programming languages can never capture all
interesting and important invariants. An attempt to make them do so
makes type correctness undecidable -- exactly as it is in PVS. In
order to know that your PVS specification is type-correct, in general
you have to prove some theorems. And by the way, PVS is more
accurately described as a proof assistant than a prover; it finds the
proof itself only in easy cases -- in hard cases you have to guide
it. Notably, when using induction you have to provide it with the
induction hypothesis; it can't guess it. And of course, all the
really interesting invariants in a program have inductive proofs.
So while I think it's great that people are thinking about how to make
type systems more and more expressive, don't go thinking that where
we're headed is a world where all important invariants are encoded as
types that can be checked automatically by the compiler. It's not
possible, and for those not familiar with the argument, it comes down
to the halting problem.
(Two important qualifications. (1) A system that allows arbitrary
invariants to be encoded as types, but which requires the manual use
of a proof assistant to type-check the program, could nevertheless be
an interesting one; for an example see www.specware.org . I don't
know, though, whether such systems are practical for general
programming yet. (2) It's conceivable that someone could develop a
higher-order prover that could handle the vast majority of proofs that
arise in real programs with only very small amounts of human
guidance. This is an inordinately difficult problem, but if it were
solved, we could use a highly expressive type system such as that of
PVS and still, _most_ of the time, have the machine be able to type-
check our program without our help. However, there is no guarantee
that this would be possible in all cases, nor can one bound the time
it would take.)
-- Scott
Barry Margolin
Jon Harrop <use...@jdh30.plus.com> wrote:
> Kaz Kylheku wrote:
> > So how do you write the following under static typing?
> >
> > (some-function (read-from-string "arbitrary data"))
> >
> > Replace the literal "arbitrary data" with an expression that pulls a
> > string from the operating system.
> >
> > Suppose that SOME-FUNCTION only takes integers.
> >
> > Now what?
>
> Either read_from_string must return an integer or you must insert an
> explicit type conversion or you parse the string directly to an int:
>
> some_function (Int.Parse "arbitrary data")
Or read_from_string returns a union datatype.
Pascal Costanza
> Slobodan Blazeski wrote:
>> True, but they don't even advertise themselves as functional language,
>> at least not according to wikipedia, if that's an acceptible source.
>> Scheme is a multi-paradigm programming language
>> http://en.wikipedia.org/wiki/Scheme_(programming_language)
>
> Scheme "supports a number of programming paradigms"?!
>
> Even if you count all impure functional languages as supporting both
> functional and imperative "paradigms" (which I would not), what else does
> Scheme support?
From the summary of R5RS: "A wide variety of programming paradigms,
including imperative, functional, and message passing styles, find
convenient expression in Scheme."
Pertti Kellomäki
> Could you elaborate more? In what case would haskell programmer make
> more intensive use of higher order functions?
This is more of a gut feeling, not something I could provide
evidence for. It has been a while since I played with Haskell,
but Lisp and Haskell seem to be pretty much on par as far as
higher order functionality is concerned. The functionality
just seems to get more extensive use in Haskell.
> Isn't it what happens to haskell programmers? They'd be lacking good
> data structures and be implementing them with functions? Or do they
> really have applications that involve naturally more higher order
> functions?
If you are thinking about building conses using lexical closures
and the like, that is not done much in Haskell. The algebraic data
types are quite handy, and because you can do pattern matching on
constructors, algebraic data types are used quite heavily. Lists
also get used quite a bit.
--
Pertti
Pascal Bourguignon
Ok.
I forgot to mention macros. That could be the significant difference.
In lisp, a lot of higher level function use is hidden in macros.
Instead of writing: (do-with-open-file path <options>...
(lambda (stream) (read stream)))
we just write: (with-open-file (stream path <options>...)
(read stream))
I guess that without macros, higher order functions are more apparent
in Haskell.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
Pertti Kellomäki
> On Mar 11, 6:47 am, Pertti Kellomäki <pertti.kellom...@tut.fi> wrote:
>> If you take a look at the current functional programming landscape,
>> you would be hard pressed to find many languages that do not have
>> static typing.
>
> That's just because the designers feel insecure in the face of
> criticism from the mainstream.
Anyone working on functional languages is already taking quite
a bit of ridicule from the mainstream of programming languages,
so I don't really find insecurity a very plausible explanation.
> They think that static typing and
> syntax which looks like serial line noise is the way of overcoming
> popularity obstacles. (It's not working, yet they continue).
People working on statically typed functional languages seem
to be more interested in type systems and functional programming
than winning popularity contests. No surprises there.
> So how do you write the following under static typing?
>
> (some-function (read-from-string "arbitrary data"))
>
> Replace the literal "arbitrary data" with an expression that pulls a
> string from the operating system.
>
> Suppose that SOME-FUNCTION only takes integers.
>
> Now what?
In a statically typed language read-from-string would return
a value of an algebraic type. For example, one could use the
Maybe type from the standard library:
data Maybe a
= Nothing
| Just a
Then just do pattern matching on the return value and call
some-function if you get back a "Just int" value.
In a dynamically typed language you have two choices: deal
with the potential type error in some way, or just trust
read-from-string to return an integer and crash if anything
goes wrong.
Dynamic typing does not make type errors go away, it just
moves them to a different place.
> Can I make a Haskell (..., etc) program out of a hundred modules, and
> then edit and recompile just one of them in total isolation, and load
> it into the running application? If you can do that, where is the
> static typing now?
So are you claiming that this would be impossible? It is certainly
true that dynamic typing makes it technically easier, and I do not
know af any such statically typed systems that exist today. But on
the other hand, this is exactly the kind of situation where you would
want to express as much of the semantics of the interfaces in a machine
checkable form.
> Much of the software
> you interact with everyday couldn't be developed with static typing
> (or without static typing being defeated all over the place).
Such as?
> See, Haskell and its ilk is just a semantic gadget that assigns a
> computational meaning to strings; they are not full-blown languages.
> They are sublanguages that need to be embedded in a host environment
> in order to make sense.
You are losing me there. Programming languages are by definition
semantic gadgets that assign meaning to strings.
--
Pertti
Pertti Kellomäki
> I guess that without macros, higher order functions are more apparent
> in Haskell.
That is certainly true. And it also partly explains why higher order
functions are more prevalent in Scheme than in CL.
The kind of code people write in any given language is also partly
a cultural thing. Certain idiomatic ways of solving problems are
used more than other functionally equivalent ways. Often this
is determined by what finds a convenient expression in the language,
but not necessarily.
--
Pertti
Thomas F. Burdick
wrote:
> thus spoke Marco Antoniotti <marc...@gmail.com>:
>
> >>> 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.
> > This has always been one of the most baffling assertions about CL.
> > While it is true that redefinition makes "harder" to do type
> > inference, it does not prevent it. CL environment usually (and
> > traditionally) maintain a lot of information about who is calling what
> > and viceversa. Using a similar setup to track signature changes is
> > doable.
>
> Even if type inference were to propagate with function redefinition, a
> dynamic variable is enough to punch a hole in the whole scheme. Nothing
> more specific than a type of T could be inferred unless some extension
> to CL is devised.
No, not really. The set of current dynamic bindings can be passed as
an extra argument, along with the continuation, to every function. At
least that's one legit way of modeling or implementing dynamic
bindings.
Ben
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.
>
> 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.
>
So how do I verify my swaption pricing model (or equivalent) gives the
correct prices using the type system? This is 90% of the value of any
financial application. How does the type system verify that an excel
like app returns the right numbers? How does it guarentee an order
isn't place twice in a database in a stock processing program? How do
you prove a word processor app has just mapped the right key press to
the right glyph?
Ben
Pertti Kellomäki
> Interesting that you should bring up PVS, because I was going to do so
> also... to make the opposite point.
>
> Type systems in programming languages can never capture all
> interesting and important invariants. An attempt to make them do so
> makes type correctness undecidable -- exactly as it is in PVS. In
> order to know that your PVS specification is type-correct, in general
> really interesting invariants in a program have inductive proofs.
>
> So while I think it's great that people are thinking about how to make
> type systems more and more expressive, don't go thinking that where
> we're headed is a world where all important invariants are encoded as
> types that can be checked automatically by the compiler. It's not
> possible, and for those not familiar with the argument, it comes down
> to the halting problem.
I largely agree with everything you say above. However, undecidable
type checking may not be as bad as it sounds. If one writes programs
(i.e. PVS specifications) as if one were using SML, the undecidability
never crops up (because SML type checking is decidable).
The reason I brought up PVS is that *if one so desires*, it is possible
to express all kinds of formal properties of programs in a machine
checkable form using the type system. It is true that all the really
interesting invariants have inductive proofs, but some more mundane
invariants can be very useful as well. For example, proving that a
divisor is never zero is usually not very difficult, and can be mostly
handled by the PVS decision procedures.
I would also do a little bit of nit picking when it comes to
terminology. It is true that a compiler cannot *find* proofs
in the general case, but it can mechanically recheck stored proofs.
So each proof only needs to be found once, and thereafter the
compiler can take over until the source code is sufficiently changed
to invalidate the proof.
I'm not claiming that PVS logic is the next big thing in programming,
but working with it has been an eye opener in what can be expressed
using an advanced type system. I would certainly welcome a programming
language that would allow me to step outside of decidable typing if
I feel like it.
--
Pertti
Slobodan Blazeski
> I'm not claiming that PVS logic is the next big thing in programming,
> but working with it has been an eye opener in what can be expressed
> using an advanced type system. I would certainly welcome a programming
> language that would allow me to step outside of decidable typing if
> I feel like it.
Tehn try Qi http://www.lambdassociates.org/, the most powerful type
system made optional. Beside you could mix it with lisp if you want or
need some libs and you could learn it in 15 minutes.
I don't even want to speak about the great documentation, whole book
and numerous papers for free.
Why do I don't use it if it's such great thing? It' s not asdf
packaged. Beside I wan't to use qi as normal lisp library not vice
versa.
cheers
Slobodan
http://tourdelisp.blogspot.com/2008/03/farewell-haskell.html
> --
> Pertti- Hide quoted text -
Stanisław Halik
>> True, but they don't even advertise themselves as functional language,
>> at least not according to wikipedia, if that's an acceptible source.
>> Scheme is a multi-paradigm programming language
>> http://en.wikipedia.org/wiki/Scheme_(programming_language)
> Scheme "supports a number of programming paradigms"?!
> Even if you count all impure functional languages as supporting both
> functional and imperative "paradigms" (which I would not), what else does
> Scheme support?
Count OOP in with Meroon/TinyCLOS.
Jon Harrop
> I largely agree with everything you say above. However, undecidable
> type checking may not be as bad as it sounds. If one writes programs
> (i.e. PVS specifications) as if one were using SML, the undecidability
> never crops up (because SML type checking is decidable).
Only if you make no mistakes. If you make a mistake then the type checker
will fly off on some crazy inference and give you unintelligable error
messages whereas an SML has no such freedom and gives much more
comprehensible error messages as a result.
Jon Harrop
> So how do I verify my swaption pricing model (or equivalent) gives the
> correct prices using the type system?
Simon Peyton Jones published a seminal paper on the use of Haskell in the
finance industry largely for its static type checking. This is why the
finance industry makes vastly more use of statically typed functional
programming languages than dynamically typed ones.
> How does the type system verify that an excel like app returns the right
> numbers?
What exactly do you mean by "an excel like app"?
> How does it guarentee an order isn't place twice in a database in a stock
> processing program?
If the information is only available at run-time then that cannot be
statically proven. So there is no difference between static and dynamic
typing in this case.
> How do you prove a word processor app has just mapped the right key press
> to the right glyph?
Using the type:
val map : key -> glyph
will prove that the "map" function always maps keys onto glyphs. It will not
prove that the mapping is correct.
Pertti Kellomäki
> Pertti Kellomäki wrote:
>> If one writes programs
>> (i.e. PVS specifications) as if one were using SML, the undecidability
>> never crops up (because SML type checking is decidable).
>
> Only if you make no mistakes. If you make a mistake then the type checker
> will fly off on some crazy inference and give you unintelligable error
> messages whereas an SML has no such freedom and gives much more
> comprehensible error messages as a result.
If PVS encounters a construct which might be well typed but,
PVS cannot prove it, PVS will create a type correctness
condition (a theorem). This theorem then needs to be proved
by the user in the interactive prover to complete type checking.
This addresses the case where types are ok, but the user has
accidentally stepped outside of the decidable subset of types.
I agree with your general observation about the inverse
relationship between freedom and quality of error messages if
there is a genuine type error.
--
Pertti
Ben
> Ben wrote:
> > So how do I verify my swaption pricing model (or equivalent) gives the
> > correct prices using the type system?
>
> Simon Peyton Jones published a seminal paper on the use of Haskell in the
> finance industry largely for its static type checking. This is why the
> finance industry makes vastly more use of statically typed functional
> programming languages than dynamically typed ones.
>
I work in the Finance industry and I wouldn't say this is true. Yuo
still need to verify the accuracy of your models, and any tests that
do that will verify the types as a byproduct. You don't need more
tests for the dynamic languages just to test the types
> > How does the type system verify that an excel like app returns the right
> > numbers?
>
> What exactly do you mean by "an excel like app"?
>
Any numerical calculation engine. How do you verify a FFT is actually
doing what it is meant to be?
> > How does it guarentee an order isn't place twice in a database in a stock
> > processing program?
>
> If the information is only available at run-time then that cannot be
> statically proven. So there is no difference between static and dynamic
> typing in this case.
>
Exactly, and I would say most industry apps rely on information that
is only availiable at run time.
> > How do you prove a word processor app has just mapped the right key press
> > to the right glyph?
>
> Using the type:
>
> val map : key -> glyph
>
> will prove that the "map" function always maps keys onto glyphs. It will not
> prove that the mapping is correct.
>
Quite. And any unit test that tests that the mapping is correct will
check the types are correct by its very nature.
Ben
Jon Harrop
> On Mar 13, 12:09 am, Jon Harrop <use...@jdh30.plus.com> wrote:
>> Ben wrote:
>> > How does the type system verify that an excel like app returns the
>> > right numbers?
>>
>> What exactly do you mean by "an excel like app"?
>
> Any numerical calculation engine. How do you verify a FFT is actually
> doing what it is meant to be?
Static typing only proves aspects of the program correct.
>> > How does it guarentee an order isn't place twice in a database in a
>> > stock processing program?
>>
>> If the information is only available at run-time then that cannot be
>> statically proven. So there is no difference between static and dynamic
>> typing in this case.
>
> Exactly, and I would say most industry apps rely on information that
> is only availiable at run time.
That is not my experience.
>> > How do you prove a word processor app has just mapped the right key
>> > press to the right glyph?
>>
>> Using the type:
>>
>> val map : key -> glyph
>>
>> will prove that the "map" function always maps keys onto glyphs. It will
>> not prove that the mapping is correct.
>
> Quite. And any unit test that tests that the mapping is correct will
> check the types are correct by its very nature.
Exactly. Those are the tests made redundant by static typing.