31–40 of 276 posts
Yeah, but it's goddamned ugly and unreadable. It considers repetition to be a design feature . If you're going to sell people on the benefits of functional programming, I think you should really be pushing more for SML or Haskell or something like that.
Repetition of what? I don't see any repetition on those snippets... What are you referring to?
I'm having trouble understanding why the derivative example was so impressive to the author. Can someone explain? It seems trivial to do in any language where functions are first class citizens.
[1] https://mitpress.mit.edu/sicp/full-text/sicp/book/node39.htm...
[2] https://github.com/clojure-numerics/expresso
[3] http://docs.sympy.org/latest/tutorial/intro.html#a-more-inte...
Yeah, but it's goddamned ugly and unreadable. It considers repetition to be a design feature . If you're going to sell people on the benefits of functional programming, I think you should really be pushing more for SML or Haskell or something like that.
What repetition are you referring to?
The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…
As a response to your objections, 1) It's just a syntax thing... It's still possible to make an understandable program through good style 2) I don't have anything. 3-6) I've heard Racket is a good spiritual successor to Lisp, complete with external libraries and a broad(er) userbase.
* Lisp does look quite a bit like stuff you're used to:
foo(bar(arg, (foo (bar arg arg
arg2), arg2) arg2
xyzz()); (xyzz))
It has familiar features like mutable lexical and global variables, control constructs for selection and iteration and so on. There is even a form of goto.
Aggregate objects like structures, class instances, lists, vectors and so on are actually referential values, like in many languages.
It is said that Javascript is a dialect of Lisp. If you understand how Javascript evaluates expressions, that goes a long way toward Lisp. Ruby is sometimes called MatzLisp, after the surname of its creator, for very good reasons. Lisp has inspired many features found in other languages. The comma, ?:, && and || operators in C appear to be Lisp inspired, as is the very idea of "expression statements": for instance when we call a function in C as a statement, it is an expression with a value, which is discarded, just like in Lisp.
Lisp lists lack encapsulation; they are not opaque bags with which you do things like (add list item). That takes getting used to: always capturing the result value of a list construction. It doesn't take that much getting used to for programmers coming from C, who understand a bunch of ways of representing lists, including representations in which a null pointer represents an empty list.
A container-like list data type is easily written in Lisp, either as a function-based ADT with a couple of functions around small state struct (or perhaps cons cell or vector), or full blown OOP.
The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…
The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…
To be fair, the one time I decided to do something biggish and kinda important in Lisp, I stopped at #3. Not exactly because "it does not have many libraries", but because "library for X, Y and Z are not there and I don't want to write them". Oddly, Haskell has a similar problem, but going through C code by the FFI does not feel like a problem. I don't think why it does in Lisp, it may be just a matter of better docu…
Yeah, but it's goddamned ugly and unreadable. It considers repetition to be a design feature . If you're going to sell people on the benefits of functional programming, I think you should really be pushing more for SML or Haskell or something like that.
x.f(y, z) has just as many parens as (f x y z). And Haskell particularly comes with so many syntax quirks. There is a lot of cruft you need to learn to get to the underlying functional core of haskell. Lips you can get 100% of the cruft out within a few days / 1 week. And the rest is just understanding programming concepts.
I don't use any LISP on a regular basis, but it still amazes me how often people are willing to dismiss a language based on parens.
It reminds me of a friend who would never try food from any other country because: Look at all the weird colors and ingredients. I'm not trying that.
In the end, no one will ever force anyone to try something - but my view in life is if everyone raves about something, and my main concern with it is by (my own admission) superficial. I still go and give it a try.
SICP gives you a new view on programming regardless of whether you ever touch lisp again or not.
Earlier quoted context omitted.
Unreadable? Personally, I think that Lisp has the clearest possible syntax - because it basically doesn't have any. It's just straight ASTs - something that I have to visualize myself in other languages wich have more syntax sugar.
Lisp has the minimal syntax for lists: (a b c d) where other languages require separating commas, but Haskell has minimal syntax for function application: f x y z with no parenthesis needed. (Technically, this is a triple application ((f x) y) z, masked by the convention of application being a left-associative binary operator.)
I'm having trouble understanding why the derivative example was so impressive to the author. Can someone explain? It seems trivial to do in any language where functions are first class citizens.
Yeah, but it's goddamned ugly and unreadable. It considers repetition to be a design feature . If you're going to sell people on the benefits of functional programming, I think you should really be pushing more for SML or Haskell or something like that.
- there's no universal syntax for everything [1]
- lisp entice you to make tiny dsl as sets of correlated functions on some domain for which there's no syntax .. [related to 1]
- close to zero magic
- parsing complexity removed and built-in, jump straight into problem solving [3]
- some advanced academics don't see classic math as the ultimate notation (one sicp author made SICM for langrangian mechanics) he likes the consistency and smallness of sexps [related to :3
[1] I know, people like infix math
[2] I failed an ADA exam because I couldnt find how to typecase a 1-char string to a char type.. try to guess
[3] instead of how cute is my looking.. Also Brown Uni. had a chapter on not wasting time on syntax in education. Although they made pyret lang since .. but syntax is not the only reason.