91–100 of 143 posts
Earlier quoted context omitted.
I currently love both Go and Lisp. They are the opposites of each other. And good for different things.
They have still one thing in common - that are not oop!
(Not stating this as a bad thing, just as a fact)
Earlier quoted context omitted.
What's the most popular Lisp in use today? Does it come with a static compile type checking?
> What's the most popular Lisp in use today? At least if based in 2016 GitHub popularity: http://sogrady-media.redmonk.com/sogrady/files/2016/07/lang.... #1 Emacs Lisp #2 Common Lisp #3 Scheme #4 Racket Unless you consider Clojure a Lisp (yes it is, and no, it isn't...), in which case #1 would be Clojure, and then the others listed above.
Earlier quoted context omitted.
What's the most popular Lisp in use today? Does it come with a static compile type checking?
Rather than most popular, I propose using the most useful. That'd be Lumen. http://github.com/sctb/lumen It's the only lisp that can interface seamlessly with any JS library you want. Just `npm i leftpad && LUMEN_HOST=node lumen` and type `(require 'leftpad)`. $ npm i leftpad $ LUMEN_HOST=node lumen > (require 'leftpad) function > ((require 'leftpad) "foo" 5) "00foo" Other lisps are nice, but they all try to build th…
(edit: it's all in the repo.)
Follow-up: I don't see much in the way of interop documentation... Pointers?
Earlier quoted context omitted.
I currently love both Go and Lisp. They are the opposites of each other. And good for different things.
They have still one thing in common - that are not oop!
Earlier quoted context omitted.
I agree that the macro example is not chosen well. Macros are just functions that take their arguments unevaluated and output code, so each macro call could be replaced by a function call where the arguments are wrapped in a list and the function executes the code directly instead of generating it. Then the only reason you'd have to use macros is if you want to do something at compile time. Like generating specialize…
But as the article states, compile time is (or can be) at runtime.. so it's a bit difficult for me to wrap my head around its practical effect :)
Earlier quoted context omitted.
Rather than most popular, I propose using the most useful. That'd be Lumen. http://github.com/sctb/lumen It's the only lisp that can interface seamlessly with any JS library you want. Just `npm i leftpad && LUMEN_HOST=node lumen` and type `(require 'leftpad)`. $ npm i leftpad $ LUMEN_HOST=node lumen > (require 'leftpad) function > ((require 'leftpad) "foo" 5) "00foo" Other lisps are nice, but they all try to build th…
Lumen seems interesting, but at a quick glance the GitHub repo has zero information as to how to install it and getting it to run. Is it an npm package/lua rock as well? (edit: it's all in the repo.) Follow-up: I don't see much in the way of interop documentation... Pointers?
You can see what each expression compiles to by passing it through (print (compile (expand ...)))
For example:
> ((require 'leftpad) "foo" 5)
"00foo"
> (print (compile (expand '((require 'leftpad) "foo" 5))))
require("leftpad")("foo", 5)
> (define-macro see (x)
`(print (compile (expand ',x))))
(macro: function)
> (fn (x) (+ x 1))
function
> (see (fn (x) (+ x 1)))
function (x) {
return x + 1;
}
If you have questions, be sure to reach out or post them here. The maintainer is also quite responsive to opening new issues.
Every time, I see one of these links or videos, I feel the urge to learn Lisp. But after some time, I lose the motivation. I think that is because I don't know what benefit learning lisp will provide me concretely. Anyone has any suggestion?
Don't force it. It will come at the right time. Enjoy your spot on the programming map, it's no use to learn Foo if it means you'll suffer your day job or can't get enough value out of it. That said, lisp is a goldmine / rabbithole crossover. As other said: - opens for a hackable tool mindset, use lisp on lisp to make it do what you need [1] - as said in this talk, if you want a dsl, you don't need a parser. Only lat…
REPL's are common, but they're rarely as useful in other languages. Even relatively basic (to Lisp programmers) things are almost universally missing, for example:
[1]> (defun f (x) (1+ (g x)))
F
[2]> (f 4)
*** - EVAL: undefined function G
The following restarts are available:
USE-VALUE :R1 Input a value to be used instead of (FDEFINITION 'G).
RETRY :R2 Retry
STORE-VALUE :R3 Input a new value for (FDEFINITION 'G).
ABORT :R4 Abort main loop
Break 1 [3]> :r3
New (FDEFINITION 'G)> (lambda (x) (* x 2))
;; Now that we gave an fdefinition for G, our (f 4) call can continue, so it
;; resumes execution and completes. Until now, it was just paused--no stack
;; unwinding unless we ask for it.
9
[4]> (g 10)
;; Because we used STORE-VALUE, it went ahead and saved the value we gave in
;; G for future use. If we had used USE-VALUE, it would have finished the (f
;; 4) call using that definition, but G still wouldn't be fbound after.
20
Mutable arrays are ubiquitous in Lisp. Explicitly cdring down lists is mostly only done in introductory textbooks; in practice, most people will use MAP, REDUCE, REMOVE-IF-NOT, etc instead, which all work just as well on arrays or lists, or they might use an imperative construct like DO, LOOP, or ITER (also note that conses are mutable as well; it's not at all unusual to setf a car or cdr or call NCONC). It's not terribly different from what you would do in eg modern Java (aside from the part where none of it requires special support from the implementation and it could all be implemented in user code).
I would also add that learning Lisp will teach you a lot about object-oriented programming. Even things that Java programmers use extensions for and give names like aspect-oriented programming just come built in as part of Lisp's stock object system. But then, Lisp's stock object system is also extremely flexible, especially given the pseudo-standard metaobject protocol. Quoting from Wikipedia about the MOP book:
"In his 1997 talk at OOPSLA, Alan Kay called [The Art of the Metaobject Protocol] "the best book anybody's written in ten years", and contended that it contained "some of the most profound insights, and the most practical insights about OOP", but was dismayed that it was written in a highly Lisp-centric and CLOS-specific fashion, calling it "a hard book for most people to read; if you don't know the Lisp culture, it's very hard to read"."
Earlier quoted context omitted.
"Do the right thing" is a brave statement for a language with no typechecking!
"Do the right thing", in this context, goes beyond just the presence or absence of typechecking. But regarding type checking, Lisp (at least Common Lisp) is strongly typed. Really, very strongly typed (for example it will complain about putting a "byte" in a "character" array; or of using an "array" when a "simple-vector" was expected... Lisp is very nitpicky regarding types!), but the type checks happens mostly at r…
Just a note that this is entirely implementation-dependent. SBCL, for instance, is very good about using type declarations as correctness checks (those that can't be statically verified transparently degrade to runtime assertions) but their exact behaviour isn't specified in the standard; for example, implementations are free to take them as declarations that the programmer knows things the implementation doesn't and to trust them, which could cause weird bugs if they're not correct.
Earlier quoted context omitted.
While I agree with you, it's important to note that the defining trait of Lisp isn't that it's a functional language. It can be functional, just as it can be object oriented or procedural, but those labels matter less to what Lisp is than does the intense focus on things like metaprogramming, in my opinion.
That is far from the defining trait of lisp. Probably brought about because it was easy to pass around functions in lisp. However, i find lisp is at its most powerful when you understand some of the imperative abstractions that are available to you.
There was always more to Lisp (I read a cute essay from the mid-60s about how to balance assignment-and-goto style programming with recursive-pure-function style programming in Lisp), but older people making that connection isn't unreasonable, or younger people who've only heard older people talk about it.