Bram Moolenaar has died • Hacker News Board

Re: Bram Moolenaar has died

#321

Post by 1letterunixname » Sat, Aug 05, 2023, 9:14 PM UTC

myst wrote: post #300

sillysaurusx wrote: post #282

Earlier quoted context omitted.

It’s remarkably uncommon to find an employee who strikes a balance between the two. But I think this doesn’t make the sentence wrong.

Literally everyone strikes the balance. According to their experience. The older, the more experienced, the more balanced.

The problem is corporate interests usually demand expedience and individual, short-term output while dismissing any notion of craftsmanship, completeness, correctness, or long-term investment. More and more corporations have completely stopped investing in employee education, career, and professional development apart from harassment and privacy training videos.

Re: Bram Moolenaar has died

#322

Post by Gibbon1 » Sat, Aug 05, 2023, 9:22 PM UTC

asveikau wrote: post #271

bennyschmidt wrote: post #225

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…

I feel it's much more common to create abstractions without regard for performance cost of the abstraction. So keeping time complexity down, even for a piece that doesn't matter much, is above average for this sort of thing.

Also creating abstractions without considering the mental overhead of reasoning about what the code is doing.

Not enterprise: event --> action.

Enterprise: event --> abstraction --> abstraction --> abstraction --> abstraction --> abstraction --> abstraction --> abstraction --> abstraction --> action_parta --> abstraction --> abstraction --> abstraction --> action_partb abstraction --> abstraction --> abstraction --> action_finalizer.

Re: Bram Moolenaar has died

#323

Post by tomcam » Sat, Aug 05, 2023, 9:32 PM UTC

uean wrote: post #320

Personal anecdote: I had lived and worked in southern Uganda with a Canadian organization called Kibaale Children’s Fund (now Kuwasha). One day Bram came by our location. We talked a bit - someone told me he was influential and “worked for google or something” and then I learned his real identity and the software he was a part of. I was just on the brink of beginning a career in IT at the time and later in life as my…

> in Uganda (where it is typical to see fundraising dollars sliced and diced with admin-fees - ICCF turned every cent of a dollar back into the community.)

That’s very good to hear. I donated, but not very much – I assumed that their money would end up going to the wrong places. How did Bram manage to avoid this?

Re: Bram Moolenaar has died

#324

Post by srik » Sat, Aug 05, 2023, 9:32 PM UTC

rip bram, you will be remembered.

Re: Bram Moolenaar has died

#325

Post by _andrei_ » Sat, Aug 05, 2023, 9:34 PM UTC

Damn life, super sad, I feel like a silly chump [1] staring at the screen with an empty mind. [1] https://www.moolenaar.net/bright.html

Re: Bram Moolenaar has died

#326

Post by kjuulh » Sat, Aug 05, 2023, 9:39 PM UTC

This hit me more then I thought it would. I have never interacted with Bram, and I haven't used his software for long. But I love the legacy he left behind, the software industry is better for it.

My condolences to his family.

Re: Bram Moolenaar has died

#327

Post by enriquto » Sat, Aug 05, 2023, 9:41 PM UTC

Really sad to hear this... My first donation as a late teen to free software, was to the ICCF Uganda, thanks to vim's charityware license. It was maybe around 1997 or 98. Later versions of vim used a formal free software license, but still off-band encouraging donations to the ICCF. I've always been a bit skeptical to the whole concept of charity, but I respected Bram Moolenaar so much due to his work on vim that I trusted his judgement. I kept donating to the ICCF for a few years until he was hired at google.

I was also deeply honored to see my (tiny, insignificant) minority language on his page for the word Mooleenar in many languages [0].

As a matter of respect and to honour his memory, I will keep using the last version of vim (by his last commit [1]) as my main text editor for as long as humanly feasible.

[0] https://www.moolenaar.net/

[1] https://github.com/vim/vim/commit/4c0089d696b8d1d5dc40568f25...

Re: Bram Moolenaar has died

#328

Post by creer » Sat, Aug 05, 2023, 9:45 PM UTC

cxr wrote: post #277

lolive wrote: 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.

I'll go with: the sentence takes this as a dimension, this at one end, that at the other. While perhaps what matters is on an entirely different dimension. From a point of view of usefulness to its users, is there a strong correlation with whether the project was "thrown over the fence" or is a work of software artistry?

Re: Bram Moolenaar has died

#329

Post by uean » Sat, Aug 05, 2023, 9:50 PM UTC

tomcam wrote: post #323

uean wrote: post #320

Personal anecdote: I had lived and worked in southern Uganda with a Canadian organization called Kibaale Children’s Fund (now Kuwasha). One day Bram came by our location. We talked a bit - someone told me he was influential and “worked for google or something” and then I learned his real identity and the software he was a part of. I was just on the brink of beginning a career in IT at the time and later in life as my…

> in Uganda (where it is typical to see fundraising dollars sliced and diced with admin-fees - ICCF turned every cent of a dollar back into the community.) That’s very good to hear. I donated, but not very much – I assumed that their money would end up going to the wrong places. How did Bram manage to avoid this?

I shouldn’t speak for Bram or ICCF but can point you to the financial docs which give a great explanation https://iccf-holland.org/iccf.html

From KCFs perspective where I worked, during my time there, I fundraised my salary (expenses) personally “door to door” to keep any funds donated to the organization going direct to the kids and community. I understood this was the case for others as well. I believe Bram paid for flights out of his own pocket.

Re: Bram Moolenaar has died

#330

Post by KerrAvon » Sat, Aug 05, 2023, 9:52 PM UTC

hock_ads_ad_hoc wrote: post #286

asveikau wrote: post #271

Earlier quoted context omitted.

I feel it's much more common to create abstractions without regard for performance cost of the abstraction. So keeping time complexity down, even for a piece that doesn't matter much, is above average for this sort of thing.

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 you wind up with fundamentally slow systems that can’t be easily sped up. You need to take some account of performance in systems design. Just don’t micro-optimize too soon.