Lispers might not like that it's not a Lisp, but I remember Luke Tierney also making a statement to the effect that the statisticians have spoken and they don't prefer the Lisp syntax.
So Julia is a happy middle ground - MATLAB-like syntax with metaprogramming facilities (i.e., macros, access to ASTs). Its canonical implementation is JIT, but the community is working on allowing creation of medium-sized binaries (there has been much effort to reduce this footprint).
Julia isn't a lisp, but I think it's the most lispy non-S-expression based language around these days. The language creators took the lessons from lisp very seriously, and it shares a lot of functionality and philosophy with lisps.
Well I think the original author was a fan of Lisp and implemented the first Julia parser in femtolisp, IIRC. (And femtolisp was a lightweight Lisp of his own.)
There are some optimizations that can be made a compile-time that can speed up the computations. It also makes it portable provided that the executables are provided for each desired platform.
> And while base Python I find to be extremely elegant, typical data science and scientific computing workflows are a headache.
That's my impression as well. Going back to the topic of the original post, pandas only partially implements the idioms of the tidyverse so you have to mix in a lot of different forms of syntax (with lambdas to boot) go get things done.
Julia is much nicer, but I find myself using PythonCall more often than I'd like.
Scipy was originally supposed to provide the scientific computing stack, but then many offshoots in the direction of pandas / ibis / JAX, etc. happened. I guess that's what you get with a community-based language. MATLAB has its warts but MathWorks does manage to present a coherent stack on that end.
> At the time it was more or less taken for granted that AI work was done in Lisp. C++ barely existed. Perl was brand new. Java was years away. Spacecraft were mostly programmed in assembler, or, if you were really being radical, Ada.
Given the choices, Lisp made a lot of sense when they started. After 2001-2004, there were other options - not to say they were necessarily better, but a mainstream language that enables a large number of people working together (interchangeably) has its value. Lisp is indeed "one-of-a-kind, highly dynamic applications that must be developed on extremely tight budgets and schedules" - but has a reputation for fostering lone geniuses and bad for large teams working together and maintaining legacy codebases.
I think the late and slow standardization process hurt it a lot. Too many cooks trying to shove their recipes in. Scheme went too much the other way of making it too minimalistic. Imagine a modern Lisp with one source and a kitchen-sink library, like Go. Clojure is the closest we have for that I think, but it running on the JVM also hurt it a bit for a wider adoption.
I've tried Vi/Vim key bindings on several occasions, but just couldn't be efficient in it. It's often touted as the "superior" form that confers benefit to those who invest time to learn it, but discussions with other coders have led me to believe this is just confirmation bias by people who prefer these key bindings.
There are people like myself who edit frequently while writing (even with in a single sentence or word), so this switching between normal and insert modes to do chunks of each operation at a time incurs a heavy cost. Yes, there is Ctrl+[ for single commands, but this is still an additional step compared to the key chord model of Emacs for instance.
I use both Vim and Emacs, extensively, so I'd just like to share my experience with mode switching in Vim. Personally, I don't find Vim mode switching to be much of a problem while editing text. It has become muscle memory to stay in normal mode by default. After any insert-mode operation, I instinctively return to normal mode. It's just a habit at this point.
Take, for example, writing a for loop. I might type:
for (int
Then, say, I pause briefly to think about the variable name. If you happened to look over my shoulder at that moment, you would find me in normal mode. Even if I only pause for a second, I reflexively return to normal mode the moment I stop typing.
Because of that, I don't really treat insert mode as a separate "place" in my mind. Let's say I want to insert the text "abc". I don't think, enter insert mode, type "abc", then return to normal mode. I just see it as a single action in normal mode that includes the key sequence "i a b c ESC".
Or say, I want to open a new line above and insert "xyz". Again, I think of it as a single operation in normal mode that includes the key sequence "shift+o x y z ESC".
This applies to all insert-mode operations for me. Normal mode feels like "home" and insert mode is just an editing phase I dip into when I need and exit. That's why it doesn't feel like I am constantly switching modes (even though I am).
I think one (often forgotten) good advice to get used to the mode-switching is to move the ESC key to Capslock on the keyboard. It's tedious to learn to always go to the ESC key, upper left of the keyboard. Capslock is available from home row, and you should probably not use CAPSLOCK anyway, it's a bad practice.
Put ESC key there instead and vim becomes wayyyyyyyy more ergonomic.
Indeed! Sometime between 2010 and 2015, I used to often work with Windows computers, so I wrote a tool for myself back then to remap Caps Lock to Esc on Windows machines:
While it was certainly possible to do that by editing Windows registry (and I have noted those techniques too in the README), registry changes couldn't be enabled or disabled without a reboot. That's what motivated me to write the above tool. And indeed, having the Caps Lock work like Esc made using Vim a much better experience!
I map 'jk' in Insert mode to <Esc>. In Insert mode, it takes me out to Normal mode. If I'm already in Normal mode, it simply moves down a line and right back up. This habit is so burned into my muscle memory that I often end up typing 'jk' into non-Vim input areas (like this HN comment box).jk
at most one y in way since Capslock is an unergonomic key in itself - it requires an unergonomic lateral movement of your weakest finger of your weaker hand
It never made any sense to me that people claim Emacs has no modes. What do you think you're doing when you hold down a modifier key? What else would it be except entering a mode in which other keys have a different meaning? Is that really different from vim's mode switching? They're just different ways of expressing modifiers.
> Because of that, I don't really treat insert mode as a separate "place" in my mind. Let's say I want to insert the text "abc". I don't think, enter insert mode, type "abc", then return to normal mode. I just see it as a single action in normal mode that includes the key sequence "i a b c ESC".
It is an action. Check out what happens if you prefix it with a repetition:
5iHello<esc>
-->
HelloHelloHelloHelloHello
Same goes for other ways to get into insert mode (like I, a, A, o, O), then for dual-actions that do a delete and switch to insert mode (like s, c) the repetitions apply to the delete part.
I used Vim for 5-ish years and I kinda got into that mindset, but on occasion I would fail to switch to insert mode (I think by not hitting the i or a key properly, but when in the flow I don't really pay attention to what my hands are doing) and stuff would go haywire. After 5 years of that happening intermittently I got really fed up with it and I started trying various alternatives.
I have been using Emacs for about 6 years now and when I fail to engage a modifier key properly all that happens is that I type some text in the active buffer. If I really manage to do a silly mistype, I can just hit C-h l to show my recent keystrokes to find out what I did.
I wonder if it would be possible to write some code to auto switch to insert mode if you press like 3 key in a very rapid succession, while in normal mode ?
> Take, for example, writing a for loop. I might type:
> for (int
> Then, say, I pause briefly to think about the variable name. If you happened to look over my shoulder at that moment, you would find me in normal mode.
I personally wouldn't but that's only because even in the case above I think in the same way as you mentioned next:
> I just see it as a single action in normal mode that includes the key sequence "i a b c ESC".
in the sense that I will ESC only after I have instered a "semantic-ish unit", which would include the variable name.
I don’t know I edit a lot but I also really like vim motion. It gets really natural at some point. The mix of b and e to move around, using cw or ce to remove and start editing then getting back to moving around. Plus a lot of edit actually happens straight from normal mode (case correction, one character changes, short deletion).
You don’t really think about the modes because things flow naturally. It might also be due to the fact that I nearly never actually switch conscientiously into a mode. I always do actions which send me in insert (like c and o, very rarely I or A) and revert back to normal when done.
Plus vim has the advantage of making things like just remove everything between these symbols and set me in edit there very easy which is something I miss when I don’t have vim bindings.
I don't think it's the keybindings in particular that people love about vim, you can rebind everything after all. I'm attached to vim keybindings in the same way I'm attached to qwerty keyboards - something had to be the default, it's fairly arbitrary, and there's very marginal benefits in switching to a different set of bindings.
It really is the modal editing style that's the main draw. Someone who edits frequently should find vim more convenient, not less, but it does require a lot of time to learn all the available commands and burn them into your muscle memory.
Yes, the default. That's why, although I am french speaking, I switched a few years ago from azerty to qwerty keyboard just to be using the keyboard used by the people who programmed the default in editors like vim and emacs. Otherwise it is just a PITA. Should have done that from the very beginning I was programming. With Karabiner and Goku I have been able to configure some key combinations to get accented letters like righr alt+e for é, right shift+right alt+e for è, ...
> There are people like myself who edit frequently while writing (even with in a single sentence or word), so this switching between normal and insert modes to do chunks of each operation at a time incurs a heavy cost.
I edit this way too and there's no heavy cost here. Well, maybe when you're first learning and switching hasn't become second nature, but when you do it's not something you even notice.
Which ones? Do you mean the unergonomic defaults where one of the most popular action (quitting to normal mode) is bound to one of the most inconvenient keys (Esc)? Also for editing within a word you actually don't need to switch between modes, but instead could use something like a home row cursor with a modifier to move in insert mode.
Indeed there is administrative bloat everywhere, and I can sympathize with your hope that tearing down the current system will leave room for building anew.
However, it's hubris to assume that everything is bloat. There is the adage of Chesterton's fence, which reads: "...reforms should not be made until the reasoning behind the existing state of affairs is understood." Many things that appear to be bloat that serves a useful function, and tearing them blindly is going to do irreparable damage.
I've never used Quarto, but I might give it a go someday. I currently have a convoluted workflow for generating math-heavy documents that involves generating equations using SymPy in a notebook, accumulating them in a string, and ultimately dumping the string into a Markdown. I would love to simplify this sooner rather than later. I'm also keeping an eye on https://typst.app/ and hoping for a sane alternative to LaTeX to emerge.
