 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] sanrrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> But the single-programming-language prediction seems a /bit/ of a miss :-)
Aren't computers supposed to "program themselves" by now? Anyone
remember that one?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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?
Well now, there are basically two ways to do documentation:
1. Have the source code, and a seperate set of documentation files.
2. Have the documentation text mingled with the source code text.
Method #1 suffers from the problem that the source code inevitably gets
updated more than the documentation, until the two end up being out of
sync. Incorrect documentation is worse than absent documentation.
Method #2 suffers from the problem that there's so much chatter in the
source file that you can't actually find the executable code any more.
It makes small, simple modules look huge and complex.
I can't think of a good way to solve this. Sure, you could have some IDE
where when you change a file, you can add a note to self to update the
documentation. But if the human forgets to add that note...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New schrieb:
> 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.
Yes, but was that right after the /invention/ of OOP?
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 :-))
>
> I'm still using 3.6. I can easily drain both cores at once. :-P
Sure - if you start two instances of 3.6. But for people like me, who
only work on one project at a time, and don't normally do any
animations, it didn't fit my definition of "convenient".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 schrieb:
>
> Method #2 suffers from the problem that there's so much chatter in the
> source file that you can't actually find the executable code any more.
> It makes small, simple modules look huge and complex.
>
My experience is that that's not the case.
To the contrary: Breaking up the source code with commenting blocks
helps give the code more structure, even if you don't change a single
statement.
> I can't think of a good way to solve this. Sure, you could have some IDE
> where when you change a file, you can add a note to self to update the
> documentation. But if the human forgets to add that note...
In any case I guess we agree that the problem of documentation needs to
be addressed not by programming /languages/, but by programming
/environments/.
I guess the ideal solution would be an IDE that is capable of managing
hypertextual RTF documents alongside with code, highly integrated with
the version management software, and for each change would ask: "What
was the nature of your code change, Dave?" - being smart enough to
identify which functions were actually changed, and also which ones
might be affected indirectly.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 schrieb:
> Aren't computers supposed to "program themselves" by now? Anyone
> remember that one?
Well, in a way they do: Think about code optimization.
The only illusion was about the level of abstraction that could be
obtained. I guess the problem there is that natural human language is
ill-suited for specifying even the problem to be solved with a computer
program (let alone the algorithm to solve it): As soon as precision is
required (and with computers that's obviously the case), it quickly gets
overly verbose and cumbersome (every scientific paper gives testimony of
this fact).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Name any OO language that was mainstream 30 years ago.
I dunno. But we got something new every 5 to 10 years for the first 40 years
or so. :-)
--
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:
> Yes, but was that right after the /invention/ of OOP?
I wasn't really following it right after the invention of OOP. I'm not
*that* old.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/01/09 13:42, Darren New wrote:
>>> 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
Somehow, I thought you may be thinking of:
http://en.wikipedia.org/wiki/Dynamic_programming
Because that's what people normally mean when they use that phrase.
Although it was obvious from the context that's not what Warp meant.
--
Why a man would want a wife is a big mystery to some people. Why a man
would want *two* wives is a bigamystery.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Docman? Javadoc?
Were that helpful, it might fit the bill. :-) As it stands now, it seems
more often an excuse to not write documentation than a tool for writing it.
> > To avoid security problems?
> I guess this would require a proper definition of "security problems".
Code doing things the author didn't want it to do because malicious people
intentionally caused it to happen.
> > To get multiple people interacting on one code base?
> You mean, something like version management built into the language?
I don't know. If I knew, I wouldn't be throwing these things out as "this is
what we don't have yet." I think there's more to having multiple people
working on a code base than "don't clobber each others changes."
Stuff like the ability for me to know that my change hurt your code.
Something like unit testing, only built into the language, say.
> > 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.
To some extent, but why is that? Is it because we're missing something
fundamentally obvious in the programming paradigm? Clearly an OO library is
helpful when you have something that behaves like objects. But you try to
interface it to something that behaves like (say) SQL records, and you get
all kinds of ugly mismatches.
> But it appears to me that as far as libraries are concerned, OOP has
> been a tremendous success regarding code re-use.
Ehn, to some extent. How many of the libraries you use would work just as
well without OO, or with faked OO (like C's stdio fakes OO)?
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Well now, there are basically two ways to do documentation:
You already lost. If you're not documenting things that have no place in the
source code to put the documentation, you've already failed at documenting
your system.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Neeum Zawan wrote:
> Somehow, I thought you may be thinking of:
> http://en.wikipedia.org/wiki/Dynamic_programming
No. It's just that C++ uses a lot of terms in ways that aren't <twitch>
*right* <twitch> sometimes, so I wanted to make sure it didn't mean
something like "lots of templates" or some such when Warp used the term. :-)
--
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:
> Docman? Javadoc?
To clarify, I'm thinking maybe something more along the lines of the
BON<->Eiffel equivalence, where something that looks like UML can be turned
into source code and back again with the appropriate tool.
Something beyond the name of the function and the types of its arguments.
Plus, documentation that covers something besides the individual functions
to be called, that covers what you cannot for now deduce from the source
code itself.
I know javadoc (and similar) is supposed to cover that. In practice, it
gives you a place to write that stuff down, but does nothing to make it
useful to the author to do so. So documentation even of that type becomes a
cost rather than a benefit.
How many projects have you seen with the doxygen or javadoc or whatever have
either obvious cut-and-paste errors or no documentation beyond what you can
gleen from the source at all?
--
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:
> clipka wrote:
>> Docman? Javadoc?
>
> Were that helpful, it might fit the bill. :-) As it stands now, it
> seems more often an excuse to not write documentation than a tool for
> writing it.
That's not a problem of the tool, but the person using it. Those people
taking it as an excuse wouldn't do any docuentation at all otherwise,
unless forced at gunpoint.
As far as making life easier for people who do have the honest desire to
document properly, I think integrating the documentation with the source
code is a good way to go, and docman and javadoc make good tools for hem.
Then again, maybe it's the approach taken from the wrong side, and the
true proper way would be embedding the source code in the documentation,
not vice versa - if only for the psychological effect.
>> > To avoid security problems?
>> I guess this would require a proper definition of "security problems".
>
> Code doing things the author didn't want it to do because malicious
> people intentionally caused it to happen.
There's no general way around it, because malicious people of this type
are highly intelligent and inventive. Whatever you'd integrate into the
language itself would just give you a /false sense of/ security.
The only truly safe computer system would be an isolated computer locked
in a stainless steel safe, with the key thrown into the Atlantic, and
the safe sunk in the Pacific. Which would somewhat limit its usefulness
I guess :-P
The only thing you can do about it is /defensive/ programming - but
that's a paradigm you probably cannot support with language features I
guess. Well, maybe stuff designed for contract-oriented programming
would help with this.
> Stuff like the ability for me to know that my change hurt your code.
> Something like unit testing, only built into the language, say.
That seems to go into a similar direction as contract-oriented design.
>> But it appears to me that as far as libraries are concerned, OOP has
>> been a tremendous success regarding code re-use.
>
> Ehn, to some extent. How many of the libraries you use would work just
> as well without OO, or with faked OO (like C's stdio fakes OO)?
It's not a question of how well they would work - it's a question of how
easy they were to implement, and how easy they are to use.
Try implementing and using generic container classes in a non-OO language.
Then try to refactor your application to use a deque container instead
of a stack for a certain job. Or a tree-backed map instead of a
hash-table-backed one someplace else.
You won't have much success without implementing verbosely what OO
languages do for you behind the scenes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> That's not a problem of the tool, but the person using it. Those people
> taking it as an excuse wouldn't do any docuentation at all otherwise,
> unless forced at gunpoint.
Not necessarily. As I said elsewhere, a tool that would make the high-level
documentation generate source code (and where the changes to the source code
would be reflected in the HDL) would help. It would let people who are
designing the system document it as part of the progress forward.
The problem with writing code documentation is that it doesn't help the
coder. It only helps the people who come after. So it's seen as a waste
unless the coder understands the business reason for it.
Imagine something like TDD, except with documentation instead of tests.
Or imagine a block diagram with arrows showing data flow between the blocks,
where that's *actually* the code.
> As far as making life easier for people who do have the honest desire to
> document properly, I think integrating the documentation with the source
> code is a good way to go, and docman and javadoc make good tools for hem.
If you're documenting the *code*, yes. I'm wondering if it's also possible
to design a language that makes it easy to document the intention, the
architecture, etc as part of building the code. Tangle and weave, anyone?
> Then again, maybe it's the approach taken from the wrong side, and the
> true proper way would be embedding the source code in the documentation,
> not vice versa - if only for the psychological effect.
Yes, exactly something like this. We probably won't get there as long as
the primary form of source code is ascii strings.
> There's no general way around it, because malicious people of this type
> are highly intelligent and inventive. Whatever you'd integrate into the
> language itself would just give you a /false sense of/ security.
Hard to say. Certainly having a language with bounds checking is safer than
a language without bounds checking. How far can that go?
> The only thing you can do about it is /defensive/ programming - but
> that's a paradigm you probably cannot support with language features I
> guess. Well, maybe stuff designed for contract-oriented programming
> would help with this.
Yeah, that's the sort of thing I'm thinking. Or like the C part of ACID.
>> Stuff like the ability for me to know that my change hurt your code.
>> Something like unit testing, only built into the language, say.
>
> That seems to go into a similar direction as contract-oriented design.
To some extent, yes. That, or typestate analysis, or some such. I don't know
the answer. I just know it's a problem looking for a better answer.
> Try implementing and using generic container classes in a non-OO language.
> Then try to refactor your application to use a deque container instead
> of a stack for a certain job. Or a tree-backed map instead of a
> hash-table-backed one someplace else.
I can't imagine changing a queue to a stack without needing to rewrite a
fair amount of the code using that structure.
C++ seems to do pretty well, and its not using any OO for the STL. Python
and LISP also do pretty well without actually using the OO portions of the
language, as would Ada I think. Erlang (and Hermes) both handle this just
fine as well, and that's not OO. You just need good encapsulation, not
inheritance or dynamic binding or anything like that.
> You won't have much success without implementing verbosely what OO
> languages do for you behind the scenes.
Sure. OO is pretty good at data structures and GUIs. But what about other
libraries? What about math libraries, HTTP libraries, networking libraries,
databases, etc? None of those types of libraries tend to be designed for you
to subclass the instances.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Well now, there are basically two ways to do documentation:
>
> You already lost. If you're not documenting things that have no place in
> the source code to put the documentation, you've already failed at
> documenting your system.
That too.
I'm thinking about documenting a library API, but if you wrote an
application and want to write a user manual for it... the user isn't
going to give a damn about why you have to register a callback after
creating a button.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Method #2 suffers from the problem that there's so much chatter in the
>> source file that you can't actually find the executable code any more.
>> It makes small, simple modules look huge and complex.
>>
> My experience is that that's not the case.
>
> To the contrary: Breaking up the source code with commenting blocks
> helps give the code more structure, even if you don't change a single
> statement.
You'd *think* it would help, but in general it just gets in the way.
When you're trying to edit the documentation, there's all these lumps of
code in the way, and when you're trying to edit the code, there's chunks
of documentation in the way. (Plus, in Haskell in particular, the
documentation tends to be vastly longer than the code.)
> In any case I guess we agree that the problem of documentation needs to
> be addressed not by programming /languages/, but by programming
> /environments/.
Yeah, pretty much. (The documentation is usually comments, after all.
All languages support this.)
> I guess the ideal solution would be an IDE that is capable of managing
> hypertextual RTF documents alongside with code, highly integrated with
> the version management software, and for each change would ask: "What
> was the nature of your code change, Dave?" - being smart enough to
> identify which functions were actually changed, and also which ones
> might be affected indirectly.
Yeah, that sounds about right. Something like Google's SideWiki.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> > To avoid security problems?
>>> I guess this would require a proper definition of "security problems".
>>
>> Code doing things the author didn't want it to do because malicious
>> people intentionally caused it to happen.
>
> There's no general way around it, because malicious people of this type
> are highly intelligent and inventive. Whatever you'd integrate into the
> language itself would just give you a /false sense of/ security.
As far as I can tell, 98% of all security issues are buffer overruns -
trivially fixable, yet nobody seems to think it's necessary.
Then there are things like data tainting (which could be enforcible at
compile-time with no run-time overhead). Hell, in Haskell land, people
regularly attempt to write code which is *provably secure*. (But then,
you have to define "secure" first... It's easy to prevent buffer
overruns, but not so simple to prevent glitches where access denied
messages inadvertantly reveal information indirectly.)
>> Stuff like the ability for me to know that my change hurt your code.
>> Something like unit testing, only built into the language, say.
>
> That seems to go into a similar direction as contract-oriented design.
Yeah, that's a nice idea. Doesn't seem very popular though...
> Try implementing and using generic container classes in a non-OO language.
>
> Then try to refactor your application to use a deque container instead
> of a stack for a certain job. Or a tree-backed map instead of a
> hash-table-backed one someplace else.
>
> You won't have much success without implementing verbosely what OO
> languages do for you behind the scenes.
Tried using Haskell recently? Haskell is not OO.
Sure, you need encapsulation, and you need polymorphism. You also need
dynamic binding *if* you want to change your mind about which data
structure you're going to use *at run-time*. But you don't necessarily
need implementation inheritance, or mutable state for that matter...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Aren't computers supposed to "program themselves" by now? Anyone
>> remember that one?
>
> Well, in a way they do: Think about code optimization.
>
> The only illusion was about the level of abstraction that could be
> obtained. I guess the problem there is that natural human language is
> ill-suited for specifying even the problem to be solved with a computer
> program (let alone the algorithm to solve it): As soon as precision is
> required (and with computers that's obviously the case), it quickly gets
> overly verbose and cumbersome (every scientific paper gives testimony of
> this fact).
I think what happened is that somebody invented Prolog, and it makes it
almost seem like the computer is "thinking". It lets the computer solve
logical problems as if by magic (i.e., it doesn't look like a regular
algorithm, it looks like real insight). And people thought that in a few
years' time, somebody would come up with a set of predicates to describe
the operation of a computer program, you'd put in a mathematical
description of what the program is supposed to do, and Prolog would
magically compute the most efficient sequence of machine instructions...
...which would just mean writing programs as mathematical statements
rather than lists of instructions. It would just be another programming
language. And, you know, people have argued that programming in Haskell
is like programming with mathematics, so...
[One might also mention Mathematica.]
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 a écrit :
> mathematical description of what the program is supposed to do
Ahahah. even the simple "description of what the program is supposed to
do" is usually a long painful phase between the requester and the
programmer.
Users do not know what they want. When they do, they usualy fail to
express it. And should it happened, there would be some misunderstanding
at some stage.
Remember, the "What" is not only the purpose, but also often the how.
and the devil is in the details.
"I want a raytracer..." is not a specification. Too ambiguous.
I want the program to output "Hello, world!", now, that's enough.
And for the nice one: "I want a proof of the Fermat..."
--
A: Because it messes up the order in which people normally read text.<br/>
Q: Why is it such a bad thing?<br/>
A: Top-posting.<br/>
Q: What is the most annoying thing on usenet and in e-mail?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
>>> Well now, there are basically two ways to do documentation:
>>
>> You already lost. If you're not documenting things that have no place
>> in the source code to put the documentation, you've already failed at
>> documenting your system.
>
> That too.
>
> I'm thinking about documenting a library API,
It's fine for the details. But try to document (say) the BSD interface to
TCP by documenting only the listen(), accept(), bind(), and connect() calls.
Without understanding what an IP address is, or a socket, or how DNS works,
etc you're still not going to win.
Or take something like a big windowing system, or a 3D graphics system, or a
physics library, and try to document *just* the routines without documenting
the architecture of the system. You'll spend three days trying to find out
where to start reading the documentation.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> As far as I can tell, 98% of all security issues are buffer overruns -
> trivially fixable, yet nobody seems to think it's necessary.
The three biggest are buffer overruns, SQL injection, and XSS injection.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
