"JavaScript was not dumb luck..." Brendan Eich

My point is simple: the likelihood of any other language syntax than C (C++ -> Java, but really: C) was low. The likelihood of something without "objects" was also low. Netscape recruited me in part because I could hack quickly, and in part because I had some language implementation chops (not enough, in hindsight). I was "that guy", not in any brag-worthy sense, just the only person who was in the position to do the deed, with (barely) enough skills to pull it off.

is EA "the Sims" doomed because of blocky competition? #Minecraft

http://www.minecraft.net/

My youngest daughter was a Sims fanatic until Minecraft arrived... Now
she spends her time building elaborate worlds. Although seemingly
simplistic, the object is to survive in a world. But the ability of
the player to build things in that world, free upgrades from the
developer and a community that builds enhancements make it compelling.
She has also figured out how to run her own server and patch worlds...
I'll need to send her to Java training next.

This game is another example of Clayton Christensen's classic "The
Innovators Dilemma".

Sent from my iPad 2

Programming did not teach people how to think. He realized that he knew too many narrow minded programmers...

"[Kay] had been convinced that teaching kids to program at an early age would permanently shape their thought processes... Yet his experiments had led him to a contradictory conclusion... Programming did not teach people how to think.   He realized that he new too many narrow minded programmers for that to be so, now that he considered the question in depth.    The truth was the converse, every individual's ingrained way of thinking affected how he or she programmed."

"Kay had remained proccuppied with the lesson he had assimilated from Marshall McLuhan: 'Once human shape their tools, they turn around and reshape us'.  that was fine if the tools were the right ones,  but he was still unconvinced that SmallTalk fell into that category."

Dealers of Lightning: Xerox PARC and the Dawn of the Computer Age (See all Computer & Internet Books)

Highly recommended read...

Michael Feathers Talks Legacy Code on .Net Rocks - great #quotes

via .NET Rocks!

  • "My point of view is that legacy code is just code without tests."
  • "What's important is to try to imagine something that is just a bit better than what you have currently. If you can target those things, then over time you will really start to make a difference in the code base."
  • [in order to reduce fear of a legacy codebase perform a scratch refactoring...] "Check out the code with no intent of checking it back in. Refactor different sections... enough to get a feel for the code base, to get a handle on it..."
  • "Functional languages get us away from some of the issues that have become so problematic in testing... Functional programming reduces the number of side effects of code..."
  • "C# is getting too big. Every time you turn around there's been something added to the language. I'd hate to see it end up like C++."
  • [regarding the new raft of languages] It's a bit like the tower of babel. For so long we had a mono culture in the industry around java and visual basic. Now it's at the point where everyone and their brother is designing a new language."
  • [Regarding OO languages hitting a wall] "I think there is something to that, but I also think it has to do more with the type systems."
  • "There are two basic themes of type safety... Type inference and Laziness, create data structures and apply limitations after the fact. I recommend that people learn Haskell. It really throws your mind in strange directions."
  • [Regarding OO programs becoming legacy...] "It seems to be the fate of everything... Progress happens."
  • "The history of the next 30 years will be about mining the last 30 years"
  • "The thing about learning Haskel... it's great... You just need to learn to think like a martian!"
  • "When you're choosing the right tests for something you have to think about it very deeply. you have to understand exactly how it operates... as you go through that process you'll arrive at higher quality without necessarily putting the bugs in there in the first place. So TDD and unit testing in general gives us quality, not through just test failures, but by forcing us to think through our code deeper than we would otherwise."
  • [Regarding Agile] "The only thing that gets me is that there seems to be a moratorium on design in the industry over the past 10 years. There was a time when peopled talked about the intricacies of object oriented design... Once you go ahead and say 'Design is going to emerge' people say 'oh well then, we don't have to talk about that'"
  • [Regarding the question: has architecture been forgotten"] "I think to a degree... there are some not nice things that have happened with the nominal title of architect over the past 20 years. But architecture expertise is definitely necessary in many application domains but they have to have a real view into the code."
  • "Architecture knowledge has to be in the team... It's a very communicative role."
  • "The import thing is continuity of knowledge in the team... When you have that, everything works out well... When you don't, everything is a fishing expedition when you need to make changes.
  • "Documentation is important but you don't want to get into the situation where everything is exquisitely detailed and has to be changed every time you change the code. It gets crazy."
  • "If you see code that is crazy and odd and you understand Conway's law, it really says something about the team that produced it. If you need to produce code in a team effort, than that team needs to get along together in order to produce good code. Otherwise, they are just sabotaging each other... even if only subtly."
  • Emergent design can work very well, but in large organizations with a large codebase you have teams that do a little work on some code and move on, a little work on other code and move on. With agile, the original goal was to have collective code ownership. In large organizations there is no ownership so you have an odd tragedy of the commons. In large organizations, there needs to be a notion of ownership and if you don't, you shouldn't be surprised with what you get."