101–110 of 276 posts
Earlier quoted context omitted.
f(x + dx) does look more conventional than (f (+ x dx)), but (/ numerator denominator) looks more like the conventional fraction syntax than putting a / somewhere in the middle of a line.
I'll give you that but also, ask 100 random people what "3/4" means and what "(/ 3 4)" means.
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.
Lisp is not a functional programming language.
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: > 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. Amusingly one of the "objections" to Common Lisp when it was standardized was its absurdly large library. Things sure look diffe…
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…
I don't mean the syntax is hard to grasp. I mean the way it looks. It becomes very confusing when the program grows in size.
This is not unique to Lisp. It applies to all dynamic languages that don't have strong tooling support (IDE's with intellisense).
(Maybe I am wrong about Lisp being dynamic; my only experience has been with "arc"; and I have had someone tell me before that common-lisp has static types)
I used to be happy about programming python and javascript in a plain text editor (vim).
However, as I was doing my first intermediate size project, I realized that I've hit a limit.
My project was in Javascript (frontend) and I couldn't keep track of what was going on anymore. Each unit of code is understandable on its own but the whole thing is a mess to look at. When I need to change the inputs or outputs of a function, I have no idea if I've done it correctly or not; due to the lack of type checking.
I absolutely need to make sense of what is what. Having everything look the same makes me confused. And I've come to realize that tooling support is of the utmost importance. Having an editor like vim with cool tricks is nice, but what I really need is to "rename variable" or "rename function" automatically across all usages in the project.
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.
This was back in 1983 where most (all?) other languages did not have first-class procedures. If you can imagine programming without them and then being exposed to that, it would be a big deal. We take them for granted today.
Earlier quoted context omitted.
I'll give you that but also, ask 100 random people what "3/4" means and what "(/ 3 4)" means.
Are you sure random people are going to recognize "3/4" notation? It could be different for "3 ÷ 4", but I think "3/4" is not widely used outside of programming?
http://www.tasteofhome.com/recipes/how-to-cook/how-to-cut-do...
Taken a drive?
https://c1.staticflickr.com/5/4149/5174138836_6603010a7d_b.j...
Earlier quoted context omitted.
> I'm having trouble understanding why the derivative example was so impressive to the author. Says someone 35 years later. :) Probably every (commonly found) derivative example, and the majority of languages with first class functions all come from this example. MIT introducing Scheme and those two professors writing SICP are a large part of the reason for the current functional programming landscape. Without them I…
I only got to read SICP almost a decade after finishing my degree, it wasn't even a thing at my university. We got to learn FP via Caml Light, Standard ML, pure lambda calculus and we also had some LP classes via Prolog. Those of us that learned Lisp did it to customize Emacs.
The first two being based lisp, and the third being what inspired lisp.
It's like saying: I learned low level imperative programming from using Go, C++, and register machines. Which, sure, but the C language was hugely influential to all of that.
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…
_My_ main objection to lisp is that it's confusing. I don't mean the syntax is hard to grasp. I mean the way it looks. It becomes very confusing when the program grows in size. This is not unique to Lisp. It applies to all dynamic languages that don't have strong tooling support (IDE's with intellisense). (Maybe I am wrong about Lisp being dynamic; my only experience has been with "arc"; and I have had someone tell m…
