C++ Community News Forum - John Ousterhout on What Limits Software Growth

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

C++ Community News Forum
John Ousterhout on What Limits Software Growth

26 replies on 2 pages. Most recent reply: Oct 8, 2006 9:56 AM by Cleo Saulnier

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 26 replies on 2 pages [ « | 1 2 ]

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: John Ousterhout on What Limits Software Growth

Posted: Sep 25, 2006 10:49 AM

> But to get back on topic, the software bottleneck is due
> to the way software and programming is delivered, not
> about programming languages.

I definitely agree it's not about programming languages. I'm not even sure it's that much about technology. If you work with poorly defined requirements that keep changing, if you have tight deadlines such that you can't think of the design and its implications, then you can hardly produce a good system. Technology can't help you much. Of course, when FORTRAN came out in 1956 it was a big step forward from assembler, because FORTRAN captured the most common "patterns" that occured in programming. Subsequent languages captured some additional design constructs (like routines and later objects) which came out from practical observations. But beyond that the variety of how things can be done gets too great and projects are too big, so it becomes more of an organizational rather than technological issue. Nevertheless, there were many successful large projects built using conventional languages and technologies (C++ for example); maybe we should learn from those.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: John Ousterhout on What Limits Software Growth

Posted: Sep 26, 2006 2:07 AM

> I definitely agree it's not about programming languages.
> I'm not even sure it's that much about technology. If you
> work with poorly defined requirements that keep changing,
> if you have tight deadlines such that you can't think of
> the design and its implications, then you can hardly
> produce a good system. Technology can't help you much. Of
> course, when FORTRAN came out in 1956 it was a big step
> forward from assembler, because FORTRAN captured the most
> common "patterns" that occured in programming. Subsequent
> languages captured some additional design constructs (like
> routines and later objects) which came out from practical
> observations. But beyond that the variety of how things
> can be done gets too great and projects are too big, so it
> becomes more of an organizational rather than
> technological issue. Nevertheless, there were many
> successful large projects built using conventional
> languages and technologies (C++ for example); maybe we
> should learn from those.

Basically any big project can be easily tackled if it is properly decomposed and each part handled accordingly. That's why the distributed transactional auto-persistent information/programming system I described earlier is much more efficient than the monolithic static blind systems we have today: it allows the incremental development of software, piece by piece, shortening both development and testing time as well as allowing evolution in a much better way.

Most of the big problems we have to tackle are really lots of small problems (sometimes quite a lot!)...systems that are very very big and very very complex so as that there are almost irreducibly complex are very rare; personally I have never heard of such a system.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: John Ousterhout on What Limits Software Growth

Posted: Sep 26, 2006 6:50 AM

Right at this moment the Artima front page contains several articles that concern the same problem:

1) grid computing: distributed processing; a distributed information system.
2) Spring validation framework: data validation in a web framework for a distributed information system.
3) the Java content repository API: a distributed information system (the content repository).
4) the ULCXML Project: thin GUI client using XML over a network.
5) problems with JAAS authentication integration with J2EE: two systems can't talk to each other very easily, requiring an endless amount of hacking, again in the context of a distributed environment.

To me, the above reads:

1) I want to spread my computation over other computers, but there isn't a simple way to do it.
2) I want to validate the data input by some client elsewhere on the server, but there isn't a simple way to do it.
3) I want to provide content and information shared on a computer accessible by clients elsewhere (but there isn't a simple way to do it).
4) the GUI of my application is distributed, but there is not an easy way to program it.
5) I want to mix two things I did not anticipate I would need to mix them, and I have to perform a series of hacks to achieve it, because there is not a simple way to do it!

So, there, in front of you, is the bottleneck the original post speaks about. Instead of actually doing new and wonderful things with our distributed information systems, we fight against monolithic monsters.

Sooner or later the need for a distributed system will arise. The future is distributed processing, with CPUs like the CELL being everywhere: in desks, in devices, in walls, in game machines etc. The first one to actually make such an operating system wins. I would have expected Microsoft to do something like this, and they certainly have thought about that (their research department has some similar ideas), but there is nothing concrete over the horizon.

Cleo Saulnier

Posts: 77
Nickname: vorlath
Registered: Dec, 2005

Re: John Ousterhout on What Limits Software Growth

Posted: Sep 26, 2006 1:36 PM

Say I have 3 computers on the Internet (A,B,C). The source data is on A, the processing software is on B and the output is used by C. What's the easiest way to get this done? Send the data from A to B to C, right? Now compare this to the way functions work. Every call must return. So you would send from A to B back to A and finally out to C. The function paradigm should die a horrible death. It has HUGE overhead and is not prone to reuse. Unfortunately, almost everything is written with functions.

It reminds me of a scenario where you have the choice to go down two roads. Down one road, you see a city with lots of people and a great deal of enthusiasm. The other road goes on what seems forever with nothing in sight. So we go to the city and have tons of fun. But there is nothing else here. The other road leads to a port that has the world in its palm, but we're scared to leave behind all this stuff we've built on the other road. Functions are nice and all, but they will lead to the doom of the computing industry if we don't leave it behind.

Replace it with something data centric and you have a winning solution. Other than functions, I agree with most of what Achilleas says and I'm glad to see more people at least starting to see the truth of the situation.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: John Ousterhout on What Limits Software Growth

Posted: Sep 26, 2006 1:55 PM

> Say I have 3 computers on the Internet (A,B,C). The
> source data is on A, the processing software is on B and
> the output is used by C. What's the easiest way to get
> this done? Send the data from A to B to C, right? Now
> compare this to the way functions work. Every call must
> return. So you would send from A to B back to A and
> finally out to C. The function paradigm should die a
> horrible death. It has HUGE overhead and is not prone to
> reuse. Unfortunately, almost everything is written with
> functions.
>
> It reminds me of a scenario where you have the choice to
> go down two roads. Down one road, you see a city with
> lots of people and a great deal of enthusiasm. The other
> road goes on what seems forever with nothing in sight. So
> we go to the city and have tons of fun. But there is
> nothing else here. The other road leads to a port that
> has the world in its palm, but we're scared to leave
> behind all this stuff we've built on the other road.
> Functions are nice and all, but they will lead to the
> e doom of the computing industry if we don't leave it
> behind.
>
> Replace it with something data centric and you have a
> winning solution. Other than functions, I agree with most
> of what Achilleas says and I'm glad to see more people at
> least starting to see the truth of the situation.

Well, I agree with you, but functions are not a bad abstraction. Recently there has been 'noise' around the internet about Google's distributed MapReduce implementation which allows Google to scale to tens of thousands of machines...

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: John Ousterhout on What Limits Software Growth

Posted: Sep 26, 2006 3:23 PM

> Replace it with something data centric and you have a
> winning solution. Other than functions, I agree with most
> of what Achilleas says and I'm glad to see more people at
> least starting to see the truth of the situation.

First of all, what is the evidence that _something_ data centric would be a winning solution? Are there any experiments that would indicate that this would be the case? Is there any practical experience that demonstrates it? Also, what would this data-centric solution look like? In science we use math to explain our observations. In software we can't use math to show that one solution is better than another - we must use and learn from our experience. So proposing something and believing that it is right without any practical evidence just doesn't make sense to me. Even when OOP was introduced in Simula it was used to solve a particular type of problem (in simulation) and the approach was shown to be effective. Nobody said "... we believe this is how software should be developed, so here's a new language!". Still, lots of inadequacies were discovered about OOP later on, just like they were discovered with structural and functional programming. All these styles were very exciting when they came out.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: John Ousterhout on What Limits Software Growth

Posted: Sep 27, 2006 5:50 AM

> First of all, what is the evidence that _something_ data
> centric would be a winning solution? Are there any
> experiments that would indicate that this would be the
> case? Is there any practical experience that demonstrates
> it? Also, what would this data-centric solution look like?
> In science we use math to explain our observations. In
> software we can't use math to show that one solution is
> better than another - we must use and learn from our
> experience. So proposing something and believing that it
> is right without any practical evidence just doesn't make
> sense to me. Even when OOP was introduced in Simula it was
> used to solve a particular type of problem (in simulation)
> and the approach was shown to be effective. Nobody said
> "... we believe this is how software should be developed,
> so here's a new language!". Still, lots of inadequacies
> were discovered about OOP later on, just like they were
> discovered with structural and functional programming. All
> these styles were very exciting when they came out.

The problem lies not in programming languages, but in the way operating systems are structured. The artificial division between processes/drivers/libraries/files does more harm than good.

I agree with you that these assertions are difficult to back up, especially when there is not a clear way (i.e. mathematics) to express them. I speak from experience: every application I had to write was mostly about the data.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: John Ousterhout on What Limits Software Growth

Posted: Sep 28, 2006 2:17 AM

Other people have reached the same conclusion as well:

http://it.slashdot.org/comments.pl?sid=197975&cid=16221645

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: John Ousterhout on What Limits Software Growth

Posted: Sep 28, 2006 10:38 AM

> Other people have reached the same conclusion as well:
>
> http://it.slashdot.org/comments.pl?sid=197975&cid=16221645

Yeah, I saw it, but I still think there should be more concrete experiments before we try to reach any conclusions on a programming model.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: John Ousterhout on What Limits Software Growth

Posted: Sep 29, 2006 3:12 AM

> Yeah, I saw it, but I still think there should be more
> concrete experiments before we try to reach any
> conclusions on a programming model.

Agreed, but I do not hold my breath. Big companies like Microsoft and Sun are interested more in selling than advancing the state of the art, the open source world is busy re-implementing commercial software and academics are stuck on the lambda calculus.

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: John Ousterhout on What Limits Software Growth

Posted: Sep 29, 2006 7:07 AM

> > Yeah, I saw it, but I still think there should be more
> > concrete experiments before we try to reach any
> > conclusions on a programming model.
>
> Agreed, but I do not hold my breath. Big companies like
> Microsoft and Sun are interested more in selling than
> advancing the state of the art, the open source world is
> busy re-implementing commercial software and academics are
> stuck on the lambda calculus.

Very true!

Cleo Saulnier

Posts: 77
Nickname: vorlath
Registered: Dec, 2005

Re: John Ousterhout on What Limits Software Growth

Posted: Oct 8, 2006 9:56 AM

> Well, I agree with you, but functions are not a bad
> abstraction. Recently there has been 'noise' around the
> internet about Google's distributed MapReduce
> implementation which allows Google to scale to tens of
> thousands of machines...

MapReduce is a data flow construct, not functional. That's why it scales.

Flat View: This topic has 26 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic