bo-tato

there's a much faster regex library: https://github.com/telekons/one-more-re-nightmare

The main thing I like is basically you always have a debugger present. When you run into some issue you don't have to restart your program in a debugger and recreate it. Even running in production you can remotely connect to your program and inspect everything about it. Another thing about this is that when exceptions happen you're dropped in the debugger before the stack is unwound, and you generally have options to recover and continue execution without restarting everything and losing your state, which imo is the only sane choice for a dynamic language where you know you will be getting some type errors at runtime in development at least. Everyone knows the frustration of starting some python script, having it run for 10 minutes only to have it crash on some exception that you have to fix and restart. Also I'm not entirely sure why, I think because CL does more checks at compile time, and there is more type checking, I tend to get fewer runtime errors and they're closer to the source of the problem and easier to debug than in other dynamic languages. Then there are questions like what happens to existing instances of classes when you add fields or otherwise change them, which CL handles (https://malisper.me/debugging-lisp-part-3-redefining-classes...), but other language REPLs don't.

Regarding the syntax of those type declarations, it's true I also thought CL was verbose and ugly at first, but it is also extremely flexible through macros and reader macros. At the end of the day I think it's easier to improve that in CL that it is to make other languages support the interactive development of CL which requires fundamentally rewriting the language runtime. For those type declarations specifically, there is serapeum which is a extremely commonly used library, that provides -> for more ergonomic type declarations, ie:

  (declaim (ftype (function (string string) string) concat))

would become: (-> concat (string string) string) there is also https://github.com/lisp-maintainers/defstar for providing more ergonomic type declarations inline in definitions

And this is another thing I'm not sure how to explain, I thought CL is surely more verbose and ugly than python for small scripts, but maybe it's macros will make it cleaner for building large systems. But then when I started writing actual programs, even small programs without any of my own macros, I generally use about 30% less LoC than in python... I've thought about making sly/slime like support for python (built on ipython with autoreload extension) or ruby (with it's fairly new low-overhead debug gem). But at the end of the day support for these things will always be incomplete and a hack compared to CL where it was designed from the start to support it, they run 20-100x slower than CL, and imo their runtime metaprogramming is harder to reason about than CL which is mostly compile time metaprogramming. When I've had to dig into some CL library, which is a lot more often than in those languages because it has 10000x fewer users so of course I will be first to run into some issue, it has generally been easy to understand what is going on and fix it, compared to large codebases in other languages.

Regarding "modern type-safe language", languages with expressive type systems, rust, ocaml, haskell, typescript, etc, can give really confusing type errors, when you get into generics and traits and more expressive stuff. I'm not convinced it's a better development experience than a dynamically typed languages where values have simple types, and when you get a type error you see the actual contents of the variable that is the wrong type and state of the program, at least in the case of CL where the stack isn't unwound on error and runtime is kind of compile-time as you're running all code as you write it. But mostly this sort of interactive development is very hard to implement in static languages, I'm not aware of any that does it. For example even in static langs like ocaml that have a repl through a bytecode interpreter, simple things don't work like say you pass some function as an event handler, and then update the function. As you passed efectively a function pointer to the old definition, rather than a symbol name like lisp, it will be calling the original function not the new version. But the main issue is that efficient staticly typed languages the type system is all at compile time, type information doesn't exist at runtime, which is great for performance, but means you don't get the ability to introspect on your running program like you do in CL and elixir, which personally I value more than full compile-time type checking.

Would I like some new language or heavy modification of existing language runtime that provides the best of everything? of course, but I also realize that it's a huge amount of work and won't happen with 10 years, while I can have a nice experience hacking away in CL and emacs right now. And ultimately CL is an extremely flexible language and I think it'll be less work to build on CL than to provide a CL like runtime for some other language. For example projects really pushing the edge there is Coalton described above. While personally I prefer dynamicly typed for general application programming I think Coalton could be great for compilers, parsing some protocol, or writing some subparts of your program in. And vernacular (https://github.com/ruricolist/vernacular) which explores bringing racket's lang and macro system to CL. For more standard CL code, using extremely common and widely used libraries like alexandria, serapeum, trivia, etc, already makes CL into a fairly modern and ergonomic language to write.

Edit: also about the lack of line numbers in the compiler message, it's funny I never noticed that and I'm not sure how exactly emacs does it, but for those compiler warnings about types emacs underlines in red not just the line but the exact expression within the line and you can press a shortcut to go to the next and previous compiler warning/error/note. For better or worse emacs is the de facto free development environment for CL (lispworks and allegro are the commercial ones still maintained), though in recent years there are plugins for VSCode and most major editors, I haven't tried them and am not sure how they compare.

And why I love doom emacs, it's almost like vscode in ease of getting set up for different languages. There's a init.el file with a :lang section where you can uncomment languages to enable them. Support for sh is enabled by default, and if shellcheck is installed it will use it without you having to customize anything. It's all the hackability of emacs when you want, but also just good defaults so everyone doesn't have to spend time configuring the same basic functionality.

The experience with distributions like Spacemacs, doom emacs or lazynvim really isn't that much worse than vscode, you select the language you want to code, it installs a reasonable set of plugins and you get to work.

configuring vanilla emacs from scratch is certainly a lot of work. There's various distributions (Doom emacs, Spacemacs) that while not perfect have a pretty decent 'new user' experience without too much work. I don't use Go too much but I've done some projects in it. I just uncommented (go +lsp) in Doom's init.el, ran doom sync, restart emacs, and everything just worked, I didn't feel that need to configure anything further.

You are loading code you wrote, not evaling untrusted user input. Common Lisp is actually safer than a lot of languages in that Java, Python, Javascript, etc all do lots of runtime reflection and metaprogramming that leads to vulnerabilities where lisp metaprogramming is happening at compile time and therefore a lot safer.

If you're just using it for quick scripting, which is where startup time mostly matters, and you only use the stdlib and no external gems, you can use --disable-gems and it starts in half the time as python for me.

In the annual lisp game jam it seems a lot of the submissions and the most polished ones are using fennel, which is a lisp that compiles to lua from the same creator of Janet. Then for lua (and fennel) there is high quality game engines LÖVE (2d games), TIC-80 (retro 2d), LÖVR (3d).

easiest solution I found was building SBCL targetting an old glibc using zig as the c compiler:

CC="zig cc -target x86_64-linux-gnu.2.28" LD="zig cc -target x86_64-linux-gnu.2.28"

zig bundles in all the glibc headers, so I think it should build on musl libc-based distro

for more complicated programs with native dependencies there is (https://github.com/Shinmera/deploy) or guix has a lot of CL libraries already and it's fairly easy to write packages for others, you can specify all dependencies with guix and use guix pack to get a .tar with all dependencies you can unpack and run on any other linux box

It seems with the massive amounts of money and full time engineers JVM has to be far more advanced technically, but does it actually make a difference? I don't know anything about compilers I just know LuaJIT is faster than any dynamic language on the JVM, SBCL is much faster than lisp on the JVM, chez scheme is much faster then scheme on the JVM, pypy is faster than jython. For statically-typed GC languages that should be comparable to Java, Go and Ocaml are famous for having very simple and fast compilers (fast as in they compile quickly without doing much optimization) and they don't perform any worse than Java.

I come from traditional "unix hacking" background and don't know at all the JVM or .NET ecosystems, and share the irrational distrust of them many unix hackers have, though I'd get over it I could actually get stuff done faster with them. But some projects I do are lower level or need high performance or reasonably small staticly linked binaries, or instant startup time (cli utilities), so rust is a better choice. For most of the rest a JVM or .NET language would be fine and should be more productive as it's a higher level language, but I don't know if I'd use it enough to learn the language and ecosystem and tooling enough to be as productive as in python or rust which cover pretty much anything I need to do at the moment.

I think that is also why rust ecosystem will keep expanding and improving a lot. They said about python that it's not the best language for anything but 2nd best for everything, which isn't really true as python can't be used when you'd need C or C++ but rust can really be used for anything.

I tried elixir and enjoyed it. I'm don't have strong feelings either way on static vs dynamic typing, I think the current craze for static typing is a lot because of people's experience with javascript vs typescript. With elixir I of course had runtime type errors but trivial ones that show up on the first run, I don't think I had any hard to find bugs or bugs that surface later that ML typing would've caught. I'd absolutely pick it over rust for web backends, but I do very little of that, I'm mostly writing cli utilities on unix. I've been experimenting with common lisp lately and it's a lot of fun, as fast to prototype with as python (when it has the libraries you need), performance around the level of java or go, great development environment if you use emacs, instant startup time for cli utilities unlike beam or jvm. I think if it was made easier to make and cross-compile fully staticly linked binaries, and it get's something like maturin for python or rustler for elixir to have easier access to bigger ecosystem when needed it'd be great for my uses but at the moment I can't use it for much

> a GC language from the ML family.

What other option is there? I thought the same and wanted a higher-level GC'd language than rust, and played some with Ocaml, Haskell and F#. In theory they should be more productive and I'm sure are for things like compilers and parsers where they have top-quality libraries, but for most things I got the impression that even if I took the time to learn well one of those languages, the quality of libraries and documentation and tooling is so far ahead in rust that it more than makes up for the productivity hit of rust making you concern yourself more with low-level details

it's a normal way to develop in clojure. The primitive no-IDE support needed trick is to just define variables with the names of your function inputs, as in: https://blog.michielborkent.nl/inline-def-debugging.html

and then you can just evaluate expressions within the function. The fancy way with editor support is: https://github.com/vvvvalvalval/scope-capture-nrepl

you make snapshots of the local variables at any point, and later evaluate code in the context of that snapshot. So you do some action in your program that results in that function being called, it'll save the input, you select that snapshot, and now you evaluate in the context of those function arguments as you edit and eval expressions in the function. And while clojure supports interactive development at a level beyond other mainstream languages, Smalltalk and Common Lisp have support for it on another level, for example: https://malisper.me/category/debugging-common-lisp/

There's some study where Smalltalk came out as the most productive language, I don't know whether it's more productive but that kind of interactive development where you build up your program evaluating it the whole time, without ever restarting, is a lot of fun. Why it went out of style I don't know

Interesting, thanks for sharing your experience. I don't doubt the Taliban is evil, but I don't think they're stupid. That they hold family hostage to force people to fight for them I can easily believe. That they kill the family of someone that just carried out an attack for them, and hasn't betrayed them or anything, seems counterproductive for them. As far as I understand paramilitary are part of almost all armed conflicts, to do the dirty work that isn't wanted to be associated with the official military. In some of latin america like you say the US had no official military role for optics and cost. Other countries like Guatemala, Colombia, etc the US had official military advisors present, and funding and cooperation with the official military. And then paramilitary groups also operating that are really just an extension of the official military and intelligence institutions, for doing the dirtier stuff.

Why do you assume the taliban killed his family? if they go around killing family of people that do bombings for them they aren't going to find many people willing in the future. I know nothing of afghanistan but where I'm from (latin america) the US has a long history of training paramilitaries and death squads. My guess just based on that story would be US or Georgian connected paramilitary group killing his family as retribution for killing one of their own, and as a message to scare future people from working with the taliban.

you're totally right that it's often easier to read in the order the functions are being applied. That's why just about every lisp/scheme family language has thread-first and thread-last macros -> and ->> so f(g(h(x))) could be written as: (-> x h g f) Janet, clojure and racket and probably others have them built in, emacs lisp has it in dash.el, common lisp has it in cl-arrows and other libraries

It's really just about readability preference though not ease of editing, lisp like languages will have paredit/sexp editing shortcuts in your editor, so when you're on (f x), you press one key and it's turned into (<cursor here> (f x))

same, and I surprisingly found it quicker to get used to doom emacs coming from vim, than it took me to get used to a modern neovim setup which I also tried briefly