Why we hate Lisp(c2.com)
c2.com
Why we hate Lisp
http://c2.com/cgi/wiki?WhyWeHateLisp
7 comments
MIT went from scheme to python. I heard an old lisp based recursive class went to python too (people want numpy and other libs, too much pressure).
Maybe the next wave will have some sml/haskell/idris.
Maybe the next wave will have some sml/haskell/idris.
MIT restructured its curriculum to be more hands on. The new curriculum included a module programming robots. Python provided an interface and is a good general purpose language. The fact that robots entered the reasoning indicates how different the new curriculum is from SICP.
"MIT restructured its curriculum" because after the dot.com bust, EECS enrollment dropped by more than 1/2 after being a solid 40% of undergraduates for more than 2 decades, and the department panicked. And, yeah, punting teaching the fundamentals for some hand-on work (robots, communications) was part of that.
There was also a commandment from on-high, don't know if this was above the department or in it from long simmering resentment, to entirely purge Scheme from the curriculum.
Given all that, Python was perhaps the least worst choice (although using Java to teach the rest of what's in SICP is not even wrong), although I personally wonder about the wisdom of purging functional programming from the curriculum at the same time that multi-cores may be making it a lot more relevant.
There was also a commandment from on-high, don't know if this was above the department or in it from long simmering resentment, to entirely purge Scheme from the curriculum.
Given all that, Python was perhaps the least worst choice (although using Java to teach the rest of what's in SICP is not even wrong), although I personally wonder about the wisdom of purging functional programming from the curriculum at the same time that multi-cores may be making it a lot more relevant.
Any data on the 'purge scheme' desire ? I find it really really strange. Was it related to post-hire issues ? or student problems ?
Nothing besides the obvious you get from the curriculum being 100% Python and Java (yep, MIT is now a "Java school"), and there being no common CS and EE curriculum besides those first two lab intense robots and communications classes (previously there was a core of SICP, two EE classes and a low level computer micro- and macro-architecture course, 6.001-4).
MIT EECS degrees, while still representing what MIT thinks its EECS graduates should know, now mean something very different, and that has, e.g. resulted in much greater differentiation between it and CMU, which has embraced functional programming in its core curriculum.
MIT EECS degrees, while still representing what MIT thinks its EECS graduates should know, now mean something very different, and that has, e.g. resulted in much greater differentiation between it and CMU, which has embraced functional programming in its core curriculum.
Yeah, and there were videos about MIT focusing more on 'material' engineering, giving ceramics playgrounds for students, rather than theory and software. In a way MIT is right, computer had their days, now things are back to the real world. Augmented reality, physical interactions, IoT, sensors etc etc. But at the same time FP gives better ways to reason and write solid code anyhow.
In a way MIT is right, computer had their days, now things are back to the real world.
MIT handled this very poorly; it's always been very conservative about bulking up departments because things can radically change. Aero/Astro was red hot from, oh, post-WWI to the early 1970s, when it catastrophically crashed without to this date a recovery.
For decades EECS struggled with 40% of the undergraduates and ~1/6th of the institute's resources, in fact when they adopted the old core of 6.001-4 in the early '80s they dropped the "service" course that taught introductory programming for lack of human resources. I don't know how much the faculty was bulked up, the ultimate metric, but before the dot.com crash they committed a quarter billion dollars to a new CS research building that was ugly, very dysfunctional, and expensive to operate (so insecure it requires a full time police officer).
Anyway, I judge that "had their days" differently, at least in the longer term. Most specifically, one of these days a programming error will kill thousands or tens of thousands of people, and at least part of the field will radically change as people get more serious about "quality" software.
(Scare quotes because e.g. Facebook and Boeing have very different, and correct for both of them, definitions of software quality.)
MIT handled this very poorly; it's always been very conservative about bulking up departments because things can radically change. Aero/Astro was red hot from, oh, post-WWI to the early 1970s, when it catastrophically crashed without to this date a recovery.
For decades EECS struggled with 40% of the undergraduates and ~1/6th of the institute's resources, in fact when they adopted the old core of 6.001-4 in the early '80s they dropped the "service" course that taught introductory programming for lack of human resources. I don't know how much the faculty was bulked up, the ultimate metric, but before the dot.com crash they committed a quarter billion dollars to a new CS research building that was ugly, very dysfunctional, and expensive to operate (so insecure it requires a full time police officer).
Anyway, I judge that "had their days" differently, at least in the longer term. Most specifically, one of these days a programming error will kill thousands or tens of thousands of people, and at least part of the field will radically change as people get more serious about "quality" software.
(Scare quotes because e.g. Facebook and Boeing have very different, and correct for both of them, definitions of software quality.)
By computers I meant desktops and their software or web apps. I was shallow anyhow, and you're right it will end up as reorganization in the field.
Great point.
> Unfortunately a Russian spy stole the last meg of a LISP program for controlling our nuclear defense systems. Fortunately, it was all right-parenthesis.
Thats a nice variation of a joke about German. "I normally skip to the back of a novel to find out what happens at the end, but in German that doesn't work because the last few pages are just full of all the verbs".
Python:
sum(range(1,11))
How did 11 come into the problem?
Aren't the integers the domain over which we are operating?
How is the comma obvious from the problem statement?
If I can assume a person knows a particular language, the J version is perfectly clear.
Aren't the integers the domain over which we are operating?
How is the comma obvious from the problem statement?
If I can assume a person knows a particular language, the J version is perfectly clear.
+/ 1+ i.10Pythonic range(a,b) is [a...b[ over the integers(in the interval sense.)
But yes, I acknowledge that every programming language requires a certain amount of knowledge about generalities, Python being no exception.
And I really should sit down at some point and learn an APL variant.
But yes, I acknowledge that every programming language requires a certain amount of knowledge about generalities, Python being no exception.
And I really should sit down at some point and learn an APL variant.
Or Perl6:
[+] 1 ... 10Ok, if you have `sum` defined:
(sum (range 1 11))
If we refuse to normalize the languages by defining `sum`, then it’s an API battle... And Clojure/Clojurescript has easy access to Java and Javascript. (Plus if we count Clojure on .NET...)
If we refuse to normalize the languages by defining `sum`, then it’s an API battle... And Clojure/Clojurescript has easy access to Java and Javascript. (Plus if we count Clojure on .NET...)
Yes, this article shows several different ways to do one same thing, you can't really expect programmers to remembers all this syntax.
from https://www.python.org/dev/peps/pep-0020/ :
> There should be one-- and preferably only one --obvious way to do it.
I don't know if common lisp is an "easier" lisp, but I sure would like to have a watered down version of lisp so I can learn its paradigms. I don't even know if that's what haskell is.
from https://www.python.org/dev/peps/pep-0020/ :
> There should be one-- and preferably only one --obvious way to do it.
I don't know if common lisp is an "easier" lisp, but I sure would like to have a watered down version of lisp so I can learn its paradigms. I don't even know if that's what haskell is.
I picked Python as its the language I think most easy to write and read. Concise enough without being write-only.
I disagree. You say so because you're used to Python. In Python you need to remember quite a few syntax rules. How many different symbols you need to write a relatively complex program? How many symbols/words are reserved? In LISPs there's much less syntax to remember.
(old thread, sorry)
Python is designed to be human readable.
Here's an old blog post by me, which may be hard to jump into because its part of a longer conversation on proggit or something, but anyway: http://williamedwardscoder.tumblr.com/post/18319031919/progr...
Python is designed to be human readable.
Here's an old blog post by me, which may be hard to jump into because its part of a longer conversation on proggit or something, but anyway: http://williamedwardscoder.tumblr.com/post/18319031919/progr...
It fails. The more symbols and syntax rules you have, the less readable it is. I think this is pretty straightforward to understand :) Human language has pretty much non-existant symbols besides the alphabet.
Yep, in Lisp all you need to remember is ().
Python has more syntax to remember than in Lisp, but ends up being a lot more readable (eg lists, dicts etc)
Python has more syntax to remember than in Lisp, but ends up being a lot more readable (eg lists, dicts etc)
I don't really see how having to remember more symbols and syntax rules makes anything more readable. It doesn't. You have to know what those symbols mean, and the more there are, the less readable it is by definition because you need more knowledge to understand it. I understand it is more readable for YOU because you already have that knowledge. The same applies where English is readable for me but Chinese is not. If Chinese "syntax" was simpler, I could actually learn it way faster, as everyone else, which would make it more "readable" to everyone that has not previous knowledge, not just to YOU :)
> lists, dicts
Clojure does them right, imho.
Clojure does them right, imho.
And uses the same symbols as Python, Ruby, and a number of other high level programming languages.
No, it doesn't. In fact, you can avoid them if you wish and build everything from simple lists. Point being: I don't have to remember a specific syntax for "for" loop, or for equality (==)...
so why am I failing to learn lisp ?
Are you failing to learn it? What have you tried? What's holding you back? I'm offering a free Clojure workshop next Saturday if you're in the Philadelphia region. http://www.meetup.com/Clojadelphia/events/221835485/
Otherwise, I worked through SICP a couple years back, and I found it invaluable to getting familiar with Lisps and functional programming in general.
I remember sitting down one day (before working through SICP) and saying, "I'm great at PHP, I'll probably just be able to write a Clojure project off the top of my head!" Cue clown music as I beat my head against a language much more expressive than anything I'd encountered to date.
It was a few solid weeks of effort before I could get anywhere, but I remember remarking at the time, "if I can learn this well enough, I'll be a wizard!"
Otherwise, I worked through SICP a couple years back, and I found it invaluable to getting familiar with Lisps and functional programming in general.
I remember sitting down one day (before working through SICP) and saying, "I'm great at PHP, I'll probably just be able to write a Clojure project off the top of my head!" Cue clown music as I beat my head against a language much more expressive than anything I'd encountered to date.
It was a few solid weeks of effort before I could get anywhere, but I remember remarking at the time, "if I can learn this well enough, I'll be a wizard!"
sicp is pretty hardcore
I tried reading lisp courses or tutorials, it really did not help. It's either too steep, or it just talks about simple things like adding numbers like (+ 5 9) I'm more into what makes me understand lisp as a better language.
I tried reading lisp courses or tutorials, it really did not help. It's either too steep, or it just talks about simple things like adding numbers like (+ 5 9) I'm more into what makes me understand lisp as a better language.
I've heard rave reviews of Joy of Clojure as a good book to "get it". I found I really had to work at the problem from several angles before it "clicked".
I started with Land of Lisp, but it felt very arcane to me at the time. I would copy in code from the book, and then look back at just jibberish. I gave up on that a few chapters in. Then I made that site in Clojure, one error at a time, pounding like a monkey until it worked. I then read Clojure Programming twice, followed by working through Let Over Lambda. About halfway through Let Over Lambda, I think it "clicked". I finished with an amazing online course in Programming Languages through Brown University. I finished with SICP chapters 1-3.
Nothing worthwhile is ever easy. If you need any help please reach out, you can't waste my time.
I started with Land of Lisp, but it felt very arcane to me at the time. I would copy in code from the book, and then look back at just jibberish. I gave up on that a few chapters in. Then I made that site in Clojure, one error at a time, pounding like a monkey until it worked. I then read Clojure Programming twice, followed by working through Let Over Lambda. About halfway through Let Over Lambda, I think it "clicked". I finished with an amazing online course in Programming Languages through Brown University. I finished with SICP chapters 1-3.
Nothing worthwhile is ever easy. If you need any help please reach out, you can't waste my time.
I would recommend:
1) Install Racket (http://racket-lang.org/) 2) Read Simply Scheme (https://www.cs.berkeley.edu/~bh/ss-toc2.html) by Brian Harvey and Matthew Wright. It's free. Harvey taught the Scheme classes at UC Berkeley for many years, and is an outstanding (and award-winning) teacher (he also has a series of videos that might be helpful).
One of the stated goals of Harvey and Wright's approach is to get the student ready for SICP. It's definitely way above the "add two numbers" level, but is not quite the instant warp factor 10 that you get when you dive into SICP.
If you do this, you should also use the Racket Library (https://www.hashcollision.org/simply-scheme/) that adds all the extra stuff used in the Harvey and Wright text.
Good luck!
1) Install Racket (http://racket-lang.org/) 2) Read Simply Scheme (https://www.cs.berkeley.edu/~bh/ss-toc2.html) by Brian Harvey and Matthew Wright. It's free. Harvey taught the Scheme classes at UC Berkeley for many years, and is an outstanding (and award-winning) teacher (he also has a series of videos that might be helpful).
One of the stated goals of Harvey and Wright's approach is to get the student ready for SICP. It's definitely way above the "add two numbers" level, but is not quite the instant warp factor 10 that you get when you dive into SICP.
If you do this, you should also use the Racket Library (https://www.hashcollision.org/simply-scheme/) that adds all the extra stuff used in the Harvey and Wright text.
Good luck!
What would you want to learn ? SICP is about fundamental patterns that you will encounter, but sometimes they are too weird to understand without context. Also SICP uses a lot of maths, some people don't like having to deal with 2 difficulties at once. Maybe try HtDP http://www.htdp.org/, you'll understand how to think about 'programs' without typing source in a particular language.
The pattern of adding numbers is just an instance of a closed set recursion.
(F e0 ... en) -> (reduce F (e0 ... en) zero-element) -> (F(...(F(F zero-element e0) e1)...) en)
Not just about simple addition, it works with function relating two elements of the same kind to another element of that kind. From 2 arguments to 1, so you can pick another element and relate it to the previous result, so on and so forth until you reduced a list of elements to just one.
Of course it's not an application like crafting a website, or rendering GUI, or manipulating sound samples, but these principles are everywhere.
The pattern of adding numbers is just an instance of a closed set recursion.
(F e0 ... en) -> (reduce F (e0 ... en) zero-element) -> (F(...(F(F zero-element e0) e1)...) en)
Not just about simple addition, it works with function relating two elements of the same kind to another element of that kind. From 2 arguments to 1, so you can pick another element and relate it to the previous result, so on and so forth until you reduced a list of elements to just one.
Of course it's not an application like crafting a website, or rendering GUI, or manipulating sound samples, but these principles are everywhere.
If you're really interested in learning and grokking Lisp, you could do worse than trying to implement it yourself.
https://github.com/kanaka/mal
Fully working lisp in 10 (easy to not so easy) steps.
https://github.com/kanaka/mal
Fully working lisp in 10 (easy to not so easy) steps.
There's not that much to understand about Lisp and that's why it seems hard.
First, you should pick a Lisp-1 because otherwise you'll be hit with "weird" behaviour earlier than necessary.
Next, learn the syntax of your Lisp. Pick one that doesn't have many extensions, as they may become a distraction. Ignore any macros your Lisp supports, leave quasiquote and unquote for later (you can use `quote`, but as a shorthand for the `list` function at first). Learning the syntax won't take long, as it becomes pretty minimal if you omit those things.
Make sure you use an editor that understands your Lisp and has advanced syntax highlighting and auto indent functionality. The difference between a well formatted and highlighted code and a blob of flat text is huge in Lisps, compare this:
Similarly, don't ever attempt to balance parens manually, your editor should handle this, along with commands for expanding and shrinking particular expresions (for example, change "(message "%s") something" into "(message "%s" something)" with a single keypress) and other goodies.
After the groundwork is done, start with control-flow constructs (forms in Lisp parlance): constructs for assignement (define/defvar/setq (but not! setf)/etc.), for branching (if/cond/etc.), for grouping (begin/progn/etc.), for looping/iteration (loop/for/dotimes/etc.) and error handling (with-handlers/condition-case/etc.). Learn basic data constructors (list/vector/hashmap/etc.). Experiment with these in the REPL or write some simple scripts using them. Learn how to define functions/procedures and refactor your scripts to use them.
You're basically done at this point. Not in the sense that you know Lisp, but you're ready to learn all there is to Lisp without much hassle. The last obstacle is learning about defmacro and quasiquote/unquote, but that's easy once you're comfortable with lists and iteration. Everything else in most Lisps is built with macros, and at that point you have all the tools needed to write Lisp code, to investigate your Lisp implementation and finally to build your own extensions into the language.
I think that most of the difficulty of learning Lisp stems from learning things in wrong order. Lispers naturally want to show you the most powerful language features to distinguish Lisps from other languages, but they already forgot that these features are built on much simpler things. Or, on the other hand, they drift into lambda calculus and Peano numbers, which smells like a Turing tarpit, where nothing of interest is easy to do.
Anyway, try learning things in that order, maybe it'll help. It worked for me, after years of approaching Lisp and quickly retreating I was finally able to grok it thanks to this approach. YMMV of course.
[EDIT: formatting]
First, you should pick a Lisp-1 because otherwise you'll be hit with "weird" behaviour earlier than necessary.
Next, learn the syntax of your Lisp. Pick one that doesn't have many extensions, as they may become a distraction. Ignore any macros your Lisp supports, leave quasiquote and unquote for later (you can use `quote`, but as a shorthand for the `list` function at first). Learning the syntax won't take long, as it becomes pretty minimal if you omit those things.
Make sure you use an editor that understands your Lisp and has advanced syntax highlighting and auto indent functionality. The difference between a well formatted and highlighted code and a blob of flat text is huge in Lisps, compare this:
(define (plot-lines data)
(parameterize ([plot-x-tick-label-anchor 'top-right]
[plot-x-tick-label-angle 35])
(let ([out-path (build-path (current-directory) "lines.png")]
[data (list (tick-grid)
(discrete-histogram data #:y-min 0 #:y-max 100))])
(plot data
#:y-label "sloc"
#:x-label #f
#:out-file out-path))))
Similarly, don't ever attempt to balance parens manually, your editor should handle this, along with commands for expanding and shrinking particular expresions (for example, change "(message "%s") something" into "(message "%s" something)" with a single keypress) and other goodies.
After the groundwork is done, start with control-flow constructs (forms in Lisp parlance): constructs for assignement (define/defvar/setq (but not! setf)/etc.), for branching (if/cond/etc.), for grouping (begin/progn/etc.), for looping/iteration (loop/for/dotimes/etc.) and error handling (with-handlers/condition-case/etc.). Learn basic data constructors (list/vector/hashmap/etc.). Experiment with these in the REPL or write some simple scripts using them. Learn how to define functions/procedures and refactor your scripts to use them.
You're basically done at this point. Not in the sense that you know Lisp, but you're ready to learn all there is to Lisp without much hassle. The last obstacle is learning about defmacro and quasiquote/unquote, but that's easy once you're comfortable with lists and iteration. Everything else in most Lisps is built with macros, and at that point you have all the tools needed to write Lisp code, to investigate your Lisp implementation and finally to build your own extensions into the language.
I think that most of the difficulty of learning Lisp stems from learning things in wrong order. Lispers naturally want to show you the most powerful language features to distinguish Lisps from other languages, but they already forgot that these features are built on much simpler things. Or, on the other hand, they drift into lambda calculus and Peano numbers, which smells like a Turing tarpit, where nothing of interest is easy to do.
Anyway, try learning things in that order, maybe it'll help. It worked for me, after years of approaching Lisp and quickly retreating I was finally able to grok it thanks to this approach. YMMV of course.
[EDIT: formatting]
The LISP + functional mind-set is not easy to get used to when you come from non-functional (specially bad is OOP), verbose, syntactically complex programming languages (e.g. C, C++, Java, C#...). I think you should focus on learning to think the functional way. Then LISPs will reveal all their power through simplicity. That's how it worked with me at least ;)
Racket (a Scheme descendant) might be a good fit. It has teaching languages, which are simplified, and a nice IDE (DrRacket), and books (HTDP/2e (free online), Realm of Racket, etc.)
Close match to the Python above:
(apply + (range 1 11))
Close match to the Python above:
(apply + (range 1 11))
Common lisp = committee lisp; it's not "easier". It standardized lisp by including about every feature that any of a set of competing Lisp's had. For example, the 'format' function can write numbers in roman digits, spell out numbers, and capitalize words (http://www.gigamonkeys.com/book/a-few-format-recipes.html)
Beginners probably are better of using scheme or racket.
Beginners probably are better of using scheme or racket.
Common Lisp == Mainline Lisp. It's the direct descendant of original formula McCarthy LISP, and has accumulated a lot of warts and random stuff. Plus it's more generally multi-paradigm than Scheme, Racket or Clojure, and has no bias towards simplicity and a limited one towards elegance.
Common Lisp is basically the successor to Maclisp - which already had the FORMAT function.
Common Lisp does not force you to use FORMAT. It has a bunch of simpler IO functions, too.
Common Lisp does not force you to use FORMAT. It has a bunch of simpler IO functions, too.
where is
times(range(1,11)) ?
(apply #'* (-range 1 11))
When in doubt, the answer is 'because Guido said so'. Benefits and downsides of having a BDFL on a language.
Hehe. Something funny I learned recently:
Python reached version 1.0 in January 1994. The major new features
included in this release were the functional programming tools
lambda, map, filter and reduce. Van Rossum stated that "Python
acquired lambda, reduce(), filter() and map(), courtesy of a Lisp
hacker who missed them and submitted working patches".[9]
And a dozen years later he wanted to wanting to purge them from the language, or at least lambda.
from functools import reduce
from operators import mul
def times(data):
return reduce(mul, data)I'm not saying it's not possible, just that they stopped too early.
>>> times([])
TypeError: reduce() of empty sequence with no initial value
from functools import reduce
from operators import mul
def times(data):
return reduce(mul, data)
>>> times = lambda l: reduce(mul, l,1)
>>> times([])
1Whoops, but again as you say that is trivial to fix.
It's more about the philosophy, some languages recognize this way of thinking, having tiny bits of ~monoid-ic logic that works for N. Lists have neutral element (nil) and concatenative operation (cons). Arithmetic operations follow that. IMO they don't approach systems the same way.
Just not included in to the standard library (it doesn't really have a common use case), but certainly implementable, and without loops to boot!
>>> def times(input):
... return reduce(lambda x, y: x*y, input, 1)
...
>>> times(range(1,11))
3628800Of course, it's just weird to see `sum` built-in all alone. They even have operator.mul so...
>>> Prod = lambda xs: fp.reduce(op.mul, xs, 1)
>>> Prod(range(1,11))
362880SmugLispWeenies is why we hate Lisp. People who, when writing Lisp tutorials, spend a condescendingly large time telling the reader that they are going to have their mind blown by the concept of first class functions. In the space year 2015 people are still doing this.
Also they have apparently never heard of Forth either.
Also they have apparently never heard of Forth either.
Yes, you still find articles praising first class functions in "space year 2015" because those websites were written from an Earth year 1997 perspective. Yes, maybe with Java, Python, and Ruby all having first class, anonymous functions -- making that feature well-known -- it is less mind blowing. That doesn't mean that Lisp (by which I mostly mean Common Lisp) doesn't still have potentially "mind blowing" things to teach.
Consider error handling. I would say that coming from any language where this is limited to the "try...catch" paradigm, seeing the separation and possibility provided by restarts is absolutely a mind blowing experience. (The stack doesn't unwind during the error handler search? Huh?)
Another "enlightenment" moment can come with understanding the way Lisp uses macros. No, I don't mean understanding writing macros, I mean looking at the language itself and seeing standard language features like "loop" or even CLOS being implemented using just macros. The idea of extending your language with entirely new abstractions, using just a few lines of code rather than some compiler update, should be mind-blowing. (Just the idea that "I have access to the full range of tools the language implementer used" can enlighten how to approach certain problems!)
Yes, exposure to Forth can also do all of this... but personally, I mentally filed Lisp and Forth together from the start. They both seem to be approaching the same peak "optimum" in code expressiveness (brevity / power), but from opposite sides of the mountain.
Consider error handling. I would say that coming from any language where this is limited to the "try...catch" paradigm, seeing the separation and possibility provided by restarts is absolutely a mind blowing experience. (The stack doesn't unwind during the error handler search? Huh?)
Another "enlightenment" moment can come with understanding the way Lisp uses macros. No, I don't mean understanding writing macros, I mean looking at the language itself and seeing standard language features like "loop" or even CLOS being implemented using just macros. The idea of extending your language with entirely new abstractions, using just a few lines of code rather than some compiler update, should be mind-blowing. (Just the idea that "I have access to the full range of tools the language implementer used" can enlighten how to approach certain problems!)
Yes, exposure to Forth can also do all of this... but personally, I mentally filed Lisp and Forth together from the start. They both seem to be approaching the same peak "optimum" in code expressiveness (brevity / power), but from opposite sides of the mountain.
Or PostScript, which combines the best of Lisp and Forth.
I can build strawmen too:
- SmugCeeWeenie: I am so fast, look (oops, core dumped)
- SmugGoWeenie: abstractions are so nasty we should get rid of functions, so that everyhting is laid out clearly. Hopefully, I have copy/paste.
- SmugAdaWeenie: Functions are not procedures and records cannot store objects. Real engineers do not "prototype" code.
- SmugHaskellWeenie: Yeah, it compiles! Job done.
> In the space year 2015 people are still doing this.
About first class functions? citation needed.
- SmugCeeWeenie: I am so fast, look (oops, core dumped)
- SmugGoWeenie: abstractions are so nasty we should get rid of functions, so that everyhting is laid out clearly. Hopefully, I have copy/paste.
- SmugAdaWeenie: Functions are not procedures and records cannot store objects. Real engineers do not "prototype" code.
- SmugHaskellWeenie: Yeah, it compiles! Job done.
> In the space year 2015 people are still doing this.
About first class functions? citation needed.
- SmugHaskellWeenie: cabal sandbox init, cabal install this, cabal install that, write code, add ghc pragma, wtf! add ghc pragma, wtf! add ghc pragma ... Yeah, it compiles! Job done. Almost, time to get rid of the warnings. add ghc pragma, and another, and one from the top Carol and ... yeah, it compiles with no warnings.
The one thing that I take away from all of this is that the people complaining just don't 'get it'. I don't know whether it's a personal failing of the individuals involved or something about lisp that is orthogonal to most people's thought processes, but the page reads more like (to me) sour grapes than a reasoned discourse on why lisp sucks. Compare that to the article posted yesterday about CLASP (https://drmeister.wordpress.com/2014/09/18/announcing-clasp/) - a brilliant piece of engineering that the creator said was just not doable in other languages, and you have a huge cognitive dissonance. But then, ymmv.
Ooops, an old link to CLASP. Here's a newer link:
https://drmeister.wordpress.com/2015/06/15/i-gave-a-talk-on-...
https://drmeister.wordpress.com/2015/06/15/i-gave-a-talk-on-...
I'm slightly unclear why this website exists.
In case you're not joking: https://en.wikipedia.org/wiki/WikiWikiWeb
As expected, a page for Lisp fanboys.
Do you ever comment more than a sentence or two? You are recognisable as the archetypical "low-effort" contributor.
Well, considering that yours is a throwaway account, he's at least reconginsable!
(from http://www.secretgeek.net/lisp_truth)