OUR NETWORK: CompTIA TechLore DijitCommunity TiVoCommunity MyOpenRouter About UsAdvertiseContact Us
The Largest Online Community
for Software CEOs and Executives.

 
Learn about scoring Forum's Raw Score: 50910.2
August 22, 2003 10:54 AM

Categories: R&D and Quality

Rating (0 votes)
  • 1
  • 2
  • 3
  • 4
  • 5
Rate This!

Member Avatar

Entrepreneur

Member
Joined: 08/15/2003

VB 6
.Net
C / C++
Delphi
Other (please list)

Discussion:    Add a Comment | Comments 1-25 of 36 | Latest Comment | 1 2 Next »

August 22, 2003 11:00 AM

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.

August 25, 2003 4:16 AM

.. 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.

August 25, 2003 9:35 AM

You wrote:
"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"

REPLY
I've heard this as well, and there's some site on the web that measures the popularity of a prog lang by looking at how often it's mentioned on the web (cool idea for a metric). Delphi is somwhere near #10 (java, C, etc are ahead of it).

HOWEVER, I *wonder* if, for SHRINKWRAP apps, if Delphi is more popular.

So... PERHAPS... if you are looking for a job writing shrinkwrap apps, Delphi might be a more popular lang. And I suspect that you'd make more money working for someone selling shrinkwrap sw than making, say, customized apps for corporations' internal use. This is merely because there's more profit (IME) in shrinkwrap because you're selling the same code 1,000s or millions of times. More company profit means more *ability* to compensate the programmers and perhaps actual higher salaries.

Anyway... that's why I posted the poll.

*I* write in vb6. Considering the move to delphi.

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.

August 25, 2003 10:08 PM

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.

David Locke

August 26, 2003 12:16 AM

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.

August 26, 2003 4:40 AM

Originally posted by Entrepreneur
You wrote:
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.

Regards,
Adrian-Bogdan Andreias

August 26, 2003 10:51 AM

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.

David Locke

August 26, 2003 8:35 PM

Hi Entrepenuer

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?

Susan

August 27, 2003 11:17 AM

Susan,

I was just curious. Our programs were written and updated over the lat 7 years in VB 3.0.

We've stretched that architecture as far as we can. (We started with 3 programs and used that same code to create 15 more programs. The code base is getting very brittle because the first programs were never designed to be expanded).

I've been programming in vb6 for several years, so I'm very comfortable with that. But, it's a "dying language" so I considered a couple of alternatives (Delphi and .net).

Delphi seems to be the best option, by far. Creates small, easily distributed static-linked EXEs. No 20 MB runtime (as .net has).

Only downside of Delphi is that it seems to not be popular. That has two disadvantages: harder to find prexisting solutions ("How do I display a transparent image?, etc.") and harder to find programmers who know it, or another job if MY company ever goes out of business (knock on wood).

It occurred to me that Delphi is less popular than .net or java for programming IN GENERAL, but perhaps not for shrinkwrap apps. So... I thought I'd gather a bit of data with a poll.

So... the reality if that I'm curious.

August 27, 2003 11:51 AM

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.

Susan

August 27, 2003 12:51 PM

Our website is:
http://www.StrokeSoftware.com

I'm the main programmer and we're looking at hiring another programmer (also proficient in VB 6, some familiarity (no experience) in .net, no knowledge of Delphi).

Yes, cost of migrating myself and the other programmer is a significant (dominant) concern.
See, that comment reminds me that this is a CEO oriented site, not a programmer oriented site. Programmers never care about that sort of thing. They want to learn the newest, most exciting language ;-)

Since we're doing a rewrite, I considered that we might want to have a more future-proof language (delphi, .net).

However, our market isn't very "hi tech". This is software for speech therapists and grandmothers. They don't care how shiny the UI is.

I LOVE delphi. I spent a month learning it and it's SWEET. However, it's hard to find prexisting solutions and there's a cost to retrain the other programmer. (I don't mind learning it over time).


In the end... after reviewing many issues... I've concluded that it makes more sense to rewrite in VB 6 and spend the extra time on marketing and jazzing up our website. IF we have to do a rewrite in 5 years, that's OK. (The reality is that I think the code will run just fine for 10 years based on the fact that 64 bit windows, delayed till 2005 (longhorn) will run 32 bit apps transparently. So, we have until 128 bit version of windows (which'll be 10 to 20 years off, I suspect) to rewrite. Heck, maybe our 16 bit apps will run on Longhorn.

ASIDE- that's the thing about writing for Windows. Bill isn't dumb. He knows that if he has backward compatibility, it'll boost sales of new OS's because people won't hesistate to upgrade (for fear of breaking existing software on which they depend).

August 27, 2003 8:35 PM

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.

David Locke

August 28, 2003 4:49 AM

Hello

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..

August 28, 2003 11:57 AM

Originally posted by Dave45000
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.

David Locke


Yes, the VB 6 community calls it "vb.NOT"

VB.net is quite different from vb 6. IN some cases, completely different syntax. There's quite a steep learning curve.

At this point, there is quite a bit of debate about whether .net will survive. A large number of vb6 programmers are moving to Java and other langauges.

The issue here, for us, is that there seems to be more programming for INTERNAL APPS and SERVER-based apps than for shrinkwrap apps that run on the customer's PC. (IMHO).

.Net is designed for that sort of thing. It's a bit chalenging to distribute .net with a 20 mb runtime. Not a problem for internal aps and for server based apps.

My $.03
(Adjusted for inflation).

September 28, 2003 12:46 AM

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.

David Locke

November 14, 2003 3:40 PM

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.

Jonathan

November 14, 2003 6:00 PM

Dave,

Yes, you only have to install the .net runtime once. However:

1. If the installation (or the 20 MB download) is too much for the customer so they don't even TRY the program, you won't even get it installed once.

2. With so much in .net (40 MB worth), there's a lot that can change, requiring a new version of the .net rutime. They are already on the second version (1.0, now 1.1, I think). Either that will continue or bugs won't get fixed very often.

IF I wrote a 1.1 app then, even if the customer has 1.0 installed I need to install .net runtime 1.1

3. You still have to include the 20 MB runtime because you can't COUNT on the .net runtime (or right version, for that matter) being installed.

My $.02 worth.

February 27, 2004 1:56 AM

.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.

Rommel

February 27, 2004 8:51 AM

Originally posted by rsigma
.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.

Rommel



The first option doesn't overcome the barrier to people trying to try our programs out: the 22+ MB download. Also, I;ve read accounts of people having problems with the .net install and blaming the company who's product uses it. And you just don't know WHAT is going into the .net install, so it's dificult to say "oh, I KNOW we didnt' mess up your computer mr. customer"

I don't know anyone who's tried the remotesoft linker. Some people have said that it's illegal to distribut PART of the .net runtime, as the remote linker does. In fact, I've read replies from Microsoft on this saying there are some intellectual property issues with dist part of the runtime. I don't get that: if I can distribute ALL of it, why can't i distibute SOME Of it.


Thanks for the suggestions.

February 27, 2004 5:18 PM

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).

Jonathan Clark
President / Thinstall.com

February 27, 2004 6:01 PM

This is a "which comes first... chicken or the egg" problem.

I don't want to be the first one to use Thinstall or something like that.

I'd like to talk to someone who's actually using the product and has deployed it extensively (1,000 or more installations).)

Every busines has one (most significat) constraint at a time. Find that contstraint, remove it, and you get more profit.

IMHO, biggest constraint for Thinstall right now is CONFIDENCE.


How big would a "hello world" app be in .net with thinstall?
(i.e., what's the minimum overhead of the .net framework?

Would the user have to have IE 6 already installed?(.net requires it) if I'm not using any I.E. features?



I think that if I was confident that thinstall would create a 5 MB or so install and run smoothly, it would be worth the price. I think this is true of other developers as well. 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).




BTW, I kept thinking the product name was thinInstall and almost couldn't find it again.

February 27, 2004 6:50 PM

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.

Jonathan

February 27, 2004 10:59 PM

Thanks for the followup.

I'm not in a rush so I'll wait for Joel's article and then contact you if I still have questions.

May 10, 2004 8:16 AM

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.

MarkM

September 2, 2004 3:17 AM

hi !

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

Badri

Discussion:    Add a Comment | Back to Top | Comments 1-25 of 36 | Latest Comment | 1 2 Next »

You must login to discuss this item.

 
 

Please log in or register to participate in this community!

Log In

Remember

Not a member? Sign up!

Did you forget your password?

You can also log in using OpenID.

close this window
close this window