From: Samantha Atkins (samantha@objectent.com)
Date: Sun Mar 31 2002 - 02:13:26 MST
Mike Linksvayer wrote:
> OTOH I know a number of good brains that have gone back to school, taken
> up working on their own projects and/or traveling. These sorts of
Great if you can afford it. Many of us can't.
> things cause financial stress, but in the long run may better serve
> creativity and innovation than a longer run at theoretically innovative
> startups rapidly morphing into overweight bureaucracies dominated by
> politics.
>
I doubt it but time will tell.
> I wrote:
>
>>>I guess one can quibble over what constitutes a significant advance or
>>>claim that nothing's new under the sun, but what about (in no particular
>>>order)
>>>
>
> [...]
>
>>>* easy internationalization and accessibility
>>>
>>Not relevant to the problem.
>>
>
> It helps indirectly, by sparing cycles otherwise spent on these problems
> and by increasing the number of people who can effectively use
> computers, some of whom should be brilliant programmers. The
> accessibility bit may even be useful for humans with augmented/altered
> senses and motor devices.
>
>
>>>I consider adoption and robust implementation highly relevant, even if
>>>the ideas are decades old. None of the above have run their course
>>>IMO. I look forward to another decade of improvements (though with a
>>>half-empty perspective, one may be looking at a decade of stagnation)
>>>
>>Not one of the things listed address better automation of the
>>software process itself and radically better toools and
>>techniques in programmers hands.
>>
>
> All of your critiques were insightful, but I think overly discount the
> bright side: sure nothing I mentioned is new, but widespread
> understanding and adoption is, and in my (again, rather limited)
> experience each accrues productivity gains and frees one to concentrate
> on higher level solutions that are just as hard as the lower level ones
> we don't have to recreate. I would hate to go back to even 1995.
>
As a long term working software engineer I quite honestly have
not seen much widespread understand and adoption of even very
old technology. Nor have I seen much freeing to concentrate on
higher level solutions. Due to a paucity of automation of our
own activities, much of practical software engineering is still
rather laborious and low-level. I am deeply unhappy with this
situation and will do what I can to improve it.
Personally I would happily go back to around 1995 or earlier to
attempt to change some wrong or less than optimal directions
taken by myself and the software industry. But hindsight is
20-20. We just should not congratulate ourselves on where we
are today. It is not that significantly better than 1995 or
even 1985 for that matter. Things I understood then are even
today understood by only a relatively few and are not in
practice. Also many things I saw as software weaknesses and
possible long-term problems are now commonplace and magnified
far beyond what I dreamed could occur then. But like many of us
I had a family to support, bills to pay and was busy "making a
living". And, to tell the truth, I was too much into building
real systems to stay too much more theoretical or academic.
Sometimes I feel guilty for not finding a way to push harder
earlier and especially for being largely out of the loop from
around 1991-1995 due to personal life complications.
>
>>Intentional programming is extremely interesting to me. In the
>>meantime a great deal could be done to reverse-engineer and
>>refactor existing code (providing much more useable information
>>about the codebase as a side-effect!) and to enable much higher
>>levels of reuse and use of design patterns. But creating a
>>viable tools company was very difficult before the meltdown. It
>>is even more so now. So it is likely these developments, if
>>they happen, will come through volunteer efforts as Open Source.
>>
>
> I certainly wouldn't want to start a tools company now, or perhaps in
> the last decade. Most of the world is wedded to Microsoft's tools
> (there's a tools company, much as I dislike them) and much of the rest
> demands libre tools. Perhaps one can have it both ways: create
> radically better open source tools, and form the next Cygnus Solutions
> around them. Collab.net's <http://tigris.org> is the closest I can
> think of to this right now. The Free Software Business mailing list is
> a good place to pick at these sort of ideas.
>
>
Most of the world is not wedded to Microsoft tools. They have
only the lion's share of the desktop application environment.
They do not have the majority of the App Server market, web
server market, large server market or embedded market. Most of
the major languages in use are not Microsoft invented or
controlled.
Collab.net is a company I am increasingly interested in.
>>The stack is getting much broader but it is not getting
>>significantly "deeper" or better organized for excellent use.
>>The very structure of many software companies and of software
>>patents and other encumbrances precludes much reuse of prior
>>efforts. A lot is re-invented over and over again by working
>>software engineers. Relatively little is reused even within
>>companies much less across them.
>>
>
> Certainly just as much code is rewritten as ever, even within companies,
> but if you consider the broad and occasionally deep libraries that are
> now available for any popular environment you've got massive code reuse
> happening.
>
Which do you have in mind? The Java libraries? They cover a
fair amount but I wouldn't consider them deep or
well-implemented overall. Their IO library is particularly
odious. Good libraries have been around for particular
languages and environments for some time. Making these language
and environment agnostic has been largely dreamed of but too
seldom acheived. Many useful components also exist deeply
ensnared within various applications, often redundantly so.
Admittedly .NET is a step toward this as are COM, CORBA and ILU.
A big problem on reuse is simply knowing what is available and
what its requirements and characteristics are in sufficient
detail to use it or extend it. It would especially be useful if
this was known programmatically. But such categorization of
algorithms, functions, classes, methods and components is a
science unto itself and one not yet mastered much less widely
implemented.
In the meantime we take a lot of relatively inflexible weak
languages as the current manna from heaven along with an
over-hyped app server framework or two and ignore many of the
most significant problems.
Perhaps you have to be in the midst of this world for some time
to see what I have seen. Many who have come into the field more
recently don't know a lot about what went before, the problems
already identified and solutions that the commerical software
industry has largely forgotten or never taken out of the lab.
> I understand that to you, a world class programmer with 20 years
> experience who has worked with or independently discovered everything I
> listed long ago, the software world may well appear stagnant. To me,
> lots of cool things are happening. Software sucks in general and tools
> in particular, though IMO a good deal of it "sucks less". Is the pace
> enough to get us to the point where a seed AI can be built in time to
> bootstrap a singularity in the current consensus (2020?) timeframe? I
> don't have any insight on that question, and perhaps that's one reason
> I'm not counting on a singularity.
>
I believe we have a LOT of work ahead of us if a singularity is
to occur at all for this species much less by 2020. And I think
that software challenges are central to a quite a bit of what is
needed. Part of that could be my own over-specialized eyes of
course.
> What tools/methodologies do people think will be necessary to facilitate
> seed AI engineering? If you had funding to hire 10 brilliant people for
> the next several years, what tools would you create?
First of all, I would choose the most powerful language to date
for AI and for creating new languages and tools, Lisp. It is an
ancient tongue but one full of power. In any event highly
reflective language and coding environment is an absolute must
for self-evolving software and for high human programmer
productivity. Software library technology needs to be further
developed and automated. Distributed and persistent objects,
procedures and data must be as seamlessly incorporated as
possible and practical. Intefaces to data storage and
intercommunication facilities in a uniform manner with fairly
uniform adaptors to higher level constructs and different client
languages would be very helpful. Some means to make use of code
already existent in other languages must be developed and
deployed that is far more natural than COM/CORBA/RMI. A
low-level language undergirthing all higher level languages is
workable (as in .NET) if (unlike in .NET) it is flexible enough
to support all useful fundamental software constructs known to
date with room to expand in the future. I would build tools
that automate as much of the detail as is practical without
losing understanding of the implementation characteristics.
Excellent debuggers and profilers are a must. Incorporation of
design methodology tools and the development of much more
powerful and broad tools would help quite a bit. These tools
should be ubiquously available without paying through the nose.
Tools to reverse-engineer existing code and analyze it would
be very useful. The industry could use some new ways to view
and understand software systems, perhaps through graphical and
other sensory representations. In any case better
human-computer interfaces and more augmentation of human
thinking, creativity and communication would help tremendously.
If I was running things :-) I would funnel some energy into new
types of operating systems like the one I heard of that has a
kernel (Synthesis Kernel - Massalin 1988) that performs run-time
code synthesis, fine grain scheduling and lock free optimistic
synchronization, Also I think we have upcoming challenges in
fine-grain concurrency that we had best get busy designing
effective languages and operating systems for now.
For creating an SI much deep thinking about mental modes and
modules and better empirical knowledge about how the human mind
works is of course also essential. But all of the above wish
list will be useful on the way to SI, for dealing with our
existing software needs and for the SI to build upon.
>
> I'd focus on security, but that's just because I'm pain averse, and I
> find the thought of an AI/upload world with today's security stack
> incredibly scary. But I don't know that security that sucks less gets
> us closer to a singularity. Perhaps closer to a desirable signularity
> (mispeling unintended, but I'm glad I noticed it).
>
It probably depends on what you do and do not mean by security.
Capability based security is pretty much required to get much
beyond today's software mess.
- samantha
This archive was generated by hypermail 2.1.5 : Sat Nov 02 2002 - 09:13:10 MST