I have elevated this comment from David I in a previous post, to the status of a post in it’s own right, in order that it might elicit the suggestions from readers/commenters that David seeks. I have adjusted the opening wording to make more sense in the context of a post, but give full credit to David I for kicking this off.
I shall be responding myself shortly, but in the meantime, here’s the chance for others to contribute to an interim, ad-hoc “Delphi Survey” of sorts. ๐
David I thought it would be great to have a post with product feature suggestions for Marco to focus on. He suspected that we might see a few of the following (in no particular order):
- Delphi ORM
- Additional features for DataSnap: security, load balancing, fail over
- Un-dockable form designer for VCL and FMX
- Improved code optimization
- Native control support for iOS/Android/etc
- MVC for Web App Development
- Dependency Injection Framework
- BiDi: better support in VCL, add support in FMX
- Accesssibility support in FMX
- IDE options, packages migration when installing new version
- Remove Package/Component compiler version dependencies
- Parallel / Concurrency support
- Garbage Collection
On your marks, get set…. GO!
[With apologies to those who already responses inline to the comment on the previous post – would you mind resubmitting to this one to kick things off ? Again ? :)]
How about fixing bugs? Linux support? I don’t think in care anymore
As lazarus/fpc is working pretty well now.
Suggestion – run this under something much more maintainable over the long run. One has been up for awhile now: http://delphi.uservoice.com/forums/4432-general
Less RTTI, more compile-time compiler smarts. A native compiler won’t ever match a managed framework on RTTI. If you make a built-in Delphi ORM, don’t base it on RTTI. And also take RTTI out of the rtl for records at the minimum, that’s just an unnecessary performance loss.
+1000
Don’t use so much string based references (LiveBindings, FMX styles). If you have to refactor your code, it becomes a nightmare!!! It would be great if the compiler will report such errors, like reference is missing. If you are a small company you don’t have the luxery to write so much Unit Tests.
All demos are showing how easy it is to create new code, but not how hard it will be to maintain. Maintaining existing code is much harder and frustrating than create new code.
Indeed. Compiler support means compile-time error detection, refactoring support, etc. Runtime means manual testing and manual migration. Live Bindings from this POV are “write only”, because they break so easily.
100000 + , I use c# and XAML as my main development, even in visual studio using reflection in XAML sucks, please develop your own language to present FMX file and reduce(Remove) the usage of RTTI, it will gives as tiny optimized EXEs , performance will be super fast and refactoring will be super easy.
Please no garbage collection, Even Apple and Microsoft are moving away from it in favour of reference counted “Automatic Garbage Collection (ARC)”: http://www.virtualdub.org/blog/pivot/entry.php?id=360
ARC stands for “Automatic Reference Counting”
Yeah, I know, was just quoting the article I referenced.
The thing that could make me want to upgrade my Delphi 2010 to a new version would be full Android support (ie. a visual designer like we’re used to; no need to separately install the Android SDK – if it’s needed by the environment, it should be installed as part of the environment’s setup, full integrated debugging support, etc.)
Other than that, a better support for hobby programmers like myself. It’s getting mighty expensive to keep upgrading to new versions, when I don’t get any income for my troubles. A hobbyist version (at the Professional edition level, ie. incl. source and the ability to make and install components) for non-commercial developments would be greatly appreciated.
Personally, I don’t need all the fancy database support, so that can (for my sake) be relegated to a business edition, but others might have different opinions.
+10000 BiDi: better support in VCL, add support in FMX
I’ll try to post my wishlist ordered by priority.
1. Package market in the IDE, something similar as NuGet. And also packages must be installed/configured separately for projects. This would greatly improve projects portability.
2. Garbage Collection. I’m sick and tired of freeing things that should be freed automatically. It would also help to write cleaner code.
3. Fix bugs. Especially in the rtti, generics.
4. Delphi ORM. Or at least make official persistence attributes like Java has (http://docs.oracle.com/javaee/5/api/javax/persistence/package-summary.html).
5. MVC for Every App Development
6. Improved code optimization
7. Lambda expressions. Current anonymous methods are too heavy.
8. Parallel / Concurrency support. Built in futures, parallel loops, attributes for methods (async, threadsafe, etc.)
9. Dependency Injection Framework. Or integrate Spring for Delphi.
10. Optimize size of compiled binaries, especially when generics are used.
i agree with point 1, Embarcadero already did it with apps “appwave”, what about “ComponentWave” or “ComponenkMonkey” what ever they like but its a must i think. Delphi ORM, revive BOLD or reinvent InstantObjects together with DataSnap, what about “DataObjectsSnap”. MVC equals to LiveBindings, i think we have to give credit about this feature. Spring for Delphi it will be a Delphi on Rails or something like that. Go
LiveBindings is MVC done wrong, ie. through RTTI. This could be done 100% at compile time, with compiler support, validation, refactoring, etc. leapfrog the competition’s card houses of runtime-only MVC on this.
They should implement property references. IMO that would solve almost any problem any binding solution currently has.
You may have noticed appwave is a failure. You just want that to get a cheap Delphi to stuff with free components.
Your right, but the technology is fine, it could be apply in another scenario, Don’t you think so?
I am waiting for the new Next Generation Delphi compiler language…
<>
I would upgrade more often if this one alone was solved. At least let every other version be non-breaking.
11: Remove Package/Component compiler version dependencies
Sorry the site dropped the text between the .
Brackets
11) Should be as simple as having to cope with JARs and .net assemblies. Fixing the runtime and class libraries provided by EMB. You described a good solution on stack overflow …
What do you mean with point “11”?
The way I understand it you want to be able to use packages compiled by an older compiler with a newer one. Let me put this short: this isn’t a good idea. This would mean that you (as in “as a compiler/RTL developer”) either can’t improve things regarding package support from one compiler version to the next or you’d need to have a compatibility layer (which can become quite complex the higher the compiler version gets). An example base on my work on FPC: specialization of generics were originally mangled as “SomeUnit_$$_TSomeGeneric$1$Type1$Type2”, but as the mangled identifiers are restricted to 255 chars I changed the “Type1$Type2” part to a CRC, so the type name now becomes: “SomeUnit_$$_TSomeGeneric$1$crc12345678”. If this type is located in a package I would need to make sure that I can resolve the correct type for older packages (with the old naming scheme) as well. This get’s nearly impossible if the package is part of the import section of the executable (thus not loaded dynamically).
Should we ever have dynamic packages support in FPC we might even need to go as far as making packages dependant on the version of the PPU (which changes whenever a structural change to the PPU format is made – the PPU is FPC’s equivalent ot Delphi’s DCU) as otherwise this would become a hell to support.
Regards,
Sven
Oh, come on. It can’t be all that difficult. Just look at .NET assemblies. If Microsoft can get it right, how hard can it be? ๐
.NET assemblies are more akin to .DLL files – not packages.
Delphi can easily cope with various versions of .DLL files.
Why do you say that? From my perspective, the essential difference between a DLL and a package is that a BPL provides enough metadata to be used transparently as Delphi code in another module that uses the package.
For example, if I declare a class in a DLL, and then I use that DLL in a Delphi project, I can’t use that class in my code. I can’t instantiate objects of that type, I can’t create new classes that inherit from it, etc. Any interaction with that class has to be marshaled through a C interface. But if I declare a class in a BPL, it “just works.”
.NET assemblies work like BPLs, not DLLs, in this crucial aspect, and they’re still able to make versioning compatibility work.
The essential difference is that a BPL contains code that is not behind a language agnostic – let alone compiler version agnostic – API, but has an API that is defined by a specific compiler, and potentially varying between different versions of that compiler. This is a disadvantage because it makes the packages specific to a particular version of the compiler, but it is an advantage because it enables the compiler to make assumptions that may be necessary, or at least useful, in simplifying the way that those DLL’s are worked with.
e.g. if it can be sure that the code on the other side of the API has the same ideas about the internal layout of it’s data structures then there is no need to have a mechanism – with potential overhead – for negotiating things that rely on such information.
How do you enable a D2009 compiled application with one set of ideas about the String type, to successfully interoperate with code in a pre-D2009 package with a completely different idea of what a String is ? Not just that one is ANSI and one is Unicode, but that each has different amounts of ‘payload’ information “hidden” at negative offsets.
As you say, a .NET assembly is essentially a package, but my guess is that the .NET team (and quite possibly Anders himself specifically) made sure that the external presentation of an assemblies internals avoided the pitfalls that packages suffer from in this area.
Packages had perhaps shown the advantages to be gained, but also taught a few lessons to be avoided.
1. Improve quality.
2. Keep developing the VCL.
I suggest him to have a look at http://qc.embarcadero.com/wc/qcmain.aspx?p=10 – this is the Delphi site on QC, and on the top there is a list of most-rated QC entries. There e.g. is a QC entry “Add undo/redo in form designer” which is there since Delphi 6 (!) and which has almost 500 votes there. So why not get the top 10 of these entries done now? Would be a very positive signal to all those who have voted these points up.
I’ll use a more constructive forum to make suggestions to Embarcadero.
Well, it’s constructive enough for David I. Perhaps you should set aside your prejudices and our differences and engage ? Just a thought. ๐
Don’t worry. I intend to engage planty.
Yes, we have many ways for you to tell us what you need/want Marco to focus on for future Delphi releases. And, this is just one of the ways – engaging customers on blogs. You can also contact Marco directly, take the annual Delphi product survey, put feature requests in QC, take part in online webinars, etc. All ways are good.
Really? What’s the point? We’ve been reporting Delphi bugs for nearly twenty years and nothing appears to ever be done. Even if something is done, it’s not fixed until the next version, not made available to existing customers. There’s an ever-increasing price which includes NO support for the average customer.
The standard response to an error report appears to be either “Need more information” or “Can’t reproduce.” Take my report QC110143 for instance. I’ve delivered a project that shows the problem, step by step, and the workaround. The original submission failed apparently because I used a web browser not the Delphi QC client. MUST use the QC client to ADD a report after the original failed attachment – no facility on the browser version. THEN I get the complaint that the project (A button + memo + created components) is too complicated. Had I received such a report, I’d be ecstatic.
Is the idea to raise such a barrier to reports that people stop submitting them and the claim can then be made “We’ve had no problems reported?” Even if you spend the time making the effort to create a demo project, it seems more important to record that fact that this is a repeat of an earlier report than it is to actually FIX the problem.
It’s all very well spruiking a halving of compile times for instance, as was done for XE2. The extra minute gained per day pales into insignificance when compared to the HOURS spent chasing bugs in supplied components that don’t work properly and never have.
More hours are wasted trying to find documentation. Simple things like a list of the clxxxx colour constants.Why are constant definitions scattered all over the shop rather than in a single library? I suspect that would make it easier to document, so maybe that’s why it’s not been done.
The VCL SHOULD be a showcase for techniques – a source of inspiration for the construction of components. It is the complete opposite – uncommented and full of obscure methods with illogical names. Why expose obscure methods like GetHashCode but hide essential elements – THEN document the gymnastics required to access the ‘private’ colour property? Why refresh, repaint AND invalidate?
And no, Firemonkey isn’t a solution as far as I’m concerned. It’s too unstable a platform at present, and clearly aimed at the cross-platform market which I’m not considering.
I believe that Embarcadero should deal with the twenty years of neglect rather than trying to add more flashy features. Get the fundamentals right first, otherwise you’re going to be permanently occupied fighting fires.
It’s also worth remembering that an “IT Manager” in small to medium enterprise – the one that signs off on the orders – is likely to be an IT Luddite who classes himself as an red-hot programmer because he’s managed to create a spreadsheet. These people are desperate to avoid technical reality. All they really know about IT is “Microsoft” and will grab on to ANY negative comment about other suppliers as an excuse to override technical opinion.
Well said. And kuddoz for writing it up. Admit I couldn’t be bothered and your first paragraph explains why perfectly.
๐ non-tech – a lot more constructive indeed ๐
I have some suggestions that perhaps aren’t directly under Marco’s purview, but are a big factor in the Delphi UX, so I’ll mix-in those here as well …
1) Get a grip on QC. The idea of QC is great, but the implementation and the sense of relevance is lacking.
2) +1,000,000 for migrating IDE settings when installing a new version of the IDE on a system with existing previous versions. Ideally, centralise some of these settings as far as possible (Editor settings in particular). Obviously this cannot be done retrospectively, but going forward…
3) +1,000,000 for NOT dwelling on things that are better addressed by 3rd parties. ORM in particular – no one ORM can suit all.
4) -1 bn for garbage collection. We already have 2 garbage collector – one at the keyboard and on in the form of reference counting (as others have pointed out, something that other managed runtimes are actually moving toward!)
5) Every new language feature should be tested for being in the “Spirit of Delphi” before being implemented. New “Pascal-like” syntax is preferable over “Existing syntax bent and twisted to fit a new feature”.
6) A “Standard” Edition to fit between “Starter” and “Pro”.
7) Provide the VCL source in Starter.
8) A free/community edition. Use it to replace Starter if necessary.
I’m right with you regarding QC.
There is a nasty debugger issue in XE2 and it appears to be still there in XE3. It’s a bad kind of “velocity”. Product management has to give the team time to FIX the core up. Hope Marco takes quality to heart.
W
“8) A free/community edition. Use it to replace Starter if necessary.”
IMO Most important point…
Stop delivering version to people who will never pay for Delphi. Concentrate efforts on high-level SKUs for people who actually pay Delphi, and won’t mind paying 2-3K for a superior tool. There were money is made.
Is not about the money, is about to give the oportunity to students or hobbiest to explore and eventually explode the pay tools, is about marketing.
5) +1000 Keep the spirit of delphi alive in new delphi features. E.g. the TPlatformService.Current.SupportsPlatformService(…) is not nice. You cannot write a IF statemant in one single line, using so long names.
Keep maintainance in focus!!!!
I completely agree regarding (8) ๐
Regards,
Sven
People for hobbyists, take a look at lazarus, if borcadera
Is to stupid to make a express version or whatever screw them,
Start using lazarus and fpc, it works great for most things.
Syntax is almost. Identical and in fpc mode you get some
Nice things like being able to use strings in a case
Dependency Injection Framework, MVC patters for VCL Forms apps and iOS support is what I need.
2) definitely
13) ARC
What if embarcadero sells Delphi with something like a Delphi Foundation, instead of Professional, Enterprise, Architect, etc. Actually is only profesional and enterprise, since architect and ultimate are external aplications bundle. After buying or upgrading your Delphi foundation you can select kits of special components. (FMX, DataSnap, WebSnap, etc.). What if Embarcadero substract the special components and sell them apart in the “ComponentWave” like platform, and custumers can select their components. Like raize or TMS or Devexpress or etc. What do you think Marco? think about it.
1. Fix bugs in VCL but especially FMX
2, Develop and improve FMX
3. Improve floating point code generation (possibly already under dev)
4. Improve penetration of Delphi in the young programmer community
I’ve red a lot about freepascal and lazarus, if i were new maybe i’ll give them a chance but they still far behind delphi RAD aproach. oxygen.NET is more impresive.
It’s not that behind and it’s rad approach is
Pretty much the same. Also can you build Linux apps
With Delphi? Didn’t think so… I have been using Delphi
Since 1995 and I built a ton of apps this year with lazarus
So you don’t have to be new to use it.
Good point, If i’ll start a new project it will be ok, but translating my old apps is a nightmare, i don’t want to spend that much time.
If it works for you, keep it that way. Greetings
If you stayed away from 3rd party stuff like dev express
It’s really not that bad, there are things like virtual tree view that work
On lazarus great and there is a built in conversion tool that
Works pretty good at converting units and dfms to lazarus.
Maybe you should take a first or second look at lazarus.
sorry for my English.
If Delphi will take good things from C with Delphi-fast compilation it’s Perfect for me. C is very flexible, Delphi is very fast and offers great GUI building tool.
* Some more polishing and Delphi imho will be much better for developer (me) than Qt (hell slow compilation). FMX sounds good.
* LLVM shoud solve much problems with optimizations. I hope it will not make compiling too slow.
* bitpacked records
did you try A := ((B shr 13) shl 5) many times in a unit.
while it could just be A := REC.Field1 (C syntax for it is very simple, while FPC a bit redundant)
* bitpacked arrays
* binary numbers %1010101010
* exporting symbols
in Delphi you can’t export initialized constant or variable. You can’t also import it. So I write plugins dependent on this in C or FPC.
* imho documenting (tags) shouldn’t be in source code. It makes code unreadable. FPDOC style from FPC seems more elegant. Docs are stored in separate xml and just bound to source code locations.
* class libraries
Rich class libraries are very important. e.g. If you need to download file from url, hey it’s already in library; just call few functions.
If you need TMap, TSet, TLinkedList you shouldn’t invent your own implementations or seek googlecode, hey, it’s in class library. Thanks EMB.
If class library will be built C# – like, it’s ok. Even simpler to migrate.
* free Delphi Express is good idea I think
those who pirate will still pirate, even if you put kernel-mode protection. those who buy it for business will buy it. btw pirates get Ultimate edition of Delphi anyway, legal users get troubles(imo)
offtopic:Some gamers may remember those starforce games when you can’t start your game due to license failure, while guys with cracked exe play smoothly. the only software is never cracked is no one need
I do not criticize EMB, just a bit tired of writing pascal code, when I see I could spend less time developing in C (though more time compiling that stuff)
I really grateful EMB does work on Delphi and don’t let it die.
Maybe I’m wrong somewhere feel free to correct me.
You are right about piracy.
I read somewhere that just by replacing “borlndmm.dll” with a cracked version speeds up Delphi.
Garbage collector? YUCK.
1. Fix compiler bugs.
2. Make editor and IDE not crash or freeze for 30 seconds on large units.
3. Make it truly possible to turn of code-completion so there are NEVER any parse-related freeze-ups, including simple things like the Edit menu, which freezes every time I drop it down, for up to 30 seconds.
Warren
What tops my company’s agenda….
1) web apps using pure object pascal ( eg unigui, radeus)
2) native android dev using pure obj pascal ( since android has overtaken apple devices )
+1
I am thinking like Nirav.
UNIGUI is great but officially supported web development is necessary.
If EMB publish browser add-ons like Spoon (spoon.net) for all browsers,
or some technics like Google’s Native Client to use our apps on the web,
it will be a next revolution of programming.
If we use firemonkey on our web developments; it would be wonderful.
+1
I am thinking like Nirav.
UNIGUI is great but officially supported web development is necessary.
If EMB publish browser add-ons like Spoon (spoon.net) for all browsers,
or some technics like Googleโs Native Client to use our apps on the web,
it will be a next revolution of programming.
If we use firemonkey on our web developments; it would be wonderful.
It is high time t take a look at already included parts of Delphi:
o Update the WebService handling to what is current today.
o Update the XML handling to what is current today.
Also make a deal with some author and produce documentation and books.
o A good example how bad it can be, is the DataSnap handling. It is hard to fnd any documenation for more than the “hello world” type of application.
o It is not enough to have a technical good product with a F1-help documentation. There must be some way to read in how to do things in a more ordered fashion. My hope is tha the “Delphi XE2 Foundation” book indicate that there is an interest from the customers to read information about the product.
What I want for Delphi in the future: Make sure the language will become a top language so it will survive in the long run!
This can be done with new technology, language enhancements, pricing, partial open sourcing, working together with other compilers, extra features / tooling / new compiler core / interoperability with other tools/companies.
And the second thing is: make sure Delphi keeps its most values asset: a very dedicated group of developers that wish to keep Delphi and move it forward. Last years there have been to many occasions where people (who advocate the product for free) are being offended, alienated etc. So top priority should be: make sure you keep those persons in the loop make them feel listened to (base your product direction on their opinion partially).
Who the hell(sorry for saying) here started to talk about GC, i have never heard anything about GC from EMB, but i think they are going to implement ARC(WOW).
Warren P’s list +
4) fix compiler bugs (important enough to say it twice). I
5) make sure that projects can be easily moved location. No more hardcoding of component paths in the .dprs. and dprojs Like Lazarus make projects have dependencies on components, and auto add component dirs to unit path if a project has a dependency on a component. Should have been done 15 years ago
6) editor autosave by default. Everytime I reinstall delphi and it crashes I lose data before I remember to enable it again. Getting annoying.
7) Don’t try to turn Delphi into Java, .NET, Objective C or whatever is in vogue.
And finally, remember that not all of us chase every IT trends. Make sure there is enough meat to upgrade for the rest of us
Maybe you are happy with this …
http://www.habarisoft.com/habari_webcomponents.html
@Ritsaert Hornstra
I agree whole heartedly. The community is the biggest assett Delphi has. Alienating existing community members who are passionate about Delphi, and speak out, is not the path to gaining new members or retaining existing ones.
My list would be:
1) fix QC
2) fix the bugs reported in QC
3) implement an a la carte pricing model, or at least metrics to determine usage, and drop functionality not used in order to reduce the support burden for EMBT, and reduce the overhead in memory and CPU cycles of the IDE.
4) implement a bug bounty program internally where end users can pay for bug fixes they deem important if EMBT doesn’t, but EMBT needs to allow their engineers to implement and release the fixes (on the developer’s own time if necessary)
5) fix the way developer relations interfaces with the community. It should not be about marketing. It should be about listening to the community and coming up with ways to make the product and community stronger (they go hand in hand).
6) Stop all the bundling (or bungling) marketing and lower the price of the core Delphi product.
7) EMBT needs to stop implementing things that are already present in the community (like ORMs, dependency injection frameworks etc), and do what only they can do; implement an extensible IDE framework with the ability to replace core features like Code Completion (since it doesn’t work very well), and leading edge compilers. Leave the rest up to the community and leverage their results by including them with the IDE install (ie: GExperts, CnPack, Virtual Tree View etc).
Bug fixing should be priority number 1. Fix as many bugs as possible before adding any new features.
Make VCL Delphi compiler version independent.
Unless the IDE becomes uncrashable, turn auto-save ON by default.
Developer time is more expensive than disk space.
64Bit IDE strongly recommended. Next year we are not able to compile our complete project.
No need for a 64 bit IDE. If the 32 bit IDE doesn’t work because it consumes too much memory, fix the 32 bit IDE.
Frankly, I can’t understand why people want to shift Delphi to areas where it can’t never be a good tool. Delphi is a tool/language to develop native compiled applications. No managed code, no web apps. If you need them, there are other, better tools. No one develops web apps in C++. Take the time to learn another language if you needthemt, Emb already made Delphi a Jack of all trades and master of none, and we see what dreadful state the result of it is.
LDS – “No one develops web apps in C++.”
I will have to ask Bjarne Stroustrup and other C++ experts about this statement ๐
Face it: you can’t keep a dedicated group of good developers if you can’t pay them. Very few skilled people work for free. People advocating a free/open source Delphi are just trying to kill it. Software development has a cost, and you have to get the money to pay for it. And I would like to know how many asking for a free Delphi then give away their applications for free as well…
No LDS, the free/cheap (I can’t think of anyone who suggested open source, beyond the VCL that is) is essential to foster the development of new skills.
The average age of attendees at Delphi events is climbing inexorably upwards. You need to bring new people in to keep the community going, otherwise that community just becomes a developer rest home and then eventually a graveyard.
Delphi has an upward hill to climb in gaining mindshare among that new talent, and these days, “free”, or “dirt cheap” is a feature that increasingly has to be included at that crucial beginning stage. No-one is advocating slashing the prices of Enterprise/Architect or even Professional editions, but if you don’t lower the barrier to entry then the price of those editions won’t matter because quite simply no-one will be left who is interested in paying.
“Starter” edition doesn’t cut it. The price is right, but the contents of that box, and the Damoclesian Sword in the license conditions are all wrong.
The people in denial over this are the ones trying to kill Delphi, even though they perhaps don’t even realise it.
i would not give my *applications*, but i participated in FLOSS Jedi and TDbf libraries and made some minor patches to a number of others.
Some suggestions:
1) Get Delphi into the hands of more developers. I have been a Delphi professional for 7 years now, but I don’t have a useable copy of Delphi at home for private projects. That way I will never ever contribute to any open source library…
And no, I’m not going to pay money to be allowed to work for free…
2) Cut down on the warts Delphi has been growing.
(String-mess, RTTI, …). No more Intern driven development (IDD) for the compiler.
3) Finally release the “Delphi 7 Forever” Edition.
4) And the most honest suggestion:
RUN!!!! It’s already too late, but RUN!!!!
Andreas wrote – “I donโt have a useable copy of Delphi at home for private projects”. You can use your Delphi at work and at home, if you are the named user.
This may be permitted in the license agreement, but may be made more difficult in the EMPLOYMENT contract.
It is quite common for an employer in this industry to assert ownership over IP in works created using their resources. So whilst the license may allow someone to install Delphi at home on the back of their employers license, and whilst the employer might be happy to allow this, it is still a problem if the individual is seeking to create independent works that they can freely contribute to the community or profit from directly themselves, rather than just doing the occasional bit of work at home as part of their job.
No David, you can’t. Not unless you want your employer to hold the copyrights to whatever you do in your private projects… I only work on my own projects on my own hardware and using my own licenses. specifically to avoid that. Please bear in mind that employment laws differ from country to country!
Indeed, and even within a given country with the laws that apply, different employers make different provisions within their contracts.
It should also be mentioned that even if an employment contract does not make any specific reference to works created using licenses (or indeed any/other resources) owned by an employer, there remains the possibility of a claim of ownership should it become in the employers interests to assert such a claim. The only situation in which you can feel totally at ease using an employers resources for private works is if you have explicit agreement and written assurance – in the contract or otherwise – that no such claims will arise or be asserted.
I’d like to see generics made more unified and bugs fixed. Sping4D is a pain to use due to all kinds of internal errors. Heavy-weight closures (or they are called lambda’s) are pain to use, comparing with maybe ugly yet practical C++ ones.
I’d like to see packages extended to split units into public and private, so one could easier define API contract. Inability to encapsulate code in BPLs is one of the greatests pro-DLL argument, and mixing DLL+BPL is somehow hard and causes bugs in RTL/VCL
i mean, finding i cannot made Min(v1,v2:T):T and Max(…):T functions over simple number types, cannot make MulAdd(v1,v2,v3:T):T – that is rather limiting. Functional approach works best on most primitive basic data types – and that is exactly where it failes miserably in Delphi.
Just hit the wall again!
We have to interface legacy lowlevel code, using C-strings as flags set.
So some objects have char Flags[10] field and others have char Flags[20].
Operates with strLCat, StrCopy, StrComp and such
It would be nice to make a hi-level wrapper for it, with auto-casts to string and set, with methods like Include, Exclude and Test…
Just a proper thing for extended record!
Type FlagsRec = record
Buffer: array[T] of AnsiChar;
…. methods
end;
…No good. And Delphi has no ISO Pascal templates that could help!
So i have to make a class with two fields, pointer + length, adding much indirection and bloat.
And that is instead of one generic class!
So close – but out of reach! hate it!
Perhaps the information in your post is incomplete, but it why couldn’t you just use a variant record in this case ?
A char Flags[10] “fits inside” a char Flags[20] so when working with an API that only expects 10, just ignore the extra 10 chars. Maybe not 100% “pure”, but clean and clear enough, no ?
You shouldunderstand that “free” “appealing”. Age is climbing because Delphi is no longer appealing, not because it is not free. Is the average age of Photoshop user “climbing”, for example? For students there are low cost academic editions. If a product is appealing people will use it anyway. If you have a product almost nobody wants, free editions won’t help you anyway. Free edition will just be used by ageing developers with tight pockets.
You cannot sensibly compare the PhotoShop market with Delphi, or any other software development tool for that matter.
Yes, you are right about a product being appealing, but “free” is very appealing when you are just getting started, especially when the $$$’s on the alternatives are paying for things you don’t have any need of or interest in (yet).
” Finally release the โDelphi 7 Foreverโ Edition.”
Hahah that would be Lazarus
Embarcadero is actually just as bad or maybe even worse
Than Borland was…
I wish people would stop complaining about a starter edition
As we have lazarus, seriously there is no reason hobbiest and new
Users can’t use lazarus and when they need something delphi
Has they can spend the cash.
Also if a lot of you smart guys helped out with
Making lazarus better there would be little to complain about.
Embarcadero doesn’t care about us, they only care about
Profits so the ceo and top execs get a huge amount huge bonus..
So my resolution for 2013 is to use Delphi as little as possible
And use some of the cash i would have spent on software assurance
And donate it to lazarus /fpc.
The problem is that this makes sense from a purely intellectual/economic argument, but “mindshare” is a less tangible but in some ways more important problem. Once someone has chosen Lazarus/FPC, switching away from that to Delphi – even if Delphi has some things that they might like to have – they are already affined to Lazarus/FPC and now instead of two choices differentiated by price, you now have to convince them to give up their initial choice and the time they have invested and pay for the privilege.
QC, QC, QC, QC, QC, QC!!! This is the place to start for EMBA & Marco!
Also, talking about IDE productivity: #245) See what Notepad++ can do compared to RAD’s IDE? (the basics!) Something *very* useful: double click a word in a source file in NP++ (to mark it) – it becomes colored and all matches around it get colored too!
CnPack has this feature but it should be in the IDE by default IMO.
“for var” syntax like in DWScript
http://www.delphifeeds.com/go/s/98167
Performance boost for FMX. Currently FMX build applications are extremly slow on my computer. They are not usable at all.
Win7 32Bit 2GB RAM.
Android Support is critical!
We are getting slaughtered in the market because we cannot deliver on this ever growing platform!
Check out RemObjects Oxygene for Java – that can target Android and will almost certainly deliver better solutions than any Delphi + FireMonkey for Android can or will.
No one that miss having an undo in the VCL form designer ?
On the issue of form designer.
o Why does the TImageList images changes between saving the form? Really irritating when using a source code control system since it indicates changes in the dfm file all the time.
Because Windows’s ImageList streaming functions put the capacity of the imagelist into the stream. And ImageList_Read uses this and increases it, so that the next ImageList_Write will write a larger value into the stream. That goes on and on. (You can see this if you Alt+F12 back and forth multiple times). My IDEFixPack plugin calculates a “static” capacity and changes the stream after ImageList_Write wrote the imagelist to it. That way the stream changes only once when you open a DFM with an unaltered (original) imagelist stream and then doesn’t change unless you add/remove images.
I don’t need any fancy features but something like these:
1) Improve code editor so I don’t need to install mandatory 3rd party components like GExperts and Castalia. These include proper function of Home and Tab buttons, ctrl + alt + down, drop-down list of procedures in the current unit and so on…
1.5) Highlight the variable under the cursor. So it’s easier to see where it is used. This is, I think, a very basic operation in other code editors.
2) Currently I cannot debug some classes like TList, I see just a memory address.
3) Linux compiler
4) 64-bit Delphi editor
Why should I not compare Delphi to Photoshop? Both are products to build a “deliverable” from “sources”. What’s the difference between delivering a commercial image or a commercial software? As already said, to “get started” there are students edition. Than if it is an hobby you can pay as many hobbyists pay $$$$$$ for their hobby (musical instruments, video/photo gear, sport apparel, etc. etc.), if you become a professional you have to invest some money in your tools. Aiming free products (without proper limitations – the one most of you don’t want) bring no money to pay for development and just make good developers fly away. I prefer an excellent $3K Delphi than a crappy $100 one. The former would repay me easily, the latter will just waste my time and will make me move to a better professional product. And believe me, there’s no way to sell a $100 good one.
Why shouldn’t you compare to Photoshop? Multiple reasons – here are just two:
1) I could choose to switch to a different image manipulation application tomorrow very easily. This means that PhotoShop HAS to stay on top of it’s game because there is no “lock-in” for existing users.
2) You can learn the techniques involved in image manipulation using other tools and then easily apply those in PhotoShop. There is no “language” or “runtime” baggage to increase the cost of transition. So the decision to move up from whatever free/cheap software you start learning with to PhotoShop is just an economic one.
That’s why the two aren’t comparable, any more than you can directly compare the markets for utility vehicles (utes and pickup trucks) and super-cars, even though they are both just automotive vehicle markets, right ?
1) Are you sure? Try. Photoshop is a lock-in as much as many dev tools. When you have your professional workflow in Photoshop (calibrations, plug-ins, etc), you can’t easily migrate to Corel Painter or whatever.
2) You can learn programming in any language. Did you learn programming in Pascal? I didn’t. I learnt BASIC and assembly before – and applied the techniques in Pascal. Many image manipulations tools and plugin are as specific as a framework, and two different products never work exactly the same way but for basic tasks – as any language/RTL. You can learn in Free Pascal and then switch to Delphi, why not?
Anyway graphics/photo schools don’t teach GIMP or Corel Painter or Paint Shop Pro – they teach using Photoshop because that’s the standard professional tool, even if there is no hobbyist edition.
And no, I didn’t compared database servers to Delphi, as your car analogy implies. I compared two products that are used in ways more alike than you think. Look at how a pro photographer/designer produces images, and I do not mean holiday snapshots, I mean a professional photographer – it’s not that different than writing software. From requirements and inception to delivery.
You are thinking about this from the perspective of the users who have already become commercial professionals, happy to pay a tiny fraction of their income to pay for the tools they use. These are the same as the enterprise customers happy to pay $2K-$3K for their Delphi licenses. The big difference is that in the case of PhotoShop, those same commercial professionals don’t have to worry about where they are going to find new recruits to hire as juniors as their company expands, because – as you point out – the schools are teaching PhotoShop, because it is the de facto industry standard in it’s field.
Which is another point of difference between Delphi and PhotoShop.
And in fact, this leads me to retract my previous assertion that you cannot compare PhotoShop to other development tools. I was mistaken. You could more fairly compare it to C# or Java, for this latter reason. And also for the fact that both are supported by standard frameworks – their own managed runtimes.
There is no de facto industry standard framework for Pascal. If you, as in interested hobbyist with an idea that interests you but which makes you no money – yet – choose FPC and the LCL, then switching to Delphi will be made more difficult by the fact that although you may well have successfully learned even the Delphi flavour of Pascal within the FPC environment, you won’t have learned much about the VCL (altho granted a fair bit of the VCL will be familiar to you, from the LCL). Not to mention nothing at all about FireMonkey.
My point with the utility/super-car comparison was to point out that selecting one convenient point of commonality cannot be used to set aside all the other differences. And the points of difference between PhotoShop and Delphi are vast.
But the biggest difference, as mentioned above, is that there is no need for the PhotoShop community or for Adobe to be concerned about where the next generation of users will come from. Delphi is in almost the exact opposite position.
Let it be, Jolyon. All you’re doing is feeding the trolls at this point.
Yep – don’t worry. I’m done trit-trot-tritting over this. ๐
Photoshop does have price/feature differentiated editions.
There is Photoshop CS6, Photoshop CS6 Extended which adds 3D and some other features and then the other applications like Elements and Lightroom that also provide catalog capabilities along with editing capabilities.
There are also online/mobile versions with Photoshop Touch and Photoshop Express.
Those are part of a “family” of products, not strictly editions of the same product in the same way that Pro / Enterprise / Architect etc. Even Elements – arguably “PhotoShop lite” – actually has things that “full” PhotoShop doesn’t, so Elements < PhotoShop isn't the same as Pro < Enterprise, w.r.t Delphi. With photography as another hobby of mine, I am a PhotoShop and Lightroom user, so I do know a little about these products. ๐ But, if like LDS you want to obsess over whether or not these really are "editions" in the same sense that I think of them, then go ahead. It's not actually relevant. ๐ The point that really needs addressing is where the next generation of Delphi users are coming from, and the major difference between PhotoShop and Delphi – the one that nullifies all other similarities when it comes to comparing market strategies, imho – is that PhotoShop’s future is far more certain than that for Delphi.
Your statement was incorrect as there is Photoshop CS6 and Photoshop CS6 Extended. As a photographer and Photoshop user I’d expect you to know this and not post a statement that was incorrect. There is no obsessing, just pointing out your incorrect statement.
What you and I consider “editions” is clearly different (or at least arguably different enough to give the trolls a sniff of a potential to “prove” me wrong, and thus promoted to the top of the significance pile). I was an idiot to use as an example of a difference something that could be argued over. But in an effort to entice the trolls to address the key point, let’s just agree that I was wrong. There are different editions of PhotoShop. I was wrong. Mea culpa. 1,000 Hail Mary’s and might I please wash your feet now ?
Congratulations. The implications of this victory for the future success of Delphi are massive. We can all rest easy. I expect my desk to be flooded with eager new recruits, desperate to learn Delphi on the back of this.
Sheesh
Have you ever considered that you may actually be part of the problem for new Delphi recruits?
A new recruit may Google Delphi and finds your blog which is by a “friend” and yet so many articles are criticisms of Delphi. Wow, with friends like that, a new recruit would be better off going and learning something else where the friends are friendly or people put effort into writing blog articles that actually help new recruits understand what is so great about Delphi and why you were attracted to it in the first place.
PS: I don’t feel your admission of being wrong is sincere enough for me and lacked a suitable official statement on your home page, a tweet, an email and a smoke signal. ๐
The problem isn’t that there are people looking at Delphi, considering it, then finding my blog talking about the things that need talking about (or anybody else’s for that matter) and being put off (most likely – if at all) not by the fact that I mention these things, but that these things exist to be mentioned.
The problem is that nobody(*) is looking at or considering Delphi at all.
(* – subject to rounding errors in the expression “not enough people”) ๐
> Photoshop … there is no hobbyist edition
Adobe Photoshop Elements ???
In a sense, yes, but Elements is essentially a different product, albeit in the same family. It isn’t just a “lite” version of PhotoShop, it actually has features that PhotoShop doesn’t have.
Like LDS you need to remember that the comparison was supposed to be “Delphi — PhotoShop”, not “RAD Studio Family — PhotoShop”. He also mentioned Lightroom, for example. In which case we need to start thinking of HTMLBuilder as part of the Delphi product line… even Embarcadero gave up on that idea! (dropping the “Delphi for PHP” name)
Feaure list on Top is OK but,
-what for Garbage Collection???
Never need such crazy ugly kiddish things like this when not playing with or be dazzled by toy languages; in my progs all is under control ๐
WTF ist “Garbage Collection”, never ever heard such thing ๐
And
-“Improved code optimization”:
yes, would be erally fine but
please please
in different gradations which should be able to be swiched off in parts of the code by compiler switches!!!!!
>3) Finally release the โDelphi 7 Foreverโ Edition.
It warms my heart….
NB: ARC is the way, not garbage collection.
1) Photosop has no editions? Look at http://www.adobe.com/products/photoshopfamily.html?promoid=JOLIW
2) Exactly. And that despite the price. So price is not an issue when a product is so good you have no reason to use another free one. The problem with Delphi is it is not good, not it is expensive.
3) Photoshop just runs on two platforms. Adobe was smart to understand it needed a Windows version too – but at the functionalities level, not trying to develop a Frankenstein.
4) Exactly. While Delphi is no longer highly regarded. And making it cheap won’t help to gain more.
But you fail to notice that there are a lot of hobbyists who do buy Photoshop. Because it is good and tops competitors. Despite the price and the availability of free alternatives. The “common sense” that Delphi has no users because it has no free edition is utterly false. Delphi has no new users because it is not appealing, and a free version won’t make it more appealing. It will only allow actual old customer spend less. As long as Delphi is mostly mismanaged crap without a clear direction and lagging behind, it wont’ attract young developers, unless maybe you start paying them to use it.
And even if you learn C++ on VS Express, it won’t help you to learn for example MFC, which doesn’t come with Express. Or other commercial frameworks – unless you go fully the open source way. Thereby this boundary exists for any commercial tool, you can’t think you will learn everything for free – but again, academic/student editions *do* exists if you want to learn the full product – of course they are not accessible by commercial development who want Delphi for free… nor hobbyists who are able to spend a lot for everything but software.
And no, I’m not a troll – but I’m really tired of all the greedy people who think the others should give away their software for free so they could earn more spending less.
You see the text in that link ? “PhotoShop FAMILY”.
The equivalent to PhotoShop in your simile is not Delphi but “The RAD Studio Family of products”.
I think you’ll find that most hobbyists using PhotoShop didn’t pay for it.
And your thinking is the problem. You think that just because you can and are willing to pay for something then there is no reason what-so-ever for anyone else to get a break. Like someone with the means to buy a house in an inflated housing market, they consider it an insult to even consider that the housing market might be over-priced. “I can afford it, everyone else can go to hell in a handcart for all I care”.
On the other hand, I look at it from different perspectives:
1) I am a hobbyist. My hobby doesn’t earn me anything – it costs me money, not least hosting this blog. It’s not a question of earning more, but a question of justifying the expense. I earn *NOTHING* from the Delphi license that *I* pay for (even the Google ads on this blog don’t even come close to covering the hosting costs).
2) I am a professional (with a license paid for by my employer) with a responsibility for hiring developers. I look around and find NO new developers in the marketplace, and no prospect of any coming TO that marketplace. As a result, every time my employer asks me if the time isn’t right for us to consider dumping Delphi, it get’s harder and harder to make the case for sticking with it.
My previous employer was – I believe – the largest single Delphi customer in NZ. They dumped Delphi earlier this year. One of the biggest reasons for that was the dwindling supply of developers. A bigger reason was the lack of clear and reliable information or direction from Embarcadero.
You protest that Embarcadero can’t afford to “give away their software” – maybe you should write to them and tell to stop doing so then (free this when you order that, etc etc). But in terms of lowering the barrier to entry for Delphi developers, the question isn’t whether Embarcadero can afford to do it, but whether the community at large can afford for them not to!
You may not be a troll, but you certainly seem to be very blinkered.
Photoshop CS6 and Photoshop CS6 Extended in that link are different editions of the same product. Your statement was incorrect about Photoshop.
In that link “Lightroom” is also an edition of PhotoShop.
But you’re not obsessing. I get that.
No Lightroom is part of the family of Photoshop products and initially didn’t even have Photoshop in it’s name. I never stated that Lightroom was an edition of Photoshop.
CS6 and CS6 Extended are editions of Photoshop.
Others did – even the people that disagree with me can’t agree among themselves. Enough said I reckon. ๐
Man, that’s what lazarus is for, you can use it
To develop commercial apps, I could care less if
Borcadero gives delphi away for free as I am barely using
It now, I make very little from my hobby shareware
Apps and guess what lazarus and fpc is good enough,
For what it’s am doing its great actually, bugs actually get
Fixed and there is a active community where team b
Does not pull dicator on your ads for saying something
They don’t like. You people need to stop whining about a
Starter/free version. And yes you can move easily between delphi
And lazarus, anyone who that says you can’t has never
Used it.