michaelfiano

I have given up on portability a long time ago. I value the concision of Julia code, the "automatically fast by default due to the great JIT compiler and type inference engine", and the "everything is zero-runtime overhead generic".

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.

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.

Only the parser is, and it was recently re-written in Julia and in the process of being merged.

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.

So far, mostly this: https://github.com/mfiano/CoherentNoise.jl

1) There is much more to the interactive development experience than the REPL. As mentioned in the article, the debugger and inspector are key parts of this workflow.

3) It's not that software is released too far apart, it's that the release of software is out of the hands of developers, and packaged by a third party with dependencies that may not even be API compatible with the developer's software. Since there is no versioning dependency management for Quicklisp to leverage, all it can do is try to build your software in isolation, not check compatibility with dependencies, and certainly not runtime compatibility.

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.

Which Lisp? What applications do you think it is slow at? Hint: It can be faster than C due to compiler macros, and infact, its regular expression engine is much faster than Perl's, which is written in C, just to give a concrete example.

Author here. How about Common Lisp, what the article talks about? :)