CVEs/LOC not a great metric

Posted Dec 3, 2024 13:05 UTC (Tue) by Wol (subscriber, #4433)
In reply to: CVEs/LOC not a great metric by khim
Parent article: NonStop discussion around adding Rust to Git

> 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