Taking Software the net Evolutionary Jump

jeff

Mon Jan 22 12:34:40 -0800 2007

manage

hmm, "tool development"... "generic tools"... sounds a bit like, i dunno,... Unix?  (damn, all these years i've been programming unintentionally)

Simonyi story about "going meta"

Beryllium Sphere(r)

Mon Jan 22 13:07:50 -0800 2007

manage

He wanted to build a WYSIWUG word processor and was in a research environment where it was against the rules to do anything tnat applied or that mundane.

So he jumped up a level of abstraction and pitched a study of programer productivity, which of course required something for the programmers to produce, so he set them a task to build a complete application.

Taking Software the next Evolutionary Jump

Richard Young

Mon Jan 22 14:24:51 -0800 2007

manage

Speaking from a architectural standpoint, I think that this has merit.
There are only so many ways to skin the same cat.

Why can't a high level object be abstracted?  If the project determines that it requires a web site, then the web site could be an object in itself.  A AJAX feed to a web page could be added to this object in the same way that you would add a array item to a set within Smalltalk.

I guess what I am trying to say, is that it would be very interesting to be able to directly create software from a higher level view, whereby the model is agreed between the technologists and the business group/unit you are dealing with.  Do we really need to constantly re-invent the wheel?  Smart lower level programmers could create the building blocks to achieve this with best practice methods in mind.

Gives me goosebumps....

Taking Software the next Evolutionary Jump

Chuck Burgess

Tue Jan 23 06:40:27 -0800 2007

manage

Sounds a lot like Ruby on Rails to me...  take the combined wisdom of many programmers over a period of time to choose an underlying architecture (MVC for web-fronted, database-backed webapps), construct the scaffolding that does all that underlying-level work, and let the "programmer" think, design, and program at the higher level.

Seems like this cycle with programming languages will always be such a cycle.  Once the combined wisdom acquired over time when programming applications in C/C++ grew to show some "best practices for this kind of final product, best practices for that kind of final product", newer languages came along to help abstract the lower-level work being done in C/C++. 

The Java JVM and .NET CLR concepts seem to me like abtraction level steps also, though at a lower level than the Ruby on Rail abstraction step.  Still, the key to moving up the abstraction scale is creating the usable puzzle pieces at the lower level, so that the programmer can choose the pieces he needs rather than building those pieces.

I think that as long as programmers collectively learn best practices for certain tasks on a given languages' level, then frameworks will spring up to represent the different best practices, and eventually the additional collective wisdom from using those frameworks results in the creation of a new language platform that moves the programmer above that framework level.  Again, that's my impression of what Ruby on Rails is doing for webapps.

In the end, though, I think it requires a period of time (several years at least) of large scale use to generate that collective wisdom before any successful abstraction breakthroughs occur.  Perhaps there has been enough collective wisdom built over the last decade or more regarding office software, to where its pieces can find their way up an abstraction level.

Taking Software the next Evolutionary Jump

duhavid

Thu Jan 25 13:20:10 -0800 2007

manage

Google "case tools".  This idea ( a good one ) has been around for a *long long* time.

I hope he succeeds, but I expect he will come up with yet another case tool.