Hacker News Reader

Comment by cturner | Hacker News Reader

I'm skeptical of these lists because people can work through things. For example, the stuff listed under "Inability to determine the order of program execution" is something that many people will get jammed on eary on as they try to take their brains (which is honed on the syntax of school level maths) into the programing world (where equals is an instruction rather than an assumptions). Another one is "Lisp is opaque to you". It's very sweet for MIT types to make these declarations from mount olympus, but lisp is something that can take time to acquire. If someone isn't a natural programmer but is happy to work at it to overcome hurdles then there's nothing wrong with that.

One of the examples of bad technique is:

    Homebrew "Business Rule Engines"

Can anyone give examples of the sorts of things the author means by this? What sort of systems have people seen, and why is it necessarily a bad thing?

View on HN

"It's very sweet for MIT types to make these declarations from mount olympus, but lisp is something that can take time to acquire."

Don't worry. In the Valley, people from MIT don't have a good reputation as great programmers. For some reason, their education is a lot of 'theory' and less practice.

Apart from Standford\Caltech, Some of the best schools that produce great programmers are your average state school.

I have a theory behind this, which may be correct. Learning to be a great programmer takes years, and school is just the start. People that do well enough go to something like MIT, think they are already very smart, and don't try hard when they come out.

But if you are hungry, and smart, and just happen to go to your average state school, you probably will do better, as you probably are humbler to begin with.

It seems when the rubber meets the street, in startups, building products, that's where the great programmers are made, and lisp is not a requirement to know to be a great programmer, or actually build great products. Having an idea of what functional languages are is a must, knowing them is not.

While I'm not an MIT student, I think the school puts a huge emphasis on being pragmatic ( see http://news.ycombinator.com/item?id=530659 ). Also, given the huge disparities in abilities of the freshmen there, I'd reckon that, more often than not, an MIT education would be a humbling experience.

My dad, an MIT alum (though in chemistry, not CS), likes to tell the story of how whenever new grad students arrive on campus, everybody's wearing Phi Beta Kappa rings. By the second week, they've all disappeared. When everybody's got one, flaunting yours displays arrogance a whole lot more than intelligence.

I think it's much simpler than that: Most good programmers are self taught. School is just increasing their exposure and nailing down some good habits.

Even fricken DeVry will help you with that if you are already motivated.

nope not the case, I know a bunch of people at these various schools, and the crux of the problem is that theres a huge culture at MIT (and moreso than many peer schools) of celebrating herculean last minute efforts that get the grade. This is great for experimental hacking on a weekend, and "good enough" for research, but it does not encourage an incremental design sensibility, owing to its last minute nature.

This is not to say that any of these people are bad at what they do, they just have bad habits that they need to walk off, but first someone needs to tell them!

the crux of the problem is that theres a huge culture at MIT (and moreso than many peer schools) of celebrating herculean last minute efforts that get the grade

That's a very astute observation. I work and have worked with many MIT people, and even TA'd an MIT course. The "all nighter" hazing ritual culture was very prevalent. To this day, my friends who went to MIT prefer to work 24 hour shifts, late nights, and on weekends - even though they've been out of school for a decade. In addition, MIT had a culture of boot-camp style negative reinforcement. "You suck, are not smart enough and are lazy, work harder" was the driving attitude. (at least it was in the late 1990s)

In contrast, when I moved to the west coast, all the Stanford people I met were more about basking in their obvious awesomeness and mastering time management. Get the project done early, schedule everything around ultimate frisbee team and rock climbing club, go to the outdoor concert on Friday night and still make it up to Tahoe for the weekend.

I've seen weak work from a few Stanford grads.

While I have great respect for these institutions and the aptitude required to succeed within a difficult program, it's not a guarantee of quality.

Well, his alternative careers for those who with an inability to determine the order of program execution are pretty good. I wouldn't mind being a civil engineer.

The inability to determine the order of program execution is what made me give up haskell for ocaml and scala. Does that make me a bad programmer?

Why do you care what order your functions run in Haskell? Seems to me you want them to run as late as possible and no sooner.

He doesn't. What he really cares about is memory consumption, especially stack consumption. Order of execution can influence that a lot: unevaluated chunks may hold quite a lot memory, and their evaluation in normal order may overflow the stack (in most implementations).

These problems are called "lazyness leaks". This is why he still cares about order of evaluation.

Don't worry, you're in good company, for example: http://janestreet.com/

I (a Haskeller) interviewed there, and ended up in an long debate with their CTO Yaron Minsky poking at warts in each other's pet languages and patterns of thought -- in retrospect we were trolling each other pretty hard just as a natural reflex.

This one time I had to work at a place where a postgresql install was not only the main datastore, it was also the main system message bus by abusing notifies. Further the enterprise message bus was a homebrew thing that was written to both pass messages and do RPC, oh and be the main way to monitor if a remote site was up or not. I think both of those count as well.

For those who are curious: given these were linux systems, d-bus was the right answer for the former, and something like RabbitMQ or OpenAMQP, or even JMS solutions would be the proper answer to the latter.

See to me, those look like homebrew solutions, and Tibco/RV or MQSeries is the proper answer.

It's easy in retrospect, but Postgres predates JMS etc by a loooong way - who's to say that wasn't the best solution at the time?

Good question! The postgres solution was unexcusable, it was always used side-by-side with dbus. The other was around before any affordable[1] enterprise message busses existed, however as that changed the buggy solutions was still touted as "amazing new tech that keeps us ahead ofthe competion. No we can't switch to something else".

[1] Affordable being defined as: this particular company could pay for it without going out of business.

Reply on news.ycombinator.com