Much gratitude to Bram for being such an inspiration - not just developing a super-useful project but thinking about how his work can be of benefit to the most needy. All his good works continue on!
Bram Moolenaar has died
391–400 of 449 posts
Re: Bram Moolenaar has died
#392Very sad to hear. I interacted with him only a couple of times, but each time I came away with a very good impression of the man. And, of course, I'm very thankful for the editor he created that I've been using daily for over a decade now. He will be missed by many, and I'm sure intensely by some. Rest in peace, Bram.
Re: Bram Moolenaar has died
#393Using gvim to automatically edit and re-path thousands of ArcView 3 project files across our network shares in the early 2000s was one my "Behold! I am mighty and a god!" highlight moments.
Before that the project was "work with these 25 people and help them open each project and fix the broken paths interactively" (because servers changed).
The script ran at night and everyone's things "just worked" the next morning. It was glorious.
Thanks Bram.
Re: Bram Moolenaar has died
#394> Anyone who's used Vim has seen evidence of Moolenaar's generosity. "Vim is Charityware," Moolenaar wrotes in its pioneering license. "You can use and copy it as much as you like, but you are encouraged to make a donation for needy children in Uganda." Moolenaar pioneered the concept of charityware decades ago, and also helped to popularize its adoption. Pioneered one of the most iconic pieces of software in history…
[deleted]
Re: Bram Moolenaar has died
#395Earlier quoted context omitted.
Creating abstractions without considering performance is probably the correct approach. It’s much better to at least start with a program with enough abstraction to allow reasoning about how things should work. Save performance concerns for when optimization is seen to be necessary.
This is how we get software that run ten times slower consumes ten times more resources and this happens on occasion when software works, more often it doesn't.
Big-O notation lets you conveniently ignore constant factors like 'ten times'.
(I'm only half joking. A system that's always ten times slower than the optimal solution, can still be beneficial to one that's quadratically slower than the optimal solution. Or it can be worse, it depends on how big your instances are.)
Re: Bram Moolenaar has died
#396Earlier quoted context omitted.
Hard disagree. Abstractions are nice when they match the mental model of a problem domain, but the odds you have the right set of abstract primitives in mind from the outset is practically 0.
This is why TDD is not good when starting from scratch. Your abstractions might change in a way that they break your tests in a major way, and not only do you end up re-writing a great part of your code but also of your test set.
Property based testing might be helpful for some of that.
Re: Bram Moolenaar has died
#397Fuck, reading all these comments i kind of feel we should have told him before he died how much we appreciated him…. :…( Like there should be an open source lifetime achievement award or something. Like the academy awards.
That thought never really occurred to me, and now I’m feeling a deep sense of regret. BM has had more impact on my career than anybody.
Re: Bram Moolenaar has died
#398Earlier quoted context omitted.
Hard disagree. Abstractions are nice when they match the mental model of a problem domain, but the odds you have the right set of abstract primitives in mind from the outset is practically 0.
This is why TDD is not good when starting from scratch. Your abstractions might change in a way that they break your tests in a major way, and not only do you end up re-writing a great part of your code but also of your test set.
The stupid thing in TDD is that when you refactor while keeping tests working, many of them turn into duds: tests that are not testing any corner case.
Suppose you use TDD to write a function that adds positive integer together. You get it working for add(0, 0), and nothing else. Then add(0, 1), and add(1, 0) and so on. So you have all these cases. The function is just switching on combinations of inputs, branching to a case, and returning a literal constant for that case.
After writing a few hundred of these cases you say, to hell with this nonsense, and refactor the function to actually add the f.f.fine numbers together.
Now you have two, maybe three problems:
1. Almost all the tests still pass, but most of them are uselessly uninformative.
2. Almost all, because you made a typo in the add(13, 13) test case such that it required the answer 28 to pass, and that's what you did in the code; the real code correctly puts out 26, requiring the test to be fixed.
2. The function adds together combinations that are not tested, just fine, but you can no longer have the function fail for hitherto untested inputs, and then make the test pass. You can no longer "do the TDD thing" on it.
TDD is just a crutch that has to fall out the way when a developer with two brain cells together implements a general algorithm that makes all possible inputs work.
At the same time, that crutch is pretty good for systems that fundamentally are just collections of oddball cases that won't generalize. As a rule of thumb, if there is no obvious way to refactor the code, then TDD is likely continuing to provide value in the sense that the tests are protecting important properties in what has been implemented, against breakage.
Re: Bram Moolenaar has died
#399I'm very sad to read this. I first downloaded vim from a public FTP server in the early 90s on my Amiga computer. My love-hate-love relationship with the editor has followed the arc of my own decades-long hacking adventure. When neovim came out, I stuck with vim out of loyalty and nostalgia, not due to any technical merits -- which was very out-of-character for me. I guess I finally have a good reason to swtich.
RIP Bram.
Re: Bram Moolenaar has died
#400Thanks a lot!
:wq!