Live data from Hacker News

I admire Fabrice Bellard. He is almost certainly a better overall programmer

twitter.com

351–360 of 488 posts

Re: I admire Fabrice Bellard. He is almost certainly a better overall programmer

#351
post #203

Earlier quoted context omitted.

Rather than potentially 1000 HN readers each spending 15 minutes on Google trying to work out what you are talking about, may I suggest that you expand that with a few plain English sentences that tell us what that means? I have no idea what "ATSC" means, and I've been in tech for nearly 40 years now so I have a fairly good handle on this stuff.

Advanced Television Systems Committee. It's the US standards organization for terrestrial digital television. ATSC 3.0 is a new standard that's very similar to DVB-T2 (used in the UK for HDTV) at the PHY layer.

Looks like "PHY layer" means physical layer.

Re: I admire Fabrice Bellard. He is almost certainly a better overall programmer

#352
Best way to describe how an "ordinary" Programmer feels towards Fabrice Bellard ;-)

"I trust that I am not more dense than my neighbours [i.e. fellow programmers], but I was [and am] always oppressed with a sense of my own stupidity in my dealings with [the works of Fabrice Bellard]."

-- inspired by Watson's comment about Sherlock Holmes in "The Red-Headed League" from the volume, The Adventures of Sherlock Holmes.

Re: I admire Fabrice Bellard. He is almost certainly a better overall programmer

#353
post #249
post #246

Reading the list of Bellard's contributions, what strikes me is not the raw ability (although certainly there is that too!) but "damn, he knows how to pick 'em!" He keeps picking stuff to work on that ends up being insanely useful to a massive number of people. That seems somehow even more remarkable than the technical ability. Deciding what to work on might be the most important question in life.

My guess would be the hueristic is "I want to do simple thing, why is it so hard?" (Modern computing has an overabundance of "DX tarpits".) Which is funny because, everyone has that experience, right? But then approximately nobody proceeds to do something about it. (Including most people who have the skills to make a difference!) Like, that's surprisingly mundane, and surprisingly actionable. --- If we distil it into…

That's still make the hard part present. Things are not good on so many considerations. So selecting and being able to focus for just as much time as it will be required are the hard part.

Thus starting with learning wow meditation seems an important first step.

For all the rest, it's already going to be more issues on how to prioritize getting the ressources mapped where seems to fit to reach the goals.

Re: I admire Fabrice Bellard. He is almost certainly a better overall programmer

#354
post #348

Earlier quoted context omitted.

> But the code quality is speed No it’s not. Code quality is just code quality. It's a subjective measure. eg how do you define one thing is of greater "quality" than another? Is it CPU ops? Memory footprint? Code readability? And how do you measure readability? By who? What I find readable someone else might not, and visa versa. If you’re making choices to improve development throughput then that’s fine. But so ofte…

> The problem with "tech debt" is it can mean anything from "this is ugly code that takes 5 minutes longer to read but it works well" to "this in a insecure/unstable pile of horse manure and customers will start to notice". > > The latter is where time should be spent. The former is a vanity project that doesn't bring the business any value. You may have worked with people whose meaning of "code quality" encompassed…

I don't think you're being very charitable in your reading of my comments. For example:

> You may have worked with people whose meaning of "code quality" encompassed things that you found inconsequential and a waste of effort. They may have even told you that if you didn't care about those things, then you didn't care about code quality. But that's not true. It only meant you disagreed with them about what code quality is and how to recognize it.

Who's these "people" you're referring to? This is an imaginary conversation you've added.

What I actually said was that there's a balance between design and output.

I did generalize that often product people will push too far towards output and often developers will push too far between design, but like all generalizations, I know there are exceptions (eg me).

But the crux of my point is that there are tradeoffs between the two, and thus times when it makes more sense to lean towards output and times when it makes more sense to focus on design.

What you've replied with isn't even remotely the same sentiment as the comment I made.

> You draw a distinction between aspects of code that tend to lead to better outcomes and aspects of code that don't matter. You say you know what tech debt looks like. When you look at a codebase, you have opinions on where time should be spent to improve it. "Code quality" is shorthand for the heuristics underlying those opinions.

No. Code quality is just a subjective term that means nothing in reality because everyone will have different goals in mind when they think about the purpose of the code.

So the underlying heuristics require far insight into project goals, deadlines, and resources than just "code quality".

> Instead of accepting that other, possibly dumber people get to define what code quality is,

The original reason I replied (albeit I did digress quite a bit) was to demonstrate that you cannot extrapolate how smart or dumb an engineer is from their "code quality" alone. So please refrain from calling people dumb in your rebuttals.

> own your own definition of it and use it when you communicate with other people.

That's literally what I've done.

---

This comment better summarizes my point: https://news.ycombinator.com/item?id=48555191

Re: I admire Fabrice Bellard. He is almost certainly a better overall programmer

#355

It's interesting to me that most of Bellard's work is basically turning specs into C. His most important projects are ffmpeg (codec specs), qEmu (ISA specs), QuickJS (the EcmaScript spec), tinyC (the C spec), and his telecom company (LTE specs). I guess the pi calculations and neural network stuff are exceptions. Just to be clear, this doesn't make his work any less impressive. Highly performant codec and emulator im…

> ffmpeg (codec specs) if your mental model is that somebody writes codec specs and then fabrice bellard comes in and turns the specs into C, you are dead wrong. first of all, codecs are usually reverse-engineered, there is no spec. second of all, even when a well specified document describes the codec, that spec does not describe how to efficiently encode or decode with that codec. people like fabrice bellard develo…

The way to criticize that comment is to point out that all the major and most important codecs that are most commonly used with ffmpeg, do not come from the ffmpeg project. H.264, H.265, libmp3lame, speex, libfdkaac, etc. all come from other projects. What ffmpeg does is provide libraries for transforming decoded data between formats and calling to and from encoders and decoders and multiplexers and bitstream formats.

It may also be worth pointing out, in terms of apportioning credit fairly, that ffmpeg has not been Bellard's project since 2004. The thing we see today is no more his project than GCC or Emacs are Stallman's projects.

Re: I admire Fabrice Bellard. He is almost certainly a better overall programmer

#357

Earlier quoted context omitted.

Although in this case it's more like using the paint in the tin to paint the tin itself. It's useless and completely missing the point of why the paint exists in the first place. You do you, I'm sorry if I come across rude and stupid, but I am both things. But "code is the product" is what IMO caused the downfall of this entire profession. No wonder everyone is trying to get rid of us. I wouldn't want a plumber that'…

Despite the gallons of ink spilled on the subject I have not worked at a single place in my 30-year career where developers sat around perfecting masterpieces. I have worked at a never-ending list of places where people shipped the first thing that worked, built spaghetti around it, something else got built on top, and the original thing is now critical infrastructure that takes 10x longer to fix bugs or add needed f…

I feel like the navel-gazing-ivory-tower programmer is almost a straw man used by commenters and bloggers to make themselves sound pragmatic. Summoned only be be torn down. Never to be found on an existing software team.

I have come across the architecture astronaut before. But I feel like they’re the result of the culture of the ecosystem the language. The Java and C# programmers whose language requires you to juggle weak types with visibility keywords and null ability. They can be forgiven for not being able to implement a priority queue without a committee and a class hierarchy deeper than the Mariana Trench.

But the perfectionist that never ships anything useful and only ever tweaks interfaces and types? Never met one.

Most people are just trying to balance progress with practical concerns.

Re: I admire Fabrice Bellard. He is almost certainly a better overall programmer

#358
post #246

Reading the list of Bellard's contributions, what strikes me is not the raw ability (although certainly there is that too!) but "damn, he knows how to pick 'em!" He keeps picking stuff to work on that ends up being insanely useful to a massive number of people. That seems somehow even more remarkable than the technical ability. Deciding what to work on might be the most important question in life.

[deleted]

Re: I admire Fabrice Bellard. He is almost certainly a better overall programmer

#359
post #246

Reading the list of Bellard's contributions, what strikes me is not the raw ability (although certainly there is that too!) but "damn, he knows how to pick 'em!" He keeps picking stuff to work on that ends up being insanely useful to a massive number of people. That seems somehow even more remarkable than the technical ability. Deciding what to work on might be the most important question in life.

> Deciding what to work on might be the most important question in life.

Work on being a positive influence in the world. Help your neighbour when they are in need and fight for the rights of those less fortunate than yourself.

Re: I admire Fabrice Bellard. He is almost certainly a better overall programmer

#360
post #249
post #246

Reading the list of Bellard's contributions, what strikes me is not the raw ability (although certainly there is that too!) but "damn, he knows how to pick 'em!" He keeps picking stuff to work on that ends up being insanely useful to a massive number of people. That seems somehow even more remarkable than the technical ability. Deciding what to work on might be the most important question in life.

My guess would be the hueristic is "I want to do simple thing, why is it so hard?" (Modern computing has an overabundance of "DX tarpits".) Which is funny because, everyone has that experience, right? But then approximately nobody proceeds to do something about it. (Including most people who have the skills to make a difference!) Like, that's surprisingly mundane, and surprisingly actionable. --- If we distil it into…

>"DX tarpits"

This is my approach which I use for SMBs (my actual clients). Never failed in decades. I am on my own since year 2000 and few times before that.

1) Always start with building single vertically scalable monolith running on dedicated server which can serve reasonable amount of transactions / date volume with acceptable performance.

2) Only start adding to infra when vertical scaling stops working (well you get some warning sign before it actually starting to hurt business) and then do it strictly on on need basis. Only rewrite / rearchitect if you see approaching google scale and can not shard simply by XXX-Canada, XXX-US etc. This will of course fail on some specialized scenarios but we are talking plain vanilla business backends for SMB.

Post reply on HN