Author here. I am a relative beginner to Julia, having only used it seriously for a few months. For those familiar with Common Lisp, I will try to answer any questions you may have in this thread, that weren't addressed in the article.
1. What's your own probability estimate that you'll be back to Lisp by, say, 2024?
2. Can you elaborate more on "they are very awkward to work with and only offer a subset of the abilities of the Emacs plugin" for vim? What did you find lacking about either slimv or vlime that you absolutely couldn't stand such that you forced yourself to use emacs? I'm most familiar with slimv and am aware of some quirks (and one bad still-open issue related to errors in threads which is annoying to deal with when it bites) and some limitations, but I'm fortunate to be mostly unbothered by them or in one case so far submitting a patch to fix one annoyance. At least, I'm not bothered to the level of abandoning vim -- I'll probably try the VS Code plugin before trying emacs again, or shell out for a LW license. Specifically it's things I see emacs users do like clicking a printed object's memory address to open the thing in the inspector, or having a slightly less ghetto code stepper. I'd rather have other things I miss from my Java life that as far as I know aren't even in emacs for CL.
3. Did you seek out any downer takes when evaluating Julia? What did you think of any of them? Some specific examples include https://yuri.is/not-julia/ or http://danluu.com/julialang/ where Yuri's post is linked at the bottom as a sort of update. If you read anything like that, have you been concerned? Any good "excuse" articles you found that address any downer points?
Anyway, thanks for your work in Lisp Land, both in code and IRC messages.
1) Julia will be my primary programming language for the foreseeable future. However, I am invested in a large CL project that has been on hiatus for a couple years, that will be starting back up soon. I will however only be working on that during our monthly meetings. I don't see new projects being developed in CL, though.
2) The Vim plugins only support SLIME, not Sly, which offers many more features I simply can't live without, such as stickers. Additionally, indentation in Vim cannot be made dynamic. That is, for every macro you write, you are forced to edit a flat file that describes the proper indentation rules. I have a couple thousand lines of my Vim configuration dedicated to working in CL, and it still isn't good enough, compared to the experience in Emacs. And yes, there are countless bugs that don't exist in Emacs/Sly.
3) Yes, I read that post and some others. Bugs like the AbstractArray usage are programmer errors, nothing to do with the language. Julia is 1-indexed by default, but with libraries such as OffsetArrays.jl and CircularArrays.jl an AbstractArray can be indexed at 0. I shrugged most of this post off, because I don't see them as correctness bugs in the language proper. As for the TTFX (time to first plot/execution) as noted in the other article, that is a problem that is actively being worked on currently by Tim Holy, and it's not really an issue if you build your own image anyway, only when you are compiling the code each time you start up your fresh image.
Do you worry about correctness flaws in Julia that make it hard to write robust and correct code when you get deep into the weeds while developing libraries meant to be used by others or meant to interoperate with other libraries? It is not a problem with Julia but seems to be a problem in Julia's library ecosystem. It bothers me. Does it bother you?
Would you prefer to add correctness tests to the compositionality that Julia gives “for free” due to multiple dispatch, or would you rather rewrite huge libraries from scratch? Eg: if you want a “new” feature like autodiff on numpy code then you need to reimplement numpy on top of every new autodiff implementation (PyTorch, jax, etc.)
I’m also curious to understand the reasoning, for either choice.
> Would you prefer to add correctness tests to the compositionality that Julia gives “for free” due to multiple dispatch, or would you rather rewrite huge libraries from scratch?
This is a hypothetical future choice, and in that case I would absolutely choose the former (and I hope we get there).
But the current choice is more like "composability that often isn't tested as generically as it should be, with no interfaces at the language level, even the abstract types used for the composition often not having clear specifications, all of it holding together only because of people fixing things organically as problems arise". Then the choice isn't as clear cut - choosing to go with the more limiting option where things are known to work together well with each other is a respectable, sane choice.
If we're going to claim composability as a strength of the language, it shouldn't come with hidden traps, caveats like "composability but really only if the hidden assumptions on both sides happen to be satisfied".
Language level interfaces would be great, but they could also easily have the same problem Abstract supertypes currently have, of being poorly defined semantically, and hence being less useful than they could be. The main change needs to happen in the community, in terms of
* more formal specifications for Abstract types your package defines
--- including in the language itself; I understand there's recently efforts to define what an `AbstractString` is, exactly, and there needs to be a lot more of that
* tests that test the limits of this specification by defining new types that are very different from existing ones, but conform to the specification (rather than the current usual practice of just testing with already existing types only)
* More integration of things like OffsetArrays, DimensionalData, AxisArrays, etc. in test suites
* An explicit "Scope and Limitations" page in package docs (like Revise.jl's Limitations page [1]) that mention what has been tested and what hasn't/isn't meant to be supported
I'm sure there's many other low hanging fruits that the community could address by itself - it's pretty late here and these are what my brain could come up with right now. But I see this largely as a community best practices and culture problem, that language features can help with to some extent, but needs to be solved at the social level.
Is the Common Lisp community really still so dysfunctional? I notice your link there dates back to 2006. Surely communities can improve over 15 years..
I would say it has improved, but it very much hurts me to watch some conversations. Lots of passive aggressiveness and stubborn people stuck with these old habits.
im only an observer on redit (lisp and common lisp) and the community seems to be quite good and supportive. there are a few members who, while very helpful, can be somewhat terse, but thats only a minority. the latter might be a bit of a turn off to some people but ive personally grown above being easily offended. overall i would say its an enjoyable community with a lot of new prominent members doing some exciting things
The sense that the user community is toxic arises from two specific individuals, one in the early days of lisp, at MIT, who was so toxic that they created a whole email list (as it was in those days) whose name was explicitly “—-without-[ahole]—-“, and one more recently who was so toxic that he single-handedly drove everyone off comp.lang.lisp. The StackOverflow lisp community, such as it is, is much less toxic.
Yes, we’ll, it was a real problem, but it was really just caused by a tiny number of people, almost entirely two. One really bad apple ... and all that — two in this case, but separated by many years, so the feeling had barely calmed down before another one arose. It could have happened in any community. For some reason it happened in Lisp. Shrug. Also, you need to take into account that Lisp has been in active use for over half a century!! A couple aholes in 60 years isn’t that bad a record.
I used Clojure years ago and I did not like it. I don't have much more to say other than it tries to force me into a particular programming paradigm and isn't very expressive.
