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.

>>29
You are the poster boy for the OP argument.
It's funny because I have a lot of experience in assembly and C. I started coding back in the early days of DOS, and more recently I was a game developer for BREW phones. I actually did do exactly what the OP is proposing, but unlike you, I went on to do his optional step of learning some real high-level languages. Now I have the magical ability to use the right tool for the job.

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.
Haha oh wow. You really have no clue how something like Scheme's numerical tower is implemented, do you? You're still taking everything you know from Java's BigInteger. Honestly, do you even know any language other than C and Java?

It's pretty easy to implement a highly-efficient BigInt. One simple way is to use a 64-bit value for your integers, and store small values in the bottom 63 bits. You can then do ordinary arithmetic on small numbers. It's trivial to tell when you overflow it; you just check the top bit after addition, and for multiplication you sum the level of the highest bits. When you do overflow it, you can set the top bit, and use the remaining bits as a pointer (down-shifted by one bit; remember the bottom three bits of a 64-bit heap pointer are always blank due to alignment.) This points to an arbitrarily large number in heap memory on which you can do arbitrary precision arithmetic.

With this sort of system you get on average maybe three additional processor instructions per arithmetic operation when doing math with small values (with highly reliable branch prediction since they are almost always small.) Not exactly five functions and hundreds of lines of code, as you seemed to imply. In almost all applications this trade-off is very much worth it to not have to ever worry about the limitations of your numbers, not to mention having a runtime that can provide absolute security against integer overflow.

And yes, as you can plainly see, I DO care a whole lot about how these things are implemented at the low level. It's interesting and exciting to work with. The point is I don't HAVE to work with it when I'm writing a large application. A well-written platform hides all of this away from you.

You need to get it into your head that not everyone is writing fucking video games for a living. I'm starting to sound like a broken record here, but you need to learn to use the right tool for the job.

You really have no clue how something like Scheme's numerical tower is implemented, do you?
Of course he doesn't, he still labours under the expensive procedure call myth.

>>40
What I'm saying is, it's so simple that the standard whatever is overkill for many things. I mean, if you'd rather instantiate an Iterator instead of just using a while loop, then that's fine, if you are a heartless monster.

^{Oh, and I'm not >>29 or any of the other guys wasting so much time over this. In fact, I wrote >>30 and a few other mutually conflicting posts, but not for any mischievous purposes.}

ITT: Java coders who've been trolled by "read SICP" for so long that they've actually bought into it.  I wonder if they've actually read it, though...

>>44
back to /pr/, please.

Nobody is saying that programmers don't benefit from understanding assembly and having a rough idea of how the hardware works, by the way. We're just saying that it's a fucking retarded way to teach programming.
I'm beginning to see where the term ``C-tard'' came from, even though I use C myself.

>>45
Fuck off, ``faggot''.

Writing assembly for a desktop computer is ridiculous for a beginner. However, writing assembly for a small microcontroller is not completely unreasonable, after they have some programming under their belt in any language.

For the desktop there is a massive gap between fibs and fact and an application. Not so for demo boards.

>>48
Writing assembly for a desktop computer is ridiculous for a beginner.
How come? Maybe I'm blind after having read and written a lot of x86 asm for both real and protected mode (mostly DOS and Windows, although I have no problem in using it on other platforms, providing I'm familiar with the ABI and overall system APIs). It never seemed too difficult to me, as for microcontrollers, those have their challenges as well.

>>1-50
NO ONE NEEDS TO WRITE IN ASSEMBLY ANYMORE SO LONG AS WE HAVE forth

>>41
3 instructions minimum (assuming a 3-operand ISA and the arith operation sets a negative flag and the compiler uses said flag), and it'll cause inefficient use of ALUs (modern CPUs can do 2+ adds per cycle but never more than branch)

Also, that only works nicely for unsigned numbers. Most people care about signs.

>>51
There's many ways to do it.
One CL implementation that I know of uses the lower 2 bits as tags (so you have 29bit signed integers, which isn't that good actually, but it's okay, if you really want fast 32bit ops, you can use  declarations or make yourselves some macros for such things - for example, if you're writing a crypto library and want to achieve c-like speed). So fixnums would be xx00, thus addition and overflows all work correctly, and converting the value to a normal int would be just a shr reg, 2.

>>52
sar I hope you mean.

Anyway, I tried doing something similar using 31-bit signed and the lsb as the flag, and unless you want to use asm to make use of overflow flags (since you can't reliably in C) I don't see it not being ugly. Improvement suggestions?

#include <stdint.h>

typedef int32_t bignum;

bignum add_big(bignum, bignum);
bignum fixup_bignum(bignum);

bignum add_signed(bignum a, bignum b)
{
    if ((a|b) & 1)
        return add_big(a, b);

    bignum result = (a>>1) + (b>>1);
    bignum sign = result & (1 << (sizeof(bignum)*8 - 1));

    if ((sign ^ (result << 1)) < 0)
        return fixup_bignum(result);

    return (result << 1) | sign;
}

actually the last or isn't needed, the top 2 bits are guaranteed to be the same from the overflow check.

but still...

which then removes the need for sign, now it's "only" an additional 10 ops for x86

I guess I should actually test this...

itt people implying that everyone should have to individually manage cpus rather than just compiler devs.

>>51
Most people care about signs.
Haha, good one

>>57
It is hardly a surprise that someone who can't comprehend the simple concept of punctuation is not able to grasp the idea of signed numbers.

>>58
If I want to do maths, I'll use a higher-level language. I've rarely required negativity in C.

>>59
That's a good start, now all that is left is to prove that you == ``most people''.

>>56
Compilers don't manage CPUs outside of the task of getting code compiled (and even then, only in abstract.)

this thread is full of idiots who need to read SICP.
until you can apply the lessons it teaches to programming in any language (including c, assembly, and even brainfuck), you're nowhere near satori.

>>62
That's an amazing post; it doesn't address anyone's points or queries (especially the OP's), it doesn't take a position on the topic (instead, it targets people on both sides of the argument without actually contributing to the discussion), and it's not even original.  It took some effort to be that useless, didn't it?  Now take a seat while the adults continue their debate.

...

The participants in this debate fall into two (well, three) camps: academics and professionals (and trolls uninterested in the subject).  The academics are concerned with the most technically correct solution to the problem -- they want to write an implementation that results in the most efficient machine code, regardless of the development cost.  Professionals, on the other hand, seek to write an implementation that balances efficiency with expense  -- there's no margin in doing it the academic way.  (And the trolls don't understand the issue at hand, they just like a good fight.) 

Being a professional, I use high level languages that remove the time-consuming details through abstraction; that doesn't mean I don't appreciate the academics' viewpoint, just that I don't subscribe to their approach while I'm working.

>>63
OH NO YOU DID NOT JUST CALL ME AN ACADEMIC

>>63
Whereas all you've done is straw man'd your opposition and made them seem like naive children.

Best way to learn programming:

1) Fuck around with BASIC until you can write programs that solve arbitrary simple to mid-complexity problems
2) Read SICP

>>63
Academics are more worried about optimization than professionals.
It's a shame you're retarded, or that would be a really good point. There are plenty of professionals with totally misplaced priorities.

>>63
It's interesting how self-described ``professionals'' always seem to feel the need to call everything they disagree with ``academic'', no matter how incredibly stupid that would be. I can promise you that the people advocating reading SICP because it teaches you the value of abstraction will prefer being called academics over professionals, and don't regard that as a dirty word.
Unless this is just an attempt at trolling both sides because you're in your third category, of course.

>>7
Hokey religions and ancient weapons are no match for a good blaster at your side kid

Hotkey religions

>>63, please turn in your /prog] passport and return to /g/.

>>71
/prog]
You fail it.

>>66
This is actually the worst way to learn programming, and, it's the most common way.  Evidence?  Look at the ratio of intelligent posts on /prog/ to posts that make you want to stab your own eyes out.  These are the programmers that are created by >>66's method.

>>63
Your argument is surprising to me.  I read the whole thing and got to the end thinking "this guy is on the professionals' side, which means he's on the OP's side."  But then you derailed me completely by saying:
Being a professional, I use high level languages that remove the time-consuming details through abstraction

It sounds like you're saying the OP is more on the academic side, while the "read SICP" crowd is the professional side?  I suspect the exact opposite.

>>73
s|/prog/|/prog/|

>>73
Evidence? Is that really evidence? I doubt these non-intelligent posts were written by those who can program. At most, they're by people who ``know a bit of Python'' or C (i.e. believe Hello World in either constitutes being able to program). None of them have learnt BASIC, otherwise that'd be the language of choice for "how do i write this program" threads (it isn't).
^{Aside: Note that a lot of code posts here are in C or Python.}

BASIC is a perfect language to learn programming with: it teaches you the basics of imperative programming, then once you can solve simple to mid-complexity programs you realise that actually, it's a bit shit. So you move on to greener pastures - C, perhaps assembly (or, if you're still a bit simple, FIOC). The knowledge gained in using BASIC is equivalent to step 1 in >>1.

Of course you cannot oppose step 2 in >>66. Nobody can.

>>63
Professionals don't use the very high level languages you advocate. They use Java, C++, and C#, all of which are terrible considering performance and development time.

Academics aren't concerned with performance on actual machines; depending on their interest they might completely ignore performance considerations outside of complexity analysis or they might assume an idealized ISA that has never existed.

I guess it would be hackers (in the original sense) that care about performance over development time, and you're one of the mythical professionals that use decent languages designed to actually decrease development time.

>>73
Well not necessarily. Someone like Paul Graham would certainly consider himself a professional, not an academic. You have to admit that coding for maximum possible performance without regard to development time is an academic pursuit. In the real world it really only applies to numerical simulations, such as scientific simulations or video games.

You're using a different definition of professional, that of a code monkey in a giant enterprise shop. Those are a different breed and they are irrelevant to this discussion because they don't get to choose their programming language. The project managers do, and for them, having a predictable schedule and replaceable programmers is a lot more important than having the fastest programs or the shortest development cycle.

>>76
Professionals focus on what they can do today, and sometimes they think about what will be possible in the future.  Academics focus on what will be possible, and sometimes they try to implement it.  Without both professionals and academics, we're fucked.

Look at those "professional" languages: Java, C++, and C#.  Their development is only possible because of the academic languages that came before them.  The people who designed these languages are academics and professionals.

Take Java, the waning king of professional languages.  When it was introduced, things like compiling to a cross-platform VM and using garbage collection were widely seen as quaint academic tricks that had no place in a production environment.  Today those are taken for granted.

Haskell is currently the big thing among academic languages.  Haskell has a few big features like better correctness guarantees, a wonderful FFI, easy parallel programming, and working STM.  Bits of Haskell will be in the next generation of "professional" languages, and you can either learn Haskell now, or wait until someone waters it down for you.

Why don't professionals use better languages?  (1) existing code (2) retraining (3) library availability (4) support

Academics are (1) writing new code (2) always learning (3) don't use as many libraries and (4) are expected to figure the damn things out themselves

Here's a tip for you: Microsoft is paying academics to work on Haskell.  It is all about the bottom line.

>>78
Bits of Haskell will be in the next generation of "professional" languages...
Of course. It's loaded with syntax, which professionals love because they can spend more time typing than thinking.

Protip: SICP is 25 years old. Computing has come far in that time,

>>80
SICP isn't about computing.

>>80
What does SICP's age have to do with computing?

>>80
Name one non-functional language that has come as far as first year MIT students from 25 years ago.

>>83
Common Lisp.

>>84
Common Lisp still has 4 of its 8 feet in the past.

>>85
And only two of those four even count!