Which platform?
-
If performance and portability matters, C and or C++ hands down. There is a healthy number of 3rd party ui toolkits and frameworks that give MFC etc a real run for their money. If it's a business app doing the database thing and you aren't worried about future ports to other operating systems, then C# & .net would be the top contender in my opinion. And, C++ isn't going anywhere anytime soon. Disabling user-mode native code would be absolutely insane and incredibly stupid and I seriously doubt that MS is that foolish.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
-
I'm continually mystified how c# has got a rep as an asp language when the vast majority of apps out there written in c# are windows forms applications and it does very well at this.
It think because so much hype is focused on the Web these days. Also, I don't think that Winforms got the same marketing touch and polish that ASP.net did initially. Personally, I think winforms are ok. And the .net delegate model really helps this as well. But, I've found that unless you enforce the use of a MVC style framework on the project you end up with a vb like application with all of the business logic coded in the OnClick methods in the forms code behind.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
-
.net is king of portability, if you can write a .net app you can simply copy the executable to Linux, Mac osx, Sun solaris, * BSD. How c++ can trump that I can't imagine. http://www.mono-project.com/Supported_Platforms[^]
No offense John, but the UI's in mono pretty much suck on non-linux or windows machines. On OS X it looks like crap, as you are greeted with X-Windows style widgets at times. I should also add, that when mono can match the .net api 100% I'd consider it for a db style business app.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
-
.net is king of portability, if you can write a .net app you can simply copy the executable to Linux, Mac osx, Sun solaris, * BSD. How c++ can trump that I can't imagine. http://www.mono-project.com/Supported_Platforms[^]
"Mono current version is 1.2.3 (as of February 2007). This version provides the core API of the .NET Framework 2.0, but its implementation of this API is still incomplete. Complete support for the .NET Framework 2.0, including the .NET 2.0 version of Windows.Forms, is planned for Mono 2.2, by the end of 2007. Implementation of .NET Framework 3.0 is under development under an experimental Mono subproject called Olive, but the availability of a Mono framework supporting .NET 3.0 is still not planned yet." Sounds like you'd be better off using Java. ;)
Kicking squealing Gucci little piggy.
The Rob Blog -
It think because so much hype is focused on the Web these days. Also, I don't think that Winforms got the same marketing touch and polish that ASP.net did initially. Personally, I think winforms are ok. And the .net delegate model really helps this as well. But, I've found that unless you enforce the use of a MVC style framework on the project you end up with a vb like application with all of the business logic coded in the OnClick methods in the forms code behind.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
Chris Austin wrote:
vb like application with all of the business logic coded in the OnClick methods in the forms code behind
Hmm..I'm not sure I understand that. All my business logic is in a business logic library several layers below the UI in typical .net winform and asp.net apps. I think there is nothing ineherently different about winform versus mfc in terms of where the business logic is; you can code it however you want to.
-
No offense John, but the UI's in mono pretty much suck on non-linux or windows machines. On OS X it looks like crap, as you are greeted with X-Windows style widgets at times. I should also add, that when mono can match the .net api 100% I'd consider it for a db style business app.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
Well the UI looks crappy in windows as well unless you snazz it up with a nice 3rd party component library like Telerik or zillions of others. Sure it's a bit early days yet, but most of the 3rd party UI and other component vendors have already signalled their willingness to ensure their stuff runs under MONO so in a couple of years it may not matter what you are running on. Still for sheer portability (however it *looks*) you can't beat MONO.
-
Well the UI looks crappy in windows as well unless you snazz it up with a nice 3rd party component library like Telerik or zillions of others. Sure it's a bit early days yet, but most of the 3rd party UI and other component vendors have already signalled their willingness to ensure their stuff runs under MONO so in a couple of years it may not matter what you are running on. Still for sheer portability (however it *looks*) you can't beat MONO.
If it doesn't support the API 100% it's not portable.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
-
"Mono current version is 1.2.3 (as of February 2007). This version provides the core API of the .NET Framework 2.0, but its implementation of this API is still incomplete. Complete support for the .NET Framework 2.0, including the .NET 2.0 version of Windows.Forms, is planned for Mono 2.2, by the end of 2007. Implementation of .NET Framework 3.0 is under development under an experimental Mono subproject called Olive, but the availability of a Mono framework supporting .NET 3.0 is still not planned yet." Sounds like you'd be better off using Java. ;)
Kicking squealing Gucci little piggy.
The Rob BlogAhh but did you look at what is not actually completed yet? Very little of general use. Let's be honest here, 99% of most deployed .net 2 apps today are almost entirely .net 1.1 compatible and for the few things that they require .net 2 level support such as generics (for example, there are other things obviously) MONO already supports it. The only stuff not supported is more on the esoteric side and if you are starting a new app as the OP is now then it's really not out of the realm of possibility to target .net for MONO for q1 2008. As for .net 3 considering the howls of indignation posted here when anyone talks about using WPF or WCF I really don't see that as any kind of issue at the moment.
-
Chris Austin wrote:
vb like application with all of the business logic coded in the OnClick methods in the forms code behind
Hmm..I'm not sure I understand that. All my business logic is in a business logic library several layers below the UI in typical .net winform and asp.net apps. I think there is nothing ineherently different about winform versus mfc in terms of where the business logic is; you can code it however you want to.
John Cardinal wrote:
ll my business logic is in a business logic library several layers below the UI in typical .net winform and asp.net apps.
As it should be. And, this wasn't meant as a hit against Winforms. But, I've see many very large business apps that use the event methods to drive the all business and data logic. It's more of an hit to the developers of those projects than winforms itself. Sorry tho confuse the matter with my personal pet peeve. :rose:
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
-
If it doesn't support the API 100% it's not portable.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
:rolleyes: Yeah right. If you look at it objectively and I'm sure being a programmer you would want to do so ;), most .net apps deployed today are really at 1.1 level plus a smattering of .net 2 such as generics etc which are already supported in MONO and if you are developing a new app now it's going to take at least a year for anything serious by which time .net 2.0 is projected to be fully supported and much of .net 3. Being even more logical it's unlikely to matter if you are targetting windows anyway, but knowing that ultimately in a year or two your app will simply run on linux, mac, bsd, solaris etc without any modifications is nice future proofing and completely eliminates the concept of the developer "porting" anything at all.
-
:rolleyes: Yeah right. If you look at it objectively and I'm sure being a programmer you would want to do so ;), most .net apps deployed today are really at 1.1 level plus a smattering of .net 2 such as generics etc which are already supported in MONO and if you are developing a new app now it's going to take at least a year for anything serious by which time .net 2.0 is projected to be fully supported and much of .net 3. Being even more logical it's unlikely to matter if you are targetting windows anyway, but knowing that ultimately in a year or two your app will simply run on linux, mac, bsd, solaris etc without any modifications is nice future proofing and completely eliminates the concept of the developer "porting" anything at all.
I find this part of your argument ironic. You have continuously boasted about the time to market of your windows apps using C# & .net (which I am pretty much in agreement). But if you are planning to start development now and portability matters like I stated originally, why would choose a toolkit that may or may not be done when you are? I say the common-sense approach would be to use an existing and proven toolkit that can handle all of you needs now. I understand what you are saying, and if I worked in a windows only or business app only world, I'd agree with most of it.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
-
Ahh but did you look at what is not actually completed yet? Very little of general use. Let's be honest here, 99% of most deployed .net 2 apps today are almost entirely .net 1.1 compatible and for the few things that they require .net 2 level support such as generics (for example, there are other things obviously) MONO already supports it. The only stuff not supported is more on the esoteric side and if you are starting a new app as the OP is now then it's really not out of the realm of possibility to target .net for MONO for q1 2008. As for .net 3 considering the howls of indignation posted here when anyone talks about using WPF or WCF I really don't see that as any kind of issue at the moment.
I actually know very little about .NET/Mono and my comment was really meant with tongue firmly in cheek. :) However, I also wouldn't gamble on something that might or might not be fully ready in 12 months from now (schedules slip, we all know that). I also worry that MS could, if they wanted to, pull the rug from under this project at any time. If I was wanted to write a cross-platform GUI app right now, it would be a toss-up between Java and some form of C++ lib (Qt or wxWidgets perhaps). I wish Mono well, but I think some companies will feel very nervous about it in the short term.
Kicking squealing Gucci little piggy.
The Rob Blog -
I actually know very little about .NET/Mono and my comment was really meant with tongue firmly in cheek. :) However, I also wouldn't gamble on something that might or might not be fully ready in 12 months from now (schedules slip, we all know that). I also worry that MS could, if they wanted to, pull the rug from under this project at any time. If I was wanted to write a cross-platform GUI app right now, it would be a toss-up between Java and some form of C++ lib (Qt or wxWidgets perhaps). I wish Mono well, but I think some companies will feel very nervous about it in the short term.
Kicking squealing Gucci little piggy.
The Rob BlogRob Caldecott wrote:
I also worry that MS could, if they wanted to, pull the rug from under this project at any time
Nope, it's completely out of Microsoft's hands, it's a public ECMA spec. I understand what you're saying, but I think time will bear out MONO and .net in general. If not well then I'll use whatever comes along then, but I'm not writing sofware for 10 years from now, I'm writing software for now and the next few years. I guess I just can't see any reasonable alternative when you're looking at simply running the same executable on windows or linux or solaris or bsd or mac or whatever else they port it to down the road. Since there's not "porting" involved ultimately that makes me very happy as a small developer with limited resources and no idea what the market would be for my app on those platforms. Time will tell, I just want to make sure there's no confusion over what's out there, Java and cross platform C++ libs have had plenty of exposure, I'm just trying to balance that out a little bit.
-
Shog9 wrote:
That said, C++ still wins out if you're looking to go cross-platform.
Not true at all, MONO is just about complete for .net 2 and will be soon for .net "3" and it's supported on many different platforms including windows, linux, mac, bsd etc: http://www.mono-project.com/Supported_Platforms[^] And even better you don't even need to recompile your assemblies, you just copy them over and run the program. Can't beat that.
Fair 'nuff - it's been a while since i looked at Mono, wasn't sure how that was coming along (used to read a really good blog by someone working on it, but that disappeared quite a while ago). Good to know. :)
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
It think because so much hype is focused on the Web these days. Also, I don't think that Winforms got the same marketing touch and polish that ASP.net did initially. Personally, I think winforms are ok. And the .net delegate model really helps this as well. But, I've found that unless you enforce the use of a MVC style framework on the project you end up with a vb like application with all of the business logic coded in the OnClick methods in the forms code behind.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
Chris Austin wrote:
And the .net delegate model really helps this as well. But, I've found that unless you enforce the use of a MVC style framework on the project you end up with a vb like application with all of the business logic coded in the OnClick methods in the forms code behind.
Ya gotta do that anyway. You should see some of the Wizard-generated MFC apps out there... OMG, the horror! FWIW, i consider the initial release of WebForms to be just as incomplete and broken as that of WinForms. 'Thing is, we're so used to lame websites it didn't phase us to the extent that plain-jane WinForms apps do. They've both come a looong way since, but i've yet to see a WebForms app that impressed me the way some of the nicer WinForms apps have... Which just goes to show, i think, that if you get people away from constantly worrying about the poorly-documented side-effects of the Win16-compatible controls they're using, they'll go out and actually write stuff of value - from scratch.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
John Cardinal wrote:
out of my igloo
mail Roger and I a couple... we could use 2 minutes of cool air. :-D
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Vivek Rajan wrote:
For quick, troublefree, functional desktop apps / batch processing - Ruby.
Hows That? Using what UI toolkit? And, how about deplploying that thing? Have you ever tried to build a ui with Ruby? It's a complete pain in the tail using tk or wX. If it weren't for rails, we wouldn't be talking about ruby at all. And, IMHO, batch processing should happen quickly, ruby's current VM is slower than molasses.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
Chris, Using the Fox Toolkit for Ruby (FX-Ruby) http://www.fxruby.org/[^] It took us under 4 days to develop a very complex network analysis tool (with almost all UI elements). For most of our batch processing cases, Ruby is sufficient. Without doubt C# is faster than Ruby, but for those who can make the trade off it is a much better choice than C#. Cross platform, a magnitude of fewer lines of code, easier to maintain, complete type independence, are the immediate advantages.
-
Vivek Rajan wrote:
We have written several Ruby GUI apps (using FxRuby) that are well received.
Win95 look in Vista?? X|
For many in-house apps, this is good enough.
-
So, we are just about to begin a new project. We're now deciding which platform should be used. The bosses asked me about this, and I replied that my bet was on C++ and Win32, as usual. A colleague voted for Java ( X| ) and someone there even dared to suggest VB ( X| X| ). At any rate, the bosses are worried about the future of C++ and Win32. They read somewhere that Microsoft's next OS won't be supporting anything but .NET Framework, so they are not convinced that C++ with Win32 should be the best option. So I'd like to ask for your opinion about this... C++ still has a future? Should we choose C# and .NET over good old C++ and Win32? Thanks.
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
Fernando A. Gomez F. wrote:
At any rate, the bosses are worried about the future of C++ and Win32. They read somewhere that Microsoft's next OS won't be supporting anything but .NET Framework, so they are not convinced that C++ with Win32 should be the best option.
Where did the PHB's read this? Please have them supply a verifiable source and not a random blog like Gizmodo or Digg...
Mike Poz
-
So, we are just about to begin a new project. We're now deciding which platform should be used. The bosses asked me about this, and I replied that my bet was on C++ and Win32, as usual. A colleague voted for Java ( X| ) and someone there even dared to suggest VB ( X| X| ). At any rate, the bosses are worried about the future of C++ and Win32. They read somewhere that Microsoft's next OS won't be supporting anything but .NET Framework, so they are not convinced that C++ with Win32 should be the best option. So I'd like to ask for your opinion about this... C++ still has a future? Should we choose C# and .NET over good old C++ and Win32? Thanks.
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
Why not consider other platforms? How about the new Adobe Apollo? Or go one step forward, and make your app web-based by using Adobe Flex Builder? Currently we are writing a very large application using Flex Builder and its great! Development is very quick and easy (data, by the way, is coming from web-services we write in C#) My roots will always be C++ and Win32, but for new apps you have to consider other things than Microsoft's future support: Ease of development, speed of development, maintainability, etc.