It isn't a pro-level tool by any stretch yet (five days of intraday data isn't much), but the way it automatically tracks what you've been doing (go back to the home page after searching for some stocks and see how it changes) is quite useful. And Google searches to find stock tickers - clearly it's tuned for that. E.g., "ms" gets you Morgan Stanley, not multiple sclerosis. Though doing a search for "ms" on Google's main page, Google Finance comes up at the top of the list.
Why is Disney's market cap $50b ($49.513b as I write this) and Pixar's $7.4b (market price $6.9b - clearly some people cashed out last night)? But Pixar made $300m more in gross receipts?
That's easy - Disney has 15 major subsidiaries, including ABC, ESPN, their live-action studios, the theme parks (yay, Disney World!), video games, mobile phone, and merchandising. The Mouse is much more than its cartoons.
Re:What about Pixar's Software Arm?
on
Pixar For Sale?
·
· Score: 2, Interesting
I haven't read Howard's announcement in detail yet, but my first impression is pretty good. Several years ago, I worked for Sony Corporation of America (for a while there, Howard was my boss's boss). Getting the different operating companies to work together for the good of the larger corporation was extremely difficult. Management for each operating company was compensated based on the performance of that individual operating company. Music execs got paid well when they sold lots of music. This went down to a fairly fine grain - Sony Classical was extremely happy to have the soundtrack to "Titanic" on their label. There was no motivation for the music company to do something to benefit the electronics company, and vice-versa. The Playstation company was making so much money, they went off and did their own thing entirely.
Eliminating the barriers between the operating companies will be a painful transition, but all in all, probably a good thing.
I'm not particularly in favor of eliminating jobs, though 7% over half a year isn't much - most of that is probably natural attrition. When Sony cut jobs while I was there, it was all attrition, and I think it was 4 or 5%.
The market doesn't seem to like it - Sony is down about 100 yen against a share price of 4000ish since the announcement, but the market may have been expecting something more dramatic. Anyway, my initial $0.02.... ObDisclaimer - I haven't worked there for years, I don't consult for them, and I don't own their stock.
Of course you can teach polymorphism first.
I'm just not (yet) convinced it is a good idea.
It wasn't an "of course" ten years ago, when I was first working on the curriculum.....
The problem is that algorithms are all about
loops, conditionals, and arithmetic. The
other stuff is completely orthogonal.
I'd disagree. An algorithm works hand-in-hand with a data structure. A sorting algorithm works in a given run-time because of the nature of the operations allowed on the data structure it operates on. This is obvious when you compare, e.g., insertion sort on an array versus insertion sort on a linked list. The red-black tree algorithm for balanced trees is useless without the data structure that allows for "coloring" the nodes of a tree.
Algorithms are behavior. Data structures are data. What is an object? Behavior and data tied together. If they are inextricably related (like the red-black tree algorithm and the colorable tree nodes), work on them together, rather than trying to create artificial separations between them. That's just good software engineering.
You might
not agree about which is more important,
but it turns out that students really lack
basic algorithmic thinking when they are
immersed in OO first.
They might lack an understanding of the deeply nested flow of control sometimes found in procedural or structural designs. But that isn't the same as not understanding complex systems - some ostensibly complex algorithms are in fact easier to understand and formulate in an object-oriented framework. For example, 2-3-4 trees are easy to implement in an object-oriented framework, much easier than the red-black trees that were invented because 2-3-4 trees were so "hard".
No, the students that have seen OOP from the beginning understand just as much. They're simply used to framing that complexity in different terms and organizing it in different ways from the class von-Neumann-driven separation of behavior and data. Faculty may not always realized that, because they may have been using a strict separation of data and behavior for much much longer.
The theory people think
they don't understand algorithms. The systems
people think they don't understand computers.
I'd suggest that the theory people and the systems people in question don't understand what it is the students do understand. That was the kind of knee-jerk responses we got at Brown, until the theory people realized that the students did understand complex systems, but just organized them in different ways - that's part of the faculty retraining I alluded to. At Brown, it was a success, and led to algorithms textbooks written from an OOP perspective (written by faculty members that were originally some of the strongest critics of the OOP approach to the curriculum). The systems people at Brown were all very OOP in mindset - they were ecstatic with the new approach and the students they got.
Of course. But I'm not talking about grads. I'm talking about students choosing courses.
Every hotshot college grad learns very quickly that the "practical" skills you learn in school are worth squat.
They may learn this once they're out of school - I was talking about the dynamics of students choosing courses, and how that affects an academic department's thinking.
Which is why I always prefer to see a solid courseload in fundamentals and theory. Then I know I've got someone who can think, design, do research, and (depending on the project) get up to speed fast. Code monkeys are a dime a dozen.
Maybe you aren't posting all the job listings with catalogs of acronyms in them, but someone is. Students read them and come to the reasonable conclusion that they need to know about those acronyms in order to obtain the best job opportunities. I'm not saying it's a good thing. I'm just explaining the phenomenon as someone that saw it - students didn't care if Java was pedagogically the best language or not. They wanted to learn Java because that's what employers wanted. The department could meet that demand and increase its enrollment or ignore it and reduce its enrollment.
If students don't take the course, enrollment drops, and the university cuts funding to the department (as funding is based in part on enrollment in the department's classes).
Students still demand courses that look good on resumes. Students still demand courses that are enjoyable and interesting. The faculty has a responsibility to teach the "right" material, but simple Darwinian survival of the department means that the faculty must teach that material in a way that gets butts into seats.
One way to keep butts out of seats is to teach boring and drab stuff, stuff that the students will find irrelevant at the time (even if the faculty knows it isn't irrelevant). RS-232 is not terribly exciting in a world of USB and Firewire, even if the principles are the same.
But if the students aren't learning that the principles of serial interfaces are the same no matter what the bandwidth or connector or acronym, whose fault is that?
Back in the day, in the early 90's, I was largely responsible/to blame for switching Brown University's undergraduate first semester programming course to object-oriented programming. It had been teaching structured programming, but industry at that time was following object-oriented design precepts (even if using languages like C). The faculty all firmly believed in OOP, and taught it in all upper-level courses. But it was seen as "too advanced" for beginning students.
As it turned out, the real problem was not teaching OOP to the students. OOP is easier to explain to new programmers than structured programming (people use real-world objects all the time - not so much real-world procedures). Half-way through the first semester, the students could implement Tetris.
The real problem was retraining the faculty. Even though they knew OOP was a good thing, it took them a while before they had internalized OOP enough to present, e.g., algorithms and data structures in an object-oriented style. No one believed that you could teach inheritance and polymorphism before you taught loops, conditionals, and arithmetic.
Faculty teaching the intro courses may be in touch with industry and research. That's not enough. The faculty need to rethink an entire course to present the right academic material in a modern, industry-relevant way. If the faculty can do that (and, make no mistake, it isn't easy), they you'll get a course the students love, that will get them a job, and that will prepare them for a strong academic program as well.
For the truly curious, the textbook for that course is actually still in print, even though it depended on Borland Pascal, which is long-since defunct.
Back in the day (circa 1990), when I was a lowly undergrad, my final team project in the graphics course was a program that would let you paint an image on the surface of a 3D object. I.e., there was a window with a 3D object in it, you'd drag the mouse around like you were using a paint program, the software would figure out what the texture map would be to make the 3D object look that way. Change the camera position, keep painting on a different side of the object. A different implementation got written up at SIGGRAPH that year - we were bummed, almost as much as our professor, who wanted to add another pub to his CV..... This was a big deal at the time, as pattern-mapping hardware was then the province of $100k super-computers - lucky us, we had access to one (yeah, it did a blazing 100k tris per sec (it also scan converted spheres)).
A grad student whose claim to fame was having the moderator of alt.sex.stories forget to remove the student's name on a posting came up with our project name: Whip Me.
We Handle Interactive Pattern Mapping Efficiently.
(and for the sexist-humor-impaired, apologies....)
A lawyer, an accountant, and an engineer all go into the men's room (they're all guys, duh:-( ).
The lawyer does his business, then washes his hands, then completely dries his hands with a truly profligate amount of paper towels.
"Lawyers are trained to be thorough," he explains.
The accountant does his business, then washes his hands. But he uses a minimal amount of paper towel, while making sure his hands are as completely dry as the lawyer's.
"Accountants are trained to be thorough and efficient!" he explains.
The engineer does his business, and walks out without washing his hands!
Flabbergasted, the lawyer and the accountant demand an explanation.
There's absolutely no need for a display system like X to allow multiple application threads to concurrently recieve events and/or update the application's display.
First, you should restrict such broad generalizations to an X client in order to be even remotely correct. The X Server doesn't know anything about the process or thread structure of its clients. The clients may not even be on the same machine. The X Server gets a socket connection and responds to messages on that socket. If something is sending good messages down that socket, the X Server doesn't care if the something is one process, ten threads, or ten million threads.
Go look at KParts - KDE embedding. One window, one application, as far as the user is concerned, but subwindows are controlled possibly by different processes on different machines.
How do you think window managers work? The X server doesn't know from window managers - the way you prevent multiple window managers is by checking for atoms on the root window. Remember, conceptually any client of a server can do something with any window - you just need a way to get the window ID.
It would just add unnesessary complexity, making it harder to debug and maintain.
Wrong. The X server already handles multiple simultaneous connections. Whether the X client does or not is the client's choice. Lots of clients for other systems handle multiple connections (your web browser, for one).
Also, having a single GUI thread is a good design pattern.
Um, add the hedge for some applications and I'll agree with you. Otherwise you're wedged in a one-track design mind. You're making your problem fit your design, rather than your design fit your problem.
There's any number of interactive applications that make lots of logical sense to be multi-threaded. Take your typical movie player with its nifty visual feedback. One thread for putting the frames up. One thread to respond to user actions.
The richer your interaction, the more application semantics are involved, the more likely that arbitrarily splitting the app in half along an arbitrary "UI/App" line is just not going to work. MVC has a similar problem. They're both cookie-cutter designs that pretend that every interactive app is structured the same way at the top level.
All GUI work is handled by one thead, all application logic is (potentially) handled by other threads. The delineation between the application's UI and logic makes it much easier to maintain.
Go read papers on the "eXene" system in the programming language "ML". A pervasively multi-threaded X client library. One widget - one thread. It makes the widget code very easy to understand - you don't have to split your code into a bazillion little callbacks. You don't have to arbitrarily time-slice things that are conceptually continuous. Things like while (buttonIsDown) followTheMouse() work just fine. Ever have to break up a callback into multiple functions, triggered by timers, just so the app didn't appear to "freeze" while you were off doing something time-intensive? Multi-threading interaction can make the code much easier to maintain because you don't have to worry about "starving" parts of the application for events while busy working on others - the thread scheduler handles pre-emption for you.
And eXene isn't some hot new thing. It dates from the early 90's.
Go back even earlier and find some of James "Java" Gosling's earliest work - NeWS. NeWS clients wrote multi-threaded PostScript to draw on the display.
Events, timer callbacks and the like are all just ways of simulating something continuous with discrete code - go look at TBAG from Sun and then the follow-on Fran from Microsoft Research. Forcing discretizations of continuous phenomena into an arbitrary serialization is just a way to kludge around a poor understanding of parallel activity.
So yeah, blackcoot shouldn't complain that X is broken, I'd say whatever app {s}he is writing needs to get fixed.
It isn't the app - it's the libraries the app is trying to use. They're a poor fit to the abstraction blackcoot would like to use.
There's no spell checker, like OmniWeb and Mail use,
What, to spell-check what you put in web forms? To me, that's a relatively minor feature, but then I'm a gud speler:-) You can add that with WordService (lots of text goodies that appear in the Services menu). Should be pretty easy for Apple to turn it on themselves in the Edit menu.
and it doesn't remember passwords like Chimera and Mozilla do.
but I'll bet it will by FCS. Chimera at least does it by putting the passwords in the user's Keychain. Try running/Applications/Utilities/Keychain Access and you'll see all your web passwords there. Since that's also where your iTools password goes and whatnot, I'd expect somewhere Safari already talks to the Keychain.
Oh that's easy. Some whack-jobs dropped a couple of planes on these tall buildings here and not even the trains were running..... And there's still soldiers with machine guns hanging around all the bridges. I'm not rich enough to own a helicopter for getting off this island, but if anyone actually invests enough money for the Land Shark to get built at the price claimed, it might be an option.
ObLizard: For anyone that's forgotten, this whole rant back and forth between me and "swillden" got started on the basis of one scientist's characterization of a female lizard as "having her cake and eating it too." A scientist getting good press with a sound bite that played up to stereotypes of sexual and marital behavior.
I criticized the stereotypes as exactly that - stereotypes.
First, I'm not talking about "right" or "wrong" (I could, and I have definite views on that, but I haven't mentioned them and I'm not going there now). I'm just talking about what creates a good life.
Do you realize how disingenuous you're being here?
You claim you're not talking about "right" and "wrong", and in the next sentence you claim to only be "talking about what creates a good life."
It's well-documented that monogamous, married people tend to live longer and be happier and more sexually satisfied than single people. Sounds like a situation to be recommended, doesn't it? Yet you seem to think it should be deprecated, that it's cruel to suggest it as a goal.
Do you actually read what I write?
I started this sub-thread by criticising stereotypes - I called them stereotypes from the beginning. Stereotypes are, by definition, overbroad - a stereotype may be accurate for a particular example but does not hold for all examples that the stereotype claims to describe. That's what makes it a stereotype.
The particular stereotype you claim marks me as a bitter cynic hopelessly scarred by a (presumed) failed marriage was that getting married necessarily led to life-long romance fairy-tale style: "Happily Ever After". As if a one-day event solved all problems for the rest of your life.
It doesn't - you know it doesn't, and have said as much yourself by talking about how much effort it is to actually make a marriage work. I agreed that it takes effort to make a marriage work.
You assumed that I was condemning all marriages on the basis of my own (again, assumed by you) ostensibly failed marriage. I'm not.
I'm criticising the fairy-tale expectation that marriage makes everything better - quoting life expectancy statistics supports the expectation that marriage makes your life better. I don't deny that marriage can make life better for some people. But, as you pointed out yourself, it takes work - it is hardly the magic panacea that fairy tales make it out to be.
I'm not judging, criticizing or condemning you or your lifestyle, so cool down.
You're being disingenuous. Again.
If you aren't criticizing me or my supposed lifestyle (even though you admitted you know nothing about it), why do you keep bringing up my supposedly failed marriage as the supposed source for my (according to you) bitter, harmful, and dangerous attitudes destined to scar all the poor little tender ears of younger/.ers, forever turning them from the ideals of marriage as you conceive it?
Have the courage of your convictions. If you frown on me or my life, say so. Don't feed me a placating line about how you aren't, smack in the middle of a diatribe aimed squarely at what you assume about my life.
it's inaccurate in the extreme to say that the stereotype of monogamous marriage producing happy lives is ridiculous.
You're misquoting and misconstruing to serve your own (quite evident) agenda in support of traditional monogamous marriage as the best and only solution available. I said marriage wasn't a "poof-Happy-Ever-After" kind of affair - it takes work. You agreed. But you went on and implied, repeatedly, that anybody that didn't make a marriage work out simply didn't work hard enough or didn't expect it to work.
That's the attitude I see as more harmful.
I prefer a more open-minded and tolerant approach that recognizes that monogamous, til-death marriage may not be right for everyone. Don't tell kids "Our way or the highway!" Give them the information to make their own choice.
Or do you really prefer to NewSpeak people into being unable to even conceive of anything besides what you think is best?
Really, if we stay on-topic for the original post, what this boils down to is a matter of the scientist who made the original quote. I think he was cold-bloodedly playing off of stereotypes to make a good sound bite for a press release. That's not good science. That's good marketing.
If that wasn't what the scientist was doing, please, tell me, what was he doing?
I could tear this reply apart point by point, but it's clear we're arguing from a different set of axioms.
You're assuming that a traditional monogamous marriage is the right thing - by your lights, no matter how much work you put into, it's worth it, because it is the right thing. (Now who's got a self-fulfilling prophesy?)
I'm not saying it's wrong. I'm only saying that there are other possibilities. You yourself cite the LDS - famous for supporting non-monogamous marriages until Utah was admitted as a state.
You keep saying that for me, it's just personal. You admit you know jack about my personal life and situation. Take the blinders off and accept the possibility that what works for you may not work for everyone else. That doesn't mean there's anything wrong with you or with anyone else. It just means that different individuals have different needs.
So you believe life-long romance and living happily every after are ridiculous?
Not ridiculous - just unlikely. And more and more unlikely as life expectancies continue to increase. Requiring something unlikely as the only acceptable solution seems, at best, poorly thought out.
Or just that the stereotype is ridiculous?
Oh, the stereotype is certainly ridiculous. Anybody that thinks that once marriage is reached everyone lives Happily Ever After has not actully tried to make a committed long term relationship really work. As they say, BTDT.
Personally, I see enough examples of the former that it seems like a fairly reasonable stereotype to me.
To which "former" do you refer? It sounds like you mean "life-long romance and happily ever after are ridiculous" but judging by your categorization of me as a cynic, that isn't quite what you meant....
The terrible thing about cynicism like yours
I'd be a bit more careful about judging someone a cynic based on one/. post. Or did you actually go to my website and learn about me and my life to know the data from which I'm drawing conclusions? Or (more likely, from your unclear antecedents in referring to "former" statements) did you just leap to an ill-informed conclusion?
is that it is a self-fulfilling prophecy. If you don't believe that a long-term, loving, stable and happy relationship is possible, you'll never do what it takes to have one.
I didn't say that I thought a "long-term, loving, stable and happy relationship" was not possible. I do think it is possible, but I also think it is difficult to acheive in practice and not necessarily the right goal for every human being.
Now, putting aside what I think, let's look again at what I said (which is not in fact what you seem to think it is). I said that the stereotype of "marriage as life-long romance for Happily Ever After" was "ridiculous and inaccurate." Statistically, approximately 50% of (American) marriages end in divorce. From personal experience, a non-trivial percent of the 50% that don't end up in divorce end up in loveless inertia. That doesn't sound like "life-long romance" to me.
My point, though, was that the original scientist who produced the quote was simultaneously agog at behavior in this lizard species that is well-documented in a variety of other species and apparently offended that this lizard species wasn't living up to the ideals of monogamous marriage. That's what the scientist seemed to be implying with his analogy of a "woman who has her cake and eats it too."
Now on this stereotype of marriage as the end goal of romance, I think it's a particularly damaging expectation to place on people. It burdens them with unrealistic expectations. Expecting young couples to meet an ideal that most people never manage, and telling them that there is no other acceptable solution is hurtful and sets these couples up for a lifetime of suppressed emotions, deceitfulness with the person to whom they ostensibly are most committed, and never-ending feelings of inadequacy. You found someone besides your spouse attractive? Burn in HELL!
Does that really sound like a way to promote love and happiness?
This is the ultimate example of a female having her cake and eating it too...It would be like a human female who marries a short, dumpy rich guy and then has an affair with a muscular 20-year-old to have a handsome son who grows up in a mansion and goes to the best schools."
A cool article, but that author spent entirely too much time thinging about that analogy.
Watch the quote marks - the scientist spent too much time thinking up the analogy. The CNN science reporter had the good sense to pull the sound-bite and put it nice and early in the article.
Me, I'd point out that the incredulous tone of the scientist is just a bit too pandering to believe. It feeds right into multiple contradictory stereotypes - the gold-digging slut trophy wife is one, as is the equally ridiculuous and inaccurate (but more socially acceptable) stereotype of marriage as life-long romance for Happily Ever After.
Lots of animals have exhibited comparable behavior, on both sides of the gender divide. You don't have to go down to obscure lizard species and you don't have to write it off to human perversion/idiocy/unnaturalness. Chimps and bonobos do this. Gorillas do this. Wolves and lions do this. Both genders in a variety of species try to gather exclusive groups of mates under their own control, and both genders "sneak around" outside these ostensibly socially sanctioned constructions.
In the interest of not selling us a "pig in a poke,"
why not let users see their own usage statistics? Before they risk their money with PayPal? Even a simple "You view X pages a month/week/day" would be helpful for people to know how much they're going to have to dish out.
Well, when I used to work for this "modest" media and electronics company, I got to go to Tokyo quite a bit - I was corporate. I got along fine in Akihabara. I speak no Japanese.
Okay, a little - I can call Tokyo, identify myself, and ask to speak to someone. Usually, I manage to get the accent decent enough that the respondent starts explaining (I presume) why this person can't come to the phone. That's when I say "Nihon go ga wakari masen" - I don't speak Japanese.
The prices seemed reaosnable, though not spectacular - from other comments, I gather you're expected to bargain. Being a foolish gaijin, I didn't realize this. As I was mostly interested in buying things that weren't sold in the States anyway, this doesn't bother me too much. I may have paid more than a native for the metallic orange camouflage MD Walkman, but it was still less than the equivalent functionality model in the States (even at the employee store). So I got a completely wack-looking MD player. Groovy, Bay-bee!
I didn't have too much problem asking after products. The staff will usually show you the register numbers when you look at them blankly after they've stated the total in Japanese. Just stick to the "protocol" of placing your money or credit card on the little tray they'll hand you with a printed receipt. They'll pick up the tray, make change or run the charge, and place the results back on the tray in front of you.
Oh, and one helpful bit of vocabulary: "Sumimasen...." usually said with a long drawn out final syllable - Sumimaseeen - and remember all the vowels are "short" and "pure" - not the dipthongs of English (One woman I was with had a strong Southern accent - she couldn't get passer-bys to understand that "Carry-Oh-Key" was "karaoke"). I'm given to understand that it translates literally as something along the lines of "I'm so very sorry to interrupt you in the midst of your important work, but....." Works wonders - staff on the other side of the shop will rush over. Even in the restaurants of "Little Tokyo" here in the East Village in New York.
Oh, and take a card from your hotel - it will have a map on the back showing where it is. Taxi drivers will need that. If you're staying with friends, ask them what train station is closest (this will also be on the hotel card map). If you can, memorize the kanji for that train station. Then you can get home, even on the subway, which doesn't have Roman lettering (but the JR train does, so it's not so difficult).
The one I saw, intended for eventual use in cell phones, was basically what looked like a sandwich of plexiglass and some spongy material. Two wires ran off from the sponge to connect to the contacts for a small fan. You'd take a bottle of methanol, squirt it on the sponge, and the fan would start to spin, slowly at first, and building up in speed as the cell heated up to optimum temperature (which I think was around 50-60 degrees celsius).
Cell phones make a good first application for this kind of technology (as opposed to cars) because the price/performance ratio is high (cell phones are expensive for the amount of power they use) and the performance/weight is relatively low (you don't need a really big stack to drive cell phone). If the fuel-cell cell phone (or even just a widget to replace the battery) costs ten times as much, but lasts ten times as long, is fully "rechargeable" with a one-minute application of methanol (which could come in sealed, disposable plastic tubes, or you could fill it the same way you fill a butane lighter), and has no "memory" problems, then you've got a real winner. People will pay $1000 for a cell phone (they did when the StarTAC first came out).
A car that costs ten times as much doesn't work, because that puts even a cheapie car into six figures. You have to get the price-performance ratio of fuel cells way way down before they become useful for cars. However, for cars, methanol distribution may not be a big problem - some researchers are working on gasoline-driven fuel cells. Not as clean as methanol (which exhausts CO_2 and H_2O), but cleaner than combustion, and the distribution infrastructure is already in place. There's still a price/performance problem, because gasoline-powered fuel cells effectively have a full chemistry lab built in, with three or four stages to go through before the actual power production. They also operate at much higher temperatures.
Direct Methanol Fuel Cells are nifty because they're solid-state. A catalyst (platinum, I think) drives the methanol/oxygen -> power/water/carbon dioxide reaction. They do have problems with supporting rapid changes in electrical draw, however. Typically this is handled by putting them in series with a capacitor. The capacitor can soak up rapid increases in demand, while the cell itself adjusts.
Hear me drool, but the prospect of MacOS X-native KDE applications is just too nice. Now, why do I post this comment here, instead of in the "Qt on MacOS X" thread? Quite simply, the prospect of Objective-C and/or Java bindings for KDE.
Don't get me wrong - I'm no great fan of ObjC (anything that pretends to be a "modern" language and relies on reference counting for "garbage collection is, well, that's a whole nother thread of its own) or Java (better than a poke in the eye with a sharp stick, but it likes monolithic hierarchies too much for its own good). But what strikes me is the prospect of Cocoa applications that make use of KDE "applications" as components. Yowza! Need a calculator in your app? Drop in KDEcalc.
Where's KDEmacs when you need it?:-)
(and before people start screaming about how both Cocoa and KDE would like to control the main event loop, I'll just say "threads" and shut up).
I happen to think that Haskell is one of the semantically cleanest languages out there (I put Self in the same category).
I mean really, in Haskell, "factorial" looks like this:
fact 0 = 1
fact n = n * fact (n - 1)
Write that, and "fact 20" works just fine:
Examples> fact 20
2432902008176640000
Examples>
However, implementing Haskell (or Self) on a von Neumann architecture is non-trivial. Implementing an efficient compiler or interpreter is tres difficil. People get Ph. D. dissertations for that sort of thing. For someone deeply used to C, Haskell and Self are perverse.
To wit:
In Haskell, nothing changes. Ever. State change is handled by creating a new state from the old one. Semantically clean, but about as far from C as you can get.
In Self, anything can change at any time. Yes, Virginia, you can redefine "if-then" whenever you feel like it. Change the inheritance hierarchy? No problem! Whoops! I made a cycle in the inheritance hierarchy! No problem! (yes, A can inherit from B and B can inherit from A). Think of C without the reliability that any particular operation (function call, operator, whatever) maps to the same place more than once. This kind of thing gives most C-family compilers hives. It used to be that C++ was perceived as significantly slower than C - I don't see anyone complaining about it anymore, but Haskell and Self are more extreme examples. C++ made it easy to use jump tables. Haskell makes it easy to use recursion, lazy evaluation, and a bunch of other things. Self makes it easy to use dynamic inheritance, multiple inheritance, even cyclical inheritance.
What is most impressive about these kinds of languages is that you can build efficient implementations, without the compromises to the semantics that C (or its derivatives) entails. The fastest FFT library out there is in C, but the C code itself was generated by Haskell code (code that came up with some original optimizations along the way). The Self compiler is the root technology for Java JIT compilers (when Sun killed the Self project, all the compiler people went to work on "virtual machine" compilers). Self was able to hit 50% of the speed of optimized C while maintaining:
Full source-level debugging
Garbage collection
Checks for stack and integer overflow
and the ability to change the "class" of any object at any time (I put class in quotes because Self is an object-oriented language without classes - part of the super-simple semantics)..
In short, there isn't anything wrong with clean linguistic semantics. But essentially every computer sold today is built around the von Neumann architecture, and non-von-Neumann semantics (like that used by Self and Haskell) are non-trivial to implement.
Slashdot Mirror
It isn't a pro-level tool by any stretch yet (five days of intraday data isn't much), but the way it automatically tracks what you've been doing (go back to the home page after searching for some stocks and see how it changes) is quite useful. And Google searches to find stock tickers - clearly it's tuned for that. E.g., "ms" gets you Morgan Stanley, not multiple sclerosis. Though doing a search for "ms" on Google's main page, Google Finance comes up at the top of the list.
Don't forget Ed Catmull taking over management of the animation studios.
Why is Disney's market cap $50b ($49.513b as I write this) and Pixar's $7.4b (market price $6.9b - clearly some people cashed out last night)? But Pixar made $300m more in gross receipts?
That's easy - Disney has 15 major subsidiaries, including ABC, ESPN, their live-action studios, the theme parks (yay, Disney World!), video games, mobile phone, and merchandising. The Mouse is much more than its cartoons.
Sell Renderman to Apple?
I haven't read Howard's announcement in detail yet, but my first impression is pretty good. Several years ago, I worked for Sony Corporation of America (for a while there, Howard was my boss's boss). Getting the different operating companies to work together for the good of the larger corporation was extremely difficult. Management for each operating company was compensated based on the performance of that individual operating company. Music execs got paid well when they sold lots of music. This went down to a fairly fine grain - Sony Classical was extremely happy to have the soundtrack to "Titanic" on their label. There was no motivation for the music company to do something to benefit the electronics company, and vice-versa. The Playstation company was making so much money, they went off and did their own thing entirely.
Eliminating the barriers between the operating companies will be a painful transition, but all in all, probably a good thing.
I'm not particularly in favor of eliminating jobs, though 7% over half a year isn't much - most of that is probably natural attrition. When Sony cut jobs while I was there, it was all attrition, and I think it was 4 or 5%.
The market doesn't seem to like it - Sony is down about 100 yen against a share price of 4000ish since the announcement, but the market may have been expecting something more dramatic. Anyway, my initial $0.02.... ObDisclaimer - I haven't worked there for years, I don't consult for them, and I don't own their stock.
When I couldn't get a dial tone after September 11th, 2001 (I lived a mile from Ground Zero at the time), Speakeasy still had service.
Algorithms are behavior. Data structures are data. What is an object? Behavior and data tied together. If they are inextricably related (like the red-black tree algorithm and the colorable tree nodes), work on them together, rather than trying to create artificial separations between them. That's just good software engineering.
They might lack an understanding of the deeply nested flow of control sometimes found in procedural or structural designs. But that isn't the same as not understanding complex systems - some ostensibly complex algorithms are in fact easier to understand and formulate in an object-oriented framework. For example, 2-3-4 trees are easy to implement in an object-oriented framework, much easier than the red-black trees that were invented because 2-3-4 trees were so "hard".No, the students that have seen OOP from the beginning understand just as much. They're simply used to framing that complexity in different terms and organizing it in different ways from the class von-Neumann-driven separation of behavior and data. Faculty may not always realized that, because they may have been using a strict separation of data and behavior for much much longer.
I'd suggest that the theory people and the systems people in question don't understand what it is the students do understand. That was the kind of knee-jerk responses we got at Brown, until the theory people realized that the students did understand complex systems, but just organized them in different ways - that's part of the faculty retraining I alluded to. At Brown, it was a success, and led to algorithms textbooks written from an OOP perspective (written by faculty members that were originally some of the strongest critics of the OOP approach to the curriculum). The systems people at Brown were all very OOP in mindset - they were ecstatic with the new approach and the students they got.Students still demand courses that look good on resumes. Students still demand courses that are enjoyable and interesting. The faculty has a responsibility to teach the "right" material, but simple Darwinian survival of the department means that the faculty must teach that material in a way that gets butts into seats. One way to keep butts out of seats is to teach boring and drab stuff, stuff that the students will find irrelevant at the time (even if the faculty knows it isn't irrelevant). RS-232 is not terribly exciting in a world of USB and Firewire, even if the principles are the same.
But if the students aren't learning that the principles of serial interfaces are the same no matter what the bandwidth or connector or acronym, whose fault is that?
As it turned out, the real problem was not teaching OOP to the students. OOP is easier to explain to new programmers than structured programming (people use real-world objects all the time - not so much real-world procedures). Half-way through the first semester, the students could implement Tetris.
The real problem was retraining the faculty. Even though they knew OOP was a good thing, it took them a while before they had internalized OOP enough to present, e.g., algorithms and data structures in an object-oriented style. No one believed that you could teach inheritance and polymorphism before you taught loops, conditionals, and arithmetic.
Faculty teaching the intro courses may be in touch with industry and research. That's not enough. The faculty need to rethink an entire course to present the right academic material in a modern, industry-relevant way. If the faculty can do that (and, make no mistake, it isn't easy), they you'll get a course the students love, that will get them a job, and that will prepare them for a strong academic program as well.
For the truly curious, the textbook for that course is actually still in print, even though it depended on Borland Pascal, which is long-since defunct.
A grad student whose claim to fame was having the moderator of alt.sex.stories forget to remove the student's name on a posting came up with our project name: Whip Me.
We Handle Interactive Pattern Mapping Efficiently.
(and for the sexist-humor-impaired, apologies....)
A lawyer, an accountant, and an engineer all go into the men's room (they're all guys, duh :-( ).
The lawyer does his business, then washes his hands, then completely dries his hands with a truly profligate amount of paper towels.
"Lawyers are trained to be thorough," he explains.
The accountant does his business, then washes his hands. But he uses a minimal amount of paper towel, while making sure his hands are as completely dry as the lawyer's.
"Accountants are trained to be thorough and efficient!" he explains.
The engineer does his business, and walks out without washing his hands!
Flabbergasted, the lawyer and the accountant demand an explanation.
"Engineers don't pee on their hands."
Go look at KParts - KDE embedding. One window, one application, as far as the user is concerned, but subwindows are controlled possibly by different processes on different machines.
How do you think window managers work? The X server doesn't know from window managers - the way you prevent multiple window managers is by checking for atoms on the root window. Remember, conceptually any client of a server can do something with any window - you just need a way to get the window ID.
Wrong. The X server already handles multiple simultaneous connections. Whether the X client does or not is the client's choice. Lots of clients for other systems handle multiple connections (your web browser, for one). Um, add the hedge for some applications and I'll agree with you. Otherwise you're wedged in a one-track design mind. You're making your problem fit your design, rather than your design fit your problem. There's any number of interactive applications that make lots of logical sense to be multi-threaded. Take your typical movie player with its nifty visual feedback. One thread for putting the frames up. One thread to respond to user actions.The richer your interaction, the more application semantics are involved, the more likely that arbitrarily splitting the app in half along an arbitrary "UI/App" line is just not going to work. MVC has a similar problem. They're both cookie-cutter designs that pretend that every interactive app is structured the same way at the top level.
Go read papers on the "eXene" system in the programming language "ML". A pervasively multi-threaded X client library. One widget - one thread. It makes the widget code very easy to understand - you don't have to split your code into a bazillion little callbacks. You don't have to arbitrarily time-slice things that are conceptually continuous. Things like while (buttonIsDown) followTheMouse() work just fine. Ever have to break up a callback into multiple functions, triggered by timers, just so the app didn't appear to "freeze" while you were off doing something time-intensive? Multi-threading interaction can make the code much easier to maintain because you don't have to worry about "starving" parts of the application for events while busy working on others - the thread scheduler handles pre-emption for you.And eXene isn't some hot new thing. It dates from the early 90's.
Go back even earlier and find some of James "Java" Gosling's earliest work - NeWS. NeWS clients wrote multi-threaded PostScript to draw on the display.
Events, timer callbacks and the like are all just ways of simulating something continuous with discrete code - go look at TBAG from Sun and then the follow-on Fran from Microsoft Research. Forcing discretizations of continuous phenomena into an arbitrary serialization is just a way to kludge around a poor understanding of parallel activity.
It isn't the app - it's the libraries the app is trying to use. They're a poor fit to the abstraction blackcoot would like to use.Oh that's easy. Some whack-jobs dropped a couple of planes on these tall buildings here and not even the trains were running..... And there's still soldiers with machine guns hanging around all the bridges. I'm not rich enough to own a helicopter for getting off this island, but if anyone actually invests enough money for the Land Shark to get built at the price claimed, it might be an option.
You claim you're not talking about "right" and "wrong", and in the next sentence you claim to only be "talking about what creates a good life."
Do you actually read what I write?I started this sub-thread by criticising stereotypes - I called them stereotypes from the beginning. Stereotypes are, by definition, overbroad - a stereotype may be accurate for a particular example but does not hold for all examples that the stereotype claims to describe. That's what makes it a stereotype.
The particular stereotype you claim marks me as a bitter cynic hopelessly scarred by a (presumed) failed marriage was that getting married necessarily led to life-long romance fairy-tale style: "Happily Ever After". As if a one-day event solved all problems for the rest of your life.
It doesn't - you know it doesn't, and have said as much yourself by talking about how much effort it is to actually make a marriage work. I agreed that it takes effort to make a marriage work.
You assumed that I was condemning all marriages on the basis of my own (again, assumed by you) ostensibly failed marriage. I'm not.
I'm criticising the fairy-tale expectation that marriage makes everything better - quoting life expectancy statistics supports the expectation that marriage makes your life better. I don't deny that marriage can make life better for some people. But, as you pointed out yourself, it takes work - it is hardly the magic panacea that fairy tales make it out to be.
You're being disingenuous. Again.If you aren't criticizing me or my supposed lifestyle (even though you admitted you know nothing about it), why do you keep bringing up my supposedly failed marriage as the supposed source for my (according to you) bitter, harmful, and dangerous attitudes destined to scar all the poor little tender ears of younger /.ers, forever turning them from the ideals of marriage as you conceive it?
Have the courage of your convictions. If you frown on me or my life, say so. Don't feed me a placating line about how you aren't, smack in the middle of a diatribe aimed squarely at what you assume about my life.
You're misquoting and misconstruing to serve your own (quite evident) agenda in support of traditional monogamous marriage as the best and only solution available. I said marriage wasn't a "poof-Happy-Ever-After" kind of affair - it takes work. You agreed. But you went on and implied, repeatedly, that anybody that didn't make a marriage work out simply didn't work hard enough or didn't expect it to work.That's the attitude I see as more harmful.
I prefer a more open-minded and tolerant approach that recognizes that monogamous, til-death marriage may not be right for everyone. Don't tell kids "Our way or the highway!" Give them the information to make their own choice.
Or do you really prefer to NewSpeak people into being unable to even conceive of anything besides what you think is best?
Really, if we stay on-topic for the original post, what this boils down to is a matter of the scientist who made the original quote. I think he was cold-bloodedly playing off of stereotypes to make a good sound bite for a press release. That's not good science. That's good marketing.
If that wasn't what the scientist was doing, please, tell me, what was he doing?
You're assuming that a traditional monogamous marriage is the right thing - by your lights, no matter how much work you put into, it's worth it, because it is the right thing. (Now who's got a self-fulfilling prophesy?)
I'm not saying it's wrong. I'm only saying that there are other possibilities. You yourself cite the LDS - famous for supporting non-monogamous marriages until Utah was admitted as a state.
You keep saying that for me, it's just personal. You admit you know jack about my personal life and situation. Take the blinders off and accept the possibility that what works for you may not work for everyone else. That doesn't mean there's anything wrong with you or with anyone else. It just means that different individuals have different needs.
Now, putting aside what I think, let's look again at what I said (which is not in fact what you seem to think it is). I said that the stereotype of "marriage as life-long romance for Happily Ever After" was "ridiculous and inaccurate." Statistically, approximately 50% of (American) marriages end in divorce. From personal experience, a non-trivial percent of the 50% that don't end up in divorce end up in loveless inertia. That doesn't sound like "life-long romance" to me.
My point, though, was that the original scientist who produced the quote was simultaneously agog at behavior in this lizard species that is well-documented in a variety of other species and apparently offended that this lizard species wasn't living up to the ideals of monogamous marriage. That's what the scientist seemed to be implying with his analogy of a "woman who has her cake and eats it too."
Now on this stereotype of marriage as the end goal of romance, I think it's a particularly damaging expectation to place on people. It burdens them with unrealistic expectations. Expecting young couples to meet an ideal that most people never manage, and telling them that there is no other acceptable solution is hurtful and sets these couples up for a lifetime of suppressed emotions, deceitfulness with the person to whom they ostensibly are most committed, and never-ending feelings of inadequacy. You found someone besides your spouse attractive? Burn in HELL!
Does that really sound like a way to promote love and happiness?
Me, I'd point out that the incredulous tone of the scientist is just a bit too pandering to believe. It feeds right into multiple contradictory stereotypes - the gold-digging slut trophy wife is one, as is the equally ridiculuous and inaccurate (but more socially acceptable) stereotype of marriage as life-long romance for Happily Ever After.
Lots of animals have exhibited comparable behavior, on both sides of the gender divide. You don't have to go down to obscure lizard species and you don't have to write it off to human perversion/idiocy/unnaturalness. Chimps and bonobos do this. Gorillas do this. Wolves and lions do this. Both genders in a variety of species try to gather exclusive groups of mates under their own control, and both genders "sneak around" outside these ostensibly socially sanctioned constructions.
In the interest of not selling us a "pig in a poke," why not let users see their own usage statistics? Before they risk their money with PayPal? Even a simple "You view X pages a month/week/day" would be helpful for people to know how much they're going to have to dish out.
The prices seemed reaosnable, though not spectacular - from other comments, I gather you're expected to bargain. Being a foolish gaijin, I didn't realize this. As I was mostly interested in buying things that weren't sold in the States anyway, this doesn't bother me too much. I may have paid more than a native for the metallic orange camouflage MD Walkman, but it was still less than the equivalent functionality model in the States (even at the employee store). So I got a completely wack-looking MD player. Groovy, Bay-bee!
I didn't have too much problem asking after products. The staff will usually show you the register numbers when you look at them blankly after they've stated the total in Japanese. Just stick to the "protocol" of placing your money or credit card on the little tray they'll hand you with a printed receipt. They'll pick up the tray, make change or run the charge, and place the results back on the tray in front of you.
Oh, and one helpful bit of vocabulary: "Sumimasen...." usually said with a long drawn out final syllable - Sumimaseeen - and remember all the vowels are "short" and "pure" - not the dipthongs of English (One woman I was with had a strong Southern accent - she couldn't get passer-bys to understand that "Carry-Oh-Key" was "karaoke"). I'm given to understand that it translates literally as something along the lines of "I'm so very sorry to interrupt you in the midst of your important work, but....." Works wonders - staff on the other side of the shop will rush over. Even in the restaurants of "Little Tokyo" here in the East Village in New York.
Oh, and take a card from your hotel - it will have a map on the back showing where it is. Taxi drivers will need that. If you're staying with friends, ask them what train station is closest (this will also be on the hotel card map). If you can, memorize the kanji for that train station. Then you can get home, even on the subway, which doesn't have Roman lettering (but the JR train does, so it's not so difficult).
You're slipping, guys!
The one I saw, intended for eventual use in cell phones, was basically what looked like a sandwich of plexiglass and some spongy material. Two wires ran off from the sponge to connect to the contacts for a small fan. You'd take a bottle of methanol, squirt it on the sponge, and the fan would start to spin, slowly at first, and building up in speed as the cell heated up to optimum temperature (which I think was around 50-60 degrees celsius).
Cell phones make a good first application for this kind of technology (as opposed to cars) because the price/performance ratio is high (cell phones are expensive for the amount of power they use) and the performance/weight is relatively low (you don't need a really big stack to drive cell phone). If the fuel-cell cell phone (or even just a widget to replace the battery) costs ten times as much, but lasts ten times as long, is fully "rechargeable" with a one-minute application of methanol (which could come in sealed, disposable plastic tubes, or you could fill it the same way you fill a butane lighter), and has no "memory" problems, then you've got a real winner. People will pay $1000 for a cell phone (they did when the StarTAC first came out).
A car that costs ten times as much doesn't work, because that puts even a cheapie car into six figures. You have to get the price-performance ratio of fuel cells way way down before they become useful for cars. However, for cars, methanol distribution may not be a big problem - some researchers are working on gasoline-driven fuel cells. Not as clean as methanol (which exhausts CO_2 and H_2O), but cleaner than combustion, and the distribution infrastructure is already in place. There's still a price/performance problem, because gasoline-powered fuel cells effectively have a full chemistry lab built in, with three or four stages to go through before the actual power production. They also operate at much higher temperatures.
Direct Methanol Fuel Cells are nifty because they're solid-state. A catalyst (platinum, I think) drives the methanol/oxygen -> power/water/carbon dioxide reaction. They do have problems with supporting rapid changes in electrical draw, however. Typically this is handled by putting them in series with a capacitor. The capacitor can soak up rapid increases in demand, while the cell itself adjusts.
Don't get me wrong - I'm no great fan of ObjC (anything that pretends to be a "modern" language and relies on reference counting for "garbage collection is, well, that's a whole nother thread of its own) or Java (better than a poke in the eye with a sharp stick, but it likes monolithic hierarchies too much for its own good). But what strikes me is the prospect of Cocoa applications that make use of KDE "applications" as components. Yowza! Need a calculator in your app? Drop in KDEcalc.
Where's KDEmacs when you need it? :-)
(and before people start screaming about how both Cocoa and KDE would like to control the main event loop, I'll just say "threads" and shut up).
I mean really, in Haskell, "factorial" looks like this:
fact 0 = 1
fact n = n * fact (n - 1)
Write that, and "fact 20" works just fine:
Examples> fact 20
2432902008176640000
Examples>
However, implementing Haskell (or Self) on a von Neumann architecture is non-trivial. Implementing an efficient compiler or interpreter is tres difficil. People get Ph. D. dissertations for that sort of thing. For someone deeply used to C, Haskell and Self are perverse.
To wit:
- In Haskell, nothing changes. Ever. State change is handled by creating a new state from the old one. Semantically clean, but about as far from C as you can get.
- In Self, anything can change at any time. Yes, Virginia, you can redefine "if-then" whenever you feel like it. Change the inheritance hierarchy? No problem! Whoops! I made a cycle in the inheritance hierarchy! No problem! (yes, A can inherit from B and B can inherit from A). Think of C without the reliability that any particular operation (function call, operator, whatever) maps to the same place more than once. This kind of thing gives most C-family compilers hives. It used to be that C++ was perceived as significantly slower than C - I don't see anyone complaining about it anymore, but Haskell and Self are more extreme examples. C++ made it easy to use jump tables. Haskell makes it easy to use recursion, lazy evaluation, and a bunch of other things. Self makes it easy to use dynamic inheritance, multiple inheritance, even cyclical inheritance.
What is most impressive about these kinds of languages is that you can build efficient implementations, without the compromises to the semantics that C (or its derivatives) entails. The fastest FFT library out there is in C, but the C code itself was generated by Haskell code (code that came up with some original optimizations along the way). The Self compiler is the root technology for Java JIT compilers (when Sun killed the Self project, all the compiler people went to work on "virtual machine" compilers). Self was able to hit 50% of the speed of optimized C while maintaining:- Full source-level debugging
- Garbage collection
- Checks for stack and integer overflow
- and the ability to change the "class" of any object at any time (I put class in quotes because Self is an object-oriented language without classes - part of the super-simple semantics)..
In short, there isn't anything wrong with clean linguistic semantics. But essentially every computer sold today is built around the von Neumann architecture, and non-von-Neumann semantics (like that used by Self and Haskell) are non-trivial to implement.