Re: LISP vs HASKELL vs PROLOG
Dimiter "malkia" Stanev
> I'm not trying to start a flame war about which one is the best. Could
> anybody explain me each of these languages features and strong points ?
I know a bit Common Lisp, but I'm still lisp toddler. I can barely
understand haskell, and have troubles reading prolog code.
So Common Lisp is multi-paradigm language - you can code in many
different ways. Strong points are powerful macro system, continuous
development cycle - e.g. you can modify the system while it's running,
the multi-dispatch Common Lisp Object System (CLOS), the special global
variables, lambdas, local variables (let), closures (let over lambdas),
and many other things builtin, or built on top of it.
Common Lisp is not purely functional (unlike Haskell, and I think
Prolog), and one can say not functional at all, but you can definitely
code easily in functional matter, given you restrict yourself to
non-destructive operations, and facilities such as FSet or similar.
Not being purely functional is both strong, and weak point. Strong, that
you can really fix performance problems with iterative code where
needed, weak that in generally allowing side-effects, you limit the
compiler abilities - mainly the compiler cannot assume that data won't
be modified. Not sure whether it's relevant :)
With Common Lisp you can quickly start prototyping code. Such code could
be 10x-1000x less efficient than what you can actually achieve, but by
iteratively profiling and applying hints and types to the compiler, you
could gain a lot more. I'm still finding my way through this.
In general, there are reasonably good compilers there, where you won't
need so much hints.
You can mend Common Lisp to your needs, as long as you become good
master in it.
My weakest point for Common Lisp so far has been ME - I have to mend
myself to the language, rather than trying to use it, the way I've been
using past languages
As little as I know of Haskell, it's strictly-typed, lazy by default
pure functional language (e.g. by default no side effects).
Can't say much about prolog.
Richard Fateman
> I'm not trying to start a flame war about which one is the best. Could
> anybody explain me each of these languages features and strong points ?
Too late.
Thomas M. Hermann
> I'm not trying to start a flame war about which one is the best. Could
> anybody explain me each of these languages features and strong points ?
This question reminds me of the Dilbert strip where the secretary asks
Dilbert to tell her everything she needs to know about engineering and
she doesn't care if it takes all day. Well, at least you didn't
cross-post it.
Have you heard of either Google or Wikipedia? Both are generally
considered good places to start when you want to expend as little effort
as possible to get some information.
http://en.wikipedia.org/wiki/Common_lisp
http://en.wikipedia.org/wiki/Haskell_(programming_language)
http://en.wikipedia.org/wiki/Prolog
Hope that helps,
Tom
Jon Harrop
> I'm not trying to start a flame war about which one is the best. Could
> anybody explain me each of these languages features and strong points ?
Common Lisp is strict evaluation, dynamic typing with macros (to rewrite
code at compile-time) and run-time code evaluation. Was a pioneering
functional language decades ago but has long since been superceded. Has no
particular strengths today and, hence, is very rare. Main weaknesses are
baggage, poor performance, bad implementations and a really backward
community. The only notable development around Lisp for a decade is the new
programming language Clojure that runs on the JVM. In particular, Clojure
addressed many of Lisp's major problems by dropping the baggage, building
upon a performant VM with a concurrent GC and stealing all of the
intelligent members of the Lisp community.
Haskell is non-strict evaluation and static typing. Is a research language
used to implement many radical ideas that are unlikely to be of any
immediate use. Main strength is that it abstracts the machine away
entirely, allowing some solutions to be represented very concisely. Main
weakness is that it abstracts the machine away entirely, rendering
performance wildly unpredictable (will my elegant program terminate in my
lifetime? who knows...).
I know little about Prolog except that it was designed specifically for
logic programming (i.e. solving problems by specifying relations and
searching for solutions) and that some of our customers use it.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Slobodan Blazeski
> I'm not trying to start a flame war about which one is the best. Could
> anybody explain me each of these languages features and strong points ?
When student is ready the answer will arrive.
Slobodan Blazeski
Tamas K Papp
> I'm not trying to start a flame war about which one is the best. Could
> anybody explain me each of these languages features and strong points ?
Your question is still too specific. Please try to be more general.
For example,
"Which one of Haskell, Prolog or CL is the best?"
gets a bonus mark for giving a vague criterion ("best") and no
context, but still constrains the answer to one of these three
languages. It is better to ask
"Which is the best computer language?"
But we are still not there: your domain of meaningless optimization is
still too restricted. Instead, ask:
"What is the best?"
Now the final touch: drop the criterion. Ask it this way:
"What?"
HTH,
Tamas
Lars Rune Nøstdal
> I'm not trying to start a flame war about which one is the best. Could
> anybody explain me each of these languages features and strong points ?
http://groups.google.com/group/comp.lang.lisp/msg/a5d5c10f811b81e8
..?
Mark Tarver
> I'm not trying to start a flame war about which one is the best. Could
> anybody explain me each of these languages features and strong points ?
In Qi (www.lambdassociates.org) all these, in a certain way, live
harmoniously together. You would probably answer your question by
experimenting with Qi.
Mark
Christoph Senjak
> I'm not trying to start a flame war about which one is the best. Could
> anybody explain me each of these languages features and strong points ?
Haskell is purely functional, very "formal", etc., Common Lisp has a
mighty object system and you can fit it to your needs in almost any
aspect, Prolog is a logical programming language. Comparing them is
like comparing mustard, apples and coffee.
Ask 10 people and you will get 11 opinions which one and why this one
is the best. As this is a Common Lisp usenet-group, it should be
expectable that most people prefer common lisp, for whatever reason.
ACL
> I'm not trying to start a flame war about which one is the best. Could
> anybody explain me each of these languages features and strong points ?
The best way is to try each and read a lot about them, as everyone who
responds will have a favorite language they are touting... Also,
certain languages will have varying amounts of power depending on the
person that you ask. Some people love common lisp and will tell you
all about how great it is, others get a headache from the parens and
haven't even written a line of code in it (but will tell you how
aweful it is anyway...).
A better thing to ask, 'what are your strong points', 'what are your
weak points', of each language community.
CL,
Pros:
+ old stable language,
+ multi-paradigm. (OO, functional, imperative, all in one).
+ macros
+ prototyping language (you can find the best algorithm fastest).
+ dynamic
+ faster than other dynamic languages (ruby/python) generally.
Cons:
- Not likely to change/improve
- Giving multi-paradigm language with macros to a bad programmer is
like giving a light sabre to a non-jedi, more likely to cut his arm
off and slice a hole in the side of the Millennium Falcon than save
Leia. (There is an amount of 'taste' involved, and not everyone has
it, even if they believe they do).
- Package system is crappy. (The package system is the real reason
people say 'there are no libraries for Common Lisp'. There are plenty
of libraries for common lisp, the problem is that they are a pain in
the ass to find/maintain and get working properly with other packages,
so you end up writing your own).
- Not quite as fast as statically typed Java/C most of the time
Neutrals:
+- If the library genuinely doesn't exist, you'll have a fun time
creating it.
(seriously I enjoy writing lisp code and would probably do it even
if I weren't paid... just don't tell my boss).
+- Through macros you get an entirely new way of development through
DSLs and bottom up programming.
+- Community has some of the most well established and talented trolls
around.
+- A few months in you'll get this completely mind blowing experience
of 'getting it'.
Jon Harrop
How is Qi like Haskell?
milanj
> stealing all of the intelligent members of the Lisp community.
I did not noticed anything like this, all smart lispers whose blogs i
read are still active, in fact they are so smart so bunch of them dont
post on c.l.l. ... also Clojure didnt stole you from us and that is a
real pity
neptundancer
Pillsy
> I'm not trying to start a flame war about which one is the best. Could
> anybody explain me each of these languages features and strong points ?
Common Lisp is so much more useful than either Prolog or Haskell that
it isn't even funny.
Why, if I want to do something in Common Lisp, I can open up a
terminal window, type "clisp", open another terminal window and type
"vim"[1] and start putting together something useful out of the
standard functions and a few essential libraries, all of which I'm
pretty familiar with.
OTOH, if I wanted to do something in Prolog, I'd have to download a
Prolog implementation, install it, read a book or two on Prolog,
probably do a bunch of exercises and little warm-up projects, and then
maybe I'd be able to put together something useful. Haskell would be
the same.
So, yeah, Common Lisp: way better than those other languages you're
talking about.
Cheers, 0
Pillsy
[1] That's on my work computer; at home I use SLIME + SBCL and things
are even more pleasant.
ACL
"Common lisp, I know it and its already installed, therefore its
better than everything else!"
:-P
(Not that I don't agree with you) :-)
Jon Harrop
Actually Clojure did steal me: they are requesting that I write books on
Clojure. Obviously I'm not going to waste my time writing books for CL...
Kenneth Tilton
> milanj wrote:
>> On Jun 24, 4:18 am, Jon Harrop <j...@ffconsultancy.com> wrote:
>>> stealing all of the intelligent members of the Lisp community.
>> I did not noticed anything like this, all smart lispers whose blogs i
>> read are still active, in fact they are so smart so bunch of them dont
>> post on c.l.l. ... also Clojure didnt stole you from us and that is a
>> real pity
>
> Actually Clojure did steal me: they are requesting that I write books on
> Clojure.
Reminds me of when my older brother would say he heard Mom calling me so
I would go away and leave him and his friends alone.
Don't fall for it, Jon!
kzo
Mark Tarver
Qi is close enough to Haskell in enough salient ways for this guy to
get an answer to his question by experiment. And he can mix and match
all these paradigms in one environment to get an answer he will find
convincing to him - which is probably the best way to learn.
ACL
> milanj wrote:
> >> stealing all of the intelligent members of the Lisp community.
>
> > I did not noticed anything like this, all smart lispers whose blogs i
> > read are still active, in fact they are so smart so bunch of them dont
> > post on c.l.l. ... also Clojure didnt stole you from us and that is a
> > real pity
>
> Actually Clojure did steal me: they are requesting that I write books on
> Clojure. Obviously I'm not going to waste my time writing books for CL...
>
> --
Agreed, no money in writing books for CL when there are already so
many good ones that are in the public domain or otherwise already
written. I mean, anyone who reads this group or reddit regularly knows
that you have a real hard-on for CL but just couldn't cut it our book
market.
But JH, you have to consider the consequences of this 'Clojure Book'.
1.) I will still /not/ buy it, because it is written by you.
2.) You will be (potentially forced) to make troll and spam posts that
are actually on topic.
3.) You might have to concede that there are good parts of common
lisp. (Stuff you cannot do easily in Ocaml or F#).
Larry Coleman
> On Jul 3, 5:55 pm, JH wrote:
>
> > milanj wrote:
> > > On Jun 24, 4:18 am, JH wrote:
> > >> stealing all of the intelligent members of the Lisp community.
>
> > > I did not noticed anything like this, all smart lispers whose blogs i
> > > read are still active, in fact they are so smart so bunch of them dont
> > > post on c.l.l. ... also Clojure didnt stole you from us and that is a
> > > real pity
>
> > Actually Clojure did steal me: they are requesting that I write books on
> > Clojure. Obviously I'm not going to waste my time writing books for CL...
>
> > --
>
> Agreed, no money in writing books for CL when there are already so
> many good ones that are in the public domain or otherwise already
> written. I mean, anyone who reads this group or reddit regularly knows
> that you have a real hard-on for CL but just couldn't cut it our book
> market.
>
Nicolas Neuss
> Agreed, no money in writing books for CL when there are already so
> many good ones that are in the public domain or otherwise already
> written.
However, one book that I eagerly await is Conrad Barski's "Land of Lisp"
which seems to linger in some limbo state. I think I'll preorder it in the
hope that this will speed things up a bit.
Nicolas
[To ACL: Sorry for replying by email first.]
Slobodan Blazeski
wrote:
Don't forget Nick Levine's Lisp outside the Box http://lisp-book.org/
Jon Harrop
> ACL <anonymous...@gmail.com> writes:
>> Agreed, no money in writing books for CL when there are already so
>> many good ones that are in the public domain or otherwise already
>> written.
>
> However, one book that I eagerly await is Conrad Barski's "Land of Lisp"
> which seems to linger in some limbo state.
Why do you eagerly await it?
Jon Harrop
> I think he also likes Haskell more than he is willing to admit.
Sure, they all have their merits but none of them have what I want right
now.
chthon
> > In general, there are reasonably good compilers there, where you won't
> > need so much hints.
>
> Can you mention some of the best compilers?
>
> > My weakest point for Common Lisp so far has been ME - I have to mend
> > myself to the language, rather than trying to use it, the way I've been
> > using past languages
>
> I believe for me that's true, because if the past languages a
> programmer has used were mainly imperative, than a different paradigm,
> I guess, would require them to change the way mind thinks about
> problems. I don't see programming just as a way for creating software
> but as a whole different way of thinking about problems and solutions.
> (Sometimes even in every-day life!).
>
> I remember myself about two years ago when I decided to start learning
> Haskell. I couldn't even understand the Hello World example.
> Finally, after a week I gave up. Since then I have retried 3 other
> times to learn Haskell and only the last time I had that bliss where
> strangely, in a matter of milliseconds, like a hammer behind the head,
> the code changed completely in front of my eyes and there it was like
> truly it is, simple and beautiful and full with meaning like never
> before. :)
> Same thing happened me with Prolog too. I retried about 3 or 4 times
> to learn it. But only after getting to understand Haskell, I suddenly
> could understand Prolog too and strangely seemed so easy.
>
> The reason for this, I believe, was that my mind was accustomed with
> the imperative way of thinking and it needed some time (and perhaps
> luck too!!!) to get the functional and logic as well.
>
> Anyway thank you for your detailed response and god luck in mastering
> Lisp ans Haskell.
>
> Best regards,
> Elton.
A good way to remove the imperative way of thinking is reading "How To
Design Programs" and doing the exercises. It uses Scheme and is really
a good book to transition from imperative languages to more functional
languages.
Regards,
Jurgen
chthon
> Haskell that atracts me and makes me believe that maybe there'll be
> something promising.
>
> I use the same setup SLIME + SBCL and I'm really starting to love
> Emacs.
There used to be 'Two Dozen Short Lessons in Haskell' on the Internet,
but now it has become a book and you cannot find it anymore. I do have
an old version though, if you are interested.
Regards,
Jurgen
Nicolas Neuss
> Nicolas Neuss wrote:
>> However, one book that I eagerly await is Conrad Barski's "Land of Lisp"
>> which seems to linger in some limbo state.
>
> Why do you eagerly await it?
Hmm, good question. I think I like his Lisp alien, the "Lisp is different"
cartoon and the Macro short course on http://www.lisperati.com/casting.html
at least sufficiently much that I would like to buy and take a look at the
book.
Nicolas
Larry Coleman
This raises a question of the kind that I generally don't ask because
I know in advance that I won't like the answer:
So what do you want from a programming language?
Xah Lee
> !!!@!!! wrote:
> > I'm not trying to start a flame war about which one is the best. Could
> > anybody explain me each of these languages features and strong points ?
>
> code at compile-time) and run-time code evaluation. Was a pioneering
> functional language decades ago but has long since been superceded. Has no
> particular strengths today and, hence, is very rare. Main weaknesses are
> baggage, poor performance, bad implementations and a really backward
> community. The only notable development around Lisp for a decade is the new
> programming language Clojure that runs on the JVM. In particular, Clojure
> addressed many of Lisp's major problems by dropping the baggage, building
> intelligent members of the Lisp community.
>
> used to implement many radical ideas that are unlikely to be of any
> immediate use. Main strength is that it abstracts the machine away
> entirely, allowing some solutions to be represented very concisely. Main
> weakness is that it abstracts the machine away entirely, rendering
> performance wildly unpredictable (will my elegant program terminate in my
> lifetime? who knows...).
>
> I know little about Prolog except that it was designed specifically for
> logic programming (i.e. solving problems by specifying relations and
> searching for solutions) and that some of our customers use it.
i heartily disagree.
In my opinion:
• lisp = useless old shit.
• haskell = useless academic shit.
• prolog = useless old and academic shit.
• Qi Lisp = Academically confined. Esoteric. Abtruse. Unreadible.
Doomed.
• Clojure lisp = of little future due to competition.
• Mathematica = Widely used. Wildly successful. witness A New Kinda
Science & Wolfram Alpha.
• OCaml = Widely used. Wildly successful. Almost all formal proof
systems that are actively used are written in OCaml. And Microsoft
giant's version of OCaml, the F#, with .NET, is about to wipe out the
planet of imperative monkies.
References:
• Language, Purity, Cult, and Deception
http://xahlee.org/UnixResource_dir/writ/lang_purity_cult_deception.html
• Proliferation of Computing Languages
http://xahlee.org/UnixResource_dir/writ/new_langs.html
• What Languages to Hate
http://xahlee.org/UnixResource_dir/writ/language_to_hate.html
• Xah's OCaml Tutorial
http://xahlee.org/ocaml/ocaml.html
Xah
∑ http://xahlee.org/
☄
Don Geddis
So, why do you post on this newsgroup, c.l.l? It's clearly for people who
are interested in Lisp. If you're not, why are you here?
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
Men occasionally stumble over the truth, but most of them pick themselves up
and hurry off as if nothing had happened. -- Winston Churchill (1874-1965)
Jon Harrop
> So what do you want from a programming language?
Excellent question. I've never really tried to enumerate it before...
Performance: the predictably-excellent performance of OCaml but with
monomorphization during JIT to remove the overhead of polymorphism and with
F#-style inlined HOFs to facilitate efficient abstraction. OCaml's x64
codegen is awesome but its x86 codegen leaves a lot of room for
improvement. However, MLton, SMLNJ, GHC, SBCL, Bigloo etc. don't seem to be
any better (except perhaps for the SSE support just added to SBCL but I
haven't tried it yet).
Data representation: should be as close to C as possible for easy interop.
For example, tuples should be C structs (at the expense of polymorphic
recursion).
Interoperability: use JIT compilation as Lisp and .NET do, with FFI code
defined entirely in the HLL.
Syntax: Indentation-sensitive syntax as in Python, Haskell and F# was a huge
design mistake because cut'n'paste from a browser can break code
semantically by altering the indentation, and it prohibits autoindentation
leaving you to reindent huge swaths of code by hand. Lisps got it wrong by
oversimplifying the syntax, making math particularly cumbersome. OCaml got
it wrong mainly by being too complex (e.g. a dozen different kinds of
brackets instead of consistent brackets and identifiers to distinguish
between lists, arrays, streams etc.) and by using unconventional operators
(e.g. ** for power and ^ for string concatenation).
Macros: can be nice but they're abused far more often than they're used.
Missing language features should be fixed at source in the compiler instead
of being retrofitted in an ad-hoc way using macros. OCaml and Lisp are both
bad for this but it is still better that being stuck with limitations as in
SML and Haskell.
Parallelism: wait-free work-stealing deques like Cilk and Microsoft's TPL.
Concurrent GC: OCaml and Python could not be worse in this respect. Haskell
(and SBCL?) are slightly better with parallel but non-concurrent
collectors. The JVM and CLR (especially in .NET 3.5 SP1) are the gold
standard, of course.
Libraries: Nothing on Linux comes close to Windows Presentation Foundation
for robustly-deployable hardware accelerated UIs but open source
computational libraries on Linux put even the most expensive commercial
offerings on Windows to shame. I'd like the best of both worlds in the
standard library and running reliably on *lots* of machines.
Interface: I want a Mathematica notebook interface with typesetting and
integrated visualization instead of plain text.
Type system: OCaml's static type system is invaluable but OCaml lacks
generic typesetting, type-safe serialization and type classes. Optional
dynamic typing can also be valuable, e.g. we're now using it in our F#
products to make the REPL easier to use:
http://fsharpnews.blogspot.com/2009/06/f-for-visualization-0400-released.html
FWIW, I'm going to try to implement as much of this as possible in HLVM:
http://hlvm.forge.ocamlcore.org/
Friedrich Dominicus
> I'm not trying to start a flame war about which one is the best. Could
> anybody explain me each of these languages features and strong
> points ?
Then the question should not be Lisp vs Haskell vs Prolog but
Lisp and Haskell and Prolog, which to use when?
--
Please remove just-for-news- to reply via e-mail.
Vassil Nikolov
On Fri, 10 Jul 2009 00:32:57 +0100, Jon Harrop <j...@ffconsultancy.com> said:
> ...
> unconventional operators (e.g. ** for power ...)
That is an at-least-55-year-old convention. How much more
conventional can it get?
---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
Frank Buss
> Thank you Tom, but I have already tried Google and Wikipedia and they
> have been more than helpful in some other way.
> But if you read my last post, I'm looking to get information from
> experiences in a more specific way, not from an encyclopedic-like
> general way. I want to get information about the position of these
> languages/tools in the software industry by their characteristics to
> be more correct.
Ok, let's start a discussion, there are really too few language flame wars
in this newsgroup :-)
Wikipedia says a bit about applications in Common Lisp:
http://en.wikipedia.org/wiki/Common_lisp#Applications
It doesn't mention that this is the complete list of bigger applications
ever written in Lisp and even Jak and Daxter was not Common Lisp.
Lisp isn't used very much in the software industry. Most of the time C,
Java, Python, PHP and other mainstream languages are used, see e.g. the
projects on Sourceforge. There are 197 Prolog projects, 492 Lisp projects,
120 Haskell projects, but for example 42832 Java projects, 32420 C
projects, 28828 PHP projects and 13412 Python projects:
http://sourceforge.net/softwaremap/trove_list.php?form_cat=177
http://sourceforge.net/softwaremap/trove_list.php?form_cat=170
http://sourceforge.net/softwaremap/trove_list.php?form_cat=451
http://sourceforge.net/softwaremap/trove_list.php?form_cat=198
http://sourceforge.net/softwaremap/trove_list.php?form_cat=164
http://sourceforge.net/softwaremap/trove_list.php?form_cat=183
http://sourceforge.net/softwaremap/trove_list.php?form_cat=178
I assume this reflects the number of programmers who used this in the
software industry as well, so Lisp or Haskell are using only about 2% of
all programmers.
This is dangeraous for big companies, because there are not enough people
who can write and maintain good software in these languages, which is the
reason why e.g. Yahoo store was rewritten in C and Perl or why Naugthy Dog
are using C++ now:
http://www.gamasutra.com/features/20020710/white_03.htm
Personally I know of a project for an insurance company which was written
in Prolog for risk analysis. After the programmer left the company, nobody
could understand and maintain the system, so it was rewritten in Java.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Vassil Nikolov
On Fri, 10 Jul 2009 09:42:46 +0200, Frank Buss <f...@frank-buss.de> said:
> ...
> Personally I know of a project for an insurance company which was written
> in Prolog for risk analysis. After the programmer left the company, nobody
> could understand and maintain the system, so it was rewritten in Java.
He had bought a large map representing the sea
Without the least vestige of land
And the crew were all happy as they found it to be
A map they could all understand.
(Fit the Second, I think, quoting from memory.)
---Vassil,
who couldn't resist...
Frank Buss
> Libraries: Nothing on Linux comes close to Windows Presentation Foundation
> for robustly-deployable hardware accelerated UIs
Do you know Qt and wxWidgets? Both libraries are really nice and the GUI
editor for Qt is as complete as for WPF, but if you are using layout
managers, you can't do bugs like this one with the buttons in the bottom
area, found in Microsoft Visual Studio 2008:
http://www.frank-buss.de/tmp/gui-bug.jpg
I don't know if Microsoft practices "eat your own dogfood" and if they are
using WPF, but this is not a good publicity for their framework.
wxWidgets has some nice GUI editors, too and it uses the native controls of
the operating system, so I assume they are hardware accelerated, but why is
this important for a GUI, if you just want to display some text and edit
fields and not realtime 3D animation?
Qt is available as LGPL, now that Nokia bought Trolltech for Windows (last
year it was available for Windows as commercial, only). wxWidget is
available for Win32, Mac OS X, GTK+, X11, Motif, WinCE, and more, and has a
LPGL-like licence.
fft1976
> Larry Coleman wrote:
> > So what do you want from a programming language?
>
> Excellent question. I've never really tried to enumerate it before...
(snip)
This "being functional" is an unhealthy obsession. 3/4 of the time
imperative idioms are more convenient, and 1/4 of the time functional
ones are more convenient.
But because most popular languages are imperative, people are whining
about those 1/4 cases and some disturbed individuals even think
languages should be pure-functional.
What I want is a safe (or has an option to be safe), fast mostly
imperative language that doesn't suck.
C++ (if you are very good and very careful), Java and OCaml are
decent, but not quite what I want. Maybe D and Ada, although I don't
know about those.
Rainer Joswig
> !!!@!!! wrote:
> > Thank you Tom, but I have already tried Google and Wikipedia and they
> > have been more than helpful in some other way.
> > But if you read my last post, I'm looking to get information from
> > experiences in a more specific way, not from an encyclopedic-like
> > general way. I want to get information about the position of these
> > languages/tools in the software industry by their characteristics to
> > be more correct.
>
> Ok, let's start a discussion, there are really too few language flame wars
> in this newsgroup :-)
>
> Wikipedia says a bit about applications in Common Lisp:
>
> http://en.wikipedia.org/wiki/Common_lisp#Applications
>
> It doesn't mention that this is the complete list of bigger applications
> ever written in Lisp and even Jak and Daxter was not Common Lisp.
Nice try Frank. Fine to get this discussion going for the nth time.
But please try not to follow 'Harrop' style, post wrong things and
wait for people to correct it.
You should come to the Lisp meeting organized by Edi Weitz and Arthur
Lemmens
in Hamburg: http://weitz.de/eclm2009/
I'm pretty sure several people can tell you a bit about the
applications
they are writing or have written. If you were a bit more familiar with
the
domains Common Lisp is used mostly, you would know that there
are thousands of applications written in Common Lisp. That you don't
know them does not mean they don't exist.
Btw.: the DEVELOPMENT ENVIRONMENT for Jak and Daxter was written in
Common Lisp. It included a compiler for a Scheme like language,
which runs on the Playstation 2.
...
> This is dangeraous for big companies, because there are not enough people
> who can write and maintain good software in these languages, which is the
> reason why e.g. Yahoo store was rewritten in C and Perl or why Naugthy Dog
> are using C++ now:
>
> http://www.gamasutra.com/features/20020710/white_03.htm
Naughty Dog says this about their decision not to use Lisp for the
Playstation 3:
"In all honesty, the biggest reason we're not using GOAL for next-gen
development is because we're now part of Sony. I can only imagine
Sony's shock when they purchased Naughty Dog a few years back, hoping
to be able to leverage some of our technology across other Sony
studios, and then realized that there was no way anyone else would be
able to use any of our codebase. :)
Sony wants us to be able to share code with other studios, and this
works both ways - both other studios using our code and vice versa.
Add this to the difficulty curve of learning a new language for new
hires, lack of support from external development tools (we had our own
compiler, linker, and debugger, and pretty much had to use Emacs as
our IDE), etc, means that there are clearly a lot of other factors
involved. Note, however, that these issues aren't really technical
problems, they're social ones.
I can definitively say that the investment in GOAL was worth it for
our PS2 titles, despite the initial setup time and maintenance. Our
productivity gains were huge, and were more than worth the time
investment. This time around, however, the circumstances aren't quite
the same. If we were still an independent studio, I'm almost positive
we'd be extending GOAL for the next-generation of development. As it
is, we are looking into alternative approaches (custom preprocessors,
assemblers, linkers, you name it) - but all of these approaches fall
short in many ways of the unified language and environment we had with
GOAL.
That said, if there was a serious effort on the part of the game
development community to develop and standardize a language for game
development, everyone could gain the benefits without suffering the
drawbacks (lack of code-sharing, learning curve, etc). And if there's
enough community support, it would only be a matter of time before
some really high-quality commercial tools came out to work with the
language."
But now Naughty Dog uses Scheme again.
http://www.naughtydog.com/corporate/press/GDC%202008/AdventuresInDataCompilation.pdf
Frank Buss
> What I want is a safe (or has an option to be safe), fast mostly
> imperative language that doesn't suck.
>
> C++ (if you are very good and very careful), Java and OCaml are
> decent, but not quite what I want. Maybe D and Ada, although I don't
> know about those.
You could try Common Lisp: It is nice for imperative code and doesn't suck
as much as C++ for functional code :-)
fft1976
> fft1976 wrote:
> > What I want is a safe (or has an option to be safe), fast mostly
> > imperative language that doesn't suck.
>
> > C++ (if you are very good and very careful), Java and OCaml are
> > decent, but not quite what I want. Maybe D and Ada, although I don't
> > know about those.
>
> You could try Common Lisp: It is nice for imperative code and doesn't suck
> as much as C++ for functional code :-)
>
It's probably inconceivable to you, but I, like 99.9% of other
programmers, respectfully disagree.
Alessio Stalla
I hope you don't disagree about C++ sucking at functional
programming... so you must disagree about Lisp being nice at
imperative code. While for heavily imperative algorithms, C-like
languages are likely to be more compact than Lisp (whether this
implies "more readable" depends on the reader), I find in my
experience with Java, and C++ shouldn't be much different, that in
practice heavily imperative code tends to be scarcer than what people
commonly think. Most of my Java methods are less than 20 lines long,
many are shorter. And of those lines, half or so at least are calls to
other methods, not loops or assignments or increments etc.
Maybe your experience is different. But for me, Lisp is more than fine
for occasional imperative code. Of course, if you try to write C in
Lisp it will come out pretty horrible, just like if you try to write
Lisp in Java (sigh...).
Cheers,
Alessio
Frank Buss
> You should come to the Lisp meeting organized by Edi Weitz and Arthur
> Lemmens
> in Hamburg: http://weitz.de/eclm2009/
Thanks, but my focus has shifted a bit. Currently I'm trying to learn piano
playing in my spare time :-)
http://www.youtube.com/user/frankbuss
and sometimes doing some interesting computing stuff, e.g. magnetic flux
calculation with graphics cards:
http://groups.google.com/group/de.sci.electronics/browse_thread/thread/619614473c54d3df
> I'm pretty sure several people can tell you a bit about the
> applications
> they are writing or have written. If you were a bit more familiar with
> the
> domains Common Lisp is used mostly, you would know that there
> are thousands of applications written in Common Lisp. That you don't
> know them does not mean they don't exist.
You are right, this was a bit exaggerated by me. But the point is that
there are millions of applications in C-like languages, so I think at least
it is true, that there are less than 2% Lisp programmers and programs. Of
course, this doesn't mean that C is better than Lisp. It is better, if you
want to get a programming job, but if you are a good Lisp and a good C
programmer, I think it is easier to implement a given problem in Lisp.
> But now Naughty Dog uses Scheme again.
>
> http://www.naughtydog.com/corporate/press/GDC%202008/AdventuresInDataCompilation.pdf
I don't see that they are using it again. They write that they are planning
to use it ("We will build DC in Scheme") and the presentation has some C++
examples, too, so looks like it will be a mix of Scheme and C++, using the
Scheme part for data definitions, which are accessed from C++.
Rainer Joswig
> Rainer Joswig wrote:
> > You should come to the Lisp meeting organized by Edi Weitz and Arthur
> > Lemmens
> > in Hamburg:http://weitz.de/eclm2009/
>
> Thanks, but my focus has shifted a bit. Currently I'm trying to learn piano
> playing in my spare time :-)
Hmm, so you post here though your focus shifted? You are not
interested
in meeting Lisp people, your focus shifted, but you tell us at most
five applications
are written in Lisp? Strange.
> > I'm pretty sure several people can tell you a bit about the
> > applications
> > they are writing or have written. If you were a bit more familiar with
> > the
> > domains Common Lisp is used mostly, you would know that there
> > are thousands of applications written in Common Lisp. That you don't
> > know them does not mean they don't exist.
>
> You are right, this was a bit exaggerated by me. But the point is that
> there are millions of applications in C-like languages, so I think at least
> it is true, that there are less than 2% Lisp programmers and programs. Of
> course, this doesn't mean that C is better than Lisp. It is better, if you
> want to get a programming job, but if you are a good Lisp and a good C
> programmer, I think it is easier to implement a given problem in Lisp.
Hmm, what you say is trivially known. Everybody knows that there
are more C programmers than Lisp programmers. What is new?
2% of millions of applications can be quite a lot in absolute
numbers and does not say much about the importance and the value
of these applications to their users.
There are also more VW rabbits than Mercedes Unimogs. But what does
it say really? There are more drivers able to drive a VW rabbit?
Great, let's do some forest work with the VW rabbit.
>
> > But now Naughty Dog uses Scheme again.
>
> > http://www.naughtydog.com/corporate/press/GDC%202008/AdventuresInData...
>
> I don't see that they are using it again. They write that they are planning
> to use it ("We will build DC in Scheme") and the presentation has some C++
> examples, too, so looks like it will be a mix of Scheme and C++, using the
> Scheme part for data definitions, which are accessed from C++.
A mix of C++ and Scheme equals zero Scheme? I don't understand your
arithmetic.
Is use of Scheme valid only if all software is written in Scheme?
This describes where and how they use Scheme and what they use else:
http://www.naughtydog.com/corporate/press/GDC%202008/UnchartedTechGDC2008.pdf
Frank Buss
> Hmm, so you post here though your focus shifted? You are not
> interested
> in meeting Lisp people, your focus shifted, but you tell us at most
> five applications
> are written in Lisp? Strange.
There is nothing strange about it. I'm still interested in Lisp, but more
in piano playing :-)
> A mix of C++ and Scheme equals zero Scheme? I don't understand your
> arithmetic.
I didn't wrote that they don't use Scheme, I just added the missing
information from your post that they are using it in combination with C++.
> Is use of Scheme valid only if all software is written in Scheme?
No. I think it is a good idea to mix different languages. Each language has
its pros and cons, e.g. Scheme could be nice for scripting and representing
data and C is nice for graphic card shaders.
> This describes where and how they use Scheme and what they use else:
>
> http://www.naughtydog.com/corporate/press/GDC%202008/UnchartedTechGDC2008.pdf
I don't see details how they used Scheme, but on page 20 they write, that
initially they used it for creating data structures, later scripting and
other things.
Rainer Joswig
> Rainer Joswig wrote:
> > Hmm, so you post here though your focus shifted? You are not
> > interested
> > in meeting Lisp people, your focus shifted, but you tell us at most
> > five applications
> > are written in Lisp? Strange.
>
> There is nothing strange about it. I'm still interested in Lisp, but more
> in piano playing :-)
So you are going to be a professional piano player? Why piano?
There are many more people playing other instruments.
You can also get more music pieces for other instruments!
Isn't the guitar more popular in mainstream music?
Why not use a more modern instrument? If you use a
computer sequencer you could check your notes before playing
and that would greatly reduce the possibility of false
notes! I'd say the piano has been superseded by more modern
instruments long ago! Btw, I have written a book:
Synthesizer for Scientists.
You should read it!
> > A mix of C++ and Scheme equals zero Scheme? I don't understand your
> > arithmetic.
>
> I didn't wrote that they don't use Scheme, I just added the missing
> information from your post that they are using it in combination with C++.
>
> > Is use of Scheme valid only if all software is written in Scheme?
>
> No. I think it is a good idea to mix different languages. Each language has
> its pros and cons, e.g. Scheme could be nice for scripting and representing
> data and C is nice for graphic card shaders.
>
> > This describes where and how they use Scheme and what they use else:
>
> >http://www.naughtydog.com/corporate/press/GDC%202008/UnchartedTechGDC...
>
> I don't see details how they used Scheme, but on page 20 they write, that
> initially they used it for creating data structures, later scripting and
> other things.
Dan Liebgold says:
We build upon this basis to create many many things
Particle definitions
Animation states
Gameplay scripts
Scripted in-gamecinematics
Weapons tuning
Sound and voice setup
Overall game sequencing and control
I would say that's quite substantial...
Frank Buss
> So you are going to be a professional piano player?
No, it's just a hobby, like Lisp programming :-)
> Why piano?
> There are many more people playing other instruments.
> You can also get more music pieces for other instruments!
> Isn't the guitar more popular in mainstream music?
> Why not use a more modern instrument? If you use a
> computer sequencer you could check your notes before playing
> and that would greatly reduce the possibility of false
> notes! I'd say the piano has been superseded by more modern
> instruments long ago!
Nice analogy! I have an electronic piano and it has a MIDI interface for
interfacing with a PC. And there are even sequencers, where you can setup
note and velocity quantizing, but the recording looses lots of expression.
And no synthesizer can produce such a wide range of nuances like a good old
real grand piano, which I play every week at a music school.
Compared to other instruments, a piano can produce lots of different styles
of music, which is impossible with other instruments, or at least doesn't
sound as good and e.g. a guitar has much less octaves than a grand piano.
Larry Coleman
> Larry Coleman wrote:
> > So what do you want from a programming language?
>
> Excellent question. I've never really tried to enumerate it before...
>
is, everyone has a different idea about how the One Ring should look
and work. As a result, we either complain and annoy those who are
basically happy with the status quo and are actually writing stuff, or
we implement yet another ultimate programming language.
I'm sure you'll be happy with HLVM when it's done. However, the next
guy will look at it, say "WTF?", and implement his own personal Ring.
I think a better approach for the rest of us is to find one or more
platforms that are "good enough" (CL and Haskell both work for me) and
start coding apps and libraries.
Rainer Joswig
The market for grand pianos is tiny compared to the market for
synthesizers.
Also Google returns many more hits for "synthesizer" than for "grand
piano".
You can also see that Google trends shows less and less searches
for "grand piano". Also the best piano players have switched to more
modern instruments long ago. The only hope I would have is with a
more modern version that is not bound by the historical baggage
of old music, old fashioned piano design, and the limited amount of
sounds
it can produce.
Nicolas Neuss
> The market for grand pianos is tiny compared to the market for
> synthesizers. Also Google returns many more hits for "synthesizer" than
> for "grand piano". You can also see that Google trends shows less and
> less searches for "grand piano". Also the best piano players have
> switched to more modern instruments long ago. The only hope I would have
> is with a more modern version that is not bound by the historical baggage
> of old music, old fashioned piano design, and the limited amount of
> sounds it can produce.
:-) But you should still add a link to your "Flying Music Consultancy"...
Nicolas
Michael Livshin
> :-) But you should still add a link to your "Flying Music Consultancy"...
nah, we get it, no need to overdo things. :)
cheers,
--m
Jon Harrop
> On Fri, 10 Jul 2009 00:32:57 +0100, Jon Harrop <j...@ffconsultancy.com>
> said:
>> ...
>> unconventional operators (e.g. ** for power ...)
>
> That is an at-least-55-year-old convention. How much more
> conventional can it get?
Superscript is more conventional.
Duane Rettig
Don't forget non-portability. And have you ever played on a good
Grand Piano after playing on a nice, cheap, synthesized piano? The
keys are hard to press, and that you have to press the keys at all is
just ludicrous - give me a good, cheap, player piano any day.
:-)
Duane
Jon Harrop
> Jon Harrop wrote:
>> Libraries: Nothing on Linux comes close to Windows Presentation
>> Foundation for robustly-deployable hardware accelerated UIs
>
> Do you know Qt and wxWidgets?
Yes, of course. Neither even attempt to provide hardware accelerated GUIs as
WPF does.
> Both libraries are really nice
They could barely be any worse. Even their own demo programs segfault
because the foundations they are built upon are rotten to the core.
Look at the use of first-class lexical closures in WPF, for example. Suffice
to say, C++ is nowhere near competitive in this respect.
> and the GUI editor for Qt is as complete as for WPF,
Nowhere near. WPF's GUI editor generates high-level safe interoperable code
than runs on .NET. I can call it directly from F# to generate binary
executables that millions of people can run directly.
Qt is a generation behind, generating code in a proprietary dialect of C++
that could barely be less safe or interoperable. I cannot even use Qt
directly from OCaml and, if I could, any compiled binaries would be brittle
with respect to the exact versions on all libraries on my machine so they
would segfault on the vast majority of other machines. So the only
practical option is to distribute source code and ask users to recompile it
or distro maintainers to create custom packages for it. That throws up
barriers to commercial software on Linux. Moreover, if you even try to
discuss making Linux more commerce friendly, you get trampled by millions
of freeloaders who want to impose "freedom" upon people by taking that
choice away from them. Hence the quality of software on Linux is already
bad and is getting worse.
And I suppose I would be expected to go back to battling with bugs in the
g++ toolchain? No thanks. I dropped that crappy language and implementation
years ago for good reasons and have no intention of going backwards.
> but if you are using layout
> managers, you can't do bugs like this one with the buttons in the bottom
> area, found in Microsoft Visual Studio 2008:
>
> http://www.frank-buss.de/tmp/gui-bug.jpg
Firstly, that software isn't even using WPF. Secondly, KDE is riddled with
similar rendering bugs.
> I don't know if Microsoft practices "eat your own dogfood" and if they are
> using WPF, but this is not a good publicity for their framework.
WPF is in VS 2010.
> wxWidgets has some nice GUI editors, too and it uses the native controls
> of the operating system, so I assume they are hardware accelerated, but
> why is this important for a GUI, if you just want to display some text and
> edit fields and not realtime 3D animation?
Are you seriously asking why someone developing a *graphical* user interface
might be interested in decent graphics?
> Qt is available as LGPL, now that Nokia bought Trolltech for Windows (last
> year it was available for Windows as commercial, only). wxWidget is
> available for Win32, Mac OS X, GTK+, X11, Motif, WinCE, and more, and has
> a LPGL-like licence.
Sure. Neither are remotely close to providing what I was asking for.
GUI libraries should be written in safe languages and they should use a
highly-reliable subset of the low-level rendering libraries for hardware
accelerated graphics. Qt and wxWidgets are both written in unsafe low-level
languages and neither make any attempt to hardware accelerate the contents
of windows. You can make completely uninteroperable use of the whole of
OpenGL but it is entirely unsafe, e.g. you can screw up the rendering
context for the next Window and cause widespread corruption.
GUI libraries should be interoperable so that many programming languages can
reap the benefits of a single mature GUI framework. Qt is written in a
proprietary dialect of C++ which is extremely difficult to interoperate
with. This essentially requires some kind of common language run-time but,
of course, Linux doesn't have any that support basic features like TCO.
GUI libraries should be written in high-level languages. The idea of trying
to write a decent framework without garbage collection is now laughable.
Finally, writing a GUI library is actually comparatively easy. The hard part
is building the foundation upon which everything is built, i.e. the safe
interoperable VM. Linux desperately needs such a thing but, so far, we're
stuck with the JVM and Mono.
Jon Harrop
> I think a better approach for the rest of us is to find one or more
> platforms that are "good enough" (CL and Haskell both work for me) and
> start coding apps and libraries.
I think that is an extremely bad idea because you're building on sand. The
very foundation of your applications and libraries is rotting.
Microsoft were right on the money when they built .NET as a rock solid
foundation for everyone to use going forward and they are right to put a
huge amount of effort into migrating as much old code to run on top of .NET
as possible. They are so far ahead of Linux now that it is just ridiculous.
For a start, you're advocating using at least two separate and
uninteroperable garbage collectors in CL and Haskell. That is obviously a
really bad idea, not to mention that no implementations of either CL or
Haskell have GCs comparable to those found in the JVM and .NET.
Larry Coleman
> Larry Coleman wrote:
> > I think a better approach for the rest of us is to find one or more
> > platforms that are "good enough" (CL and Haskell both work for me) and
> > start coding apps and libraries.
>
> I think that is an extremely bad idea because you're building on sand. The
> very foundation of your applications and libraries is rotting.
What does this even mean?
>
> Microsoft were right on the money when they built .NET as a rock solid
> foundation for everyone to use going forward and they are right to put a
> huge amount of effort into migrating as much old code to run on top of .NET
> as possible. They are so far ahead of Linux now that it is just ridiculous.
>
And for all that the .NET languages are so far inadequate to meet your
needs that you feel compelled to create yet another programming
environment.
> For a start, you're advocating using at least two separate and
> uninteroperable garbage collectors in CL and Haskell. That is obviously a
> really bad idea, not to mention that no implementations of either CL or
> Haskell have GCs comparable to those found in the JVM and .NET.
>
Actually, I'm only advocating picking something that works reasonably
well and getting on with it. I use either CL or Haskell according to
the task.
Also, I don't think you really got the point I was trying to make
earlier. So, let's ask this question: Don't you think the creators of
Ruby, Arc, Clojure, etc., all thought they were creating the ultimate
programming environment?
Ertugrul Söylemez
> > > So what do you want from a programming language?
> >
> > Excellent question. I've never really tried to enumerate it
> > before...
>
> (snip)
>
> This "being functional" is an unhealthy obsession. 3/4 of the time
> imperative idioms are more convenient, and 1/4 of the time functional
> ones are more convenient.
Fortunately that's just your opinion and not the reality. Even
Microsoft has found the value in functional programming. See F#. It's
scheduled to be packaged with Visual Studio in 2010, AFAIK. Also many
imperative languages are employing more and more functional concepts.
> But because most popular languages are imperative, people are whining
> about those 1/4 cases and some disturbed individuals even think
> languages should be pure-functional.
What's wrong with purely functional languages?
> What I want is a safe (or has an option to be safe), fast mostly
> imperative language that doesn't suck.
If you want safety, go for functional programming. About speed, most
decent functional languages aren't considerably slower than C, but given
that you save a lot of development time, you'll get your result much
faster.
Also purely functional languages (e.g. Haskell, Clean) and languages
with immutable data (e.g. F#) allow clean and concise algorithm
implementations, which are still just as fast as imperative variants
with explicit reference/memory handling. Finally with these two classes
of languages and additionally Erlang you get concurrency and parallelity
almost for free. Multithreaded programming is a PITA in all imperative
languages.
> C++ (if you are very good and very careful), Java and OCaml are
> decent, but not quite what I want. Maybe D and Ada, although I don't
> know about those.
Just in case you didn't notice, OCaml is a functional language.
However, nobody is "very good" and "very careful". C++ leaves too many
spots open for making mistakes. D is much better at that, if you insist
on imperative programming.
All in all you're just showing that you don't have a clue about
functional programming. Before making such unfounded claims, you'd
better try a functional language for more than 15 minutes. If you still
think that functional programming sucks, you should provide reasons to
support your claims.
Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
George Neuner
wrote:
You mean the 99.9% who have never tried Lisp?
Common Lisp (_not_ Scheme) offers assignment and imperative control
constructs - a variety of standard loops, case and typecase (like C
switch), labeled gotos, lexical block structures with named exit, etc.
Using named blocks, labels and gotos, you can define your own control
structures if you don't like the standard ones.
Although most programmers prefer to write in a more functional style,
Lisp's imperative constructs are used extensively for DSL code
generators and foreign code translators (C->Lisp, Pascal->Lisp,
SQL->Lisp, etc.).
That said, Lisp isn't for everyone ... if you don't like it - fine.
Just don't knock it without trying it.
George
Xah Lee
> So, why do you post on this newsgroup, c.l.l? It's clearly for people who
> are interested in Lisp. If you're not, why are you here?
See:
• Why do I Rant In comp.lang.lisp?
http://xahlee.org/UnixResource_dir/writ/why_comp_lang_lisp.html
In the past, i wouldn't have answered your idiotic question, because
it is off topic and all. But now i do, taking it as a chance to speak
for myself. Why? See:
• How Shall I Respond?
http://xahlee.org/Netiquette_dir/how_shall_i_respond.html
On retrospect of the article “Why do I Rant In comp.lang.lisp?”, i ask
myself whether i have achieved something about creating a book length
collection of my ideas and opinions. I must say yes i have. For
example, especially in the past few years, usually when i argue with
the tech geekers online, i can usually pull out a collection of some 5
or 10 essays of my opinions or tech expositions on a some particular
argued topic. For example of this, recent debate about lisp1 vs lisp2
in this very thread, i pulled out 10 essays about jargons:
• The Importance of Terminology's Quality In Computer Languages
http://xahlee.org/UnixResource_dir/writ/naming_functions.html
• Jargons of Info Tech Industry
http://xahlee.org/UnixResource_dir/writ/jargons.html
• Why You should Not Use The Jargon Lisp1 and Lisp2
http://xahlee.org/emacs/lisp1_vs_lisp2.html
• The Term Currying In Computer Science
http://xahlee.org/UnixResource_dir/writ/currying.html
• What Is Closure In A Programing Language
http://xahlee.org/UnixResource_dir/writ/closure.html
• What are OOP's Jargons and Complexities
http://xahlee.org/Periodic_dosage_dir/t2/oop.html
• Interface in Java
http://xahlee.org/java-a-day/interface.html
• Math Terminology and Naming of Things
http://xahlee.org/cmaci/notation/math_namings.html
• Politics and the English Language
http://xahlee.org/p/george_orwell_english.html
btw, your idiotic reply:
> So, why do you post on this newsgroup, c.l.l? It's clearly for people who
> are interested in Lisp. If you're not, why are you here?
is actually wrong, and is a common response to me in the past 10
years. People say that to me on Perl, Python groups, as well. I guess
i could spend few hours now and write another essay focused on
expounding this issue... and creating a addition to my essay
collection. Not sure i feel like that now though. But to quip, why are
YOU not interested in lisp?? if not, why r u here?? arn't u trolling?
Thanks for your troll, cause, without trolls like u, i wouldn't have
the chance, the spur, to have created my essays in the past decade.
Xah
∑ http://xahlee.org/
☄
George Neuner
wrote:
>On Jul 9, 4:32�pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>> Larry Coleman wrote:
>> > So what do you want from a programming language?
>>
>> Excellent question. I've never really tried to enumerate it before...
>
>(snip)
>
>This "being functional" is an unhealthy obsession. 3/4 of the time
>imperative idioms are more convenient, and 1/4 of the time functional
>ones are more convenient.
Only because that's what you are used to.
>But because most popular languages are imperative, people are whining
>about those 1/4 cases and some disturbed individuals even think
>languages should be pure-functional.
And they are wrong. Strict, impure functional languages are easier to
use and easier to reason about. Laziness is occasionally a good thing
to have, but it doesn't need to be built in - it can be implemented
reasonably on top of any language with closures.
>What I want is a safe (or has an option to be safe), fast mostly
>imperative language that doesn't suck.
Then why are you posting in groups that promote functional languages?
>C++ (if you are very good and very careful), Java and OCaml are
>decent, but not quite what I want. Maybe D and Ada, although I don't
>know about those.
I've always liked Modula-3. Ada is great if you are working on bare
hardware but IMO it is not a great general application language.
George
Jon Harrop
> fft1976 <fft...@gmail.com> wrote:
>> But because most popular languages are imperative, people are whining
>> about those 1/4 cases and some disturbed individuals even think
>> languages should be pure-functional.
>
> What's wrong with purely functional languages?
. Unpredictable performance.
. Unreliable.
. Uninteroperable.
>> What I want is a safe (or has an option to be safe), fast mostly
>> imperative language that doesn't suck.
>
> If you want safety, go for functional programming.
If you want to interoperate with code written in other languages then
functional languages like OCaml and Haskell are *less* safe than the JVM
and CLR because their FFIs are comparatively poorly designed and poorly
implemented.
> About speed, most decent functional languages aren't considerably slower
> than C,
That assertion is uselessly subjective. What are "decent" functional
languages? How much is "considerably" slower? Why are you comparing with C?
Are you assuming GCC and not Intel C++ (which often generates code that is
several times faster)?
The fastest BWT implementation written in Haskell, after weeks of
optimization by several experts, remained over 200x slower than C++:
http://www.mail-archive.com/haskell-cafe%40haskell.org/msg25645.html
So either Haskell is not "decent" or 200x slower is "not considerably
slower".
> but given that you save a lot of development time, you'll get your result
> much faster.
Not if your "result" is efficient code, which is often the case for
professional developers because their end users demand speed.
> Also purely functional languages (e.g. Haskell, Clean) and languages
> with immutable data (e.g. F#) allow clean and concise algorithm
> implementations, which are still just as fast as imperative variants
> with explicit reference/memory handling. Finally with these two classes
> of languages and additionally Erlang you get concurrency and parallelity
> almost for free.
GHC's stop-the-world GC does not scale so Haskell programmers obviously do
not get "parallelism almost for free".
> Multithreaded programming is a PITA in all imperative languages.
Cilk makes parallelism easy.
George Neuner
<alessi...@gmail.com> wrote:
>On Jul 10, 10:34�am, fft1976 <fft1...@gmail.com> wrote:
>> On Jul 10, 1:23�am, Frank Buss <f...@frank-buss.de> wrote:
>>
>> > fft1976 wrote:
>> > > What I want is a safe (or has an option to be safe), fast mostly
>> > > imperative language that doesn't suck.
>>
>> > > C++ (if you are very good and very careful), Java and OCaml are
>> > > decent, but not quite what I want. Maybe D and Ada, although I don't
>> > > know about those.
>>
>> > You could try Common Lisp: It is nice for imperative code and doesn't suck
>> > as much as C++ for functional code :-)
>>
>> It's probably inconceivable to you, but I, like 99.9% of other
>> programmers, respectfully disagree.
>
>I hope you don't disagree about C++ sucking at functional
>programming... so you must disagree about Lisp being nice at
>imperative code. While for heavily imperative algorithms, C-like
>languages are likely to be more compact than Lisp (whether this
>implies "more readable" depends on the reader), I find in my
>experience with Java, and C++ shouldn't be much different, that in
>practice heavily imperative code tends to be scarcer than what people
>commonly think. Most of my Java methods are less than 20 lines long,
>many are shorter. And of those lines, half or so at least are calls to
>other methods, not loops or assignments or increments etc.
Lots of little functions != functional programming
C++ and Java make functional programming possible, but neither makes
it particularly easy. It might get better in C++0X with the addition
of standard closures, but I doubt it ... the proposed syntax is too
messy and too similar to what Boost does now (which is horrible if
you've ever used a real FPL). Java's closures are no better ... far
too messy to use anonymously.
C++ at least has a simple function object syntax which doesn't
distract the programmer when using higher level functions - Java can't
even get that right. But the lack of multiple runtime dispatch in
both language forces unnatural, imperative "pattern" coding (C++ has
multiple compile time dispatch, but it's not the same).
>Maybe your experience is different. But for me, Lisp is more than fine
>for occasional imperative code. Of course, if you try to write C in
>Lisp it will come out pretty horrible, just like if you try to write
>Lisp in Java (sigh...).
A lot of Lisp programmers write what is essentially imperative code.
The only real difference is that they typically use binding more than
assignment. Personally I hate LOOP ... I learned it so I can read
other people's code, but I never use it myself.
George
Vend
> Fortunately that's just your opinion and not the reality. Even
> Microsoft has found the value in functional programming. See F#. It's
> scheduled to be packaged with Visual Studio in 2010, AFAIK. Also many
> imperative languages are employing more and more functional concepts.
F# is not purely functional.
> > But because most popular languages are imperative, people are whining
> > about those 1/4 cases and some disturbed individuals even think
> > languages should be pure-functional.
>
> What's wrong with purely functional languages?
>
> > What I want is a safe (or has an option to be safe), fast mostly
> > imperative language that doesn't suck.
>
> If you want safety, go for functional programming.
Why?
Type safety is orthogonal to the functional/imperative distinction.
> About speed, most
> decent functional languages aren't considerably slower than C, but given
> that you save a lot of development time, you'll get your result much
> faster.
However, if I understand correctly, purely functional languages
typically have performance problems.
> Also purely functional languages (e.g. Haskell, Clean) and languages
> with immutable data (e.g. F#) allow clean and concise algorithm
> implementations, which are still just as fast as imperative variants
> with explicit reference/memory handling.
This makes no sense, since you can always use mutable variables as if
they were immutable.
What makes functional languages more coincise is the availability of
first-class procedures.
Lazy evaluation can also improve expressivity, at the cost of
performance problems.
> Finally with these two classes
> of languages and additionally Erlang you get concurrency and parallelity
> almost for free. Multithreaded programming is a PITA in all imperative
> languages.
Again, these issues are orthogonal. Erlang's message passing model of
concurrency can be also used in imperative languages.
> > C++ (if you are very good and very careful), Java and OCaml are
> > decent, but not quite what I want. Maybe D and Ada, although I don't
> > know about those.
>
> Just in case you didn't notice, OCaml is a functional language.
But it is not pure.
> However, nobody is "very good" and "very careful". C++ leaves too many
> spots open for making mistakes. D is much better at that, if you insist
> on imperative programming.
>
> All in all you're just showing that you don't have a clue about
> functional programming. Before making such unfounded claims, you'd
> better try a functional language for more than 15 minutes. If you still
> think that functional programming sucks, you should provide reasons to
> support your claims.
He didn't say that functional programming sucks, he said that the
functional paradigm is useful 25% of times.
Raffael Cavallaro
> What's wrong with purely functional languages?
The "purely" part. Some solutions are naturally expressed in a pure
functional manner. Others are not. The programmer should have a choice.
Moreover, there's abundant linguistic and cognitive scientific evidence
that human beings naturally conceptualize the world in terms of
stateful entities and their mutation, not functionally, so imperative
languages fit our natural cognitive models better. This suggests that
DSLs will often include an imperative component in their surface syntax
at the very least.
--
Raffael Cavallaro
Frank Buss
> They could barely be any worse. Even their own demo programs segfault
> because the foundations they are built upon are rotten to the core.
Are we talking about the same library? Qt is a mature library, KDE and lots
of programs are based on it, QTopia and QTE works on lots of embedded
devices. I've never seen a segfault in one of the Qt demo programs. I've
tried version 4.4 on a x86 Linux box and the QTE version on an ARM embedded
device, for which I've developed my own graphics driver, which translates
the Qt calls to accelerated calls to an attached graphics chip. Qt has a
nice architecture to make such things very easy.
> Look at the use of first-class lexical closures in WPF, for example. Suffice
> to say, C++ is nowhere near competitive in this respect.
Yes, this could be a nice feature.
> Nowhere near. WPF's GUI editor generates high-level safe interoperable code
> than runs on .NET. I can call it directly from F# to generate binary
> executables that millions of people can run directly.
>
> Qt is a generation behind, generating code in a proprietary dialect of C++
> that could barely be less safe or interoperable.
This is only half of the truth: You can generate C++ code, but for a
commercial project e.g. I save the GUI forms as XML, which are loaded by
JavaScript, which is integrated in Qt and which has access to all GUI
elements. The GC and prototype based programming style of JavaScript is
very nice for GUI programming, e.g. you can use anonymous functions as
button handlers with a very simple syntax.
> I cannot even use Qt
> directly from OCaml and, if I could, any compiled binaries would be brittle
> with respect to the exact versions on all libraries on my machine so they
> would segfault on the vast majority of other machines. So the only
> practical option is to distribute source code and ask users to recompile it
> or distro maintainers to create custom packages for it. That throws up
> barriers to commercial software on Linux.
This is wrong. There are many way how to use Qt: On Linux there is no
problem with different versions of libraries, because it has a descent
version managment for shared libraries and you link your programs to the
right version, which you can deliver with your application, if not already
installed on the system. To avoid any problems, you can even link it
statically to your application.
I've just installed
http://get.qtsoftware.com/qtsdk/qt-sdk-win-opensource-2009.03.exe
Included in this release was even the compiler (based on MinGW) and with Qt
Creator an IDE you don't need any other program to start programming. There
is a demo, which just works, no "brittle" problems at all.
> And I suppose I would be expected to go back to battling with bugs in the
> g++ toolchain? No thanks. I dropped that crappy language and implementation
> years ago for good reasons and have no intention of going backwards.
Does WPF even exists for Linux? On Windows Qt works with Visual Studio,
which has not a perfect C++ compiler, but still good quality.
>> wxWidgets has some nice GUI editors, too and it uses the native controls
>> of the operating system, so I assume they are hardware accelerated, but
>> why is this important for a GUI, if you just want to display some text and
>> edit fields and not realtime 3D animation?
>
> Are you seriously asking why someone developing a *graphical* user interface
> might be interested in decent graphics?
I was thinking of warehouse applications, databases etc., but you are right
that you need accelerated graphics for multimedia applications etc. Thanks
Trolltech that they support it :-)
Jon Harrop
> Why?
> Type safety is orthogonal to the functional/imperative distinction.
Only in theory. In practice, functional languages (OCaml, Haskell) offer far
more expressive type systems than any available safe imperative language
implementation (Java, C#).
>> Also purely functional languages (e.g. Haskell, Clean) and languages
>> with immutable data (e.g. F#) allow clean and concise algorithm
>> implementations, which are still just as fast as imperative variants
>> with explicit reference/memory handling.
>
> This makes no sense, since you can always use mutable variables as if
> they were immutable.
That does not recover the properties of purely functional data structures.
Jon Harrop
> On Fri, 10 Jul 2009 01:34:49 -0700 (PDT), fft1976 <fft...@gmail.com>
> wrote:
>>On Jul 10, 1:23 am, Frank Buss <f...@frank-buss.de> wrote:
>>> You could try Common Lisp: It is nice for imperative code and doesn't
>>> suck as much as C++ for functional code :-)
>>
>>It's probably inconceivable to you, but I, like 99.9% of other
>>programmers, respectfully disagree.
>
> You mean the 99.9% who have never tried Lisp?
You say that as if Lisp had not been taught to millions of computer science
students, 99.9% of whom really do choose not to use Lisp.
Ertugrul Söylemez
> > Fortunately that's just your opinion and not the reality. Even
> > Microsoft has found the value in functional programming. See
> > F#. It's scheduled to be packaged with Visual Studio in 2010,
> > AFAIK. Also many imperative languages are employing more and more
> > functional concepts.
>
> F# is not purely functional.
So...?
> > > What I want is a safe (or has an option to be safe), fast mostly
> > > imperative language that doesn't suck.
> >
> > If you want safety, go for functional programming.
>
> Why?
> Type safety is orthogonal to the functional/imperative distinction.
Type safety is one kind of safety. The functional paradigm gives you
other types of safety, too, which doesn't require additional language
constructs like 'foreach'.
> > About speed, most decent functional languages aren't considerably
> > slower than C, but given that you save a lot of development time,
> > you'll get your result much faster.
>
> However, if I understand correctly, purely functional languages
> typically have performance problems.
That statement wasn't restricted to purely functional languages, but
despite Dr. Harrop's usual noise purely functional languages perform
quite well.
> > Also purely functional languages (e.g. Haskell, Clean) and languages
> > with immutable data (e.g. F#) allow clean and concise algorithm
> > implementations, which are still just as fast as imperative variants
> > with explicit reference/memory handling.
>
> This makes no sense, since you can always use mutable variables as if
> they were immutable.
You cannot in the same convenient way. With immutable data you can make
a function take a tree and return a slightly modified tree without much
programming effort.
> What makes functional languages more coincise is the availability of
> first-class procedures.
Modern imperative languages have that as well. Functional programming
is a paradigm, not a tool.
> Lazy evaluation can also improve expressivity, at the cost of
> performance problems.
Lazy evaluation is a semantic property. What it compiles to is a
different question. Particularly Haskell as the outrider in non-strict
semantics does quite well at that (with GHC).
> > Finally with these two classes of languages and additionally Erlang
> > you get concurrency and parallelity almost for free. Multithreaded
> > programming is a PITA in all imperative languages.
>
> Again, these issues are orthogonal. Erlang's message passing model of
> concurrency can be also used in imperative languages.
Erlang is inherently thread-safe. The other languages I mentioned get
that property partly through immutable data and partly through excellent
synchronization constructs.
> > > C++ (if you are very good and very careful), Java and OCaml are
> > > decent, but not quite what I want. Maybe D and Ada, although I
> > > don't know about those.
> >
> > Just in case you didn't notice, OCaml is a functional language.
>
> But it is not pure.
So...? The OP obviously doesn't like functional programming. That's my
point.
> > However, nobody is "very good" and "very careful". C++ leaves too
> > many spots open for making mistakes. D is much better at that, if
> > you insist on imperative programming.
> >
> > All in all you're just showing that you don't have a clue about
> > functional programming. Before making such unfounded claims, you'd
> > better try a functional language for more than 15 minutes. If you
> > still think that functional programming sucks, you should provide
> > reasons to support your claims.
>
> He didn't say that functional programming sucks, he said that the
> functional paradigm is useful 25% of times.
Yes, and he didn't support that statement by anything.
Ertugrul Söylemez
> > What's wrong with purely functional languages?
>
> The "purely" part. Some solutions are naturally expressed in a pure
> functional manner. Others are not. The programmer should have a
> choice.
They have a choice. A purely functional language has a theoretical
property, which is very useful. That doesn't mean you can't use the
things you're used to. You just don't -- usually.
> Moreover, there's abundant linguistic and cognitive scientific
> evidence that human beings naturally conceptualize the world in terms
> of stateful entities and their mutation, not functionally, so
> imperative languages fit our natural cognitive models better. This
> suggests that DSLs will often include an imperative component in their
> surface syntax at the very least.
And we all know that humans are far from perfect. They make mistakes
all the time just because of that cognitive property. Safety is all
about restricting this or finding alternatives.
Frank Buss
> You guys really are amazing!!! You're so good at starting flame
> wars!!! I don't understand why you make such useless debates about
> which programming languages is the best ?!?! Haven't you yet realised
> that you'll never come to a mutual opinion because you have different
> preferences and jobs that require different tools!?!?! You make
> robotic arguments of these languages features, sometimes without even
> have trying programming in these languages and you sound like you are
> reading a definition from an encyclopedia with a comunist like voice
> protecting his beloved mother language!!!
Hello !!!@!!!,
I know that many people discussing in this thread have much experience in
multiple languages and in the languages they are talking about. Maybe you
are talking to yourself regarding lack of experience?
Larry D'Anna
>
> The "purely" part. Some solutions are naturally expressed in a pure
> functional manner. Others are not. The programmer should have a choice.
Uh, in Haskell you absolutely do have a choice. Haskell gives the programmer
access to all the non-functional things you want: mutable cells, mutable arrays,
foreign functions, IO, etc. You just have to use monads to get to it all. You
can take any imperative algorithm you like and translate it into Haskell in a
totally straightforward way.
--larry
Ertugrul Söylemez
> > What's wrong with purely functional languages?
>
> . Unpredictable performance.
Wrong.
> . Unreliable.
Wrong (although right to some extent on PPC).
> . Uninteroperable.
Right. That's something that could use some improvement.
> > About speed, most decent functional languages aren't considerably
> > slower than C,
>
> That assertion is uselessly subjective. What are "decent" functional
> languages? How much is "considerably" slower? Why are you comparing
> with C? Are you assuming GCC and not Intel C++ (which often generates
> code that is several times faster)?
>
> The fastest BWT implementation written in Haskell, after weeks of
> optimization by several experts, remained over 200x slower than C++:
>
> http://www.mail-archive.com/haskell-cafe%40haskell.org/msg25645.html
>
> So either Haskell is not "decent" or 200x slower is "not considerably
> slower".
Hmm. This one took me about 10 minutes:
bwt :: B.ByteString -> B.ByteString
bwt str =
let sorted = map fst . sortBy (compare `on` snd) $ zip [0, 1..] (B.unpack str)
slen = B.length str
in B.pack . map (\i -> B.index str ((i-1) `mod` slen)) $ sorted
It's not optimal, because it uses list sorting. Replace it by an
in-place sort and you're set.
> GHC's stop-the-world GC does not scale so Haskell programmers
> obviously do not get "parallelism almost for free".
Right. It's not that it makes such a big difference anyway, but it
could be improved a lot. When using explicit threading in Haskell I
usually get c*n*100% of the performance of a single thread, where c is
some constant between 0.8 and 0.9 and n is the number of CPUs and
threads. Unfortunately this is not true for implicit parallelism using
strategies, but I don't believe that this can be improved a lot.
Ertugrul Söylemez
> > I know that many people discussing in this thread have much
> > experience in multiple languages and in the languages they are
> > talking about. Maybe you are talking to yourself regarding lack of
> > experience?
>
> See???
> This is what I was talking about.
> These arguments are useless and a waste of time.
> I am very thankful to you Frank that troubled yourself to post here
> and answer the questions of an 'lacked-experience' guy like me but if
> you don't have any other piece of wisdom to share with us I suggest
> you to not waste your time and tire your fingers to write here. But I
> supose you don't take suggestions from guys like me, do you?
=)
Slobodan Blazeski
> > But because most popular languages are imperative, people are whining
> > about those 1/4 cases and some disturbed individuals even think
> > languages should be pure-functional.
>
> What's wrong with purely functional languages?
They suck when the problem is not purely functional.
Slobodan
Larry Coleman
> On Jul 10, 1:10 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>
> > Larry Coleman wrote:
> > > I think a better approach for the rest of us is to find one or more
> > > platforms that are "good enough" (CL and Haskell both work for me) and
> > > start coding apps and libraries.
>
> > I think that is an extremely bad idea because you're building on sand. The
> > very foundation of your applications and libraries is rotting.
>
> What does this even mean?
>
building on sand was meaningless. What I meant to imply was that your
statement was content-free.
Also, in relation to my earlier point, a future Dr. Harrop will say
exactly the same thing about HLVM (that using it is like building on
sand and a rotting foundation).
Raffael Cavallaro
> You just have to use monads to get to it all. You
> can take any imperative algorithm you like and translate it into Haskell in a
> totally straightforward way.
monads. straightforward. <= contradiction in terms
--
Raffael Cavallaro
Raffael Cavallaro
> And we all know that humans are far from perfect. They make mistakes
> all the time just because of that cognitive property. Safety is all
> about restricting this or finding alternatives.
And expressiveness is all about *not* restricting the ability to write
the solution in the language of the problem domain just because of some
misplaced notion of "safety."
--
Raffael Cavallaro
Jon Harrop
> Jon Harrop <j...@ffconsultancy.com> wrote:
>> > What's wrong with purely functional languages?
>>
>> . Unpredictable performance.
>
> Wrong.
There is overwhelming evidence to the contrary. Indeed, you provide more
below...
>> So either Haskell is not "decent" or 200x slower is "not considerably
>> slower".
>
> Hmm. This one took me about 10 minutes:
>
> bwt :: B.ByteString -> B.ByteString
> bwt str =
> let sorted = map fst . sortBy (compare `on` snd) $ zip [0, 1..]
> (B.unpack str)
> slen = B.length str
> in B.pack . map (\i -> B.index str ((i-1) `mod` slen)) $ sorted
Your incomplete implementation is over 100x slower than bzip2. Moreover,
your Haskell runs out of memory when trying to compress only 8Mb.
The poor performance of your Haskell code is a direct consequence of
Haskell's unpredictability. Obviously you failed to predict how bad your
code was or you would not have posted an example that contradicts your own
assertions.
Jon Harrop
Here is a trivial counter example:
http://flyingfrogblog.blogspot.com/2009/04/f-vs-ocaml-vs-haskell-hash-table.html
Jon Harrop
> Raffael Cavallaro <raffaelc...@pas.espam.s.il.vous.plait.mac.com>
> wrote:
>> > What's wrong with purely functional languages?
>>
>> The "purely" part. Some solutions are naturally expressed in a pure
>> functional manner. Others are not. The programmer should have a
>> choice.
>
> They have a choice. A purely functional language has a theoretical
> property, which is very useful. That doesn't mean you can't use the
> things you're used to.
Here is a trivial counter example: mutate an element in an array in O(1).
Larry D'Anna
>> can take any imperative algorithm you like and translate it into Haskell in a
>> totally straightforward way.
>
> monads. straightforward. <= contradiction in terms
They're a bit difficult to learn, but once you understand them they're not hard
to use.
--larry
Larry D'Anna
On 2009-07-10, Jon Harrop <j...@ffconsultancy.com> wrote:
> Here is a trivial counter example: mutate an element in an array in O(1).
easy.
http://cvs.haskell.org/Hugs/pages/libraries/base/Data-Array-ST.html
--larry
fft1976
> Then why are you posting in groups that promote functional languages?
To help you see the light.
Jon Harrop
That is O(n) with GHC.
Raffael Cavallaro
> They're a bit difficult to learn, but once you understand them they're not hard
> to use.
The point here is that it is completely unnecessary cognitive overhead.
If, semantically, I mean to do mutation of state, I should be able to
just mutate state in a direct fashion, not have to use a state monad.
Having said that, it may (or may not) be a desireable to *implement* a
syntax for mutation in terms of monads, but at the level of surface
syntax, it should just look like ordinary mutation.
--
Raffael Cavallaro
Jon Harrop
> On Fri, 10 Jul 2009 01:10:49 -0700 (PDT), fft1976 <fft...@gmail.com>
> wrote:
>>But because most popular languages are imperative, people are whining
>>about those 1/4 cases and some disturbed individuals even think
>>languages should be pure-functional.
>
> use and easier to reason about. Laziness is occasionally a good thing
> to have, but it doesn't need to be built in - it can be implemented
> reasonably on top of any language with closures.
But at what cost? F# is certainly better than OCaml but it can still be a
long way from the clarify of Haskell.
Jon Harrop
> On 2009-07-10 17:09:41 -0400, Larry D'Anna <la...@elder-gods.org> said:
>> They're a bit difficult to learn, but once you understand them they're
>> not hard to use.
>
> The point here is that it is completely unnecessary cognitive overhead.
All HLL features are "unnecessary cognitive overhead".
Jon Harrop
But do the benefits outweigh the costs?
Rob Warnock
+---------------
| "!!!@!!!" <elto...@gmail.com> wrote:
| > if you don't have any other piece of wisdom to share with us I suggest
| > you to not waste your time and tire your fingers to write here. But I
| > supose you don't take suggestions from guys like me, do you?
|
| http://xkcd.com/114/
Or more generally, <http://xkcd.com/386/>.
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
fft1976
> Common Lisp (_not_ Scheme) offers assignment and imperative control
> constructs
Scheme has SET!, VECTOR-SET!, SET-CDR! (in <=R5RS), etc.
Why would someone pretend to know something when they don't?
Jon Harrop
> You guys really are amazing!!! You're so good at starting flame
> wars!!! I don't understand why you make such useless debates about
> which programming languages is the best ?!?! Haven't you yet realised
> that you'll never come to a mutual opinion because you have different
> preferences and jobs that require different tools!?!?! You make
> robotic arguments of these languages features, sometimes without even
> have trying programming in these languages and you sound like you are
> reading a definition from an encyclopedia with a comunist like voice
> protecting his beloved mother language!!!
I am implementing a VM and language. I appreciate peer review of my ideas.
Jon Harrop
> Xah Lee <xah...@gmail.com> wrote on Thu, 9 Jul 2009 :
>> In my opinion:
>> lisp = useless old shit.
>
> So, why do you post on this newsgroup, c.l.l? It's clearly for people who
> are interested in Lisp. If you're not, why are you here?
Is c.l.lisp only for pro-Lisp misinformation?