No one at the time expected the changes in CISC processors. CISC processors still do have a "complex" instruction set in that they allow multiple forms of adddressing and varying length opcodes. However, internally these chips have become much more RISC-like. The current generation of Pentiums actually does an internal version of dynamic translation from CISC to RISC-micro-ops (which may be 1 or more per CISC instruction) and executes the micro-ops using a different instruction set internally. This internal RISC instruction set is used so central to the design that the L1 I-Cache is not actually a verbatim data cache of the CISC instructions but actually a trace cache of the translated RISC-like micro-ops.
It really just goes to show the error in the view that RISC and CISC are considered opposite approaches to processor design. The dichotomy was more pronounced in the early days of chip design, but the fact was that proponents of both approaches had good points, and so it was inevitable that modern chips combine the best of both philosophies.
I think the progress made on the PowerPC architecture is a testament to its viability. The fact that it's even managed to stay anywhere close to Intel/AMD is remarkable given the difference in R&D dollars (I'm just guessing). But the timing of the Intel switch makes perfect sense.
Consider the switch to the PowerPC in the 90s. It was a time when Microsoft was rapidly catching up to the Mac in terms of UI, and computers were generally underpowered for the common applications that people needed. Gambling on a more promising architecture could have paid off huge if the performance panned out. That never happened, and Apple was in pretty bad shape by the late 90s.
Now, however, computer performance has reached adequate levels for all the things the common people want... audio, video, web surfing, word processing. We can always use more power, but performance is not such a big deal as it used to be. Since they're not seeking a competitive advantage in performance, it makes sense of Apple to at least assure commodity performance by going with the dominant CPU architecture. Apple has contiunously struggled with supply problems from chip vendors for years, hopefully this will now be behind them, and they can focus on the creative part of their business which is where they've always excelled.
There were always several of these types in the low level classes I took when I got my BS. Why would you take computer science if you didn't actually want to learn it? There are much easier degrees to get, and almost anything would be more useful than csci if you don't plan on actually working with computers when you graduate. I mean seriously, what good could come of it?
I'm planning on buying the fastest G5 tower that Apple ships just before they shift completely to Intel. Although the G5 towers are mammoth, they are possibly (IMO) the most beautiful towers, inside and out, ever to be created. And in terms of performance I feel they will hold out for a very long time. Eventually I will probably retire Mac OS X in favor of some flavor of Linux on it, and run it as a server into the distant future. If I ever have any spare time I can tinker with the compiler and explore the Power architecture as a hobby.
Jobs' vision is important to Apple (by all evidence anyway), but the other half of the equation is talent. Dell can never get the talent Apple has because people who are that good don't want to work for Dell. Vision's not enough, it's all about the people and Apple's got that locked down. Dell probably has good business people, but that's something else entirely.
On the other hand you can have talent but no vision? Microsoft is the perfect example. Sure, Gates has a vision, but it's a vision for Microsoft software to control everything. He's more interested in integration than functionality. And at the end of the day it's just too geeky a vision to really catch on. You'll notice Apple does integration too, but it's not the driving theme, they put it where it makes sense. It pisses off some of the free software zealots, but the Apple customer base pretty much eats it up.
It's not so much charisma as the fact that Apple actually has interesting products. Who wants to hear some suit talk about the next wave of 100 slightly different models of commodity PC? Hell, even considering Apple seems to be the only computer manufacturer that's ever succeeded at make something that looks halfway decent, I don't think anyone would turn out for just hardware (ipods and intel chips aside). No, it's the software that keeps people coming back to Apple. Sure, all the hardcore fans and zealots care deeply about the new hardware specs, but only so they can decide the perfect time to renew their investment in Apple's platform.
I never bought a Mac after Win 95 came out because the software just wasn't that great anymore... no differentiation. But by the time Mac OS X hit, and Windows viruses started escalating, Apple was looking pretty attractive again and not for their underpowered hardware of the time either. Now it seems Apple has the kind of code base that they can really push feature-wise while Microsoft struggles to maintain Babel's XP and get something new out the door this year.
So 'security through obscurity' (i'm beginning to dislike that phrase) is fine when you're not 'the main target' and hence works to Linux's advantage but it's not OK, at the same level, for Windows to make it more difficult to find vulnerabilities in the first place by not revealing it's source code?
Maybe some open-source hippie zeolots don't think it's OK for Windows to keep its source code hidden, but don't ascribe that opinion to me. I have no problem with commercial software, I dislike some of Microsoft's predatory practices, but that's about the extent of it.
Not to mention that the majority of those vulnerabilities only affect a limited number of installations, sometimes so small as to make virus-style transmission difficult.
And of course there's the issue that for the average computer user who don't have any blackhats after them, Linux, BSD or OS X is going to a lot more secure in a practical sense just because they aren't the main target. I'm the first to admit that the most popular OS is going to get a lot more security scrutiny, but I don't really care which OS is more secure in theory. I only care that I'm not getting infected on a regular basis.
Re:Loving complexity for complexity's sake
on
Ruby Off the Rails
·
· Score: 2, Informative
He's correct that certain tasks are easier in Ruby than in java, not to mention that the code is more readable. But he is missing in my opinion the most important part of Rails and that the ORM. Use scaffolding or don't use it. But if you bypass Active Record you're just making more work for yourself.
The article isn't about Rails... in fact it's not even about database-driven websites... or even web programming in general. It's just a comparison of the Ruby and Java languages in general. ORM is neither here nor there.
But here's an equally difficult question: what is conciousness? Can you define it?
It's an axiom of human experience. Maybe you could write a definition, but its still unverifiable from the outside. This is (currently) an intractable problem for science to tackle, but I see it casting a shadow over the field of AI. The baby elephant in the room.
And what makes you think the human brain is anything more than just algorithms?
The clue is consciousness. Why should an algorithmic machine be self-aware?
Unfortunately we can only observe consciousness with any certainty in our own selves. Anything else that looks conscious could just be powered by a complex algorithm.
Until someone actually discovers a mechanism for consciousness, it's ridiculous to assume one way or the other that our brains make us conscious. They provide cognition, but what makes us conscious may or may not be in there. Artificial intelligence is an interesting problem, but at some point the deeper issues will have to be tackled.
LOL, as if you could do thing the ruby way in Java.
Re:Amusing, but mostly wrong.
on
Ajax in Action
·
· Score: 1
I'm sorry, but you need to step up and defend your own points. 80% of your responses are "I never said that or that or that". Just because he did not literally quote you does not mean you did not imply all those things.
Quoting myself (for the third or fourth time now): "The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place.
Um, state is kept in sessions through the use of cookies. It has nothing to do with AJAX. Cookies are not perfect (they may be turned off), but they are a far cry from Byzantine.
You've answered your own question here.
So what you're trying to say is that server-based applications are garbage? That's not a foregone conclusion. If you need a smart client code a smart client, that doesn't mean there aren't benefits to doing things the other way.
Can you point out where I say that a transmission protocol makes things procedural?
I can't point out anywhere where you say how web applications are procedural, I was just trying to guess at your meaning. You just say "dumb xml data structures get passed to "stateless" objects (in other words, procedures)". Only where are the stateless objects? The backend code is all object-oriented and stateful, and the JavaScript code has the current view as its state. Where's the procedural code?
So you're saying that if all of us clever technology types put our heads together, no one will be able to devise a content scheme that has more capability than HTML while remaining compatible with HTTP?
Web applications are about the most expensive development effort the world has ever seen. So my answer, with respect to any reasonable alternative, is, "less than the cost of a Web application."
Of course someone can come up with a better idea. But that's 1% of the problem. Then you have to implement it on every platform and have it shipping with every computer.
Also where do you get the idea that web applications are so expensive? This is just your impression. The web's limitations may be its downfall when it comes to rich interfaces, but it's a strength when it comes to speedy development and deployment of simple apps.
On the other hand, I would like you to explain how asserting that something is badly designed constitutes pretention.
No your disdain due to an assertion that I'm following a herd is pretentious.
I also never said that Web applications are "a poor copy of traditional client applications.
Are you for real? Or am I just not allowed to summarize? The whole gist of your arguments was that web applications are a 'lobotimization' of older technologies. I just assumed client applications, but maybe you were referring to something else. Either way, your arguments by themselves are not cohesive, I have to extrapolate somewhat to argue at all.
And in the midst of your pragmatism, how hard do you work to blind yourself to the debilitating design flaws inherent in the technology that supplies you with a living?
There's no need to blind myself to any flaws. That those flaws are debihilitating is simply your unsubstantiated opinion. The web grew up organically and so things like AJAX are clearly not ideal, but on the other hand they get the job done. The fact is that most things people want to do on computers do on the Internet do not require complex interfaces. You can point out a million ways web applications could be better, but ultimately they work pretty well and they're pretty easy to develop. You've pointed out several flaws, but you haven't made a case for why they are so debihilitating. Either you are not comfortable with the web app paradigm and the associated tools, or you are only interested in things that the web isn't good at. My point is not that the web is good at everything, but rather its very good at a large number of things that a large number of people are interested in using.
You came out firing about what garbage web apps were because they were lobotomized versions of pre-existing technology. The web is designed as ligh
I made no assertion one way or the other about HTML and HTTP being suitable for particular purposes. Eulogize all you want about the wonders of the Web. It has nothing to do with my point.
Okay, well if it had nothing to do with your point then why even mention that HTTP is a 'lobotomized' form of something else?
Had you been able to hold my entire sentence in your little head at once, you would have seen that my point was about "object oriented" vs. "procedural," not "platform independent" vs. "platform dependent."
Nice ad hominem attack. That really proves your intelligence.
Um, in case you didn't read your own comment, you said that the web is procedural because dumb data is passed to 'stateless' objects. I explained that this is nonsense because there's nothing stateless about web applications. Yes, HTTP is stateless. Therefore web applications implement state at a higher level. You write the backend in Java, PHP, Ruby, Perl or any other language which supports any number of programming paradigms. You write your frontend in Javascript (if you need it) which is fully object-oriented. Where's the procedural code?
An intelligent reader would have discerned my point: they are *data structures*, not objects.... The point is that real software gives you a choice.
As indeed I did. But what you didn't explain is why you need to pass objects to the client? Since everything is happening on the server, the only thing passed to the client is presentation. Maybe it's straight HTML, or maybe it's in XML format so that it can easily be coerced and inserted via Javascript. The idea that software is not 'real' unless it's a client-server architecture with code being transmitted across the network is extremely narrowminded.
My contention is precisely that Ajax attempts to simulate an object-oriented model by layering hideously complicated sets of stuff on top of a pre-existing structure that is not itself object oriented (or, more precisely, used to be object oriented until it was lobotomized).
Honestly, have you ever written a web application? If all your code is object-oriented, how is it that then magically it is lobotomized by a transmission protocol and suddenly procedural. There's plenty wrong with web development, but I'm afraid you're not getting it.
Yes, we all know that Javascript puts "view" code in the browser. Bully for you. And I apologize for not being sufficiently excited that my Web applications force me to take nearly the entire processing load on my server while the client's 3GHz machine sits idle waiting for a picture to paint. I will try to imitate your macho stoicism by meditating on the fact that my application code has the privilege of staying "in a controlled environment where it is secure." While I do this, I will also try to avoid any unpleasant questions about the security of my browser.
You're just highlighting the difference between regular GUI apps and web apps. They both have their advantages. I'm not saying traditional apps are dead. Your problem is you don't seem to think there is any value to keeping your code on your server, or distributing your application by means of a URL that anyone can type in to instantly access your application, or tight integration with tons of other applications on the same platform. Or maybe you just think there is a better way of achieving these benefits. Well call me when the better solution is out there. In the meantime I'll be making my living on the web.
Ajax, on the other hand, is capable of doing considerably less.
Yeah, and getting it out to the masses. What good is your ideal solution if no one uses it?
Yes, HTML is simpler than writing a gui. Perhaps you can explain how this relates to what I said.
Gladly. Most web applications are content related. Manipulating and presenting this content is core to the web app, so naturally using a platform that supports
Web apps are ALWAYS more difficult than the equivalent in client apps.
Only if you don't know how to use any frameworks. Writing a web app in raw PHP is like writing a client app drawing directly to the screen and capturing clicks and keystrokes. Of course GUI toolkits are going to be more mature having been a core area of commercial development over the past 25 years while the web has only been heavily prospected for 10.
Most development is not "for the internet", it is for in-house apps where you really DON'T NEED a web app.
Well as long as your company has one standard platform, and there are no outdates machines, and you have suitable infrastructure for automatic deployment and upgrades.
If you have pointy-haired bosses telling you to do everything based on buzzwords without even taking your opinion into account, then you should be looking for another job, not griping about technology trends.
reiteration of previous point cause yur out of good things to say
That's funny, because it seems I said a lot while you said nothing other than "I disagree".
So you think people like to download and install software, and you think that everything should be written in a verbose language with bloated APIs using cumbersome engineering techniques, and you think that content creation is an afterthought that can be accomplished equally well on any platform. That doesn't make you anything more than elitist.
I have a clue for you. Any moron can list 100 flaws with the web, but it takes a genius to come up with something better and get market penetration. In the meantime you can cry sour grapes about how the web is shit, but I'll be out there running my own business and developing applications that people actually use. When something better comes along, I'll be there because I don't have some idealogical ties to the 'one true way' of doing things.
Re:Ajax Killed Himself
on
Ajax in Action
·
· Score: 3, Interesting
Take a reliable, stateful transport protocol (TCP) and lobotomize it so that connection state gets thrown away. This is http. Take a platform-independent object technology (Java) and lobotomize it so that dumb xml data structures get passed to "stateless" objects (in other words, procedures), and all processing must happen at one end of the connection. This is Web applications. Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a browser. So: having gone from a world of functional, stateful, distributed applications engineered to a true software model, we are now back (despite all the self-congratulatory rhetoric about "objects") to procedural programming and dumb terminals (meaning Web browsers). In other words, 1970s technology with pictures. Any half-wit can see that this situation is broken. How do we fix it? The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place. Brilliant.
Oh please, not this tired argument again! What you software engineering nazis are forgetting is that HTTP and HTML were designed to transmit static content. In that regard the protocol and the markup language are a tremendous success. HTML and HTTP are incredibly scalable and easy to use, which means getting more done in far less time. Remember that most of the web is static information. In fact, web infrastructure was so dead simple and easy to work with that web applications have flourished. It's not like there weren't competing technologies, and if they were the panacaea you seem to think, no doubt they would have done better in the marketplace.
The real problem here is your inability to think outside your own comfort zone.
Take a platform-independent object technology (Java) and lobotomize it so that dumb xml data structures get passed to "stateless" objects (in other words, procedures), and all processing must happen at one end of the connection. This is Web applications.
This sentence is complete gibberish. Java is platform independent? Pretty close maybe, but you still have to test it for every target platform. There are advantages to having your application running on your server. Dumb XML data structures? No, we pass view data to the browser... maybe XML to be processed via JavaScript, maybe HTML/CSS for raw output, maybe an image, maybe a string. Why pass bloated objects and more code to be tested on every target platform when we can just pass the data we want the user to see? "stateless" objects? Just because HTTP is stateless doesn't mean web applications are. This is a separate issue from object-orientedness, which also has nothing to do with underlying protocols. all processing must happen at one end of the connection? View processing can be done client-side via Javascript which is very much optimized for that type of code. Meanwhile the bulk of your application code stays on the server in a controlled environment where it is secure. Don't underestimate the value of running your code in only one place.
You seem to think being able to pass Java objects to a remote computer would be some kind of revolution in web development, but it would introduce a whole slew of issues, and for what? Not much we can't do just as easily now (unless you only know Java).
Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a browser.
HTML + CSS is orders of magnitude simpler than presenting typical content through a GUI. Remember, the web is first and foremost about content. Name one other format that you can edit in a text editor and get anywhere near the power of HTML and CSS. Not PDF, Not Word Docs, Not Illustrator Files, Not Quark Files. Web browsers are not GUI technology. The fact that people can use it as a suitable replacement for GUI technology is a testament to
Let's face it though. Javascript is hack to make a web-based document viewing technology into an interactive one. It would be far better to upgrade HTTP and HTML to natively support the functionality that all interactive web-apps need then to download the same boiler-plate javascript code trillions of times forever and ever.
Better from a technological standpoint, yes, but logistically impossible. What we can hope for is incremental improvement. Better CSS and Javascript support, Xforms, SVG. Its nice to think that something could come and sweep away all the web's problems, replacing it with perfect new tech, but I'm afraid HTTP/HTML/CSS/Javascript is far too ingrained for that.
UNLESS -- you write your own accessibility aids and write your own UI framework that compiles into both an AJAX version and a web accessible version.
It doesn't need to be that complicated. You can write standard forms that are simply enhanced with AJAX if it is available. With proper server side architecture this requires almost no additional code.
And even though Javascript was never intended for 'real' programming it is the only language all browsers implement so it is what everyone is forced to use.
Two things. First off, a lot javascript's bad wrap comes from poor browser implementations. Support these days is quite good, and with a good toolkit, a lot of the remaining issues evaporate. Secondly, javascript is a view-centric programming language. No, it is not replacement for C or Java or Python, but is tremendously well-suited for web pages. It's fully object-oriented, has good regexp support, and hooks into almost anything you could possibly want in the browser window.
GUI and CLI programmers constantly complain about how primitive web applications are, but they're judging them by the wrong standards. Web applications are cross-platform, content-centric, instantly distributed, and rapidly developed. Yes, web applications suffer from legacy decisions that are not perfectly suited to today's world. But look at it from the flipside. If you wanted to make a GUI application that distributed and linked content as well as the web you'd have to refactor all the work that went into HTTP, HTML, and CSS to begin with, maybe it would be better, but you'd certainly create a slew of new issues for slashdotters to lambast you with.
Macromedia are probably gonna have to re-think things (in the new Adobe environment, of course) since they were convinced that Flash would be the vehicle of choice in developing what they call Rich Web Applications. They'll now have to sell it on the basis that you can get a hell of a lot of functionality out of very few lines of Flex code.
AJAX is not magic. All the same CSS/JavaScript/PNG cross-platform issues still exist. Good toolkits can abstract away a lot of the incompatibilities, but you still hit a wall awfully quick when you want to create innovative effects (and visual feedback is absolutely necessary with AJAX).
Some insignificant portion of Flash users may switch to AJAX, but by an large the market for AJAX is traditional HTML/CSS developers. Flash will be fine.
I gotta hand it to you for a brilliant troll. You pass this off as some kind of revelation about AJAX, when in fact this is the truth about every technology. There was always a better technology that never caught on (or never made it past the drawing board) for any given need. There are also always cynics who criticize anything popular by pointing out its flaws. Of course any alternate technology also has its flaws, but they aren't as easy to point out because no one uses it.
Seriously you build upon the failures DHTML, HTML, Javascript, XML, XMLHTTRequest and you form a system which requires at least a 1 ghz processor just run a very simple GUI.
First of all HTML, JavaScript and XML are not failures. They may not be ideal for whatever it is you think they should be doing, but as technologies they are incredibly successful. Secondly, AJAX requiring a 1 ghz processor is complete bullshit. I use google maps on my 400mhz G4 all the time, and I'll tell you that the operating system slowness itself is more of a source of frustration than javascript.
There is nothing special about this other than the incredible amount of sheer dependencies that exist. You cross browser incompatibilities you have inexact everything. This is not a good solution people.
Oh wait, except if you use a decent toolkit you can write AJAX apps that work in 99.99% of new computers running any operating system, right out of the box. Shit, I guess we better go write some Java Applets or DirectX because AJAX is so horrible.
This is also a good example of how bad Java and Sun has failed. If Sun would've opened up Java, let people distribute it, as well as from day 1 enabled easy RMI over HTTP we wouldn't be up to our necks in a horrible mixture of presentation logic and business logic.
Okay, that's just outta left field. There's a huge market in between monolithic business applications and pure content documents. Using something like Java to do lightweight web development might satisfy your pedantic idea of proper coding practices, but it wouldn't make anybody more productive. Not to mention assuming that a specific language would somehow make people better software engineers.
So here we are, requiring gargantuan browser which are brought to a halt with this AJAX technology when we had many other technologies which did so much better but failed for various other reasons.
Oh boohoo! You didn't perchance work on one of these superior technologies did you?
JUST BECAUSE AJAX NOW FINALLY WORKS DOESN'T MEAN IT IS A GOOD SOLUTION.
Well it makes it a good solution if you want to:
Get something done
Satisfy bosses/clients
Make something available on any computer with an Internet connection
Distribute it to the masses
Unfortunately it doesn't do anything to:
Satisfy idealistic software theorists who never actually created a popular website
For web developers the important thing is that we've passed the first inflection point: that is, companies can no longer afford to ignore Firefox.
But we're still a long way from the second inflection point: where can stop hacking to support IE (6, maybe 7). That's not happening for a long time, but if you look back 5 years, supporting IE 6 is really a piece of cake compared to IE 5, NS 4, etc.
Slashdot Mirror
No one at the time expected the changes in CISC processors. CISC processors still do have a "complex" instruction set in that they allow multiple forms of adddressing and varying length opcodes. However, internally these chips have become much more RISC-like. The current generation of Pentiums actually does an internal version of dynamic translation from CISC to RISC-micro-ops (which may be 1 or more per CISC instruction) and executes the micro-ops using a different instruction set internally. This internal RISC instruction set is used so central to the design that the L1 I-Cache is not actually a verbatim data cache of the CISC instructions but actually a trace cache of the translated RISC-like micro-ops.
It really just goes to show the error in the view that RISC and CISC are considered opposite approaches to processor design. The dichotomy was more pronounced in the early days of chip design, but the fact was that proponents of both approaches had good points, and so it was inevitable that modern chips combine the best of both philosophies.
I think the progress made on the PowerPC architecture is a testament to its viability. The fact that it's even managed to stay anywhere close to Intel/AMD is remarkable given the difference in R&D dollars (I'm just guessing). But the timing of the Intel switch makes perfect sense.
Consider the switch to the PowerPC in the 90s. It was a time when Microsoft was rapidly catching up to the Mac in terms of UI, and computers were generally underpowered for the common applications that people needed. Gambling on a more promising architecture could have paid off huge if the performance panned out. That never happened, and Apple was in pretty bad shape by the late 90s.
Now, however, computer performance has reached adequate levels for all the things the common people want... audio, video, web surfing, word processing. We can always use more power, but performance is not such a big deal as it used to be. Since they're not seeking a competitive advantage in performance, it makes sense of Apple to at least assure commodity performance by going with the dominant CPU architecture. Apple has contiunously struggled with supply problems from chip vendors for years, hopefully this will now be behind them, and they can focus on the creative part of their business which is where they've always excelled.
There were always several of these types in the low level classes I took when I got my BS. Why would you take computer science if you didn't actually want to learn it? There are much easier degrees to get, and almost anything would be more useful than csci if you don't plan on actually working with computers when you graduate. I mean seriously, what good could come of it?
I'm planning on buying the fastest G5 tower that Apple ships just before they shift completely to Intel. Although the G5 towers are mammoth, they are possibly (IMO) the most beautiful towers, inside and out, ever to be created. And in terms of performance I feel they will hold out for a very long time. Eventually I will probably retire Mac OS X in favor of some flavor of Linux on it, and run it as a server into the distant future. If I ever have any spare time I can tinker with the compiler and explore the Power architecture as a hobby.
I hope it's faster than the PPC version, because that's the main reason I'm still using Safari as my primary browser.
I have a feeling that the slowness has to do more with Aqua and Cocoa then with the processor.
Jobs' vision is important to Apple (by all evidence anyway), but the other half of the equation is talent. Dell can never get the talent Apple has because people who are that good don't want to work for Dell. Vision's not enough, it's all about the people and Apple's got that locked down. Dell probably has good business people, but that's something else entirely.
On the other hand you can have talent but no vision? Microsoft is the perfect example. Sure, Gates has a vision, but it's a vision for Microsoft software to control everything. He's more interested in integration than functionality. And at the end of the day it's just too geeky a vision to really catch on. You'll notice Apple does integration too, but it's not the driving theme, they put it where it makes sense. It pisses off some of the free software zealots, but the Apple customer base pretty much eats it up.
It's not so much charisma as the fact that Apple actually has interesting products. Who wants to hear some suit talk about the next wave of 100 slightly different models of commodity PC? Hell, even considering Apple seems to be the only computer manufacturer that's ever succeeded at make something that looks halfway decent, I don't think anyone would turn out for just hardware (ipods and intel chips aside). No, it's the software that keeps people coming back to Apple. Sure, all the hardcore fans and zealots care deeply about the new hardware specs, but only so they can decide the perfect time to renew their investment in Apple's platform.
I never bought a Mac after Win 95 came out because the software just wasn't that great anymore... no differentiation. But by the time Mac OS X hit, and Windows viruses started escalating, Apple was looking pretty attractive again and not for their underpowered hardware of the time either. Now it seems Apple has the kind of code base that they can really push feature-wise while Microsoft struggles to maintain Babel's XP and get something new out the door this year.
So 'security through obscurity' (i'm beginning to dislike that phrase) is fine when you're not 'the main target' and hence works to Linux's advantage but it's not OK, at the same level, for Windows to make it more difficult to find vulnerabilities in the first place by not revealing it's source code?
Maybe some open-source hippie zeolots don't think it's OK for Windows to keep its source code hidden, but don't ascribe that opinion to me. I have no problem with commercial software, I dislike some of Microsoft's predatory practices, but that's about the extent of it.
Not to mention that the majority of those vulnerabilities only affect a limited number of installations, sometimes so small as to make virus-style transmission difficult.
And of course there's the issue that for the average computer user who don't have any blackhats after them, Linux, BSD or OS X is going to a lot more secure in a practical sense just because they aren't the main target. I'm the first to admit that the most popular OS is going to get a lot more security scrutiny, but I don't really care which OS is more secure in theory. I only care that I'm not getting infected on a regular basis.
He's correct that certain tasks are easier in Ruby than in java, not to mention that the code is more readable. But he is missing in my opinion the most important part of Rails and that the ORM. Use scaffolding or don't use it. But if you bypass Active Record you're just making more work for yourself.
The article isn't about Rails... in fact it's not even about database-driven websites... or even web programming in general. It's just a comparison of the Ruby and Java languages in general. ORM is neither here nor there.
But here's an equally difficult question: what is conciousness? Can you define it?
It's an axiom of human experience. Maybe you could write a definition, but its still unverifiable from the outside. This is (currently) an intractable problem for science to tackle, but I see it casting a shadow over the field of AI. The baby elephant in the room.
And what makes you think the human brain is anything more than just algorithms?
The clue is consciousness. Why should an algorithmic machine be self-aware?
Unfortunately we can only observe consciousness with any certainty in our own selves. Anything else that looks conscious could just be powered by a complex algorithm.
Until someone actually discovers a mechanism for consciousness, it's ridiculous to assume one way or the other that our brains make us conscious. They provide cognition, but what makes us conscious may or may not be in there. Artificial intelligence is an interesting problem, but at some point the deeper issues will have to be tackled.
LOL, as if you could do thing the ruby way in Java.
I'm sorry, but you need to step up and defend your own points. 80% of your responses are "I never said that or that or that". Just because he did not literally quote you does not mean you did not imply all those things.
Quoting myself (for the third or fourth time now): "The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place.
Um, state is kept in sessions through the use of cookies. It has nothing to do with AJAX. Cookies are not perfect (they may be turned off), but they are a far cry from Byzantine.
You've answered your own question here.
So what you're trying to say is that server-based applications are garbage? That's not a foregone conclusion. If you need a smart client code a smart client, that doesn't mean there aren't benefits to doing things the other way.
Can you point out where I say that a transmission protocol makes things procedural?
I can't point out anywhere where you say how web applications are procedural, I was just trying to guess at your meaning. You just say "dumb xml data structures get passed to "stateless" objects (in other words, procedures)". Only where are the stateless objects? The backend code is all object-oriented and stateful, and the JavaScript code has the current view as its state. Where's the procedural code?
So you're saying that if all of us clever technology types put our heads together, no one will be able to devise a content scheme that has more capability than HTML while remaining compatible with HTTP?
Web applications are about the most expensive development effort the world has ever seen. So my answer, with respect to any reasonable alternative, is, "less than the cost of a Web application."
Of course someone can come up with a better idea. But that's 1% of the problem. Then you have to implement it on every platform and have it shipping with every computer.
Also where do you get the idea that web applications are so expensive? This is just your impression. The web's limitations may be its downfall when it comes to rich interfaces, but it's a strength when it comes to speedy development and deployment of simple apps.
On the other hand, I would like you to explain how asserting that something is badly designed constitutes pretention.
No your disdain due to an assertion that I'm following a herd is pretentious.
I also never said that Web applications are "a poor copy of traditional client applications.
Are you for real? Or am I just not allowed to summarize? The whole gist of your arguments was that web applications are a 'lobotimization' of older technologies. I just assumed client applications, but maybe you were referring to something else. Either way, your arguments by themselves are not cohesive, I have to extrapolate somewhat to argue at all.
And in the midst of your pragmatism, how hard do you work to blind yourself to the debilitating design flaws inherent in the technology that supplies you with a living?
There's no need to blind myself to any flaws. That those flaws are debihilitating is simply your unsubstantiated opinion. The web grew up organically and so things like AJAX are clearly not ideal, but on the other hand they get the job done. The fact is that most things people want to do on computers do on the Internet do not require complex interfaces. You can point out a million ways web applications could be better, but ultimately they work pretty well and they're pretty easy to develop. You've pointed out several flaws, but you haven't made a case for why they are so debihilitating. Either you are not comfortable with the web app paradigm and the associated tools, or you are only interested in things that the web isn't good at. My point is not that the web is good at everything, but rather its very good at a large number of things that a large number of people are interested in using.
You came out firing about what garbage web apps were because they were lobotomized versions of pre-existing technology. The web is designed as ligh
I made no assertion one way or the other about HTML and HTTP being suitable for particular purposes. Eulogize all you want about the wonders of the Web. It has nothing to do with my point.
.... The point is that real software gives you a choice.
Okay, well if it had nothing to do with your point then why even mention that HTTP is a 'lobotomized' form of something else?
Had you been able to hold my entire sentence in your little head at once, you would have seen that my point was about "object oriented" vs. "procedural," not "platform independent" vs. "platform dependent."
Nice ad hominem attack. That really proves your intelligence.
Um, in case you didn't read your own comment, you said that the web is procedural because dumb data is passed to 'stateless' objects. I explained that this is nonsense because there's nothing stateless about web applications. Yes, HTTP is stateless. Therefore web applications implement state at a higher level. You write the backend in Java, PHP, Ruby, Perl or any other language which supports any number of programming paradigms. You write your frontend in Javascript (if you need it) which is fully object-oriented. Where's the procedural code?
An intelligent reader would have discerned my point: they are *data structures*, not objects
As indeed I did. But what you didn't explain is why you need to pass objects to the client? Since everything is happening on the server, the only thing passed to the client is presentation. Maybe it's straight HTML, or maybe it's in XML format so that it can easily be coerced and inserted via Javascript. The idea that software is not 'real' unless it's a client-server architecture with code being transmitted across the network is extremely narrowminded.
My contention is precisely that Ajax attempts to simulate an object-oriented model by layering hideously complicated sets of stuff on top of a pre-existing structure that is not itself object oriented (or, more precisely, used to be object oriented until it was lobotomized).
Honestly, have you ever written a web application? If all your code is object-oriented, how is it that then magically it is lobotomized by a transmission protocol and suddenly procedural. There's plenty wrong with web development, but I'm afraid you're not getting it.
Yes, we all know that Javascript puts "view" code in the browser. Bully for you. And I apologize for not being sufficiently excited that my Web applications force me to take nearly the entire processing load on my server while the client's 3GHz machine sits idle waiting for a picture to paint. I will try to imitate your macho stoicism by meditating on the fact that my application code has the privilege of staying "in a controlled environment where it is secure." While I do this, I will also try to avoid any unpleasant questions about the security of my browser.
You're just highlighting the difference between regular GUI apps and web apps. They both have their advantages. I'm not saying traditional apps are dead. Your problem is you don't seem to think there is any value to keeping your code on your server, or distributing your application by means of a URL that anyone can type in to instantly access your application, or tight integration with tons of other applications on the same platform. Or maybe you just think there is a better way of achieving these benefits. Well call me when the better solution is out there. In the meantime I'll be making my living on the web.
Ajax, on the other hand, is capable of doing considerably less.
Yeah, and getting it out to the masses. What good is your ideal solution if no one uses it?
Yes, HTML is simpler than writing a gui. Perhaps you can explain how this relates to what I said.
Gladly. Most web applications are content related. Manipulating and presenting this content is core to the web app, so naturally using a platform that supports
Web apps are ALWAYS more difficult than the equivalent in client apps.
Only if you don't know how to use any frameworks. Writing a web app in raw PHP is like writing a client app drawing directly to the screen and capturing clicks and keystrokes. Of course GUI toolkits are going to be more mature having been a core area of commercial development over the past 25 years while the web has only been heavily prospected for 10.
Most development is not "for the internet", it is for in-house apps where you really DON'T NEED a web app.
Well as long as your company has one standard platform, and there are no outdates machines, and you have suitable infrastructure for automatic deployment and upgrades.
If you have pointy-haired bosses telling you to do everything based on buzzwords without even taking your opinion into account, then you should be looking for another job, not griping about technology trends.
reiteration of previous point cause yur out of good things to say
That's funny, because it seems I said a lot while you said nothing other than "I disagree".
So you think people like to download and install software, and you think that everything should be written in a verbose language with bloated APIs using cumbersome engineering techniques, and you think that content creation is an afterthought that can be accomplished equally well on any platform. That doesn't make you anything more than elitist.
I have a clue for you. Any moron can list 100 flaws with the web, but it takes a genius to come up with something better and get market penetration. In the meantime you can cry sour grapes about how the web is shit, but I'll be out there running my own business and developing applications that people actually use. When something better comes along, I'll be there because I don't have some idealogical ties to the 'one true way' of doing things.
Take a reliable, stateful transport protocol (TCP) and lobotomize it so that connection state gets thrown away. This is http. Take a platform-independent object technology (Java) and lobotomize it so that dumb xml data structures get passed to "stateless" objects (in other words, procedures), and all processing must happen at one end of the connection. This is Web applications. Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a browser. So: having gone from a world of functional, stateful, distributed applications engineered to a true software model, we are now back (despite all the self-congratulatory rhetoric about "objects") to procedural programming and dumb terminals (meaning Web browsers). In other words, 1970s technology with pictures. Any half-wit can see that this situation is broken. How do we fix it? The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place. Brilliant.
Oh please, not this tired argument again! What you software engineering nazis are forgetting is that HTTP and HTML were designed to transmit static content. In that regard the protocol and the markup language are a tremendous success. HTML and HTTP are incredibly scalable and easy to use, which means getting more done in far less time. Remember that most of the web is static information. In fact, web infrastructure was so dead simple and easy to work with that web applications have flourished. It's not like there weren't competing technologies, and if they were the panacaea you seem to think, no doubt they would have done better in the marketplace.
The real problem here is your inability to think outside your own comfort zone.
Take a platform-independent object technology (Java) and lobotomize it so that dumb xml data structures get passed to "stateless" objects (in other words, procedures), and all processing must happen at one end of the connection. This is Web applications.
This sentence is complete gibberish. Java is platform independent? Pretty close maybe, but you still have to test it for every target platform. There are advantages to having your application running on your server. Dumb XML data structures? No, we pass view data to the browser... maybe XML to be processed via JavaScript, maybe HTML/CSS for raw output, maybe an image, maybe a string. Why pass bloated objects and more code to be tested on every target platform when we can just pass the data we want the user to see? "stateless" objects? Just because HTTP is stateless doesn't mean web applications are. This is a separate issue from object-orientedness, which also has nothing to do with underlying protocols. all processing must happen at one end of the connection? View processing can be done client-side via Javascript which is very much optimized for that type of code. Meanwhile the bulk of your application code stays on the server in a controlled environment where it is secure. Don't underestimate the value of running your code in only one place.
You seem to think being able to pass Java objects to a remote computer would be some kind of revolution in web development, but it would introduce a whole slew of issues, and for what? Not much we can't do just as easily now (unless you only know Java).
Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a browser.
HTML + CSS is orders of magnitude simpler than presenting typical content through a GUI. Remember, the web is first and foremost about content. Name one other format that you can edit in a text editor and get anywhere near the power of HTML and CSS. Not PDF, Not Word Docs, Not Illustrator Files, Not Quark Files. Web browsers are not GUI technology. The fact that people can use it as a suitable replacement for GUI technology is a testament to
Let's face it though. Javascript is hack to make a web-based document viewing technology into an interactive one. It would be far better to upgrade HTTP and HTML to natively support the functionality that all interactive web-apps need then to download the same boiler-plate javascript code trillions of times forever and ever.
Better from a technological standpoint, yes, but logistically impossible. What we can hope for is incremental improvement. Better CSS and Javascript support, Xforms, SVG. Its nice to think that something could come and sweep away all the web's problems, replacing it with perfect new tech, but I'm afraid HTTP/HTML/CSS/Javascript is far too ingrained for that.
UNLESS -- you write your own accessibility aids and write your own UI framework that compiles into both an AJAX version and a web accessible version.
It doesn't need to be that complicated. You can write standard forms that are simply enhanced with AJAX if it is available. With proper server side architecture this requires almost no additional code.
And even though Javascript was never intended for 'real' programming it is the only language all browsers implement so it is what everyone is forced to use.
Two things. First off, a lot javascript's bad wrap comes from poor browser implementations. Support these days is quite good, and with a good toolkit, a lot of the remaining issues evaporate. Secondly, javascript is a view-centric programming language. No, it is not replacement for C or Java or Python, but is tremendously well-suited for web pages. It's fully object-oriented, has good regexp support, and hooks into almost anything you could possibly want in the browser window.
GUI and CLI programmers constantly complain about how primitive web applications are, but they're judging them by the wrong standards. Web applications are cross-platform, content-centric, instantly distributed, and rapidly developed. Yes, web applications suffer from legacy decisions that are not perfectly suited to today's world. But look at it from the flipside. If you wanted to make a GUI application that distributed and linked content as well as the web you'd have to refactor all the work that went into HTTP, HTML, and CSS to begin with, maybe it would be better, but you'd certainly create a slew of new issues for slashdotters to lambast you with.
Macromedia are probably gonna have to re-think things (in the new Adobe environment, of course) since they were convinced that Flash would be the vehicle of choice in developing what they call Rich Web Applications. They'll now have to sell it on the basis that you can get a hell of a lot of functionality out of very few lines of Flex code.
AJAX is not magic. All the same CSS/JavaScript/PNG cross-platform issues still exist. Good toolkits can abstract away a lot of the incompatibilities, but you still hit a wall awfully quick when you want to create innovative effects (and visual feedback is absolutely necessary with AJAX).
Some insignificant portion of Flash users may switch to AJAX, but by an large the market for AJAX is traditional HTML/CSS developers. Flash will be fine.
First of all HTML, JavaScript and XML are not failures. They may not be ideal for whatever it is you think they should be doing, but as technologies they are incredibly successful. Secondly, AJAX requiring a 1 ghz processor is complete bullshit. I use google maps on my 400mhz G4 all the time, and I'll tell you that the operating system slowness itself is more of a source of frustration than javascript.
Oh wait, except if you use a decent toolkit you can write AJAX apps that work in 99.99% of new computers running any operating system, right out of the box. Shit, I guess we better go write some Java Applets or DirectX because AJAX is so horrible.
Okay, that's just outta left field. There's a huge market in between monolithic business applications and pure content documents. Using something like Java to do lightweight web development might satisfy your pedantic idea of proper coding practices, but it wouldn't make anybody more productive. Not to mention assuming that a specific language would somehow make people better software engineers.
Oh boohoo! You didn't perchance work on one of these superior technologies did you?
Well it makes it a good solution if you want to:
Unfortunately it doesn't do anything to:
For web developers the important thing is that we've passed the first inflection point: that is, companies can no longer afford to ignore Firefox.
But we're still a long way from the second inflection point: where can stop hacking to support IE (6, maybe 7). That's not happening for a long time, but if you look back 5 years, supporting IE 6 is really a piece of cake compared to IE 5, NS 4, etc.
Of course they need donations:
Donate Today!