Poor arguments against

Posted Feb 18, 2015 8:08 UTC (Wed) by HelloWorld (guest, #56129)
In reply to: Poor arguments against by mchapman
Parent article: Scalar typing in the PHP world

> In my experience, the benefits of reference counted objects outweigh these problems. For instance, reference counting gives you guarantees on when an object's destructor is called
Not if the data structure happens to be cyclic, therefore it's an incomplet solution at best. Rust gets this right.

> Perl programmers know that this is the memory model perl uses, so they write their code accordingly;
That's the point, Perl programmers need to think about this sort of things, and this is exactly the kind of thing that a high-level language should relieve one of. Cycles can hide in very surprising places.

Poor arguments against

Posted Feb 18, 2015 8:34 UTC (Wed) by mchapman (subscriber, #66589) [Link] (5 responses)

> That's the point, Perl programmers need to think about this sort of things, and this is exactly the kind of thing that a high-level language should relieve one of.

Yeah, so? All programming languages have required knowledge.

Optimizing a language for new programmers is a losing strategy. You're only new to a language once.

Poor arguments against

Posted Feb 19, 2015 21:52 UTC (Thu) by HelloWorld (guest, #56129) [Link] (4 responses)

> Yeah, so? All programming languages have required knowledge.
This has nothing to do with being new to a language. It has to do with not solving a problem even though the solution is known and has been for decades. Anyway, I don't really care if you agree or not. A language that requires me to think about memory management is not high-level, period.

Poor arguments against

Posted Feb 20, 2015 4:34 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (3 responses)

So what do you call managing space leaks in Haskell if not "memory management"? Or is Haskell not high level?

Poor arguments against

Posted Feb 20, 2015 5:50 UTC (Fri) by nybble41 (subscriber, #55106) [Link] (2 responses)

I don't think most programmers would consider that "memory management". The runtime is still transparently taking care of allocating memory and freeing it when it's no longer required. It's not even a "space leak", really, since that would imply that the program is failing to free memory that it no longer needs. When non-strict evaluation results in higher memory use, it's because the inputs to an expression are larger than the final value—e.g. you need the sum of a long list and don't otherwise care about the contents. If you compute the sum eagerly then you can free the list and just store the sum, at the cost of potentially wasting some CPU time if the sum isn't needed later. Since the expression hasn't been evaluated yet, the inputs are still needed, and aren't being "leaked".

This is more about controlling the order of evaluation than managing memory. It isn't something which affects most programs, but it is something you have to be aware of when working in a non-strict language like Haskell, particularly when summarizing large data structures. Sometimes it works the other way, though; for example, `print (take 5 [1..])` requires constant memory (~1 list element) due to non-strict evaluation, whereas strict evaluation would demand infinite memory just to evaluate the `[1..]`.

Poor arguments against

Posted Feb 21, 2015 6:08 UTC (Sat) by zlynx (guest, #2285) [Link] (1 responses)

This sounds like exactly the sort of arguments Java programmers start to make when their software takes up too much RAM.

"No, it isn't a memory management problem. We just happened to completely redesign the object storage system to better manage object lifetimes."

And you look at what they did and realize it would have been simpler to write it in C++.

Poor arguments against

Posted Feb 22, 2015 5:07 UTC (Sun) by nybble41 (subscriber, #55106) [Link]

I realize this thread is getting way off topic, but the original point was about actual object leaks in Perl where objects with cyclic references will never be freed, even if none of them are accessible from active code. That is a good example of a problem with memory management, or rather a failure of the system to manage memory automatically. Dealing with cycles is one of the basic functions of a garbage collector; if you have to design your program to avoid them or risk leaking objects, you might as well be managing memory manually.

Anyway, the point was that the fundamental purpose of memory management is to recognize and free memory which will never be accessed throughout the remainder of the program so that it can be reused for new objects. In C++ all memory management is manual. Breaking cycles in Perl is something the programmer must do to ensure that unreachable objects get freed. That is low-level manual memory management. Redesigning an object storage system to better track object lifetimes is also memory management, albeit at a much higher level: an ideal garbage collector would recognize "reachable" objects which will in fact never be accessed regardless of the input and free them; manually removing the references is a hint necessitated by imperfect garbage collection.

On the other hand, I would not consider modifying an algorithm to compute a result a different way to be memory management, even though it may have an effect on the amount of memory required. Changes in evaluation order can have a fundamental impact on the nature of the program, to the point of altering whether it's computable at all within finite time. This is not to say that managing the order of evaluation in Haskell is any less work than managing memory manually in C++, just that it doesn't come under the heading of memory management. The equivalent task in C++ would be designing the algorithm, though in C++ it's much more difficult to defer evaluation, and you're consequently less likely to consider that option.