Which platform?
-
John Cardinal wrote:
Well to be fair my 39th birthday passed (unnoticed here as usual, I guess I should stop being such a dick if I want people to wish me happy birthday ) a few days ago and I haven't lost any knack or desire for grasping new technologies unlike the bunch of luddites that hang out here.
Well, you are in Canada and all that below-freezing weather slows down your ageing, so your brain age must be that of a 20 year old American :rolleyes:
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. (*Sample chapter available online*) -
Depending on the type of application, you might even consider Ruby. We have written several Ruby GUI apps (using FxRuby) that are well received. 1) For performance and heavy lifting (apps like Internet Explorer, Database servers, networking, high end graphics) - C++. 2) For quick, troublefree, functional desktop apps / batch processing - Ruby. 3) For web - C# / ASP
Vivek Rajan wrote:
We have written several Ruby GUI apps (using FxRuby) that are well received.
Win95 look in Vista?? X|
-
It depends on the app. C# w/ .NET has become a far better, far less dirty "Quick 'n' Dirty" RAD platform than VB ever was. And it's flexible enough that you can still use many non-managed components, if that's a necessity. That said, C++ still wins out if you're looking to go cross-platform. C++ still wins out if you're looking for maximum performance (provided you have the skills to actually take advantage of what it gives you). And straight Win32 wins out if... well, screw that. In the scenarios where straight Win32 wins out, the alternatives are too horrible to even contemplate, much less actively consider alternatives. So, yeah. If you're doing the standard "business app" where the bottlenecks are in front of the keyboard or across the network, C# on .NET. If you're doing a web app, C# on ASP.NET or Java are both good choices.
----
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
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.
-
.net - no questions.
.net is a box of never ending treasures, every day I get find another gem.
norm .net wrote:
.net - no questions.
What else? I don't understand the discussions here! :confused: :~ :suss:
-
Depending on the type of application, you might even consider Ruby. We have written several Ruby GUI apps (using FxRuby) that are well received. 1) For performance and heavy lifting (apps like Internet Explorer, Database servers, networking, high end graphics) - C++. 2) For quick, troublefree, functional desktop apps / batch processing - Ruby. 3) For web - C# / ASP
-
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