Well, I would RTFA if I could RTFA, but I'll try to give you an answer anyway.
The problem is granularity. I interpret from the title (and nothing else, since I can't RTFA) that they want to reuse individual classes rather than entire projects.
I _hate_ the fact that every UML diagram begins with a blank sheet of paper and that individual classes are almost never reused.
Individual classes, however, are even harder to reuse than whole libraries. In theory you could take somebody's generic model of, say, a Person, and extend it with the extra things you need. As long as Person were well-written it might actually be reusable.
But in practice, it won't extend the classes you need it to extend, and it'll probably be tied in to a vast array of other classes that you simply don't need, making your life very complicated. Since requirements gathering is far harder than code writing, people who have to gather their own requirements generally just end up writing the code to match, since it's a trivial effort.
You lose a lot when that happens: you can't reuse a lot of other processing code that you want. However, how long will it take to find that code? Days, plus the time it takes to adapt? How long would it take you to write it yourself?
The lower the granularity, the harder reuse is. I'd like to see better, but with present programming languages it's not going to happen.
I really think you should wait before analyzing the philosophy of the Matrix too deeply. It is clear that there is much more to come in the third film and they really haven't touched their core thoughts yet.
I happen to agree with most of the posters: the core philosophy, even incomplete, is totally self-serving self-involved rubbish. Late night college freshman bullshit sessions. But I don't care. I thought it was hilarious. And beautiful. What more could I want?
I'm in the unusual position of being both a hacker and a Shakesperean actor. So I'm going to indulge myself on the subject of Shakespeare for a moment.
Shakespeare was clearly popular entertainment of the day, and not everything that dropped from his pen was Great Art. I don't mean the low, ribald comedies; I mean Pericles and Cymbeline and others.
Even his greatest works usually need to be trimmed of some fat. Shakespeare's audience understood the language natively, so his actors could speak faster than I should. His Romeo and Juliet fit into two hours; it takes me longer than that to perform a cut-down version.
And yet, I think you really need to perform Shakespeare to see why people think he's so great. It's difficult to describe, but the words just feel good on your tongue. You'd think it would be hard to memorize an hour's worth of text in a slightly foreign, sometimes over-florid language. But it usually isn't. It sticks in your mind like a good Monty Python line. You just can't get it out of your head.
I grew up despising Shakespeare because all I'd done was read it, under duress. That's the worst possible way to deal with it. It's meant to be performed. You should see it performed, not by Olivier or somebody else performing for your parents or grandparents.
And not by your high school, either, since the student plays are rarely educated enough to mean more than reading it. You need to find experts who love the plays and who will show you why they love them so much. The right community theater, or the right professional troupe, who really understands why these plays are good and aren't just repeating conventional wisdom ("Hamlet's a great play and you're going to sit down and watch me do it, dammit.")
Even better, go out and perform them yourself. It's easier than you think.
Thank you for your time if you've bothered reading this, and not modding me too far down if you don't care.
Excellent points. I have no mod points (actually, I do, but not here) but you deserve them.
I dearly hope Apple sewed up Windows rights along with Apple rights during the initial phase. Or at least set up a fairly solid "Let's roll it out for Mac and if it does X well you get Y terms when we hit the big Windows market." Otherwise, even at a million songs a week this is probably not profitable.
There's more to Java than cross-platform. In fact, with all the various versions running around, I'd say its cross-platform qualities are significantly overrated.
Java is far more important in its security and software engineering features (which are actually very closely related). I find that I'm far more productive in Java than I ever was in C++ and C. I find that's even truer for less experienced programmers. Java increases the ability of programmers to work together through better memory management, better type enforcement, exceptions, etc.
You don't really need to hear all this. At this point you either believe it or not and I'm not going to convince you.
I haven't been able to compare it to C#, which appears to offer many of the same advantages over C/C++. I think of Java in a different class from languages like Perl and PHP, which are less well-suited to teamwork, which is an important goal of mine.
So the reason for this is not because we need another browser (boy, do we not) but because Java needs a browser for use in its environment. Java is still very poor on the client side, for a host of reasons, one of which is its lack of browser integration. Applets were always a stupid idea, I'm afraid, because software distribution via applets just isn't ready and the toys are generally beneath contempt.
You need a browser as part of Java. It's the best way to view text, whether for help, mail, etc. Java has several, but none are really any good because they're not 100% compatible with the lastest rounds of HTML/HTTP/Javascript. A browser, compatible with IE and Mozilla, will help make Java a decent client environment.
I hope Apple gets its Windows version of iTunes quickly. Microsoft has a habit of making mediocre software available quickly, taking advantage of its large installed base, eliminating competition, then ceasing improvement.
People will pay for music, as they've demonstrated. Provide them a good interface and give them a reasonable deal and they'll pay. I think a lot of people find $1 per song to be a reasonable price, and iTunes is far easier to use than Kazaa/Gnutella. Most people don't want to hack, they don't want to circumvent DRM, they don't want to wait forever to download music, and they sure don't want spyware. They're happy to pay a fair price for the service.
My worry may be misplaced, because unlike other Microsoft placements, this won't be free. Even if it comes on your computer for free (and people are upgrading much more slowly than they used to, so just providing it with the OS doesn't provide the channel that it used to), you still have to sign up and pay. Microsoft is pretty good at tricking people into doing so; the service will assuredly use Passport and they can be very...insistent about signing up for a Passport account.
But a lot of people won't pay, because it's too much trouble for them. Many of those who will pay will go the extra step to get Apple's software. That is, of course, assuming that Apple gets the software out. It's claimed it for the fall, but Microsoft can probably get its software out at least that quickly and into a "service pack" for Windows.
That also assumes Microsoft intends to actually develop the software at all. Microsoft doesn't even need to develop software at this point. Many users will read the announcement and forget about Apple's take on it, because they'll assume it'll come free with their next computer.
It won't make them happy, but my basic assumption in marketing is that users are lazy. Look at the number of people whose home page is still MSN because they never bothered to get a different browser or even to change the home page to something they care about. Users will put up with a lot of crap if it means no effort. It takes a very smart company to work around that laziness.
I hope Apple can be that company, because it's the best shot I've seen at getting music to people and money to musicians I've seen yet. It's not perfect for a host of reasons (mainly due to the record studios and Clear Channel), but I think it's the right compromise today.
I haven't worked with OCAML, so I'm speaking solely from theory, and practice with other languages.
I have to admit surprise at the results, if for no other reason than that g++ presumably has many more programmer hours put into its optimzation.
I've long speculated that a functional language would one day outstrip imperative languages in performance. They offer far more opportunities for optimization. I didn't expect it to happen any time soon, since exploiting those opportunities takes time, and since functional languages attract less attention than imperative ones, I didn't expect that time to have been put in yet. I actually expected it to be a purely functional language, because of the difficulties I outlined in my original post.
I'll have to spend more time exploring the language and see how the compiler writers have actually exploited the optimization opportunities. Thanks for the pointers.
Like any drug, used occasionally, wisely, and with moderation, it can add pleasure to your life without ruining it.
I like TV when I'm frustrated; it can reset my mind when I'm spinning on some issue. I like TV when I'm ill; it takes my mind off the suffering. I like TV when I have 30 minutes to kill and there happens to be an episode of The Simpsons on.
It's a drug many, many people abuse, and I'm sure that's what you're thinking of in your post. If you're watching TV three hours a night, every night, it's clearly a drug that has begun to control you. If you're settling for the best thing on TV rather than getting on with your life, you're doing it wrong.
To paraphrase Shakespeare: "Good TV is a good familiar creature, if it be well used; exclaim no more against it."
I do wish most people would watch less TV, but I think that declaring TV in general to be a "disease" is counterproductive. Try thinking of it as a drug that too many people are addicted to.
It's usually a very bad idea to include imperative aspects in functional languages.
Functional languages are amazing creatures. They're really strange to work in. They take a serious change of mindset. They can be very slow to execute. I/O is really odd when side effects are forbidden.
They have astounding benefits, too. The localization of effect means that they're really easy to debug. The lack of side effects means that some really enormous optimizations are open, which is crucial since the naive execution is slow.
Once you throw in any imperative aspects at all, these effects go right out the window. Even a single imperative statement potentially interferes with every optimization. ("Can I eliminate this execution branch? It seems like a redundant call but it might branch to that imperative statement.")
I think that this got in the way of ML. It can be easy to want to add just a tiny imperative element to make something easier, but that small crack opened up a lot of headaches for me. I greatly preferred the purity of Haskell.
I haven't read the F# spec, so I may be overreacting from the notoriously inaccurate Slashdot summary. That's next.
It's not like anybody needs extra piracy tools. They are copious and readily available.
The difference with iTunes is that it makes obtaining music convenient, efficient, and legal. Running iTunes doesn't feel like hacking into something. It feels like buying something. And a million downloads the first week suggests that a lot of people would rather get their music without feeling dirty and without having to wade through the bad connections, dubious rippings, and intermittent availablity of a P2P network.
This site changes very little. Apple has put just enough difficulties into iTunes protocol to make it easier to buy music than steal it. Slashdot caters to the technical crowd who want to know what's possible. There's a big difference between the possible and the feasible.
Re:That's what theoretical CS is all about
on
Innovation on the Edge?
·
· Score: 2, Interesting
I can think of only a few: System/R becoming relational databases; the language work that became LALR parsers; some of the graph-theoretic work that became the Internet.
In most cases it was a huge leap between research and the implementation that made it actually useful. Innovations in the course of a "simple matter of programming" are more often intuitive understanding that only later is justified by research, sometimes prior but unknown research.
Meantime, 99.9% of what comes out of theoretical labs is crap. That's not where I go looking for the next generation.
Look, I _am_ a theoretical computer scientist, and my job right now consists of taking a bunch of old theory work on logic programming and ontologies and making a commercial product out of it.
And because of that, every "crazy" computer guy who think's he's Galileo wants to show me his crackpot theory, and he's sure I can fill in the few blank spaces in his work. Note to such: if you think you're a crazy genius, recall that the former outnumber the latter by about 400 to 1. There are a few in both categories, but more likely you're one or the other, and I know which way I'm betting.
Probably because it's not worth the effort to publish negative results. If you hated a book, or even just disliked it, you just ignore it. It'll be lost in the vast morass of other books out there.
The exception will be books like Stephen Wolfram's A New Kind of Science, where the book has such high visibility that the Slashdot community will want to hear either way, good or bad. And it got a mixed-to-negative review, as I recall.
This isn't a book-review site, so it won't be comprehensive. To make it so, we'd have 20 times as many articles as we do now, most of them with so-so or negative reviews.
Amdahl's law is more of a "law" than Moore's law is. It's a way of figuring out how much of a speedup is really possible from parallelization. The formula is:
S=N/((B*N)+(1-B))
where S is the speedup, N is the number of processors, and B is the percentage of the program that must be serially. The upshot is that as long as B is greater than 0, you'll never get the N-times speedup you'd hope for from throwing N processors at the problem.
It seems a pretty trivial result, but it's basically Gene Amdahl's way of throwing the "multiprocessing will save us" theory back in the faces of its proponents. Multiprocessing is the obvious way to speed things up, but if it won't work on every problem, we'll have to look elsewhere.
The concept is designed only for digital content. From the site's Merchange FAQ:
Use the PepperMill to encrypt your digital goods for sale. Part of this process includes associating a price and description with each item.
Publish your encrypted content--we call these new files PepperBoxes--on your Web site. (You can also choose to email PepperBoxes to targeted customers.) Make sure to indicate on your Web site that you accept Peppercoin payments for this content.
All consumers are free to download your content in encrypted PepperBox form; however, only those who pay are allowed access to the content. When the consumer pays for the content an exchange is made--the consumer sends a "PepperCoin" for the sale price, and receives the decryption key.
Peppercoin then processes your transactions by running our patent-pending payment processing protocol. You are paid and the consumer is billed by Peppercoin.
It's remarkable that Serkis did both the (incredible) voice work and (astounding) physical performance. There will be more characters like Gollum over the years, but they're unlikely to match Serkis' incredible range. You'll have a dancer for the body, a rubber-face for the face, a voice actor for the voice, and so on. It's rare to encounter so much talent in one person.
This is a golden moment for the Academy to honor an astounding performance the likes of which we may never see again.
I can't hold it against them too much: for the most part the Academy wouldn't recognize good acting if it walked up and bit them. They too often honor "showy" acting, largely one-dimensional with huge emotional swings and featured parts, that are actually built on a combination of music, camera work, editing, and a host of other factors outside the performance itself.
I'm an actor myself, and IMHO on film you can see only a performance, not an actor. That's good: you're not supposed to be watching the acting. The hard work of acting is accomplished where you can't see it, in rehearsal rooms and in the actor's bathroom, in front of the mirror, and in long talks with fellow actors at the bar worrying about each syllable, on set finding the right tone not just for you but for everybody in a scene. All of which can be lost by different editing, direction, a music choice going the other way, or another actor taking a different choice.
I applaud Serkis' work, and I want to see if he has range as well as talent. I'm sorry the Academy chose not to honor him, and that's always going to hurt no matter how meaningless the award and no matter how thunderous the accolades from the people whose opinions really do matter.
I doubt the lack of sales tax is the only reason you buy from the Web.
Among other things, Web stores are open 24 hours a day and they have things in stock that you can't get at your local store.
Web stores operate out of warehouse space, which is far cheaper than retail space, especially if you live in a city. The employees don't have to deal with the public, so their time is spent more effectively.
Retail stores have many downsides. They have to deal with remainders (items that don't sell) more often, and have to choose carefully the tradeoff among items to stock. Most can't operate 24/7. The employees can be a real problem: if one person doesn't show up for work, long lines can develop at retail counters.
Shipping is expensive, but it's the only downside to web stores. They have many other economic advantages on their side, so they can continue to be a bit cheaper, and often more convenient. I buy things from Amazon that I could get from my local Borders, but that bookstore is a good 20 minutes away. Total round trip is 40 minutes. I'd buy it from Amazon even if it were a bit more expensive. Add the fact that it's generally cheaper, even with Amazon's economic model hiding the shipping cost in the price, and it's no contest: I spend far more at Amazon than retail bookstores.
Other stores offer things I can't get locally without much travel, from cake decorating supplies to obscure DVDs to Ebay's miscellania, and I live in a major metropolitan area.
Does it suck that I'm now paying 5% more for my stuff than I used to? Sure. Will it cut into some sales? A bit. But I doubt it's the Imminent Death of the Web.
In some ways, the problem wasn't so much "incredibly mediocre" as just "mediocre". They took no chances so they never could succeed (the series, not the characters, who took amazing risks but always, always won.)
I'm an actor myself (amateur), and for me, the best drama is always the kind that risks failure. It has to have an opportunity for people to hate it before anybody will really love it.
TOS took great risks, even in the movies. Many of them failed; many others succeeded.
When you try to please everybody, you end up pleasing nobody. The latest movie even ended up alienating my mother, who's the perfect model for their target: she's an old series fan from the first, and she's mainstream rather than sci-fi. She's exactly the type to be pleased with simply seeing her old favorites again. Nemesis offered her nothing new, so she saw it exactly once. We saw Wrath of Khan over a dozen times.
I saw each new Star Trek movie with her on Christmas day ("It's a Technicolor Christmas when you're Jewish.") She'd seen it opening weekend, and couldn't be bothered to see it again. So I never saw it.
Funny. I'm in the same boat, and there are others in the thread who said the same thing. We're Star Trek fans and we've all decided, simultaneously, to give up.
That's not necessarily the reason the movie tanked. We're not really its core audience anymore. They've been trying to make it more mainstream for some time. My guess is that the mainstream heard, "Well, if the Trekkies aren't going to see it, why should we?"
That's not the media reviews. That's their friends. I'm the biggest Trekkie of my group. If I'd gone, others would have come.
Why did we all give up simultaneously? I think it's a combination of sub-par TNG movies and the sub-par Voyager and Enterprise series. When there were only 79 episodes of TOS, you _had_ to see the movies: you'd seen everything else. You even had to see Trek V. But if you gave up after Voyager, as I did, and never got into Enterprise, you're already out of the loop. It's not that you're afraid you won't get it. It's that you no longer have that drive to see 100% of Star Trek.
I don't think that LotR at the same time was the problem. If it had been very good, or if we were all still dedicated fans, we'd have made time. We weren't spending that time watching LotR again. We were doing something else, out of the theaters entirely.
I don't believe the Trek franchise can be salvaged. Certainly not as long as Berman doesn't understand why the last one tanked. But even if he did, he's lost an awful lot of potential fan base. He might be better off starting a new series of his own.
He could turn it over to the Deep Space 9 crew instead. The series didn't develop the cult that TOS did, but it did have a devoted following. They too would have a hard time digging out of the hole the franchise has dug itself, but they've got the best chance.
If not that, then just let it rest. I loved the series, but none of the other things I love are immortal. Someday I will find something new to love; indeed, I already have. I will remember Star Trek fondly, and that means I probably won't see Nemesis until I catch it, wistfully, on DVD, and remember better days.
Re:Programming for the Java Virtual Machine
on
The Future of Java?
·
· Score: 1
Unfortunately, you can't divorce the libraries from the rest of the VM when you want to talk about what makes a great VM.
From a computational standpoint, the instruction set is just part of the Turing tar-pit. They're all the same; there's nothing you can do on one that you can't do on the other. Some are going to be oriented towards particular languages (like the Emacs bytecode for lisp, or the JVM for Java) or you can make it more general purpose.
You could, for example, translate C for the JVM. Unfortunately, it would be a singularly unpleasant translation, because C's pointers would mean you can't use any of the native types. You'd have to emulate all of memory in a big byte array.
So the question is, can you use the JVM to access the parts of the computer that aren't related to computation: the disks, the monitor, the network. I happen to really like Java's approach compared to Microsoft's, but that's largely a matter of taste.
Universality is also really important. Although the JVM has been ported to a vast array of platforms, the fact is that by putting the CLR on on Windows, it'll have vast penetration. It'll also be easier to access. If you've ever tried to actually deliver a Java-based program, you know you have to deal with either deliver a 14-megabyte runtime system or trust that you can find the correct version of Java. The JVM changes very rarely (I can recall only one real change, in the area of floating-point ops), but the libraries change all the time.
But you're probably really asking about the instruction set. It's clear from looking at the CLR that they knew the JVM, and knew what they liked and didn't like. It's a very Microsoftian approach: start with something good, add features to it that arguably make it better (but which some would argue just add bloat) and make sure it's everywhere, for free. It happened to Netscape, it happened to Stacker, and it could happen to Java.
There are some odd things in the CLR instruction set. For example, the CLR has references to native values. That's certainly convenient for some things. Just yesterday I wanted to return two values from a function, and it would have been easier if I could just pass in a reference to an integer.
But that's going to make it hard to optimize. The JVM JIT knows that if you have an int field of an object, the only way to change that value is to have access to the object. That's a huge boost to optimizer writers. If you can prove something doesn't change, you can sometimes eliminate huge swaths of code just by proving that they have no side effects.
I found a kind of odd instruction called "tail", which allows you to turn method calls into gotos. Gotos are bad for software engineering, but they're really what goes on in the chip itself. A method call, at the most fundamental level, is moving a bunch of stuff onto a stack, including a reference to get back, and executing a goto. If you can prove that you don't really need to come back (because the method call is the last thing you're going to do) you can free up your local variables. You may even be able to inline the method call, which allows you to save the goto.
(Gotos are bad at the JIT level, because they violate locality of reference. Locality of reference allows you to pre-load upcoming instructions, and maybe even start to execute them. Gotos aren't as bad for that as conditional gotos, but they still imply that you're jumping to a different block of code that you may not have cached. That can take on the order of 100 nanoseconds, which is forever given that on a modern CPU an instruction can take as little as 1 nanosecond. Even less if you take all the pipelining into account that lets you run dozens of instructions simultaneously.)
The most obvious place where the CLR stole from the JVM is in verification. I'm sure that the JVM wasn't the first VM to enforce type guarantees on the stack, but it was a completely academic issue until Java put it on every computer in the world. The CLR uses the exact same concept, except that it's more complicated because the CLR has many extra features over the JVM.
Not to mention that the CLR has an "out" designed to allow C code to be translated better than the system I described above. The upside to that is that it allows you to integrate old C programs more easily: you just recompile for the CLR and live with the fact that it's not safe anymore. On the JVM, you'd have to patch in JNI and that's a real pain in the ass. Plus it violates all the same safety guarantees, so you're just as screwed.
That screwage applies to optimization as well. C allows you to optimize memory access brilliantly, but it makes it almost impossible for a JIT to ferret out your intentions and optimize. If you can't prove that a piece of code has no side effects, you can't eliminate it. Pointers make it nearly impossible to prove the absence of side effects; any piece of code could affect the memory of any other piece of code.
So to finally get back to your question: which do I prefer? Microsoft did a great job of learning from the JVM's mistakes (or things they consider mistakes). I love the idea of Haskell for the CLR (I did a thesis on Haskell, and it's a hard langauge to love but I do anyway).
I suppose to really answer the question I'd need to know one thing I haven't had a chance to investigate yet: how fast does the CLR run? MS has always been oriented towards performance over clean engineering. But premature optimization is the root of all evil, and there are a lot of people writing angry replies to this right now castigating me for claiming that Microsoft has any interest in performance. The problem is they do: they optimize early, and we're still living with the disasters of early optimizations. Remember 8.3? That saves you a bunch of disk space on 720k diskettes. Not so good on 120 gig hard drives.
The JVM has almost 10 years worth of optimization, plus I've outlined some theoretical reasons why it should run faster in the limit case. But I don't have any performance comparisons at my fingertips.
That may not make a difference, in the end. At 4 GHz, who cares about whether a machine is 10% slower? I learned to program on a computer literally 1,000 times slower. Today's usability has a lot to do with how much you want it to do. That computer couldn't handle a single window, nor could it antialias the text. I'd be pretty pissed off to be using that computer today. But at the time it did the job. A 10% performance boost wouldn't move Swing from "unacceptable" to "acceptable", and that's mostly outside the bounds of the JVM.
I'm also curious to see how well the CLR will penetrate. Sun has fought to get the JVM on every computer. I don't think it will, even with Microsoft shipping it, because the Java library changes too often. I like the changes, love them, but I'm busily shifting code from 1.3 to 1.4, and I'll probably shift to 1.5 when it comes out, because I love the idea of polymorphic types. So it won't matter if Microsoft ships 1.4 on every system; if I use even a single 1.5 specific feature, I'm stuck delivering my own JVM. For me, that's not so bad: my current software takes up 100 megs. But my first delivered Java program was a fun crossword puzzle applet, and it takes 100K. You can't load that up with 14 megs of runtime to deliver it.
In the end, despite their vast similarities, there's really no comparison between the JVM and the CLR. The differences will be manifest not in the instruction set but with the popularity with developers and the needs of companies to distribute actual, running code to actual, running computers. That will end up being more a political decision than a technical one.
Programming for the Java Virtual Machine
on
The Future of Java?
·
· Score: 4, Informative
I wrote a book on the subject of translating other languages into JVM bytecodes. It's called Programming for the Java Virtual Machine, from Addison-Wesley, and you can pick it up at
Amazon
So speaking as a nominal expert, while you certainly can translate non-Java languages into bytecodes, the machine clearly isn't designed to be general-use. It has a lot of object-oriented instructions that fit the Java object model and not a lot else. You can adapt them to your language, or you can ignore them and code everything up as one big method call (except that you'll run out of space, since function size is limited, and you can't modify it once written).
I've successfully adapted languages like Prolog and Lisp, and taken advantage of Java objects to provide the continuation-like features of these languages. I've even found a couple of places where you can generate code which could not come from Java code but which is legal and verifiable (e.g. crossed loops).
I use it mostly for small projects. For example, Ontology Works generates Java APIs for its custom database description languages. It generates the bytecodes directly, since the APIs are too large to be conveniently compiled from Java. But that's not a general-purpose language, so the code is actually fairly simple.
I've only glanced at CLI, but it appears to be somewhat more general purpose than JVM bytecodes. (In the end it's all Turing tar pit.) However, CLI a bit more heavily oriented towards calling out to native code, which makes the code less portable and harder to optimize. The JVM also supports native methods, but they receive a lot less encouragement.
Mostly, I'm a huge fan of the way JVM does verification. It's brilliant that you can restrict code to safe code and still be Turing complete by eliminating a large class of safe-but-invalid instruction sequences. You can make huge optimizations to verified code that you can't make to generalized code. Verification also allows much more fine-grained authorization than the Microsoft way, which is all based on signed code.
You always want to choose the best language for the job. C/C++/Java are largely identical, and I think in general a group should pick one and stick to it. But there are languages (Lisp, Prolog, Haskell) which are genuinely different, and I consider it a good thing that you can write compilers for them. That has yet to completely fulfill its promise on the JVM platform, where there are proofs of the concept but they are little used.
Slashdot Mirror
Well, I would RTFA if I could RTFA, but I'll try to give you an answer anyway.
The problem is granularity. I interpret from the title (and nothing else, since I can't RTFA) that they want to reuse individual classes rather than entire projects.
I _hate_ the fact that every UML diagram begins with a blank sheet of paper and that individual classes are almost never reused.
Individual classes, however, are even harder to reuse than whole libraries. In theory you could take somebody's generic model of, say, a Person, and extend it with the extra things you need. As long as Person were well-written it might actually be reusable.
But in practice, it won't extend the classes you need it to extend, and it'll probably be tied in to a vast array of other classes that you simply don't need, making your life very complicated. Since requirements gathering is far harder than code writing, people who have to gather their own requirements generally just end up writing the code to match, since it's a trivial effort.
You lose a lot when that happens: you can't reuse a lot of other processing code that you want. However, how long will it take to find that code? Days, plus the time it takes to adapt? How long would it take you to write it yourself?
The lower the granularity, the harder reuse is. I'd like to see better, but with present programming languages it's not going to happen.
We had something like that here last night.
Somehow eclipses just strike me as something you have to be there for.
I really think you should wait before analyzing the philosophy of the Matrix too deeply. It is clear that there is much more to come in the third film and they really haven't touched their core thoughts yet.
I happen to agree with most of the posters: the core philosophy, even incomplete, is totally self-serving self-involved rubbish. Late night college freshman bullshit sessions. But I don't care. I thought it was hilarious. And beautiful. What more could I want?
I'm in the unusual position of being both a hacker and a Shakesperean actor. So I'm going to indulge myself on the subject of Shakespeare for a moment.
Shakespeare was clearly popular entertainment of the day, and not everything that dropped from his pen was Great Art. I don't mean the low, ribald comedies; I mean Pericles and Cymbeline and others.
Even his greatest works usually need to be trimmed of some fat. Shakespeare's audience understood the language natively, so his actors could speak faster than I should. His Romeo and Juliet fit into two hours; it takes me longer than that to perform a cut-down version.
And yet, I think you really need to perform Shakespeare to see why people think he's so great. It's difficult to describe, but the words just feel good on your tongue. You'd think it would be hard to memorize an hour's worth of text in a slightly foreign, sometimes over-florid language. But it usually isn't. It sticks in your mind like a good Monty Python line. You just can't get it out of your head.
I grew up despising Shakespeare because all I'd done was read it, under duress. That's the worst possible way to deal with it. It's meant to be performed. You should see it performed, not by Olivier or somebody else performing for your parents or grandparents.
And not by your high school, either, since the student plays are rarely educated enough to mean more than reading it. You need to find experts who love the plays and who will show you why they love them so much. The right community theater, or the right professional troupe, who really understands why these plays are good and aren't just repeating conventional wisdom ("Hamlet's a great play and you're going to sit down and watch me do it, dammit.")
Even better, go out and perform them yourself. It's easier than you think.
Thank you for your time if you've bothered reading this, and not modding me too far down if you don't care.
Excellent points. I have no mod points (actually, I do, but not here) but you deserve them.
I dearly hope Apple sewed up Windows rights along with Apple rights during the initial phase. Or at least set up a fairly solid "Let's roll it out for Mac and if it does X well you get Y terms when we hit the big Windows market." Otherwise, even at a million songs a week this is probably not profitable.
There's more to Java than cross-platform. In fact, with all the various versions running around, I'd say its cross-platform qualities are significantly overrated.
Java is far more important in its security and software engineering features (which are actually very closely related). I find that I'm far more productive in Java than I ever was in C++ and C. I find that's even truer for less experienced programmers. Java increases the ability of programmers to work together through better memory management, better type enforcement, exceptions, etc.
You don't really need to hear all this. At this point you either believe it or not and I'm not going to convince you.
I haven't been able to compare it to C#, which appears to offer many of the same advantages over C/C++. I think of Java in a different class from languages like Perl and PHP, which are less well-suited to teamwork, which is an important goal of mine.
So the reason for this is not because we need another browser (boy, do we not) but because Java needs a browser for use in its environment. Java is still very poor on the client side, for a host of reasons, one of which is its lack of browser integration. Applets were always a stupid idea, I'm afraid, because software distribution via applets just isn't ready and the toys are generally beneath contempt.
You need a browser as part of Java. It's the best way to view text, whether for help, mail, etc. Java has several, but none are really any good because they're not 100% compatible with the lastest rounds of HTML/HTTP/Javascript. A browser, compatible with IE and Mozilla, will help make Java a decent client environment.
I hope Apple gets its Windows version of iTunes quickly. Microsoft has a habit of making mediocre software available quickly, taking advantage of its large installed base, eliminating competition, then ceasing improvement.
People will pay for music, as they've demonstrated. Provide them a good interface and give them a reasonable deal and they'll pay. I think a lot of people find $1 per song to be a reasonable price, and iTunes is far easier to use than Kazaa/Gnutella. Most people don't want to hack, they don't want to circumvent DRM, they don't want to wait forever to download music, and they sure don't want spyware. They're happy to pay a fair price for the service.
My worry may be misplaced, because unlike other Microsoft placements, this won't be free. Even if it comes on your computer for free (and people are upgrading much more slowly than they used to, so just providing it with the OS doesn't provide the channel that it used to), you still have to sign up and pay. Microsoft is pretty good at tricking people into doing so; the service will assuredly use Passport and they can be very...insistent about signing up for a Passport account.
But a lot of people won't pay, because it's too much trouble for them. Many of those who will pay will go the extra step to get Apple's software. That is, of course, assuming that Apple gets the software out. It's claimed it for the fall, but Microsoft can probably get its software out at least that quickly and into a "service pack" for Windows.
That also assumes Microsoft intends to actually develop the software at all. Microsoft doesn't even need to develop software at this point. Many users will read the announcement and forget about Apple's take on it, because they'll assume it'll come free with their next computer.
It won't make them happy, but my basic assumption in marketing is that users are lazy. Look at the number of people whose home page is still MSN because they never bothered to get a different browser or even to change the home page to something they care about. Users will put up with a lot of crap if it means no effort. It takes a very smart company to work around that laziness.
I hope Apple can be that company, because it's the best shot I've seen at getting music to people and money to musicians I've seen yet. It's not perfect for a host of reasons (mainly due to the record studios and Clear Channel), but I think it's the right compromise today.
I haven't worked with OCAML, so I'm speaking solely from theory, and practice with other languages.
I have to admit surprise at the results, if for no other reason than that g++ presumably has many more programmer hours put into its optimzation.
I've long speculated that a functional language would one day outstrip imperative languages in performance. They offer far more opportunities for optimization. I didn't expect it to happen any time soon, since exploiting those opportunities takes time, and since functional languages attract less attention than imperative ones, I didn't expect that time to have been put in yet. I actually expected it to be a purely functional language, because of the difficulties I outlined in my original post.
I'll have to spend more time exploring the language and see how the compiler writers have actually exploited the optimization opportunities. Thanks for the pointers.
Like any drug, used occasionally, wisely, and with moderation, it can add pleasure to your life without ruining it.
I like TV when I'm frustrated; it can reset my mind when I'm spinning on some issue. I like TV when I'm ill; it takes my mind off the suffering. I like TV when I have 30 minutes to kill and there happens to be an episode of The Simpsons on.
It's a drug many, many people abuse, and I'm sure that's what you're thinking of in your post. If you're watching TV three hours a night, every night, it's clearly a drug that has begun to control you. If you're settling for the best thing on TV rather than getting on with your life, you're doing it wrong.
To paraphrase Shakespeare: "Good TV is a good familiar creature, if it be well used; exclaim no more against it."
I do wish most people would watch less TV, but I think that declaring TV in general to be a "disease" is counterproductive. Try thinking of it as a drug that too many people are addicted to.
It's usually a very bad idea to include imperative aspects in functional languages.
Functional languages are amazing creatures. They're really strange to work in. They take a serious change of mindset. They can be very slow to execute. I/O is really odd when side effects are forbidden.
They have astounding benefits, too. The localization of effect means that they're really easy to debug. The lack of side effects means that some really enormous optimizations are open, which is crucial since the naive execution is slow.
Once you throw in any imperative aspects at all, these effects go right out the window. Even a single imperative statement potentially interferes with every optimization. ("Can I eliminate this execution branch? It seems like a redundant call but it might branch to that imperative statement.")
I think that this got in the way of ML. It can be easy to want to add just a tiny imperative element to make something easier, but that small crack opened up a lot of headaches for me. I greatly preferred the purity of Haskell.
I haven't read the F# spec, so I may be overreacting from the notoriously inaccurate Slashdot summary. That's next.
It's not like anybody needs extra piracy tools. They are copious and readily available.
The difference with iTunes is that it makes obtaining music convenient, efficient, and legal. Running iTunes doesn't feel like hacking into something. It feels like buying something. And a million downloads the first week suggests that a lot of people would rather get their music without feeling dirty and without having to wade through the bad connections, dubious rippings, and intermittent availablity of a P2P network.
This site changes very little. Apple has put just enough difficulties into iTunes protocol to make it easier to buy music than steal it. Slashdot caters to the technical crowd who want to know what's possible. There's a big difference between the possible and the feasible.
I can think of only a few: System/R becoming relational databases; the language work that became LALR parsers; some of the graph-theoretic work that became the Internet.
In most cases it was a huge leap between research and the implementation that made it actually useful. Innovations in the course of a "simple matter of programming" are more often intuitive understanding that only later is justified by research, sometimes prior but unknown research.
Meantime, 99.9% of what comes out of theoretical labs is crap. That's not where I go looking for the next generation.
Look, I _am_ a theoretical computer scientist, and my job right now consists of taking a bunch of old theory work on logic programming and ontologies and making a commercial product out of it.
And because of that, every "crazy" computer guy who think's he's Galileo wants to show me his crackpot theory, and he's sure I can fill in the few blank spaces in his work. Note to such: if you think you're a crazy genius, recall that the former outnumber the latter by about 400 to 1. There are a few in both categories, but more likely you're one or the other, and I know which way I'm betting.
End of rant. Thanks for your attention.
TV...over the air...no wires! Who would have thought it was possible? This will change everything!
That is fun. Thanks.
I note that googling "google.com" yields a one-result answer: google itself (and contains, among other things, a cache of google.com).
That's the evil "bit" story, as opposed to the "evil bit" story. Same story, different judgment call. And I'm with you on that.
Probably because it's not worth the effort to publish negative results. If you hated a book, or even just disliked it, you just ignore it. It'll be lost in the vast morass of other books out there.
The exception will be books like Stephen Wolfram's A New Kind of Science, where the book has such high visibility that the Slashdot community will want to hear either way, good or bad. And it got a mixed-to-negative review, as I recall.
This isn't a book-review site, so it won't be comprehensive. To make it so, we'd have 20 times as many articles as we do now, most of them with so-so or negative reviews.
Amdahl's law is more of a "law" than Moore's law is. It's a way of figuring out how much of a speedup is really possible from parallelization. The formula is:
S=N/((B*N)+(1-B))
where S is the speedup, N is the number of processors, and B is the percentage of the program that must be serially. The upshot is that as long as B is greater than 0, you'll never get the N-times speedup you'd hope for from throwing N processors at the problem.
It seems a pretty trivial result, but it's basically Gene Amdahl's way of throwing the "multiprocessing will save us" theory back in the faces of its proponents. Multiprocessing is the obvious way to speed things up, but if it won't work on every problem, we'll have to look elsewhere.
The concept is designed only for digital content. From the site's Merchange FAQ:
Use the PepperMill to encrypt your digital goods for sale. Part of this process includes associating a price and description with each item.
Publish your encrypted content--we call these new files PepperBoxes--on your Web site. (You can also choose to email PepperBoxes to targeted customers.) Make sure to indicate on your Web site that you accept Peppercoin payments for this content.
All consumers are free to download your content in encrypted PepperBox form; however, only those who pay are allowed access to the content. When the consumer pays for the content an exchange is made--the consumer sends a "PepperCoin" for the sale price, and receives the decryption key.
Peppercoin then processes your transactions by running our patent-pending payment processing protocol. You are paid and the consumer is billed by Peppercoin.
It's remarkable that Serkis did both the (incredible) voice work and (astounding) physical performance. There will be more characters like Gollum over the years, but they're unlikely to match Serkis' incredible range. You'll have a dancer for the body, a rubber-face for the face, a voice actor for the voice, and so on. It's rare to encounter so much talent in one person.
This is a golden moment for the Academy to honor an astounding performance the likes of which we may never see again.
I can't hold it against them too much: for the most part the Academy wouldn't recognize good acting if it walked up and bit them. They too often honor "showy" acting, largely one-dimensional with huge emotional swings and featured parts, that are actually built on a combination of music, camera work, editing, and a host of other factors outside the performance itself.
I'm an actor myself, and IMHO on film you can see only a performance, not an actor. That's good: you're not supposed to be watching the acting. The hard work of acting is accomplished where you can't see it, in rehearsal rooms and in the actor's bathroom, in front of the mirror, and in long talks with fellow actors at the bar worrying about each syllable, on set finding the right tone not just for you but for everybody in a scene. All of which can be lost by different editing, direction, a music choice going the other way, or another actor taking a different choice.
I applaud Serkis' work, and I want to see if he has range as well as talent. I'm sorry the Academy chose not to honor him, and that's always going to hurt no matter how meaningless the award and no matter how thunderous the accolades from the people whose opinions really do matter.
I doubt the lack of sales tax is the only reason you buy from the Web.
Among other things, Web stores are open 24 hours a day and they have things in stock that you can't get at your local store.
Web stores operate out of warehouse space, which is far cheaper than retail space, especially if you live in a city. The employees don't have to deal with the public, so their time is spent more effectively.
Retail stores have many downsides. They have to deal with remainders (items that don't sell) more often, and have to choose carefully the tradeoff among items to stock. Most can't operate 24/7. The employees can be a real problem: if one person doesn't show up for work, long lines can develop at retail counters.
Shipping is expensive, but it's the only downside to web stores. They have many other economic advantages on their side, so they can continue to be a bit cheaper, and often more convenient. I buy things from Amazon that I could get from my local Borders, but that bookstore is a good 20 minutes away. Total round trip is 40 minutes. I'd buy it from Amazon even if it were a bit more expensive. Add the fact that it's generally cheaper, even with Amazon's economic model hiding the shipping cost in the price, and it's no contest: I spend far more at Amazon than retail bookstores.
Other stores offer things I can't get locally without much travel, from cake decorating supplies to obscure DVDs to Ebay's miscellania, and I live in a major metropolitan area.
Does it suck that I'm now paying 5% more for my stuff than I used to? Sure. Will it cut into some sales? A bit. But I doubt it's the Imminent Death of the Web.
In some ways, the problem wasn't so much "incredibly mediocre" as just "mediocre". They took no chances so they never could succeed (the series, not the characters, who took amazing risks but always, always won.)
I'm an actor myself (amateur), and for me, the best drama is always the kind that risks failure. It has to have an opportunity for people to hate it before anybody will really love it.
TOS took great risks, even in the movies. Many of them failed; many others succeeded.
When you try to please everybody, you end up pleasing nobody. The latest movie even ended up alienating my mother, who's the perfect model for their target: she's an old series fan from the first, and she's mainstream rather than sci-fi. She's exactly the type to be pleased with simply seeing her old favorites again. Nemesis offered her nothing new, so she saw it exactly once. We saw Wrath of Khan over a dozen times.
I saw each new Star Trek movie with her on Christmas day ("It's a Technicolor Christmas when you're Jewish.") She'd seen it opening weekend, and couldn't be bothered to see it again. So I never saw it.
Funny. I'm in the same boat, and there are others in the thread who said the same thing. We're Star Trek fans and we've all decided, simultaneously, to give up.
That's not necessarily the reason the movie tanked. We're not really its core audience anymore. They've been trying to make it more mainstream for some time. My guess is that the mainstream heard, "Well, if the Trekkies aren't going to see it, why should we?"
That's not the media reviews. That's their friends. I'm the biggest Trekkie of my group. If I'd gone, others would have come.
Why did we all give up simultaneously? I think it's a combination of sub-par TNG movies and the sub-par Voyager and Enterprise series. When there were only 79 episodes of TOS, you _had_ to see the movies: you'd seen everything else. You even had to see Trek V. But if you gave up after Voyager, as I did, and never got into Enterprise, you're already out of the loop. It's not that you're afraid you won't get it. It's that you no longer have that drive to see 100% of Star Trek.
I don't think that LotR at the same time was the problem. If it had been very good, or if we were all still dedicated fans, we'd have made time. We weren't spending that time watching LotR again. We were doing something else, out of the theaters entirely.
I don't believe the Trek franchise can be salvaged. Certainly not as long as Berman doesn't understand why the last one tanked. But even if he did, he's lost an awful lot of potential fan base. He might be better off starting a new series of his own.
He could turn it over to the Deep Space 9 crew instead. The series didn't develop the cult that TOS did, but it did have a devoted following. They too would have a hard time digging out of the hole the franchise has dug itself, but they've got the best chance.
If not that, then just let it rest. I loved the series, but none of the other things I love are immortal. Someday I will find something new to love; indeed, I already have. I will remember Star Trek fondly, and that means I probably won't see Nemesis until I catch it, wistfully, on DVD, and remember better days.
Nerds!
/me kisses his karma goodbye
Nerds nerds nerds!!!
Unfortunately, you can't divorce the libraries from the rest of the VM when you want to talk about what makes a great VM.
From a computational standpoint, the instruction set is just part of the Turing tar-pit. They're all the same; there's nothing you can do on one that you can't do on the other. Some are going to be oriented towards particular languages (like the Emacs bytecode for lisp, or the JVM for Java) or you can make it more general purpose.
You could, for example, translate C for the JVM. Unfortunately, it would be a singularly unpleasant translation, because C's pointers would mean you can't use any of the native types. You'd have to emulate all of memory in a big byte array.
So the question is, can you use the JVM to access the parts of the computer that aren't related to computation: the disks, the monitor, the network. I happen to really like Java's approach compared to Microsoft's, but that's largely a matter of taste.
Universality is also really important. Although the JVM has been ported to a vast array of platforms, the fact is that by putting the CLR on on Windows, it'll have vast penetration. It'll also be easier to access. If you've ever tried to actually deliver a Java-based program, you know you have to deal with either deliver a 14-megabyte runtime system or trust that you can find the correct version of Java. The JVM changes very rarely (I can recall only one real change, in the area of floating-point ops), but the libraries change all the time.
But you're probably really asking about the instruction set. It's clear from looking at the CLR that they knew the JVM, and knew what they liked and didn't like. It's a very Microsoftian approach: start with something good, add features to it that arguably make it better (but which some would argue just add bloat) and make sure it's everywhere, for free. It happened to Netscape, it happened to Stacker, and it could happen to Java.
There are some odd things in the CLR instruction set. For example, the CLR has references to native values. That's certainly convenient for some things. Just yesterday I wanted to return two values from a function, and it would have been easier if I could just pass in a reference to an integer.
But that's going to make it hard to optimize. The JVM JIT knows that if you have an int field of an object, the only way to change that value is to have access to the object. That's a huge boost to optimizer writers. If you can prove something doesn't change, you can sometimes eliminate huge swaths of code just by proving that they have no side effects.
I found a kind of odd instruction called "tail", which allows you to turn method calls into gotos. Gotos are bad for software engineering, but they're really what goes on in the chip itself. A method call, at the most fundamental level, is moving a bunch of stuff onto a stack, including a reference to get back, and executing a goto. If you can prove that you don't really need to come back (because the method call is the last thing you're going to do) you can free up your local variables. You may even be able to inline the method call, which allows you to save the goto.
(Gotos are bad at the JIT level, because they violate locality of reference. Locality of reference allows you to pre-load upcoming instructions, and maybe even start to execute them. Gotos aren't as bad for that as conditional gotos, but they still imply that you're jumping to a different block of code that you may not have cached. That can take on the order of 100 nanoseconds, which is forever given that on a modern CPU an instruction can take as little as 1 nanosecond. Even less if you take all the pipelining into account that lets you run dozens of instructions simultaneously.)
The most obvious place where the CLR stole from the JVM is in verification. I'm sure that the JVM wasn't the first VM to enforce type guarantees on the stack, but it was a completely academic issue until Java put it on every computer in the world. The CLR uses the exact same concept, except that it's more complicated because the CLR has many extra features over the JVM.
Not to mention that the CLR has an "out" designed to allow C code to be translated better than the system I described above. The upside to that is that it allows you to integrate old C programs more easily: you just recompile for the CLR and live with the fact that it's not safe anymore. On the JVM, you'd have to patch in JNI and that's a real pain in the ass. Plus it violates all the same safety guarantees, so you're just as screwed.
That screwage applies to optimization as well. C allows you to optimize memory access brilliantly, but it makes it almost impossible for a JIT to ferret out your intentions and optimize. If you can't prove that a piece of code has no side effects, you can't eliminate it. Pointers make it nearly impossible to prove the absence of side effects; any piece of code could affect the memory of any other piece of code.
So to finally get back to your question: which do I prefer? Microsoft did a great job of learning from the JVM's mistakes (or things they consider mistakes). I love the idea of Haskell for the CLR (I did a thesis on Haskell, and it's a hard langauge to love but I do anyway).
I suppose to really answer the question I'd need to know one thing I haven't had a chance to investigate yet: how fast does the CLR run? MS has always been oriented towards performance over clean engineering. But premature optimization is the root of all evil, and there are a lot of people writing angry replies to this right now castigating me for claiming that Microsoft has any interest in performance. The problem is they do: they optimize early, and we're still living with the disasters of early optimizations. Remember 8.3? That saves you a bunch of disk space on 720k diskettes. Not so good on 120 gig hard drives.
The JVM has almost 10 years worth of optimization, plus I've outlined some theoretical reasons why it should run faster in the limit case. But I don't have any performance comparisons at my fingertips.
That may not make a difference, in the end. At 4 GHz, who cares about whether a machine is 10% slower? I learned to program on a computer literally 1,000 times slower. Today's usability has a lot to do with how much you want it to do. That computer couldn't handle a single window, nor could it antialias the text. I'd be pretty pissed off to be using that computer today. But at the time it did the job. A 10% performance boost wouldn't move Swing from "unacceptable" to "acceptable", and that's mostly outside the bounds of the JVM.
I'm also curious to see how well the CLR will penetrate. Sun has fought to get the JVM on every computer. I don't think it will, even with Microsoft shipping it, because the Java library changes too often. I like the changes, love them, but I'm busily shifting code from 1.3 to 1.4, and I'll probably shift to 1.5 when it comes out, because I love the idea of polymorphic types. So it won't matter if Microsoft ships 1.4 on every system; if I use even a single 1.5 specific feature, I'm stuck delivering my own JVM. For me, that's not so bad: my current software takes up 100 megs. But my first delivered Java program was a fun crossword puzzle applet, and it takes 100K. You can't load that up with 14 megs of runtime to deliver it.
In the end, despite their vast similarities, there's really no comparison between the JVM and the CLR. The differences will be manifest not in the instruction set but with the popularity with developers and the needs of companies to distribute actual, running code to actual, running computers. That will end up being more a political decision than a technical one.
So speaking as a nominal expert, while you certainly can translate non-Java languages into bytecodes, the machine clearly isn't designed to be general-use. It has a lot of object-oriented instructions that fit the Java object model and not a lot else. You can adapt them to your language, or you can ignore them and code everything up as one big method call (except that you'll run out of space, since function size is limited, and you can't modify it once written).
I've successfully adapted languages like Prolog and Lisp, and taken advantage of Java objects to provide the continuation-like features of these languages. I've even found a couple of places where you can generate code which could not come from Java code but which is legal and verifiable (e.g. crossed loops).
I use it mostly for small projects. For example, Ontology Works generates Java APIs for its custom database description languages. It generates the bytecodes directly, since the APIs are too large to be conveniently compiled from Java. But that's not a general-purpose language, so the code is actually fairly simple.
I've only glanced at CLI, but it appears to be somewhat more general purpose than JVM bytecodes. (In the end it's all Turing tar pit.) However, CLI a bit more heavily oriented towards calling out to native code, which makes the code less portable and harder to optimize. The JVM also supports native methods, but they receive a lot less encouragement.
Mostly, I'm a huge fan of the way JVM does verification. It's brilliant that you can restrict code to safe code and still be Turing complete by eliminating a large class of safe-but-invalid instruction sequences. You can make huge optimizations to verified code that you can't make to generalized code. Verification also allows much more fine-grained authorization than the Microsoft way, which is all based on signed code.
You always want to choose the best language for the job. C/C++/Java are largely identical, and I think in general a group should pick one and stick to it. But there are languages (Lisp, Prolog, Haskell) which are genuinely different, and I consider it a good thing that you can write compilers for them. That has yet to completely fulfill its promise on the JVM platform, where there are proofs of the concept but they are little used.