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.
This attitude that programming is about exactly what the hardware is doing is harmful nonsense. Anyone who has read SICP would realise this.
Name:
Anonymous2010-09-02 14:44
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.
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 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.
>>13
You can't think of any counterarguments; duly noted.
Name:
Anonymous2010-09-02 18:16
>>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.
Name:
Anonymous2010-09-02 20:46
>>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.
Name:
Anonymous2010-09-02 22:09
>>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
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.
>>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?
Name:
Anonymous2010-09-03 10:16
>>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.
>>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.
Name:
Anonymous2010-09-03 11:40
>>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.
Name:
Anonymous2010-09-03 12:48
>>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; }.
Name:
Anonymous2010-09-03 13:55
>>36
Until you fully understand SICP, you'll keep making the mistake that other programming languages, books and paradigms exist.
Name:
Anonymous2010-09-03 14:02
>>38
That other guy is right, you really do need to read your SICP. Come back when you know what an abstraction is.
Name:
Anonymous2010-09-03 14:12
>>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.
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.
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.