Darren New wrote:

> It's fine for the details. But try to document (say) the BSD interface 
> to TCP by documenting only the listen(), accept(), bind(), and connect() 
> calls. Without understanding what an IP address is, or a socket, or how 
> DNS works, etc you're still not going to win.
> 
> 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.

Ah yes... This is how I tried to learn OpenGL. (By reading function 
descriptions, that is.) It's not very easy...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> As far as I can tell, 98% of all security issues are buffer overruns - 
>> trivially fixable, yet nobody seems to think it's necessary.
> 
> The three biggest are buffer overruns, SQL injection, and XSS injection.

Not for desktop applications, I'd suspect. (Injection attacks are 
typically more applicable to websites.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> Not for desktop applications, I'd suspect. (Injection attacks are 
> typically more applicable to websites.)

Yes. This was from SANS, so they cover pretty much everything, from 
operating systems to desktop apps to web apps.

Altho have you heard of the Slammer attack? :-) That's basically code injection.

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

Post a reply to this message

Captain Jack wrote:

> I recall three different people (all academics, natch) 
> making predictions of this sort. One said the "universal" language would be 
> based on C, one cited Pascal, and the other one used the phrase "Super 
> LISP", although he didn't really explain what would be super about it.


You know you're talking to an academic when he says that PASCAL will 
become universally popular.  I've never seen it used outside of the 
context of learning to program.

Regards,
John

Post a reply to this message

John VanSickle wrote:
> You know you're talking to an academic when he says that PASCAL will 
> become universally popular.  I've never seen it used outside of the 
> context of learning to program.

It was quite popular for commercial code on microcomputers in the 80's. UCSD 
Pascal as well as a few others were pretty common for programming Z-80 
machines, 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

Darren New wrote:
> What comes after Object Oriented?
> 
> I mean, we started with assembler, then libraries, then HLLs, then 
> portable HLLs, then interpreters, then structured programming, then a 
> whole bunch of stuff that nobody really picked up (workspaces, LISP, 
> self-modifying code, sophisticated macros, functional programming, etc), 
> then Object Oriented, then .... nothing.
> 
> Why has programming language development been functionally stalled for 
> 30 years?
> 

More like we started with binary commands, moved on to assembler 
mnemonics, then Pascal / C type command-oriented, then class based 
object-oriented...

Since we're dealing with progressive levels of encapsulation here, the 
next layer deals with more abstract object types.  I believe Lisp and 
Haskell are examples of this level.  Following that, we would probably 
see something which allows more abstract manipulation of systems.

...Chambers

Post a reply to this message

Darren New wrote:
> Because I program for a living, and 99% of the time it's tedious, error 
> prone, and suckful.  And the hardware hasn't stopped improving. But I'm 
> still using the same programming techniques I used on my 2MHz 
> sparkstation with 4Meg of RAM.


There are serious attempts to improve programmer efficiency, but they 
are often met with derision and scorn.

Case in point: I mentioned to one of my instructors that I switched from 
C++ to C#, and his response was, "So you took a step backward, then?"

You get even stronger reactions from people about Visual Basic.  This, 
despite the fact that VB and C# are both designed to *increase* 
programmer efficiency.

...Chambers

Post a reply to this message

On 3-10-2009 3:08, John VanSickle wrote:
> Captain Jack wrote:
> 
>> I recall three different people (all academics, natch) making 
>> predictions of this sort. One said the "universal" language would be 
>> based on C, one cited Pascal, and the other one used the phrase "Super 
>> LISP", although he didn't really explain what would be super about it.
> 
> 
> You know you're talking to an academic when he says that PASCAL will 
> become universally popular.  I've never seen it used outside of the 
> context of learning to program.

I did

Post a reply to this message

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

Post a reply to this message

On 10/03/09 07:30, andrel wrote:
>> You know you're talking to an academic when he says that PASCAL will
>> become universally popular. I've never seen it used outside of the
>> context of learning to program.
>
> I did

	You talked to an academic?

-- 
How do frogs die? Ker-mit suicide.

Post a reply to this message

>> 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

Hahaha! Yeah, that too...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New wrote:
> where something that looks like UML can be 
> turned into source code and back again with the appropriate tool.

I'm constantly wondering why we don't have this yet.

In fact, why aren't we all programming by drawing flowchart diagrams, 
and defining the behavior of each box on them?

The compiler itself could look at each unit, determine what effects it 
has*, and tell you the end state as a result of running that chunk of 
code, making documentation unnecessary.  In fact, it might make catching 
bugs easier, since it would mention unintentional side effects.

*I realize that this would be impractical for sufficiently large code 
chunks (or for sufficiently large groups of code chunks), but it's easy 
enough to put a soft limit in there that the developer could adjust. 
The developer could set, say, the number of lines they want the 
displayed output to fit into and, for anything more complex than that, 
it simply wouldn't show it.

...Chambers

Post a reply to this message

Darren New wrote:
> 
>> Then again, maybe it's the approach taken from the wrong side, and the 
>> true proper way would be embedding the source code in the 
>> documentation, not vice versa - if only for the psychological effect.
> 
> Yes, exactly something like this.  We probably won't get there as long 
> as the primary form of source code is ascii strings.
> 

Well, litterate programming does already exist... But the adoption rate 
is not so high :-)

Hey, I've used it, even wrote my own tool to do it, but the problem is 
that people don't want to write the documentation at first. If you 
design a language that forces them to do so it'll just not get 
adopted... Imagine if you had to document every tiny piece of code you 
do just to learn how to code?

-- 
Vincent

Post a reply to this message

>> where something that looks like UML can be turned into source code and 
>> back again with the appropriate tool.
> 
> I'm constantly wondering why we don't have this yet.
> 
> In fact, why aren't we all programming by drawing flowchart diagrams, 
> and defining the behavior of each box on them?

Ever used a CASE tool?

Back at uni, we had a thing called Rational Rose that would let you draw 
a bunch of diagrams, and if the diagrams went into sufficient detail 
[you could draw a rough outline if you prefer], the program would spit 
out 25 miles of C++ code.

The problem with this is that it tends to be *insanely* tedious to work 
like this. For example, Native Instruments sell a product called Reaktor 
[note absurd spelling] which allows you to basically write DSP 
algorithms by placing boxes and connecting wires between them. Just for 
giggles, try forming the expression "4x^3 - 3x" (the 3rd Chebyshev 
polynomial of the 1st kind), assuming you have an incoming wire which 
holds "x". That little expression there contains 5 multiplications and a 
subtraction; the wires get messy, fast. And it takes a lot longer to 
draw them all out than it does to write the formula...

I gather there was some sort of graphical Haskell evaluator that worked 
a little like this. You'd draw an expression tree, press a button and 
watch the graph reduction happen. I don't know what happened to it though...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New schrieb:

> Not necessarily. As I said elsewhere, a tool that would make the 
> high-level documentation generate source code (and where the changes to 
> the source code would be reflected in the HDL) would help. It would let 
> people who are designing the system document it as part of the progress 
> forward.

Dream on :-)

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'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.

> 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.


>> Then again, maybe it's the approach taken from the wrong side, and the 
>> true proper way would be embedding the source code in the 
>> documentation, not vice versa - if only for the psychological effect.
> 
> Yes, exactly something like this.  We probably won't get there as long 
> as the primary form of source code is ascii strings.

Probably not, indeed. Embedding code into documentation will only work 
if the file format is inherently suited to documentation needs. 
Unfortunately it's not so easy to find some common ground for this.


>> The only thing you can do about it is /defensive/ programming - but 
>> that's a paradigm you probably cannot support with language features I 
>> guess. Well, maybe stuff designed for contract-oriented programming 
>> would help with this.
> 
> Yeah, that's the sort of thing I'm thinking.  Or like the C part of ACID.

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


>> Try implementing and using generic container classes in a non-OO 
>> language.
> 
> 
>> Then try to refactor your application to use a deque container instead 
>> of a stack for a certain job. Or a tree-backed map instead of a 
>> hash-table-backed one someplace else.
> 
> 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.

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.


> 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 also appears to me that the main reason to avoid any class hierarchy 
for the "primary classes" is in this case the heavy use of templates, 
which may not mix too well with inheritance on various compilers.

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").


> Python and LISP also do pretty well without actually using the OO 
> portions of the language, as would Ada I think. Erlang (and Hermes) both 
> handle this just fine as well, and that's not OO. You just need good 
> encapsulation, not inheritance or dynamic binding or anything like that.

Note that data encapsulation /is/ an OO trait. And are you really sure 
they don't use any OO portions behind the scenes? You were obviously 
mistaken regarding STL.

>> You won't have much success without implementing verbosely what OO 
>> languages do for you behind the scenes.
> 
> Sure. OO is pretty good at data structures and GUIs. But what about 
> other libraries? What about math libraries, HTTP libraries, networking 
> libraries, databases, etc? None of those types of libraries tend to be 
> designed for you to subclass the instances.

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

Post a reply to this message

On 3-10-2009 19:09, Vincent Le Chevalier wrote:
> Darren New wrote:
>>
>>> Then again, maybe it's the approach taken from the wrong side, and 
>>> the true proper way would be embedding the source code in the 
>>> documentation, not vice versa - if only for the psychological effect.
>>
>> Yes, exactly something like this.  We probably won't get there as long 
>> as the primary form of source code is ascii strings.
>>
> 
> Well, litterate programming does already exist... But the adoption rate 
> is not so high :-)

I have also used knuth's web system. It works as long as you want to 
design a nice document. The focus of programming shifts from coding to 
describing the right algorithms. We found it rather enjoyable to write 
the documentation and learned a lot more than we would if we had coded 
it straight away. However, it is IME not a style you can use if you have 
only many short periods of work and when that is under stress.

Post a reply to this message

Orchid XP v8 schrieb:

> Hell, in Haskell land, people 
> regularly attempt to write code which is *provably secure*. (But then, 
> you have to define "secure" first... It's easy to prevent buffer 
> overruns, but not so simple to prevent glitches where access denied 
> messages inadvertantly reveal information indirectly.)

There's indeed no such thing as "provably secure".

People thought smartcards were provably secure, because they would keep 
their data to themselves, and communicate to the outside world only via 
a single, clearly defined 3-wire interface with a clearly defined 
protocol. So how could anyone possibly get at the data?

Then people realized that there are two other wires interfacing the card 
to the outside world: The power supply. And they found that as the card 
does its cryptographic computations, it mumbles to itself in a distinct 
pattern.

The problem is that proof is always based on axioms - and each axiom can 
turn out to be wrong (otherwise it wouldn't be an axiom but a theorem, 
and therefore itself based on other axioms). In this case, the axiom was 
"the smartcard reveals information only via a single 3-wire interface".


>> That seems to go into a similar direction as contract-oriented design.
> 
> Yeah, that's a nice idea. Doesn't seem very popular though...

It's my favorite approach, actually. I know of no better or easier way 
to design the interface of any module, class, component or what-have-you.


>> Try implementing and using generic container classes in a non-OO 
>> language.
>>
>> Then try to refactor your application to use a deque container instead 
>> of a stack for a certain job. Or a tree-backed map instead of a 
>> hash-table-backed one someplace else.
>>
>> You won't have much success without implementing verbosely what OO 
>> languages do for you behind the scenes.
> 
> Tried using Haskell recently? Haskell is not OO.

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

The functional approach has many features that give it power similar to 
(if not greater than) the object-oriented approach, so I leave it out of 
the discussion of OO achievements.

Post a reply to this message

Darren New schrieb:
> Orchid XP v8 wrote:
>> Not for desktop applications, I'd suspect. (Injection attacks are 
>> typically more applicable to websites.)
> 
> Yes. This was from SANS, so they cover pretty much everything, from 
> operating systems to desktop apps to web apps.
> 
> Altho have you heard of the Slammer attack? :-) That's basically code 
> injection.

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

Post a reply to this message

Orchid XP v8 schrieb:
> I think what happened is that somebody invented Prolog, and it makes it 
> almost seem like the computer is "thinking". It lets the computer solve 
> logical problems as if by magic (i.e., it doesn't look like a regular 
> algorithm, it looks like real insight). And people thought that in a few 
> years' time, somebody would come up with a set of predicates to describe 
> the operation of a computer program, you'd put in a mathematical 
> description of what the program is supposed to do, and Prolog would 
> magically compute the most efficient sequence of machine instructions...

Yeah, that sounds plausible.

> ...which would just mean writing programs as mathematical statements 
> rather than lists of instructions. It would just be another programming 
> language. And, you know, people have argued that programming in Haskell 
> is like programming with mathematics, so...
 >
> [One might also mention Mathematica.]

Another fallacy of that time (and possibly with the functional 
programming approach) was the assumption that computer programs would 
always have the purpose of solving inherently mathematical problems - 
and that programming would therefore always be done by studied 
mathematicians.

Now I guess the math required to program a word processor or an e-mail 
client is not /that/ complicated :-)

Unfortunately, the functional approach is quite brain-wrecking for 
anyone not trained in university-level mathematical thinking - or so it 
appears to me.

Post a reply to this message

John VanSickle schrieb:

> You know you're talking to an academic when he says that PASCAL will 
> become universally popular.  I've never seen it used outside of the 
> context of learning to program.

Just take any application written in Delphi, which is basically Pascal 
with OO add-ons.

The DOS configuration software for the CH Flightstick series of 
joysticks (back in the pre-USB era) was apparently written using Turbo 
Pascal, to name a commercial, non-"homebrewn" piece of software.

Post a reply to this message

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

Darren New wrote:
> 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.
> 
Well, the documentation is fairly specific about how it does, just not 
how to turn it on. Its basically a mode flag, which when turned on, 
triggers, "show_grab_handles", and, "disable_control", or something like 
the second one. I don't remember the name. In theory, you could also 
trip both of those states *in* the control yourself, but the control 
needs to support grab handles, and have a draw state, where it shows 
itself in its "not working" mode, and refuses input. In other words, 
clicking on any part of it should just trigger "drag", not what ever the 
control would normally do when clicked, and it shouldn't, if a display, 
react to data coming into it, such as setting its text, etc. Windows, 
and certain other standard containers, contain the internal capabilities 
of triggering a "go into design mode" message to all of their children. 
The problem is, the only application that "supports" this function seems 
to be the compiler suite, and there is no clear documentation of how to 
use it in your own applications.

There is also an implication, both from how the compiler GUI works, and 
the documentation, which implies that any such container, which works as 
part of the GUI, can have this setting flipped, and trigger the event, 
without making the entire application do it. This is why you can move 
around objects in the design GUI, while the GUI itself is still 
"functional", including windows, which are themselves elements that can 
be placed in other containers, such as the compiler's GUI window. You 
still have to implement code to show the "default" state of your 
control, and display grab handles, when in that mode, but, in principle, 
existing controls, like those that come with the compiler, already have 
both. The trick then is, making your container "fire" the event, by 
changing its state. Sadly, its not like any of the other states in the 
object. You can't set if using the normal methods. Its a **hidden** 
function, as is the function to show the handles, or disable the 
control, separately. It would have been a **lot** easier if they had 
made it an addressable option.

Oh, and just to make things even more fun, some standard controls have 
two modes, like the text box "single" vs. "multi-line", which can only 
be "set" while the control is in 'design' mode. This means that, if you 
wanted to implement a means to add such a control to your own 
application, even as something like an element read from an XML markup, 
you have to implement *both* the single and multi-line versions in your 
application, so that you can instance the correct one, instead of the 
**sane** thing, which would be to instance just TextBox, then set it, as 
needed, to the single/multiline version you need.

Mind, a lot of this got easier with .NET, and much of it is now 
meaningless, but I spent almost a year pulling my hair out a while back, 
when the thing I wanted to use it in was likely to be running in Win98 
as well as XP.

-- 
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

Darren New schrieb:

>> 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.

In contract-oriented programming, how could you possibly break the Order 
class by a change in the Customer class? All you could possibly do is 
/violate the contract/ of the Order class.

As far as that is concerned, such a violation /could/ be detected by 
static code analysis (within limits regarding the complexity of the 
pre-/postconditions), or by running the application in debug mode with 
pre-/postcondition checks enabled (within limits regarding test coverage).

I don't see where the C in ACID could be verified any differently.


>>> 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? :-)

Maybe the underlying type needs to be changed to allow doing just that, 
to implement some change request (or fix a design flaw).


>> 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.

In Java, if you'd be smart you wouldn't declare function arguments as of 
a certain /class/ type, but of a certain /interface/ type. You can then 
easily "upgrade" to a more powerful type without changing any existing 
code (except for the actual container object creation).

In other OO programming languages, you could do the same using the type 
names of abstract base classes instead of whatever actual implementation 
is used.

If you did your homework properly, most OO languages will allow you to 
pull off the stunt even without recompiling most of the code.


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

I presume this sentence was left incomplete? (Otherwise: Erm... yes, 
there are indeed lots of paradigms :-))

> 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.

But my primary point was that the OO /paradigm/ was highly influential 
in the creation of such type libraries - and that a non-OO approach 
doesn't get you there, unless you somehow "emulate" OO behavior.

In the case of the STL, the library in a sense uses a "static OO" model: 
The implementing classes are /designed/ to be interchangeable without 
code change (to the extent that they implement the same "concept"); they 
are /designed/ to use the same function names and parameters for the 
common functionality. The only thing they lack is a language that allows 
them to carry this flexibility over to run-time.

>> 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.

This discussion seems familiar to me. I'd say it is /the/ most important 
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.

Oh yes, it part of the point I'm making.


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

No, but they both "inherit" from the same "concepts".


>> 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?)

 From an object's caller's point of view, OO support in programming 
languages /is/ "just a nice way of passing a pointer around".

 From an object implementation's point of view, OO support in 
programming languages /is/ typically nothing more than syntactic sugar 
to automatically generate implementation details such as virtual method 
tables, and (in the case of class-based OO) provide the compiler with 
hints about type compatibility.

And, as you say yourself, subclassing and inheritance is one of the 
primary defining features of /class-based/ OO. Given that there is 
non-class-based OO, obviously subclassing and inheritance /cannot/ be 
the primary defining features of OO in general.

Post a reply to this message

Darren New schrieb:
> Darren New wrote:
>> Erlang? Tcl? LISP?
> 
> Actually, Ada can do this too, I'm pretty sure, even without using its 
> OO features.

"Non-OO mainstream (imperative) language"?

These languages all don't appear to fit that bill.


> 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*.

I never said it does.

Though it wouldn't stand in the way of that. This is primarily a matter 
of the run-time system, not the programming language (let alone software 
design) paradigm.

Post a reply to this message

Patrick Elliott wrote:
> Its basically a mode flag, which when turned on, 
> triggers, "show_grab_handles", and, "disable_control", or something like 
> the second one. 

I see.  That's kind of what I thought. I thought you were talking about the 
control doing something in the IDE, rather than the IDE driving the control.

> Mind, a lot of this got easier with .NET, 

Yes. I never got into the design mode of COM stuff.

-- 
   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:
> In contract-oriented programming, how could you possibly break the Order 
> class by a change in the Customer class? 

By changing the contract of the customer class that the order class relies 
on.  I haven't seen anything in a language where the order class could say 
what parts of the customer class's contract it relies upon.

> As far as that is concerned, such a violation /could/ be detected by 
> static code analysis (within limits regarding the complexity of the 
> pre-/postconditions), or by running the application in debug mode with 
> pre-/postcondition checks enabled (within limits regarding test coverage).

One would hope.

> I don't see where the C in ACID could be verified any differently.

It's more mathematical. Of course, it's harder to enforce everything in SQL 
that you can express in (say) Eiffel.

> In Java, if you'd be smart you wouldn't declare function arguments as of 
> a certain /class/ type, but of a certain /interface/ type. You can then 
> easily "upgrade" to a more powerful type without changing any existing 
> code (except for the actual container object creation).

Right.

> In other OO programming languages, you could do the same using the type 
> names of abstract base classes instead of whatever actual implementation 
> is used.

Right.

> If you did your homework properly, most OO languages will allow you to 
> pull off the stunt even without recompiling most of the code.

Probably. But ... so? :-)

> 
>> The point I was making is that there are lots of paradigms
> 
> I presume this sentence was left incomplete? (Otherwise: Erm... yes, 
> there are indeed lots of paradigms :-))

Sorry. There are lots of paradigms that let you do things like change the 
type of a variable without having to have OO.

> But my primary point was that the OO /paradigm/ was highly influential 
> in the creation of such type libraries - and that a non-OO approach 
> doesn't get you there, unless you somehow "emulate" OO behavior.

Ehn. I'll disagree. I'll agree that container classes and GUIs both 
benefited tremendously from an OO treatment, but I'll also assert that 
non-OO modules and libraries (say, Ada83's) did nicely without the need for OO.

> In the case of the STL, the library in a sense uses a "static OO" model: 
> The implementing classes are /designed/ to be interchangeable without 
> code change (to the extent that they implement the same "concept"); they 
> are /designed/ to use the same function names and parameters for the 
> common functionality. The only thing they lack is a language that allows 
> them to carry this flexibility over to run-time.

Well, yes. But that doesn't make them designed based on OO, any more than 
UNIX's file system design was based on OO just because everything was a file 
and used the same read and write calls.

>>> 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.
> 
> This discussion seems familiar to me. I'd say it is /the/ most important 
> trait of OO.

Yes. But it's not definitive. You can't have OO without encapsulation, but 
there are many ways to have encapsulation without OO.  The container example 
you gave was all about encapsulation, not OO.

>> Does the STL's dequeue inherit from the STL's stack, or vice versa?
> No, but they both "inherit" from the same "concepts".

Um, ... No.  Have you ever worked with a modular language that *isn't* OO? 
Ada, Modula-3, something like that?

> And, as you say yourself, subclassing and inheritance is one of the 
> primary defining features of /class-based/ OO. Given that there is 
> non-class-based OO, obviously subclassing and inheritance /cannot/ be 
> the primary defining features of OO in general.

I don't think there is a primary *defining* feature of OO in general.

-- 
   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:
> Darren New schrieb:
>> Darren New wrote:
>>> Erlang? Tcl? LISP?
>>
>> Actually, Ada can do this too, I'm pretty sure, even without using its 
>> OO features.
> 
> "Non-OO mainstream (imperative) language"?
> 
> These languages all don't appear to fit that bill.

You don't think Ada or Tcl is mainstream?  Just because you haven't run into 
them doesn't mean they're not widely used.

Heck, many of the GUIs you see out there are based on Tk, which is based on 
Tcl, which isn't OO.  Fire up Python's IDLE, for example, and note that it 
has a Tk logo in the corner.

> Though it wouldn't stand in the way of that.

To some extent it would, depending on how your OO is integrated with the 
rest of your system. OO tends to have many references to one object 
scattered about in other objects. You have to avoid that if you're going to 
incrementally upgrade code as it runs.

-- 
   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:

> 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.

Personally, I don't know how the program is going to work until I've 
figured out how to write it.

(Which probably just means I always implement my programs in the way 
that's easiest for me to program...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> 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.

Well, when you compile a C program, you don't then edit the generated 
machine code. You edit the original C program and recompile.

Similarly with CASE, you edit in the case tool and then regenerate the 
source code.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> ...which would just mean writing programs as mathematical statements 
>> rather than lists of instructions. It would just be another 
>> programming language. And, you know, people have argued that 
>> programming in Haskell is like programming with mathematics, so...
>  >
>> [One might also mention Mathematica.]
> 
> Another fallacy of that time (and possibly with the functional 
> programming approach) was the assumption that computer programs would 
> always have the purpose of solving inherently mathematical problems - 
> and that programming would therefore always be done by studied 
> mathematicians.
> 
> Now I guess the math required to program a word processor or an e-mail 
> client is not /that/ complicated :-)

Some people might retort that too few programmers realise the deep 
mathematical structure of the programs they're trying to implement. :-P

For example, Darcs is a version control system, much like RCS or CVS 
are. But Darcs has an "algebra of changesets". Basically this dictates 
the possible ways in which changesets can be applied. (If you think this 
is barking mad, recall that databases are based on the relational 
algebra, and that works just fine.)

To my knowledge, nobody has written a word-processor or e-mail client in 
Haskell yet. But they have written an IRC bot, and a text editor along 
the lines of Emacs. [Possibly the least-usable text editor in history...]

"Mathematics" isn't just about calculating things, you know.

> Unfortunately, the functional approach is quite brain-wrecking for 
> anyone not trained in university-level mathematical thinking - or so it 
> appears to me.

Heh, well... I suspect it only appears that way due to the strange 
notation and unusual technical terms. I have no mathematical training of 
any description at all, and I can work it...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 4-10-2009 10:51, Orchid XP v8 wrote:
> Darren New wrote:
> 
>> 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.
> 
> Personally, I don't know how the program is going to work until I've 
> figured out how to write it.
> 
> (Which probably just means I always implement my programs in the way 
> that's easiest for me to program...)

Next time, after you finished it, try to document how and especially why 
it works. Just as an exercise. I bet you end up documenting (and 
programming) something more efficient and robust.

Post a reply to this message

Orchid XP v8 wrote:
> Darren New wrote:
> 
>> 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.
> 
> Personally, I don't know how the program is going to work until I've 
> figured out how to write it.

Ah, but right there is the difference between documentation that you can put 
in javadoc and documentation you can't.

"What does this do" is in no way related to "how does it do it".

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

Post a reply to this message

Orchid XP v8 wrote:
> Similarly with CASE, you edit in the case tool and then regenerate the 
> source code.

Yep. This assumes you can put everything into the CASE tool that you need. 
If the CASE tool is only generating the skeleton, you need to be able to go 
back, is what I was saying.

Not being able to go back and forth is one reason the CASE tools are so 
expensive - they can't solve just the part they want to solve. They have to 
solve the whole end-to-end thing.

-- 
   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:
> Patrick Elliott wrote:
>> Its basically a mode flag, which when turned on, triggers, 
>> "show_grab_handles", and, "disable_control", or something like the 
>> second one. 
> 
> I see.  That's kind of what I thought. I thought you were talking about 
> the control doing something in the IDE, rather than the IDE driving the 
> control.
> 
>> Mind, a lot of this got easier with .NET, 
> 
> Yes. I never got into the design mode of COM stuff.
> 
Yeah. Wish I hadn't. Wasted a lot of time trying to solve something that 
just wasn't obviously solvable. Mind, I am sure you could work it out 
with enough time to play with IDispatch, but I was looking to the 
concrete example. I had wanted to design something that would allow you 
to make a layout for a window, then export the settings to XML, and 
later "reload" it. This would allow someone to make an importable layout 
for different games, which could even be sent over on the fly, as 
needed. The point was to avoid the overhead of needing the compiler 
suite to make the layout, or worse, having to use something like IE to 
"load" script and layout, when the client in question already had its 
own, far more efficient, script system, and just lacked access to a way 
to create custom windows.

Since then, some of these features have been added, but they are far 
more limited than they would have been if you could have just plugged in 
*any* control you wanted, instead of being limited only to those already 
supported (which may be faster than COM, but adds more code and overhead 
*in* the client itself).

The other issue we ran into was working out how to pull and IE and link 
in such controls dynamically, so they didn't have to be "predefined", 
and the client could pass on events from the attached control to the 
script system. That is documented... sort of. The only example shows 
using "one" control, in a very limited instance, doesn't go into detail 
on any other aspects, and gives no example of how to properly handle 
multiple copies of the control, *nor* several different controls. Sort 
of a, "this is how to park your car in a single space, but not in a 
crowded parking lot." In principle, someone with more understanding 
could have worked it out. I didn't even have a "current" version of the 
compiler to work with, which supported the API I needed. :p

-- 
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

Darren New schrieb:

>> In contract-oriented programming, how could you possibly break the 
>> Order class by a change in the Customer class? 
> 
> By changing the contract of the customer class that the order class 
> relies on.  I haven't seen anything in a language where the order class 
> could say what parts of the customer class's contract it relies upon.

Ah, I get that point now... my mental image had dependency the other way 
round for some obscure reason.

Now that's a problem indeed: Changing a contract is a particularly 
problematic change. Because that's why contracts are there in the first 
place.

Note that a good contract places as many constraints on /both/ parties 
as possible, to get some "room to breathe" in case either side needs to 
be modified.


>>> The point I was making is that there are lots of paradigms
>>
>> I presume this sentence was left incomplete? (Otherwise: Erm... yes, 
>> there are indeed lots of paradigms :-))
> 
> Sorry. There are lots of paradigms that let you do things like change 
> the type of a variable without having to have OO.

Maybe, but at any rate OO has been the most influential of these in the 
last decades.

>> But my primary point was that the OO /paradigm/ was highly influential 
>> in the creation of such type libraries - and that a non-OO approach 
>> doesn't get you there, unless you somehow "emulate" OO behavior.
> 
> Ehn. I'll disagree. I'll agree that container classes and GUIs both 
> benefited tremendously from an OO treatment, but I'll also assert that 
> non-OO modules and libraries (say, Ada83's) did nicely without the need 
> for OO.

As my point is the tremendous benefit thing, I can live with that 
assertion of yours.

Post a reply to this message

Orchid XP v8 schrieb:

> Well, when you compile a C program, you don't then edit the generated 
> machine code. You edit the original C program and recompile.
> 
> Similarly with CASE, you edit in the case tool and then regenerate the 
> source code.

That's the /theory/ :-)

Post a reply to this message

>> Similarly with CASE, you edit in the case tool and then regenerate the 
>> source code.
> 
> Yep. This assumes you can put everything into the CASE tool that you 
> need. If the CASE tool is only generating the skeleton, you need to be 
> able to go back, is what I was saying.
> 
> Not being able to go back and forth is one reason the CASE tools are so 
> expensive - they can't solve just the part they want to solve. They have 
> to solve the whole end-to-end thing.

True enough.

I think the main thing, though, is that there's generally not a huge 
demand for CASE tools. Rational Rose lets me program in a diagram which 
describes exactly how a given function executes, but... it would be 
drastically, *drastically* quicker to type this as text. The diagramming 
tool makes it take 10 times longer to do (more or less) the same job.

I think perhaps the job could be quickER with something like Haskell, 
since there are so few primitives to deal with. But even then, typing is 
likely to be faster. (OTOH, with fewer primitives, maybe the reverse 
transformation becomes more feasible...)

Post a reply to this message

Darren New schrieb:

>>> Actually, Ada can do this too, I'm pretty sure, even without using 
>>> its OO features.
>>
>> "Non-OO mainstream (imperative) language"?
>>
>> These languages all don't appear to fit that bill.
> 
> You don't think Ada or Tcl is mainstream?  Just because you haven't run 
> into them doesn't mean they're not widely used.

My copy of Wikipedia categorizes Tcl as "multi-paradigm: 
object-oriented, functional, procedural, event-driven programming" 
(emphasis added; I haven't done enough Tcl coding to verify this claim) 
- even though it does appear to be mainstream indeed, it doesn't seem to 
fit the bill of "Non-OO ... (imperative) language".

As for Ada: When I think "mainstream", I don't usually think avionics, 
weapon systems or spacecraft - or any other embedded or real-time 
application, for that matter.

>> Though it wouldn't stand in the way of that.
> 
> To some extent it would, depending on how your OO is integrated with the 
> rest of your system. OO tends to have many references to one object 
> scattered about in other objects. You have to avoid that if you're going 
> to incrementally upgrade code as it runs.

As I said, it depends on the runtime. If for instance the runtime would 
store object references as a combination of a "data address" and a "type 
identifier", it would be more than problematic to add data fields (due 
to inability to move the object on the heap), or to "upgrade" only some 
objects to the new implementation; if the runtime instead stores object 
references as pointers to memory blocks including both the data and a 
virtual method table, data size may still not grow, but implementation 
could be changed for individual objects of a type; and a runtime that 
happens to use chained references for garbage collection would have all 
the necessary power to actually relocate objects on the heap, thus 
allowing for arbitrary changes to the data structure. With such a 
runtime, your "object network" can be arbitrarily complex. Similar 
flexibility can be achieved by adding a level of indirection between the 
reference and the actual data.

Post a reply to this message

clipka wrote:
> Now that's a problem indeed: Changing a contract is a particularly 
> problematic change. Because that's why contracts are there in the first 
> place.

Right. This is why I laugh at all the people that tell me to just write unit 
tests and everything will be fine.

> Note that a good contract places as many constraints on /both/ parties 
> as possible, to get some "room to breathe" in case either side needs to 
> be modified.

This assumes you're not making fundamental changes like adding a new level 
of heirarchy to the product catalog or a new kind of management operation or 
whatever.  Depending on what you code in your contracts, they can really get 
in the way.

> Maybe, but at any rate OO has been the most influential of these in the 
> last decades.

Yes. See OP. ;-)

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

Post a reply to this message

Invisible wrote:
> drastically, *drastically* quicker to type this as text. The diagramming 
> tool makes it take 10 times longer to do (more or less) the same job.

Which is why you need to be able to go back and forth, you see.

The *problem* with being able to go back and forth is that it really doesn't 
add a whole lot of value if the two forms are isomorphic.

Which is why having a CASE tool generate a textual skeleton of code, and 
then being able to change that skeleton and have the CASE tool able to 
handle the changes, is probably the most effective way.

-- 
   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:
> - even though it does appear to be mainstream indeed, it doesn't seem to 
> fit the bill of "Non-OO ... (imperative) language".

It's not OO. There's a library to make it look like it's OO. When you use 
that library, each object is represented as a global procedure. It can kind 
of sort of look OO, but it isn't.

> As for Ada: When I think "mainstream", I don't usually think avionics, 
> weapon systems or spacecraft - or any other embedded or real-time 
> application, for that matter.

OK. When I say "mainstream", I mean a language that's actually used for 
actual development by people other than those at the same company where the 
language was invented. I rule out things like Blue and Sing# and such, the 
experimental languages crafted for a specific program to be written in.

I would say anything where you can go to Amazon and buy a textbook and then 
download the compiler would have to be mainstream. If you have to download 
the whitepaper that describes the language? That's not mainstream.

> As I said, it depends on the runtime. If for instance the runtime would 
> store object references as a combination of a "data address" and a "type 
> identifier", it would be more than problematic to add data fields (due 
> to inability to move the object on the heap),

I think we can safely rule out upgrading running executable code for systems 
that don't have automatic memory management.

> or to "upgrade" only some 
> objects to the new implementation; 

Nah. You'd just patch the type in the pointers that point to the new objects.

> if the runtime instead stores object 
> references as pointers to memory blocks including both the data and a 
> virtual method table, data size may still not grow, but implementation 
> could be changed for individual objects of a type; and a runtime that 
> happens to use chained references for garbage collection would have all 
> the necessary power to actually relocate objects on the heap, thus 
> allowing for arbitrary changes to the data structure. With such a 
> runtime, your "object network" can be arbitrarily complex. Similar 
> flexibility can be achieved by adding a level of indirection between the 
> reference and the actual data.

The problem you might be missing is the existence of return addresses on the 
stack that index into the code you're changing. If your objects sit around a 
long time in various networks, and you can't tell which bits of running code 
are using which objects (as in, have methods of those objects on the stack 
for that thread), then you're going to have a hard time replacing the 
objects without clobbering code that's already running. You're also going to 
have a hard time running the old code in one thread and the new code in 
another thread both using the same shared object.

I guess you could make the upgrades of an entire class at once, but you'd 
have to make sure nobody is executing any methods in that class when you did 
it. (I'm also implicitly assuming for good reason that few people are going 
to want to upgrade a single-threaded process while it's running.)

It's sort of like trying to reorganize a SQL table while there's 
transactions in progress on it. Messy.

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

Post a reply to this message