Having migrated a few applications from MySQL to Postgres, the truth is, it will be painful, but the result is you will be a LOT more confident in the quality and manageability of your data. Start here
PostgreSQL has all the datatypes that MySQL has, and more (see especially the ), and usually with far less limitations. Any character type can be up to 1GB in size if needed, for example.
The biggest sources of pain will likely come from character set handling (some MySQL oddities there) and MySQL's ready acceptance of NULL where it really shouldn't occur. Learn to love grep, sed and the 'iconv' utility.
There are conversion utilities that will get you part of the way there with a DB structure dump, but they will hardly do justice to a complex database. You will have to reengineer your system--in fact you will want to, since PostgreSQL has many capabilities that you cannot take advantage of in MySQL.
Triggers and stored functions are a little less 'wieldy' in Postgres, but far more capable once you get the concepts. For one thing, MySQL re-compiles all stored procedures for every instance of a connection (making SPs in PHP web-based apps almost pointless). One caveat: Postgres does not have 'true' stored procedures in the sense that they cannot span multiple transactions. Thus they are called functions, but aside from the transaction limitation, they are far more capable than MySQL stored procedures. For example, result sets from functions can be treated exactly like result sets from tables, and nested inside other queries and views, even in the FROM clause in ways that MySQL still does not allow. Full referential transparency.
Postgres has many more indexing options than MySQL, which you will want to explore for performance tweaking.
Postgres has the RULE system which allows for query rewriting in much the way that Apache's mod_rewrite allows for URL rewriting. It is a powerful tool, allowing you to potentially get rid of tons of stored procedure code. In some ways it works like an alternate triggering mechanism, but it is very lightweight.
BTW, one way you might consider handling your migration is using PostgreSQL's new foreign data wrapper or SQL/MED functionality, which can allow you to query a MySQL table from within a PostgreSQL DB (read-only for now, but excellent for importing tables interactively)
Bingo. Exactly what I have been saying for years, but... we both know that this sort of idea is far too sensible and boring for the 'concept du jour' programming community.
Nowhere in your rambling, incoherent response did you come close to anything that could be considered a rational thought. We are all dumber for having listened to it. I award you no points and may God have mercy on your soul.
A while back (June 5 2009) Tom Levenson was talking about his book, "Newton and the Counterfeiter: The Unknown Detective Career of the World's Greatest Scientist," on Science Friday http://www.npr.org/templates/story/story.php?storyId=105012144. A caller asked the Levenson about Stephenson's work. Levenson said that the Newton's voice was so plausible that he had stopped reading them until he had finished his own book.
Very interesting to note. I had been wondering about that part of the story.
Also, don't give up reading the trilogy! It gets better and a lot of the pieces don't come together until the final book.
Absolutely!. I am at the last 100 pages right now and it surely does not lose steam. Nor punk. (OK, I'll stop now)
It's not 2000 anymore. 99% of the problems people have historically with MySQL are simply not present in recent production versions. PostgreSQL and MySQL roughly have feature parity nowadays, Stop treating MySQL as if it's some toy. WikiVS has a good, up-to-date comparison: http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL
Big emphasis on the "roughly". The features may look the same as tick points on a list, but when you actually try to use them, vast differences show up. Roughly bundled-together features without a comprehensive plan is what it looks like to me. For example, no referential transparency or transitive closure. You can't just nest expressions, views, function calls and procedure calls transparently. You can't alias temp tables in procedures, etc... Lots of odd restrictions and "can't get there from here" scenarios.
I also find it amusing that an AC below complains about "how many storage engines"? Whoosh, that's the sound of the point flying over his head.
By the way, I'm not dissing PostgreSQL in any way, I think it's great. But it's about time some meaningless mantras stop being chanted.
Yeah, we shouldn't expect that old bugaboo "conceptual integrity" to intrude on modern software design, right? Can't use full-text indexing and foreign key constraints on the same table? What kind of compulsive freak would want that, anyway...?
I hear our dba's complain about replication too. We run services on both mysql and postgresql and from what I gathered it was far more difficult and error prone to configure the replication for complex posgresql databases (defining per table?).
Well of course replication on a complex database is going to be hard. Fact is, most MySQL databases are very simple (the only appropriate use of MySQL, IMHO). Once a MySQL database gets complicated, it is all but impossible to coax robust replication out of it. In the case of one I had to deal with, I had to finally retreat to the simplest master->slave approach, AND I had to upgrade to 5.1 for row-base replication (statement-based replication is just impossible if you have complex stored procedures). Even so, I have to set slave_exec_mode to IDEMPOTENT in order to actually keep replication running, which of course makes the actual replication far less robust. (I know, if they moved to full transactional INNODB tables it probably wouldn't be necessary, but unfortunately they need MyISAM tables for some things).
Point is, replication is HARD to get right on any moderately complex system. I doubt there will ever be a magic bullet in that regard.
MySQL replication barely deserves the name. It plain and simple DOES NOT guarantee data consistency. Maybe it's nice and easy to work with, but I would never trust mission-critical data to it.
I know that replication has been the sore point of PostgreSQL, mainly because there were several different approaches being developed--all provided as external solutions, and it could be confusing to try and wade through all the data to find the best option. Fortunately, version 9.0 (moving from alpha to beta soon) will come with built-in hot standby and streaming replication.
While insightful and informative in its own right, that isn't a logical response to my post.
He was asking for an alternative to Mysql. I was pointing out that moving from mysql to postgresql was not done by large companies with a lot of smart people working for them, because any performance improvements were not worth it.
That really depends on the kind of company and the kinds of applications involved.
MySQL can probably still handle a higher # of raw queries per second *using MyISAM tables* than PostgreSQL, however once you test with a table type like InnoDB, which has to support such things as constraints and transactions, the MySQL speed advantage is lost.
Many large web companies don't really need transactions, MVCC, constraints and other such niceties because the type of data they work with doesn't demand such precision. That's a perfect answer as to why many of the are investigating non-relational alternatives. However, a company doing business applications involving money, or other critical, non-trivial data can't afford to take such chances with data consistency.
Developers need to understand the real nature of the trade-offs involved in all these things. NoSQL type systems can be fine as long as you don't need complicated ad-hoc queries, provable consistency or mission-critical business rules. Once you start needing those things, though, you ignore relational databases at your peril.
Of course, there's always another way to skin a cat. It is possible to work with a hybrid set-up, such as relational database at the core for business rules and consistency, but high volume demand-driven data cached out to NoSQL systems. For example, in 2008 Yahoo created a custom PostgreSQL hybrid with cloud storage backend to handle clickstream data, weighing in at 2 petabytes. I can only imagine how big it is now.
I know several Libertarians. I don't think they are nutty. No, I think they are bat-shit crazy. I have thought about it for well over half a minute, and I just can't wrap my head around the selfishness involved in a Libertarian position.
How true.
We're selfish because we don't want to take your money to support our needs or our pet social causes, and because we don't want to force you to be anything you don't want to be. I feel such a deep sense of shame washing over me right now...
Actually, deregulation ALONG WITH removal of all protectionism, bailouts, juicy government contracts, favorable (targeted) legislation, etc. would go a long way toward evening the scales between small companies and large companies.
Big companies can always find a lawyer to help them through the regulation minefield, plus they can always pay off a congressman or two to make people look the other way.
Honestly, big companies love big government, and they love bureaucracy, because THAT is what ensures their continued existence. Do you really think the Big 3 auto makers would still be in existence today if they had to function in a competitive market?
I really don't like the direction the craft is heading. We were making good progress up until Swing and WinForms, but then web development took over and it feels like we've made a serious regression.
HTML was never intended to be an application language, just a document presentation one. And rather than develop an additional language to embed real application elements, we've spent the past 10 years trying to turn a hammer into a screwdriver.
Mozilla tried to present a workable solution in the form of XUL, which actually gives web developers a real GUI toolkit to work with. The world pretty much ignored or misused it, sadly. (Although I have to admit early XUL implementation was pretty buggy and limited). At present, XUL is mainly used to create Firefox extensions, but even there we see a movement away from that to HTML.
Be that as it may, you have to admit that there are things web apps deliver that the traditional client-side program couldn't. Will we ever see a good marriage of the two? I suppose it's possible, but for the near future I foresee more and more of this 'papering over'; layering frameworks on top of suboptimal core technology in order for developers to at least achieve some sanity.
Perhaps you can clear something up for me: It was my understanding that in developer mode, you have a complete Linux environment, command line and all. Doesn't that mean you can compile C and C++ code to run on the Pre? Of course I know that the UI has to be handled through HTML/JS, but is it possible for the UI to talk to back-end components running as compiled code?
So, I wonder, how do you libertarians actually propose that people change and learn new behaviors, if there is no feedback resulting from the vast majority of their actions, and the feedback they do get is completely unclear as to it's source behavior?
Amazing things happen when people actually interact with people, instead of faceless organizations. "Feedback" does indeed happen without organizatiions, although some of the better charities often do provide you with personal messages from the people whose lives you affect (something we are extremely unlikely ever to see from a government bureaucracy). In fact, I would argue that the bigger and more official the organization (and the greater the level of government enforcement) the more likely the feedback is to be negative rather than positive. In a world where people are forced to give at fear of punishment, the more likely they are to resent the act of giving and to find any means of escape.
Also, the bigger the bureaucracy, the more likely that the greater percentage of any dollar extracted from you will go to support the bureacracy rather than support the supposed end recipient.
Of course I feel an obligation, which is why I donate money to help those in need. We libertarians tend to draw the line at enforcement, though, believing that in a truly civil society force is only used to stop those who would use force on others. It's called the principle of non-initiation of force.
A truly civil society can only exist when enough people of goodwill make free choices to help others. The whole struggle should be in the convincing of others to do good, rather than in expecting a strong-arm government to make us good. Enforcement of such has never worked, and the more you enforce, the less civil the society becomes.
> Not only that, but FreeBSD is a far more reliable and > higher-quality core than even Debian could ever hope to be.
If that's true, it's only because FreeBSD refuses to include anything in the core. Even extremely basic things like Perl and bash are ports-tree stuff and go in/usr/local. I'm sorry, but that's cheating.
No, that's sensible system design. Core is/usr, and has a wealth of system-level programs and utilities, but application software goes in/usr/local. Bash is not the FreeBSD default terminal software; tcsh is. Perl is not a core system scripting language, but it is of course needed for many tasks once you start extending the system in different directions. And/usr/local is not (as in Linux) a little tacked-on directory with nothing in it. it is a very thoroughly laid-out directory tree with everything in a sensible place. Once I moved from Linux to FreeBSD, I loved how everything was in a consistent and unsurprising location.
Yikes! But thanks for the info. You really don't use the onClick or other event handlers at all? Or do you just mean you don't reference them externally via element.onXXX?
Life would be so much better without IE6, but unfortunately it is still the standard rollout in a many large companies.
Yes, I've been considering moving all HTML rendering to the browser, but some apps that work that way tend to annoy me. A lot of the things that used to be taken for granted in web interaction start changing when you work that way. The back button won't work, you can't bookmark anything, and of course the inevitable memory leaks mean your browser memory footprint threatens to take over the desktop.
I really don't see what was so bad about the old per-page request/response model. For about 95% of what people need to do in web applications, it is just fine. Of course there are things that AJAX solves, but I try to solve everything I can before that. For example, all this fancy new stuff in Slashdot here doesn't seem to enhance usability more than a fraction over the old method.
I wrote a lightweight document management app and after thinking it through, rejected AJAX and went with a REST-ish approach. It was very nice to realize that anyone could bookmark a document, or send the URL to someone else (Of course, access controls made sure the recipient was logged in and had permission to view the document).
(In thinking about it, I realize that AJAX could work as a nice helper to a REST system, so you can send realtime feedback, such as "User [x] is trying update this document. Would you like to view the changes or save a copy?".)
-the biggest problem is the lack of good libraries and controls. It feels like programming for DOS.
Yes, too bad that Mozilla's XUL didn't take off. It was clunky and frustrating in some ways, but at least you had a real suite of widgets and controls with decent event-handling behavior.
Your thoughtfulness should at least rate a 2 or a 3.
I actually like the idea of preserving 'document-oriented' HTML, which is an endangered species.
As for the server-side JS question, I am still on the fence; just trying to examine and evaluate.
Server-side and client-side have different needs, sure, but that's more a question of the interpreter infrastructure and libraries than the language itself. Although, I do like the idea of manipulating documents with jQuery or somesuch on both the client and server side. Building HTML documents by concatenating strings or outputting at random places in code (ex. 90% of the PHP code out there) is a horrendous idea that should have died in the 90s. For any PHP work these days I use phpQuery along with a good caching library, so I can work with document semantics on the server side. I get 100% valid HTML output and I can manipulate any part of the document I want before output without ridiculous regex acrobatics or other buggy half-baked HTML parsing libraries.
If you delete an array key directly with the delete command, eg: `delete myArray[4];` the length property doesn't get updated even though the number of elements in the array does. (WTF?!?!)
That one I can't speak to... interesting if true.
Yes, delete will mull the value of an array element but leave the index. To remove an array element, use splice(), which removes AND returns the indexed element in question:
Slashdot Mirror
That has long been one of my thoughts. For example, PG'OCaml looks very promising.
Having migrated a few applications from MySQL to Postgres, the truth is, it will be painful, but the result is you will be a LOT more confident in the quality and manageability of your data. Start here
PostgreSQL has all the datatypes that MySQL has, and more (see especially the ), and usually with far less limitations. Any character type can be up to 1GB in size if needed, for example.
The biggest sources of pain will likely come from character set handling (some MySQL oddities there) and MySQL's ready acceptance of NULL where it really shouldn't occur. Learn to love grep, sed and the 'iconv' utility.
There are conversion utilities that will get you part of the way there with a DB structure dump, but they will hardly do justice to a complex database. You will have to reengineer your system--in fact you will want to, since PostgreSQL has many capabilities that you cannot take advantage of in MySQL.
Triggers and stored functions are a little less 'wieldy' in Postgres, but far more capable once you get the concepts. For one thing, MySQL re-compiles all stored procedures for every instance of a connection (making SPs in PHP web-based apps almost pointless). One caveat: Postgres does not have 'true' stored procedures in the sense that they cannot span multiple transactions. Thus they are called functions, but aside from the transaction limitation, they are far more capable than MySQL stored procedures. For example, result sets from functions can be treated exactly like result sets from tables, and nested inside other queries and views, even in the FROM clause in ways that MySQL still does not allow. Full referential transparency.
Postgres has many more indexing options than MySQL, which you will want to explore for performance tweaking.
Postgres has the RULE system which allows for query rewriting in much the way that Apache's mod_rewrite allows for URL rewriting. It is a powerful tool, allowing you to potentially get rid of tons of stored procedure code. In some ways it works like an alternate triggering mechanism, but it is very lightweight.
BTW, one way you might consider handling your migration is using PostgreSQL's new foreign data wrapper or SQL/MED functionality, which can allow you to query a MySQL table from within a PostgreSQL DB (read-only for now, but excellent for importing tables interactively)
Bingo. Exactly what I have been saying for years, but... we both know that this sort of idea is far too sensible and boring for the 'concept du jour' programming community.
Why is this modded down? +1 informative, please.
Nowhere in your rambling, incoherent response did you come close to anything that could be considered a rational thought. We are all dumber for having listened to it. I award you no points and may God have mercy on your soul.
A while back (June 5 2009) Tom Levenson was talking about his book, "Newton and the Counterfeiter: The Unknown Detective Career of the World's Greatest Scientist," on Science Friday http://www.npr.org/templates/story/story.php?storyId=105012144. A caller asked the Levenson about Stephenson's work. Levenson said that the Newton's voice was so plausible that he had stopped reading them until he had finished his own book.
Very interesting to note. I had been wondering about that part of the story.
Also, don't give up reading the trilogy! It gets better and a lot of the pieces don't come together until the final book.
Absolutely!. I am at the last 100 pages right now and it surely does not lose steam. Nor punk. (OK, I'll stop now)
It's not 2000 anymore. 99% of the problems people have historically with MySQL are simply not present in recent production versions. PostgreSQL and MySQL roughly have feature parity nowadays, Stop treating MySQL as if it's some toy. WikiVS has a good, up-to-date comparison: http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL
Big emphasis on the "roughly". The features may look the same as tick points on a list, but when you actually try to use them, vast differences show up. Roughly bundled-together features without a comprehensive plan is what it looks like to me. For example, no referential transparency or transitive closure. You can't just nest expressions, views, function calls and procedure calls transparently. You can't alias temp tables in procedures, etc... Lots of odd restrictions and "can't get there from here" scenarios.
I also find it amusing that an AC below complains about "how many storage engines"? Whoosh, that's the sound of the point flying over his head.
By the way, I'm not dissing PostgreSQL in any way, I think it's great. But it's about time some meaningless mantras stop being chanted.
Yeah, we shouldn't expect that old bugaboo "conceptual integrity" to intrude on modern software design, right? Can't use full-text indexing and foreign key constraints on the same table? What kind of compulsive freak would want that, anyway...?
I hear our dba's complain about replication too. We run services on both mysql and postgresql and from what I gathered it was far more difficult and error prone to configure the replication for complex posgresql databases (defining per table?).
Well of course replication on a complex database is going to be hard. Fact is, most MySQL databases are very simple (the only appropriate use of MySQL, IMHO). Once a MySQL database gets complicated, it is all but impossible to coax robust replication out of it. In the case of one I had to deal with, I had to finally retreat to the simplest master->slave approach, AND I had to upgrade to 5.1 for row-base replication (statement-based replication is just impossible if you have complex stored procedures). Even so, I have to set slave_exec_mode to IDEMPOTENT in order to actually keep replication running, which of course makes the actual replication far less robust. (I know, if they moved to full transactional INNODB tables it probably wouldn't be necessary, but unfortunately they need MyISAM tables for some things).
Point is, replication is HARD to get right on any moderately complex system. I doubt there will ever be a magic bullet in that regard.
MySQL replication barely deserves the name. It plain and simple DOES NOT guarantee data consistency. Maybe it's nice and easy to work with, but I would never trust mission-critical data to it.
I know that replication has been the sore point of PostgreSQL, mainly because there were several different approaches being developed--all provided as external solutions, and it could be confusing to try and wade through all the data to find the best option. Fortunately, version 9.0 (moving from alpha to beta soon) will come with built-in hot standby and streaming replication.
While insightful and informative in its own right, that isn't a logical response to my post.
He was asking for an alternative to Mysql. I was pointing out that moving from mysql to postgresql was not done by large companies with a lot of smart people working for them, because any performance improvements were not worth it.
That really depends on the kind of company and the kinds of applications involved.
MySQL can probably still handle a higher # of raw queries per second *using MyISAM tables* than PostgreSQL, however once you test with a table type like InnoDB, which has to support such things as constraints and transactions, the MySQL speed advantage is lost.
Many large web companies don't really need transactions, MVCC, constraints and other such niceties because the type of data they work with doesn't demand such precision. That's a perfect answer as to why many of the are investigating non-relational alternatives. However, a company doing business applications involving money, or other critical, non-trivial data can't afford to take such chances with data consistency.
Developers need to understand the real nature of the trade-offs involved in all these things. NoSQL type systems can be fine as long as you don't need complicated ad-hoc queries, provable consistency or mission-critical business rules. Once you start needing those things, though, you ignore relational databases at your peril.
Of course, there's always another way to skin a cat. It is possible to work with a hybrid set-up, such as relational database at the core for business rules and consistency, but high volume demand-driven data cached out to NoSQL systems. For example, in 2008 Yahoo created a custom PostgreSQL hybrid with cloud storage backend to handle clickstream data, weighing in at 2 petabytes. I can only imagine how big it is now.
Modded 0? I thought this was at least mildly funny.
I know several Libertarians. I don't think they are nutty. No, I think they are bat-shit crazy. I have thought about it for well over half a minute, and I just can't wrap my head around the selfishness involved in a Libertarian position.
How true.
We're selfish because we don't want to take your money to support our needs or our pet social causes, and because we don't want to force you to be anything you don't want to be. I feel such a deep sense of shame washing over me right now...
Actually, deregulation ALONG WITH removal of all protectionism, bailouts, juicy government contracts, favorable (targeted) legislation, etc. would go a long way toward evening the scales between small companies and large companies.
Big companies can always find a lawyer to help them through the regulation minefield, plus they can always pay off a congressman or two to make people look the other way.
Honestly, big companies love big government, and they love bureaucracy, because THAT is what ensures their continued existence. Do you really think the Big 3 auto makers would still be in existence today if they had to function in a competitive market?
Agreed. I'm not much for IDEs, but for text editors my two favorite choices are
Windows:
- UltraEdit (very nice SSH/SFTP integration)
Linux:
- Kate (KDE Advanced Text Editor) using KDE's fish://user@server/path/to protocol
Also, both support column-mode editing, which is my other non-negotiable.
I really don't like the direction the craft is heading. We were making good progress up until Swing and WinForms, but then web development took over and it feels like we've made a serious regression.
HTML was never intended to be an application language, just a document presentation one. And rather than develop an additional language to embed real application elements, we've spent the past 10 years trying to turn a hammer into a screwdriver.
Mozilla tried to present a workable solution in the form of XUL, which actually gives web developers a real GUI toolkit to work with. The world pretty much ignored or misused it, sadly. (Although I have to admit early XUL implementation was pretty buggy and limited). At present, XUL is mainly used to create Firefox extensions, but even there we see a movement away from that to HTML.
Be that as it may, you have to admit that there are things web apps deliver that the traditional client-side program couldn't. Will we ever see a good marriage of the two? I suppose it's possible, but for the near future I foresee more and more of this 'papering over'; layering frameworks on top of suboptimal core technology in order for developers to at least achieve some sanity.
Perhaps you can clear something up for me: It was my understanding that in developer mode, you have a complete Linux environment, command line and all. Doesn't that mean you can compile C and C++ code to run on the Pre? Of course I know that the UI has to be handled through HTML/JS, but is it possible for the UI to talk to back-end components running as compiled code?
So, I wonder, how do you libertarians actually propose that people change and learn new behaviors, if there is no feedback resulting from the vast majority of their actions, and the feedback they do get is completely unclear as to it's source behavior?
Amazing things happen when people actually interact with people, instead of faceless organizations. "Feedback" does indeed happen without organizatiions, although some of the better charities often do provide you with personal messages from the people whose lives you affect (something we are extremely unlikely ever to see from a government bureaucracy). In fact, I would argue that the bigger and more official the organization (and the greater the level of government enforcement) the more likely the feedback is to be negative rather than positive. In a world where people are forced to give at fear of punishment, the more likely they are to resent the act of giving and to find any means of escape.
Also, the bigger the bureaucracy, the more likely that the greater percentage of any dollar extracted from you will go to support the bureacracy rather than support the supposed end recipient.
Of course I feel an obligation, which is why I donate money to help those in need. We libertarians tend to draw the line at enforcement, though, believing that in a truly civil society force is only used to stop those who would use force on others. It's called the principle of non-initiation of force.
A truly civil society can only exist when enough people of goodwill make free choices to help others. The whole struggle should be in the convincing of others to do good, rather than in expecting a strong-arm government to make us good. Enforcement of such has never worked, and the more you enforce, the less civil the society becomes.
> Not only that, but FreeBSD is a far more reliable and
> higher-quality core than even Debian could ever hope to be.
If that's true, it's only because FreeBSD refuses to include anything in the core. Even extremely basic things like Perl and bash are ports-tree stuff and go in /usr/local. I'm sorry, but that's cheating.
No, that's sensible system design. Core is /usr, and has a wealth of system-level programs and utilities, but application software goes in /usr/local. Bash is not the FreeBSD default terminal software; tcsh is. Perl is not a core system scripting language, but it is of course needed for many tasks once you start extending the system in different directions. And /usr/local is not (as in Linux) a little tacked-on directory with nothing in it. it is a very thoroughly laid-out directory tree with everything in a sensible place. Once I moved from Linux to FreeBSD, I loved how everything was in a consistent and unsurprising location.
Yikes! But thanks for the info. You really don't use the onClick or other event handlers at all? Or do you just mean you don't reference them externally via element.onXXX?
Life would be so much better without IE6, but unfortunately it is still the standard rollout in a many large companies.
Yes, I've been considering moving all HTML rendering to the browser, but some apps that work that way tend to annoy me. A lot of the things that used to be taken for granted in web interaction start changing when you work that way. The back button won't work, you can't bookmark anything, and of course the inevitable memory leaks mean your browser memory footprint threatens to take over the desktop.
I really don't see what was so bad about the old per-page request/response model. For about 95% of what people need to do in web applications, it is just fine. Of course there are things that AJAX solves, but I try to solve everything I can before that. For example, all this fancy new stuff in Slashdot here doesn't seem to enhance usability more than a fraction over the old method.
I wrote a lightweight document management app and after thinking it through, rejected AJAX and went with a REST-ish approach. It was very nice to realize that anyone could bookmark a document, or send the URL to someone else (Of course, access controls made sure the recipient was logged in and had permission to view the document).
(In thinking about it, I realize that AJAX could work as a nice helper to a REST system, so you can send realtime feedback, such as "User [x] is trying update this document. Would you like to view the changes or save a copy?".)
-the biggest problem is the lack of good libraries and controls. It feels like programming for DOS.
Yes, too bad that Mozilla's XUL didn't take off. It was clunky and frustrating in some ways, but at least you had a real suite of widgets and controls with decent event-handling behavior.
Your thoughtfulness should at least rate a 2 or a 3.
I actually like the idea of preserving 'document-oriented' HTML, which is an endangered species.
As for the server-side JS question, I am still on the fence; just trying to examine and evaluate.
Server-side and client-side have different needs, sure, but that's more a question of the interpreter infrastructure and libraries than the language itself. Although, I do like the idea of manipulating documents with jQuery or somesuch on both the client and server side. Building HTML documents by concatenating strings or outputting at random places in code (ex. 90% of the PHP code out there) is a horrendous idea that should have died in the 90s. For any PHP work these days I use phpQuery along with a good caching library, so I can work with document semantics on the server side. I get 100% valid HTML output and I can manipulate any part of the document I want before output without ridiculous regex acrobatics or other buggy half-baked HTML parsing libraries.
How is Javascript closure evaluation monumentally broken? (Not being sarcastic, just curious)
If you delete an array key directly with the delete command, eg: `delete myArray[4];` the length property doesn't get updated even though the number of elements in the array does. (WTF?!?!)
That one I can't speak to... interesting if true.
Yes, delete will mull the value of an array element but leave the index. To remove an array element, use splice(), which removes AND returns the indexed element in question:
js> arr = [4,5,6,7];
4,5,6,7
js> print(arr.splice(2));
6
js> print(arr);
4,5,7
js> delete arr[1];
true
js> print(arr);
4,,7
Why is parent modded troll? Like it or not, it is at least a somewhat substantive argument.