Parent sounds a little like they were in over their head. Was the problem NHibernate (the implementation) or the ORM (the concept)?
As someone who's written an ORM that handled a medium swatch of the features for the product space (metadata, state, caching, lazy-loading, transactions mgmt, SQL generation, etc). I can say that done well, ORMs greatly simplify database-backed systems for any system size over ~10 tables, or systems with less-than-solid feature requirements.
Simply put, there is a finite set of operations one can do against an RDBMS, and if you can continue doing all of them, then the tool shouldn't matter. Hand-scribing up your own SQL and linking it to code any way you like is fine, if you like maintaining a huge pile of boring and building estimates by the number of impacted queries from a feature request.
You have to know the tool well - it doesn't make data flow management easier, it just moves the switches and dials to a single layer. For the vast majority of cases, ORMs are amazingly helpful.
NHibernate and it's similars serve a legit purpose, and are used successfully throughout the dev world.
Like Inversion Of Control, Test Driven Design, Policy Injection, Design By Contract and other modern terms for not-so-modern concepts, Object-Relational Mapping is just another tool. And like all tools - there's a world of detail under a seemingly simple concept.
There's not a lot of "sections" to smart. If someone don't believe the US landed on the moon these days, the onus is on them to prove it. Otherwise, they're pretty dumb - like earth-is-flat dumb.
Remember, they are all walled gardens. Nobody is touting the new features of their phone by stating "it works with everyone else's phone too!"
I agree with you though: MS is particularly heinous, going back to the days of Netscape's demise, the Office Open XML disaster, IE's compatibility & security nightmares, plus the usual MeToo junk of J#, Moviemaker, Zune, etc.
Actually, if you look at set theory and declarative languages, SQL is coming to more traditionally procedural environments. (MS's LINQ, for example.) It's an amazing language, good at what it's supposed to do. You could nearly complain the same about XML transforms as SQL. They just collect & format data. It's the programmers who make it complex.
Unavoidable bottlenecks in systems come from storage, searches and transforms. If you want to remove the DB from the equation, what layer of your system should be performing these things?
BTW: The math in set theory hasn't changed since the 1960's, it doesn't "get old" and need replacing. And you should learn to spell COBOL, your rants will appear more credible.
Your opinions are far, far from current reality. The vast majority of Windows applications and services are built in managed code. Since it's easy to hit any unmanaged API, there's no reason to start in C++. The framework assistance.NET delivers, along with a huge, vibrant market of 3rd party extensions) allow one to write strong applications very quickly and easily.
Many system applications in Win7 are in managed code, and more continue to be. The speed issue has been addressed many times over - there's very little hit in the managed environment, comparing apples to apples.
I agree that your numbers are probably closer to reality, but I think the minimum should still stand at 1, or even 0. The survival rates of feral cats are probably good, but they're not perfect. Also, the breeding availability of feral cats is more limited than you assume due to competition for territory, mates and resources. Also, parasites and spoiled food are two large contributors to weakened feral animals and inability to reproduce.
Assumptions about context are a huge contributor to both runtime errors and language understanding. Some of the goals of modern languages include eliminating implicit context from a language, while simultaneously removing extraneous syntax. Ask anyone new to C languages to decipher some pointer manipulation code and you'll see why we've moved on (Example: x=(c==*f)?1:0; ). Keystrokes are cheaper than debugging time, we now know.
You could use '=' for both assignment and comparison, as assignment is a 'function that returns the assigned value'. You can still do this in C-based languages, unless the compiler is told to disallow it. Those compilers can deduce comparison context and check for assignments, warning you.
Remember, to overload a symbol is to introduce context. But to just introduce new single-character symbols makes typing difficult (anyone still have APL overlay?)
Alternatives are to have very localized context, something we still problems with (f = y*f++).
Or making symbols from multiple keystrokes, and then you must decide which semantic meaning gets which characters. So '==' is used for equality because it's quick and easy, while '=' is left for assignment. Assignment was assumed more prevalent, so it got the single keystroke.
That's interesting, because I've been talking this idea up forever. Taking over full support of the Mono platform would ingrain.NET development into so many platforms that MS would have a massive link between developer culture, operational congruency, good will, and several other perceptions that I cannot imagine a good reason for keeping.NET a MS-only platform. Just bad reasons, like manager stubbornness, ROI-only-based accounting, and hubris.
Ironically, I remember when.NET was first released, competing with Java for a run-on-everything multi-language framework. It's now a painful reminder that MS cannot seem to shed their chains of pride and interact with the rest of the larger computing market.
For example, even their web proposal (IE/Silverlight) cannot compete with the likes of Chrome, where Google doesn't care what platform it runs on, just that they're a presence in the space. IE on anything but Windows? I doubt it, and this means it'll simply be a corporate layer or noob-home-user default, like today.
Instead of integrating and offering ideas to available platforms, MS buys/builds their own space and competes in it, then wonders why it's so damn expensive to start such ideas (Xbox, for example).
Well, first of all, we've seen part of their strategy: Avoid the "pad" nomenclature entirely - instead it will be a "slate" platform. The marketing department will slick this into oblivion, trying to own every part of the market space, appearing snooty and over-promising from the start. The height of this was MS's introduction of the word "squirt" to transfer data - probably the most condescending marketing term ever, followed closely by the Kin marketing, Clippy, etc.
2nd, MS will be behind on this platform not only due to the late arrival of product, but the environment will be new. Right now, iPad development is dovetailing from the iPhone framework, with Apple showing the way with very strong operational guidelines to developers for UI, power, accessories, form factor, etc. MS has never issued anything of this level. I'm guessing a crippled mixture of.NET/Silverlight, SQLServer and some office bloatware will be on board. This can look/perform all the same pretty, but it again introduces a mashup that developers need to learn. They'll also probably come out with a noob programming environment to kick start the suck, ala Visual Basic - just to attract applications.
3rd, these devices are a moving platform and MS is just leaving the gate while the real race is in a new venue. You can bet Apple, Amazon, RIM, Palm & Google will be integrating hardware & optimizations that leave them rushing for a Windows 8 platform now. I can only imagine where we're going, but real-time voice translation, interesting interface designs (for example, Pranav Mistry's "Sixth Sense" work), and continued amazing collaborative/connectivity ideas. MS wishes it could hire enough PhD's to dream this up, but it doesn't happen like that. It happens by thousands of folks trying short applications out with their friends and seeing what sticks, not by spending years on a huge project that, while amazing, doesn't have the legs to go anywhere (Exhibit A: MS Research).
"Slate" wording is part of step 2. Watch for other strange marketo language soon. Anyone still interested in a Squirt(TM)?
Step 3 is their own lameness when their "slate" only connects easily to Bing, XBox, MS Live and just their cloud.
You can bet by the time MS gets a good "slate" released that market leaders will be moving from haptics to eyetracking/brainwave/biofeedback interfaces.
This may be true in term of single-system size, but for sheer market penetration & visibility, iPhone/Android & apps are way beyond what people do with Desktops now.
Business applications abound for.NET, but this is not as visible at home. O'Reilly is watching where the new development for home users is going: smart devices
It'll take ten years, but eventually the smart device platform will make enough inroads to replace some of the business market. Ask anyone with a Blackberry or laptop. This article is a clone of similar from the early 90's where both of those devices were derided as too slow/expensive/cumbersome for business use.
C'mon dude. Bizspark is mostly a networking concept. Not a cool-application platform.
This article isn't about VC-level startups, it's about students building the NextSmallThing in their dorm room. For the price of a bank of old servers, someone can build a web app and get a cool company started. MS is never going to deliver the performance/cost ratios of an old fashioned LAMP stack. It's not a business model that competes that way. Plus, that stack is just a gateway anymore - the real fun is in social mesh.
MS is also not going to work on the hardware that kids already own (smartphones/pad forms). They are building mashups. MS doesn't even play in most of these markets. For example:
Mobile 7 + Bing + MSDN/.NET = solitary nerd writing a blog on Codeplex that 50 clones know about. Probably hired to code for an existing business's IT dept.
iPhone + Geotagging Google Earth + Fart noise = fun and popular iPhone app that 20,000 people play at the BBQ this weekend. Makes 2 guys 10 grand over a month, then they move on. They build smartphone apps for any number of startups focused on gaming/productivity/social media.
The smart device is the new web. Guess who's late to the game because they built their own stadium and charged at the door?
10. New language specification / programming paradigm
HTML/JS and several frameworks in, one must wade through several stages of Flash development to gain proficiency in yet another toolkit for delivering content.
9. Text
Your text and tags are hidden, perhaps exposed through clunky mechanisms. Search exposure and SEO are a nightmare. Forget about clipboard compatibility.
8. Version incompatibility
It may not happen as often due to Flash's relative stability, but plugin upgrades will still happen. So, consider yourself coding around several versions if you're using anything new.
7. Perceived vacuous content
More often than not, the New Shiny of vector graphics overwhelms developers and they deliver more gee-whiz than any real content. Transitions, animations, endless gradients all polish up something that might be more easily just text.
6. Ever-shifting browser performance levels
These days browsers are increasing their performance, with today's beta version rivaling complete OS responsiveness of just 10 years ago. Flash may have a native code advantage, but with tighter lock-in of graphics hardware to a browser's rendering engine just around the corner, the advantage of native code running as a 3rd party plug-in will not be as necessary except for the most intensive games.
5. Security
As browsers & their tabs run in more sandboxed areas with each round of security lockdown, Flash is a gaping hole of unknown security. Adobe has not always be forthcoming of closing their known issues. JS holes are well-studied, open to all for review, and usually fixed in short order.
4. Agility
Adobe's release schedule doesn't converge with any particular browser's and the support of a new browser feature may require still more waiting if you're to using it from within Flash. By using a framework - or several - one would expect patches/extensions to arrive and mature more quickly than a single vendor.
3. Openness
When using an open JS framework, you can continue to dive until the issue you are researching is isolated and in plain sight. With a native plug-in, you may get to the undesired behavior of an API and be stuck with working around it or skipping it's use altogether.
2. Market acceptance
Like it or not Apple is refusing to run Flash. Other emerging platforms may or may not jump on this bandwagon. Proven over and over, sticking to the core platform of a delivered browser and it's open standards is the best bet for long term viability for a site.
1. One not Two
Every site is going to be using JS anyway - do you really need to carry data between the two layers? Just stick within the lower-walls of the garden you're already in rather than constantly embed and marshal.
I'd mod up but today I'm out of dots. Anyway, your point is key, I believe: MSFT cannot ignore online services at any cost - even a loss. They will continue to throw things at the wall, hoping for it to stick in a large-market way. Until then, they fund their smaller players as a set that adds up to a moderate player overall.
I think what is more expected of something "cross platform" these days is being able to install the sandbox on any machine - without encumbrances..NET's CLR cannot install on platforms not directly or indirectly supported by MS itself.
Silverlight, SQLServer, WebApp are all examples of embedding, not cross platform. The platform is the hosting stack that mitigates hardware resource contention.
I think of cross-platform as in: Palm, IPhone, Android, OSX, Linux, AS/400. Mono is one path to these, but de Icaza knows the devil in the details: less-than-full.NET framework has been made available without open licensing to his project.
Some of the strongest minds in computer science have built out.NET, and continue to do so. There are some practicality gaps, but today the majority of the corporate world is powered by.NET devs, for better or worse.
However, this many years into the platform, it's starting to show it's age. From.NET 1.0 applications, laden with crude pinvokes to Win32 API's, GDI+ silliness, messy ADO.NET integration, through 2.0, 3.5, 4.0, the "Enterprise" helper classes, the "Foundation Extensions", the integration of pseudo-SQL declarative syntax with LINQ, Entity Relation classes, Unity, security, contracts, plus all of the layers of ASP.NET tools.... don't VS's forget code analysis, test suites, code coverage, profiling, generated documentation... there are many more but you get the point......all this is shaping up to be a very MS-centric view of the.NET universe. Which is a mistake, De Icaza seems to imply. I wholeheartedly agree. While the computing world abandons PCs for most tasks (gaming, editing information aside) and info consumption is done via smaller devices, on a variety of hardware & OS's, MS has bound.NET to their OS deployments - and there will be many other OS's talking in that space.
This is Microsoft's biggest gamble with.NET: That as the OS lives or dies, so does this platform. Really, it could be bigger than Windows. If MS shipping a full (even licensed) 4.0+ framework for use on Linux & Apple, it would inject a massive growth spurt in both those platforms but a huge and lasting foothold on the MS-based app development.
- The one where you rented a Caterpillar tractor from the dude down the interstate to level your pad? - The one that used PVC piping from Dow Corning to build your well and leach field? - The Monsanto engineered seeds that grow the veggies to supply almost 60% of all calories in the entire US market, including the ethanol? - The one that used a hugely complex system of energy generation, transmission, regulation to form anything made of glass, metal, plastic, paper, etc. - The systems of cartography, tax districts, property ownership that map, photograph and check on your little patch of homemade campground?
Dude, there's been tons of reliance on an external system of commerce, energy, logistics, information that "off the grid" has been a misnomer for decades in the US. A chainsaw and a generator does not make anyone off the grid.
What you're mistaking is that the concept of "pay as you use" for medical care is gone - rightly so, because it;'s been gone a long time. When you are pried out of your crashed pickup truck and driven to the hospital, patched up and sent home, the $50k is took to get you through that isn't just wrapped into taxes, it's now a separate line item. Oh, unless you were holding onto that 50k for just such an occasion. In a cabin. Off the grid.
Medical emergency situations occur many times a week. Would you rather we just moved folks that couldn't pay to the side and left them there? We're paying for medical system that anyway. Now you can help us, those that understand and accept an interdependent world, while still play-acting "off the grid".
Porsche 918 Spyder gets 58mpg and this is a freaken scream machine. Porsche
If they were all made of paper-light materials with low-drag-cof. surfaces and one-weather tires, and had specialized components - all with a budget 3x the cost of a normal auto manufacturer, then HEY! You could be right!
The initial momentum vertically is the highest energy requirement, which severely limits payload as energy storage becomes a huge issue. Large fan blades are probably not possible as well.
Perhaps a spring or hydraulic based jump-start system (undercarriage paddles?) could enable a vehicle to begin large hops while engaging a ducted fan system that doesn't give full lift, but can slow a landing. For full flight, I suspect a folded wing system of some kind will be necessary.
Slashdot Mirror
Parent sounds a little like they were in over their head. Was the problem NHibernate (the implementation) or the ORM (the concept)?
As someone who's written an ORM that handled a medium swatch of the features for the product space (metadata, state, caching, lazy-loading, transactions mgmt, SQL generation, etc). I can say that done well, ORMs greatly simplify database-backed systems for any system size over ~10 tables, or systems with less-than-solid feature requirements.
Simply put, there is a finite set of operations one can do against an RDBMS, and if you can continue doing all of them, then the tool shouldn't matter. Hand-scribing up your own SQL and linking it to code any way you like is fine, if you like maintaining a huge pile of boring and building estimates by the number of impacted queries from a feature request.
You have to know the tool well - it doesn't make data flow management easier, it just moves the switches and dials to a single layer. For the vast majority of cases, ORMs are amazingly helpful.
NHibernate and it's similars serve a legit purpose, and are used successfully throughout the dev world.
Like Inversion Of Control, Test Driven Design, Policy Injection, Design By Contract and other modern terms for not-so-modern concepts, Object-Relational Mapping is just another tool. And like all tools - there's a world of detail under a seemingly simple concept.
And is anyone asking companies to pay for the costs/injuries from reclaiming materials from the waste stream?
There's not a lot of "sections" to smart. If someone don't believe the US landed on the moon these days, the onus is on them to prove it. Otherwise, they're pretty dumb - like earth-is-flat dumb.
Remember, they are all walled gardens. Nobody is touting the new features of their phone by stating "it works with everyone else's phone too!"
I agree with you though:
MS is particularly heinous, going back to the days of Netscape's demise, the Office Open XML disaster, IE's compatibility & security nightmares, plus the usual MeToo junk of J#, Moviemaker, Zune, etc.
Actually, if you look at set theory and declarative languages, SQL is coming to more traditionally procedural environments. (MS's LINQ, for example.) It's an amazing language, good at what it's supposed to do. You could nearly complain the same about XML transforms as SQL. They just collect & format data. It's the programmers who make it complex.
Unavoidable bottlenecks in systems come from storage, searches and transforms. If you want to remove the DB from the equation, what layer of your system should be performing these things?
BTW: The math in set theory hasn't changed since the 1960's, it doesn't "get old" and need replacing. And you should learn to spell COBOL, your rants will appear more credible.
Where's that "flying car" huckster Moller when you want him?
Before you imagine driving any dual-purpose design through a typical urban area, take a look at what the typical traffic would be.
Seems a little far-fetch to get any kind of flying car design through such an area.
Your opinions are far, far from current reality. The vast majority of Windows applications and services are built in managed code. Since it's easy to hit any unmanaged API, there's no reason to start in C++. The framework assistance .NET delivers, along with a huge, vibrant market of 3rd party extensions) allow one to write strong applications very quickly and easily.
Many system applications in Win7 are in managed code, and more continue to be. The speed issue has been addressed many times over - there's very little hit in the managed environment, comparing apples to apples.
I agree that your numbers are probably closer to reality, but I think the minimum should still stand at 1, or even 0. The survival rates of feral cats are probably good, but they're not perfect. Also, the breeding availability of feral cats is more limited than you assume due to competition for territory, mates and resources. Also, parasites and spoiled food are two large contributors to weakened feral animals and inability to reproduce.
Age to maturity: 6 to 10 months
Litters per year: 0 to 3
Litter size: 1 to 8
so, using a changing multipler for newborns of
year1= 0 to 12 offspring
year2,3,4,5 = 0 to 24 offspring
i get values around
end year1: 1 to 25 cats
end year2: 1 to 300 cats
end year3: 1 to 3900 cats
end year4: 1 to 54k cats
end year5: 1 to 835k cats
So it pretty much stands as a useless range
Assumptions about context are a huge contributor to both runtime errors and language understanding. Some of the goals of modern languages include eliminating implicit context from a language, while simultaneously removing extraneous syntax. Ask anyone new to C languages to decipher some pointer manipulation code and you'll see why we've moved on (Example: x=(c==*f)?1:0; ). Keystrokes are cheaper than debugging time, we now know.
You could use '=' for both assignment and comparison, as assignment is a 'function that returns the assigned value'. You can still do this in C-based languages, unless the compiler is told to disallow it. Those compilers can deduce comparison context and check for assignments, warning you.
Remember, to overload a symbol is to introduce context. But to just introduce new single-character symbols makes typing difficult (anyone still have APL overlay?)
Alternatives are to have very localized context, something we still problems with (f = y*f++).
Or making symbols from multiple keystrokes, and then you must decide which semantic meaning gets which characters. So '==' is used for equality because it's quick and easy, while '=' is left for assignment. Assignment was assumed more prevalent, so it got the single keystroke.
That's interesting, because I've been talking this idea up forever. Taking over full support of the Mono platform would ingrain .NET development into so many platforms that MS would have a massive link between developer culture, operational congruency, good will, and several other perceptions that I cannot imagine a good reason for keeping .NET a MS-only platform. Just bad reasons, like manager stubbornness, ROI-only-based accounting, and hubris.
Ironically, I remember when .NET was first released, competing with Java for a run-on-everything multi-language framework. It's now a painful reminder that MS cannot seem to shed their chains of pride and interact with the rest of the larger computing market.
For example, even their web proposal (IE/Silverlight) cannot compete with the likes of Chrome, where Google doesn't care what platform it runs on, just that they're a presence in the space. IE on anything but Windows? I doubt it, and this means it'll simply be a corporate layer or noob-home-user default, like today.
Instead of integrating and offering ideas to available platforms, MS buys/builds their own space and competes in it, then wonders why it's so damn expensive to start such ideas (Xbox, for example).
Well, first of all, we've seen part of their strategy: Avoid the "pad" nomenclature entirely - instead it will be a "slate" platform. The marketing department will slick this into oblivion, trying to own every part of the market space, appearing snooty and over-promising from the start. The height of this was MS's introduction of the word "squirt" to transfer data - probably the most condescending marketing term ever, followed closely by the Kin marketing, Clippy, etc.
2nd, MS will be behind on this platform not only due to the late arrival of product, but the environment will be new. Right now, iPad development is dovetailing from the iPhone framework, with Apple showing the way with very strong operational guidelines to developers for UI, power, accessories, form factor, etc. MS has never issued anything of this level. I'm guessing a crippled mixture of .NET/Silverlight, SQLServer and some office bloatware will be on board. This can look/perform all the same pretty, but it again introduces a mashup that developers need to learn. They'll also probably come out with a noob programming environment to kick start the suck, ala Visual Basic - just to attract applications.
3rd, these devices are a moving platform and MS is just leaving the gate while the real race is in a new venue. You can bet Apple, Amazon, RIM, Palm & Google will be integrating hardware & optimizations that leave them rushing for a Windows 8 platform now. I can only imagine where we're going, but real-time voice translation, interesting interface designs (for example, Pranav Mistry's "Sixth Sense" work), and continued amazing collaborative/connectivity ideas. MS wishes it could hire enough PhD's to dream this up, but it doesn't happen like that. It happens by thousands of folks trying short applications out with their friends and seeing what sticks, not by spending years on a huge project that, while amazing, doesn't have the legs to go anywhere (Exhibit A: MS Research).
Embrace, Extend, Extinguish.
Announcement is step 1
"Slate" wording is part of step 2. Watch for other strange marketo language soon. Anyone still interested in a Squirt(TM)?
Step 3 is their own lameness when their "slate" only connects easily to Bing, XBox, MS Live and just their cloud.
You can bet by the time MS gets a good "slate" released that market leaders will be moving from haptics to eyetracking/brainwave/biofeedback interfaces.
This may be true in term of single-system size, but for sheer market penetration & visibility, iPhone/Android & apps are way beyond what people do with Desktops now.
Business applications abound for .NET, but this is not as visible at home. O'Reilly is watching where the new development for home users is going: smart devices
It'll take ten years, but eventually the smart device platform will make enough inroads to replace some of the business market. Ask anyone with a Blackberry or laptop. This article is a clone of similar from the early 90's where both of those devices were derided as too slow/expensive/cumbersome for business use.
C'mon dude. Bizspark is mostly a networking concept. Not a cool-application platform.
This article isn't about VC-level startups, it's about students building the NextSmallThing in their dorm room. For the price of a bank of old servers, someone can build a web app and get a cool company started. MS is never going to deliver the performance/cost ratios of an old fashioned LAMP stack. It's not a business model that competes that way. Plus, that stack is just a gateway anymore - the real fun is in social mesh.
MS is also not going to work on the hardware that kids already own (smartphones/pad forms). They are building mashups. MS doesn't even play in most of these markets. For example:
Mobile 7 + Bing + MSDN/.NET = solitary nerd writing a blog on Codeplex that 50 clones know about. Probably hired to code for an existing business's IT dept.
iPhone + Geotagging Google Earth + Fart noise = fun and popular iPhone app that 20,000 people play at the BBQ this weekend. Makes 2 guys 10 grand over a month, then they move on. They build smartphone apps for any number of startups focused on gaming/productivity/social media.
The smart device is the new web. Guess who's late to the game because they built their own stadium and charged at the door?
right on, sir! exactly what i was going to say.
10. New language specification / programming paradigm
HTML/JS and several frameworks in, one must wade through several stages of Flash development to gain proficiency in yet another toolkit for delivering content.
9. Text
Your text and tags are hidden, perhaps exposed through clunky mechanisms. Search exposure and SEO are a nightmare. Forget about clipboard compatibility.
8. Version incompatibility
It may not happen as often due to Flash's relative stability, but plugin upgrades will still happen. So, consider yourself coding around several versions if you're using anything new.
7. Perceived vacuous content
More often than not, the New Shiny of vector graphics overwhelms developers and they deliver more gee-whiz than any real content. Transitions, animations, endless gradients all polish up something that might be more easily just text.
6. Ever-shifting browser performance levels
These days browsers are increasing their performance, with today's beta version rivaling complete OS responsiveness of just 10 years ago. Flash may have a native code advantage, but with tighter lock-in of graphics hardware to a browser's rendering engine just around the corner, the advantage of native code running as a 3rd party plug-in will not be as necessary except for the most intensive games.
5. Security
As browsers & their tabs run in more sandboxed areas with each round of security lockdown, Flash is a gaping hole of unknown security. Adobe has not always be forthcoming of closing their known issues. JS holes are well-studied, open to all for review, and usually fixed in short order.
4. Agility
Adobe's release schedule doesn't converge with any particular browser's and the support of a new browser feature may require still more waiting if you're to using it from within Flash. By using a framework - or several - one would expect patches/extensions to arrive and mature more quickly than a single vendor.
3. Openness
When using an open JS framework, you can continue to dive until the issue you are researching is isolated and in plain sight. With a native plug-in, you may get to the undesired behavior of an API and be stuck with working around it or skipping it's use altogether.
2. Market acceptance
Like it or not Apple is refusing to run Flash. Other emerging platforms may or may not jump on this bandwagon. Proven over and over, sticking to the core platform of a delivered browser and it's open standards is the best bet for long term viability for a site.
1. One not Two
Every site is going to be using JS anyway - do you really need to carry data between the two layers? Just stick within the lower-walls of the garden you're already in rather than constantly embed and marshal.
I'd mod up but today I'm out of dots. Anyway, your point is key, I believe: MSFT cannot ignore online services at any cost - even a loss. They will continue to throw things at the wall, hoping for it to stick in a large-market way. Until then, they fund their smaller players as a set that adds up to a moderate player overall.
I think what is more expected of something "cross platform" these days is being able to install the sandbox on any machine - without encumbrances. .NET's CLR cannot install on platforms not directly or indirectly supported by MS itself.
Silverlight, SQLServer, WebApp are all examples of embedding, not cross platform. The platform is the hosting stack that mitigates hardware resource contention.
I think of cross-platform as in: Palm, IPhone, Android, OSX, Linux, AS/400. Mono is one path to these, but de Icaza knows the devil in the details: less-than-full .NET framework has been made available without open licensing to his project.
Some of the strongest minds in computer science have built out .NET, and continue to do so. There are some practicality gaps, but today the majority of the corporate world is powered by .NET devs, for better or worse.
However, this many years into the platform, it's starting to show it's age. From .NET 1.0 applications, laden with crude pinvokes to Win32 API's, GDI+ silliness, messy ADO.NET integration, through 2.0, 3.5, 4.0, the "Enterprise" helper classes, the "Foundation Extensions", the integration of pseudo-SQL declarative syntax with LINQ, Entity Relation classes, Unity, security, contracts, plus all of the layers of ASP.NET tools .... don't VS's forget code analysis, test suites, code coverage, profiling, generated documentation... there are many more but you get the point... ...all this is shaping up to be a very MS-centric view of the .NET universe. Which is a mistake, De Icaza seems to imply. I wholeheartedly agree. While the computing world abandons PCs for most tasks (gaming, editing information aside) and info consumption is done via smaller devices, on a variety of hardware & OS's, MS has bound .NET to their OS deployments - and there will be many other OS's talking in that space.
This is Microsoft's biggest gamble with .NET: That as the OS lives or dies, so does this platform. Really, it could be bigger than Windows. If MS shipping a full (even licensed) 4.0+ framework for use on Linux & Apple, it would inject a massive growth spurt in both those platforms but a huge and lasting foothold on the MS-based app development.
'Off the grid' you say? What part is "off"?
- The one where you rented a Caterpillar tractor from the dude down the interstate to level your pad?
- The one that used PVC piping from Dow Corning to build your well and leach field?
- The Monsanto engineered seeds that grow the veggies to supply almost 60% of all calories in the entire US market, including the ethanol?
- The one that used a hugely complex system of energy generation, transmission, regulation to form anything made of glass, metal, plastic, paper, etc.
- The systems of cartography, tax districts, property ownership that map, photograph and check on your little patch of homemade campground?
Dude, there's been tons of reliance on an external system of commerce, energy, logistics, information that "off the grid" has been a misnomer for decades in the US. A chainsaw and a generator does not make anyone off the grid.
What you're mistaking is that the concept of "pay as you use" for medical care is gone - rightly so, because it;'s been gone a long time. When you are pried out of your crashed pickup truck and driven to the hospital, patched up and sent home, the $50k is took to get you through that isn't just wrapped into taxes, it's now a separate line item. Oh, unless you were holding onto that 50k for just such an occasion. In a cabin. Off the grid.
Medical emergency situations occur many times a week. Would you rather we just moved folks that couldn't pay to the side and left them there? We're paying for medical system that anyway. Now you can help us, those that understand and accept an interdependent world, while still play-acting "off the grid".
You may want to get a version of linux made after 2000.
Porsche 918 Spyder gets 58mpg and this is a freaken scream machine. Porsche
If they were all made of paper-light materials with low-drag-cof. surfaces and one-weather tires, and had specialized components - all with a budget 3x the cost of a normal auto manufacturer, then HEY! You could be right!
The initial momentum vertically is the highest energy requirement, which severely limits payload as energy storage becomes a huge issue. Large fan blades are probably not possible as well.
Perhaps a spring or hydraulic based jump-start system (undercarriage paddles?) could enable a vehicle to begin large hops while engaging a ducted fan system that doesn't give full lift, but can slow a landing. For full flight, I suspect a folded wing system of some kind will be necessary.