6 ms·
C'mon kids. Not again. Tools in your toolbox. Use them as you wish based on whatever criteria fits the moment and the project. I made hundreds of thousands o
by robomartin 14y ago
C'mon kids. Not again.
Tools in your toolbox. Use them as you wish based on whatever criteria fits the moment and the project.
I made hundreds of thousands of dollars with a program I wrote in 8051 assembler. To be fair, it was part of a larger hardware solution. Still, the UI portion of the code was all assembly language.
It wasn't until well after the product was in the market and selling very well that I converted it to C. I did so mainly to make it easier to maintain and expand.
Could this have benefited from OO? Who cares?
To add insult to injury, the workstation portion of the solution was written in --sit down-- Visual Basic! Yeah! VB. Did it matter that it wasn't Visual C++? Nope. Was it ever converted to VC++. Are you friggin kidding me? Nope. It was making plenty of money as it was.
Plenty of other projects were done using other languages, such as APL, Forth, Lisp and, yes, C++.
My point is that none of this really matters. People have gone to the moon without OO. Whole banking systems have been run without OO. OO has its place. And, when applied correctly, it can be a lot of fun to work with.
Digging through one of the links in the posted article there's an article that suggests new programmers should be taught Python without the OO stuff. What? Crazy.
Every new programmer needs to start with C. In fact, I am convinced that every new programmer needs to start with C and be tasked with writing an RTOS on a small memory-limited 8 bit processor. And then write several applications that run within that RTOS.
Then give them a budget of n clock cycles and m memory bytes and have them create a solution for a particular problem that barely fits within these constraints.
I would then expose them to Forth and ask that the re-write the same RTOS and applications.
Then I'd move them up to Lisp.
From there move into one of the OO languages. My first OO language was C++, but I suppose today I might opt to teach someone Java or something like that. Definitely not Objective-C. Keep it simple.
The above progression will expose a new programmer to tons of really valuable ideas and approaches to solving problems.
Then I'd get serious and ask them to write something like a genetic solver on a workstation in all of these languages and optimize each solution for absolute top performance (generations per second) first and absolute minimal memory footprint as second batch. Lots of invaluable lessons in that exercise.
Now you have a programmer that can identify which technology to use under what circumstance and for what reason. This is a programmer who knows how to get a 100x or 1000x performance gain out of a piece of code or how to get something done 10x faster at the expense of raw performance. Here's a programmer who understands exactly what is happening behind the code.
And, in the end the most important thing still is data representation. You can make a program 100 times harder to write if you choose the wrong representation for the problem being solved. Just like the first article points out: search a small table and the "hacker" solution is almost trivial.
- bad_user 14y agoYou're arguing against what exactly? Rob Pike's opinion is consistent to what you've said. The long comment implies that you do care.
- robomartin 14y agoArguing against continuing to have these pointless discussions on HN every 57.3 days. Of course I care. It's what I do. I just don't see a point in people getting lost in language, editor, IDE --whatever-- discussions. They just don't matter. One can write absolutely-brilliant or absolutely-shit code using any tool one might care to name.
- patricius 14y agoYeah. Let's get essential. Let's not talk about non-essential stuff like programming languages, IDEs, tools. The only thing that really matters is that the thing you are using can make money. And lots of them. No. Let people discuss what interests them. Discussions lead to better tools and new perspectives. Stop this "I transcend these trivial discussions and I am such a pragmatic and bricolage type of person."
- robomartin 14y agoI get your point. And, yes, you are right. The problem is that a lot of these discussions turn in to pissing matches that are not constructive at all. In the meantime, if you are a working programmer none of this is relevant to you. If you are working on iOS you are, more than likely, not going to be writing native apps in Python or Lisp no matter how wonderful they might be. The academic discussions are most definitely necessary. When they take place in places like HN I am not sure that they surface in the best possible light. There are no real conclusions. There are no "calls to action". No test cases are produced and few, if any, real-world results can be pointed to. I seriously doubt that such discussions on HN would start a massive movement to introduce a new paradigm that sweeps a significant portion of the software development universe. I think those things happen far more organically and, by the time they bubble-up to places like HN a significant body of work is already in place. I'll use as an example something like Meteor. I don't know that full history. I did learn about it on HN --which is solid indication that there's value in HN as provider of programmer-relevant news. However, I don't think that Meteor had it's genesis out of a discussion on HN. And a significant body of work was already in place by the time it made it into HN. And, as far as I know, Meteor wasn't created out of long academic discussions on HN or otherwise. It probably was an idea that coalesced into a project when the founders got together and bounded it around (best guess). I have seen (and got sucked into) many pointless discussions on HN about these kinds of topics. Discussions about such topics as "to vim or not to vim" can get, to be kind, "interesting", when, in reality, they are pointless. You use the tools that let you get to a shippable product at the time you have a project on your desk and move on. In that context there is no "best". That was my point in mentioning making money with assembler. Did I want to write complex code in assembler? No. Was it necessary due to performance? Nope. Was it a pain? Absolutely. Did it work? Yup. I had lemons and I made lemon-juice. Optimize later.