I've seen a video of a crow fashioning a hook out of a piece of wire and using it to snare something from the bottom of a glass beaker â" which exceeded the length of the crow's beak.
Just floating a unlikely hypothesis here, but could it be that cetan's use of a well-known pseudo-homophone of an idiomatic phrase, in a thread on that very subject, might be intentional?
In my 41 years on this planet, I had never heard "dog in a manger". In contrast, I've heard "tragedy of the commons" frequently. I admit that I'm just one data point, but it could be that the fable is too obscure to be useful.
Actually, afterreading about it, it appears that the fable misses the mark slightly, since the moral of the story hinges on the fact that the dog cannot eat the hay. In contrast, those who hoard IP frequently benefit from doing so.
If one's goal were to help set national mood-lighting for war, the combination of liberal politicians and conservative press wouldn't be a bad choice. Hypothetically, of course.
Midori is being designed in such a way that components of the OS communicate with each other in a location independent manner. API calls to a local machine are no different than API calls to a remote machine.
This strikes me as being similar to a design goal shared by Plan 9, and its spiritual descendant Inferno, both of which were based around the 9P protocol.
Juxtaposing the buyout and their annual revenues may have dramatic value, but not much meaning. What was their annual profit, and how would it compare to the current value of their APPL shares if the held?
I just wonder what it would take for you to believe that he was either full of it when he wrote that letter
Hard evidence to the contrary, I guess. He also promised 3Ghz PowerPC processors and couldn't deliver because the entire industry hit a brick wall in the race for clock-speed. It wouldn't surprise me if he overestimated his ability to renegotiate contracts too, and I would think publicly calling the labels out probably hurt in that endeavor. One of the many reasons it's better to keep quiet until you know you can deliver, I guess.
Because the existence of Amazon, Rhapsody, eMusic.com's DRM-free MP3 stores seems to say otherwise.
Why would you think that all contracts would have the same terms? That seems like a naive assumption. Couldn't it be that more liberal terms were given to these other services as a reaction to Apple's powerful position as a distributor? Or to balance out some other stipulations in the contracts, like greater revenue-sharing, or some other arrangement?
I'm honestly interested to hear all the alternative suggestions out there for communicating this message to Apple. We can't just send letters to generic customer service addresses and wait quietly.
When I read this, I'm reminded of old posts in the advocacy channels on usenet: an endless stream of people who just had to tell the world how they'd run the company if it was theirs: Apple, IBM, Amiga,... and they'd get all bent out of shape when their ideas were not put into practice. Pathetic, really.
Now if you were talking about toxic waste, or thalidomide babies, or child labor, then I'd have some sympathy for your earnest desire to get a company to listen.
DRM sucks, but it's a tradeoff that some consumers willingly buy into, and so what if they do? It's not a decision you need to make. Their choice does not adversely effect your ability to make another. Nobody dies...
It's not your company to run. Go run your own. Or educate consumers about the tradeoffs they're making. But don't get so stuck on the idea that Steve Jobs needs to listen to you in order for all to be right with the world.
I mean, especially given the fact that you're not even talking to the right company. DRM is a condition imposed by the record labels, genius.
It took Android and the jailbreak community to force their hand, make them admit that a web browser was not an SDK.
That's a wild & unsupported claim. A much simpler hypothesis is that the SDK wasn't ready to ship, the App Store wasn't ready to go live, and the browser was just used to placate developers and buy some time.
Your interpretation may make the jailbreak community feel great about themselves, but it fails the law of parsimony, don't you think?
What a brilliantly-conceived suicidal PR campaign. I can't wait until clang/llvm reaches the point where Apple can kick the FSF's stagnant compiler to the curb. Cut that weed off at the roots.
Please forgive me for continuing this thread for the benefit of anyone interested in GWT. This is the perfect opportunity to illustrate how deep the analogy between javascript and machine language is, since your concerns are exactly the sort of situations that a foreign function interface is designed to address: how do I call out to code in another language, or worse what if code in this other language needs to call back into my code?
We did run into a case where we needed this facility. We had to use a java applet to handle bulk uploads of extremely large files. This applet had a plain javascript API for callbacks into javascript, and we were able to expose methods in our java source code to receive these events (when the upload was completed, failed, or cancelled) and it was pretty easy to do.
The JSNI mechanism counts as one of the coolest hacks I've seen, as it lightly abuses the "native" keyword in java, which causes javac to ignore the method body when it compiles, leaving the GWT designers free to allow you to embed arbitrary javascript in the method body. In our case, it was just a few lines, but it was easy and damned powerful.
Sorry I can't give you a better example, but it's the get feeling I get about the whole thing when I look through how it works.
This actually makes a lot of sense. If you actually went and read the GWT source code -- and saw their extensive use of the JSNI interface (where java and javascript code reside in the same file), you might be left with the impression that this is how the source of your application needs to look. If that's what happened, then I can certainly understand your distaste for it. The good news, though, is that they make extensive use of JSNI at the lowest levels so that you don't have to. If you need to, you can, but that only happens in extreme circumstances.
I actually got to implement DnD in the GWT application that we wrote. We even looked at the gwt-dnd library (used in the example you linked to), decided that it was overengineered, and decided to hand-roll the DnD code that we needed for our specific app. (Our app is sort-of iTunes-like, where you can multi-select rows in a data table and drag the items over to a folder or playlist). Handling those events was very simple: one call to sinkEvents() to say what sort of events you're interested in, then in the body of onBrowserEvent() you have a switch statement that has a case for each event type you might get. The event types are exactly the same ones that come from the browser. They didn't invent new ones or try to map them to AWT/Swing events or any such nonsense. onMouseDown, onMouseMove, onMouseUp,... The language constructs I used for handling the drag protocol were two interfaces (DropTarget & DragSource), a DragController class, and an abstract DropController class -- of which I had a concrete but anonymous implementation in each of the two widgets that received drops. Oh, and a DragProxy view that moves along with the mouse. It was pretty easy, in retrospect.
When I write in GWT, I never agonize about what the underlying Javascript looks like. It's very much like writing in C, where you think only in terms of the semantics of the source language -- and rarely need to think of assembly language constructs like load, store, add, and compare.
There is inherently a difference between what you write in Java and what Javascript can do, and I simply do not trust that disconnect to be resolved well.
Thank you for replying. I'm curious to know if you can think of a concrete example to illustrate what you're trying to get at here.
I would far rather keep the transaction between myself and any client side UI purely data driven and code for the client side specifically, rather than have a half-hearted interface extracted for me from the server side code.
I'm also having difficulty mapping what you've written here with some aspect of GWT or how it is used. Although I agree that what you describe sounds frustrating and undesirable, I'm not getting how it relates.
For what it's worth, my aim is not to convince you of GWT's value proposition. I was just addressing misconceptions that might cause others to misjudge it.
if I primarily develop client side code then the least complex path is to do it in the native language for that environment, javascript.
I think history argues against this belief: you're not just writing code for one environment, but many different browsers, and different versions of each browser: IE6, IE7, FF2, FF3, Safari 2, Safari 3, Opera 8, Opera 9...This situation is very much like the situation that led to ANSI-C and POSIX, because the frustratingly-different flavors of UNIX and different instruction sets of the processors made it much less complex a proposition to write platform-independent code instead.
In my project, I was able to use Safari throughout development. When I tested in FF, it all worked beautifully. When I tested in IE, I had a brief panic, but it turned out to be one bad idiom on my part and I fixed it in a day. GWT really does insulate you from browser quirks. It was amazing.
And quite frequently in my experience EXACTLY what you want to do is tweak the generated code.
Maybe you could install a shock collar on yourself to condition yourself out of this impulse. I find that when my object code isn't quite what I want, the best course of action is to edit my source and recompile.;-)
Your answer is based upon misconceptions about GWT, though. Setting the amusing semantic debate about "code generation" aside(*), all of your objections are easily addressed by the JSNI facility in GWT.
This is no assumption about the back end, and invoking a soap client, or hitting a plain URL to fetch xml content, is certainly possible.
I can understand how one can walk away from a casual glance at GWT with these misconceptions. Nevertheless, misconceptions they are.
(*) The "code generation is evil" meme is typically reserved for the cases where one is expected to do something with the output beyond executing it.
Hmm...GWT is a compiler, not a code generator. ("Code generator", to me, implies that you're intended to read or modify, the output â" or send it through yet another compilation phase. None of those is true for the output of GWT's compiler.) Does your contempt extend your contempt to every other compiler in the universe: gcc, javac,...?
Also, I'm not sure I understand what "coupling" you believe exists between a GWT front-end and your back-end. You don't need to use java on the back-end at all. Lots of people use ordinary JSON services written in languages like python or ruby just fine.
The adoption rate of GWT is actually much greater than misleading question by the article's submitter. The reason that you don't see GWT on random websites has nothing to do with the fear of compiling to javascript. Rather, it's because GWT shines the brightest for sophisticated web applications that you never see because they're hidden behind intranets, or in some niche market that you don't encounter.
I've used it; it's awesome. When I started, I didn't know if I could trust the compiler either â" but that trust came quickly. Javascript is just x86 machine code to me now, and I love it that way.
Slashdot Mirror
So that you could have 8 to 16 virtual cores?
I've seen a video of a crow fashioning a hook out of a piece of wire and using it to snare something from the bottom of a glass beaker â" which exceeded the length of the crow's beak.
Grab a random phrase
Man, that would be a great...well...perhaps if the genre were emo or shoegazing...
Just floating a unlikely hypothesis here, but could it be that cetan's use of a well-known pseudo-homophone of an idiomatic phrase, in a thread on that very subject, might be intentional?
In my 41 years on this planet, I had never heard "dog in a manger". In contrast, I've heard "tragedy of the commons" frequently. I admit that I'm just one data point, but it could be that the fable is too obscure to be useful.
Actually, afterreading about it, it appears that the fable misses the mark slightly, since the moral of the story hinges on the fact that the dog cannot eat the hay. In contrast, those who hoard IP frequently benefit from doing so.
...won't someone think of the PORN!?
If one's goal were to help set national mood-lighting for war, the combination of liberal politicians and conservative press wouldn't be a bad choice. Hypothetically, of course.
Midori is being designed in such a way that components of the OS communicate with each other in a location independent manner. API calls to a local machine are no different than API calls to a remote machine.
This strikes me as being similar to a design goal shared by Plan 9, and its spiritual descendant Inferno, both of which were based around the 9P protocol.
Juxtaposing the buyout and their annual revenues may have dramatic value, but not much meaning. What was their annual profit, and how would it compare to the current value of their APPL shares if the held?
You sure about that? Slashdot is always full of people wanting to see license agreements enforced. Surely you've heard of the GPL.
I just wonder what it would take for you to believe that he was either full of it when he wrote that letter
Hard evidence to the contrary, I guess. He also promised 3Ghz PowerPC processors and couldn't deliver because the entire industry hit a brick wall in the race for clock-speed. It wouldn't surprise me if he overestimated his ability to renegotiate contracts too, and I would think publicly calling the labels out probably hurt in that endeavor. One of the many reasons it's better to keep quiet until you know you can deliver, I guess.
Do you have evidence for this?
This letter is sufficient for me.
Because the existence of Amazon, Rhapsody, eMusic.com's DRM-free MP3 stores seems to say otherwise.
Why would you think that all contracts would have the same terms? That seems like a naive assumption. Couldn't it be that more liberal terms were given to these other services as a reaction to Apple's powerful position as a distributor? Or to balance out some other stipulations in the contracts, like greater revenue-sharing, or some other arrangement?
I'm honestly interested to hear all the alternative suggestions out there for communicating this message to Apple. We can't just send letters to generic customer service addresses and wait quietly.
When I read this, I'm reminded of old posts in the advocacy channels on usenet: an endless stream of people who just had to tell the world how they'd run the company if it was theirs: Apple, IBM, Amiga,... and they'd get all bent out of shape when their ideas were not put into practice. Pathetic, really.
Now if you were talking about toxic waste, or thalidomide babies, or child labor, then I'd have some sympathy for your earnest desire to get a company to listen.
DRM sucks, but it's a tradeoff that some consumers willingly buy into, and so what if they do? It's not a decision you need to make. Their choice does not adversely effect your ability to make another. Nobody dies...
It's not your company to run. Go run your own. Or educate consumers about the tradeoffs they're making. But don't get so stuck on the idea that Steve Jobs needs to listen to you in order for all to be right with the world.
I mean, especially given the fact that you're not even talking to the right company. DRM is a condition imposed by the record labels, genius.
By "essentially", of course, you mean "not actually". ;-)
Unless you can link to a press release where Apple said that no SDK would ever ship, that is.
Do you even know the company you're talking about? If they're known for anything, it's that they keep their cards close to their chest.
It took Android and the jailbreak community to force their hand, make them admit that a web browser was not an SDK.
That's a wild & unsupported claim. A much simpler hypothesis is that the SDK wasn't ready to ship, the App Store wasn't ready to go live, and the browser was just used to placate developers and buy some time.
Your interpretation may make the jailbreak community feel great about themselves, but it fails the law of parsimony, don't you think?
(Occam's Razor)
What a brilliantly-conceived suicidal PR campaign. I can't wait until clang/llvm reaches the point where Apple can kick the FSF's stagnant compiler to the curb. Cut that weed off at the roots.
Please forgive me for continuing this thread for the benefit of anyone interested in GWT. This is the perfect opportunity to illustrate how deep the analogy between javascript and machine language is, since your concerns are exactly the sort of situations that a foreign function interface is designed to address: how do I call out to code in another language, or worse what if code in this other language needs to call back into my code?
We did run into a case where we needed this facility. We had to use a java applet to handle bulk uploads of extremely large files. This applet had a plain javascript API for callbacks into javascript, and we were able to expose methods in our java source code to receive these events (when the upload was completed, failed, or cancelled) and it was pretty easy to do.
The JSNI mechanism counts as one of the coolest hacks I've seen, as it lightly abuses the "native" keyword in java, which causes javac to ignore the method body when it compiles, leaving the GWT designers free to allow you to embed arbitrary javascript in the method body. In our case, it was just a few lines, but it was easy and damned powerful.
Sorry I can't give you a better example, but it's the get feeling I get about the whole thing when I look through how it works.
This actually makes a lot of sense. If you actually went and read the GWT source code -- and saw their extensive use of the JSNI interface (where java and javascript code reside in the same file), you might be left with the impression that this is how the source of your application needs to look. If that's what happened, then I can certainly understand your distaste for it. The good news, though, is that they make extensive use of JSNI at the lowest levels so that you don't have to. If you need to, you can, but that only happens in extreme circumstances.
I actually got to implement DnD in the GWT application that we wrote. We even looked at the gwt-dnd library (used in the example you linked to), decided that it was overengineered, and decided to hand-roll the DnD code that we needed for our specific app. (Our app is sort-of iTunes-like, where you can multi-select rows in a data table and drag the items over to a folder or playlist). Handling those events was very simple: one call to sinkEvents() to say what sort of events you're interested in, then in the body of onBrowserEvent() you have a switch statement that has a case for each event type you might get. The event types are exactly the same ones that come from the browser. They didn't invent new ones or try to map them to AWT/Swing events or any such nonsense. onMouseDown, onMouseMove, onMouseUp, ... The language constructs I used for handling the drag protocol were two interfaces (DropTarget & DragSource), a DragController class, and an abstract DropController class -- of which I had a concrete but anonymous implementation in each of the two widgets that received drops. Oh, and a DragProxy view that moves along with the mouse. It was pretty easy, in retrospect.
When I write in GWT, I never agonize about what the underlying Javascript looks like. It's very much like writing in C, where you think only in terms of the semantics of the source language -- and rarely need to think of assembly language constructs like load, store, add, and compare.
There is inherently a difference between what you write in Java and what Javascript can do, and I simply do not trust that disconnect to be resolved well.
Thank you for replying. I'm curious to know if you can think of a concrete example to illustrate what you're trying to get at here.
I would far rather keep the transaction between myself and any client side UI purely data driven and code for the client side specifically, rather than have a half-hearted interface extracted for me from the server side code.
I'm also having difficulty mapping what you've written here with some aspect of GWT or how it is used. Although I agree that what you describe sounds frustrating and undesirable, I'm not getting how it relates.
For what it's worth, my aim is not to convince you of GWT's value proposition. I was just addressing misconceptions that might cause others to misjudge it.
if I primarily develop client side code then the least complex path is to do it in the native language for that environment, javascript.
I think history argues against this belief: you're not just writing code for one environment, but many different browsers, and different versions of each browser: IE6, IE7, FF2, FF3, Safari 2, Safari 3, Opera 8, Opera 9...This situation is very much like the situation that led to ANSI-C and POSIX, because the frustratingly-different flavors of UNIX and different instruction sets of the processors made it much less complex a proposition to write platform-independent code instead.
In my project, I was able to use Safari throughout development. When I tested in FF, it all worked beautifully. When I tested in IE, I had a brief panic, but it turned out to be one bad idiom on my part and I fixed it in a day. GWT really does insulate you from browser quirks. It was amazing.
And quite frequently in my experience EXACTLY what you want to do is tweak the generated code.
Maybe you could install a shock collar on yourself to condition yourself out of this impulse. I find that when my object code isn't quite what I want, the best course of action is to edit my source and recompile. ;-)
Your answer is based upon misconceptions about GWT, though. Setting the amusing semantic debate about "code generation" aside(*), all of your objections are easily addressed by the JSNI facility in GWT.
This is no assumption about the back end, and invoking a soap client, or hitting a plain URL to fetch xml content, is certainly possible.
I can understand how one can walk away from a casual glance at GWT with these misconceptions. Nevertheless, misconceptions they are.
(*) The "code generation is evil" meme is typically reserved for the cases where one is expected to do something with the output beyond executing it.
Hmm...GWT is a compiler, not a code generator. ("Code generator", to me, implies that you're intended to read or modify, the output â" or send it through yet another compilation phase. None of those is true for the output of GWT's compiler.) Does your contempt extend your contempt to every other compiler in the universe: gcc, javac,...?
Also, I'm not sure I understand what "coupling" you believe exists between a GWT front-end and your back-end. You don't need to use java on the back-end at all. Lots of people use ordinary JSON services written in languages like python or ruby just fine.
The adoption rate of GWT is actually much greater than misleading question by the article's submitter. The reason that you don't see GWT on random websites has nothing to do with the fear of compiling to javascript. Rather, it's because GWT shines the brightest for sophisticated web applications that you never see because they're hidden behind intranets, or in some niche market that you don't encounter.
I've used it; it's awesome. When I started, I didn't know if I could trust the compiler either â" but that trust came quickly. Javascript is just x86 machine code to me now, and I love it that way.