You're now talking about different problems. 1. Memory management. 2. Resource management.
GC solves memory management.
For resource management, there should be a language construct that brackets use of the resource. A bracket construct like a 'for' or 'while' loop. At the top of the bracket construct, as part of the language syntax, the resource is allocated, and the compiler generates the code to guarantee closing / releasing the construct at the bottom of the bracket construct. As an example, I would point out Java's 'try' with resource. Any object that implements the AutoCloseable interface can be used in this construct. A file. An IO Stream. A SQL connection. A SQL result set. In Java locks have been handled since the 90's with the 'synchronize' block with brackets. Since these constructions are all part of the language syntax, the compiler generates the code. It works on every platform. And there is GC.
Why not use the resource management idiom to manage memory? Because you don't necessarily release memory in the same place as you allocate it. A library API call may allocate some complex structure and return it to the caller. The caller may pass parts of that structure into other library APIs written by other authors, in different decades of past time. Even if I let go of my main reference to the main structure. other code may be holding on to sub-parts of that original complex structure. With GC you simply don't have to worry about when to release anything. If you no longer use it, just let pointers fall out of scope. Or assign null to a pointer in an object so it no longer points to anything -- thus possibly making what it did point to become GC'able.
I like both dynamic and static typing. I also like some strong typing systems that seem like dynamic typing.
In a small program, you can't beat dynamic typing.
If you build a very large program, you quickly learn to appreciate static typing. Especially as the program ages over the years. A large dynamically typed program becomes very brittle with age. Anything you change you have to worry about how and whether it will break something. Are you really sure your tests cover every possible execution path in a very large program? With static typing, if you break something the compiler spots it instantly and you see files start turning red in your editor. Or rather, in the project pane where the file tree lives.
I would be happy for you to educate me about these better ways. I have used GC for decades. I have given the GC problem a lot of thought -- but have never formally implemented anything.
The first obvious different approach is reference counting. Every time a new pointer is created to the same object, the object's reference count is incremented. Every time a pointer no longer points to an object, the object's reference counter is decremented. If the reference counter reached zero (no references), then you deallocate the object -- which also means that any pointers it contains no longer point to other objects, thus decrementing their reference counters, and so on. It sounds good. But wait! What if you end up with a cyclic reference? A points to B. B points to C. C points to A. Even if the last pointer to A is removed, A's reference count is one because of C. C's reference count is one because of B. B's reference count is one because of A. Only a GC can solve this.
Mabye you've read an old Vulcan saying that any sufficiently complex program ends up re-implementing a poorly specified, bug ridden Lisp inside of it.
In an immensely complex program with immensely complex data structures, I could come up with a memory management discipline in, say, C++. But why? I could write my entire program in assembly language too. But the whole point of using higher and higher level abstractions is to increase human productivity. And the whole point of this slashdot topic is about what would a language have if the overriding goal was to make human programmers more productive -- disregarding execution performance. Why is it okay to disregard compute resources? Answer: because they are cheap and now scalable. Just throw another hundred gigabytes of RAM at it and call it a day.
Modern GC systems are concurrent and parallel. They run concurrently with the workload. And the GC can run on multiple CPU cores. Just throw another dozen cpu cores at it. Problem cheaply solved -- compared to programmer time and cost. Obviously, I'm talking about software and hardware that is not for "my little pony" type applications.
It sounds like you believe that we could never face a legitimate crisis of defending our freedom or even our existence.
I understand how the military gets misused by politicians owned by corporations. That doesn't mean we don't need to have a military in case a genuine, non-contrived need were to arise. I believe we should take care of these people. Educating them for a good job is probably better for society than letting them rot and have to be supported by taxpayers. Given the opportunity for education, I believe most ex-military people might probably have better motivation and ambition.
An infinitely fast computer doesn't make programmers infinitely fast. The question was about making human programmers more productive without focusing on the execution speed. What would your ideal language have to make YOU more productive if execution speed was not something to worry about?
The question is not stupid. It is to get one to think about what makes a human programmer more productive and not to focus on the computer execution speed. The way I read it is that even if a language was interpreted on a mechanical system powered by rodents running on spinning wheels; what attributes of a great programming language would make humans more productive at programming if execution speed were not a factor for consideration? If somehow your programming language would be fast and you didn't care how, then what would you want in a language to make your life more productive?
Writing everything in BASIC does not achieve the desired outcome. The problem stated design for human productivity only (or coding productivity it said). While I was very fond of interpreted BASIC four decades ago (yes, I really was!), it is simply too low level a language. I would not try to use BASIC to write, say, a Sudoku solver. Or Rubik's Cube solver. Or a compiler. Or a modern large web application.
I think the reason the problem stated infinite speed was so that everyone would focus on human productivity and not squibble about performance issues like static typing vs dynamic typing. Or compiled / interpreted. Etc.
> If [GC] happens automatically at infinite speed, removing it would have no effect on your coding productivity.
Having GC improves productivity. You no longer need to free anything you allocate. It does not mean you have infinite memory. Just that the system will deallocate things for you.
Improving productivity was one of the requirements of the problem statement.
Static typing is not just about performance. It is also about program correctness and ability of your IDE to provide powerful refactoring capabilities.
> then we could perhaps use higher languages for real time.
You can already use GC languages for soft real time. Like a game. Or signal processing. Simply DO NOT allocate any data structures during the soft real time loop. Set up everything. Allocate all data structures in advance. Then enter your soft real time loop, do your signal processing, high frequency trading, game loop, etc.
I would point out that big banks and enterprise applications use Java. Java is used in high frequency trading. So are other languages. But the fact that Java is a GC language is my point.
GC doesn't mean infinite memory. It simply means the programmer doesn't have to expressly release memory.
One of the problem definitions was to increase human productivity. GC does this in spades. Is it any wonder why so many modern and high level languages have GC? Python. Java. C#. JavaScript. All lisps. Logic programming languages. CAS (computer algebra systems).
GC doesn't let the programmer allocate infinite memory any more than C lets you allocate infinite memory. The difference is that you no longer have any concern about deallocating it. Just like you don't have any concern about which branch instruction to use. Or how many bytes back the relative branch instruction is for this while loop. GC is simply one more burden that higher level languages remove from the programmer.
> The only big problem with garbage collection IS performance.
Actually if you can have several times the memory than your program actually needs, then performance is no longer an issue with any modern concurrent GC.
I'm serious.
Programmer time is expensive. Hardware is cheap. Memory is cheap. Would you rather get your code to market sooner because you can use a higher level language without memory management in exchange for adding an extra 32 or 64 GB of memory? Getting to market sooner may be the difference between being in business or not.
One of the goals of the problem statement was to improve human productivity. Therefore GC would be a requirement. Not having to manually manage memory removes a large burden from programmers.
GC has an often overlooked, but fairly silent other advantage. It greases the compatibility of libraries written by many different authors. All of the libraries are guaranteed to have the same memory management discipline. Just to pick on C / C++ for example, multiple libraries might have different memory management disciplines. It is necessary to understand whether the API has special functions to deallocate some structure, and who is responsible for such deallocation. With GC all of that disappears. If an API call hands me back a datastructure, I just let go of it when I'm done with it. No concern about who deallocates it. The GC is what deallocates it when there is no longer a reference to it.
Another important attribute would be toolability. Java, for example, is very toolable. IDEs for Java are able to statically deduce a great deal and then offer intelligent suggestions to auto complete things as you type. There is doubt about what type of parameter some function has -- because it's statically typed. There is no doubt about what local and global variables you have available, of that type, which could be passed as the actual value for that parameter.
Basically the Editor knows about your source code as well as the compiler does. If you click on some function name, or variable name, or class name, it is unambiguous where it is declared.
Modern Java IDEs also can intelligently rename things. If you rename some identifier, the IDE knows precisely what other parts of your entire source code base need to have this same rename done. If I change function 'abc" to "def", not only is the declaration changed, but every reference to that function throughout the program. But if there were another local function somewhere else with the name "abc", it would not be changed, nor would references to that. The compiler knows exactly, unambiguously what references what.
There are many other powerful refactoring tools as well. People who say they will use a simple text editor because they don't like the bells and whistles of a modern IDE is like someone saying that they would rather dig a huge ditch with a shovel because they don't like the noise of a backhoe.
Static typing would be a must for large programs. Modern languages with type inference allow you to avoid typing in much of the type information, yet still have static typing.
Static typing is not primarily about performance (although it is about that). (And the problem definition said performance is infinite.) Static typing is also about correctness of code and compile time checking, and the toolability and refactoring I mentioned.
> He was paid wages for hose 12 years. He got *exactly* what he deserves.
He gave up the best young years of his life to defend your freedom while you were getting your education. Now that he's done, he should be able to get his education. Even if he got married during his young years, as you might have done.
Another point -- whether or not he had to fight in a war to defend your freedom is beyond his control. What he did is volunteer to be trained and serve, and even fight and die for your and my freedom. If a genuine threat to our nation emerged, or even outright war, he would be the first one fighting. He did a lot more than just have a job. He put his life at some jeopardy in the event that he is ordered to go to war -- whether justified or not.
If he wants to get married at a young age, just as you might, why should he be denied that? Why should it work against him once he gets out of the military and now wants the opportunity to get an education -- which was a benefit promised when he signed up. He chose to delay his education in order to serve his country.
In the year 9995, I will begin seriously brushing up on my COBOL.
In the year 9997 everyone is going to start getting worried about the Y10K issue being the end of civilization as we switch over to five digit years. There will suddenly be a lot of short term COBOL work available.
It sounds nice. But in the year 9995, the COBOL compiler is going to only accept punched cards. The cards must be punched on a keypunch machine that has the Windows 8 Metro user interface with no keyboard. Touch screen only.
In another topic on Slashdot this morning I wrote:
As part of my retirement plan, I will seriously brush up on COBOL in the year 9995. In about the year 9997 everyone will start getting worried about the Y10K problem. People will think Y10K will be the end of civilization as we switch over to five digit years. There will be lots of COBOL work available.
With a modern language, you DO need to think AND plan, if you are building any non-trivial program and it needs to be maintainable.
For trivial programs there are many posers who can quickly turn out unmaintainable crap code heavily copy/pasted from Google and Stackoverflow without thinking or planning.
The posers can't build the large non-trivial program, even in a modern language. Thinking and planning is still necessary. Experience also counts. (Experience measured in code and learning from past programs.)
I promise you that the posers can turn out garbage in any programming language. Even YOUR favorite language.
Slashdot Mirror
You're now talking about different problems. 1. Memory management. 2. Resource management.
GC solves memory management.
For resource management, there should be a language construct that brackets use of the resource. A bracket construct like a 'for' or 'while' loop. At the top of the bracket construct, as part of the language syntax, the resource is allocated, and the compiler generates the code to guarantee closing / releasing the construct at the bottom of the bracket construct. As an example, I would point out Java's 'try' with resource. Any object that implements the AutoCloseable interface can be used in this construct. A file. An IO Stream. A SQL connection. A SQL result set. In Java locks have been handled since the 90's with the 'synchronize' block with brackets. Since these constructions are all part of the language syntax, the compiler generates the code. It works on every platform. And there is GC.
Why not use the resource management idiom to manage memory? Because you don't necessarily release memory in the same place as you allocate it. A library API call may allocate some complex structure and return it to the caller. The caller may pass parts of that structure into other library APIs written by other authors, in different decades of past time. Even if I let go of my main reference to the main structure. other code may be holding on to sub-parts of that original complex structure. With GC you simply don't have to worry about when to release anything. If you no longer use it, just let pointers fall out of scope. Or assign null to a pointer in an object so it no longer points to anything -- thus possibly making what it did point to become GC'able.
I like both dynamic and static typing. I also like some strong typing systems that seem like dynamic typing.
In a small program, you can't beat dynamic typing.
If you build a very large program, you quickly learn to appreciate static typing. Especially as the program ages over the years. A large dynamically typed program becomes very brittle with age. Anything you change you have to worry about how and whether it will break something. Are you really sure your tests cover every possible execution path in a very large program? With static typing, if you break something the compiler spots it instantly and you see files start turning red in your editor. Or rather, in the project pane where the file tree lives.
I would be happy for you to educate me about these better ways. I have used GC for decades. I have given the GC problem a lot of thought -- but have never formally implemented anything.
The first obvious different approach is reference counting. Every time a new pointer is created to the same object, the object's reference count is incremented. Every time a pointer no longer points to an object, the object's reference counter is decremented. If the reference counter reached zero (no references), then you deallocate the object -- which also means that any pointers it contains no longer point to other objects, thus decrementing their reference counters, and so on. It sounds good. But wait! What if you end up with a cyclic reference? A points to B. B points to C. C points to A. Even if the last pointer to A is removed, A's reference count is one because of C. C's reference count is one because of B. B's reference count is one because of A. Only a GC can solve this.
Mabye you've read an old Vulcan saying that any sufficiently complex program ends up re-implementing a poorly specified, bug ridden Lisp inside of it.
In an immensely complex program with immensely complex data structures, I could come up with a memory management discipline in, say, C++. But why? I could write my entire program in assembly language too. But the whole point of using higher and higher level abstractions is to increase human productivity. And the whole point of this slashdot topic is about what would a language have if the overriding goal was to make human programmers more productive -- disregarding execution performance. Why is it okay to disregard compute resources? Answer: because they are cheap and now scalable. Just throw another hundred gigabytes of RAM at it and call it a day.
Modern GC systems are concurrent and parallel. They run concurrently with the workload. And the GC can run on multiple CPU cores. Just throw another dozen cpu cores at it. Problem cheaply solved -- compared to programmer time and cost. Obviously, I'm talking about software and hardware that is not for "my little pony" type applications.
It sounds like you believe that we could never face a legitimate crisis of defending our freedom or even our existence.
I understand how the military gets misused by politicians owned by corporations. That doesn't mean we don't need to have a military in case a genuine, non-contrived need were to arise. I believe we should take care of these people. Educating them for a good job is probably better for society than letting them rot and have to be supported by taxpayers. Given the opportunity for education, I believe most ex-military people might probably have better motivation and ambition.
An infinitely fast computer doesn't make programmers infinitely fast. The question was about making human programmers more productive without focusing on the execution speed. What would your ideal language have to make YOU more productive if execution speed was not something to worry about?
If speed wasn't an issue, how would you design your query language to make YOU more productive?
The question is not stupid. It is to get one to think about what makes a human programmer more productive and not to focus on the computer execution speed. The way I read it is that even if a language was interpreted on a mechanical system powered by rodents running on spinning wheels; what attributes of a great programming language would make humans more productive at programming if execution speed were not a factor for consideration? If somehow your programming language would be fast and you didn't care how, then what would you want in a language to make your life more productive?
Writing everything in BASIC does not achieve the desired outcome. The problem stated design for human productivity only (or coding productivity it said). While I was very fond of interpreted BASIC four decades ago (yes, I really was!), it is simply too low level a language. I would not try to use BASIC to write, say, a Sudoku solver. Or Rubik's Cube solver. Or a compiler. Or a modern large web application.
I think the reason the problem stated infinite speed was so that everyone would focus on human productivity and not squibble about performance issues like static typing vs dynamic typing. Or compiled / interpreted. Etc.
> If [GC] happens automatically at infinite speed, removing it would have no effect on your coding productivity.
Having GC improves productivity. You no longer need to free anything you allocate. It does not mean you have infinite memory. Just that the system will deallocate things for you.
Improving productivity was one of the requirements of the problem statement.
Static typing is not just about performance. It is also about program correctness and ability of your IDE to provide powerful refactoring capabilities.
> then we could perhaps use higher languages for real time.
You can already use GC languages for soft real time. Like a game. Or signal processing. Simply DO NOT allocate any data structures during the soft real time loop. Set up everything. Allocate all data structures in advance. Then enter your soft real time loop, do your signal processing, high frequency trading, game loop, etc.
I would point out that big banks and enterprise applications use Java. Java is used in high frequency trading. So are other languages. But the fact that Java is a GC language is my point.
GC doesn't mean infinite memory. It simply means the programmer doesn't have to expressly release memory.
One of the problem definitions was to increase human productivity. GC does this in spades. Is it any wonder why so many modern and high level languages have GC? Python. Java. C#. JavaScript. All lisps. Logic programming languages. CAS (computer algebra systems).
GC doesn't let the programmer allocate infinite memory any more than C lets you allocate infinite memory. The difference is that you no longer have any concern about deallocating it. Just like you don't have any concern about which branch instruction to use. Or how many bytes back the relative branch instruction is for this while loop. GC is simply one more burden that higher level languages remove from the programmer.
> The only big problem with garbage collection IS performance.
Actually if you can have several times the memory than your program actually needs, then performance is no longer an issue with any modern concurrent GC.
I'm serious.
Programmer time is expensive. Hardware is cheap. Memory is cheap. Would you rather get your code to market sooner because you can use a higher level language without memory management in exchange for adding an extra 32 or 64 GB of memory? Getting to market sooner may be the difference between being in business or not.
One of the goals of the problem statement was to improve human productivity. Therefore GC would be a requirement. Not having to manually manage memory removes a large burden from programmers.
GC has an often overlooked, but fairly silent other advantage. It greases the compatibility of libraries written by many different authors. All of the libraries are guaranteed to have the same memory management discipline. Just to pick on C / C++ for example, multiple libraries might have different memory management disciplines. It is necessary to understand whether the API has special functions to deallocate some structure, and who is responsible for such deallocation. With GC all of that disappears. If an API call hands me back a datastructure, I just let go of it when I'm done with it. No concern about who deallocates it. The GC is what deallocates it when there is no longer a reference to it.
Another important attribute would be toolability. Java, for example, is very toolable. IDEs for Java are able to statically deduce a great deal and then offer intelligent suggestions to auto complete things as you type. There is doubt about what type of parameter some function has -- because it's statically typed. There is no doubt about what local and global variables you have available, of that type, which could be passed as the actual value for that parameter.
Basically the Editor knows about your source code as well as the compiler does. If you click on some function name, or variable name, or class name, it is unambiguous where it is declared.
Modern Java IDEs also can intelligently rename things. If you rename some identifier, the IDE knows precisely what other parts of your entire source code base need to have this same rename done. If I change function 'abc" to "def", not only is the declaration changed, but every reference to that function throughout the program. But if there were another local function somewhere else with the name "abc", it would not be changed, nor would references to that. The compiler knows exactly, unambiguously what references what.
There are many other powerful refactoring tools as well. People who say they will use a simple text editor because they don't like the bells and whistles of a modern IDE is like someone saying that they would rather dig a huge ditch with a shovel because they don't like the noise of a backhoe.
Static typing would be a must for large programs. Modern languages with type inference allow you to avoid typing in much of the type information, yet still have static typing.
Static typing is not primarily about performance (although it is about that). (And the problem definition said performance is infinite.) Static typing is also about correctness of code and compile time checking, and the toolability and refactoring I mentioned.
Blue LEDs are an abomination and their use should be banned. Instead use green LEDs as God intended.
> He was paid wages for hose 12 years. He got *exactly* what he deserves.
He gave up the best young years of his life to defend your freedom while you were getting your education. Now that he's done, he should be able to get his education. Even if he got married during his young years, as you might have done.
Another point -- whether or not he had to fight in a war to defend your freedom is beyond his control. What he did is volunteer to be trained and serve, and even fight and die for your and my freedom. If a genuine threat to our nation emerged, or even outright war, he would be the first one fighting. He did a lot more than just have a job. He put his life at some jeopardy in the event that he is ordered to go to war -- whether justified or not.
If he wants to get married at a young age, just as you might, why should he be denied that? Why should it work against him once he gets out of the military and now wants the opportunity to get an education -- which was a benefit promised when he signed up. He chose to delay his education in order to serve his country.
In the year 9995, I will begin seriously brushing up on my COBOL.
In the year 9997 everyone is going to start getting worried about the Y10K issue being the end of civilization as we switch over to five digit years. There will suddenly be a lot of short term COBOL work available.
It's not a real egg. It's just industrial goo. But don't tell Dr. Franklin.
It sounds nice. But in the year 9995, the COBOL compiler is going to only accept punched cards. The cards must be punched on a keypunch machine that has the Windows 8 Metro user interface with no keyboard. Touch screen only.
In another topic on Slashdot this morning I wrote:
As part of my retirement plan, I will seriously brush up on COBOL in the year 9995. In about the year 9997 everyone will start getting worried about the Y10K problem. People will think Y10K will be the end of civilization as we switch over to five digit years. There will be lots of COBOL work available.
When your only hammer is C all problems begin to look like a thumb.
(or a device driver)
It is as if millions of COBOL programmers suddenly cried out in terror, and were suddenly silenced.
No. Modern languages are not for them. They just use those languages.
Someone that knows what they are doing can use new high level languages as a powerful lever when appropriate.
With a modern language, you DO need to think AND plan, if you are building any non-trivial program and it needs to be maintainable.
For trivial programs there are many posers who can quickly turn out unmaintainable crap code heavily copy/pasted from Google and Stackoverflow without thinking or planning.
The posers can't build the large non-trivial program, even in a modern language. Thinking and planning is still necessary. Experience also counts. (Experience measured in code and learning from past programs.)
I promise you that the posers can turn out garbage in any programming language. Even YOUR favorite language.
If there were one perfect programming language, everyone would be using it already. That's why programming language fanboy wars are fun to watch.
A hammer is better.
No! A wrench is better!
You're both wrong, a screwdriver is the best!