Are we just "Cash Cows"?

[MichaelT 6]

We are not the Cash Cows, that's Delphi. We are the goats to be milked. Reminds me of a story in my childhood in which a goat used to complain, 'I only jumped over grass and didn't find a single leaf'. Maybe at least another one in this forum who read the same stories or fairy tales in the child hood and nowadays as well on EMB flyers ...

 

Pretty much the same issue with COM/ActiveX/COM+ support in the 1990s. Delphi went beyond what VB was in the position to offer but pretty 'late' in comparison what C/C++ offered once the feature was offered by Windows. These days almost no user except from a few enthusiasts installed the latest version of Windows the moment it was released. It was still easier to implement something using those technologies compared to writing all the various files manually in a consistent way at once. It didn't hurt to be late, but features offered by Delphi were never released on time the moment external dependencies came into play. Delphi never offered a more convenient consistent way of building COM & Co artifacts in a sense of just more easy C or C++, without haven to ship additional BPLs or link proprietary stuff.

 

Delphi .net did away with all that because MS did away with all that when introducing C# .net in V 1.1. better said little later in 2.0. Even if room for improvement was left, those major issued were addressed and finally covered.

 

This game of everlasting catching up returned together with the various SDKs offered for different platforms by the vendors.

 

The idea of giving up on expected quality shipped at the same point in time but on budget never really worked out great for anyone (triangle) and is a luxury today btw.

 

Embarcadero does ship new features and I observe a slowing down almost everywhere, when it comes to tools and technologies. This same problems the vendors of CASE tools have not been in the position to address let IDEs turn out to become one of the most dominant concepts and finally the big winner at the end of the 20th century.

 

Putting a strong focus on just quality would put Delphi immediately into a corner/niche in which Eiffel & Co ended up almost 30 years ago. Today there is not even a niche left because all those who provide technologies designed their own IDE for their niches.

 

-

 

It's hard to change the language in a fully integrated environment when the IDE relies on scanning source code files. I'm aware that Delphi does not scan source code files solely. The big advantage of JARs and .net 'assemblies' hurt C/C++ around 2k. A few years later the hip web programming languages run into pretty much the same problem e.g. PHP4 vs. PHP5 still remaining the best example. When PHP Storm started to address this issue the one idea or the other moved into the mainstream IDEs too for very much the same reason but never made it into Delphi and C++ is a whole different story but today those features are available too. No matter if a community did provide them or the supplier.

 

Since C programmers started to use those languages too the C ish programming style (Schottern slang. ger. ok. Austrian language), writing 50 lines of code and compile them later at one, spread. IDEs adopted into this direction. Think of an article about 'Delphi fighting a battle lost long time ago, in which a former Delphi programmer talked very positive about being in the position to write working code that way without the need to compile, because of being guided by the IDE plus Java technology. Same counts for VS and C#/.net to a certain degree. I call that assisted coding similar to assisted living (residence).

 

Today the last issue, which is no for me personally, is Error Insight. I personally do have nothing but 'Use Editor Font' checked an nothing else enabled in Code Insight. This time I found no reason to turn those features off but I don't have 10.4 installed at the moment.  So I cannot comment on how far 'Assisted Programming' is supported today. Error Insight works for me too.

 

-

 

Language: I don't care in general or at all. I'm happy.

 

-

 

Compilers: It makes sense for such a professional tool allowing other tool providers (e.g. threading & Co) to support Delphi Win64 quickly. This has always been missing but since vendors do/did support Delphi 32-bit there must have been a demand. There will be no nice little handy Delphi once again, even if EMB(T) is trying to sell such an illusion. That's not the only reason why tested 'quality' has to be shipped. No one assumes a development system that allows to address such a wide range of applications and platforms the native way to be nice and cuddly but it must work and using it must work smoothly.

 

-

 

In fact we never really went beyond having 4 tabs Standard, Additional, Win32 and System. Ok, dialogs and Win 3.1 for those who have to cope with the ultimate legacy source code. Anything else is usable and well maintained imo.

 

What hurts to a certain degree that from the overall picture/perspective  Lazarus/FPC leaves a more complete or compact impression at a first glance. Not talking about what can be done or what the result might be, just from the perspective of how things can be done.

 

In order to build your own controls in sense of widget set today, you needed a continuously improved CDK. For all those who have to maintain millions of lines of code building components for both VCL and FMX is not a big issue very likely. It's very nice to have access to an IDE which MVPs can handle and extend with style(s). This approach sound pretty elite not saying esoteric. Admiring all of you for what you are in the position to do with Delphi, will not help to grow a young generation of programmers within an acceptable amount of time. Kidding. Today people use tools like hardware tools lying around in grand pa's craft cellar or a workshop.

 

I'm wondering in how far it does make sense from the developer's perspective (apart from buying components which introduces a lower but another kind of complexity) to be in the position to create a component (especially) for the GUI but having to consider all available target platforms in order stay happy because of being prepared for whatever target that has to be addressed in the future. Putting silver under the pillow neighter does make you feel save nor does it make you sleep better. On a contrary your will very likely wake up with headache.

[Darian Miller 361]

16 minutes ago, David Heffernan said:

There is no buzz. Where are all the new developers?

 

I think there is a little more buzz today than, say, 5 years ago.  The mobile offering is getting better so I see some new devs trying to produce apps.  To provide something measurable, I've added more than 1,000 new connections on LinkedIn within the last 6 months, almost all Delphi developers or related.  I've asked for many of those connections, and posted on my blog asking for people to reach out to me which has generated quite a few inbound requests.  That's not necessarily 'buzz' in the general marketplace but it does show me that there still is some interest in Delphi.  I've also been playing around with a blog on occasion and it's had a little activity.  

 

I did 'Get Excited' with 10.4 and I thought it had the potential to be a really cool new version.  Unfortunately, their internal testing seems to be seriously lacking (or perhaps the people making the decision to 'ship it' are not listening to those that know better.)  I offered to help provide/debug test suites for their PPL but they resisted due to IP concerns.  I did publish a few tests on GitHub and one test sparked a conversation here which hopefully has led to a much needed fix in 10.4.1.  (Thanks to those that did the hard work, mainly Pyscripter and Anders Melander)

 

Perhaps we as a commuity revisit the community-powered RTL test suite that Nick Hodges started years ago?  From what I remember, one problem that derailed the last attempt was the desire to test old versions which complicated matters.  Is anyone else interested in participating?  Or perhaps a better first question: does anyone already have some RTL/VCL/FMX type tests that they would be willing to contribute to a public GitHub repo?  I'd be willing to do much of the initial leg work behind the project.  I think it would ramp up quickly if we just combined a set of currently available tests.  (I'm assuming that I'm not the only one that generates a few tests for RTL hotspots.)  This would include existing projects that reproduce existing quality portal items that could probably be converted into a unit test.  If interested, zip up the projects and send me what you'd like to contribute:  darian@ideasawakened.com and I'll get them added to https://github.com/ideasawakened/DelphiKB/tree/master/Delphi Tests/Source   Or, create your own RTL/VCL/FMX test repo and post a link.

 

 

[FredS 138]

26 minutes ago, Darian Miller said:

I think there is a little more buzz today

 

Could be, certainly there was a window of opportunity with the Community Edition.. however that dimmed quickly as bug reports spiked and waited.. still waiting..

 

 

[Mahdi Safsafi 225]

57 minutes ago, Mike Torrettinni said:

I wish I was wrong and we have a generation of new Delphi developers, but perhaps Community edition, Academy and other activities could slowly add a few of them.

Its much complex than offering a community edition and an academy. 

In the last decade the market was bload up with new programming languages(thanks to LLVM). Those languages are very easy and very attractive for young people. Moreover they're free and have a wide community support(thanks to the big tech behind them). Delphi on the other hand is an old language and is no longer considered as the easiest language. Today developers are not like old developers. Today developers tend to seek for easy and fast solution without much complexity(i.e : GC).

Quote

but their main focus doesn't seem to be new developers.

A language is considered dead when its no longer able to attract young people. Delphi can't compete with those languages. Not because its bad ... but because is not able to satisfy a particular range of new developers. I believe EMB understood clearly this. that's why it focuses on old developers, on compatibility and does not spend much on resources.  

[Darian Miller 361]

28 minutes ago, FredS said:

 

Could be, certainly there was a window of opportunity with the Community Edition.. however that dimmed quickly as bug reports spiked and waited.. still waiting..

 

I think the Community Edition is still very cool...but the powers to be are apparently getting nervous about it stealing too much from their cash cow so they plan on delaying 10.4 CE for months.  To me, you either want a bunch of new developers, or you don't.  It takes some cojones to stick to a plan.  

 

My guess is that once their lawyers figure out how to further complicate the CE user agreement, 10.4 CE will probably be released with a few additional feature limitations.  Hopefully they don't get too over-zealous and self-defeat their own plan.

 

 

[Lars Fosdal 1792]

A language dies when it is no longer in use. COBOL is alive and kicking, but good luck finding young COBOL programmers.

 

There is no shortage of things that can be improved in Delphi. 

 

I wish they would do more with the language. Especially generics constraints need more love. Attributes are still somewhat half-baked.

 

I wish they would do more to improve the generated code for efficient memory access and math / vector math. I'd love an ARM64 compiler for Windows, as well as Linux/R pie. 

 

I wish the debuggers just worked and kept working and were smarter with regards to multi-threaded code. 

 

I wish the IDE would do incremental background compilation so that running your edited code was near instantaneous. 

 

But, in the mean time I code... And rant. 

[Stefan Glienke 2007]

4 hours ago, Rollo62 said:

please file a QP report

Will probably be reclassified as "new feature" :trollface:

[Mahdi Safsafi 225]

50 minutes ago, Lars Fosdal said:

A language dies when it is no longer in use. COBOL is alive and kicking, but good luck finding young COBOL programmers.

Soon or later current COBOL developers are going to retire. So if its not died ... its dying.

[Bill Meyer 337]

2 hours ago, Lars Fosdal said:

There is no shortage of things that can be improved in Delphi.

Too true.

2 hours ago, Lars Fosdal said:

I wish they would do more with the language. Especially generics constraints need more love. Attributes are still somewhat half-baked.

 

I wish they would do more to improve the generated code for efficient memory access and math / vector math. I'd love an ARM64 compiler for Windows, as well as Linux/R pie.

Agreed on generics. Toiling in legacy code, I am so far from attributes I can't even imagine using them.

 

Code efficiency certainly needs attention. ARM64, meh. Linux... been trying to make it a thing for myself for a quarter century. But in my area of work, it;s just not a factor.

2 hours ago, Lars Fosdal said:

I wish the debuggers just worked and kept working and were smarter with regards to multi-threaded code. 

 

I wish the IDE would do incremental background compilation so that running your edited code was near instantaneous.

Yes! Reliability of IDE and debuggers are bedrock. Background compilation would be nice, but not essential if compiler speed is high.

 

I'd wish for better tools for dealing with legacy issues. MMX identifies unit dependency cycles, but in a large app, the challenge is then to discover in which units they are actually created, and which modules are merely caught in the chain.

 

I would rant, but need the energy more for finding patience with IDE and debugger problems. 😉

[Lars Fosdal 1792]

1 hour ago, Mahdi Safsafi said:

So if its not died ... its dying.

Like the rest of us.

Meanwhile, we make the best of it until we or it retires. 

 

[Lars Fosdal 1792]

7 minutes ago, Bill Meyer said:

ARM64, meh. Linux... been trying to make it a thing for myself for a quarter century. But in my area of work, it;s just not a factor.

Well, the next MacBook Pro will be ARM64.

If that exercise works out, will any of the Macs remain x64? There already is a Windows for ARM64. The only constant is change. 

[Lars Fosdal 1792]

16 minutes ago, Bill Meyer said:

I'd wish for better tools for dealing with legacy issues. MMX identifies unit dependency cycles, but in a large app, the challenge is then to discover in which units they are actually created, and which modules are merely caught in the chain.

 

OMG, Yes! 

[mvanrijnen 123]

Not read the whole thread, but this is my opinion.

 

Delphi comes to me as a product for which you pay full price (a lot more then VisualStudio), with less capabilities/tooling,

but the most painfull, it seems/looks like it is being developed as a opensource project with some projectmanagers and a varying dev team. 

They really should sit on their customers seat for a while and get a new perspective on how to go forward with Delphi.
It's a wonderful language with enough possibilities, would be a shame if we would have to go look around for another dev platform if quality does not improve. At the moment it;s not future proof.

 

Edited July 17, 2020 by mvanrijnen

[Markus Kinzler 174]

9 hours ago, Lars Fosdal said:

Well, the next MacBook Pro will be ARM64.

If that exercise works out, will any of the Macs remain x64? There already is a Windows for ARM64. The only constant is change. 

No, Apple will completely switch to their own apple silicon.

[Lars Fosdal 1792]

11 minutes ago, Markus Kinzler said:

No, Apple will completely switch to their own apple silicon.

ARM is an architecture, not a brand.

The Apple chips are ARM based.

[Markus Kinzler 174]

Just now, Lars Fosdal said:

ARM is an architecture, not a brand.

The Apple chips are ARM based.

I know. Your question was wether any Macs stay x86.

[Lars Fosdal 1792]

5 minutes ago, Markus Kinzler said:

I know. Your question was wether any Macs stay x86.

That is still very much an open-ended question, especially if you consider the power of the Mac Pro.

https://www.theverge.com/2020/6/23/21296365/apple-mac-arm-processor-silicon-chips-performance-power-speed-wwdc-2020

 

[Dalija Prasnikar 1396]

1 hour ago, Lars Fosdal said:

ARM is an architecture, not a brand.

The Apple chips are ARM based.

Apple Silicon is terminology used for Apple designed, ARM based chips https://en.wikipedia.org/wiki/Apple_Silicon

[Guest]

@Lars Fosdal Does how Apple manage their products and RD belong to this thread !!!!!!🤬 

 

Does it ? 😎

 

 

[Rollo62 536]

13 hours ago, Mahdi Safsafi said:

Soon or later current COBOL developers are going to retire.

Sorry Mahdi Safsafi, I think this is same issue as above.

This very same text line is from 1995 too, please update that as well to a more modern version.

[mvanrijnen 123]

20 minutes ago, Rollo62 said:

Sorry Mahdi Safsafi, I think this is same issue as above.

This very same text line is from 1995 too, please update that as well to a more modern version.

for a fact my first official programming classes where in COBOL 🙂

very long time ago.

[Mahdi Safsafi 225]

45 minutes ago, Rollo62 said:

 Sorry Mahdi Safsafi, I think this is same issue as above.

This very same text line is from 1995 too, please update that as well to a more modern version.

Nothing last for ever. its just a question of time. COBOL developers are old by now and the time they go for retiring, No one would be there to fill that gap as the language is unable to attract young developers. A programming language that is unable to attract young people would likely to have no future.

Its hard to me to declare the above statements but that's the reality -whether we liked or not-.

[Sherlock 663]

Yeah, all the cool kids want to JavaScript, while banks and insurance companies are going out of their way to pay regal salaries to those old COBOL geezers. COBOL delivers, where JS just looks shiny.

[Mahdi Safsafi 225]

18 minutes ago, Sherlock said:

Yeah, all the cool kids want to JavaScript, while banks and insurance companies are going out of their way to pay regal salaries to those old COBOL geezers. COBOL delivers, where JS just looks shiny.

Exactly, you hit the nail on the head. 

[FredS 138]

6 hours ago, mvanrijnen said:

They really should sit on their customers seat for a while

 

Developing Delphi with Delphi was a reasonably good guarantee of that..