41–50 of 174 posts
What's a good Lisp dialect to write small programs in? I have some Emacs Lisp experience but I wouldn't use it to automate small tasks. For that, I typically use Python.
Earlier quoted context omitted.
Performance: Getting Lisp to run as fast as C takes major effort when at all possible. Resources: Lisp needs a lot of space to do it's thing; and while it's certainly possible to downsize it, you're left with something that's not really Lisp anymore. Ecosystem: Finding solid libraries is tricky since it's not very popular professionally. Power: Unleashing the full power of Lisp in a diverse team is a recipe for an ad…
If performance was such a problem python wouldn't have a subreddit. I think a lot of lispers like handling various paradigms in their head and start with basic lisp, and resort to edsl to reach more appropriate semantics/mechanical sympathy. Just like people call out to C wrappers mostly. The social side of lisp I can't say for sure but I'm sure it's fuzzier than it seems. I've just talked to a dude saying his new gu…
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...
Earlier quoted context omitted.
> Getting Lisp to run as fast as C takes major effort when at all possible. But Lisp is faster than almost every widely used language that's not C/C++/Rust, around Java speed. > Lisp needs a lot of space to do it's thing; and while it's certainly possible to downsize it, you're left with something that's not really Lisp anymore Dunno, by modern standards it seems pretty small. > Finding solid libraries is tricky sinc…
> There's code out there for most use cases, at least for back-end-y things. I'm not sure about that. These days in the backend you need a lot of libraries for cloud providers and new databases/services. For example, is there a Common Lisp library for AWS/Azure/Google cloud? Is there one for Clickhouse?
Clickhouse doesn't have an official CL client but they have a CLI, TCP and HTML interfaces, C++ interface, etc... all listed on their website. It's not that hard to connect to an API without a library.
But yes, there's more Java/Python/Go/Ruby/JS stuff pre-built than Common Lisp. But you'll also find more CL stuff out there than almost any esoteric language, probably because it's easy to build stuff in CL.
What's a good Lisp dialect to write small programs in? I have some Emacs Lisp experience but I wouldn't use it to automate small tasks. For that, I typically use Python.
What's a good Lisp dialect to write small programs in? I have some Emacs Lisp experience but I wouldn't use it to automate small tasks. For that, I typically use Python.
They both work really well for little scripts and tools where i found clojure startup time annoying.
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...
Lisp compiles to native code, 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.
Earlier quoted context omitted.
Performance: Getting Lisp to run as fast as C takes major effort when at all possible. Resources: Lisp needs a lot of space to do it's thing; and while it's certainly possible to downsize it, you're left with something that's not really Lisp anymore. Ecosystem: Finding solid libraries is tricky since it's not very popular professionally. Power: Unleashing the full power of Lisp in a diverse team is a recipe for an ad…
> Getting Lisp to run as fast as C takes major effort when at all possible. The Computer Language Benchmarks Game shows Lisp Code as generally being between 2x and 10x slower than C++[1]. As fast as C? No. Way faster than Python, and more than fast enough to be used in almost every single application, modulo hard-real-time systems and AAA video games? Yes. > Lisp needs a lot of space to do it's thing; and while it's…
One of my favorite stories of the ideas of lisp commercially is a dialect that Naughty Dog developed for their game development.
It started as being developed for Crash Banicoot on the PS1.
Which is really interesting given how limited the system was (1mb to 2mb of ram depending on what you were doing with the system!)
They later iterated on it for Jak and Daxter on the PS2. To quote the wikipedia page:
> GOAL does not run in an interpreter, but instead is compiled directly into PlayStation 2 machine code to execute. > ... > GOAL has extensive support for inlined assembly language code using a special rlet form,[1] allowing programs to freely mix assembly and higher-level constructs within one function. > ... > It supports a long term compiling listener session which gives the compiler knowledge about the state of the compiled and thus running program, including the symbol table. This, in addition to dynamic linking, allows a function to be edited, recompiled, uploaded, and inserted into a running game without having to restart.
[https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp]
I almost don't believe it, honestly.
In most modern engines I've used we STILL struggle hard for a perfect live-reload system.
I've implemented many types of custom interfaces that let you tweak things on the fly in my games, and it's almost criminal how much better/productive it feels vs. the 'tweak, compile, test' loop we're usually stuck with.
All that said, I see the same reason of why companies always transition away from lisp all the time:
> In all honesty, the biggest reason we're not using GOAL for next-gen development is because we're now part of Sony. I can only imagine Sony's shock when they purchased Naughty Dog a few years back, hoping to be able to leverage some of our technology across other Sony studios, and then realized that there was no way anyone else would be able to use any of our codebase.
It really makes me wish some big company would make a python clone in lisp, but put a tiny escape hatch in to fully utilize the lispy parts.
Earlier quoted context omitted.
> Getting Lisp to run as fast as C takes major effort when at all possible. The Computer Language Benchmarks Game shows Lisp Code as generally being between 2x and 10x slower than C++[1]. As fast as C? No. Way faster than Python, and more than fast enough to be used in almost every single application, modulo hard-real-time systems and AAA video games? Yes. > Lisp needs a lot of space to do it's thing; and while it's…
>> Finding solid libraries is tricky since it's not very popular professionally. > This one is so true it's not even funny I'd say that's a bit out of date as Quicklisp has made a huge difference for CL. Obviously it's still not the most library-rich ecosystem but it's come a very long way.
Earlier quoted context omitted.
I cut my teeth on Lisp, but I've found that happiness comes from compile time guarantees. Maybe those two things aren't mutually exclusive, but a thoroughly robust type system seems like a big ask in such a dynamic language. None of the solutions I've encountered have satisfied me, but in fairness I haven't looked that hard.
I have 0 experience here but that's really surprising to me. I'd think out of any language lisp would shine here. You could write as complex of a type system as you wanted that compile time checks, so it's surprising someone hasn't written one that mimics at least java/c++/whatever style types. I do think that is one of the down sides to lisp though. When you can do almost anything it's very hard to agree on what to…