On 6 Jul 2010, at 16:52, John Engelhart wrote: On Mon, Jul 5, 2010 at 9:08 AM, Ian Joyner <email@hidden> wrote:
On 5 Jul 2010, at 20:51, Hamish Allan wrote:
> Every high-level language you use, at the end of the day,
> runs on a machine that needs to differentiate between values and
> pointers. If "a->b" didn't exist, you'd have to write "(*a).b", and
> you'd still have to make changes across your entire codebase if you
> decided to change the level of indirection of a variable. How would
> you design a language to expose these levels of indirection which did
> not require such changes?
That's really easy.
obj A { b }
A a; // This a just goes on stack
To access b:
a.b
A *a; // This goes on heap
To access b:
a.b
Just the same. The compiler is smart enough to know one is on the stack and one is in the heap.
Ian, let's be honest here. You took what are arguably the two most trivial cases, wrote some text that uses the same '.' operator in both cases, and then said "Just the same. The compiler is smart enough...". Your assertion that "the compiler is smart enough" does not make it so.
Sorry, you are right. I should not use anthropomorphic language about programs. Rather the compiler can be constructed to do this.
You wrote three or four lines, and I think it's fair to say that most people would have figured that you would have "a.b" and "a.b" for both examples. Then, without any explanation of HOW you could accomplish this, you declared the problem "solved". It's as if you honestly believe that because you typed it that way, and that's the way you'd like it, it somehow makes it possible.
It's because it is possible and commonly done.
So, riddle me this:
1) A **a; a.b; 2) A ***a; a.b; 3) A **a[][]; a.b;
Does #1 work? Why not? Or better yet, why does it work? Just how many levels of this automagic indirection does your new '.' operator do?
What new '.' operator? This kind of thing is common in other languages. One? Or as many as required? Or do you have to write #1 as *a.b;, or possibly even (*a).b?
What happens if b happens to be a pointer? Do you have to write it as *(a.b)? Or (*a).b?
The same issues apply to 2 and 3. Does your automagic indirection '.' operator automatically dereference through arrays, too? How many levels?
And lets face it, at some point I'm probably going to have a situation where I really want to prevent this automagic indirection from taking place. How does "&" integrate in to all of this? Does "&" prevent indirection? And once you fix that quirk, aren't you pretty much back to weird stuff where "(&a).b" is going to be required... almost as if you've just sort of pushed the problem around, and not really fixed anything?
I don't even know where to start with your complex thinking... so I'm not going to bother.
Programmer changes mind compiler generates correct access code. There really is no need for two access operators that do the same thing, just as there is no need to have Objective-C objects declared with a * because everything goes on the heap anyway. If you could clean up these languages you'd get less irritating syntax errors, less programming exceptions and more reliable software, less need for common refactorings. All of these ills with the range of techniques with which you can undermine C to create viruses and worms means C is a weak base for any language. And yes it confuses new comers because it is confusing. C reminds me of the slides in WWDC 2010 session 103 showing the two urinals together so only one is usable, staircases on the outside of a building, and the non-balcony.
Yep, it's all C's fault, that's for sure, and why it's only in use at a few sites around the world... mostly due to legacy reasons, sort of like COBAL.
COBAL... what's that? That's why the obviously superior programming languages like ALGO 6X and Pascal are so popular today. Programmers simply can't get enough of those languages "The language designer knows best" philosophy,
I'll stop you there in that thought. Because it's wrong. Your whole philosophy and the philosophy of a whole generation of programmers are unfortunately based on this incorrect notion of "evil language designers" trying to stop programmers from what they want to do. Result - hackers liberally create viruses and worms, etc. and they are so much more productive when they constantly have to battle the compiler to accomplish simple things because some pointy hat in an ivory tower decided that the programmer does not, in fact, know best.
More widespread misconceptions. It is unfortunate that the C world actually got away with perpetrating this extremely immature thinking. If by ivory tower, you mean that programming is an activity of the intellect - then yes it is. Fortunately, the computer industry is starting to grow up. The compiler and language should help the programmer accomplish their goal, but only as long as it's safe to do so to the point of sterility... and then go out of its way to put up roadblocks and obstacles whenever you try to do something "wrong", regardless of how important it is that you need to break the rules in this particular case.
You don't seem to appreciate the fact that yes, there have been languages in the past with less warts than C, "safer", etc, whatever.... yet programmers actively choose not to take them up, or even outright abandoned them in favor of other languages. Invariably, programmers turned to C. I can't speak for others, but for me at least, one of the primary reasons why I choose C, and continue to choose C is precisely because it does none of these things that you are advocating or claiming that it would "make for a better language."
A lot of people have no choice. Fortunately, we can choose Apple over Microsoft -or perhaps not, because there don't seem to be many jobs around in the Apple world, so most people are forced to become MS programmers, just as many people are forced to use C.
You can choose C if you like. But most of us are stuck with it. We know it has flaws. Why are we attacked by this C cabal (no that's not a language) whenever those flaws are pointed out? What are you trying to hide? Popularity does not make something right. It's like the old adage, "the more value you add, the less valuable it becomes." For me, the fact that it "does so little" is precisely why it so useful.
What is doing little? C compilers do relatively little, this is why the programmer must do a lot, lot manual dereferencing and try to balance all of this complexity while actually trying to write correct software. It just takes the programmer's attention away from what is important. C is in reality a very large and complex language trying to keep things simple for the compiler but making things harder for the programmer. C is a verbose language, that's why you have all these operators like '.' vs '->' which essentially do the same thing, but in a different way. C is almost a kitchen sink of languages, but not quite... C++ is that.
It all boils down to complexity. Complexity is an interesting topic. It is there in whatever you are building. But it is a matter of where it is. C expects the programmer to manage the complexity, like juggling many balls at once. I'm glad you feel you are clever enough to do it and produce correct software (or that you have enough time to do so). I'd rather simplify the life of the programmer, make software production a quick and 'agile' process and have the complexity in the compiler.
This is why high-level languages came to be in the first place, and why they have been the only order of magnitude improvement in producing software systems (see Fred P Brooks No Silver Bullet). Otherwise there is no silver bullet. But it is unfortunate that we are now stuck with this language that is more like assembler than a true HLL. In that we are stuck with piles of complex and brittle legacy code makes C very much like COBOL. C is now an old and tired language and the limitations that were around in the creation of C are now long gone - that is the truth. I agree with you... let's be honest here. |
