Warp wrote:
>   I understand that "bashing" can also be used to describe overly negative
> critique of something in a way that, while not telling any lies per se,
> makes it sound a lot worse than it really is. 

Fair enough. I thought we'd already talked to death the advantages of unsafe 
languages (primarily performance and control).

> Especially if the impact of
> many of these negative things is exaggerated, 

I think you underestimate how much of a problem some problems are for 
average programmers because you've become expert.  I still occasionally get 
questions from people who have been programming for decades who ask
   "How do I debug something when it stops crashing after I add a printf()?"

You yourself have posted C++ code with a quiz-like "what's wrong with this 
class".  Clearly it takes a fair amount of expertise to write correct C++ 
code, doesn't it?

I can write C code that doesn't have bugs due to the unsafeness, but it 
takes me much longer because I have to think a lot harder about the 
boundaries. It's also something that took years of experience to learn.

I also figured it wouldn't be taken to be "bashing C++" if I pointed out the 
equivalent flaws in the whole list of other languages we were talking about, 
which is what led me to believe you might be a bit oversensitive or 
oversensitized.

>   For example, in my "I hate Java" page I'm outright bashing Java because
> I'm pointing everything that I consider negative about it, without pointing
> out anything positive to compensate (although Java does have its positive
> things as well). Someone who didn't know anything about Java could get a
> rather biased impression of the language by reading that page alone. (Guess
> twice if I care. ;) )

There's nothing wrong IMO with a good bash so labeled. I don't think 
anyone's going to read a page labeled "I hate Java" and expect a balanced 
presentation, any more than they're going to go to apple.com to see the pros 
vs cons of apples vs windows, say. I even think something like the C++ FQA 
is a valuable service, bashing as it is. I wish there were pages like that 
for every language and tool.

I don't think it's a bash of any one language to say "no language strictly 
enforces modularity, they're all broken in various ways, and here they are: 
...."  I'm hoping it's not considered bashing Y to say "I like X better than 
Y because ..."  It's not like I started talking about the flaws I think are 
in the design of C++ that haven't anything to do with violating modularity, 
or that I argued you can't violate modularity in the other languages.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Warp wrote:
>   With this I mean that with the memcpy() you are not accessing the private
> members any more than you are with "a = b;".

I would disagree for the following reason:

Altho {a = b;} *might* do the same thing as memcpy(), the author of the 
class has the ability to make it do something different, or to declare 
operator= to be private, preventing it altogether.

memcpy() can not be "defended against" in that sense.

"Can I change the values of private variables without invoking a class 
method or friend function?"  "Yes."  I'd say that's breaking modularity.

I think at this point we each understand what the other is saying, and now 
we're just having an argument about whether to call it "really" unmodular or 
only "kinda" unmodular. :-)

> They are both copying the
> state of the entire object to another instance. You could say that with
> memcpy() you still don't know *what* you are copying (what type of members,
> how they are padded inside the class, etc), only that you are copying
> everything verbatim.

Note, too, that even in this case, if you change your pixel example to be 
HSV instead of RGB, the memcpy() approach still works for moving pixels 
around. :-)

>   The difference, and what makes the memcpy() version non-modular, is that
> the memcpy() version bypasses the normal class assignment semantics and
> instead goes to the "raw hardware level". If the class would need a more
> complex copying semantics than a bit-by-bit copy, then the copy is broken.

Sure. I'm just arguing that the ability to use memcpy() *is* non-modular. 
The fact that it breaks or is non-portable in some cases would not seem to 
counter that fact. It would just seem to say "it's a bad way of doing 
things." :-) Which we both agree with.

>   I understand your argument to be that memcpy() could be used in this
> way to *access* the private members of the object. However, it can't,
> not in a portable way anyways, because you still can't know the internal
> structure the compiler has generated for the class, and you can't point
> to individual private elements.

Agreed. Not that it's difficult to figure out. I can think of at least 3 
easy ways to figure out where individual variables are: 1) use a debugger, 
2) look at the generated asm code, 3) stick a friend function into the 
header that returns the offset of the private instance. None of those are 
particularly portable, except the last, assuming that adding a friend 
function declaration doesn't rearrange the actual structure members.

I agree it's a concern in CLOS that someone will read your source code and 
access the internals of your class by learning the names of private 
variables and then you'll have to support it. I also contend it's about the 
same level of concern that someone will look at your header file, see it's 
POD, and write code that uses memcpy() to move POD-structs around (perhaps 
to different address spaces or into files or something), and you'll wind up 
having to support that.  Neither is really common enough to worry about, and 
both are trivial to avoid if you can change the module you're talking about 
or avoid the need to do that altogether in the caller.

>   Perhaps this could be compared to calling the CopyFile() function of
> the Windows API: Even though it copies the entire contents of a file to
> another file, I'm still not *accessing* the contents of the file with
> that function in my program. I'm just telling the system to copy it.

Sure. And my comparison would be that "Anything you can call CopyFile() on, 
you can open and read and write, possibly messing up the program that uses 
the file, or possibly for the purpose of bypassing DRM."

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Warp wrote:
>   I understand that "bashing" can also be used to describe overly negative
> critique of something 

Or, to just phrase it a different way, I've been actively and consciously 
attempting not to say bad things about C++ and to ensure whenever I point 
out a limitation I also point out the equivalent limitation in other 
languages. Yet you continue to fall back on "you're bashing C++ to annoy 
me", which is kind of discouraging.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Darren New wrote:
> I agree it's a concern in CLOS that someone will read your source code 

Or, to phrase it a bit differently, I'll agree that using memset() or 
memcpy() to get to the entire instance opaquely *feels* qualitatively 
different than the sorts of access CLOS or Python allows.

On the other hand, it seems kind of similar to the sorts of things 
reflection allows.

Even in Python, I think there's two kinds of accesses:
    x = myinstance._myprivatevar
vs
    "iterate over all public and private variables of this instance
     and do XYZ with them."
They feel qualitatively different, with the latter feeling more like
reflection and the former feeling more like bad news, even though they
both stem from precisely the same language rules.



As an example you might be able to relate to, to see what I'm talking about, 
consider http://www.boost.org/doc/libs/1_38_0/libs/serialization/doc/index.html

Look at the "class gps_position" example. It has a pair of routines named 
"serialize" each of which lists the exact same variables in the routine as 
are in the class. With a reflection library, adding this sort of 
serialization would be done by having a mix-in multi-inheritance routine, 
and you wouldn't need to code that sort of body at all. Of course, there 
would likely be routines like "serialize everything" and "serialize all 
public members", as well as routines like "serialize everything but X and Y, 
and when you load back in from the archive, invoke fix_up() on the loaded 
instance to fix X and Y." So lots of uses of this sort of thing are done 
from within the class, just taking advantage of the fact that you *already* 
listed the names and types of the instance variables, so why do it again?

Yeah, you can use it to get to the insides of classes from outsides, but you 
kind of want that for your IDE and your debugger. :-) It's a lot of power, 
and IME not a whole lot of misuse.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Or, to just phrase it a different way, I've been actively and consciously 
> attempting not to say bad things about C++ and to ensure whenever I point 
> out a limitation I also point out the equivalent limitation in other 
> languages. Yet you continue to fall back on "you're bashing C++ to annoy 
> me", which is kind of discouraging.

  I'll try to be less paranoid next time.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I'll try to be less paranoid next time.

Thank you. I appreciate it.  In return, feel free to say something early on 
if it sounds like I'm not making the effort. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   I'll try to be less paranoid next time.
>
> Thank you. I appreciate it.  In return, feel free to say something early on
> if it sounds like I'm not making the effort. :-)

whoa!  A lot of kicks, punches and bruises later and you almost feel in love...
:P

Post a reply to this message

nemesis wrote:
> whoa!  A lot of kicks, punches and bruises later and you almost feel in love...

I'm not offended by anything Warp has said. He's a smart and insightful guy 
with lots of knowledge. I learn enough from him I want to stay on his good 
side. Occasionally his conversations style is annoying, but I'm pretty sure 
mine is moreso. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Darren New wrote:

> http://vijaymathew.wordpress.com/2009/03/13/dangerous-designs/

Why write

   (define (addn n) (lambda (k) (+ n k)))

when you can just say

   addn n = (+n)

? ;-)

Seriously though, adding completely new features to a system not 
designed to support them is not an easy thing to do. This is not news. I 
do, however, agree that a simple design that is widely powerful is 
better than a huge raft of special-purpose rules for specific situations.

(This is one of the reasons why Haskell's ever-expanding set of features 
worries me. If people need all these extra features, doesn't that kind 
of indicate that the language is broken?)

Post a reply to this message

Warp wrote:

> "The argument is that, using a very small number of rules for forming
> expressions and with a minimal syntax it is possible to support all
> possible programming paradigms. For instance, if the language has
> support for higher-order functions, closures and dynamic typing, we
> can implement object oriented programming without special language
> level syntactic support. Tail-call optimization elude the need for
> special looping constructs."
> 
> sounds like you could argue in favor of languages like brainfuck which
> have a minimal set of instructions, yet are still Turing-complete.
> 
>   Eg. just because tail recursion is enough to perform any kind of
> looping construct doesn't necessarily mean that special looping constructs
> wouldn't be a useful tool.

If a language is "powerful enough", you can create the abstractions you 
need from within the language and use that. If the language is not 
powerful enough, the things you need must be hard-coded into the 
language, which is less flexible.

On the other hand, a compiler can take advantage of the specific 
features of a specific language, but can't easily take advantage of the 
properties of some custom abstraction that you designed yourself. 
(Although some languages allow the programmer to specify compile-time 
transformations that go some of the way.)

Post a reply to this message