On Tue, May 29, 2012 at 11:56:47AM -0400, Tedd Sperling wrote:

> On May 29, 2012, at 10:20 AM, Stuart Dallas wrote:
> 
> > -snip- Besides, truth is subjective, but then so is everything,
> > including that assertion.
> > 
> > -Stuart
> 
> You reply was longer than my monitor was high so I can't give an
> immediate reply -- I have to scroll. :-)
> 
> However, with that said, you made good points and I don't disagree
> with any of them.
> 
> As for me, I was speaking from my experience where the size of my
> functions over the last few decades has grown (up to a point) with my
> increasing monitor size. However, my eyesight has not improved and
> thus should be figured into this somehow.
> 
> As I said before, mine is just an observation that supports the limits
> in reception/comprehension articles I have read.
> 
> I think your 24 line terminal vs the 30" monitor argument is a valid
> one, up to a point. But I think the problems (if any) would depend
> upon many factors -- too numerous to elaborate here.
> 
> But let me pose an idea. 
> 
> When I was in college, my degrees were in Geology. My Summer Field
> study (6 weeks) was to map out Geologic outcrops on a USGS topographic
> map. At the end of the study, all maps that matched the Professors'
> maps, were given the highest grades (mine the highest in all modesty).
> Not because they were alike, but because they approached the "truth"
> of the matter. The truth here was not subjective for there was only
> ONE defining truth and that could be discovered by detailed mapping.
> We all (including the Professors) approached the same problem in the
> same way and reached similar results. The closer to the truth, the
> more similar the maps.
> 
> Over the years I've seen programming languages converge producing
> single solutions for common tasks, such as a FOR loop and IF
> statements. These seem to be universal constructs in programming
> logic. So my question is, as in my Geology study "Is this convergence
> in programming logic discovering the truth of the task?" Do you see
> what I mean?
> 
> If so, then maybe the way we break down problems into smaller subsets
> might also be approaching an optimum method as well. I used to use
> (30+ years ago): 1) Input; 2) Calculation; 3) Display; as the main
> categories in my division logic to tackle problems and that was long
> before I heard of MVC.
> 
> So, what I am saying is that we might all be approaching and
> contributing to an overall optimal logical solution in programming.
> Kind of an ant-colony think sort of thing. The solution is certainly
> not simple, but it might be an universally single solution to all the
> problems we perceive.
> 
> Said only for "Food for thought".

About 30 years ago, a guy wrote an essay about "architectural
stablization" or somesuch. He was a computer guy who had written a whole
office suite for 8 bit computers (called Valdocs, written for the Epson
QX-10 computer, for you voracious learners). His point was that this
phenomena was recognizable in many fields involving technology. For
example, the architecture of automobiles eventually stabilized in such a
way that these days, they pretty much all have steering wheels used for
steering, four wheels, two headlights, etc. I think "mainstream"
programming languages have probably done a lot of stabilization over the
years. You do occasionally find weird languages like Lisp/Scheme, but in
the main, most languages bear strong resemblance to C and Fortran.
They're geared for slightly different environments or purposes, but
syntactically, they bear strong resemblance to each other, compared to,
say, APL or Lisp/Scheme. And to some extent they model how most people
(programmers) would naturally approach the solution of programming
problems.

(Of course, there are always the oddballs like me who still prefer
reverse polish notation on our calculators. Go figure.)

Paul

-- 
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to