Sorry for spamming the group, but I wrote an article about Haskell
from Lisp point of view. So I would like to see some feedback from
all those lispers who do Haskell in case I wrote something really
stupid asI have only a week playing with Haskell. I know that I should
wait more but I just wanted this out of my mind.
http://tourdelisp.blogspot.com/2008/03/lisper-first-look-at-haskell.html
thanks
Slobodan
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.
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
On Mar 9, 6:28 pm, Jon Harrop <······@jdh30.plus.com> wrote:
> Lispers who, almost by definition,
> don't know any modern programming languages.
Lispers know tons of modern languages. We invent a new one
every time we write another application. :)
-------------------------------
Dan Bensen
http://www.prairienet.org/~dsb/
On Mar 10, 7:40 am, danb <·········@gmail.com> wrote:
> On Mar 9, 6:28 pm, Jon Harrop <······@jdh30.plus.com> wrote:
>
> > Lispers who, almost by definition,
> > don't know any modern programming languages.
>
> Lispers know tons of modern languages. We invent a new one
> every time we write another application. :)
>
> -------------------------------
> Dan Bensenhttp://www.prairienet.org/~dsb/
Great added to my collection of lisp quotes.
danb wrote:
> On Mar 9, 6:28 pm, Jon Harrop <······@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
On Mar 10, 1:40 am, danb <·········@gmail.com> wrote:
> On Mar 9, 6:28 pm, Jon Harrop <······@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.
On Mar 10, 1:40 am, danb <·········@gmail.com> wrote:
> Lispers know tons of modern languages. We invent a new one
> every time we write another application. :)
That is slick. Were you saving that one? :)
On Mar 9, 6:28 pm, Dr. Frog <······@jdh30.plus.com> wrote:
> Lispers who, almost by definition,
> don't know any modern programming languages.
On Mar 10, 1:40 am, danb <·········@gmail.com> wrote:
> Lispers know tons of modern languages.
> We invent a new one [for every] application.
On Mar 23, 12:19 pm, Griff <·······@gmail.com> wrote:
> That is slick. Were you saving that one? :)
Troll wars are naturally inspiring :)
--Dan
------------------------------------------------
Dan Bensen
http://www.prairienet.org/~dsb/
On 2008-03-09 19:28:07 -0400, The Amphibian formerly known as Frog said:
> Statements like "It's like life in a monastery, full of fasting, preying and
> compassion under the all seeing eye of the abbot, punishing you for every
> mistake..." lend no credence to what you write. Anyone who makes serious
> use of static typing will not take you seriously and anyone who doesn't
> might be misguided by your opinion.
The irony of His Moistness complaining about a language being
misrepresented is truly priceless. You couldn't script this stuff -
really. Yet another data point showing that Usenet is funnier than
professional comics.
On Mar 10, 12:28 am, Jon Harrop <······@jdh30.plus.com> wrote:
> Slobodan Blazeski wrote:
> > Sorry for spamming the group, but I wrote an article about Haskell
> > from Lisp point of view. So I would like to see some feedback from
> > all those lispers who do Haskell in case I wrote something really
> > stupid asI have only a week playing with Haskell. I know that I should
> > wait more but I just wanted this out of my mind.
> >http://tourdelisp.blogspot.com/2008/03/lisper-first-look-at-haskell.html
>
> There are many spelling mistakes: essey, togather, Unflexible, preying,
> definately, Hakellers.
Thanks, your grammatical advice is invaluable.
>
> The vast majority of interlanguage blog posts are newbies blubbing. You have
> done a better than average job in this respect but there is still a lot of
> room for improvement:
>
> You say that notepad is the best Haskell editor available for Windows. What
> about Visual Studio?
Noninteractive. Forces me to install Visual Studio.
>
> You say "Big issue for someone used to full power of unification" but you
> don't explain why Haskell (and all MLs) do not provide unification in their
> pattern matchers.
I didn't designed Haskell nor ML, nor studied why they are designed as
they did.
So if you have idea why did Haskell designers decided to choose
pattern matching instead unification. Or why they didn't allow me to
repeat variable into a pattern, I'm all ears.You can use ML if you
prefer.
>
> You say "haskell looks like a family caravan against full blood racers" yet
> you have no relevant and don't cite any references to substantiate your
> view.
yes I did
Quote:
Haskell doesn't allows me to experiment. It doesn't allows me to
create modulus with some functions undefined or defined wrong. Bundle
this togather with loading file to redefine a module, the cruppiest
feature they took from Prolog and you'll start to value your lisp
listeners
Is above acceptable in your eyes that's up to you.
>
> Statements like "It's like life in a monastery, full of fasting, preying and
> compassion under the all seeing eye of the abbot, punishing you for every
> mistake..." lend no credence to what you write. Anyone who makes serious
> use of static typing will not take you seriously and anyone who doesn't
> might be misguided by your opinion.
Friend of mine suggested that I'm still in lisp mode so this might or
might not change later.
>
> Finally, you do not appear to have sought advice from Haskell experts but,
> instead, have posted directly to a Lisp newsgroup.
I seek criticism from Lispers who happens to know Haskell, that's why
the article is named like is named.
Quote
So this essey is from lisper point of view. I doubt that users of
other languages will find much use of it.
> You cannot hope to get
> constructive criticism about Haskell from Lispers who, almost by
> definition, don't know any modern programming languages.
Frog talk.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/products/
P� Mon, 10 Mar 2008 10:24:00 +0100, skrev Slobodan Blazeski
<·················@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
On Mar 10, 11:40 am, "John Thingstad" <·······@online.no> wrote:
> På Mon, 10 Mar 2008 10:24:00 +0100, skrev Slobodan Blazeski
> <·················@gmail.com>:
>
>
>
> >> You cannot hope to get
> >> constructive criticism about Haskell from Lispers who, almost by
> >> definition, don't know any modern programming languages.
> > Frog talk.
>
> How are your Prolog studies going?
They're on hold because of Haskell. I'm giving Haskell one more week
and that's this one. If I still don't like it I'm going back to
Prolog. I just hate to program and not have fun in my spare time.
Slobodan
Slobodan Blazeski kirjoitti:
> I'm giving Haskell one more week
> and that's this one. If I still don't like it I'm going back to
> Prolog. I just hate to program and not have fun in my spare time.
I appreciate your sentiment, but if you are only going to try out
things that you can master in a couple of weeks, you are going
to miss out on a lot of interesting stuff.
--
Pertti
On Mar 10, 1:51 pm, Pertti Kellomäki <················@tut.fi> wrote:
> Slobodan Blazeski kirjoitti:
>
> > I'm giving Haskell one more week
> > and that's this one. If I still don't like it I'm going back to
> > Prolog. I just hate to program and not have fun in my spare time.
>
> I appreciate your sentiment, but if you are only going to try out
> things that you can master in a couple of weeks, you are going
> to miss out on a lot of interesting stuff.
> --
> Pertti
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 wrote:
> On Mar 10, 12:28 am, Jon Harrop <······@jdh30.plus.com> wrote:
>> You say that notepad is the best Haskell editor available for Windows.
>> What about Visual Studio?
>
> Noninteractive.
I think it would be worth putting that in your article.
>> You say "Big issue for someone used to full power of unification" but you
>> don't explain why Haskell (and all MLs) do not provide unification in
>> their pattern matchers.
>
> I didn't designed Haskell nor ML, nor studied why they are designed as
> they did.
> So if you have idea why did Haskell designers decided to choose
> pattern matching instead unification. Or why they didn't allow me to
> repeat variable into a pattern, I'm all ears.You can use ML if you
> prefer.
Haskell and ML restrict pattern matching to linear patterns for two main
reasons:
. Predictable performance: linear patterns are matched in constant time.
. Checking: Haskell and ML patterns can be checked for various kinds of
correctness.
Unification provides a different set of trade-offs and, in particular, lacks
both of these features because unification can take an arbitrarily long
time and conveys no type information.
>> You say "haskell looks like a family caravan against full blood racers"
>> yet you have no relevant and don't cite any references to substantiate
>> your view.
>
> yes I did
> Quote:
> Haskell doesn't allows me to experiment. It doesn't allows me to
> create modulus with some functions undefined or defined wrong. Bundle
> this togather with loading file to redefine a module, the cruppiest
> feature they took from Prolog and you'll start to value your lisp
> listeners
>
> Is above acceptable in your eyes that's up to you.
You have only presented one side of the argument. The other side is:
. Haskell's static checking catches errors earlier in development, without
having to wait for the code to run.
. Haskell's static checking obviates 99% of unit tests.
This is why Haskell is so much faster to develop in that Lisp. The ability
to run broken code is insignificant in comparison.
>> Statements like "It's like life in a monastery, full of fasting, preying
>> and compassion under the all seeing eye of the abbot, punishing you for
>> every mistake..." lend no credence to what you write. Anyone who makes
>> serious use of static typing will not take you seriously and anyone who
>> doesn't might be misguided by your opinion.
>
> Friend of mine suggested that I'm still in lisp mode so this might or
> might not change later.
You sound like someone who has been dabbling in maths for a week and
concluded that mathematical proofs are just unnecessary "bondage and
discipline" and we should all just use our mathematical derivations to
build buildings and bridges without bothering to prove anything. Just plug
in a few numbers and make sure the answers look about right.
In practice, static typing with type inference has enormous benefits. You
get machine-verified documentation for free that is updated for you as you
develop. Performance improves enormously. Brevity improves enormousely.
Development time improves enormously...
>> Finally, you do not appear to have sought advice from Haskell experts
>> but, instead, have posted directly to a Lisp newsgroup.
>
> I seek criticism from Lispers who happens to know Haskell, that's why
> the article is named like is named.
> Quote
> So this essey is from lisper point of view. I doubt that users of
> other languages will find much use of it.
You would get more useful criticism from the Haskell community. Perhaps the
best people to ask would be former Lispers who now use Haskell.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
On 10 Mrz., 16:04, Jon Harrop <······@jdh30.plus.com> wrote:
> . Haskell's static checking catches errors earlier in development, without
> having to wait for the code to run.
... catches a very restricted set of errors earlier in development,
without
having to wait for the code to run.
> . Haskell's static checking obviates 99% of unit tests.
Is that a proof by usenet posting? Even if you would reduce your
statistics to a more realistic value of perhaps 5-10%: It is often
easier to write the tests instead of being forced to program in a
static straitjacket.
> This is why Haskell is so much faster to develop in that Lisp. The ability
> to run broken code is insignificant in comparison.
Bzzt! Wrong. Running broken code in a debugging environment can be
very significant.
> You sound like someone who has been dabbling in maths for a week and
> concluded that mathematical proofs are just unnecessary "bondage and
> discipline" and we should all just use our mathematical derivations to
> build buildings and bridges without bothering to prove anything. Just plug
> in a few numbers and make sure the answers look about right.
Sounds to me like the perfect description of J. "Toady" Frogarrop, the
guy who tries to mislead newbies by feigning helpfulness and spreading
FUD about what he sees as the most dangerous business competition to
his very questionable and highly opinionated publications.
ciao,
Jochen
--
Jochen Schmidt
CRISPYLOGICS
Julienstr. 1, 90419 Nuremberg
Fon +49 (0)911 517 999 82
Fax +49 (0)911 517 999 83
···········@crispylogics.com
http://www.crispylogics.com
Jochen Schmidt wrote:
> On 10 Mrz., 16:04, Jon Harrop <······@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.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
On Mar 10, 6:25 pm, Jon Harrop <······@jdh30.plus.com> wrote:
> Jochen Schmidt wrote:
> > On 10 Mrz., 16:04, Jon Harrop <······@jdh30.plus.com> wrote:
> >> . Haskell's static checking catches errors earlier in development,
> >> without having to wait for the code to run.
>
> > ... catches a very restricted set of errors earlier in development,
> > without having to wait for the code to run.
>
> Static type checking in these languages is widely reputed to catch "most
> errors". If that were not true, unit testing would be as prevalent in
> static languages like OCaml, Haskell and F# as it is in dynamic languages
> like Lisp.
Lack of testing is certainly not something you should be proud of.
>
> >> . Haskell's static checking obviates 99% of unit tests.
>
> > Is that a proof by usenet posting?
>
> That is the result of my survey of millions of lines of industrial code.
> Programs written in dynamic languages like Lisp and Python devote up to 50%
> of their codebase to unit testing. In contrast, OCaml and F# programs only
> have 1-2% of their code devoted to tests. If you include unit testing code,
> the static languages are also much more concise.
>
> However, from my personal experience I would say that programmers using
> dynamic languages like Lisp tend to be of below average ability and
> productivity and choose Lisp because they don't know anything more modern.
> This effect will bias the results because the quality of the code will be
> different. Indeed, industrial code written in dynamic languages
> (particularly Python) is typically of extremely poor quality by comparison.
If you were such an expert as you trying to present yourself you
wouldn't have a minute reading newsgroups.
You would be busy doing your job. Here's a job add you might got
hired go get http://www.intellifactory.com/Jobs.aspx
Slobodan Blazeski wrote:
> Lack of testing is certainly not something you should be proud of.
Only if it undermines reliability, which it does not if you are leveraging
static checking correctly.
> If you were such an expert as you trying to present yourself you
> wouldn't have a minute reading newsgroups. You would be busy doing your
> job.
On the contrary, experts find it easy to earn money and can spend more time
doing other things, like posting here. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
On 10 Mrz., 18:59, Jon Harrop <······@jdh30.plus.com> wrote:
> On the contrary, experts find it easy to earn money and can spend more time
> doing other things, like posting here. :-)
Well - that at least means you're no expert - since you're actually
here to try to earn money (by misleading people to buy questionable
publications).
On Mar 11, 4:59 am, Jon Harrop <······@jdh30.plus.com> wrote:
> Slobodan Blazeski wrote:
> > Lack of testing is certainly not something you should be proud of.
>
> Only if it undermines reliability, which it does not if you are leveraging
> static checking correctly.
>
> > If you were such an expert as you trying to present yourself you
> > wouldn't have a minute reading newsgroups. You would be busy doing your
> > job.
>
> On the contrary, experts find it easy to earn money and can spend more time
> doing other things, like posting here. :-)
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/products/?u
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.
·············@gmail.com wrote:
> I don't understand how simply knowing that you have a correct type
> significantly reduces unit testing effort.
With an expressive type system (e.g. Haskell/ML), types convey a lot of
information and checking the types buys you a lot of correctness as a
consequence.
> A C/C++ compiler can
> determine if I have correct types, but it can't determine if my
> program has correct behaviour.
Sure. C/C++ aren't even safe. Java is a step in the right direction and
addresses many of the more serious problems with C++ but it still suffers
terribly from null reference exceptions because it has only a very
rudimentary type system, e.g. cannot express non-null references. A more
expressive type system can massively increase code density (to match most
dynamic languages) and eliminate null reference exceptions as well as many
other sources of error.
> Unit tests are primarily about correct
> _behaviour_ of isolated "units" of code e.g. behaviour under error
> conditions, required pre/post conditions, does it give expected
> results etc.
In dynamic languages, unit tests also pick up type errors, e.g. one kind of
value has been passed to a function that was not expecting that kind of
value, or a function has been passed the wrong number of arguments. These
unit tests can be made almost entirely unnecessary with static typing.
> I'm reminded of when I was a student and I was first learning to
> program using Pascal. I was ecstatic when I got something to compile
> - but to claim that the static checking done by the compiler had any
> bearing on correct program behaviour is a stretch in my opinion.
Yes. Pascal has a comparatively simple type system.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
From: Giorgos Keramidas
Subject: Re: Lisper's first look at Haskell
Date:
Message-ID: <87k5k59p1r.fsf@kobe.laptop>
On Tue, 11 Mar 2008 04:32:07 +0000, Jon Harrop <······@jdh30.plus.com> wrote:
> ·············@gmail.com wrote:
>> 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.
While this is true, type-checking of the arguments is only *part* of
what units tests are about. A small part, as it is. The need for
functional integrity & behavioral correctness is not covered at all by
static typing.
Giorgos Keramidas wrote:
> While this is true, type-checking of the arguments is only *part* of
> what units tests are about.
Yes.
> A small part, as it is.
No: a very large part that obviates ~99% of the unit tests seen in
dynamically typed languages.
> The need for functional integrity & behavioral correctness is not covered
> at all by static typing.
That is not correct, of course. The "list with >0 elements" type that I gave
is one simple example but static typing is widely used to enforce
behavioural correctness in many more sophisticated ways. You can even use
it to ensure that tree manipulations retain balancing properties. You also
have linear types that let you prove that values cannot escape scope. Many
static type systems help with thread safety, e.g. knowing that functions
are pure in Haskell.
Look at the finger tree implementation of DataSequence in Haskell, for
example.
None of this is particularly new. You can learn about it from any good book
about any modern statically typed language. The basic techniques are
already very widely used in industry.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
On 14 Mar, 20:00, Jon Harrop <······@jdh30.plus.com> wrote:
> Giorgos Keramidas wrote:
> > While this is true, type-checking of the arguments is only *part* of
> > what units tests are about.
>
> Yes.
No.
--
DDr Jon Harrop, Flying Consultancy Ultd.
http://www.fonsultansy.con/product/?
On 14 Mar, 18:46, Giorgos Keramidas <········@ceid.upatras.gr> wrote:
> While this is true, type-checking of the arguments is only *part* of
> what units tests are about. A small part, as it is. The need for
> functional integrity & behavioral correctness is not covered at all by
> static typing.
Please elaborate on that.
Since I never use dynamic languages, maybe I'm simply closed to
anything I could learn from them.
--
DDr Jon Harrop, Flying Consultancy Ultd.
http://www.fonsultansy.con/product/?
On 2008-03-11, in comp.lang.lisp, ·············@gmail.com wrote:
> 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 (················@xortec.fi)
"Wovon man nicht sprechen kann, daruber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
On 10 Mrz., 18:25, Jon Harrop <······@jdh30.plus.com> wrote:
> Jochen Schmidt wrote:
> > On 10 Mrz., 16:04, Jon Harrop <······@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
CRISPYLOGICS
Julienstr. 1, 90419 Nuremberg
Fon +49 (0)911 517 999 82
Fax +49 (0)911 517 999 83
···········@crispylogics.com
http://www.crispylogics.com
From: Edi Weitz
Subject: Re: Lisper's first look at Haskell
Date:
Message-ID: <uzlt66z2e.fsf@agharta.de>
On Mon, 10 Mar 2008 14:24:24 -0700 (PDT), Jochen Schmidt <···@crispylogics.com> wrote:
> How can anyone with a healthy mind do any business with someone who
> tries to earn money by misleading people. You actively fool people
> to get their money; not even stopping at conscious lying. Why do you
> post to Java Groups that there is nobody using it, why do you try to
> market languages as "modern" or "not modern" here in Common Lisp?
> Why do play the helpful guy on comp.lang.fortran before recommend
> buying your books about... not fortran! The way of unethical
> marketing your questionable stuff is so distasteful that I just can
> hope that more people realize the hidden agenda.
BTW, if you ever wondered how our beloved little toad looks like -
here he is:
http://www.dotnetrocks.com/default.aspx?showNum=266
Charming, isn't he?
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Jochen Schmidt wrote:
> And what do you mean by "industrial code"?
To understand that, you just need to compare your products page with ours:
http://www.crispylogics.com/en/products
http://www.ffconsultancy.com/products/?cl
Incidentally, you should replace "do you want an existing software to get
customized?" with "do you want existing software customized?".
One thing of interest:
http://www.crispylogics.com/en/downloads/opensource/
You are the first non-Haskell users of darcs that I've heard of...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
On 11 Mrz., 05:17, Jon Harrop <······@jdh30.plus.com> wrote:
> 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
···········@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
Jochen Schmidt wrote:
> 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.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
On Mar 11, 1:03 pm, Jon Harrop <······@jdh30.plus.com> wrote:
>
> >> 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
On Mar 11, 1:03 pm, Jon Harrop <······@jdh30.plus.com> wrote:
> Jochen Schmidt wrote:
> > 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
On Mon, 10 Mar 2008 17:25:20 +0000, Jon Harrop wrote:
> Jochen Schmidt wrote:
>> On 10 Mrz., 16:04, Jon Harrop <······@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
tim wrote:
> On Mon, 10 Mar 2008 17:25:20 +0000, Jon Harrop wrote:
>> Jochen Schmidt wrote:
>>> On 10 Mrz., 16:04, Jon Harrop <······@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.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
On Tue, 11 Mar 2008 03:53:35 +0000, Jon Harrop wrote:
> tim wrote:
>> On Mon, 10 Mar 2008 17:25:20 +0000, Jon Harrop wrote:
>>> Jochen Schmidt wrote:
>>>> On 10 Mrz., 16:04, Jon Harrop <······@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
thus spoke tim <····@internet.com>:
>> You're assuming there are type declarations.
> In SBCL it does type inference and complains of inconsistencies. This can
> be a good or bad thing. ... but this is just based on what it picks up
> along the way.
This isn't of much use anyway, as type inferences can't be reliably done
for non-inline user-defined functions due to the possibility of
redefinition. sb-impl::%fun-type can be used to check them anyway.
--
Nawet świnka wejdzie na drzewo kiedy ją chwalą.
On Mar 11, 7:15 am, Stanis³aw Halik <··············@tehran.lain.pl>
wrote:
> thus spoke tim <····@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
thus spoke Marco Antoniotti <·······@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.
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.
--
Nawet świnka wejdzie na drzewo kiedy ją chwalą.
On Mar 11, 8:13 pm, Stanis³aw Halik <··············@tehran.lain.pl>
wrote:
> thus spoke Marco Antoniotti <·······@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.
tim wrote:
> On Tue, 11 Mar 2008 03:53:35 +0000, Jon Harrop wrote:
>> tim wrote:
>>> 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.
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.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
Jon Harrop wrote:
> 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.
Do you have a link to this article or the name and issue of the magazine
where you read it?
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
P� Sun, 16 Mar 2008 10:08:45 +0100, skrev Frank Buss <··@frank-buss.de>:
> Jon Harrop wrote:
>
>> 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.
>
> Do you have a link to this article or the name and issue of the magazine
> where you read it?
>
I think it depends more on development style. Many lispers use agile
programming techniques that encourages you to write huge volumes of tests.
This is one implementation strategy, but hardly the only one. (For example
we also have verifiable programming as with ACL2.) Further you would need
the same volume of tests in Java for example. And agile programming is a
successful idea that has produced more reliable, usable programs fast.
(Mileage may vary, of cource..)
--------------
John Thingstad
Frank Buss wrote:
> Jon Harrop wrote:
>> 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.
>
> Do you have a link to this article or the name and issue of the magazine
> where you read it?
I think its buried in my bookmarks. I'll post it when I've dug it out...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
Jon Harrop wrote:
> Jochen Schmidt wrote:
> > On 10 Mrz., 16:04, Jon Harrop <······@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
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/products/?u
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.
> 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.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
On Mar 13, 12:09 am, Jon Harrop <······@jdh30.plus.com> wrote:
> 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
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/products/?u
Ben wrote:
> On Mar 13, 12:09�am, Jon Harrop <······@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.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
On Mar 13, 2:29 pm, "j.oke" <········@gmail.com> wrote:
> On 13 Mar, 13:46, Jon Harrop wrote:
>
> > [...]
> > That is not my experience.
>
> Would you all please be so kind to excuse Sir Dr Jon D Harrop, as he
> doesn't have any Lisp experience whatsoever...
He doesn't have ANY experience, beside spamming of course.
j.oke wrote:
> On 13 Mar, 13:46, Jon Harrop wrote:
>>> Exactly, and I would say most industry apps rely on information that
>>> is only availiable at run time.
>>
>> That is not my experience.
>
> Would you all please be so kind to excuse Sir Dr Jon D Harrop, as he
> doesn't have any Lisp experience whatsoever...
Not that Lisp is relevant to industrial code...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
j.oke wrote:
> (I omitted the words you don't have any experience in).
> And what does the above mean?
It means you've conceded defeat by resorting to ad-hominem claims rather
than stating a logical argument. Anyone reading it would assume that you
did this because there are no logical arguments to support your beliefs.
Ben at least tried to construct a logical argument but the best he could
come up with was "static typing cannot make tea" which is true but
irrelevant.
Wow, look at this growth:
http://people.debian.org/~igloo/popcon-graphs/index.php?packages=clisp%2Cocaml-nox&show_installed=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
Wow, look at this trend:
http://www.google.com/trends?q=f%23%2Ccommon+lisp&ctab=0&geo=all&date=all&sort=0
What can it mean?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
Jon Harrop <······@jdh30.plus.com> wrote on Thu, 13 Mar 2008:
> Wow, look at this trend:
> http://www.google.com/trends?q=f%23%2Ccommon+lisp&ctab=0&geo=all&date=all&sort=0
> What can it mean?
You've posted this irrelevant link many times in the past. You've been
corrected each time, and yet persist in ignoring the corrections. The
answer, as always, is obvious. Just take a look at the example articles on
the right:
Not Giving a ··@% About You
Box Office Prophets - Jul 19 2006
Flow Presents, F#*?!
Transworld Snowboarding.com - Mar 1 2007
··@K the Burnside Couplet guest column
BlueOregon - Apr 10 2007
So, your link provides some evidence that people enjoy f#*%-ing somewhat
more than programming in Common Lisp. Although apparently only in the last
few years.
I don't know. I'm a big fan of Common Lisp. But I still prefer ··@*-ing
to programming.
YMMV, of course. Perhaps you have the opposite preference.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
After all, what is your hosts' purpose in having a party? Surely not for you
to enjoy yourself; if that were their sole purpose, they'd have simply sent
champagne and women over to your place by taxi. -- P. J. O'Rourke
Jon Harrop wrote:
> Wow, look at this growth:
>
> http://people.debian.org/~igloo/popcon-graphs/index.php?packages=clisp%2Cocaml-nox&show_installed=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
http://people.debian.org/~igloo/popcon-graphs/index.php?packages=maxima%2Cocaml-nox&show_installed=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
Before you cry "that's not Common Lisp", I think the to_lisp() command
disagrees.
Brian wrote:
>
http://people.debian.org/~igloo/popcon-graphs/index.php?packages=maxima%2Cocaml-nox&show_installed=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
>
> Before you cry "that's not Common Lisp", I think the to_lisp() command
> disagrees.
Compare with the OCaml run-time:
http://people.debian.org/~igloo/popcon-graphs/index.php?packages=maxima%2Cocaml-base-nox&show_installed=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
Or with software written in OCaml:
http://people.debian.org/~igloo/popcon-graphs/index.php?packages=maxima%2Clibfftw3-3&show_installed=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
Ouch!
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
On 2008-03-13 16:53:44 -0400, the tumbling toad said:
> It means you've conceded defeat by resorting to ad-hominem claims rather
> than stating a logical argument.
Stating that someone has no experience in a particular area is not an
ad hominem attack, but a legitimate warning that his statements about
that domain have most likely been pulled straight out of his ass.
Raffael Cavallaro wrote:
> On 2008-03-13 16:53:44 -0400, the tumbling toad said:
>> It means you've conceded defeat by resorting to ad-hominem claims rather
>> than stating a logical argument.
>
> Stating that someone has no experience in a particular area is not an
> ad hominem attack...
It is if the area is irrelevant, as it was in this case.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
Jon Harrop escribi�:
> j.oke wrote:
>> (I omitted the words you don't have any experience in).
>> And what does the above mean?
>
> It means you've conceded defeat by resorting to ad-hominem claims rather
> than stating a logical argument. Anyone reading it would assume that you
> did this because there are no logical arguments to support your beliefs.
>
> Ben at least tried to construct a logical argument but the best he could
> come up with was "static typing cannot make tea" which is true but
> irrelevant.
>
> Wow, look at this growth:
>
> http://people.debian.org/~igloo/popcon-graphs/index.php?packages=clisp%2Cocaml-nox&show_installed=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
>
> Wow, look at this trend:
>
> http://www.google.com/trends?q=f%23%2Ccommon+lisp&ctab=0&geo=all&date=all&sort=0
>
> What can it mean?
>
What did we do? Why this curse?
Leandro
Leandro Rios <··················@gmail.com> writes:
> What did we do? Why this curse?
Did? Past tense? It's still happening.
People keep answering the guy. Maybe they take pleasure out of it...
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig escribi�:
> Leandro Rios <··················@gmail.com> writes:
>
>> What did we do? Why this curse?
>
> Did? Past tense? It's still happening.
>
> People keep answering the guy. Maybe they take pleasure out of it...
>
People seem to have to release pressure in some way; this guy is *very*
irritating. But I agree with you: The better way to deal with him is to
ignore him.
Leandro
> Duane Rettig escribi�:
>
>> Leandro Rios <··················@gmail.com> writes:
>>
>>> What did we do? Why this curse?
>>
>>
>> Did? Past tense? It's still happening.
>>
>> People keep answering the guy. Maybe they take pleasure out of it...
>>
Yes. And we have prior art:
http://en.wikipedia.org/wiki/Weeble
hth, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Sun, 16 Mar 2008 21:21:34 -0400, Ken Tilton
<···········@optonline.net> wrote:
>
>> Duane Rettig escribi�:
>>
>>> Leandro Rios <··················@gmail.com> writes:
>>>
>>>> What did we do? Why this curse?
>>>
>>>
>>> Did? Past tense? It's still happening.
>>>
>>> People keep answering the guy. Maybe they take pleasure out of it...
>>>
>
>Yes. And we have prior art:
>
> http://en.wikipedia.org/wiki/Weeble
>
>hth, kenny
Shmoos came long before Weebles. I had a schmoo punching bag when I
was young - it never fell down. Weebles just copied the idea.
George
--
for email reply remove "/" from address
On Mar 16, 4:25 pm, Leandro Rios <··················@gmail.com> wrote:
> Duane Rettig escribió:
>
> > Leandro Rios <··················@gmail.com> writes:
>
> >> What did we do? Why this curse?
>
> > Did? Past tense? It's still happening.
>
> > People keep answering the guy. Maybe they take pleasure out of it...
>
> People seem to have to release pressure in some way; this guy is *very*
> irritating. But I agree with you: The better way to deal with him is to
> ignore him.
>
> Leandro
Well our favourite toad has deteriorated from jerk (*) -> Compost (**)
and finally -> Palooka(***)
Show's over folks, go home, there's nothing more to see here. Only a
beaten frog trying waving with it's broken plastic sword.
slobodan
http://tourdelisp.blogspot.com/
(*) http://redwing.hutman.net/~mreed/warriorshtm/jerk.htm
Jerk is sarcastic, mean, unforgiving and never misses an opportunity
to make a cutting remark. Jerk's repulsive personality quickly
alienates other Warriors, and after some initial skirmishing he is
usually ostracized. Still, Jerk is very happy to participate in
electronic forums because in cyberspace he is free to be
himself...without the risk of getting a real-time punch in the mouth
(**) http://redwing.hutman.net/~mreed/warriorshtm/compost.htm
A weak Warrior with few weapons at his disposal Compost flings
expletives and vulgarities to keep his opponent at bay. This tactical
maneuver can occasionally rout especially sensitive combatants, such
as Innocence Abused, but it is generally ineffective against more
powerful Warriors.
(***) http://redwing.hutman.net/~mreed/warriorshtm/palooka.htm
Palooka will battle anyone, anytime, anywhere - he seems to love it,
even though he always takes a beating. After a terrific pounding at
the hands of, for example, Kung-Fu Master, he'll just struggle to his
feet and wobble back into the ring. His astonishing ability to absorb
punishment leads one to suspect that during his long Warrior career
Palooka has taken a few too many punches. Often, as an act of mercy,
Nanny will step in to stop the fight
Leandro Rios wrote:
> Jon Harrop escribi�:
>> j.oke wrote:
>>> (I omitted the words you don't have any experience in).
>>> And what does the above mean?
>>
>> It means you've conceded defeat by resorting to ad-hominem claims rather
>> than stating a logical argument. Anyone reading it would assume that you
>> did this because there are no logical arguments to support your beliefs.
>>
>> Ben at least tried to construct a logical argument but the best he could
>> come up with was "static typing cannot make tea" which is true but
>> irrelevant.
>>
>> Wow, look at this growth:
>>
>> http://people.debian.org/~igloo/popcon-graphs/index.php?packages=clisp%2Cocaml-nox&show_installed=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
>>
>>
>> Wow, look at this trend:
>>
>> http://www.google.com/trends?q=f%23%2Ccommon+lisp&ctab=0&geo=all&date=all&sort=0
>>
>>
>> What can it mean?
>>
>
> What did we do? Why this curse?
heh-heh, good one! (Assuming you are referring to most F# "news results"
being those that use F#!%& form of curse words.)
That said, I do see some energy out there for these OCaml-like
languages, good for them!
kenny
Ken wrote:
> heh-heh, good one! (Assuming you are referring to most F# "news results"
> being those that use F#!%& form of curse words.)
Honestly, Kenny. If anyone knows how common swear words were before 2004 it
should be you. ;-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
Ken escribi�:
> Leandro Rios wrote:
>>>
>>
>> What did we do? Why this curse?
>
> heh-heh, good one! (Assuming you are referring to most F# "news results"
> being those that use F#!%& form of curse words.)
>
No, Kenny, that second (funny) meaning was yours. I was just crying out
of desperation :)
Leandro
On Mar 14, 1:27 am, "j.oke" <········@gmail.com> wrote:
> On 13 Mar, 21:53, Jon Harrop <······@jdh30.plus.com> wrote:
>
> > What can it mean?
>
> The answer, my friend, is somewhere in here:
>
> http://www.gigamonkeys.com/book/
>
> Yes, it's written for people like you: plain naked Lisp noobs!
>
> Happy reading!
>
> -JO
Nope, but here http://www.googlefight.com/index.php?lang=en_GB&word1=ocaml&word2=sharepoint
Hint :
OCaml is an implementation of a language called caml, but there is
another one with the same name used customize Microsoft sharepoint
portal.
But our toad doesn't look outside it's pond very often.The world
dislikes little green creatures especially if they're full of poison.
Slobodan
Slobodan Blazeski wrote:
> Hint : OCaml is an implementation of a language called caml...
No, it isn't. OCaml is a language and an implementation that are the
successor to INRIA's caml-light implementation of the CAML language. OCaml
is a cousin of F# because F# also inherits from CAML.
Microsoft's Collaborative Application Markup Language (CAML) has nothing to
do with OCaml and will not affect hits for the search term "OCaml" because
it has a different name.
Moreover, "ocaml" is a more popular search term than "caml" anyway:
http://www.google.com/trends?q=ocaml%2Ccaml
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
On Mar 14, 7:48 pm, Jon Harrop <······@jdh30.plus.com> wrote:
> Slobodan Blazeski wrote:
> > Hint : OCaml is an implementation of a language called caml...
>
> No, it isn't. OCaml is a language and an implementation that are the
> successor to INRIA's caml-light implementation of the CAML language.
Frog talk. Now you're trying to be more catholic than the pope,
because according to Inria http://caml.inria.fr/
Caml is a general-purpose programming language....
The Objective Caml system is the main implementation of the Caml
language.
Which part of above doesn't get in your amphibian brain?
> Moreover, "ocaml" is a more popular search term than "caml" anyway:
It's ok froggy, you can cry in the toilet. We understand.
slobodan
http://tourdelisp.blogspot.com/
Slobodan Blazeski wrote:
> Caml is a general-purpose programming language....
> The Objective Caml system is the main implementation of the Caml
> language.
CAML was superceded by OCaml 12 years ago.
You might as well claim that OCaml is derived from SML which is also
overloaded to mean the "Service Modeling Language" but that also has
nothing to do with the metrics I cited.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
On Mar 15, 11:28 pm, Jon Harrop <······@jdh30.plus.com> wrote:
> Slobodan Blazeski wrote:
> > Caml is a general-purpose programming language....
> > The Objective Caml system is the main implementation of the Caml
> > language.
>
> CAML was superceded by OCaml 12 years ago.
Screw inria then, what the hell they know about (o)caml anyway. No
wait they forgoth to update their page for 12 years. Froggy, froggy
when you gonaa learn. If you want to prove something you need to put
facts on the table. Facts, not something coming from your ass. And the
main authority for what is or isn't Ocaml is Inria, not you.
Oh and dodn't try to dodge with misrepresenting informations.
> CAML was superceded by OCaml 12 years ago.
OCaml is the successor to Caml Light.
http://en.wikipedia.org/wiki/OCaml
Try reading wikipedia a little, if they didn't took your access for
spamming it.
slobodan
http://tourdelisp.blogspot.com/
Slobodan Blazeski wrote:
> And the main authority for what is or isn't Ocaml is Inria, not you.
If you want to know what a word is used to mean you must survey how it is
used. You cannot infer the meaning of a modern word from its inventor.
In practice, "OCaml" dominates both content and search terms and the
word "OCaml" has no direct relationship with Microsoft's SharePoint that
would bias the data I presented.
>> CAML was superceded by OCaml 12 years ago.
>
> OCaml is the successor to Caml Light.
> http://en.wikipedia.org/wiki/OCaml
Wikipedia is not even self-consistent in this respect:
"Caml and Caml Light, languages from which OCaml evolved"
> Try reading wikipedia a little, if they didn't took your access for
> spamming it.
I chose to stop contributing the Wikipedia because it rots back to an
equilibrium of very low quality information very quickly.
Feel free to update that page if you believe OCaml is somehow related to
Microsoft's SharePoint. Nobody will mind.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
On Mar 10, 4:04 pm, Jon Harrop <······@jdh30.plus.com> wrote:
> Slobodan Blazeski wrote:
> > On Mar 10, 12:28 am, Jon Harrop <······@jdh30.plus.com> wrote:
> >> You say that notepad is the best Haskell editor available for Windows.
> >> What about Visual Studio?
>
> > Noninteractive.
>
> I think it would be worth putting that in your article.
I already did. I revised a little my article.
>
> >> You say "Big issue for someone used to full power of unification" but you
> >> don't explain why Haskell (and all MLs) do not provide unification in
> >> their pattern matchers.
>
> > I didn't designed Haskell nor ML, nor studied why they are designed as
> > they did.
> > So if you have idea why did Haskell designers decided to choose
> > pattern matching instead unification. Or why they didn't allow me to
> > repeat variable into a pattern, I'm all ears.You can use ML if you
> > prefer.
>
> Haskell and ML restrict pattern matching to linear patterns for two main
> reasons:
>
> . Predictable performance: linear patterns are matched in constant time.
Bad design. If I need performance I will code in c.
>
> . Checking: Haskell and ML patterns can be checked for various kinds of
> correctness.
Like what?
>
> Unification provides a different set of trade-offs and, in particular, lacks
> both of these features because unification can take an arbitrarily long
> time and conveys no type information.
Rubbish. I worked with Suciu algo and I could keep all the type
information I need, if I want to in the unification table.
Actually I might specify even more specific unification rules between
types.
Also there is no problem to unify in more than 2 sides in paralel.
like (unify (?x (1 2) ?z)
(2 ?y ?g)
(?g ?y 2))
The unification tables could be precompiled if you lack speed. But
unless you're doing some heavy number crunching or
game development performance is nothing to worry about.Will Ocaml be
faster. Probably but I don't care about that I want to easy on my
coding.
Oh yes occurs check is not implemented so that might brake algo for
now.
>
> >> You say "haskell looks like a family caravan against full blood racers"
> >> yet you have no relevant and don't cite any references to substantiate
> >> your view.
>
> > yes I did
> > Quote:
> > Haskell doesn't allows me to experiment. It doesn't allows me to
> > create modulus with some functions undefined or defined wrong. Bundle
> > this togather with loading file to redefine a module, the cruppiest
> > feature they took from Prolog and you'll start to value your lisp
> > listeners
>
> > Is above acceptable in your eyes that's up to you.
>
> You have only presented one side of the argument. The other side is:
>
> . Haskell's static checking catches errors earlier in development, without
> having to wait for the code to run.
No it doesn't. It catches type errors. The promise of error free code
when you finally got god damn thing to run is coming from revisiting
my code several times while trying to please the type system. I've
noticed that everytime I wrestled with type system I made changes in
my function that usually have nothing to do with the type system.
>
> . Haskell's static checking obviates 99% of unit tests.
BS I defined at least a dozen of functions this morning that were Ok
re static checking but would fail on certain inputs. Like one elements
list, negative Int, all uppercase string etc etc.
Nothing could replace writing unit tests.
>
> This is why Haskell is so much faster to develop in that Lisp.
Find better premises above two are easily found to be flowed
> The ability
> to run broken code is insignificant in comparison.
Frog talk.
>
> >> Statements like "It's like life in a monastery, full of fasting, preying
> >> and compassion under the all seeing eye of the abbot, punishing you for
> >> every mistake..." lend no credence to what you write. Anyone who makes
> >> serious use of static typing will not take you seriously and anyone who
> >> doesn't might be misguided by your opinion.
>
> > Friend of mine suggested that I'm still in lisp mode so this might or
> > might not change later.
>
> You sound like someone who has been dabbling in maths for a week and
> concluded that mathematical proofs are just unnecessary "bondage and
> discipline" and we should all just use our mathematical derivations to
> build buildings and bridges without bothering to prove anything. Just plug
> in a few numbers and make sure the answers look about right.
That's why I'm not interested in building unforgiving systems, I'll
leave them to you.
On the other side when my facebook freezes and fails to deliver
message I got little upset but nobody get kills.
When Mafia physics fails I get nervous but I reload the game. Nobody
gets hurt.
>
> In practice, static typing with type inference has enormous benefits. You
> get machine-verified documentation for free that is updated for you as you
> develop. Performance improves enormously. Brevity improves enormousely.
> Development time improves enormously...
Even more frog talk.
>
> >> Finally, you do not appear to have sought advice from Haskell experts
> >> but, instead, have posted directly to a Lisp newsgroup.
>
> > I seek criticism from Lispers who happens to know Haskell, that's why
> > the article is named like is named.
> > Quote
> > So this essey is from lisper point of view. I doubt that users of
> > other languages will find much use of it.
>
> You would get more useful criticism from the Haskell community. Perhaps the
> best people to ask would be former Lispers who now use Haskell.
I have some credit to spam c.l.l a bit, but no money on my Haskell
account.
On the other side you're in deep red.
Slobodan Blazeski wrote:
> On Mar 10, 4:04�pm, Jon Harrop <······@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.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
On Mar 10, 6:43 pm, Jon Harrop <······@jdh30.plus.com> wrote:
> Slobodan Blazeski wrote:
> > On Mar 10, 4:04 pm, Jon Harrop <······@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.
Assuming that you know what the industry is. And it's nothing like
pond.
>
> >> You would get more useful criticism from the Haskell community. Perhaps
> >> the best people to ask would be former Lispers who now use Haskell.
>
> > I have some credit to spam c.l.l a bit, but no money on my Haskell
> > account.
>
> I'm sure the Haskell community would warmly welcome a newcomer looking for
> helpful advice.
Nope until Haskell proves worth learning I'm not interested becoming a
part of it's community
> > Lack of testing is certainly not something you should be proud of.
>
> Only if it undermines reliability, which it does not if you are leveraging
> static checking correctly.
Frog talk
>
> > If you were such an expert as you trying to present yourself you
> > wouldn't have a minute reading newsgroups. You would be busy doing your
> > job.
>
> On the contrary, experts find it easy to earn money and can spend more time
> doing other things, like posting here. :-)
Yeah and begging under the bridge
On Sun, 09 Mar 2008 23:28:07 +0000, Jon Harrop wrote:
>
> <blabla>
>
> from Lispers who, almost by definition, don't know any modern
> programming languages.
many do, few care
--
Lars Rune Nøstdal
http://nostdal.org/
On Mar 10, 7:51 am, Lars Rune Nøstdal <···········@gmail.com> wrote:
> On Sun, 09 Mar 2008 23:28:07 +0000, Jon Harrop wrote:
>
> > <blabla>
>
> > from Lispers who, almost by definition, don't know any modern
> > programming languages.
>
> many do, few care
Another one for my collection of lisp quotes.
>
> --
> Lars Rune Nøstdal http://nostdal.org/
Jon Harrop <······@jdh30.plus.com> writes:
> Finally, you do not appear to have sought advice from Haskell experts but,
> instead, have posted directly to a Lisp newsgroup. You cannot hope to get
> constructive criticism about Haskell from Lispers who, almost by
> definition, don't know any modern programming languages.
Haskell does not qualify as a modern programming language. Neither does ML,
OCaml, or SML.
Chris Barts kirjoitti:
> Haskell does not qualify as a modern programming language. Neither does ML,
> OCaml, or SML.
Can you name some modern programming languages? Not that I
have anything against old fashioned languages, like CL ;-).
I'm just curious what qualifies a language as "modern".
--
Pertti
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...
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Mar 10, 2:52 pm, Ken Tilton <···········@optonline.net> wrote:
> Pertti Kellomäki wrote:
> > Chris Barts kirjoitti:
>
> >> Haskell does not qualify as a modern programming language. Neither
> >> does ML,
> >> OCaml, or SML.
>
> > Can you name some modern programming languages? Not that I
> > have anything against old fashioned languages, like CL ;-).
> > I'm just curious what qualifies a language as "modern".
>
> Dynamic, reflective, GCed, typed data, untyped variables, absolutely
> must treat code as any other kind of data, functions as first-class
> objects, less than fifty <scratch scratch> sixty years old...
Wake up your Kennyness. Multicore processors are here and they're
going to stay.
Dual cores is already low end, Quads cores are coming close to
standard offer, and servers are 8 cores.
When nehalem hits the road this numbers will probably rize higher
probably to 16 cores. And there will be users hungry to utilizy all
those cores,so their app will run faster, so who will gonna developers
turn? Functional languages, where they'll get concurrency for
free.
>
> kenny
>
> --http://smuglispweeny.blogspot.com/http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
Slobodan Blazeski wrote:
> On Mar 10, 2:52 pm, Ken Tilton <···········@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/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Mar 10, 6:01 pm, Ken Tilton <···········@optonline.net> wrote:
> Slobodan Blazeski wrote:
> > On Mar 10, 2:52 pm, Ken Tilton <···········@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 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
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Mar 10, 7:20 pm, Ken Tilton <···········@optonline.net> wrote:
> Slobodan Blazeski wrote:
> > Just get out with it immediately , good software is good software.
>
> Looks like I have no choice, I sure don't want to work on it now.
>
> > BTW have you looked at weblocks?
>
> I am looking at OpenLaszlo, it has constraints (aka Cells). Can compile
> to JS or DHTML. Or I might just do Flex, get something Interwebby on the
> resume while I am at it.
>
> kenny
What's stopping you to at least look at weblocks? All your greatest
fans are there: me, Sohail, Leslie. Beside how many days you will need
to cellify it before you got bored. 4 days , 3 days, nah
I'm sure you could do it in less than 2 days. Beside you will got your
sweet revenge for the foolish lispers who ignored cells for years or
were too stupid to learn it. Now they will have to use it like it or
not to build do their pathetic Web 2.0 apps.
Slobodan
>
> --http://smuglispweeny.blogspot.com/http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
Slobodan Blazeski wrote:
> On Mar 10, 7:20 pm, Ken Tilton <···········@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/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Mon, 10 Mar 2008 16:36:42 -0400, Ken Tilton wrote:
> OpenLaszlo still gets an edge for working w/out JS, tho. But I am still
> learning. The crux of the matter is MathML, and mainstream browser
> support for that bites. But it looks like Flash supports it. That could
> be The Decider.
Weblocks works with and without JS. But OpenLazlo looks pretty cool,
thanks for pointing it out.
--
Sohail Somani
http://uint32t.blogspot.com
From: Edi Weitz
Subject: Re: Lisper's first look at Haskell
Date:
Message-ID: <u8x0q8gcj.fsf@agharta.de>
On Mon, 10 Mar 2008 16:36:42 -0400, Ken Tilton <···········@optonline.net> wrote:
> but you'll need an endorsement from Edi, I use what he uses.
LispWorks?
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Mon, 10 Mar 2008 12:42:19 -0700, Slobodan Blazeski wrote:
> What's stopping you to at least look at weblocks? All your greatest fans
> are there: me, Sohail, Leslie. Beside how many days you will need to
> cellify it before you got bored. 4 days , 3 days, nah I'm sure you could
> do it in less than 2 days. Beside you will got your sweet revenge for
> the foolish lispers who ignored cells for years or were too stupid to
> learn it. Now they will have to use it like it or not to build do their
> pathetic Web 2.0 apps.
Actually, I'm not currently using it but I think it is neat and novel.
Also, I think Slava has actually implemented his own CLOS dataflow hack!
--
Sohail Somani
http://uint32t.blogspot.com
From: Joost Diepenmaat
Subject: Re: Lisper's first look at Haskell
Date:
Message-ID: <87tzje2wim.fsf@zeekat.nl>
Slobodan Blazeski <·················@gmail.com> writes:
> What's stopping you to at least look at weblocks? All your greatest
> fans are there: me, Sohail, Leslie.
He's probably thinking of expanding his fan base ;-)
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
On Mar 10, 8:45 pm, Joost Diepenmaat <·····@zeekat.nl> wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > What's stopping you to at least look at weblocks? All your greatest
> > fans are there: me, Sohail, Leslie.
>
> He's probably thinking of expanding his fan base ;-)
What for? The current ones didn't do any good.
Joke aside I hope that he will be happy with flex or OpenLaszlo. I was
wrong with pushing weblocks on him. Beside weblocks is continuations
beside, something that Kenny despises, and it's own declarative UI
building DSL. And if Kenny integrates it's cells in it it'll probably
grow into a framework with craziest flow in the world, if it ain't
already. As they say, people want technologies that are 15 minutes
before time, anything more and they'll shun them.
cheers
Slobodan
>
> --
> Joost Diepenmaat | blog:http://joost.zeekat.nl/| work:http://zeekat.nl/
"Ken Tilton" <···········@optonline.net> wrote in message
······························@cv.net...
>
>
> Slobodan Blazeski wrote:
>> Just get out with it immediately , good software is good software.
>
><snip>
>....Or I might just do Flex, get something Interwebby on the
> resume while I am at it.
>
> kenny
>
> --
> http://smuglispweeny.blogspot.com/
> http://www.theoryyalgebra.com/
Tho who's gonna replace Flex's actionscript with CL or, dare I say it...,
Ruby?...
Graham
On Mon, 10 Mar 2008 20:13:14 +0000, Slark wrote:
> Tho who's gonna replace Flex's actionscript with CL or, dare I say
> it..., Ruby?...
I think someone needs to write a lisp->as macro. Why would you say Ruby
anyway?
--
Sohail Somani
http://uint32t.blogspot.com
"Sohail Somani" <······@taggedtype.net> wrote in message
··························@edtnps82...
> On Mon, 10 Mar 2008 20:13:14 +0000, Slark wrote:
>
>> Tho who's gonna replace Flex's actionscript with CL or, dare I say
>> it..., Ruby?...
>
> I think someone needs to write a lisp->as macro. Why would you say Ruby
> anyway?
>
> --
> Sohail Somani
> http://uint32t.blogspot.com
Or an as repl for cl...
Graham
Slobodan Blazeski wrote:
> 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.
It's not true that functional languages get concurrency for free. It may
be easier to parallelize execution of effect-free expressions, but that
doesn't buy you a lot.
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/
Hi Pascal,
> It's not true that functional languages get concurrency for free. It may
> be easier to parallelize execution of effect-free expressions, but that
> doesn't buy you a lot.
I suggest you read Allen & Kennedy, Optimizing Compilers for Modern
Architectures, and you will see how much referential transparency in
fact buys you when trying to parallelize programs.
The Sisal <http://en.wikipedia.org/wiki/SISAL> language is an
interesting real world example targeting high performance computing
on parallel architectures.
In the multimedia domain there are many algorithms that inherently
contain lots of parallelism. However, if you then code them in your
run of the mill imperative language, it can be very tedious to recover
the parallelism. There is plenty of action nowadays in ways of avoiding
that imperative bottleneck, for example various stream oriented
languages.
--
Pertti
Pertti Kellom�ki wrote:
> Hi Pascal,
>
>> It's not true that functional languages get concurrency for free. It
>> may be easier to parallelize execution of effect-free expressions, but
>> that doesn't buy you a lot.
>
> I suggest you read Allen & Kennedy, Optimizing Compilers for Modern
> Architectures, and you will see how much referential transparency in
> fact buys you when trying to parallelize programs.
>
> The Sisal <http://en.wikipedia.org/wiki/SISAL> language is an
> interesting real world example targeting high performance computing
> on parallel architectures.
>
> In the multimedia domain there are many algorithms that inherently
> contain lots of parallelism. However, if you then code them in your
> run of the mill imperative language, it can be very tedious to recover
> the parallelism. There is plenty of action nowadays in ways of avoiding
> that imperative bottleneck, for example various stream oriented
> languages.
I know.
The important point is that you have to arrange your programs in certain
ways to be able to really take advantage of parallel architectures. You
don't get it for free just because you program in a functional style.
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/
Pascal Costanza kirjoitti:
> The important point is that you have to arrange your programs in certain
> ways to be able to really take advantage of parallel architectures. You
> don't get it for free just because you program in a functional style.
The thing is, though, that the optimum arrangement of programs is
different for different parallel architecture (vector, SIMD, SMP, ...),
and you really do not want to refactor your weather simulation model
every time the hardware changes. You just want to express the
computation cleanly, and let the compiler transform the program
into the contorted form that executes efficiently on the hardware
of the day. Referential transparency substantially simplifies
the analysis required for that.
But this is straying quite far from Lisp so I'll stop here.
--
Pertti
Pertti Kellom�ki wrote:
> Pascal Costanza kirjoitti:
>> The important point is that you have to arrange your programs in
>> certain ways to be able to really take advantage of parallel
>> architectures. You don't get it for free just because you program in a
>> functional style.
>
> The thing is, though, that the optimum arrangement of programs is
> different for different parallel architecture (vector, SIMD, SMP, ...),
> and you really do not want to refactor your weather simulation model
> every time the hardware changes. You just want to express the
> computation cleanly, and let the compiler transform the program
> into the contorted form that executes efficiently on the hardware
> of the day. Referential transparency substantially simplifies
> the analysis required for that.
Sure.
> But this is straying quite far from Lisp so I'll stop here.
No, no, this is very related. StarLisp, Connection Machine Lisp and
Paralation Lisp were all steps in the right direction, which provide
abstract of talking about parallel computation without getting too much
into the details of concrete architectures. Fortress seems to be heavily
influenced by these approaches (not surprising, because Guy Steele was
involved in all of them to different extents). Fortress actually seems
to be a combination of the Paralation Model and the Series library
described in CLtL2.
They nice thing about these models is that they don't remove side
effects completely from the underlying language. That seems to me to be
an important ingredient to keep programming convenient.
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/
Pascal Costanza wrote:
> Fortress seems to be heavily
> influenced by these approaches (not surprising, because Guy Steele was
> involved in all of them to different extents). Fortress actually seems
> to be a combination of the Paralation Model and the Series library
> described in CLtL2.
I watched the video presentation that was posted here a while ago,
and it looked pretty intriguing. It will be interesting to see if
they can pull it off efficiently enough.
> They nice thing about these models is that they don't remove side
> effects completely from the underlying language. That seems to me to be
> an important ingredient to keep programming convenient.
One nice language I've come across is Clean, which has a concept
of uniqueness types <http://en.wikipedia.org/wiki/Uniqueness_type>.
The type system guarantees that a value whose type has the
uniqueness property can only be used once. This means that one
can express e.g. array assignment in a functional manner, constructing
a completely new array that differs from the original by one element.
But since the compiler knows that the original array cannot be
referenced any more, it can just do regular assignment behind the
scenes.
I don't know how this affects analysis, though, because presumably
any analysis that the compiler does would need to be based on the
actual imperative implementation, not the functional illusion
presented to the programmer.
--
Pertti
Pertti Kellom�ki wrote:
> Hi Pascal,
>
>> It's not true that functional languages get concurrency for free. It
>> may be easier to parallelize execution of effect-free expressions, but
>> that doesn't buy you a lot.
>
> I suggest you read Allen & Kennedy, Optimizing Compilers for Modern
> Architectures, and you will see how much referential transparency in
> fact buys you when trying to parallelize programs.
Thanks for the link, this looks very interesting!
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/
SB>
http://tourdelisp.blogspot.com/2008/03/lisper-first-look-at-haskell.html
>Hogs a lot of brain resources. It's syntax is complex, and together with
static typing it forces me to spend more resources on dealing with language
than with dealing with the problem.
IMHO underlying semanitcs of lazy and recursive structures hogs a lot of
brain resources, syntax and types are only on surface.
my theory is that one needs a special kind of brain organization to be
comfortable with Haskell -- one needs to _think_ in logical expression,
probably this corresponds to audio thinking type. this is also a type of
thinking of hardcore mathematicians -- i mean those who prove theoremes,
rather than solving applied tasks.
but most people think in a visual way, so to understand Haskell they need to
convert these logical expressions into some visual structure -- and it's
pretty complex task, hence "Haskell hogs a lot of brain resources".
as for syntax, probably it's close to logical expressions in those wonderful
people minds, so they do not have problems deciphering it, and then
operating on these logical expressions as on first-class objects.
but again, this syntax is totally alient to "normal" people.
this does not mean that people should not learn Haskell -- it might be an
interesting challenge, brain is pretty flexible, so it can adapt to these
constructs.
but i seriously doubt that Haskell can become optimal language of choice for
people who do not find it's natural from beginning.
Slobodan Blazeski kirjoitti:
> So I would like to see some feedback from
> all those lispers who do Haskell in case I wrote something really
> stupid asI have only a week playing with Haskell.
I would not go as far as labeling anything you wrote
stupid, but clearly you have not yet encountered your
muso when it comes to functional programming. Trying
to bring Lisp habits to Haskell is just not going to
work out. I am no expert in functional programming, but
I have dabbled in SML, Haskell, as well as Common Lisp
and Scheme.
You complain how you need to put a lot of effort into
dealing with the static typing. This is as it should be,
since in functional programming (of the ML, Haskell etc.
school), half of the action is in the types! Types in a
well designed functional program reflect the structure of
the problem, and nobody promised that analysis would be
easy.
As for the development tools, from a language point of
view it is irrelevant whether a graphical IDE exists or
not. Or would you say that the original Lisp was a crappy
language because there was no IDE?
If you have not read "What the hell are monads?", I encourage
you to do it. It is available in many places, here's the first
Google hit I got:
<http://web.cecs.pdx.edu/~antoy/Courses/TPFLP/lectures/MONADS/Noel/research/monads.html>
Monads can be difficult to wrap one's head around, but once
you see the light, they are a really powerful construct.
What one gets is referential transparency (i.e. no nasty mutable
state) even when dealing with the outside world. If you look at
some other functional languages, you will see that the impedance
mismatch between a pure functional computational world and the
mutating real world has always been a problem. So it is not
as if the Haskell designers were unaware of the problem until
they stumbled on it, and then cooked up something in a haste.
Rather, it is the invention of monads that really enables a
language such as Haskell to allow referential transparency,
laziness, and mutability to exist in harmony.
In my opinion it is the statically typed functional languages that
lispers should keep an eye on. If anything is going to drive Lisp
out of business, it is bound to come from that direction.
--
Pertti
On Mar 10, 1:43 pm, Pertti Kellomäki <················@tut.fi> wrote:
> Slobodan Blazeski kirjoitti:
>
> > So I would like to see some feedback from
> > all those lispers who do Haskell in case I wrote something really
> > stupid asI have only a week playing with Haskell.
>
> I would not go as far as labeling anything you wrote
> stupid, but clearly you have not yet encountered your
> muso when it comes to functional programming. Trying
> to bring Lisp habits to Haskell is just not going to
> work out. I am no expert in functional programming, but
> I have dabbled in SML, Haskell, as well as Common Lisp
> and Scheme.
>
> You complain how you need to put a lot of effort into
> dealing with the static typing. This is as it should be,
> since in functional programming (of the ML, Haskell etc.
> school), half of the action is in the types! Types in a
> well designed functional program reflect the structure of
> the problem,
What about Erlang?
>and nobody promised that analysis would be
> easy.
I don't like to think that much. I prefer action. That's in my nature.
It's very rare to done something right the first time. Implementation
punching me in my nose every single time I make mistake is not my
friend, It's an adversary.
>
> As for the development tools, from a language point of
> view it is irrelevant whether a graphical IDE exists or
> not. Or would you say that the original Lisp was a crappy
> language because there was no IDE?
No language is living in void. In the real world it's made of :
1. Core language
2. Libraries
3. Programming tools
4. Community
5. Accumulated knowledge: books, tutorials , articles, code samples,
thesis etc
>
> If you have not read "What the hell are monads?", I encourage
> you to do it. It is available in many places, here's the first
> Google hit I got:
> <http://web.cecs.pdx.edu/~antoy/Courses/TPFLP/lectures/MONADS/Noel/res...>
>
> Monads can be difficult to wrap one's head around, but once
> you see the light, they are a really powerful construct.
> What one gets is referential transparency (i.e. no nasty mutable
> state) even when dealing with the outside world. If you look at
> some other functional languages, you will see that the impedance
> mismatch between a pure functional computational world and the
> mutating real world has always been a problem. So it is not
> as if the Haskell designers were unaware of the problem until
> they stumbled on it, and then cooked up something in a haste.
> Rather, it is the invention of monads that really enables a
> language such as Haskell to allow referential transparency,
> laziness, and mutability to exist in harmony.
I'm not ready to comment on the monads, I'll leave that for later.
Anyway thanks for the link.
>
> In my opinion it is the statically typed functional languages that
> lispers should keep an eye on. If anything is going to drive Lisp
> out of business, it is bound to come from that direction.
If you said functional we might got into some agreement about next
popular thing. Though I doubt that anybody could drive lisp out of
business. But what the hell does that has to with static typing?
Nobody is doing that now better than Erlang, and Erlang is dynamically
typed.
> --
> Pertti
While you're here could you please try to explain me what's type-
directed semantics?
thanks
Slobodan
Slobodan Blazeski kirjoitti:
> On Mar 10, 1:43 pm, Pertti Kellom�ki <················@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
On Mar 10, 4:23 pm, Pertti Kellomäki <················@tut.fi> wrote:
> Slobodan Blazeski kirjoitti:
>
> > On Mar 10, 1:43 pm, Pertti Kellomäki <················@tut.fi> wrote:
> >> in functional programming (of the ML, Haskell etc.
> >> school), half of the action is in the types! Types in a
> >> well designed functional program reflect the structure of
> >> the problem,
> > What about Erlang?
>
> Another great language, but not in the ML, Haskell etc. school
> of functional languages (see above). Erlang is also different
> from Lisp and Haskell, because it is really a domain specific,
> or maybe domain oriented language. And in the domain where Erlang
> shines, complexity is in the interactions, not in the data.
Having a strongest colelction of libraries in certain area doesn't
make you a domain specific language.
Erlang could be used as general purpose langauge. You could build even
OpenGL driven game engine with it if you want.
>
> If one could come up with the equivalent of a strong type system
> for interactions, that would benefit Erlang much more than a
> strong type system for data. [I know about process algebras,
> but they are not quite there yet.]
Why should they? It works great without it.
>
> > I don't like to think that much. I prefer action. That's in my nature.
> > It's very rare to done something right the first time. Implementation
> > punching me in my nose every single time I make mistake is not my
> > friend, It's an adversary.
>
> On the other hand, an implementation that lets you make mistakes
> that blow on your face later on is a rather sloppy friend.
It's usually easier to fix something than starting from scratch.
Static typing gets in my way of starting to produce anything.
If I didn't fix my mess later, than I don't worth much anyway.
>
> >> As for the development tools, from a language point of
> >> view it is irrelevant whether a graphical IDE exists or
> >> not. Or would you say that the original Lisp was a crappy
> >> language because there was no IDE?
> > No language is living in void. In the real world it's made of :
> > 1. Core language
> > 2. Libraries
> > 3. Programming tools
> > 4. Community
> > 5. Accumulated knowledge: books, tutorials , articles, code samples,
> > thesis etc
>
> True, but one should be careful to distinguish between those.
> By 2-5 in your list, the original Lisp would have been a poor
> language, even though it was quite brilliant, especially for its
> time. Likewise, one could argue that by 2-5, Java is a really good
> language, even though reasonable people may disagree.
Agreed.
>
> The design of the core language is in my opinion more important than
> you make it appear, because it has rather profound effects on what
> can be built on it.
B utthe final word would be on the full product. If you don't make
good 2-5 in your niche , people won't use it.
> Just compare C libraries and C++ libraries.
> Or Lisp libraries and Java libraries.
>
> >> In my opinion it is the statically typed functional languages that
> >> lispers should keep an eye on. If anything is going to drive Lisp
> >> out of business, it is bound to come from that direction.
>
> > If you said functional we might got into some agreement about next
> > popular thing. Though I doubt that anybody could drive lisp out of
> > business. But what the hell does that has to with static typing?
> > Nobody is doing that now better than Erlang, and Erlang is dynamically
> > typed.
>
> Erlang is IMO irrelevant to this discussion. <snipped>
Erlang is FUNCTIONAL general purpose dynamically typed programming
language . And the only thing I'm worried that could hurt lisp is
concurrency, because we're living in the age of multicore processors.
So unless your static typed languages could do FAR better than
dynamically typed Erlang in this area, I really don't why the hell
should I care about static typing.
>
> My point is that if you look at how static typing has progressed,
> type systems in more recent statically typed functional languages
> are lightyears from the original "please reserve four bytes of memory
> for this variable" variety. There is some information that can be
> made explicit using a good type system that is left implicit in
> a latently typed language.
So what? I don't give a damn about none of those.
>
> My limited experience with Haskell has been that I only need to
> explicitly write out types when it is a good idea to write them
> for documentation purposes anyway. Type inference takes care of
> the rest.
And I think you should gain more experience with it before giving
another newb advices, that goes for me too :)
>
> > While you're here could you please try to explain me what's type-
> > directed semantics?
>
> You just uncovered my ignorance there.
You've just missed the golden arrow. Next time lad.
> --
> Pertti
Slobodan Blazeski kirjoitti:
> Having a strongest colelction of libraries in certain area doesn't
> make you a domain specific language.
No, but an execution model based on light weight processes
communicating by best effort message passing does give quite
strong hints as to where the language might be useful. The
libraries are just an added bonus.
> Erlang could be used as general purpose langauge. You could build even
> OpenGL driven game engine with it if you want.
I'm sure it would be possible, but not making a very good use
of the language. Erlang was never intended to be a general purpose
language, and it would be somewhat mediocre at that as far as
functional programming languages are concerned. You don't have to
believe me, just ask Ulf Wiger who is a regular at comp.lang.functional
and is one of the designers of Erlang. I am pretty sure he would agree.
>> If one could come up with the equivalent of a strong type system
>> for interactions, that would benefit Erlang much more than a
>> strong type system for data. [I know about process algebras,
>> but they are not quite there yet.]
> Why should they? It works great without it.
I'm not saying that they should, I'm saying that a type system
for behavioral properties would be *more useful* than a type
system for data for Erlang. For example, it would be more useful to
have a type system to express and enforce that a given set of processes
implement an atomic transaction, than to have a type system that
could express and enforce that a given list only contains integers.
> Static typing gets in my way of starting to produce anything.
It should not be a big surprise that one particular way of
thinking does not suit everyone. But then again it could just
be that you haven't quite gone native yet. Even when coming from
a functionalish language like Lisp, the purely functional way of
thinking does require some getting used to.
>>> No language is living in void. In the real world it's made of :
>>> 1. Core language
>>> 2. Libraries
>>> 3. Programming tools
>>> 4. Community
>>> 5. Accumulated knowledge: books, tutorials , articles, code samples,
>>> thesis etc
[...]
> B utthe final word would be on the full product. If you don't make
> good 2-5 in your niche , people won't use it.
I am not claiming otherwise. I just don't think it has much to do
how good or bad the *language* is. A good enough core language like
Python that is strong on the rest has a good chance of being used.
But it is entirely possible to have a brilliant core language that
just does not accumulate the rest of the critical mass. Would not
be the first time that technical merits do not win in the marketplace.
>> Erlang is IMO irrelevant to this discussion. <snipped>
> Erlang is FUNCTIONAL general purpose dynamically typed programming
> language . And the only thing I'm worried that could hurt lisp is
> concurrency, because we're living in the age of multicore processors.
> So unless your static typed languages could do FAR better than
> dynamically typed Erlang in this area, I really don't why the hell
> should I care about static typing.
They are not *my* statically typed languages. The only language
I could rightly call mine was a dynamically scoped bastard cousin
of Lisp that I implemented before I knew better.
The reason I said that Erlang is irrelevant to this discussion
is that it is targeted to a problem domain where data is simple,
and strong typing would not give much added value. Therefore the
fact that Erlang is dynamically typed does not prove anything one
way or another.
>> There is some information that can be
>> made explicit using a good type system that is left implicit in
>> a latently typed language.
> So what? I don't give a damn about none of those.
Using a good type system it might for example be possible to
express the invariant properties of a red-black tree. Then by declaring
a function be of type red_black_tree -> red_black_tree, one would
then be guaranteed _by the type system_ that the function respects
those invariants. I'm not up to speed with dependent types, so I
don't know if they are expressive enough yet to do what I described,
but that is the direction type systems are headed to. I know for fact
that you could do that by programming in the logic of the PVS theorem
prover and compiling it to Common Lisp.
>> My limited experience with Haskell has been that I only need to
>> explicitly write out types when it is a good idea to write them
>> for documentation purposes anyway. Type inference takes care of
>> the rest.
> And I think you should gain more experience with it before giving
> another newb advices, that goes for me too :)
I never said I was clueless. I've had a fair bit of experience
on Scheme and CL, and on the typed side of the fence I have spent
some time with SML, Clean and Haskell. So my opinions do have
a little bit of empirical backing.
--
Pertti
On Mar 10, 11:42 pm, Pertti Kellomäki <················@tut.fi> wrote:
> 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.
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.
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?
From: Pertti Kellomäki
Subject: Re: Does purely functional way requires static typing?
Date:
Message-ID: <fr6258$qvi$1@news.cc.tut.fi>
Slobodan Blazeski kirjoitti:
> On Mar 10, 11:42 pm, Pertti Kellom�ki <················@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
On Mar 11, 6:47 am, Pertti Kellomäki <················@tut.fi> wrote:
> Slobodan Blazeski kirjoitti:
>
> > On Mar 10, 11:42 pm, Pertti Kellomäki <················@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.
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.
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 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.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
In article <···············@corp.supernews.com>,
Jon Harrop <······@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.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: Pertti Kellomäki
Subject: Re: Does purely functional way requires static typing?
Date:
Message-ID: <fr84lf$u1v$1@news.cc.tut.fi>
Kaz Kylheku kirjoitti:
> On Mar 11, 6:47 am, Pertti Kellom�ki <················@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
On Mar 11, 2:47 pm, Pertti Kellomäki <················@tut.fi>
<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
In article <············@news.cc.tut.fi>,
Pertti Kellom�ki <················@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, ······@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
On Tue, 11 Mar 2008 14:55:41 -0400, Barry Margolin wrote:
> In article <············@news.cc.tut.fi>,
> Pertti Kellomäki <················@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
In article <···············@mid.individual.net>,
Andrew Reilly <···············@areilly.bpc-users.org> wrote:
> On Tue, 11 Mar 2008 14:55:41 -0400, Barry Margolin wrote:
>
> > In article <············@news.cc.tut.fi>,
> > Pertti Kellomäki <················@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,
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++).
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Pertti Kellom�ki <················@tut.fi> writes:
> Slobodan Blazeski kirjoitti:
>> On Mar 10, 11:42 pm, Pertti Kellom�ki <················@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__
From: Pertti Kellomäki
Subject: Re: Does purely functional way requires static typing?
Date:
Message-ID: <fr82l8$sua$1@news.cc.tut.fi>
Pascal J. Bourguignon kirjoitti:
> 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
Pertti Kellom�ki <················@tut.fi> writes:
> Pascal J. Bourguignon kirjoitti:
>> 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.
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
From: Pertti Kellomäki
Subject: Re: Does purely functional way requires static typing?
Date:
Message-ID: <fr8522$u58$1@news.cc.tut.fi>
Pascal Bourguignon kirjoitti:
> 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
Pertti Kellom�ki wrote:
> Slobodan Blazeski kirjoitti:
>> On Mar 10, 11:42 pm, Pertti Kellom�ki <················@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.
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/
On Mar 11, 8:32 pm, Pascal Costanza <····@p-cos.net> wrote:
> Pertti Kellomäki wrote:
> > Slobodan Blazeski kirjoitti:
> >> On Mar 10, 11:42 pm, Pertti Kellomäki <················@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.
>
> Scheme?
Multiparadigm. Remember that set! thingy.
slobodan
http://tourdelisp.blogspot.com/
Slobodan Blazeski wrote:
> On Mar 11, 8:32 pm, Pascal Costanza <····@p-cos.net> wrote:
>> Pertti Kellom�ki wrote:
>>> Slobodan Blazeski kirjoitti:
>>>> On Mar 10, 11:42 pm, Pertti Kellom�ki <················@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.
>> Scheme?
>
> Multiparadigm. Remember that set! thingy.
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.
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/
On Mar 11, 9:18 pm, Pascal Costanza <····@p-cos.net> wrote:
> Slobodan Blazeski wrote:
> > On Mar 11, 8:32 pm, Pascal Costanza <····@p-cos.net> wrote:
> >> Pertti Kellomäki wrote:
> >>> Slobodan Blazeski kirjoitti:
> >>>> On Mar 10, 11:42 pm, Pertti Kellomäki <················@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.
> >> Scheme?
>
> > Multiparadigm. Remember that set! thingy.
>
> The functional programming landscape doesn't consist only of pure
> functional languages.
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)
>It's true that higher-order functions are not used
> a lot in Common Lisp,
Yes I never ever found a use of functions as values in my own code,
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 -
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?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
Jon Harrop wrote:
> 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."
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/
From: Stanisław Halik
Subject: Re: Does purely functional way requires static typing?
Date:
Message-ID: <fr8t19$mfa$2@news2.task.gda.pl>
thus spoke Jon Harrop <······@jdh30.plus.com>:
>> 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.
--
Nawet świnka wejdzie na drzewo kiedy ją chwalą.
Slobodan Blazeski wrote:
> 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.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
On Mar 10, 3:42 pm, Pertti Kellomäki <················@tut.fi> wrote:
> 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
Scott Burson wrote:
> 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 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.
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
On Mar 12, 2:53 pm, Pertti Kellomäki <················@tut.fi> wrote:
> 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 -
>
> - Show quoted text -
Pertti Kellom�ki wrote:
> 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.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
Jon Harrop wrote:
> 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
Slobodan Blazeski wrote:
> Sorry for spamming the group, but I wrote an article about Haskell
> from Lisp point of view. So I would like to see some feedback from
> all those lispers who do Haskell in case I wrote something really
> stupid asI have only a week playing with Haskell. I know that I should
> wait more but I just wanted this out of my mind.
> http://tourdelisp.blogspot.com/2008/03/lisper-first-look-at-haskell.html
>
I don't qualify as a lisper, knowing only a little CL and scheme but,
yes, you should have spent longer looking at haskell. In fact it
strikes me as ridiculous that you make such a litany of dogmatic
remarks about it after dabbling with it in a random way for such a
short time. Many of your remarks, from the wild generalisations to the
misinformed details, are badly mistaken and could be put right by
persevering for a while. Unless...this is a circle jerk for your
c.l.l. pals! OMG, I just realised I wasted my time typing this
message! Rats.
> thanks
> Slobodan
On Mar 11, 12:21 am, jim burton <··········@gmail.com> wrote:
> Slobodan Blazeski wrote:
> > Sorry for spamming the group, but I wrote an article about Haskell
> > from Lisp point of view. So I would like to see some feedback from
> > all those lispers who do Haskell in case I wrote something really
> > stupid asI have only a week playing with Haskell. I know that I should
> > wait more but I just wanted this out of my mind.
> >http://tourdelisp.blogspot.com/2008/03/lisper-first-look-at-haskell.html
>
> I don't qualify as a lisper, knowing only a little CL and scheme but,
> yes, you should have spent longer looking at haskell.
That's what is called first look.
> 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.
>http://tourdelisp.blogspot.com/2008/03/lisper-first-look-at-haskell.html
>
> thanks
> Slobodan
I'm a lisper, and i spent some time with haskell. Much longer though
than you.
I love haskell and its concise and very elegant syntax. I also have no
problems with IO monads.
But as I dabbled further, I stumbled into monad transformers.
You can read my comments about them here:
http://reddit.com/info/691v1/comments/c037it9
That was a wall i hit my head on.
I hope I will eventually find time and desire to overcome this
obstacle, but my enthusiasm about haskell is severely damaged.
On Mar 11, 8:38 am, Vagif Verdi <···········@gmail.com> wrote:
> >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.
Concise yes, elegant no. Too many good damn rules. But beauty is in
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.
On 9 Mar, 23:01, Slobodan Blazeski <·················@gmail.com>
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
>
> thanks
> Slobodan
Many thanks, really interesting!
(Maybe I'll finally switch to Common Lisp some day...)
--
DDr Jon Harrop, Flying Consultancy Ultd.
http://www.fonsultansy.con/product/?
thus spoke ··········@googlemail.com:
> On 9 Mar, 23:01, Slobodan Blazeski <·················@gmail.com>
> 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
>> thanks
>> Slobodan
> Many thanks, really interesting!
> (Maybe I'll finally switch to Common Lisp some day...)
Please stop at once, you sorry excuse for an imposter.
--
Nawet świnka wejdzie na drzewo kiedy ją chwalą.
On 15 Mar, 14:49, Stanis³aw Halik <··············@tehran.lain.pl>
wrote:
> Please stop at once, you sorry excuse for an imposter.
Be civil. Don't say things you wouldn't say in a face to face
conversation.
Please see my profile. I'm seriously considering to switch to Common
Lisp some day.
Seriously.
--
DDr Jon Harrop, Flying Consultancy Ultd.
http://www.fonsultansy.con/product/?
On Mar 15, 9:38 pm, ··········@googlemail.com wrote:
> On 15 Mar, 14:49, Stanis³aw Halik <··············@tehran.lain.pl>
> wrote:
>
> > Please stop at once, you sorry excuse for an imposter.
>
> Be civil. Don't say things you wouldn't say in a face to face
> conversation.
>
> Please see my profile. I'm seriously considering to switch to Common
> Lisp some day.
>
> Seriously.
>
> --
> DDr Jon Harrop, Flying Consultancy Ultd.http://www.fonsultansy.con/product/?
You didn't put any of your accomplishments, like:
I was kicked out from wikipedia for spamming it.
I was one of the technical reviewers for the book "Inside the spam
cartel".
I've become a resident spammer in c.l.l where nice people tolerate me
more than folks from all the other groups combined, oh just when I
think of c++ fiasco my ears heart.
I didn't wrote nor seen any program in the industry. Actually the
longest thing I ever wrote is an raytracer.
Now I'm preparing my autobiography "Clueless" though the title could
be changed for "Clueless toad" because of copyright infringements. The
book could be preordered at Amazon and paid with cash, flies or bugs.
On Mar 15, 1:38 pm, ··········@googlemail.com wrote:
>I'm seriously considering to switch to Common
>Lisp some day.
>
>Seriously.
No kiddin!
Care to elaborate why would you consider such a stupid thing ?
On 16 Mar, 22:04, Vagif Verdi <···········@gmail.com> wrote:
> On Mar 15, 1:38 pm, Jon Harrop wrote:
>
> >I'm seriously considering to switch to Common
> >Lisp some day.
>
> >Seriously.
>
> No kiddin!
>
> Care to elaborate why would you consider such a stupid thing ?
So you're implying that I've gone schizophrenic? The answer is no
(many people have more than one email account. And this time I even
took care to provide my nice smile, so everybody is able to verify
that I'm no monster).
But I'm in no hurry. Maybe it will take me a couple years. Anyway, the
first months I'll painstakingly study all of the Common Lisp symbols;
there are so many of them: 978(!).
Wish me luck!
--
DDr Jon Harrop, Flying Consultancy Ultd.
http://www.fonsultansy.con/product/?