New thread

Best way to learn programming:

1) Learn logic
2) Learn assembly
3) Learn C

At this point, two choices: stick with C or learn whatever high-level languages/paradigms suit what you want to do.

Almost everyone does the exact reverse.  First learn BASIC or Java, then attempt to understand what's going on underneath (and probably never get around to it).

If you go from the bottom up, each step gets easier and there's no mystery hiding what's going on under the hood.

Read SICP

there's no mystery hiding what's going on under the hood
But I like mysteries.
Does that imply I would have enjoyed learning from the other direction?

This attitude that programming is about exactly what the hardware is doing is harmful nonsense. Anyone who has read SICP would realise this.

The book "The Elements of Computing Systems" takes this kind of approach, building up through nand gates to the computer architecture, and then through a series of translator projects. It's a fun enough book, but it will be disappointingly easy for those on /prog/ that can actually program.

>>4
True, as I've said many times on /prog/, CPUs are far more complicated than your assembly class made them out to be.

At its core, programming is about abstraction. To the beginning programmer, there is no value in learning an assembly language. If there was one thing TAOCP demonstrated, it was this.
We need more education in very high-level languages, and less wasting time on outdated attitudes.

>>4,7
This attitude that programming is about exactly what the hardware is doing is harmful nonsense.
To the beginning programmer, there is no value in learning an assembly language.
IHBT, but, there is tremendous value in knowing what the hardware is doing.  Unless you don't find value in efficiency or correctness.  Then, yeah, I guess go with the high-level fluff.

>>8
Hardware is just an interpreter implemented in hardware.

>>8
To the beginning programmer, there is no value in learning an assembly language.
there is tremendous value in knowing what the hardware is doing.
The fact that you think that that is an answer to >>7 makes me smile

>>8
More efficiency is to be gained in good algorithms than in micromanaging your CPU. Getting hung up on assembly gets in the way of a deep understanding of algorithms. I hate quoting Knuth, so I won't, but he wasn't entirely wrong.
As far as correctness goes, that shows that you really don't understand the meaning of abstraction. Read SICP.

http://www.infoq.com/presentations/click-crash-course-modern-hardware

>>11
micromanaging your CPU
Oh God, you're hilarious.  Keep 'em coming!

>>13
You can't think of any counterarguments; duly noted.

>>8
IHBT, but, there is tremendous value in knowing what the hardware is doing.  Unless you don't find value in efficiency or correctness.
Ludicrous. You have the correctness issue completely backwards. High-level languages can provide a wide variety of correctness guarantees that have nothing to do with the hardware or the implementation, and everything to do with the semantics of the language.

Correctness becomes difficult when a language exposes too much of its underlying platform. For example in a language like C or Java, you need to understand a lot about how the hardware handles concurrency because they have terrible or non-existent language support for it. Concurrency is simple in a language that provides thread isolation and channels; you don't have to know shit about what the hardware is doing to write correct programs.

>>15
Here's the thing about correctness.  Since I know how registers (and RAM) work, I know that when I add 1 to 4294967295, I will get various results depending on the platform and the compiler and the data type.  Since I know how pointers work, I know why I need to be careful when writing a linked list.  And when shit gets really nasty and multithreaded, I know exactly how to protect that linked list, correctly and efficiently.

Now you can argue that all this is low-level shit that you don't need to worry about, but all you're really doing is relying on someone else to know it for you.

>>16
I hope you're trolling, but somehow I think you're serious.

>>16
Here's the thing about correctness. Since I know how registers (and RAM) work, I know that when I add 1 to 4294967295, I will get various results depending on the platform and the compiler and the data type.
In a real high-level language, you get 4294967296. It's just a number like any other; it has no special significance.

Since I know how pointers work, I know why I need to be careful when writing a linked list
I have no clue what you mean here. A "binding", "reference", or "handle" to an object is an abstract concept that has no relation to the underlying implementation. You don't need to know shit about hardware addresses to implement a linked list.

And when shit gets really nasty and multithreaded, I know exactly how to protect that linked list, correctly and efficiently.
In a real high-level language, you don't. A language like Erlang provides memory protection between threads. A language like Haskell provides immutability that makes synchronization unnecessary.

There are many ways to abstract away the ugly details of concurrency. You're stuck in Blub-land here bud, where you seem to think Java-style mutexes are the height of parallel programming.

Now you can argue that all this is low-level shit that you don't need to worry about, but all you're really doing is relying on someone else to know it for you.
YES, EXACTLY, in the same way as you're relying on an engineer to know how transistors work, and on a physicist to know how quantum mechanics works. That's the whole fucking point of abstraction layers, so you don't have to think about this shit. You get to focus on the problem at hand instead of worrying about the implementation of your platform so damn much.

Forcing every programmer to learn assembly, computer architecture, and compiler theory would be worth it solely so that I don't have to read another diatribe on how Java/C# is faster than C.

Computer scientists are exempt, but only if they're pure computer scientists.

That's the whole fucking point of abstraction layers, so you don't have to think about this shit.
No, you have to, or forever remain an ignorant Java codemonkey.

>>20
No. Abstraction isn't about being ignorant of the details, it's about using the right tool for the job. If some code doesn't have a premium resource budget, the programmer can devote her mental resources into getting more work done as opposed to concentrating on irrelevant details.

>>16
what the hell do you need a linked list for in this day and age?  more importantly, why the hell would you write your own?

>>22
Linked list hater.

>>22
I recently used a linked list for literal nodes on a trail behind an entity that acted like a lasso in a little nonsense game I made. It was in C++ and using some standard container felt like overkill when I could just as quickly write it myself. So suck my dick.

>>21
her
Nice try, bub.

you know asm, thats cool!

>>24
And actually having a vague idea of what can be found in the standard library for the language you're using is too much for Sepples morons like you?

>>24
using some standard container felt like overkill when I could just as quickly write it myself.
The fuck?

>>18
In a real high-level language, you get 4294967296. It's just a number like any other; it has no special significance.
Right, because all computers have infinite memory and can represent any number, no matter how large.  And what about floating-point values?  They all have infinite precision and range at the same time, right?  No need to understand how a floating-point processor works!

I have no clue what you mean here. A "binding", "reference", or "handle"
A "handle" is usually a pointer to a pointer.  You would probably not use handles to build a linked list.

You are the poster boy for the OP argument.  It's probably fine in your case, but competent programmers can always do better than the built-in mechanisms in a high-level language.  It's not that language designers are incompetent, they just can't foresee what every individual programmer wants to do in their specific application.

From your description of high-level languages, you're completely unaware of just how inefficient your code actually is.  You expect your numeric values to always be some sort of "BigInt" class, apparently.  So your version of a + b is probably, realistically, about five function calls and maybe 50 to 100 lines of code, where it would be a single instruction for anyone who knows what they're doing.

You can call the difference between 50 lines of code (probably interpreted code, at that) and a single, native instruction "micro-optimization" if it makes you feel better.  But that's for doing a + b.  When, someday, you do need to write a large, complex application, you'll see things differently.

>>27,28
Linked lists can be simplified as much as necessary, but I'm not sure >>24 knows that the standard container he purposely didn't use would probably have been included anyway, completely nullifying any benefits he wanted to gain.

>>29
I don't know how it's possible to miss the point so widely. You really, really need to read SICP.

>>31
I didn't read your previous post, but I feel that the aforementioned poster made a pretty good point. You directing him to SICP seems to signify major anus pain on your end, which you might need to have fixed ASAP.

>>29
competent programmers can always do better than the built-in mechanisms in a high-level language.
This is what Ctards actually believe.

So your version of a + b  is probably, realistically, about five function calls and maybe 50 to 100 lines of code, where it would be a single instruction for anyone who knows what they're doing.
Apparently because they don't have the faintest idea how much work goes into implementing a standard library. Hint: language implementors don't half-ass it like you would, because they actually understand the problem at hand.

probably interpreted code, at that
Yes, most fundamental language features are written in interpreted code.

I'm not saying that programmers in high-level languages shouldn't know what's happening at a low level (or that they don't). But it's abundantly apparent that low-level programmers have even more studying to do if they're ever going to move beyond Greenspinning terrible solutions to every problem they encounter.

>>33
This is what Ctards actually believe.
Built-in mechanisms are written by competent programmers. It's a similar situation to ASM handwritten by a competent programmer being better than its compiler-generated equivalent.

Yes, most fundamental language features are written in interpreted code.
What are you on about? This makes no sense.

>>28,29
>>30
Why should I bother with some asshole's template? It's a matter of maintainability. My needs were ultra-light and everyone knows a linked list when they see one. Furthermore everyone can write them in their sleep. It's a standard for a reason. Fuck get_iterator.

I partially agree with OP.
Having a good understanding of logic and mathemathical thinking is very useful when programming, however certain 'ways of thinking' are also very useful when approaching programming tasks.

the way of assembly->C is fine, but I hardly think it's the complete way, instead it should be assembly->C->SICP->other high-level and low-level paradigms and languages. I don't even consider SICP to be the end-point of one's learning. One should also consider advacing their knowledge in other ways (for example, learn Common Lisp, Haskell, Prolog, Forth, APL, ML, learn other computer architectures, learn beyond imperative programming and go into EE as well by learning some Verilog or VHDL, and maybe even lower! Learn about asynchronous and synchronous design, etc). One should never stop learning. If you just stop at asm/c, you'll merely be a simple imperative programmer who is limited and possibly lives a boring life, without understanding all his possibilities and how he can save time or squeeze performance beyond what he imagined.

Personally, I started with assembly and C, then I learned other imperative and OO languages. I was becoming bored and annoyed by limitations of the languages I've used and wanted more, after which I read SICP, and then my mind was open enough to look at different paradigms, languages and architectures.

tl;dr: do not ever stop learning. asm->c is not a bad way to start, but it's only the beggining, it's not where you should stop, and it's not all you need to know.

>>34
Built-in mechanisms are written by competent programmers. It's a similar situation to ASM handwritten by a competent programmer being better than its compiler-generated equivalent.
Built-in mechanisms ought to be written by better than a "competent" programmer, but even if I were to accept the proposition that you're capable of doing anything right, you'd be retarded to think that any piece of shit you dash off is going be equal to the amount of care and thoughful optimization that the implementors put into their version. Heck, the compiler may even have special support for standard library versions of things.

What are you on about? This makes no sense.
I know it makes no sense! That's why I pointed it out. The entire post I was quoting was full of nonsense.

>>35
Reinventing the wheel in a slightly different way each time I need a basic data structure is more maintainable than using the standard library.
IHBT

My needs were ultra-light and everyone knows a linked list when they see one.
Everybody who isn't too retarded to be allowed to program knows what's in the standard library too, and they don't have to read your implementation to know how it works.

Both of you, quit programming forever. Or if you're the same person, quit programming forever: you're that bad. Better yet, kill yourself. How is it that we're even having this discussion? I shouldn't have to explain to programmers why the standard library exists.

>>37
IHBT
It's not really an entire wheel, though, is it? It's just struct foo { struct foo *next; }.

>>36
Until you fully understand SICP, you'll keep making the mistake that other programming languages, books and paradigms exist.

>>38
That other guy is right, you really do need to read your SICP. Come back when you know what an abstraction is.