Imagine you are designing a practical relatively low-level programming language to use instead of C++. What approach to memory management would you use?
In case someone asks, ``what is wrong with manly manual memory management in C++?'', I would briefly explain my disdain towards it. C++ strives to allow for efficient programs to be written, yet you have to jump through hoops and remember 30 different things if you want to avoid inefficiences C++ compilers inject into your application code. Where C would hit the spot with passing of pointers, C++ programmers need to know about RVO and const references and rvalues and perfect forwarding and noexcept declaration of copy constructors (why even have copy constructors anyway‽ how sane is having such thing‽) and reference collapsing rules. All just to prevent compiler from inserting procedures that needlessly copy your data multiple times here and there.
Instead of fixing a conceptually shitty design the committee adds 5 even more shitty things, each with its own semantics, each designed to work around one compiler/stdlib deficiency or another. Each has to be used manually.
So C++ programmers spend their brain cycles on recalling hundreds of shitty techniques while churning out code doing stuff which would be trivial for a saner language compiler to infer, instead of focusing on actual functionality.
Since it is lunch time where I work, I want to fantasize about a language/compiler which has most or all benefits of fast memory management (no GC), takes modern hardware into account, and doesn't fucking get in your way every time you pass a string to a function.
All these academic languages are taking the wrong approach. Every time one of these new languages is made, it comes with a ton of new rules about how you can use different types together and what operations you can perform in what kinds of functions. Academia is making up new rules of safety faster than it can write code to implement them!
C and C++ have flaws, but they get the fundamentals right: They put the programmer in control. Any language that violates that principle, even in the interest of addressing those flaws, is built on the wrong idea. Any language based on garbage collection, or restrictive rules of safety, is just wrong. Programming is not about letting the computer figure out how to do it for you. You have to know what you're doing. You have to be the expert. If you depend on academia to know your field for you, they won't. You have to be the one who does your own job.
>>45 Gee, why oh why don't nuclear plants put their employees in control and force those ridiculous safety rules upon them? "The languages which put the programmer in control" can't even handle concurrency properly, for fuck's sake. Which is why your favorite C and C++ are thankfully getting flushed down the drain.
Why can't you retards understand that the speed of software development is proportional not to the number of low-level good-for-nothing LOC, and not to the number of pointer bits the "l33t macho coder" can fuck around with unsafely, but to the number of lines of code the programmer gets correctly on first try. And in order to get things fucking correctly right away, you need a safe language in which the compiler will shove your mistakes in your face as fast as it is (non-)humanly possible.
You have to know what you're doing. You have to be the expert.
Exactly. You have to know the problem domain and what you're doing in it. Not the tedious and and unproductive bookkeeping that goes along with it.
Fuck, when I want to print hello + str, I just write print $ "hello" ++ str, not
allocate me a goddamn buffer of some fuck-do-I-know size; run a cycle where I have to manually screw little integers around to fill the buffer; print the string from that buffer; don't forget to free the buffer
In fact, Idris and Rust allow you to do all the same mutable whoring that you think is so empowering about C and C++, except that it will be safe AND high-level.
>>48 Your example doesn't really hold for sepples, so I don't know why you included it. If you have a std::string str("sex") you can simply say std::cout << "butt" << str to print it.
There are valid criticisms for sepples, but yours was not one of them.
implying academic safety rules work in practices, instead of getting in the way.
C/C++ is a enormously popular, yet the most unsafe language after machine codes. PHP is somewhat safer, yet its practical problems arise from unescaped queries, memory leaks and bad scoping - none of these problems is fixable with static analysis. You can probably invent some overly-complex static query verifier, which would have failed miserable in practice, even if any potential user had time to learn it.
The major problem of functional programming languages is the construction of many temporary data structures, which makes manual memory management impractical. Thus arises requirement for automatic memory management, usually implemented through heap and garbage collection process (GC), which determines obsolete data and frees its memory. Heap-based GC processes are complex, requiring suspending execution and copying large chunks of memory to avoid fragmentation, which impedes allocation of large continuous data structures. To avoid pauses, modern GCs uses generations, but generations are still unreliable, uncontrollable by user and poorly map to memory usage.
Symta's motto for memory management is "no heap - no garbage". By using just stack we can compact incrementally and use stack frames naturally as garbage collector generations: when a function leaves a stack frame, all frame's data is freed or compacted to parent frame. A good example would be a video game engine `render_frame`, allocating a lot of per frame data, which won't be needed for the next frame. Stack provides explicit, intuitive and predictable way to manage memory.
Name:
Anonymous2014-11-03 7:46
>>54 Fragmentation arises without automatic memory management just as well. "No heap - no garbage" is just idiocy. Heaps were invented for a reason, obviously.
Symta's motto for memory management is "no heap - no garbage". By using just stack we can compact incrementally and use stack frames naturally as garbage collector generations: when a function leaves a stack frame, all frame's data is freed or compacted to parent frame. A good example would be a video game engine `render_frame`, allocating a lot of per frame data, which won't be needed for the next frame. Stack provides explicit, intuitive and predictable way to manage memory.
Rust does this. It's not enough for 100% of use cases, which is why the system is extended with other features like refcounted heap objects.
>>55 If the compiler can statically determine that a memory object will outlive the context in which it was first allocated, and also identify the context in which it should be deallocated, then it can be allocated in the latter context's stack frame.
Rust does this. It's not enough for 100% of use cases, which is why the system is extended with other features like refcounted heap objects.
I've looked up Rust, and it appears to do different thing - smart pointers and allocates on heap.
If the compiler can statically determine that a memory object will outlive the context in which it was first allocated, and also identify the context in which it should be deallocated, then it can be allocated in the latter context's stack frame.
We all know that static code analysis is impractical bullshit. The promising at first field of program verification has degenerated into a vulgar pathological science, inventing perpetuum mobiles. It is impossible to build Facebook with Agda, the same way it is impossible to prove halting, unless you work on a toy problem.
I've looked up Rust, and it appears to do different thing - smart pointers and allocates on heap.
It is capable of both. You tell it on an object-by-object basis which approach you want it to use.
We all know that static code analysis is impractical bullshit.
Don't be ridiculous. First of all, nobody is seriously calling static analysis a panacea for every programming problem you might ever have. Second, all compiler optimizations involve some limited application of static analysis. If you're actually taking a hardliner stance against it, you are wasting your time by interacting with a computer. They are built on static analysis of problem spaces.
As for comparing Rust to Agda, your ignorance is just disappointing. Escape analysis (statically determining where on the stack to allocate an object without being told by the programmer where to put it) has been part of Java for years. When Java is unable to decide where to put an object, it leaves it on the heap. When Rust is unable to decide, it flags an error and tells the programmer to be more specific. It's not magic.
Don't worry! I have no chance outdoing the ridiculousness of academia crackpots.
First of all, nobody is seriously calling static analysis a panacea for every programming problem you might ever have.
So far it haven't been even a leech therapy level efficient.
all compiler optimizations involve some limited application of static analysis.
No. They involve explicitly stating what you want. Like using "restrict" keyword or using bytes instead of 64-bit integer.
If you're actually taking a hardliner stance against it, you are wasting your time by interacting with a computer. They are built on static analysis of problem spaces.
Compilers are built on translating high-level code into machine code.
When Rust is unable to decide, it flags an error and tells the programmer to be more specific.
You may as well use C++. Rust solves the wrong problem.
It has to be one or the other. Those two ideas don't work together.
As for comparing Rust to Agda (...) When Rust is unable to decide, it flags an error and tells the programmer to be more specific.
That is what Agda does.
Name:
Anonymous2014-11-03 19:52
>>60 Escape analysis is a flawed concept. When a function returns, the calling function should grow its own stack frame and move allocations into it, skipping anything that's no longer used. See >>54
Name:
Anonymous2014-11-09 9:23
I think the ideal is a language where there is a pure (total) core functional language, and where all effects, including non-termination and exceptions, are banished to a secondary language (e.g., monad). An example is Coq + the Ynot monad.
There, you get the best of both worlds. You get to evaluate the pure fragment CBN, CBV, or CB-need or however you see fit. (Though I think I prefer a cost model that leans towards CBV to avoid the space problems. However, to support control-abstraction, which I also think is important, you might lean towards CBN or CB-need.) You get to factor everything out with "let" if you like. You get to do de-forestation. The compiler doesn't have to do strictness analysis. You can add "strictness" annotations to types or calls to seq and have it not break all of those nice properties Haskell folks claim they have for small programs, but never have for big ones.
There are other advantages. Integrating dependent types is easier. Embedding DSLs with control requirements that rule out divergence or exceptions becomes possible. And you get to do Curry-Howard, something you can't pull off in Haskell at all, and in ML only when you do silly things like restrict dependencies to A-normal form (c.f., Leroy's modules.)
A whole bunch of copying. Your stack will be slower than conventional stacks.
Also what about static vars? Consider: 1. Function F1 calls F2 which returns, but it's got some static vars that it will need for its next invocation. 2. These static vars get copied to F1's frame. 3. F2 gets called again, it needs the static vars, but they're already in F1's frame. So either they'll need to be copied back to fucking F2's frame, or F2 will need access to all the frames on the stack.