Are we just "Cash Cows"?

[Rollo62 536]

@Günther Schoch

Well, I love risky business.

<OT>dreaming> I hope that will pay off one day   </OT>

Edited July 15, 2020 by Rollo62

[David Heffernan 2345]

40 minutes ago, Sherlock said:

I didn't read the book, but I'm guessing that only applies when you add those programmers to the same problem. Luckily Delphi has a ton of problems, that could each feed a programmer for at least a month

The problem with that is the the problems tend to interact with each other.

[Javier Tarí 23]

Everywhere but in Delphi, we see MVVM, MC, MVP  architectural patterns

Everywhere but in Delphi, many techniques as Dependency Injection are common

About DI, there is some work out there, but MVVM and such, just doesn't exist

All that should come in the box

IMO, Delphi programming hasn't changed so much on the latest 25 years.

Yes, I program since D1, and before that, since Turbo Pascal 3

 

[David Champion 48]

udderly ridiculous

[Rollo62 536]

2 minutes ago, David Champion said:

 udderly ridiculous

Yes well.

But isn't it more close to that ?

https://www.youtube.com/watch?v=JQ8jGqdE2iw

[Anders Melander 1783]

44 minutes ago, David Heffernan said:

The point of the book is that adding programmers won't necessarily result in a better output.

The book has many (good) points. One of them is that you can't naively solve a deadline problem by throwing more manpower at it; Time=Work/Resources is a meaningless equation. I assume this is what you allude to.

However it also points out that you can solve a 2000 man-hour job in less that 2000 hours by allocating more manpower if the job can be split into separate, largely independent, tasks. I think that applies here.

[Anders Melander 1783]

12 minutes ago, Javier Tarí said:

Everywhere but in Delphi, many techniques as Dependency Injection are common

Nothing is stopping you from doing DI. Why do you need that "in the box"?

As for MVVM I'm not convinced Delphi should do it at all. Not every pattern fits every language.

[Bill Meyer 337]

1 hour ago, David Heffernan said:

The point of the book is that adding programmers won't necessarily result in a better output.

Oversimplified, but Brooks demonstrates that adding programmers to a late project makes it later, and shows why that is inevitable.

 

1 hour ago, Sherlock said:

I didn't read the book, but I'm guessing that only applies when you add those programmers to the same problem. Luckily Delphi has a ton of problems, that could each feed a programmer for at least a month

Make time to read it. Your guess is correct, if the "problem" is defined broadly, for example, the compiler, the code editor, and so on. Thinking that smaller chunks may be attacked in parallel is risky, unless you have a very clean architecture and minimal coupling. And tasks defined and assigned by a product architect.

Edited July 15, 2020 by Bill Meyer

[David Heffernan 2345]

17 minutes ago, Anders Melander said:

if the job can be split into separate, largely independent, tasks. I think that applies here.

I'm less convinced that is so.

[Guest]

 

1 hour ago, Lars Fosdal said:

IMO, the development resources are probably sufficient, but as for most organizations, there simply isn't enough resource dedicated to testing - manual or automated.

That almost is a hypocrisy, with utmost respect for you and for everyone here and everywhere but developer don't or can't be called developer if they lack the ability to deliver tested and working code, you simply don't deliver and don't collect !

Lars "No time for caution", if this will hurt someone feeling then let it be, see i can go in the toilet now and with my many academic math years write the formula fully in code to deliver Falcon-X to Mars, then send it to SpaceX and charge them, and when my Delphi written code fail and will say i didn't have the resource test it or double check it, because my deed in the toilet was number 1 not number 2 !

Lars you are sentimental here, just think about the last 15 years of Delphi, what has been changed and what other languages had become, even big chunk of the RAD IDE (Delphi/Cbuilder) is written in what C# or is it VB for .NET ?! who knows.

 

1 hour ago, Anders Melander said:

2 hours ago, David Heffernan said:

I take it that everybody has read this

Sure, but how is that relevant?

The book is great no one arguing there, but it doesn't discuss how to handle legacy software/project, yes, Delphi entered that realm many years ago, the book doesn't handle how to revive an already deadlocked project or how to remove the sticks from the wheels, or remove the fossils that stopping the wheels from turning, by fossils i am not referring to age, i mean mentally hardcore radicals, or some teen seen the future must be Scratch and Delphi should follow( do it all by mouse for the 8 years old). they know for sure there is no use for them in an progressive modern area, that simply can be called incompetency, the inability to move to better or just do better, 

People should be let go, you can save funds too in that way, all of these years and we all are waiting and paying, to get what ? been called cows ! this how they sees us, and this what are they waiting from you and from me, without official explanation.

 

About R&D, all what i can say, the people who prefer to tour the world happily with small or tiny accomplishment, can't and should not be trusted to manage any R&D, they will waste any dedicated resources on ice cream testing for flavour.

 

40 minutes ago, Javier Tarí said:

Everywhere but in Delphi, we see MVVM, MC, MVP  architectural patterns

Lets not go far that much, key feature and marketing words for current Embarcadero is cloud, internet, REST, DB.... bla bla bla.... all of depends on Indy, it is unbelievable, amazing and astonishing in the same time, is Indy supported by Embarcadero or just been taken as granted, and here i don't know of the Remy the maintainer of core connection layer of all Embarcadero products is been supported or not, does he get paid or even is he getting a free license ? who knows. that must be irrelevant for them.

If Remy for some reason got busy and dropped Indy, then guess what, Embarcadero will use your code QC and hope it will work, not a biggy, is it outlandish to delegate or contract Remy to build supper stable layer for TCP transport( something like IOCP) , no they don't have funds as it spent on paying the expense of outsourcing !

[Javier Tarí 23]

1 hour ago, Anders Melander said:

Nothing is stopping you from doing DI. Why do you need that "in the box"?

As for MVVM I'm not convinced Delphi should do it at all. Not every pattern fits every language.

It doesn't matter if you like MVx or not, because with Delphi you can not use ANY of the MVx patterns

 

It does not exist any Delphi framework for  MVVM, nor MVC, nor MVP... Zero, zilch, Nil

Delphi developer base is... Quite senior

And seems between us there is not much interest in these kind of tools

 

 

 

[Bill Meyer 337]

2 hours ago, Anders Melander said:

As for MVVM I'm not convinced Delphi should do it at all. Not every pattern fits every language.

Particularly since MVVM appears to have been created largely to fit the specifics of C# and XAML.

[dummzeuch 1505]

1 hour ago, Javier Tarí said:

It doesn't matter if you like MVx or not, because with Delphi you can not use ANY of the MVx patterns

 

It does not exist any Delphi framework for  MVVM, nor MVC, nor MVP... Zero, zilch, Nil

What about  https://github.com/danieleteti/delphimvcframework ?

 

I don't know it, I just googled because I remember reading about an MVC framework for Delphi.

 

There are also quite a few hits on "delphi MVVM" but I didn't investigate any further.

[Javier Tarí 23]

1 hour ago, Bill Meyer said:

Particularly since MVVM appears to have been created largely to fit the specifics of C# and XAML.

You provided a good example of what I'm arguing...

 

Do you mean that in Delphi we don't need MVC, MVP, MVVM and so on?

 

Or perhaps is just that in Delphi we don't have anything like that?

[Javier Tarí 23]

2 minutes ago, dummzeuch said:

What about  https://github.com/danieleteti/delphimvcframework 

No, that's a REST framework; quite good, but not related to MVC UI implementations

I don't know where the MVC in the name it comes from

And about MVVM, zero

Just old posts and such; no working solution at all

[Bill Meyer 337]

Just now, Javier Tarí said:

You provided a good example of what I'm arguing...

 

Do you mean that in Delphi we don't need MVC, MVP, MVVM and so on?

 

Or perhaps is just that in Delphi we don't have anything like that?

I mean that not all patterns fit all languages. XAML is not a feature of Delphi. Examples have been written of MVC and MVP in Delphi. A book has been written about MVVM in Delphi, though it is not clear that what it describes is actually MVVM -- an objection raised by Stefan Glienke, to whom I defer.

 

In my experience, one of the most common patterns in Delphi legacy apps is the anti-pattern of large routines on forms in event handlers. That is something the double-click on a button and write code makes all too common. Thoughtless coding. Patterns are no guarantee of good design.

[Javier Tarí 23]

17 minutes ago, Bill Meyer said:

Stefan Glienke, to whom I defer.

 

In my experience, one of the most common patterns in Delphi legacy apps is the anti-pattern of large routines on forms in event handlers. That is something the double-click on a button and write code makes all too common. Thoughtless coding. Patterns are no guarantee of good design.

I found this forum searching for anything related to MVVM and Delphi; there is a Stefan post here where he says something on the line of Delphi MVVM won't work together

I have the book; I've read most or perhaps all that is written about MV* and Delphi

I'm working with some friends towards MVVM, but time is scarce

Delphi programming makes way too easy writing messy code, with iron-clad coupling between interface code and business rules

That's a big point against Delphi

[Javier Tarí 23]

Funny enough, LiveBindings seem to fit MVVM or just MVx

We didn't had it before, and they seem overkill just to avoid having DBaware components

[Bill Meyer 337]

21 minutes ago, Javier Tarí said:

Delphi programming makes way too easy writing messy code, with iron-clad coupling between interface code and business rules

That's a big point against Delphi

You can write bad code in any language. It's a poor workman who blames his tools. Delphi is not perfect, and certainly we battle defects in the IDE, but failure to design is a plan for failure in any language.

[Dalija Prasnikar 1396]

1 minute ago, Bill Meyer said:

You can write bad code in any language. It's a poor workman who blames his tools. Delphi is not perfect, and certainly we battle defects in the IDE, but failure to design is a plan for failure in any language.

I literally just started typing same sentence.

 

Delphi devs always complain all logic is dumped in form (event handlers), Android devs always complain all logic is dumped in Activity (Delphi form equivalent), iOs devs always complain all logic is dumped in ViewController (again Delphi form equivalent)...

[Bill Meyer 337]

9 minutes ago, Dalija Prasnikar said:

Delphi devs always complain all logic is dumped in form (event handlers), Android devs always complain all logic is dumped in Activity (Delphi form equivalent), iOs devs always complain all logic is dumped in ViewController (again Delphi form equivalent)...

Ah, but the "dumping" is inevitably triggered by a thoughtless coder. I have never seen Delphi insert an event handler without human action. 😉

[Mahdi Safsafi 225]

22 minutes ago, Dalija Prasnikar said:

I literally just started typing same sentence.

 

Delphi devs always complain all logic is dumped in form (event handlers), Android devs always complain all logic is dumped in Activity (Delphi form equivalent), iOs devs always complain all logic is dumped in ViewController (again Delphi form equivalent)...

That reminded me about a nice quote :

Quote

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” ― Bjarne Stroustrup.

 

[Darian Miller 361]

There are plenty of historical examples of Venture Capital/Private Equity takeovers in the software industry.  I would assume five main reasons an investment company buys a software company:

 

#1: Expand an under-funded company to get exponential growth.  (Pour cash in to reap future rewards at a high return.)

#2: Replace key management to yield better results with the same base.  (Also seen as 'take it to the next level' as the original owner is incapable.)

#3: Merge existing companies to scale out / share similar resources to yield a higher combined bottom line.  (one HR group handling multiple companies, joint purchasing power to reduce costs...)

#4: Buy and keep it afloat with 'streamlined operations'.  (basically kill as much payroll and overhead as possible to keep it running and pocket the monthly recurring revenue at a much higher return due to the cost cutting.)

#5: Merge technology from multiple companies to provide a new industry-changing offering.  (Assumes greater worth together than apart.  Cox/Dealer Track, Vista/DealerSocket are two large software company examples in the auto industry.)

 

Which of the 5 does Embarcadero best fall into since Idera purchased them in fourth quarter 2015?  Idera itself was purchased by private equity in 2014.  And another PE firm took over in first quarter of 2017.  Since then, they have went on a bit of a purchasing spree:  Sencha, AquaFold, Ranorex, Whole Tomato, Froala, Lansa, Webyog, Travis CI, Fusion Charts...

 

We are seeing a tiny benefit with the ancient customer portal being partially redone in Sencha.  But it's a project taking many months with no end in sight with very few progress reports (so it seems to actually be a 'would appear cool to dogfood our own tools' type project with no real financial support.)  We do see AquaFold now included in the Architect Edition...which seems to be a much better option than the previous offering from Idera.  

 

But look at what was purchased, including RAD Studio, and consider possible reasons for these purchases.  They could be combining resources of all of these companies...something they wouldn't really announce and we wouldn't neccessarily see.  They do not appear to be plowing additional cash into any of these companies to accelerate growth.  So unless they have some master plan on providing an industry-changing/Visual Studio Killer project that integrates much of this technology, the general trend of each of these seems to be #4.  But we really don't have any insight into their grand strategy so this is all speculation.  We do have the knowledge of the previous cuts in their R&D staff with acknowledgement that they are using more lower-cost contractors instead (also easily seen in some of the new code being generated.)  On the other hand, they currently state that they "invest nearly 2x the industry average in R&D as a percentage of sales"  

 

All I hope for is that Delphi continues as long as possible.  I don't expect some magic re-awakening where Delphi takes a significant market share.  I expect it to be hard to kill as there is just so much code out there.  I also expect to see some eventual growth given all the time wasted on other new technology that needs rewritten every 9-12 months.  

 

I also expect some sort of patch/update for 10.4 very soon.  I was a 10.4 fan-boy extreme but I've turned off the LSP-based Code Insight as it's just often annoyingly wrong.  There were 85 days between 10.3 and 10.3.1 with 3 patches in between.  We're at 50 days since release of 10.4 with one minor installer patch.  I hope it's not 30+ more days before some of these major problems in 10.4 are addressed.  

 

[Bill Meyer 337]

On 8/29/2019 at 3:56 AM, Stefan Glienke said:

IMO not - the beauty of MVVM comes from things that I have not seen yet seen achieved in Delphi.

It requires special support for every existing control by either subclassing or other ways, CoC and existing data binding solutions are very brittle and easily break when renaming things, functional approaches like done in ReactiveUI are almost impossible or create clunky and bloated code.

 

The problem of "special support for every single control" will not be easily remedied. I doubt it will be addressed at all.

[Anders Melander 1783]

3 hours ago, Javier Tarí said:

It doesn't matter if you like MVx or not, because with Delphi you can not use ANY of the MVx patterns

That's just nonsense. I've written plenty of applications in Delphi that applied the MVC or MVP patterns.

True, there's no wizard that can, clickety-click, write your template code for you, but it's really not that hard to do yourself once you've decided how to apply the pattern.

 

It makes no sense to insist that one tool should be good for all problems or that Delphi should support all patterns. There are patterns that work well in Delphi but which doesn't fit for example JavaScript. That doesn't mean there's something wrong with JS. It just means you need to use a different pattern.