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

My Software North Star

kristoff.it

Post reply on HN
Print view View original

81–90 of 166 posts

Re: My Software North Star

#81

Post by pixl97 »

camdenreslink wrote: post #65
dopple wrote: post #58

Earlier quoted context omitted.

> There is a pretty clear and important difference between a program that does something wrong, and a program that just doesn't do something somebody wants. Your argument hinges on all parties agreeing on what "wrong" means. Take a step back and consider that parties do not agree on a common definition of "wrong." Does "wrong" mean a gap between the spec and the implementation or a gap between a reasonable user's exp…

There are some really obvious things that are definitely bugs. If login doesn’t work if your email address contains the letter “e” when the expectation is all valid email addresses should work, then that is a bug. It isn’t “indistinguishable from a feature”. If clicking a button in your accounting software consumes all the RAM on your computer and causes it to crash, then there is no universe or agreed upon definitio…

>If login doesn’t work if your email address contains the letter “e” when the expectation is all valid email addresses should work,

And what about the + symbol?

Re: My Software North Star

#82

Post by rirze »

dnautics wrote: post #8
flooow wrote: post #7

I imagine it's a difficult time to be a Zig developer. In the near term, Bun choosing to switch from Zig to Rust specifically to fix all the memory errors seems to have done the Zig community some psychological damage. But more significantly, in the medium term it looks likely that AI coding is going to overtake the industry before Zig gets properly established. And it is going to be very hard to justify choosing Zig…

> before Zig gets properly established. zig is reasonably established. the llms write pretty good zig. see project linked below which is almost entirely llm-written > And it is going to be very hard to justify choosing Zig for your sloppy-but-functional AI-written code why? because one project that was shipping fast made a dog's breakfast of it? > why open yourself up to memory unsafety on top of everything else? thi…

> the llms write pretty good zig

I doubt this from my personal experience. Every week after a release, I see tweets complaining how AI wrote some depreciated code because Zig is making breaking changes every release. (They are valid in doing so, it's just not AI friendly yet)

Re: My Software North Star

#83

Post by giancarlostoro »

alkonaut wrote: post #34

> It doesn’t matter that the language you use is memory-safe, if you didn’t design for correctness or have no process that will eventually lead you to fixing all bugs. After many years in the business I have come to a more pragmatic view. There is no meaningful way of distinguishing features from bugs. It doesn't matter that work tracking software usually does. Once you realize that the lack of a feature is the same…

> There is no meaningful way of distinguishing features from bugs.

Especially when you implement it exactly as directed by a project manager. Everyone forgets why it was done the way it was done, and then the same project manager asks for it to be "fixed" despite it being the way they wanted it in your original ticket.

Re: My Software North Star

#84

Post by oytis »

flooow wrote: post #7

I imagine it's a difficult time to be a Zig developer. In the near term, Bun choosing to switch from Zig to Rust specifically to fix all the memory errors seems to have done the Zig community some psychological damage. But more significantly, in the medium term it looks likely that AI coding is going to overtake the industry before Zig gets properly established. And it is going to be very hard to justify choosing Zig…

I don't understand the idea behind Zig. What I have read sounded like "let's make a language like Rust, but not memory-safe", which doesn't make a lot of sense to me.

Re: My Software North Star

#85

Post by appplication »

coldtea wrote: post #75
alkonaut wrote: post #34

> It doesn’t matter that the language you use is memory-safe, if you didn’t design for correctness or have no process that will eventually lead you to fixing all bugs. After many years in the business I have come to a more pragmatic view. There is no meaningful way of distinguishing features from bugs. It doesn't matter that work tracking software usually does. Once you realize that the lack of a feature is the same…

> Once you realize that the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features", then you also accept that you will never be done. This doesn't make sense at all. Your email software mangles my email. Or your media player randomly skips. That's a bug. No big philosophy needs to be hidden behind it. That your media player doesn't have the shuffle feature i…

My read was they were not saying they’re actually, literally, the same, but for the purposes of prioritization there’s no point in differentiating feature from bug when you use the same “how does this impact my products value to users” as the deciding factor for what gets scoped.

It’s an interesting insight but I’m also not sure it’s valuable in practice. Sort of like “we’re just bags of chemicals that tricked rocks into thinking”.

Re: My Software North Star

#86

Post by alkonaut »

coldtea wrote: post #75
alkonaut wrote: post #34

> It doesn’t matter that the language you use is memory-safe, if you didn’t design for correctness or have no process that will eventually lead you to fixing all bugs. After many years in the business I have come to a more pragmatic view. There is no meaningful way of distinguishing features from bugs. It doesn't matter that work tracking software usually does. Once you realize that the lack of a feature is the same…

> Once you realize that the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features", then you also accept that you will never be done. This doesn't make sense at all. Your email software mangles my email. Or your media player randomly skips. That's a bug. No big philosophy needs to be hidden behind it. That your media player doesn't have the shuffle feature i…

There are things that are clearly bugs and clearly features. And a lot of things that are somewhere in between. It’s not black or white and as such perhaps not worth categorizing?

Especially with dramatic processes like ”always fix all bugs before implementing any feature”.

Re: My Software North Star

#87

Post by pegasus »

pixl97 wrote: post #80
coldtea wrote: post #77

Earlier quoted context omitted.

> Your argument hinges on all parties agreeing on what "wrong" means No, it just hinges on common sense. "All parties" are never gonna agree on everything. There will always be customers that demand whatever and treats its lack as a bug. Doesn't make it a bug anymore than me asking for a free glass of wine with my meal and not being given any is "injustice" - when the restaurant never promised any.

>No, it just hinges on common sense Common sense doesn't exist in the business environment.

Sure it does. To a point, as all things. One could always have more, but it is what it is.

Re: My Software North Star

#88

Post by alkonaut »

coldtea wrote: post #76
alkonaut wrote: post #39

Earlier quoted context omitted.

Some times there is, and in many cases there is not. Distinguishing a feature from a bug requires having some kind of spec. In some cases you can have obvious sign the behaviour is unintended/not desired, but in other cases it's not so easy. For example a customer reports a bug, your program can't print. Oh, you say, we never even had that feature! Please post again, as a feature request. Customer mumbles and request…

> Some times there is, and in many cases there is not. Distinguishing a feature from a bug requires having some kind of spec. In some cases you can have obvious sign the behaviour is unintended/not desired, but in other cases it's not so easy. For example a customer reports a bug, your program can't print. Oh, you say, we never even had that feature! Please post again, as a feature request.Customer mumbles and reques…

Not even a development team can (or should!) be able to agree on whether something is a bug. Just because there is never a complete spec. It’s a mental state of the team. Or expectations among stakeholders.

Re: My Software North Star

#89

Post by alkonaut »

dxdm wrote: post #48
alkonaut wrote: post #34

> It doesn’t matter that the language you use is memory-safe, if you didn’t design for correctness or have no process that will eventually lead you to fixing all bugs. After many years in the business I have come to a more pragmatic view. There is no meaningful way of distinguishing features from bugs. It doesn't matter that work tracking software usually does. Once you realize that the lack of a feature is the same…

When a program clearly deviates from its spec, would you be okay with calling that a "bug"? There's always a gray area of what's intended by the spec, but a program can absolutely and blatantly deviate from the letter of the spec, and they often do. This distinction seems worthwhile to me, because it means that something someone already relies on does not work (anymore), even though reasonable people would agree that…

Absolutely would. But if we can categorize 1/3 of defects as ”bugs” 1/3 as ”missing or incomplete functionality” then there is 1/3 in the middle which we can’t decide. So the dichotomy is kind of weird, and making ”rules” and processes about this categorization is probably not worthwhile.

Re: My Software North Star

#90

Post by thaumasiotes »

coldtea wrote: post #76
alkonaut wrote: post #39

Earlier quoted context omitted.

Some times there is, and in many cases there is not. Distinguishing a feature from a bug requires having some kind of spec. In some cases you can have obvious sign the behaviour is unintended/not desired, but in other cases it's not so easy. For example a customer reports a bug, your program can't print. Oh, you say, we never even had that feature! Please post again, as a feature request. Customer mumbles and request…

> Some times there is, and in many cases there is not. Distinguishing a feature from a bug requires having some kind of spec. In some cases you can have obvious sign the behaviour is unintended/not desired, but in other cases it's not so easy. For example a customer reports a bug, your program can't print. Oh, you say, we never even had that feature! Please post again, as a feature request.Customer mumbles and reques…

> Any software has a spec.

Note that the 'spec' you're referring to isn't the same thing as the 'spec' in your pulled quote. The Java spec tells us that the expression

    var >> 40
refers to the value

    var / 256
This is a bug in Java. It's not a bug in the implementation of the spec - that's what the spec says. But it is a bug in the spec.

To identify that bug, you need another spec that can find fault with the official spec. Only the official spec is written down.

Here are some other common and widely-recognized bugs-in-the-spec:

- The conventional sign of the electric charge of protons and electrons has been reversed.

- Mathematical function applications are written before their argument, when they should be written after.

Post reply on HN