CVEs/LOC not a great metric

Posted Dec 3, 2024 10:53 UTC (Tue) by paulj (subscriber, #341)
In reply to: CVEs/LOC not a great metric by Cyberax
Parent article: NonStop discussion around adding Rust to Git

> It's actually easy to explain: the array reserves space exponentially on appends.

Can you expand on that for non-Go people? The slice that append returns is a different type of slice to the original []int slice?

CVEs/LOC not a great metric

Posted Dec 3, 2024 11:05 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (11 responses)

It looks like bad copy-on-write semantics to me. The first call's `append` has to allocate new memory, so `newNumbers[0]` is completely separate from the input array's backing memory. The second call uses the existing allocation (the extra space the first call to `append` reserved) and writes "see through" to the passed array and modifications affect it. Feels kind of like the Python behavior where `def foo(arr=[]): arr.append(1)` ends up modifying the default argument's backing store if `arr` is not passed.

CVEs/LOC not a great metric

Posted Dec 3, 2024 12:40 UTC (Tue) by khim (subscriber, #9252) [Link] (8 responses)

Correct. And the most amusing issue there is the reaction to that problem from language developers: just don't do that.

Come on, guys! If just don't do that (and write your code without bugs, dummy) would have been a good, actionable, answer then that push for the “memory safe” languages wouldn't have happened in the first place!

If you write code without mistakes then you can write correct, working, program in C, C++ or even assembler: D. J. Bernstein did that (or almost did that depending on you are asking), this approach works!

But it doesn't scale – and that raises the question: why should we accept such answer in “memory safe” languages… we have just abandoned “memory unsafe” precisely because that's bad answer!

P.S. This doesn't mean that Ada or Rust never say just don't do that. Sometimes it's just simply unavoidable. E.g. if you hash functions doesn't always return the same value for the same object (which may happen if you use address of some objects in hash and then object is moved) then Rust's HashSet is not guaranteed to find element in that set. Kind of unfortunate, but hard to offer better alternative. But to design language in XXI century and conflate dynamic array and slice “for simplicity”? Really? Sure, you “simplified” the language… by shoving all that complexity into my head… how is that a good trade-off? I like “simple” languages as much as the next guy – till that “simplicity” is not bought by shoving the intrinsic complexity into my head! And most “memory safe” languages that are popular today are like that: they are “simple” in a sense that their reference guide is short – but then all that complexity have to live in the head of the language user… because where else could it go?

CVEs/LOC not a great metric

Posted Dec 3, 2024 13:05 UTC (Tue) by Wol (subscriber, #4433) [Link] (7 responses)

> Really? Sure, you “simplified” the language… by shoving all that complexity into my head… how is that a good trade-off?

Einstein: "Make things as simple as possible - But No Simpler!"

If you make *PART* of the problem space simpler, by pushing the complexity elsewhere (where it doesn't belong), you make the overall solution more complex.

(Don't get me started on Relational and SQL :-)

Cheers,
Wol

CVEs/LOC not a great metric

Posted Dec 3, 2024 13:20 UTC (Tue) by khim (subscriber, #9252) [Link] (6 responses)

> (Don't get me started on Relational and SQL :-)

Lol. That's actually surprisingly relevant (if sad) example. Sure, SQL is horrible paradigm, but would anything else have a chance in a world where so many people know SQL and so few know anything else?

That push for safer, more robust programs (and push for “memory safe” langauges) have started not because what Rust offers is better than what C++ offers, no.

It have only started when losses started being measured in trillions.

Does the [ab]use of SQL have a chance to lead to losses of that magnitude? Does it cause anything but 10x (or maybe 100x?) excess resource consumption in some rare situations?

I don't know, in all the applications where I use SQL 100x speedup of database access would affect the work of the whole system only very marginally.

CVEs/LOC not a great metric

Posted Dec 3, 2024 14:14 UTC (Tue) by Wol (subscriber, #4433) [Link] (5 responses)

> I don't know, in all the applications where I use SQL 100x speedup of database access would affect the work of the whole system only very marginally.

And if it sped up DEVELOPMENT time by the same one or two orders of magnitude?

One of my war stories (that I'm not sure if it rings true ... the database side rings true, it's the rest of it that doesn't) the Australian breweries when Australia introduced GST.

Of the six breweries, five ran a relational-based accounts system. One of these realised that by leasing barrels to the pubs rather than selling and buying back, they could save a lot of tax. They updated their systems and caught the other five breweries on the hop.

The other four relational breweries took six months to catch up - and lost a lot of market share. Made worse because the sixth brewery modified their Pick-based system in two months - so for the last four months they had TWO breweries taking market share because they were paying less tax...

(Oh - and where seconds count, like 999-response systems (that's 112 or 911 to non-brits), would a "results almost before I hit "return" " response time make much difference? :-)

Cheers,
Wol

CVEs/LOC not a great metric

Posted Dec 3, 2024 16:02 UTC (Tue) by khim (subscriber, #9252) [Link] (4 responses)

> that I'm not sure if it rings true ... the database side rings true, it's the rest of it that doesn't

But it's the rest of it that matters.

> The other four relational breweries took six months to catch up - and lost a lot of market share. Made worse because the sixth brewery modified their Pick-based system in two months - so for the last four months they had TWO breweries taking market share because they were paying less tax...

And the whole thing just falls to pieces at this point. My sister is an accountant and she faced cases like these few times. Usually it just takes two or three days to cobble together something working using some Excel sheets and maybe VBA scripts. And accounting people just do papers by hand. Then later, when the need is not as pressing one makes it automatic.

But sure that only works for a small companies that are not under extra-strict pressure… but these companies that do have the need to do everything in a “certified” fashion… who the hell allowed them to use Pick in place of SAP?

In my experience if something takes not days, but months or years that's not the result of deficiency of SQL or something like that, but the need to jump through lots of paper barriers – and I fail to see how Pick can improve anything there.

> Oh - and where seconds count, like 999-response systems (that's 112 or 911 to non-brits), would a "results almost before I hit "return" " response time make much difference? :-)

Most likely no. Simply because no one would even allow you to use anything without pile of certification papers… that Pick-based system wouldn't have (and most SQL-based systems wouldn't have either).

In the end some horribly inefficient, but certified solution would be picked, no matter what you do.

CVEs/LOC not a great metric

Posted Dec 3, 2024 17:03 UTC (Tue) by Wol (subscriber, #4433) [Link] (2 responses)

> In my experience if something takes not days, but months or years that's not the result of deficiency of SQL or something like that, but the need to jump through lots of paper barriers – and I fail to see how Pick can improve anything there.

In my experience (and I'm currently living the hell ...) writing one single query in SQL can take days. The same query in Pick can be knocked up, tested, and verified! in five minutes! (The query I'm currently trying to debug, and falling over corner cases, and discovering that I'm querying data that doesn't exist or is stored somewhere else, and and and - has taken me months and I've just had a message saying it's screwed up AGAIN! I think I know why, some attribute I don't give a monkeys about has an unexpected value ... :-(

> In the end some horribly inefficient, but certified solution would be picked, no matter what you do.

True :-(

So basically, you're saying that 90% of the work is not programming, but administration ... but there's a lot of places where that isn't true. I work for an (ex)FTSE100, and I'm trying to introduce Pick to get rid of our Excel database. But yes, I know about paperwork - it's supposedly dead easy to introduce "new" technology, there's just a whole bunch of hoops I don't have a clue how to navigate :-( Once it's in, it won't be a problem any more ...

Cheers,
Wol

CVEs/LOC not a great metric

Posted Dec 3, 2024 17:24 UTC (Tue) by daroc (editor, #160859) [Link] (1 responses)

I think we've wandered pretty far off topic, at this point. Let's leave this discussion here.

CVEs/LOC not a great metric

Posted Dec 4, 2024 13:04 UTC (Wed) by paulj (subscriber, #341) [Link]

Wol was doing so well the last while... He's actually managed to go quite a while recently without bringing up Pick. This is his first relapse of his pickaholicism in a while, TTBOM. Maybe he can last a bit longer again from this point forward. ;)

CVEs/LOC not a great metric

Posted Dec 3, 2024 17:08 UTC (Tue) by Wol (subscriber, #4433) [Link]

> But sure that only works for a small companies that are not under extra-strict pressure… but these companies that do have the need to do everything in a “certified” fashion… who the hell allowed them to use Pick in place of SAP?

The accountants? Because chances are, the accounting system was written by accountants who knew what an accounting system was supposed to do, and not by programmers who filled it with bugs because they didn't have a clue?

(Okay, this IS a seriously double-edged sword!)

Cheers,
Wol

CVEs/LOC not a great metric

Posted Dec 3, 2024 18:09 UTC (Tue) by mirabilos (subscriber, #84359) [Link] (1 responses)

Except that the Python behaviour is consistent (and documented, not sure about the issue9 behaviour wrt. that).

CVEs/LOC not a great metric

Posted Dec 3, 2024 21:16 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Yes, there are definitely lints that warn about such things in Python. My caveman club-level of finesse with Golang is usually just happy to get things to work (though I've not dealt with its slices enough to know how any linters behave with them).