![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Warp wrote:
> > I don't see it that language development has been stuck with OOP for 30
> > years.
> I haven't seen a new "wow, this is a great improvement" sort of thing
> happen, tho.
Was OOP a "wow, this is a great improvement" at the time it was introduced,
or was it a gradual shift, which we are now compressing into one big event
when looking back, 30 years after?
> > But otherwise I have seen a trend in programming design to move a bit
> > more away from pure OOP and more towards dynamic programming.
> 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
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Was OOP a "wow, this is a great improvement" at the time it was introduced,
> or was it a gradual shift, which we are now compressing into one big event
> when looking back, 30 years after?
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. Which is why the hype about inheritance was about, and the fact
that it didn't work out that way is related to the fact that people aren't
using nearly as much inheritance as they expected to.
>>> But otherwise I have seen a trend in programming design to move a bit
>>> more away from pure OOP and more towards dynamic programming.
>
>> 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 all
very dynamic in actual usage. Rails is basically one big dynamic programming
library.)
While I think this is a good trend, I worry what it's going to do for
maintenance. It makes putting together smaller programs a lot faster, but it
can be a real headache when you're trying to understand only a piece of the
code.
(I'm not sure I'd agree functional programming, closures, or continuations
count as "dynamic programming", but it's a pretty informal definition.)
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Wed, 30 Sep 2009 18:14:24 -0700, Darren New <dne### [at] san rr com> wrote:
>
>Because I program for a living, and 99% of the time it's tedious, error
>prone, and suckful.
I knew it! :-)
--
Regards
Stephen
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New schrieb:
> Yes, and Erlang does this too (invented the idea of hooking it into the
> language, eve). My point is that it isn't a mainstream kind of thing.
> There's all kinds of great research out there. It just doesn't seem
> like any of it hit mainstream language design.
Name any OO language that was mainstream 30 years ago.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New schrieb:
> 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?
Sure, Docman is not /really/ part of the core language, but it can be
used as such. Javadoc comes closer to being part of the language, as it
has been integral part of Sun's Java SDK since early days.
Doesn't C# include some mechanism along those lines, too?
> To avoid security problems?
I guess this would require a proper definition of "security problems".
> To get multiple people interacting on one code base?
You mean, something like version management built into the language? I
guess there's no real need for that - external version management tools
do quite a good job on this one, and modern IDEs do quite a good job at
integrating them with the development.
Integrating them into the programming language would actually be
counter-productive, as its scope would be restricted to the language
source code, and make it difficult to also manage other resources needed
to compile a program.
> 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.
At the application level, it may actually be counter-productive: When
you need a tool to put nails into wood, any attempt to re-use components
of a screwdriver will prevent you from designing a proper hammer.
But it appears to me that as far as libraries are concerned, OOP has
been a tremendous success regarding code re-use.
>> This is probably the case in business software, which is a different
>> animal anyway, but software quality hasn't been playing a /too/ big
>> role in consumer software,
>
> Possibly because it's too hard with current languages. Too easy to make
> mistakes that cost too much to find. But that's exactly the sorts of
> things that HLLs, structured programming, and OOP were supposed to help
> with.
That may have been the motivation to /invent/ them. But in the realm of
consumer software, their actual /use/ was much more motivated by
allowing to write much more complex applications.
> I'm just hoping that .NET or C++ isn't the pinacle of software language
> design. ;-?
Not bloody likely :-)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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 :-))
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Captain Jack schrieb:
> I remember predictions (from about 30 years ago, interestingly; 1980,
> specifically) that the computer world would move toward having a single
> programming language that everyone would use for everything, with something
> like little high speed translators that would make the code run on whatever
> platform it was on.
Uh-huh... bytecode, anyone?
But the single-programming-language prediction seems a /bit/ of a miss :-)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
Now, if I could somehow purchase a PC with dual hexacore processors...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |