A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I'm working on an application written in Java. It is not aimed at users of a specific platform, and probably most of the users will probably be Windows based. I would like the application to grow and mature over time, expand it, add features, and hope that it has a good lifespan.
Simple question: Can an ISV really sell a product that is written in Java?
.NET - Isn't that basically the same as Java with a different kind of bytecode?
C++ MFC - Does it have a future, is the development time too great?
Friday, September 30, 2005
You might want to elaborate on the application or problem domain you are seeking to solve. A mention of the target audience wouldn't hurt. A thorough consideration for factors like these (and more) may help you find some fundamentally insurmountable* deal-breaker/show-stopper within a specific solution framework.
* On the other hand, aren't you getting paid to solve big problems? I guess you (or someone you hire) better be pretty hard-working and/or talented.
Shrinkwrapped desktop application that will have a growing feature set over time.
Target audience - home user. No web technologies.
I like executables derived from native code, but I like the development turnaround time of Java - my only concern is whether or not home user's mind an application written in Java ( don't get me wrong - it is of professional quality).
Saturday, October 01, 2005
The big issue I see for this is deployment.
They arent going to be too happy about having to also download the JVM (or the .NET runtime for .NET which as you say is currently beset by similar issues).
If its for a business it should not be a big problem. For home use it could be. The JVM is an annoyiningly large download, and if they are running other Java based apps that need a different version of Java and they use the standard installer it will cause problems.
If you are selling a CD you can probably (check with Sun for any licensing issues) include the JVM on it and customise its installation a bit - ie copying it over without screwing with JAVA_HOME and CLASSPATH etc... and start your app using a batch file? (There should actually be better ways of doing it. Indeed I think this is one of the reasons java to .exe compilers were popular for a while back when java first came out).
Sunday, October 02, 2005
Well, I personally don't believe end-users (especially home users) have any perferences about which language you are using.
What a customer cares is your software's functionality and user interface design, which are mapping to the following two questions:
1. what is your idea?
2. how to present your idea?
If you had a very good idea and you did represent your idea very well, you would get customers.
In an other word, its really hard to convence a person to buy a poorly functioned application with ugly user interface with the only reason of being written in the programming lauage that her/he like most.
I have one of my (full time job) companies software installed on my home PC. Its Java. the JRE is packaged with the software and installs at 35 MB. The application amounts to 7MB. However, its functionality is very very sexy indeed - when you install the software the JRE is put on seamlessly. Most users don't notice. The fact we write in Java gives us a really fast development turn around, and we have many Linux and Mac users who we support.
For my home-project I'm currently writing in Java and moving rapidly to producing a really nice application from the useability point of view. I would love to package the application on CD although I'm sure I will allow download installs from a web site too.
True, the JRE is installed on the target machine (not pleasent), but the target audience probably won't notice - disk space is cheap, download time over high-speed internet won't be too long, and I think I can provide new features quickly to users via download updates. I'm thinking of sticking with Java for this application and I will see what the target audience reaction is on my beta release - I'm not depending on this work for income as I have a full time job, so if the users really hate it I can rewrite in another language.
Thanks for all the input.
Sunday, October 02, 2005
>>.NET - Isn't that basically the same as Java with a >>different kind of bytecode?
But, may be you need to check based on the problem you need to solve. If either .NET or Java offers more quick solution for your problem you can go in that path. Yes, byetecode are different in those 2.
>>C++ MFC - Does it have a future, is the development time >>too great?
It has future, MS is going to support both in Future too. Even for longhorn they are going to release MFC updated framework. But, when it comes to development time it takes more compare to .NET or Java for sure. Also, you need to have good MFC/C++ programmers to bring the expected deliverables.
Also, If you cannot solve a portion of problems using other langauges/RAD tools. You can go for MFC/C++.
Monday, October 03, 2005
When you say you're not sure if users will accept a Java application, are you referring to the installation of the JRE or the look and feel of the app?
For the former, JDeveloper bundles the JDK and installs it with the app in the same directory, and refers to it directly. I would be annoyed if software silently installed a new JRE system-wide. If it was just local to the app, no harm done, and now you only have one JVM target to test.
I know a lot of people (or a vocal minority) complain about the look and feel about Swing apps, since they don't look native to the O/S. If that is your issue, you may want to look at SWT ( http://www.eclipse.org/swt/ ). I'm a web developer, though, and can't speak about it from experience, but Eclipse seems to use it to good effect.
Monday, October 03, 2005
Obviously with Java, the right way is to deploy the JVM to support the application locally - this I have no problem with... The biggest answer came from my wife this weekend. I was talking about the forum and what you guys said while we were having dinner. She said one thing that convinced me I was thinking in the wrong way about my language problems:
She then went on to tell me that the target audience generally don't care about the language that the application was written in, or even how it were installed - so long as it doesn't cause them problems. She said that people want an application that looks nice and is easy and fun to use, and that THIS is the biggest concern.
Once again, I put my 'development' hat on while thinking through this problem, and not my 'user' hat... She got to the crux of the problem in two words... very cool.
Let's say you do it this way:
Flash front-end, statically compiled backend. Flash speaks to backend via xmlhttprequest pointing at 127.0.0.1:some_benign_port.
I think this above arrangement of tools may achieve quite a bit for your requirements:
Achieving sexy: You do your GUI in Flash, you grab a world-renown Flash-/UI- artist to push out something even the Mac UI Group would be proud of. Really easy to use. Think Microsoft Bob--but sensibly sexy.
Achieving performance: backend done in C or C++ (with Delphi/Real Basic being a backup, if RAD is of primary importance)
Achieving small downloads: See previous choices--already pre-optimized. Flash is still. C/C++/Delphi all small. Not sure about Real Basic.
Java like RAD of GUI: Flash is definitely there. Especially if all you are trying to do is do a GUI for something like Nero. (However once you start targeting Joe MBA instead of Joe's Aunty Martha--you'll miss Swing/MFC/SWT/Windows Forms and they way they scale in forms-related work.)
Java like RAD of backend logic: Delphi is there. But if you are a C++ god.... Real Basic has a smaller market of third-party components than Delphi. However if you don't need to buy any libraries you are ducky, it wins in portability.
FAQ on this combination:
Where do I find an installer since I am not using VS.NET's installer builder?
You'll need to rely on a 3rd-party installation/upgrade module that can take care of the DLL hell. This is not hard to source. There are many competent installers on the market.
Will this pointing at 127.0.0.1:unused_port work?
Personal firewalls will complain. But you can tell the user what's up during the installation and on your site FAQ.
Is Delphi portable?
I don't know if Borland still cares about the Linux port, the general consensus is it's Windows-only. So if you are interested in portability then you'll have to do a C++ back-end that uses open-source libraries already known for being well-established in the Mac and Linux space. So if you are a C++ god, this is great. Real Basic is cross-platform.
xmlhttprequest won't be necessary if a cross-platform projector exist on all platforms where Flash exist. A projector is a COM container that plays a swf file and can interact with it. Passing events back and forth. There's an ActiveX container but none exist to work with Cocoa/Carbon/Qt/Gtk. If Macromedia had this they could actually realize their claim that Flash is ready for rich internet applications, but they probably wouldn't do it as long as Microsoft doesn't care to compete with them in this space. Microsoft is interested, as seen by the Expression suite in the works--so maybe Macromedia will change their attitude. Otherwise people will just laugh when they think cross-platform RIA and Flash--laugh hard.
All the famous apps that you think about when you think about "shrinkwrap apps" are written in raw C using Win32 or C++ using MFC. It is the safe choice, insofar as many people have done it before.
Java shrinkwrap apps have had lots of failures. The cause seems to be that they stumble into a situation that cannot be solved without a huge cost. It might be speed or appearance of the app. I think that that it is possible to get a saleable shrinkwrap app out but either you are lucky or you are willing to become an expert at JVM internals (i.e. C code), JNI and Swing or SWT internals (more C code) when the situation warrants. Most companies aren't prepared for that situation so they just die.
.NET apps seem to be coming along well with a good number of freeware, shareware and low-cost shrinkwrap apps doing reasonably well. Microsoft has one or two major products that are all .NET though everything else is stuck in C and C++ code. .NET is similar to Java in implementation but its superior access to Microsoft technologies makes it better for shrinkwrap.
If I were to choose today, I'd probably choose C++/MFC (or, actually, C++ and wxWidgets but that's more of a risk that I'm personally willing to take) if I was planning a world-class, go-against-the-big-guys shrinkwrap app, though I'd still get .NET plenty of thought. If it is a smaller microISV type effort, I'd probably choose .NET.
Wednesday, October 05, 2005
Flash is a good idea and I'm somewhat confused as to why more companies haven't used it. Flash has been used for a lot of corporate training apps: it works well and is very visual.
Most shrinkwrap probably isn't done in Flash because Flash is oriented towards artists, rather than developers. The environment is very visual and it is hard to find serious developers who have become experts in it. (If you are a microISV, this may not matter. I knew a developer who did a bunch of Flash for a microISV and it worked out fine.) You may also have difficulty with a sophisticated architecture since Flash isn't designed for full-fledged OOP.
Wednesday, October 05, 2005
"Java shrinkwrap apps have had lots of failures."
Care to elaborate?
".NET apps seem to be coming along well with a good number of freeware, shareware and low-cost shrinkwrap apps doing reasonably well."
Name two shrinkwrap apps. Can I buy them at CompUSA or Fry's?
I have experience with both of these technologies. Both are bad news for the shrinkwrap market. Java is at least possible to deliver in this fashion, dotNet is not.
.Net requires the framework, which means modifying the users system. There are still lots of PC's that just won't run the dotNet framework, and telling the user to buy a new PC means "no Sale"
Your post sounds like you are parroting something you have heard, as opposed to experienced.
Thursday, October 06, 2005
I guess that I can't really defend my opinion of Java shrinkwrap apps because the reviews of MoneyDance are respectable these days, after being a dog in the beginning. Like I said, I think that it's doable, apparently some people are even doing it, although I'd be hesitant to recommend Java to anybody except an absolute expert in it. (He'd probably say: "Phzzt! What do you know?")
As for .NET, I believe that Microsoft InfoPath is written entirely in .NET. FeedDemon is entirely in .NET, I think. Admittedly, you can't buy either of these things in Fry's or CompUSA. But I use the shrinkwrap moniker in the same way that Joel Spolsky does to include very GUI, commercial software sold over the Internet.
Sure, a C++ guy might pooh-pooh this whole discussion and just say flat out that everything not written in C++ is, by definition, crud. It'd be hard to dispute because, like I said, C/C++ was probably used for 98% of existing shrinkwrap apps today and, well, it's easy to nitpick that 2% to death and just call it 0%.
I'd love to see an article that discusses your experiences in concrete terms. I'm not aware of many good shrinkwrap apps written in Java and would like to know why the teams didn't encounter the challenges that I described. I'd also be interested to know why .NET is a dead issue: I've seen some very promising apps written with it.
Thursday, October 06, 2005
I think that you've also got to break the shrinkwrap market into a couple of parts.
I'd call VMware a shrinkwrap app but home users with Win95 and Win98 systems can't run it.
I'd agree that a low-end checkbook app written on .NET wouldn't work, if you are targetting consumers who are stuck with Win95 and Win98.
But many developers and some companies are dumping support for everything under Windows 2000 anyway. Rightly or wrongly, they conclude that people stuck on anything older than Windows 2000 aren't likely to buy any new software, anyway. So, for some, .NET is very viable because the "interesting" part of the market actually can run .NET.
Thursday, October 06, 2005
Say I decide to user C++... I'm thinking if I do this I would use wxWidget as a UI toolkit, rather than MFC. I have a couple of issues though:
a) Lack of library support (that you DO get with Java) for C++, and to complexity required to write code to do simple tasks (GregorianCalendar comes to mind - I need to write my own specialized Calendar component, but use a Gregorian Calendar at the lower level). I don't want to mess with coding things I don't want to code - I want to code the product itself.
b) The other issue is whether in two years time of supporting the product I have complex legacy code that is simply a pain to maintain. For all the issues around Java that C++ people don't like (and I like both languages for different reasons), Java is a nice language to maintain and work with - its easily pliable (Of course it also depends how you write the code).
c) A JRE CAN be easily installed seamlessly with the product (for example (I can't afford it), but install anywhere allows this) and many of the historic install problems are taken away from the user. I do agree that an .exe is even easier.
I'm more than happy to write the application in C++ if I can convince myself that the above issues are really non-issues. To get over my pain I have installed wxWidgets at home and I am this weekend working on a C++ blitz to see how much trouble I get myself in.
I'm at a cross roads on deciding which technology to use for the application. Its definately going to be a desktop application for the long haul. I have written some of the code in Java already and I will play with C++ to see how easy it will allow me to implement the features in a rapid and bug free way (down to me I guess, but the nature of the language also impacts this) to give the user the best user experience. I've discounted .NET before I even started this question on technologies. The only reason is that if I need to use a 'bulky' cross-platform language, I think Java fits the mold better.
"I'd love to see an article that discusses your experiences in concrete terms. I'm not aware of many good shrinkwrap apps written in Java and would like to know why the teams didn't encounter the challenges that I described. I'd also be interested to know why .NET is a dead issue: I've seen some very promising apps written with it. "
I think that article might be like an old person talking about their surgeries or an athelete talking about accomplishments - boooring.
The dotNet thing isnt dead, its in transition. Give it 3-5 years and it can be viable. Right now there aren't shrinkwrap apps (apps wrapped in plastic sold on shelves) because it doesn't make sense to do so. C++ and/or VB6 still work fine and will require less maintenance than anything produced in today's version of dotNet.
Java already works in most end-user cases. The code is easy to maintain. It's not a cure-all, but it is a cure-much. You don't see shrinkwrap apps for it either, because if the client has a slow machine, you get a returned package. However in controlled deployments rollout is smoother than anything else I have experienced.
The java horror stories I have seen are mostly people doing things that are crazy (using enum as a variable name) where they should expect to get burnt.
My dotNet horror stories come from toolkit inspired dll hell and permissions issues in IIS. Neither are really dotNet problems, so I don't blame the platform for them. It's just that I foresee having to fix broken code when the new dotNet comes out, and I haven't had much of that problem with java.
Comes down to time and money...
Friday, October 07, 2005
I like wxWidgets. Heck, I even use it. But, by choosing wxWidgets over MFC, you give up very nice, off-the-shelf libraries like BCGSoft ( http://www.bcgsoft.com/ ). Also, know ahead of time that you'll spend about 10% extra time fixing up wxWidgets internal code that you wouldn't spend on MFC. On the flip side, wxWidgets has the capability to go to multiple platforms, it has a vibrant community and is a lot of fun.
a) You may miss the Java libraries a little bit but that's not where you burn your time on a shrinkwrap app. You burn time on fixing the zillion little bugs in getting all your messages/events going to the right place, writing paint routines and getting all your windows to cooperate. While I can commiserate with wanting to focus on the logic of what you're trying to do, shrinkwrap apps are 90% GUI.
b) You're pretty much correct here. But shrinkwrap is about creating the best and easiest user experience possible, not about maintainability. It's a tradeoff between making a world-class GUI and a respectable, maintainable but non-world-class GUI.
c) Install is one issue but others are speed and control over the GUI. I think that it is possible but very hard to make a Java shrinkwrap app. Like I said, you may just run into a wall where things get horribly complicated, very, very quickly.
In the end, you may decide that the trouble of a world-class GUI isn't worth it. World class GUIs are very expensive in time and effort.
Currently I don't have money for off the shelf GUI libraries, hence the idea to use wxWidgets. Any other options? Interesting what you say about world class GUIs being about speed (as well as user experience). To be honest, I work commercially with Java for my full time job. Occasionally I need to write code in C and C++ (daemons, database code, etc), but I feel kind of dirty using Java for my shrinkwrap idea ... I can't explain why - it just feels that way (and I can't explain it!!).
That guy, flash91, and I are pretty much in agreement, despite appearances.
At Fry's and CompUSA, the apps are nearly all C/C++. His reasons are as good as any but I'd add that very few new apps actually get into those places. PhotoShop, Microsoft Office, clip art, TurboTax, Quicken and nearly all the rest have been around for 10 years or more and they're written in C/C++ because that was really the only choice back when they were started. Games are a different matter but still all C/C++ for reasons not related to being old codebases.
We seem to agree on Java. If your GUI merely needs to be adequate, it's fine. If your GUI needs to be great, it's mostly not fine.
I'd agree that it will take 3-5 years for CompUSA and Fry's to sell shrinkwrap apps built on .NET. But I don't think that CompUSA or Fry's are an important market for new apps, anyway.
The use of the term, "shrinkwrap", obviously caused some discord. I took a more liberal definition than he did. Whether you are a 1-man or 500-man company and whether you are new startup or not will have a very big effect on how you see this whole situation.
If you use C++ with either wxWidgets or MFC, it almost certainly means that you'll need to purchase a legitimate copy of Microsoft Visual Studio at some point which costs over $1000. So, C++ isn't really possible on the cheap. You may decide not to buy an off-the-shelf GUI library but it won't be because of the cost. With MFC, you can always buy and integrate the library later but, with wxWidgets, it simply isn't supported. Either choice is fine as long as you know what you're giving up. Which you do.
Of course, with Java, you get Eclipse for free.
If it were me, I'd look at the nature of your idea. If it is something that you have huge ambitions for and you fully intend to try your hardest to make a company that pulls in 10s of millions of dollars, a world class GUI might be a necessity. Otherwise, it might make sense to do a good-enough GUI in Java.
Well, in terms of application...
Currently I have a full time development position with a very good company and I lead a team on a very successful server + ui intensive project. I intend to do the following at home:
1) Keep full time job.
2) Work at home to produce a product that I want to use. I have several friends that want to use it, and there may be a potential of selling it. Its a desktop product.
3) Keep my day job and make some money on the side.
4) I need to write my own components and be able to draw calendars + graphs + charts - these have to be bespoke as they have non-off-the-shelf elements (for example, the calendar has various markers on it indicating a certain thing to be done on that day).
5) Provide long term support and mature the product for friends. I will want to get a web site and perhaps try to sell it locally in my community.
6) Won't be heartbroken if it doesn't sell, because another idea will come along... But I think there is potential to make some sales, at least...
7) I have some code written in Java and its qutie UI intensive, but doesn't feel quite right. I work with UI on Java and web in my day job and we have successful products that the customers (not private desktop PCs) love. I know my UI.
8) I AM personally tending toward C++ + wxWidget/MFC. I will have to go on the cheap until I can make some sales (if I can), then I will have money for proper tools. I think the users will be EXPECTING a native look and feel application and one that doesn't seem clunky - I know I would be. Competitor (if you like) products are all native code.
Immediate thoughts would be well received.
I think you are making the right choice. Following successful competitors is usually a good plan.
I do java but to get it to look and feel "right" I use riverlayout and kunststoff. Even then I don't get the nice c++ startup time.
Friday, October 07, 2005
Visual C++ 2005 is launching in November. If you look around, you might be able to get a Visual C++ 2005 Beta 2 for free. Dr. Dobbs Journal and some other magazines had little coupons that you could send in and get the beta. Also, it was easy to get the beta at various trade shows. You may have friends that got the beta but never used it so you might ask around.
I actually installed Visual C++ 2005 Beta 2 and compiled wxWidgets with only a few easily fixable warnings and errors. The few wxWidgets samples that I tried worked fine. No worries at all.
Ahead-of-time compilation is still alive and well in Java space. Always an option. Another classic is GCJ. Not sure about the quality of their work though, maybe a compiler-expert can chip in?
Microsoft is related projects as well.
And a Hotspot compiler essentially compiles the code into the final executable. By generating bytecodes stored in java packages and dotnet assemblies you enable platform independence. So basically your only responsibility as a ISV is to obfuscate the bytecode since if you don't do that you are essentially giving the source code away.
I guess projectors do exist for Flash on Macs. It's called Zinc.
And you can even code in C#. Xamlon is also trying to do something similar but they don't do Macs/Linux.
For C++ the best toolkit available is QT
Full crossplatform support and exteremely well documented.
A very powerful signal/slot paradigm, which will make you wonder why none ever did it before.
I have used wxWidgets and QT and wxWidgets seems much less polished than QT ( I have spent many weeks trying to get the wxWidgets FL docking library to actually work without crashing the app)
If you want to do Windows native apps and forego the crossplatorm and C++, Delphi all the way. Delphi apps can be migrated to .NET by just recompiling. That will keep you futureproofed.
Even if you do go for Java, Borland JBuilder is worth looking at.
Sunday, October 09, 2005
Talking about Java and GUI I have to say that Eclipse has possibly the best GUI I have ever seen. The fact that it is succesful with one of the most discerning audiences, software developers, who use the tool 9-5 every day also speaks volumes. It is SWT but still 100% Java.
Of course I have no idea how much they had to work to get Eclipse where it is at, but the sheer extensibility and also the rate of improvement of the app suggests that it is indeed a great architecture (as opposed to a kludge of workarounds).
I'll go even further. FL in wxWidgets is so bad that it isn't even worth using, assuming you get it compiled. I ended up writing my own.
That's the 10% that I talk about.
Monday, October 10, 2005
I think that Eclipse is adequate but not great, in both the looks and functionality department. I'd also say that developers are less picky than ordinary users in many circumstances, including with Eclipse.
Monday, October 10, 2005
I'm tending toward C++ and MFC now.
I worked on Java, C++ and wxWidgets, and C++ and MFC this weekend to do a comparison of technologies for my app. Here are my findings:
1) I'm not sure that Java Swing will cut it for a desktop application that is going to home users. Its great for web applications (such as the one I am working on in my day job), but when you do a comparison of it agaist MFC/wxWidget/C++ you notice:
a) Large deployment.
b) Its visibly slow compared to its native language counterpart.
c) It doesn't look as good.
I didn't try SWT because I just felt if I use Java I should use Swing. No other reasons.
2) I really liked wxWidgets, but I felt there might be gaps in it that would mean more work from me in order to work around or patch up (such as build warnings when building the libs). I wondered whether there was enough widgets or whether the number of supported widgets may be too few compared to MFC. wxWidgets looked a bit like MFC to me (I'm not familiar with wxWidget/MFC programming by the way).
3) My first ever play with MFC was a little tricky due to lack of tutorials, but setting up a project in VC++ 6 was easy enough and coding (not using the app wizard) seemed straight forward. My incling was that there may be more MFC widgets in the libraries than wxWidgets, and perhaps even user support may be more than wxWidgets.
So, my final unbiased analysis was this:
a) I never considered .NET.
b) Java UI seems 'amateurish' compared with what I can do in native code with native widgets.
c) wxWidgets is a great idea but I mature it is.
d) MFC would support 95% of my customer base (Windows). If I can afford to lose 5% of my customer base (Linux/MAC), which realistically I can, and Visual C++ 2005 is coming out in November, and MFC will be supported in the future (?) then this seems like a sensible choice given its maturity. wxWidgets doesn't seem to offer anything extra that I can find, apart from cross-platform compilation (I wonder how easy that really is?).
I want to build an application that gives a really fine user experience. I think, perhaps, C++ and MFC may be the answer. Of course I curse myself for thinking this. I'm not really a Microsoft advocate, but 95% of my userbase will run the application on Windows, and the use of C++ means a lot more complexity than Java. But I've been writing software for over 20 years now and I've been there and done that before, so I shall rise to the challenge of using these technologies. Right tools for the right job, and I will enjoy every minute!
From what I've heard, SWT is finely tuned for Eclipse but not for development of other apps. It makes sense: Eclipse is the short term main goal of SWT and a general purpose GUI framework is a long term, nice-to-have goal of SWT. So, you are right in mostly not researching SWT.
Swing is what it is. Swing advocates might be able to make a great looking Swing app but nearly everybody else can't. It's not technically impossible but that doesn't mean that it's worth doing, either. Your conclusions are solid here.
The basic widgets that come with wxWidgets and MFC are similar. Maybe wxWidgets has a few more basic widgets but they are somewhat more hacky and inflexible. MFC and wxWidgets are very, very similar in programming. But, of course, you can't buy any fancy wxWidgets widgets but you can buy tons of fancy MFC widgets. There is also exactly one wxWidgets book and, oh, maybe a million MFC books.
If you had worked on a serious MFC project in the past few years, I might recommend that you go with wxWidgets. You'd be able to leverage your MFC understanding to see how similar wxWidgets is to it and make it work. But, my impression is that you don't have any MFC experience which makes it harder to be successful with a framework that has one book to learn from and is more do-it-yourself in terms of quality and components.
With wxWidgets, I always program it for Windows, try it on Linux and then am amazed that it works as well as it does. It isn't instant or great; you do have to fiddle with it and then tune, test and customize. But it is cross-platform.
Still, I think MFC is a good choice for your situation.
In terms of MFC support, Microsoft has a mixed record. When .NET first came out, Microsoft beat pretty hard on developers saying, "MFC is dead! Long live .NET!" Then, about a year or two ago, they reversed themselves 180 degrees. Suddenly, it was, "Lots of people are using MFC and .NET isn't good for everything. We're improving MFC, encouraging people to use MFC and MFC is a first class tool."
Tuesday, October 11, 2005
Very interesting what you say about the future of MFC - I guess a lot of people have been or will be asking the same question in the light of .NET. You are right - I've stayed away from MFC by choice in my career, but currently it seems to be the right tool for the right job. Especially if supported by a first class IDE/compiler (VC++ 2005 - I hope it is as good as the older products).
I'm pretty comfortable with my analysis and decisions. If anyone can pursuade me against the choice I would love to hear. Of course I've been developing Java in the recent past so I'm a little apprahensive about getting back into C++, but I used to work on cell phone software/UI in native code and have come from a game programming background before my current networking software life - I'll get it back again!
I love Java and I always thought I'd use it for development from now until eternity - until I had an idea for a desktop product that might enable me to make some money (yes, greed here - hey, why not use my skills for myself?).
Thanks for the help.
If you are only going after the Windows users you should consider VB6. The development time is a lot quicker than C++/MCC.
Tuesday, October 11, 2005
I don't know much about VB, however I am biased - I'm a hardcore lowlevel developer from the old school. True this shouldn't matter, but it does. I also don't believe that VB will give me the power that I need to create a stunning UI and the kind of low level control in the future... Of course this is just an opinion - I would feel more comfortable writing in C++ and I may decide to support other OSs in the future.
Tuesday, October 11, 2005
Perhaps you might take a step back and do a story-board or two. Get the UI and features fleshed out and planned out from Version 1.0 to three years after that (do some hypothetical sketches). Some of the more serious questions you'll have to ask are:
* Why do your customers want to buy your software? What is their problems? How big? How much does it cost them? What is your solution (elevator statement)? Is your solution bigger or smaller than the problem? What do you know are some competiting solutions? (dig a bit, do some lateral thinking here) What is the cost of the solution? How constant are these ROI ratios in a relationship between your customer and you or between your customer and your competition? Can you retain these customers?
* Based on your understanding of your customers, will they demand bug-fixes at a schedule you can't do if you use older technologies like c, or are you so familiar with it you'll do better to develop in it than in some new language/framework? What if you end up with so many bugs you can't take care of it without quitting your day job or your customers leave you.
* Will they demand feature-adds? What's the best case scenario, worst case with scheules and your free time? Can you hack it if it turns out you need to do this full time? Is this the life-style you want? Can you handle giving it up again if you end up having to manage a team? Can you keep learning for the next 15 years? It's never the same, but it's going to be the same problem to you.
* Will they be very demanding of the GUI, or it maybe the third program they'll ever meet after Microsoft Word and IE?
* Are you expecting power users demanding complicated property panels, task panes, and complicated inter-relations between GUI components such as drag-and-drop and perspectives (Outlook, Excel)? Or are we talking wizards to set things up and a status view after (Nero) for the casual user?
* Are you going to end up making the interface easier and easier (and refraining from adding features in the long run that are more frills and checkboxes than core competencies) or are you chasing expected competition?
* Do you have the domain down cold? Are you on good terms with your customers and have a clear idea of where they are going and how you can help? Can you make them happy without outside help (GUI, DB work, system administration, site development)?
* Are your competitions more nimble than you? Are they going to out flank you if you have a large verbose code-base that can't be easily changed?
I'd think the more you can test some of your assumptions (answers to the above questions) on a few friends the better.
I understand your hesitation when I speak of VB6. However, have a look at Microsoft's Antispyware program. This program was developed with VB6. This is a modern impressive application developed with a tool that many would have you believe is obsolete.
The fact of the matter is, in my opinion, for the type of app you are considering VB6 is going to be hard to beat. What do others think about VB6 for Bob's requirements?
Wednesday, October 12, 2005
I'm biased against Visual Basic for shrinkwrap apps and I'll tell you why.
With Visual Basic, you get into this situation where you can't make it look or do what you want. "No problem," VBers say, "Just knock out a DLL in C++, suck it into VB and you're done."
Now, wait, so now they're saying that the programmer now has to be an expert at both Visual Basic and Visual C++? Two languages, two environments, two mindsets. That doesn't sound more productive.
If it's all C++ (or all Visual Basic), you just learn one language, hire people who know one language, never need any "glue" (to cross between the languages) and it is all straightforwardly debuggable in one environment.
I may be overplaying the problem. Joel was successful with CityDesk by using this approach (although I wonder if the various quirks and bugs that drove me away from that product are caused by it). It is clearly workable. It is an option. But it wouldn't be my choice, at least not for shrinkwrap.
Wednesday, October 12, 2005
Let me qualify my comments by saying that I write SCADA app's not shrink-wrap software so I am not an expert on the subject.
Don't get me wrong, I would not try to write Excel or AutoCAD in VB6 and I don't know exactly what Bob is planning. However, in the 6 or so years that I used VB5/6 it was not very often that I said " I can't do this with basic I am going to have to write something in C/C++ " Now more that once I bought a control from a third party supplier but what's wrong with that? They all worked great and made my app look better.
99% of Bob's end-users won't know or care what the program is written in. Does it look nice, does it run fast, is it user friendly and does it help me do something I was having trouble doing before.
The company I work for ported most of our app's to .Net a few years ago from VB6. Do they run better? No. Do they look better? No. The bottom line is we probably spent allot of money and time for nothing. Oh well, Microsoft likes us. VB6 is not going anywhere. There is still a huge amount of development with it and support for it that's not going to go away any time soon. It is still possible to turn out a quality app with VB6 that will run fine on any Microsoft Windows operating system. This is critical for Bob's proposed application.
Wednesday, October 12, 2005
I agree. If your app isn't Excel or AutoCAD, use Visual Basic. If your app is Excel or AutoCAD (i.e. shrinkwrap), consider all the viewpoints in the previous discussion.
Wednesday, October 12, 2005
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz