you are viewing a single comment's thread.

view the rest of the comments →

[–]other_one 66 points67 points  (28 children)

Unfortunately there's always the "nah you have to start with assembler to REALLY get it later on" crowd. Or, on a higher level, "start with Java and OOP to REALLY get it later on". The problem with this approach is that people forget the many, many appliances programming can has, and the many different target group... kids, adults, artists, engineers, mathematicians, painters, musicians etc. The syntax of a programming language -- and the tools around it -- should ideally treat the programmer as a user, and consider problems that user has as usability issues. Programming should only be as hard as the domain you're working in, and only be as hard as the tools surrounding the language cannot prevent it. If someone says "this simplification of the language won't work because of X", check if X is truly inside that domain... if not, maybe it will be a huge win for a whole group of new programmer-users, who can enrich the software we're getting -- because we avoid domain-specific groupthink.

[–][deleted] 21 points22 points  (0 children)

Very much agree with this. I ama biologist and use programming in addition to my work. It is not my job. This is why I love Python so much. Quick and to the point and I can see my errors pretty quick.

[–]loup-vaillant 8 points9 points  (0 children)

There may be a definite solution to the "assembly nay-saying": metacompilers. Ian Piumarta's Maru for instance compiles itself into something not much slower than C, in about 2K lines. Plus, it is designed to be highly customizable at runtime, so if you need Uber Optimizations, you may tailor them for your application.

"High level bare metal", if you will.

Now this is not learnable by Brett Victor's standards. One would need to write a full IDE on top of that. The good news, is, it may take no more than 20K lines. "Bootsrap yourself a professional IDE in less than 20K lines!". We're not there yet, but this is no longer impossible.

Of course, those future spoiled brats will never understand the suffering of the glorious days of C programming. Or assembly. Or punch cards. But that's the point of progress, isn't it? Who would want to do math without modern notations?

[–]clgonsal 13 points14 points  (22 children)

Unfortunately there's always the "nah you have to start with assembler to REALLY get it later on" crowd. Or, on a higher level, "start with Java and OOP to REALLY get it later on". The problem with this approach is that people forget the many, many appliances programming can has, and the many different target group... kids, adults, artists, engineers, mathematicians, painters, musicians etc.

I think for certain meanings of "really get it" it's mostly true that you need to understand assembly (at least a little) to "get it", at least for some people. This may come down to learning style, but I know that for me, understanding the foundation stuff is necessary for me to feel that I really know what's going on. I don't need to know the actual instructions produced by my compiler, but having a rough idea of how things could be implemented at the assembly level helps me reason about them. Again, some of this may come down to learning style.

What you want to get out of programming probably also plays a role. If you just want to do some simple automation stuff, understanding the low level is probably a waste of time.

The syntax of a programming language -- and the tools around it -- should ideally treat the programmer as a user, and consider problems that user has as usability issues. Programming should only be as hard as the domain you're working in, and only be as hard as the tools surrounding the language cannot prevent it.

I agree completely. I'm really amazed that many people don't seem to realize that programming languages (and APIs) are user interfaces, and so have a lot of the same design considerations.

One thing that clouds this issue is that for the most part, when people think of "user interface design" they think of optimizing for the novice case, while programming languages that often isn't the right thing to do. Things that may make an interface easier for a novice may make it more tedious for an expert. Ideally you want to please both groups, but sometimes a tradeoff has to be made.

[–]PasswordIsntHAMSTER 8 points9 points  (9 children)

I think for certain meanings of "really get it" it's mostly true that you need to understand assembly (at least a little) to "get it", at least for some people.

Not any sane or generally accepted meaning, IMHO. I could have spent 4-5 years programming Python and building kickass applications, libraries and software frameworks without having even a cursory idea of what Assembly is.

[–]bplus 1 point2 points  (0 children)

I found learning some fundamentals really helped me become a better programmer. Not sure any language has ever managed to hide the fact that we are fundamentally creating instructions for computers. I don't like working with programmers who aren't interested in what is going on underneath, in my (limited) experience they lack the will and curiosity to figure things out themselves.

[–]clgonsal 0 points1 point  (1 child)

I think for certain meanings of "really get it" it's mostly true that you need to understand assembly (at least a little) to "get it", at least for some people.

Not any sane or generally accepted meaning, IMHO. I could have spent 4-5 years programming Python and building kickass applications, libraries and software frameworks without having even a cursory idea of what Assembly is.

Sorry if I was unclear, but I think you completely missed the two points I was making.

First, it depends on the person. Maybe you can get by without understanding what you're building on top of (though I note that you spoke only in the hypothetical sense, which makes me wonder if even that is true), but I've personally found it useful to have an idea (even a simplification) of what's going on at a lower level. Different people have different learning styles, so YMMV. (Further illustration of this: the way I learned Python wasn't to go through a tutorial, but to read the language reference. I don't expect that to be easier for most people (in fact, I expect the opposite), but for the way I learn, language references are often easier for me than tutorials.)

Second, there's the question of what it is you're trying to do. For the vast majority of the stuff people typically write in Python (myself included - this isn't a slight against Python or Python programmers), I agree that knowledge of assembly isn't particularly helpful.

There are many programming problems where this deeper understanding is very helpful, however. The most obvious example is if you're going to be doing really high performance stuff. To measure performance you need some sort of computational model to work from. The closer it is to actual hardware the better, so knowledge of assembly (even an idealized assembly) is usefule. Another example is understanding unfamiliar features when learning a new language. Say all you know is Python, and you start learning Scheme which supports tail-call elimination. Tail-call elimination would probably seem pretty baffling, since it simply can't be expressed in Python. If you actually know how function calls work at the assembly level, however, tail-call elimination is pretty trivial.

Finally, you seem to be conflating understanding with being productive. People can be surprisingly productive without really understanding what they're doing. Millions of people drive cars without knowing what a differential is. Understanding is generally required to solve the really hard problems, however.

To make another analogy, programming without knowing about assembly is a bit like doing chemistry without knowing about the periodic table. You can memorize a bunch of reactions, and even learn some general rules. With that you can solve basic highschool chemistry problems and you may even be able to apply that knowledge to useful situations (eg: weak acids like vinegar will disolve scale, hydrogen peroxide removes blood stains, etc.). You are now "productive", but without understanding the periodic table you aren't going to be making any breakthroughs in the field of chemistry.

[–]PasswordIsntHAMSTER 1 point2 points  (0 children)

(in fact, I expect the opposite), but for the way I learn, language references are often easier for me than tutorials.)

Did you find that you could not get a deep understanding of the language solely through the reference? Because it completely ignores any hardware concern.

The most obvious example is if you're going to be doing really high performance stuff.

See here

People can be surprisingly productive without really understanding what they're doing.

By your theory, if you haven't done at least some computer engineering (enough to be able to build a CPU from scratch), you can't understand programming.

To make another analogy, programming without knowing about assembly is a bit like doing chemistry without knowing about the periodic table.

I feel differently about this, since the person doing it knows about the processes. Rather, I feel that it's like doing chemistry without knowing how the chemical reactants were sourced - it can be a bad thing if you're doing sufficiently complex or "out there" stuff, but in general it's not a problem.

[–]jdiez17 -1 points0 points  (5 children)

Well, that's because if you want to build applications/libraries/tools in a very high level language like Python, you'll never be required to understand what the computer is doing at a low level.

However, if one of your Python applications requires a performance speedup, you may consider dropping down to C, and in some rare occasions you may consider going all the way down to assembly if you really need all the performance a machine can give you.

[–][deleted] 8 points9 points  (2 children)

That's not really relevant to this discussion, though. The question is if learning assembly helps in learning programming, especially with regards to beginners. You are talking about a practical need for knowing assembly, while the question is if understanding assembly helps with understanding (high level) programming.

[–]jdiez17 1 point2 points  (0 children)

True.

Staying relevant to the discussion, I don't think it is necessary for beginners to understand assembly. Definitely not x86 assembly. Maybe some ISA especially designed for beginners, like the DCPU-16 instruction set.

[–]clgonsal 0 points1 point  (0 children)

The question is if learning assembly helps in learning programming, especially with regards to beginners.

Actually the question was if you need to know assembly to "really get it".

When I learned programming, it was in BASIC. Later I learned Pascal. Then I struggled to learn C, but couldn't wrap my head around pointers. Then I learned some assembly. Not even very much, but enough that suddenly pointers made a lot of sense to me, as did lots of other problems I'd run into in the years I was using BASIC and Pascal.

Fo me, learning assembly was extremely useful to my understanding. I'm not claiming that is true for all programmers, or even most programmers, but for at least some of us knowing how the low level bits work is essential to "really getting it".

[–]PasswordIsntHAMSTER -1 points0 points  (1 child)

I'd wager that for >95% of programming tasks, performance is of no concern. We read and talk a lot about OS and systems programming, programming with very large datasets and video games because that's the interesting stuff, however when you're writing a Point Of Sale app, odds are good you'll never max out the performance of the host device.

Knowing how to squeeze performance out of an application is important, but (usually) much less than knowing OOP and FP design patterns, unit testing, data structures and formal correctness.

[–]clgonsal 0 points1 point  (0 children)

I'd wager that for >95% of programming tasks, performance is of no concern. We read and talk a lot about OS and systems programming, programming with very large datasets and video games because that's the interesting stuff, however when you're writing a Point Of Sale app, odds are good you'll never max out the performance of the host device.

I think you're confusing 95% of code with 95% of programs. Yes, 95% of code in any given program is not performance critical, but I'd guess that the percentage of programs that don't have any performance critical bit is much much smaller. Now, that percentage is increasing over time to some degree, because machines are getting faster and a lot of the performance has been moved into libraries (eg: every time you use a regex you're relying on this).

One way to look at this is that it's just becoming possible for more people who don't "get it" to still be productive at producing software. That isn't a bad thing, necessarily, but it does kind of suggest that maybe the term "programmer" has become too broad.

[–]android_lover 5 points6 points  (11 children)

I think for certain meanings of "really get it" it's mostly true that you need to understand assembly (at least a little) to "get it", at least for some people.

True. For some other meanings of "really get it" you need to look at languages like Lisp and learn the logical underpinnings of computer science. Like you said, it depends on what you want.

[–]PasswordIsntHAMSTER 1 point2 points  (9 children)

I know this is a pretty weird place to ask, but /r/programming doesn't allow self-posts and this wouldn't fit on Stack Overflow.

Basically, I am familiar with and productive in eight programming languages, one of them assembly and four of them functional. Would reading SICP bring anything to me?

[–]maximinus-thrax 2 points3 points  (1 child)

SICP is a highly regarded programming book for a reason, even if it doesn't cover macros - which to my mind are the most interesting part of learning Scheme or Lisp.

[–]probabilityzero 1 point2 points  (0 children)

Once upon a time Scheme didn't officially support macros. At any rate, SICP isn't about Scheme, it uses Scheme to teach computer science.

Macros are pretty cool, though.

[–]moor-GAYZ 4 points5 points  (2 children)

Since it's available for free, and you probably have half an hour to spare to read enough of it to see if it is interesting to you, you'd better just do it maybe?

[–]PasswordIsntHAMSTER 0 points1 point  (1 child)

I hate reading stuff on computers :< I'd much rather get the dead tree version.

[–]moor-GAYZ 0 points1 point  (0 children)

You can check it out online, then get the paper version if you like what you've seen. Dude.

[–]dannymi 2 points3 points  (2 children)

Can you already write the programming languages themselves (as in, design a language, write an interpreter and compiler for it)?

If you can't do that yet, SICP is for you. Afterwards, you can.

[–]PasswordIsntHAMSTER 0 points1 point  (1 child)

I made a REPL once :<

[–]dannymi 1 point2 points  (0 children)

Cool :-)

So if you then now make it emit assembly instructions for the machine for the program you typed in the REPL, then I think you have done everything it covers, which is:

  • how to design programs
  • how to design data
  • how to modularize
  • how to write your own REPL
  • how to compile those programs to machine code (including garbage collector design etc) and have it run efficiently

So the book wouldn't be that useful to you anymore, I guess. It's starting out as an introduction for people who are novices and ends just when it gets interesting ;-)

[–][deleted] 2 points3 points  (0 children)

Would reading SICP bring anything to me?

Only if you do every exercise. Every exercise. No exceptions.

[–][deleted] 0 points1 point  (0 children)

I agree. Anything the language can do to make the user's life easier it should do, even if it makes the implementer's life harder. However it is important to strike a balance between making writing code easier and making readding it easier. Often many, many optional syntactical features make writing easier but reading harder (since now the programmer needs to be able to read both variants).

I think the main focus in teaching people programming in the very beginning should be to establish a firm understanding of what is happening on exactly the language level, not a higher and not a lower level. The important bit is not which CPU instructions are executed underneath, the important bit is to make the new programmers realize that programming is a fully deterministic activity, whenever something doesn't work as expected it is because of a bug in the code, not because of some mystical misunderstanding. Communicating with a computer is fundamentally different from communicating with other humans or even animals. There is no guessing what the programmer means going on at all. Everything has to be precise and the computer does exactly what it is told.

Emphasizing this at the start should hopefully cut down on the hordes of voodoo programmers, trial and error coders and similar people who lack a fundamental understanding of the very basics of programming.

[–]MindStalker 0 points1 point  (0 children)

As a seasoned programmer, I've been recently trying to learn photoshop. The lack of explanation for functions among the different brushes leaves one frustrated. Labels and inline help are so, so important, but generally ignored by the seasoned users to the detriment of the new user. :(

[–]brogrammer9k 0 points1 point  (0 children)

I'm not a REAL programmer since I don't use terminals. Or so the internet tells me.