Realistically, I think Godel's Incompleteness Theorem implies that there can be
no 'last' programming language (formal system).
But I think it is possible for a fundamentally different paradigm make a huge
leap in our ability to build complex systems. My thinking from a couple of
years back:
ific problems with things like recursion
and typing problems. But, I've always thought that it was an alternative worth
considering.
Paul.
>
>From: BGB
>To: Fundamentals of New Computing
>Sent: Monday, July 18, 2011 2:14:55 PM
>Subject: Re:
erger wrote:
>> Even if it were possible to have a last language, it would be double plus
>> ungood.
>>
>> On Mon, Jul 18, 2011 at 8:58 AM, Paul Homer<[1]paul_ho...@yahoo.ca>
>> wrote:
>>
>> Realistically, I think Godel's Incomp
There is nothing simple about simplification :-)
In '07 I penned a few thoughts about it too:
http://theprogrammersparadox.blogspot.com/2007/12/nature-of-simple.html
Paul.
>
>From: David Barbour
>To: Fundamentals of New Computing
>Sent: Thursday, July 28, 2
I've always suspected that it comes from the ability to see around corners,
which appears to be a rare ability. If someone keeps seeing things that other
people say aren't there, eventually it will drive them a little crazy :-)
An amazing example of this (I think) is contained in this video:
ht
I see something deeper in what Zed is saying.
My first really strong experiences with programming came from the
data-structures world in the late 80s at the University of Waterloo. There was
an implicit view that one could decompose all problems into data-structures
(and a few algorithms and a
to it.
Eventually all that conquering needs to be conquered itself ...
Paul.
>
> From: Loup Vaillant
>To: fonc@vpri.org
>Sent: Friday, June 15, 2012 1:54:04 PM
>Subject: Re: [fonc] The Web Will Die When OOP Dies
>
>Paul Homer wrote:
>> It
que? One could argue that this sort of hand adding of columns of
>numbers is also dated. Let's don't go there I am just using this as an example
>of going back and looking at a beginning that is hard to see because it is
>"just too darn fundamental".
>
>
>
This discussion has inspired me to try once again to express my sense of what I
mean by complexity. It's probably too rambly for most people, but some may find
it interesting:
http://theprogrammersparadox.blogspot.ca/2012/06/what-is-complexity.html
Paul.
>
>
It always seems to be that each new generation of programmers goes straight for
the low-hanging fruit, ignoring that most of it has already been solved many
times over. Meanwhile the real problems remain. There has been progress, but
over the couple of decades I've been working, I've always felt
slightly different). With that type of man-power
directed, some pretty cool things could be created.
Paul.
>
> From: BGB
>To: fonc@vpri.org
>Sent: Tuesday, October 2, 2012 5:48:14 PM
>Subject: Re: [fonc] How it is
>
>
>On 10/2/201
es, and if they were shared are intrinsically reusable
(and recombination).
So I'd basically go backwards :-) No higher abstractions and bigger pieces, but
rather a sea of very little ones. It would be fun to try :-)
Paul.
>____
> From: Loup Vaillant
&
nd
less (as we get closer to 'everything'). My sense of the industry right now is
that pretty much every year (factoring in the economy and the waxing or waning
of the popularity of programming) we write more code than the year before. Thus
we are only starting :-)
Paul.
>__
2012 4:01:36 PM
>Subject: Re: [fonc] How it is
>
>
>Paul,
>
>This sounds a little like Linda and TupleSpaces... what was that you were
>saying about re-inventing the wheel over and over?
>
>
>LOL...
>
>
>Alan Moore
>
>
>
>
>
>
>
&
xt or you don't) mostly because the linkage
between the user and data is under control of just one single (distributed)
program.
Paul.
>
> From: David Barbour
>To: Paul Homer ; Fundamentals of New Computing
>
>Sent: Wednesday, October 3,
_____
> From: David Barbour
>To: Paul Homer ; Fundamentals of New Computing
>
>Sent: Wednesday, October 3, 2012 7:10:53 PM
>Subject: Re: [fonc] How it is
>
>
>Distilling what you just said to its essence:
> * humans develop miniature dataflows
>
the edges. These days I'm busy paying off the mortgage,
writing, playing with math, traveling (not enough) and generally trying to keep
my very old house (1904) from falling down, so it's unlikely that I'll get a
chance to play around here in the near (<100 years) future.
Paul.
cases
there are ways to migrate 'things' from one side to other (which no doubt has
some deeper ramifications).
Paul.
>
> From: Kurt Stephens
>To: fonc@vpri.org
>Sent: Tuesday, October 30, 2012 2:03:23 PM
>Subject: Re: [fonc]
My take is that crafting software is essentially creating a formal system. No
doubt there is some clean, normalized way to construct each one, but given that
the work is being done by humans, a large number of less than optimal elements
find their way into the system. Since everyone is basically
I don't think a more formalized language really gets around the problem. If
that were true, we'd have already fallen back to the most consistent, yet
simple languages available, such as assembler. But on top of these we build
significantly more complex systems, bent by our own internal variation
Most programs are models of our irrational world. Reflections of rather
informal systems that are inherently ambiguous and contradictory, just like our
species. Nothing short of 'intelligence' could validate that those
types of rules match their intended usage in the real world. If we don't
bui
My thinking has been going the other way for some time now. I see the problem
as the need to build bigger systems than any individual can currently imagine.
The real value from computers isn't just collecting the input from a single
person, but rather 'combining' the inputs from huge groups of p
Hi Alan,
I can't predict what will come, but I definitely have a sense of where I think
we should go. Collectively as a species, we know a great deal, but individually
people still make important choices based on too little knowledge.
In a very abstract sense 'intelligence' is just a more dyn
that show how often even scientists go against their
> training and knowledge in their decisions, and are driven more by desire and
> environment than they realize. More knowledge is not the answer here -- but
> it's possible that very different kinds of training could h
e that looks at the system implications of
> local human desires and actions.
>
> Etc.
>
> I'm guessing that without a lot of training, most humans would not choose to
> use a real "thinking augmenter".
>
> Best wishes,
>
> Alan
>
> From: Paul H
ure you are aware that yours is a very "Engelbartian" point of view,
>> and I think there is still much value in trying to make things better in
>> this direction.
>>
>> However, it's also worth noting the studies over the last 40 years (and
>> especia
26 matches
Mail list logo
