Vapourware Trying to learn programming from ~0, realistic goals naturally help needed.

[Perkel]

Slight correction: x is a different pointer than y. But both pointers point to the same memory. In higher level languages they are called references. The difference being in that with pointers you can manipulate what memory they point to directly while with references you cannot.

And there is also a but. Some things are not references - primitive types. So for example if you do in python:

x = 3 # x is int with value 3
y = x # y is an int with value 3
y = 4 # y is an int with value 4
print x # prints 3

This also means if you pass an int to a function it will be copied.

That's why I mentioned in one post you should look into pass by reference and pass by value.

I don't get above.
If x and y now have same address space then why x didn't change to 4 ?

I can't fallow how it would look like in assembler:

x is defined and it takes adress in memory let's say adress "a"
then we type function so pointerx ------ > 00000003 to adress "a" Adress a now is 00000003
y is defined it takes adress in memory let's say "b"
but y pointer changes to x pointer so changes in y will lead to change 00000003 to something else
then we change 00000003 through pointer y to 00000004
we print out memory space connected to x and that should give me hex ending with 3 not 4.

Almost right but the details are not important.

If you have unbearable curiosity, look up the difference between stack and heap, why they exist and how primitives get allocated to each, and why and how that interacts with registers.

thanks i will look for that in spare time. It is interesting imo.

guess. In case like you mentioned above it does some additional math fallowing some logic that doesn't fallow normal way. (if i can call something "normal")

 

[SCO]

This is bullshit undergraduate pap i learned over 5 years ago and that i can't remember very well.

Heap is your normal memory as you think of it. The stack or (in X86 at least) registers are the specialized memory the processor uses to 'hold' memory it is operating on. When you declare a primitive on a function (not on a object) its allocated not in normal memory when it needs to (it would be absurd to have to fetch all the way there to get a '5'), but directly into the processor memory. It's called 'stack' (when it is stack and not registers), because it operates like one. When the processor sees it needs to create some memory it just pushes it down at the end just like a (list/stack). When it doesn't need it anymore (the function ends and returns to the caller) it just moves the stack pointer back to the beginning without bothering to zero the memory

This is why 'smashing the stack' is a hacker thing.

As was mentioned x86 uses register but the stack is still a abstraction on the heap of many languages. Why? It's easier to code a compiler for stackmachines and then adapt the output to registers (the input-output transformations are known as the frontend and backend(s) - for more than one processor type - of compilers).

 

[Perkel]

Also what kind of fruit is "boner"?

probably something the same as "Flying Penis Monster" in my earlier exercise,
though i didn't write "boner" i wrote "bone"

Yes, very important. That's why you can have two lists and they can point to the same elements.
It also means that by removing an object from a list you do not delete the element itself!
In practical terms it however normally amounts to the same, because if there is no other object referencing it, the garbage collector will pick it up and delete it for you.

So when i delete things i actually delete pointers and then language garbage collector checks for address spaces without pointers and clears them out ?

neat.

I assume that there is no garbage collector in lower level languages like for example in C/C+ ?

And if yes this naturally has probably consequences to speed as it is process that constantly runs in background looking for pointerless addresses in memory ?

 

[7h30n]

Slight correction: x is a different pointer than y. But both pointers point to the same memory. In higher level languages they are called references. The difference being in that with pointers you can manipulate what memory they point to directly while with references you cannot.

And there is also a but. Some things are not references - primitive types. So for example if you do in python:

x = 3 # x is int with value 3
y = x # y is an int with value 3
y = 4 # y is an int with value 4
print x # prints 3

This also means if you pass an int to a function it will be copied.

That's why I mentioned in one post you should look into pass by reference and pass by value.

I don't get above.
If x and y now have same address space then why x didn't change to 4 ?

I can't fallow how it would look like in assembler:

x is defined and it takes adress in memory let's say adress "a"
then we type function so pointerx ------ > 00000003 to adress "a" Adress a now is 00000003
y is defined it takes adress in memory let's say "b"
but y pointer changes to x pointer so changes in y will lead to change 00000003 to something else
then we change 00000003 through pointer y to 00000004
we print out memory space connected to x and that should give me hex ending with 3 not 4.

Almost.
x = 3
This allocates space for an integer in as you say address "a". btw adresses are usually written in this hex format 0xHEX_NUM (or lowercase) so I'll use that.
x points to 0xA and fills the memory with value 3
y = x
This also allocates new space for an integer to address 0xB and fills it with the value 3.
y points to 0xB, and 3 is stored at that address. This effectively makes a copy.
The rest is good:
y = 4
writes 4 to where y points to, and y points to 0xB
print x
prints the value that is stored at the location x points to 0xA which is still 3

Remember pointers point to memory. You cannot change a pointer in Python, but you can change the value at the memory the pointer points to. You probably shouldn't bother with memory layouts and pointer at this level. The important thing to take from here is most of the stuff in Python passes around where the stuff points to so you can modify it "in place", but there are some things that have their values copied instead (like integers).

 

[SCO]

So when i delete things i actually delete pointers and then language garbage collector checks for address spaces without pointers and clears them out ?

neat.

I assume that there is no garbage collector in lower level languages like for example in C/C+ ?

There are implementations in C and C++, but they require code that intends to use them. You can't just put in some compiler flag and presto (unfortunately) - although there are projects that compile C code into javabyte code or whatever. This is naturally slow and buggy because of a great many reasons, but if you're desperate for a library it's a option.

As for speed of higher level languages, the greatest hit is the other safety measures these languages also implement. Namely every array access must be checked to not access invalid memory anyway. GC is still costly ofc, but there are differences. Java GC is faster than python for instance (both because of design tradeoffs and a great deal of money applied).

That's why Rust was designed. It's trying to move the checking of invalid memory operations from the runtime (GC, array checks), to compile time, so it's both safer and still as fast as C. It's a more complicated language naturally.

 

[Perkel]

So Rust checks invalid operations in compiler and thus after compiling program doesn't need to check it anymore (as it was checked in compile stage), this way Rust runs at full speed unhindered by constant memory checks that eats into performance where other languages need to run it after their compile stage or in interpreter.

Wow that looks great compared to other languages. Where is the catch though ? I mean something like this seems to be very logical and i doubt people writing for example C+ standard wouldn't know it especially considering it has compilation stage where those things either way are checked ?

Maybe it has something to do with security as for example i would be able use my Cheat Engine change some values and brake math behind code generating ponterless addresses that wouldn't be cleared as there is no GC running in background ?

 

[SCO]

Nothing to do with security. The 'catch' is that usually these efforts lead to complicated new languages. The X10 language by IBM for instance, made every function primitive and array argument declare their expected domain. It was safe, but butthurt programmers don't adopt safe but wordy unless they're forced to. Rust is extremely pedantic about 'borrowing' (and the computer is always right).

Actually, i'm not sure if Rust is actually tackling invalid array access. Maybe it's only no-gc safety (which is easier). I recall microsoft research was doing something OS level for this.

 

[SCO]

Oh and it's impossible to evolve C++/etc to evolve to run 'safely' and still compile current code in the wild. Because it's not safe. So there is no point in the C++ std putting out a new language and pretending it's still C++, that was the original mistake. 'Hey guys, it's C, but with classes, and it's totally compatible forever' (it wasn't). Not that it stopped them... *grumble* C++11.

 

[Perkel]

Thanks SCO and the rest of you for your knowledge this day cleared up a lot for me a lot of things i had in mind.
I didn't do much today in therm of coding but overall it is day on great +.

Also i need to look for those primitive not primitive things tomorrow and finish up python training program as there are like 2 more things to do (oo and i/o i think).

Also question on difference between languages that run compilers and languages that are done in interpreters.

Compiler type language:
+ doesn't need anything more after compiling
- it is not real time/ compiling can eat your iteration time

Interpreter type language:
+ faster in therm of iteration as for some cases you can see your code executed instantly
- it requires source instalations (python, java) to run

Is that comparison right ?

Because if yes this more or less means that for learning purpose i should choose interpreters as my iteration is more important for now.

 

[SCO]

edit: never mind, here you have a lot of nerds discussing it:
http://stackoverflow.com/questions/...time-compilation-versus-ahead-of-time-compila

 

[Burning Bridges]

The simple answer is that C++ is a glorious way to create machine code. This should not keep you from learning C++, you should only know that sooner or later you will come into contact witrh things from the machine code world.
When that begins, some people begin to panic. But it's absolutely possible to learn C++ as a beginner, and it can teach you a lot of things that can be useful in safe languages. If youre not afraid of assembler and how computers really work you should try it.

 

[7h30n]

Also what kind of fruit is "boner"?

probably something the same as "Flying Penis Monster" in my earlier exercise,
though i didn't write "boner" i wrote "bone"

Yes, very important. That's why you can have two lists and they can point to the same elements.
It also means that by removing an object from a list you do not delete the element itself!
In practical terms it however normally amounts to the same, because if there is no other object referencing it, the garbage collector will pick it up and delete it for you.

So when i delete things i actually delete pointers and then language garbage collector checks for address spaces without pointers and clears them out ?

neat.

I assume that there is no garbage collector in lower level languages like for example in C/C+ ?

And if yes this naturally has probably consequences to speed as it is process that constantly runs in background looking for pointerless addresses in memory ?

The simple answer is that C++ is a glorious way to create machine code. This should not keep you from learning C++, you should only know that sooner or later you will come into contact witrh things from the machine code world.
When that begins, some people begin to panic. But it's absolutely possible to learn C++ as a beginner, and it can teach you a lot of things that can be useful in safe languages. If youre not afraid of assembler and how computers really work you should try it.

Perhaps C would be better choice for that since it is more cleanly designed and simpler than C++. But yeah, eventually one of those two should be learned (even only on a basic level) just to get the feel and understanding for the foundation.

 

[SCO]

Fuck C++. If you have to learn it, learn C.

 

[Burning Bridges]

C is a good option, because C++ is also C, the two are usually intermixed.
Personally I like C++ but it's a lot more work, because you write a lot more code per class (header files). Precompiler and IDE are also a pain in the butt if you just want to program. And then there is the constant worry that you create memory leaks, although there are tools to check that, but I have never managed to learn how they work. Never had a real memory leak, but this stuff always worries me, because I don't understand enough about computers.

By the way from application developers perspective I hear only good things about Delphi. A big advantage is that it compiles into machine code and needs no runtime.
This can be advantageous if you want to convince people to install your program - it does not force them to install a lot of stuff from Sun or Microsoft, which might in turn trigger their virus software to raise alarms.
Users only think, if I want to run Hello_World.java why do I need to download 5 other "programs"?
If you deploy Delphi or C++ applications, you can only give them the exe and they will be able to run it (provided that you have tested enough).

 

[Burning Bridges]

My recommendations would be C#, Delphi and CPP.
Java is ok from a language point of view, but to me it feels I let something alien to my system.
It lives in its own virtual world and can never fully integrate with the rest of my programs. If you don't need to work tightly with other applications that's not a problem though.

 

[Burning Bridges]

Thanks SCO and the rest of you for your knowledge this day cleared up a lot for me a lot of things i had in mind.
I didn't do much today in therm of coding but overall it is day on great +.

Also i need to look for those primitive not primitive things tomorrow and finish up python training program as there are like 2 more things to do (oo and i/o i think).

Also question on difference between languages that run compilers and languages that are done in interpreters.

Compiler type language:
+ doesn't need anything more after compiling
- it is not real time/ compiling can eat your iteration time

Interpreter type language:
+ faster in therm of iteration as for some cases you can see your code executed instantly
- it requires source instalations (python, java) to run

Is that comparison right ?

Because if yes this more or less means that for learning purpose i should choose interpreters as my iteration is more important for now.

Not really.

machine code (C, C++, Delphi)
-> compiles into machine code (that's why you also need a target platform)
-> runs directly on your system
-> it may still need dependencies like dlls
-> the current Microsoft compilers need fucked up stuff like manifests and runtimes

bytecode (Java C#)
-> compiles into intermediary language (bytecode)
-> bytecode is run on a virtual machine, and thanks to optimizations not much slower than machine code
-> very safe because the VM manages garbage collection and prevents access to unprotected memory
-> these languages are also considered the "cleanest" and most modern

interpreter (Python, VBA, javascript)
-> does not compile at all
-> source code is interpreted at runtime

Interpreter is slowest, but very fast if you are debugging it. VBA for example is certainly a primitive language but it is nice that you only hit F5 and your program begins to run.
C# is very fast for debugging (at least the older versions), and also absolutely ok at runtime.
C++ is very slow for debugging, compiling a program can take minutes, and often fails for very complicated reasons

The problem with virtual machines is that you will have many different versions, and while it should make things easier it actually becomes much harder.

You can find some interesting articles that OOP is actually a deep pit and that there are much better ways of doing it. It could be interesting to understand other paradigms concurrently.

 

[Burning Bridges]

"Object Oriented Programming is Inherently Harmful"

http://harmful.cat-v.org/software/OO_programming/

“Object-oriented programming is an exceptionally bad idea which could only have originated in California.” — Edsger Dijkstra

“object-oriented design is the roman numerals of computing.” — Rob Pike

“The phrase "object-oriented” means a lot of things. Half are obvious, and the other half are mistakes.“ — Paul Graham

“Implementation inheritance causes the same intertwining and brittleness that have been observed when goto statements are overused. As a result, OO systems often suffer from complexity and lack of reuse.” — John Ousterhout Scripting, IEEE Computer, March 1998

“90% of the shit that is popular right now wants to rub its object-oriented nutsack all over my code” — kfx

“Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function.” — John Carmack

“The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” — Joe Armstrong

“I used to be enamored of object-oriented programming. I’m now finding myself leaning toward believing that it is a plot designed to destroy joy.” — Eric Allman

OO is the “structured programming” snake oil of the 90' Useful at times, but hardly the “end all” programing paradigm some like to make out of it.

And, at least in it’s most popular forms, it’s can be extremely harmful and dramatically increase complexity.

Inheritance is more trouble than it’s worth. Under the doubtful disguise of the holy “code reuse” an insane amount of gratuitous complexity is added to our environment, which makes necessary industrial quantities of syntactical sugar to make the ensuing mess minimally manageable.

 

[baturinsky]

If you deploy Delphi or C++ applications, you can only give them the exe and they will be able to run it (provided that you have tested enough).

Depends. It's quite likely that you will need some MC redistridutable.

 

[SCO]

Inheritance can be bad. Interfaces/Traits are extremely fucking useful. All the good parts of object orientation were adopted by modern "functional" (not very much anymore ah ah) languages. And vice versa.

 

[JMab]

There's a huge amount of advice in this thread that covers a vast about of programming topics, for a guy trying to write a text adventure in Python!

But... to add even more advice, I'd agree that inheritance should be used very selectively, and only in a shallow class hierarchy when you do. I'd say that the one place you really want to avoid inheritance in a game is when you design your entities (or game objects, or whatever you call them). Rather than using inheritance and having "is a" relationships like "Entity is a 3DModel", "Entity is a RigidBody", "Entity is a ScriptControlledEntity", which as you can imagine would quickly become completely unworkable, you use composition so "Entity has a 3DModel", "Entity has a RigidBody", etc. This is commonly called the Entity-Component System and is popular in games.

These are obviously OO concepts more commonly seen in languages like C++, C# and Java, but there are classes in Python, so you could design your text adventure in a similar manner. It would be at least good practice for your second game!

 

[Davaris]

There's a huge amount of advice in this thread that covers a vast about of programming topics, for a guy trying to write a text adventure in Python!

But... to add even more advice, I'd agree that inheritance should be used very selectively, and only in a shallow class hierarchy when you do. I'd say that the one place you really want to avoid inheritance in a game is when you design your entities (or game objects, or whatever you call them). Rather than using inheritance and having "is a" relationships like "Entity is a 3DModel", "Entity is a RigidBody", "Entity is a ScriptControlledEntity", which as you can imagine would quickly become completely unworkable, you use composition so "Entity has a 3DModel", "Entity has a RigidBody", etc. This is commonly called the Entity-Component System and is popular in games.

These are obviously OO concepts more commonly seen in languages like C++, C# and Java, but there are classes in Python, so you could design your text adventure in a similar manner. It would be at least good practice for your second game!

The thread got assbergered. But this is the Codex after all.

 

[Perkel]

doing text adventure for now is not a goal. Goal # 2 is to create working functions that will define systems like combatmath, reloading magazine. Practical stuff like that.

It's more about practicing lists/loops and functions for now. I will know what will be my #GOAL2 when i will finish #GOAL1 which is to finish python training program on codeacademy and understand everything there perfectly.

 

[Sam Ecorners]

You won't be a developer. It takes too long to get decent at, and all of your goals are way too ambitious. Just start with modding, write some scripts and forget the full blown developer thing for a long while.

But since you won't do that, att least learn to test, read about proper TDD. Pick a framework, start with web dev, it's easiest. Jango is ok. I, myself, made a pretty decent career slinging rails. Once you get the basics and can deliver clean and stable code, move on to the real thing.

Not like you're going to do that though.

 

[Neckbeard Shitlord]

Learning programming:

1. Learn data structures.
2. Learn algorithms.
3. Learn computer architecture.
4. Learn assembly (easiest programming language, sounds harder than it is). Preferably a non x86 assembly.
5. Put it all together and then you will be ready to learn whatever language you want to use for reals.

That's more or less what a good computer science program will give you with respect to programming. You could probably do a crash course of 3-4 months and get almost as much learning in if you skip the bullshit and just concentrate on these important basics.

Also make sure to ignore almost everyone in this thread. This is the worst case of blind leading the blind I can remember. Some of the people seem smart but are going way too high level. A lot of them are not much ahead of you and shouldn't be telling anyone anything.

This is bullshit undergraduate pap i learned over 5 years ago and that i can't remember very well.

Heap is your normal memory as you think of it. The stack or (in X86 at least) registers are the specialized memory the processor uses to 'hold' memory it is operating on. When you declare a primitive on a function (not on a object) its allocated not in normal memory when it needs to (it would be absurd to have to fetch all the way there to get a '5'), but directly into the processor memory. It's called 'stack' (when it is stack and not registers), because it operates like one. When the processor sees it needs to create some memory it just pushes it down at the end just like a (list/stack). When it doesn't need it anymore (the function ends and returns to the caller) it just moves the stack pointer back to the beginning without bothering to zero the memory

This is why 'smashing the stack' is a hacker thing.

As was mentioned x86 uses register but the stack is still a abstraction on the heap of many languages. Why? It's easier to code a compiler for stackmachines and then adapt the output to registers (the input-output transformations are known as the frontend and backend(s) - for more than one processor type - of compilers).

Trigger warning ahead: sorry but you have no idea what you are talking about and should not be trying to teach anyone to program.

First off, stack and heap are DATA STRUCTURES.

Second, there IS JUST ONE MEMORY POOL.

If you don't understand basic facts like this very well, you will spend your whole life utterly mystified.

That's why in school they focus on data structures, algorithms and basic computer architecture. If you just learn some high level language you will have no idea what's going on even if you work in it for 20 years you will never produce anything but throwaway shit code.

Temporary variables come from the stack. The stack can actually overflow especially in bad recursion, so if some guy is making C++ code and this happens and he doesn't know what's going on, he will have no hope to fix it. So obviously you never did anything in C++ or Java beyond hello world.

Usually programmers are happy when they can fit lots of stuff on the stack instead of the heap. The heap gets fragmented with use and takes a longer time to allocate memory and has other issues as well. The stack is kind of like free money. In C++ you use that to get more performance. In Java you need it to keep the garbage collector from going shitnuts every 30 seconds. If it's in a loop, it should always be on the stack.

 

[SCO]

Shut the fuck up shitlord (are you orgasm again?). While it's 'true' that they're both in ram, parts of the stack are very often found cached on L1 memory simply because it's what the CPU operates in most often. Or did you think it was faster magically?

jesus fucking christ - ignored

edit: also dear, shitlord, the memory heap is not a data structure, you're getting it confused with the other heaps, which are trees - unfortunate naming that.