|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> The multi-processing challenge /is/ a surprise to software
> developers, as a decade ago nobody would have thought that the increase
> in computing power would take /this/ route in consumer computers. So
> there's a growing computing power "vacuum" waiting to be filled. And it
> /will/ be filled.
>
> But maybe I'm a bit biased by working on POV-Ray :-)
Oh, with POV-Ray there's never a shortage of ways to use up CPU power. :-P
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
>>> I suspect it's because we reached the end of the low-hanging fruit in
>>> language design which also has a high payoff.
>>
>> I disagree. I can think of a number of persistent problems with large
>> code bases that aren't solved by todays languages or libraries.
>
> Such as?
Interactions between large code bases with fundamental different design
ideas. Documentation. Navigation. Intermixing of different kinds of concerns
in the same code (logging, error handling, debugging info, actual code you
care about, etc). Dependency management. Dynamic upgrading (as in, replacing
code while it's running). Version management (as in, upgrading libraries you
depend on with the assurance you won't break something, avoiding DLL hell,
etc., which MS has started to address with the .NET and C# stuff). Modifying
stored data to match new code.
Some of this is handled in some languages. Nothing popular really has a lot
of this sort of stuff in it. (Other than, as I said, .NET taking the first
steps.)
> And anyway, I think he's only saying that the stuff that's "easy" to fix
> has already been fixed, leaving only the less easy stuff.
Sure. But heck, array indexing wasn't *easy* when it was invented. I'm just
surprised I haven't seen too much mainstream improvement in how things work
in so long. About the only things I can think of that got popular since OO
are dynamic loading of code, libraries like CPAN and imitators, "sandboxing"
code, and maybe scripting languages (embedded or not). Generally, 20 years
ago, programs were pretty well self-contained. Nowadays a lot of them are
built from public parts.
--
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 <dne### [at] sanrrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 30 Sep 2009 18:14:24 -0700, Darren New <dne### [at] sanrrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |
|
|