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