|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> But the single-programming-language prediction seems a /bit/ of a miss :-)
Aren't computers supposed to "program themselves" by now? Anyone
remember that one?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Yeah. That's definitely a change driven by new hardware paradigms,
>> tho. Besides that obvious change, what else, tho? What would make it
>> easier to write documentation?
>
> Docman? Javadoc?
Well now, there are basically two ways to do documentation:
1. Have the source code, and a seperate set of documentation files.
2. Have the documentation text mingled with the source code text.
Method #1 suffers from the problem that the source code inevitably gets
updated more than the documentation, until the two end up being out of
sync. Incorrect documentation is worse than absent documentation.
Method #2 suffers from the problem that there's so much chatter in the
source file that you can't actually find the executable code any more.
It makes small, simple modules look huge and complex.
I can't think of a good way to solve this. Sure, you could have some IDE
where when you change a file, you can add a note to self to update the
documentation. But if the human forgets to add that note...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New schrieb:
> There was a tremendous amount of hype about how this would change
> software development. The biggest hype was with software reuse, and
> "Software ICs" and such.
Yes, but was that right after the /invention/ of OOP?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 schrieb:
>>> Oh, with POV-Ray there's never a shortage of ways to use up CPU
>>> power. :-P
>>
>> There /was/ with 3.6 :-)
>>
>> (Or, let's say, there was some shortage of /convenient/ ways to starve
>> the idle task :-))
>
> I'm still using 3.6. I can easily drain both cores at once. :-P
Sure - if you start two instances of 3.6. But for people like me, who
only work on one project at a time, and don't normally do any
animations, it didn't fit my definition of "convenient".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 schrieb:
>
> Method #2 suffers from the problem that there's so much chatter in the
> source file that you can't actually find the executable code any more.
> It makes small, simple modules look huge and complex.
>
My experience is that that's not the case.
To the contrary: Breaking up the source code with commenting blocks
helps give the code more structure, even if you don't change a single
statement.
> I can't think of a good way to solve this. Sure, you could have some IDE
> where when you change a file, you can add a note to self to update the
> documentation. But if the human forgets to add that note...
In any case I guess we agree that the problem of documentation needs to
be addressed not by programming /languages/, but by programming
/environments/.
I guess the ideal solution would be an IDE that is capable of managing
hypertextual RTF documents alongside with code, highly integrated with
the version management software, and for each change would ask: "What
was the nature of your code change, Dave?" - being smart enough to
identify which functions were actually changed, and also which ones
might be affected indirectly.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 schrieb:
> Aren't computers supposed to "program themselves" by now? Anyone
> remember that one?
Well, in a way they do: Think about code optimization.
The only illusion was about the level of abstraction that could be
obtained. I guess the problem there is that natural human language is
ill-suited for specifying even the problem to be solved with a computer
program (let alone the algorithm to solve it): As soon as precision is
required (and with computers that's obviously the case), it quickly gets
overly verbose and cumbersome (every scientific paper gives testimony of
this fact).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Name any OO language that was mainstream 30 years ago.
I dunno. But we got something new every 5 to 10 years for the first 40 years
or so. :-)
--
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:
> Yes, but was that right after the /invention/ of OOP?
I wasn't really following it right after the invention of OOP. I'm not
*that* old.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/01/09 13:42, Darren New wrote:
>>> What do *you* mean by the term "dynamic programming"? I know what I'd
>>> mean by it, but I don't know if your background would make it mean
>>> the same thing as mine does.
>>
>> http://en.wikipedia.org/wiki/Dynamic_programming_language
>>
>
> Cool. We agree on the definitions and I think we agree on the idea that
> dynamic programming is becoming a big thing. (Tcl, Python, Ruby, etc are
Somehow, I thought you may be thinking of:
http://en.wikipedia.org/wiki/Dynamic_programming
Because that's what people normally mean when they use that phrase.
Although it was obvious from the context that's not what Warp meant.
--
Why a man would want a wife is a big mystery to some people. Why a man
would want *two* wives is a bigamystery.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Docman? Javadoc?
Were that helpful, it might fit the bill. :-) As it stands now, it seems
more often an excuse to not write documentation than a tool for writing it.
> > To avoid security problems?
> I guess this would require a proper definition of "security problems".
Code doing things the author didn't want it to do because malicious people
intentionally caused it to happen.
> > To get multiple people interacting on one code base?
> You mean, something like version management built into the language?
I don't know. If I knew, I wouldn't be throwing these things out as "this is
what we don't have yet." I think there's more to having multiple people
working on a code base than "don't clobber each others changes."
Stuff like the ability for me to know that my change hurt your code.
Something like unit testing, only built into the language, say.
> > Or the perennially favorite, "reusable code"?
>
> I think practice has shown that the benefit of core reuse is limited to
> some standard classes: Container libraries; GUI frameworks; stuff like
> that.
To some extent, but why is that? Is it because we're missing something
fundamentally obvious in the programming paradigm? Clearly an OO library is
helpful when you have something that behaves like objects. But you try to
interface it to something that behaves like (say) SQL records, and you get
all kinds of ugly mismatches.
> But it appears to me that as far as libraries are concerned, OOP has
> been a tremendous success regarding code re-use.
Ehn, to some extent. How many of the libraries you use would work just as
well without OO, or with faked OO (like C's stdio fakes OO)?
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |