Sounds like the typical Microsoft approach: "we're gonna ignore the topic, and tell you how wonderful our stuff is".
I don't' think their ignoring the issue. They just don't agree that we should be looking for a declarative solution (and I couldn't agree more):
We wish to present [snip-marketing crap] some experiences on the feasibility of standardization of procedural programming models (in contrast to declarative document formats).
They are suggesting we abandon the idea of using declarative markup for web applications and use real programming languages. I seriously doubt they were suggesting they would share Avalon, so I can only assume they were trying to convince us to create a parallel standard. This isn't that different than the approach XUL takes (MS just uses binary code rather than ECMA-script for the logic).
I would like to point out that I didn't mean to put down HTML or HTTP. HTML is a great way to display and link documents. I don't have any problems with HTTP either (although, knowing what we know today, we could make improvements). I also wasn't trying to condemn applications that communicate to a centralized server for content or even processing capabilities. I'm just saying that I don't believe any amount of hacking is going to allow HTML to provide the user experience we ultimately want it to have. Even if we could, the resulting code would be an un-maintainable mess.
We've had perfectly good frameworks for creating rich GUI applications for years (rich UI features with much more maintainable code). We just don't use them for much because we can't get more than a few thousand people to install an application unless it's *really* important to them. I'd write more, but then I'd end up with a term paper about how/why other attempts have failed (applets, activeX, webstart) and pro/cons of solutions in the works today (Avalon, standard flash components).
The term 'web application' in my opinion smells of a hack. We took a nice little text markup language and added a handful of basic UI components, a few scripting languages, CGI, server side content generation engines and standard after standard layered upon each other to try to re-create a user experience that already existed in 1984. The entire reason we choose to make web applications over 'thick client applications' is because of deployment issues. Why don't we just work to make our thick applications more easily distributed instead?
So you're bitching that Java got too complex, and it's going to collapse under its own weight. You say it should be simpler. THAT'S WHAT SPRING IS ALL ABOUT!
J2EE is the result of monster corporations fighting over huge unmanageable solutions. The compromise usually involves using *everyone's* solution (example - both session beans and entity beans exist because IBM and Oracle couldn't agree on a strategy for persistence). Spring is simply the open source community's response: Smaller, lighter, pluggable frameworks. When J2EE collapses under its own weight, those who stick around (ie. don't switch to.NET) will watch frameworks like Spring rise from its ashes to take its place.
After all, Java development environments are well known for thier conciseness and simple nature. Let's throw another couple of tools into the works....
Your comment seems to sum up J2EE fairly well. This is why Spring was created. A container should provide a framework for containing things. period. If you want persistence, add a persistence framework. If you want transactions, add a transaction framework. If you think you need all the extra complexity, feel free to add it.
J2EE, however is complex by default. Spring tries to get away from that. Whether Spring itself can replace J2EE has yet to be shown, but it's philosophy will (at least in those companies flexible enough to change).
J2EE was a good first step, I suppose. They combined all the complex middleware software of the early to mid 90's into one giant all-inclusive spec. Anyone with a couple million man hours could implement the spec and join the market. I guess it made sense at the time.
Now we have a handful of application servers each costing tens of thousands of dollars (not including two very nice open source implementations). Most companies opt to spend $20k on WSAD just for transaction support, or just so they can use the app server's security. They never stop and ask if they need all the power their buying. Spring (and the light weight containers that are sure to follow) will give people an alternative.
I am sure that others have expressed this view before, but is this necessarily going to be A Good Thing? Isn't this going to lead to developers less likely to have special OS X ports that take advantage of specific OS X features?
I think this is a great thing for OSX. OSX support will lead to full featured mono cocoa bindings. This will allow mono and.net developers to port the core logic of thier applications to the mac and still take advantage of OSX facilities for the UI and IO.
Sure, there will always be the lazy programmers who just use mono's winforms implementation to move a windows app to the mac (like all those ugly X11 apps being moved to the mac today). In.net, those winforms implementations can be treated as a stop-gap until a new UI can be written for the app in cocoa#.
I think mono is going to draw out a lot of windows programmers who always wanted to write for the mac or linux, but never wanted to learn the languages (Objective-C or C). Now they can keep working in C#, VB, or whatever. They just pickup a new API (cocoa# or gtk#) and start coding 'native' mac or linux apps.
I've read this before and still don't quite understand. Why would someone intentionally design a rich user interface in CSS, HTML, ECMAscript and XML? Wouldn't it be much easier, more maintainable and just as cross-platform to implement the application in Java or Mono. For that matter, it might have been easier to port an existing C++ library to a bunch of platforms. What's the advantage?
I can't speak for C++, but in the Java world most of these checks are built into the IDEs. Eclipse needs to compile the source to show most errors (which it does every time you save a file). It's a bit of a pain in my opinion. I've gotten used to IntelliJ IDEA, which parses the file with every keystroke. I assume it doesn't do this from scratch each time, since it's still very responsive. It also keeps some sort of index in memory so it can quickly show bindings to other source code (this method is an implementation of this interface, for example). The markup for these links are updated with every keystroke without pegging the CPU.
That said, I doubt this is as feasible with C++. Java IDEs can use type information to provide these messages without any assumptions. Managed C++ may have access to these features, but I haven't played with that to know what type info is available.
I agree with what you're saying, but I think you miss another big hole in the Linux desktop: You won't even try to install software if you can't get your hardware installed. Even though hardware installation isn't controlled by GNOME or KDE, it effects them in a big way. A user needs to be able to install a sound card before they will even think about installing a game. Currently the installation process (for many distributions) gets a large amount of the hardware correctly, but if it misses anything, or the user makes a change to the system? Joe Sixpack *might* be willing to unzip and untar the source for the driver, but recompile the kernel? Linux is so far away from being consumer usable, I don't even think its worth discussing at this point.
That being said, I'm having a great time putting together my MythTv box.. Linux does have it's place, and it does very well there.
The list of music (and many properties of the music) is stored in the library file (a huge xml file). There is only one library per user per machine. Even if you have a central location for the files, the library won't know when you add a song. You would have to go to each computer and individually add the song to the library for each machine (and each user on the machine).
The very first program I install is VNC. I have all my software on one computer on my network. Once VNC in installed, I connect from my laptop and finish setting up the computer from the couch. While programs install on the new computer, I can actually *do* something on the laptop (or just veg in front of the TV).
isnt avalon the new windows Quartz extreme knockoff?
Generally speaking, yes. It does have some different features, but it does basically the same thing. Here are some better links than a simple google search would give you:
Mozilla has the GRE (Gecko Runtime Engine) which is all that is needed to execute XUL apps. The GRE can be loaded without the browser. Last time I check I think it was a little under 10 megs which is not too bad since 1 GRE can support multiple XUL apps.
A one-time runtime installation was also the case with Java, flash and even the gtk. None of those framworks ever took off on the windows desktop. The best solution for deployment of thick clients is going to take advantage of the runtime already running on the client machine. Sure you can use a third party library for the widgets (if it's small enough and completly portable), but even ONE install procedure is still more than Microsoft's platform is going to require.
I liked the sentiment of your post, but I have two minor criticisms:
1) Mono is not the new Wine. The mono implementation of WinForms may be (at one time they talked about binding it to wine). I see the main use of Mono to be building Linux applications that only *happen* to work on windows. At first they will use GTK# and later some new better UI toolkit (Avalon# ???, XUL# ???)
2) Mono opens the doors for many more programmers to contribute to Linux, but not just unwittingly. When (if) mono become commonplace on the Linux desktop, Window programmers and Java programmers will flock to the Linux desktop. Thousands of people who have been reading/. for years, wanting to contribute (but were unwilling to go back to C) will help build the next Linux desktop.
I for one welcome the change. God knows there's plenty of work.
What about the deployment issues. Why would a bank use XUL for an application (forcing all thier users to download mozilla), when they can let them run native Longhorn appps from thier browser without any installation? XUL may compete fine with XMAL, but neither is especially helpful for solving the real problem.
Making a good Swing app takes a long time and a lot of effort. Swing is designed to be flexible rather than easy and was intended to be extended and 'cleaned up' by IDE developers. Any extensions to Swing are usually considered unclean (proprietary) by the Java community and ignored..Net on the other hand was built in layers to provide flexible underpinnings under ready to use simple components (like SWT and JFace). Swing in comparison feels academic and half completed.
All that said. I've been working in Swing for a living for the past 4 years. I've been watching mono for a while now, hoping they would deal with the UI issue. Bindings to GTK and Cocoa are cute, but Avalon has the potential to make the open source community look pretty stupid (despite it's lack of real innovation). If Miguel has any ideas for how to catch up again I'd like to help. Swing was fun, but there's no future in it.
The player should also learn from my actions. If I skip a song five seconds after it starts playing, it should know to rate that song lower (play it less often). If I manually play a song (or albumm), it should keep track of that too.
iTunes lets you create a playlist based on how many times you've heard a song, but it increments the count even if the song was selected randomly (it doesn't pay attention to user choice). The information is also only used to create playlists (not to weight shuffle selection).
To tell you the truth, I would love to have a "Heavy Rotation" feature on my iPod (Not HEAVY - like Clear Channel). I wouldn't mind shuffling through all of my music, but weighting the selection based on rating and playing my newer music a little more often than the rest.
It seems like iTunes' smart playlists almost get you there. I just need a way to join playlists together based on weights.
I know your joking, but I've heard XBoxes make great MythTV front ends. They even have a Knoppmyth install for it. I just started putting together my first Myth box, and have thought about used XBoxes for front end boxes elsewhere in the house.
Why does PlayFair make copies of the song? That's nice for portable players (where the codec can't be replaced), but I'd like to see the music players ignore the DRM all together. That way I don't have to make new copies of my files after I buy them. After all, most of us are just trying to solve the same problem: We either have too many computers (more than three) or we run an unsupported platform (linux). A tool that leaves the DRM in place might not be looked down upon as badly either.
First of all, you make some really good points. I mention this, because this is slashdot - it took me by surprise.
I think our difference comes down to a prediction of the future. You believe that decisions of the marketplace would lead to the cannibalization of society if left unchecked. I believe that those checks are necessary in some cases (to make sure we don't spread our resources too thin, for example by outsourcing to multiple countries causing little economic growth in any one country). Overall, however I think most of these checks are unnecessary (it also bothers me that they could be driven by prejudice and fear). I think that jobs going to India will hurt the US in the short run, but make a huge impact on the future of India (think Japan). Rather than cannibalizing our society, India will become a new market that didn't exist before. Not only will we become a market for them, but they will become a market for us.
I don't believe there is a finite amount of wealth. I don't believe that India is taking anything from our society that they won't return later with interest. But I admit, this is a of a leap of faith in my argument. People who believe otherwise are scared and those who think they 'deserve' their job (and won't stay competitive) should be scared.
Exactly! There is a burning desire in the Open Source community to leave everything up to the user. This makes configuration files (or configuration screens), long and unmanageable. While flexibility is great for advanced users, beginners are scared away by the complexity. One of the solutions for this is called 'progressive disclosure'. Its a theory in UI that simple task should be simple, but the more advanced tasks should be close at hand for those adventurous enough to look around. The best implementations of progressive disclosure show hints to the user tempting them to explore the advanced features without forcing those features on them.
There are good examples of this in Word, Excel, IntelliJ IDEA and the Mac desktop. Any user can immediately start using the product. But little by little, the more advanced features show themselves.
Examples of UIs that go against progressive disclosure include wizards, clippy and requiring the user to search for configuration options among page after page of options.
Slashdot Mirror
Sounds like the typical Microsoft approach: "we're gonna ignore the topic, and tell you how wonderful our stuff is".
I don't' think their ignoring the issue. They just don't agree that we should be looking for a declarative solution (and I couldn't agree more):
We wish to present [snip-marketing crap] some experiences on the feasibility of standardization of procedural programming models (in contrast to declarative document formats).
They are suggesting we abandon the idea of using declarative markup for web applications and use real programming languages. I seriously doubt they were suggesting they would share Avalon, so I can only assume they were trying to convince us to create a parallel standard. This isn't that different than the approach XUL takes (MS just uses binary code rather than ECMA-script for the logic).
I would like to point out that I didn't mean to put down HTML or HTTP. HTML is a great way to display and link documents. I don't have any problems with HTTP either (although, knowing what we know today, we could make improvements). I also wasn't trying to condemn applications that communicate to a centralized server for content or even processing capabilities. I'm just saying that I don't believe any amount of hacking is going to allow HTML to provide the user experience we ultimately want it to have. Even if we could, the resulting code would be an un-maintainable mess.
We've had perfectly good frameworks for creating rich GUI applications for years (rich UI features with much more maintainable code). We just don't use them for much because we can't get more than a few thousand people to install an application unless it's *really* important to them. I'd write more, but then I'd end up with a term paper about how/why other attempts have failed (applets, activeX, webstart) and pro/cons of solutions in the works today (Avalon, standard flash components).
The term 'web application' in my opinion smells of a hack. We took a nice little text markup language and added a handful of basic UI components, a few scripting languages, CGI, server side content generation engines and standard after standard layered upon each other to try to re-create a user experience that already existed in 1984. The entire reason we choose to make web applications over 'thick client applications' is because of deployment issues. Why don't we just work to make our thick applications more easily distributed instead?
So you're bitching that Java got too complex, and it's going to collapse under its own weight. You say it should be simpler. THAT'S WHAT SPRING IS ALL ABOUT!
.NET) will watch frameworks like Spring rise from its ashes to take its place.
J2EE is the result of monster corporations fighting over huge unmanageable solutions. The compromise usually involves using *everyone's* solution (example - both session beans and entity beans exist because IBM and Oracle couldn't agree on a strategy for persistence). Spring is simply the open source community's response: Smaller, lighter, pluggable frameworks. When J2EE collapses under its own weight, those who stick around (ie. don't switch to
After all, Java development environments are well known for thier conciseness and simple nature. Let's throw another couple of tools into the works....
Your comment seems to sum up J2EE fairly well. This is why Spring was created. A container should provide a framework for containing things. period. If you want persistence, add a persistence framework. If you want transactions, add a transaction framework. If you think you need all the extra complexity, feel free to add it.
J2EE, however is complex by default. Spring tries to get away from that. Whether Spring itself can replace J2EE has yet to be shown, but it's philosophy will (at least in those companies flexible enough to change).
J2EE was a good first step, I suppose. They combined all the complex middleware software of the early to mid 90's into one giant all-inclusive spec. Anyone with a couple million man hours could implement the spec and join the market. I guess it made sense at the time.
Now we have a handful of application servers each costing tens of thousands of dollars (not including two very nice open source implementations). Most companies opt to spend $20k on WSAD just for transaction support, or just so they can use the app server's security. They never stop and ask if they need all the power their buying. Spring (and the light weight containers that are sure to follow) will give people an alternative.
I am sure that others have expressed this view before, but is this necessarily going to be A Good Thing? Isn't this going to lead to developers less likely to have special OS X ports that take advantage of specific OS X features?
.net developers to port the core logic of thier applications to the mac and still take advantage of OSX facilities for the UI and IO.
.net, those winforms implementations can be treated as a stop-gap until a new UI can be written for the app in cocoa#.
I think this is a great thing for OSX. OSX support will lead to full featured mono cocoa bindings. This will allow mono and
Sure, there will always be the lazy programmers who just use mono's winforms implementation to move a windows app to the mac (like all those ugly X11 apps being moved to the mac today). In
I think mono is going to draw out a lot of windows programmers who always wanted to write for the mac or linux, but never wanted to learn the languages (Objective-C or C). Now they can keep working in C#, VB, or whatever. They just pickup a new API (cocoa# or gtk#) and start coding 'native' mac or linux apps.
It's in it's first beta. 1.0 is due at the end of June. Here's the story. And the roadmap
I've read this before and still don't quite understand. Why would someone intentionally design a rich user interface in CSS, HTML, ECMAscript and XML? Wouldn't it be much easier, more maintainable and just as cross-platform to implement the application in Java or Mono. For that matter, it might have been easier to port an existing C++ library to a bunch of platforms. What's the advantage?
I can't speak for C++, but in the Java world most of these checks are built into the IDEs. Eclipse needs to compile the source to show most errors (which it does every time you save a file). It's a bit of a pain in my opinion. I've gotten used to IntelliJ IDEA, which parses the file with every keystroke. I assume it doesn't do this from scratch each time, since it's still very responsive. It also keeps some sort of index in memory so it can quickly show bindings to other source code (this method is an implementation of this interface, for example). The markup for these links are updated with every keystroke without pegging the CPU.
That said, I doubt this is as feasible with C++. Java IDEs can use type information to provide these messages without any assumptions. Managed C++ may have access to these features, but I haven't played with that to know what type info is available.
I agree with what you're saying, but I think you miss another big hole in the Linux desktop: You won't even try to install software if you can't get your hardware installed. Even though hardware installation isn't controlled by GNOME or KDE, it effects them in a big way. A user needs to be able to install a sound card before they will even think about installing a game. Currently the installation process (for many distributions) gets a large amount of the hardware correctly, but if it misses anything, or the user makes a change to the system? Joe Sixpack *might* be willing to unzip and untar the source for the driver, but recompile the kernel? Linux is so far away from being consumer usable, I don't even think its worth discussing at this point.
That being said, I'm having a great time putting together my MythTv box.. Linux does have it's place, and it does very well there.
The list of music (and many properties of the music) is stored in the library file (a huge xml file). There is only one library per user per machine. Even if you have a central location for the files, the library won't know when you add a song. You would have to go to each computer and individually add the song to the library for each machine (and each user on the machine).
The very first program I install is VNC. I have all my software on one computer on my network. Once VNC in installed, I connect from my laptop and finish setting up the computer from the couch. While programs install on the new computer, I can actually *do* something on the laptop (or just veg in front of the TV).
isnt avalon the new windows Quartz extreme knockoff?
Generally speaking, yes. It does have some different features, but it does basically the same thing. Here are some better links than a simple google search would give you:
Avalon
The Blinking Lights Division
FYI, there was a lot of talk in the minutes about XAML, which is similar to XUL. It's a part of Avalon as well.
Mozilla has the GRE (Gecko Runtime Engine) which is all that is needed to execute XUL apps. The GRE can be loaded without the browser. Last time I check I think it was a little under 10 megs which is not too bad since 1 GRE can support multiple XUL apps.
A one-time runtime installation was also the case with Java, flash and even the gtk. None of those framworks ever took off on the windows desktop. The best solution for deployment of thick clients is going to take advantage of the runtime already running on the client machine. Sure you can use a third party library for the widgets (if it's small enough and completly portable), but even ONE install procedure is still more than Microsoft's platform is going to require.
I liked the sentiment of your post, but I have two minor criticisms:
/. for years, wanting to contribute (but were unwilling to go back to C) will help build the next Linux desktop.
1) Mono is not the new Wine. The mono implementation of WinForms may be (at one time they talked about binding it to wine). I see the main use of Mono to be building Linux applications that only *happen* to work on windows. At first they will use GTK# and later some new better UI toolkit (Avalon# ???, XUL# ???)
2) Mono opens the doors for many more programmers to contribute to Linux, but not just unwittingly. When (if) mono become commonplace on the Linux desktop, Window programmers and Java programmers will flock to the Linux desktop. Thousands of people who have been reading
I for one welcome the change. God knows there's plenty of work.
What about the deployment issues. Why would a bank use XUL for an application (forcing all thier users to download mozilla), when they can let them run native Longhorn appps from thier browser without any installation? XUL may compete fine with XMAL, but neither is especially helpful for solving the real problem.
Making a good Swing app takes a long time and a lot of effort. Swing is designed to be flexible rather than easy and was intended to be extended and 'cleaned up' by IDE developers. Any extensions to Swing are usually considered unclean (proprietary) by the Java community and ignored. .Net on the other hand was built in layers to provide flexible underpinnings under ready to use simple components (like SWT and JFace). Swing in comparison feels academic and half completed.
All that said. I've been working in Swing for a living for the past 4 years. I've been watching mono for a while now, hoping they would deal with the UI issue. Bindings to GTK and Cocoa are cute, but Avalon has the potential to make the open source community look pretty stupid (despite it's lack of real innovation). If Miguel has any ideas for how to catch up again I'd like to help. Swing was fun, but there's no future in it.
The player should also learn from my actions. If I skip a song five seconds after it starts playing, it should know to rate that song lower (play it less often). If I manually play a song (or albumm), it should keep track of that too.
iTunes lets you create a playlist based on how many times you've heard a song, but it increments the count even if the song was selected randomly (it doesn't pay attention to user choice). The information is also only used to create playlists (not to weight shuffle selection).
To tell you the truth, I would love to have a "Heavy Rotation" feature on my iPod (Not HEAVY - like Clear Channel). I wouldn't mind shuffling through all of my music, but weighting the selection based on rating and playing my newer music a little more often than the rest.
It seems like iTunes' smart playlists almost get you there. I just need a way to join playlists together based on weights.
I know your joking, but I've heard XBoxes make great MythTV front ends. They even have a Knoppmyth install for it. I just started putting together my first Myth box, and have thought about used XBoxes for front end boxes elsewhere in the house.
Why does PlayFair make copies of the song? That's nice for portable players (where the codec can't be replaced), but I'd like to see the music players ignore the DRM all together. That way I don't have to make new copies of my files after I buy them. After all, most of us are just trying to solve the same problem: We either have too many computers (more than three) or we run an unsupported platform (linux). A tool that leaves the DRM in place might not be looked down upon as badly either.
C was a higher level language... 30 years ago.
First of all, you make some really good points. I mention this, because this is slashdot - it took me by surprise.
I think our difference comes down to a prediction of the future. You believe that decisions of the marketplace would lead to the cannibalization of society if left unchecked. I believe that those checks are necessary in some cases (to make sure we don't spread our resources too thin, for example by outsourcing to multiple countries causing little economic growth in any one country). Overall, however I think most of these checks are unnecessary (it also bothers me that they could be driven by prejudice and fear). I think that jobs going to India will hurt the US in the short run, but make a huge impact on the future of India (think Japan). Rather than cannibalizing our society, India will become a new market that didn't exist before. Not only will we become a market for them, but they will become a market for us.
I don't believe there is a finite amount of wealth. I don't believe that India is taking anything from our society that they won't return later with interest. But I admit, this is a of a leap of faith in my argument. People who believe otherwise are scared and those who think they 'deserve' their job (and won't stay competitive) should be scared.
What does pretty have to do with UI design? Did you read any of his post?
Exactly! There is a burning desire in the Open Source community to leave everything up to the user. This makes configuration files (or configuration screens), long and unmanageable. While flexibility is great for advanced users, beginners are scared away by the complexity. One of the solutions for this is called 'progressive disclosure'. Its a theory in UI that simple task should be simple, but the more advanced tasks should be close at hand for those adventurous enough to look around. The best implementations of progressive disclosure show hints to the user tempting them to explore the advanced features without forcing those features on them.
There are good examples of this in Word, Excel, IntelliJ IDEA and the Mac desktop. Any user can immediately start using the product. But little by little, the more advanced features show themselves.
Examples of UIs that go against progressive disclosure include wizards, clippy and requiring the user to search for configuration options among page after page of options.