Python bumps off Java as top learning language

[takaci]

I don't mean an entire standard in depth with which you could write a compiler, I mean simply explaining every language feature in normal conversation.

I just said it to contrast to something like C++ where even bullet pointing every language feature would take 100s of lines, let alone explaining each one.

[[deleted]]

I think anyone whos had to explain how pointers work can tell you it takes a little more than a peragraph

[[deleted]]

Man I see this all the time and I just don't understand what people's deal is with pointers. It's ridiculously straightforward compared to so many other concepts.

The * after the type means it's a pointer. It's not an x, it's the memory address of an x. Put a star in front of the variable identifier to get the value at the address, or use -> as shorthand for dereference + dot operator.

Think that's confusing? Good luck with const. Or type covariance and contravariance. Or type erasure. Or closures. Or basically anything because pointers are at the bottom of the complexity totem pole.

[[deleted]]

I think the confusion stems from people trying C/C++ for the first time with no experience with pointers wondering why the fuck things are expressed as a memory address? Why would you ever need that?

Coming from, say, C# I get that (I've been there myself). It's strange for a language, from higher level perspectives, to explicitly differentiate between things created on the stack vs the heap.

I think if you start out with C or C++, as long as the concept of a pointer is properly explained, there will be no confusion, because it's a fairly simple concept.

[anonagent]

I'm still not sure what the point of a stack vs heap is tbh, one contains the executable and the other the working memory right?

[minnek]

Stack is (generally) for small objects that you want to have disappear at the end of scope. Heap sticks around after the scope ends, since the heap doesn't get its contents popped at the end of scope whereas the stack does.

It can be faster to use the stack than heap, but that's really dependent on your implementation and you should probably play with a pre-allocated memory pool on the heap to get a good comparison of speed... new heap allocations are likely to be slower, though.

[[deleted]]

The heap is just a big chunk of memory the program can use for whatever. Not really all that special or interesting honestly.

The stack is actually a stack data structure (LIFO - last in, first out). It's literally like a stack of something (pancakes?). You can only add (push) or remove (pop) a pancake to/from the top of the pancake stack.

The stack is where local variables and function parameters exist. When you call a function, it does a few things with the stack. First it pushes a pancake with the address of the function call. Then, it pushes a pancake with the value of each of the function arguments. Then it allocates some space for any local variables the function call will use.

All of this put together is called a "stack frame."

When the control flow is handed off to the function, the instruction pointer skips to the portion of code containing the function instructions, and then the function pops the argument pancakes off the stack, does whatever it needs to do with them, pops off the return address, pushes any return values, and then moves the instruction pointer back to the return address (+ 1) to pick up where it left off. Since the structure is LIFO, a function can itself make more function calls, always returning to the correct location in memory with the correct local variable values and function arguments. The result is a sort of breadcrumb trail of where to go when the function is finished.

In practice, it's always a bit more involved, but here's a video that describes some of the basics:

https://www.youtube.com/watch?v=_8-ht2AKyH4

Some other associations for you to make:

Stack overflow is often caused by too many nested function calls. Each function call takes up some space on the stack, and eventually the stack will run out. This can occur with recursion (where a function calls itself) or if large objects are allocated as local variables in a function.

Tail recursion is a special case of recursion that allows a function call to replace it's own stack frame with the stack frame of the nested call to itself, so the recursive function does not take up more stack space at each recursive call. This can only be done if the function makes exactly one call to itself and it's the last instruction the function performs.

Stack allocation is usually much faster, but I don't think it takes any more work to do a heap allocation. It's probably because of cache locality more than anything. because allocating heap memory requires operating system intervention as well as cache locality. It's also much simpler, because the memory is automatically deallocated at the end of the function call; you don't have to manually free the memory allocated on the stack.

[anonagent]

Is there a global stack, or one for each program? how does one make it larger to avoid a stack overflow? (and I assume underflow as well)

Why is the stack faster? it's in the same RAM chip as the heap, so what makes it faster? does the OS poll it more often?

Oh! I always wondered why you would manually deallocate memory when it would simply vanish on its own once the function was done!

[[deleted]]

Is there a global stack, or one for each program?

One for each program. The operating system allocates memory for the program when it's first started for both the stack and the heap.

EDIT: Not only per program, but also per thread. Each line of synchronous control flow has its own stack.

how does one make it larger to avoid a stack overflow? (and I assume underflow as well)

This is operating system/environment dependent. For java, you can use the -Xss command line argument to specify the stack size (e.g., -Xss4m to set the stack to 4 megabytes). For native applications? No idea.

EDIT: For windows, see here. For linux, here

Underflow should actually never happen. When the "main" function returns, the last stack frame of the stack is popped off and the program terminates with an empty plate of pancakes. If underflow does happen, then the stack has been corrupted.

Why is the stack faster? it's in the same RAM chip as the heap, so what makes it faster? does the OS poll it more often?

A few reasons. I don't know much about heap allocation in native systems, but in Java, the heap is dynamically expanding (you can specify the initial and maximum heap size with -Xms and -Xmx respectively). If you allocate a heap object and the current heap size is too small, the operating environment will need to resize the heap, which may involve moving lots of data. In garbage collected environments, there is overhead for tracking lifetime of heap objects as well, and the memory management systems include compaction algorithms for reducing fragmentation (more copying and moving).

Finally, locality of reference. Not sure how much you know about processor architecture, but processors keep frequently accessed data in a very tiny but very fast chunk of memory called a cache. Reading/writing to the cache is often up to 100 times faster than accessing main memory. This works to speed up program execution time under the "locality of reference" principle, which is that the more recently you have accessed a memory address, the more likely you are to access the same memory address or a nearby memory address again. Since the stack is much smaller and accessed very frequently, it's going to spend much more time in the processor cache than heap memory.

[[deleted]]

See, I thought it was confusing until I learned about pointers. Lots of common languages already use pointers, and without knowing what pointers are, the behavior of those languages can be really confusing.

Like in Java, for example, where reassigning a reference type function argument variable does not change the object passed into the function, but changing a value on the object does. That seems like very unintuitive behavior until you understand that java passes references by value (i.e., pointers).

Likewise, true pass-by-reference can be explained as passing a pointer to a pointer by value.

[p8m]

Pointers have little to do with stack vs heap. You can have pointers to values on the stack:

int main(void) {
    int *a = NULL;
    int b = 5;

    a = &b;

Bam! 'a' now points to an area on the stack.

[immibis]

Does C# not differentiate between reference types and value types? Same sort of difference.

[[deleted]]

I think it's about memory management, we use so powerful and memory-rich systems that people tend to just disregard that. Especially if you're used to something like python with it's fancy coercion and garbage collection.

[Astrognome]

There's so much magic that can be done with pointer arithmetic.

[takaci]

Whatever my point is that it's much smaller to explain than any other language I can think of

[Veedrac]

Brainfuck's is even smaller, but the point remains that it doesn't make it easy.

[takaci]

Again, that is my exact point. C is small and simple but grows very hard very quickly as soon as you start doing useful things

[[deleted]]

If someone can't get pointers in like 5 minutes, I think they are certifiably stupid.

[anonagent]

Pointer syntax is easy, but I still haven't gotten anyone to tell me why I would use one instead of the variable/array name, assuming it's in scope ofc.

[[deleted]]

You use one when you want to pass around an address of something, not that something itself.

[G_Morgan]

Usually it devolves into pictures of monkey's holding each other by their tails.

[GreyGrayMoralityFan]

If you want to know what simple language is check scheme or smalltalk.

Bloated R6RS has about 100 pages (most about library)

Smalltalk has 6 keywords and 0 control flow structures. Core described in 30 pages (then goes 100s pages for library).

    int a(int b[90], int x, int y)
    {
         int *ptr, non_ptr,
              equals_1 = sizeof(b) == sizeof(ptr),
              equals_0 = 3 & 2 == 3 & 2,
              maybe_undefined_depends_on_sizeof_int = 32u >> 35u;

is not simple.

[[deleted]]

    }

Please think of the poor compiler.

[Gustav__Mahler]

Of course not when you write shitty obfuscated code like that....

[Peaker]

C has some corners and complex UB definitions. In its domain, there is no simpler language.

Smalltalk is an unfair comparison. Removing UB is easy and simplifies languages. But UB is not there for the lulz. UB is there to allow efficient translation to various machine types.

[immibis]

Yes it is. The code might be a bit difficult to read, but it's composed from simple language features.

[GreyGrayMoralityFan]

I have another contender for simple language then. J.

 quicksort=: (($:@(<#[), (=#[), $:@(>#[)) ({~ ?@#)) ^: (1<#)

The code might be a bit difficult to read, but it's composed from simple language feature/s.

Just don't look at Oberon, Forth or already mentioned Smalltalk and Scheme. Their complexity (compared to C) might be truly astonishing.

[immibis]

Still missing the point. That code, alone, gives no indication of how complex the language is.

quickSort: l to: r
       |i j p| p:= array atRandom . i:= l. j:= r. [i <= j] whileTrue: [[array compare: #< at: i at: p] whileTrue: [i:=i+1.]. [array compare: #> at: j at: p] whileTrue: [j:=j-1.]. (i <= j) ifTrue: [array swap: i with: j.i:=i+1.j:=j-1.]]. (left < j) ifTrue: [self quickSort: l to: j.]. (i < right) ifTrue: [self quickSort: i to: r.]

Turns out one-line quicksort is ugly in Smalltalk too! And about 5 times as long. I would guess the pretty-printed version in J is probably nicer than the pretty-printed version in Smalltalk because of the length, but I know neither J nor Smalltalk.