4 ms·
As I said before, resource management is first and foremost a matter of correctness, so performance is neither here nor there. While you don't need manual resou
by catnaroek 9y ago
As I said before, resource management is first and foremost a matter of correctness, so performance is neither here nor there. While you don't need manual resource management for data structures containing values, you do need it for various types of handles (files, network connections, you name it), which a GC cannot guarantee it will collect at the right moment. There is no reason why you couldn't have GC when it makes sense, and deterministic reclamation where it is required.
- pjmlp 9y ago> There is no reason why you couldn't have GC when it makes sense, and deterministic reclamation where it is required. Which is actually available in quite a few GC enabled languages. I think lack of exposure to multiple programming languages has created this urban myth that there is only one way of doing resource management in languages with a GC. That is what happens when professional schools adopt "one language to rule them all" teaching.
- catnaroek 9y ago> Which is actually available in quite a few GC enabled languages. In existing implementations, not with Rust's static safety guarantees about dynamically allocated resources, sorry. “Just provide some way to disable the garbage collector” raises some obvious (at least to me) questions that are nevertheless not addressed by the alternatives you usually propose: (0) When does it make sense to disable the GC? (1) How do we know we are using resources correctly by ourselves? (2) How do we know we are cleaning up resources correctly by ourselves? (3) How would you rigorously prove all of the above? (Yes, unlike most other programmers, I do prove my programs correct.)
- pjmlp 9y agoI have not written anywhere “Just provide some way to disable the garbage collector”, rather that they offer other ways of managing resources. In Modula-3 or D, as possible examples, a solution might be destructors or scope attributes. The only way to actually be 100% safe would be if everyone would be programming with formal logic, which still requires a lot of research to make it approachable by the average developer.
- catnaroek 9y ago> In Modula-3 or D, as as possible examples, a solution might be destructors or scope attributes. These still allow you to mismanage resources. > The only way to actually be 100% safe would be if everyone would be programming with formal logic, Indeed. In order to construct a correct program, you also need to construct the logical argument that establishes its correctness. So, yes, you have to use formal logic. > which still requires a lot of research to make it approachable by the average developer. s/research/education/ You raise the craftsman to the level the craft requires, not lower the craft to the level of an apprentice.
- pjmlp 9y ago> These still allow you to mismanage resources. True, I didn't say the solution was perfect, but it is good enough for most devs. > You raise the craftsman to the level the craft requires, not lower the craft to the level of an apprentice. Nice goal, but I doubt you would manage to achieve that to anyone doing enterprise CRUD apps, mobile apps, games, ... to bother one second to learn TLA+, Idris, Coq or similar, unless their jobs depend on it.
- catnaroek 9y agoThe original post to which you replied begins with: > As I said before, resource management is first and foremost a matter of correctness, so performance is neither here nor there. Your proposed alternatives, namely: > In Modula-3 or D, as possible examples, a solution might be destructors or scope attributes. merely offer automation, not verification. Automation without verification simply makes screw-ups harder to undo.
- nickpsecurity 9y agoReplying here since your other comment may be gone. When you phrased it as trees and graphs, it made a lot of since given I looked previously at languages like term-rewriting that did stuff like that. I'll pay you back with one of my most recent finds on handling trees with dedicated language: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/toplasFAST.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... I agree with you on your point that you can mix GC and manual management selectively. As pjmlp, there's quite a few things in between full manual and GC, though, to add to that claim. Ada also has techniques with contracts recently added. Any language with contracts then adds even more if one can express the property in the contract logic for manual or automated methods. Far as performance, it matters so much that the biggest ecosystems either got there due to better cost/performance ratio or marketing moves by big companies. Those are arguably more important if one wants mass adoption with all the library and funding benefits that come with it. Both Go and Rust are nailing it in their respective niches by balancing performance and safety benefits. Even Haskell developers invested lots of effort into compiler performance with some commercial uptake happening as a result. I tell language authors to ignore performance or ecosystem compatibility at their language's peril.
- catnaroek 9y ago> Replying here since your other comment may be gone. I deleted it because zenhack's reply was better. > Those are arguably more important if one wants mass adoption with all the library and funding benefits that come with it. I couldn't care less about “mass adoption”. Also, working on the Right Thing (tm) doesn't require a lot of money. It requires an intrinsic scientific motivation, and patience to polish programs until they are flawless. > I tell language authors to ignore performance or ecosystem compatibility at their language's peril. Performance is important, but only after correctness has been established. It doesn't matter how fast a program is if it doesn't work. As for “ecosystems”, again I couldn't care less.