From: Dmitry V. Gorbatovsky
Subject: 2 cents to Lisp comparisons
Date:
Message-ID: <elggv3$sfr$1@aioe.org>
LEARNING COMMON LISP IS A VERY EXPENSIVE TASK.
So, some one has to have real motivation and
personal resources to go through this rewarding,
but time and work consuming process.
Obviously the learning complexity of language
is EXPONENTIALLY grows with number of
"available degrees of freedom".
By "degree of freedom" here I mean programming
methodology and respective techniques.
As far as I understand.
Common Lisp has at least two additional
"degrees of freedom" comparing to most of
mainstream and semi-mainstream programming
languages. One may count CLOS-MOP,
macro + closures, declarative/functional programming
style or all that together.
As a reward from learning such a big language,
one has a real power to express by programming computer.
From this perspective, comparison of Common Lisp
with majority of programming languages
does not make much sense. Like comparison
betwin British English and AECMA Simplified English.
Regard, Dmitry
(message (Hello 'Dmitry)
(you :wrote :on '(Sun, 10 Dec 2006 10:36:52 +0200))
(
DVG> LEARNING COMMON LISP IS A VERY EXPENSIVE TASK.
do you know the term "learning curve"?
when speaking about learning, we'd better estimate steepness of learning
curve rather than total expenses.
Common Lisp have relatively gentle learning curve.
for example, to do basic stuff in C++ you have to write something like
#include <iostream>
int main() {
std::cout << (2 + 2);
return 0;
}
while in Common Lisp it's just (+ 2 2) in REPL.
you need at least month to explain all concepts involved with C++ program,
but as for Common Lisp, you'll just have to explain how to call functions in
prefix notations, and then give a list of available function (it should take
less than 10 minutes).
well, most scripting languages have very .low starting point on this curve,
in most languages you can write just 2+2 in repl, as taught on math lessons,
so starting point is even lower, but calling non-arithmetic functions has
another syntax -- sin(1.0), and there's yet another syntax for printing
operations -- print 2 + 2 in python, so Common Lisp might be even superior
at this point.
having less syntax and coherent design can make learning lisp even superior
(less steep) than 'simple' scripting languages -- you can learn one
function/operator at a time, you don't have to memorize syntax pecularities,
and it's very easy to find a reference -- typically searching for some
syntatic constuct in lang ref is quite painful. despite i've tried learning
some Perl stuff rather hard, i cannot do even some basic stuff, like 2-d
arrays (however, i'm able to work with regex'es, i've done some web
applications in Perl -- so it doesn't mean i'm stupid :).
so well, lisp IMHO has even more gentle learning curve than scripting
languages like Python -- but that's arguable. at least, it's not much
steeper.
but once you've learned basic stuff, that's all in scripting languages --
but you can continue learning advanced stuff in Lisp: CLOS, macros, MOP etc.
so, it's advantage -- you _can_ continue learning, but you are not required
to.
well, there are some glitches: if you will have an error inside
macroexpanded macro, you'll see very odd stuff in the debugger. and there
are relatively complex sublanguages -- format facility and LOOP. LOOP shows
us that even having very simple appearance, non-uniform syntax is quite hard
to be learned, so syntax simplicity is very important for learning.
but other languages have some glitches too, so it doesn't add much to cost
of learning.
so, entry cost of learning Lisp is very low -- you can code something after
a day or so (provided you already know programming and it's only language
new). cost of learning ALL Common Lisp is relatively high -- but that's not
measure commonly used. i bet there are very few people who know _all_
++ -- i'm doing C++ programming already for 5 years or so, but i cannot say
i know C++ at good level, and i'm very very far to learning _all_ C++, but
my relative level is quite good -- actually people are doing practical C++
programming with very low level of knowledge. so total cost is not relevant.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Hi folks
The question I have is , is it worth it?
Resounding YES.
The thing about Lisp is you can build an enivonment to develop stuff -
that cuts the cost of development right down - our lewis application
server is getting new functionality all the time and what we did was to
even make things like creating an Ajax form that will open in a window
ONE LINE OF CODE!!!!!
You know there were moments that I thought, perhaps we should quit and
go back to Microsoft programming languages... but you know I'm so glad
we pulled through. Lewis is going to be doing some REALLY interesting
projects, we've got one coming that I'm almost certain we've got that
will receive data from sensors in the desert (thats not pudding, thats
large expanse of sand) and produce a map online.
We have a Lisp software house that is making money and no one is more
SURPRISED than I am!
Paul
hyperstring.net
"hyperstring.net ltd" <············@hyperstring.net> writes:
> Hi folks
>
> The question I have is , is it worth it?
>
> Resounding YES.
>
> The thing about Lisp is you can build an enivonment to develop stuff -
> that cuts the cost of development right down - our lewis application
> server is getting new functionality all the time and what we did was to
> even make things like creating an Ajax form that will open in a window
> ONE LINE OF CODE!!!!!
>
> You know there were moments that I thought, perhaps we should quit and
> go back to Microsoft programming languages... but you know I'm so glad
> we pulled through. Lewis is going to be doing some REALLY interesting
> projects, we've got one coming that I'm almost certain we've got that
> will receive data from sensors in the desert (thats not pudding, thats
> large expanse of sand) and produce a map online.
>
> We have a Lisp software house that is making money and no one is more
> SURPRISED than I am!
>
> Paul
> hyperstring.net
Um.
(message (Hello 'Bill)
(you :wrote :on '(Sun, 10 Dec 2006 12:12:36 -0500))
(
BA> Um.
um can be translated from russian as "brain" (actually, "mind").
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
On Sun, 10 Dec 2006 20:42:44 +0200, "Alex Mizrahi"
<········@users.sourceforge.net> tried to confuse everyone with this message:
>(message (Hello 'Bill)
>(you :wrote :on '(Sun, 10 Dec 2006 12:12:36 -0500))
>(
>
> BA> Um.
>
>um can be translated from russian as "brain" (actually, "mind").
>
Or "intelligence".
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
From: Dmitry V. Gorbatovsky
Subject: Re: 2 cents to Lisp comparisons
Date:
Message-ID: <elgpqm$gdn$1@aioe.org>
Alex Mizrahi wrote:
> (message (Hello 'Dmitry)
> (you :wrote :on '(Sun, 10 Dec 2006 10:36:52 +0200))
> (
>
> DVG> LEARNING COMMON LISP IS A VERY EXPENSIVE TASK.
>
> do you know the term "learning curve"?
> when speaking about learning, we'd better estimate steepness of learning
> curve rather than total expenses.
Right, but that another perspective.
I am not sure better one, when speaking
about working professional, used to
program staff in fortran/algol offspring.
There are plenty of contemporary languages
with low entrance expenses, or low-pitched
"learning curve",if you prefer.
Common Lisp not a best one.
Arguably, not even among best's.
But that is not my point.
My point is about length of that "learning curve"
up to the level sufficient for professional use.
Some one should have a real motivation to go
so long as "pupil". Especially one proficient
in some mainstream language.
Regards, Dmitry
(message (Hello 'Dmitry)
(you :wrote :on '(Sun, 10 Dec 2006 13:08:06 +0200))
(
DVG> My point is about length of that "learning curve"
DVG> up to the level sufficient for professional use.
you're overestimating "level sufficient for professional use".
i can understand most programming languages after looking for two minutes on
some examples.
for example, i've never learned Java, but i was able to fix an error in the
ABCL (Common Lisp implemented in Java) -- that's two megabytes of relatively
complex source files -- an multithreaded error that arised when multiple
threads are trying to access object when hardware supports SMP. i've found
exact source line that produced an error, than i googled for Java's
synchronization primitives, and after a minute of learning i've fixed it.
yes, it might be somewhat hard to start making real production-ready code
after two minutes of looking into the language.
but that's ok if you are not going to start as a lead programmer -- if guy
joins a team, he'll need to learn how team writes code, not how code is
generally written in that language. then he should mimic how other guys are
doing that. so "sufficient level" is not a problem.
i bet only 0.1% of professional C++ programmers know C++ at sufficient
level, so it's none-sense.
by the way, serious books on software development methodologies tell that
very many serious projects fail -- that's abnormal comparing to other
industries. i suppose that for serious projects they hire professionals with
"sufficient level" of language knowledge (after some years of learning the
language) -- but that doesn't help. so i think it's not anyhow relevant
parameter.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> (message (Hello 'Dmitry)
> (you :wrote :on '(Sun, 10 Dec 2006 13:08:06 +0200))
> (
>
> DVG> My point is about length of that "learning curve"
> DVG> up to the level sufficient for professional use.
>
> you're overestimating "level sufficient for professional use".
:-(
> by the way, serious books on software development methodologies tell that
> very many serious projects fail -- that's abnormal comparing to other
> industries. i suppose that for serious projects they hire professionals with
> "sufficient level" of language knowledge (after some years of learning the
> language) -- but that doesn't help. so i think it's not anyhow relevant
> parameter.
Ok, but how many tender do you see in other industries, where for
example, they specify that you must use only screws of 12mm for the
whole car? On the other hand, for some strange reason, in the IT
"industry" they seem entitled to tender, for example, web projects to
use PHP.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"This statement is false." In Lisp: (defun Q () (eq nil (Q)))
From: Dmitry V. Gorbatovsky
Subject: Re: 2 cents to Lisp comparisons
Date:
Message-ID: <eli0o0$b8e$1@aioe.org>
Alex Mizrahi wrote:
> (message (Hello 'Dmitry)
> (you :wrote :on '(Sun, 10 Dec 2006 13:08:06 +0200))
> (
>
> DVG> My point is about length of that "learning curve"
> DVG> up to the level sufficient for professional use.
>
> you're overestimating "level sufficient for professional use".
Maybe I do , as none-professional programmer.
Or maybe I don't, and its explains why I believe
that software bugs should be exceptionally rare,
as mathematical miscalculations in general.
Basicly I just try to speculate what
wrong with majority of "Why I never got into Lisp"
or "Lisp vs. something" type of posting.
By pointing that Common Lisp quite unique
and can't serve as general contraposition
to most other languages.
Thanks for your comments,
Dmitry
(message (Hello 'Dmitry)
(you :wrote :on '(Mon, 11 Dec 2006 00:12:15 +0200))
(
??>> you're overestimating "level sufficient for professional use".
DVG> Maybe I do , as none-professional programmer.
DVG> Or maybe I don't, and its explains why I believe
DVG> that software bugs should be exceptionally rare,
DVG> as mathematical miscalculations in general.
you are right, but that's not language knowledge what's required to make
good programs -- unfortunately nobody knows how to make reliable software
without vast budgets. maybe some not-yet-known language can do this, but
that's not Common Lisp for sure.
but i believe Common Lisp can help us to create tools for better software.
DVG> Basicly I just try to speculate what
DVG> wrong with majority of "Why I never got into Lisp"
DVG> or "Lisp vs. something" type of posting.
DVG> By pointing that Common Lisp quite unique
DVG> and can't serve as general contraposition
DVG> to most other languages.
C++ is a language with extremely high complexity, but still it's quite
popular.
i think that relative unpopularity of Lisp is more connected with history
and trends rather than with some language qualities.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Dmitry V. Gorbatovsky <·········@midasitech.com> wrote:
> LEARNING COMMON LISP IS A VERY EXPENSIVE TASK.
OK, and your question is?
Your time seems to be pretty cheap.
From: Dmitry V. Gorbatovsky
Subject: Re: 2 cents to Lisp comparisons
Date:
Message-ID: <elhcmi$prn$1@aioe.org>
Stefan Scholl wrote:
> Your time seems to be pretty cheap.
Ye... and I am not very tall,
and almost baldheaded.
Cheers, Dmitry.
On Dec 10, 4:30 pm, "Dmitry V. Gorbatovsky" <·········@midasitech.com>
wrote:
> Stefan Scholl wrote:
> > Your time seems to be pretty cheap.Ye... and I am not very tall,
> and almost baldheaded.
>
> Cheers, Dmitry.
Not learning Common Lisp can be even more expensive, if it means you
are restricted to using other programming languages.
-- David
On Sun, 10 Dec 2006 10:36:52 +0200, Dmitry V. Gorbatovsky wrote:
> LEARNING COMMON LISP IS A VERY EXPENSIVE TASK.
Learning CL COMPLETELY is a very expensive task. Aside from the two
Pascals in this group, I don't know anyone who has even come close to
doing that.
>
> So, some one has to have real motivation and
> personal resources to go through this rewarding,
> but time and work consuming process.
It's probably better to learn a workable subset suited to your specific
life and then add to that ad-hoc as you have time and/or reason.
You know, the same way you learn a natural language. (English, Russian,
etc.)
>
> Obviously the learning complexity of language
> is EXPONENTIALLY grows with number of
> "available degrees of freedom".
> By "degree of freedom" here I mean programming
> methodology and respective techniques.
This sounds reasonable.
>
> As far as I understand.
> Common Lisp has at least two additional
> "degrees of freedom" comparing to most of
> mainstream and semi-mainstream programming
> languages. One may count CLOS-MOP,
> macro + closures, declarative/functional programming
> style or all that together.
But you can learn only one of those things and take good advantage of the
language.
>
> As a reward from learning such a big language,
> one has a real power to express by programming computer.
This I agree with.
>
> From this perspective, comparison of Common Lisp
> with majority of programming languages
> does not make much sense. Like comparison
> betwin British English and AECMA Simplified English.
Certainly comparing all of CL to standard C is pretty bogus.
>
> Regard, Dmitry
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
From: Dmitry V. Gorbatovsky
Subject: Re: 2 cents to Lisp comparisons
Date:
Message-ID: <eljphk$7ar$1@aioe.org>
Chris Barts wrote:
> It's probably better to learn a workable subset suited to your specific
> life and then add to that ad-hoc as you have time and/or reason.
> You know, the same way you learn a natural language. (English, Russian,
> etc.)
As if writer writing his novel , using just limited
"Basic English" subset, and expect from first class
publisher to put it into print. :)
> But you can learn only one of those things and take good advantage of the
> language.
see above
Regards, Dmitry
Dmitry V. Gorbatovsky wrote:
> Chris Barts wrote:
> > It's probably better to learn a workable subset suited to your specific
> > life and then add to that ad-hoc as you have time and/or reason.
> > You know, the same way you learn a natural language. (English, Russian,
> > etc.)
> As if writer writing his novel , using just limited
> "Basic English" subset, and expect from first class
> publisher to put it into print. :)
Except that the point of writing a program in Common Lisp isn't usually
to display your mastery of the language to the world. For many
applications, the use won't even know that it was written in Common
Lisp, let alone that it was written in some "basic CL subset". Provided
that your program works well, users won't care even if they do know.
Cheers,
Pillsy
From: Dmitry V. Gorbatovsky
Subject: Re: 2 cents to Lisp comparisons
Date:
Message-ID: <elk1ri$qng$1@aioe.org>
Pillsy wrote:
> Except that the point of writing a program in Common Lisp isn't usually
> to display your mastery of the language to the world. For many
> applications, the use won't even know that it was written in Common
> Lisp, let alone that it was written in some "basic CL subset". Provided
> that your program works well, users won't care even if they do know.
>
> Cheers,
> Pillsy
"Programs must be written for people to read, and only incidentally for
machines to execute".
Abelson & Sussman, SICP
Regards, Dmitry
Dmitry V. Gorbatovsky wrote:
[...]
> "Programs must be written for people to read, and only incidentally for
> machines to execute".
> Abelson & Sussman, SICP
The examples for SICP itself are written in Scheme, which is a Lisp
dialect that's quite tiny compared to Common Lisp. I don't think
there's anything in the first three chapters of the book[1] that you
couldn't do in a basic subset of CL[2].
Writing readable code hardly requires using all of CL!
Cheers, Pillsy
[1] I haven't read chapters 4 and 5.
[2] No need for CLOS, DEFMACRO, extended LOOPs or FORMAT, for instance.
From: Dmitry V. Gorbatovsky
Subject: Re: 2 cents to Lisp comparisons
Date:
Message-ID: <elk3pk$v7g$1@aioe.org>
Pillsy wrote:
> I don't think
> there's anything in the first three chapters of the book[1] that you
> couldn't do in a basic subset of CL[2].
>
:)
Thanks for your comments.
Good luck, Dmitry
Dmitry V. Gorbatovsky wrote:
> Pillsy wrote:
> > I don't think
> > there's anything in the first three chapters of the book[1] that you
> > couldn't do in a basic subset of CL[2].
> :)
> Thanks for your comments.
No prob. :^)
I think there is *something* to your point though, in that if you wrote
CL like A&S write Scheme in SICP, more experienced CLers might find it
a bit awkward.
You'd get your point across fine, but improving your vocabulary and
mastering new idioms and ways of expressing yourself will make your
code even prettier.
Cheers,
Pillsy
On Mon, 11 Dec 2006 18:43:30 +0200, "Dmitry V. Gorbatovsky"
<·········@midasitech.com> tried to confuse everyone with this message:
>Pillsy wrote:
>
>> Except that the point of writing a program in Common Lisp isn't usually
>> to display your mastery of the language to the world. For many
>> applications, the use won't even know that it was written in Common
>> Lisp, let alone that it was written in some "basic CL subset". Provided
>> that your program works well, users won't care even if they do know.
>>
>> Cheers,
>> Pillsy
>
>"Programs must be written for people to read, and only incidentally for
>machines to execute".
>Abelson & Sussman, SICP
When this was written, programs were probably printed on punchcards (or whatever
they're called) and to actually execute them you had to stand in a huge queue to
the room-sized Computer and read other people's programs to pass time.
Fortunately, in this day and age people run programs far more often than read
them. :)
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
····@mail.ru (Timofei Shatrov) writes:
>>"Programs must be written for people to read, and only incidentally for
>>machines to execute".
>>Abelson & Sussman, SICP
>
> When this was written, programs were probably printed on punchcards (or whatever
> they're called) and to actually execute them you had to stand in a huge queue to
> the room-sized Computer and read other people's programs to pass time.
> Fortunately, in this day and age people run programs far more often than read
> them. :)
I don't know if you're just kidding, but I think this is still a
pretty great maxim.
Bill Atkins <······@rpi.edu> writes:
> ····@mail.ru (Timofei Shatrov) writes:
>
>>>"Programs must be written for people to read, and only incidentally for
>>>machines to execute".
>>>Abelson & Sussman, SICP
>>
>> When this was written, programs were probably printed on punchcards (or whatever
>> they're called) and to actually execute them you had to stand in a huge queue to
>> the room-sized Computer and read other people's programs to pass time.
>> Fortunately, in this day and age people run programs far more often than read
>> them. :)
>
> I don't know if you're just kidding, but I think this is still a
> pretty great maxim.
I agree. In fact, I'd say it is even more critical for programs to be
written to be read by humans now than when things were done on punch
cards as the complexity has increased - complexity the human has to
grok. To the machine, its really isn't any more complex than it was
with punch cards - after all, its just the same basic code, just more
of it.
Tim
--
tcross (at) rapttech dot com dot au
From: Dmitry V. Gorbatovsky
Subject: Re: 2 cents to Lisp comparisons
Date:
Message-ID: <elkkgi$6nn$1@aioe.org>
Timofei Shatrov wrote:
> On Mon, 11 Dec 2006 18:43:30 +0200, "Dmitry V. Gorbatovsky"
> <·········@midasitech.com> tried to confuse everyone with this message:
>
>>Pillsy wrote:
>>
>>> Except that the point of writing a program in Common Lisp isn't usually
>>> to display your mastery of the language to the world. For many
>>> applications, the use won't even know that it was written in Common
>>> Lisp, let alone that it was written in some "basic CL subset". Provided
>>> that your program works well, users won't care even if they do know.
>>>
>>> Cheers,
>>> Pillsy
>>
>>"Programs must be written for people to read, and only incidentally for
>>machines to execute".
>>Abelson & Sussman, SICP
>
> When this was written, programs were probably printed on punchcards (or
> whatever they're called) and to actually execute them you had to stand in
> a huge queue to the room-sized Computer and read other people's programs
> to pass time. Fortunately, in this day and age people run programs far
> more often than read them. :)
>
And if you are not kidding, than I should mention
That today and in foreseen future make source
of the program as understandable as possible
is the only! way to manage complexity and eliminate
bugs. For any sufficiently large project.
Regards, Dmitry
····@mail.ru (Timofei Shatrov) writes:
> On Mon, 11 Dec 2006 18:43:30 +0200, "Dmitry V. Gorbatovsky"
> <·········@midasitech.com> tried to confuse everyone with this message:
> >
> >"Programs must be written for people to read, and only incidentally for
> >machines to execute".
> >Abelson & Sussman, SICP
>
> When this was written, programs were probably printed on punchcards (or whatever
> they're called) and to actually execute them you had to stand in a huge queue to
> the room-sized Computer and read other people's programs to pass time.
OK, I see the smiley below, but SICP was written long after the demise
of the punch-card era, at least at MIT. The main point of the aphorism
is that the intent of the program should be clear to people. Much of
software engineering practice is really predicated on the need to make
the logic and meaning of the programming clear to the programmers who
write and more importantly maintain code.
> Fortunately, in this day and age people run programs far more often than read
> them. :)
Ah, beware the premature optimization impulse.
--
Thomas A. Russ, USC/Information Sciences Institute