 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New schrieb:
> What comes after Object Oriented?
>
> I mean, we started with assembler, then libraries, then HLLs, then
> portable HLLs, then interpreters, then structured programming, then a
> whole bunch of stuff that nobody really picked up (workspaces, LISP,
> self-modifying code, sophisticated macros, functional programming, etc),
> then Object Oriented, then .... nothing.
>
> Why has programming language development been functionally stalled for
> 30 years?
Because it hasn't.
There are languages out there, for instance, that support "design by
contract", which was first mentioned no more than 23 years ago.
Aspect-oriented programming languages haven't been around for longer
than 8 years.
But I guess the most pressing problem computer languages need to address
is multiprocessing. At present, the number of languages /natively/
supporting multithreading (let alone distributed computing) is rather
limited, while target platforms are already starting to enter consumer
households on a large scale.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
> If course many/most languages support some form of inheritance and
> dynamic binding, but practical software development uses those tools
> a lot less than was expected at the height of the OOP craze.
Agreed. I think it doesn't solve most of the problems of "reusable
software" it was supposed to solve.
The modularity is good, and transcends programming languages, yes.
> 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.
> Of course OOP will never die. It's just too useful for many situations.
Sure. Structured programming never died - it's still inside each method, for
example. It just doesn't scale to really big programs.
> (For example GUI programming in modern windowed systems is a situation
> where OOP seems to be just perfect. It's like OOP was invented to solve
> the GUI programming problem in the best possible way.) It's just that its
> purest form has fallen a bit out of fashion.
GUI and lots of kinds of data structures, but not really too much bigger
than that.
I'm thinking something along the lines of LISP-power macros or other
templating sorts of programming, or "aspect-oriented programming" might be
next.
My guess is this:
Ignoring programing paradigms forced by hardware advances (like
multiprocessing), I'd say the modularity has to keep getting increased. But
the only way to do that is to have numerous bits of code in different places
all be interacting at once. You need to separate out the error handling, the
logging, the sanity checks, the assertions/preconditions/invariants, the
performance hints, etc. Sort of like the way SQL's performance information
is separated out from the semantics - tables are tables, but index creation
statements give you the performance you need.
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. Kind of like how C++
makes all the clean-up when there's an error be off in another bit of code,
in the destructors of the local variables, instead of how you'd do it in C
with an if statement or in Java with a finally clause.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
