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.
Name:
Anonymous2014-10-21 8:25
So here is a bunch of my crappy ideas, in no particular order.
∘ There is a limited number of types in a language. Writing memory allocators for each is tedious. Why not make an arena for each by default? ∘ However, some containers might enforce that their data (objects) lie in a continuous chunk of memory (think vectors). In this case, objects ``owned'' by those containers will be moved there (see next item). ∘ Compiler can infer which data is used simultaneously, and improve its locality. It can even do it in runtime to certain pieces of data (if it knows which pointers point to which; atomic swap of objects AND pointers requires locks though; need to think more about it). ∘ Objects are created on heap by default, and passed around by reference. However, if an object is a temporary or a function-local thing which is never returned or stored outside of function-local or temporary containers, it may be allocated on stack. You have no say in where exactly the object will be created.
I have not been thinking about it for long, so the ideas are likely very crappy and unrealistic and troublesome. Maybe you have better ones. Let's listen.
Name:
Anonymous2014-10-21 8:25
C is the language you are looking for. malloc() and free() are usually very fast, it does not have a GC, compilers will optimize for modern hardware, and it never gets in your way of passing an argument to a function.
This is simply not true. And you have to use them carefully if you want anything resembling efficiency.
>>4 Did not yet have the chance to look at it, but it sounds very promising.
Name:
Anonymous2014-10-21 10:11
I just want to make my anus haxing device that goes directly to the prostate and does all the work for you. Maybe it can even change size. I can walk around Akihabara with a tiny stick the size of a pencil and just wait for some asshole to give me the stinkeye. Then I shove it straight up his anus and it expands to ten times that size! Haxxing so bad that he may never walk again.
Name:
Anonymous2014-10-21 10:23
// this program will use at most 10KB #define MEMSIZE 1024*10 static char mem[MEMSIZE]; static size_t nalloc;
>>7 The commet lies. It obviously takes at least 10KB + sizeof(size_t) + whatever the stack needs (which is very hard to figure out in practical cases)
>>11 //this program will use at most 3 inches of RAM
Name:
Anonymous2014-10-21 15:04
>>11 The other one is JEDEC but only sandniggers use JEDEC.
Name:
Anonymous2014-10-21 16:19
i would go for a racket-style garbage compiled language with support for explicit C-style memory management through malloc/free for when ya really need it.
Name:
Anonymous2014-10-21 19:08
>>5 You can't screw up allocations in Rust without being aware of it. Heap allocations are explicit and assigning to pointers only copies if you actually create a copy during the assignment.
Name:
Anonymous2014-10-21 22:52
>>15 I feel like Rust has a lot of good ideas, but suffers from the enormous complexity of having both "everything is manual/explicit" and "everything is safe." They basically reinvented a worse version of ATS. It's a shame all that work went nowhere.
>>16 I'm nearing the end of a two week project using Rust. My main motivation writing with Rust is to avoid writing with any C++ nightmares in the future.
Unfortunately, I'm arriving at a similar conclusion which you mentioned. It has good ideas to be implemented on a lower level lang. However, the explicitiness, lack of higher kinds, funky fn names for simple stuff, and tiring conversions between primitives can be really annoying at times. Sometimes, it's too much because now I have a 150+ col one liner which would have been 50 col in C. Its verbose and complex syntax is difficult to read.
I really want to like it more than its currently worth. And I'll probably use it off/on and before/after it hits 1.0 because I'm sure as hell won't ever be going back to C++. But I don't enjoy it as much as its capable.
Name:
Anonymous2014-10-23 6:40
>>16 ATS syntax looks like someone trying to stir a vomit-covered wine glass with excrement in it with a fork.
Name:
Anonymous2014-10-23 14:07
>>18 I'm just happy it's nicer to write than C++. Even nicer than C most of the time because of the abstractions you can use.
Name:
Anonymous2014-10-23 18:02
>>20 But "nicer" by how much, exactly? Is it really nicer in ways that Ada (for example) isn't?
Name:
Anonymous2014-10-24 7:27
>>21 Ada is a great language, shunned for some unknown to me reason by many.
>>24 That's what NSA would like you to think. They have destroyed evidence in the past, and will destroy evidence of tampering with Ada should you raise the issue.
>>23 That's not a problem if you're programming for them.
Name:
Anonymous2014-11-01 16:09
Reason 2: Ada hath no metaprogramming.
Name:
Anonymous2014-11-01 19:09
Ada Wong
Name:
Anonymous2014-11-01 22:53
Just do manual memory management and use tools to catch memory leaks and use-after-free. This is not something that needs support at the language level.
Name:
Anonymous2014-11-02 8:51
Hey, I didn't know that Idris is headed for uniqueness types. They've built an experimental level of support for them:
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.