As for misconception, a simple Unity game with a leaderbord is not a big project either. It can be done in under 500 lines of code, server included.
I know you can do beautiful things in C++, I have been programming in that language (among others) for the last 20 years. STL and Boost are nice upgrades to the language. I believe it just gives you too much power too soon. Learning a more strict language will make one avoid more dangerous features when they will handle C++.
I also recommend learning some of 6502, Z80 or ARM assembly. Not to be able to actually write programs with it, but to be able to grasp how the higher level code work under the hood. It makes it much easier to understand data structures (stacks, lists, trees, etc.) when you can see that it references actual memory in a structured way and is not only some abstract drawing that a teacher put on a whiteboard.
I honestly cannot understand how learning asm helps you understand data structures in any way.
Firstly, you don't need to know anything at all about asm or machine code in order to understand how a certain data structure works inside and out (its efficiency, its memory usage, its advantages and disadvantages, where it's good and where it's inappropriate, and even how it's implemented at a low level.)
Secondly, even if you wanted to know how the data structure works on the hardware level (at least if we are talking about low-level languages), you don't need to learn asm for that. You only need to learn a few concepts of how memory works, how it's allocated by the system and what are memory addresses. Zero asm required for this. Even if you wanted to know what's the difference between actual physical RAM and virtual RAM (ie. how the CPU and the OS map virtual memory addresses to actual physical RAM addresses) you still don't need any asm whatsoever. (And while all this can be interesting, it has little value in actually understanding data structures and how they are used.)
The futility of learning asm to understand data structures becomes even more prominent with higher-level languages like Java or Haskell, where references are not raw memory addresses, but are much more abstract than that. The disconnect between asm and these abstract references is quite large. (You can study how these references work at machine code level, but that info doesn't help you understand the data structure itself at all.)
You don't learn how to repair a car by buying a book on chemistry and molecular physics.
EEssentia wrote:
And believe it or not, it's easy to write safe, modern, flexible and powerful C++ code with few to no consequences.
Yes, but getting to the point where you can fluently write simple&safe C++ requires quite a lot of practice and experience. It's not like you can just grab a C++ book and in a week start writing safe C++ like a pro.
I'd like to say that I agree with Warp; as useful as learning about a computer's architecture may be, doing so does not require you to know any assembly whatsoever.
So unless you're planning on programming microprocessors, compilers. drivers et cetera (or your program really, really needs all the speed and memory efficiency you can possible squeeze out of it, there's some things compilers just can't do for you) there's not really any reason to learn assembly other than purely out of interest.
Also, I learned C++ by first creating a (approximately) 10-line console-version of pong and then I started making my own Wolfenstein-like raycasting engine. As long as you have enough general programming experience to recognize bad coding, have a feel for designing your program well and the patience to do ten parts reading to each part coding (and more for your first line), I don't think you'll have to much trouble learning C++ by just taking on a project that you know you can't do yet.
As far as Vakan12's problems with Python coding are concerned: you'll just have to learn. My personal favorite Python design environment is Notepad++. No IDE will take care of things like parentheses, colons, semi-colons and the like for you (though some try).
(or your program really, really needs all the speed and memory efficiency you can possible squeeze out of it, there's some things compilers just can't do for you)
Something programmed directly in asm being faster than what a compiler can produce is in general a misconception.
My personal hypothesis of where this misconception comes from is from the 80's and the 8-bit computers of that era. Usually you had two choices: BASIC or asm. And no matter what you wrote, if it was written in asm it was usually at least 10 times faster than the equivalent BASIC program. This birthed a very popular concept that anything written in asm is automatically faster than anything written in an abstract, high-level language.
For a long time this was perhaps true even for low-level compiled languages like C, and possibly even FORTRAN (although I wouldn't bet my life on the latter case.) Back in the 70's and 80's C and C++ compilers were not all that good at optimizing. Maybe even in the early 90's.
However, during the 90's and especially in the 2000's compilers have got a lot better at it. Also, hardware has progressed so rapidly that it's very hard for an asm coder to keep up, and to keep beating compilers. (What was an efficient way to implement something in the early 90's might well not be the most efficient way of implementing it today.) Unlike in the early 90's, today processors are extremely complicated and it's very hard to optimize for them manually. Compilers have got pretty competent at optimizing for them.
This doesn't mean there aren't cases where implementing some subroutines in asm wouldn't result in something that's measurably more efficient than anything the compiler can produce. However, these cases are relatively rare. (The disadvantage of doing this is, of course, that it's absolutely not portable.)
As I said, I do not advocate learning assembly to actually be able to program in it. I believe it is useful to grasp what a computer can an cannot do, and not see it as a magic box where putting in more RAM makes the box more magical.
Unlike knowing chemistry can help you repair a car (that would be more like understanding how to design integrated circuits out of transistors can help you program), the car analogy of learning assembly would be more like taking a class on material resistance physics. When doing actual repair work, you'll then instictively understand (or remember) why you should not screw a bolt tighter than a certain resistance, carefully grind and make large round corners for your shims as tighter corners will put more stress on the piece and it will break again, etc.
Learning assembly is not meant to program in it, IMHO. As Warp suggested, compilers do a much better job at code optimisation than people. It is meant to understand why the computer behaves like it does when there's a problem in your code. Only learn a few basic operands, the different addressing modes and registers, how higher level languages call functions and how the the call stack works and that's enough.
Learning assembly is not meant to program in it, IMHO. As Warp suggested, compilers do a much better job at code optimisation than people. It is meant to understand why the computer behaves like it does when there's a problem in your code. Only learn a few basic operands, the different addressing modes and registers, how higher level languages call functions and how the the call stack works and that's enough.
Ok, let's try it like this:
Assume that someone is learning, let's say, C# as their first language. Please give me a concrete example of how learning asm would help understanding C# in any way?
(Note that C# is actually quite abstract. It's not compiled directly to machine code. Instead, it's compiled to a byte code format which gets interpreted by a virtual machine. This virtual machine usually JIT-compiles this byte code to machine code on the fly for increased efficiency. However, there are so many steps and so many layers of abstraction between the C# source you write and what ends up being run by the CPU, that it basically has nothing to do with asm. In fact, it's perfectly possible to purely interpret C# bytecode, without even a single thing you wrote being compiled into actual machine code.)
Even so, all these topics are really, really advanced stuff. You most certainly do not need to know them when you are learning to program for the first time. (Suggesting learning asm to a newbie programmer is just inane.)
Moreover, even if after you become fluent at programming you would like to know more in depth about the details, for example about why this data container consumes this amount of RAM and why that data container causes so many CPU cache misses, and why this container causes so much memory fragmentation, you still don't need to know any asm for this. You only need to know how the CPU addresses memory, how the CPU caches work, and how the OS and/or the runtime environment of your program allocates memory.
Even if you were learning C++ (or even C), you still wouldn't need asm for any of that.
Now, if you were for example programming for a PIC controller that has 2 kilobytes of program memory and 128 bytes of RAM, and for which there exists basically no optimizing C compiler (or, more precisely, there exist optimizing C compilers, but they are able to optimize only certain things, but do a very poor job at others), that would be a quite different story. In that case understanding what the compiler is producing becomes a lot more important, especially since you need to do a lot of hand-optimization if you want any speed. (Even then, the PIC asm is quite different from your regular x86 asm...)
I happen to teach undergraduate programmers, so I have some idea about this.
......
Don't attempt to learn C++ without professional help. (And even then, you need good professional help.)
I won't tell you that I have learned VC# by myself.
I happen to teach undergraduate programmers, so I have some idea about this.
......
Don't attempt to learn C++ without professional help. (And even then, you need good professional help.)
I won't tell you that I have learned VC# by myself.
Joined: 10/6/2011
Posts: 1697
Location: RU · ID · AM
I began with Pascal at school several years ago… Do not remember anything >_<
Now I work as a PHP programmer (and sometimes team collaboration manager, UNIX administrator and so on) in a small web studio, which is a bit boring.
When I have spare time, I write simple applications in C++/Qt, but yes, sometimes I use some «outdated» things from C. Tried to write in pure C (using libjpeg) as well (not so successfull).
I have great experience with XMPP.
My current interest is learning Django — a Python web framework.
S3&A [Amy amy%] improvement (with Evil_3D & kaan55) — currently in SPZ2
my TAS channel · If I ever come into your dream, I’ll be riding an eggship :)
I'm halfway through a great book on Python but I'm kind of hoping there's a better IDE to use than the one Python provides. As a noob I have a bad habit of forgetting indents, colons, mixing up variable types, etc and I'm hoping there's an IDE that's more forgiving with that (eg/ adding colons automatically after an if statement).
You don't want a an IDE that does this work for you. Maybe that's good for people just starting up, but you clearly have that much under your belt, so don't start using training wheels when you never had to.
My personal view is that aspiring programmers should start with Python to learn how to describe a program without getting into too many technicals (Lua is alright for this, too). Once you've learned all the major concepts for it (making your own objects is a must) and make some non-trivial program with it, I would move on to C or C++ to get a better idea about how programming actually works. Finally, at least understanding how an assembly language relates to C is imperative. Assembly language is the closest thing to what computers see that humans can read, so realizing how these three levels translate will make you a better programmer.
Do you need to know all of this to make money? Absolutely not; I made quite a bit of money on freelance sites doing PHP when I was 16, even after the ridiculous fees they charged. Do you need to know this to write good, efficient code? In my opinion, yes. You'd be shocked some of the critical mistakes you will make without this understanding.
By the way, if you see me on IRC, feel free to ask for help with programming and related subjects. I love helping people, but forums are slow for me. Also, if you want some useful practice, BizHawk can always use more hands. ;)
Finally, at least understanding how an assembly language relates to C is imperative. Assembly language is the closest thing to what computers see that humans can read, so realizing how these three levels translate will make you a better programmer.
Will people please stop making that suggestion already? Just stop it.
Studying asm to become a better programmer is like studying a ready-made meal under a microscope to become a better cook.
A lot, lot more imperative to become a good programmer is to understand how algorithms and data containers work, what their efficiency is, what different algorithms and containers are good for and bad for, and so on. Computational complexity and memory usage of these things are significantly more important to know than how the compiler translates it to machine code (if it translates it at all; not all languages are compiled, and even those that are might not be compiled directly to machine code.)
There are many other things as well which are much more important to a programmer than knowing asm. For example program design, including things like proper object-oriented design.
Maybe, maybe, when you become fluent with algorithms, data containers and other programming techniques, then it might be interesting to know what they translate to under the hood. Regardless, knowing that won't make you a better programmer, except in quite exceptional cases. (Mostly if you intend to program, for example, to really low-level embedded systems such as a PIC controller.)
I don't mean a deep level of asm. I am saying that you should know how data is represented, how control logic works underneath the hood, etc. I think that having an understanding of assembly is complementary with data structures and algorithms. Most of those should be covered while learning Python and a lower level language like C++. At that point, it would be helpful, at least it was for me.
Knowing assembly or even cache is pretty pointless if you all you do is code in C#, Java, etc.
If you learn C++, then knowing how cache works (at the very least, what stuff wreaks havoc with caches and what does not) can be a significant advantage.
Knowing assembly is usually hardly of any use unless you really need to bring out the processor juicy, and only really applies to really low-level code. Only consider if you are learning C/C++. But even then, you most likely won't need it. Compilers do a very nice job these days.
I'd say knowing assembly language helps avoid common misconceptions in C in particular. You're unlikely to actually use it for anything (unless you're programming on very low-powered processors like washing machine controllers and old consoles), but it's good background knowledge.
On x86 at least, compilers will nearly always beat humans at converting a low-level algorithm to assembly language. (Partly because processors don't really work the way C and asm imagine them to work anyway nowadays.) So if you're just planning to program PCs or Macs, asm is mostly pointless except as a step to learning.
I am saying that you should know how data is represented, how control logic works underneath the hood, etc.
In the majority of programming tasks knowing that is not very useful. At most you need to know if there are some limits in the representation of values (such as integers in C/C++, which are limited to 32 or 64 bits, which means that there are minimum and maximum values that can be represented with them.) However, you don't really need to know anything about asm in order to know what the limits of an integer (or any such primitive type) may be in a given language.
(Even knowing the bit pattern, ie. the internal representation of a value, such as typically 2's complement for integers in most architectures, is something that one doesn't need to know, unless one is making really low-level optimizations for something. And in the vast majority of cases you don't to do such optimizations (even if you think you do). There may be other situations where it might be useful information, but it's not all that common.)
I think that having an understanding of assembly is complementary with data structures and algorithms.
I don't see how. I most certainly don't need to know how the machine code generated from using, for example, a std::list looks like in order to fully understand how it works, what it does, what's useful and not useful for, how efficient it is, and how it compares to other data containers. I can perfectly well understand pointers (and even understand that in C++ they are more or less directly memory addresses) and how objects are allocated, without knowing anything about asm.
I'm not saying "don't learn asm". I'm just saying that if you think you will become a better programmer by learning asm, you are mistaken, especially if you are still learning to program. (In fact, it could actually be the opposite. You might start thinking too "low-level" about things and perform micro-optimizations that are actually more detrimental than beneficial. If for nothing else, then with respect to the readability of your code. In some cases even with respect to its speed.)
EEssentia wrote:
Knowing assembly or even cache is pretty pointless if you all you do is code in C#, Java, etc.
If you learn C++, then knowing how cache works (at the very least, what stuff wreaks havoc with caches and what does not) can be a significant advantage.
Cache optimization can in fact be useful also in C# and Java.
Certain programs can indeed become much faster if you change the order in which you handle the data. (In general, the rule of thumb is that you should do as much as possible with smallish chunks of data, rather than doing things to very large amounts of it over and over.) Of course this is a relatively advanced topic, hardly something a beginner programmer should worry too much about.
Certain programs can indeed become much faster if you change the order in which you handle the data. (In general, the rule of thumb is that you should do as much as possible with smallish chunks of data, rather than doing things to very large amounts of it over and over.) Of course this is a relatively advanced topic, hardly something a beginner programmer should worry too much about.
But then again, you know, without basic knowledge of how operating systems work and how cache works, you might create a code that brings a program to a crawl.
I'm not suggesting that a newbie needs to know how to optimize these things, but at least IMO, they should be able to know enough to avoid creating such code in the first place.
Some argue that these things (the basics) really should be taught alongside of algorithms and datastructures, and having seen firsthand on how it can affect programs, I am a somewhat inclined to agree.
Btw, I get the impression that some people are confusing "asm" with something like "the internal representation of values/data structures in memory" and/or how the data in data containers is placed in memory.
The bit representation of data, and how a program allocates and uses memory, is not the same thing as "asm".
"Asm" is, generally, a programming language that maps directly keywords to corresponding opcodes in the machine code of the target CPU. (An opcode is the sequence of bits that the CPU interprets as one of the commands that it executes when running a program.)
Knowing how data is represented in memory can be useful at some level, but knowing machine code, much less an "asm" language used to represent it, has nothing to do with this.
@Warp: You haven't tried to teach an entire room of newbie C programmers who don't see why they have to use malloc.
If you're not using low-level languages at all, fine. If you are, though, start with the basics.
No need to get religious about assembly. Wrap doesn't believe it is useful to understand for new programmers, I believe otherwise, could we just all get along and stop this pointless argument? There are countless topics on the pros and cons of learning that all over the web, I think whoever cares should just Google it and decide for himself.
@Warp: You haven't tried to teach an entire room of newbie C programmers who don't see why they have to use malloc.
What exactly does that have to do with asm?
I've never seen someone thinking memory magically comes out of nowhere in asm. Partly because you have to do the arithmetic yourself for things like arrays.
Joined: 10/6/2011
Posts: 1697
Location: RU · ID · AM
Programming today is like a bunch of layers… Assembly languages are an abstraction from binary codes, C/C++ are higher levels, next layer is represented by interpreted languages like Python, Ruby, PHP, Perl… Also bytecode interpreters like Java, .NET and erlang. And it’s even not the last level — there are many implementations of language interpreters in interpreted languages — PHP’s Twig and Django’s template engine, elixir and so on.
If you program on the highest level, you’ll find it terribly hard to switch to the lowest, even if you are very nerdy with what you do…
S3&A [Amy amy%] improvement (with Evil_3D & kaan55) — currently in SPZ2
my TAS channel · If I ever come into your dream, I’ll be riding an eggship :)
I've never seen someone thinking memory magically comes out of nowhere in asm. Partly because you have to do the arithmetic yourself for things like arrays.
That's pure mathematics. Knowing how to access the Nth element of an array is something any programmer can do without knowing how memory works.
I've never seen someone thinking memory magically comes out of nowhere in asm. Partly because you have to do the arithmetic yourself for things like arrays.
Sorry, I still find to see the connection between "teaching how to allocate memory" and "teaching asm".
It's a bit like:
"Why are you teaching chemistry to these culinary students?"
"Well, they wouldn't be able to buy the vegetables required to make food otherwise."
"Wha?"
Vykan12, you said you're a CS undergrad. If you have the time, take a look at algorithmic programming competitions, the most well known of them is the ICPC. To participate in the regional level, you just need to register a team. Getting to the World Finals is quite a challenge, though :)
Preparing for those contests will teach you a lot about programming (the wikipedia article lists some online judges), though the actual problems you have to solve there have little to do with real world ones. Almost everyone that does well at competitions like that gets job offers from big companies like Google, Facebook and Microsoft. In fact, Google and Facebook like these so much as a recruiting tool that they now organize competitions of their own, Google Code Jam and Facebook Hacker Cup.
