I don't see what's so great about Paul Graham's
On Lisp.
=begin
(defun before (x y lst &key (test #'eql))
(and lst
(let ((first (car lst)))
(cond ((funcall test y first) nil)
((funcall test x first) lst)
(t (before x y (cdr lst) :test test))))))
(defun after (x y lst &key (test #'eql))
(let ((rest (before y x lst :test test)))
(and rest (member x rest :test test))))
(defun duplicate (obj lst &key (test #'eql))
(member obj (cdr (member obj lst :test test))
:test test))
(defun split-if (fn lst)
(let ((acc nil))
(do ((src lst (cdr src)))
((or (null src) (funcall fn (car src)))
(values (nreverse acc) src))
(push (car src) acc))))
=end
Ruby:
def before x, y, list, &block
block = proc{|a,b| a==b} if not block
list.each_with_index{|thing,i|
return nil if block.call(y,thing)
return list[i..-1] if block.call(x,thing) }
nil
end
def member obj, list
if block_given?
where = nil
list.each_with_index{|elt,i| break(where=i) if yield(obj,elt) }
else
where = list.index( obj )
end
where and list[where..-1]
end
p member( 4, [5,6,8] ){|x,y| x % 4 == y % 4 }
def after x, y, list, &block
rest = before( y, x, list, &block ) and
member( x, list, &block )
end
def duplicate obj, list, &block
rest = member( obj, list, &block ) and
member( obj, rest[1..-1], &block )
end
p duplicate( 4, [3,4,5,8,9,10] ){|x,y| x % 4 == y % 4 }
def split_if list
flag = false
list.partition{|x| flag or flag=yield(x) }.reverse
end
p split_if( [22,33,44,55,66]){|x| 44==x }
On 7 nov, 01:39, William James <·········@yahoo.com> wrote:
> I don't see what's so great about Paul Graham's
Forget PG... he is a troll on another level.
You are not going to convince these people that they are wrong. They
are too much trapped. They will deny everything!
When you finish translating to Ruby the whole book, contact the
author: He says he is fond to see the book translated to other
languages (like japanese). You'd have to rename it "On Ruby", though.
On Nov 6, 6:39 pm, William James <·········@yahoo.com> wrote:
> I don't see what's so great about Paul Graham's On Lisp.
Maybe there is nothing to see? That is for you to decide.
How would you implement the OO system in Ruby that he does in Lisp?
On Nov 6, 7:39 pm, William James <·········@yahoo.com> wrote:
> I don't see what's so great about Paul Graham's
> On Lisp.
>
The example you pick, a rather pedestrian example of the functional
programming style, is not particularly emblematic of what _On Lisp_ is
about; particularly, _On Lisp_ is about macros, and your example has
none.
I enjoyed _On Lisp_ when I read it, but the book does have faults, and
I believe much of what it does present is presented better by
_Paradigms of AI Programming_.
That being said, one is reminded of the story of the man who visited a
museum of modern art and remarked to the guard "I don't see what is so
special about this art," to which the guard responded "The value of
these artworks is no longer a matter for debate. It is not the works
that are being judged, but you."
···············@gmail.com wrote:
> That being said, one is reminded of the story of the man who visited a
> museum of modern art and remarked to the guard "I don't see what is so
> special about this art," to which the guard responded "The value of
> these artworks is no longer a matter for debate. It is not the works
> that are being judged, but you."
Yes, of course. Contrary to popular perceptions, Lisp is actually a
mainstream language and has proven its worth time and time again. The value
of Lisp is no longer a matter for debate. Nobody can escape the runaway
success that is Lisp.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> ···············@gmail.com wrote:
>
>>That being said, one is reminded of the story of the man who visited a
>>museum of modern art and remarked to the guard "I don't see what is so
>>special about this art," to which the guard responded "The value of
>>these artworks is no longer a matter for debate. It is not the works
>>that are being judged, but you."
>
>
> Yes, of course. Contrary to popular perceptions, Lisp is actually a
> mainstream language and has proven its worth time and time again. The value
> of Lisp is no longer a matter for debate. Nobody can escape the runaway
> success that is Lisp.
>
Well said. Now be sure to call us on the 50th anniversary of F#.
kxo
Kenny wrote:
> Jon Harrop wrote:
>> ···············@gmail.com wrote:
>>>That being said, one is reminded of the story of the man who visited a
>>>museum of modern art and remarked to the guard "I don't see what is so
>>>special about this art," to which the guard responded "The value of
>>>these artworks is no longer a matter for debate. It is not the works
>>>that are being judged, but you."
>>
>>
>> Yes, of course. Contrary to popular perceptions, Lisp is actually a
>> mainstream language and has proven its worth time and time again. The
>> value of Lisp is no longer a matter for debate. Nobody can escape the
>> runaway success that is Lisp.
>
> Well said. Now be sure to call us on the 50th anniversary of F#.
You mean F# will be a flash in the pan whereas Lisp never made it near the
pan but, instead, remained in cold storage for 50 years.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> Kenny wrote:
>
>>Jon Harrop wrote:
>>
>>>···············@gmail.com wrote:
>>>
>>>>That being said, one is reminded of the story of the man who visited a
>>>>museum of modern art and remarked to the guard "I don't see what is so
>>>>special about this art," to which the guard responded "The value of
>>>>these artworks is no longer a matter for debate. It is not the works
>>>>that are being judged, but you."
>>>
>>>
>>>Yes, of course. Contrary to popular perceptions, Lisp is actually a
>>>mainstream language and has proven its worth time and time again. The
>>>value of Lisp is no longer a matter for debate. Nobody can escape the
>>>runaway success that is Lisp.
>>
>>Well said. Now be sure to call us on the 50th anniversary of F#.
>
>
> You mean F# will be a flash in the pan whereas Lisp never made it near the
> pan but, instead, remained in cold storage for 50 years.
>
Nonsense. Lisp was born red hot and never dropped a Kelvin. What varies
is the mob's appreciation of Lisp, but mobs are never interesting. What
is interesting is the power of good ideas like dynamic typing to pull
the mob back no matter how far they have strayed.
Python, Ruby, and now Javascript have built a neuronal bridge for the
lemmings to cross... come to think of it, have you ever smelled a
sufficient quantity of lemmings? Maybe I should look at F#. I need a
language bad enough that it will never catch on. If it is proprietary
and sponsored by the most despised organization in computing, that would
be gravy.
kt
P� Sat, 08 Nov 2008 18:57:47 +0100, skrev Kenny <·········@gmail.com>:
>
> Nonsense. Lisp was born red hot and never dropped a Kelvin. What varies
A kenny at any rate.
--------------
John Thingstad
Kenny wrote:
> Nonsense. Lisp was born red hot and never dropped a Kelvin.
That certainly explains all of these incredible success stories surrounding
Lisp in 2007. Like the use of Lisp in a Hungarian government project that
handles as many as 300 on-line users:
http://p-cos.blogspot.com/2007/11/levente-mszros-posted-following-lisp.html
Like OCaml's Wink and F#'s AdCenter, except they handle 300,000,000 users
each.
> What varies
> is the mob's appreciation of Lisp, but mobs are never interesting. What
> is interesting is the power of good ideas like dynamic typing to pull
> the mob back no matter how far they have strayed.
Old ideas are always the best. Particularly in slow-moving areas like the
software industry.
> Python, Ruby, and now Javascript have built a neuronal bridge for the
> lemmings to cross... come to think of it, have you ever smelled a
> sufficient quantity of lemmings?
The swarms of people migrating from Java and C# to Lisp via Python certainly
explains a huge growth in the Lisp community instead of the OCaml and F#
communities.
OCaml and F# jobs go from 0 to 30 in 1 year:
http://www.itjobswatch.co.uk/jobs/uk/ocaml.do
http://www.itjobswatch.co.uk/jobs/uk/fsharp.do
Whereas Lisp goes from 18 to 23:
http://www.itjobswatch.co.uk/jobs/uk/lisp.do
> Maybe I should look at F#. I need a language bad enough that it will never
> catch on...
My OCaml and F# books are now outselling all Lisp books combined by a factor
of three.
The keyword "F#" is currently 15x more searched for than "Common Lisp":
http://www.google.com/trends?q=%22common+lisp%22%2Cf%23&ctab=0&geo=all&date=2008-10&sort=0
Best of luck riding the Common Lisp wave!
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Nov 8, 3:56 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> The keyword "F#" is currently 15x more searched for than "Common Lisp":
>
> http://www.google.com/trends?q=%22common+lisp%22%2Cf%23&ctab=0&geo=al...
>
> Best of luck riding the Common Lisp wave!
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u
"Crap" is infinitely more than popular than "Flying Frog Consultancy":
http://www.google.com/trends?q=%22flying+frog+consultancy%22%2C+crap&ctab=1684956530&geo=all&date=all
Jon Harrop wrote:
> OCaml and F# jobs go from 0 to 30 in 1 year:
>
> http://www.itjobswatch.co.uk/jobs/uk/ocaml.do
> http://www.itjobswatch.co.uk/jobs/uk/fsharp.do
Sorry, that should be 0 to 39 jobs in 1 year for OCaml + F#.
> Whereas Lisp goes from 18 to 23:
>
> http://www.itjobswatch.co.uk/jobs/uk/lisp.do
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 2008-11-08, Jon Harrop <···@ffconsultancy.com> wrote:
> Kenny wrote:
>> Nonsense. Lisp was born red hot and never dropped a Kelvin.
>
> That certainly explains all of these incredible success stories surrounding
> Lisp in 2007.
It sure explains why Lisp has one Jon Harrop spellbound.
Welcome back, by the way. You didn't manage to stay away for long.
> My OCaml and F# books are now outselling all Lisp books combined by a factor
> of three.
That only shows that these languages are poorly documented, and that there is
lack of free books in electronic form.
Between the free books you can download about Lisp, and the ANSI standard being
available in the form of HyperSpec, there is no need for anyone to be buying
Lisp books. At least not ones that have the flavor of a tutorial or reference
manual.
If you want to move books, why don't you try writing real pulp? Paperback
novels outsell OCaml and F# books by orders of magnitude. Half the stuff
you write here is pure fiction already.
Jon Harrop <···@ffconsultancy.com> writes:
> Kenny wrote:
>> Jon Harrop wrote:
>>> ···············@gmail.com wrote:
>>>>That being said, one is reminded of the story of the man who visited a
>>>>museum of modern art and remarked to the guard "I don't see what is so
>>>>special about this art," to which the guard responded "The value of
>>>>these artworks is no longer a matter for debate. It is not the works
>>>>that are being judged, but you."
>>>
>>>
>>> Yes, of course. Contrary to popular perceptions, Lisp is actually a
>>> mainstream language and has proven its worth time and time again. The
>>> value of Lisp is no longer a matter for debate. Nobody can escape the
>>> runaway success that is Lisp.
>>
>> Well said. Now be sure to call us on the 50th anniversary of F#.
>
> You mean F# will be a flash in the pan whereas Lisp never made it near the
> pan but, instead, remained in cold storage for 50 years.
Lame, lame, lame. Kenny stung you with that zinger, and that's the
best you have. Lame. I wonder why you're posting dribble on c.l.l
instead of comp.lang.f#, oh wait ...
On Nov 7, 9:17 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> ···············@gmail.com wrote:
> > That being said, one is reminded of the story of the man who visited a
> > museum of modern art and remarked to the guard "I don't see what is so
> > special about this art," to which the guard responded "The value of
> > these artworks is no longer a matter for debate. It is not the works
> > that are being judged, but you."
>
> Yes, of course. Contrary to popular perceptions, Lisp is actually a
> mainstream language and has proven its worth time and time again. The value
> of Lisp is no longer a matter for debate. Nobody can escape the runaway
> success that is Lisp.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
I fail to see how anything in my post could be construed as claiming
that Lisp is a mainstream language.
Perhaps, for the sake of Ph.D.'s more interested in trolling than
thinking, I should clarify: my point was only that the opinion
expressed in Mr. James' post says much more about Mr. James than it
does about _On Lisp_.
Likewise, the apparent need for a distinguished F# consultant to visit
a Lisp forum for the purpose of trashing Lisp's "mainstream" status
and performance in web search statistics says a great deal about the
state of F#, F# consultancy, and the amount of time that F#
consultants spend making sure their web address ends up in
comp.lang.lisp archives, but says very little about the state of Lisp.
···············@gmail.com wrote:
> On Nov 7, 9:17 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> ···············@gmail.com wrote:
>> > That being said, one is reminded of the story of the man who visited a
>> > museum of modern art and remarked to the guard "I don't see what is so
>> > special about this art," to which the guard responded "The value of
>> > these artworks is no longer a matter for debate. It is not the works
>> > that are being judged, but you."
>>
>> Yes, of course. Contrary to popular perceptions, Lisp is actually a
>> mainstream language and has proven its worth time and time again. The
>> value of Lisp is no longer a matter for debate. Nobody can escape the
>> runaway success that is Lisp.
>
> I fail to see how anything in my post could be construed as claiming
> that Lisp is a mainstream language.
You implied that Lisp's value is not a matter for debate.
> Perhaps, for the sake of Ph.D.'s more interested in trolling than
> thinking, I should clarify: my point was only that the opinion
> expressed in Mr. James' post says much more about Mr. James than it
> does about _On Lisp_.
>
> Likewise, the apparent need for a distinguished F# consultant to visit
> a Lisp forum for the purpose of trashing Lisp's "mainstream" status
> and performance in web search statistics says a great deal about the
> state of F#, F# consultancy, and the amount of time that F#
> consultants spend making sure their web address ends up in
> comp.lang.lisp archives, but says very little about the state of Lisp.
In other words, you would rather your assertions were accepted without
question.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
I've been lurking on comp.lang.lisp for many years. Sometimes, my
patience is exhausted and I reply to certain characters against my
better judgment.
On Nov 9, 10:29 am, Jon Harrop <····@ffconsultancy.com> wrote:
> You implied that Lisp's value is not a matter for debate.
What you continually fail to realize is that there are at least 2
contexts in which Lisp's value is not a matter for debate. The first
context is my personal use of Lisp. I've made the determination to use
Lisp based on my own set of requirements. You have incomplete
knowledge of my requirements and are therefor in no position to advise
me that Lisp does not meet my requirements or meets them less
adequately than F#. When you repeatedly make this argument, you are
only demonstrating hubris and ignorance.
The second context in which the value of Lisp is not up for debate is
comp.lang.lisp. No one is coerced into participating in
comp.lang.lisp. Implicit in the fact that a newsgroup specific to Lisp
exists is that a sufficient number of people have found value in Lisp
to seek a newsgroup dedicated to its discussion. Your posts extolling
the virtues of F# over Lisp are out of context and simply noise. Why
is that so difficult for you to realize?
> In other words, you would rather your assertions were accepted without question.
In the context of my personal use and the discussions of
comp.lang.lisp, that is correct. I do not need someone continually
questioning my decision to use Lisp. If I want a critical review of my
programming, I will ask for it. If I want to compare the value of Lisp
with some other language, I will seek out the appropriate forum. You
are doing yourself quite a disservice with your posts.
You haven't posted on comp.lang.lisp for some time and I truly do
appreciate that. Please go back to lurking and leave the denizens of
comp.lang.lisp to our blissful ignorance of F#.
Thomas M. Hermann wrote:
> On Nov 9, 10:29 am, Jon Harrop <····@ffconsultancy.com> wrote:
>> You implied that Lisp's value is not a matter for debate.
>
> What you continually fail to realize is that there are at least 2
> contexts in which Lisp's value is not a matter for debate. The first
> context is my personal use of Lisp. I've made the determination to use
> Lisp based on my own set of requirements. You have incomplete
> knowledge of my requirements and are therefor in no position to advise
> me that Lisp does not meet my requirements or meets them less
> adequately than F#. When you repeatedly make this argument, you are
> only demonstrating hubris and ignorance.
I said nothing of your requirements.
> The second context in which the value of Lisp is not up for debate is
> comp.lang.lisp. No one is coerced into participating in
> comp.lang.lisp. Implicit in the fact that a newsgroup specific to Lisp
> exists is that a sufficient number of people have found value in Lisp
> to seek a newsgroup dedicated to its discussion.
Discussing something does not make it valuable.
>> In other words, you would rather your assertions were accepted without
>> question.
>
> In the context of my personal use and the discussions of
> comp.lang.lisp, that is correct. I do not need someone continually
> questioning my decision to use Lisp.
Exactly.
> If I want a critical review of my programming, I will ask for it. If I
> want to compare the value of Lisp with some other language, I will seek
> out the appropriate forum. You are doing yourself quite a disservice with
> your posts.
Delusions of grandeur. In reality, Lispers are of no direct importance to me
at all (they are mostly unemployable). I correct their misinformation as a
hobby. If you don't want to be corrected, don't post here.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Nov 9, 1:23 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Thomas M. Hermann wrote:
> > On Nov 9, 10:29 am, Jon Harrop <····@ffconsultancy.com> wrote:
> >> You implied that Lisp's value is not a matter for debate.
>
> > What you continually fail to realize is that there are at least 2
> > contexts in which Lisp's value is not a matter for debate. The first
> > context is my personal use of Lisp. I've made the determination to use
> > Lisp based on my own set of requirements. You have incomplete
> > knowledge of my requirements and are therefor in no position to advise
> > me that Lisp does not meet my requirements or meets them less
> > adequately than F#. When you repeatedly make this argument, you are
> > only demonstrating hubris and ignorance.
>
> I said nothing of your requirements.
Not directly, but when you repeatedly post that F# is superior to
Lisp, you are most definitely addressing the requirements of those on
comp.lang.lisp, including me. And, you are addressing requirements of
which you have no understanding.
> > The second context in which the value of Lisp is not up for debate is
> > comp.lang.lisp. No one is coerced into participating in
> > comp.lang.lisp. Implicit in the fact that a newsgroup specific to Lisp
> > exists is that a sufficient number of people have found value in Lisp
> > to seek a newsgroup dedicated to its discussion.
>
> Discussing something does not make it valuable.
Correct, but that has no bearing on my point. comp.lang.lisp is for
discussions of Lisp by people that find value in Lisp. Discussions of
Lisp do not make it valuable. Lisp has it own value. Discussions have
their own value. Your posts on comp.lang.lisp rarely have value. While
we're at it, let's extend your point. The volume of Google searches of
something, say some programming language, do not add value to
something any more than discussing it does.
> >> In other words, you would rather your assertions were accepted without
> >> question.
>
> > In the context of my personal use and the discussions of
> > comp.lang.lisp, that is correct. I do not need someone continually
> > questioning my decision to use Lisp.
>
> Exactly.
In the appropriate context, I have no problem with my assertions being
challenged. What I am trying to convey to you is that your posts are
out of context. Your posts are noise.
> > If I want a critical review of my programming, I will ask for it. If I
> > want to compare the value of Lisp with some other language, I will seek
> > out the appropriate forum. You are doing yourself quite a disservice with
> > your posts.
>
> Delusions of grandeur. In reality, Lispers are of no direct importance to me
> at all (they are mostly unemployable). I correct their misinformation as a
> hobby. If you don't want to be corrected, don't post here.
The only delusion I'm experiencing is that you'll go away. You can't
correct what you don't understand. Let's be explicit. You don't
understand that the people on comp.lang.lisp use Lisp because it meets
their requirements. Requirements that you also don't understand. You
also don't understand that people on comp.lang.lisp don't find value
in your posts.
The reason that your corrections are of no value on comp.lang.lisp is
that when someone posts on comp.lang.lisp, the question is generally
not about language choice, but rather about using Lisp. When your
response suggests something other than Lisp, it is orthogonal to the
question. Therefore, it is noise. You correct nothing.
Is this truly your hobby? Most people I know have hobbies that don't
involve tilting at windmills. Then, again, I have responded to 2, well
maybe 3, of your posts. Call me Sancho.
On Sun, 09 Nov 2008 11:25:08 -0800, Thomas M. Hermann wrote:
> involve tilting at windmills. Then, again, I have responded to 2, well
> maybe 3, of your posts. Call me Sancho.
There is little point in responding to him. It appears that JH was
brought up lacking manners, so he butts in with out-of-context remarks
that do not interest the readers of this newsgroup and are explicitly
discouraged by netiquette. His parents could have done something about
these tendencies this when he was young, maybe they didn't have the
requisite cultural background either. There is nothing we can do about
this now, so it is best to ignore him.
What he does not realize is that he is leaving a net trail that should
discourage anyone from hiring his services as a consultant: trolling
Usenet is rarely a skill a prospective employer is looking for. If you
look at the webpage of his consultancy, you will find no references to
successful projects they participated in or even a staff page, just vague
references to "elite programmers".
Tamas
Tamas K Papp wrote:
> What he does not realize is that he is leaving a net trail that should
> discourage anyone from hiring his services as a consultant: trolling
> Usenet is rarely a skill a prospective employer is looking for.
Gone are the days that comp.lang.lisp was of any such importance. My
ramblings here used to get us significant sales but the continued demise of
Lisp has, unfortunately, undermined that revenue stream. Perhaps I poached
Lispers to extinction.
In fact, we have become so successful at creating, shipping and marketing
our own OCaml and F# products that we have increased our consultancy fees
to $2,000 per day and are still rejecting contracts. Hence the views of
your hypothetical employer are of no importance.
> If you look at the webpage of his consultancy, you will find no references
> to successful projects they participated in
F#, Mathematica and XenEnterprise are the obvious ones. Most recently, we
consulted for a company called DataSynapse who are adding support for F# to
their data center software. Note that my consultancy is as much about
business management as it is about technical issues these days.
Industrialists need to know that F# has a future and Lisp does not.
> or even a staff page,
There are two of us and my colleague values her anonymity.
> just vague references to "elite programmers".
Specifically, we offer a head hunting service to match elite functional
programmers with high-paying employers.
Smug Lisp Weenies need not apply: they are unemployable.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop <···@ffconsultancy.com> writes:
> Tamas K Papp wrote:
>> or even a staff page,
>
> There are two of us and my colleague values her anonymity.
Not surprised.
Thomas M. Hermann wrote:
> On Nov 9, 1:23 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> Thomas M. Hermann wrote:
>> > On Nov 9, 10:29 am, Jon Harrop <····@ffconsultancy.com> wrote:
>> >> You implied that Lisp's value is not a matter for debate.
>>
>> > What you continually fail to realize is that there are at least 2
>> > contexts in which Lisp's value is not a matter for debate. The first
>> > context is my personal use of Lisp. I've made the determination to use
>> > Lisp based on my own set of requirements. You have incomplete
>> > knowledge of my requirements and are therefor in no position to advise
>> > me that Lisp does not meet my requirements or meets them less
>> > adequately than F#. When you repeatedly make this argument, you are
>> > only demonstrating hubris and ignorance.
>>
>> I said nothing of your requirements.
>
> Not directly, but when you repeatedly post that F# is superior to
> Lisp...
Then why didn't you reply to such a post rather than replying here, where it
is not relevant?
>> > The second context in which the value of Lisp is not up for debate is
>> > comp.lang.lisp. No one is coerced into participating in
>> > comp.lang.lisp. Implicit in the fact that a newsgroup specific to Lisp
>> > exists is that a sufficient number of people have found value in Lisp
>> > to seek a newsgroup dedicated to its discussion.
>>
>> Discussing something does not make it valuable.
>
> Correct, but that has no bearing on my point.
You stated that the existence of this newsgroup implied that Lisp is
valuable when, in fact, discussing something does not make it valuable.
> comp.lang.lisp is for discussions of Lisp by people that find value in
> Lisp.
And lots of people like me.
> Discussions of
> Lisp do not make it valuable. Lisp has it own value. Discussions have
> their own value. Your posts on comp.lang.lisp rarely have value. While
> we're at it, let's extend your point. The volume of Google searches of
> something, say some programming language, do not add value to
> something any more than discussing it does.
Then you will be more interested in the job market or product sales.
>> >> In other words, you would rather your assertions were accepted without
>> >> question.
>>
>> > In the context of my personal use and the discussions of
>> > comp.lang.lisp, that is correct. I do not need someone continually
>> > questioning my decision to use Lisp.
>>
>> Exactly.
>
> In the appropriate context, I have no problem with my assertions being
> challenged. What I am trying to convey to you is that your posts are
> out of context. Your posts are noise.
Except that my post was in response to a false implication by Joseph and, in
fact, your post was out of context (noise).
>> > If I want a critical review of my programming, I will ask for it. If I
>> > want to compare the value of Lisp with some other language, I will seek
>> > out the appropriate forum. You are doing yourself quite a disservice
>> > with your posts.
>>
>> Delusions of grandeur. In reality, Lispers are of no direct importance to
>> me at all (they are mostly unemployable). I correct their misinformation
>> as a hobby. If you don't want to be corrected, don't post here.
>
> The only delusion I'm experiencing is that you'll go away. You can't
> correct what you don't understand. Let's be explicit. You don't
> understand that the people on comp.lang.lisp use Lisp because it meets
> their requirements. Requirements that you also don't understand. You
> also don't understand that people on comp.lang.lisp don't find value
> in your posts.
Yet my posts sell our products.
> The reason that your corrections are of no value on comp.lang.lisp is
> that when someone posts on comp.lang.lisp, the question is generally
> not about language choice, but rather about using Lisp. When your
> response suggests something other than Lisp, it is orthogonal to the
> question. Therefore, it is noise. You correct nothing.
Or you do not understand what I write.
> Is this truly your hobby?
Yes.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Nov 9, 9:21 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Then why didn't you reply to such a post rather than replying here, where it
> is not relevant?
As I stated earlier, my patience with your posts was finally
exhausted. As for relevance, this thread was worthless from the start,
so it was no great loss to respond to your posts.
> >> > The second context in which the value of Lisp is not up for debate is
> >> > comp.lang.lisp. No one is coerced into participating in
> >> > comp.lang.lisp. Implicit in the fact that a newsgroup specific to Lisp
> >> > exists is that a sufficient number of people have found value in Lisp
> >> > to seek a newsgroup dedicated to its discussion.
>
> >> Discussing something does not make it valuable.
>
> > Correct, but that has no bearing on my point.
>
> You stated that the existence of this newsgroup implied that Lisp is
> valuable when, in fact, discussing something does not make it valuable.
Those are 2 separate, unrelated, concepts. Indeed, discussing
something does not make it valuable. The existence of this newsgroup
is evidence that there are people that value Lisp. Discussions on this
newsgroup can add value, perhaps. Clearly, this one isn't.
>
> > comp.lang.lisp is for discussions of Lisp by people that find value in
> > Lisp.
>
> And lots of people like me.
Fortunately, there are not lots of people like you.
> > Discussions of
> > Lisp do not make it valuable. Lisp has it own value. Discussions have
> > their own value. Your posts on comp.lang.lisp rarely have value. While
> > we're at it, let's extend your point. The volume of Google searches of
> > something, say some programming language, do not add value to
> > something any more than discussing it does.
>
> Then you will be more interested in the job market or product sales.
No, programming facilitates my profession, it is not my profession.
>
> >> >> In other words, you would rather your assertions were accepted without
> >> >> question.
>
> >> > In the context of my personal use and the discussions of
> >> > comp.lang.lisp, that is correct. I do not need someone continually
> >> > questioning my decision to use Lisp.
>
> >> Exactly.
>
> > In the appropriate context, I have no problem with my assertions being
> > challenged. What I am trying to convey to you is that your posts are
> > out of context. Your posts are noise.
>
> Except that my post was in response to a false implication by Joseph and, in
> fact, your post was out of context (noise).
I have to agree, my posts in this thread have been noise. But, this
thread was noise from the start, so nothing lost there.
> >> > If I want a critical review of my programming, I will ask for it. If I
> >> > want to compare the value of Lisp with some other language, I will seek
> >> > out the appropriate forum. You are doing yourself quite a disservice
> >> > with your posts.
>
> >> Delusions of grandeur. In reality, Lispers are of no direct importance to
> >> me at all (they are mostly unemployable). I correct their misinformation
> >> as a hobby. If you don't want to be corrected, don't post here.
>
> > The only delusion I'm experiencing is that you'll go away. You can't
> > correct what you don't understand. Let's be explicit. You don't
> > understand that the people on comp.lang.lisp use Lisp because it meets
> > their requirements. Requirements that you also don't understand. You
> > also don't understand that people on comp.lang.lisp don't find value
> > in your posts.
>
> Yet my posts sell our products.
So, your posts are marketing? Previously, you said this was your
hobby. Which is it?
> > The reason that your corrections are of no value on comp.lang.lisp is
> > that when someone posts on comp.lang.lisp, the question is generally
> > not about language choice, but rather about using Lisp. When your
> > response suggests something other than Lisp, it is orthogonal to the
> > question. Therefore, it is noise. You correct nothing.
>
> Or you do not understand what I write.
In some sense, you're correct. It boggles the mind that someone would
repeatedly post information that is not welcomed. You've claimed it's
a hobby. You've claimed it's marketing. I'm not sure you understand
what you write.
>
> > Is this truly your hobby?
>
> Yes.
First you say it's your hobby, then you say it's marketing, now it's
your hobby again?
Thomas M. Hermann wrote:
>> >> Discussing something does not make it valuable.
>>
>> > Correct, but that has no bearing on my point.
>>
>> You stated that the existence of this newsgroup implied that Lisp is
>> valuable when, in fact, discussing something does not make it valuable.
>
> Those are 2 separate, unrelated, concepts. Indeed, discussing
> something does not make it valuable.
Yes.
> The existence of this newsgroup is evidence that there are people that
> value Lisp.
No. People can and do discuss valueless things. The presence of this
newsgroup indicates that people once wanted to discuss Lisp. That does not
indicate that Lisp is valuable.
> Discussions on this newsgroup can add value, perhaps. Clearly, this one
> isn't.
Indeed. I've never seen a valuable discussion here. These discussions are
generally people posting about better alternatives to Lisp (e.g. this
thread), posting about how they've reinvented the wheel using Lisp or
posting falsehoods about Lisp being blub because it lets them reinvent the
wheel.
>> > Discussions of
>> > Lisp do not make it valuable. Lisp has it own value. Discussions have
>> > their own value. Your posts on comp.lang.lisp rarely have value. While
>> > we're at it, let's extend your point. The volume of Google searches of
>> > something, say some programming language, do not add value to
>> > something any more than discussing it does.
>>
>> Then you will be more interested in the job market or product sales.
>
> No, programming facilitates my profession, it is not my profession.
Unless you're running your own VM on your own OS, you're still building upon
technology created by people for whom programming is their profession.
Their work dictates what is available to you. So their work should still be
of interest to you.
>> > In the appropriate context, I have no problem with my assertions being
>> > challenged. What I am trying to convey to you is that your posts are
>> > out of context. Your posts are noise.
>>
>> Except that my post was in response to a false implication by Joseph and,
>> in fact, your post was out of context (noise).
>
> I have to agree, my posts in this thread have been noise. But, this
> thread was noise from the start, so nothing lost there.
This thread was a valid and interesting criticism of Lisp literature. If
Lisp were good, why are Lisp books full of examples where Lisp fares poorly
compared to other languages?
Moreover, why do you consider any such objective questions to be noise?
>> >> > If I want a critical review of my programming, I will ask for it. If
>> >> > I want to compare the value of Lisp with some other language, I will
>> >> > seek out the appropriate forum. You are doing yourself quite a
>> >> > disservice with your posts.
>>
>> >> Delusions of grandeur. In reality, Lispers are of no direct importance
>> >> to me at all (they are mostly unemployable). I correct their
>> >> misinformation as a hobby. If you don't want to be corrected, don't
>> >> post here.
>>
>> > The only delusion I'm experiencing is that you'll go away. You can't
>> > correct what you don't understand. Let's be explicit. You don't
>> > understand that the people on comp.lang.lisp use Lisp because it meets
>> > their requirements. Requirements that you also don't understand. You
>> > also don't understand that people on comp.lang.lisp don't find value
>> > in your posts.
>>
>> Yet my posts sell our products.
>
> So, your posts are marketing? Previously, you said this was your
> hobby. Which is it?
Both. Who wouldn't want a hobby that earns money?!
>> > The reason that your corrections are of no value on comp.lang.lisp is
>> > that when someone posts on comp.lang.lisp, the question is generally
>> > not about language choice, but rather about using Lisp. When your
>> > response suggests something other than Lisp, it is orthogonal to the
>> > question. Therefore, it is noise. You correct nothing.
>>
>> Or you do not understand what I write.
>
> In some sense, you're correct. It boggles the mind that someone would
> repeatedly post information that is not welcomed.
If it is not welcomed, why does it boost our sales?
> You've claimed it's a hobby. You've claimed it's marketing. I'm not sure
> you understand what you write.
I don't like to stand by and watch people be deceived. The Lisp community
have spent a long time evolving convincing pseudo-scientific arguments and
the people who hear them have to spend a long time studying to work out why
the arguments are flawed. All too often, people don't question the mantra
and just have faith in it. For many people, hearing the counter arguments
from me just saves them time.
For some reason, programming languages evoke the same emotions in people as
religion and this causes a lot of problems. Pascal Costanza tries to write
scientific papers as an academic. He wrote something in a draft that I knew
was wrong (he generalized a limitation of Java to all statically-typed
languages) so I wrote to him with the correction and a trivial counter
example. He wasn't interested in facts, he just wanted to publish papers
that made Lisp sound good. So he went ahead and published his academic
paper anyway. No correction, no erratum. Now the Lisp community can cite
that paper as "fact" and so it goes on...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Nov 10, 9:36 am, Jon Harrop <····@ffconsultancy.com> wrote:
> > The existence of this newsgroup is evidence that there are people that
> > value Lisp.
>
> No. People can and do discuss valueless things. The presence of this
> newsgroup indicates that people once wanted to discuss Lisp. That does not
> indicate that Lisp is valuable.
No, the fact that this newsgroup has moderate activity, sans
discussions like this one, indicates that people still want to discuss
Lisp and find it valuable.
> > Discussions on this newsgroup can add value, perhaps. Clearly, this one
> > isn't.
>
> Indeed. I've never seen a valuable discussion here. These discussions are
> generally people posting about better alternatives to Lisp (e.g. this
> thread), posting about how they've reinvented the wheel using Lisp or
> posting falsehoods about Lisp being blub because it lets them reinvent the
> wheel.
You're wrong, I find valuable discussions on comp.lang.lisp
frequently. On occasion, when you're not trying to prop up F# by
trashing Lisp, you've even posted reasonable responses to discussions
on comp.lang.lisp. That's why it's all the more annoying when you post
drivel, because I know you're capable of posting better.
> > No, programming facilitates my profession, it is not my profession.
>
> Unless you're running your own VM on your own OS, you're still building upon
> technology created by people for whom programming is their profession.
> Their work dictates what is available to you. So their work should still be
> of interest to you.
By that metric, F# and the other technologies that you advocate would
be excluded without review. If my overriding metric was prior art in
my profession and what was available, I would be working exclusively
in C and Fortran. Based on your repeated posts, I reviewed F# and
ocaml some time ago. I also reviewed Haskell. F# is a very risky
language to invest my resources in because of Microsoft's track record
with respect to language support, the best(or worst) example being VB.
As for ocaml and Haskell, there just wasn't any compelling reason,
based on my requirements, to adopt those languages. My requirements
are well met by Common Lisp. It is standardized, it is available on
any platform I choose to run and I'm confident that 5, 10 or 20 years
from now, I'll still be using the code that I invested my time in
today. It satisfies my performance requirements, it satisfies my data
representation requirements and it satisfies my workflow requirements.
Common Lisp is just plain satisfying to use. You can shout from the
bell towers all you wish about F#, but until it is liberated from
Microsoft, it is just too risky for me to invest my time in.
> This thread was a valid and interesting criticism of Lisp literature. If
> Lisp were good, why are Lisp books full of examples where Lisp fares poorly
> compared to other languages?
No, this thread was a clumsy translation of Lisp literature and a
sophomoric comparison at best. Books on programming languages in
general are filled with examples that do not represent best practices.
The goals of examples, especially in the early chapters of the book,
are not to present best practices, but to illustrate concepts
commensurate with the amount of domain knowledge the reader is
expected to have at that point. As someone that has written a
programming book, I would expect you to appreciate that.
> Moreover, why do you consider any such objective questions to be noise?
Not at all, I enjoy objective questions and criticisms, but I expect a
certain level of rigor that this thread completely lacks. What I
expect is something on the order of this:
http://www.cs.northwestern.edu/academics/courses/325/readings/graham/graham-notes.html
> > So, your posts are marketing? Previously, you said this was your
> > hobby. Which is it?
>
> Both. Who wouldn't want a hobby that earns money?!
I don't because if my hobby earns me money, I have to start worrying
about reporting it on my taxes and then the thrill is truly gone.
> > In some sense, you're correct. It boggles the mind that someone would
> > repeatedly post information that is not welcomed.
>
> If it is not welcomed, why does it boost our sales?
I know that it's not welcomed, I'll just have to take your word that
it boost your sales.
> > You've claimed it's a hobby. You've claimed it's marketing. I'm not sure
> > you understand what you write.
>
> I don't like to stand by and watch people be deceived. The Lisp community
> have spent a long time evolving convincing pseudo-scientific arguments and
> the people who hear them have to spend a long time studying to work out why
> the arguments are flawed. All too often, people don't question the mantra
> and just have faith in it. For many people, hearing the counter arguments
> from me just saves them time.
You insult the intelligence of the people that read comp.lang.lisp
with that statement and at the same time overrate the value of the
service that you're providing. Live and let live. I'm quite confident
that the people reading comp.lang.lisp are sophisticated enough to
make these decisions on their own.
> For some reason, programming languages evoke the same emotions in people as
> religion and this causes a lot of problems.
For example, repeatedly posting about the superiority of F# over Lisp
on comp.lang.lisp? Hello, pot? Yeah, this is the kettle.
> Pascal Costanza tries to write
> scientific papers as an academic. He wrote something in a draft that I knew
> was wrong (he generalized a limitation of Java to all statically-typed
> languages) so I wrote to him with the correction and a trivial counter
> example. He wasn't interested in facts, he just wanted to publish papers
> that made Lisp sound good. So he went ahead and published his academic
> paper anyway. No correction, no erratum. Now the Lisp community can cite
> that paper as "fact" and so it goes on...
And you just want to sell books about F#. Now, you publicly broadcast
a private conversation and personally impugn someone. I don't know
whether or not your criticism was valid, but that last paragraph was
in very poor taste. The appropriate forum for your criticism would
have been a letter to the publication. Those are regularly published
in the journals that I subscribe to and I think are a valuable part of
the process.
Aside from feeling that I was wasting time and generating noise with
this conversation, I really didn't have too much of a problem with it
until I read your last paragraph. Now, I regret that the conversation
led to the point that you felt the need to make a personal attack on
someone not involved in it in anyway, shape or form. I think, though,
that I have learned my lesson. Patience is a virtue.
From: Michael Ekstrand
Subject: The PL design space is not that simple (was: Re: Alternatives 4)
Date:
Message-ID: <87myg8zn58.fsf_-_@elehack.net>
Jon Harrop <···@ffconsultancy.com> writes:
> Thomas M. Hermann wrote:
>> On Nov 9, 10:29 am, Jon Harrop <····@ffconsultancy.com> wrote:
>>> You implied that Lisp's value is not a matter for debate.
>>
>> What you continually fail to realize is that there are at least 2
>> contexts in which Lisp's value is not a matter for debate. The first
>> context is my personal use of Lisp. I've made the determination to use
>> Lisp based on my own set of requirements. You have incomplete
>> knowledge of my requirements and are therefor in no position to advise
>> me that Lisp does not meet my requirements or meets them less
>> adequately than F#. When you repeatedly make this argument, you are
>> only demonstrating hubris and ignorance.
>
> I said nothing of your requirements.
That may be; however, requirements are an important part of selecting a
solution, including a programming language. There are very few
arguments about programming language or tool selection which can be made
in a vacuum. Arguments are only relevant when measured against specific
requirements. "This feature is great" is fine to say, but what
requirement does it help satisfy, and satisfy better than another
solution without that feature?
>> The second context in which the value of Lisp is not up for debate is
>> comp.lang.lisp. No one is coerced into participating in
>> comp.lang.lisp. Implicit in the fact that a newsgroup specific to Lisp
>> exists is that a sufficient number of people have found value in Lisp
>> to seek a newsgroup dedicated to its discussion.
>
> Discussing something does not make it valuable.
As a general rule, value is based on demand and usage. You may have a
spectacular widget, but if no one wants it, it is not valuable.
Now, by that argument, if the statements you make about the job market
are accurate (a fact I rather doubt), then one could say that Lisp
programmers are not valuable. But the presence of people wanting Lisp,
and wanting to discuss its usage and improvement, indicates that Lisp
itself is valuable. Further, the ability of Franz and the company
selling LispWorks to sell products and stay in business indicates that
Lisp has monetary value to some people. It may not be valuable to you,
but it is certainly valuable to many of us.
>>> In other words, you would rather your assertions were accepted without
>>> question.
>>
>> In the context of my personal use and the discussions of
>> comp.lang.lisp, that is correct. I do not need someone continually
>> questioning my decision to use Lisp.
>
> Exactly.
>
>> If I want a critical review of my programming, I will ask for it. If I
>> want to compare the value of Lisp with some other language, I will seek
>> out the appropriate forum. You are doing yourself quite a disservice with
>> your posts.
>
> Delusions of grandeur. In reality, Lispers are of no direct importance to me
> at all (they are mostly unemployable). I correct their misinformation as a
> hobby. If you don't want to be corrected, don't post here.
Dr. Harrop, I see in your posts in this venue the same thing I see from
many programming-language-theoretic people (and which drove me away from
the subject as a research focus in pursuing my own Ph.D): an assumption
of certain features and concepts in language design as inherent goods.
I don't believe that the PL design space is that simple. Programming
language design (like virtually all design) is an art of tradeoffs.
While design decisions provide certain benefits, they generally require
something to be sacrificed to gain those benefits. This is why the
selection of a programming language (or other tool) requires an
understanding of application requirements: different applications will
be affected by the benefits and detriments of different solutions in
different ways. For some applications, the strong type checking and
analysis of a statically-typed FPL is a major win. I use OCaml quite
regularly for many tasks, particularly to facilitate my research, and
think it is an excellent language (F# may be as well, but I'm
sufficiently disinterested in Microsoft's product offerings that I have
not investigated it myself). I find it particularly excellent for graph
analysis problems. It is not, however, the holy grail or silver bullet
of programming languages. This summer, I switched a project from OCaml
to Common Lisp because the latter mapped better to my requirements, and
don't regret that decision at all.
In summary, please stop insinuating that people chosen the wrong
language to meet their requirements simply because they happen to have
chosen Lisp. Also, the dubious arguments made on the basis of things
many people don't care about are simply noise -- many people, or at
least myself, don't care how many jobs are available requiring Common
Lisp expertise, we care that Common Lisp lets us accomplish our goals
effectively.
And finally, please recognize and concede that Common Lisp is not
entirely without merit. If it were, then no rational person would
choose to use it, and in my experience there are quite a few rational
people on this newsgroup who have chosen to use it.
Regards,
- Michael
--
mouse, n: A device for pointing at the xterm in which you want to type.
Michael Ekstrand wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> I said nothing of your requirements.
>
> That may be; however, requirements are an important part of selecting a
> solution, including a programming language. There are very few
> arguments about programming language or tool selection which can be made
> in a vacuum. Arguments are only relevant when measured against specific
> requirements. "This feature is great" is fine to say, but what
> requirement does it help satisfy, and satisfy better than another
> solution without that feature?
Absolutely.
>>> The second context in which the value of Lisp is not up for debate is
>>> comp.lang.lisp. No one is coerced into participating in
>>> comp.lang.lisp. Implicit in the fact that a newsgroup specific to Lisp
>>> exists is that a sufficient number of people have found value in Lisp
>>> to seek a newsgroup dedicated to its discussion.
>>
>> Discussing something does not make it valuable.
>
> As a general rule, value is based on demand and usage. You may have a
> spectacular widget, but if no one wants it, it is not valuable.
Exactly.
> Now, by that argument, if the statements you make about the job market
> are accurate (a fact I rather doubt), then one could say that Lisp
> programmers are not valuable.
I think the data speak for themselves:
http://www.itjobswatch.co.uk/jobs/uk/lisp.do
http://www.itjobswatch.co.uk/jobs/uk/ocaml.do
http://www.itjobswatch.co.uk/jobs/uk/fsharp.do
jobs x salary = value
17 x £44,971 = £0.76M Lisp
29 x £40,448 = £1.17M OCaml
10 x £44,000 = £0.44M F#
But the trend is the real killer: both OCaml and F# have been growing
superlinearly.
> But the presence of people wanting Lisp, and wanting to discuss its usage
> and improvement, indicates that Lisp itself is valuable.
No. Discussing something does not make it valuable.
> Further, the ability of Franz and the company selling LispWorks to sell
> products and stay in business indicates that Lisp has monetary value to
> some people.
Then why are The LispWorks still in an incubation center four years after
their incorporation? I suspect they are only sustained by external funding.
>>> If I want a critical review of my programming, I will ask for it. If I
>>> want to compare the value of Lisp with some other language, I will seek
>>> out the appropriate forum. You are doing yourself quite a disservice
>>> with your posts.
>>
>> Delusions of grandeur. In reality, Lispers are of no direct importance to
>> me at all (they are mostly unemployable). I correct their misinformation
>> as a hobby. If you don't want to be corrected, don't post here.
>
> Dr. Harrop, I see in your posts in this venue the same thing I see from
> many programming-language-theoretic people (and which drove me away from
> the subject as a research focus in pursuing my own Ph.D): an assumption
> of certain features and concepts in language design as inherent goods.
> I don't believe that the PL design space is that simple. Programming
> language design (like virtually all design) is an art of tradeoffs.
> While design decisions provide certain benefits, they generally require
> something to be sacrificed to gain those benefits. This is why the
> selection of a programming language (or other tool) requires an
> understanding of application requirements: different applications will
> be affected by the benefits and detriments of different solutions in
> different ways. For some applications, the strong type checking and
> analysis of a statically-typed FPL is a major win. I use OCaml quite
> regularly for many tasks, particularly to facilitate my research, and
> think it is an excellent language (F# may be as well, but I'm
> sufficiently disinterested in Microsoft's product offerings that I have
> not investigated it myself). I find it particularly excellent for graph
> analysis problems. It is not, however, the holy grail or silver bullet
> of programming languages. This summer, I switched a project from OCaml
> to Common Lisp because the latter mapped better to my requirements, and
> don't regret that decision at all.
What were your requirements and how did Common Lisp fill them better?
> In summary, please stop insinuating that people chosen the wrong
> language to meet their requirements simply because they happen to have
> chosen Lisp. Also, the dubious arguments made on the basis of things
> many people don't care about are simply noise -- many people, or at
> least myself, don't care how many jobs are available requiring Common
> Lisp expertise, we care that Common Lisp lets us accomplish our goals
> effectively.
You should care. The people who fill those jobs and pay their taxes are the
only reason academic positions like yours can be afforded.
> And finally, please recognize and concede that Common Lisp is not
> entirely without merit. If it were, then no rational person would
> choose to use it, and in my experience there are quite a few rational
> people on this newsgroup who have chosen to use it.
That depends what you mean by "choose to use it". I'm interested in people
embarking on serious ventures, and no rational people seem to be choosing
Lisp for that. The Hungarian government fiasco was the last one I heard.
No, the Lisp community is composed almost entirely of hobbyists dabbling
with Lisp who have never created anything of any significance. They don't
even buy the Lisp books that have been published: F# for Scientists is
already selling at 3x the rate of all Lisp books combined!
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
From: Michael Ekstrand
Subject: Re: The PL design space is not that simple
Date:
Message-ID: <878wrse1dv.fsf@elehack.net>
Jon Harrop <···@ffconsultancy.com> writes:
> Michael Ekstrand wrote:
>> Jon Harrop <···@ffconsultancy.com> writes:
>> But the presence of people wanting Lisp, and wanting to discuss its usage
>> and improvement, indicates that Lisp itself is valuable.
>
> No. Discussing something does not make it valuable.
You are correct, discussing something does not make it valuable. It
merely indicates that it is valuable (value, is a necessary condition
for discussion).
>> Further, the ability of Franz and the company selling LispWorks to sell
>> products and stay in business indicates that Lisp has monetary value to
>> some people.
>
> Then why are The LispWorks still in an incubation center four years after
> their incorporation? I suspect they are only sustained by external
> funding.
>
>>>> If I want a critical review of my programming, I will ask for it. If I
>>>> want to compare the value of Lisp with some other language, I will seek
>>>> out the appropriate forum. You are doing yourself quite a disservice
>>>> with your posts.
>>>
>>> Delusions of grandeur. In reality, Lispers are of no direct importance to
>>> me at all (they are mostly unemployable). I correct their misinformation
>>> as a hobby. If you don't want to be corrected, don't post here.
>>
>> Dr. Harrop, I see in your posts in this venue the same thing I see from
>> many programming-language-theoretic people (and which drove me away from
>> the subject as a research focus in pursuing my own Ph.D): an assumption
>> of certain features and concepts in language design as inherent goods.
>> I don't believe that the PL design space is that simple. Programming
>> language design (like virtually all design) is an art of tradeoffs.
>> While design decisions provide certain benefits, they generally require
>> something to be sacrificed to gain those benefits. This is why the
>> selection of a programming language (or other tool) requires an
>> understanding of application requirements: different applications will
>> be affected by the benefits and detriments of different solutions in
>> different ways. For some applications, the strong type checking and
>> analysis of a statically-typed FPL is a major win. I use OCaml quite
>> regularly for many tasks, particularly to facilitate my research, and
>> think it is an excellent language (F# may be as well, but I'm
>> sufficiently disinterested in Microsoft's product offerings that I have
>> not investigated it myself). I find it particularly excellent for graph
>> analysis problems. It is not, however, the holy grail or silver bullet
>> of programming languages. This summer, I switched a project from OCaml
>> to Common Lisp because the latter mapped better to my requirements, and
>> don't regret that decision at all.
>
> What were your requirements and how did Common Lisp fill them better?
One requirement is the ability to incrementally develop a layered
infrastructure with outer layers hooking back in to the lower layers to
extend functionality in various ways. Also, being able to develop and
test iteratively in small pieces. And finally, having fun, as it's a
personal project.
CLOS generics were the killer feature. I could implement extensions
(part of the project involved a simple DOM I wanted to be able to extend
with macros adding new types of DOM nodes) with ease, and hook back in
to and modify base functionality in a layered fashion. It would have
been possible to do a lot of this with OCaml objects, but doing so was
not pleasant (yes, a subjective reaction). Haskell-like type classes
would have improved the situation somewhat (yes, you can do most type
class things with objects, but I like the feel of type classes better).
Extensibility was the primary motivation for the switch. Once I
switched, being able to use SLIME to recompile single functions in a
running Lisp image and immediately test the results was a huge benefit
over the edit-compile-test cycle. Also, SLIME's in-line assistance
(completion of symbol names, argument listings, etc.) made the
development experience much more effective. Since I have been
developing the application in an experimental and incremental fashion,
it has been a great boon. My conclusion is that Common Lisp can provide
substantial benefit for applications where functionality is prototyped
and developed in a small incremental pieces, especially when the
application is a long-running process (in this case, a web application
server).
Most of the applications I use OCaml for are tools which are run (rather
than interactive process), and I usually know ahead of time what I want
them to do. But for interactive experimentation, Lisp + SLIME seems to
beat it.
>> In summary, please stop insinuating that people chosen the wrong
>> language to meet their requirements simply because they happen to have
>> chosen Lisp. Also, the dubious arguments made on the basis of things
>> many people don't care about are simply noise -- many people, or at
>> least myself, don't care how many jobs are available requiring Common
>> Lisp expertise, we care that Common Lisp lets us accomplish our goals
>> effectively.
>
> You should care. The people who fill those jobs and pay their taxes are the
> only reason academic positions like yours can be afforded.
The availability or not of jobs makes no difference to my use of Common
Lisp. And if I start looking for an industry job somewhere, the lack of
Common Lisp jobs won't be a detractor or cause me to think that my time
with Lisp has been wasted; rather, I believe that being able to think
and program competently in a wide variety of languages, including Common
Lisp, will make me a better candidate for a job using virtually any
language. And when I want to poke at things for my own pleasure, I can
still use Common Lisp.
>> And finally, please recognize and concede that Common Lisp is not
>> entirely without merit. If it were, then no rational person would
>> choose to use it, and in my experience there are quite a few rational
>> people on this newsgroup who have chosen to use it.
>
> That depends what you mean by "choose to use it". I'm interested in
> people embarking on serious ventures, and no rational people seem to
> be choosing Lisp for that. The Hungarian government fiasco was the
> last one I heard.
There's always the canonical example of Paul Graham's company in the
90's. I'm not overly well versed in the details of who's doing what
with lisp; I'm just here because I like it. Sure, a lot of people are
doing hobby things with it. So what? We find it useful, and evidently
don't consider it a waste of effort or time.
> No, the Lisp community is composed almost entirely of hobbyists
> dabbling with Lisp who have never created anything of any
> significance. They don't even buy the Lisp books that have been
> published: F# for Scientists is already selling at 3x the rate of all
> Lisp books combined!
I'm not the best one to speak on this, as my use is hobbyist. I'm just
arguing that there evidently is merit to Common Lisp and that we aren't
wasting our time. All the world isn't about making money and selling
products -- some of us program just for fun.
- Michael
--
mouse, n: A device for pointing at the xterm in which you want to type.
Confused by the strange files? I cryptographically sign my messages.
For more information see <http://www.elehack.net/resources/gpg>.
In article <··············@elehack.net>,
Michael Ekstrand <·······@elehack.net> wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
> > Michael Ekstrand wrote:
> >> Jon Harrop <···@ffconsultancy.com> writes:
> >> But the presence of people wanting Lisp, and wanting to discuss its usage
> >> and improvement, indicates that Lisp itself is valuable.
> >
> > No. Discussing something does not make it valuable.
>
> You are correct, discussing something does not make it valuable. It
> merely indicates that it is valuable (value, is a necessary condition
> for discussion).
Michael, just a hint: discussions with Mr. Harrop are a waste of time.
It has been tried before here. All he wanted was to advertise
for his business.
--
http://lispm.dyndns.org/
Michael Ekstrand <·······@elehack.net> writes:
> You are correct, discussing something does not make it valuable. It
> merely indicates that it is valuable (value, is a necessary condition
> for discussion).
The sheer volume of blather in talk.origins is indeed a powerful
indicator of the value inherent in Creationism. There is no need to
answer Harrop's silliness with such feeble arguments -- lively
discussion on some topic is an indicator of interest, not of value.
> All the world isn't about making money and selling products -- some
> of us program just for fun.
Lisp is indeed great fun, as are several other programming
languages. Type class magic in Haskell has its appeal, too, for
example.
--
Aatu Koskensilta (················@uta.fi)
"Wovon man nicht sprechen kann, darüber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
From: Brian Adkins
Subject: Re: The PL design space is not that simple (was: Re: Alternatives 4)
Date:
Message-ID: <m2od0ncz4b.fsf@gmail.com>
Jon Harrop <···@ffconsultancy.com> writes:
> I think the data speak for themselves:
>
> http://www.itjobswatch.co.uk/jobs/uk/lisp.do
> http://www.itjobswatch.co.uk/jobs/uk/ocaml.do
> http://www.itjobswatch.co.uk/jobs/uk/fsharp.do
>
> jobs x salary = value
>
> 17 x �44,971 = �0.76M Lisp
> 29 x �40,448 = �1.17M OCaml
> 10 x �44,000 = �0.44M F#
Lisp has a higher average salary and fewer programmers to compete
with? Sign me up.
Brian Adkins wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> I think the data speak for themselves:
>>
>> http://www.itjobswatch.co.uk/jobs/uk/lisp.do
>> http://www.itjobswatch.co.uk/jobs/uk/ocaml.do
>> http://www.itjobswatch.co.uk/jobs/uk/fsharp.do
>>
>> jobs x salary = value
>>
>> 17 x £44,971 = £0.76M Lisp
>> 29 x £40,448 = £1.17M OCaml
>> 10 x £44,000 = £0.44M F#
>
> Lisp has a higher average salary and fewer programmers to compete
> with? Sign me up.
No, there are a huge number of Lisp programmers but very few Lisp jobs.
If you want to earn money from Lisp you'll probably have to do what I did
with OCaml and F#, i.e. do everything yourself.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
From: Brian Adkins
Subject: Re: The PL design space is not that simple (was: Re: Alternatives 4)
Date:
Message-ID: <m263mvcwy8.fsf@gmail.com>
Jon Harrop <···@ffconsultancy.com> writes:
> If you want to earn money from Lisp you'll probably have to do what I did
> with OCaml and F#, i.e. do everything yourself.
I expect that programming languages, businesses, universities,
etc. probably feel about your endoresements/association the way McCain
felt about Bush's endorsement on SNL:
http://www.breitbart.tv/?p=204883
Brian Adkins wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> If you want to earn money from Lisp you'll probably have to do what I did
>> with OCaml and F#, i.e. do everything yourself.
>
> I expect that programming languages, businesses, universities,
> etc. probably feel about your endoresements/association the way McCain
> felt about Bush's endorsement on SNL:
>
> http://www.breitbart.tv/?p=204883
I'm endorsing capitalism.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop <···@ffconsultancy.com> wrote:
> Brian Adkins wrote:
> > Jon Harrop <···@ffconsultancy.com> writes:
> >> If you want to earn money from Lisp you'll probably have to do what I did
> >> with OCaml and F#, i.e. do everything yourself.
> >
> > I expect that programming languages, businesses, universities,
> > etc. probably feel about your endoresements/association the way McCain
> > felt about Bush's endorsement on SNL:
> >
> > http://www.breitbart.tv/?p=204883
>
> I'm endorsing capitalism.
You love money.
I love Lisp.
> Programming language design (like virtually all design) is an art of tradeoffs.
I have to write this somewhere and put it on my office door. This is so
well said!
Thank you Michael, for this insight!
From: Aatu Koskensilta
Subject: Re: The PL design space is not that simple (was: Re: Alternatives 4)
Date:
Message-ID: <87zlk0lh0i.fsf@alatheia.dsl.inet.fi>
Michael Ekstrand <·······@elehack.net> writes:
> And finally, please recognize and concede that Common Lisp is not
> entirely without merit. If it were, then no rational person would
> choose to use it, and in my experience there are quite a few rational
> people on this newsgroup who have chosen to use it.
By that argument Scientology or Objectivism are not without merit
either. If one wishes to argue for the merits of Lisp a more specific
argument is needed, establishing that the choice of those rational
people who have chosen Common Lisp as they preferred language for this
or that purpose is related to the properties of Lisp as a programming
language. Of course there is no need for anyone to justify their
choice if all they wish to do is to discuss Common Lisp -- such people
can safely set Harrop's bizarre antics aside.
--
Aatu Koskensilta (················@uta.fi)
"Wovon man nicht sprechen kann, darüber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
Aatu Koskensilta <················@uta.fi> wrote:
> Michael Ekstrand <·······@elehack.net> writes:
>
> > And finally, please recognize and concede that Common Lisp is not
> > entirely without merit. If it were, then no rational person would
> > choose to use it, and in my experience there are quite a few rational
> > people on this newsgroup who have chosen to use it.
>
> By that argument Scientology or Objectivism are not without merit
> either. If one wishes to argue for the merits of Lisp a more specific
> argument is needed, establishing that the choice of those rational
> people who have chosen Common Lisp as they preferred language for this
> or that purpose is related to the properties of Lisp as a programming
> language. Of course there is no need for anyone to justify their
> choice if all they wish to do is to discuss Common Lisp -- such people
> can safely set Harrop's bizarre antics aside.
Assumes facts not in evidence, viz. that people are rational.
····@stablecross.com (Bob Felts) writes:
> Aatu Koskensilta <················@uta.fi> wrote:
>
> > By that argument Scientology or Objectivism are not without merit
> > either. If one wishes to argue for the merits of Lisp a more
> > specific argument is needed, establishing that the choice of those
> > rational people who have chosen Common Lisp as their preferred
> > language for this or that purpose is related to the properties of
> > Lisp as a programming language. Of course there is no need for
> > anyone to justify their choice if all they wish to do is to
> > discuss Common Lisp -- such people can safely set Harrop's bizarre
> > antics aside.
>
> Assumes facts not in evidence, viz. that people are rational.
I fail to see where I have assumed people are rational.
--
Aatu Koskensilta (················@uta.fi)
"Wovon man nicht sprechen kann, darüber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
Aatu Koskensilta <················@uta.fi> wrote:
> ····@stablecross.com (Bob Felts) writes:
>
> > Aatu Koskensilta <················@uta.fi> wrote:
> >
> > > By that argument Scientology or Objectivism are not without merit
> > > either. If one wishes to argue for the merits of Lisp a more
> > > specific argument is needed, establishing that the choice of those
> > > rational people who have chosen Common Lisp as their preferred
> > > language for this or that purpose is related to the properties of
> > > Lisp as a programming language. Of course there is no need for
> > > anyone to justify their choice if all they wish to do is to
> > > discuss Common Lisp -- such people can safely set Harrop's bizarre
> > > antics aside.
> >
> > Assumes facts not in evidence, viz. that people are rational.
>
> I fail to see where I have assumed people are rational.
"... that the choice of those rational people..."
But don't let my nitpicking obscure the fact that I agree with your
argument.
····@stablecross.com (Bob Felts) writes:
> But don't let my nitpicking obscure the fact that I agree with your
> argument.
All is well then. Though the wording might suggest it it was not my
intention to imply anything about the existence or non-existence of
rational people. For purposes of the argument their existence is
immaterial.
--
Aatu Koskensilta (················@uta.fi)
"Wovon man nicht sprechen kann, darüber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
On 16 Nov 2008 17:30:29 +0200, Aatu Koskensilta
<················@uta.fi> wrote:
>····@stablecross.com (Bob Felts) writes:
>
>> But don't let my nitpicking obscure the fact that I agree with your
>> argument.
>
>All is well then. Though the wording might suggest it it was not my
>intention to imply anything about the existence or non-existence of
>rational people. For purposes of the argument their existence is
>immaterial.
"Humans are not rational, doctor ... they are rationalizing."
-- Spock
George Neuner <········@comcast.net> wrote:
> On 16 Nov 2008 17:30:29 +0200, Aatu Koskensilta
> <················@uta.fi> wrote:
>
> >····@stablecross.com (Bob Felts) writes:
> >
> >> But don't let my nitpicking obscure the fact that I agree with your
> >> argument.
> >
> >All is well then. Though the wording might suggest it it was not my
> >intention to imply anything about the existence or non-existence of
> >rational people. For purposes of the argument their existence is
> >immaterial.
>
> "Humans are not rational, doctor ... they are rationalizing."
> -- Spock
I don't think Spock said that. My memory isn't what it used to be, but
Google doesn't have anything, either.
What episode was this supposed to be from?
On Mon, 17 Nov 2008 11:18:22 -0500, ····@stablecross.com (Bob Felts)
wrote:
>George Neuner <········@comcast.net> wrote:
>
>> On 16 Nov 2008 17:30:29 +0200, Aatu Koskensilta
>> <················@uta.fi> wrote:
>>
>> >····@stablecross.com (Bob Felts) writes:
>> >
>> >> But don't let my nitpicking obscure the fact that I agree with your
>> >> argument.
>> >
>> >All is well then. Though the wording might suggest it it was not my
>> >intention to imply anything about the existence or non-existence of
>> >rational people. For purposes of the argument their existence is
>> >immaterial.
>>
>> "Humans are not rational, doctor ... they are rationalizing."
>> -- Spock
>
>I don't think Spock said that. My memory isn't what it used to be, but
>Google doesn't have anything, either.
>
>What episode was this supposed to be from?
It's from "The Man Trap", from the end of the scene where Spock and
McCoy are discussing Dr. Crater's decision to protect the creature
that killed his wife.
I'm not surprised that you can't find it ... the line has been cut
from reruns for 20 years and isn't in the remastered series either.
It is on the old VHS tapes if you can still find them.
Actually I've found a lot of subtle differences between what was aired
on TV way back when and what ends up on DVD now ... not just with Star
Trek but with many of the old shows. Frequently the DVDs use some
version of a scene that either wasn't aired or was aired in Europe but
not in the US (or vice versa). It is sometimes frustrating to watch
the DVDs because you sit there thinking "this is wrong - it didn't
happen that way". I used to timeshift television a lot (still do) and
I have boxes of tapes from the 80's and 90's. Occasionally I can pull
out one of them and prove that the DVD version is different.
George
George Neuner <········@comcast.net> wrote:
> On Mon, 17 Nov 2008 11:18:22 -0500, ····@stablecross.com (Bob Felts)
> wrote:
>
> >George Neuner <········@comcast.net> wrote:
> >
> >> On 16 Nov 2008 17:30:29 +0200, Aatu Koskensilta
> >> <················@uta.fi> wrote:
> >>
> >> >····@stablecross.com (Bob Felts) writes:
> >> >
> >> >> But don't let my nitpicking obscure the fact that I agree with your
> >> >> argument.
> >> >
> >> >All is well then. Though the wording might suggest it it was not my
> >> >intention to imply anything about the existence or non-existence of
> >> >rational people. For purposes of the argument their existence is
> >> >immaterial.
> >>
> >> "Humans are not rational, doctor ... they are rationalizing."
> >> -- Spock
> >
> >I don't think Spock said that. My memory isn't what it used to be, but
> >Google doesn't have anything, either.
> >
> >What episode was this supposed to be from?
>
> It's from "The Man Trap", from the end of the scene where Spock and
> McCoy are discussing Dr. Crater's decision to protect the creature
> that killed his wife.
>
> I'm not surprised that you can't find it ... the line has been cut
> from reruns for 20 years and isn't in the remastered series either.
> It is on the old VHS tapes if you can still find them.
>
> Actually I've found a lot of subtle differences between what was aired
> on TV way back when and what ends up on DVD now ... not just with Star
> Trek but with many of the old shows. Frequently the DVDs use some
> version of a scene that either wasn't aired or was aired in Europe but
> not in the US (or vice versa). It is sometimes frustrating to watch
> the DVDs because you sit there thinking "this is wrong - it didn't
> happen that way". I used to timeshift television a lot (still do) and
> I have boxes of tapes from the 80's and 90's. Occasionally I can pull
> out one of them and prove that the DVD version is different.
>
Well, I see that Pascal stole my "George Orwell in my Star Trek?" line.
And I remember being glued to the TV when that episode aired but, as I
was 11 at the time, I don't remember that particular line.
However, here's a bit of trivia. The "incredible salt vampire" appeared
in one other ST:TOS. Know the episode? Oh, forget it. The Wilipedia
article gives it away. Trek trivia was a lot more fun before the advent
of the intertubes.
George Neuner <········@comcast.net> writes:
> Occasionally I can pull out one of them and prove that the DVD
> version is different.
"Han shot first."
...Peder...
--
I wish a new life awaited _me_ in some off-world colony.
George Neuner <········@comcast.net> writes:
> I'm not surprised that you can't find it ... the line has been cut
> from reruns for 20 years and isn't in the remastered series either.
> It is on the old VHS tapes if you can still find them.
>
> Actually I've found a lot of subtle differences between what was aired
> on TV way back when and what ends up on DVD now ... not just with Star
> Trek but with many of the old shows. Frequently the DVDs use some
> version of a scene that either wasn't aired or was aired in Europe but
> not in the US (or vice versa). It is sometimes frustrating to watch
> the DVDs because you sit there thinking "this is wrong - it didn't
> happen that way". I used to timeshift television a lot (still do) and
> I have boxes of tapes from the 80's and 90's. Occasionally I can pull
> out one of them and prove that the DVD version is different.
>
> George
George... Orwell!
--
__Pascal Bourguignon__ http://www.informatimago.com/
ADVISORY: There is an extremely small but nonzero chance that,
through a process known as "tunneling," this product may
spontaneously disappear from its present location and reappear at
any random place in the universe, including your neighbor's
domicile. The manufacturer will not be responsible for any damages
or inconveniences that may result.
Jon Harrop wrote:
> In reality, Lispers are of no direct importance to me
> at all (they are mostly unemployable).
Cost more in a week than your measly income from F# books can afford, eh?
On Mon, 10 Nov 2008 15:18:10 +0100, Matthias Buelow wrote:
> Jon Harrop wrote:
>
>> In reality, Lispers are of no direct importance to me at all (they are
>> mostly unemployable).
>
> Cost more in a week than your measly income from F# books can afford,
> eh?
I had some idle time to pass in the library the other day, and I looked
at his F# for Scientists. It is a nice joke on those who are silly
enough to shell out $56 for a [Programming Language] for Scientists book.
I have to say that I am averse to the very idea of [Programming Language]
for Scientists books. I think that there should be books on algorithms
that people in a given profession use, and books on how to program in the
programming language. Mixing the two leads to horrible chimeras like
Press et al ("Cut and Paste Badly Written Algorithms Today! No Need to
Understand What You Are Doing!"). But JH's book is nowhere near that
advanced, it gives an intro to F#, tells you how to fight F# in your
daily life, and gives a few simple examples that could have been
implemented in any decent language just as nicely -- somehow people still
don't get the idea is that simple, well-specified algorithms are not the
hard part of programming.
The good doctor has an interesting idea about what scientists do, he
thinks it is mostly gluing others' code together. Inject values into
Excel! Use .NET to glue together Mathematica, Matlab and of course
Excel, the ultimate scientific tool. [1] Fourier transform is a showcase
for him (as we have noticed on c.l.l many times), the guy still hasn't
realized that FFT is something like linear solvers: it has been
standardized, implemented and packaged into libraries, the challenge is
not here, move along. Chapter 12 contains some other examples, but none
of them are particularly complex, the whole chapter is 21 pages.
I have to admit that I was interested in F# before browsing through his
book (because I like Haskell), but now I would not touch it with a 10
foot pole. If I ever wanted that inimitable pain in the rear end from
fast Bondage & Discipline language, I would just turn to the latest
Fortran incarnations: it would cut my runtime by about 60% and increase
my development time about tenfold, a considerable net loss. Apart from
the .NET glue, the book presents no convincing case for F# as compared to
other functional or non-functional languages.
Maybe I will polish this up and post it on Amazon :-)
Tamas
[1] http://www.burns-stat.com/pages/Tutor/spreadsheet_addiction.html
On 10 Nov, 16:29, Tamas K Papp <······@gmail.com> wrote:
> [..]
> Maybe I will polish this up and post it on Amazon :-)
Please do!
Never seen a more convincing posting revealing such a pseudo
scientist...
-PM
Tamas K Papp wrote:
> On Mon, 10 Nov 2008 15:18:10 +0100, Matthias Buelow wrote:
>> Jon Harrop wrote:
>>> In reality, Lispers are of no direct importance to me at all (they are
>>> mostly unemployable).
>>
>> Cost more in a week than your measly income from F# books can afford,
>> eh?
>
> I had some idle time to pass in the library the other day, and I looked
> at his F# for Scientists. It is a nice joke on those who are silly
> enough to shell out $56 for a [Programming Language] for Scientists book.
Damn. I forgot to target the Hungarian economics student market.
> Chapter 12 contains some other examples, but none of them are particularly
> complex, the whole chapter is 21 pages.
Err, chapter 12 is pages 281-309 inclusive.
F# for Scientists received its other negative review from Sal Mangano. You
may appreciate his review a non-scientist who has also started by never
finished a degree and probably also has difficulty counting:
http://semanticvector.blogspot.com/2008/08/f-for-scientists-misses-boat-on.html
> Maybe I will polish this up and post it on Amazon :-)
Be sure to give F# for Scientists 5 stars just like the four other reviews
(by accomplished people).
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 2008-11-09 11:29:40 -0500, flappy the flyeater <······@cloaca.com> said:
> In other words, you would rather your assertions were accepted without
> question.
No, oh airborne amphibious one.
We would rather that you be true to your name and,
Moistly slip the surly bonds of earth,
To soar beyond the swamp that saw your birth,
Here, straining forth, your froggy lips may kiss,
the hairy, lambda crusted arse of Lisp
Raffael Cavallaro wrote:
> On 2008-11-09 11:29:40 -0500, flappy the flyeater <······@cloaca.com> said:
>
>> In other words, you would rather your assertions were accepted without
>> question.
>
>
> No, oh airborne amphibious one.
> We would rather that you be true to your name and,
>
>
> Moistly slip the surly bonds of earth,
> To soar beyond the swamp that saw your birth,
> Here, straining forth, your froggy lips may kiss,
> the hairy, lambda crusted arse of Lisp
>
You are on a frickin roll, dude. Post on, Raffy! Post on!
kzo
On 2008-11-09 14:49:12 -0500, Kenny <·········@gmail.com> said:
> You are on a frickin roll, dude. Post on, Raffy! Post on!
<blush>
what can i say - a gift for doggerel runs in my family. no real poetry
mind you, just doggerel...
;^)
On Nov 9, 11:29 am, Jon Harrop <····@ffconsultancy.com> wrote:
> ···············@gmail.com wrote:
> > On Nov 7, 9:17 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> >> ···············@gmail.com wrote:
> >> > That being said, one is reminded of the story of the man who visited a
> >> > museum of modern art and remarked to the guard "I don't see what is so
> >> > special about this art," to which the guard responded "The value of
> >> > these artworks is no longer a matter for debate. It is not the works
> >> > that are being judged, but you."
>
> >> Yes, of course. Contrary to popular perceptions, Lisp is actually a
> >> mainstream language and has proven its worth time and time again. The
> >> value of Lisp is no longer a matter for debate. Nobody can escape the
> >> runaway success that is Lisp.
>
> > I fail to see how anything in my post could be construed as claiming
> > that Lisp is a mainstream language.
>
> You implied that Lisp's value is not a matter for debate.
Again, I fail to see how I made this implication. I apologize for your
inability to comprehend my post.
> > Perhaps, for the sake of Ph.D.'s more interested in trolling than
> > thinking, I should clarify: my point was only that the opinion
> > expressed in Mr. James' post says much more about Mr. James than it
> > does about _On Lisp_.
>
> > Likewise, the apparent need for a distinguished F# consultant to visit
> > a Lisp forum for the purpose of trashing Lisp's "mainstream" status
> > and performance in web search statistics says a great deal about the
> > state of F#, F# consultancy, and the amount of time that F#
> > consultants spend making sure their web address ends up in
> > comp.lang.lisp archives, but says very little about the state of Lisp.
>
> In other words, you would rather your assertions were accepted without
> question.
>
In other words, you would prefer to respond what you think you read as
opposed to what people actually write.
I did not intend to make, nor do I believe I made, any assertion about
the Lisp language. Again, I meant only to express what I felt was the
unfounded nature of Mr James's opinion of a particular book, because
Mr. James's original post indicated to me he had missed the point of
the book entirely.
Whether one person appreciates or understands a book about Lisp does
not necessarily have much to do with the current success of Lisp as a
"mainstream" programming language.
On Nov 7, 1:39 am, William James <·········@yahoo.com> wrote:
> I don't see what's so great about Paul Graham's
> On Lisp.
Huh? You criticize a book by translating some of the
contained source code into another programming language?
I don't get it... :/
Leslie P. Polzer wrote:
> On Nov 7, 1:39 am, William James <·········@yahoo.com> wrote:
>> I don't see what's so great about Paul Graham's
>> On Lisp.
>
> Huh? You criticize a book by translating some of the
> contained source code into another programming language?
>
> I don't get it... :/
If the most compelling examples of Lisp are more easily written in other
languages, what is the value of Lisp?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Nov 11, 4:46 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Leslie P. Polzer wrote:
> > On Nov 7, 1:39 am, William James <·········@yahoo.com> wrote:
> >> I don't see what's so great about Paul Graham's
> >> On Lisp.
>
> > Huh? You criticize a book by translating some of the
> > contained source code into another programming language?
>
> > I don't get it... :/
>
> If the most compelling examples of Lisp are more easily written in other
> languages, what is the value of Lisp?
The value is 42, checked it with the REPL.
blandest wrote:
> On Nov 11, 4:46 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> Leslie P. Polzer wrote:
>> > On Nov 7, 1:39 am, William James <·········@yahoo.com> wrote:
>> >> I don't see what's so great about Paul Graham's
>> >> On Lisp.
>>
>> > Huh? You criticize a book by translating some of the
>> > contained source code into another programming language?
>>
>> > I don't get it... :/
>>
>> If the most compelling examples of Lisp are more easily written in other
>> languages, what is the value of Lisp?
>
> The value is 42, checked it with the REPL.
I bet you went through all the inefficiency of arbitrary precision integer
arithmetic to get there and, even then, you're not really sure that's an
int.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Nov 11, 9:46 am, Jon Harrop <····@ffconsultancy.com> wrote:
> Leslie P. Polzer wrote:
> > On Nov 7, 1:39 am, William James <·········@yahoo.com> wrote:
> >> I don't see what's so great about Paul Graham's
> >> On Lisp.
>
> > Huh? You criticize a book by translating some of the
> > contained source code into another programming language?
>
> > I don't get it... :/
>
> If the most compelling examples of Lisp are more easily written in other
> languages, what is the value of Lisp?
>
Mr. James does not demonstrate the ability to tell which examples are
"most compelling." Nor do you.
Which is where I came into the conversation.
On 2008-11-11, Jon Harrop <···@ffconsultancy.com> wrote:
> Leslie P. Polzer wrote:
>> On Nov 7, 1:39�am, William James <·········@yahoo.com> wrote:
>>> I don't see what's so great about Paul Graham's
>>> On Lisp.
>>
>> Huh? You criticize a book by translating some of the
>> contained source code into another programming language?
>>
>> I don't get it... :/
>
> If the most compelling examples of Lisp are more easily written in other
> languages, what is the value of Lisp?
Ironically, in this thread, people have shown that the ``compelling'' examples
of Graham's dialect of Lisp are much more nicely expressed in Common Lisp.
William James schrieb:
> I don't see what's so great about Paul Graham's
> On Lisp.
Let�s see:
CL:
(defun before (x y lst &key (test #'eql))
(and lst
(let ((first (car lst)))
(cond ((funcall test y first) nil)
((funcall test x first) lst)
(t (before x y (cdr lst) :test test))))))
Ruby:
def before x, y, list, &block
block = proc{|a,b| a==b} if not block
list.each_with_index{|thing,i|
return nil if block.call(y,thing)
return list[i..-1] if block.call(x,thing) }
nil
end
Clojure:
(defn before
([x y [f & r :as lst]] (before x y lst =))
([x y [f & r :as lst] test]
(and lst
(cond (test y f) ()
(test x f) lst
:else (recur x y r test)))))
That�s 6 lines for CL, 7 for Ruby and 7 for Clojure.
The length in bytes of each, when leading whitespace in each line is
removed:
CL: 181 chars, Ruby: 187 chars, Clojure: 157 chars
CL: -- (member)
Ruby:
def member obj, list
if block_given?
where = nil
list.each_with_index{|elt,i| break(where=i) if yield(obj,elt) }
else
where = list.index( obj )
end
where and list[where..-1]
end
Clojure: -- (drop-with)
CL: 0 loc and 0 chars, Ruby 9 loc and 177 chars, Clojure: 0 loc and 0 chars.
CL:
(defun after (x y lst &key (test #'eql))
(let ((rest (before y x lst :test test)))
(and rest (member x rest :test test))))
Ruby:
def after x, y, list, &block
rest = before( y, x, list, &block ) and
member( x, list, &block )
end
Clojure:
(defn after
([x y lst] (after x y lst =))
([x y lst test]
(let [rest (before y x lst test)]
(and rest (drop-while #(test x %) rest)))))
CL: 3loc/122chars, Ruby: 4loc/98chars, Clojure: 5loc/135chars
CL:
(defun duplicate (obj lst &key (test #'eql))
(member obj (cdr (member obj lst :test test))
:test test))
Ruby:
def duplicate obj, list, &block
rest = member( obj, list, &block ) and
member( obj, rest[1..-1], &block )
end
Clojure:
(defn duplicate [obj lst test]
(drop-while #(test obj %)
(rest (drop-while #(test obj %) lst))))
CL: 3loc/103chars, Ruby: 4loc/109chars, Clojure: 3loc/96 chars
CL:
(defun split-if (fn lst)
(let ((acc nil))
(do ((src lst (cdr src)))
((or (null src) (funcall fn (car src)))
(values (nreverse acc) src))
(push (car src) acc))))
Ruby:
def split_if list
flag = false
list.partition{|x| flag or flag=yield(x) }.reverse
end
Clojure: --
CL: 6loc/160loc, Ruby: 4loc/85chars, Clojure: 0loc/0chars.
Complete:
CL: 18 LOC / 566 chars
Ruby: 28 LOC / 656 chars
Clojure: 14 LOC / 388 chars.
Overall winner is: Clojure.
Second place: Common Lisp.
Loser: Ruby.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org
On Nov 11, 9:10 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> William James schrieb:
> Complete:
> CL: 18 LOC / 566 chars
> Ruby: 28 LOC / 656 chars
> Clojure: 14 LOC / 388 chars.
>
> Overall winner is: Clojure.
> Second place: Common Lisp.
> Loser: Ruby.
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org
wow this is key argument ... i dont know why Rich Hickey skip this at
the Boston Lisp meeting presentation ... you should send him this to
put on clojure.org
On Tue, 11 Nov 2008 21:10:11 +0100, André Thieme wrote:
> CL: 18 LOC / 566 chars
> Ruby: 28 LOC / 656 chars
> Clojure: 14 LOC / 388 chars.
Sorry, but this is silly. Counting characters/lines in simplistic code
snippets is not a relevant statistic. The ease of managing medium-sized
or large projects is what matters - people who are arguing over whose <20
line code snippet is more compact are missing the point.
Tamas
On 2008-11-11, Tamas K Papp <······@gmail.com> wrote:
> On Tue, 11 Nov 2008 21:10:11 +0100, Andr� Thieme wrote:
>
>> CL: 18 LOC / 566 chars
>> Ruby: 28 LOC / 656 chars
>> Clojure: 14 LOC / 388 chars.
>
> Sorry, but this is silly. Counting characters/lines in simplistic code
> snippets is not a relevant statistic.
It's highly relevant to programming language academics, but irrelevant
to software developers.
> The ease of managing medium-sized
> or large projects is what matters - people who are arguing over whose <20
> line code snippet is more compact are missing the point.
If you haven't actually been on such a project, you won't get the point.
To have the full maturity, you must have not only participated in a big
project, but actually started, led and finished one.
People who have never been in a team lead role in a large software project,
which they saw through from the beginning to the end, have no business
commenting on programming languages, let alone designing them.
Kaz Kylheku wrote:
>> Sorry, but this is silly. Counting characters/lines in simplistic code
>> snippets is not a relevant statistic.
> It's highly relevant to programming language academics, but irrelevant
> to software developers.
I agree with Kaz here in part, and I'd like to expand on this point.
I just want to point out that at the end of the road (for terseness)
you get a syntax like line noise. (Yes, I actually remember line noise.
Be quiet.) It's not something to strive for. If you want terse, you
can do it with a highly context-sensitive language that has a lot of
one-character operators, a lot of special cases, and a baroque system
of short pronouns. But (with all due respect to Larry Wall) most
people don't want to program in that language.
You can make lisp code terser, for example, by using an open square
brace for two open-parens and a closing square brace for three close-
parens. This is "optimal" in some way because you practically never
have sequences of three open parens, and if you use a closing brace
for two close parens it doesn't save as much.
But it's wrongheaded, because the break in symmetry doesn't reflect
the way programmers actually think.
>> The ease of managing medium-sized
>> or large projects is what matters - people who are arguing over whose <20
>> line code snippet is more compact are missing the point.
Here I disagree. There's room in the universe for a lot of different
programming languages, because firstly people do think differently
and secondly the idea of "what matters," here expressed so strongly,
is actually quite variable. Sometimes what matters is all about
managing teams in medium-sized or large projects. Sometimes what
matters is something else.
> People who have never been in a team lead role in a large software
> project, which they saw through from the beginning to the end, have no
> business commenting on programming languages, let alone designing them.
Here I disagree more strongly. Designing, implementing, and using
new programming languages sharpens your insight and skills, and is
worth doing for that reason alone. Also, not every language is to
be measured on the same yardstick of being most useful for teams of
programmers working on medium-sized or large projects. There are a
lot of small projects done by individuals, and they are as worthy of
support as larger ones. There are also computing devices and
environments with unusual capabilities not well modeled by
mainstream languages, and even programmers whose methods of thought
are not well modeled by those languages. If the frustrations grow
large enough, then a new language may be exactly the thing that's
needed.
Bear
Kaz Kylheku wrote:
> People who have never been in a team lead role in a large software project,
> which they saw through from the beginning to the end, have no business
> commenting on programming languages, let alone designing them.
C vs. C++, Lisp vs. Java, ...?
I think I prefer the amateur stuff, then.
Kaz Kylheku wrote:
> On 2008-11-11, Tamas K Papp <······@gmail.com> wrote:
>> On Tue, 11 Nov 2008 21:10:11 +0100, André Thieme wrote:
>>
>>> CL: 18 LOC / 566 chars
>>> Ruby: 28 LOC / 656 chars
>>> Clojure: 14 LOC / 388 chars.
>>
>> Sorry, but this is silly. Counting characters/lines in simplistic code
>> snippets is not a relevant statistic.
>
> It's highly relevant to programming language academics, but irrelevant
> to software developers.
If you want to convince decision makers in industry then you'll need it to
fit on a slide.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Tamas K Papp schrieb:
> On Tue, 11 Nov 2008 21:10:11 +0100, André Thieme wrote:
>
>> CL: 18 LOC / 566 chars
>> Ruby: 28 LOC / 656 chars
>> Clojure: 14 LOC / 388 chars.
>
> Sorry, but this is silly. Counting characters/lines in simplistic code
> snippets is not a relevant statistic. The ease of managing medium-sized
> or large projects is what matters - people who are arguing over whose <20
> line code snippet is more compact are missing the point.
Well, it is a relevant statistic if people are interested in writing
short code snippets. This is probably not what you are interested in.
Others are. Please don’t tell them if this is realistic or not.
Instead of complains I hope to see from you statistics about medium-
sized or large projects soon.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Andr� Thieme <······························@justmail.de> wrote:
> Tamas K Papp schrieb:
> > On Tue, 11 Nov 2008 21:10:11 +0100, Andr� Thieme wrote:
> >
> >> CL: 18 LOC / 566 chars
> >> Ruby: 28 LOC / 656 chars
> >> Clojure: 14 LOC / 388 chars.
> >
> > Sorry, but this is silly. Counting characters/lines in simplistic code
> > snippets is not a relevant statistic. The ease of managing medium-sized
> > or large projects is what matters - people who are arguing over whose <20
> > line code snippet is more compact are missing the point.
>
> Well, it is a relevant statistic if people are interested in writing
> short code snippets.
Where's the comparison w/ APL?
On Tue, 11 Nov 2008 19:36:14 -0500, ····@stablecross.com (Bob Felts)
wrote:
>Andr� Thieme <······························@justmail.de> wrote:
>
>> Tamas K Papp schrieb:
>> > On Tue, 11 Nov 2008 21:10:11 +0100, Andr� Thieme wrote:
>> >
>> >> CL: 18 LOC / 566 chars
>> >> Ruby: 28 LOC / 656 chars
>> >> Clojure: 14 LOC / 388 chars.
>> >
>> > Sorry, but this is silly. Counting characters/lines in simplistic code
>> > snippets is not a relevant statistic. The ease of managing medium-sized
>> > or large projects is what matters - people who are arguing over whose <20
>> > line code snippet is more compact are missing the point.
>>
>> Well, it is a relevant statistic if people are interested in writing
>> short code snippets.
>
>Where's the comparison w/ APL?
APL is too verbose. Where's the comparison with BrainFuck.
George Neuner <········@comcast.net> wrote:
> On Tue, 11 Nov 2008 19:36:14 -0500, ····@stablecross.com (Bob Felts)
> wrote:
>
> >Andr� Thieme <······························@justmail.de> wrote:
> >
> >> Tamas K Papp schrieb:
> >> > On Tue, 11 Nov 2008 21:10:11 +0100, Andr� Thieme wrote:
> >> >
> >> >> CL: 18 LOC / 566 chars
> >> >> Ruby: 28 LOC / 656 chars
> >> >> Clojure: 14 LOC / 388 chars.
> >> >
> >> > Sorry, but this is silly. Counting characters/lines in simplistic code
> >> > snippets is not a relevant statistic. The ease of managing medium-sized
> >> > or large projects is what matters - people who are arguing over whose <20
> >> > line code snippet is more compact are missing the point.
> >>
> >> Well, it is a relevant statistic if people are interested in writing
> >> short code snippets.
> >
> >Where's the comparison w/ APL?
>
> APL is too verbose. Where's the comparison with BrainFuck.
Well, since languages are being compared, let's take a look at the site
"99 Bottles of Beer" (http://99-bottles-of-beer.net), which features
programs in 1,233 programming languages/variations which print out the
lyrics to the song "99 bottles of beer".
Here's the F# version
(http://99-bottles-of-beer.net/language-fsharp-1348.html):
------------------------------------------------------------------------
#light
open System
open System.Text
open System.Drawing
open System.Windows.Forms
let theBottleSong =
let strSong = new StringBuilder()
let append (s:string) = strSong.Append(s) |> ignore
for i = 99 downto 0 do
if (i = 0) then
append("\nNo more bottles of beer on the wall, no more bottles
of beer." +
"\nGo to the store and buy some more, 99 bottles of beer
on the wall.")
else
let x = i - 1
let plural = if (i = 1) then "" else "s"
append (sprintf "\n%d bottle%s of beer on the wall, %d
bottle%s" i plural i plural);
append "\nTake one down and pass it around, ";
match x with
| 1 -> append "1 bottle "
| 0 -> append " no more bottles "
| _ -> append (sprintf "%d bottles of beer on the wall.\n" x)
strSong.ToString()
let form = new Form(Width=500, Height=420,
Visible=true, TopMost=true,
FormBorderStyle=FormBorderStyle.FixedSingle,
Text="99 bottles of beer presented in F#")
let textBox = new RichTextBox(Size=new Size(480, 350),
Location=new Point(5, 5),
Text=theBottleSong)
form.Controls.Add(textBox)
let btnClose = new Button(Location=new Point(408, 360), Text="Close")
btnClose.Click.Add (fun _ -> form.Close())
form.Controls.Add(btnClose)
[<STAThread>]
do Application.Run(form)
------------------------------------------------------------------------
Here's one Lisp version (look at it in a monospaced font):
(defun bottle-song (&optional (in-stock 99) (stream *standard-output*))
;; Original idea and primary coding by Geoff Summerhayes
;; <sumrnot @hotmail.com>
;; Formatting idea by Fred Gilham <gilham @snapdragon.csl.sri.com>
;; Actual formatting & minor recoding by Kent M Pitman
;; <pitman @world.std.com>
(format
stream
"-----~2%~
~{~&~1&~
~[~^~:;~
·····@(~
~R~) bo~
ttle~:P o~
f beer on t~
he wall~01:*~[.~
~:;,·······@(~R~
~) bottle~:*~P ~
of beer.~%You t~
ake one down, p~
ass it around, ~
~01%~[*No* more~
·········@(~R~)~
~] bottle~:*~P ~
of beer on the ~
wall.~2&-----~%~
~1%~:*~]~]~}~0%"
(loop for bottle from in-stock downto 0 collect bottle)))
------------------------------------------------------------------------
There's simply no comparison. Lisp wins hands down for simplicity,
elegance, and beauty.
F# is just another pedestrian programming language. Lisp is an artists
easel, canvass, palette, and brush all in one.
Bob Felts wrote:
> There's simply no comparison...
Indeed. The F# is a self-contained GUI app whereas the Lisp is an incomplete
console app. Moreover, they don't print the same answer.
> Lisp is...
...not good for GUI programming?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop schrieb:
> Bob Felts wrote:
>> There's simply no comparison...
>
> Indeed. The F# is a self-contained GUI app whereas the Lisp is an incomplete
> console app. Moreover, they don't print the same answer.
>
>> Lisp is...
>
> ...not good for GUI programming?
Fair question, and the answer is: �No, Lisp is good for GUI programming�.
You can program for example with Swing or QT, you can use the most
modern GUI builders, etc.
Your applications can simply run with a mouse click on a website.
If you want an example look at this:
http://dist.trolltech.com/developer/download/webstart/
Any pain of GUI programming that one has in (say) Java or C# go away
in Clojure.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
André Thieme wrote:
> Jon Harrop schrieb:
>> Bob Felts wrote:
>>> Lisp is...
>>
>> ...not good for GUI programming?
>
> Fair question, and the answer is: „No, Lisp is good for GUI programming”.
> You can program for example with Swing or QT, you can use the most
> modern GUI builders, etc.
> Your applications can simply run with a mouse click on a website.
> If you want an example look at this:
> http://dist.trolltech.com/developer/download/webstart/
> Any pain of GUI programming that one has in (say) Java or C# go away
> in Clojure.
Ah, in Clojure I can well believe that. I was referring to CL.
Yes, I think Clojure has real potential. Not for my line of work but people
on the JVM obviously value dynamic languages (Groovy, JRuby, Jython etc.)
and, in that remit, I don't think you will get much better than Clojure.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Clearly we should all use visual basic!
Google fight tells me that it is used for building GUIs far more than
F# is.
http://www.googlefight.com/index.php?lang=en_GB&word1=vb+gui&word2=F%23+gui
On a serious note, why do people on these boards count characters so
much?
I can touch type, I have copy-paste, and I have grep.
I write my programs as verbosely as possible (it makes documentation
easier, and when i go back after wards I (and others!) can figure out
what I was doing...)
Solution:
Take a basic keyboarding class?
················@gmail.com wrote:
> Clearly we should all use visual basic!
>
> Google fight tells me that it is used for building GUIs far more than
> F# is.
>
http://www.googlefight.com/index.php?lang=en_GB&word1=vb+gui&word2=F%23+gui
I can well believe that.
> On a serious note, why do people on these boards count characters so
> much?
> I can touch type, I have copy-paste, and I have grep.
>
> I write my programs as verbosely as possible (it makes documentation
> easier, and when i go back after wards I (and others!) can figure out
> what I was doing...)
>
> Solution:
> Take a basic keyboarding class?
That won't reduce the amount of code you have to read.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Nov 14, 12:05 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> ················@gmail.com wrote:
> > Clearly we should all use visual basic!
>
> > Google fight tells me that it is used for building GUIs far more than
> > F# is.
>
> http://www.googlefight.com/index.php?lang=en_GB&word1=vb+gui&word2=F%...
>
> I can well believe that.
>
> > On a serious note, why do people on these boards count characters so
> > much?
> > I can touch type, I have copy-paste, and I have grep.
>
> > I write my programs as verbosely as possible (it makes documentation
> > easier, and when i go back after wards I (and others!) can figure out
> > what I was doing...)
>
> > Solution:
> > Take a basic keyboarding class?
>
> That won't reduce the amount of code you have to read.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u
Right, but it might reduce the time it takes me to read and comprehend
the code?
(Something that low character count would have an adverse effect on).
If i can skim through the functions and get the gist of what each does
by function name, it seems to be a greater return on my extra typing
investment when I get into the debug-compile-test phase (as that is
where most programming time is spent?).
Obviously this isn't an argument for or against any language, if we
tried to argue which language has the best semantics in terms
readability, we'd get into all sorts of 'angels on the head of a pin'
arguments... as readability is difficult (perhaps impossible) to
measure.
On Fri, 14 Nov 2008 08:58:43 -0800, JonathanSmith415 wrote:
>> > On a serious note, why do people on these boards count characters so
>> > much?
>> > I can touch type, I have copy-paste, and I have grep.
In case you are using SLIME, you also have slime-complete-symbol, slime-
complete-form (usually bound to C-i and C-s) and other nifty tools. I
imagine other Lisp IDEs have similar things.
>> > I write my programs as verbosely as possible (it makes documentation
>> > easier, and when i go back after wards I (and others!) can figure out
>> > what I was doing...)
>>
>> That won't reduce the amount of code you have to read.
>
> Right, but it might reduce the time it takes me to read and comprehend
> the code?
> (Something that low character count would have an adverse effect on).
Indeed. Thanks for exposing how clueless the Good Doctor is.
The habit if keeping variable and function names short stems from the
times of early Fortran where people had to save precious punchcard space.
In contemporary practice, people use short names because line breaks
present a problem. Where do you break this piece of C code, for example?
really_long_variable_name = verbose_function_name(argument_name_that_just_goes_on_and_on, another_bloody_argument);
Lisp has no such constraint and handles the line breaks very nicely, so
the issue is moot. If some other language doesn't, it just sucks, tough
luck.
I really hate reading code where the author thought it would be a good
idea to use many short variable names. Fortran77 is a prime example of
that, 3-page functions with variable names like BX, KCQ and KCH take a
lot of time to decipher even for veteran Fortran programmers.
Anyhow Jonathan, you really are a good Samaritan to engage in this
discussion with JH. Consulting mustn't be going that well, he is bored,
but he doesn't have the expertise to talk about anything really deep, so
he picks on the length of variable names. If you get bored with him but
still have the urge to do good, help out at an animal shelter, cats and
dogs are much better companions than JH.
Best,
Tamas
Tamas K Papp <······@gmail.com> wrote:
+---------------
| In contemporary practice, people use short names because line breaks
| present a problem. Where do you break this piece of C code, for example?
|
| really_long_variable_name =
| verbose_function_name(argument_name_that_just_goes_on_and_on,
| another_bloody_argument);
+---------------
I would write it as:
really_long_variable_name =
verbose_function_name(argument_name_that_just_goes_on_and_on,
another_bloody_argument);
or in extremis, with *really* long names:
really_long_variable_name =
verbose_function_name(
argument_name_that_just_goes_on_and_on,
another_bloody_argument);
But then, these days I tend to use Lisp indentation when writing C. ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
················@gmail.com wrote:
> On Nov 14, 12:05 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> ················@gmail.com wrote:
>> > I write my programs as verbosely as possible (it makes documentation
>> > easier, and when i go back after wards I (and others!) can figure out
>> > what I was doing...)
>>
>> That won't reduce the amount of code you have to read.
>
> Right, but it might reduce the time it takes me to read and comprehend
> the code?
I believe the opposite but we only have anecdotal evidence. Look at this
comparison, for example:
http://schwarzwald.infogami.com/blog/lispocaml
> (Something that low character count would have an adverse effect on).
I don't believe that. I personally find it much harder to read code that
uses extremely verbose identifiers (let alone inherently verbose
languages).
> If i can skim through the functions and get the gist of what each does
> by function name, it seems to be a greater return on my extra typing
> investment when I get into the debug-compile-test phase (as that is
> where most programming time is spent?).
No. Programmers only spend a significant amount of time debugging when they
don't have a modern static type system.
For example, OCaml has a sophisticated "time travel" debugger but I've never
used it in four years of writing commercial OCaml code. I simply have no
use for a debugger any more.
> Obviously this isn't an argument for or against any language, if we
> tried to argue which language has the best semantics in terms
> readability, we'd get into all sorts of 'angels on the head of a pin'
> arguments... as readability is difficult (perhaps impossible) to
> measure.
Languages are still highly relevant to this though. For example, you can
often tell what an OCaml or F# function does by looking at its type
signature. In OCaml and F#, the compiler infers function signatures
automatically. In Lisp, the compiler cannot. So the OCaml and F# languages
give you a lot more information to go on by design. Moreover, modern
development environments like F#'s Visual Studio mode give you interactive
graphical throwback of inferred types and documentation.
Perhaps you cannot measure readability but we can certainly measure
development speed:
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/590f20047a9a81fc?hl=en&ie=UTF-8&q=development++concentration+ocaml+lisp
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Nov 14, 2:42 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> ················@gmail.com wrote:
> > On Nov 14, 12:05 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> >> ················@gmail.com wrote:
> >> > I write my programs as verbosely as possible (it makes documentation
> >> > easier, and when i go back after wards I (and others!) can figure out
> >> > what I was doing...)
>
> >> That won't reduce the amount of code you have to read.
>
> > Right, but it might reduce the time it takes me to read and comprehend
> > the code?
>
> I believe the opposite but we only have anecdotal evidence. Look at this
> comparison, for example:
>
> http://schwarzwald.infogami.com/blog/lispocaml
>
The lisp can be rewritten as a 3 liner in that example,
however I will admit it wouldn't be as optimized.
This does show something interesting about lisp, however.
What you have there is a hand rolled version of Ocaml's int_of_string
function in the flet.
This inadvertently show's one of lisp's powers...
You can feasibly work at either a very high level or a very low level.
(Optimize what you need to).
It could be just as easily done with (read-from-string (read-line
*standard-input* nil "nil")).
> > (Something that low character count would have an adverse effect on).
>
> I don't believe that. I personally find it much harder to read code that
> uses extremely verbose identifiers (let alone inherently verbose
> languages).
>
It is a very subjective claim either way.
> > If i can skim through the functions and get the gist of what each does
> > by function name, it seems to be a greater return on my extra typing
> > investment when I get into the debug-compile-test phase (as that is
> > where most programming time is spent?).
>
> No. Programmers only spend a significant amount of time debugging when they
> don't have a modern static type system.
>
Honestly I keep track of typing pretty well in my head (remembering
lisp is dynamically typed),
it is second nature at this point...
What I worry about more are logic errors that effect the actual
behavior of the program.
Until someone writes a mind-reading IDE, I doubt very much that that
type of bug will be eliminated...
> For example, OCaml has a sophisticated "time travel" debugger but I've never
> used it in four years of writing commercial OCaml code. I simply have no
> use for a debugger any more.
>
> > Obviously this isn't an argument for or against any language, if we
> > tried to argue which language has the best semantics in terms
> > readability, we'd get into all sorts of 'angels on the head of a pin'
> > arguments... as readability is difficult (perhaps impossible) to
> > measure.
>
> Languages are still highly relevant to this though. For example, you can
> often tell what an OCaml or F# function does by looking at its type
> signature. In OCaml and F#, the compiler infers function signatures
> automatically. In Lisp, the compiler cannot. So the OCaml and F# languages
> give you a lot more information to go on by design. Moreover, modern
> development environments like F#'s Visual Studio mode give you interactive
> graphical throwback of inferred types and documentation.
>
I don't know enough about F# or Ocaml to disagree with you,
however I will say it would be cool to have access to a visual studio-
like environment for lisp.
> Perhaps you cannot measure readability but we can certainly measure
> development speed:
>
> http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/59...
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u
Fortunately for me, I'm extremely productive in lisp. :)
················@gmail.com wrote:
> On Nov 14, 2:42 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> http://schwarzwald.infogami.com/blog/lispocaml
>
> The lisp can be rewritten as a 3 liner in that example,
> however I will admit it wouldn't be as optimized.
>
> This does show something interesting about lisp, however.
> What you have there is a hand rolled version of Ocaml's int_of_string
> function in the flet.
> This inadvertently show's one of lisp's powers...
> You can feasibly work at either a very high level or a very low level.
> (Optimize what you need to).
> It could be just as easily done with (read-from-string (read-line
> *standard-input* nil "nil")).
And the OCaml code demonstrates how other languages can provide both
performance and brevity at the same time, which is the power of OCaml.
>> I don't believe that. I personally find it much harder to read code that
>> uses extremely verbose identifiers (let alone inherently verbose
>> languages).
>
> It is a very subjective claim either way.
I'd have thought there would be good agreement in some cases though. Pattern
matching is an obvious example where convention dictates the use of:
h::t
or:
x::xs
instead of:
the_first_element :: the_remaining_elements
The reason being that pattern matching lets you reflect the structure of a
data structure in your code but that is impossible to read if you use long
identifiers.
>> > If i can skim through the functions and get the gist of what each does
>> > by function name, it seems to be a greater return on my extra typing
>> > investment when I get into the debug-compile-test phase (as that is
>> > where most programming time is spent?).
>>
>> No. Programmers only spend a significant amount of time debugging when
>> they don't have a modern static type system.
>
> Honestly I keep track of typing pretty well in my head (remembering
> lisp is dynamically typed), it is second nature at this point...
With >1 programmer, that breaks down.
Inferred types are also very useful when teaching.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
# let d f x =
let eps = sqrt epsilon_float in
((f (x +. eps)) -. (f (x -. eps))) /. (2. *. eps);;
val d : (float -> float) -> float -> float = <fun>
The inferred type immediately tells you that this is a higher-order "d"
function, "f" is its function argument etc.
You might say that documentation achieves the same effect in Lisp but it is
not machine verified and it does not compose. For example, the type of the
following expression immediately tells us that it is also a combinator:
# nest 3 d;;
- : (float -> float) -> float -> float = <fun>
> What I worry about more are logic errors that effect the actual
> behavior of the program.
> Until someone writes a mind-reading IDE, I doubt very much that that
> type of bug will be eliminated...
Sure.
>> For example, OCaml has a sophisticated "time travel" debugger but I've
>> never used it in four years of writing commercial OCaml code. I simply
>> have no use for a debugger any more.
>>
>> > Obviously this isn't an argument for or against any language, if we
>> > tried to argue which language has the best semantics in terms
>> > readability, we'd get into all sorts of 'angels on the head of a pin'
>> > arguments... as readability is difficult (perhaps impossible) to
>> > measure.
>>
>> Languages are still highly relevant to this though. For example, you can
>> often tell what an OCaml or F# function does by looking at its type
>> signature. In OCaml and F#, the compiler infers function signatures
>> automatically. In Lisp, the compiler cannot. So the OCaml and F#
>> languages give you a lot more information to go on by design. Moreover,
>> modern development environments like F#'s Visual Studio mode give you
>> interactive graphical throwback of inferred types and documentation.
>
> I don't know enough about F# or Ocaml to disagree with you, however I will
> say it would be cool to have access to a visual studio-like environment
> for lisp.
Same for OCaml. Emacs is the best there is as far as an IDE for OCaml goes
but it could barely suck any more than it does. There is really nothing
worth having outside the Linux world in this respect. There are some pretty
amazing domain-specific non-Windows IDEs though:
http://unity3d.com/
IDEs were discussed on the OCaml mailing list recently. Linux desperately
needs equivalents of the CLR and WPF if people are going to develop those
kinds of applications for it. Language-specific tools like Qt are worse
than useless because they're dragging Linuxers back to C++ for no decent
reason.
If OCaml gets its parallel GC, I think I'll start work on a new GUI toolkit
written in OCaml...
>> Perhaps you cannot measure readability but we can certainly measure
>> development speed:
>>
>> http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/59...
>
> Fortunately for me, I'm extremely productive in lisp. :)
We'll have to agree to disagree. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> ...There is really nothing worth having outside the Linux world in this
> respect...
I meant "in the Linux world", of course.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Nov 15, 1:48 am, Jon Harrop <····@ffconsultancy.com> wrote:
> ················@gmail.com wrote:
> > On Nov 14, 2:42 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> >>http://schwarzwald.infogami.com/blog/lispocaml
>
> > The lisp can be rewritten as a 3 liner in that example,
> > however I will admit it wouldn't be as optimized.
>
> > This does show something interesting about lisp, however.
> > What you have there is a hand rolled version of Ocaml's int_of_string
> > function in the flet.
> > This inadvertently show's one of lisp's powers...
> > You can feasibly work at either a very high level or a very low level.
> > (Optimize what you need to).
> > It could be just as easily done with (read-from-string (read-line
> > *standard-input* nil "nil")).
>
> And the OCaml code demonstrates how other languages can provide both
> performance and brevity at the same time, which is the power of OCaml.
>
http://shootout.alioth.debian.org/debian/benchmark.php?test=sumcol&lang=sbcl&id=2
And the optimized lisp benchmarks twice as fast...
Is all about trade-offs I guess.
Can you do that sort optimization in ocaml?
> >> I don't believe that. I personally find it much harder to read code that
> >> uses extremely verbose identifiers (let alone inherently verbose
> >> languages).
>
> > It is a very subjective claim either way.
>
> I'd have thought there would be good agreement in some cases though. Pattern
> matching is an obvious example where convention dictates the use of:
>
> h::t
>
> or:
>
> x::xs
>
> instead of:
>
> the_first_element :: the_remaining_elements
>
> The reason being that pattern matching lets you reflect the structure of a
> data structure in your code but that is impossible to read if you use long
> identifiers.
>
In a context where I already know that you are doing something on a
datastructure, they seem to be about equivalent?
Otherwise, the second one seems to win. Although:
first :: rest
Probably would have been easier.
> >> > If i can skim through the functions and get the gist of what each does
> >> > by function name, it seems to be a greater return on my extra typing
> >> > investment when I get into the debug-compile-test phase (as that is
> >> > where most programming time is spent?).
>
> >> No. Programmers only spend a significant amount of time debugging when
> >> they don't have a modern static type system.
>
> > Honestly I keep track of typing pretty well in my head (remembering
> > lisp is dynamically typed), it is second nature at this point...
>
> With >1 programmer, that breaks down.
>
> Inferred types are also very useful when teaching.
>
> http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
>
> # let d f x =
> let eps = sqrt epsilon_float in
> ((f (x +. eps)) -. (f (x -. eps))) /. (2. *. eps);;
> val d : (float -> float) -> float -> float = <fun>
>
> The inferred type immediately tells you that this is a higher-order "d"
> function, "f" is its function argument etc.
>
Hmm. Maybe this all just went whoosh, right over my head, but I
believe you can statically type lisp.
> You might say that documentation achieves the same effect in Lisp but it is
> not machine verified and it does not compose. For example, the type of the
> following expression immediately tells us that it is also a combinator:
>
> # nest 3 d;;
> - : (float -> float) -> float -> float = <fun>
>
Documentation *and* naming-conventions.
'NumberOfThisOrThat' probably returns (or points to) a number.
How do you handle data objects that are not inherent to the language?
> Everyone knows that using dynamically typed languages
> means spending your life running unit tests in a debugger.
I did not know that!
I'd also like to note that we started talking about F# and are now
talking about Ocaml (?)
In which can I do everything?
················@gmail.com writes:
> I'd also like to note that we started talking about F# and are now
> talking about Ocaml (?)
The difference between Ocaml and F# is not relevant to any of the
claims put forth by Harrop to which you replied. What was at issue was
whether static typing allows one to reduce verboseness without
compromising comprehensibility -- any modern statically typed
functional language, that is, any language with a Hindley-Milner type
type system, serves for the purposes of this discussion.
--
Aatu Koskensilta (················@uta.fi)
"Wovon man nicht sprechen kann, darüber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
On Nov 15, 7:02 pm, Aatu Koskensilta <················@uta.fi> wrote:
> ················@gmail.com writes:
> > I'd also like to note that we started talking about F# and are now
> > talking about Ocaml (?)
>
> The difference between Ocaml and F# is not relevant to any of the
> claims put forth by Harrop to which you replied. What was at issue was
> whether static typing allows one to reduce verboseness without
> compromising comprehensibility -- any modern statically typed
> functional language, that is, any language with a Hindley-Milner type
> type system, serves for the purposes of this discussion.
>
> --
> Aatu Koskensilta (················@uta.fi)
>
> "Wovon man nicht sprechen kann, darüber muss man schweigen"
> - Ludwig Wittgenstein, Tractatus Logico-Philosophicus
This really about whether I eat my toast butter side up or butter side
down it seems.
Butter side down! Down with the butter side up Heretics!
················@gmail.com wrote:
> On Nov 15, 1:48 am, Jon Harrop <····@ffconsultancy.com> wrote:
>> And the OCaml code demonstrates how other languages can provide both
>> performance and brevity at the same time, which is the power of OCaml.
>
>
http://shootout.alioth.debian.org/debian/benchmark.php?test=sumcol&lang=sbcl&id=2
>
> And the optimized lisp benchmarks twice as fast...
>
> Is all about trade-offs I guess.
>
> Can you do that sort optimization in ocaml?
Yes. You can do that in any language. There is still the question of whether
or not the result would be sufficiently fast but that applies equally to
Lisp as to any other language. One advantage Lisp has is run-time
compilation. That is not bundled with OCaml (although it is easy enough to
do, e.g. with LLVM). However, Lisp's EVAL imposes the same performance
problems as the Lisp environment itself. In practice, that is often too
much, making it pointless and leading everyone to use the same
heterogeneous metaprogramming instead.
>> I'd have thought there would be good agreement in some cases though.
>> Pattern matching is an obvious example where convention dictates the use
>> of:
>>
>> h::t
>>
>> or:
>>
>> x::xs
>>
>> instead of:
>>
>> the_first_element :: the_remaining_elements
>>
>> The reason being that pattern matching lets you reflect the structure of
>> a data structure in your code but that is impossible to read if you use
>> long identifiers.
>>
>
> In a context where I already know that you are doing something on a
> datastructure, they seem to be about equivalent?
> Otherwise, the second one seems to win. Although:
>
> first :: rest
>
> Probably would have been easier.
Not if you're restructuring something non-trivial:
# let rec f = function
| (h1::t1)::(h2::t2)::ts -> h1 + h2 :: f(t1::t2::ts)
| []::ts | _::[]::ts -> f ts
| _ -> [];;
val f : int list list -> int list = <fun>
# f [[1;2;3]; [4;5;6]; [7;8;9]];;
- : int list = [5; 7; 9]
I do not believe longer identifiers improve clarity at all in such
situations but they certainly degrade it by forcing you to split your code
across many lines.
This is a fundamental difference between OCaml and Lisp: the brackets in
Lisp make it incomprehensible unless you split across lines and use
indentation to replace syntax, in which case you have nothing to lose by
adopting long identifiers. This is also why I prefer LOC to Andre Thieme's
unindented non-whitespace chars: lots of indentation is essential in Lisp
and it culminates in lots of wasted screen real estate. So the information
content on a screen of code is ~2x lower with Lisp (or Java) than OCaml,
F#, SML or Haskell.
>> Inferred types are also very useful when teaching.
>>
>> http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
>>
>> # let d f x =
>> let eps = sqrt epsilon_float in
>> ((f (x +. eps)) -. (f (x -. eps))) /. (2. *. eps);;
>> val d : (float -> float) -> float -> float = <fun>
>>
>> The inferred type immediately tells you that this is a higher-order "d"
>> function, "f" is its function argument etc.
>>
>
> Hmm. Maybe this all just went whoosh, right over my head, but I
> believe you can statically type lisp.
Absolutely. Persue that idea for 35 years and you get to where OCaml and F#
already are.
>> You might say that documentation achieves the same effect in Lisp but it
>> is not machine verified and it does not compose. For example, the type of
>> the following expression immediately tells us that it is also a
>> combinator:
>>
>> # nest 3 d;;
>> - : (float -> float) -> float -> float = <fun>
>
> Documentation *and* naming-conventions.
> 'NumberOfThisOrThat' probably returns (or points to) a number.
That's just even more for the programmer to have to maintain. If they don't
maintain it correctly by hand, it gets out of sync and becomes misleading
instead of helpful. The equivalent in OCaml/F# is inferred by the compiler
and checked by the machine but still only a mouse hover away.
> How do you handle data objects that are not inherent to the language?
>
>> Everyone knows that using dynamically typed languages
>> means spending your life running unit tests in a debugger.
>
> I did not know that!
Ah, yes. Look at the proportion of code devoted to unit testing in projects
written in dynamic and (modern) static languages:
MLDonkey: <1% (OCaml)
Presenta: <1% (OCaml)
F# for Visualization: 1.5% (F#)
Maxima: 13% (Lisp)
> I'd also like to note that we started talking about F# and are now
> talking about Ocaml (?)
OCaml and F# are the same for the purposes of this discussion.
> In which can I do everything?
All of this stuff, yes. Both OCaml and F# have some features that the other
lacks.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
It looks like static typing is very important to you.
Would it make you happy if there were a code-walker
program for Lisp that inserted all the inferrable
declarations, declamations, etc, and printed warnings
for any object whose type it could not infer?
'Cos, it wouldn't actually be all that hard, and I'm
pretty sure somebody's done it already.
I think it would probably be a useful tool - possibly
making code faster on implementations that don't already
have that level of type inference built in but which
use declarations.
And, heck, if you don't keep track of types adequately,
it might even surprise you by pointing out a spot where
your program really could run into a type error.
But the main use for it I think would be confidence and
SQA. You'd be able to document that the code contained
no type errors, while *NOT* spending any time doing
unit tests.
That would certainly make it an easier sell to management
teams accustomed to static languages, and also into markets
that need hardcore reliability, where people die in case
of software failures and rigorous government-mandated test
requirements fill volumes.
Bear
On Nov 16, 1:58 pm, Ray Dillinger <····@sonic.net> wrote:
> It looks like static typing is very important to you.
>
> Would it make you happy if there were a code-walker
> program for Lisp that inserted all the inferrable
> declarations, declamations, etc, and printed warnings
> for any object whose type it could not infer?
>
> 'Cos, it wouldn't actually be all that hard, and I'm
> pretty sure somebody's done it already.
>
> I think it would probably be a useful tool - possibly
> making code faster on implementations that don't already
> have that level of type inference built in but which
> use declarations.
>
> And, heck, if you don't keep track of types adequately,
> it might even surprise you by pointing out a spot where
> your program really could run into a type error.
>
> But the main use for it I think would be confidence and
> SQA. You'd be able to document that the code contained
> no type errors, while *NOT* spending any time doing
> unit tests.
>
> That would certainly make it an easier sell to management
> teams accustomed to static languages, and also into markets
> that need hardcore reliability, where people die in case
> of software failures and rigorous government-mandated test
> requirements fill volumes.
>
> Bear
This idea was kind of in the back of my mind too.
Also I did a little research and SBCL actually has inferred static
typing,
for what it's worth. (as does CMUCL...)
>John Harrop
>This is a fundamental difference between OCaml and Lisp: the brackets in
>Lisp make it incomprehensible unless you split across lines and use
>indentation to replace syntax, in which case you have nothing to lose by
>adopting long identifiers.
Ah, exactly the point, however.
A good lisp programmer splits his code up over multiple lines.
Counting LOC in lisp is silly.
The structure of the code reflects the structure of the data being
processed (they are often isomorphic).
I can look at a well written block of lisp and get a visual idea of
the data structure that it is parsing.
I can certainly see how the quality/intelligence of the programmer
would effect code much more in lisp than it would in other languages
(in fact, I'm happy to concede that point).
················@gmail.com wrote:
> A good lisp programmer splits his code up over multiple lines.
Yes.
> Counting LOC in lisp is silly.
Only if you're counting lines in unidiomatically-formatted code. Otherwise
LOC is a great measure of the effect you just described.
I value my screen real estate. I don't want to waste it on lots of
indentation when I could use syntax to express the same thing in half the
area because that makes it much easier to read any serious quantity of
code.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
> I value my screen real estate. I don't want to waste it on lots of
> indentation when I could use syntax to express the same thing in half the
> area because that makes it much easier to read any serious quantity of
> code.
>
I wish you were valuing the readers of comp.lang.lisp more than your
screen estate. The latter don't want space wasted in the group from SPAM
or other non-related to lisp stuff.
All in all, you are like someone trying to sell airplanes at an
automobile convention. Or meat to a vegan...
Either go away, or come back with interesting stuff that is really7
useful or related to Common Lisp. So far you have shown nothing that
would improve it, or any relation to it.
Remember what comes around, goes around.
Ray Dillinger wrote:
> It looks like static typing is very important to you.
>
> Would it make you happy if there were a code-walker
> program for Lisp that inserted all the inferrable
> declarations, declamations, etc, and printed warnings
> for any object whose type it could not infer?
>
> 'Cos, it wouldn't actually be all that hard, and I'm
> pretty sure somebody's done it already.
>
> I think it would probably be a useful tool - possibly
> making code faster on implementations that don't already
> have that level of type inference built in but which
> use declarations.
>
> And, heck, if you don't keep track of types adequately,
> it might even surprise you by pointing out a spot where
> your program really could run into a type error.
>
> But the main use for it I think would be confidence and
> SQA. You'd be able to document that the code contained
> no type errors, while *NOT* spending any time doing
> unit tests.
>
> That would certainly make it an easier sell to management
> teams accustomed to static languages, and also into markets
> that need hardcore reliability, where people die in case
> of software failures and rigorous government-mandated test
> requirements fill volumes.
...while doing nothing to ensure reliability so I wonder why you said it
was good for that. What is ensured is ass-wiped management saying "you
cannot fire me, I made them follow steps X Y and Z, I did my job." which
is prima facie laughable to anyone involved in our game and completely
compelling to the dipwads higher up the ladder. Look at Obama's
application form: everyone with whom I have cohabitated in ten years,
all my interwebby activity, every resume sent out, every court date and
citation # for every traffic violation... I wager only a Jeffrey Dahlmer
could come up with that, but the Obamster will be able to say, "Omigod!
Kenny lied!!!". OTOH, IIUC Obama has turned the heat up only a few
points compared to prior Orwellian admins so maybe it's just me, but the
point is...reliability? From crap like that. Soo.. Java code never
fails?... Awesome!
kt
Ray Dillinger wrote:
> It looks like static typing is very important to you.
>
> Would it make you happy if there were a code-walker
> program for Lisp that inserted all the inferrable
> declarations, declamations, etc, and printed warnings
> for any object whose type it could not infer?
That would not satisfy me because static type systems require careful
design. For example, that is the difference between Java and OCaml.
However, Erlang already has such a tool and it is apparently quite commonly
used.
> 'Cos, it wouldn't actually be all that hard, and I'm
> pretty sure somebody's done it already.
Yes. The problem is that it can infer very little type information because
the Lisp language was not designed to express type information.
> I think it would probably be a useful tool - possibly
> making code faster on implementations that don't already
> have that level of type inference built in but which
> use declarations.
Yes, it could annotate the source with static type information to improve
performance (assuming the compiler could use that). Perhaps you could
factor out the type inference in one of the better open source Lisp
compilers and make it a separate tool?
> And, heck, if you don't keep track of types adequately,
> it might even surprise you by pointing out a spot where
> your program really could run into a type error.
>
> But the main use for it I think would be confidence and
> SQA. You'd be able to document that the code contained
> no type errors, while *NOT* spending any time doing
> unit tests.
Such tools offer very little confidence.
> That would certainly make it an easier sell to management
> teams accustomed to static languages, and also into markets
> that need hardcore reliability, where people die in case
> of software failures and rigorous government-mandated test
> requirements fill volumes.
The ramifications are usually that the software company gets a reputation
for poor reliability, customers dry up and the company goes bankrupt.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 2008-11-14 14:42:42 -0500, He Who Must Remain Unnamed
<····@up.his.google.ranking.com> said:
> I personally find it much harder to read code that
^^^^^^^^^^^^ !!!!!!!
> uses extremely verbose identifiers (let alone inherently verbose
> languages).
personally? PERSONALLY!???
Did the aquatic one just accidentally admit that <gasp> personal
preferences might differ among programmers? That there isn't one
objective best language or programming practice?
Isn't this one of the signs of the Apocalypse?
In any event, do I have to mention that my preferences are precisely
opposite to his here as well, and that:
I dtst prgmrs who chs rlly shrt idntfr nms,
thy mk rdng cd mch hrdr thn it nds 2 b
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com>
wrote:
[...]
>
> I dtst prgmrs who chs rlly shrt idntfr nms,
>
> thy mk rdng cd mch hrdr thn it nds 2 b
Maybe you should learn Hebrew?
On 2008-11-14, Jon Harrop <···@ffconsultancy.com> wrote:
> No. Programmers only spend a significant amount of time debugging when they
> don't have a modern static type system.
>
> For example, OCaml has a sophisticated "time travel" debugger but I've never
> used it in four years of writing commercial OCaml code. I simply have no
> use for a debugger any more.
Good thing you don't have credibility as a software developer, or you'd be
destroying it all over again.
You're trying to make the argument that:
- statically typed programs always correctly implement their specification,
and that specification is always complete and internally consistent.
- statically typed programs always handle all unexpected environmental
situations gracefully and are robust against all bad inputs.
- modern, statically typed, functional programs never have any run-time state
which may have incorrect values.
- specifically, no object constructed in a statically typed, functional
program, ever has an incorrect structure; all possible ways of being
incorrect in a given situation are always reflected by some kind of
type constraint (and the type system ensures that the programmer
never forgets to specify all necessary constraints).
- modern static typing diagnoses all infinite looping situations (even though
the language is Turing-complete) so that only deliberately requested infinite
loops (e.g. event processing) survive into run-time.
- statically typed procedures are written in a Turing-complete language,
yet are guaranteed to terminate whenever it is not the programmer's
intention to specify an infinite event-processing loop.
- furthermore, static typing magically eliminates priority inversions, race
conditions, starvations, deadlocks and livelocks from real-time concurrent
software.
Could it be that you simply don't write complicated enough programs to run into
serious bugs. How badly can you screw up some academic example intended to fit
into a one page figure box with a caption underneath?
Could it be that you just don't test deeply enough? If your attitude is that
your code is bug free, why would you bother looking for bugs, right? If the
program produces the expected result for good inputs, it's bug-free, right?
On Sat, 15 Nov 2008 00:05:32 +0000, Kaz Kylheku wrote:
> Could it be that you simply don't write complicated enough programs to
> run into serious bugs. How badly can you screw up some academic example
> intended to fit into a one page figure box with a caption underneath?
That is just pure slander. JH is known to have written a 50-line toy
raytracer in Ocaml! Try putting that into a one page figure box, and you
won't have place for the caption, unless you use a small font of course.
If you only saw the light and subscribed to the famous F# Journal (only
99 GPD/year, really a bargain), you would see the true range of his
programming abilities. For example, the June 2007 issue is said to
contain a Sudoku Solver. Legend says that the first version of the
program played chess instead, but thanks to static typechecking the error
was recognized at compile time - it was a close call though.
Tamas
Kaz Kylheku wrote:
> How badly can you screw up some academic example intended to fit into a
> one page figure box with a caption underneath?
You seem to be confusing "being educated" with "being an academic". Look at
our products:
http://www.ffconsultancy.com/products/?cll
> Could it be that you just don't test deeply enough?
> ...
> Could it be that you simply don't write complicated enough programs to run
> into serious bugs.
> ...
> If your attitude is that your code is bug free, why would you bother
> looking for bugs, right?
In other words, we haven't run infinite tests on infinitely large and
infinitely complex software.
We sell 500kLOC of software. We have hundreds of thousands of users. I can
count the number of outstanding bugs in all of our software products
combined on one hand. Bugs just aren't a problem for us.
This is not news. Everyone knows that using dynamically typed languages
means spending your life running unit tests in a debugger. That's precisely
when I stopped using them for general purpose programming when I was a
teenager.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 15 Nov, 08:08, Jon Harrop <····@ffconsultancy.com> wrote:
> Everyone knows that using dynamically typed languages...
BTW, forgot to mention another "everyone knows" (regarding the
future):
Everyone knows that F# will soon be surpassed by Clojure (so I'm
actually wasting my time here).
Jon Harrop
http://clojure.org/
http://groups.google.com/group/clojure
···················@gmail.com wrote:
> Everyone knows that F# will soon be surpassed by Clojure (so I'm
> actually wasting my time here).
Maybe, if it ever gets tail calls, i.e. if the JVM ever gets tail calls.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 16 Nov, 14:12, Jon Harrop <····@ffconsultancy.com> wrote:
> ... tail calls ... JVM ...
...as updated people already know, are currently being implemented.
Jon Harrop
http://clojure.org/
http://groups.google.com/group/clojure
···················@gmail.com wrote:
> On 16 Nov, 14:12, Jon Harrop <····@ffconsultancy.com> wrote:
>> ... tail calls ... JVM ...
>
> ...as updated people already know, are currently being implemented.
Yes, its vaporware.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> ···················@gmail.com wrote:
>
>>On 16 Nov, 14:12, Jon Harrop <····@ffconsultancy.com> wrote:
>>
>>>... tail calls ... JVM ...
>>
>>...as updated people already know, are currently being implemented.
>
>
> Yes, its vaporware.
>
Or you need to be updated. That would be fun to watch, actually.
Meanwhile, Googlefight shows Ruby extending its lead 88k to 60k over
Python, Lisp hanging in there at 10k, and Javascript making all of them
and especially you and your silly Microsoft-sucking rag irrelevant with
590k.
This is good news, we won't ever have to worry about the Great Unwashed
landing on our pristine shores.
As for you, my favorite scenes in Leave It to Beaver were those
featuring Eddie Haskell, yer fine.
kt
Kenny wrote:
> Jon Harrop wrote:
>> ···················@gmail.com wrote:
>>>On 16 Nov, 14:12, Jon Harrop <····@ffconsultancy.com> wrote:
>>>
>>>>... tail calls ... JVM ...
>>>
>>>...as updated people already know, are currently being implemented.
>>
>> Yes, its vaporware.
>
> Or you need to be updated.
No, it really is vaporware.
The only update is that Sun are laying off thousands of employees for the
second time since 2006. So the company looks doomed. Their PL team were
gambling money the company doesn't have on dynamic languages like Groovy
that don't need tail calls. So they don't give a toss about tail calls
which is why they only hinted that one employee was looking at tail calls
in his spare time and he'll probably be fired on Friday...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 17 Nov, 21:15, Jon Harrop <····@ffconsultancy.com> wrote:
> No, it really is vaporware.
No, yes, yes, no, Sun is becoming vaporware, much the same as
Microsoft.
Tail calls in the open source JVM are only a matter of time, and they
are the one and only objection possible of Clojure not surpassing F#.
If I wanted to implement F# on the JVM, I would instantly miss tail
calls.
Clojure does not depend on such insignificant details, so it will
certainly surpass F#, hopefully not before F# making me an independent
millionaire...
Jon Harrop
http://clojure.org/
http://groups.google.com/group/clojure
On 17 Nov, 03:08, Jon Harrop <····@ffconsultancy.com> wrote:
> Yes, its vaporware.
Yes, it's coming soon!
BTW, did I mention that I like Clojure?
Jon Harrop
http://clojure.org/
http://groups.google.com/group/clojure
···················@gmail.com writes:
> On 17 Nov, 03:08, Jon Harrop <····@ffconsultancy.com> wrote:
>> Yes, its vaporware.
>
> Yes, it's coming soon!
> BTW, did I mention that I like Clojure?
>
> Jon Harrop
So now I have to add Fake Frogs to my kill file also ? <sigh>
> http://clojure.org/
> http://groups.google.com/group/clojure
On 2008-11-15, Jon Harrop <···@ffconsultancy.com> wrote:
> Kaz Kylheku wrote:
>> How badly can you screw up some academic example intended to fit into a
>> one page figure box with a caption underneath?
>
> You seem to be confusing "being educated" with "being an academic". Look at
> our products:
>
> http://www.ffconsultancy.com/products/?cll
Most of the stuff you have here could be implemented in C, without doing
anything remotely risky with pointers, or worrying about complicated
interactions with other components, unexpected environmental situations, and
the like.
You could probably use Fortran, even.
> We sell 500kLOC of software.
I'd be surprised if you could peddle the same 2000 lines to 250 users. (But no
doubt you'd call that 500 kloc sold).
> We have hundreds of thousands of users.
By what Google searching contortion did you dream up this fantasy figure? If
each of those users paid you a mere pound, you wouldn't be here.
Kaz Kylheku wrote:
> On 2008-11-15, Jon Harrop <···@ffconsultancy.com> wrote:
>> Kaz Kylheku wrote:
>>> How badly can you screw up some academic example intended to fit into a
>>> one page figure box with a caption underneath?
>>
>> You seem to be confusing "being educated" with "being an academic". Look
>> at our products:
>>
>> http://www.ffconsultancy.com/products/?cll
>
> Most of the stuff you have here could be implemented in C, without doing
> anything remotely risky with pointers, or worrying about complicated
> interactions with other components, unexpected environmental situations,
> and the like.
>
> You could probably use Fortran, even.
That would not be commercially viable.
>> We have hundreds of thousands of users.
>
> By what Google searching contortion did you dream up this fantasy figure?
> If each of those users paid you a mere pound, you wouldn't be here.
Why would I not be here if we had pulled in >£25k per annum?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Tue, 11 Nov 2008 21:24:33 -0500, Bob Felts wrote:
> ~] bottle~:*~P ~
> of beer on the ~
> wall.~2&-----~%~
> ~1%~:*~]~]~}~0%"
>
> (loop for bottle from in-stock downto 0 collect bottle)))
>
> ------------------------------------------------------------------------
>
> There's simply no comparison. Lisp wins hands down for simplicity,
> elegance, and beauty.
That program is not written in Lisp, it is written in Format :-)
Tamas
André Thieme wrote:
> Let’s see:
>
> CL:
> (defun before (x y lst &key (test #'eql))
> (and lst
> (let ((first (car lst)))
> (cond ((funcall test y first) nil)
> ((funcall test x first) lst)
> (t (before x y (cdr lst) :test test))))))
> ...
> CL: 181 chars, Ruby: 187 chars, Clojure: 157 chars
Hmm...
$ cat >x
(defun before (x y lst &key (test #'eql))
(and lst
(let ((first (car lst)))
(cond ((funcall test y first) nil)
((funcall test x first) lst)
(t (before x y (cdr lst) :test test))))))
$ wc x
6 33 232 x
You got 181 but it is actually 232 chars for CL. Let me guess, you're not
counting parentheses?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> André Thieme wrote:
>
>>Let’s see:
>>
>>CL:
>>(defun before (x y lst &key (test #'eql))
>> (and lst
>> (let ((first (car lst)))
>>(cond ((funcall test y first) nil)
>>((funcall test x first) lst)
>>(t (before x y (cdr lst) :test test))))))
>>...
>>CL: 181 chars, Ruby: 187 chars, Clojure: 157 chars
>
>
> Hmm...
>
> $ cat >x
> (defun before (x y lst &key (test #'eql))
> (and lst
> (let ((first (car lst)))
> (cond ((funcall test y first) nil)
> ((funcall test x first) lst)
> (t (before x y (cdr lst) :test test))))))
> $ wc x
> 6 33 232 x
>
> You got 181 but it is actually 232 chars for CL. Let me guess, you're not
> counting parentheses?
>
Parentheses? What parentheses? Do you count the spaces? We don't need
not stinkin spaces.
hth,kzo
ps. Weren't you supposed to go away for another forty-eight years? k
Kenny wrote:
> Jon Harrop wrote:
>> André Thieme wrote:
>>
>>>Let’s see:
>>>
>>>CL:
>>>(defun before (x y lst &key (test #'eql))
>>> (and lst
>>> (let ((first (car lst)))
>>>(cond ((funcall test y first) nil)
>>>((funcall test x first) lst)
>>>(t (before x y (cdr lst) :test test))))))
>>>...
>>>CL: 181 chars, Ruby: 187 chars, Clojure: 157 chars
>>
>>
>> Hmm...
>>
>> $ cat >x
>> (defun before (x y lst &key (test #'eql))
>> (and lst
>> (let ((first (car lst)))
>> (cond ((funcall test y first) nil)
>> ((funcall test x first) lst)
>> (t (before x y (cdr lst) :test test))))))
>> $ wc x
>> 6 33 232 x
>>
>> You got 181 but it is actually 232 chars for CL. Let me guess, you're not
>> counting parentheses?
>
> Parentheses? What parentheses? Do you count the spaces? We don't need
> not stinkin spaces.
Try running the Lisp without the parentheses.
> ps. Weren't you supposed to go away for another forty-eight years? k
No, you were supposed to bury your head for 48 years and imagine that I had
gone away.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> Kenny wrote:
>
>>Jon Harrop wrote:
>>
>>>André Thieme wrote:
>>>
>>>
>>>>Let’s see:
>>>>
>>>>CL:
>>>>(defun before (x y lst &key (test #'eql))
>>>> (and lst
>>>> (let ((first (car lst)))
>>>>(cond ((funcall test y first) nil)
>>>>((funcall test x first) lst)
>>>>(t (before x y (cdr lst) :test test))))))
>>>>...
>>>>CL: 181 chars, Ruby: 187 chars, Clojure: 157 chars
>>>
>>>
>>>Hmm...
>>>
>>>$ cat >x
>>>(defun before (x y lst &key (test #'eql))
>>> (and lst
>>> (let ((first (car lst)))
>>> (cond ((funcall test y first) nil)
>>> ((funcall test x first) lst)
>>> (t (before x y (cdr lst) :test test))))))
>>>$ wc x
>>> 6 33 232 x
>>>
>>>You got 181 but it is actually 232 chars for CL. Let me guess, you're not
>>>counting parentheses?
>>
>>Parentheses? What parentheses? Do you count the spaces? We don't need
>>not stinkin spaces.
>
>
> Try running the Lisp without the parentheses.
>
>
>>ps. Weren't you supposed to go away for another forty-eight years? k
>
>
> No, you were supposed to bury your head for 48 years and imagine that I had
> gone away.
>
Man, you are so unworthy of being kennyized. If you want a t-shirt yer
gonna have to do a lot better than that.
Here's a fat pitch: everybody loves Javascript (my new language), and
Javascript is more like Lisp than... well, it is nothing like F#.
Feel the tide going out?
peace,k
Kenny wrote:
> Here's a fat pitch: everybody loves Javascript (my new language), and
> Javascript is more like Lisp than... well, it is nothing like F#.
Javascript isn't "like Lisp". That's just what Lispers tell other Lispers to
try to comfort them and shield them from the truth while they huddle
together sharing warmth in their dark, dank, tiny corner of the world.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> Kenny wrote:
>
>>Here's a fat pitch: everybody loves Javascript (my new language), and
>>Javascript is more like Lisp than... well, it is nothing like F#.
> Javascript isn't "like Lisp".
Untyped variables, first-class functions, lexical scope, closures...
hmmm, a preprocessor ala C would have been /something/.
No static typing, no pattern-matching syntax...
Tide! Wherefor art thou, tide?! Why hast thou gone out on me?!
> That's just what Lispers tell other Lispers to
> try to comfort them and shield them from the truth while they huddle
> together sharing warmth in their dark, dank, tiny corner of the world.
>
...laughing their asses off writing great code between bong hits, IIRC.
kzo
Kenny wrote:
> Jon Harrop wrote:
>> Kenny wrote:
>>>Here's a fat pitch: everybody loves Javascript (my new language), and
>>>Javascript is more like Lisp than... well, it is nothing like F#.
> > Javascript isn't "like Lisp".
>
> Untyped variables, first-class functions, lexical scope, closures...
> No static typing, no pattern-matching syntax...
What about Visual Basic, IronPython, IronRuby, Phalanger, P#, Windows
PowerShell, Mathematica, Groovy, Perl, PHP, Erlang, Objective C, Smalltalk
and Scheme?
Meanwhile: No macros and no s-exprs (no code-is-data). No CAR, CDR. BASIC
(not Lisp) style EVAL.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> Kenny wrote:
>
>>Jon Harrop wrote:
>>
>>>Kenny wrote:
>>>
>>>>Here's a fat pitch: everybody loves Javascript (my new language), and
>>>>Javascript is more like Lisp than... well, it is nothing like F#.
>>
>> > Javascript isn't "like Lisp".
>>
>>Untyped variables, first-class functions, lexical scope, closures...
>>No static typing, no pattern-matching syntax...
>
>
> What about Visual Basic, IronPython, IronRuby, Phalanger, P#, Windows
> PowerShell, Mathematica, Groovy, Perl, PHP, Erlang, Objective C, Smalltalk
> and Scheme?
>
All of them (I'll trust you) also happily surfing the Lisp Wave, while
F# sits like a beahced whale high and dry on Microsoft's statically
typed private, well, it is so far from the water now that it's not
really a beach anymore, is it? Shall we call it ...wasteland?
Sorry about that bet you made on F# based on MS domination of the
desktop, but no one cares about the desktop anymore kiddo. What matters
now is the Interweb and Javascript and Chrome with its compiled JS is
pretty much the MS death knell. OpenOffice will eat what is left of that
market, and you... you went proprietary?!!!! Oh my.
RIP, jonzo, RIP.
Kenny wrote:
> Jon Harrop wrote:
>> Kenny wrote:
>>>Jon Harrop wrote:
>>>>Kenny wrote:
>>>>>Here's a fat pitch: everybody loves Javascript (my new language), and
>>>>>Javascript is more like Lisp than... well, it is nothing like F#.
>>>>
>>>> Javascript isn't "like Lisp".
>>>
>>>Untyped variables, first-class functions, lexical scope, closures...
>>>No static typing, no pattern-matching syntax...
>>
>> What about Visual Basic, IronPython, IronRuby, Phalanger, P#, Windows
>> PowerShell, Mathematica, Groovy, Perl, PHP, Erlang, Objective C,
>> Smalltalk and Scheme?
>
> All of them (I'll trust you) also happily surfing the Lisp Wave, while
> F# sits like a beahced whale high and dry on Microsoft's statically
> typed private, well, it is so far from the water now that it's not
> really a beach anymore, is it? Shall we call it ...wasteland?
>
> Sorry about that bet you made on F# based on MS domination of the
> desktop, but no one cares about the desktop anymore kiddo. What matters
> now is the Interweb and Javascript and Chrome with its compiled JS is
> pretty much the MS death knell. OpenOffice will eat what is left of that
> market, and you... you went proprietary?!!!! Oh my.
I actually read your post and forget to reply. I remembered as I was trying
to write a blog post about a product update and noticed that Firefox
running Javascript on my 8-core Opteron server was unable to keep up with
my typing. No wonder Javascript is circling the drain:
http://www.google.com/trends?q=javascript
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 2008-11-12, Jon Harrop <···@ffconsultancy.com> wrote:
> Kenny wrote:
>> Here's a fat pitch: everybody loves Javascript (my new language), and
>> Javascript is more like Lisp than... well, it is nothing like F#.
>
> Javascript isn't "like Lisp".
Did he say that?
I believe we can complete the sentence in some way to produce a truth:
``Javascript is more like Lisp than ...''
Even better: ``Fortran is more like Lisp than ... a bicycle is like a fish.''
> That's just what Lispers tell other Lispers to
> try to comfort them and shield them from the truth while they huddle
> together sharing warmth in their dark, dank, tiny corner of the world.
Be that as it may, a small nook within this tiny corner is where you choose to
do a lot of your attention whoring. There is must be not a negligible measure
of some kind of comfort in that for you.
Kaz Kylheku wrote:
> ...a bicycle is like a fish...There is must be not a negligible...
I think you've been working on your big project for too long. ;-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop schrieb:
> André Thieme wrote:
>> Let’s see:
>>
>> CL:
>> (defun before (x y lst &key (test #'eql))
>> (and lst
>> (let ((first (car lst)))
>> (cond ((funcall test y first) nil)
>> ((funcall test x first) lst)
>> (t (before x y (cdr lst) :test test))))))
>> ...
>> CL: 181 chars, Ruby: 187 chars, Clojure: 157 chars
>
> Hmm...
>
> $ cat >x
> (defun before (x y lst &key (test #'eql))
> (and lst
> (let ((first (car lst)))
> (cond ((funcall test y first) nil)
> ((funcall test x first) lst)
> (t (before x y (cdr lst) :test test))))))
> $ wc x
> 6 33 232 x
>
> You got 181 but it is actually 232 chars for CL. Let me guess, you're not
> counting parentheses?
I said in my original post:
“The length in bytes of each, when leading whitespace in each
line is removed [...]”.
So:
user> (count "(defun before (x y lst &key (test #'eql))
(and lst
(let ((first (car lst)))
(cond ((funcall test y first) nil)
((funcall test x first) lst)
(t (before x y (cdr lst) :test test))))))")
==> 181
And:
user> (count "def before x, y, list, &block
block = proc{|a,b| a==b} if not block
list.each_with_index{|thing,i|
return nil if block.call(y,thing)
return list[i..-1] if block.call(x,thing) }
nil
end")
==> 187
In the Lisp dialect Clojure it’s just 157 chars.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/