``It is a pity that KDE 4.0 wasn't really ready to be a 4.0 release''
Which raises a good question: What to call the releases leading up to what will be the next major release?
There are several schemes in common use, but I haven't seen one that really strikes me as the right way to go.
For the software that I develop, I simply don't make a release until I feel it is usable. Intermediate versions can be referred to by the identifier assigned to them by the version control system. For actual release numbers, I use the major.minor.micro scheme, where major version changes indicate changes that aren't backward compatible, minor version increases indicate added features, and micro version changes indicate bugfixes.
This works, because the software I develop is simple, and I can put together a new stable release in limited time. But for a project the size of KDE, doing a major overhaul and getting it stable can easily take years and require a lot of communication and testing. You probably do want intermediate versions to be packaged and easily installable by end users, because you want those users to try it out and give you feedback. So you will want to make releases that aren't your new major version yet. But how do you label them? Obviously, calling them X.0 is not the way to go... but what is?
Interesting. That's the first time I've heard about an Uranium shortage.
Over where I live, fission plants are being touted as the answer to our energy needs. They're supposed to be clean, low-health risk (lower risk than coal plants, at least), and fuel is supposed to be plentiful. I thought the only thing the government wasn't telling us is that it's actually one of the more expensive sources of energy, but now you're saying that Uranium is actually in short supply?
Regardless, I think the answer to any energy shortage is, first of all, conservation (which we can easily do a lot more of!) and, secondly, renewable resources, including widely known ones such as wind and solar energy, but also less widely known ones such as biofuels (you do need something you can control the output of, after all, rather than having to depend on the weather).
``Security has become the number 1 reason that software is now a continuous version stream with patches rolling out every 6 minutes.''
Which is why I am such a fan of distributions that don't do feature updates. Keep everything the same, only sending out updates to fix bugs.
``The UNIX-like OSes of the world have always handled this concept more gracefully, but when you look at windows that wants to reboot 4 times a week for updates it seems much more like an afterthought.''
I am not so sure. I think Unix got lucky, in that it grew up in a world where computer security was much less of an issue than nowadays. By the time Internet worms and the like became widespread, Unix had had a long time to mature, and faded to the background enough that people had mostly forgotten about it (how many people know what HP-UX is anymore?)
So you don't see a lot of malware targeting Unix, because it isn't such a big target, because there are a plethora of different, non-binary compatible versions out there, and because most of the outdated versions are mostly out of use and forgotten, whereas the up to date versions are quite mature.
The big exception to this is popular software that is getting many features added to it rapidly, such as the Linux kernel, various popular desktop programs, and many, many web applications: these are both rife with bugs and often break compatibility on updates. On the other hand, they're still popular, because people want those features.
The beauty of the Unix universe is that you can have it your way. You can have a stable system with few bugs and little maintenance, or you can have a cutting edge system with the latest features, at the cost of more bugs and time spent on maintenance.
In case you're not getting the joke: The very definition of open-source states that modification and distribution must be allowed.
So yes. If it is open source, you _are_ allowed to distribute and modify, exactly as I stated.
Also, Free software and open source software are _not_ different things (and neither does the article referenced by the parent claim they are). The difference is not in the software, but in the philosophy: open source is the apolitical term, whereas Free software is the term preferred by those who wish all software to be Free software.
``Just because someone allows you to use the source of a program doesn't mean you can legally do anything you want with it.''
That is correct, but just being allowed to use the source in some way does not make the software open source, in the same way that not being charged for the software doesn't make it Free software. Some of Microsoft's earlier "shared source" initiatives can serve as an example of this: you get to see the source code, but you are not allowed to modify and distribute it - therefore, it is not open source.
``Just want you all to know the difference so you're not confused in the future.''
I hope that my post has managed to clear up some confusion. And please, don't go off misrepresenting open source anymore.
The Real WTF is the managers holding up this guy as an example to aspire to, without knowing _how_ what he did benefited the project. If they had done even something as basic as setting goals for the project (e.g. features that need to be implemented, issue tracker tickets resolved,...) and measured by that, they would have gotten a better metric. Or they could have asked another coder. But no, they went and invented a metric, evaluated team members by it, and went to sing the praises of the member who came out on top... without ever stopping to wonder if their metric was any good. Brillant.
No longer do you have to depend on Microsoft for bugfixes. No longer do you have to hope that, one day, they will implement the feature you're waiting for. Microsoft is no longer the only party allowed to improve the platform or tailor it to your needs.
Yes, you are, and yes, they are, because in the end it's them who will distribute their.NET Runtime, not you. Your fork may have feature X added, and bug Y corrected, but it doesn't matter because in the end, you'll have to code for their platform implementation.''
I don't see why. Since the platform is open source, you can distribute your improved version of it.
Making it open source allows you to use it, distribute it, and modify it. Even if nobody ports it to your favorite platform, it's still a win for the users. No longer do you have to depend on Microsoft for bugfixes. No longer do you have to hope that, one day, they will implement the feature you're waiting for. Microsoft is no longer the only party allowed to improve the platform or tailor it to your needs. Once it's open source, everyone is allowed to do so.
So while you are right that making the software open source doesn't magically make it portable, it is far from meaningless.
Actually, I think it's pretty much like KDE follows Windows whereas GNOME follows Mac OS X.
KDE, like Windows, favors features over a clean, streamlined, integrated experience.
GNOME, like OS X, favors a clean interface over features, and emphasizes interface standards to provide a consistent experience.
Of course, there are elements of every system in every other system; KDE and Windows have definitely gotten on the eyecandy bandwagon (popularized by Mac OS X) now, and GNOME still has a taskbar remniscent of what Windows versions before Windows 7 have.
You know, F/OSS is more than GNOME. There is a lot of innovation going on in the F/OSS universe. It has always been this way and I'm willing to bet it will always be that way. That you don't see it says more about you than about the F/OSS universe.
And yes, F/OSS projects copy things from proprietary software, too. And this is a Good Thing. After all, one of the most heard complaints about F/OSS is that it doesn't have whatever it is the complainer wants to have that they do have with their proprietary software of choice. Well, the likes of OpenOffice.org, KDE, GNOME, and many others cater to those wishes.
If you want something original and open source, there are numerous examples. Many features of modern Unix were pioneered in the open-source BSD, many others are pioneered in Linux (e.g. several filesystems), the TeX typesetting system was a real innovation, the open source Apache is the world's leading web server, the Python programming language is open source and certainly innovative; and that's just a few examples.
``I know there's OpenGL ES, and there's full-fledged OpenGL. Is there a practical common subset?''
Depends on which versions you're talking about. As this maemo.org page about OpenGL ES nicely illustrates, there is some overlap, but nothing that works across all four of OpenGL 1.x, OpenGL 2.x, OpenGL ES 1.x and OpenGL ES 2.x.
The differences are in the supported shader models and in the support of fixed-point arithmetic.
OpenGL 1.x has floating point arithmetic and fixed shaders. OpenGL ES 1.x is sort of an extended subset of OpenGL 1.x, removing features and adding fixed-point arithmetic.
OpenGL 2.x supports everything OpenGL 1.x supports, but adds programmable shaders. OpenGL ES 2.x is like OpenGL 2.x, except fixed shaders are not supported, and fixed-point arithmetic has been added.
This means that programmable shaders are not in OpenGL 1.x and OpenGL ES 1.x, and fixed shaders are not in OpenGL 2.x. So, no matter which kind of shader you use, there is some flavor of OpenGL that doesn't support it.
Also, note that the non-ES versions of OpenGL don't support fixed-point arithmetic. So if you want full compatibility, you will have to use floating-point arithmetic. That would be fine if it wasn't for the fact that many devices that support OpenGL ES (1.x or 2.x) only support fixed-point arithmetic.
So, basically: no, there is no common subset of all the OpenGL flavors that you can program in and have your program be compatible with all implementations.
In other words, what we have here is just a rehash of cross-site scripting? Just like you can upload snippets of JavaScript to a site and have them execute in visitors' browsers, you can upload Flash to a site and have it execute in visitors' browsers?
``Browser vendors have the right incentives because users have a realistic choice of browsers. Flash is an all-or-nothing affair.''
And that is a real problem for users, and not just because of its effect on security. Only Adobe makes software that can handle all the Flash applets out there, and anytime there is only a single supplier, the incentives to make things better for customers aren't there. Adobe has been pretty nice with Flash, considering.
Seems to me there _is_ an easy fix: disable that behavior by default (why would you want it, anyway?). Then, for sites that are broken by it, allow it to be selectively enabled.
Of course, the fact that Adobe isn't fixing it and we aren't allowed to fix it nicely illustrates why having the whole world depend on a piece of proprietary software is a bad idea at least from a security point of view.
Your post illustrates pretty much exactly the frustrations that have led me to my ideas.
``The problem is that worrying about semantic vs presentation is something that almost no one gives a s**t about, because it is an artificial division that makes sense for computer science reasons, not human reasons. I don't sit down to make a web page and completely divorce the content vs the layout; the layout gives context and can be just as important as the content itself in terms of a human brain grasping an attempt at communication.''
Right. But humans who can see your shiny, flashy presentation are not the only ones who will be analyzing the information. There are also those who must do without visual cues, such as search engines, visually impaired people, people on text-only systems. You may not care about those, but it's sure nice to have your page well represented in search engines, at least. Hence my suggestion for a good language for expressing semantics.
``I know I shouldn't use tables for presentation but I just don't care.''
And, in fact, you shouldn't. The only reason some people want you to care about that is that they think table is semantic, whereas you would be using it just for presentation. The truth is that tables _are_ presentation, and it should be perfectly fine to use them for that. Hence my suggestion for a good language for expressing presentation.
``In oh so many ways writing a web app is like stepping back into computer GUI v1.0; so much must be manually re-implemented in a different way for every app.''
Hence my suggestion for re-usable libraries.
``This kind of crap is so frustrating and wastes MILLIONS upon MILLIONS of man-hours year after year, yet we can't even get the major browser vendors to agree to HTMLv5 and what little bits (though very useful) it brings to the table. So please spare me the semantic vs presentation argument. If just a few people gave a s**t and stopped stroking their own egos on these bulls**t committees and actually tried to solve the problems that developers and designers deal with every day then they wouldn't have to worry about forcing everyone to adopt their standard (IPv6), the desire to adopt it would come naturally.''
The way I see it, the problem is mostly:
1. The people on the standards committees don't come up with the tools we need to make what we really want to make
2. The people who do come up with such tools make them proprietary and/or poorly integrated with the Web
3. Meanwhile, we have kludges that are Good Enough for a lot of people, reducing the incentive to come up with a real solution
While we're at it, let's also make processing web pages faster.
We have a semantic language (HTML) and a language that describes how to present that (CSS), right? This is good, let's keep it that way.
But things aren't as good as they could be. On the semantic side, we have many elements in the language that don't really convey any semantic information, and a lot of semantics there isn't an element for. On the presentation side, well, suffice it to say that there are a _lot_ of things that cannot be done, and others that can be done, but only with ugly kludges. Meanwhile, processing and rendering HTML and CSS takes a lot of resources.
Here is my proposal:
- For the semantics, let's introduce an extensible language. Imagine it as a sort of programming language, where the standard library has elements for common things like paragraphs, hyperlinks, headings, etc. and there are additional libraries which add more specialized elements, e.g. there could be a library for web fora (or blogs, if you prefer), a library for screenshot galleries, etc.
- For the presentation, let's introduce something that actually supports the features of the presentation medium. For example, for presentation on desktop operating systems, you would have support for things like buttons and checkboxes, fonts, drawing primitives, and events like keypresses and mouse clicks. Again, this should be a modular system, where you can, for example, have a library to implement the look of your website, which you can then re-use in all your pages.
- Introduce a standard for the distribution of the various modules, to facilitate re-use (no having to download a huge library on every page load).
- It could be beneficial to define both a textual, human readable form and a binary form that can be efficiently parsed by computers. Combined with a mapping between the two, you can have the best of both worlds: efficient processing by machine, and readable by humans.
- There needn't actually be separate languages for semantics, presentation and scripting; it can all be done in a single language, thus simplifying things
I'd be working on this if my job didn't take so much time and energy, but, as it is, I'm just throwing these ideas out here.
``I can't imagine free movies would be that great if they are only ad supported. Hollywood wouldn't give the rights to any movie actually worth seeing unless you pay the expensive royalties.''
``Of course they can not admit they simply copy Apple, after all.''
Well, why not? I don't see the big deal here. So Windows copied ideas from OS X.
OS X copied, like, the whole of Unix!
And Unix? Well, it copied ideas from MULTICS. And the GUI is probably inspired by the Mac's.
Really, copying ideas is nothing new in the OS biz, and it's a Good Thing there as it is everywhere else. Why reinvent the wheel? If a good idea is already out there, why not use it?
``Have a look at the Go Language FAQ. It states very clearly why exceptions were not added to Go.''
Yes, I've read that since. I hadn't bothered to read the whole thing before posting.:-)
It seems to me the reason Go doesn't have exceptions is that "we haven't figured out a good way to implement them yet".
``Have you ever considered, from an assembly language perspective, what exception processing looks like? How handling of multiple stack frames might take place?''
As a matter of fact, yes. I am the creator of the Voodoo programming language, a low-level language intended to be used as an intermediate step to native code generation. I am currently working on mapping the constructs of my Mana programming language (which, alas, is mostly documented on paper as of now) to Voodoo. That includes exceptions, restarts, continuations, closures, tail calls, garbage collection, the whole enchilada. Exceptions aren't exactly straightforward to implement (they break call-return control flow), but it's work you only have to do once and that will save users of your language a lot of headaches. "It's somewhat difficult to implement" has never been a good reason not to have a good idea in a programming language, especially if it _has_ been done before.
``If you want languages that provide safety then you must sacrifice speed.''
Is that so? Care to back up that assertion with some argumentation?
``I, personally, have never found myself enamoured by exception handling. It has its conveniences but you may well find many old school programmers find themselves content without it.''
Oh, I manage just fine in languages without exception handling, too. I'd also manage just fine if all I had was an assembler. In fact, I've done just that for years (back when there wasn't Internet access where I lived). But that doesn't mean I don't think high level languages or exceptions aren't a good idea.
``I could see it as a 'system' language as in 'write applications in it'.
Not scripts, not embedded functionalities, not CGI, and no, not servers.''
But that would make it an application programming language in my book.
Of course, many people these days use systems programming languages like C and C++ for application programming - with all the bugs and security vulnerabilities that results in.
Slashdot Mirror
``It is a pity that KDE 4.0 wasn't really ready to be a 4.0 release''
Which raises a good question: What to call the releases leading up to what will be the next major release?
There are several schemes in common use, but I haven't seen one that really strikes me as the right way to go.
For the software that I develop, I simply don't make a release until I feel it is usable. Intermediate versions can be referred to by the identifier assigned to them by the version control system. For actual release numbers, I use the major.minor.micro scheme, where major version changes indicate changes that aren't backward compatible, minor version increases indicate added features, and micro version changes indicate bugfixes.
This works, because the software I develop is simple, and I can put together a new stable release in limited time. But for a project the size of KDE, doing a major overhaul and getting it stable can easily take years and require a lot of communication and testing. You probably do want intermediate versions to be packaged and easily installable by end users, because you want those users to try it out and give you feedback. So you will want to make releases that aren't your new major version yet. But how do you label them? Obviously, calling them X.0 is not the way to go ... but what is?
Interesting. That's the first time I've heard about an Uranium shortage.
Over where I live, fission plants are being touted as the answer to our energy needs. They're supposed to be clean, low-health risk (lower risk than coal plants, at least), and fuel is supposed to be plentiful. I thought the only thing the government wasn't telling us is that it's actually one of the more expensive sources of energy, but now you're saying that Uranium is actually in short supply?
Regardless, I think the answer to any energy shortage is, first of all, conservation (which we can easily do a lot more of!) and, secondly, renewable resources, including widely known ones such as wind and solar energy, but also less widely known ones such as biofuels (you do need something you can control the output of, after all, rather than having to depend on the weather).
``Security has become the number 1 reason that software is now a continuous version stream with patches rolling out every 6 minutes.''
Which is why I am such a fan of distributions that don't do feature updates. Keep everything the same, only sending out updates to fix bugs.
``The UNIX-like OSes of the world have always handled this concept more gracefully, but when you look at windows that wants to reboot 4 times a week for updates it seems much more like an afterthought.''
I am not so sure. I think Unix got lucky, in that it grew up in a world where computer security was much less of an issue than nowadays. By the time Internet worms and the like became widespread, Unix had had a long time to mature, and faded to the background enough that people had mostly forgotten about it (how many people know what HP-UX is anymore?)
So you don't see a lot of malware targeting Unix, because it isn't such a big target, because there are a plethora of different, non-binary compatible versions out there, and because most of the outdated versions are mostly out of use and forgotten, whereas the up to date versions are quite mature.
The big exception to this is popular software that is getting many features added to it rapidly, such as the Linux kernel, various popular desktop programs, and many, many web applications: these are both rife with bugs and often break compatibility on updates. On the other hand, they're still popular, because people want those features.
The beauty of the Unix universe is that you can have it your way. You can have a stable system with few bugs and little maintenance, or you can have a cutting edge system with the latest features, at the cost of more bugs and time spent on maintenance.
Hahaha, nice one.
In case you're not getting the joke: The very definition of open-source states that modification and distribution must be allowed.
So yes. If it is open source, you _are_ allowed to distribute and modify, exactly as I stated.
Also, Free software and open source software are _not_ different things (and neither does the article referenced by the parent claim they are). The difference is not in the software, but in the philosophy: open source is the apolitical term, whereas Free software is the term preferred by those who wish all software to be Free software.
``Just because someone allows you to use the source of a program doesn't mean you can legally do anything you want with it.''
That is correct, but just being allowed to use the source in some way does not make the software open source, in the same way that not being charged for the software doesn't make it Free software. Some of Microsoft's earlier "shared source" initiatives can serve as an example of this: you get to see the source code, but you are not allowed to modify and distribute it - therefore, it is not open source.
``Just want you all to know the difference so you're not confused in the future.''
I hope that my post has managed to clear up some confusion. And please, don't go off misrepresenting open source anymore.
The Real WTF is the managers holding up this guy as an example to aspire to, without knowing _how_ what he did benefited the project. If they had done even something as basic as setting goals for the project (e.g. features that need to be implemented, issue tracker tickets resolved, ...) and measured by that, they would have gotten a better metric. Or they could have asked another coder. But no, they went and invented a metric, evaluated team members by it, and went to sing the praises of the member who came out on top ... without ever stopping to wonder if their metric was any good. Brillant.
``
Yes, you are, and yes, they are, because in the end it's them who will distribute their .NET Runtime, not you. Your fork may have feature X added, and bug Y corrected, but it doesn't matter because in the end, you'll have to code for their platform implementation.''
I don't see why. Since the platform is open source, you can distribute your improved version of it.
``This is nothing more than a stealth PR attempt, they will use it to say, "We opened everything up, and see ..."''
Or maybe it's just fear of more lawsuits from the EU.
However, the result is that .NET Micro Framework is now open source. That's a Good Thing.
Making it open source allows you to use it, distribute it, and modify it. Even if nobody ports it to your favorite platform, it's still a win for the users. No longer do you have to depend on Microsoft for bugfixes. No longer do you have to hope that, one day, they will implement the feature you're waiting for. Microsoft is no longer the only party allowed to improve the platform or tailor it to your needs. Once it's open source, everyone is allowed to do so.
So while you are right that making the software open source doesn't magically make it portable, it is far from meaningless.
Could somebody be so kind as to post links to downloadable versions of the videos?
Those who fail to reckon with the Streisand effect are doomed to invoke it.
``Do we laugh or cry? It's like KDE and Gnome are in some sort of frantic struggle for who can botch desktop Linux the most.''
So let's put some more effort into the alternatives, such as Enlightenment.
Actually, I think it's pretty much like KDE follows Windows whereas GNOME follows Mac OS X.
KDE, like Windows, favors features over a clean, streamlined, integrated experience.
GNOME, like OS X, favors a clean interface over features, and emphasizes interface standards to provide a consistent experience.
Of course, there are elements of every system in every other system; KDE and Windows have definitely gotten on the eyecandy bandwagon (popularized by Mac OS X) now, and GNOME still has a taskbar remniscent of what Windows versions before Windows 7 have.
You know, F/OSS is more than GNOME. There is a lot of innovation going on in the F/OSS universe. It has always been this way and I'm willing to bet it will always be that way. That you don't see it says more about you than about the F/OSS universe.
And yes, F/OSS projects copy things from proprietary software, too. And this is a Good Thing. After all, one of the most heard complaints about F/OSS is that it doesn't have whatever it is the complainer wants to have that they do have with their proprietary software of choice. Well, the likes of OpenOffice.org, KDE, GNOME, and many others cater to those wishes.
If you want something original and open source, there are numerous examples. Many features of modern Unix were pioneered in the open-source BSD, many others are pioneered in Linux (e.g. several filesystems), the TeX typesetting system was a real innovation, the open source Apache is the world's leading web server, the Python programming language is open source and certainly innovative; and that's just a few examples.
``I know there's OpenGL ES, and there's full-fledged OpenGL. Is there a practical common subset?''
Depends on which versions you're talking about. As this maemo.org page about OpenGL ES nicely illustrates, there is some overlap, but nothing that works across all four of OpenGL 1.x, OpenGL 2.x, OpenGL ES 1.x and OpenGL ES 2.x.
The differences are in the supported shader models and in the support of fixed-point arithmetic.
OpenGL 1.x has floating point arithmetic and fixed shaders.
OpenGL ES 1.x is sort of an extended subset of OpenGL 1.x, removing features and adding fixed-point arithmetic.
OpenGL 2.x supports everything OpenGL 1.x supports, but adds programmable shaders.
OpenGL ES 2.x is like OpenGL 2.x, except fixed shaders are not supported, and fixed-point arithmetic has been added.
This means that programmable shaders are not in OpenGL 1.x and OpenGL ES 1.x, and fixed shaders are not in OpenGL 2.x. So, no matter which kind of shader you use, there is some flavor of OpenGL that doesn't support it.
Also, note that the non-ES versions of OpenGL don't support fixed-point arithmetic. So if you want full compatibility, you will have to use floating-point arithmetic. That would be fine if it wasn't for the fact that many devices that support OpenGL ES (1.x or 2.x) only support fixed-point arithmetic.
So, basically: no, there is no common subset of all the OpenGL flavors that you can program in and have your program be compatible with all implementations.
In other words, what we have here is just a rehash of cross-site scripting? Just like you can upload snippets of JavaScript to a site and have them execute in visitors' browsers, you can upload Flash to a site and have it execute in visitors' browsers?
Thanks, mate. I won't dispute the "idiot", but let's just say I wish you were right about the fucking.
``Browser vendors have the right incentives because users have a realistic choice of browsers. Flash is an all-or-nothing affair.''
And that is a real problem for users, and not just because of its effect on security. Only Adobe makes software that can handle all the Flash applets out there, and anytime there is only a single supplier, the incentives to make things better for customers aren't there. Adobe has been pretty nice with Flash, considering.
Seems to me there _is_ an easy fix: disable that behavior by default (why would you want it, anyway?). Then, for sites that are broken by it, allow it to be selectively enabled.
Of course, the fact that Adobe isn't fixing it and we aren't allowed to fix it nicely illustrates why having the whole world depend on a piece of proprietary software is a bad idea at least from a security point of view.
Your post illustrates pretty much exactly the frustrations that have led me to my ideas.
``The problem is that worrying about semantic vs presentation is something that almost no one gives a s**t about, because it is an artificial division that makes sense for computer science reasons, not human reasons. I don't sit down to make a web page and completely divorce the content vs the layout; the layout gives context and can be just as important as the content itself in terms of a human brain grasping an attempt at communication.''
Right. But humans who can see your shiny, flashy presentation are not the only ones who will be analyzing the information. There are also those who must do without visual cues, such as search engines, visually impaired people, people on text-only systems. You may not care about those, but it's sure nice to have your page well represented in search engines, at least. Hence my suggestion for a good language for expressing semantics.
``I know I shouldn't use tables for presentation but I just don't care.''
And, in fact, you shouldn't. The only reason some people want you to care about that is that they think table is semantic, whereas you would be using it just for presentation. The truth is that tables _are_ presentation, and it should be perfectly fine to use them for that. Hence my suggestion for a good language for expressing presentation.
``In oh so many ways writing a web app is like stepping back into computer GUI v1.0; so much must be manually re-implemented in a different way for every app.''
Hence my suggestion for re-usable libraries.
``This kind of crap is so frustrating and wastes MILLIONS upon MILLIONS of man-hours year after year, yet we can't even get the major browser vendors to agree to HTMLv5 and what little bits (though very useful) it brings to the table. So please spare me the semantic vs presentation argument. If just a few people gave a s**t and stopped stroking their own egos on these bulls**t committees and actually tried to solve the problems that developers and designers deal with every day then they wouldn't have to worry about forcing everyone to adopt their standard (IPv6), the desire to adopt it would come naturally.''
The way I see it, the problem is mostly:
1. The people on the standards committees don't come up with the tools we need to make what we really want to make
2. The people who do come up with such tools make them proprietary and/or poorly integrated with the Web
3. Meanwhile, we have kludges that are Good Enough for a lot of people, reducing the incentive to come up with a real solution
While we're at it, let's also make processing web pages faster.
We have a semantic language (HTML) and a language that describes how to present that (CSS), right? This is good, let's keep it that way.
But things aren't as good as they could be. On the semantic side, we have many elements in the language that don't really convey any semantic information, and a lot of semantics there isn't an element for. On the presentation side, well, suffice it to say that there are a _lot_ of things that cannot be done, and others that can be done, but only with ugly kludges. Meanwhile, processing and rendering HTML and CSS takes a lot of resources.
Here is my proposal:
- For the semantics, let's introduce an extensible language. Imagine it as a sort of programming language, where the standard library has elements for common things like paragraphs, hyperlinks, headings, etc. and there are additional libraries which add more specialized elements, e.g. there could be a library for web fora (or blogs, if you prefer), a library for screenshot galleries, etc.
- For the presentation, let's introduce something that actually supports the features of the presentation medium. For example, for presentation on desktop operating systems, you would have support for things like buttons and checkboxes, fonts, drawing primitives, and events like keypresses and mouse clicks. Again, this should be a modular system, where you can, for example, have a library to implement the look of your website, which you can then re-use in all your pages.
- Introduce a standard for the distribution of the various modules, to facilitate re-use (no having to download a huge library on every page load).
- It could be beneficial to define both a textual, human readable form and a binary form that can be efficiently parsed by computers. Combined with a mapping between the two, you can have the best of both worlds: efficient processing by machine, and readable by humans.
- There needn't actually be separate languages for semantics, presentation and scripting; it can all be done in a single language, thus simplifying things
I'd be working on this if my job didn't take so much time and energy, but, as it is, I'm just throwing these ideas out here.
I'd like to hear from users who have upgraded from the previous release (as opposed to performing a new installation).
How did you perform the upgrade?
How did it go?
Did anything that was working before stop working?
Is there anything in the new version that you like so much you don't want to go back to the old version anymore?
``I can't imagine free movies would be that great if they are only ad supported. Hollywood wouldn't give the rights to any movie actually worth seeing unless you pay the expensive royalties.''
Isn't that how ... all movies get on TV?
``Of course they can not admit they simply copy Apple, after all.''
Well, why not? I don't see the big deal here. So Windows copied ideas from OS X.
OS X copied, like, the whole of Unix!
And Unix? Well, it copied ideas from MULTICS. And the GUI is probably inspired by the Mac's.
Really, copying ideas is nothing new in the OS biz, and it's a Good Thing there as it is everywhere else. Why reinvent the wheel? If a good idea is already out there, why not use it?
``Have a look at the Go Language FAQ. It states very clearly why exceptions were not added to Go.''
Yes, I've read that since. I hadn't bothered to read the whole thing before posting. :-)
It seems to me the reason Go doesn't have exceptions is that "we haven't figured out a good way to implement them yet".
``Have you ever considered, from an assembly language perspective, what exception processing looks like? How handling of multiple stack frames might take place?''
As a matter of fact, yes. I am the creator of the Voodoo programming language, a low-level language intended to be used as an intermediate step to native code generation. I am currently working on mapping the constructs of my Mana programming language (which, alas, is mostly documented on paper as of now) to Voodoo. That includes exceptions, restarts, continuations, closures, tail calls, garbage collection, the whole enchilada. Exceptions aren't exactly straightforward to implement (they break call-return control flow), but it's work you only have to do once and that will save users of your language a lot of headaches. "It's somewhat difficult to implement" has never been a good reason not to have a good idea in a programming language, especially if it _has_ been done before.
``If you want languages that provide safety then you must sacrifice speed.''
Is that so? Care to back up that assertion with some argumentation?
``I, personally, have never found myself enamoured by exception handling. It has its conveniences but you may well find many old school programmers find themselves content without it.''
Oh, I manage just fine in languages without exception handling, too. I'd also manage just fine if all I had was an assembler. In fact, I've done just that for years (back when there wasn't Internet access where I lived). But that doesn't mean I don't think high level languages or exceptions aren't a good idea.
``I could see it as a 'system' language as in 'write applications in it'.
Not scripts, not embedded functionalities, not CGI, and no, not servers.''
But that would make it an application programming language in my book.
Of course, many people these days use systems programming languages like C and C++ for application programming - with all the bugs and security vulnerabilities that results in.