Re: paul grahams arc, a new lisp, and his words about makign code ?shorter, vs forth?

Andreas Klimas wrote:
Ask these kids if they found garbage collection complicated. The answer? No. They weren't even aware of it was going on. Ask these kids if they found object orientation difficult to grasp? The answer? No. They found these were very natural abstractions and metaphors that mapped nicely into their real-world experience.

you are joking, don't you ?
advantage of GC: you can switch off your brain in first place.

When I'm using a language with garbage collection, I am not "switching off my brain." In fact, I find the ability to focus on the problem and not the solution often opens up to me new perspectives and opportunities. I can try approaches that I wouldn't try in a language like Forth (or C) because dealing with the low-level storage issues ends up dominating my development time.

drawback: sooner or later you will see memory usage growing
because of caching objects which in turn will keep the whole
object database in memory. so you introduce weak references
here and here. but there might still hidden cached objects
which are very hard to find.
conclusion: you have to think anyway, why not avoiding GC in
first place ?

Because if you know the strengths and limitations of the tool, you can effectively work with it. People who run into the problems of hidden caches are people who aren't using the tool properly. Doctor, it hurts when I do this. As always, the problem isn't with the tool, it's with the use (or misuse) of the tool.

Complexity is one of those terms tossed around in comp.lang.forth that often has very little if any meaning. Complex relative to what? Complex relative to who? It's a lot like the word "efficient" that is equally abused here.

it's not my Job to unswer such esotherik questions. if you
don't see 'complexity' or 'inefficient' I can't help you.

It isn't an esoteric question: Words like "complexity" and "efficiency" only have meaning in a context. Saying (for example) that garbage collection is complex may be true in some contexts, but false in others. And if you can't see that, then you either don't have as much experience as you claim, or the scope of your experience is pretty limited.

I believe there is in some sense a "conservation of complexity." That is, for non-trivial problems, there is a set amount of complexity in the system that you can't remove. It's in the nature of the problem being solved.

What you can do is push that complexity around. So a programmer might write simple "Do What I Mean" code expressed in some high level language that handles all the underlying low-level details. There, the complexity has been pushed to the language. Or, for the same problem, a programmer might choose a simple low-level language (like Forth), but now have to tediously specify each and every step. There, the complexity has been pushed to the programmer.

The mental trap here is assuming that one approach is always right. And I think part of that mental trap comes from programmers who work with blinders on, focusing entirely on narrow aspects of a system and never stepping backward and looking at the system as a whole. We see this in comp.lang.forth all the time-- programmers wringing their hands over how complex a particular solution is, seeking something simpler. But that is usually meaningless. I can't count the number of times I've had a programmer proudly hand me an exquisitely crafted set of routines that presented some utterly simple and consistent view of problem being solved. And then, when I have to actually use that in a system, I find it's too simple-- that it doesn't do what I want or need. The result? You either end up rewriting the "simple" routines or you write some abstraction around it to make it work like you want.

I'll toss out a simple example. A while back in comp.lang.forth, there was a discussion about graphics and how to deal with some of the complexity of some basic routines. Say you wanted to draw a box. In the usual approach most people would take, you would need at least four arguments on the stack-- the X/Y location of a corner and either the X/Y location of the opposite corner, or a length/width pair.

Someone came up with an object-oriented approach of using turtle graphics. Have an object (the turtle) that maintains state about where it is on the screen, and give it commands to move relative to where it is. So drawing a rectangle breaks down into four "move a distance and turn 90 degrees." Simple and elegant.

So someone takes the simplicity and elegance of this design, and now they want to draw a line graph with quantities expressed in X,Y pairs. And suddenly what would have been a simple line drawing routine now becomes a problem where you have to calculate the rotation angle and distance to move the turtle. Not difficult, but additional complexity driven by having something underlying that is too simple (or at least, not matched well to the problem being solved).

This is what drives me nuts about many of the messages in comp.lang.forth. These discussions of complexity and efficiency are far more often than not discussed in a vacuum, as if they were absolutes that don't rely on context. But they of course do.

.

Relevant Pages

  • Re: C or C++
    ... that the beginner programmer is an adult --- they're like innocent ... it is indeed a simpler language (from a certain ... even though it is an extremely complex language, the complexity ...
    (comp.os.linux.development.apps)
  • Re: (and about tests) Re: Pedantic pickling error after reload?
    ... If there are things with nested classes etc, the programmer will have to ... Yes, I could have written that code on the fly, hitting F5 every few seconds/minutes to see if things work out - and once I'd be finished, I didn't have anything permanent that ensured the functionality over time. ... But we also use selenium to test JS-driven interfaces, as now the complexity of the interface rises, with all the bells & whistles of ajaxiness and whatnot. ...
    (comp.lang.python)
  • Re: Java is becoming the new Cobol
    ... Believe me, I don't have a problem with complexity, when it's warranted. ... Several years later, a programmer ... graphics data compression algorithms, including an assembly language ... Since the data backs up my impressions, ...
    (comp.lang.cobol)
  • Re: Design Patterns and Functional programming
    ... Impurity is not required, as purely functional languages do exist, but it ... not the asymptotic complexity. ... this form of static checking requires the pattern matcher to be ... Then compiler leaves it up to the programmer. ...
    (comp.object)
  • Re: Java is becoming the new Cobol
    ... Believe me, I don't have a problem with complexity, when it's warranted. ... Several years later, a programmer ... graphics data compression algorithms, including an assembly language ... Since the data backs up my impressions, ...
    (comp.lang.cobol)