190 karma · joined May 12, 2008
To the point that levels of complexity can be hidden by an external production pyramid:
Encapsulating complexity through a 'pyramid' of vendors is the evolutionary norm for all complicated systems. "I don't want to harvest vegetables, boil down some bone to make chicken stock, collect herbs & spices, throw it all in a pot and simmer for 4 hours - I'll just go to the store and buy some soup instead!"
This has always been the norm in software as well. From bits to file systems to grep and on and on, software is always built on building blocks that abstract complexities. We're starting to see this with software at levels that ease the burden of maintaining entire systems or networks(Amazon & Google,etc).
However, these abstractions away from complexities do not ease the burden of creating new software, just as lacquer and wood providers do not make it any simpler to create a warehouse that produces pencils. You can have all the supplies in the world but won't succeed until you know how to put them together, and in general putting them together in an efficient, useful manner is the hardest problem. There's no barrier to entry when it comes to providing a new web app - all the technology exists already, and is fairly well maitained! The barrier to entry is in combining the technology to create something new that is needed. Which brings me to my second point -
Regarding the articles conclusion: You had me till the 'out of the crisis'. If I follow correctly, the argument is that we should charge a fee for utilization of the utility that is software, not for the bits themselves. What this means is that I'm going to pay a cent every time I use my web browser. But this also means that my web browser creators, and, well, they're gonna pay .5 cents each time the browser is used for whoever provided the C++ libraries(or whatever it's built in). Who in turn is going to pay .2 cents for each use of....and so on. If the plan is to create a system that facilitates a broadening or evolution of the "roots" or building blocks of software, this will never work.
Here's why I'm not going to pay for the roots - we're already at a point in software where the 'roots' I really need are built, open-sourced and free. Or close to free. And for the components that aren't readily available - I simply refuse not to build them.
It's not that there's no incentive to provide more roots, it's that I don't want to pay for their use each time my software runs! Screw that. I'll spend an extra week implementing it myself, bugs be damned, and I'll collect all the revenue!
At least, that's the way the thinking usually goes.
Web apps are dominated by Flash, and to a lesser extent, Silverlight, for a reason. The hype around these new frameworks just isn't justified. If the title was more to the effect of 'new frameworks are a good step forward in the javascript-based web-app approach' then I'd happily concede. The title says completely changing the web app industry!! The point of the article seems, to me, to be about how these new frameworks allow for simple web-app (aka RIA, more or less) development with more support from big players. My point is that this isn't as much of a game-changer as some people seem to think.
1) Video.
Video on the web is king. Streaming video. Live video. Video comments. Video video video. None of these javascript-based solutions have an inherent solution for incorporating video into your web app, and therefore will always need to be augmented with a video technology for web-apps that require video.
2) Cross-browser compatibility
We're getting closer with javascript compatibility, but not there yet. Yes, many of these frameworks claim to hide the issue, but what about developers that want to develop components for the framework? A virtual machine that is consistent across all browsers (well, supported browsers) makes development much cleaner.
3) Flash IS Open-source.
Flash may not be truly 'open-source', but rarely is there a mention that Adobe has released the specifications for the specifications for both the .swf file format and the actionscript virtual machine, and are accepting feedback on both.
4) Rapid Development Environments
I admit to knowing little about how people are developing these apps in these languages, but doubt that the IDE's contain the feature-rich capabilities required for complex RIAs - things like code hinting across libraries, a walk-through debugger, visual drag & drop component interface, etc etc.
---
I am in no way suggesting that these new technologies are not exciting or an improvement - I just think the hype around them (http://www.roughlydrafted.com/2008/06/14/cocoa-for-windows-f...) is somewhat unsubstantiated. They still have a long way to go. But it's great to see some new competition creeping in on the big guys - good for the consumer!
Edit: Quote from their site - "An eWeek Labs Analyst's Choice award winner, this open-source product is one of the best solutions period - for company portals and intranets" - eWeek, April 2006 issue
The upvotes that people give this "joke" (it’s not really meant to be funny at all), regardless of how often they’ve heard it before, probably means that they agree with the sentiment, and as members of the same community have the option to make that vote as they see fit. Hopefully they don’t upmod because they find the post humorous. It’s meant to be commentary on the state of the community, and your negative responses only seem to validate the point further.
Interesting how the net’s anonymity results in much sharper criticism than you find the real world. For example, you would never call a joke stupid if someone you had just met told it, regardless of how many times you’d heard it before. Something to consider, especially given that we’re all here to focus on the same goal: learning from one another, gaining valuable insight, growing as a community. Not disrespecting one another.
I may not have been a registered user for very long, but I have read HN for quite a long time before that, and am just as immersed and interested in the startup community as any one of you. I agree that, if anyone cares about karma, a formula that gives karma based upon length of time they’ve been a registered member of the community is a cool idea.. I’m all for informative, excellent content, but I’m also not against a bit of humor, commentary, or just plain fun. What good is being entrepreneurial if you can’t have fun?
Now stop upvoting this post!
I suppose I should revise my question a bit. What I really meant to understand was what was it is about OO that makes it a focus of conversation as a hard technique, when compared to all these other programming techniques you hear little no arguments about.
For all its usefulness, you don't see too many blog posts vehemently defending or refuting recursion. It's simply another way to write some code. You don't hear joel or jeff going on about whether or not data structures are useful or on the whole a degradation to programming communities. These are all just different techniques used to accomplish the same thing; in some cases, those techniques make achieving a goal easier or the code more elegant.
I do hear these things about OO programming, and yet, OO is just another one of these techniques! So, my question now becomes - not what is so hard about OO - but instead - what is so arguable about OO, that people feel the need to call it hard, useless, or revolutionary, while leaving the other techniques like poor recursion out in the cold?
Am I one of them?
Are you?
How are we to know with no example of HOW OO is hard? What exactly is so hard about it? Class Apple extends Fruit. apple = new Apple(). apple.eat(). Makes sense to me. How are people using it wrong? Is the real issue that people don't understand when to use it?
Here's a similar article:
Playing poker is hard. A lot of people really don't understand how to play poker. People that play poker should stop, and start playing go fish. They should leave poker to the professionals that understand poker. All poker books should now become go fish books.
I'd imagine a few open-source php classes and one or two standard DB tables would do the trick, and maybe a simple interface for managing users and emails.
Adobe's hope is that opening a platform with 98% penetration will further increase platform acceptance as the standard for rich media on the web.
Think about it from a developers POV - let's say that you're making a choice between two rich media platforms on the web - both proprietary, closed systems that require proprietary plugins and code built on proprietary languages. Tough choice, eh? Maybe you pick the one with a language you're more familiar with, or one thats been really hyped recently.
Now consider a slightly different scenario: What if you had to choose between an open, standardized platform built on an open language with open-source tools that can create applications that run on the web in any browser or your mac, windows or linux desktop. How does that compare with the proprietary choice?
Adobe has consistently moved towards an open solution both for its development tools and its platform, no doubt in response to competitive threats. Microsoft is trying to inch that way as well but seems a step behind.
This could be a hosted solution or one that you install on your own servers (preferably self-installed and easily modifiable) - either way you'd set it up, code your own visual interface for logging in, signing up, etc, but use the user management API on the back end for storing user data, storing new user data, etc. It would also utilize smart encryption techniques, allow for mass emails, etc.
I understand that these issues are mostly straightforward, but it seems crazy that every new web app has to re-invent the wheel for user management!?