Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Github announced Atom which is very similar to Sublime. Even some keyboard shortcuts like ⌘ + P, ⌘ + Shift + P etc. are same.
How is Atom different from Sublime?
Does it include IDE features like build tools, function definition jumps, documentations, etc.?
Has anyone using Sublime got a Beta invitation to point out the differences?
Can I use the themes, schemes and packages from Sublime as is, like Sublime could do with text mate.
1
PS: Open image in new tab for bigger resolution.
In addition to the points from prior answers, it's worth clarifying the differences between these two products from the perspective of choices made in their development.
Sublime is binary compiled for the platform. Its core is written in C/C++ and a number of its features are implemented in Python, which is also the language used for extending it. Atom is written in Node.js/Coffeescript and runs under webkit, with Coffeescript being the extension language. Though similar in UI and UX, Sublime performs significantly better than Atom especially in "heavy lifting" like working with large files, complex SnR or plugins that do heavy processing on files/buffers. Though I expect improvements in Atom as it matures, design & platform choices limit performance.
The "closed" part of Sublime includes the API and UI. Apart from skins/themes and colourisers, the API currently makes it difficult to modify other aspects of the UI. For example, Sublime plugins can't interact with the sidebar, control or draw on the editing area (except in some limited ways eg. in the gutter) or manipulate the statusbar beyond basic text. Atom's "closed" part is unknown at the moment, but I get the sense it's smaller. Atom has a richer API (though poorly documented at present) with the design goal of allowing greater control of its UI. Being closely coupled with webkit offers numerous capabilities for UI feature enhancements not presently possible with Sublime. However, Sublime's extensions perform closer to native, so those that perform compute-intensive, highly repetitive or complex text manipulations in large buffers are feasible in Sublime.
Since more of Atom will be open, Github open-sourced Atom on May 6th. As a result it's likely that support and pace of development will be rapid. By contrast, Sublime's development has slowed significantly of late - but it's not dead. In particular there are a number of bugs, many quite trivial, that haven't been fixed by the developer. None are showstopping imo, but if you want something in rapid development with regular bugfixing and enhancements, Sublime will frustrate. That said, installable Atom packages for Windows and Linux are yet to be released and activity on the codebase seems to have cooled in the weeks before and since the announcement, according to Github's stats.
In terms of IDE functions, from a webdev perspective Atom will allow extensions to the point of approaching products like Webstorm, though none have appeared yet. It remains to be seen how Atom will perform with such "heavy" extensions, since the editor natively feels sluggish. Due to restrictions in the API and lack of underlying webkit, Sublime won't allow this level of UI customisation although the developer may extend the API to support such features in future. Again, Sublime's underlying performance allows for things that involve computational grunt; ST3's symbol indexing being an example that performs well even with big projects. And though Atom's UI is certainly modelled upon Sublime, some refinements are noticeably missing, such as Sublime's learning panels and tab-complete popups which weight the defaults in accordance with those you most use.
I see these products as complementary. The fact that they share similar visuals and keystrokes just adds to the fact. There will be situations where the use of either has advantages. Presently, Sublime is a mature product with feature parity across all three platforms, and a rich set of plugins. Atom is the new kid whose features will rapidly grow; it doesn't feel production ready just yet and there are concerns in the area of performance.
[Update/Edit: May 18, 2015]
A note about improvements to these two editors since the time of writing the above.
In addition to bugfixes and improvements to its core, Atom has experienced a rapid growth in third-party extensions, with autocomplete-plus becoming part of the standard Atom distribution. Extension quality varies widely and a particular irritation is the frequency by which unstable third party packages can crash the editor. Within the last year, Atom has moved to using React by way of shifting reflow/repaint activity to the GPU for performance reasons, significantly improving the responsiveness of the UI for typical editing actions (scrolling, cursor movement etc.). While this has markedly improved the feel of the editor, it still feels cumbersome for CPU intensive tasks as described above, and is still slow in startup. Apart from performance improvements, Atom feels significantly more stable across the board.
Development of Sublime has picked up again since Jan 2015, with bugfixes, some minor new features (tooltip API, build system improvements) and a major development in the form of a new yaml-based .sublime-syntax definition (to eventually replace the old xml .tmLanguage). Together with a custom regex engine which replaces Onigurama, the new system offers more potential for precise regex matching, is significantly faster (up to 4x) and can perform multiple matches in parallel. Apart from colouring syntax, Sublime uses these components for symbol indexing (goto definition etc.) and other language-aware features. In addition to further speeding up Sublime, particularly for large files, this feature should open up the potential for performant language-specific features such as code-refactoring etc.. Further 'big developments' are promised, though the author remains, as ever, tight lipped about them.
Atom is written using Node.js, CoffeeScript and LESS. It's then wrapped in a WebKit wrapper, which was originally only available for OSX, although there is now also a Windows version available. (Linux version has to be built from source, but there is a PPA for Ubuntu users.)
A lot of the architecture and features have been duplicated from Sublime Text because they're tried and tested. The plugin system works almost the same, but opens up a lot of new features and potential by exposing new APIs too.
I believe that the shortcuts remain mostly the same due to muscle memory – people will remember them and be able to instantly click with Atom.
The preferences can be controlled with a GUI rather than by editing JSON directly, which might lower the entry barrier towards getting people started with Atom. I myself find it difficult to navigate them all since there is no search feature in Preferences.
You can signup for an invite on the ##atom-invites IRC channel or signup to their website and add your email. The first round of invites came quickly.
How is Atom different from Sublime?
Atom is an open source text editor/IDE, built on JavaScript/HTML/CSS.
Sublime Text is a commercial product, built on C/C++ and Python.
Comparable to Atom is Adobe Brackets, another open source text editor/IDE built on JavaScript/HTML/CSS. Be minded that this makes Brackets more oriented towards Web development, specially in the front end.
Advantages of open source projects are faster rate of development and, of course, price.
Does it include IDE features like build tools, function definition jumps, documentations, etc.?
The short answer is yes, yes, and yes. The app is completely modular. Open source will give people the freedom to fill the gaps on several of these features.
Has anyone using Sublime got a Beta invitation to point out the differences?
Advantages of Atom is entry-level hackability, since it's built on the same code that powers Web sites.
Advantages of Sublime Text is performance, as it doesn't need to run on top of Node.js, and it's a more mature product, about to reach a stable version 3.
There are a long list of minor differences that can be included in the comments (I wish this markdown could be able to draw a table for comparisons, but that's another issue).
Because of Atom's rapid turnout, I am afraid some of differences I list here will become outdated over time. Per example, at the time of this writing, Atom is only available on the Macintosh while Sublime Text is already multiplatform.
Can I use the themes, schemes and packages from Sublime as is, like Sublime could do with text mate.
The short answer is no, but because of Atom's hackability, it will be easy to retool packages from other editors to Atom.
Atom is open source (has been for a few hours by now), whereas Sublime Text is not.
Here are some differences between the two:
Atom is open source (MIT License)
A single user license for Sublime Text costs $70.
Atom is written in Node.js, CoffeeScript, HTML and LESS.
Sublime Text is written in C++, Python for plugins, and Objective-C for Cocoa integration
Atom has a built-in package manager*
Sublime Text depends on a third-party solution for package management
(Wbond Package Control)
At the time of writing this (05/20/2014), there are Atom binaries only for Mac OS X (10.8 or later). If you want to use it under Windows or Linux, you'll have to build it. Update: Nowadays, there are Atom binaries for Mac OS X (10.8 or later) Windows and Linux.
Sublime Text binaries are available for Mac OS X, Windows (installable or portable) and Linux (as a .deb or tarball)
Atom settings can be configured either through a user-friendly interface or directly by editing configuration files.
Sublime Text only allows you to change settings through configuration files.
*Though APM is a separated tool, it's bundled and installed automatically with Atom
Atom has been created by Github and it includes "git awareness". That is a feature I like quite a lot:
Also it highlights the files in the git tree that have changed with different colours depending on their commit status:
I just got my beta invitation today and tried Atom right away. The GUI feels like Sublime, and yes, there some shortcuts adopted from Sublime.
Besides everything mentioned above, here are some differences I have noticed so far:
Vim mode is not as good as the Vintage mode on Sublime (which is not a fully featured vim either) because the vim package is in an early stage of development. See https://atom.io/packages/vim-mode for detail.
As James mention, Atom is written using web tools, so you have access to the stylesheet of the text editor (styles.less) to do whatever appearance changes you want using CSS. There is also an option to change the startup CoffeeScript.
Again, because Atom is still in the beta stage, Sublime has much more native plugin packages. However, since Atom is written in Node.js, the Atom official site said you can "choose from over 50 thousand in Node's package repository." (Because I am not a Node.js pro, I haven't look into this feature though)
Atom has better Github support out of the box, but Sublime has a several Git packages.
Sublime is a paid application unlimited evaluation period. Atom is free at the beta stage but we don't know whether Github wants to charge it or not.
So the bottom line is Atom is a text editor built with web technology at beta stage. By contrast, Sublime has evolved through many different iterations. Atom is still missing a lot of packages that Sublime supports, so the question is will Atom catch up with Sublime or become some better? Github seems to be confident about the future of this text edit because of its popular underlying technologies, and Atom is probably going to be a good alternative to Sublime in the long run.
Another difference is that Sublime text is a closed source project, while Atom source code is/will be publicly available --although Github does not plan to release it as a real open source project. They want to give access to the code, without opening it to contributions.
Github made the code public: http://blog.atom.io/2014/05/06/atom-is-now-open-source.html
Atom is still in beta (v0.123 as I'm writing this) but it's moving fast. Way faster than Sublime. New builds are released on a weekly basis, sometimes even few of them in the same week. In its short life span, it had more releases than Sublime which takes months to release a new feature or a bug fix. Here's an updated take on things looking back on the path Atom has taken since the launch of the beta:
Sublime has better performance than Atom. Simply because it's written in C++. Atom on the other hand is a web based desktop app built on top of Chromium, and while they take performance close to heart, it will be really hard or even impossible to reach the same speed and responsiveness. Last July Atom began using React and it gave it a nice performance boost but you can still feel the difference. Apart from that, if Atom’s performance issues will not push users away - Sublime better speed up the release cycle, brush up its small UX tweaks, and consider letting in more contributors because this is where Atom is winning.
Atom's package ecosystem is also growing really fast, it might not be as big as Sublime's at the moment but I have a feeling that with GitHub at it's back it will keep growing even faster. It probably has the majority of IDE like plug-ins you can think of. A major difference right now is that it can't handle files bigger than 2MB so it's something to keep in mind.
The one thing you'll notice first is that the Sublime minimap is gone! Other than that, the first impression is that Atom looks almost the same as Sublime. I wrote a more in depth comparison about it in this blog post.
No easy straightforward way to port your Sublime configurations, packages and such as far as I know.
I tried Atom and it looks really nice BUT there is one major problem (at least in v 0.84):
It doesn't support vertical select Alt+Drag - this is a must for every modern code editor.
One major difference is the support of "Indic Fonts" aka South Asian Scripts (including Southeast Asian languages such as Khmer, Lao, Myanmar and Thai). Also, there is much better support for East Asian languages (Chinese, Japanese, Korean). These are known bugs (actually the most highly rated bugs) that have been going on for years (thought it appears East Asian language support used to work better but have now become difficult to use):
http://sublimetext.userecho.com/topic/117587-thai-language-issue/
http://sublimetext.userecho.com/topic/99013-can-not-show-or-type-chinese-charactor-on-ubuntu-system/
I'm working in little extreme environment; edit files on remote filesystem (external network, surely) that is mounted on my Laptop thru ssh(aka. sshfs). Regardless why I'm doing like this, also though its cumbersome responsiveness, it's fairly edible when I'm using Sublime Text 2.
I tried on Atom after reading this post, but it turned out to be somewhat painful to me; Atom seems that it doesn't cache directory structure so efficiently. Every time I expand a folder on Tree View, the UI froze for a short time, 2~3 seconds, maybe fetching file system info. Yes, it's because I'm using remote filesystem. But Sublime handles this more efficient, at least it doesn't freeze every time I expand a folder, so less painful.
I think Atom is hell nice for free, and my story is trivial that might be enhanced someday, but it would be helpful to someone at this time.
--
added on 8/26/2014
Recently, I changed my laptop from Macbook Air 2010 late to Macbook Pro 13" 2013 late. It has likely 4 times faster CPU and much enhancements in performance. I want to mention my opinion is about in the case WHEN YOU MOUNT REMOTE FILE SYSTEM. (using OS X Mavericks, most recent version of Atom, FUSE 2.7.3 / OSXFUSE 2.6.4 / sshfs 2.5.0, and remote system is Ubuntu server) Eventually, UI freeze gets pretty shorter, but it is still there. Specifically, to open a folder with many folder/files in it and index it is requires certain amount of time. Also, if you expand a folder full of files, it just falters. (when collapsing the folder, it doesn't)
According to #EliDuenisch , it seems not happen on Linux Mint. I'm not sure but it might be from difference between OSes. Surely, if you work on local file system, you don't have to care about this issue at all.
One major difference that no one has pointed out so far and that might be important to some people is that (at least on Windows) Atom doesn't fully support other keyboard layouts than US. There is an bug report on that with a few hundred posts that has been open for more than a year now (https://github.com/atom/atom-keymap/issues/35).
Might be relevant when choosing an editor.
ATTENTION ::
-- because of poorly made caching system, in Atom loss of data occurs often when using big files.
It has been proven numerous times.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We currently have a large business-critical application written in COBOL, running on OpenVMS (Integrity/Itanium).
As the months pass, there is more and more speculation about the lifetime of the Itanium architecture. Nothing is said out in the open, of course, but articles like this and this paint a worrying picture. Although I can find nothing official to support this, there are even murmurings in the corridors of our company of HP ditching OpenVMS and HP COBOL along with it.
I cannot believe that we are alone in this.
The way I see it, there are a few options:
Emulate some old hardware and run the application on that using a product like CHARON-VAX or CHARON-AXP. The way I see it, the pros are that the process should be relatively painless, especially if the 64-bit (AXP) option is used. Potential cons are a degradation in performance (although this should be offset by faster and faster hardware);
Port the HP COBOL-based application to a more modern dialect of COBOL, such as Visual COBOL. The pros, then, are the fact that the porting effort is relatively low (it's still COBOL) and the fact that one can run the application on a Unix or Windows platform. The cons are that although you're porting COBOL, the fact that you're porting to a different operating system could make things tricky (esp. if there are OpenVMS-specific dependencies);
Automatically translate the COBOL into a more modern language like Java. This has the obvious benefit of immediately freeing one from all the legacy issues in one fell swoop: hardware support, operating system support, and especially finding administrators and programmers. Apart from this being a big job, an obvious downside is the fact that one will end up with non-idiomatic Java (or whatever target language is ultimately chosen); arguably, this is something that can be ameliorated over time.
A rewrite, from the ground up (naturally, using modern technologies). Anyone who has done this knows how expensive and time-consuming it is. I've only included it to make the list complete :)
Note that there is no dependency on a proprietary DBMS; the database is ISAM file-based.
So ... my question is:
What are others faced with the imminent obsolescence of Itanium doing to maintain business continuity when their platform of choice is OpenVMS and COBOL?
UPDATE:
We have had an official assurance from our local HP representative that Integrity/Itanium/OpenVMS will be supported at least up until 2022. I guess this means that this whole issue is less about the platform, and more about the language (COBOL).
The main problem with this effort will be the portions of the code that are OpenVMS specific. Most applications developed on OpenVMS typically use routines and procedures that are not easily ported to another platform. Rather that worry about specific language compatibility, I would initially focus on the runtime routines and command procedures used by the application.
An alternative approach may be to continue to use the current application while developing a new one or modifying a commercially available application to suit your needs. While the long term status of Itanium is in question, history indicates that OpenVMS will remain viable for some time to come. There are still VAX machines being used today for business critical applications. The fact that OpenVMS and its hardware is stable is the main reason for its longevity.
Dan
Looks like COBOL is the main dependency that keeps you worried. I undrestand Itanium+OpenVMS in this picture is just a platform.
You're definitely not alone running mission-critical stuff on OpenVMS. HP site has OpenVMS roadmap (both Alpha and Integrity), support currently stretches to 2015. Oracle seems trying to leverage it's SUN asset in different domains recently.
In any case, if your worries are substantial (sure we all worried about COMPAQ, then HP, vax>>alpha>>Itanium transitions in the past), there's time to un-tie the COBOL dependency.
So I would look now into charting out migration path from COBOL onto more portable language of choice (eg. C/C++ ANSII without platform extensions). Perhaps Java isn't the frendliest choice, given Oracle's activity. Re-write, how unpleasant it is, will be more progressive and likely will streamline the whole process. The sooner one starts, the sooner one completes.
Also, in addition to emulators, there're still plenty of second-hand hardware. Ironically, one company I know just now phases-in Integrity platforms to supplant misson-critical Alphas -- I guess, it's "corporate testing requirements"...
Do-nothing is an option as well, though obviously riskier: OpenVMS platforms are proven to be dependable, so alternatively, finding a reliable third-party support company may extend your future hardware contingency.
This summer's Rolling Roadmap makes porting off OpenVMS look like an excellent idea.
Given how much COBOL exists in the world finding people to support COBOL will not be a problem for the foreseeable future. As noted above there are COBOL compilers on other platforms. The problem lies in the OpenVMS system service calls and DEC language extensions your application uses. You do not mention where your data is stored, so worst case your COBOL uses RMS. There is a company that provides an implementation of many OpenVMS system services on Linux and the Unixes. Not needing to replace those services while porting to another operating system may reduce the complexity. Check out Sector7.com.
I used to use Pythia to obfuscate my D6 program. But it seems Pythia does not work anymore with my D2007.
Here's the link of Pythia (no update since early 2007) : http://www.the-interweb.com/serendipity/index.php?/archives/86-Pythia-1.1.html
From link above, here's what I want to achieve
Over the course of time, a lot of new language features were added.
Since there is no formal grammar available, it is very hard for tool vendors (including Embarcadero themselves) to keep their Delphi language parsers up at the same level as the Delphi Compiler.
It is one of the reasons it takes tool vendors a bit of time (and for Delphi generics support: a lot of time!) to update their tools, of they are update at all.
You even see artifacts of this in Delphi itself:
the structure pane often gets things wrong
the Delphi modelling and refactoring sometimes fails
the Delphi code formatter goes haywire
Pythia is the only obfuscator for the native Delphi language I know of.
You could ask them on their site if they plan for a newer version.
Personally, I almost never use obfuscators for these reasons:
reverse engineering non-obfuscated projects is difficult enough (it would take competitors long enough to reverse engineer, so the chance to lessen the backlog they already have in the first place is virtually zero)
their added value is limited when you have multi-project solutions (basically they only hide internal or private stuff)
they make bug hunting production code far too cumbersome
--jeroen
You may try UPX - Ultimate Packer for Executable). It will compress the resources and all the text entries are non-readable without de-compress first.
I don't know any good free solutions, but if you really need some protection you can always buy something like:
http://www.aspack.com/asprotect.html
or
http://www.oreans.com/themida.php
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am looking at Erlang for a future version of a distributed soft-real-time hosted web-based telephony app (i.e. Erlang looks like absolutely the perfect choice for this kind of app). I come from a .NET background and the current version of this app uses a combination of C#, WCF and JQuery to deliver the service. I now need Erlang to allow me to add extra 9s to my up-time and to allow me to get more bang for my server bucks.
Previously I'd set up a development process here combining VS.NET, GIT, TeamCity and auto-deployment of MSI files to the various environments we maintain. It's not perfect, but we're all now pretty comfortable with it. I'm wondering whether a process like we have is even appropriate for such a radically different technology stack (LYME)?
I'm confident that all of the programming challenges we previously solved using .NET can be better solved in less code with Erlang, so I'm completely sold on the language choice. What I don't yet understand from reading the Pragmatic and O'Reilly books on Erlang, is how I should adapt my software engineering and application life-cycle management (ALM) processes to suit the new platform. I see that in-place code updates could make my (and my testing and ops team's) life much easier (compared to the god-awful misery of trying to deploy MSI files across a windows network) but I am not sure how things should change when I use Erlang.
How would you:
do continuous integration in Erlang (is it commonly used?)
use it during a QA cycle (we often run concurrent topic branches using GIT, that get their own mini-QA cycle, so they all get deployed into a test environment)
build and distribute your code to DEV, TEST, UAT, STAGING, and PROD environments
integrate code generation phases into your build cycle (we currently use MSBUILD + T4 templates)
centralize logging for a bunch of different servers (we currently use Log4Net, MSMQ, etc)
do alerting with tools like SCOM
determine whether someone/something has misconfigured your production servers
allow production hot-fixes only after adequate QA (only by authorized personnel)
profile the performance (computation and communication) of your apps
interact with windows-based active directory servers
I guess I need to know what worked for you and why! What tools and frameworks did you use? What did you try that failed? What would you do differently if you could start over, knowing what you know now?
Whoa, what a long post. First, you should be aware that the 99.9% and better kool-aid is a bit dangerous to drink while blind. Yes, you can get some astounding stability figures, but you need to write your program in a way facilitating this. It does not come for free. It does not happen by magic either. Your application must be designed in a way such that other subsystems recover. OTP will help you a lot - but it still takes time to learn.
Continuous integration: Easily done. If you can call rebar or make through your build-bot you are probably set here already. Look into eunit, cover and Erlang QuickCheck (the mini variant is free for starters) - all can be run from rebar.
QA Cycle: I have not had any problems here. Again, if using rebar you can build embedded releases that are minimized erlang vm's you can copy anywhere and run (they are self-contained). You can even hot deploy fixes to such a system pretty easily by altering the code path a bit so you have an overlay of newer fixes. Your options are numerous. Git already help you here a lot.
Environmentalization: Easily done.
Logging centralization: Look into SASL and the error_logger. You can do anything you want here.
Alerting: The system can be probed for all you need (introspection is strong in Erlang). But you might have to code a bit to hook it up to the system of your choice.
Misconfiguration: Configuration files are Erlang terms. If it can be computed, it can be done.
Security: Limit who has access. It is a people problem, not a technical one in my opinion.
Profiling: cprof, cover, eprof, fprof, instrument + a couple of distributed systems for doing the same. Random sampling is also easy (introspection is strong in Erlang).
Windows interaction: Dunno. (Bias: last time I used windows professionally was in 1998 or so).
Some personal observations:
Your largest problem might end up being that you try to cram Erlang into your existing process and it might resist. It is a new environment, so new approaches will be needed in places and you should expect to adapt and workaround limitations you find along the way. The general consensus is that it can work (it is working for several big sites).
It looks like you have a well-established and strict process. How much is that process allowed to be sacrificed to give way to a new kind of thinking?
Are your programmers willing to throw out almost all of their OO knowledge? If not, you will end with a social problem rather than a technical one. If they are like me however, they will cheer, clap in their hands and get a constant high by working with an interesting language solving an interesting problem in a new way.
How many Erlang-experienced programmers do you have? If you have rather few, then better cut your teeth on some smaller subsystems first and then work towards the larger goal. Getting the full benefit of the system takes months if not years. Getting partial benefit can be had in weeks though.
We have a medium-to-large size application. One version runs on Delphi 6 and another one on Delphi 2006.
One argument would be support for Unicode. We need that to cater to Customers around the world.
Other things I have read about are: better IDE (stability, speed), better Help and some cool additions to the language (e.g.: generics)
What about third-party components? We use DevExpress, DBISAM and many others. Are these already ported?
Touch/Gestures sound cool, but we have no use for that in our application.
Better theme support (eg., TStringGrid/TDBGrid now support themes).
Support for Windows Vista and Windows 7, including support for the Direct2D Canvas in Win7 and the Touch/Gesture support you mentioned.
Improved refactoring, including support for refactoring generics.
Built-in source code formatter.
IDE Insight allows you to find things in the IDE itself.
Enhanced RTTI.
Improvements in the debugger, including new custom data visualizers and the ability to create your own. There are two included with source (one for TDateTime and one for TStringList). Also better support for debugging threads, including the ability to name threads for debugging and set breakpoints on specific threads.
The ability to add version control support to the IDE via interfaces. This will allow version control developers to add support directly in the IDE itself.
The help is much better than in previous versions. It's been completely redesigned again, and is much more comprehensive and complete. There's also an online wiki-based version (used to generate the help itself) that you can add or edit.
Background compilation allows you to continue working while you're compiling your project.
As far as third party controls, that's up to the specific vendor; you'll have to check to see if Delphi 2010 versions are available for each of them individually. (You might check the Embarcadero web site, though, to see if they have a list already available; I seem to recall hearing of one... Ah, yes. Here it is. )
Last upgrade for old version
With old version of Delphi (before Delphi 2005), you have only before january 1 2010 to upgrade.
After you will have to buy a full version.
Productivity
http://www.tmssoftware.com/site/blog.asp?post=127
Purely as a reactive measure. Lets say that there is a new feature in the latest version of a yet to be released operating system. Lets say that this feature breaks certain features inside your application. IF there was to be a global fix for it, it would most likely not be placed in older versions of the compiler, but the newer versions which "officially" support the new operating system. The largest problem about waiting too long is that when such a measure is needed its generally at the zero hour when sales are at risk.
Upgrade NOW, and help prepare your application to be more reactive to future changes.
Don't convince him for a Delphi 2009/2010 upgrade, Do it for a Software Assurance.
The refactoring tools and overall
speed and stability of the IDE will
make the development team more
productive.
Working with the latest tools will make it easier to recruit top talent.
The IDE is definitely a step up from Delphi 6 and/or Delphi 2006.
If Unicode is important to your customers then Delphi 2009/2010 is a clear option. But if Unicode is important to you, rather than your customers, then I'd be careful.
Unicode is not "free". If your users/customers have concerns w.r.t memory footprint and/or performance, and/or your application involves extensive string handling, then Unicode exacts a price that all your customers will have to pay, and for customers who are not themselves concerned with Unicode support, that price comes with zero benefit (to them).
Similarly if your application sits on top of a currently non-Unicode enabled database schema. Migrating existing databases from non-Unicode to Unicode is non-trivial, and if you have customers with large production databases, incurring downtime for those customers whilst they migrate their data stores is something you should consider carefully.
Also you will need to be very aware of any interfaces to external systems - your code will unilaterally "go Unicode", and that may adversely impact on external interfaces to other systems that are not.
In such cases you would do well to tie the transition to Unicode with other compelling feature improvements and benefits to make the transition compelling for other reasons.
Also, if you genuinely have customers with a real need for true Unicode, then the transition is not as simple as recompiling with the latest/greatest compiler and VCL. True Unicode support will involve a great deal more work in your application code than you might at first appreciate.
Of course, having a Unicode capable compiler/VCL is a crucial component, but it's not an answer on it's own.
The Unicode change has a significant impact on 3rd party components. Even if you have the source to your 3rd party code you may find yourself facing Unicode issues in that code unless the vendor has taken steps to update that code in a more current version. Most current vendor libraries are Unicode by now though I think, so unless you are using a library that is no longer supported by the vendor, you should be OK on that score.
I would also exercise caution when it comes to those "cool" language features such as generics. They sure do look cool, but they have some seriously limiting characteristics that you will run into outside of feature demonstrations and can result in maintenance and debugging difficulties as the experience of the community in working with them is limited, so "best practice" has yet to emerge and the tool support perhaps hasn't yet caught up with the uses to which those features are being put in actual code.
Having said ALL that.... Since you cannot realistically choose any version other than Delphi 2010 to upgrade to, then if you are going to upgrade at all then you have to bite the Unicode bullet and will find yourself presented with lots of tempting language features to tinker with and distract you. ;)
And now that Embarcadero are imposing a more draconian policy w.r.t qualifying upgrade products, you will have to get off of Delphi 2006 if you wish to qualify for upgrade pricing for Delphi 20*11* onward, whether you decide that 2010 is right for you or not, otherwise when the time comes to upgrade to Delphi 2011 you will find yourself treated as a new customer, and if you thought that upgrade pricing was steep, check out the new user license costs!
D2006 was an awful version of Delphi. It's worth upgrading just to be rid of all the memory leaks and random IDE crashes and glitches. Justify it to the boss as a massive decrease in lost productivity. That means less money wasted paying you to not produce code because your dev tools aren't working. It'll pay for itself very quickly on that basis alone.
As for D6 vs. D2010, that's a feature argument. Start with Skamradt's response, that it helps your code be future-proof. Underscore it with OS compatibility. D2007 was the first version that understands Vista. D2010 is the first version to understand Windows 7. If you're compiling with any older version, your app is obsolete before you even deploy it because there's no guarantee it's compatible with modern versions of Windows.
Then you've got actual language features. The main improvements IMO from 2006 to 2010 are Generics, which helps out with all sorts of repetitive tasks, and extended RTTI. Robert Love has been doing some great blog posts lately on how the extended RTTI can simplify common real-world problems. (Plus Unicode, of course.)
Playing the devils advocate, there may be reasons not to upgrade. For instance you might be missing the source to certain components or you may still need to support Win9X.
I think you'll probably find the best reason to upgrade (leaving all the new wizz-bang features aside) is that you'll be significantly more productive in the new IDE. If you don't / can't upgrade I'd recommend grabbing a copy of Castalia, which can give you access to many productivity enhancements (e.g. refactoring) in Delphi 6.
DBISAM is updated, I just emailed them this past week concerning a project I hope to be upgrading from Delphi 3 to Delphi 2010.
All the other packages I looked into upgrading for that project (WPTools, Infopower, TMS) all state on their websites that they offer compatibility with 2010.
I never had D2006 (I have 2007) so I can't speak to any defects in that particular release (D2007 isn't that great, either) but it's generally a good principal to keep your tools in good shape. For a saw that means sharp, for software that means current. Especially in a new-OS year, you probably want the corresponding version of your primary development environment.
It seems to me there are 2 aspects in developing professional applications:
You want to earn money: you have to stick to your customer's demands, keep your stuff KISS, maintainable and so on... You have to be productive: no matter of generics, RTTI, widgets like flowpannel, gesture and so on because it takes time to learn and more time to use. In this way, change from D7 to D2010 is not nessary relevant. Change for another IDE like REAL Basic allowing multiplaform target is more accurate.
BUT as a developer there is a child and a poet in you, fascinated by new technologies or/and algorithms... This is the creative part of the job. You got to be creative if you want to be impressive and innovator. Upgrade to Delphi 2010 is a must have, searching for new classes, new objects is a way of life in today's programming.
That's my humble point of view and the reason that keep me spend my money to upgrade Delphi from I to 2010.
Best regards,
Didier
Lists of compatible components that already support Delphi 2010 including DevExpress (article will be periodically updated from our technology partner database) is at
http://edn.embarcadero.com/article/39864
Argument - tens of thousands of tools and components available for the things you might need in addition to the open api(s) for components and the IDE.
Item 9 of the The Joel Test: 12 Steps to Better Code is:
Do you use the best tools money can buy?
Perhaps this argument is germane here.
On the other hand if you are maintaining legacy code and not generating anything that has dependency on new OS or tool features, it is a hard argument to win. I would not however recommend generating entirely new projects on tools that old.
Unicode has been supported on Windows since at least NT 4.0, and for Windows 95/98/Me since the addition of MSLU in 2001 - so surely Delphi 2006 supports it!? [edit]Not fully supported in the component library it seems.[/edit]
I suggest that the one compelling argument is in order to ensure Vista and Windows 7 compatibility. I understand that 64bit target support was planned for Delphi this year. That may be another argument; but again it only applies if you actually intend to target such a platform, and in a way that will give a tangible benefit over 32bit code. [edit]I emphasised planned because I did no know whether it had made it into the product, but that it might be a consideration for you. It seems it has not, so the argument you put to management might be even less strong.[/edit]
Management are not going to be impressed by the "I just want cool tools to play with", you have to approach it on a "Return on Investment" (ROI) basis. Will you get your product out faster or cheaper using this tool? Are the existing tools a technical barrier to progress? Conversely, consider whether spending time porting your legacy code to new tools (with the associated validation and testing) will kill your budgets and deadlines for no commercial advantage?
I have a freeware scientific app that is used by thousands of people in nearly 100 countries. Many have offered to translate for free. Now that D2009 makes this easier (with integrated and external localization tools, plus native Unicode support) I'd like to make this happen for a few languages and steadily add as many as user energy will support.
I'm thinking that I'll distribute a spreadsheet with a list of strings (dozens but not hundreds) to be translated, have them return it, and compare submissions in the same language from 2-3 users then work to resolve discrepancies by consensus. Then I'll incorporate the localizations using the Integrated Translation Environment, and distribute localized updates.
Has anyone delegated translation to users? Any gotchas, D2009-specific or otherwise?
EDIT: Has anyone compared the localization support built into D2009 versus dxgettext?
I have never been a friend of proprietary localization tools for Freeware or Open Source applications. Using dxgettext, the Delphi port of GNU gettext looks like a much better option to me:
Integration into the program (even much later than its development) is easy.
Extraction of translatable strings can be done by command line programs and is therefore easily introduced into an automated build.
A new translation can be added simply by creating a new directory with the correct structure, copying the empty translation file into it, and starting to translate the strings. This is something each user can do for themselves, there's no need to involve the original author for creation of a new translation. There is also instant gratification with this process - once the program is restarted the new translations are shown immediately.
Changing an existing translation is even easier than creating a new one. Thus if a user finds spelling or other errors or needs for improvement in the translation they can correct them easily and send the changes to the author.
New program versions work with old translations, the system degrades very gracefully - new and untranslated strings are simply shown unmodified.
Translations can be made using only notepad, but there are several free tools for creating and managing translation files too; see the links on the dxgettext page. They are localized themselves, and have some advantages over a spreadsheet as well:
The location of the strings in the source code can be shown (makes sense only for Open Source apps, of course).
The percentage of translated strings is shown.
Modifications to already translated strings are highlighted too.
The whole system is mature and future-proof - I have used dxgettext for Delphi 4 programs, and there should be no changes necessary for Delphi 2009 even - translation files have always been UTF-8 encoded.
Using a spreadsheet for the translation doesn't seem a workable solution to me once you have more than a few languages. Suppose a new program version adds 2 new strings and changes 10 strings only slightly - wouldn't you need to add the new strings to and highlight the changed strings in all of the several dozen spreadsheet files and send them again to your translators? Using dxgettext you just mail the changed po file to all of them.
Edit:
There is an interesting comment about the problems there may be with dxgettext and libraries. I did never experience this, as I have stopped using resource strings altogether. The biggest part of our programs are in German, and only a few are in English or translated into several languages.
Our internal libraries use "_(...)" around all translatable strings. There are defines ENGLISH and USEGETTEXT that are set on a per-project basis. If ENGLISH or USEGETTEXT are defined, then the English texts are compiled into the DCUs, else the German text is compiled into the DCUs. If USEGETTEXT is not defined "_()" is compiled as a function that returns its parameter as-is, else the dxgettext translation lookup is used.
I have... There can be some challenges.
a string does not mean much in itself, it needs a context.
corollary, the same string can need to have more than one translation.
screen real estate: beware of varying length depending on the language, for instance, French tends to be more verbose than English.
unless you are proficient in a given language, you won't be able to evaluate the discrepancies.
I've used TsiLang Translation Suite for enabling end users to translate. I modified the code to allow encryption so that if someone does a really good job they can protect their name against a translation file, but in general the idea is that people can share their translations, and add/edit any small part they wish to. Given that it all happens within the app, and with instant visibility, it works really nicely.
As you have mentioned, D2009 comes with localization tools. Why not simply using them? AFAIK you can distribute the external translation manager (etm.exe). Do you need anything else?
Also, localization is more than just translating text. ETM also supports translation of .dfm resources.
For completeness, here is another Delphi localization tool called Delphi Localizer I recently found that looks to be well designed and polished. The tool is free for commercial use with the exception of Government projects (not exactly sure why the exception).
FWIW I have uses TsiLang Translation Suite in the past and am currently working on another project using the localization tools shipped with DevExpress VCL. The later integrates nicely with their components as well as third-party components.