It's fast out of the box, and even moreso if you know how to tune it. Coming from an Oracle background, that's a breath of fresh air.
It's very, very easy to administer. Don't have enough room on this filesystem? Move your largest table over to another with "mv" and "ln".
It comes pre-installed just about everywhere.
Is all of that true for [pick your fav DB]...perhaps, but shock though it may be, people generally look for a tool that suits their needs, not EVERY tool that suits their needs. MySQL suits the needs of a lot of people, and it's very good at what it does. I've yet to find something that I needed that it didn't do well, and given my rather painfully convoluted needs, that was something I was very pleased with.
clients that use more php put far less of a load on the system than people writing in perl scripts...
Well there you have it. Treat Perl like a scripting language and you get what you deserve.
Check out TTK, Mason or bricolage. I think you'll find that writing very low-footprint, scalabale applications is as easy in Perl as it is in many languages, and moreso than most. The problem arises when you get someone who doesn't even understand what a stateless system's likely bottlenecks will be trying to write complex code. In that case, yes, PHP protects you to a certain extent, but in doing so, it vastly limits the options of those who DO know what they're doing!
No more so than any other language. PHP really doesn't count here... it's an HTML templating tool that was adapted to programming, which is why it's great for prototyping small web tools, but even at the medium-scale (e.g. PHPNuke/PostNuke) it's already cumbersome in the extreme (look at how many times those two projects have had to re-architect). Insofar as PHP is getting back to its roots and becoming Perl again, it's a good language.
If I were starting from scratch on a new Web-related project I might use PHP, but I would almost certainly treat it as a templating system only, and then write the back-end in Perl or Java depending on the platform. But that might just be that I've not explored TTK enough... I've heard very good things about it as a templating system.
it's significantly slower than php
No, no it's not. Running any kind of benchmark on real code it's not. When you integrate Perl poorly with a Web server, then it's slow. When you integrate it well (e.g. bricolage, TTK, Mason) it's quite reasonable, and VERY easy to develop in.
[PHP is] easier to understand and easier to program in
well... to a PHP programmer yes.
PHP is a Perl derivative in roughly the same way that Java is a C++ derivative. One's children always spend their youth claiming that their parents "did it all wrong", but as they grow and mature they find that their parents had gone through all of this before and that their decisions were not so very surprising after all. PHP has come a long way, and bravo to it, but let's not get hyperbolic.
Familiarity with perl (slashdot)
Were you using Slash as an example of something written by someone familliar with Perl or as an example of something one would be familliar with?
If the former, it probably should have been "Familiarity with Perl and PHP not having been written yet (Slashcode)"
Re:Logic, Logic -- Who's Got the Logic?
on
D&D Is 30
·
· Score: 1
context-sensitive programming languages [...] pale in comparison to natural languages
Of course. But, that was not the OP's assertion. They made no qualitative distinction.
Pragmatics is all about trying to understand what someone intends to mean (vs. what the words literally mean)
No. Pragmatics is all about trying to understand what someone is trying to convey vs the many other meanings that they might have conveyed at the same time.
This is a fine line, but an important one.
Computers are positiviely famous for not being able to do this
Again, I would have to disagree. A great, but simple example is emacs. In emacs, I want to save all of my files. Instead of typing "C-x s", I type "C-x C-c". To emacs that means quit, so it asks me if I want to safe my modified files. I say yes too all but my current buffer and then it asks me if I'm sure I wanted to exit with modified files open. I say "no".
I "meant" save all of my files, but I "said" exit. The computer behaved correctly.
It may seem primative, but again... it is done and done quite often. Computers are context-sensitive beasts at this point. What you're complaining about is that they are not self-aware enough to REALIZE that they are behaving context-sensitvely. It still requires a human deciding to make them behave so.
A brief summary of my previous post would be to say that certain features of Firefox make it too easy to misuse the web browser to surf for pornography
Um.. April 1 was a while back...
But I've since discovered that actual Mozilla supported extensions such as this one, "Magpie" or this one "Prev/Next image", which are actually given web space and bookmarked by default by the Mozilla developers themselves can only be useful in the context of searching for and downloading hardcore or violent pornography
Magpie can be used to download any images, including non-violent porn, violent non-porn and non-violent, non-porn... imagine!
Prev/Next image is useful for any numerically indexed images such as software screenshots, wallpaper, artist portfolios and even, yes, porn.
Again... you... were joking... weren't you? Man, I really hope so.
Pornography is destroying the Internet and the moral health of this nation
Well, let's see... pornography not only paid for much of the exisiting Internet buildout (given that it was the first, and for a very long time, ONLY widespread profitable enterprise on the Net) it has also underwritten most major changes in media since the printing press. Ever wonder how there came to be a separate rate for postcards? Yep, porn. So, if you want to remove porn-related media start with the postal rate for postcards.
And "destroying... the moral health of this nation"? I guess you're probably refering to the US, since most of the ignorant sods that say "this nation" over the Internet are from the US. And, I would venture to say that something that has been around and a strong part of our culture for over a century... probably isn't the reason for any currently growing woes. In fact, I've noticed that in the last 10-20 years we backward US types have actually started to GET OVER porn and recognize it for what it is: pictures, nothing more, nothing less.
Perhaps someday we'll be so grown up that we can talk to each other about sex and not get flustered. Wow, imagine being an adult AND being allowed to act like it!
Having a major open source project associate itself publicly with perversion and pornography [...] is no way to gain respect.
1. Seems to work fine in every other area of life 2. When did you introduce perversion?
Repeat after me: images aren't porn unless they involve sex. The ability to manipulate imagines cannot preclude sexual images.
Those two are true regardless of how you feel about sex and porn.
Ephiphany was the right choice at the time. The idea was to have a lightweight, Mozilla-based browsing engine that could be turned into a component, not just to have a stand-alone browser.
As such I think it was a fine choice. Distribution vendors should, of course, include a full-featured browser like Galeon or Mozilla as the default user-accessible browser, but Ephiphany makes a fine component-browser.
Half-assed browsers like Konq?! It may be hard for you to believe, but some of us actually find Konq better to use than Mozilla.
It's nice to have another browser around to keep Mozilla moving forward. Stagnation is, of course, bad, but Konq isn't a full-featured browser, and has years of development to go before it is. This is why Safari is so under-featured. That's unfortunate, but they made their choice. Apple users can, fortunately, still use Firefox or Mozilla if they wish.
Konqueror, Nautilus, Epiphany, Galeon, Firefox, Mozilla et etc
Konq is a lightweight browser designed for general-purpose desktop integration, and it was the right choice at the time.
Nautilus is not a browser, and could not be replaced with one.
Epiphany, Galeon and Firefox are all Mozilla. They're just UI layers on top of the core browser, and I have no problem with making them available, just as I have no problem with making 200 skins available. No functional or administrative difference that is so profound it causes problems.
Others have replied, but let me be very specific: Microsoft was not wrong FROM A TECHNICAL STANDPOINT. Tight integration between the browser and the desktop is TECNICALLY sound. The problems were that a) they did not publish the API for tying a browser into the desktop, so only IE could implement the API and thus IE was essentially part of the OS b) they had competition in the market that they were attempting to squash by making their product useless... such a melding of GNOME and Mozilla would not render Opera useless on Linux, as long as Opera played nice with GNOME in the same ways as Mozilla.
No one in their right minds would claim that tighter integration between the browser and desktop is bad, only that it can be done badly.
Re:Logic, Logic -- Who's Got the Logic?
on
D&D Is 30
·
· Score: 1
the rigid semantics of computers (which have no pragmatics)
Absolutely wrong.
The context-sensitive syntax, grammar and semantics of many programming languages are well known.
For example, Perl uses context at the syntax level (as almost all languages do), the grammar level (making regular expressions a part of the grammar rather than oddly handled strings and having context-sensitive treatment of braces). At the semantic level, context is highly important in Perl, such as the:
while(<>){...}
construct which, due to the presence of the while loop reads from certain filehandles and writes to certain variables. Perl 6 will add even more semantic richness, alowing certain commands to load an entirely different parser (e.g. to part Perl 5 code) or to modify the meaning of various core language constructs and compile-time.
Context sensitivity is not limited to Perl, of course, but it's probably the one language that makes the widest use of it, in order to be more like a natural language in terms of its structure and adaptability.
Comparing Nautilus with Konqueror is pure nonsense, comparing GNOME with KDE is even bigger nonsense. If we get a team of developers on a Table and discuss all the crap we find between KDE and GNOME then I can tell from own experience that the answer is clearly that GNOME will fail horrible here.
What can you say... most of that isn't even coherent enough to be deemed english.
But KDE had exactly all these things 2 years ago already. There is a development difference of 4 years between both Desktop solutions.
And there's a development difference of 2-4 years in the other direction on other issues. What's surprising about one (very good) desktop system having different priorities than another (very good) desktop system?
I thought that the whole point of integer registers in Parrot was to not use PMCs
Integer, string, and float registers are really for internal use by compilers. Anything that you expose to the user as a variable is going to have to go in a PMC. While it might be shadowed in an int register for performance, in most cases you won't be able to avoid the allocation of a PMC. At least that was Dan's take at the talk he gave on Parrot internals.
It's nice to say "this is just an int, I can tell that by looking at the code", but in many dynamic languages, you can pull the rug out from under such assumptions at run time, and Perl is certainly one such. Perl 6 in fact has a well defined way to walk up the stack and modify existing code, it's how you write "use" (remember all of Perl 6 will be written in Perl 6).
This is the price you pay for using a dynamic language.
That said, a PMC is only heavy-weight in terms of construction and destruction. When working with a PMC, there's just an extra pointer dereference that the machine has to make, so it's no more costly than the C:
You are correct... most of the time, and Larry corrected me on part of this. But even then, you're not REALLY dealing with an int, you're dealing with a PMC that stores an int along with garbage collection information, a vtable that keeps track of how to modify it, etc. The JIT might find a way to optimize it down to a hardware int in some circumstances, but I would not hold my breath.
Shared memory negotiation as in "setting up the segment and conferring access to it" is blurred with shared memory negotiation as in "accessing data in the segment in a negotiated (e.g. locked) way." Clearly when I said that a thread doesn't have that overhead, I meant the setup, not the locking, which the thread would still have to do.
I assume you don't really mean that you agree with me, since you don't seem to. You probably just used the wrong username.
Here's the deal: Sometimes stored procedures are a win. Those cases are fairly limited. For the rest of the cases, it's a matter of propper data management.
For example, one of the classic reasons to use stored procedures is to "keep the code close to the data". But, that's a totally arbitrary concept. You can't have the stored procedures bypassing, security, transactional atomicity, constraints, etc. so there's just as much indirection. "Ah!" you say, "but the stored procedures execute inside the server!"
Do they? Do you halt your server in order to run them? No. So, you run them in another thread. Aha! That thread is close to the server! Sure is. You know why? Because it can access the same memory, but then so can your process. It's true. Go look at the implementation sometime. You're getting data via shared memory, which you have to negotiate control over (the same semephore-based locking a thread would have to use). So the only overhead is the negotiation of the shared memory, which the thread doesn't have to do.
If you think shared memory negotiation overhead is your bottleneck in a process that inherently involves disk reads... well, let's just say that hwo stored procedures scale or don't is not your largest problem....
To sum up MySQL sucks. So does every other RDBMS I've ever worked with, but that's because being constrained in your access to your data sucks. MySQL is a fine tool for many jobs, but if your job happens to not be one such... then I invite you to apply another tool. Knock yourself out.
Just don't go around saying, as the other poster did "Bull. Fucking. Shit." when someone says MySQL is an adequate job for most tasks, and an ideal one for many.
read Stephenson going on for two pages about a pipe organ
I did. Did you? Personally, I found the topic interesting and more than a little informative (to use the Slashdot nomenclature). Was it the most insightful passage in the book? No. Was it worth 2 pages? That's really a matter of taste, but to those of us who appreciate technical geekery regardless of genre, it was.
If the book was not for you, cool. If you prefer another author's approach, cool. I have my own gripes about Stephenson, too. But, what I'm not so willing to swallow is that the Slashdot crowd has any place going off on someone for exploring a technical tangent. What's more, the pipe organ bit was NECESSARY for the reader to understand how one could possibly fashion a computer out of these parts, and why it made our hero particularly capable of doing so.
One of my professors got his PhD in CS by writing his thesis on a computer which he constructed entirely out of water and piping that any plumber would have access to, so I saw this coming early on in the story, but it was still a brilliant bit, and not at all obvious to most readers. Had he dropped it in as "and then he made an automatic calculator out of some spare pipe-organ parts", most of the readers would be up in arms over how stupid the idea was!
I am insulted, and bit shamed, that you feel I was being anti-erudite. I'm not
I guess I was a bit harsh. Let me just say that your post fit well into a trend of "don't give me detail, just advance the plot," that I see in most modern reviews of technical fiction. Someone else cited Clancy and he gets the same kind of reviews.
But, go read Melville and you'll find out that Stephenson and Clancy are dead-on-target minimalists compared to some of the authors that we hold in such high regard as to force school-children to read them.
Stephenson's one and only failing in my eyes is that he tends to get lost in the euphoria of his own stories, and I swear to GOD I can point to the exact paragraph in Cryptonomicon where he started thinking about Quicksilver... the book just "finishes up" after the cable-diving bit, and it feels forced and abrubt (which is impressive in a GIANT book like that). Stephenson needs to learn to hold on to the story and not give it up until it's done.
Diamond age had EXACTLY the same problem. Brilliant book. Great start. Good characters. Stunningly cogent extrapolation of tech. Worst ending I've read in ages, but there too, I can see where it stopped being "The Diamond Age or A Young Lady's Illustrated Primer" and reverts to "A proposed outline for The Diamond Age or A Young Lady's Illustrated Primer" with little or no finish.
Beyond that failing, he is the modern-day Arthur C. Clarke: a man whose grasp of the present tech is sufficient to credibly extrapolate its future and whose prose is more than sufficient to demonstrate to us the promise, folly and danger of our endevours. The fact that he loses focus 2/3 of the way through a book is, IMHO, small price to pay for that kind of clarity.
As others have pointed out, this is a classic blunder. Oracle, for example, has type constraints (it's been a while, that's not the actual term) that you have to twiddle if you want to get this kind of thing the way you want. Please note that I said "the way you want"... there is no "right" here, because you're dealing with real numbers in finite precision. If you feel that your number is in a cononical form when you enter it, you should be using a fixed-point type, which all modern RDBMSs (including MySQL) support.
create table bar (task int, tasktype int, requestdate int)
return a list of users and the associated task with the lowest (highest) priority and earliest date
Well, not that I like to do people's homework for them, but, here's what any database that supports subqueries will end up doing anyway:
select user, task, priority, requestdate from foo join bar on foo.tasktype = bar.tasktype group by user, task order by priority desc, requestdata asc limit 10
Sorry, but that one doesn't require a sub-query at all. Did you, perhaps mis-state the problem?
you are guilty of the same thing with blanket statements like 'Stored procedures and similar features are just bloat, and gain you no real advantage' - many programmers working with more advanced RDBMSes know otherwise
And yet, correctly, the MySQL folks have prioritized features based on real need rather than what "people know" on Slashdot. When a customer needs something, it's added to or moved up the list. When a customer says "eh, I guess we can live without", something else ends up getting done first. Subqueries and stored procedures turn out to be the most widely gotten around features of modern RDBMSs
I also disagree with your assertion about subqueries being slow
Good, because I would too. That's why I never said that.
you have to take care, yes
THAT is what I said. You have to take care. Worse, you have to take care to avoid the really non-obvious penalties that fall out of how the optimizer decides to strategize the sub-queries. Oracle manuals just give up and suggest that you run the query with the option that prints out the optimization strategy and try to hand-tune around the optimizer retro-actively! That seems to me a like a feature you're better off leaving to people who have thought enough about it to create the temporary tables themselves.
BUT, the MySQL folks disagree with me here, and ARE adding this feature. They're just taking their time about it, and doing more important things first.
I'm interested to know: have you ever run into the problems mentioned in MySQL Gotchas? Or are these deviations from the ANSI standards something that doesn't matter in practice.
Most of what's listed there are the same sorts of things you could list for any modern RDBMS. They are places where MySQL's feature-set is richer than the standard (just as Oracle's is, or PostgreSQL's, etc) and where the assumptions that YOU might make about how such extensions behave could be incorrect.
I would suggest that anyone using MySQL on a regular basis read that document, as it's quite helpful, but to point out a database's extensions as some kind of reason not to use it seems... a tad overzealous.
Partenogenesis is, in general, spontaneous generation of life without the actual act of procreation. Granted, the biology community has narrowed the definition, but I think it's safe to say that classically, this is parthenogenesis, no?
Slashdot Mirror
The most fundamental reasons to use MySQL are:
It's fast out of the box, and even moreso if you know how to tune it. Coming from an Oracle background, that's a breath of fresh air.
It's very, very easy to administer. Don't have enough room on this filesystem? Move your largest table over to another with "mv" and "ln".
It comes pre-installed just about everywhere.
Is all of that true for [pick your fav DB]...perhaps, but shock though it may be, people generally look for a tool that suits their needs, not EVERY tool that suits their needs. MySQL suits the needs of a lot of people, and it's very good at what it does. I've yet to find something that I needed that it didn't do well, and given my rather painfully convoluted needs, that was something I was very pleased with.
clients that use more php put far less of a load on the system than people writing in perl scripts...
Well there you have it. Treat Perl like a scripting language and you get what you deserve.
Check out TTK, Mason or bricolage. I think you'll find that writing very low-footprint, scalabale applications is as easy in Perl as it is in many languages, and moreso than most. The problem arises when you get someone who doesn't even understand what a stateless system's likely bottlenecks will be trying to write complex code. In that case, yes, PHP protects you to a certain extent, but in doing so, it vastly limits the options of those who DO know what they're doing!
Perl had to be adapted to web development
... to a PHP programmer yes.
No more so than any other language. PHP really doesn't count here... it's an HTML templating tool that was adapted to programming, which is why it's great for prototyping small web tools, but even at the medium-scale (e.g. PHPNuke/PostNuke) it's already cumbersome in the extreme (look at how many times those two projects have had to re-architect). Insofar as PHP is getting back to its roots and becoming Perl again, it's a good language.
If I were starting from scratch on a new Web-related project I might use PHP, but I would almost certainly treat it as a templating system only, and then write the back-end in Perl or Java depending on the platform. But that might just be that I've not explored TTK enough... I've heard very good things about it as a templating system.
it's significantly slower than php
No, no it's not. Running any kind of benchmark on real code it's not. When you integrate Perl poorly with a Web server, then it's slow. When you integrate it well (e.g. bricolage, TTK, Mason) it's quite reasonable, and VERY easy to develop in.
[PHP is] easier to understand and easier to program in
well
PHP is a Perl derivative in roughly the same way that Java is a C++ derivative. One's children always spend their youth claiming that their parents "did it all wrong", but as they grow and mature they find that their parents had gone through all of this before and that their decisions were not so very surprising after all. PHP has come a long way, and bravo to it, but let's not get hyperbolic.
Familiarity with perl (slashdot)
Were you using Slash as an example of something written by someone familliar with Perl or as an example of something one would be familliar with?
If the former, it probably should have been "Familiarity with Perl and PHP not having been written yet (Slashcode)"
context-sensitive programming languages [...] pale in comparison to natural languages
Of course. But, that was not the OP's assertion. They made no qualitative distinction.
Pragmatics is all about trying to understand what someone intends to mean (vs. what the words literally mean)
No. Pragmatics is all about trying to understand what someone is trying to convey vs the many other meanings that they might have conveyed at the same time.
This is a fine line, but an important one.
Computers are positiviely famous for not being able to do this
Again, I would have to disagree. A great, but simple example is emacs. In emacs, I want to save all of my files. Instead of typing "C-x s", I type "C-x C-c". To emacs that means quit, so it asks me if I want to safe my modified files. I say yes too all but my current buffer and then it asks me if I'm sure I wanted to exit with modified files open. I say "no".
I "meant" save all of my files, but I "said" exit. The computer behaved correctly.
It may seem primative, but again... it is done and done quite often. Computers are context-sensitive beasts at this point. What you're complaining about is that they are not self-aware enough to REALIZE that they are behaving context-sensitvely. It still requires a human deciding to make them behave so.
Slightly amusing, but incredibly stupid.
:-(
Did you read what he was following up to? I would say that the only danger in that kind of reply is that the OP might have assunmed he was serious.
A brief summary of my previous post would be to say that certain features of Firefox make it too easy to misuse the web browser to surf for pornography
... the moral health of this nation"? I guess you're probably refering to the US, since most of the ignorant sods that say "this nation" over the Internet are from the US. And, I would venture to say that something that has been around and a strong part of our culture for over a century... probably isn't the reason for any currently growing woes. In fact, I've noticed that in the last 10-20 years we backward US types have actually started to GET OVER porn and recognize it for what it is: pictures, nothing more, nothing less.
Um.. April 1 was a while back...
But I've since discovered that actual Mozilla supported extensions such as this one, "Magpie" or this one "Prev/Next image", which are actually given web space and bookmarked by default by the Mozilla developers themselves can only be useful in the context of searching for and downloading hardcore or violent pornography
Magpie can be used to download any images, including non-violent porn, violent non-porn and non-violent, non-porn... imagine!
Prev/Next image is useful for any numerically indexed images such as software screenshots, wallpaper, artist portfolios and even, yes, porn.
Again... you... were joking... weren't you? Man, I really hope so.
Pornography is destroying the Internet and the moral health of this nation
Well, let's see... pornography not only paid for much of the exisiting Internet buildout (given that it was the first, and for a very long time, ONLY widespread profitable enterprise on the Net) it has also underwritten most major changes in media since the printing press. Ever wonder how there came to be a separate rate for postcards? Yep, porn. So, if you want to remove porn-related media start with the postal rate for postcards.
And "destroying
Perhaps someday we'll be so grown up that we can talk to each other about sex and not get flustered. Wow, imagine being an adult AND being allowed to act like it!
Having a major open source project associate itself publicly with perversion and pornography [...] is no way to gain respect.
1. Seems to work fine in every other area of life
2. When did you introduce perversion?
Repeat after me: images aren't porn unless they involve sex. The ability to manipulate imagines cannot preclude sexual images.
Those two are true regardless of how you feel about sex and porn.
Ephiphany was the right choice at the time. The idea was to have a lightweight, Mozilla-based browsing engine that could be turned into a component, not just to have a stand-alone browser.
As such I think it was a fine choice. Distribution vendors should, of course, include a full-featured browser like Galeon or Mozilla as the default user-accessible browser, but Ephiphany makes a fine component-browser.
Half-assed browsers like Konq?! It may be hard for you to believe, but some of us actually find Konq better to use than Mozilla.
It's nice to have another browser around to keep Mozilla moving forward. Stagnation is, of course, bad, but Konq isn't a full-featured browser, and has years of development to go before it is. This is why Safari is so under-featured. That's unfortunate, but they made their choice. Apple users can, fortunately, still use Firefox or Mozilla if they wish.
Konqueror, Nautilus, Epiphany, Galeon, Firefox, Mozilla et etc
Konq is a lightweight browser designed for general-purpose desktop integration, and it was the right choice at the time.
Nautilus is not a browser, and could not be replaced with one.
Epiphany, Galeon and Firefox are all Mozilla. They're just UI layers on top of the core browser, and I have no problem with making them available, just as I have no problem with making 200 skins available. No functional or administrative difference that is so profound it causes problems.
So what's the problem?
Others have replied, but let me be very specific: Microsoft was not wrong FROM A TECHNICAL STANDPOINT. Tight integration between the browser and the desktop is TECNICALLY sound. The problems were that a) they did not publish the API for tying a browser into the desktop, so only IE could implement the API and thus IE was essentially part of the OS b) they had competition in the market that they were attempting to squash by making their product useless... such a melding of GNOME and Mozilla would not render Opera useless on Linux, as long as Opera played nice with GNOME in the same ways as Mozilla.
No one in their right minds would claim that tighter integration between the browser and desktop is bad, only that it can be done badly.
Absolutely wrong.
The context-sensitive syntax, grammar and semantics of many programming languages are well known.
For example, Perl uses context at the syntax level (as almost all languages do), the grammar level (making regular expressions a part of the grammar rather than oddly handled strings and having context-sensitive treatment of braces). At the semantic level, context is highly important in Perl, such as the:construct which, due to the presence of the while loop reads from certain filehandles and writes to certain variables. Perl 6 will add even more semantic richness, alowing certain commands to load an entirely different parser (e.g. to part Perl 5 code) or to modify the meaning of various core language constructs and compile-time.
Context sensitivity is not limited to Perl, of course, but it's probably the one language that makes the widest use of it, in order to be more like a natural language in terms of its structure and adaptability.
Comparing Nautilus with Konqueror is pure nonsense, comparing GNOME with KDE is even bigger nonsense. If we get a team of developers on a Table and discuss all the crap we find between KDE and GNOME then I can tell from own experience that the answer is clearly that GNOME will fail horrible here.
What can you say... most of that isn't even coherent enough to be deemed english.
But KDE had exactly all these things 2 years ago already. There is a development difference of 4 years between both Desktop solutions.
And there's a development difference of 2-4 years in the other direction on other issues. What's surprising about one (very good) desktop system having different priorities than another (very good) desktop system?
Stallman is a jelous developer, and you shall have no others before him!
Integer, string, and float registers are really for internal use by compilers. Anything that you expose to the user as a variable is going to have to go in a PMC. While it might be shadowed in an int register for performance, in most cases you won't be able to avoid the allocation of a PMC. At least that was Dan's take at the talk he gave on Parrot internals.
It's nice to say "this is just an int, I can tell that by looking at the code", but in many dynamic languages, you can pull the rug out from under such assumptions at run time, and Perl is certainly one such. Perl 6 in fact has a well defined way to walk up the stack and modify existing code, it's how you write "use" (remember all of Perl 6 will be written in Perl 6).
This is the price you pay for using a dynamic language.
That said, a PMC is only heavy-weight in terms of construction and destruction. When working with a PMC, there's just an extra pointer dereference that the machine has to make, so it's no more costly than the C:
No, he corrected me on the p5l mailing list on this same point. See my reply to another post in this thread for info on exactly how.
You are correct... most of the time, and Larry corrected me on part of this. But even then, you're not REALLY dealing with an int, you're dealing with a PMC that stores an int along with garbage collection information, a vtable that keeps track of how to modify it, etc. The JIT might find a way to optimize it down to a hardware int in some circumstances, but I would not hold my breath.
On re-reading there is ambiguity in my post:
Shared memory negotiation as in "setting up the segment and conferring access to it" is blurred with shared memory negotiation as in "accessing data in the segment in a negotiated (e.g. locked) way." Clearly when I said that a thread doesn't have that overhead, I meant the setup, not the locking, which the thread would still have to do.
I assume you don't really mean that you agree with me, since you don't seem to. You probably just used the wrong username.
Here's the deal: Sometimes stored procedures are a win. Those cases are fairly limited. For the rest of the cases, it's a matter of propper data management.
For example, one of the classic reasons to use stored procedures is to "keep the code close to the data". But, that's a totally arbitrary concept. You can't have the stored procedures bypassing, security, transactional atomicity, constraints, etc. so there's just as much indirection. "Ah!" you say, "but the stored procedures execute inside the server!"
Do they? Do you halt your server in order to run them? No. So, you run them in another thread. Aha! That thread is close to the server! Sure is. You know why? Because it can access the same memory, but then so can your process. It's true. Go look at the implementation sometime. You're getting data via shared memory, which you have to negotiate control over (the same semephore-based locking a thread would have to use). So the only overhead is the negotiation of the shared memory, which the thread doesn't have to do.
If you think shared memory negotiation overhead is your bottleneck in a process that inherently involves disk reads... well, let's just say that hwo stored procedures scale or don't is not your largest problem....
To sum up MySQL sucks. So does every other RDBMS I've ever worked with, but that's because being constrained in your access to your data sucks. MySQL is a fine tool for many jobs, but if your job happens to not be one such... then I invite you to apply another tool. Knock yourself out.
Just don't go around saying, as the other poster did "Bull. Fucking. Shit." when someone says MySQL is an adequate job for most tasks, and an ideal one for many.
read Stephenson going on for two pages about a pipe organ
I did. Did you? Personally, I found the topic interesting and more than a little informative (to use the Slashdot nomenclature). Was it the most insightful passage in the book? No. Was it worth 2 pages? That's really a matter of taste, but to those of us who appreciate technical geekery regardless of genre, it was.
If the book was not for you, cool. If you prefer another author's approach, cool. I have my own gripes about Stephenson, too. But, what I'm not so willing to swallow is that the Slashdot crowd has any place going off on someone for exploring a technical tangent. What's more, the pipe organ bit was NECESSARY for the reader to understand how one could possibly fashion a computer out of these parts, and why it made our hero particularly capable of doing so.
One of my professors got his PhD in CS by writing his thesis on a computer which he constructed entirely out of water and piping that any plumber would have access to, so I saw this coming early on in the story, but it was still a brilliant bit, and not at all obvious to most readers. Had he dropped it in as "and then he made an automatic calculator out of some spare pipe-organ parts", most of the readers would be up in arms over how stupid the idea was!
I am insulted, and bit shamed, that you feel I was being anti-erudite. I'm not
I guess I was a bit harsh. Let me just say that your post fit well into a trend of "don't give me detail, just advance the plot," that I see in most modern reviews of technical fiction. Someone else cited Clancy and he gets the same kind of reviews.
But, go read Melville and you'll find out that Stephenson and Clancy are dead-on-target minimalists compared to some of the authors that we hold in such high regard as to force school-children to read them.
Stephenson's one and only failing in my eyes is that he tends to get lost in the euphoria of his own stories, and I swear to GOD I can point to the exact paragraph in Cryptonomicon where he started thinking about Quicksilver... the book just "finishes up" after the cable-diving bit, and it feels forced and abrubt (which is impressive in a GIANT book like that). Stephenson needs to learn to hold on to the story and not give it up until it's done.
Diamond age had EXACTLY the same problem. Brilliant book. Great start. Good characters. Stunningly cogent extrapolation of tech. Worst ending I've read in ages, but there too, I can see where it stopped being "The Diamond Age or A Young Lady's Illustrated Primer" and reverts to "A proposed outline for The Diamond Age or A Young Lady's Illustrated Primer" with little or no finish.
Beyond that failing, he is the modern-day Arthur C. Clarke: a man whose grasp of the present tech is sufficient to credibly extrapolate its future and whose prose is more than sufficient to demonstrate to us the promise, folly and danger of our endevours. The fact that he loses focus 2/3 of the way through a book is, IMHO, small price to pay for that kind of clarity.
As others have pointed out, this is a classic blunder. Oracle, for example, has type constraints (it's been a while, that's not the actual term) that you have to twiddle if you want to get this kind of thing the way you want. Please note that I said "the way you want"... there is no "right" here, because you're dealing with real numbers in finite precision. If you feel that your number is in a cononical form when you enter it, you should be using a fixed-point type, which all modern RDBMSs (including MySQL) support.
Battle-cry of the troll.
Later on, confirming the wisdom (or lack thereof) of this post:
Bull. FUCKING. Shit.
I'm reminded of the old "This is the title of the story, which is also found several times in the story itself", which I loosly quote from memory:Nuff said.
you are guilty of the same thing with blanket statements like 'Stored procedures and similar features are just bloat, and gain you no real advantage' - many programmers working with more advanced RDBMSes know otherwise
And yet, correctly, the MySQL folks have prioritized features based on real need rather than what "people know" on Slashdot. When a customer needs something, it's added to or moved up the list. When a customer says "eh, I guess we can live without", something else ends up getting done first. Subqueries and stored procedures turn out to be the most widely gotten around features of modern RDBMSs
I also disagree with your assertion about subqueries being slow
Good, because I would too. That's why I never said that.
you have to take care, yes
THAT is what I said. You have to take care. Worse, you have to take care to avoid the really non-obvious penalties that fall out of how the optimizer decides to strategize the sub-queries. Oracle manuals just give up and suggest that you run the query with the option that prints out the optimization strategy and try to hand-tune around the optimizer retro-actively! That seems to me a like a feature you're better off leaving to people who have thought enough about it to create the temporary tables themselves.
BUT, the MySQL folks disagree with me here, and ARE adding this feature. They're just taking their time about it, and doing more important things first.
I'm interested to know: have you ever run into the problems mentioned in MySQL Gotchas? Or are these deviations from the ANSI standards something that doesn't matter in practice.
Most of what's listed there are the same sorts of things you could list for any modern RDBMS. They are places where MySQL's feature-set is richer than the standard (just as Oracle's is, or PostgreSQL's, etc) and where the assumptions that YOU might make about how such extensions behave could be incorrect.
I would suggest that anyone using MySQL on a regular basis read that document, as it's quite helpful, but to point out a database's extensions as some kind of reason not to use it seems... a tad overzealous.
Partenogenesis is, in general, spontaneous generation of life without the actual act of procreation. Granted, the biology community has narrowed the definition, but I think it's safe to say that classically, this is parthenogenesis, no?