> I think you need to be aware that not everyone who disagrees with you or fails to kiss your ass is trolling.
?
EDIT I can't believe I've gotten drawn into this. Your use of loaded terms "bitchiness", "ass", "whining", giving your opinions as if they were truth, issuing commands, all in terms that didn't relate to the comment you were replying to, should have tipped me off. No more responses from me. Bye.
I've really got to learn to stop posting anything to HackerNews that in any way can be construed as an admission of weakness or vulnerability. I sensed that was the case here when I was writing, but didn't think it was necessary to hide it. I will be more careful in future to not reveal more than is absolutely necessary, and so avoid this typical, casually condescending reply. It's annoying because it's the "mistake" that gets seized on, instead of what I'm saying... as if there's more interest in correction than communication.
Maybe I am alone here in disliking unsolicited advice, but ironically, when I ask a question here, I usually don't get any help...
...so perhaps the secret is not to ask, but state something that incidentally reveals the lack of knowledge, so the scent of inexcusable ignorance rouses the instinctive hacker display of superior knowledge. I will try this.
Or maybe, I am just not a hacker. Although I love coding (especially to help other people) and I'm not a corporate type, I am coming to think this more and more; because behaviour like giving unsolicited advice seems to be totally acceptable and approved of on sites like this, but by my values is a form of trolling, and has never sat well with me.
EDIT I just checked the site mqt lists in his profile (http://mark.nirv.net/), and judging by his May 26, 2007 entries, he does troll at times ("What a f______ p___"; "Use a spell checker next time, a______." - to me, that's really abusive). Trolls have sometimes gotten under my radar by combining genuine knowledge and apparent helpfulness with their trolling. Oh well, you live and you learn; without risking mistakes and uncongeniality, one cannot learn.
There's a famous economics essay about the size of the firm by Ronald Coase (winners of the Nobel prize for economics), in which he discusses why firms (companies, organizations) exist at all (instead of individual contractors), and the factors influencing their size.
FP is the future of programming, and always will be.
The argument that many-core will lead to FP adoption used to appeal to me, but then I studied Erlang, and saw that its concurrency power was due to shared-nothing pure-message passing, and not due to it being functional. FP is a way to not need to share memory, but Erlang doesn't actually use that for concurrency. The thinking seems to be that inter-core communication should be coarser-grained (e.g. at the module level, not the level of recursion over a list), because it will always be slower than communication within a core.
Also, surprisingly to me, the over-hyped web services, SOA and ESB etc arguably also aim at pure-message passing concurrency.
By what criterion did they decide if a field looks "good" or not? It matters less what you see than how you see.
It looks like market assessment, probably based on likely growth in demand, existing competitors and the HP founders' capabilities to make a "[technical] contribution" (as they later came to call it).
Business model is the question: (1) Trade sale to spreadsheet makers. (2) Sell a plug-in to spreadsheet users. (3) Or... let users lead you to a problem that only you can solve.
I don't think it's patentable[1]. It's a cute idea, kind of obvious; I'm not sure how well it really generalizes on all the cases that come up in huge datasets. If you continue along this path, you might come up with some patentable detail. I think in the US, you can file up to a year after inventing, so public demos don't destroy novelty (IANAUSAPA).
I think your strength is less the technology than the interface, which is nicely wrapped up and works[2].
You'll get interesting user leads from this demo. Maybe: who is suffering from what problem in what specific context who really needs your help. It's hard to get this market research any other way,
I can't see a really neat or natural way to monetize it - it's just not big enough. But the world's imagination is greater than my imagination. If you stick at it, I think something will come to you. That would be really cool!
[1] a patent isn't for suing people, but to have something to sell to Microsoft or Google etc.
[2] of course, you can improve the GUI further once you know what people need - imperfection is a good thing, because a head start on the competition is worthless when you run out of track.
Sorry, that was a suggestion phrased as a question (i.e. I know what isotopes are). I was suggesting a name that signifies operational properties rather than "the" definition of what it is. If heavy water became commonly available, this would undoubtedly occur.
It's like features vs. benefits, which I've been working with over a few weeks, to understand the need for my product, and the gaps left by existing offers in the marketplace. Quite possibly, I'm thinking too much in those terms :-)
Deuterated bonds can be up to 80 times stronger than those containing hydrogen.
That seems likely to alter chemical behaviour (as researchers found). I'm not a chemist, but it seems reasonable to consider compounds with such bonds as different compounds. Why should we think of carbon-12 and carbon-13 as variations of carbon, instead of distinct elements - if they have different chemical behaviour?
The blackbox testing tells us that 35% heavy water is lethal, but doesn't tell why. It's possible - and even likely - that it is the very bonds we wish to protect that become lethal if strengthened 80 times.
The final "heavy babies" grayed paragraph at the end is fascinating (in case you skipped it: babies have more carbon-13, and their mothers are unusually depleted with it around the time of birth.)
I have one of these (or had - lost somewhere) and they are fantastic. A real pleasure to use. They fit snugly in hand, and you can drive force into the work. The metal itself somehow feels soft. There's even an integrated component for removing eyes from potatoes (I never use that; but I like the idea).
I don't know if they are really all that great - however, they are so much better than the standard ones (pencil shaped).
As in the old saying, you don't have to make a perfect mousetrap - just a better one.
Google could arrange and track etc the ads quite easily I think.
They already have Adwords, and they acquired that huge banner ad company, doubleclick. They also acquired an in-game ad company (which is probably the most similar to this concept, in terms of technology).
A missing component is them paying the creator of the video...
The "BRAVE" one differs, because the article talks about such confidence and optimism that one doesn't experience fear. Courage requires fear, as the article says.
The Motto reminds me of: "One word sums up probably the responsibility of any Governor, and that one word is 'to be prepared'"
note that "adwords" isn't just the idea of putting ads next to search, but mainly the auction aspect of it (so google always gets the highest price possible; and advertisers never pay more than needed - the idea is it's a little market), and linking it to search.
Overture/goto.com was basically adwords alone (no search results), and was quite profitable I believe.
Unfortunately, my little correction doesn't contribute to the topic of the debate... um, departments can certainly be entrepreneurial, also, in some companies, with skunkworks and so on, you are certainly doing all the things an entrepreneur does: funding, new products, marketing. The only difference (and perhaps a key difference, according to fallentimes) is that it ain't their money. Entrepreneurialism certainly has a gut-test component... and maybe that risk/reward of ownership is essential.
Otherwise, you're gambling for matchsticks. Using all the same skills, but you ain't gambling.
Complex and confusing problems can be tackled by breaking them into modules, with interfaces between. Objects are one way of doing it.
Each object wraps up a program. The program's global variables become variables of the object. The program's functions become functions of the object. The public functions are the interface of the object (an interface is the part of a module that interacts with other modules, like the surface of an object). So basically, you have the inside of the object, and the outside (surface).
Think of it as support for the modules that you already wanted, that seem to be naturally present in the problem, or in how you naturally want to divide it up and think about it. That is, use OO to support your conception, instead of a priestly template to mold yourself into. Tools are good slaves, poor masters. If you follow your conception, you will make mistakes - but those mistakes will belong to you, and so you will learn from them.
Using objects for modularity does not work well for every case (e.g. I think parsing works better in the old-fashioned style).
OO is nothing special. There's no wonderful mysterious secret. It doesn't even have a precise definition that everyone agrees on. It's just a tool. Inheritance and polymorphism are grossly overrated, but presented as a quasi-religious AI solution-to-everything - but are useful in some cases (e.g. great for windows/GUIs). There's also a danger of having overly theoretical modules - the "spaces" you mention. Be problem-driven. What does the problem need?
?
EDIT I can't believe I've gotten drawn into this. Your use of loaded terms "bitchiness", "ass", "whining", giving your opinions as if they were truth, issuing commands, all in terms that didn't relate to the comment you were replying to, should have tipped me off. No more responses from me. Bye.