[Interest] The willy-nilly deletion of convenience, methods

[Roland Hughes]

On 3/23/21 2:31 AM, interest-request at qt-project.org wrote:
> On 3/22/2021 7:32 PM, Turtle Creek Software wrote:
>> Re: willy-nilly
> ....
>> I can relate to anyone who is unhappy about deprecated functions.  It is
>> never fun when existing code breaks.  We want to be inventing new stuff,
>> not going back and fixing old code just to stay in the same place.  The
>> C++ language has been decent about advancing, but still keeping ancient
>> code stable.  Windows bends over backwards to stay backwards compatible.
>> I think it's a basic courtesy that all platforms owe to developers.
>> Programming is hard. Doing things once should be enough.
> Amen brother, +100.
>
> Life's too short for that BS, and computers are supposed to make our
> lives easier in the first place.
>
> 20 years in the life of a language or API or library is nothing (I'm
> over 50, which gives me some perspective). Assuming anyone actually uses
> it for more than a weather app or media browser. Something like that
> needs to last for as long as anyone uses it, and if it's time for it to
> die or be replaced then let it go in peace instead of gutting it and
> pretending it's still the same animal.  And yes I do think Windows has
> done us a great service in this regard... just talk to any non-fanboy
> MacOS developer who is older than 30.  And on *nix of course everyone
> still uses utilities written before they were born.  Stability, baby.
>
> Dear QtC: Just call Qt6 a new library and make it all clean and sexy and
> commercial, or whatever.  But at least do right by everyone who's put
> their time into earlier versions, including by using them, and finish it
> up in style instead of scandal & annoyance. Not only would all the users
> appreciate it, but it just may make you seem more reliable going
> forward.  For me personally 5.12.x is the last Qt branch I will trust
> (until maybe someday all the 5.15 fixes are OS).

+1000

Amen! Can I get a witness?

Welcome to the north of 50 club, not far from the north of 60 club.

The entire problem is this x86-wanna-be-a-real-computer-when-it-grows-up 
mentality. Real products have to have 30+ years of stability, not be 
gutted every few years.

For those too young to understand, this is where AGILE and Iterative 
Development fail spectacularly. You are constantly putting out things 
that aren't going to last. By definition unstable.

30 years is __nothing__ for production systems. It is ordinary for a 
well developed system to run 10+ years without any modifications. Yeah, 
you really do need both doc and comments in the code because even if you 
wrote it, ten years later you are a different person.

You can't chase the phone market __and__ serve actual business.

These are diametrically opposed goals.

When a company puts a surgical robot in the field it has to be 
maintainable for at least 20 years. They can't afford a gut & rewrite. 
Yes, over the course of a 20+ year life a robot will "get taught new 
tricks" but those will be additional tricks. Even something as "simple" 
as a patient monitor will have to have minor software upgrades due to 
new FDA/HIPPA regulations.

Here's the 8000 pound Elephant in the room.

Cross platform isn't needed. Ain't nobody going to put Android or 
Windows behind a touch screen on a medical device. That's always going 
to be a Yocto Linux build. The dev host is always going to be a YABU or 
some other Linux distro. Cross platform has very little meaning in the 
embedded medical, industrial controls, test equipment world.

Cross platform had meaning in the desktop world. It's become a limited 
meaning though. Yeah, it's nice that I can run text editor A on Windows, 
Linux, and that obscure platform. The sad reality is they rarely run the 
same. Just try KATE on Windows. So, yes. A browser, an editor, a music 
player, in short, tiny "consumer apps" have some need for cross 
platform. The real business apps just don't do it. A front end for a 
medical records system simply isn't going to run on Mac or Linux unless 
they went with a browser interface.

The phone world is just an alternate reality. That's actually how this 
downward spiral started, with the introduction of QML and forcing people 
to re-write, re-write, re-write.

People poke fun at COBOL, but the reason it still today has more lines 
of code in production than any other language is the fact COBOL doesn't 
delete anything until the hardware and OS it was added to support can 
only be found in a museum. The compiler vendors also send out technical 
bulletins to their customers when considering changes. If it is not 
forced on them by a language standards committee they query the customer 
base before doing it. This isn't a deprecation warning someone stumbles 
into when they try to compile something old. It's actual communication.

All of this is too late of course.

For roughly the past two years there has been zero management of Qt in 
general. That's why I only see medical device projects still using Qt 
4.8 OpenSource or a token few that are trying with Qt 5 because they 
started the process well over a year ago. I don't see any of them 
looking to buy a commercial license given that it buys next to nothing.

What the big checkbook companies expect when they buy commercial 
development tools and support contracts is that bugs filed, if not fixed 
immediately, are fixed within 90 days, not left to rot. It's been that 
way since the early midrange and mainframe days. Companies spend north 
of a million bucks on IBM z/OS because they get that level of support. 
They are paying it forward.

Likewise, commercial product vendors of significant volumes accept that 
high quality commercial products will have an up-front price tag that 
make smaller companies blanche. It won't try to nickel and dime them 
along the way. They will be able to use it for whatever they want 
without additional per-seat/per-unit-manufactured fees.

Here we must broach a sensitive subject. One of the reasons developers 
with degrees from decent (not even good, just decent) schools look 
askance at the self-taught world is they don't have the tools they need 
to make good decisions. A decent IT degree program forces a student to 
take Accounting I, Accounting II, and Cost Accounting. When you don't 
have these in your background you fall for the consumer trap of signing 
up for auto-billing monthly fees you forget about and continue to pay 
long after you've stopped using the service. When you've been through 
(and passed) Cost Accounting you learn that "free stuff" has a high 
price and "high priced" stuff becomes free.

There's a reason companies use the high priced Perforce stuff instead of 
Git or any of the "free" stuff. There's also a reason no renamed Digia 
is ever going to get back the trust of serious companies.

Raise your hands.

How many of you have reported bugs that have sat open for over a year?

Raise your hands.

How many of you have bugs reported against earlier versions of Qt that 
sat open until they were closed as being against an unsupported version?

That doesn't happen in the big boy commercial world. Neither situation. 
You paid real money up front and that buys you the ability to escalate a 
ticket all the way up to SEV-1 if it is a critical production outage. At 
SEV-1 there is a live person on the phone with you until there is a 
patch or a work around. Usually it is a work around followed by a patch 
in a few days/weeks. That's what is expected from commercial. When you 
pay $600+K, none of your bugs go unfixed.Your feature requests may never 
get added, but none of your bugs go untended.

Raise your hands.

How many of you have had to scrap products or features because bugs you 
reported were blockers and they were just rotting in the bug database? 
How many of those bugs are still rotting?

Free stuff, it's expensive.

When you've passed Cost Accounting, you understand this.

Years ago I was working with another consultant on a patient monitor. 
They drove us hard to make all of the graphics work without a GPU. 
During the peak of my frustration I had to sit back and remember my cost 
accounting. The same CPU with GPU was 0.25/unit more. Totally up the 
hours they spent over $100K just making the device work with the cheaper 
processor. They sold something like 7 million of them in 3 years. Our 
very expensive time was free. That 0.25/unit was really expensive. That 
device is still selling today and my checks cleared the bank years ago.

The Qt OpenSource model simply does not work. It cannot really be made 
to work.

You can't pursue licensing from lone wolfs and shoestring startups and 
expect well run legitimate companies to have any respect for you. It's 
not going to happen.

The only thing that is going to work for the big ticket companies is a 
100% commercial product that happens to release its older stuff as 
OpenSource and sometimes accepts software developed by others for free. 
Nobody wants to hear that, but that is the only model that works. With 
that model comes fixing all bugs inside 90 days. None of this hoping 
someone in the OpenSource community fixes it for free.

Everybody wanting bleeding edge features, especially the phone crowd, 
will wail to high heaven, but that is the only model that can work in 
this day and age. If there __has__ to be commercial that's how it has to 
be. It also cannot have any current or former Digia management. They've 
created a massive crater with black smoke and ash spewing from it. The 
industry rep is sooooo bad now that any new version of Qt __has__ to be 
renamed. A product with the name Qt is never going to be looked at in 
the industrial controls/test or medical device world again. The groups 
maintaining their own Qt 4.8 will keep doing that. You might find one or 
two living with whatever version of Qt 5 they have, but you won't find 
anyone taking the plunge now. That bridge wasn't burned, it was nuked.

It's highly doubtful that any company could pull in the staff to 
maintain all of the markets and eliminate all of the bugs, but that 
would have to be the starting point for such a venture.

That QML stuff really has to be ripped out and put into its own 
commercial package so the rest of the world doesn't have to pay the 
heavy price. When you rip out all of the QML most of the bugs will 
probably go away.

Btw, Digia needs to either stop selling consulting services or hire 
qualified developers. Twice now I've had to sweep up behind the train 
wrecks. I don't remember the order, I think the touch screen for Wolfe 
ovens via a startup in Detroit was the first train wreck. IP Ghoster was 
the other project. Both times the companies paid serious money to get 
the initial application developed. Both times Digia developers used a 
state machine which was a completely inappropriate tool. The Wolfe oven 
needed a stacked widget, not a state machine. Project craters like these 
aren't helping the reputation of Qt.

The It-Seems-to-Be-Working-For-Now model.

Because they don't have bugs that have been rotting for over a decade, 
CopperSpice went to a support and consulting contract only model. It 
seems to be working. I don't pay for support so I don't have access to 
the support database. Roughly half of my bugs reported via the forum are 
fixed within a couple of days. Some of the others are differences in 
philosophies. It takes them a bit long to admit I'm right. It remains to 
be seen if they can scale to thousands of paying customers. Thanks to 
the licensing FUD over the past two years they don't have to really 
advertise for customers.

They don't have QML which is +10,000. I don't know if phones are on the 
horizon for them. I hope not.

Medical devices, industrial controls, even desktop apps want a long 
stable platform.

Phones only care about what is shipping next week.

As I said before, those are diametrically opposed markets.

Just my 0.0002 cents.




-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210323/b9bc3b9b/attachment.html>