81–90 of 276 posts
a lot of people handwave the parenthesis and prefix notation as something you get used to, but it really is the thing that I think most people can't get a handle on. There's a reason why DSPs and languages that look like a real languages are sought after - it makes conversion between business logic/requirements to code easier. It makes maintenance easier - it's easy to make sure you made the right changes when the ch…
What's DSP in this context?
Earlier quoted context omitted.
Well, in 1992 (IIRC), I did a numerical integration in C. For a "first class function", it just took a function pointer. That approach would have been available in C in 1983...
That's not really the same thing at all. What's missing is the ability to close over values, which is a key part of first-class functions. You could not re-create the original example in C, which is to return a new function. You'd have to return some sort of object that keeps a reference to the function pointer, and provides a special mechanism for calling it, i.e. a poor man's closure.
Note: I'm not saying that C could express closures and first-class function objects anywhere near as neatly as Lisp. But the idea that only Lisp allowed you to use them, and C was the land of straightforward procedural code... does not represent what I saw back then.
Just as you can write FORTRAN code in any language, you can transfer ideas from other languages to C. What's great about Lisp is that it made the ideas easily accessible.
Earlier quoted context omitted.
Indeed, posts like this are of historical interest, but today, take Python: dx = 0.0001 def deriv(f): return lambda x: (f(x + dx) - f(x)) / dx This works just the same as the author's example and looks even more like the calculus formula people are used to.
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.
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 guess the stuff about parentheses that's highly confusing in Lisp is that x is different from (x). Outside of that, it's just ordinary grouping.
function(x) { return x; }
function(x) { return x; }()
Earlier quoted context omitted.
That's not really the same thing at all. What's missing is the ability to close over values, which is a key part of first-class functions. You could not re-create the original example in C, which is to return a new function. You'd have to return some sort of object that keeps a reference to the function pointer, and provides a special mechanism for calling it, i.e. a poor man's closure.
> What's missing is the ability to close over values, which is a key part of first-class functions. This is not true. You can have first-class function which are not closures: every dynamically-scoped Lisp works that way, see Emacs Lisp without `lexical-binding: t` and the `lexical-let` implementation.
(setq dx .0001)
(defun deriv (f)
(lambda (x)
(/ (- (funcall f (+ x dx)) (funcall f x))
dx)))
(defun cube (x) (* x x x))
(setq cube-deriv (deriv #'cube))
(funcall cube-deriv 2)
Error: Symbol's value as variable is void: f
Earlier quoted context omitted.
Learning lisp or functional programming is more of a conceptual experience than a practical one. That is not to say it is not practical to learn lisp, but the state of the programming world as it is today makes it so that it is less practical to learn lisp than it is to learn about say something like java.
If you ever have to write JavaScript, a fairly practical and widespread language, the functional paradigm proves to be highly useful.
The functional paradigm in Javascript is used everywhere because that's all there was.
a lot of people handwave the parenthesis and prefix notation as something you get used to, but it really is the thing that I think most people can't get a handle on. There's a reason why DSPs and languages that look like a real languages are sought after - it makes conversion between business logic/requirements to code easier. It makes maintenance easier - it's easy to make sure you made the right changes when the ch…
Mastering operator precedence in your typical infix language is harder.
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…
For me it's not the paranthesis, but that Lisp posts always show low level code. At least half of my programming is tying together high level services and libraries. I know how I can express those concepts succinctly in Java, C++, JS, Swift etc. I'd love to see some examples of Lisp for something like a REST controller, where I call services, repositories etc.
You should look at Racket. Racket is a Scheme-like[0] Lisp that aims to be "batteries-included". It includes things like a web-server out-of-the-box.
[0] it is technically a hybrid of R5RS and R6RS, so pedants can argue over whether it is really "a Scheme" or not.
Earlier quoted context omitted.
Yeah, this seems to be a common objection, but in my experience of actually having used a lisp (Clojure) in production, this was never a problem. Sure, you'll likely still end up with some technical debt, but no more than the Java project's we had at the same company. And not because of macros. When people first learn about macros, they go crazy trying to do all kinds of things that weren't possible without macros. B…
Clojure has a BDFL (Rich Hickey) and it lacks reader macros. It's kind of the exception that proves the rule.