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

Tue Mar 23 14:16:37 CET 2021

Having read this entire conversation I find it interesting that we as developers are complaining about features being deprecated and removed in Qt but yet where is the anger when C++ spec removes features? 

https://en.wikipedia.org/wiki/C%2B%2B20#Removed_features_and_deprecation

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2131r0.html#removed

http://www.cplusplus2017.info/removed-features-from-c17/

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1319r0.html#removed

I have also been caught when trying to upgrade some legacy codes that were written well over 15 years ago by compiling with a “modern” C++ Compiler. We complain when the API gets bloated and slow then we complain when it gets trimmed down to be fast again. Pick something. 

I’m not disagreeing with the license issue. I’m not disagreeing with the “Qt6 is a mess”. Just pointing out that even C++ undergoes changes where features that people may have used get’s removed.

--

Michael Jackson | Owner, President

      BlueQuartz Software

[e] mike.jackson at bluequartz.net

[w] www.bluequartz.net

From: Interest <interest-bounces at qt-project.org> on behalf of Roland Hughes <roland at logikalsolutions.com>
Date: Tuesday, March 23, 2021 at 7:02 AM
To: <interest at qt-project.org>, <max-l at wdg.us>
Subject: Re: [Interest] The willy-nilly deletion of convenience, methods

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
_______________________________________________ Interest mailing list Interest at qt-project.org https://lists.qt-project.org/listinfo/interest 

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