It’s been a while since the last road map.
Until the powers that be provide us a new one – what feature(s) would you like to see in the next Delphi city?
Some of my whimsical desires include…
– More fixes for known issues
– Proper High DPI management built into VCL (multi DPI image lists, etc) and a proper overhaul for the IDE to rid it of scaling issues
– RTL performance improvements for generics and multithreaded memory management
– A default out-of-the box cross-platform exception stack tracer with API for plugging in enhanced custom stack tracers, information providers and logging mechanisms
– Code generation improvements utilising more modern CPU features
– Beacon/IoT support for VCL/Windows platform
Who installs a 32-bit OS on their development workstation these days? Why run a 32-bit IDE on a 64-bit OS, if you can have a 64-bit IDE? Seattle still only uses between 1/8 and 1/10 of my available memory.
+Lars You also fall into the trap of asking for implementation rather than functionality. Almost every single request for 64 bit IDE is of that nature.
David Heffernan With the implementation comes the functionality… But you seem to be missing that point
David Heffernan That’s no trap, but evolution.
Lars Fosdal Nobody here seems to understand me. Never mind.
David Heffernan – It appears you think it is not worth the effort, as the memory issues we have can be solved in 32-bit for now. This is mostly true, but in the grapevine there are mumblings about compilation of very large projects (1M+ lines) slowing to a crawl in #10Seattle . Also – if memory is not a limited resource, the IDE can be more liberal with internal data structures and caching and as such – in theory – improve performance. Again – not revolutionary, but evolutionary.
The current 32-bit IDE/Compiler appear to be locked to using one core, and really doesn’t utilize our powerful CPUs.Perhaps this can be remedied in 32-bit, but more threads = more memory requirements. Personally, I would love a better compiler, but we know that the LLVM compiler introduces a performance penalty – which in theory could be alleviated by background compilation and linking.
I do not know if there is a practical limit to the number of threads – but there seems to be a limit under 32-bit (which does not exist in 64-bit) since WOW64 allocates an extra 512K 64-bit stack per thread. https://msdn.microsoft.com/en-us/library/windows/desktop/aa384219(v=vs.85).aspx
Lars Fosdal No, I’ve never said that it’s not worth the effort. Let’s see if I can state my point one more time so that people can understand it.
Do I care how my tools are implemented? No.
Do I care if my tools work? Yes.
If my tools don’t work well, do I want them improved? Yes.
So, rather than asking for a 64 bit IDE, what I think people are really asking for is an IDE that is more robust. If the best way to achieve that is to switch to a 64 bit process, so be it. But for its own sake, a 64 bit IDE has absolutely no value to me over a 32 bit IDE.
I don’t think anyone anyone in the thread would ask for a move to 64-bit, if they didn’t think it would add value – or make it possible to add value – beyond just “bittedness” and more memory. We have received a 32-bit version that is more robust – stability-wise, but it has not improved when it comes to being future-robust.
If time and effort was not an issue – they should ideally be dogfooding a cross platform IDE. I bet that would do wonders for FireMonkey, but it would also take a lot of effort.
For me, bittedness is just the start. That equates to more memory available to the process. This equates to big and better plug-ins, which means a better IDE environment, which means more enjoyable programming/being more productive…
What is the equation: Speed, Correctness, and Memory – pick any two.
It seems that I cannot make my point clearly. Never mind.
David Heffernan What is your problem? As far as I can see, you have singled out my 64 bit IDE suggestion, while others have suggests that would fit the same category which you have left without a comment.
I have tried over and over to explain why I think a 64 bit IDE would be a good thing but you have not acknowledged them in any manner, yet I have acknowledge your perspective on the matter, even if I think it is out of place in the context of the question that was put forward.
So I will ask again, what is your problem?
Nicholas Ring I’ve explained it many times now. I’m not going to repeat myself again.
David Heffernan I raised a number of points in my last comment and yet you barely addressed one of them. If that is the future of things to come, please do not comment.
Nicholas Ring I don’t agree with that statement at all.
David Heffernan And now I have to ask why… Please just go away. You are being childish now.
Nicholas Ring It’s not appropriate to insult people and be abusive. Please refrain.
David Heffernan But being childish is ok? While calling you childish might be considered an insult, it was not abusive. If I was going to be abusive to you, you would know it. 😛
Now, please go away.
+Nicholas Your conduct is out of order.
David Heffernan Flag me then 🙂 Bye
It looks like that a person in this thread has pushed me to my limits, all because they couldn’t explain themselves.
I do apologise to all in this thread for my last few comments and I will try to refrain from letting idiots get the better of me in the future.
FWIW, Visual Studio is 32bit. They do however have a 64bit version of their C++ compiler, which is indeed needed in some cases as the 32bit compiler can run out of address space compiling some projects.
Loading up a multi-project solution with roughly 600-800kloc of C++ code, opening dozens of files across multiple projects VS2013 itself consumes about 140MB memory. That’s with Qt though, so no form designer in VS as such, just code.
Building one of the projects in release mode takes roughly 1-2 GB of memory, but the build tools are run as separate processes.
However, before they rewrote their IntelliSense “engine” (their version of Code Insight), IntelliSense would frequently stop working on this solution due to running out of address space…
So, to sum it all up… Can a 32bit IDE be effective and robust? I’d say VS tells us that yes it can. However there’s no denying that some things are easier to solve, or will be much faster, by going 64bit.
That said, 32bit or 64bit IDE is an implementation detail. I agree with David Heffernan that it’s better to focus on the end goals rather than on the implementation details.
However I also agree with Nicholas Ring that a 64bit IDE will most likely open up some doors that we don’t even know about yet.
Just 5 cents: When someone appears to not understand your sentiment, it’s not necessarily the receiving end that is the problem. The challenge with all internet discussion is reaching across – and expressing oneself in such a way that the message is clear. Cultural, linguistic and experience/educational gaps are as much of a challenge for the writer, as they are for the reader. Adapt and overcome, please?
+Lars I don’t understand that comment, and I also don’t understand why it seems to be permissible to insult others here.
I ask myself that very same question every day. Passive aggressiveness is still aggressiveness.
Lars Fosdal I don’t see any passive aggressiveness. So it’s fine to be insulting and abusive here, and to call people names?
Surely people can express different views and opinions without resorting to that?
David Heffernan If there was name calling and grave insults, I would ask people to tone it down. When there is disagreement and heated debate – and the opponents clearly are talking past each other – I’d first ask them to cool down, then ask them to explain more clearly. Then again, I’d expect most grown men to be able to handle being called childish, or otherwise be directly or indirectly implied to be lacking in cognitive faculties without getting all riled up.
This seems to be the status:- You say it doesn’t matter if the IDE is 32- or 64-bit as long as it meets your development requirements, and you say that moving to a 64-bit IDE for the sake of 64-bitness is unnecessary.
“But my argument is all about the principle. On the premise that a 32 bit IDE works as well as. 64 bit IDE in all regards, surely you would not want Emba to spend their resources on a 64 bit IDE.”
“So, rather than asking for a 64 bit IDE, what I think people are really asking for is an IDE that is more robust. If the best way to achieve that is to switch to a 64 bit process, so be it. But for its own sake, a 64 bit IDE has absolutely no value to me over a 32 bit IDE.”
Some of our comments say that we believe moving to a 64-bit environment would be beneficial (and name some reasons), which you effectively dismiss as a valid argument, and then comment about making a conceptual point, that we don’t understand, that you cannot make your point clearly, that you already have explained, and that you won’t do it again – and for Nicholas Ring you did so without addressing his points.
I guess he got a bit frustrated, but I don’t need to make excuses for him as he is perfectly capable of expressing himself clearly. I’ll stop commenting the person to person relationships here. You two sort it out.
As for 64-bit or not. I am for, not for the sake of it, but because I think it is a necessary move.
Lars Fosdal Well, I don’t think it’s acceptable to call somebody else here an “idiot”. You seem to think that it’s fine to do that. I disagree very strongly with you.
Lars Fosdal As for the second part of that comment, I can’t see any contradiction in my arguments. Early in the thread, and from multiple people, I’ve seen a plain request for a 64 bit IDE. My point was, and always has been, that a desire for a 64 bit IDE should be driven by the benefits that brings. That was the point that I was arguing.
To me it seems quite simple. If the best way to implement a desirable feature is to move to a 64 bit IDE, and if the cost of doing so is outweighted by the benefit to the users, then let’s have a 64 bit IDE. If it’s cheaper to implement the desirable features in the existing 32 bit IDE, then leave it as 32 bit.
And my final point is that I believe that Embarcadero are best placed to evaluate these trade offs. So I feel that it is most productive for users to request functionality. Or to explain the problems that they face with the product, and ask Embarcadero to consider ways to address those problems. I do feel that the developer of a product is generally in the best position to determine how best to implement new functionality.
David Heffernan A point that noone disagrees with, as far as I can tell. So… why are we arguing?
David Heffernan I didn’t not call anyone here an idiot. I said (copy and paste):
“I do apologise to all in this thread for my last few comments and I will try to refrain from letting idiots get the better of me in the future.”
If you took this to be directed to person(s) here, then I do apologise for any misinterpretation that occurred.
Ref “idiot”. I missed that comment. I don’t think it is appropriate, but as insults go – I have been called a lot worse.
Linux console apps & services