 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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?
--
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 wrote:
> Why has programming language development been functionally stalled for
> 30 years?
Because the current environment is well-suited to survival in its
current form?
Why the societal fascination with, nay, *demand* for 'new and improved'?
"If it's old, it's bad!" is only valid if the current situation is no
longer suitable for the old thing to exist. Software development has
pushed the expectation for Something New in an artificial and
exaggerated way.
--
Tim Cook
http://empyrean.freesitespace.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Cook wrote:
> Darren New wrote:
>> Why has programming language development been functionally stalled for
>> 30 years?
>
> Because the current environment is well-suited to survival in its
> current form?
Really??
> Why the societal fascination with, nay, *demand* for 'new and improved'?
Because I program for a living, and 99% of the time it's tedious, error
prone, and suckful. And the hardware hasn't stopped improving. But I'm
still using the same programming techniques I used on my 2MHz sparkstation
with 4Meg of RAM.
--
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 wrote:
> What comes after Object Oriented?
Only time will tell, but my guess would be language features to help the
compiler understand how to efficiently run a program in a highly
parallel or even heterogeneous environment. This has already started to
a degree as there are now multiple programming languages targeted to GPUs.
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,
but it seems like the best bet for what's next. Also, I suspect that
"everyone starts using pure FP" will not be the way in which this
happens, although maybe some FP ideas will pay a role.
> Why has programming language development been functionally stalled for
> 30 years?
I suspect it's because we reached the end of the low-hanging fruit in
language design which also has a high payoff. This is actually a
somewhat testable hypothesis, since if it's true we should expect to see
an increase in the development of useful tools to assist programmers
(IDEs, source control, testing, collaboration, etc.) dovetailing with
the decrease in useful language developments.
I still think it's an interesting question if there's any really useful
unexplored language paradigms (in fact I think there are), but I think
the question is more fruitfully answered by considering both language
advances and programming tool advances.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> Why has programming language development been functionally stalled for 30 years?
we've been to busy fixing old code. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Why has programming language development been functionally stalled for 30 years?
>
> we've been to busy fixing old code. :)
That's probably about right, you know...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> Only time will tell, but my guess would be language features to help the
> compiler understand how to efficiently run a program in a highly
> parallel or even heterogeneous environment. This has already started to
> a degree as there are now multiple programming languages targeted to GPUs.
>
> 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,
> but it seems like the best bet for what's next. Also, I suspect that
> "everyone starts using pure FP" will not be the way in which this
> happens, although maybe some FP ideas will pay a role.
Most programming languages I've seen tackle parallel programming using
threads, locks and semaphores. These are not exactly ground-breaking
techniques. Over in Haskell land, we have sparks, parallel arrays,
software transactional memory... and also threads and locks if you
prefer. I find all this very exciting.
Parallel arrays in particular look very suitable for the GPU... but
then, how long has Haskell been claiming that running on the GPU is
"just around the corner"? Hasn't happened yet. (Although I think this is
due to lack of manpower rather than anything more fundamental. It seems
there's barely enough people to keep GHC going. But hey, where are you
going to get more people from?)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> 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?
I don't see it that language development has been stuck with OOP for 30
years.
Instead, what has happened is that practical software development has
taken what's good about OOP (namely modularity) and moved a bit away from
what resulted to be not-so-useful-after-all (namely inheritance, dynamic
binding).
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. They were
not, after all, the panacea of programming, nor are they very well
suited for the majority of problems.
Modularity, on the other hand, is at a completely different level of
software design. It is an uber-tool which just works and is more or less
mandatory for any program of a significant size to remain manageable. The
larger your program is, the more important modularity is. I'd say modularity
is an essential programming design principle which transcends any single
programming paradigm. OOP is very heavily based on modularity, which explains
why it's so popular. Just the modular part of OOP makes large programs
manageable and maintainable.
But otherwise I have seen a trend in programming design to move a bit
more away from pure OOP and more towards dynamic programming. Also
functional programming is trying to raise as a viable design strategy,
maybe because modern functional programming languages have quite a lot
of dynamic programming style in them (although I have my own doubts about
whether it will ever truely become mainstream).
Dynamic programming could be, rather roughly, seen as a "more versatile
way of doing what inheritance and dynamic binding were supposed to do".
Where OOP (sans modularity) falls short, dynamic programming often offers
a much easier solution.
Of course OOP will never die. It's just too useful for many situations.
(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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
