|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |