I'm referring to shrinkwrap software that a customer would purchase for thier own use.
I am NOT referring to server software or ASP type applications. Those apps have different constraints (must be fast, but install can be difficult, etc.).
I'm just curious. I suspect a lot of this sort of sw is written in
Delphi and VB.
C / C++
Other (please list)
.. is now C# (.NET)
There were two reasons for the change, both political - first our major partner got into bed with Microsoft in a major way and posted a load of internal docs for their partners sayng how this was the way to go. Second if it all went belly up, C#/.NET is a growing market where Delphi is at best static over the last three or so years IMHO.
I have a feeling I'm writing about 25% less code to get the same amount of work done, but I'm also 'picking my battles' very carefully and using Delphi components where I know the quality/functionalty on offer justifies the mix.
I've not found the requirement to install the .NET framework is affecting corporates from trialling our stuff, (we sell off-web), but it might be stopping smaller firms evaluating- I don't know.
Shrinkwrap is distribution.
You can program in the most appropriate language for the application, or for existing third party software developers, or in the same language that the product you are complementing was written in.
The langauage decision and the distribution decision are not linked.
We shipped a shrinkwrapped PowerBuilder framework once upon a time.
This decision can be based only after a clear defination of the functionality of the app.
Choosing a development environment without the functionality or specs could spell a lot of trouble for you at a later date.
Originally posted by Entrepreneur
It's a sweet language. And, based on a brief review of delphi vs. .net, delphi seems to be better at inheritance. Ex: if you have one form inherit from another, you can actually modify the code in the click event of, say, a button the form, using delphi. You can't do that in .net. You get the inherited button, but you can only leave it or make it not visible. You can't MODIFY that code in the click event. This looks suspiciously like MS has kludged together inheritance.
Of course, that's just one data point.
I think you're wrong here.
C# (.NET) is even better then Delphi on dynamically changing event handlers. The .NET approach is similar to the Java UI event handlers. For every event on a control you have a list of (pointers to) methods (more then one) that are called when event is triggered. And you can opperate on this list the way you want (delete all handlers for instance).
OTOH Delphi allows a single event handler on an event.
To check this for sure, take a look at the code that is generated when you add an event handler in VS.NET.
It's one thing to use an inheritence lattice in an application you will maintain. It is another to sell a framework that uses them. The pattern movement is a response to the overuse and abuse of inheritance. The other response is a lot of dead framework sellers. When it comes to frameworks, if it takes longer to understand it than to do it yourself, you do it yourself.
Microsoft embeds style decisions in their tools all the time, so I wouldn't be surprised.
Some interesting points have been brought up here but I donĀ?t know what you were hoping to find out.
Are you in or investigating a certain market?
Desktop Game apps?
Desktop Productivity apps?
Web Development tools?
Desktop Security utilities.... [to name a very few]
Could you describe so we might direct our answers to your situation.
Do you have an investment in a code base in a particular language? Or would you like opinions on the utility of one language vs another? Again, the context is important, to optimise what? achieve what?
What is your product? I don't see any reference to a website. Maybe I'm blind.
Your question makes sense to me, particularly the finding good proficient programmers as you product matures.
In the short run the cost of migrating your current staff to a new language is an important consideration. Does your staff, presuming it is more than you, have an opinion on the subject?
And again is the marketing question, is your market solid? I see your are in health care. They seem to be on a technology growth spurt. Getting off the subject.
Hope some of the Delph - .NET discussion was helpful.
Back when I worked for a vendor that sold PowerBuilder frameworks, Delphi was a competitor. I never saw PowerBuilder applications outside the IT department or departmenal context, except for the vendors that sold to the PowerBuilder development community. I would guess it was likewise for Delphi.
Microsoft killed VB. I thought there was a .Net version of VB, but I also heard that it is very different from VB. This seems to be the case for all languages heading towards .Net.
Atleast with our experience we have several clients who have started thier new projects in Visual Basic 6.0.
Why did we zero in on Visual Basic and not Delphi/.NET...
1. The functional scope of the project could be easily met in VB without a problem.
2. With its inherent RAD abilities they could have a product evolve before thier eyes in a relative short span of time.
3. There are a HUGE set of VB compatible Acitve X Controls & Plugins available. (When I mean compatible.. they were designed with VB is mind and not Delphi). Hence component building and testing was not a problem.
4. Windows is a MS product ... VB is a MS product, it is obvious clashes between the OS and the application would be relatively less. It is a MS world we live in whether we like it or not and your users are MS users, they like the MS interface, they like the touch and feel.
5. As already indicated you can always get a VB engineer but you cant say the same for Delphi.. oh yes not forgetting the fact they demand much lower salaries than Delphi people.
6. There are vast Knowledge Bases around for VB compared to Delphi, just check the...Google Groups.
7. I am sure you have experienced the ease of maintainence of a VB project.
I am not necessarily an MS fan but if your scope can be fulfilled by VB why venture into Delphi and to top it all you have the experience in VB, use that experience for a developing a great product.
With regards to . NET I persoanlly feel it is too early a technology to burden your users with at this stage.
BTW we do use DELPHI as well but just to give you an example, we used Visual Basic for a inventory control system while we used Delphi for a controlling a proximity sensor.
Choose the development environment keeping in mind the functional scope. The users dont really care what it has been built it so long as it works well & looks good.
Hope my 2 cents helps..
I've heard secondhand that the runtime only has to be installed once, kind of like Java.
We are developing an architecture that will work with or without connections to the Internet. The only problem is that I can't see what the disconnected MS Office suite is going to be, or even if that is going to be possible. If we have to go to non-MS applications, so be it. Having my office suite connected to the net is a nusiance.
I talk to a large number of number of software developers selling shrink wrap software. Coming from the video game world where the only option is C++, I was surprised by the large number number of VB6 and .NET programmers out there.
.NET seems to be used more by startups/shareware authors because of it's new-ness. Companies with established products usually cannot afford to switch. The VB6 folks that are happy keep quiet, so you don't hear much from them.
Very few people use Java for shrink wrap software for whatever reason - I'm not aware of any successful commercial application that uses it. There are probably about 5% delphi users, and a few people using VB6 replacements like PowerBasic, etc.
In my personal opinion, the top programming teams usually use C++ and many of the best selling products on the market are written in C++.
We are working on a product to allow for easier deployment of of .NET applications - 5MB for the required parts of the runtime linked directly into the EXE. This makes .NET a lot more practicle for consumer software.
.Net installation problem?
You may try packaging your software using Installshield that handles the .net and mdac installation
-- or --
Use the remotesoft program that embeds .net into your .executable program.
For what it's worth, we make a product that "links" the .NET Framework and byte code into a single EXE that runs without any installation or file extraction. Unlike Remotesoft, we don't modify the framework or byte code at all (other than to compress it and exclude files you aren't using) - so slightly less likely to run into problems with MS.
I don't want to make any legal analysis on the EULA, etc. here but we have many customers who ship retail and internal applications this way (including departments inside of microsoft).
President / Thinstall.com
I don't want to use this forum for sales pitches, so please contact me privately for followups.
> I'd like to talk to someone who's actually using the product and has deployed it extensively (1,000 or more installations).)
I can put you in touch with someone who has installs in the >100,000 range depending on who you are (contact me privately). We keep our customer list very private. Thinstall packaged Apps are downloaded and installed on more than 1mil PCs per month, so it's not exactly a chicken / egg thing.
> Heck, I'm sure the Joel Spolsky can affort $1k or so for the product if it is EASY and PAINLESS for JOEL and (more importantly to Joel, IMHO) HIS CUSTOMER, you've got a sale. Sell Joel on it and... well... a lot of people listen to Joel (with good reason).
Joel arleady has someone doing an article about Thinstall and we've been in touch with this person. I'm not sure when the article will be out - guessing around 2 week time frame (Thinstall does many other things which are also being covered in the article) but yes - I think it will be great exposure.
> How big would a "hello world" app be in .net with thinstall?
A console hello world is 3.9MB. It's possible to be a little smaller if you exclude Windows 98/ME and Chinese/Japanese support. Further we expect to eventually reach a .NET EXE that is under 3MB. A gui version would be somewhere around 5MB.
> Would the user have to have IE 6 already installed?(.net requires it) if I'm not using any I.E. features?
Min requirements still apply, these are: no win95, IE 5, NT SP3, and a few other minor things. Thinstall automatically checks for these things before running your app and sends the user to appropriate download pages if they don't have them. This is built into all EXEs. IE 5 is required becuase it upgrades many other needed components/DLLs on the system, not because .NET specifically uses IE.
We have concentrated our shrink wrapped product on Macromedia Director with on line versions in Flash. This seems to provide all we need for the best price/performance.
The very thread presupposes that technology is the be-all and end-all ! I beg to differ with this basic premise, more so considering the shrink-wrapped software.
one must ponder over the following questions in the choice of technology !!
what is the application all about ? who is the target customer ? what kind of system resources is he likely to have ? what are his likely expectations from your product ? what is the operating system ?
correct me if i am wrong! I do not think that anybody buys a software because it is being done in VB and Access (or whatever combination you want to choose) ! he / she is buying a shrinkwrapped software hoping that his / her problem areas an be best solved by that software. Obviously, the software must be compatible with the operating system such as Windows 98 or XP or Linux.
every development environment has its own pluses and minuses and these should be viewed in light of the application area and the customer expectations. I remember a client of mine proudly demonstrating his POS software Product developed with the Oracle Backend and I was aghast. this product was supposed to help small traders and grocers and Oracle would be certainly an overkill considering the database management issues alone. Add the license costs of Oracle and the product would be a non-starter ab initio. The moral of this story is "merely because one has lot of expertise in a particular language, does not mean that that should be the dev platform".
if speed of performance is really not a criterion for the customer, such as an acceptable delay of couple of seconds while committing , then do not go in for the real time stuff !
to make it short and sweet, choose an appropriate development platform based on the application area, customer profile etc and not on account of some jazzy feature available in a product !
Again, please remember that no one in their right mind would buy a product because it was developed in X or Y !
Hope this helps