Does anybody here really care about any of this stuff? I program computers for a living, and I couldn't even muster the energy to page-down through that mess of tables and graphs.
Does anybody here really care about any of this stuff? I program computers for a living, and I couldn't even muster the energy to page-down through that mess of tables and graphs.
Yes.
> I program computers for a living, and I couldn't even muster the energy to page-down through that mess of tables and graphs.
There are a lot of people who share your view. It is no coincidence that there is also a lot of crappy software out there.
Interspersed among "all those tables and graphs" that you could not muster the energy for are things called "words." Those words convey meaning. You might want to try to understand that meaning before dismissing "this stuff" as not worth caring about.
The author, peter van roy, has written a book, ctm, that many consider the successor to sicp, and created a programming a programming language, mozart/oz, that is the most advanced and well thought ever (it's descrined as almost like magic on it's homepage).
In 1995, I was asked in an interview what it meant to "deference" a pointer. I hadn't the first clue what this guy was talking about, despite having 5 years of self-taught C and C++ under my belt at that point, much of that time spent deferencing away happily without a fancy term for it.
Your point about c and c++ kind of illustrates my point, I think there are very few people who should ever be programming at such a low level, if more programmers were to thoroughly familiarize themselves with the 'abstractions' that have been discovered, that mistake wouldn't be made.
> Your point about c and c++ kind of illustrates my point,
> I think there are very few people who should ever be
> programming at such a low level...
Certainly, one can be excused for programming in C in 1995. You realize that there weren't many alternatives back then, right?Substitute "Factory Patterns" if it helps you understand what I'm talking about. Or CTM or SICP.
I'm all about working at a nice high level of abstraction. I'm just not particularly bothered to know the technical term for whatever abstraction I happen to be using at the moment or its storied history.
I see something like "Figure 2, Taxonomy of Programming Paradigms", and I can't for the life of me understand the mind of somebody who'd consider that chart essential learning for a programmer.
I didn't mean to imply you directly, the question is why did the company you were applying to and the industry in general not 'see the light'. lisp,python,tcl,prolog,sql existed before 1995.
Personally, I disagree with the pattern languages of object oriented design, they aren't necessary if you know the full range of abstractions of which CTM and SICP describe (functional, relational, logical, constraint etc). The proliferation of these difficult to use OO patterns is another symptom of programmers not knowing enough computer science.
And if I'm ever back in 1995, I'll ask that guy if that's what he meant by "deferencing." :)
... I just don't want other people to be doing it on my Internet, so I'm going to complain when I see others doing it.
Seriously, what do you think you're adding to this conversation? That there are people who think they don't need that there fancy book learnins' is not news.
Basically, the community is trying to reject you—a person who has explicitly stated that they are not of the third type—like a foreign body.
"I'm sure we all agree that we ought to love one another and I know there are people in the world that do not love their fellow human beings and I hate people like that!" -- Tom Lehrer, "National Brotherhood Week"
As I stated in my first post on this thread, this article seems to not contain anything of value to a person building and growing an entrepreneurial startup. If I had to bet, it was the anti-anti-intellectual crowd doing the rejecting here, on the assumption that I don't like knowledge.
In order to create new ideas, you must play with the ones that exist and argue about how they fit together. In order to do that, you must rigorously and precisely define the terms you're working with. Otherwise, when you, for example, design a new programming language, you'll just end up inventing your own terminology for your business objects (i.e. closures, dereferencing expressions, A-Lists, etc.) and no one will be able to work with the results.
The first reason is that I'm kind of a wonk for this stuff. I like reading about the different languages and learning them. I have fun doing it; (I also program because I think it is fun, I could probably make plenty of money doing something else had i the desire...).
The second reason is that I believe you should use the right tool for the right job.
Firstly, by learning more paradigms I get more flexible with my programming in any language. I can pick the way to implement that will fit my solution best, rather than worrying about shoehorning the solution in my head into the wrong pattern.
Secondly, I can make better choices at the start of a project.
If I have a basic plan at the beginning of a project, I can decide based on the plan what will most likely make implementing it the most pain free. When your implementing language fits your problem domain perfectly, you can be incredibly productive.