Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Lisp?

nyxt.atlas.engineer

Post reply on HN
Print view View original

261–270 of 339 posts

Re: Why Lisp?

#261

Post by Capricorn2481 »

akira2501 wrote: post #72
dehrmann wrote: post #61

> The developers of Lisp give you the full powers that they had to develop the language. So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? And the abstractions provided by modern languages are woefully incomplete? > Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation You could say the same about Java and 2…

> they have to learn Inhouse Lisp? Is this much different from selecting a particular vendor deployment stack, such as react native, or a particular GUI toolkit such as Qt? So.. now I don't just have to know C++ I have to know C++/Qt, or not just JavaScript but JavaScript/React?

Yes. Because React has documentation and in-house Lisp almost never does

Re: Why Lisp?

#262

Post by foldr »

kazinator wrote: post #233
foldr wrote: post #228

Earlier quoted context omitted.

It’s not a problem if you don’t need zero cost abstractions (which indeed you may not, depending on your domain). But if you do, then using the FFI to define unboxed arrays of a simple 2D point class is considerably less attractive than writing struct Point { float x, y }; Point points[10]; If you really can’t see this then I think we’re at an impasse.

In Lisp, we can embed a lower-level language, and macro over it. Like the defx86lapfunction forms in this file: https://github.com/Clozure/ccl/blob/master/level-0/X86/x86-a... It would be useful to have a more abstract, portable form of this (vaguely analogous to WebAssembly): a way to write code for a low level virtual machine that translates to native code.

You're basically describing C++.

Nothing in your link suggests a practical way of constructing unboxed arrays of structs in CL. And even if it did, it would presumably be one that worked only on a specific architecture.

Re: Why Lisp?

#263

Post by foldr »

medo-bear wrote: post #238
foldr wrote: post #228

Earlier quoted context omitted.

It’s not a problem if you don’t need zero cost abstractions (which indeed you may not, depending on your domain). But if you do, then using the FFI to define unboxed arrays of a simple 2D point class is considerably less attractive than writing struct Point { float x, y }; Point points[10]; If you really can’t see this then I think we’re at an impasse.

sure taken separately that looks more elegant. but, provided your whole program is complex enough, i think if you take a step back your language of choice is gonna look like a pigs sty compared to the same thing written in common lisp. i think the amazing thing about common lisp as a high level language is that it can be a low language also. imo it is an unmatched balance of a high/low level language

Are there any examples of elegant CL code that performs lots of vector geometry calculations? I'm skeptical that this sort of code would come out elegantly in CL (at least if it had to perform reasonably well).

Re: Why Lisp?

#264

Post by Capricorn2481 »

reikonomusha wrote: post #259
dataangel wrote: post #194

Earlier quoted context omitted.

Coalton doesn't actually work: https://github.com/coalton-lang/coalton/issues/84?s=09 This is why it's important to always look at the issues on a repo instead of just believing what's in the README. It fails to detect type errors in some of the most basic situations

"Coalton doesn't actually work" is extremely disingenuous and easily misinterpreted to mean something that is not true. Coalton does work, and has been deployed for use in production on non-trivial, commercial problems. [1,2] Mutation is an issue with any Hindley-Milner system, because mutation is inherently impure and non-functional, violating principles that the Hindley-Milner algorithm relies on. The Coalton devel…

Honestly you're defending this a little too much. Nobody cares about an unfinished LISP spin-off that may be production ready some day. The OP's point still stands, CL lacks static types.

This is frustratingly common with niche languages (and I am not saying CommonLisp is not productive, itself). If people are criticizing a missing feature in a language and the response is "Yeah, but we have some bespoke third-party solution available here," it's like the responder has missed the whole point.

Re: Why Lisp?

#265

Post by foldr »

lukego wrote: post #234
foldr wrote: post #228

Earlier quoted context omitted.

It’s not a problem if you don’t need zero cost abstractions (which indeed you may not, depending on your domain). But if you do, then using the FFI to define unboxed arrays of a simple 2D point class is considerably less attractive than writing struct Point { float x, y }; Point points[10]; If you really can’t see this then I think we’re at an impasse.

I can meet you in the middle on "considerably less attractive" :-) For what it's worth, if I wanted zero-cost then the way I'd probably write that in Common Lisp would be with a more spartan abstraction like: (deftype f () 'double-float) (deftype points () '(simple-array (2 *) f)) (-> euclidian-distance (f f f f) f) (defun euclidian-distance (x1 y1 x2 y2) (sqrt (+ (expt (- x2 x1) 2) (expt (- y2 y1) 2)))) (-> point@ (…

Try extending this approach to, say, a Polygon datatype and see how far you get :)

Re: Why Lisp?

#266

Post by reikonomusha »

Capricorn2481 wrote: post #264
reikonomusha wrote: post #259

Earlier quoted context omitted.

"Coalton doesn't actually work" is extremely disingenuous and easily misinterpreted to mean something that is not true. Coalton does work, and has been deployed for use in production on non-trivial, commercial problems. [1,2] Mutation is an issue with any Hindley-Milner system, because mutation is inherently impure and non-functional, violating principles that the Hindley-Milner algorithm relies on. The Coalton devel…

Honestly you're defending this a little too much. Nobody cares about an unfinished LISP spin-off that may be production ready some day. The OP's point still stands, CL lacks static types. This is frustratingly common with niche languages (and I am not saying CommonLisp is not productive, itself). If people are criticizing a missing feature in a language and the response is "Yeah, but we have some bespoke third-party…

Common Lisp, as defined by the standard, does not have static types. As such, Common Lisp will never have static types as a built-in language feature. For the people who care about built-in languages features alone, and not what the library ecosystem has to offer, the discussion could very well end there.

Most programmers seem to care what the library ecosystem has to offer, though, so long as said libraries are actually working and useful. Is Coalton such? It's a technology that has been in development for around 5 years, that is presently used for commercial purposes, and that offers an approach to static typing a la Haskell's type system within Common Lisp projects. It's not a slapdash weekend project that purports to do something, only to find it really only does 5% of what was advertised. All things considered, it seems reasonable to suggest it as an option for static typing.

Production-readiness is a gradient. (Or, less usefully, it's a binary quality determined by the question, "Is it used in production at a company?") I wouldn't personally use Coalton to build real-time rocket control software for many reasons, the most important of which is that it's not billed as a "1.0" product. But I also wouldn't dismiss it because it has a bug tracker with an exposition on an intrinsic limitation of Hindley-Milner type inference. Coalton is a tool built in Common Lisp that is used in production, today, now, as documented by those links in my GP comment. You can even be paid real money to develop Coalton and/or software in Coalton.

Look, I get that people are tired of this peculiar rhetoric, the

> Lisp has macros therefore it's always one step away from implementing any popular language feature.

kind. For a variety of reasons, it's usually not true in a practical sense, and ultimately leaves the would-be user holding the bag.

I suggest, however, that Coalton really isn't a smokescreen that just exists to duly check off a "Has Static Types?" feature checkbox for Common Lisp.

Re: Why Lisp?

#267

Post by Capricorn2481 »

erichocean wrote: post #192
pmarreck wrote: post #167

Elixir is like a LISP with pure functions, only immutable values all the way down (which gets you a guarantee you wouldn't have otherwise in languages where this is optional), actor concurrency, pattern-matching, actual readable syntax, and of course macros (which do the same thing LISP macros do- Accept and output an AST value that happens at the compilation step- the only difference being LISP homoiconicity). It si…

Clojure does all three: 1) Native, compiled binaries with GraalVM. 2) ClojureScript (already mentioned) for the browser. 3) For ML, Clojure in the last 2-3 years has built a really great internal ecosystem but it hardly matters because libpython-clj exists so you can run NumPy, PyTorth, etc. from Clojure. Getting data in and out of Python land is just as easy as Java-interop. The reverse also works (calling out to Cl…

ClojureDart is not ready. I would be surprised of ClojErl was. And GraalVM is not some drop-in native compiler. You might have to radically change your code to work with GraalVm.

Proposing these things as "ready for the average Clojure noob" is exactly the snake-oil nonsense that turns people off to Clojure

Re: Why Lisp?

#268

Post by jsmith45 »

hajile wrote: post #99
ryukafalz wrote: post #68

Earlier quoted context omitted.

> Python is a good enough Lisp, as Peter Norvig has concluded. And it’s got all batteries included. Ain‘t nothing it can’t do. I almost agree, but Python fails in one area, which happens to be my current area of interest. It doesn't have sufficiently strict encapsulation to support object capabilities[0] at the language level. JavaScript, on the other hand, does[1] - so you don't necessarily need Lisp for this, but I…

It falls short in several key ways. First, it has no macros. The ability to metaprogram in Python is practically nonexistent compared to Lisp. Second, it has no usable lambda (being limited to a single expression in a non-expression oriented language. Most lisps heavily rely on the ability to pass around arbitrary functions whether named or not. Third, it is slow. Your toy scheme implementation is probably going to b…

Python does have plenty of metaprogramming capabilities, they just are more complex to use than a macro system. One simple, but highly limited system is metaclasses. Similarly weak but existing features include creating classes at runtime, and adding new methods to classes at runtime. A far more powerful system is compiling source to AST, which can then be manipulated, and finally compiled to bytecode. This allows arbitrary metaprogramming, but is certainly fairly complex.

One could even use it to implement a macro-like system by coding up a new finder that uses a new SourceFileLoader subclass that overrides the (accidentally undocumented!?) `source_to_code` method. In there, one can compile to ast, transform the ast, and then compile the ast to bytecode. (The method was documented back in 3.4 by way of being documented on a ancestor abstract base class, but that documented ancestor was changed to be static in 3.5, leaving this method seemingly accidentally undocumented.)

For the transform the AST step, one might look for apparent function calls to special macro functions, and instead call those macro methods as AST time passing in the AST of its arguments, receiving back as AST that you place in the tree replacing the function call. There is some trickiness here. For example, it is much easier if the macros are defined in another module so that they can already be compiled, and thus available while importing a module that uses them.

It should also be possible to handle macros defined in the same file by stripping out non-macro function definitions, and non-imports from top level statements, compiling that, and then using the result while processing the whole (unstripped) AST, and then finally compiling the result.

Of course such a system is significantly more complicated than with a lisp, but it is still possible. Its load time performance is also not likely to be especially wonderful, but python is not exactly a performance powerhouse.

Re: Why Lisp?

#269

Post by nkjnlknlk »

hajile wrote: post #253
bjoli wrote: post #218

Earlier quoted context omitted.

Is it? HN is mostly static content. Ten years ago I wrote a simple web application using twister (python) that did well over a thousand requests per second. If we count just handling requests (and not churning out much data or doing anything fun processing) japronto for python claims to handle something like 1.2 million req/s on a single thread.

The most frequently access parts of the site are always in flux with users constantly adding, removing, and editing content. I don’t know how you could statically generate that. At most, you could memoize the parts of the page that haven’t changed yet and return them without a complete lookup, but keeping that in synch with a database is not an easy problem.

HN doesn't have that much traffic so it's easier than you might think!

Re: Why Lisp?

#270

Post by lukego »

foldr wrote: post #265
lukego wrote: post #234

Earlier quoted context omitted.

I can meet you in the middle on "considerably less attractive" :-) For what it's worth, if I wanted zero-cost then the way I'd probably write that in Common Lisp would be with a more spartan abstraction like: (deftype f () 'double-float) (deftype points () '(simple-array (2 *) f)) (-> euclidian-distance (f f f f) f) (defun euclidian-distance (x1 y1 x2 y2) (sqrt (+ (expt (- x2 x1) 2) (expt (- y2 y1) 2)))) (-> point@ (…

Try extending this approach to, say, a Polygon datatype and see how far you get :)

Hard to please some people :)
Post reply on HN