5 ms·

I like that there's a push now for these reconsiderings of older systems that are still in common use. Vi/vim has been around forever, and has survived all sor

I like that there's a push now for these reconsiderings of older systems that are still in common use. Vi/vim has been around forever, and has survived all sorts of other editors emerging as competitors. Kakoune is an interesting concept because most post-vi editors have abandoned modality, and Kakoune embraces it wholeheartedly in an attempt to capture the essence of what makes vi powerful and attractive for a certain type of user, but trying to ditch some of the historical ed/ex syntax and thought patterns that make vi weirdly inconsistent. I don't think kakoune is quite there -- I think the multi-selection gimmick is not strong enough to be worth being first-class (especially the way that search-and-replace works), too many common operations are chorded, and there's no selection "mode" -- you have to remember to keep pressing 'J' as long as you want to grow the selection; one 'j' and you're lost. In programming languages I think we're seeing this happening also; C has remained a prominent language despite its age and the number of C-killers that have emerged over the years, and now we're seeing a resurgence of projects that are really trying to preserve something at the heart of C that has made it attractive for so long, but that even the most jaded systems programmer can see are not ideal, like the fact that types precede names in variable declarations, or the lack of a keyword for function or variable declaration that make it hard to grep, or the superfluous parens in ifs and fors that are obviated by mandatory blocks, or the default pass-through behavior in switch statements. Previous attempts, like C++ and D, have diverged too much from the simplicity of "I can imagine what the assembly code for this function will look like based on the compiler in my head", Rust has some attraction, but nim and zig and Jai and v are all emerging to nuzzle into that niche by restricting their feature set.

F-0X 8y ago
>even the most jaded systems programmer can see are not ideal, like the fact that types precede names in variable declarations, Honestly, I find it shocking anybody can hold this opinion. I hate that every single new language insists on types being on the right. I searched for a reason why this is, and typically the results are along the lines of type inference being easier to implement. I'd prefer to take no inference at all and have my types on the left, where they belong. I'm totally serious. Types on the right are a readability disaster.
- andrewla 8y ago
  For me it's about compactness of type representation -- types are on the right, except when they're not -- in arrays or function pointer declarations, you have to deal with the fact that the variable name being introduced may be nested in unintuitive ways deep inside the declaration. By moving it to the right, you make that much clearer. In Java, they made it so that array information went on the left, which made it a little clearer, but was still kind of ugly, and Java really had no notion of function pointers anyway. The other problem with the type-on-the-left is that variable declarations are hard to find without tooling designed for that purpose. Being able to search for "var x" is a nice feature that makes it easy to separate out the declarations from the usage. I agree that type inference and optional types is something of an anti-feature from my perspective as well; even more frustrating is languages that treat a type declaration as a type assertion rather than a declaration, which serves to divorce ideas about physical storage from the code; abstract types like "bool", though, have already crept into C to make the type model a little more complicated than it has to be. Types in C used to be declarations of storage class as well; now I know that a bool in a struct will take up a byte, but that byte and bool are not really compatible types makes it a little harder to reason about, even if that does give better hinting to the compiler.
- matthiaswh 8y ago
  I agree. It's such an illogical and unreadable construct to me. Even after working with a typed language for awhile my instinct is to declare the type before the variable name. I've been envisioning a future programming environment that automatically aids in code readability by hiding unnecessary information when you're not using it. Manual code folding was sort of a first step, but this environment would take it further by hiding things like types until you need them. So something like proc eval(c: Criterion, token: Token): bool = let tokenCrit = (token.identifier, token.token) return tokenCrit == c Might look like proc eval(c, token) = let tokenCrit = (token.identifier, token.token) return tokenCrit == c Or even proc eval(c, token) = ... return tokenCrit == c It would have to be smart enough to expand the hidden blocks when you need them and in an unobtrusive way. It's also possible that the type declarations wouldn't actually expand in this editor, but would be set by some sort of popup selector (similar to how autocomplete works, but you'd select the variable type). This is just a rough idea and I'm not sure how well it works in reality. But when code starts looking like `proc add*[T](root: var BinaryTree[T], n: var seq[BinaryTree[T]]) =` it starts to lose its at-a-glance readability.
clarry 8y ago
> I think the multi-selection gimmick is not strong enough to be worth being first-class (especially the way that search-and-replace works), too many common operations are chorded, and there's no selection "mode" -- you have to remember to keep pressing 'J' as long as you want to grow the selection; one 'j' and you're lost. Agreed. I also don't like that this system requires you to have what are essentially duplicate keybindings with the only difference being that one does the motion while starting a new selection, and the other does the motion but keeps (and extends) current selection. It guess it's supposed to be ergonomic, but I think it's too wasteful and in wasting so many possible keybindings, we're trading ergonomy away by not being able to bind more powerful functions to all these spent keys. I'm not sure what the solution should be. I like what Kakoune is trying to do, but I don't think they landed on the right idea. I'm not sure I'd like having to toggle selection mode on or off. I think it'd be better to always be in the selection mode; then if you don't want all your recent navigation selected, you press a key to reset the selection. The obvious downside is that you'll end up having to reset the selection a lot. On the other hand, if it's only one easily accessible key, it might work well enough. A slightly more advanced solution would be that you always have a selection formed automatically from the latest motion, plus a mark (perhaps any number of marks) that can be used when you need to combine multiple motions. Normally editing commands that take a selection would only operate on the most recent motion, but with a single prefix or postfix key could be extended to apply up to the mark. Whatever it is, I think there's got to be a way to improve on vi without making as many tradeoffs as I think Kakoune did.
- andrewla 8y ago
  I think the problem with any sort of selection/motion combo is that a selection has two endpoints (limiting to just single-selections; multi-selections and cursor make this a jillion times more complicated). When you make a motion you have to decide which one of the endpoints is the current cursor, and that's where I feel like you run into trouble. "Grow the selection up by one line" is a hard notion to express when you started by selecting down. Vim has visual select mode, which has a line-based, character-based, and block-based mode. I'm not totally sure that we need them to be distinct. The problem is that kakoune now has me vaguely dissatisfied with both vim and kakoune and I don't like it.
norswap 8y ago
Nim is certainly not a language I would qualify as having a "restricted feature set". Jai is mostly under wraps but from what I've heard from the author, while it very strongly opposes some common language features that C doesn't have, it will also bring quite a few unusual features. Thanks for pointing out v, which I didn't know about!

F-0X 8y ago

>even the most jaded systems programmer can see are not ideal, like the fact that types precede names in variable declarations, Honestly, I find it shocking anybody can hold this opinion. I hate that every single new language insists on types being on the right. I searched for a reason why this is, and typically the results are along the lines of type inference being easier to implement. I'd prefer to take no inference at all and have my types on the left, where they belong. I'm totally serious. Types on the right are a readability disaster.

andrewla 8y ago
For me it's about compactness of type representation -- types are on the right, except when they're not -- in arrays or function pointer declarations, you have to deal with the fact that the variable name being introduced may be nested in unintuitive ways deep inside the declaration. By moving it to the right, you make that much clearer. In Java, they made it so that array information went on the left, which made it a little clearer, but was still kind of ugly, and Java really had no notion of function pointers anyway. The other problem with the type-on-the-left is that variable declarations are hard to find without tooling designed for that purpose. Being able to search for "var x" is a nice feature that makes it easy to separate out the declarations from the usage. I agree that type inference and optional types is something of an anti-feature from my perspective as well; even more frustrating is languages that treat a type declaration as a type assertion rather than a declaration, which serves to divorce ideas about physical storage from the code; abstract types like "bool", though, have already crept into C to make the type model a little more complicated than it has to be. Types in C used to be declarations of storage class as well; now I know that a bool in a struct will take up a byte, but that byte and bool are not really compatible types makes it a little harder to reason about, even if that does give better hinting to the compiler.
matthiaswh 8y ago
I agree. It's such an illogical and unreadable construct to me. Even after working with a typed language for awhile my instinct is to declare the type before the variable name. I've been envisioning a future programming environment that automatically aids in code readability by hiding unnecessary information when you're not using it. Manual code folding was sort of a first step, but this environment would take it further by hiding things like types until you need them. So something like proc eval(c: Criterion, token: Token): bool = let tokenCrit = (token.identifier, token.token) return tokenCrit == c Might look like proc eval(c, token) = let tokenCrit = (token.identifier, token.token) return tokenCrit == c Or even proc eval(c, token) = ... return tokenCrit == c It would have to be smart enough to expand the hidden blocks when you need them and in an unobtrusive way. It's also possible that the type declarations wouldn't actually expand in this editor, but would be set by some sort of popup selector (similar to how autocomplete works, but you'd select the variable type). This is just a rough idea and I'm not sure how well it works in reality. But when code starts looking like `proc add*[T](root: var BinaryTree[T], n: var seq[BinaryTree[T]]) =` it starts to lose its at-a-glance readability.

clarry 8y ago

> I think the multi-selection gimmick is not strong enough to be worth being first-class (especially the way that search-and-replace works), too many common operations are chorded, and there's no selection "mode" -- you have to remember to keep pressing 'J' as long as you want to grow the selection; one 'j' and you're lost. Agreed. I also don't like that this system requires you to have what are essentially duplicate keybindings with the only difference being that one does the motion while starting a new selection, and the other does the motion but keeps (and extends) current selection. It guess it's supposed to be ergonomic, but I think it's too wasteful and in wasting so many possible keybindings, we're trading ergonomy away by not being able to bind more powerful functions to all these spent keys. I'm not sure what the solution should be. I like what Kakoune is trying to do, but I don't think they landed on the right idea. I'm not sure I'd like having to toggle selection mode on or off. I think it'd be better to always be in the selection mode; then if you don't want all your recent navigation selected, you press a key to reset the selection. The obvious downside is that you'll end up having to reset the selection a lot. On the other hand, if it's only one easily accessible key, it might work well enough. A slightly more advanced solution would be that you always have a selection formed automatically from the latest motion, plus a mark (perhaps any number of marks) that can be used when you need to combine multiple motions. Normally editing commands that take a selection would only operate on the most recent motion, but with a single prefix or postfix key could be extended to apply up to the mark. Whatever it is, I think there's got to be a way to improve on vi without making as many tradeoffs as I think Kakoune did.

andrewla 8y ago
I think the problem with any sort of selection/motion combo is that a selection has two endpoints (limiting to just single-selections; multi-selections and cursor make this a jillion times more complicated). When you make a motion you have to decide which one of the endpoints is the current cursor, and that's where I feel like you run into trouble. "Grow the selection up by one line" is a hard notion to express when you started by selecting down. Vim has visual select mode, which has a line-based, character-based, and block-based mode. I'm not totally sure that we need them to be distinct. The problem is that kakoune now has me vaguely dissatisfied with both vim and kakoune and I don't like it.

norswap 8y ago

Nim is certainly not a language I would qualify as having a "restricted feature set". Jai is mostly under wraps but from what I've heard from the author, while it very strongly opposes some common language features that C doesn't have, it will also bring quite a few unusual features. Thanks for pointing out v, which I didn't know about!