Programming Paradigms for Dummies: What Every Programmer Should Know
lambda-the-ultimate.org
lambda-the-ultimate.org
"It seems that we need to have and not have named state at the same time. How do we solve this dilemma? One solution is to concentrate the use of named state in one part of the program and to avoid named state in the rest. The bulk of the program is a pure function without named state. The rest of the program is a state transformer: it calls the pure function to do the actual work. This concentrates the named state in a small part of the program."
This very closely resembles the philosophy behind Clojure.
This chapter is fascinating. Or rather has me fascinated with Oz. However, I see that Mozart was last updated in 2008.
This is a god damned nightmare if you want to actually use the language. Why? Because each of these types has separate methods and syntaxes that are used for manipulation.
Go on, try to write something that is generic, I dare you.
Oz is, without a doubt, the best example of why you should not try to be everything to everyone that I have ever seen.
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.
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...
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.
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.