Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bram Moolenaar has died

groups.google.com

Post reply on HN
Print view View original

371–380 of 449 posts

Re: Bram Moolenaar has died

#372

Post by kmarc »

benreesman wrote: post #299

Personal Anecdote: When I was first getting started in software I was very much part of the "I can think faster than I type" school and I had the good fortune to fall in with some really serious hackers, one of whom was an absolute wizard with `vim`. He was a very humble guy, so it was some time before I learned he was in no small part such a `vi` pro because he had written a real vi , it was called `xvi` and I gathe…

> Bram changed the lives and careers of so many of us

True.

> [...] he was humble, brilliant, helpful, and took his craft as seriously as anyone I've ever heard of

I start to think that this is not a coincidence. These excellent people, the "brilliant, but humble" ones are the ones that changed my (and possibly others') lives and careers.

Mr Moolenaar, many other FOSS devs (maintainers), university professors (I'm sure I'm not the only lucky one who experienced this), all the real silent "rock stars".

Re: Bram Moolenaar has died

#373

Post by kykeonaut »

regular_trash wrote: post #354
hock_ads_ad_hoc wrote: post #286

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

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.

Re: Bram Moolenaar has died

#375

Post by geodel »

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

Re: Bram Moolenaar has died

#376

Post by tmountain »

Aachen wrote: post #353
tmountain wrote: post #275

I am such a huge fan of Vim that I ran a Vim blog and posted daily tips for several years (will not mention it by name because I do not want to self-promote in this thread). I don't have much to say besides the fact that I feel like we've lost a "giant" in the open source world, and Bram's contributions as a software engineer, and more importantly, a fantastic human being, will not be forgotten. :help uganda

Could mention the site in profile btw. Afaik it's common/good practice to have some sort of way to get to a contact method in one's profile

Thanks, added.

Re: Bram Moolenaar has died

#377

Post by wyclif »

anonygler wrote: post #206

I worked with Bram at Google. He was an incredibly nice guy. He went out of his way to meet with me on a few different occasions. I wasn’t important at the time—I just made a few UI widgets for Google Calendar, which was his team at Google. Very swell guy who made the world a better place.

That's interesting; I didn't know he worked on Google Calendar and I've been a vimmer my entire career.
Post reply on HN