"People should be required to learn the basics of programming first. They should start with immutable data objects"
Immutable data objects and all the stuff are not the basics of programming. They never were. Unless you single-handedly redefine the meaning of "programming".
The whole text you just wrote is full with dumb self-praise and deprecation of others; based on worship of principles that were never proven to produce good software, or any software at all. This receiving upvotes makes me sad.
There's no need to redefine programming. There are essentially two fundamental ways to approach a program: what it does (coming from EE) and what it means (coming from math).
If you're coming from the first perspective, than mutation is fundamental. Registers are always changing in value and everybody likes self-modifying assembly.
However, if you're coming from the second direction--which is at least as fundamental as the first--the basis of computation does not involve mutation. This is where the lambda calculus comes in. It's the abstraction that underlies most of the mathematically well-behaved languages. And in the lambda calculus, as well as a bunch of its popular variations, there is no mutation.
From this second perspective, immutable data is a basic building block of programming. Essentially, all you have are functions that can bind names to arguments and be applied to each other. It's a surprisingly simple and elegant model.
There are some other popular models of a computer program like the SKI calculus. However, it's easy to translate between the lambda calculus and SKI calculus, so for the purpose of this discussion they are effectively the same.
So from a more mathematical standpoint, functional programming is more fundamental than imperative programming. Redefining the meaning of "programming" is not required!
Programming is about writing some code that does useful work. Okay?
When you argue that programming is something else, you're doing just that: redefining.
Because from the first days programming meant building computational devices or programming programmable devices. And those have changing state, and then they have machine code, which mutates state.
It's how it always was and now some people want to redefine it but I say no to them. Programming is not CS. Programming is about producing programs. Historically and statistically programs are written to work by mutating their state.
Turing machines have mutable state. The lambda calculus does not. Yet any algorithm which can be expressed by one can also be expressed by the other. We have proof that state is merely an implementation detail, which happens to be widespread in today's hardware because we figured out how to implement it at scale.
Programmers need to understand the difference between the abstract algorithm they're trying to express and the representation they've chosen (and the ones they didn't) inside the computers they're using, just as astronomers need to distinguish between the stars they study and the measurements coming out of the various telescopes they can choose.
Your hard-line stance is a little bit too far IMHO. That inanimate matter programming is all about manipulating also has no notion of objects or object orientation... or (for the most part) methods, fields, functions, procedures, arrays, modules, encapsulation, interfaces, garbage collection, databases ... and so on and so on. All that abstraction exists to make programming easier for humans to grok, and for teams to deliver some "useful work".
To borrow from Robin Milner, who worked on ML: "Types are the leaven of computer programming; they make it digestible." All that abstraction makes programming more digestible, or more palatable. Functional programming is just some more abstraction to make it more digestible. To say that it's a redefinition of programming is just a distraction, since programming has already been redefined.
Also, you're right that CS isn't programming, and viewed in a certain light one could argue CS is basically just a branch of math. But on the other hand, programming without CS really wouldn't be that useful. It's just not a helpful distinction to make in this way.
I would argue that objects, methods, fields, modules, encapsulation, interfaces, garbage collection, databases are not the basics of programming either.
Good things to have, but are not basics of programming. So, teach/learn them later in the cycle.
Basics of programming are variables, branches, arrays, loops and simple I/O. You can go a long way with these. And you can explain those to 6 yr old child.
Recursion is fundamental. Reassigning to a bunch of variables in a loop is a poor imitation of recursion that caught on because fifty years ago we could barely afford call stacks and hadn't invented tail call optimization. The better our hardware and our theory gets, the more of these shortcuts we can and should leave behind, so that we no longer need to try to preserve the illusion that programs run sequentially and state is globally consistent.
Everything we do in any high level programming languages is an illusion. In fact, even assembly language is an illusion. The only thing that isn't an illusion is building a computer out of nand gates, and the like.
In my education, we STARTED with functional programming, and eventually we built real microcoded computers that we designed ourselves out of nand gates and adder chips. And, yes, I mean REAL chips with lots and lots of wires on a real physical breadboard.
Is a nand gate, the fundamental building block of all computers, is that functional? You bet your ass it is! State only comes by using this functional component and feedback to make a flip-flop.
Your premises are all wrong: My education started with FUNCTIONAL programming. We then learned how to build OO on top of functional programming, using only closures and single mutation operation: variable rebinding. We then went on to design and build our own physical computers out of chips and wires, starting with the fundamental functional component: a nand gate.
You do not program nand gates. You program your cpu. Last time I've checked, it's not Reduceron II but instead AMD64 or ARM cpu. One which is inherently imperative - it's von neumann machine. It has registers, shared writable memory and stuff.
First of all, as I have mentioned, I have implemented programs using real nand gates, with my very own hands, using copper wires and microcode.
Furthermore, my CPU is made out of nand gates, so yes I do program nand gates every day.
If you deny this reductionism, then I deny your reductionism to the CPU. I don't program the CPU--I program the Scala compiler. My Scala code doesn't run on an AMD64, or an ARM CPU, it runs on ANYTHING, past, present, and future for which the Scala compiler has been implemented. In the future, my program runs on DNA or on neutronium Tinker Toys.
Traveling into the past, rather than the future, I have written Lisp code and then compiled it to microcode.
P.S. I don't trust the opinion of anyone who hasn't built a computer out of nand gates, as clearly they are out of touch with the hardware. Have you built your own CPU from scratch?
What I see in your comments is the constant stream of I's.
I, me, I did, I studied, I think this, I think that.
Guess what? Nobody cares that much except for you.
When talking about basics, we should consider the least common denominator of all programmers' knowledge.
You can reason that the basics should be different, but what if you are wrong? You are a smart guy who loves scala, but there are other smart guys who consider scala a failure, for example. And there are guys smarter than you and me who just do it all in C because they can't be bothered with abstractions, and FP is an abstraction in the end.
People are different, and if you think that you're such an unique yet the most important snowflake - why?
Nobody questions your ability to write successful FP code. So what? What does it prove? Nobody even questions that.
But there are people who write FORTH. And there are people who write Prolog. Both groups claim they get much bigger bang for the buck than anyone else. Why do we listen to you and not them?
You keep expressing your opinion. Please tell me how there is no "I" in your opinion. I see two of them: o-p-I-n-I-o-n.
Also, I never said not to listen to any of these other folks. It was you who told me that I didn't learn to program in my first programming class because it started with functional programming as the most fundamental concept. That statement was offensive and false, and I am now demonstrating to you why you are so wrong.
This is not to say that there are not many possible reasonable approaches. I think the one I learned was great. Are there better approaches? Who knows? Certainly not you.
SICP is overrated to whom? For me, it was the most profound and wonderful educational experience of my life. I found it to be profoundly inspirational and educational. I found it to be beautiful, uplifting, moving, rewarding, and just incredible in all sorts of ways that I cannot even begin to express. And it pumped up my joy of learning in a way that survives to this day, decades later. There are not enough words in the English language for me to express how much this course meant to me and how much intellectual joy it provided me.
Of course, YMMV.
As to what I should and should not do, who are you to tell me that?
Mathematically, immutability is more fundamental than mutability, as the mathematical models for computer programs all model mutability in terms of immutability.
Pedagogically, either approach seems to work. Which one is better? For me, the functional approach was FAR superior. The best pedagogical approach is almost always the one that is the most inspirational, and SICP truly inspired me. I found it to be beautiful, whereas I found the more traditional approach to be merely workmanlike.
Having received both kinds of education, I'm qualified to say which worked better for me. Is my experience representative? Well, lots of people who have learned via this approach seem to agree with me. Zillions of people LOVE SICP. On the other hand, zillions of people swear by imperative approach. The best approach then might vary from individual to individual. There may be no one-size-fits-all education. But I suppose that we cannot rule out that future education researchers might show that on average one approach is better than the other. The Logo people claim to have done such research for children, and they settled on the functional approach. But children are not adults, and I'm sure their research did not reach the level of proven fact.
As to which approach results in engineers who produce the highest quality software, I believe that having a deep understanding of the functional approach results in higher quality software, and the best way to acquire such a deep understanding is to start with it from the very beginning. I am not prepared to prove this assertion, but neither are you prepared to prove its contradiction.
As to which approach is closest to the hardware du jour, who cares? That has nothing to do with anything, unless you are writing in assembly language. I will point out, however, that today's hardware comes with multiple cores, and this tend is only likely to increase. Functional approaches to programming result in very natural extension to multiple cores, while with imperative styles, not so much.
If we were talking about teaching programming to kids, I actually agree with you. It wasn't clear from the top-level comment that started this thread if that's what we were talking about though. I thought that we were talking about intro to CS for freshmen in college. That's where I think it might be valuable to start with functional programming. Note: might -- I really don't know.
"People should be required to learn the basics of programming first. They should start with immutable data objects"
We weren't talking about freshmen in college. And talking about freshmen in college is not so interesting because they agreed to listen to bullshit (information of questionable utility) by joining college.
It's much more interesting to talk about kids or adults because they have the choice.
It's used to do all sorts of interesting things, including real economic modeling. I.e., I've seen it used by real economists.
When I first saw NetLogo being used by an economist to demonstrate an economic model, I thought it strange that the NetLogo people had re-used the name "Logo", a kid's programming language, for something that is a serious tool used by professional researchers. It took me a while to figure out that it is the same Logo! And those kids, I guess, grew up, and decided to do something real with it.
R is also a functional programming language used to do very real work.
The inventors of C++, Java, Perl, Python, Erlang are trying to solve problems basic to many other domains. So it depends on what you define as basic. What you seem to define are pre requisite to start learning basics.
Computer science: the science behind making computers work.
Hacking: getting shit to work in a fast manner/making something faster.
These are two orthogonal philosophies that give you very different perspectives, and they are both labeled as "programming."
So, how about this: the next time you want to deride someone's opinion because they are misusing a term, why don't you clue the rest of the class into what your definition of the term is?
Coming off conceited doesn't make him wrong regarding CS curriculum. He believes that people should have strong underpinnings in functional programming principles before learning oop. I think fp plays off required math classes pretty well.
Consider function composition which is commonly taught in required pre-calc courses.
f(x) = ......
f(g(x)) = ......
I will submit that first-class functions map more directly to function composition than polymorphism does. In turn, this background helps new developers have a stronger understanding of polymorphism and when to use it.
Whether or not fp principles were ever "proven to produce good software, or any software at all" is besides the point. What's more important is whether or not fp ideas make for better DEVELOPERS. Maybe they do.
Okay, but CS is not programming.
After all, programming is not CS.
And by the way, I don't think anybody should first know anything before learning how to program. Programming is like breathing. Do you need to study anything before you breathe? No you don't!
So anybody who argues that you should learn all sorts of not useful things before having the privilege of trying useful things, is a strange person indeed to me.
One is a semi-automated bodily process necessary for extracting oxygen from the atmosphere, and the other is writing instructions in strictly defined languages to control the resources of computer systems.
Other than a contrived emotional connection you might make between the two, they aren't comparable.
You assume that you live in a physical world but you live in information world for real.
I think you do, and you will increasingly do so as time passes.
So, being able to control information flow becomes as important as controlling air flow. Yes, you don't die by being unable to do so for five minutes. You don't live that much either.
>Immutable data objects and all the stuff are not the basics of programming. They never were. Unless you single-handedly redefine the meaning of "programming".
Immutability was considered to be more fundamental when I took my first programming course at MIT. I received a very good education.
We, of course, eventually moved onto objects with mutable, but they were definitely considered to be more dangerous and less fundamental.
It means the course wasn't about programming.
Maybe it was misnamed or maybe you approximate its real title.
Me, not really interested in what people who never wrote any widely used software consider more what and less what.
Programming is what happens (and always happened) on top of computing devices that have, you know, memory, registers and opcodes. It's just the hard truth. That's what programming is. Writing code that compiles (interprets) as machine code for said computing devices. All other kinds of stuff - not programming. Call it CS, call it whatever.
Parent of your comment might have been talking the Structure and Interpretation of Computer Programs. Likely it needs no introduction, but it is absolutely about programming, and goes right down the rabbit-hole to implementing interpreters, virtual register machines, and a compiler for said machine. Yes, the first couple of chapters is mostly purely functional, but that doesn't detract from the rest, which includes mutable code as well.
Really, I don't know why you're so hostile to this pedagogical approach. Do you have experience with teaching CS and/or programming, and have found using C or assembly or following some kind of Java school curriculum more effective? Have you found teaching functional programming first deficient? Or maybe you're looking at this from the perspective of an employer and have had to deal with hiring new grads who are brain damaged by functional intro CS classes?
I, for one, welcome this kind of experimentation or change of pace on the part of CS educators like Robert Harper at CMU (http://existentialtype.wordpress.com/). It can't be worse than what I had (mediocre, big box state Java school)
Yes, the class was SICP. I can't say enough good things about how it influenced my still-forming mind. I went to MIT because I wanted to study black holes and neutron stars, and after this class, I learned that there was something even cooler than that!
I have experience suggesting that to learn programming, you write programs. The hard way, how Zed Shaw calls it.
And when you have enough experience in writing programs with limited success, now you are ready for some theory. You know already to separate bullshit from useful things, for one.
When you never wrote any programs, you would not be able to do that separation, which is bad for you.
Where do you get the crazy idea that you can't write functional programs? Or that SICP didn't have you write programs? SICP didn't start off with "theory"--it started off with PROGRAMMING. The programming that you did at first, however, just so happened to be recursion-heavy functional programming. The class then taught you how to build your own mutable object system out of the functional primitives, using closures and messages.
I clearly got a far better introduction to PROGRAMMING than you did. E.g., I learned how to add an OO subsystem to a functional programming language in my very first programming class.
SICP was a lab class. It nearly killed me with all the programming I had to do. It was billed as a 15-hour-a-week class, but 40 hours a week was more like it. I lived in the computer lab during that class. The intense programming assignments began on the first day, and continued all the way through to the end.
Is there any other way that you would like to continue to advertise your unsubstantiated bias and ignorance on the issue?
And there you go again, as the OP did. Self-praise, deprecation of others. What happened to humility?
You can write functional programs. You can also write concatenative programs and logical programs. Why not we suggest that people should be required to learn about beating around the stack and predicates first?
What makes functional programming so special? The hubris of its followers?
I can tell you now what makes imperative programming special. It allows all other kinds of programming to function. And it's the most used kind - by large. So, sorry. Basics are just so big that they won't fit any FP concepts. Loops, variables, procedures, branches, arrays. There you go. Be blessed and do not sin.
P. S. The whole concept of immutability linguistically depends on the default of mutability. Where did that default came from? Math does not have the concept of mutability. It came from imperative programming!
So, we are told that people should learn basic things, whose definition depends on understanding non-basic things.
> And there you go again, as the OP did. Self-praise, deprecation of others. What happened to humility?
That's surely the pot calling the kettle black! First of all, I didn't praise myself--I praised the education that I was fortunate enough to receive. It was first rate. Furthermore I'm not disparaging you because it's necessarily bad to learn imperative programming first. I'm disparaging your willful ignorance, and your knee-jerk assertion that people who learned to program in a different manner from how you learned, didn't learn to program at all.
Your attitude here is offensive and counter-productive.
Regarding what makes functional programming "special" is that it results in code that is easier to reason about, and consequently to maintain and adapt. It also increases the ability to write "reusable" code, which can then be used unmodified in future projects.
On the other hand, FP is not a magic elixir. It is just one of many techniques that a good software engineer should understand. At MIT, when I first was taught to program there as an undergraduate, it was, however, considered to be the most fundamental technique.
Victor Pelevin, a great writer, noted in his book Empire V:
(my translation)
"The main idea that person tries to convey to others is that he has access to much better consumption than they would think. At the same time he tries to tell them that their way of consumption is much less of premium than they were thinking."
And now you're telling me that you had access to much better education and that my education surely sucked ass. It's like the part from Borat's Kazakhstan hymn about Uzbekistan.
I do not argue that FP results in code that is easier to reason about. I'm just aruing that you should not call FP concepts like immutability and referential transparency "basics of programming". Programming is big and basics implies something very small. The kind of taking with you to an uninhabited island.
Demanding everyone to pray to functional gods before they are allowed to learn any programming, as OP implied, is a naive and dangerous dream. You're not alone in this, please behave.
> And now you're telling me that you had access to much better education and that my education surely sucked ass.
Your education is obviously lacking because you say uneducated things. It's as simple as that.
For instance, you asserted that if someone's first programming class started off with functional programming, then they didn't learn to program at all. That assertion is offensive, uneducated malarky. The quality of your education speaks for itself.
As to what people should have to do before learning any programming: no one has implied any such thing.
"As to what people should have to do before learning any programming: no one has implied any such thing."
"People should be required to learn the basics of programming first. They should start with immutable data objects, referentially transparent functions."
You either lie or "should" means different thing in your English than "should".
As to that quote, firstly you give it stronger weight than it was intended to convey. It was someone's opinion on the best way to educate, not a statement about use of force to allow or disallow anything.
More importantly, that quote is neither here nor there in the discussion between you and me. I did not utter it, you did not utter it, and the OP did not utter it. Therefore it is irrelevant without you having alerted me to what particular bee you have in your bonnet.
Additionally, it almost certainly true that any first class in programming should start with numbers, which are immutable data objects, and mathematical functions, which are referentially transparent.
E.g.,
def inc(x): return x + 1
Consequently, there is nothing at all incorrect about that assertion.
In any case, I am done with this conversation, and in conversing with you. You have a very rigid and myopic and, yes, ill-educated opinion. I do not wish to converse with you further.
>It means the course wasn't about programming. Maybe it was misnamed or maybe you approximate its real title.
Oops, my mistake. I took you for a serious poster, not a troll.
The class I took at MIT (SICP) and the textbook that was used are world-famous, and it was certainly a programming class.
As to having "never written any widely used software": Among other things, I wrote the software that was used to configure a NASA space telescope (Rossi X-ray Timing Explorer), from which about 1,000 peer-reviewed astronomy papers were published. I've worked on brain surgery software (3D Slicer) and now I work on software used for doing RNA Interference-based cancer research.
But I guess you've made your point: All that is just "Computer Science" noodling, not real programming. So, sure don't listen to what I say.
"Me, not really interested in what people who never wrote any widely used software consider more what and less what."
This argument is getting really really really old. Anyone with 5 minutes and a working internet connection can find hundreds of successful widely used applications written with a focus on immutability, either at the language level or the design level.
The people who write software with focus on immutability are not the same people who advocate pushing immutability down the students' throats. For example, I do write some functional code, but pragmatically.
And even after that, the total share of functional code is negligible. Sad but true.
Immutable data objects and all the stuff are not the basics of programming. They never were. Unless you single-handedly redefine the meaning of "programming".
The whole text you just wrote is full with dumb self-praise and deprecation of others; based on worship of principles that were never proven to produce good software, or any software at all. This receiving upvotes makes me sad.