BatmanAoD @ BatmanAoD @programming.dev

Posts

1

Comments

301

Joined

2 yr. ago

I'm sympathetic to the desire for an "install and forget" drop-in Vim replacement, but...don't you think that this runs contrary to the purpose of Vim/NeoVim as a flexible, customizable editor? If you're an advanced enough user to have a nontrivial vimrc, then it's entirely possible that you'd also want different configurations for vim vs nvim, and that you'd want to be able to switch between them easily if you discover something doesn't work in nvim (especially since nvim is not yet at version 1.0). It's also probable that a lot of Vim users wish that more classic Unix/POSIX tools followed XDG, rather than requiring rc files in your home directory. As for Bash, not everyone uses it, there's no reliable way to automatically insert content into a bashrc file without potentially screwing things up, and Windows doesn't even have a reliable way to run a Bash script (assuming some version of Bash is even installed).

I do think it would be reasonable for the neovim installer (on all systems) to have an option to create an init.vim file that reads your vimrc, and possibly even to create a shell alias as you describe. But these should definitely be opt-in, not opt-out.

What do you mean, the docs don't explain the fix? One of the most prominent topics in the documentation is how to migrate from vim: https://neovim.io/doc/user/nvim.html#nvim-from-vim

...I admit it's annoying that you need a new config file, but on the other hand, it's nice that it follows the xdg spec. Also there's really only one new file you need (init.vim) and it can just source your vimrc.

Neovim is a fork; it's compatible with those.

Plus, if you eventually do need or want to learn C++ for some reason, I honestly think that knowing Rust first would be quite helpful.

I remember thinking that Qt seemed like a really good approach that should be more widely adopted...until I actually had to use it.

Not that it's terrible; it's really not. But C++ is just not at all a good language for

<s>

</s>

I think the "ten days" explanation has the merit of being charitable, because it implies that Brendan Eich wouldn't have made such short-sighted design choices under more favorable circumstances.

(I do not believe that it's a "sensible principle" to treat text as such a fundamental form of data that a basic language feature like the equality operator should be entirely shaped around it. Surely the consequences of building an entire language around text manipulation should be apparent by considering how awkward Posix-style shells are for any nontrivial scripts.)

It's still pretty bad that the normal equality operator is as bad as it is.

The research is the interviews he did with engineers. That sentence is obviously a simplification, especially since he immediately follows it with one about talking to a civil engineer who builds mines.

This is probably the most well-researched piece of writing on the matter: https://www.hillelwayne.com/post/are-we-really-engineers/

I'm not sure where you're quoting from, but as far as I can see, only "Professional Engineer", "Licensed Engineer", and "Registered Engineer" are protected in the US.

I'm trying to think of examples of this, and I actually don't know that this is true. Here are the examples I can think of:

• Arguably object-oriented .method() syntax is similar to "subject-verb" order, but we also have function(self, ...) which is the reverse of that.
• for foo in bar is used in a few languages (or sometimes foreach). But many languages use a totally non-English construct, such as for i = 0; i < limit; i++ or for (auto foo : bar).

What else is there?

There are a fair number of them: https://en.m.wikipedia.org/wiki/Non-English-based_programming_languages

But arguably, as long as the compiler supports unicode, it shouldn't matter that much what language the keywords are in. There are other more important issues impacting how easy it is to program in non-English languages:

• availability of documentation and tutorials
• English comments and API names in common libraries, especially the standard library
• tooling for handling unicode, especially BiDi (which is part of why Arabic is especially tricky) - Vim, for instance, has had an open issue about this for almost a decade: https://github.com/vim/vim/issues/204

The joke is basically "what if an actual software engineering job were like a standard job interview".

Yes, it's largely for SPAs, but you said "requires killing the web app", and most web apps are SPAs.

Wow, of course he's pretending the response is a misrepresentation of his opinion instead of defending it in good faith.

Well, not quite, since Rust got WebAssembly support quite early.

When reading the announcement post, I was indeed hoping they'd include an example word with two "m"s in a row, so I was glad to see the example here. I don't mind it, but it does feel almost dishonest to exclude that case from their post.

I'm not sure I'd consider that "failing". At first glance, I don't mind the distinct "m" glyphs being juxtaposed. But perhaps I'd find it annoying after a while.

Languages with dynamic typing and implicit large-integer types, such as Python and Ruby, generally just convert to that large-integer type.

I figured Java would probably define the behavior in the JVM, but based on a quick web search it sounds like it probably doesn't by default, but does provide library methods to add or subtract safely.

Rust guarantees a panic by default, but provides library methods for wrapping, saturating, and unchecked (i.e. unsafely opting back in to undefined behavior).