Here is where it becomes relevent: In a court of law, someone who commits murder or rape, can be found not guilty (though they'll end up in an institution), if they can show that they did not "willingly" do the act. For example, saying they had a mental disorder of some kind.
The problem lies there: the definition of a mental disorder stops where someone cannot control something about their psyche, which messes up their lives. Its not simply when we can show some chemical in their head is unbalanced. That means the definition of a mental disorder, is subjective: it depends on the world in which the person lives. For example, someone is not considered hypersexual until it starts ruinning their lives. But the threshold for that is totally dependant on society: if we lived in a world where sex wasn't as taboo, the threshold for someone to be considered hypersexual would be much, much higher. So far so good, following me?
Now, if all actions someone does is basically pre-determined by their biological makeup, environment, etc, everything they do is "not their fault". In a court of law, this can ALREADY be used as a defence. If you can prove you did not have free will when you killed or raped, you will not go to jail, you will get psychological help forced on you instead. But now, if the above is true, NO ONE who has EVER commited a crime, is guilty, by our current law: it is NEVER the "criminal's fault".
And thats why its a whole mess. This concept is ALREADY used by lawyers all the time. Almost everytime someone is accused of pedophilia, murder, grand theft, you name it, they blame it on a mental disorder, on some outside influence, etc. Lawyers (ironically) have already realised that humans do not have free will. And that its a loophole in the law.
Thus, it is incredibly relevent. Showing scientificaly if we have free will or not (regardless of our perception), could give us reasons to fix our legal system. And in my opinion, it is in dire need of it. Its way too easy to claim insanity or whatsnot when you get accused of anything and everything: because EVERYONE who does something wrong, by definition in the law, along with this theory on not having free will, is "insane".
Why would a website ever have, without specific permission by the user given, access to the contents of the clipboard? I still do not see it.
The permission part is for the user experience. It annoyes the users sometimes fast. Imagine the following: I'm overriding the contextual menu to add functionality to my web app. Virtual ALL dumb corporate users go straight to the contextual menu when they want to do anything. Now, the COPY option is not there anymore, because I overrid it. So I need to put it back. But now, whenever a user uses it, it asks for a confirmation. Awkward.
I understand the security issues, and thus it has to be disabled by default and ask permissions. There's no choice. But it is a major usuability hit in more complex web apps. There will literally NEVER be a time when I could justify the SERVER having access to the clipboard. But the actual client side UI? Yes, most definately.
I was about to post the same thing. Honestly, it is time email gets banned from the net altogether or something. All these problems come from an obsolete protocole that was created in the days before we realised just how the internet would be abused. As useful as email can be, it has to be replaced, even if its by something less useful. All that spam is definately slowing down the internet.
Yeah, spammers will just move to the next thing...but we have to work our way up. Email is slowly becoming useless now... so it won't be a big loss.
HTML isn't about layout....anymore. It used to be though:) I prefer seeing XHTML as the structured content language, since XML is about structure. HTML was around before CSS, so obviously it was made with layout in mind, originally. The whole HTML/CSS to separate the structure from the layout is also obsolete in my opinion... That was from before server side languages became mainstream. ASPX (ASP.NET), JSP, JSF, the templating part of PHP, ASP, whatever...those are now about structuring content, and HTML and CSS both ends up being about the layout if you see what i mean. CSS/HTML becomes a superfluous separation, since its already separated. Then merged, then separated again @.@
Anyhow, back to your point:
div style height 100%, a position:relative that works no matter what the container is, and an expression language would do the trick.
If I could do, let say:
<div id="whatever"> One column </div> <div id="another" style="height:#whatever.height + 20em"> Another column </div>
Give or take (typing code in slashdot's text editor isn't ideal, haha), now then we would be in business. But again, all that would still fall short of other presentation layer solutions, when HTML is so mainstream, it should not be limited. At least not when read on a desktop. Now that ASP.NET, JSP, PHP, and so on are mainstream, and gives us the extra separation, the whole HTML deal seems overkill. Separations within separations within separations just at the presentation layer level, when my app is already separated in 20+, is really overkill.
If HTML/CSS is a solution designers like, so be it. I want a solution for web apps. Microsoft has one: XAML. But thats Microsoft only, and will never be widely accepted. I want another:) (Yeah, i'm picky).
Until that happens, the thing I showed above would solve 90% of problems. If at the very least I could structure my data using HTML, without having to think at ALL about the layout (because with CSS' current limitation, I do. Just look at the CSS Zen Garden, it has an extreme amount of tags to allow perfect separation of layout and structure, and it STILL is limited, if to a much lesser extent...thats insane!), then it will be sufficient. For now.
The problem isn't that. The feature is there so you can add usuability features to your site. Like a better, and customised "right click" menu, for example with data grids, or text editors. A way to, let say, parse Word clip board and strip formatting. Pasting HTML with a special formatting. You name it. Its useful.
The problem is that since this is accessible in javascript, you could, let say, paste that data in a hidden field, so that when a user post a form, it will post their clipboard. Or use Ajax to push it to the server, etc. Thats the exploit.
The feature itself was NEVER meant for the web site to get the data...it was meant to help the user copy and paste more effectively when using a web page, and improve usuability... The only issue is that it CAN be used to let the server fetch the data, something you never, ever, EVER want.
You misunderstood me. What im saying is that for extremely complex layout in other (not HTML) environment, you always have some kind table based layout engine (which is NOT the same as using a data grid, etc. I am talking about something that does exactly the same thing as using tables for page layout in HTML, but as a totally separate element, with layout specific features).
Take Java Swing for example: jTable -> tabular data. Gridbag layout -> "table" layout.
HTML/CSS needs something -specificaly- for table layouts to cover these cases (for example, like having multiple columns that need to grow symetrically, with specific resizing constraints, etc )in a more intuitive manner, without having to rely on a -datatable- element (the current HTML tables).
Thus, Im saying HTML is missing a layout element. And CSS's display:table doesn't count.
Simply out of curiosity...I don't know if you'll ever read this, but oh well:)
You mention that if you build the index on the fly, it leaves you with an unbalanced tree. But last I checked, b-trees are always balanced no matter what.
Indeed, however, for the time being, SOAP is the most useful way to use web services when you don't know the clients. I mean, yeah you could use JSON, but then it is definately not as easy to interoperate (a lot of legacy environments don't even support document mode and you're forced to use RPC, and thats with SOAP....nevermind less mainstream ones).
So it is still a big hit in that sense. Not that I'd cry if SOAP was replaced by something else...
I agree, to some extent. The catch is here: There are many different browser based engines, usualy in the form of plugins, that work fine, even on limited hardware. Flash, for example.
The reason WHY they made CSS the way it is, makes a lot of sense, I'll give you that. However, they failed. The browser already has to be aware of a ton more things, for DOM, javascript, etc. So CSS's implementation helps...cellphones. Thats about it...
The only thing in the spec that makes sense put in perspective, as someone who has had to code layout engines from scratch in the past, is how selectors can only fetch their childs, not their parents. That obviously makes a lot of sense. But a lot of the rest is really out of wack, for BOTH the web designer (CSS is definately NOT powerful enough) and the people who develop the browsers (no one got it 100% right yet, while there are full implementations of Flash, Java,.NET, XALM {soon}, etc).
I really understand all the logic you're trying to explain. But regardless: CSS failed at its goal, from virtualy all angles, except at being friendly for embedded devices when paired with XHTML.
On the contrary, some of the most frequently complained about shortcomings of CSS are due to the desire to keep implementations simple, which is practically the opposite of being "all about theory". They purposefully left out things like a decent query mechanism because they considered it too hard for people to implement.
Makes sense. However, looking at the specs, its too simple to pass a real world usuability test (aka: do what my customers want it to do), yet too convoluted to be implemented properly (as a programmer myself, I'd rather implement XAML, Java or Flash from scratch than CSS, at first glance. You know, the whole "This property works. But only for elements of this type. Or with this, this, or that property. Unless its parent has this property, or is of this type. Unless you're using %, in which case it doesn't work at all. Unless....". Holy jesus!).
No, Netscape implemented an alternative (JSSSL) and submitted it to the W3C for standardisation
Ok, you win there, I didn't know about that. Though the W3C has proven (with things like XSD, etc) that it is amazingly bad at selecting useful standards... so I'm really wondering if, at the time (obviously TODAY it is easy to see where CSS failed, and propose something better, but it wasn't back then), something better could have been done, if the process of selecting a standard would have went better...
but also because CSS 2.0 is a convoluted, sloppily designed specification
Correct. Honestly, I don't really ever want to see an -actively pushed-, and considered "standard" specification proposition go out without a reference implementation. Sit down, agree to a specification, propose it, then make a reference implementation, THEN start pushing it.
When you look at most successful specs, from videocard chipsets, to Java specifications, they come with a reference implementation: this makes sure that everything makes sense in -practice-, not just in theory. With CSS, it is all about theory, without real world tests.
The only reason it got pushed as standard, is because the web evolved too fast for its own good, and no one realised what was happening before it was too late, to propose an alternative to CSS.
Re:Safari has done Acid2 for more than a year!
on
CSS Turns 10 Years Old
·
· Score: 3, Informative
The sad part is, Safari can pass Acid 2, but last I checked, it didn't handle onload image event contexts properly. Sad.
The part that irks me about the whole "table were never meant to be used for layout" deal, is that in most other environment, there are multiple layout methods. CSS implements most of those. Even a subset of "table layouts" in the form of the display:table-cell, display:table, etc, but no actual grid/table layout of some kind. To do some stuff, these ARE the easiest way to do things.
So in the same way in other environments we have "data tables", to display tabular data, and "table layout" to do what tables have been used to do in HTML, there should be something like that in CSS too (and no, the display CSS properties aren't enough).
I don't understand the logic behind expecting a standard feature to work efficiently(...)
Wow, its late and I can't type anymore it seems. What I meant is, I don't understand why you think its noobish to expect a feature to work efficiently in MySQL, when it works fine everywhere else, and is amazingly useful in a dynamic production environment.
Yes it is commong practice for noobs to run an index on a 100 million row table
Here's the catch: on just about any mainstream RDBMS except.... MySQL (from what I hear, as by the previous parent, etc. Haven't tried it myself) and Pervasive SQL, adding an index on a table that already contains data isn't an issue. Obviously it isn't: if there's a manual workaround, its even easier to have it built in the RDBMS.
So watching you argue how "noob" it is to do it, is quite the chuckle. And that doesn't count into the fact all the issues there are when you transfer data the way you suggest, when you have thousands of objects that depend on the original, on a live system.
So again, I'll restate my original point: It works everywhere else(Since I refuse to acknowledge Pervasive SQL's existance beyond naming it), and it works just fine, fast, etc . Why shouldn't we expect MySQL to do it too?
I don't understand the logic behind expecting a standard feature to work efficiently, when it already works in so many other implementation: its not like its a physical limitation or anything.
yes, the diagnostic would be to create the index, BEFORE you load the data.
You're kidding, right? You've never had to use a DBMS in business environments or something? Needs and requirement changes, and you sooner or later have to add indexes on terrabytes of data. No way around it, unless you're doing a stupid personal web site. Thus why the parent was testing how quickly it would be.
And most serious RDBMS don't have any issue with it. Maybe in Fairy Land you can make a database design and stick with it: in the real world thats a dream and little more.
I use mysql with billion row tables , all indexed just fine, instant return on select queries.. Tired of these noobs not knowing what they are doing..
Hmm, I wasn't aware special training was required to create a 50 million record table and index it. A "noob" who "doesn't know what they are doing", can do it perfectly fine on just about every other RDBMS.
Care to explain to me what your diagnostic might be for the parent's problem, Mr. Anonymous Coward?
Yup. Symmetric encryption of the cookies, on top of SSL enabled, for the win. That tends to be good enough for a lot (not all) purposes, as then the cookie is semi-temper proof.
the problem isn't even javascript or cookies. Its that making web sites was marketed as something easy, when in practice, web apps are significantly more difficult to make than desktop applications (at least if you don't half ass them). So you have a ton of people claiming to be web experts, that don't know how all these technologies work... The technologies are decent at what they do, as long as the average skill of those who use them is greater than your typical 6th grader...
ajax doesn't allow you to keep a live connection or something. It still does standard HTTP requests and such. So you're still living in a disconnected model. It doesn't help, unless you're using a fancy framework that will handle things for you: but then its the framework that helps, not ajax.
Does not have enough experience with generic RDBMS features, you mean. This whole thing reads like someone who's used to MySQL as a full featured standard database(plus it seems to be old, as this looks like its mostly comparing Postgres 7 and MySql 4).
Features like stored procedures were dumped in a generic category, when they make or break RDBMS single handedly depending on their features, in business environments. (I personally prefer dynamic sql, but seems like most architects do not, so well...).
I'm not particularly interested in either of these databases as they do not meet my requirements, but this comparison is totally rediculous.
You are somewhat right, in a way. Having to make money is the real goal, in many cases. As long as the way you decide to make money isn't based on mistakes, its pretty irrelevent: For example, if, let say, the makers of Opera were to give me 1 million dollar for making a web site that only works with them and use Opera specific features (Opera is quite feature full, and while its all based on standards, most other browsers aren't as advanced, so it is quite easy to make a "Opera-only" site), I'd make a web site thats Opera-only, even if it turns off 90% of my customers (assuming that my busines isn't worth a million dollar. I'm pulling numbers out of my ass here).
This is far fetched, but it makes the point: standards are a tool. They are not a goal. Something using standards as a sub-goal (like I do), can be a tool in itself. But in the end, it is still just a tool. The standard isn't a purpose in itself.
So if someday, XAML is so freakishly popular, that my estimates of R&D + Development vs Return and Customers is greater using XAML (which is as "Microsoft-only" as it gets), including considering the risk of Microsoft screwing me over, and I decide its worth it, Ill use that. So it all depends on the market, and what my goals are.
And I have had to make IE-only web sites in the past, when customers were willing to pay a LOT just to have a javascript that would automatically dump some data in the clipboard from a web page in a way that was IE only, and didn't give a damn about cross-browser support (as it was an internal app, and every, single, last, user hated alternative browsers, even though they had to use them for other purposes, long story), and thus, its what I did.
When in business, money drives it all. It just so happens that very, very often, following the standard is the best way to make money. But NOT ALWAYS. We're not charity organisations here:) If someone pays me 400$/hour to write spagetti code, I'll write spagetti code, no matter how stupid I know it is (and that HAS happened to me in the past...)
Re:'Javas slow decline in favor of...' oh please
on
2007 Java Predictions
·
· Score: 2, Interesting
Agreed. I'm a software developer working mostly on ERP systems in medium to large scale projects, and while I work in.NET 2.0 and 3.0, while speaking to people in the industry (mostly consulting firms), Java is actualy in GROWING demand.
Currently, in my area, Java -junior- programmers get snatched right up. You don't hire junior programmers in a declining industry, you hire senior programmers (because by the time the juniors become senior, the environment will be history). There has been an increasing amount of projects in Java, especialy since Java 1.5, since that was quite the milestone. Same with the last few J2EE versions.
On top of that, now in the latest specs, EJB 3.0 is actualy useful (and doesn't have to be systematicaly replaced by third party frameworks).
Now, on top of all this, more and more schools are using Java as a teaching tool. Which means all these people that come out of school, will be wanting to use their skills. Thus more demand, more support, more projects.
In the hardcore enterprise world, the only thing that can match this is.NET, and thats Windows-only (Mono cannot deal with Enterprise level projects), leaving Java with all the Windows projects not using.NET, and all the non-Windows stuff. Thats a lot, and as Windows' monopoly slows down a bit, it increases.
The one exception to this is the high end R&D stuff, which tends to use Python/C++ or something along that line (I beleive thats what Google use for a lot of things?), but thats a different market altogether.
Well, I didn't try Firefox 2, but I know that for quite a few things (not many, but still too many, though I don't remember them off hand), Firefox 1 was closer to IE7's behavior than Opera's... Thats when I started developing in Opera -first-, because it was more (at the time at least) compliant than Firefox. Was quite awkward.
There are other annoyances. For example, Safari's javascript implementation sucks. Simply put, there aren't any standard compliant browsers. Just browsers that get damn close. So its not quite as simple as it should be:( You -have- to test in all browsers. Coding in a standard compliant way, then saying "it will work in standard compliant browsers" means jack shit: if I code by W3C specs exactly, at 100%, I -still- have to test in all browsers. INCLUDING Opera (which is probably the most standard compliant one), just in case... Annoying as hell.
Slashdot Mirror
Here is where it becomes relevent: In a court of law, someone who commits murder or rape, can be found not guilty (though they'll end up in an institution), if they can show that they did not "willingly" do the act. For example, saying they had a mental disorder of some kind.
The problem lies there: the definition of a mental disorder stops where someone cannot control something about their psyche, which messes up their lives. Its not simply when we can show some chemical in their head is unbalanced. That means the definition of a mental disorder, is subjective: it depends on the world in which the person lives. For example, someone is not considered hypersexual until it starts ruinning their lives. But the threshold for that is totally dependant on society: if we lived in a world where sex wasn't as taboo, the threshold for someone to be considered hypersexual would be much, much higher. So far so good, following me?
Now, if all actions someone does is basically pre-determined by their biological makeup, environment, etc, everything they do is "not their fault". In a court of law, this can ALREADY be used as a defence. If you can prove you did not have free will when you killed or raped, you will not go to jail, you will get psychological help forced on you instead. But now, if the above is true, NO ONE who has EVER commited a crime, is guilty, by our current law: it is NEVER the "criminal's fault".
And thats why its a whole mess. This concept is ALREADY used by lawyers all the time. Almost everytime someone is accused of pedophilia, murder, grand theft, you name it, they blame it on a mental disorder, on some outside influence, etc. Lawyers (ironically) have already realised that humans do not have free will. And that its a loophole in the law.
Thus, it is incredibly relevent. Showing scientificaly if we have free will or not (regardless of our perception), could give us reasons to fix our legal system. And in my opinion, it is in dire need of it. Its way too easy to claim insanity or whatsnot when you get accused of anything and everything: because EVERYONE who does something wrong, by definition in the law, along with this theory on not having free will, is "insane".
The permission part is for the user experience. It annoyes the users sometimes fast. Imagine the following: I'm overriding the contextual menu to add functionality to my web app. Virtual ALL dumb corporate users go straight to the contextual menu when they want to do anything. Now, the COPY option is not there anymore, because I overrid it. So I need to put it back. But now, whenever a user uses it, it asks for a confirmation. Awkward.
I understand the security issues, and thus it has to be disabled by default and ask permissions. There's no choice. But it is a major usuability hit in more complex web apps. There will literally NEVER be a time when I could justify the SERVER having access to the clipboard. But the actual client side UI? Yes, most definately.
I was about to post the same thing. Honestly, it is time email gets banned from the net altogether or something. All these problems come from an obsolete protocole that was created in the days before we realised just how the internet would be abused. As useful as email can be, it has to be replaced, even if its by something less useful. All that spam is definately slowing down the internet.
Yeah, spammers will just move to the next thing...but we have to work our way up. Email is slowly becoming useless now... so it won't be a big loss.
If HTML/CSS is a solution designers like, so be it. I want a solution for web apps. Microsoft has one: XAML. But thats Microsoft only, and will never be widely accepted. I want another
The problem isn't that. The feature is there so you can add usuability features to your site. Like a better, and customised "right click" menu, for example with data grids, or text editors. A way to, let say, parse Word clip board and strip formatting. Pasting HTML with a special formatting. You name it. Its useful.
The problem is that since this is accessible in javascript, you could, let say, paste that data in a hidden field, so that when a user post a form, it will post their clipboard. Or use Ajax to push it to the server, etc. Thats the exploit.
The feature itself was NEVER meant for the web site to get the data...it was meant to help the user copy and paste more effectively when using a web page, and improve usuability... The only issue is that it CAN be used to let the server fetch the data, something you never, ever, EVER want.
You misunderstood me. What im saying is that for extremely complex layout in other (not HTML) environment, you always have some kind table based layout engine (which is NOT the same as using a data grid, etc. I am talking about something that does exactly the same thing as using tables for page layout in HTML, but as a totally separate element, with layout specific features).
Take Java Swing for example: jTable -> tabular data. Gridbag layout -> "table" layout.
HTML/CSS needs something -specificaly- for table layouts to cover these cases (for example, like having multiple columns that need to grow symetrically, with specific resizing constraints, etc )in a more intuitive manner, without having to rely on a -datatable- element (the current HTML tables).
Thus, Im saying HTML is missing a layout element. And CSS's display:table doesn't count.
Simply out of curiosity...I don't know if you'll ever read this, but oh well :)
You mention that if you build the index on the fly, it leaves you with an unbalanced tree. But last I checked, b-trees are always balanced no matter what.
So was that really what you meant?
Indeed, however, for the time being, SOAP is the most useful way to use web services when you don't know the clients. I mean, yeah you could use JSON, but then it is definately not as easy to interoperate (a lot of legacy environments don't even support document mode and you're forced to use RPC, and thats with SOAP....nevermind less mainstream ones).
So it is still a big hit in that sense. Not that I'd cry if SOAP was replaced by something else...
I agree, to some extent. The catch is here: There are many different browser based engines, usualy in the form of plugins, that work fine, even on limited hardware. Flash, for example.
.NET, XALM {soon}, etc).
The reason WHY they made CSS the way it is, makes a lot of sense, I'll give you that. However, they failed. The browser already has to be aware of a ton more things, for DOM, javascript, etc. So CSS's implementation helps...cellphones. Thats about it...
The only thing in the spec that makes sense put in perspective, as someone who has had to code layout engines from scratch in the past, is how selectors can only fetch their childs, not their parents. That obviously makes a lot of sense. But a lot of the rest is really out of wack, for BOTH the web designer (CSS is definately NOT powerful enough) and the people who develop the browsers (no one got it 100% right yet, while there are full implementations of Flash, Java,
I really understand all the logic you're trying to explain. But regardless: CSS failed at its goal, from virtualy all angles, except at being friendly for embedded devices when paired with XHTML.
Ok, you win there, I didn't know about that. Though the W3C has proven (with things like XSD, etc) that it is amazingly bad at selecting useful standards... so I'm really wondering if, at the time (obviously TODAY it is easy to see where CSS failed, and propose something better, but it wasn't back then), something better could have been done, if the process of selecting a standard would have went better...
Correct. Honestly, I don't really ever want to see an -actively pushed-, and considered "standard" specification proposition go out without a reference implementation. Sit down, agree to a specification, propose it, then make a reference implementation, THEN start pushing it.
When you look at most successful specs, from videocard chipsets, to Java specifications, they come with a reference implementation: this makes sure that everything makes sense in -practice-, not just in theory. With CSS, it is all about theory, without real world tests.
The only reason it got pushed as standard, is because the web evolved too fast for its own good, and no one realised what was happening before it was too late, to propose an alternative to CSS.
The sad part is, Safari can pass Acid 2, but last I checked, it didn't handle onload image event contexts properly. Sad.
The part that irks me about the whole "table were never meant to be used for layout" deal, is that in most other environment, there are multiple layout methods. CSS implements most of those. Even a subset of "table layouts" in the form of the display:table-cell, display:table, etc, but no actual grid/table layout of some kind. To do some stuff, these ARE the easiest way to do things.
So in the same way in other environments we have "data tables", to display tabular data, and "table layout" to do what tables have been used to do in HTML, there should be something like that in CSS too (and no, the display CSS properties aren't enough).
Idiots cannot accept that they are idiots, and thus claim they are perfectly normal, and blame their idiocy on others. What a sad world are we in...
So watching you argue how "noob" it is to do it, is quite the chuckle. And that doesn't count into the fact all the issues there are when you transfer data the way you suggest, when you have thousands of objects that depend on the original, on a live system.
So again, I'll restate my original point: It works everywhere else(Since I refuse to acknowledge Pervasive SQL's existance beyond naming it), and it works just fine, fast, etc . Why shouldn't we expect MySQL to do it too?
I don't understand the logic behind expecting a standard feature to work efficiently, when it already works in so many other implementation: its not like its a physical limitation or anything.
You're kidding, right? You've never had to use a DBMS in business environments or something? Needs and requirement changes, and you sooner or later have to add indexes on terrabytes of data. No way around it, unless you're doing a stupid personal web site. Thus why the parent was testing how quickly it would be.
And most serious RDBMS don't have any issue with it. Maybe in Fairy Land you can make a database design and stick with it: in the real world thats a dream and little more.
Care to explain to me what your diagnostic might be for the parent's problem, Mr. Anonymous Coward?
Yup. Symmetric encryption of the cookies, on top of SSL enabled, for the win. That tends to be good enough for a lot (not all) purposes, as then the cookie is semi-temper proof.
the problem isn't even javascript or cookies. Its that making web sites was marketed as something easy, when in practice, web apps are significantly more difficult to make than desktop applications (at least if you don't half ass them). So you have a ton of people claiming to be web experts, that don't know how all these technologies work... The technologies are decent at what they do, as long as the average skill of those who use them is greater than your typical 6th grader...
ajax doesn't allow you to keep a live connection or something. It still does standard HTTP requests and such. So you're still living in a disconnected model. It doesn't help, unless you're using a fancy framework that will handle things for you: but then its the framework that helps, not ajax.
Does not have enough experience with generic RDBMS features, you mean. This whole thing reads like someone who's used to MySQL as a full featured standard database(plus it seems to be old, as this looks like its mostly comparing Postgres 7 and MySql 4).
Features like stored procedures were dumped in a generic category, when they make or break RDBMS single handedly depending on their features, in business environments. (I personally prefer dynamic sql, but seems like most architects do not, so well...).
I'm not particularly interested in either of these databases as they do not meet my requirements, but this comparison is totally rediculous.
You are somewhat right, in a way. Having to make money is the real goal, in many cases. As long as the way you decide to make money isn't based on mistakes, its pretty irrelevent: For example, if, let say, the makers of Opera were to give me 1 million dollar for making a web site that only works with them and use Opera specific features (Opera is quite feature full, and while its all based on standards, most other browsers aren't as advanced, so it is quite easy to make a "Opera-only" site), I'd make a web site thats Opera-only, even if it turns off 90% of my customers (assuming that my busines isn't worth a million dollar. I'm pulling numbers out of my ass here).
:) If someone pays me 400$/hour to write spagetti code, I'll write spagetti code, no matter how stupid I know it is (and that HAS happened to me in the past...)
This is far fetched, but it makes the point: standards are a tool. They are not a goal. Something using standards as a sub-goal (like I do), can be a tool in itself. But in the end, it is still just a tool. The standard isn't a purpose in itself.
So if someday, XAML is so freakishly popular, that my estimates of R&D + Development vs Return and Customers is greater using XAML (which is as "Microsoft-only" as it gets), including considering the risk of Microsoft screwing me over, and I decide its worth it, Ill use that. So it all depends on the market, and what my goals are.
And I have had to make IE-only web sites in the past, when customers were willing to pay a LOT just to have a javascript that would automatically dump some data in the clipboard from a web page in a way that was IE only, and didn't give a damn about cross-browser support (as it was an internal app, and every, single, last, user hated alternative browsers, even though they had to use them for other purposes, long story), and thus, its what I did.
When in business, money drives it all. It just so happens that very, very often, following the standard is the best way to make money. But NOT ALWAYS. We're not charity organisations here
Agreed. I'm a software developer working mostly on ERP systems in medium to large scale projects, and while I work in .NET 2.0 and 3.0, while speaking to people in the industry (mostly consulting firms), Java is actualy in GROWING demand.
.NET, and thats Windows-only (Mono cannot deal with Enterprise level projects), leaving Java with all the Windows projects not using .NET, and all the non-Windows stuff. Thats a lot, and as Windows' monopoly slows down a bit, it increases.
Currently, in my area, Java -junior- programmers get snatched right up. You don't hire junior programmers in a declining industry, you hire senior programmers (because by the time the juniors become senior, the environment will be history). There has been an increasing amount of projects in Java, especialy since Java 1.5, since that was quite the milestone. Same with the last few J2EE versions.
On top of that, now in the latest specs, EJB 3.0 is actualy useful (and doesn't have to be systematicaly replaced by third party frameworks).
Now, on top of all this, more and more schools are using Java as a teaching tool. Which means all these people that come out of school, will be wanting to use their skills. Thus more demand, more support, more projects.
In the hardcore enterprise world, the only thing that can match this is
The one exception to this is the high end R&D stuff, which tends to use Python/C++ or something along that line (I beleive thats what Google use for a lot of things?), but thats a different market altogether.
Well, I didn't try Firefox 2, but I know that for quite a few things (not many, but still too many, though I don't remember them off hand), Firefox 1 was closer to IE7's behavior than Opera's... Thats when I started developing in Opera -first-, because it was more (at the time at least) compliant than Firefox. Was quite awkward.
:( You -have- to test in all browsers. Coding in a standard compliant way, then saying "it will work in standard compliant browsers" means jack shit: if I code by W3C specs exactly, at 100%, I -still- have to test in all browsers. INCLUDING Opera (which is probably the most standard compliant one), just in case... Annoying as hell.
There are other annoyances. For example, Safari's javascript implementation sucks. Simply put, there aren't any standard compliant browsers. Just browsers that get damn close. So its not quite as simple as it should be