comma_at

Disclaimer: I use both at work and prefer clojure.

Common Lisp is huge, which is fine. In some concepts it is closer to traditional languages (mutable data structures, multiple inheritance OO, tools to write low-level efficient code). It is more extendable than clojure (reader macros, symbol macros, CLOS and MOP). With quicklisp you can find most of the libraries you might need.

Clojure is much more different from traditional languages. It puts immutable maps and vectors up front and expects you to work with data directly. Why is that preferable is hard to explain in a short post, if you're interested about the ideas I'd recommend watching Rich Hickey's talks like Value of Values[1].

> neither of these languages can help me much in finding a new job

I don't know about CL but there are clojure shops hiring. Depending on your employer if the JVM is being used you might get a chance to use clojure as well (or CL through ABCL for that matter). It's also used by some shops for the frontend. And for your own work you can often choose what to use. Both can be used as a scripting language (clojure through babashka[2]).

> CL sounds like the logical choice because of SLIME

I'm not sure what you mean.

> Clojure sounds like the choice to avoid because of the JVM and the fact that I already know Go that plays in the same domain...

I don't get the JVM hate. Sure, every platform has its issues, but the JVM is a highly tuned virtual machine that has decades of development behind it. It is cross platform. It is used for high performance projects as well. It has libraries for everything.

[1] http://infoq.com/presentations/Value-Values [2] https://github.com/babashka/babashka

The coronavirus alreay spreads before showing symptoms.

The clojurians zulip chat[1] offers a free, full-text-searchable archive of slack.

Also, IMHO it's much better than slack for chatting. If only everyone switched!

[1] https://clojurians.zulipchat.com/

That's false, building an uberjar has nothing to do wit that. If you're packaging an application typically your -main needs to be AOT compiled, that's why you put :gen-class in your ns declaration. That namespace will get AOT compiled. This still doesn't pose any issues since you shouldn't be doing such side effects in the toplevel. So

    (alter-config-file!)

is bad because that code will run during compilation, but in

    (defn -main [& args]
      (alter-config-file!)
      (app!))

it will run only after calling -main.

Either you missed the context or are pulling a straw man. Building a simple VM is not unique, but can you build one that will be competitive with the other's in a reasonable timeframe?

Unless you provide one of

- a simple VM implementation - code using a JIT framework - using Apache Impala on this particular dataset

which performs on par and didn't take astonishingly long to write then these are just vague claims and hypotheses.

> Who guarantees that if you combine `my-dsl-1-macro` with `my-dsl-2-macro` or simply with general purpose code, that they don't interfere in odd ways?

Nobody does. But that's where the power lies. You can't have unrestricted power with restricted features. Lisp gives you unrestricted power. It's up to you to use it correctly, for w/e definition of correct your context makes sense.

I think the point is just because there's an EOL doesn't mean everyone will be ready or even willing to jump the ship. Companies run all sorts of old software. In 2017 7% of PCs were running Windows XP[1], which had EOL in 2014[2]. Why do you think an EOL will magically stop people using python 2.7? I'm sure even new code will be written after its EOL.

[1] https://www.businessinsider.com/how-many-people-use-windows-... [2] https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp...

Calling out fallacies while commiting more is, well, funny.

> Encoding invariants in a type system is far cheaper than writing tests.

You may need to back that claim up with something or you're going to be anecdotal as well.

> Rejecting an entire field of study (like types!) is not only anti-intellectual, but also does nothing to move the state of our industry forward.

Who says type theory is needed to move our industry forward? Even if you think that why would every language need to use it? This is slippery slope.

> I’d say that’s especially harmful now in a time where software errors can bring down a couple of Boeing 787 Max airplanes and kill hundreds of people.

Was the crash the result of a bug that a type system would have solved? Otherwise this is quite the straw man too.

I think (s)he was talking about BEAM. Using RabbitMQ makes no difference if you're not programming in Erlang. If you look at the BEAM VM you will see isolated processes, supervisors, restart strategies etc. Wikipedia[1] lists Erlang's runtime system characteristics: "Distributed, Fault-tolerant, Soft real-time, Highly available, non-stop applications, Hot swapping, where code can be changed without stopping a system." Does that ring any bells?

[1] https://en.wikipedia.org/wiki/Erlang_(programming_language)

Way overthought. There's 3 things happening: 1. Waiting. We have `sleep` for that, or `at` or `cron` if one wanted a different interface. 2. Accepting seconds in a more user-friendly format. We should make a separate program for that so we can reuse it in other contexts. 3. Notifying. Notify-send is all we need. The -c addition echoes back the output with 2 new words and a newline. No added value. If there's need for another backend like echo one could rather implement --notify-with (notify-send|echo|...) or --json to allow other consumers but at least add the seconds-to-wait information as well. I don't see much added value in that anyway though.

So..

> Some might see the expansion of a single compound command into a nearly 200-line script as a sign of everything wrong with modern software development.

No, just avoid - looking for functionality that noone is asking for (YAGNI) - complecting

Hard to say without context. Was the change discussed with the core team? Did they say yes and then suddenly backed out? Otherwise I don't see much reason for being frustrated.

Emacs has evil-mode which implements vim's bindings so of course this can be done. Give it a spin though, you might find that some of your customization isn't even needed here, the design is very clean and composable, even more than vim's I'd say.

I'm no developer but I've been using kakoune for editing for the past month or two and the experience is very good. Mawww has been working on the editor for the past 3 years so it's in a pretty good shape. Programming-wise there's syntax highlighting for many languages already, check out https://github.com/mawww/kakoune/tree/master/rc for a list. Adding a basic syntax highlighter is simple enough as well. IDE-wise you'll get the best experience when writing c/c++ I think as the author does that and put a lot of effort in it running smoothly. Editing-wise I like the features more than vim's or emacs'. Working with multiple selections is very effective, fast and fun. Stability-wise I don't think you have to worry too much anymore, there's occasional bugs that are fixed very quickly and the key bindings are pretty much set (there's a minor change every now and then when implementing new bindings but nothing major). Customizing-wise there's enough options and they are quite well thought out. There's no vimscript or elisp, for the design choices check out https://github.com/mawww/kakoune/blob/master/doc/design.asci... . The author is also very responsive to suggestions and is implementing features the users are asking for (if they make sense and conform to the design of course).