Aha, my friend, you've forgotten one very important example. Why do I think it's important? Because they've made a model that's worth following. That company is TrollTech, better known as the authors of the Qt toolkit. They seem to be quite well with their model, which basically amounts to releasing their library code under the GPL, and making it available as a standard commercial library for a fee. That means if you want to write Free Software (err or rather, anything GPL-compatible and Free, I guess) you can use their library under the terms of the GPL. If you want to write commercial software, you can write commercial closed-source (or whatever other commercial model you are using) software, you just have to pay for developer seat licenses. Makes perfect sense.
I don't know what their bottom line looks like, but they seem to have been rapidly expanding and releasing new and improved products over the last few years, so it seems to be working well for them. I also think this is a pretty reasonable model for developers of library software - the benefits of Open Source, and the ability to actually profit off of your labor too. So while I agree that in general the GPL is probably too restrictive for businesses to feel comfortable with (they tend to feel more comfortable with BSD licenses - it's free, use it as you please, give us a nod for giving it to you), there are cases where it has been used successfully by profitable businesses.
I mean, it's great that Wi-Fi hardware is so cheap and commoditized and everything, but what people keep seem to be missing is that A) the cheap commodity hardware is designed for small local area coverage, which is fabulous for business LANs and easy home networking, but bad for a general mobile wireless service B) hotspot-only coverage just doesn't provide a strong enough value proposition C) the purely commoditized nature of the hardware makes for a zero barriers to entry business. Anybody can build a network of hotspots on one payment system. But even if everybody used the same payment system, there would certainly be some value from it, but not at such a striking level that it is likely to happen. D) The only businesses that really have a striking imperative to need hotspots there are coffee shops, hotels and other places that make a living off of having people linger. McDonalds wireless - bad idea (I know they are experimenting with it), they want to get you in and out as soon as possible.
The fact is, 3G wireless networks are going to win out in the long run. Being able to open your laptop in the coffee shop and surf the web is great, but the bigger "wireless" market is vehicular embedded communications devices, fully connected PDAs, email-on-the-go, web browsing from where-ever you want. And no, futzing with my fucking cellphone keypad to send a stupid SMS message just doesn't count, I want it all on my Palm Pilot/Windows CE device, I want it seemless, I want it universal, I want it affordable.
Okay, we all know DOM parsing is a hugely inefficient memory hog of a way to get data out of an XML file. This guy states, perhaps without lots of evidence, that SAX/event based parsing is hard to use.
Now I don't really agree. I've written my share of SAX parsing code ranging from simple to shockingly complex. The real problem is that as your problem becomes more complex, the state machine you build in your SAX parser is going to get more and more outrageous. Lots of booleans, or integers, or other miscellaneous state flags sitting around. It tends to make code that's unreadable by anybody except the author, and even then, I don't know if I could sit down and read some of the massive SAX-based Java-from-XML code generators I built a few years back without serious headaches. No, please don't tell me I'm a bad programmer, I am not interested in hearing unfounded criticism. My code is well structured and well documented, as much so as it could be, given that the structure of an event oriented parser is just plain convoluted.
Obviously if you are doing something really simple, none of this likely matters. And if you are doing something non-time or non-resource critical, you can generally get away with using DOM/tree-based parsing.
But it would be nice to have an alternative syntax that describes what you are ACTUALLY looking for when you are parsing a document. Something more readable than a big ole' event/callback state-machine mess. Alternative syntax (and semantics) for stream-based XML parsing. And that's what this guy is proposing, though his proposal is a bit strange, since it sort of looks like an oversimplified version of an event-callback parser, but maybe I just need to see a more complete concept or prototype of it than that one example. As for me, what I'd like to see is some "state-machine"ish way of describing what you are actually doing in the event parsing, that is compact and hopefully readable in a logical, linear way, so you don't have chunks of code in different methods all over the place flipping little state flags manually. But perhaps in the end any system ends up reducing to a variant of the existing event/callback parsing model, and you just can't gain any syntactic simplicity without major loss of expressivity. I just haven't thought about it enough.
Mini-DVDs. Like the small format mini-CDRs you can burn with ~200 megs of MP3s. I love my Memorex mini-CDR/MP3 player, for the portability of the discs, which I can easily carry 4 or 5 of in my jacket pocket when I go skiing. If they made mini DVD-R/MP3 players, I could fit my entire music collection on one mini DVD-R. And that would convince me to finally buy a DVD burner.
Sony has become a rather schizo company. Their consumer electronics division seems to want to make cool, sleek gadgets and their music division seems to want to prevent this from happening.
My favorite quote from the article speaks for itself:
Mike Tsurumi, a president of Sony Consumer Electronics in Berlin, insists that the move makes sense. "The music companies need to change their business model, he says.
This is an executive within Sony talking, mind you. Fucking amazing. Is there any centralized coordination? Isn't there a CEO of Sony corporate who keeps his divisions in line with the goals (i.e. bottom line interests) of the company as a whole?
All the opt-out list systems are just encouraging businesses to set up "partnerships" solely for the purposes of exchanging direct marketing data. I don't want calls from AT&T's "exclusive partner" in marketing baubles, trinkets and bullshit. I set up a business relationship with AT&T to provide me with phone service, period. If they call me to offer a new phone plan, fine, I can tolerate that, it's within the bounds of our business relationship. If their "exclusive partner" calls to offer me baubles, trinkets and bullshit ("exclusive promotional offer to sign up with suckourballs.com"), they can blow me.
I plan on taking a stand against this personally by breaking off business relationships with companies that insist on sharing my data with their "exclusive marketing partners" and crap like that. I signed up for the Massachusetts State Opt-Out list for a reason.
Yup, you're pretty much on the money. If the goal is transparent scalability, maybe you should first focus on making a system that is efficient (i.e. you don't need twenty computers in a cluster to run it), and reliable (with EJBs there are often so many extra things to break that they end up being less reliable). There are better O/R mapping tools out there, some of which are even free (Castor). The last project I worked on basically ended up eliminating entity beans and using almost exclusively stateless session beans. At which point we realized we were pretty much using no features of the EJB container exception transactionality at function call boundaries. Not that this is so hard that you need all that complexity to address it - a much simpler framework could provide declarative transactionality.
Of course, we couldn't eliminate EJBs entirely, because our customers really wanted it to run with the Weblogic 6 licenses they had bought (woe befalls he who tries to explain that if you are going to use EJBs, you might as well use JBoss since it's a ton faster and generally more reliable than Weblogic, and pretty well supported through their online forum). But then again the customers wanted to know they could call Weblogic with a problem - of course, Weblogic would never really be able to help them anyway (I know, I've tried their "support").
Yup, basically I would never use EJBs in pretty much any project I can think of again, since they just don't solve enough problems to be worth the pain and hassle. What they DO provide, and the reason people use them, is an application "blueprint" for teams without a decent architect to solve their structural problems. It's just possibly the worst such model imaginable, and it's truly sad that this model has caught on. If you want a framework for a truly distributed, reliable, scalable framework, Jini and, say, JavaSpaces provided MUCH more interesting options, but had no corporate acceptance. If you had REAL problems that require a distributed framework, this was the way to go, since EJBs have absolutely no awareness of the location remoteness features they provide built in (resulting in a potential mess of RMI shit in all but very, very simple systems). Which, in short, is why everyone ends up scrapping entity beans.
Ugh. Thanks for reminding me why the enterprise software business sucks so much.:)
Well, because that forces you to wrap and rewrap exceptions repeatedly to debug accurately, which is a gigantic pain in the ass. Perhaps this doesn't make much sense, but if you have a "Messaging" interface, which you then write an implementation of in JMS, you have to catch JMSException and translate it into a SystemException (or really probably a MessagingException, which extends your SystemException). The JMSException is probably a translation of some internal exception condition to begin with, since JMS is usually a wrapper layer around some proprietary API a vendor uses. Then you need to wrap the SystemException in your code if you are passing it up to a client in some remote-invokation system (we had our own custom one of those in this case too... ugh). And our initial crack at it worked, until some over-engineering entusiast old fogey idiot promised our Director of Engineering he had a better solution, and he went through and replaced everything with a generic "wrapping" system that resulted in (literally) 10-20 page long exception dumps everytime something went wrong. Then the developers couldn't even figure out what happened when something broke ("well, there's this exception, here, but that's not the real exception, we have to scroll down to get to the 10th exception and now look at the stack trace for it to see what's really going wrong..."). In other words, when you embed or wrap exceptions, you lose the stack trace, or have to embed it as text. What a fucking mess that system became after Joejoe Overengineering Idiot got his hands on it.
I'm not saying anything in particular is "wrong" (other than what this one fellow did), I'm just pointing out a flaw in the exception handling model that Java uses - several papers have been written on the subject, so I'm not the only one who feels that way.
Or maybe it's all psychosomatic? And maybe she has a mental illness? And maybe you and your sister began experiencing symptoms because you were being "taught" to experience this from an early age? I'm not trying to dismiss your mother's problem, it sounds very real, but I am not sure there's any evidence that it really is anything more than a psychological disorder. Certainly your description of the fact that exposure to broader society and developing normal social relationships with people who don't expect or tolerate such wierdnesses made your symptoms "go away" imply induced psychosomatic sympathy for your mother's illness.
I do know what I'm talking about too. I have family members who have suffered from anxiety disorder and panic disorder. The symptoms (a panic attack can feel like you are having a heart attack) are very real, even when the causes are psychological in origin. Luckily, the people in my family were self-aware enough to realize these were psychological problems, and they sought help of the appropriate kind, and didn't go hole themselves up in "safe" homes in the woods.
Well if you're right, then the authors of this article are indeed idiots. It sounds then like it should be pretty trivial to translate from WordML to OpenOffice XML. As for Microsoft's unwillingness to work with standards organizations, what the hell is new? Nobody ever thought they would do that. They've never done it before, they're not about to stop their monopolistic ways now.
Did you read the article? It's not about breaking a standard, it's about making a fucking USELESS file. If no formatting information is saved, it's no better than File->Save As Text. Clearly, separation of presentation and content is not unreasonable, and I think everybody would say they support that. But that's not what they've done. They have (at least according to the article, we won't know for sure till it's released) is eliminate the presentation data from their XML format. ELIMINATION of presentation makes the format useless for document exchange, and thus an essentially useless feature, period.
Re:Separating Content from Presentation a Good Thi
on
Office 2003 and XML
·
· Score: 1
Are you fucking dull or something? Sure, it would be in keeping with the theory of XML if you created an XML file that uses abstract constructs to separate blocks of text into their structural units, and then used XSL stylesheets to store the formatting information. But fundamentally the data is incomplete and the format is LOSSY if you don't save the formatting information, which is a critical part of the data. And frankly it's trivial to write an XML parsing program that just ignores any formatting data and gets the raw text from an XML document if that's what you want. A lossy format is unacceptable for document exchange uses, period, thus making this useless.
Now go off into your corner and be a good little troll.
Sigh, obviously I am familiar with the second law, and I understand that ultimately, most power on this planet is solar (hydro and geothermal, perhaps not, but even wind currents are fueled by absorption of solar energy). Nonetheless, the question is who puts that energy into it. If we have to generate electricity and take it off the grid, presumably the limiting reagent is the efficiency and cost of PV (photovoltaic) or related technology. If we can make use of biological systems that are substantially lower cost, lower environmental impact, and net carbon-neutral (absorb CO_2, output hydrocarbons of some sort), we aren't really paying for the solar, other than whatever opportunity costs of land use are. If it's a sustainable practice that doesn't require huge land resources, then it's reasonable - and as long as the cost reflects the economic allocation of land and so forth, the market is a reasonable mechanism for enforcing this. And like I said, ethanol can be produced cheap from cellulose, whereas hydrogen is expensive. The point is that hydrogen is not just solar power, it's photovoltaic solar power.
Bioethanol is biological solar power, much lower cost, much lower environmental impact, and so on. I don't have to justify it, since the point is obvious if you look at a basic cost analysis. Much cheaper to make, transport and burn ethanol, per energy unit output (or per mile travelled), than it is to do the same with hydrogen, and generating the ethanol can be done much more easily utilizing existing biological systems for low cost, low effort cellulose production, as compared to high cost (high environmental impact, high resource utilization) photovoltaics. There are several projects to use bacteria to make hydrogen, but they are pretty far off, just because natural systems don't tend to make substances in such a high energy state.
As to your first point, I encourage you to back this up with numbers. Please reference the correct research from the Department of Energy NREL programs. In fact, all of the current research has shown that ethanol can be produced from low cost feedstock in large scale facilities at comparable cost, per mile, to where gas is now (well, somewhat less than where gas is now actually). Specific numbers have varied between 1.00 and 1.30 per gallon of ethanol produced. And you get about 25% fewer miles per gallon with ethanol than with gasoline. Anyway, you can do the simple math. Cost competitive with gasoline, assuming you give it tax breaks for being net carbon-neutral in emissions. The ethanol you are talking about that's being used currently is corn-based ethanol, which is substantially more expensive because of the feedstock cost. Corn is a high cost/high value food crop. Bioethanol from low cost or waste cellulosic material (corn stover, surplus wood pulp and so on) has very different cost economics.
And I think this should answer your second question. Obviously corn ethanol isn't a sane choice - that's more of a government subsidy for corn growers than a viable fuel. And there are plenty of more efficient crops that can make use of land insufficiently arable for corn, or waste cellulose from other crops. The technology (enzymatic hydrolysis) to do it economically is still being perfected, but has a lot of promise. And with gas prices where they are now, you could even do it economically with older acid hydrolysis techniques and be cost-competitive.
Well, that doesn't sound like a great idea for a variety of reasons. The best proposal out there is a network of solar satellites. To build them cost effectively really first requires lowering launch costs drastically. This requires building a space elevator. This will all, I believe, happen, but realistically, it's 50+ years off. If we're going to have a national program to focus resources on, it should be building a space elevator (i.e. developing the remaining pieces of technology needed), because that could lower energy costs to the point where a "hydrogen economy" will become a self-evident reality. If energy costs were much lower, you can damn well believe that people would start buying cars that run on hydrogen produced with nice clean, cheap off-the-wire electrical power generated by solar satellites.
In any case, none of this addresses the short term social and political needs addressed by bioethanol.
Okay, let's throw away the environment from the equation. And throw away hydrogen momentarily. Assuming gasoline stays where it is now in terms of cost, roughly, we can make ethanol available at a lower cost per gallon and a roughly comparable cost per mile. And it performs roughly comparably in terms of engine performance to gasoline in an FFV.
Now let's look at hydrogen. It's expensive to produce. Real expensive. It's expensive to transport. Real expensive. Unlike ethanol, we don't have plans for factories that can produce and deliver cost competitive hydrogen. The closest we can come is natural gas reformation.
NOW add in the efficiency considerations. The hydrogen production process is quite inefficient. Hydrogen storage and transportation is always going to be more difficult and expensive than storing and transporting liquid fuels, though methods will improve with time. And on-fueling-site production is reasonable, but generally doesn't provide the same economics as large-scale facility production.
In short, it doesn't make sense to switch everything over to hydrogen as the magical "universal energy unit" until we've answered these questions better. And there are intermediate technologies, like bioethanol production, that we can take advantage of today. Cost competitive hydrogen cars are not 10 years off, they are more likely 20 years off. And the variety of refueling options is just not going to go away in the immediate future - there will still be legacy gas refueling, diesel for trucks, etc. Adding in ethanol to the mix doesn't really harm anything any more than adding in hydrogen, and it's remarkably easy and cheap to do it, comparitively speaking. In the long term, you are probably right, we don't want 8 different fuel choices, probably 2 or 3 is more than enough, but that will take a long time to accomplish, indeed.
I am as strong a proponent as any you will find for getting the oil monkey off our collective backs. We need to break the addiction - the cost of oil politics, as Peter Schwartz points out in this article, is too high.
But the myth of the hydrogen economy is confounding to me. For example, take the claim that "hydrogen is plentiful" made by Mr. Schwartz. Yes, it's a plentiful element, bound in low energy configurations in other molecules. There are no hydrogen "free lunches" sitting out there waiting for us to take advantage of them. The problem is that most of the sources of hydrogen take more energy to get hydrogen from than they provide in energy output from burning the hydrogen (or reacting it in a fuel cell). This is fundamental chemistry and physics. No ranting and raving or spending campaign is going to change it.
The "hydrogen economy" really needs to be relabeled as the "coal economy" or the "nuclear economy", because hydrogen's role in this hypothesized economy is merely as a very efficient battery.
The most viable alternative energy sources we have right now are right under our noses but we've chosen not to see them. Ethanol can be produced quite efficiently at reasonable cost from renewable sources. Low cost cellulose-containing feedstocks are available that don't end up with the energy-sinkhole problems faced by corn-based ethanol (i.e. you end up putting more energy into making it than you get out of it). The tools of biocommodity engineering are starting to mature, and this is where we need to put more resources.
Ethanol and methanol, in fact, can be used to power fuels fairly efficiently (not quite as much so as hydrogen). But we don't have to wait - FFVs (Flexible Fuel Vehicles) are on the market today, thanks to tax incentives. People need to be made aware of this alternative. The problem? Outside of the midwest and corn based ethanol, it's hard to fuel up on fuel grade ethanol at the pump. More investment in building production facilities and developing distribution channels to the pump is needed for the several million FFVs already on the road, and a government-financed consumer awareness campaign would also go a long way to supporting this effort.
Other real possibilities exist too - biodiesel, for one, though the economics of it are likewise not as favorable as for ethanol production.
We don't need to enslave ourselves to oil. But we do need to be realistic about the alternatives and acknowledge that hydrogen is merely part of the equation. We shouldn't use "hydrogen" as shorthand to refer to the broad array of _real_ alternative energy solutions that are available. The myths about hydrogen need to debunked - it doesn't make you anti-progress or pro-oil to point out the realities of a full "lifecycle analysis" (to use the term from the biocommodity engineering literature) of hydrogen production and usage. And to divert vast volumes of money to research hydrogen when that's not necessarily the most viable path to a sustainable energy economy seems at best foolish.
True to an extent, but it violates the "worse is better" principle. The languages that let you do the "bad things" (quick hacks that are useful, perhaps) and still enable you to do a lot of good useful things seem to tend to be particularly popular (witness Perl and C/C++).
Few can doubt that the move to procedural programming and the move to OOP are so useful you can't neglect them, but languages like the above that force nothing on you still prove to be popular. And functional languages have been around for years, as you know (the original "Worse is Better" article was written to explain the fact that LISP, the "better" language was losing out to C), but still only see usage in particular problem domains or among academics. And frankly, Java is hugely successful only in a particular problem domain - large server-side enterprise systems (notably, of course, not the domain it was designed for originally, at all).
But generally, you are correct that eliminating degrees of freedom does improve productivity - BUT if the capabilities lost make it harder to think about or map the problem into code, it's generally too costly a loss of functionality (i.e. loss of state in pure functional languages).
In java you can get 50% of the way to AOP using Dynamic Proxies (see java.lang.reflect.Proxy) which allows you to wrap all method invocations or an object. This without an outside tool. This is how a lot of j2ee app servers do thier magic.
Sure, of course you can. AOP is a technique, supported by tools, it doesn't need to be hoodoo magic to be useful. Mind you, like you said, it'll get you 50% of the way. You can get 50% of the benefits of assertions by writing a static Assert class and using it consistently. It's just that it is nice to have capabilities either built into the language to support good practices, or extensions to the language (a la AspectJ) to support them.
And the List thing is tired. We all know that Java is limited. It's limited compared to C++, it's limited compared to Lisp. Ya know what? That's a good thing. For large software development projects with many engineers involved. I can pick up other people's code and not worry about whether X really means X or whether it's a macro that's been defined elsewhere to mean Y. I realize my view on this isn't the most popular on Slashdot, but that's probably because people haven't had to manage teams of developers who aren't populated throughout with brilliant coders, capable of writing fast, functional readable code in languages that leave n degrees of freedom.
Adding capabilities to a language to support a particular kind of new programming paradigm is not unreasonable. I realize that the fact an extension to the language is needed seems like a limitation, and it is, but like I said, that limitation can be a godsend, and it's worth the tradeoff.
Of course, when I'm working on my own time on my own projects, I far prefer to use a manly language like C++, or a pleasant language like Python.
I checked this out almost a year ago now, and I'm sure it's come a way since then. First off, AOP is not going to replace OOP or any other paradigm of programming. It simply provides a viable alternative way to think about the control flow and execution of a program, and a shortcut for making more maintainable code.
Anybody who has worked extensively in Java has found this problem before. Cross-cutting concerns - you know, those systemic things that infiltrate their way into every module of your humongo-system, no matter how you try to partition it. Now, object-oriented programming, isn't that supposed to let you "blackbox" things so you can just abstract away such things and throw them in some "common" or "system" package and be done with it? Sure, you can. And you probably have. And I've done it too.
But these solutions can be suboptimal - for example, a project I once worked on had an Interface in the com.blah.blah.system package for logging, messaging, persistence, and some other features. These were always nasty pains in the ass to manage. I mean, some implementor of these objects existed everywhere in the system - if something changed fundamentally, or there was some insuffiency in the interface that was discovered, god forbid, you'd have to root around for hours changing code everywhere. Especially when exception signatures changed. Which eventually leads, in sheer frustration, to using Runtime exceptions everywhere, or declaring all of your "system" interfaces with "throws Exception". Ugh. Each solution seems worse than the problem.
Admittedly, problems like this can be solved with good refactoring tools and practices. But not always well. The exception issue for "system" or "cross-cutting" interfaces was one I've never seen solved well (again, I'm thinking of Java here, it's the language I have the most experience working in large commercial-scale projects in where this stuff is really important). If you are working on medium or small sized open source projects, or medium or small sized tools or desktop applications, you may never have come across these kinds of limitations or frustrations in sufficient numbers to justify looking into AspectJ/AOSD in general. But if you've worked on large enterprise software projects, I'm sure you can see that there is a need to "patch," but certainly not replace, the standard OOP methodology to address these kinds of concerns.
What part of Freedom are you misunderstanding? Freedom is a double-edged sword. Even RMS, who I'm sure isn't a flag waving patriot warmonger, would, I hope, argue that part of the Free in Freedom involves people who you don't like doing things you don't always approve of with your software. People can use software to train people who then kill people. People can use software to coordinate schedules and plan meetings to coordinate schedules and plan meetings about killing people. This is Freedom - they have the Freedom to do good or bad things with your software. If you are serious about Freedom in your software, you will accept this.
If on the other hand, your software is a political platform for your views and you think that's more important than Free Software (or Open Source Software, depending on your leaning), then go ahead and add the restrictions. I won't use your software since I find software that pretends to be Free while throwing in lots of additional random restrictions to be much more distasteful than straightforward, honest commercial software.
Slashdot Mirror
I don't know what their bottom line looks like, but they seem to have been rapidly expanding and releasing new and improved products over the last few years, so it seems to be working well for them. I also think this is a pretty reasonable model for developers of library software - the benefits of Open Source, and the ability to actually profit off of your labor too. So while I agree that in general the GPL is probably too restrictive for businesses to feel comfortable with (they tend to feel more comfortable with BSD licenses - it's free, use it as you please, give us a nod for giving it to you), there are cases where it has been used successfully by profitable businesses.
The fact is, 3G wireless networks are going to win out in the long run. Being able to open your laptop in the coffee shop and surf the web is great, but the bigger "wireless" market is vehicular embedded communications devices, fully connected PDAs, email-on-the-go, web browsing from where-ever you want. And no, futzing with my fucking cellphone keypad to send a stupid SMS message just doesn't count, I want it all on my Palm Pilot/Windows CE device, I want it seemless, I want it universal, I want it affordable.
Now I don't really agree. I've written my share of SAX parsing code ranging from simple to shockingly complex. The real problem is that as your problem becomes more complex, the state machine you build in your SAX parser is going to get more and more outrageous. Lots of booleans, or integers, or other miscellaneous state flags sitting around. It tends to make code that's unreadable by anybody except the author, and even then, I don't know if I could sit down and read some of the massive SAX-based Java-from-XML code generators I built a few years back without serious headaches. No, please don't tell me I'm a bad programmer, I am not interested in hearing unfounded criticism. My code is well structured and well documented, as much so as it could be, given that the structure of an event oriented parser is just plain convoluted.
Obviously if you are doing something really simple, none of this likely matters. And if you are doing something non-time or non-resource critical, you can generally get away with using DOM/tree-based parsing.
But it would be nice to have an alternative syntax that describes what you are ACTUALLY looking for when you are parsing a document. Something more readable than a big ole' event/callback state-machine mess. Alternative syntax (and semantics) for stream-based XML parsing. And that's what this guy is proposing, though his proposal is a bit strange, since it sort of looks like an oversimplified version of an event-callback parser, but maybe I just need to see a more complete concept or prototype of it than that one example. As for me, what I'd like to see is some "state-machine"ish way of describing what you are actually doing in the event parsing, that is compact and hopefully readable in a logical, linear way, so you don't have chunks of code in different methods all over the place flipping little state flags manually. But perhaps in the end any system ends up reducing to a variant of the existing event/callback parsing model, and you just can't gain any syntactic simplicity without major loss of expressivity. I just haven't thought about it enough.
Mini-DVDs. Like the small format mini-CDRs you can burn with ~200 megs of MP3s. I love my Memorex mini-CDR/MP3 player, for the portability of the discs, which I can easily carry 4 or 5 of in my jacket pocket when I go skiing. If they made mini DVD-R/MP3 players, I could fit my entire music collection on one mini DVD-R. And that would convince me to finally buy a DVD burner.
My favorite quote from the article speaks for itself:
Mike Tsurumi, a president of Sony Consumer Electronics in Berlin, insists that the move makes sense. "The music companies need to change their business model, he says.
This is an executive within Sony talking, mind you. Fucking amazing. Is there any centralized coordination? Isn't there a CEO of Sony corporate who keeps his divisions in line with the goals (i.e. bottom line interests) of the company as a whole?
I plan on taking a stand against this personally by breaking off business relationships with companies that insist on sharing my data with their "exclusive marketing partners" and crap like that. I signed up for the Massachusetts State Opt-Out list for a reason.
Of course, we couldn't eliminate EJBs entirely, because our customers really wanted it to run with the Weblogic 6 licenses they had bought (woe befalls he who tries to explain that if you are going to use EJBs, you might as well use JBoss since it's a ton faster and generally more reliable than Weblogic, and pretty well supported through their online forum). But then again the customers wanted to know they could call Weblogic with a problem - of course, Weblogic would never really be able to help them anyway (I know, I've tried their "support").
Yup, basically I would never use EJBs in pretty much any project I can think of again, since they just don't solve enough problems to be worth the pain and hassle. What they DO provide, and the reason people use them, is an application "blueprint" for teams without a decent architect to solve their structural problems. It's just possibly the worst such model imaginable, and it's truly sad that this model has caught on. If you want a framework for a truly distributed, reliable, scalable framework, Jini and, say, JavaSpaces provided MUCH more interesting options, but had no corporate acceptance. If you had REAL problems that require a distributed framework, this was the way to go, since EJBs have absolutely no awareness of the location remoteness features they provide built in (resulting in a potential mess of RMI shit in all but very, very simple systems). Which, in short, is why everyone ends up scrapping entity beans.
Ugh. Thanks for reminding me why the enterprise software business sucks so much.
Hey pVoid, where do you live? Because your comments are always pretty spot-on. Got a resume handy? :)
I'm not saying anything in particular is "wrong" (other than what this one fellow did), I'm just pointing out a flaw in the exception handling model that Java uses - several papers have been written on the subject, so I'm not the only one who feels that way.
I do know what I'm talking about too. I have family members who have suffered from anxiety disorder and panic disorder. The symptoms (a panic attack can feel like you are having a heart attack) are very real, even when the causes are psychological in origin. Luckily, the people in my family were self-aware enough to realize these were psychological problems, and they sought help of the appropriate kind, and didn't go hole themselves up in "safe" homes in the woods.
Well if you're right, then the authors of this article are indeed idiots. It sounds then like it should be pretty trivial to translate from WordML to OpenOffice XML. As for Microsoft's unwillingness to work with standards organizations, what the hell is new? Nobody ever thought they would do that. They've never done it before, they're not about to stop their monopolistic ways now.
Did you read the article? It's not about breaking a standard, it's about making a fucking USELESS file. If no formatting information is saved, it's no better than File->Save As Text. Clearly, separation of presentation and content is not unreasonable, and I think everybody would say they support that. But that's not what they've done. They have (at least according to the article, we won't know for sure till it's released) is eliminate the presentation data from their XML format. ELIMINATION of presentation makes the format useless for document exchange, and thus an essentially useless feature, period.
Now go off into your corner and be a good little troll.
Bioethanol is biological solar power, much lower cost, much lower environmental impact, and so on. I don't have to justify it, since the point is obvious if you look at a basic cost analysis. Much cheaper to make, transport and burn ethanol, per energy unit output (or per mile travelled), than it is to do the same with hydrogen, and generating the ethanol can be done much more easily utilizing existing biological systems for low cost, low effort cellulose production, as compared to high cost (high environmental impact, high resource utilization) photovoltaics. There are several projects to use bacteria to make hydrogen, but they are pretty far off, just because natural systems don't tend to make substances in such a high energy state.
And I think this should answer your second question. Obviously corn ethanol isn't a sane choice - that's more of a government subsidy for corn growers than a viable fuel. And there are plenty of more efficient crops that can make use of land insufficiently arable for corn, or waste cellulose from other crops. The technology (enzymatic hydrolysis) to do it economically is still being perfected, but has a lot of promise. And with gas prices where they are now, you could even do it economically with older acid hydrolysis techniques and be cost-competitive.
In any case, none of this addresses the short term social and political needs addressed by bioethanol.
Now let's look at hydrogen. It's expensive to produce. Real expensive. It's expensive to transport. Real expensive. Unlike ethanol, we don't have plans for factories that can produce and deliver cost competitive hydrogen. The closest we can come is natural gas reformation.
NOW add in the efficiency considerations. The hydrogen production process is quite inefficient. Hydrogen storage and transportation is always going to be more difficult and expensive than storing and transporting liquid fuels, though methods will improve with time. And on-fueling-site production is reasonable, but generally doesn't provide the same economics as large-scale facility production.
In short, it doesn't make sense to switch everything over to hydrogen as the magical "universal energy unit" until we've answered these questions better. And there are intermediate technologies, like bioethanol production, that we can take advantage of today. Cost competitive hydrogen cars are not 10 years off, they are more likely 20 years off. And the variety of refueling options is just not going to go away in the immediate future - there will still be legacy gas refueling, diesel for trucks, etc. Adding in ethanol to the mix doesn't really harm anything any more than adding in hydrogen, and it's remarkably easy and cheap to do it, comparitively speaking. In the long term, you are probably right, we don't want 8 different fuel choices, probably 2 or 3 is more than enough, but that will take a long time to accomplish, indeed.
But the myth of the hydrogen economy is confounding to me. For example, take the claim that "hydrogen is plentiful" made by Mr. Schwartz. Yes, it's a plentiful element, bound in low energy configurations in other molecules. There are no hydrogen "free lunches" sitting out there waiting for us to take advantage of them. The problem is that most of the sources of hydrogen take more energy to get hydrogen from than they provide in energy output from burning the hydrogen (or reacting it in a fuel cell). This is fundamental chemistry and physics. No ranting and raving or spending campaign is going to change it.
The "hydrogen economy" really needs to be relabeled as the "coal economy" or the "nuclear economy", because hydrogen's role in this hypothesized economy is merely as a very efficient battery.
The most viable alternative energy sources we have right now are right under our noses but we've chosen not to see them. Ethanol can be produced quite efficiently at reasonable cost from renewable sources. Low cost cellulose-containing feedstocks are available that don't end up with the energy-sinkhole problems faced by corn-based ethanol (i.e. you end up putting more energy into making it than you get out of it). The tools of biocommodity engineering are starting to mature, and this is where we need to put more resources.
Ethanol and methanol, in fact, can be used to power fuels fairly efficiently (not quite as much so as hydrogen). But we don't have to wait - FFVs (Flexible Fuel Vehicles) are on the market today, thanks to tax incentives. People need to be made aware of this alternative. The problem? Outside of the midwest and corn based ethanol, it's hard to fuel up on fuel grade ethanol at the pump. More investment in building production facilities and developing distribution channels to the pump is needed for the several million FFVs already on the road, and a government-financed consumer awareness campaign would also go a long way to supporting this effort.
Other real possibilities exist too - biodiesel, for one, though the economics of it are likewise not as favorable as for ethanol production.
We don't need to enslave ourselves to oil. But we do need to be realistic about the alternatives and acknowledge that hydrogen is merely part of the equation. We shouldn't use "hydrogen" as shorthand to refer to the broad array of _real_ alternative energy solutions that are available. The myths about hydrogen need to debunked - it doesn't make you anti-progress or pro-oil to point out the realities of a full "lifecycle analysis" (to use the term from the biocommodity engineering literature) of hydrogen production and usage. And to divert vast volumes of money to research hydrogen when that's not necessarily the most viable path to a sustainable energy economy seems at best foolish.
As long as it's not "suttee at home", I think we're fine.
Few can doubt that the move to procedural programming and the move to OOP are so useful you can't neglect them, but languages like the above that force nothing on you still prove to be popular. And functional languages have been around for years, as you know (the original "Worse is Better" article was written to explain the fact that LISP, the "better" language was losing out to C), but still only see usage in particular problem domains or among academics. And frankly, Java is hugely successful only in a particular problem domain - large server-side enterprise systems (notably, of course, not the domain it was designed for originally, at all).
But generally, you are correct that eliminating degrees of freedom does improve productivity - BUT if the capabilities lost make it harder to think about or map the problem into code, it's generally too costly a loss of functionality (i.e. loss of state in pure functional languages).
In java you can get 50% of the way to AOP using Dynamic Proxies (see java.lang.reflect.Proxy) which allows you to wrap all method invocations or an object. This without an outside tool. This is how a lot of j2ee app servers do thier magic.
Sure, of course you can. AOP is a technique, supported by tools, it doesn't need to be hoodoo magic to be useful. Mind you, like you said, it'll get you 50% of the way. You can get 50% of the benefits of assertions by writing a static Assert class and using it consistently. It's just that it is nice to have capabilities either built into the language to support good practices, or extensions to the language (a la AspectJ) to support them.
And the List thing is tired. We all know that Java is limited. It's limited compared to C++, it's limited compared to Lisp. Ya know what? That's a good thing. For large software development projects with many engineers involved. I can pick up other people's code and not worry about whether X really means X or whether it's a macro that's been defined elsewhere to mean Y. I realize my view on this isn't the most popular on Slashdot, but that's probably because people haven't had to manage teams of developers who aren't populated throughout with brilliant coders, capable of writing fast, functional readable code in languages that leave n degrees of freedom.
Adding capabilities to a language to support a particular kind of new programming paradigm is not unreasonable. I realize that the fact an extension to the language is needed seems like a limitation, and it is, but like I said, that limitation can be a godsend, and it's worth the tradeoff.
Of course, when I'm working on my own time on my own projects, I far prefer to use a manly language like C++, or a pleasant language like Python.
Anybody who has worked extensively in Java has found this problem before. Cross-cutting concerns - you know, those systemic things that infiltrate their way into every module of your humongo-system, no matter how you try to partition it. Now, object-oriented programming, isn't that supposed to let you "blackbox" things so you can just abstract away such things and throw them in some "common" or "system" package and be done with it? Sure, you can. And you probably have. And I've done it too.
But these solutions can be suboptimal - for example, a project I once worked on had an Interface in the com.blah.blah.system package for logging, messaging, persistence, and some other features. These were always nasty pains in the ass to manage. I mean, some implementor of these objects existed everywhere in the system - if something changed fundamentally, or there was some insuffiency in the interface that was discovered, god forbid, you'd have to root around for hours changing code everywhere. Especially when exception signatures changed. Which eventually leads, in sheer frustration, to using Runtime exceptions everywhere, or declaring all of your "system" interfaces with "throws Exception". Ugh. Each solution seems worse than the problem.
Admittedly, problems like this can be solved with good refactoring tools and practices. But not always well. The exception issue for "system" or "cross-cutting" interfaces was one I've never seen solved well (again, I'm thinking of Java here, it's the language I have the most experience working in large commercial-scale projects in where this stuff is really important). If you are working on medium or small sized open source projects, or medium or small sized tools or desktop applications, you may never have come across these kinds of limitations or frustrations in sufficient numbers to justify looking into AspectJ/AOSD in general. But if you've worked on large enterprise software projects, I'm sure you can see that there is a need to "patch," but certainly not replace, the standard OOP methodology to address these kinds of concerns.
2. People ignore insane laws and follow reasonable courses of action.
3. Hem and haw about changing moronic legislation.
4.
5. Oh come on, you know what comes last.
If on the other hand, your software is a political platform for your views and you think that's more important than Free Software (or Open Source Software, depending on your leaning), then go ahead and add the restrictions. I won't use your software since I find software that pretends to be Free while throwing in lots of additional random restrictions to be much more distasteful than straightforward, honest commercial software.
The Right To Keep and Bear Arms is about more than target shooting or hunting...
Well, let's get the story straight mister. Either we have the right to Keep And Arm Bears, or we don't.