3 ms·

"I think they are both valid approaches." For limited ranges of valid. If you are implementing a low performance requirement CRUD app, certainly you can become

by RogerL 13y ago

"I think they are both valid approaches." For limited ranges of valid. If you are implementing a low performance requirement CRUD app, certainly you can become an effective programmer without knowing the low level details. But if you want to be an engineer? Good luck. I've worked with people that didn't know the stuff behind C, and they are pretty useless as soon as performance matters, or you need to talk to hardware, or crank through a lot of numerical computations, minimize watt usage of a cellphone, app, debug complicated situations, and so on. They don't have a good mental model of the machine in their mind, and so they cannot figure out what is going on, reason about the performance of a modern chip, and so on. There are a lot of arguments for expediency on HN. Probably it is partially justified, but I will always advocate for an engineering education, as opposed to a 'learn rails in 3 weeks and get a job' approach. Education and knowledge enables you to tackle any problem that comes your way. So, while you can learn to be an effective debugger of a Python script (say) and so on without detailed knowledge of the machine, mastering the fundamentals will make you an effective debugger and enable you to do so much more. To stick with the python, what happens if the python implementation is buggy? There is a large subset of programmers that can not cope with that situation. Why limit yourself? If this is going to be your career, the way you pay your mortgage, feed your kids, and so on, invest in yourself. I'm having trouble of thinking of the downside of acquiring the knowledge, but I can trivially think of the upside.

actsasbuffoon 13y ago
There are advantages to the other side. Many fascinating developments were made possible by those who prefer to think functionally, as opposed to imperatively. Modern relational database engines are fairly easy to implement once you understand set theory. Lambda calculus has taught me how to create a linked list using nothing but partially applied higher order functions. Software transactional memory was invented in Haskell, and it's easy to see why it happened there first. The world needs people who think mechanically as well as people who think at a very high level of abstraction. I'm glad people like you exist, as tech would be vastly behind where it is now otherwise. I'm also glad there are people like me. We may not always see problems the same way, but the world is a better place because of our differences.
- ori_b 13y ago
  If you aren't able to think about both sides, you've got a massive hole in your education. I'd be willing to bet that the people that came up with software transactional memory were comfortable in C and assembly as well as Haskell, and hadn't bottlenecked themselves with the false dichotomy of thinking functionally vs thinking imperatively. The world needs people who think mechanically AND at a high level of abstraction at at the same time.

by RogerL 13y ago

actsasbuffoon 13y ago

There are advantages to the other side. Many fascinating developments were made possible by those who prefer to think functionally, as opposed to imperatively. Modern relational database engines are fairly easy to implement once you understand set theory. Lambda calculus has taught me how to create a linked list using nothing but partially applied higher order functions. Software transactional memory was invented in Haskell, and it's easy to see why it happened there first. The world needs people who think mechanically as well as people who think at a very high level of abstraction. I'm glad people like you exist, as tech would be vastly behind where it is now otherwise. I'm also glad there are people like me. We may not always see problems the same way, but the world is a better place because of our differences.

ori_b 13y ago
If you aren't able to think about both sides, you've got a massive hole in your education. I'd be willing to bet that the people that came up with software transactional memory were comfortable in C and assembly as well as Haskell, and hadn't bottlenecked themselves with the false dichotomy of thinking functionally vs thinking imperatively. The world needs people who think mechanically AND at a high level of abstraction at at the same time.