"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 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.
Mmm... Computer Science... 39 pages of things that have no bearing whatsoever on what I do every day while building a startup.
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?
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.
Programming computers is about creating abstractions, if you ignored the abstractions others have methodically thought out - well, then you'd still be programming in assembly.
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).
Sure, but then most of Computer Science is common sense to anybody who's been doing it since they were a kid. I'm perfectly happy not knowing the CS terms for the things that I do or the design patterns that I use.
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.
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.
... 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.
I saw an article here a few months ago, about how there were three kinds of people—people who weren't really "interested" in anything per se; people who had one Thing that they spent all their time thinking about; and people who were interested in everything, and would readily consume information about any topic. Entrepreneurs tend to be the third type; that is one of the main reasons HN was renamed from its original title of "Startup News." (The term "Hacker" is, in usage, 99% similar to "someone who wants to know everything about everything, just for the sake of it.")
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 agree with your 3 groups, but if you read my post history you'll see that I'm firmly in the 3rd camp. Anything related to building and growing a tech startup gets my full attention here.
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.
Er, no—having dispersed interests focused around a central subject, like running a startup, is the second group. The point is that the people in the third group don't care that "this article seems to not contain anything of value to a person building and growing an entrepreneurial startup", because startups are just one of their (unlimited) interests.
"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."
You're being a hypocrite by doing that, if you're in third type, where you're interested in everything, you should be intereseted in a multiplicity of viewpoints as well.
Horsehockey. You can learn about a viewpoint and then reject it. Being interested in everything doesn't mean you have to give every idea equal weight.
"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"
Well, Peter Van Roy's CTM is not an impenetrable and jargon filled, it's actually easier to read than SICP, I think all programmers should read it at least once (I don't know peter van roy personally, I'm not shilling for him or anything).
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.
"Certainly, one can be excused for programming in C in 1995. You realize that there weren't many alternatives back then, right?"
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.
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.
"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.