clipka wrote:
> Darren New schrieb:
> 
>> Or take something like a big windowing system, or a 3D graphics 
>> system, or a physics library, and try to document *just* the routines 
>> without documenting the architecture of the system.  You'll spend 
>> three days trying to find out where to start reading the documentation.
> 
> You mean, like the Windows API documentation? :-P

Exactly. That's why there are classes and books on programming with the 
Windows API. You can read IDispatch all you want, and if you don't know what 
COM *is*, it's going to be meaningless.

Thing is, see, people who are writing the code know this before they write 
the code. Nobody sits down, typing C code, and then says "Wow, look, it 
turns out it's a web server!"

Now, what can you do with a programming language to make it easier to save 
that sort of thing with the code than to throw it away when you're done?

Here's another example: There's a thing in Blender (I forget what, actually, 
maybe the fluid simulation) where third parties were trying to document how 
it worked. The author added it, submitted the code patch, but didn't say 
what any of the parameters meant or how to use it. People trying to write 
the documentation were saying "whoever wrote this, can you send me the files 
you used to test it? You must have tested it,b ecause it works, and it'll 
help me write documentation if I can see what you tested it with."  Such a 
thing wouldn't happen if there was a language with TDD built in, for 
example. Something where a procedure declaration included test-case 
declarations inside it, or where the only way to write a procedure is to 
include it inside a test case, for example.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Vincent Le Chevalier wrote:
> that people don't want to write the documentation at first. 

Generally speaking, people who hack code don't write the documentation 
before the code. And once the code is written, there's no benefit to the 
author to write the documentation.

The real problem is that most hackware is written by people who don't know 
what they want. They don't figure out what they want to code to do before 
they write the code.

Me, I write the documentation *first*. That way, I know when I'm done. If 
it's small enough that I don't do that, it's small enough that you don't 
need documentation.   But even that little 50-line DF3 converter program I 
posted here, I wrote the help message first.  I can't imagine how I could be 
productive writing code if I don't know what I want it to do when I'm done.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

clipka wrote:
> "Although titled "SQL slammer worm", the program did not use the SQL 
> language; it exploited a buffer overflow bug"

Sorry.  I meant the shatter attack. It's where you fake using the keyboard 
to write executable code into (say) a text entry box, then you send a 
message to the program that makes it invoke a callback in such a way as it 
jumps to the text in the text entry box.

(Sorry. Long week. I'm awake now. :)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

clipka wrote:
> Okay, let me rephrase that: Try that in a non-OO /mainstream/ 
> (imperative) language.

Erlang? Tcl? LISP?

It's a trick of modularity, not a trick of OO. There are many ways to get 
modularity without using objects.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

clipka wrote:
> Dream on :-)

Well, sure, that's the whole thread, isn't it? :-)

> Automatic code generation from tools has been the subject of wishful 
> thinking for decades. Yes, CASE tools do exist. But where are they used, 
> and how powerful are they really?

I think part of the problem is that you can't go back. You generate the code 
from the CASE tool, and then when you modify the code, you can't generate 
the CASE tool files from it.

> I've seen such a tool only once in real life: It was used to document 
> state machines and generate code for them. But even there, too often 
> people would just try to make it generate the state machine they wanted, 
> instead of actually documenting it. And more often than not, the actual 
> "meat" code would contain additional hidden state variables.

Sure. The trick is to make it *easier* to write the documentation first.

Like, take the whole TDD thing going on. What if your top-level module was a 
"unit", and inside that unit you had your implementation and your test 
cases. Then you couldn't write code without a test case. A bit B&D, but 
could you make it easier to write test cases than not?

>> The problem with writing code documentation is that it doesn't help 
>> the coder. It only helps the people who come after. So it's seen as a 
>> waste unless the coder understands the business reason for it.
> 
> Exactly. But this will not happen unless management understands the 
> business reason for it in the first place, and makes sure the coder has 
> enough time to carefully plan, document and test his work.

Yes. And heaven help you if you're writing open source code, where there's 
no business need to make it usable to anyone else. :-)

> That C part of ACID would be covered by the contract-oriented paradigm I 
> think.

Well... to some extent, yes. Contract-oriented tells you the relationships 
with individual objects. The C of ACID tells you the relationships between 
objects. But they're similar concepts, yes.

The contract-oriented paradigm won't tell me if I change the Customer class 
and it breaks the Order class.

>> I can't imagine changing a queue to a stack without needing to rewrite 
>> a fair amount of the code using that structure.
> 
> That direction may indeed be problematic, but changing from a stack to a 
> double-ended queue shouldn't be a problem, as a stack is just a special 
> case of a deque that provides no access to the "head" of the queue.

True, but then why would you do that if you aren't going to be dequeueing 
stuff at the other end? :-)

> That it's not so easy with the STL is a problem of C++, not OO languages 
> in general. And even with the STL it would be a piece of cake if you had 
> chosen to use a typedef (which you could interpret as a kind of 
> "identity inheritance") in the first place instead of hard-coding the 
> type name everywhere.

Right. I mean, that's a trivial kind of thing. You have the same problem 
with names in Java as you do in C++.  If you code your functions to all take 
arguments of type stack, changing to a dequeue is going to require tracking 
all those down, just like if you did it with STL.

The point I was making is that there are lots of paradigms

>> C++ seems to do pretty well, and its not using any OO for the STL.  
> 
> Oh, sure it does! For instance, the class behind the vector::iterator 
> type derives from the class behind vector::const_iterator, which in turn 
> derives from some obscure class _Ranit - to name just the very first 
> example I chanced upon.

It doesn't *have* to, tho. There's nothing in the paradigm that makes that 
so, unlike in OO coding. The iterators may inherit, but the other things 
don't need to. There's no dynamic dispatch involved, so it's not OO.

> And the /design/ of the STL is heavily object-oriented at any rate. For 
> instance, the documentation refers to both "deque<T,Alloc>" and 
> "vector<T,Alloc>" as /models/ (think "implementation") of the /concepts/ 
> (think "abstract classes" or "interfaces") "Random access container" and 
> "Back insertion sequence" (with "deque" also being a model of "Front 
> insertion sequence").

Yes. But they're not inherited from each other, and they're not necessarily 
dynamically dispatched. All you're saying is that you can do things similar 
to OO with templates.  I.e., yes, the *design* is OO, but the implementation 
need not be, so you're making my point for me that you can have generic 
containers without OO.

> Note that data encapsulation /is/ an OO trait. 

It's a trait of a lot of languages. It's not the definitive trait of OO.

> And are you really sure 
> they don't use any OO portions behind the scenes?

They might, but that's not the point.

> You were obviously 
> mistaken regarding STL.

STL is a specification, not an implementation. Everyone is free to implement 
it differently.

Does the STL's dequeue inherit from the STL's stack, or vice versa?

> A library using an OO design does not necessarily imply that you can 
> subclass it, or any of its components.

Right. But then it's just a library. Subclassing and inheritance is one of 
the primary defining features of (class-based) OO. Otherwise, it's just a 
nice way of passing a pointer around, and you might as well do it the same 
way stdio.h does.  (stdio is a library with an OO design, yes?)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Chambers wrote:
> I'm constantly wondering why we don't have this yet.

Well, there's something called BON that comes close. It just doesn't write 
the code for you, only the contracts.

It's related to Eiffel, if you care to look it up, but it's basically a 
box-and-arrow thing that will declare your classes and methods, and if you 
change the classes and methods, it can draw the pictures again.
-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New wrote:
> Sorry.  I meant the shatter attack. It's where you fake using the 
> keyboard to write executable code into (say) a text entry box, then you 
> send a message to the program that makes it invoke a callback in such a 
> way as it jumps to the text in the text entry box.

Incidentally, this is exactly the reason the UAC does that funky thing with 
the screen. It's also the reason you get warnings every single time you 
start up a privileged program that opens a window, even if it's just an icon 
in the system tray.

You're *supposed* to write a service that runs with the appropriate 
privilege, then write an unprivileged UI that talks to the service, and the 
service makes sure that what the UI tells it to do is safe. If you just let 
the user talk straight to the privileged code thru the UI, you can have 
trouble.

Kind of a dumb design decision, probably left over from Win16 days. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New wrote:
> Erlang? Tcl? LISP?

Actually, Ada can do this too, I'm pretty sure, even without using its OO 
features.

Plus, heck, in Erlang you can make that change without stopping the program 
and without losing any data.

If you look at the source for Wings3D, you can see where there are pieces of 
code that basically say "hey, there's a new version of the code, load it and 
run it *without* closing my window, saving the shape i'm working on, etc." 
I.e., the developer could find a bug while working, fix the bug, and keep 
working except with the new code running.

OO isn't going to give you *that*.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New wrote:
> clipka wrote:
>> Darren New schrieb:
>>
>>> Or take something like a big windowing system, or a 3D graphics 
>>> system, or a physics library, and try to document *just* the routines 
>>> without documenting the architecture of the system.  You'll spend 
>>> three days trying to find out where to start reading the documentation.
>>
>> You mean, like the Windows API documentation? :-P
> 
> Exactly. That's why there are classes and books on programming with the 
> Windows API. You can read IDispatch all you want, and if you don't know 
> what COM *is*, it's going to be meaningless.
> 

Snort. Worse than that. You can read every book ever written on COM and 
IDispatch and still not be able to answer this question: "How do you 
take advantage of the 'design mode' flag used to change the behavior of 
controls in a control container, of which all correctly designed 
containers possess, without being forced to use those containers in the 
MS compiler suite, which seems to be the only application that actually 
**uses** this badly documented feature?" Basically, you want to know how 
to make you control react to it, great! You want to create a control 
container, like a window, then "tell" that window to turn on 'design 
mode', so you can use the existing grab handles and functions to move 
around the control (never mind disable it, so it won't do nothing while 
moving it around), well.. tough luck, because its **not** in any of 
their damn documentation, anyplace, as far as I could ever find.

-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott wrote:
> moving it around), well.. tough luck, because its **not** in any of 
> their damn documentation, anyplace, as far as I could ever find.

Huh. I didn't think that's how design mode works.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message