So far, they're adding specific APIs that have been pointed out as missing. Most recently, https://quality.embarcadero.com/browse/RSP-11432 Do you have some specific APIs in mind, Asbjørn Heid?
I see there are 5 listed, we'd definitely have a look. There is another 20+ is a different list we are considering. This isn't something generally done in update, but in a new release. If others have suggestions, they are welcome. If you wonder why we don't take the entire API is this has large areas hardly used (not only from Delphi), and we'd like to focus on core APIs, going beyond an automatic translation with some actual testing....
Javier Hernández There are plenty of newer APIs from those versions of Windows. Just not all. It would be a huge task to translate them all. And then test them all.
Would you prefer that Embarcadero spent significant resources on that rather than more mainstream tasks? Do you appreciate at all the fact that development resources are finite and must be allocated according to priority?
Javier Hernández You wrote: "There are new apis from 7, 8.1 and even 10. I don't see those in Delphi 10." Identify those that are missing and that you need.
Javier Hernández I could not disagree more vehemently. Embarcadero are doing nothing out of the ordinary here. Your expectations are utterly unrealistic. You'd prefer Embarcadero to devote resources to translating the entire Windows SDK no matter what. You believe that is the most important task for Embarcadero? You'd rather that Emabarcadero did that instead of, say, working on the compiler to output more performant code?
If you don't understand that development resources have to be prioritised then you are seriously delusional.
Javier Hernández The Sync items link looks like mostly compiler intrinsics, such as those covered in System.Syncobjs.TInterlocked? There are some API calls that look useful, so you should post a QP with a request for these APIs/Structures. Being specific and explain your need helps a lot for priority. Make the QP and share it and remind us why, and I guess those of us that see the need will vote it up too.
Lars Fosdal wrote "Identify those that are missing and that you need". Windows Services API's would be a nice start Lars (currently very backward). If anyone's interested, search for DDService on line (if it's still around) - will give you an idea what I'm referring to.
Personally I'd prioritise updating the compiler to fully support the extensions to 1990s COM used by the WinRT API. A full set of API translations is a nice to have, but far more important is being able to write them ourselves if necessary.
This thread has turned into a large debate, no intention to replying or commenting on each point (as I'd better focus on the product ;-) .., but a couple of things are worth.
Yes, we do have finite resources. As a company, we can push in multiple directions, trying to keep the product balanced. Do we need to expose more native APIs (on Windows and all other platforms we support)? This is clearly a yes. But we need to focus on relevant ones. Suggestions a welcome.
We also need to make it possible for developers to use all APIs -- hence the work on WInRT in 10 Seattle was quite critical. Developers can write their own interfaces and share them (remember project JEDI?). Same for mobile.
Recently, we have also invested in tools to automate translation. We released on for Java to Object Pascal. This tools that we can use internally and our customers can use by themselves, are possibly even more important than the actual translations. In an ideal world, the tool will just consume the headers and generate the Pascal interface. In the real world, you need a developer testing the outcome, experiments with the API, write unit tests and demos, and this takes significant time.
And for compiler improvements in Update 1, a couple of them have been very visible (bug fixes type of improvements)... but you cannot technically change the language in an update or you invalidate all existing DCUs and packages.
David Heffernan "Do you appreciate at all the fact that development resources are finite and must be allocated according to priority?"
You could also argue then that they don't have sufficient resources to produce a competitive product. When I used to work in an industry with a competitor 12 times our size, we made a Herculean effort to go above and beyond what our competitor provided simply because everyone expected us to not be able to compete. If i had to work 60 hour weeks or work through Christmas or New Year's Eve (yes I was working midnight December 31, 1999!) I did it because otherwise I know customers would say we were too small to compete. Eventually we managed to steal business from that larger competitor!
I checked out PyWin32, an open source library for an open source language, and the missing API was covered there.
If you're going to be competing against free you can't actually offer less than what free offers. That ought to be your measuring stick: offer no less than any other mainstream language offers in terms of API.
David Heffernan "You believe that is the most important task for Embarcadero? You'd rather that Emabarcadero did that instead of, say, working on the compiler to output more performant code?
If you don't understand that development resources have to be prioritised then you are seriously delusional."
I think the problem is that they simply don't have enough development resources. An IDE, several compilers, two frameworks, two languages... too much. They either have to bring on board more developers or let something go. Whether that would be turning Delphi into a plugin for VS or IntelliJ or what I don't know.
Joseph Mitzen I don't disagree - some of these APIs should have seen a proper refresh.
However, I see where Idera (I guess we should start using that name) is coming from when it comes to "blanket inclusion" and I do think using the Pareto rule is the better option.
Some of these APIs have seen open source work for Delphi as well - and usually there is nothing that stops us from creating the imports ourselves - just as the Python community have done.
You're a bad man Asbjørn Heid - you've just brought a tear to the eye of a lot of Delphi programmers out there
ReplyDeleteI'm sure there was some cases registered at QC, but I couldn't find any on QP yet, so I made one: https://quality.embarcadero.com/browse/RSP-12982
ReplyDeleteSo far, they're adding specific APIs that have been pointed out as missing. Most recently, https://quality.embarcadero.com/browse/RSP-11432
ReplyDeleteDo you have some specific APIs in mind, Asbjørn Heid?
I see there are 5 listed, we'd definitely have a look. There is another 20+ is a different list we are considering. This isn't something generally done in update, but in a new release. If others have suggestions, they are welcome. If you wonder why we don't take the entire API is this has large areas hardly used (not only from Delphi), and we'd like to focus on core APIs, going beyond an automatic translation with some actual testing....
ReplyDeleteWell, RTM was November 2006, so there's plenty of time left! ;-)
ReplyDeleteJavier Hernández There are plenty of newer APIs from those versions of Windows. Just not all. It would be a huge task to translate them all. And then test them all.
ReplyDeleteWould you prefer that Embarcadero spent significant resources on that rather than more mainstream tasks? Do you appreciate at all the fact that development resources are finite and must be allocated according to priority?
Javier Hernández You wrote: "There are new apis from 7, 8.1 and even 10. I don't see those in Delphi 10."
ReplyDeleteIdentify those that are missing and that you need.
Javier Hernández I could not disagree more vehemently. Embarcadero are doing nothing out of the ordinary here. Your expectations are utterly unrealistic. You'd prefer Embarcadero to devote resources to translating the entire Windows SDK no matter what. You believe that is the most important task for Embarcadero? You'd rather that Emabarcadero did that instead of, say, working on the compiler to output more performant code?
ReplyDeleteIf you don't understand that development resources have to be prioritised then you are seriously delusional.
Javier Hernández Do you, or do you not, recognise that development resources are finite, and must be prioritised?
ReplyDeleteJavier Hernández The Sync items link looks like mostly compiler intrinsics, such as those covered in System.Syncobjs.TInterlocked? There are some API calls that look useful, so you should post a QP with a request for these APIs/Structures. Being specific and explain your need helps a lot for priority.
ReplyDeleteMake the QP and share it and remind us why, and I guess those of us that see the need will vote it up too.
Lars Fosdal wrote "Identify those that are missing and that you need". Windows Services API's would be a nice start Lars (currently very backward). If anyone's interested, search for DDService on line (if it's still around) - will give you an idea what I'm referring to.
ReplyDeleteHow do you eat an elephant?
ReplyDeleteLars Fosdal Javier just swallows it whole in one bite
ReplyDeletePersonally I'd prioritise updating the compiler to fully support the extensions to 1990s COM used by the WinRT API. A full set of API translations is a nice to have, but far more important is being able to write them ourselves if necessary.
ReplyDeleteChris Rolliston Got a link for that? Haven't paid much attention to WinRT.
ReplyDeleteMarco Cantù Two of them are "collections" of a few API calls but yeah.
ReplyDeleteThis thread has turned into a large debate, no intention to replying or commenting on each point (as I'd better focus on the product ;-) .., but a couple of things are worth.
ReplyDeleteYes, we do have finite resources. As a company, we can push in multiple directions, trying to keep the product balanced. Do we need to expose more native APIs (on Windows and all other platforms we support)? This is clearly a yes. But we need to focus on relevant ones. Suggestions a welcome.
We also need to make it possible for developers to use all APIs -- hence the work on WInRT in 10 Seattle was quite critical. Developers can write their own interfaces and share them (remember project JEDI?). Same for mobile.
Recently, we have also invested in tools to automate translation. We released on for Java to Object Pascal. This tools that we can use internally and our customers can use by themselves, are possibly even more important than the actual translations. In an ideal world, the tool will just consume the headers and generate the Pascal interface. In the real world, you need a developer testing the outcome, experiments with the API, write unit tests and demos, and this takes significant time.
And for compiler improvements in Update 1, a couple of them have been very visible (bug fixes type of improvements)... but you cannot technically change the language in an update or you invalidate all existing DCUs and packages.
David Heffernan "Do you appreciate at all the fact that development resources are finite and must be allocated according to priority?"
ReplyDeleteYou could also argue then that they don't have sufficient resources to produce a competitive product. When I used to work in an industry with a competitor 12 times our size, we made a Herculean effort to go above and beyond what our competitor provided simply because everyone expected us to not be able to compete. If i had to work 60 hour weeks or work through Christmas or New Year's Eve (yes I was working midnight December 31, 1999!) I did it because otherwise I know customers would say we were too small to compete. Eventually we managed to steal business from that larger competitor!
Lars Fosdal
ReplyDeleteHere's a good example:
http://rarog-it.blogspot.com/2013/12/delphi-and-missing-windows-api-functions.html
I checked out PyWin32, an open source library for an open source language, and the missing API was covered there.
If you're going to be competing against free you can't actually offer less than what free offers. That ought to be your measuring stick: offer no less than any other mainstream language offers in terms of API.
David Heffernan "You believe that is the most important task for Embarcadero? You'd rather that Emabarcadero did that instead of, say, working on the compiler to output more performant code?
ReplyDeleteIf you don't understand that development resources have to be prioritised then you are seriously delusional."
I think the problem is that they simply don't have enough development resources. An IDE, several compilers, two frameworks, two languages... too much. They either have to bring on board more developers or let something go. Whether that would be turning Delphi into a plugin for VS or IntelliJ or what I don't know.
Joseph Mitzen I don't disagree - some of these APIs should have seen a proper refresh.
ReplyDeleteHowever, I see where Idera (I guess we should start using that name) is coming from when it comes to "blanket inclusion" and I do think using the Pareto rule is the better option.
Some of these APIs have seen open source work for Delphi as well - and usually there is nothing that stops us from creating the imports ourselves - just as the Python community have done.
Yes, think of PyWin32 as being analagous to JEDI
ReplyDelete