 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> It's not clear to me if this will require a major new programming
> paradigm to solve or if it can be shoehorned into existing techniques,
Both. ;-) Trust me, it'll get shoe-horned into what's there, *and* there
will be a decent language in case you don't want to use something like
C-with-a-bag-on-the-side.
> 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.
--
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:
> There are languages out there, for instance, that support "design by
> contract", which was first mentioned no more than 23 years ago.
Great. There's one language that supports it, and the compiler still sucks.
:-) Sure, there are a couple other languages, probably, but nothing that you
could point to a big company using. Nobody is betting their corporation on
the benefits provided by "design by contract" is what I'm saying.
(I tried to get people to use Eiffel 15 years ago for a new project. They
went with Java.)
> Aspect-oriented programming languages haven't been around for longer
> than 8 years.
Name a language besides LISP that I can use to write production-quality code
in that supports AOP?
I think AOP is a great idea, and it probably is the way going forward. I
just don't see it showing up in mainstream programming languages. But try to
create a language today that doesn't have OOP, and you'll get laughed at.
> But I guess the most pressing problem computer languages need to address
> is multiprocessing.
Maybe. The power of modern computers to handle *one* task is sufficient for
most everything. Stuff like games will get sped up by specialized hardware
(graphics engines, physics engines, etc). Servers and scientific work will
tend to parallelize along easy cleavage planes.
I mean, we had 64-CPU boxes for our servers in 1992. We just ran more than
64 processes on them independently. I'm not sure this isn't a viable
alternative for quite some time.
I guess I'm saying the kind of task you can speed up for a home user is not
going to get a big boost with 4 CPUs instead of 1, IMO. And servers scale
almost linearly.
I think software reliability and flexibility in the face of changing
requirements is a bigger motivator than taking advantage of multiple CPUs.
--
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 schrieb:
>
> I think you'll see things like the ability to say "log this message
> whenever this method gets called" or "that method can never get called
> with a null pointer", instead of having them inline in the code.
Such languages already exist. For instance, "Nice" allows you to
formalize contract constraints (pre- and postconditions), and have them
automatically checked at runtime in a debug version.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New schrieb:
> clipka wrote:
>> There are languages out there, for instance, that support "design by
>> contract", which was first mentioned no more than 23 years ago.
>
> Great. There's one language that supports it, and the compiler still
> sucks. :-) Sure, there are a couple other languages, probably, but
> nothing that you could point to a big company using. Nobody is betting
> their corporation on the benefits provided by "design by contract" is
> what I'm saying.
>
> (I tried to get people to use Eiffel 15 years ago for a new project.
> They went with Java.)
Then "Nice" may be something to try. It compiles to Java bytecode.
>> Aspect-oriented programming languages haven't been around for longer
>> than 8 years.
>
> Name a language besides LISP that I can use to write production-quality
> code in that supports AOP?
Hey, could you have named a language to write production-quality /OOP/
code 8 years after the concept was first mentioned?
> I mean, we had 64-CPU boxes for our servers in 1992. We just ran more
> than 64 processes on them independently. I'm not sure this isn't a
> viable alternative for quite some time.
No, because the home user will not normally have 64 processes to run,
but he'll still expect his software to run 4 times as fast on a quad
core system.
Game developers have already pioneered this area, and I guess as
multi-core systems get ever more common, whatever mechanisms and
languages the game developers have come up with will enter mainstream
languages. It may take some time, but it will happen. And we may be
surprised what software can then benefit from multithreading once it
becomes easier to express process interactions.
> I think software reliability and flexibility in the face of changing
> requirements is a bigger motivator than taking advantage of multiple CPUs.
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, and the challenges there come as not much of a
surprise. 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 :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Darren New" <dne### [at] san rrcom> wrote in message
news:4ac3fcc5$1@news.povray.org...
>
> Why has programming language development been functionally stalled for 30
> years?
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. I recall three different people (all academics, natch)
making predictions of this sort. One said the "universal" language would be
based on C, one cited Pascal, and the other one used the phrase "Super
LISP", although he didn't really explain what would be super about it.
I recall that later I was discussing this with a friend of mine who was an
engineering student and was, during the conversation, struggling with
Fortran related homework. His comment was, "as long as it ain't COBOL, I'm
happy."
:)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Darren New schrieb:
>>
>> I think you'll see things like the ability to say "log this message
>> whenever this method gets called" or "that method can never get called
>> with a null pointer", instead of having them inline in the code.
>
> Such languages already exist. For instance, "Nice" allows you to
> formalize contract constraints (pre- and postconditions), and have them
> automatically checked at runtime in a debug version.
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.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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?
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.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Hey, could you have named a language to write production-quality /OOP/
> code 8 years after the concept was first mentioned?
Sure. Both smalltalk and simula were used in production environments.
Just ... things moved on without them.
> No, because the home user will not normally have 64 processes to run,
> but he'll still expect his software to run 4 times as fast on a quad
> core system.
I think many users nowadays are happy with a 1MHz laptop and a 420RPM disk.
Almost everything is I/O time.
> Game developers have already pioneered this area, and I guess as
> multi-core systems get ever more common, whatever mechanisms and
> languages the game developers have come up with will enter mainstream
> languages. It may take some time, but it will happen. And we may be
> surprised what software can then benefit from multithreading once it
> becomes easier to express process interactions.
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? To avoid security problems? To get multiple people
interacting on one code base? Or the perennially favorite, "reusable code"?
> 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.
> 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.
That's a point.
I'm just hoping that .NET or C++ isn't the pinacle of software language
design. ;-?
--
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:
> 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
|
|
| |
| |
|
|
|
|
| |
|
|
