On Wed, Mar 04, 2015 at 01:39:55AM -0600, T.J. Duchene wrote: > > On 03/03/2015 09:07 PM, Hendrik Boom wrote: > >As time passed, they kept finding new uses for their scripting > >language. Occasionally they would realize and existing module > >needed major new functinoality, and it was easier to write the new > >version in Scheme than to modify the old. Over two years or so, > >they ended up replacing their C code, piece by piece, with Scheme > >code. In the end they had a system that was mostly written in > >Scheme, was more reliable, did more, ran faster, and was only > >about 30000 lines of Scheme. > > When I say this, please do not think that I am making remarks > against your experience or observations, but I just "don't get it". > > I don't see how that can be the case. The version of Scheme that > you mention is specifically implemented on top of C, so your remarks > cannot be entirely true, nor make any sense to me at all. Scheme > can't be more reliable, do more, or run faster, especially if it > implemented on top of C or even converted into system object code by > the very same C compiler.
No doubt the programmers could in principle have written the same code that Gambit generated. I say "in principle" because the generated C code is bulky, uncommented, and well-nigh incomprehensible. They could have even written equivalent code in well ant truly commented readable C code. But to someone new coming to the project, any 200,000 lines of code are incomprehensible, regardless of quality. What made the difference is that 30,000 lines of code are more comprehensible than 200,000, just by sheer volume. It was easier to understand what the code was doing. So they could see what was really going on and replace algorithms easily. The increase in comprehensibility might have been due simply to the reduced volume of code. But the powerful metaprogramming features of Gambit may also have helped. They could adapt the language to their applications semantics, making it all more comprehensible. And it may also have reduced the total amount of code they needed to write. > > The entire statement is "non sequitur." > > I will that any specific compiler, even a C compiler, can be total > and utter crap, if it is badly implemented. I will also agree that > individuals' programming skills can be massively lacking. It is > possible that they were more skilled with Scheme than C, but that > does not make Scheme superior to C by any objective standard. > > >It was really a win for the high-level, garbage-collected language. > > > > I've used enough GC languages to know the problems that they try to > solve. It's a good idea to try, really, and it is a fantastic > debugging tool when testing code. It's a fantastic debugging tool only in a run-time secure language. Then you can rely on things like pointers pointing to the kind of thing they should when interpreting debugging output and making deductions about what yout code did. If your language isn't run-time secure, combining garbage collection and undebugged code is a disaster. The Boehm garbage collector may well *not* be your friend when writing C or C++. > > But that is all it is good for. There are problems in which the data structures are so inherently tangled that garbage collection is the *only* practical way to manage memory. I agree that most programs are not of this type. One use of a garbage collector is in fsck. It garbage collects file systems. This was especially useful in the days when you could hard-link directories. > No one has ever created a fail-proof GC design. When the GC model > fails, it makes fixing your code difficult, sometimes even > impossible to correct without a patch for the entire runtime, not to > mention you may need to recompile everything regardless after you > get it. The same is true for a compiler that generates subtly bad code. I don't know of any bug-free compilers. Do you? Well, actually, I was once told that the Algol 60 compiler written by Kruseman Aretz was bug-free. But I have no direct experience with it. I'm told that his friends, as an April Fool's joke, once carefully faked up a program listing and its (wrong) output and claimed they had detected a bug after the compiler had been running correctly for years. He caught on when he realised that the page numbers on the program listing were not *quite* printed as his compiler would have written them. > > When someone can design a GC language that solves leaks and buffer > overflows 100% of the time, I'll give them all the praise they > deserve. Buffer overflows can be stopped by a language. Until, of course, you step outside the language because you need to use code that does things not allowed in the language. Leaks are more difficult. GC can prevent dangling pointers, but determining for sure whether any piece of storage will ever be used again is Turing-undecidable. Systems languages that are type- and storage- secure handle this pragmatically. They have an "UNSAFE" language variant that does allow the unsafe operations. But you have to request that specifically. You don't get to violate safety restriction accidentally. And, of course, the language takes no responsibility for the safety of that code. This is where it *does* assume you know what you're doing. This is where you can explicitly do your own storage allocation and freeing. Indeed, the Modula 3 garbage collectors are written in the UNSAFE dialect. Yes, Modula 3 has several GCs, depending on your needs. And it has both garbage-collected and (UNSAFE) not-garbage-collected storage, depending on data type. I once thought it would be fun to write a Pascal compiler that actually checks all the restrictions in the manual, and, for safety, uses a garbage collector. New and dispose would still be what the programmer uses, but the GC would be used as a check. Storage disposed would be marked as gone, but would be kept as long as things still pointed to it -- so we get a comprehensible error message if it's ever actually used. And storage garbage-collected but never explicitly 'dispose' would be an opportunity for a memory leak warning -- a sort of software-implemented valgrind. This is GC for debugging. > Until then, the only things that GC does for you is waste memory, > processor time, and force you to reboot the entire system more > frequently in order to clear the exhausted resources. Garbage collectors tend to be the most intensely debugged components of a programming language implementation. And the most difficult to debug. But if there's a bug there, lots of code fails. And that's very noticeable. So if you have implementers with high standards (and those are the *only* ones that should be implementing programming languages that people rely on) garbage collector bugs are not usually a problem. If there are a lot of bugs logged against a language implementation, I'd avoid it, whether it has a garbage collector or not. (Except wishlist bugs, of course. Excessive response to wishlist bugs often indicates code churn, and possibly lanuage-design churn.) > > Have a great evening! > t.j. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
