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

71–80 of 166 posts

Re: My Software North Star

#71

Post by BirAdam »

Zakis1 wrote: post #35
mobelkh wrote: post #3

Earlier quoted context omitted.

the piece didn't really seem very targeted at Rust as much as it's targeted at projects claiming to be secure just because they're written in Rust

Agree, the claim "secure because Rust" is wrong. But "more secure than if it were written in an unsafe language" is probably going to be true most of the time.

Nah. You’re assuming that the developer has some experience. The false assurance that the magic of Rust will protect the developer from himself/herself will lead that young developer to make worse decisions. An experienced developer typically has discernment, and has learned, rather painfully, that he/she can make serious errors in any language.

Re: My Software North Star

#72

Post by n42 »

Ygg2 wrote: post #64
raincole wrote: post #6

Earlier quoted context omitted.

I don't get it. Are we reading the same article? This article is so generic that it reads like vacuous truth to me. But I don't see their bitterness towards Rust (or anything, really. It's just vacuous.) from it. Is this person a famous anti-rust'er or something?

I don't get how you dont't get. It links about memory safety (with a link towards an extremely biased article in Rust's favor) and a link to design to correctness (that leads to Zig project). There is a lot to dislike about this paragraph: 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. Hang on. If I…

Not if choosing statically checked memory safety sacrifices for correctness where it is a local optimum

Re: My Software North Star

#74

Post by zaphirplane »

raincole wrote: post #50
Zakis1 wrote: post #25

Earlier quoted context omitted.

Agreed unfortunately, if Zigs whole selling point is meant to be a "nicer C" (and a much nicer DX than Rust because no fighting the borrow checker etc) - does that really matter in a world where an LLM is writing the code? I am not going to be fighting the borrow checker, the LLM is. And as always, the response you'll hear is: but AI sucks/hallucinates/could never replace me etc... Just look at the progress LLM'S hav…

> Just look at the progress LLM'S have made in the past few years, and extrapolate that to the next 10 or 20 years. First of all, past trend doesn't predict the future. And if it did, then the answer would be nothing will matter in 20 years. Not just "no programming language," but nothing .

What does nothing matter mean thou ? The extrapolation is very plausible outcome thou

Re: My Software North Star

#75

Post by coldtea »

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 is not a bug. It's just an item on a wishlist.

>If you have a bug to fix to weigh against a feature to add, which do you pick?

Depends on the seriousness of the bug. If your disk backup software corrupts backups, I'd fix that, I wouldn't go add schedulled backups or encryption first.

If what you meant to say is that bugs and features are both items to prioritize when deciding work, sure. But they're not the same thing and are not hard to tell apart, so the metaphor doesn't work.

Re: My Software North Star

#76

Post by coldtea »

alkonaut wrote: post #39
0815beck wrote: post #37

Earlier quoted context omitted.

what do you mean "there is no way to distinguish a feature from a bug"? of course there is

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 requests the same thing as a feature request, not a bug report. They never understood what the difference was though. They couldn't print. Program bad.

Any software has a spec. It might not be publicly written, but you have in mind what you build and which features it supports. And software that's sold has lists of features, presentation pages, and trials for people to see its features.

If some random user can't tell a bug from a feature, that's on them.

Re: My Software North Star

#77

Post by coldtea »

dopple wrote: post #58
tikhonj wrote: post #45

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. "You don't support printing", "pressing the print button doesn't print", "pressing the print button crashes the computer" and "pressing the print button lets an attacker get root access to the system" are all different and it makes sense to distinguish them. (The…

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

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

Re: My Software North Star

#78

Post by coldtea »

jihadjihad wrote: post #38
0815beck wrote: post #37

Earlier quoted context omitted.

what do you mean "there is no way to distinguish a feature from a bug"? of course there is

I read it as an argument from the end user’s perspective. Kind of like this: - trying to do X, getting software error: bug - wishing the software did Y, even though it’s not implemented: bug Indeed there are people who think like that, but usually they are people like my grandparents, whose level of software understanding boils down to “the Desktop is where I play Solitaire” and “Internet Explorer is the literal inte…

>an argument from the end user’s perspective

Well, the end user's perspective is buggy.

And a developer doesn't have to give the same semantics as the user, anymore than a medical equipment manufactured needs to consider its products based on what each random patient wants and what misconceptions or urban legends they believe.

Re: My Software North Star

#79

Post by pixl97 »

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…

You must use some very small software if what it does can be held in the mind alone. Try working on something with hundreds of thousands to millions of lines of code. Have it evolve over 5 different PMs. Have it serve enterprise customers. Even something simple like

* Supports FooBaz

Now means, supports what feature set of FooBaz, what particular versions of FooBaz, does it support the fork FooBar that have the market quickly migrated to, what about the bugs in FooBaz that only show up when using your program.

Users are dumber than you think, and when they pay you a lot it's never on them.

Re: My Software North Star

#80

Post by pixl97 »

coldtea wrote: post #77
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…

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

Post reply on HN