On 3/23/21 2:31 AM, interest-requ...@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@qt-project.org
https://lists.qt-project.org/listinfo/interest