Live data from Hacker News

Bram Moolenaar has died

groups.google.com

411–420 of 449 posts

Re: Bram Moolenaar has died

#411

Earlier 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.

Unit test driven development is not good at this. Integration test driven development works pretty well though.

Re: Bram Moolenaar has died

#412
>>> aptitude hold vim

For a while, until I get over this.

I've been teaching vim to hundreds of people and usually have about a dozen vim sessions open. So soon after Kevin, two names that are my heroes since the 90ies.

Re: Bram Moolenaar has died

#413
post #277
post #160

Went to his website. There was an interview of him from 2022. The answer that really stroke me was not about Vim, but about software craftmanship vs professional programming: « I have been working for a company where quite a few managers, educated in physics and mechanics, thought the software was just the same as what they knew and they could decide how to make it. That company went downhill and was eventually taken…

What's wrong with the last sentence? For ease of consumption, the context again: > On the other end of the scale are people who want to write beautiful code, spend lots of time on it, and don’t care if it actually does what it was intended to do or what the budget was. Somewhere in between, there is a balance.

After reading all the comments, I realise I misinterpretated the last two sentences. I thought Bram was concluding that you have to accept the same kind of trade-off you accept in the frame of professional software development, when you deliver an app you are really dedicated to.

Obviously, Bram, or Linus, or Stallman, and many other devs I don’t even know, are not there for delivering half-baked pieces of art. And that’s eventually a GOOD thing. [the counterpart being that the dedication level is MUCH beyond the one in professional environments]

Re: Bram Moolenaar has died

#414
Personal office anecdote ca 2010: while he was walking past our desk area, someone shouted over to him: Bram, what editor are you using for Java? He answered with a smile: Eclipse of course. Very nice guy.

Re: Bram Moolenaar has died

#415

Sharing a piece of advice Bram gave to me once: " It appears you think that everybody is like you. But that's not so. " I didn't take the advice well at the time, but now, a little older and wiser, I understand. Thank you, Bram. Thank you for vim, for your time and dedication, and for taking the time to deposit a small amount of your wisdom into my brain. Sorry for being a dick.

classic line. Do you think he'll be remembered for his struggles with the perils of open source feature requests, as well as for vim itself? Largley because of the keybindings, Vim was a perfect storm for this: maybe the epitaph is "he could never figure out how to quit vim either". +1 for the Moolenaar award to show appreciation for people whilst they're still alive and coping with the rest of us all being dicks....

Re: Bram Moolenaar has died

#418
post #366

Earlier quoted context omitted.

> people who want to write beautiful code, spend lots of time on it, and don’t care if it actually does what it was intended to do There was a funny React framework a while back that has all kinds of cool state management and this and that, but it renders nothing. For the developers who spend more time theorizing, migrating, refactoring, than shipping. It's funny when people go back and forth about the time complexit…

Re-frame?

This was immediately what I thought of, too.

Re: Bram Moolenaar has died

#420
post #160

Went to his website. There was an interview of him from 2022. The answer that really stroke me was not about Vim, but about software craftmanship vs professional programming: « I have been working for a company where quite a few managers, educated in physics and mechanics, thought the software was just the same as what they knew and they could decide how to make it. That company went downhill and was eventually taken…

> people who want to write beautiful code, spend lots of time on it, and don’t care if it actually does what it was intended to do There was a funny React framework a while back that has all kinds of cool state management and this and that, but it renders nothing. For the developers who spend more time theorizing, migrating, refactoring, than shipping. It's funny when people go back and forth about the time complexit…

> people go back and forth about the time complexity of a click handler (that is debounced anyway)

This is the modern software world in a nutshell.

Post reply on HN