Live data from Hacker News

Why Lisp? (2015)

blog.rongarret.info

121–130 of 174 posts

Re: Why Lisp? (2015)

#121
post #69

Why does it feel like there’s more prose about lisp being written than lisp code? I swear there’s like 15 people writing Common Lisp — Nikodemus, Shirakumo, Stylewarning, Christian Schafmeister, Borodust, the ITA folks, and maybe 2 startups.

That is because it is a little secret. It is a secret hidden in the open. We program in C#, we program in swift, C and C++, but we continue using so much Lisp as I did 20 years ago or way more. With Lisp you don't need to write only Lisp, you can write swift or any other language in Lisp, as we do. When people ask what programming languages we use, even competitors, we just tell them. They don't listen. They just can…

> Lisp guys have nothing to sell you but probably the software they create. And if they have a powerful tool, they are not that interested on you knowing their secret.

This level of claim is indistinguishable from fiction.

Re: Why Lisp? (2015)

#123
post #3

Better question: why not Lisp?

Can I be extremely shallow? Because the language feels like it's from the 60s. Like writing Fortran or Ada or Algol in 2021. C is timeless, it doesn't count. I love lisps, but Racket, for example, feels more modern than Common Lisp to me. And for shallow people like me, feel and ergonomics are very important when writing code.

C was already pre-historic in the 1990's, of course it counts.

Re: Why Lisp? (2015)

#124
post #76

Earlier quoted context omitted.

> TCL is forever parsing the strings it passes around. No it isn't. Tcl has had dual-ported objects and a bytecode interpreter for over 20 years.

Well I learned something. But if you represent a list as a lift of strings wouldn’t it have to parse them as Argv in the c implementation? It has been a while but only 17 years since I wrote TCL commands but each one started with a list of strings. Maybe the byte code interpreter doesn’t work with older C extensions? But the main selling point of TCL was easy extension.

Only if you were using the pre-Tcl 8 FFI API, our startup was built on a Tcl "Rails" similar to AOL Server, and we did plenty of native bindings.

Re: Why Lisp? (2015)

#125
post #37

Everyday there's at least a post about Lisp. But I see none about TCL that is as regular in syntax as Lisp. Some call it a Lisp without parenthesis. TCL is also very stable between releases, it has industrial strength and threading support. But it lacks advocacy. It could get one tenth of what Lisp gets...

Tcl is quite nice, having been part of a product similar to AOL Server, I never got the hype around Rails.

Re: Why Lisp? (2015)

#126
post #69

Why does it feel like there’s more prose about lisp being written than lisp code? I swear there’s like 15 people writing Common Lisp — Nikodemus, Shirakumo, Stylewarning, Christian Schafmeister, Borodust, the ITA folks, and maybe 2 startups.

That is because it is a little secret. It is a secret hidden in the open. We program in C#, we program in swift, C and C++, but we continue using so much Lisp as I did 20 years ago or way more. With Lisp you don't need to write only Lisp, you can write swift or any other language in Lisp, as we do. When people ask what programming languages we use, even competitors, we just tell them. They don't listen. They just can…

This, this right here is the attitude I’m referring to. From now on all I’m gonna say is “GitHub or GTFO.” Show me all this lisp you’re writing, or at least tell me the fantastic product you’ve built with it or GTFO.

Re: Why Lisp? (2015)

#127

Earlier quoted context omitted.

that's basically Julia. take lisp, remove the s expressions and add a bunch of really good math libraries and you've just reinvented Julia.

there was dylan before julia, so julia might just be reinventing dylan :) but that's not what's interesting the julia project is in fact very interesting to me and has a great team developing its ecosystem and i work with it alongside python for numerical work. however one key drawback (compared to common lisp) for me is that it is not self-compiled. it is hosted on llvm and over 30% of its repository is in another l…

It would be really cool to make Julia self hosting. The easiest non-julia in Base to replace is the parser which currently is in femtolisp. Most of the c++ code is just LLVM which we keep our own copy of because Julia has pretty specific LLVM version requirements that OS provided versions are unlikely to satisfy. Getting the C code out would be interesting since it's difficult to bootstrap a language that doesn't like being ahead of time compiled, but it would be a cool project.

Re: Why Lisp? (2015)

#128
post #86

Earlier quoted context omitted.

> ... it goes well beyond any Lisp/Scheme (and many modern languages) in terms of having a practical but expansive ecosystem with a strong set of idiomatic conventions. Does it, really?? Common Lisp is an ANSI Standard, I don't know how you get a more "strong set of idiomatic conventions" than that. And it's been "done" for 20 years now! People continue to use it just as it is, and there's very little pressure to cha…

In fairness, the CL spec being quite old, has a fairly dated type system. Obviously, CL is still blazing fast compared to Python, but it can't easily do the kind of things that Julia or even C++ can when it comes to numerical programming. You can write a lot of macrology to get around it, but there's a point where you want actual compiler writers to be doing this.

> You can write a lot of macrology to get around it, but there's a point where you want actual compiler writers to be doing this

this is not the job of compiler writers (although writing macros is akin to writing a compiler but i do not think that this is what you mean). in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the drivers to the underlining hardware are closed-source [0]. also here is the similar library in common lisp [1]

[0] https://github.com/JuliaGPU/CUDA.jl

[1] https://github.com/takagi/cl-cuda

Re: Why Lisp? (2015)

#129

Earlier quoted context omitted.

Can I be extremely shallow? Because the language feels like it's from the 60s. Like writing Fortran or Ada or Algol in 2021. C is timeless, it doesn't count. I love lisps, but Racket, for example, feels more modern than Common Lisp to me. And for shallow people like me, feel and ergonomics are very important when writing code.

> C is timeless, it doesn't count. Of course C counts. IMO it is a language that should have stayed in the last century. > feel and ergonomics are very important when writing code This is the reason why I can't stomach languages like Java, C++, etc.I feel like I'm fighting a very constrained interface.

C's succesor is either Go or Plan9/9front's C. Outside of "Unix 2.0", you have Go.

Please, do not compare Java and C++ against C, C++ is a monster it should never have born, and Java it's a shitty TCL "alternative" from its era.

Re: Why Lisp? (2015)

#130
post #129

Earlier quoted context omitted.

> C is timeless, it doesn't count. Of course C counts. IMO it is a language that should have stayed in the last century. > feel and ergonomics are very important when writing code This is the reason why I can't stomach languages like Java, C++, etc.I feel like I'm fighting a very constrained interface.

C's succesor is either Go or Plan9/9front's C. Outside of "Unix 2.0", you have Go. Please, do not compare Java and C++ against C, C++ is a monster it should never have born, and Java it's a shitty TCL "alternative" from its era.

If anything zig or rust are the successor, Go is a language from the 90s. We can agree on C++ and java, though.
Post reply on HN