How is this relevant? A byte is still a byte. You can still skip to the end of a chunk by counting bytes.
Your "optimization" requires that the document know its encoding beforehand, and will break if the encoding is changed. This is not a deal killer, but it does feel wrong having the higher level data depend on the mutable lower level in such a way.
2. XML is nested. Length changes in a child node would require all ancestors to be recalculated
Only on writing the file, and the cost should be relatively small, since anything modified will, by definition, be in memory already.
You were talking about making the xml more random access. This hurts random writes, and would be more costly than you think to calculate because it would require the serialized data (or more hacks to pre-calculate length).
3. The optimization is broken by whitespace changes that otherwise do not affect the data
And this matters why? If it is part of the container format, any program that modifies the data would be expected to keep it up-to-date.
This is NOT part of XML. XML does not care about whitespace between tags. Being encoded in XML, your data should not care about whitespace between tags. Adding such a constraint is fucking retarded.
5. You don't need to have random access to the XML file unless it is just a ridiculously massive document. You already get random access in-memory via DOM
MS Word and similar files can be ridiculously massive, etc.
6. You probably didn't save much parsing time anyhow
For a short document, that's true. For a hundred page document, you potentially save parsing 99% of the document prior to first display. That's a -lot- of parsing time. For a multi-thousand-page government document, that's probably high double digit seconds of parsing time.
Here is my genius idea that does not go against XML while trying to optimize it: use multiple XML files. Better algorithms ftw.
Sounds like something straight out of the Watchmen. Bill Gates is going to start beaming angry psychic paperclips full of pirate story.docs over to Cupertino, but only after nullifying the reality distortion powers of Steve Jobs with...tachyon particles.
You've really struck a chord with me. All these theta-level posters lack the compass necessary to plot a course past the merely awful puns and gain memborship to the oft-maligned sectors of Combat Punnery.
This is a terrible, horrible idea for many reasons
1. Different encodings = different byte lengths 2. XML is nested. Length changes in a child node would require all ancestors to be recalculated 3. The optimization is broken by whitespace changes that otherwise do not affect the data 4. You can already parse XML as a stream. It's called SAX 5. You don't need to have random access to the XML file unless it is just a ridiculously massive document. You already get random access in-memory via DOM 6. You probably didn't save much parsing time anyhow
New students shouldn't even get an editor. I say keep it simple; bang out the cadence of ones and zero with your head against the desk. If your app compiles, the university covers hospitalization and rehabilitation costs. If not, piss off, because this is exactly what programming for most corporations is like.
I should have dismissed this as not being pertinent to AJAX immediately in my original post. Didn't mean it as a slight against you, I was just trying to cull a useless subthread of my own making.
Sometimes I have wanted more than just a marked up document back from the server. For example, changing the currency changes the price of many basket items -- in many different places -- but I don't want my AJAX call to return the entire basket display again. (I know it can be worked around, but the point remains that HTML documents (or even fragments) aren't always what I want back from the server, even if they're just fine for you).
Return XML with the data points that need updating, then, and have the javascript update those values. I was already doing this with Flash 5's XMLSocket back in 2002 (possibly earlier). Less update latency, too, because XMLSocket can be server pushed.
So how exactly does rails "put to use, especially to find a profitable or practical use" AJAX? Rails does not put anything to use. It's a web application framework. You can install rails and it does not put AJAX (or javascript, or HTML, or XML, or kittens, etc.) to use. You can write a web application and it does not put AJAX to use. And so on.
To say that "rails utilizes AJAX" is just plain wrong. You probably meant that rails makes it easy for the developer to utilize AJAX.
Your definition is very shortsighted. How does a developer utilize Ajax? Through code. Where is the Ajax implementation? In Rails. So, the developer is both using and utilzing Ajax via the Rails implementation. Frameworks are middle tiers - they use and are used, utilize and are utilized. Rails puts AJAX, HTML, and XML to use on behalf of the programmer. The "on behalf of the programmer" is redundant in that sentence because we're talking about a framework. It could also be argued that simply making a thing available in a framework causes the the thing to be utilized by said framework since encapsulating technologies in a set architecture for developer consumption is what frameworks do.
You wanna start with Quine's theories of the indeterminacy of translation (frequently extended to include translation between idolects)? Or his theory that an extensional account of meaning is impossible? Or Tarski's theory that a study of semantics in natural languages is impossible? Or how about Davidson's assertion that substitutional theories of semantics are always subject to Taski's objections? I guess it doesn't really matter what you start with as I've got pretty good grounds for suggesting that semantic wars are impossible. Yay for (semantic) world peace.
Why is it that, every time I call somebody on semantics, I get the board-clearing "well, everyone has their own definition of things" postulate instead of specific argument on why their definition or usage of the object of debate is more correct? I don't know whether I should award you extra points for citing sources or take them away for being needlessly obfuscatory. Some interesting reading in there, at least.
'Tis ironic really, because you threaten semantic war over the utilization of "utilize" with a non-intentional referring entity (rails), which is impossible by definiton. Cute.
I'm not sure what you mean by "non-intentional referring entity" here. Possible counter: Rails is a manifestation of intent.
(Really oughta go do some work now)
Same:) This conversation has been way, way above usual slashdot standards, hence all the time spent.
You're argument is valid, but please play fair. You used an extraneous arrow, and your Perl doesn't compile.
I forgot a pair of parens, which demonstrates my point even better. As for the "arrow": I always include the extra infix in my own code because I think it makes things a bit more obvious and matches $foo->method->subMethod syntax, making the code slightly easier to scan through.
Besides, I think most people would write it as
$_->blahblah for @{$foo->{monkey}{bananna_array}};
Have you never heard of TIMTOWTDI? I could have also done a
, but I didn't. I don't like your preferred reversed syntax and use the foreach loop I provided instead (with the missing parens supplied, of course).
You could've written that and still made your point about Ruby's superiority in object/reference syntax. As it is, the point you made was that you don't use Perl, or at least that you don't use Perl well.
I use it daily in e-commerce. You have no concept of TIMTOWTDI and are posting AC. Who is the one full of shit here?
Testing in multiple browsers will only show you that's it's broken. Fixing pages so that they look right is hard, and sometime impossible.
Nothing about that is AJAX-specific, and unfixable layout problems can always be worked around. This is a basic reality of the web. Using it to level pot shots at technology X simply doesn't work because it also affects technologies A through W.
Powerful, yes. Well designed, no. (Of course, this is a subjective judgement, and javascript does what it does a lot better than the alternatives. But there is still a lot it does badly, or shouldn't do at all.)
As far as embedded scripting languages go, I consider it damned amazing. We could have gotten something like TCL instead *cringe*...and this makes it a bad choice for AJAX. If your only return type is marked up documents then you end up having to do funky stuff some of the time.
I don't need a fucking CORBA connection to the sever. Marked up documents are fine. There is this "interweb" thing that uses them all the time!
This is true to an extent. Rails makes it really easy to write most of your application, which leads to minimalism in your code.
Minimalism is not how many lines of code you wrote. Minimalism is how many features you left out.
It's not that slow.
No, it's really, really slow.
It should be quick enough for a lot of web apps. I find that any slowness is due to my bad coding rather than ruby's speed in the majority of cases. (Although this might say more about my coding that it does about ruby;)
It's definitely fast enough to do web work with, and it has good caching support which can make up for slow page rendering. Regardless, I think the development time/performance tradeoff is worth it. Ruby and Rails are just joyous to work in.
No it doesn't. Rails providers helpers for AJAX and javascript, but it does not utilize them. People writing rails apps might utilise them, and the fact that rails helps you out is a Good Thing. It would be wrong, though, to suggest that rails somehow depends upon them.
Utilize != use. Read the usage note in this definition. No dependency was suggested.
Never get into a semantic war with me - I will end you:)
I think the grandparent poster is right -- comparing AJAX and rails is misleading. Rails is much better thought out and designed; AJAX is more of a cobbled together pragmatic solution.
The GP was the one who made the comparison (unless we are talking about a different post?). Really, AJAX is only a methodology, so the comparison is even more wrong.
The real beauty of rails is that it makes it easy to write applications properly, and discourages you from reinventing the wheel badly.
I can't believe you post is currently rated as +5 Insightful - it's a knee jerk, rant-like, fanboy reaction to the a criticism to your current "this is so cool" hype word du jour.
I'm sorry, could you repeat that? Your knee was jerking too much for me to concentrate.
If having to test on every browser (not to mention browser versions) is not a mark of a poorly design technology i don't know what is.
If not testing every target platform you intend to deploy to is not a mark of poor QA methodology, I don't know what is. Say you wrote an app in C that builds clean on Redhat. Do you automatically claim compatibility with all Linux distros? No, because that is a trivialization of the complex technology you are buidling upon. Browsers are complex technology.
It's so well designed that people felt the need of doing many different implementations AND you need an abstraction layer on top of the language. Impressive.
Way to fly that argument right into the side of a mountain. People didn't "feel the need", they fucking have to for each browser they make. Then you make out like an abstraction layer is some sort of furthur insult when it is, instead, the logical reaction to their being multiple somewhat-incompatible implementations. On top of all that, the incompatibilities have nothing to do with the design of the language itself. That's all implementation-specific.
"nowhere near perfect, but it does function admirably in the scope of AJAX (when not using IE's broken ass implementation)"
So how exactly are you making your case here?
Logically. IE CSS is a shoddy implementation, and the vast majority of users are running it. Can you blame AJAX for being compatible with the browser 90% of the web uses? Out here in the real world, you have to use what is available to you.
The OP mentioned it's "possible" to perforate the abstraction layer in the context of a framwork which (according to the article) achieves it's increase in developer productivity by being very specific of a certain type of situation.
If he had told me that in person I'd immediately set his ignore bit. OF COURSE IT IS POSSIBLE TO IGNORE ABSTRACTIONS. His statement was a tautology - no information content whatsoever. The question is never "can I ignore them?", it is "should I?".
In response you went into a half-insulting rant that really doesn't show any logical or coherent arguments ("sounds like marketroid speak" and "who [...] Almost nobody" are not logical or coherent arguments)
The OP's blurb I was replying to was barely coherent. Bullshit spoken, bullshit called. I actually thought I credited the OP too much by providing any sort of explantion whatsoever - it should have been obvious to anyone reading.
Now for the real arguments: - AJAX is not a framework
Thank you, we all knew this
However AJAX does not in any way whatsover improve software development productivity - it actually is slower to implement most functionalities (functionality being something an application does for the users, not some piece of programming coolness) in AJAX than it is to implement it as full-page refresh in whatever server-side dynamic page generation language you are using.
Thank you, we all knew this, and nobody was debating it. Why are you talking about it? AJAX offers additional functionality and polish at the expense of being more difficult to write. Everyone knows this. Additional functionality increases complexity and development time. This is SO. FUCKING. OBVIOUS.
A couple of reasons why software development productivity with AJAX is lower than with "traditional" approaches:
Again, why are you talking about this?
- Comparative lack of frameworks/libraries that implement common functions in an AJAX compatible way. Meaning developers spend time reinventing the wheel while everybody else just creates new cars.
Compared to what? What common functions? Can you be le
I have neither used nor encountered $_. If it is in there, nobody is using it. Really, very little syntax is borrowed from Perl. The $dollar and @at sigils are used, but only as scoping signifiers (which I find useful, being that self.at and @at are two different things in Ruby). First class regex support is also in there, but I consider that a feature. There's too much syntax in a regex to work nicely without either a bloated interface or first class support - look at preg_replace in PHP. Too ugly to use in a single line.
Compare foreach my $b @{$foo->{monkey}->{bananna_array}} { $b->blahblah } to foo.monkey.bannanas.each {|b| b.blahblah}
Perl doesn't get really ugly until you start using references. Ruby stays clean, fresh, and smells of pine.
Based on Larry's apocalypses (apocalypti? I like that better, as I do not slobber all over when saying it), it looks he's trying to design a metalanguage to encapsulate every idiom instead of just a better Perl. I imagine this would bloat development time a bit.
AJAX is based on technologies with extremely poor design and implementation, such as browsers, JavaScript, and HTML (poorly designed for this application, perfectly ok for marking up documents)
The only part of that I'll give you is the poor IE implementation of CSS. Browsers' main problem lies in their non-compliance with standards. Solution: test in multiple browsers. WOW, THAT WAS HARD. Next up: JavaScript. Poor design? I was shocked at how powerful the language is when I finally started digging into it after years of avoidance. Poor imlpementation? Not really - just many different implementations. Of course, this can and has already been worked around with libs that abstract the differences away for you. HTML? It still is used as a basic markup language, with all the heavy lifting being pushed into the CSS. Now, CSS is nowhere near perfect, but it does function admirably in the scope of AJAX (when not using IE's broken ass implementation).
Rails takes lessons learned from a decade of server-side Web development, as well as the catastrophe that has become J2EE through over-engineering, and simplifies it to the essential mechanisms.
I half-agree. You imply a minimalism that isn't present. The framework is quite complicated in places and does a lot of tricky things. You see, programming with just the essential mechanisms sucks; you've gone back to CGI.pm. What Rails does is provide a massive lever with which to move your problem. The Actual Work Done Per Line of Code metric exceeds any other framework I have used before. Code efficiency is the watchword, not simplicity.
Built on top of Ruby, which is itself a pretty thin simplification wrapper over C++,
No it isn't. Ruby's implementation is a big, slow VM that doesn't act much like C++ at all. Really, the poor performance is the only thing I dont like about the language.
it combines the simplification of Web site development best practices (MVC, proper tiers, etc.) with the power of an high level development language overlaid directly on top of a low level near-assembly language, with the ability to perforate the abstraction layer (first through modifying Rails source in Ruby, then through C extensions) if needed for performance or other reasons.
That sounds like marketroid speak, and is about 3/4ths BS. Perforate the abstraction layer? Jesus. And just who is running around writing C++ extensions for web apps? Almost nobody. Takes too damn long, and isn't as safe as running through the VM.
Short, brutal version: AJAX built on crap by script kiddies, Rails on bedrock by software engineers.
DHH is something closer to a hacker, not to mention the fact that rails utilizes AJAX and, more generally, javascript all over the place. Does that make AJAX apps built on top Rails rock? Or does all that terrible, awful AJAX stuff diminish Rails? Maybe they, I don't know, utilise the same foundation technologies and standards and complement each other quite nicely? Maybe you are an idiot?
Personally, I'd rather fight a much weaker (but much smarter) boss, where I actually had to show some initiative, where the fight is different from week to week. Ever played the same chess game twice with an experienced player?
So your ultimate scenario is to play chess with a weakling? Companies must be throwing money at you to design the next big MMO.
Nice troll. Kernel programming is not program programming. It is programming a program to run programs. The cost of additional complexity in a kernel is a couple orders of magnitude higher than your run of the mill php app. What is good for the goose is not necessarily good for the kernel.
Slashdot Mirror
I wonder if there is a correlation between hard drive size and blindness
Now I can't get that Deee-Lite song out of my head.
"Stem cells in the heaaaaeaaaaaaaeaeaeaaaaaaart"
1. Different encodings = different byte lengths
How is this relevant? A byte is still a byte. You can still skip to the end of a chunk by counting bytes.
Your "optimization" requires that the document know its encoding beforehand, and will break if the encoding is changed. This is not a deal killer, but it does feel wrong having the higher level data depend on the mutable lower level in such a way.
2. XML is nested. Length changes in a child node would require all ancestors to be recalculated
Only on writing the file, and the cost should be relatively small, since anything modified will, by definition, be in memory already.
You were talking about making the xml more random access. This hurts random writes, and would be more costly than you think to calculate because it would require the serialized data (or more hacks to pre-calculate length).
3. The optimization is broken by whitespace changes that otherwise do not affect the data
And this matters why? If it is part of the container format, any program that modifies the data would be expected to keep it up-to-date.
This is NOT part of XML. XML does not care about whitespace between tags. Being encoded in XML, your data should not care about whitespace between tags. Adding such a constraint is fucking retarded.
5. You don't need to have random access to the XML file unless it is just a ridiculously massive document. You already get random access in-memory via DOM
MS Word and similar files can be ridiculously massive, etc.
6. You probably didn't save much parsing time anyhow
For a short document, that's true. For a hundred page document, you potentially save parsing 99% of the document prior to first display. That's a -lot- of parsing time. For a multi-thousand-page government document, that's probably high double digit seconds of parsing time.
Here is my genius idea that does not go against XML while trying to optimize it: use multiple XML files. Better algorithms ftw.
I'm eating his courage, not his inability to parry. The stem cells are just gravy. Literally.
I've always believed that eating the heart of a fallen enemy would give me his courage. Getting his stem cells to boot is a totally unexpected bonus.
Sounds like something straight out of the Watchmen. Bill Gates is going to start beaming angry psychic paperclips full of pirate story .docs over to Cupertino, but only after nullifying the reality distortion powers of Steve Jobs with...tachyon particles.
What do modern high schoolers make? A fat load of nothing that's what.
Hey, I made a fat load of fat: soap! Of course, I work in IT now, so I suppose it wasn't all that practical.
You've really struck a chord with me. All these theta-level posters lack the compass necessary to plot a course past the merely awful puns and gain memborship to the oft-maligned sectors of Combat Punnery.
This is a terrible, horrible idea for many reasons
1. Different encodings = different byte lengths
2. XML is nested. Length changes in a child node would require all ancestors to be recalculated
3. The optimization is broken by whitespace changes that otherwise do not affect the data
4. You can already parse XML as a stream. It's called SAX
5. You don't need to have random access to the XML file unless it is just a ridiculously massive document. You already get random access in-memory via DOM
6. You probably didn't save much parsing time anyhow
Lac Operon is the best sci fi name ever
[some guy] Hey Louie, here's some hydrogen
[Louie] I wanna DIP MY BALLS in it!
New students shouldn't even get an editor. I say keep it simple; bang out the cadence of ones and zero with your head against the desk. If your app compiles, the university covers hospitalization and rehabilitation costs. If not, piss off, because this is exactly what programming for most corporations is like.
"NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!"
(additional text added to get Lucas' dialogue past the lameness filter)
multiple browser testing confusion
:) This conversation has been way, way above usual slashdot standards, hence all the time spent.
I should have dismissed this as not being pertinent to AJAX immediately in my original post. Didn't mean it as a slight against you, I was just trying to cull a useless subthread of my own making.
Sometimes I have wanted more than just a marked up document back from the server. For example, changing the currency changes the price of many basket items -- in many different places -- but I don't want my AJAX call to return the entire basket display again. (I know it can be worked around, but the point remains that HTML documents (or even fragments) aren't always what I want back from the server, even if they're just fine for you).
Return XML with the data points that need updating, then, and have the javascript update those values. I was already doing this with Flash 5's XMLSocket back in 2002 (possibly earlier). Less update latency, too, because XMLSocket can be server pushed.
So how exactly does rails "put to use, especially to find a profitable or practical use" AJAX? Rails does not put anything to use. It's a web application framework. You can install rails and it does not put AJAX (or javascript, or HTML, or XML, or kittens, etc.) to use. You can write a web application and it does not put AJAX to use. And so on.
To say that "rails utilizes AJAX" is just plain wrong. You probably meant that rails makes it easy for the developer to utilize AJAX.
Your definition is very shortsighted. How does a developer utilize Ajax? Through code. Where is the Ajax implementation? In Rails. So, the developer is both using and utilzing Ajax via the Rails implementation. Frameworks are middle tiers - they use and are used, utilize and are utilized. Rails puts AJAX, HTML, and XML to use on behalf of the programmer. The "on behalf of the programmer" is redundant in that sentence because we're talking about a framework. It could also be argued that simply making a thing available in a framework causes the the thing to be utilized by said framework since encapsulating technologies in a set architecture for developer consumption is what frameworks do.
You wanna start with Quine's theories of the indeterminacy of translation (frequently extended to include translation between idolects)? Or his theory that an extensional account of meaning is impossible? Or Tarski's theory that a study of semantics in natural languages is impossible? Or how about Davidson's assertion that substitutional theories of semantics are always subject to Taski's objections? I guess it doesn't really matter what you start with as I've got pretty good grounds for suggesting that semantic wars are impossible. Yay for (semantic) world peace.
Why is it that, every time I call somebody on semantics, I get the board-clearing "well, everyone has their own definition of things" postulate instead of specific argument on why their definition or usage of the object of debate is more correct? I don't know whether I should award you extra points for citing sources or take them away for being needlessly obfuscatory. Some interesting reading in there, at least.
'Tis ironic really, because you threaten semantic war over the utilization of "utilize" with a non-intentional referring entity (rails), which is impossible by definiton. Cute.
I'm not sure what you mean by "non-intentional referring entity" here. Possible counter: Rails is a manifestation of intent.
(Really oughta go do some work now)
Same
My father was killed by a microkernel.
You're argument is valid, but please play fair. You used an extraneous arrow, and your Perl doesn't compile.
I forgot a pair of parens, which demonstrates my point even better. As for the "arrow": I always include the extra infix in my own code because I think it makes things a bit more obvious and matches $foo->method->subMethod syntax, making the code slightly easier to scan through.
Besides, I think most people would write it as
$_->blahblah for @{$foo->{monkey}{bananna_array}};
Have you never heard of TIMTOWTDI? I could have also done a
map {$_->blahblah} @{$foo->{monkey}->{bananna_array}};
, but I didn't. I don't like your preferred reversed syntax and use the foreach loop I provided instead (with the missing parens supplied, of course).
You could've written that and still made your point about Ruby's superiority in object/reference syntax. As it is, the point you made was that you don't use Perl, or at least that you don't use Perl well.
I use it daily in e-commerce. You have no concept of TIMTOWTDI and are posting AC. Who is the one full of shit here?
Testing in multiple browsers will only show you that's it's broken. Fixing pages so that they look right is hard, and sometime impossible.
...and this makes it a bad choice for AJAX. If your only return type is marked up documents then you end up having to do funky stuff some of the time.
;)
:)
Nothing about that is AJAX-specific, and unfixable layout problems can always be worked around. This is a basic reality of the web. Using it to level pot shots at technology X simply doesn't work because it also affects technologies A through W.
Powerful, yes. Well designed, no. (Of course, this is a subjective judgement, and javascript does what it does a lot better than the alternatives. But there is still a lot it does badly, or shouldn't do at all.)
As far as embedded scripting languages go, I consider it damned amazing. We could have gotten something like TCL instead *cringe*
I don't need a fucking CORBA connection to the sever. Marked up documents are fine. There is this "interweb" thing that uses them all the time!
This is true to an extent. Rails makes it really easy to write most of your application, which leads to minimalism in your code.
Minimalism is not how many lines of code you wrote. Minimalism is how many features you left out.
It's not that slow.
No, it's really, really slow.
It should be quick enough for a lot of web apps. I find that any slowness is due to my bad coding rather than ruby's speed in the majority of cases. (Although this might say more about my coding that it does about ruby
It's definitely fast enough to do web work with, and it has good caching support which can make up for slow page rendering. Regardless, I think the development time/performance tradeoff is worth it. Ruby and Rails are just joyous to work in.
No it doesn't. Rails providers helpers for AJAX and javascript, but it does not utilize them. People writing rails apps might utilise them, and the fact that rails helps you out is a Good Thing. It would be wrong, though, to suggest that rails somehow depends upon them.
Utilize != use. Read the usage note in this definition. No dependency was suggested.
Never get into a semantic war with me - I will end you
I think the grandparent poster is right -- comparing AJAX and rails is misleading. Rails is much better thought out and designed; AJAX is more of a cobbled together pragmatic solution.
The GP was the one who made the comparison (unless we are talking about a different post?). Really, AJAX is only a methodology, so the comparison is even more wrong.
The real beauty of rails is that it makes it easy to write applications properly, and discourages you from reinventing the wheel badly.
Agreement
I can't believe you post is currently rated as +5 Insightful - it's a knee jerk, rant-like, fanboy reaction to the a criticism to your current "this is so cool" hype word du jour.
I'm sorry, could you repeat that? Your knee was jerking too much for me to concentrate.
If having to test on every browser (not to mention browser versions) is not a mark of a poorly design technology i don't know what is.
If not testing every target platform you intend to deploy to is not a mark of poor QA methodology, I don't know what is. Say you wrote an app in C that builds clean on Redhat. Do you automatically claim compatibility with all Linux distros? No, because that is a trivialization of the complex technology you are buidling upon. Browsers are complex technology.
It's so well designed that people felt the need of doing many different implementations AND you need an abstraction layer on top of the language. Impressive.
Way to fly that argument right into the side of a mountain. People didn't "feel the need", they fucking have to for each browser they make. Then you make out like an abstraction layer is some sort of furthur insult when it is, instead, the logical reaction to their being multiple somewhat-incompatible implementations. On top of all that, the incompatibilities have nothing to do with the design of the language itself. That's all implementation-specific.
"nowhere near perfect, but it does function admirably in the scope of AJAX (when not using IE's broken ass implementation)"
So how exactly are you making your case here?
Logically. IE CSS is a shoddy implementation, and the vast majority of users are running it. Can you blame AJAX for being compatible with the browser 90% of the web uses? Out here in the real world, you have to use what is available to you.
The OP mentioned it's "possible" to perforate the abstraction layer in the context of a framwork which (according to the article) achieves it's increase in developer productivity by being very specific of a certain type of situation.
If he had told me that in person I'd immediately set his ignore bit. OF COURSE IT IS POSSIBLE TO IGNORE ABSTRACTIONS. His statement was a tautology - no information content whatsoever. The question is never "can I ignore them?", it is "should I?".
In response you went into a half-insulting rant that really doesn't show any logical or coherent arguments ("sounds like marketroid speak" and "who [...] Almost nobody" are not logical or coherent arguments)
The OP's blurb I was replying to was barely coherent. Bullshit spoken, bullshit called. I actually thought I credited the OP too much by providing any sort of explantion whatsoever - it should have been obvious to anyone reading.
Now for the real arguments:
- AJAX is not a framework
Thank you, we all knew this
However AJAX does not in any way whatsover improve software development productivity - it actually is slower to implement most functionalities (functionality being something an application does for the users, not some piece of programming coolness) in AJAX than it is to implement it as full-page refresh in whatever server-side dynamic page generation language you are using.
Thank you, we all knew this, and nobody was debating it. Why are you talking about it? AJAX offers additional functionality and polish at the expense of being more difficult to write. Everyone knows this. Additional functionality increases complexity and development time. This is SO. FUCKING. OBVIOUS.
A couple of reasons why software development productivity with AJAX is lower than with "traditional" approaches:
Again, why are you talking about this?
- Comparative lack of frameworks/libraries that implement common functions in an AJAX compatible way. Meaning developers spend time reinventing the wheel while everybody else just creates new cars.
Compared to what? What common functions? Can you be le
I have neither used nor encountered $_. If it is in there, nobody is using it. Really, very little syntax is borrowed from Perl. The $dollar and @at sigils are used, but only as scoping signifiers (which I find useful, being that self.at and @at are two different things in Ruby). First class regex support is also in there, but I consider that a feature. There's too much syntax in a regex to work nicely without either a bloated interface or first class support - look at preg_replace in PHP. Too ugly to use in a single line.
Compare
foreach my $b @{$foo->{monkey}->{bananna_array}} { $b->blahblah }
to
foo.monkey.bannanas.each {|b| b.blahblah}
Perl doesn't get really ugly until you start using references. Ruby stays clean, fresh, and smells of pine.
Based on Larry's apocalypses (apocalypti? I like that better, as I do not slobber all over when saying it), it looks he's trying to design a metalanguage to encapsulate every idiom instead of just a better Perl. I imagine this would bloat development time a bit.
AJAX is based on technologies with extremely poor design and implementation, such as browsers, JavaScript, and HTML (poorly designed for this application, perfectly ok for marking up documents)
The only part of that I'll give you is the poor IE implementation of CSS. Browsers' main problem lies in their non-compliance with standards. Solution: test in multiple browsers. WOW, THAT WAS HARD. Next up: JavaScript. Poor design? I was shocked at how powerful the language is when I finally started digging into it after years of avoidance. Poor imlpementation? Not really - just many different implementations. Of course, this can and has already been worked around with libs that abstract the differences away for you. HTML? It still is used as a basic markup language, with all the heavy lifting being pushed into the CSS. Now, CSS is nowhere near perfect, but it does function admirably in the scope of AJAX (when not using IE's broken ass implementation).
Rails takes lessons learned from a decade of server-side Web development, as well as the catastrophe that has become J2EE through over-engineering, and simplifies it to the essential mechanisms.
I half-agree. You imply a minimalism that isn't present. The framework is quite complicated in places and does a lot of tricky things. You see, programming with just the essential mechanisms sucks; you've gone back to CGI.pm. What Rails does is provide a massive lever with which to move your problem. The Actual Work Done Per Line of Code metric exceeds any other framework I have used before. Code efficiency is the watchword, not simplicity.
Built on top of Ruby, which is itself a pretty thin simplification wrapper over C++,
No it isn't. Ruby's implementation is a big, slow VM that doesn't act much like C++ at all. Really, the poor performance is the only thing I dont like about the language.
it combines the simplification of Web site development best practices (MVC, proper tiers, etc.) with the power of an high level development language overlaid directly on top of a low level near-assembly language, with the ability to perforate the abstraction layer (first through modifying Rails source in Ruby, then through C extensions) if needed for performance or other reasons.
That sounds like marketroid speak, and is about 3/4ths BS. Perforate the abstraction layer? Jesus. And just who is running around writing C++ extensions for web apps? Almost nobody. Takes too damn long, and isn't as safe as running through the VM.
Short, brutal version: AJAX built on crap by script kiddies, Rails on bedrock by software engineers.
DHH is something closer to a hacker, not to mention the fact that rails utilizes AJAX and, more generally, javascript all over the place. Does that make AJAX apps built on top Rails rock? Or does all that terrible, awful AJAX stuff diminish Rails? Maybe they, I don't know, utilise the same foundation technologies and standards and complement each other quite nicely? Maybe you are an idiot?
all they have to do is supply the blonde!
But then they'd be getting only half of what they want
All I can think of of Peter Griffin flying past the kitchen window in a plane, laughing.
Personally, I'd rather fight a much weaker (but much smarter) boss, where I actually had to show some initiative, where the fight is different from week to week. Ever played the same chess game twice with an experienced player?
So your ultimate scenario is to play chess with a weakling? Companies must be throwing money at you to design the next big MMO.
Nice troll. Kernel programming is not program programming. It is programming a program to run programs. The cost of additional complexity in a kernel is a couple orders of magnitude higher than your run of the mill php app. What is good for the goose is not necessarily good for the kernel.