Exactly. Who's bright idea was it to make web applications rely on RDBMS systems that depend on a single (easily corrupted) binary database? A database that is modified practically everytime you enter or update data. A file that keeps growing the longer you run your web application and as a consquence slows your machine more and more.
Not being able to unload an assembly from an appdomain is a seriously flaw in.NET's design. I'm hoping it'll be fixed in V2.0.
For anyone who doesn't know already, Java classes are unloaded when there are no more instances of the class and when the class loader has no more references.
You can do "drag'n'drop" with Swing layout managers too. Check out Forte or Sun ONE. I don't see how your layout manager control is any better than Swing's layout management system.
The Windows API not supporting layout management is partially (if not mostly) responsible for the modal dialog boxes and non-resizable dialog boxes.
The same thing is happening with Windows Forms....You'd think with all that time inbetween J++ and C# they would have upgraded the UI toolkit to use more modern techniques.
Don't know about you but I'm tired of the fact that every time I use a swing based app(like some of the popular IDE's) I need a minimum of 512mb of ram.
Hmm...price you pay I guess. Wait until Windows.NET. You'll need 512MB of ram and a new 3D card.
PS. Sorry about being snide. Been dealing with far too many idiotic VB programmers recently.
Oh, and FYI (because you appear to be very ignorant wrt anything non-MS) Swing supports absolute layout management for those people who still need that kind of thing.
found you comments amusing about how layouts suck in windows forms... That has always been my feel about awt/swing. Why the hell should I align things left and right? Top/bottom? I want direct placement... I don't wont to align it to anything...
I guess you don't like HTML eh? All that top/bottom placement stuff must be too confusing for you! You should stick with your fixed sized dialogs.
If you look at *ANY* UI you will notice that things almost *NEVER* need to be placed absolutely. The OK button for example is placed on the bottom-middle-left of a message box. The absolute pixel position is irrelevant. If you're writing fixed sized dialogs and UIs I seriously recommend you reconsider.
Think of all the times you've had to deal with fixed sized dialog boxes. Remember how sucky it was when the windows open/save dialogs couldn't be resized??
Every tried to type in change the PATH environment variable under NT? The text box they provide fits like 100 characters...and the dialog ISN'T resizable for absolutely no reason except that windows doesn't support layout management. The text box could have easily been defined to be 90% of the width of the dialog instead of 300 pixels (or whatever).
Take a look at any office 2003 application and tell me it isn't beautiful to look at... Windows forms rock...(and yes I know you can reimplement that look and feel in swing but it's insanely slow, memory intensive comparatively and quite difficult to do besides.)
Take a look at OSX and tell me it isn't beutiful -- and it supports proper scaling and dynamic layouts.
Office 2003 looks great until you start to use it and realise that opening the options dialog locks you out of the rest of the application (because it's modal).
I know you can reimplement that look and feel in swing but it's insanely slow, memory intensive comparatively and quite difficult to do besides.)
When was the last time you used swing? It may be memory intensive (memory is cheap as dirt these days) but it's certainly not slow. In fact, Java2D is far faster than the hideous GDI+ based System.Drawing APIs.
PS. Are you or have you ever been a VB programmer?
In my opinion it still doesn't really have an equal in Java
In terms of power and being brilliant to work with Swing kicks Windows Forms' ass. Try making a TreeView that's synchronized with the FileSystem or an XML DOM in Windows Forms and tell me you don't have state problems.
And Windows Forms layout management SUCKS LIKE HELL. Try this: Anchor a control on the left. Anchor another control on the right. Now resize your window and notice how on of the controls overlaps the otherone when the window is too small. Looks very, very ugly. With Swing the controls would resize dynamically until their minimum size is reached at which point a scrollbar would appear.
Makes me wonder if you even understand what MVC means? You as the developer should implement the MVC pattern for your app
Makes me wonder if you know what it means. I'm not talking about applying MVC to a web application. I'm talking about applying the MVC pattern to GUIs. Windows Forms doesn't support the MVC pattern. "Hacking" on MVC by wrapping all the controls isn't sufficient because you lose many of the advantages of MVC. For example, the ListView control *STORES* the data it displays. A clear violation of the seperation of the data and the view. Making a model-aware ListView based on the Microsoft ListView would still mean that the underlying UI control stores the data (albeit more transparently). This has serious performance issues. Try making a JList in Java and display 2^32 items. It takes *no time* and it's fast. Try doing that with Windows Forms and tell me when your computer memory runs out.
Again your understanding is flawed. Rhino does not compile JavaScript to java opcodes as a Mono-based JavaScript engine would, so it cannot take advantage of lots of VM features. The two are completely different under the hood.
Well actually...Rhino can compile JavaScript directly bytecode.
How about a language for developing GUIs that doesn't suck? Yes, I like Python too, but horror stories of large apps getting extra-buggy when written using Python due to its heritage of being a scripting language haunt me. Java is dead on the desktop basically, it had its chance (for years!) and blew it. Now it's the turn of.NET
The Windows Forms API looks like it was designed by a 12 year old. Not MVC based making it horrible to work with if you want to do anything complicated.
What bullshit. If you use mail you use System.Web.Mail namespace which may or *maynot* use MAPI underneath. It's completely managed and the MAPI api is never exposed. For the record, Mono has a working implementation of the System.Web.Mail namespace.
Your dam prolly won't give many people time to run whereas the nuclear reactor will. It's also easier to take down a reactor than it is to take down millions of litres of water.
And I bet the New York will still be standing after the reactor goes. New York will need some radiation cleanup but it won't be as bad as all the damage caused by the silt and water:P.
I never said that there haven't been nuclear disasters. You had an issue with my question "When was the last time you saw a meltdown?" and you were wrong.
Whether nuclear disasters outnumber or are worse than damn disasters is a different discussion...
nuclear power, leading to large amounts of nuclear waste and with an increased risk of a meltdown occurring in a 2nd/3rd world country with dubious safety records and high levels of corruption... drawing fire from the same people who are criticising the environmental impact of the dam
The nuclear waste gets buried and when was the lsat time you saw a meltdown?
And what kind of impact do you think the dam bursting would have hmmm!? The dam (to me) looks far more dangerous than a few nuclear power stations. Containing a nuclear disaster is nothing compared to containing all that water.
Slashdot Mirror
Exactly. Who's bright idea was it to make web applications rely on RDBMS systems that depend on a single (easily corrupted) binary database? A database that is modified practically everytime you enter or update data. A file that keeps growing the longer you run your web application and as a consquence slows your machine more and more.
Did the title remind anyone else of the scene where those Nurv goons were remotely watching and stealing code from OSS developers in real time?
Not being able to unload an assembly from an appdomain is a seriously flaw in .NET's design. I'm hoping it'll be fixed in V2.0.
For anyone who doesn't know already, Java classes are unloaded when there are no more instances of the class and when the class loader has no more references.
Apologies again. I thought you were yet another VB programmer who thinks that everything remotely different from VB is wrong. All my fault. *sigh*
Ahh....I see what you mean now.
Do you mean you can't tell where a window is on the desktop? JFrame.getLocation would do that...
You can do "drag'n'drop" with Swing layout managers too. Check out Forte or Sun ONE. I don't see how your layout manager control is any better than Swing's layout management system.
.NET. You'll need 512MB of ram and a new 3D card.
The Windows API not supporting layout management is partially (if not mostly) responsible for the modal dialog boxes and non-resizable dialog boxes.
The same thing is happening with Windows Forms....You'd think with all that time inbetween J++ and C# they would have upgraded the UI toolkit to use more modern techniques.
Don't know about you but I'm tired of the fact that every time I use a swing based app(like some of the popular IDE's) I need a minimum of 512mb of ram.
Hmm...price you pay I guess. Wait until Windows
PS. Sorry about being snide. Been dealing with far too many idiotic VB programmers recently.
Oh, and FYI (because you appear to be very ignorant wrt anything non-MS) Swing supports absolute layout management for those people who still need that kind of thing.
found you comments amusing about how layouts suck in windows forms... That has always been my feel about awt/swing. Why the hell should I align things left and right? Top/bottom? I want direct placement... I don't wont to align it to anything...
I guess you don't like HTML eh? All that top/bottom placement stuff must be too confusing for you! You should stick with your fixed sized dialogs.
If you look at *ANY* UI you will notice that things almost *NEVER* need to be placed absolutely. The OK button for example is placed on the bottom-middle-left of a message box. The absolute pixel position is irrelevant. If you're writing fixed sized dialogs and UIs I seriously recommend you reconsider.
Think of all the times you've had to deal with fixed sized dialog boxes. Remember how sucky it was when the windows open/save dialogs couldn't be resized??
Every tried to type in change the PATH environment variable under NT? The text box they provide fits like 100 characters
Take a look at any office 2003 application and tell me it isn't beautiful to look at... Windows forms rock...(and yes I know you can reimplement that look and feel in swing but it's insanely slow, memory intensive comparatively and quite difficult to do besides.)
Take a look at OSX and tell me it isn't beutiful -- and it supports proper scaling and dynamic layouts.
Office 2003 looks great until you start to use it and realise that opening the options dialog locks you out of the rest of the application (because it's modal).
I know you can reimplement that look and feel in swing but it's insanely slow, memory intensive comparatively and quite difficult to do besides.)
When was the last time you used swing? It may be memory intensive (memory is cheap as dirt these days) but it's certainly not slow. In fact, Java2D is far faster than the hideous GDI+ based System.Drawing APIs.
PS. Are you or have you ever been a VB programmer?
Makes me wonder if you even understand what MVC means? You as the developer should implement the MVC pattern for your app
I still can't get over how thick this statement is. Aparently MVC is only for application developers and not GUI API developers?
In my opinion it still doesn't really have an equal in Java
In terms of power and being brilliant to work with Swing kicks Windows Forms' ass. Try making a TreeView that's synchronized with the FileSystem or an XML DOM in Windows Forms and tell me you don't have state problems.
And Windows Forms layout management SUCKS LIKE HELL. Try this: Anchor a control on the left. Anchor another control on the right. Now resize your window and notice how on of the controls overlaps the otherone when the window is too small. Looks very, very ugly. With Swing the controls would resize dynamically until their minimum size is reached at which point a scrollbar would appear.
Makes me wonder if you even understand what MVC means? You as the developer should implement the MVC pattern for your app
Makes me wonder if you know what it means. I'm not talking about applying MVC to a web application. I'm talking about applying the MVC pattern to GUIs. Windows Forms doesn't support the MVC pattern. "Hacking" on MVC by wrapping all the controls isn't sufficient because you lose many of the advantages of MVC. For example, the ListView control *STORES* the data it displays. A clear violation of the seperation of the data and the view. Making a model-aware ListView based on the Microsoft ListView would still mean that the underlying UI control stores the data (albeit more transparently). This has serious performance issues. Try making a JList in Java and display 2^32 items. It takes *no time* and it's fast. Try doing that with Windows Forms and tell me when your computer memory runs out.
Again your understanding is flawed. Rhino does not compile JavaScript to java opcodes as a Mono-based JavaScript engine would, so it cannot take advantage of lots of VM features. The two are completely different under the hood.
Well actually...Rhino can compile JavaScript directly bytecode.
How about a language for developing GUIs that doesn't suck? Yes, I like Python too, but horror stories of large apps getting extra-buggy when written using Python due to its heritage of being a scripting language haunt me. Java is dead on the desktop basically, it had its chance (for years!) and blew it. Now it's the turn of
The Windows Forms API looks like it was designed by a 12 year old. Not MVC based making it horrible to work with if you want to do anything complicated.
What bullshit. If you use mail you use System.Web.Mail namespace which may or *maynot* use MAPI underneath. It's completely managed and the MAPI api is never exposed. For the record, Mono has a working implementation of the System.Web.Mail namespace.
You're not married are you? :)
Yeah, working if you don't count the windows specific APIs like MAPI, etc.
Since when did ASP.NET have anything to do with MAPI?
Or more importantly...why would they need to kill people to steal *open source* code?
You do realise that they aren't just writing a compiler right? Do you think they're idiots?Sheesh.. they've even got a working version of ASP.NET.
that Ximian are encouraging people to risk cloning a substantial portion of Microsoft's IP.
I guess you totally hate the WINE project then huh?
100 million nanoscopic hair each centimetre square
Is it just me or also you? I think you talk like Dr. Seuss too.
If I built both then I could always use the dam to take out the reactor if it went critical :P.
Your dam prolly won't give many people time to run whereas the nuclear reactor will. It's also easier to take down a reactor than it is to take down millions of litres of water.
:P.
And I bet the New York will still be standing after the reactor goes. New York will need some radiation cleanup but it won't be as bad as all the damage caused by the silt and water
I never said that there haven't been nuclear disasters. You had an issue with my question "When was the last time you saw a meltdown?" and you were wrong.
Whether nuclear disasters outnumber or are worse than damn disasters is a different discussion...
I assume you're talking about Chernobyl which DID NOT have a meltdown.
nuclear power, leading to large amounts of nuclear waste and with an increased risk of a meltdown occurring in a 2nd/3rd world country with dubious safety records and high levels of corruption
The nuclear waste gets buried and when was the lsat time you saw a meltdown?
And what kind of impact do you think the dam bursting would have hmmm!? The dam (to me) looks far more dangerous than a few nuclear power stations. Containing a nuclear disaster is nothing compared to containing all that water.