I can't take this seriously - blaming an individual, especially a CEO, for destroying a corporate culture is ridiculous. I know essentially nothing about the history of HP, but what I do know is that the board bears ultimate responsibility for big decisions, for example a massive layoff.
There is also the distinct possibility that the 'HP Way' was sacrificed to save the company. Again, I know nothing of the history, but putting out a hit piece like this right before the election is just crude.
I can't take this seriously - blaming an individual, especially a CEO, for destroying a corporate culture is ridiculous.
I think this is actually the dumbest thing I've ever seen written on Hacker News. If the CEO isn't responsible for corporate culture, then A) Who is? and B) What's the CEO responsible for?
And why are CEOs getting paid way more than everyone else if they have zero responsibility? Seems like an absolutely sweet gig if you can get paid and shirk any responsibility for a company's failure.
Just convince the board that you are a CEO and they should hire you.
It worked for a friend I know who is a film producer who faked his early resumé as "Producer" and kept getting hired as a such. He would hire good staff & they'd pretty much run the show. He learned producing on the job and quickly replaced the fake resumé jobs with real ones. Thing is, all it took was convincing someone he actually was a Producer. I think many CEOs do the same thing. Walk the walk, talk the talk and hope your employees don't screw up.
It's still a political hit piece which would not exist in the alternative universe where this week's California Republican senate candidate is, say, Tom Campbell.
There may be a time and a place for discussing the upsides and downsides of any particular CEO's tenure at any given company, but it would probably be much better to discuss it when said CEO is not standing for election in less than a week, so that people's feelings on politics don't cloud their opinions on technology management.
I know nothing about Carly Fiorina's time as CEO of HP, but am disinclined to trust anyone's opinion on the subject this week. Can we talk about Geoffrey Immelt's CEOship of General Electric instead?
That seems like a particularly relevant time to talk about it, though. When someone from the tech industry is being proposed for some position with greater power, isn't that a good time to review the existing information as a basis on which to make decisions? I'd say the same of positive reviews: if someone thought Fiorina was a great CEO, now, when people are about to make decisions about whether she should be a Senator or not, is a great time to write that piece and tell us why. I guess it'll still be relevant for the history books to write it in 10 years, but it's more practically useful to write it when people can actually use the information.
A lot of people on HN do know something about it, both as techies and as residents of the area. Listening to their opinions or not is your prerogative, but if you live in California I wonder what criteria you feel she should be evaluated on besides her history running a tech giant.
but if you live in California I wonder what criteria you feel she should be evaluated on besides her history running a tech giant
Indeed, taking her experience into account, and comparing it to that of Barbara Boxer, is a good idea when you're deciding for whom to vote (unless you're just going to vote on ideology as most people do anyway). But the subject then is still "politics" rather than "tech news".
Incidentally, I do think she has a chance of victory. And I also think she and boxer share the same weakness - lack of answers for the underlying problem. Fiorina and other CEOs didn't outsource thousands of jobs to Asia because regulatory compliance was tedious, they did so because the skill level required for a great many jobs is available at a fraction of the price elsewhere. Even if we cut the price of doing business in the USA by 25% in the morning and made administration, regulation and healthcare cheap and easy for all, low-tech manufacturing and services would still be a lot more expensive in the USA than in China or India, and within a few years we'd be back to where we are now.
We need internal reforms, and there are some valid proposals for what to reform and how from both the left and the right. But the big question, to which neither party has proposed any good answers, is how to productively employ the least skilled members of the workforce so that they can have a reasonable level of economic security. People often talk about reviving US manufacturing; that sounds like a fine idea, but first we must identify what we can make that everyone will prefer to buy. In other words, what comparative advantage do we have in manufacturing over the developing world? If no such advantage exists, how can we redeploy that part of our labor force?
I like the green jobs idea, but wind turbines and solar panels can't make up 5% of the economy for the long term.
Well, did Tom Campbell run a major corporation nearly into the ground and leave with literally everybody saying he's a major screwup?
Everybody's been saying she was a disaster for half of a decade. And yes, it's relevant to someone who attempts to make "business experience" a reason to vote for them.
I agree, but in the case of HP I would add that the board has been entirely capable of disgracing itself independently of Fiorina. Fiorina, Hurd, and Apotheker didn't manifest out of thin air, after all.
The funny thing is that you're both right and wrong. You're wrong in that the CEO is the person most responsible for corporate culture, everything else flows from there.
But in this particular case, the HP way was 'on the way out' for a while before she ever joined the company, the Agilent spin-off was already in the works before she took over as CEO.
I'm sure that she carries her portion on the blame for what came next though, but spinning off Agilent was definitely not a smart move because it was to a large extent the strongest hold-out of 'the hp way'.
Guido van Rossum holds a master's degree in Math and CS.
I'd say that it is common sense that mathematical talent is correlated with coding talent provided that the person receive substantial training in coding. Generally speaking, everyone is a terrible coder for the first 2 years, it doesn't matter if you are a math genius, you still need to learn how to crank out good code.
The real question is: is there extra correlation between math talent and programming talent beyond both being correlated with g, the general intelligence factor.
Clojure, like Lisp, has terrible syntax that is difficult for human beings to read. This is one of the reasons the academic community kept Lisp alive - independence from industry, ability to weed out weaker programmers, flexibility.
I'm well aware that I'm posting this on Hacker News, a site founded by an individual who made gazillions on a website powered by Lisp --- I think it is safe to say that it is the exception rather than the rule.
In order to be widely accepted, a language must do many things well enough. If it fails badly at one particular thing, in this case syntax readability, its ability to gain followers will be severely diminished. It may, however, gain a strong following in academia.
If you disagree, then do this thought experiment: who currently uses serious parallel processing power? I can think of a few: Blizzard's WoW servers, government research labs, and bio-informatics operations. How would you convince them to try out Clojure? What problem do they have that Clojure solves so much better than anything else out there that it would gain a foothold?
By the way, I learned CS from Abelson and Sussman and Scheme was my language of choice between 1996 and 2004.
I'm 30, and I've worked at various corporations, both small and large, for 5 years. I've never once been told "I can't do things". Not once. Rather the opposite - I've worked with people who went on to found start-ups, and I've learned a great deal from my colleagues.
The larger question is: should a person in a position of power be encouraging young people to drop out of school? It strikes me as irresponsible.
All of the fears he mentions are present all of the time when coding - fear of working on the wrong thing, fear of not being able to solve problem X, etc... Those fears are healthy and there for good reason - to enable the planning and execution of software projects from small to large. In fact, a developer who did not have, say, the fear of working on the wrong thing would...spend a lot of time working on the wrong things.
I'm not really sure I buy the idea that any of these fears would be substantial enough to impact the allocation of time on programming unless the person in question had some issues to work out such as procrastination.
Afraid of what others will say? Don't tell them. The practice is still going to be worthwhile.
Afraid of not finishing? Break down the project into small chunks, write tests to make sure the small chunks work properly, and iterate between planning out the next steps and executing the next step in the queue (in theory, any number of subsequent steps can be added, removed, deleted, or re-arranged after executing any single step).
Afraid you won't know how to solve a problem? Which problem? Did you read the Wikipedia article and consult the relevant textbooks?
Afraid you're not working on the right thing? First figure out what the right thing is, and justify why it is right. If you're working on anything else, stop. Now start planning how to approach the right thing. You are now working on the right thing, for a discussion on when to transition to coding, see Code Complete.
It's good to be thinking about what the right thing to be working on is. It's bad to feel the emotion of fear as you're doing this, because fear triggers your evolved instinct to stop giving your cerebral cortex cognitive resources and get the hell away from whatever is making you afraid. (If there's a car or wildebeest coming at you contemplating it in depth is not going to help you survive and reproduce.)
Playing strategic computer games like Civilization is a good way to convince yourself that you can make decisions about complicated stuff without feeling the emotion of fear.
This is an excellent suggestion. Other suggestions: read the wikipedia articles on Simple LR and General LR parsers; google "python descriptor" and read the top results.
A parser does not a DSL make. I find this advice, and the advice of the parent, dangerous, as it suggests writing a DSL is just a, relatively simple, technical challenge.
It is like advising the Dragon book and someone replying 'meh, just read SICP'. As in that case, SICP or articles on LR parsers do not even remotely stack up to the Fowler DSL book combined with the ANTLR reference.
Two things: (1) classifying Chapter 4 of SICP as a chapter about parsing is just plain wrong and (2) Fowler's DSL book just came out; by definition you simply can't place it in the same class as the Dragon book.
I think if you actually read Chapter 4 you would have a much different opinion. There's nothing "simple" about it. If you actually grok Chapter 4 then you grok Lisp. After that, it becomes apparent that the phrase "Domain Specific Language" is really just unnecessary terminology.
classifying Chapter 4 of SICP as a chapter about parsing
is just plain wrong
I classified my parent as suggesting writing a DSL is mostly writing a parser. I classified your post as saying writing a DSL is mostly a technical challenge, because there are many issues about writing a DSL that SICP doesn't touch upon (or at least, that's mostly what you will get from it on a first reading. See the final paragraph of this reply).
Fowler's DSL book just came out; by definition you simply
can't place it in the same class as the Dragon book.
I didn't place it in 'the same class': I suggested Fowler's book plus the ANTLR reference have many interesting, relevant, even necessary, things to say about the subject of writing DSL's that aren't in SICP (but again: see the final paragraph of this reply), like the Dragon book has many interesting, relevant and necessary things to say about compilers that aren't in SICP.
After that, it becomes apparent that the phrase "Domain
Specific Language" is really just unnecessary terminology.
You didn't originally get that just from chapter 4 of SICP. You have much, much more knowledge of all kinds of things relevant to writing DSL's that you didn't learn from chapter 4 of SICP. That it may all be implied in that chapter does not mean it is a useful resource for someone touching the subject of DSL's for the first time, because they won't grasp the implications. Implications may be clear in hindsight, when you apply all your other knowledge to that chapter, but that doesn't mean they were even remotely clear to you in the first place.
If you actually grok Chapter 4 then you grok Lisp
And you won't grok that chapter until long after you have acquired a vast array of secondary, additional, related knowledge on the subjects the chapter touches upon.
SICP is like a deep philosophical work: you need to study philosophy and read a lot of primary and secondary works to truly understand it's references and implications. To most people, it is not useful as an initial guide to writing DSL's.
You didn't originally get that just from chapter 4 of SICP. You have much, much more knowledge of all kinds of things relevant to writing DSL's that you didn't learn from chapter 4 of SICP. That it may all be implied in that chapter does not mean it is a useful resource for someone touching the subject of DSL's for the first time, because they won't grasp the implications. Implications may be clear in hindsight, when you apply all your other knowledge to that chapter, but that doesn't mean they were even remotely clear to you in the first place.
SICP is like a deep philosophical work: you need to study philosophy and read a lot of primary and secondary works to truly understand it's references and implications. To most people, it is not useful as a guide to writing DSL's.
This is a fair point and worth talking about. When I read SICP I already understood Lisp macros, which is a major conceptual leap. So I will admit that I cannot provide a datapoint myself to support the idea that Chapter 4 is stand alone. However, the text itself was used in MIT's first computer science course for many years and they did teach through Chapter 4. Many other schools have used SICP in the past as well (http://mitpress.mit.edu/sicp/adopt-list.html). I think the fact that college freshman are capable of grasping it in a semester provides some evidence against your claim that you need "much, much more knowledge of all kinds of things". Hell, even spending a year to learn it would be fantastic.
Look, I'm with you on the fact that SICP is hard. But let's just reflect on the fact that Chapters 4 and 5 in a book written 26 (or 14) years ago give you a strong foundation in programming languages and compilers. There's tons of stuff you can do with this foundation, including writing DSLs. It's a pet peeve of mine that we seem to be constantly rehashing various ideas in SICP, except that we need to write thousand page books on how to express these ideas in languages like Java or C#. Based on a quick glance of the book draft, this bloat is immediately apparent! For example, the distinction between internel and external DSLs? Completely unnecessary. With an understanding of Lisp the idea of an internal DSL disappears; it's just a natural part of the language. And when you think about it, the idea of external DSLs isn't useful either. If the external DSL is expressive enough, it's just like an internal DSL; simply an extension of the language you implemented it in. If not, well then you're parsing am external file format and not a language.
So yes, to reiterate, teaching SICP is hard. But we'd be better off just biting the bullet to avoid all the bloat and repetition that results from not teaching it.
I think the fact that college freshman are capable of
grasping it in a semester provides some evidence against
your claim that you need "much, much more knowledge of all
kinds of things".
I would say they probably grasp it as much as I grasped quantum mechanics after the first course: I was able to go through the motions and explain the concepts involved, but that doesn't mean I actually understood it. I would claim that at some later point, after more courses, labwork and discussions on the subject, I did understand certain parts of it. Much of the additional knowledge and principles I learned are already implied in decent basic texts on the subject, but I simply wasn't in any position to 'expand' those implications.
There's tons of stuff you can do with this foundation,
including writing DSLs.
However, writing your first DSL on that foundation requires you to reinvent many wheels, some of which you will reinvent in a square way that first time. Knowing how to write a programming language in Lisp doesn't tell you how to write DSL's, like having a Ph.D. in English means you know how to write a novel, without you actually being capable of writing an good novel. They would still benefit from reading books on 'writing novels' by people that have practical knowledge in writing actually good novels, even if those books were written by authors whose genre they dislike and the style of whom's examples they dislike.
the distinction between internal and external DSLs?
Completely unnecessary.
If everyone would program in Lisp: yes. However, people write DSL's in different languages, for all kinds of reasons you may or may not agree with. That means books on writing a DSL in other languages than Lisp simply have their place. And may also be valuable for those writing DSL's in Lisp, for the reasons mentioned above.
I fail to see how Chris was a "casualty of the system". I have a little trouble buying his stated desire to transfer to a vocational school for training mechanics...in any city there are plenty of mechanics around, and you just need a little guts to up to a bunch of them and say "I want to be a mechanic, please tell me how". Sooner or later, you're going to get a lead. They may or may not take you on, but I find it difficult to believe that you can't become a mechanic if you show at least some of the signs of being worth an investment in time - maturity, respect, willingness to work hard, motivation, some relevant experience like, say, fixing other things that are less expensive than but share some characteristics with cars, etc...
I get the impression that Chris' journal writings have more to do with his gang aspirations than his desire to live an honest life. Gangs are known to deal in stolen cars, and they deal with shady characters who perform a variety of roles to support this illegal business - ripping cars apart, putting together knock-offs, making illegal modifications, and so on. With a little work, I have no doubt Chris will be able to satisfy his love of cars as a gang member.
Being a gang member is a high risk / high reward proposition, but it has a variety of perks: money, women, and cars among them. This leaves the issue of morality untouched - clearly gangs are evil and mechanics are good...but you can't teach someone to be good.
The equal-odds rule is simply wrong. A few examples: Andrew Wiles, Charles Darwin, John Forbes Nash. These people produced a small amount of work, but they shook the earth. Some people are geniuses, and some are not. It appears rather that some geniuses are prolific while others are not. Examples of some prolific ones: Einstein, Serge Lang.
Edit: A commenter pointed out that Charles Darwin goes in the second list.
I think it is difficult to actually assess the veracity of the equal-odds hypothesis. You don't know how much Darwin or Einstein threw away, or how much of their stuff was irrelevant and forgotten.
I should add however, that the equal-odds thing is the way that i learned to be a better photographer. Shoot as much as you can, figure out what you did to take the good ones (I guess it's like the monte carlo method for artistic improvement).
I agree - there is a vagueness issue with the rule, and it is not obviously falsifiable. But as stated, the rule does not discuss unpublished works - it is a statement about published work, and the statement is that each scientist is throwing the dice when they publish, and there is nothing the scientist can do to increase his chances.
Not sure I disagree overall, but Darwin isn't a very good example. He produced quite a lot of writing throughout a long career, and his most famous book, On the Origin of Species, came somewhat late (he was 50, and it was something like his tenth or eleventh published book).
There will always be outliers in any population. Assuming you are a genius so you only need write once or twice to be universally read is a good way to never be read. Assuming you are subject to the equal-odds rule means you will publish more and have a much higher chance of being read.
