My observations about languages:
1) Spend a little time evaluating and toss quickly those that you don’t like
2) Toy problems are designed to make a language look good or to point out its strongest features
3) Fiddling with your own toy problems highlights issues of a language relevant to your use of it
4) Until you implement a real problem you can’t understand the language
5) Until you hit the limits of applicability you aren’t proficient in a language
6) A language will subliminimally and fundamentally alter your perception of a problem
7) Don’t believe the hype
8) The proper or improper design of data structures can make a problem range from trivial to unsolvable; ease of expressing and redesigning data structures is essential to solving real problems
This is actually from a larger narrative about why someone chose to switch to Erlang.Why I chose erlang (very, very long story) (I’ve been looking at Erlang recently for a variety of reasons - which if I ever get any where I’ll post about)
Even though this is about Erlang - the general ideas above seem appropriate to discuss when you eval any new language. I guess number #2 was the one that really stood out since I’ve met so many people have “played with” Rails. It almost seems literal - I mean they watched the screen cast - downloaded it - made a screen and that was it….
< img src="http://static.flickr.com/63/171460457_a6df7357d4_b.jpg">
Wonder when I can get my whole lobster?
The Power (and Peril) of Praising Your Kids — New York Magazine
Interesting view on how to make people “smarter” without turning them into people who give up at the first sign of trouble…
The only difference between the control group and the test group were two lessons, a total of 50 minutes spent teaching not math but a single idea: that the brain is a muscle. Giving it a harder workout makes you smarter. That alone improved their math scores.
If you follow my advice and remove yourself from the code, then you are removing yourself from the act of creation. This act is why I don’t really sweat outsourcing. Automatons don’t build, they process. While good process can save a lot of money, it’s not going to bring anything new to the world.
What do you think - should a manager stay in the code or get out of the way?
Facebook | Programming Puzzles
Your name is Randall, former NASA roboticist and all-around smart guy. You and fifteen friends are on your way to see a movie about velociraptors and math
.
I’m thinking about playing with this in Ruby….


