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