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.
Can you give links and resources to support accomplishing the "CS curriculum" you suggested?
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.
Besides K&R, which resources will help someone accomplish such a task?
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.
ditto
I would then expose them to Forth and ask that the re-write the same RTOS and
applications.
what forth resource are worth learning from? why forth?
Then I'd move them up to Lisp.
what lisp resources?
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.
> Can you give links and resources to support accomplishing the "CS curriculum" you suggested?
I'd have to Google it just as you would. Here a few points.
C - Well grab a copy of K&R
Microcontroller: Get over to SiliconLabs (http://www.silabs.com) and grab a development board for something like their C8051C020 along with the free tools. Or you could buy a Keil compiler. Study their sample code in depth.
Lots to learn here: configuring the processor, i/o ports, interrupts, timers, counters, clock frequency, serial I/O ports, etc. Make an LED blink. Then make it blink when you press a button. Output an 8 bit counter to a bank of eight LEDs. Have the LEDs count up and down in binary. Have the LEDs scan left-right-left. Figure out how to read a potentiometer with the A/D. Use the potentiometer to control an output that runs an RC servo. Get creative. Have fun. Google is your friend.
RTOS. Get over to Amazon and get yourself a copy of "MicroC OS II". Once you are done with that book --and fully understand it-- you'll find yourself flying at a different level.
Forth: It's been a while since I've used Forth. "Thinking Forth" used to be a go-to resource. I would imagine it is still of value. Not sure what Forth compilers are available for free today. Google it.
Go over to Amazon and get yourself a copy of "Threaded Interpretive Languages". Either learn a little assembler or use C and the aforementioned microprocessor board to bootstrap your own Forth on the C8051C020. You might want to find yourself a copy of "Embedded Controller Forth For The 8051"
I actually learned Lisp while having to customize AutoCAD. They called their flavor of Lisp "AutoLisp". It was a really neat way to learn it because you were dealing with complex graphic entities from the start and Lisp was excellent at manipulating them.
Not sure what the current favorite Lisp implementations might be for different platforms. Google it.
OO Programming: Get a copy of Java and one of the many excellent tutorials out there. Go to Amazon for a copy of "Design Patterns: Elements of Reusable Object-Oriented Software". Read it cover to cover. Five times. While you are at it, get a copy of "Code Complete".
I know this is expensive, but, in general terms, surround yourself with multiple books covering the various subjects. I never buy just one book. I might buy five to ten books covering the subject from different angles. Sometimes you don't necessarily read them cover to cover, but you use them for reference as you move forward. The 'net doesn't always get you there. Searching for solutions on SO does not necessarily teach you what you need to know in order to understand how you got there. Someone can show you the code you need to write an Objective-C class that complies with a Protocol, but, do you really understand the five why's and how's?
For example, if I need to code an FIR (Finite Impulse Response) filter using a new language or on a new platform I can usually do reasonably well hunting for code examples on the 'net. The important part here is that I already know what an FIR filter is and how it is supposed to work. I have implemented them from scratch in anything from hardware to DSP's. So, scouring the 'net for code snippets really becomes a way to help me discover how to express these ideas in this new language rather than me trying to both learn the language and about FIR filters at the same time. Hopefully that makes sense.
I'd much rather hire a programmer that has depth of knowledge in algorithms, patterns and the general subject matter we might be working on (say, as an example, inertial control systems) and tells me that he or she is not fully versed in the language that we have to work with than one who knows the language in his/her sleep but lacks the depth. You can google the language. You can't google the other stuff.
Sorry, this isn't a complete answer. I'd say, above all, as you learn you really have to feed your curiosity with projects you are interested in. If writing a solution for banking doesn't get you excited it is likely that you are not going to be inspired to learn anything new while forced to write that code. If, however, figuring out how to make a robot walk inspires your curiosity, you'll find yourself coding for sixteen hours at a time trying hard to solve problems and learn as you go.
Thank you for this, it's really helpful. I couldn't find the C8051C020 at silabs and wondered if you meant the C8051F020 [0] instead. While this was already a long and helpful post I was wondering if you had any plans to elaborate further (maybe somewhere else) on programming for micro-controllers and RTOS programming.
Yes, the F020 is it. BTW, the only reason I recommend that one is that it is nicely loaded with peripherals that are useful. It isn't the simplest uC to use because of the way you setup the I/O. If you are playing with the development board though this isn't a problem. If you are laying out a board you better have the I/O configuration nailed down or you can shaft yourself inside a microsecond. Don't ask me how I know this.
Let me see what else I can say about programming microcontrollers and RTOS's. I really enjoy programming at this level. It can be a lot of fun and, as a hobby, there are tons of places where one can apply them.
I've used other uC's in their line-up with good results. Of course, Microchip has a number of good ones too. Probably cheaper. It's been a while since I've used one of theirs.
Once you get to a certain level (and to a certain type of problem) moving up to 16 or 32 bit uC's is a good idea. You can even run really compact versions of embedded Linux on some of these. I've played with chips from TI (MSP430 family, if I remember correctly) and others. But first steps are better taken with simpler 9 bit MCU's. It is important to learn what you can with just a few bytes of code and data.
I am currently teaching my son embedded programming using a number of tools. We started out with Lego Mindstorm and their graphical programming approach. That didn't last long. I am sure there are people who love it, but I find it incredibly restrictive. It is very, very difficult to express and describe complex logic with icons and wires.
I've had the same experience at a much higher level. When developing with FPGA's you have the option to use graphical (schematic) tools to describe functionality and have the compile infer circuitry. When I was getting started with FPGA's I thought it'd be great. It didn't take long to realize that the graphical approach is limiting and hard to maintain. A few pages of Verilog (a C-like language used to describe circuitry) is light-years away in terms of usability, expression and maintainability.
Digressing. So, we moved to RobotC from Carnegie Mellon:
Very cool. Neat way to learn some level of embedded programming without having to go too low level. You have high-level commands to run the motors, read sensors, buttons, etc. It makes it easier to focus on learning the basics of programming, robotics and algorithms.
I also have him cranking on Java through the use of another wonderful too: GreenFoot, from the University of Kent.
I couldn't recommend GreenFoot more as a really neat way to learn about OO programming and programming in general. Yes, I know, I may have sounded like I was jumping in the anti-OO wagon in earlier posts. That is not the case. I will use any tool at hand and happen to like OO very much when it makes sense.
There are tons of very nice tutorials for GreenFoot that have you writing mini games within a few sessions. Very, very cool tool.
The next step is to move him to a PIC or SiLabs development board and go back to pure C. Start from scratch and write the code to do things like blink LEDs, sense switches and switch arrays, run a double-buffered serial port, etc.
The first project is always something like making a single LED blink.
Then you move on to making eight LED's light to reflect an internal 8 bit value.
Then you turn that value into a counter and you use various techniques to make the count visible. A uC running at 20+ MHz can count so fast that the LED's would simply look like a blur. A beginner might use loops to waste time between output events in order to slow down the count. Then you move on to using timers and then timers with interrupts.
The next step could be to build a simple clock or stop-watch with a set of seven-segment LED displays. Now it starts to feel like a real project.
After that, maybe an RC servo driver and then a multiple RC servo driver. Then make it so that it can be commanded through a serial port.
These are just a bunch of ideas. They have a progression of design complexity in both the electronics and software. With the right guidance and tutorials there's a lot to learn right there and we are not into RTOS's at all.
Eventually you get to a point where you need to start doing more than one thing at a time. This is where one starts to learn about time-slicing the microprocessor in order to do a little bit of one task and then the next and so on. One common pattern is to break-up execution into, say, 1ms slices and hand that millisecond, if you will, to a given task. The task would have to quickly do something and then give control back to the scheduler so that the next task can get a shot. There are a number of ways to do multitasking, each with its own pros and cons.
Example: Say you are building an auto-pilot for an RC plane or helicopter. You are going to need to monitor commands from the pilot (via radio), temperature, voltage, acceleration, gyroscopic and magnetic sensors as well as possibly a GPS receiver and other resources. And you are going to have to do this very quickly in order to create the illusion of doing it all simultaneously. This is where multitasking and an RTOS come into play.
Multitasking doesn't necessarily demand an RTOS. I've done plenty or projects where lots of I/O is being services without a real RTOS in place. There are well understood techniques to do this sort of thing.
The field is vast and can be very interesting and rewarding. I'll probably have my son go through the above (not the auto-pilot, that was just an example) and the task him with something like building a sprinkler controller or some such project entirely on his own at some point.
I am hoping that by the time he gets to college he will have programming in his DNA. This will allow him to focus on higher-level work. I seems to be developing a real interest for robotics, which could lead to AI and other interesting fields of study.
Incidentally, I am doing all of this because, of course, I want to teach my kids everything I know. I am also very interested in teaching other teenagers about programming, robotics and technology in general. So, I am using my oldest son as a test subject to develop the framework for a potentially neat tech summer camp for teens to be launched here in the Los Angeles area next year. We'll see how that goes.
Thanks again for a great post. Not sure this really adds anything to the conversation, but felt that I should thank you again. For what its worth, I never thought you were dismissive of OOP; your original post seemed rather clear, if rather alpha in tone, that you thought the important thing was to use the tools at hand.
Funnily enough I was asking for the same reason that you had in mind: I have a child with an interest in robotics who recently hit the the limits of Mindstorms. Alas it has been 15 years since I last did any embedded programming so I am rather out of touch. (Indeed it has been a while since I have done any programming.) The silabs dev board seems to be an amazing deal in terms of the amount of peripherals and documentation available, thanks for pointing that out. I think I shall get one and have a fool around, it looks like great fun!
It still is, though "Starting Forth" is probably a better starting point. There's a variety of Forths available today, like GForth: http://www.gnu.org/software/gforth/
Interested programmers might want to check out Factor as well; it's heavily inspired by Forth: http://factorcode.org/
Why is this comment ranking above the much more insightful and beneficial thread started by malandrew? It's partly a question of how HN works but I assumed comments with the highest karma filter up to the top? If that's true, I must also question the community: why has this received so many votes?
It only serves to make robomartin look like an idiot by maki g fun of him. He is most definitely not an idiot and this commenter makes it clear that they haven't read the entire comment.
I have a lot to take away from his comment and from the thread I mentioned. I'm sure there are a few here who will also have big take aways. It's content and comments like these that make me love HN. The negativity from the commenter can spiral out of control and fatally harm a community if endorsed. I've seen it happen before to another community I deeply loved and it pains me to be reminded of such negativity.
While I agree that the form of this comment was too harsh (so, your second paragraph largely rings true for me), I was wondering why robomartin's comment was at the top in the first place: it starts with a general insult to commenters ("C'mon kids. Not again.") and then continues with a "proof by how much money I made using it" against the apparent strawman "if you don't use OOP you can't do things that are useful (such as make a lot of money)".
The article that Rob Pike was responding to, and Rob Pike's response, were about whether people who use (or do not use) OOP somehow fundamentally better understand "the nature of computation". There are people out there, some of whom I have on my list of "personal heroes", whom are quite clear when asked that they know very little about computation or computers, and yet they wrote a bunch of code and made tons of money anyway; that is simply irrelevant to a discussion about understanding "the nature of computation".
(Yes: I have purposely ignored all of the mentions of an improved CS curriculum in my primary comments here. All of that conversation was off-topic for the argument being made by both the original paper and Rob's response: it doesn't contribute in any way to the argument about whether knowing OOP or not knowing OOP has anything to do with how to best understand "the nature of computation", if nothing else as the things you learn first are often, in pedagogic contexts, either approximations or downright incorrect, and are later updated or replaced by later teachings.)
Thanks. The way I look at it, those who read HN and can filter out the BS don't need anyone to tell them when a post is bad or useless.
And, yes, I have been an idiot on HN a few times. It happens mostly when I, against my better judgement, choose to enter into political discussions. I should not do that. I am trying hard not to discuss politics on HN. My views come from years of having skin in the business trenches. You'll never never find me self describe as a democrat or republican. On HN my views tend to run contrary to the <conjecture>mostly liberal leaning</conjecture> audience here. It's really easy to come off as an idiot if you are not careful.
We are all idiots at something.
When it comes to technology and using it to create products and build a business I am nothing but pragmatic. You use what you have at hand and make the best of it. Case in point: Objective-C. I don't like it. Yet, if I wanted to write native iOS apps it really is the only choice. The frameworks that try to avoid it are always fraught with issues. So, I learned it and use it every day. It's about putting out a product and not about polishing the wrenches, pliers and screwdrivers in your toolbox.
That's not to say that if a new approach or better tools surface I ignore them. Not so. I love good tools.
Because you keep playing the "100s of 1000s of dollars" tune, oblivious to the fact that he only talks about making said amount with his assembler program.
He doesn't write that rewriting it in C made him 100s of 1000s of dollars -- just that he rewrote it to be easier to maintain. And VB was just the front-end for said project.
Plus, all the rest as mentioned as tools, without mentioning money at all ("plenty of other projects where made in APL, Forth, Lisp" etc).
Then you go on to miss the rest 70% of his comment, which isn't about money at all, but discusses a rather "hardcore", old-school way of teaching programming.
Arguing 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.
Yeah. 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."
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.
Oh I worked with the guys he's talking about. They never start with data, they never even consider talking about data. Their world is the world of categories and taxonomies. They treat everything as an organism and favor class diagrams to data flow charts.
Rob Pike is insanely good at what he does. But along the way he maintained insane ignorance about everything he doesn't do. Unfortunately, he forgets to confine his opinions to the important areas where he is knowledgeable, and has grown defensive about the world straying away from his domain. Hence the nonsensical rants against OO and type theory that put incoherent words in the mouths of his straw men.
Contrast to someone like Simon Thompson, toiling for decades on a marginalized language (Haskell) for decades, yet never wasting time insulting people who ignore his work. In fact, he praises his team for avoiding the distrsctions and hassles of attaining popularity before his work is perfected
Part of the reason it comes up frequently is that a large number of educated, experienced programmers have decided that a toolbox without OOP is a better toolbox, than a toolbox with OOP.
But, it is difficult to throw out a bad tool when there appears to be no alternative that delivers its benefits. When that happens, when a tool is devised that delivers what OOP delivers without the problems -- such as the diamond problem, or the problem of having to decide "where" to put functions, or the problem of generic functions of more than one argument -- then at that time those very problems will become much easier for everyone to acknowledge.
The same thing will happen to classes and synchronous message passing, that happened to inheritance. In that case it took a while but an alternative came in the form of interface subtyping or predicate based subtyping, and then it was easy to see that inheritance was more trouble than it was worth.
My approach is a bit different probably because I've done a lot of work across a range of disciplines while using different tools. I have yet to run into a problem that was unsolvable due to the tools or language selection made. I don't think the tools or languages have ever caused undue delays, bugs or unreliability in any projects I've had part on. From robotics and low-level real-time embedded to image processing, DBMS and even hardware development (Verilog, VHDL). Not once have the tools and languages been brought up as an issue.
In my experience most problems come from bad design, bad programmers, terrible data representation, incomplete specs, bad management and a myriad of other issues.
Don't get me wrong, I am first in line for a good-solid discussion on how to properly split a bit in two. However, when it comes to the business of making money by creating products that involve some kind of software, well, pick a tool based on experience and focus on delivering a solid product. No excuses.
- People who went to moon: top 1%
- People who made the "vessel": top 1%
- People who wrote the code: top 1%
- The process of the development: Exacting
- The funding available: Lavish
...
Tools in your toolbox. Yea why not. I've always been an OOP composition-only guy. It was always the model that made the most sense to me. It's efficient and clear. I'm amused that just now people are coming out and saying that this is the best model. On the other hand, I've had a project once where I needed to apply a different function to different objects. No need for function pointers with polymorphism, much much easier so I used that. I'm still against templates to this day, although I use some parts of the STL sometimes when I'm lazy ^^
Sure. Sorry for the late reply, I go to parties.
I have nothing against having more power at compile time. It's just the way C++ does it that I don't like. It's like a language within a language. I prefer the way it's done in D. Check the examples if you haven't, it's compile time done right in my opinion.
I understand, and agree with you about D templates. Static polymorphism and generic algorithms are too useful to give up, so of course I wouldn’t do away with templates; but there’s little reason for them to be the underpowered, syntactically hairy functional programming language that they’ve become.
In the past I worked on a language where there was no distinction between compiletime and runtime code. You simply asked for something to be evaluated at compiletime without needing to change the source; there was the stipulation that it ought to terminate, though, else your program would never compile. ;)
In school I was in love with APL. I got a chance to drop Fortran and sub it with an APL class (which my Physics prof insisted I take) and it was absolutely fantastic. What an eye opener! It kind of screws you up because --as an early stage programmer-- you can easily look at other languages and start thinking that everything else really sucks. Of course, that's not the case.
My list matches yours in probably a slightly different order. I love C because it can be very low level and also allow you to write high level code efficiently. I have written code for countless embedded projects with C as well as used it to optimize computationally intensive portions of iOS applications (where Objective-C would make things 1000x slower).
Forth? I've mostly done robotics with Forth. Wow. What a language. It's a really amazing feeling --if you ever get the chance to do it-- to bootstrap an embedded system using Forth. A little assembly and very soon you are off and running. Write you own screen editor, etc. I had a chance to do that once. It was a blast. There's nothing like writing your own disk controllers and other driver software. Forth makes it possible without a huge amount of pain. Neat.
I have a friend who sold his company many years ago for about $20 million. He had developed one product. It was based on a set of off-the-shelf Z80 STD cards in a frame along with a few custom cards. The software running the system was written entirely in Forth. No OS, just finely-tuned Forth from the ground up. No graphical interface either. The thing was operated via a terminal over RS-232 or RS-422.
So, yeah, lots of very lucrative niches out there in industrial, medical, defense and other markets that have nothing whatsoever to do with creating websites or mobile apps. You just have to find them and jump on them. I've been lucky enough to hook a couple of those over the years, though not as "juicy" as the niche my friend found.
I wonder if the 'net and mobile craze is creating a situation where CS grads are coming out of school having nearly no idea that there are very interesting worlds out there that lie outside of those domains?
It isn't necessarily about being in "hard" industries. Frankly, sometimes it is about just about the proverbial right-place-right-time effect while having the drive (and the balls) to jump into a problem face-first after having identified it. That was the case for my friend and my own experiences. He saw a problem and dove right into it at the expense of everything else. He didn't know how big this thing could be when he launched into it. He developed a good solution and it turned out to be a hit.
In my case I've had weird things come across my table. Some have been total wastes of time. Some have been extremely lucrative. For example, I was asked to build a protocol translator that would receive commands over RS-232 and convert them to a different protocol out of a second RS-232 port and do this bidirectionally. I thought it was a one-off. I built it out of mostly existing hardware and sold it to the company that contracted me to do this for $3,000. Then they came back and ordered another 30 at the same price. My COGS was probably no more than $200. Imagine my surprise.
There are many areas of industry ripe for disruption. Some harder than others for various reasons. This is why I think it is important to be exposed to a lot of corners of the tech world. I'd like to say that I planned what I did, but that would not be true. I was fortunate enough to bounce around a number of areas and learned from all of it.
Take, for example, the CNC industry. After cobbling-up a number of DIY CNC machines I decided to spend my time on what I was actually trying to build rather than getting derailed making "amateur" manufacturing equipment. So, I leased my first Haas VF-6SS vertical machining center. I didn't know the first thing about running such a machine. I kind of knew G-code, but not really. Things are far more serious when you have a 20HP spindle and a table that can move so fast it's scary. Anyhow, after getting up to speed on the technology and being very comfortable writing G-code as well as developing models on Solidworks and programming the machine using CAM software it became very obvious that this industry is ripe for serious disruption. I won't go into all the details here. If you don't have the context of having run these kinds of systems it just won't make sense anyway. Let's just say that they are still in the stone age and it would be fantastic to see someone bring them out of the cave. Tough industry to crack. Lots of crusty non-tech people to sell to.
> I wonder if the 'net and mobile craze is creating a situation where CS grads are coming out of school having nearly no idea that there are very interesting worlds out there that lie outside of those domains?
I don't think so. I think its just making the world more accessible to people who normally wouldn't have entered.
I myself was always interested in CS / Programming, but never had the discipline to learn it. Web stuff got me involved later in life, and now having the discipline, I"m slowly working my way down (as it were..). I think those niche's become apparent to people who, being interested in the subjects, just keep digging.
If you know this, why is he bothering to say that he declines to give information about what he's accomplished? Why explicitly claim something's a secret if it isn't actually secret anymore?
Is it really so hard to understand that there are projects people don't like or can discuss in public?
This does not mean that it's not public knowledge that lots of people have made substantial amounts of money on software written in assembler. Most games written in the 80's for example. Lots and lots of business software written in the 80's and before.
There's nothing unusual about that.
And lots of software people won't want to or be able to talk about in public.
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.