5 ms·

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 qu

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.

akkartik 4y ago
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..
- michaelfiano 4y ago
  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.
- abrax3141 4y ago
  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.
  - eigenspace 4y ago
    Oof. You know you have a real problem when StackOverflow is your less toxic community. At least that's my experience with StackOverflow
    - abrax3141 4y ago
      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.
      - eigenspace 4y ago
        Yes, sorry I was more taking a dig at StackOverflow there than anything. Was not in very good taste.
- medo-bear 4y ago
  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
ssivark 4y ago
So what kind of libraries have you been building in Julia? Please do link!
- michaelfiano 4y ago
  So far, mostly this: https://github.com/mfiano/CoherentNoise.jl https://github.com/mfiano/CoherentNoise.jl
Jach 4y ago
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/ https://yuri.is/not-julia/ or http://danluu.com/julialang/ 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.
- michaelfiano 4y ago
  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.
dimitar 4y ago
Have you also considered Clojure for your use cases?
- michaelfiano 4y ago
  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.
ctrlmeta 4y ago
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?
- ssivark 4y ago
  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.
  - sundarurfriend 4y ago
    > 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".
    - ssivark 4y ago
      I appreciate that critique. So what would it take to make this pathway smoother? Do you think interfaces might be a silver bullet? If so, what’s holding back the language from prioritizing this in the medium term? (For v2.0, say) Or maybe the most useful improvements are anticipated to come from somewhere else?

akkartik 4y ago

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..

michaelfiano 4y ago
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.
abrax3141 4y ago
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.
- eigenspace 4y ago
  Oof. You know you have a real problem when StackOverflow is your less toxic community. At least that's my experience with StackOverflow
  - abrax3141 4y ago
    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.
    - eigenspace 4y ago
      Yes, sorry I was more taking a dig at StackOverflow there than anything. Was not in very good taste.
medo-bear 4y ago
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

ssivark 4y ago

So what kind of libraries have you been building in Julia? Please do link!

michaelfiano 4y ago
So far, mostly this: https://github.com/mfiano/CoherentNoise.jl https://github.com/mfiano/CoherentNoise.jl

Jach 4y ago

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/ https://yuri.is/not-julia/ or http://danluu.com/julialang/ 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.

michaelfiano 4y ago
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.

dimitar 4y ago

Have you also considered Clojure for your use cases?

michaelfiano 4y ago
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.

ctrlmeta 4y ago

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?

ssivark 4y ago
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.
- sundarurfriend 4y ago
  > 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".
  - ssivark 4y ago
    I appreciate that critique. So what would it take to make this pathway smoother? Do you think interfaces might be a silver bullet? If so, what’s holding back the language from prioritizing this in the medium term? (For v2.0, say) Or maybe the most useful improvements are anticipated to come from somewhere else?