Re: [fonc] The Web Will Die When OOP Dies
On 6/14/2012 10:19 PM, John Zabroski wrote: Folks, Arguing technical details here misses the point. For example, a different conversation can be started by asking Why does my web hosting provider say I need an FTP client? Already technology is way too much in my face and I hate seeing programmers blame their tools rather than their misunderstanding of people. Start by asking yourself how would you build these needs from scratch to bootstrap something like the Internet. What would a web browser look like if the user didnt need a seperate program to put data somewhere on their web server and could just use one uniform mexhanism? Note I am not getting into nice to have features like resumption of paused uploads due to weak or episodic connectivity, because that too is basically a technical problem -- and it is not regarded as academically difficult either. I am simply taking one example of how users are forced to work today and asking why not something less technical. All I want to do is upload a file and yet I have all these knobs to tune and things to install and none of it takes my work context into consideration. idle thoughts: there is Windows Explorer, which can access FTP; would be better if it actually remembered login info, had automatic logic, and could automatically resume uploads, ... but, the interface is nice, as an FTP server looks much like a directory, ... also, at least in the past, pretty much everything *was* IE: could put HTML on the desktop, in directories (directory as webpage), ... but most of this went away AFAICT (then again, not really like IE is good). maybe, otherwise, the internet would look like local applications or similar. they can sit on desktop, and maybe they launch windows. IMHO, I don't as much like tabs, as long ago Windows basically introduced its own form of tabs: the Windows taskbar. soon enough, it added another nifty feature: it lumped various instances of the same program into popup menus. meanwhile, browser tabs are like Win95 all over again, with the thing likely to experience severe lag whenever more than a few pages are open (and often have responsiveness and latency issues). better maybe if more of the app ran on the client, and if people would use more asynchronous messages (rather than request/response). ... so, then, webpages could have a look and feel more like normal apps. Why do I pay even $4 a month for such crappy service? On Jun 11, 2012 8:17 AM, Tony Garnock-Jones tonygarnockjo...@gmail.com mailto:tonygarnockjo...@gmail.com wrote: On 9 June 2012 22:06, Toby Schachman t...@alum.mit.edu mailto:t...@alum.mit.edu wrote: Message passing does not necessitate a conceptual dependence on request-response communication. Yet most code I see in the wild uses this pattern. Sapir-Whorf strikes again? ;-) I rarely see an OO program where there is a community of objects who are all sending messages to each other and it's conceptually ambiguous which object is in control of the overall system's behavior. Perhaps you're not taking into account programs that use the observer/observable pattern? As a specific example, all the uses of the dependents protocols (e.g. #changed:, #update:) in Smalltalk are just this. In my Squeak image, there are some 50 implementors of #update: and some 500 senders of #changed:. In that same image, there is also protocol for events on class Object, as well as an instance of Announcements loaded. So I think what you describe really might be quite common in OO /systems/, rather than discrete programs. All three of these aspects of my Squeak image - the dependents protocols, triggering of events, and Announcements - are encodings of simple asynchronous messaging, built using the traditional request-reply-error conversational pattern, and permitting conversational patterns other than the traditional request-reply-error. As an aside, working with such synchronous simulations of asynchronous messaging causes all sorts of headaches, because asynchronous events naturally involve concurrency, and the simulation usually only involves a single process dispatching events by synchronous procedure call. Regards, Tony -- Tony Garnock-Jones tonygarnockjo...@gmail.com mailto:tonygarnockjo...@gmail.com http://homepages.kcbbs.gen.nz/tonyg/ ___ fonc mailing list fonc@vpri.org mailto:fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
John Zabroski johnzabro...@gmail.com writes:
Folks,
Arguing technical details here misses the point. For example, a
different conversation can be started by asking Why does my web
hosting provider say I need an FTP client? Already technology is way
too much in my face and I hate seeing programmers blame their tools
rather than their misunderstanding of people.
Start by asking yourself how would you build these needs from scratch
to bootstrap something like the Internet.
What would a web browser look like if the user didnt need a seperate
program to put data somewhere on their web server and could just use
one uniform mexhanism? Note I am not getting into nice to have
features like resumption of paused uploads due to weak or episodic
connectivity, because that too is basically a technical problem -- and
it is not regarded as academically difficult either. I am simply
taking one example of how users are forced to work today and asking
why not something less technical. All I want to do is upload a file
and yet I have all these knobs to tune and things to install and
none of it takes my work context into consideration.
There are different problems.
About the tools and mechanisms, and their multiplicity, it's normal to
have a full toolbox. Even with evolving technologies some tools are
used less often, each has its specific use and they're all useful.
Also, the point of discrete tools is that they're modular and can be
combined to great effect by a competent professionnal. You wouldn't
want to dig all the holes with the same tool, be it either a spoon or a
caterpillar.
Now for the other problem, the users, one cause of that problem is the
accessibility and openess of computer and software technology, which
doesn't put clear boundaries between the professionnals and the
customers. There're all shades of grays, amateurs, students and D.I.Y
in between.
But you're perfectly entitled to have expectations of good service and
ease of use. You only need to realize that this will come with a cost,
and it won't be cheap.
Basically, your choice is between:
- here, we have a toolbox, we will gladly lend it to you so you can have
fun hacking your own stuff.
- tell us what you want, we'll work hard to provide you the easy
service, and we'll send you the bill.
(ok, there are intermediary choices, but you can basically classify each
offer between a do-it-yourself solution and a everything-s-done-for-you
one).
However the difficulties of the later option is that things evolve so
fast that we may not have the time to develop affordable fine tuned
customer oriented solutions before they become obsolete. Developing and
refining such services takes time, and money.
And in general, programmers are not paid well enough.
Just compare the hourly wages of a plumber and a computer programmer,
and you'll understand why you don't get the same easy service from
programmers than what you get from plumbers. But this is a problem
easily solved: just put the money on the table, and you'll find
competent programmers to implement your easy solution.
But it seems customers prefer crappy service as long as it's cheap (or
free).
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
On Fri, Jun 15, 2012 at 6:36 AM, Pascal J. Bourguignon p...@informatimago.com wrote: John Zabroski johnzabro...@gmail.com writes: Folks, Arguing technical details here misses the point. For example, a different conversation can be started by asking Why does my web hosting provider say I need an FTP client? Already technology is way too much in my face and I hate seeing programmers blame their tools rather than their misunderstanding of people. Start by asking yourself how would you build these needs from scratch to bootstrap something like the Internet. What would a web browser look like if the user didnt need a seperate program to put data somewhere on their web server and could just use one uniform mexhanism? Note I am not getting into nice to have features like resumption of paused uploads due to weak or episodic connectivity, because that too is basically a technical problem -- and it is not regarded as academically difficult either. I am simply taking one example of how users are forced to work today and asking why not something less technical. All I want to do is upload a file and yet I have all these knobs to tune and things to install and none of it takes my work context into consideration. There are different problems. About the tools and mechanisms, and their multiplicity, it's normal to have a full toolbox. Even with evolving technologies some tools are used less often, each has its specific use and they're all useful. Also, the point of discrete tools is that they're modular and can be combined to great effect by a competent professionnal. You wouldn't want to dig all the holes with the same tool, be it either a spoon or a caterpillar. Now for the other problem, the users, one cause of that problem is the accessibility and openess of computer and software technology, which doesn't put clear boundaries between the professionnals and the customers. There're all shades of grays, amateurs, students and D.I.Y in between. But you're perfectly entitled to have expectations of good service and ease of use. You only need to realize that this will come with a cost, and it won't be cheap. Basically, your choice is between: - here, we have a toolbox, we will gladly lend it to you so you can have fun hacking your own stuff. - tell us what you want, we'll work hard to provide you the easy service, and we'll send you the bill. (ok, there are intermediary choices, but you can basically classify each offer between a do-it-yourself solution and a everything-s-done-for-you one). However the difficulties of the later option is that things evolve so fast that we may not have the time to develop affordable fine tuned customer oriented solutions before they become obsolete. Developing and refining such services takes time, and money. And in general, programmers are not paid well enough. Just compare the hourly wages of a plumber and a computer programmer, and you'll understand why you don't get the same easy service from programmers than what you get from plumbers. But this is a problem easily solved: just put the money on the table, and you'll find competent programmers to implement your easy solution. But it seems customers prefer crappy service as long as it's cheap (or free). Sorry, you did not answer my question, but instead presented excuses for why programmers misunderstand people. (Can I paraphrase your thoughts as, Because people are not programmers!) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
John Zabroski wrote: On Fri, Jun 15, 2012 at 6:36 AM, Pascal J. Bourguignon p...@informatimago.com mailto:p...@informatimago.com wrote: John Zabroski johnzabro...@gmail.com mailto:johnzabro...@gmail.com writes: All I want to do is upload a file and yet I have all these knobs to tune and things to install and none of it takes my work context into consideration. snip Basically, your choice is between: - here, we have a toolbox, we will gladly lend it to you so you can have fun hacking your own stuff. - tell us what you want, we'll work hard to provide you the easy service, and we'll send you the bill. (ok, there are intermediary choices, but you can basically classify each offer between a do-it-yourself solution and a everything-s-done-for-you one). snip But it seems customers prefer crappy service as long as it's cheap (or free). Sorry, you did not answer my question, but instead presented excuses for why programmers misunderstand people. (Can I paraphrase your thoughts as, Because people are not programmers!) Ok.. let's try making it simple: - you want it easy - you want it cheap - you don't want to take the effort to find a tool or service provider that makes it easy (plenty of them exist, some of them are cheap, some free) Guess what, the problem is not the technology, or the programmers - it's you. -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
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 little bit of glue). My sense at the time was that the newly emerging concepts of OO were a way of entrenching this philosophy directly into the programming languages. When applied to tasks like building window systems, OO is an incredibly powerful approach. If one matches what they are seeing on the screen with the objects they are building in the back, there is a strong one-to-one mapping that allows the programmer to rapidly diagnose problems at a speed that just wasn't possible before. But for many of the things that I've built in the back-end I find that OO causes me to jump through what I think are artificial hoops. Over the years I've spent a lot of time pondering why. My underlying sense is that there are some fundamental dualities in computational machines. Static vs. dynamic. Data vs. code. Nouns vs. verbs. Location vs. time. It is possible, of course, to 'cast' one onto the other, there are plenty of examples of 'jumping' particularly in languages wrt. nouns and verbs. But I think that decompositions become 'easier' for us to understand when we partition them along the 'natural' lines of what they are underneath. My thinking some time ago as it applies to OO is that the fundamental primitive, an object, essentially mixes its metaphors (sort of). That is, it contains both code and data. I think it's this relatively simple point that underlies the problems that people have in grokking OO. What I've also found is that that wasn't there in that earlier philosophy at Waterloo. Sure there were atomic primitives attached to each data-structure, but the way we build heavy-duty mechanics was more often to push the 'actions' to something like an intermediary data-structure and then do a clean simple traversal to actuate it (like lisp), so fundamentally the static/dynamic duality was daintily skipped over. It is far more than obvious that OO opened the door to allow massive systems. Theoretically they were possible before, but it gave us a way to manage the complexity of these beasts. Still, like all technologies, it comes with a built-in 'threshold' that imposes a limit on what we can build. If we are too exceed that, then I think we are in the hunt for the next philosophy and as Zed points out the ramification of finding it will cause yet another technological wave to overtake the last one. Just my thoughts. Paul. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
I have kinda lost track of this thread so forgive me if I wander off in a perpendicular direction. I believe that things do not have to continually get more and more complex. The way out for me is to go back to the beginning and start over (which is what this mailing list is all about). I constantly go back to the beginnings in math and/or physics and try to re-understand from first principles. Of course every time I do this I get less and less further along the material continuum because the beginnings are so darn interesting. Let me give an example from arithmetic which I learned from Ken Iverson's writings years ago. As children we spend a lot of time practicing adding up numbers. Humans are very bad at this if you measure making a silly error as bad. Take for example: 365 + 366 -- this requires you to add 5 6, write down 1 and carry 1 to the next column then add 6, 6, and that carried 1 and write down 2 and carry a 1 to the next column finally add 3, 3 and the carried 1 and write down 7 this gives you 721, oops, the wrong answer. In step 2 I made a totally dyslexic mistake and should have written down a 3. Ken proposed learning to see things a bit differently and remember the digits are a vector times another vector of powers. Ken would have you see this as a two step problem with the digits spread out. 3 6 5 + 3 6 6 Then you just add the digits. Don't think about the carries. 3 6 5 + 3 6 6 6 12 11 Now we normalize the by dealing with the carry part moving from right to left in fine APL style. You can almost see the implied loop using residue and n-residue. 6 12 11 6 13 0 7 3 0 Ken believed that this two stage technique was much easier for people to get right. I adopted it for when I do addition by had and it works very well for me. What would it be like if we changed the education establishment and used this technique? 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. We need to reduce complexity at all levels and that includes the culture we swim in. cheers, -David Leibs On Jun 15, 2012, at 10:58 AM, BGB wrote: On 6/15/2012 12:27 PM, Paul Homer wrote: I wouldn't describe complexity as a problem, but rather an attribute of the universe we exist in, effecting everything from how we organize our societies to how the various solar systems interact with each other. Each time you conquer the current complexity, your approach adds to it. Eventually all that conquering needs to be conquered itself ... yep. the world of software is layers upon layers of stuff. one thing is made, and made easier, at the cost of adding a fair amount of complexity somewhere else. this is generally considered a good tradeoff, because the reduction of complexity in things that are seen is perceptually more important than the increase in internal complexity in the things not seen. although it may be possible to reduce complexity, say by finding ways to do the same things with less total complexity, this will not actually change the underlying issue (or in other cases may come with costs worse than internal complexity, such as poor performance or drastically higher memory use, ...). Paul. From: Loup Vaillant l...@loup-vaillant.fr 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 is far more than obvious that OO opened the door to allow massive systems. Theoretically they were possible before, but it gave us a way to manage the complexity of these beasts. Still, like all technologies, it comes with a built-in 'threshold' that imposes a limit on what we can build. If we are too exceed that, then I think we are in the hunt for the next philosophy and as Zed points out the ramification of finding it will cause yet another technological wave to overtake the last one. I find that a bit depressing: if each tool that tackle complexity better than the previous ones lead us to increase complexity (just because we can), we're kinda doomed. Can't we recognized complexity as a problem, instead of an unavoidable law of nature? Thank goodness we have STEPS project to shed some light. Loup. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
David Leibs david.le...@oracle.com writes:
I have kinda lost track of this thread so forgive me if I wander off
in a perpendicular direction.
I believe that things do not have to continually get more and more
complex. The way out for me is to go back to the beginning and start
over (which is what this mailing list is all about). I constantly go
back to the beginnings in math and/or physics and try to re-understand
from first principles. Of course every time I do this I get less and
less further along the material continuum because the beginnings are
so darn interesting.
Let me give an example from arithmetic which I learned from Ken
Iverson's writings years ago.
As children we spend a lot of time practicing adding up
numbers. Humans are very bad at this if you measure making a silly
error as bad. Take for example:
365
+ 366
--
this requires you to add 5 6, write down 1 and carry 1 to the next
column then add 6, 6, and that carried 1 and write down 2 and carry a
1 to the next column finally add 3, 3 and the carried 1 and write down
7 this gives you 721, oops, the wrong answer. In step 2 I made a
totally dyslexic mistake and should have written down a 3.
Ken proposed learning to see things a bit differently and remember the
digits are a vector times another vector of powers. Ken would have
you see this as a two step problem with the digits spread out.
3 6 5
+ 3 6 6
Then you just add the digits. Don't think about the carries.
3 6 5
+ 3 6 6
6 12 11
Now we normalize the by dealing with the carry part moving from right
to left in fine APL style. You can almost see the implied loop using
residue and n-residue.
6 12 11
6 13 0
7 3 0
Ken believed that this two stage technique was much easier for people
to get right. I adopted it for when I do addition by had and it works
very well for me. What would it be like if we changed the education
establishment and used this technique? 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.
It's a nice way to do additions indeed.
When doing additions mentally, I tend to do them from right to left,
predicting whether we need a carry or not by looking ahead the next
column. Usually carries don't carry over more than one column, but
even if it does, you only have to remember a single digit at a time.
There are several ways to do additions :-)
Your way works as well for substractions:
3 6 5
- 3 7 1
---
0 -1 4
0 -10 + 4 = -6
3 7 1
- 3 6 5
---
0 1 -4
10 -4 = 6
and of course, it's already how we do multiplications too.
We need to reduce complexity at all levels and that includes the
culture we swim in.
Otherwise, you can always apply the KISS principle
(Keep It Simple Stupid).
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
Hi David, The often used quote by Einstein is: Make everything as simple as possible, but not simpler People interpret that in a lot of interesting ways, but it does point to a 'minimum simplicity'. In software, you might build a system with 100,000 lines of code. Someone else might come along and build it with 20,000 lines of code, but there is some underlying complexity tied to the functionality that dictates that it could never be any less the X lines of code. The system encapsulates a significant amount of information, and stealing from Shannon slightly, it cannot be represented in any less bits. If you let your imagination go wild, you can envision a system with twice as much functionality. Now it may be that it requires less than 2X lines of code, but it still has a minimum. All modern systems we have today exist in silos. Many interact with each other, but for the most part we are forced to deal with them individually. If we wanted to get closer to what Zed was describing, we'd have to integrate them with each other. Given that there are probably huge redundancies it wouldn't end up being N*X lines of code, but given the amount of information we've encoded it our various systems it would still be stunningly large. I think Windows is up around 50M. There may be systems out there that are larger. I certainly can imagine a system that might contain 500M lines of code. It would be a pretty nice piece of software, but I honestly doubt that we could build such a thing (as a single thing*) given our current technologies. *One could take the Internet as a whole with its 2.3 billion users and untold number of machines as a 'single system'. I might accept that, but if it were so I'd have to say that its overall quality is very low in the sense that as one big piece it is a pretty messy piece. Parts of it work well, parts of it don't. If things are expanding then they have to get more complex, they encompass more. Our usage of computers is significant, but it isn't hard to imagine them doing more for us. To get there, we have to expand our usage and thus be able to handle more complexity. Big integrated systems that make life better by keeping it more organized are probably things we absolutely need right now. Our modern societies are outrageously complex and many suspect unsustainable. The promise of computers has been that we could embed our intellect into them so that we could use them as tools to tame that problem, but to get there we need systems that dwarf our current ones. Paul. From: David Leibs david.le...@oracle.com To: Fundamentals of New Computing fonc@vpri.org Sent: Friday, June 15, 2012 3:17:19 PM Subject: Re: [fonc] The Web Will Die When OOP Dies I have kinda lost track of this thread so forgive me if I wander off in a perpendicular direction. I believe that things do not have to continually get more and more complex. The way out for me is to go back to the beginning and start over (which is what this mailing list is all about). I constantly go back to the beginnings in math and/or physics and try to re-understand from first principles. Of course every time I do this I get less and less further along the material continuum because the beginnings are so darn interesting. Let me give an example from arithmetic which I learned from Ken Iverson's writings years ago. As children we spend a lot of time practicing adding up numbers. Humans are very bad at this if you measure making a silly error as bad. Take for example: 365 + 366 -- this requires you to add 5 6, write down 1 and carry 1 to the next column then add 6, 6, and that carried 1 and write down 2 and carry a 1 to the next column finally add 3, 3 and the carried 1 and write down 7 this gives you 721, oops, the wrong answer. In step 2 I made a totally dyslexic mistake and should have written down a 3. Ken proposed learning to see things a bit differently and remember the digits are a vector times another vector of powers. Ken would have you see this as a two step problem with the digits spread out. 3 6 5 + 3 6 6 Then you just add the digits. Don't think about the carries. 3 6 5 + 3 6 6 6 12 11 Now we normalize the by dealing with the carry part moving from right to left in fine APL style. You can almost see the implied loop using residue and n-residue. 6 12 11 6 13 0 7 3 0 Ken believed that this two stage technique was much easier for people to get right. I adopted it for when I do addition by had and it works very well for me. What would it be like if we changed the education establishment and used this technique? 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
Re: [fonc] The Web Will Die When OOP Dies
Speaking of multiplication. Ken Iverson teaches us to do multiplication by
using a * outer product to build a times table for the digits involved.
+-++
| | 3 6 6|
+-++
|3| 9 18 18|
|6|18 36 36|
|5|15 30 30|
+-++
Now you sum each diagonal:
(9) (18+18) (18+36+15) (36+30) (30)
936 6966 30
And just normalize as usual:
9 36 69 66 30
9 36 69 69 0
9 36 75 9 0
9 43 5 9 0
13 3 5 9 0
1 3 3 5 9 0
The multiplication table is easy and just continued practice for your
multiplication facts.
You don't need much more machinery before you have the kids doing Cannon's
order n systolic array algorithm for matrix multiply, on the gym floor, with
their bodies. This assumes that the dance teacher is coordinating with the
algorithms teacher. Of course if there isn't something relevant going on that
warrants matrix multiply then all is lost. I guess that's a job for the
motivation teacher. :-)
-David Leibs
On Jun 15, 2012, at 12:57 PM, Pascal J. Bourguignon wrote:
David Leibs david.le...@oracle.com writes:
I have kinda lost track of this thread so forgive me if I wander off
in a perpendicular direction.
I believe that things do not have to continually get more and more
complex. The way out for me is to go back to the beginning and start
over (which is what this mailing list is all about). I constantly go
back to the beginnings in math and/or physics and try to re-understand
from first principles. Of course every time I do this I get less and
less further along the material continuum because the beginnings are
so darn interesting.
Let me give an example from arithmetic which I learned from Ken
Iverson's writings years ago.
As children we spend a lot of time practicing adding up
numbers. Humans are very bad at this if you measure making a silly
error as bad. Take for example:
365
+ 366
--
this requires you to add 5 6, write down 1 and carry 1 to the next
column then add 6, 6, and that carried 1 and write down 2 and carry a
1 to the next column finally add 3, 3 and the carried 1 and write down
7 this gives you 721, oops, the wrong answer. In step 2 I made a
totally dyslexic mistake and should have written down a 3.
Ken proposed learning to see things a bit differently and remember the
digits are a vector times another vector of powers. Ken would have
you see this as a two step problem with the digits spread out.
3 6 5
+ 3 6 6
Then you just add the digits. Don't think about the carries.
3 6 5
+ 3 6 6
6 12 11
Now we normalize the by dealing with the carry part moving from right
to left in fine APL style. You can almost see the implied loop using
residue and n-residue.
6 12 11
6 13 0
7 3 0
Ken believed that this two stage technique was much easier for people
to get right. I adopted it for when I do addition by had and it works
very well for me. What would it be like if we changed the education
establishment and used this technique? 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.
It's a nice way to do additions indeed.
When doing additions mentally, I tend to do them from right to left,
predicting whether we need a carry or not by looking ahead the next
column. Usually carries don't carry over more than one column, but
even if it does, you only have to remember a single digit at a time.
There are several ways to do additions :-)
Your way works as well for substractions:
3 6 5
- 3 7 1
---
0 -1 4
0 -10 + 4 = -6
3 7 1
- 3 6 5
---
0 1 -4
10 -4 = 6
and of course, it's already how we do multiplications too.
We need to reduce complexity at all levels and that includes the
culture we swim in.
Otherwise, you can always apply the KISS principle
(Keep It Simple Stupid).
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
Fascinating.
How did Iverson do division?
Op 15 jun. 2012, om 23:08 heeft David Leibs het volgende geschreven:
Speaking of multiplication. Ken Iverson teaches us to do multiplication by
using a * outer product to build a times table for the digits involved.
+-++
| | 3 6 6|
+-++
|3| 9 18 18|
|6|18 36 36|
|5|15 30 30|
+-++
Now you sum each diagonal:
(9) (18+18) (18+36+15) (36+30) (30)
936 6966 30
And just normalize as usual:
9 36 69 66 30
9 36 69 69 0
9 36 75 9 0
9 43 5 9 0
13 3 5 9 0
1 3 3 5 9 0
The multiplication table is easy and just continued practice for your
multiplication facts.
You don't need much more machinery before you have the kids doing Cannon's
order n systolic array algorithm for matrix multiply, on the gym floor, with
their bodies. This assumes that the dance teacher is coordinating with the
algorithms teacher. Of course if there isn't something relevant going on that
warrants matrix multiply then all is lost. I guess that's a job for the
motivation teacher. :-)
-David Leibs
On Jun 15, 2012, at 12:57 PM, Pascal J. Bourguignon wrote:
David Leibs david.le...@oracle.com writes:
I have kinda lost track of this thread so forgive me if I wander off
in a perpendicular direction.
I believe that things do not have to continually get more and more
complex. The way out for me is to go back to the beginning and start
over (which is what this mailing list is all about). I constantly go
back to the beginnings in math and/or physics and try to re-understand
from first principles. Of course every time I do this I get less and
less further along the material continuum because the beginnings are
so darn interesting.
Let me give an example from arithmetic which I learned from Ken
Iverson's writings years ago.
As children we spend a lot of time practicing adding up
numbers. Humans are very bad at this if you measure making a silly
error as bad. Take for example:
365
+ 366
--
this requires you to add 5 6, write down 1 and carry 1 to the next
column then add 6, 6, and that carried 1 and write down 2 and carry a
1 to the next column finally add 3, 3 and the carried 1 and write down
7 this gives you 721, oops, the wrong answer. In step 2 I made a
totally dyslexic mistake and should have written down a 3.
Ken proposed learning to see things a bit differently and remember the
digits are a vector times another vector of powers. Ken would have
you see this as a two step problem with the digits spread out.
3 6 5
+ 3 6 6
Then you just add the digits. Don't think about the carries.
3 6 5
+ 3 6 6
6 12 11
Now we normalize the by dealing with the carry part moving from right
to left in fine APL style. You can almost see the implied loop using
residue and n-residue.
6 12 11
6 13 0
7 3 0
Ken believed that this two stage technique was much easier for people
to get right. I adopted it for when I do addition by had and it works
very well for me. What would it be like if we changed the education
establishment and used this technique? 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.
It's a nice way to do additions indeed.
When doing additions mentally, I tend to do them from right to left,
predicting whether we need a carry or not by looking ahead the next
column. Usually carries don't carry over more than one column, but
even if it does, you only have to remember a single digit at a time.
There are several ways to do additions :-)
Your way works as well for substractions:
3 6 5
- 3 7 1
---
0 -1 4
0 -10 + 4 = -6
3 7 1
- 3 6 5
---
0 1 -4
10 -4 = 6
and of course, it's already how we do multiplications too.
We need to reduce complexity at all levels and that includes the
culture we swim in.
Otherwise, you can always apply the KISS principle
(Keep It Simple Stupid).
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
Paul, I found your post interesting in that it might reflect a fundamental problem that I have with normal, average OO, and that is that methods belong with data. I have never bought that ideaever. I remember feeling stupid because I could never grok that idea and then felt better when the chief scientist at Franz (who of course produce Franz Lisp) said that functions don't belong with data. So of course in Common Lisp we have generic functions. There's this continuous mental dilenma with me about what belongs in a class. It's just a big bowl of wrong (TM Jeff Garlin) where we have everything that can ever be done to a class belong to that class. So that's why I subscribe to anemic classes, despite what Fowler and others say. The exception I have is valid state (factories), but even then I find that I want to bring extension methods (in c#) back into the proper class. We're doing something wrong, but I'm just a joe-average programmer and like subscribing to newsgroups like this to hear what the big brains are saying :) On Fri, Jun 15, 2012 at 11:45 AM, Paul Homer paul_ho...@yahoo.ca wrote: 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 little bit of glue). My sense at the time was that the newly emerging concepts of OO were a way of entrenching this philosophy directly into the programming languages. When applied to tasks like building window systems, OO is an incredibly powerful approach. If one matches what they are seeing on the screen with the objects they are building in the back, there is a strong one-to-one mapping that allows the programmer to rapidly diagnose problems at a speed that just wasn't possible before. But for many of the things that I've built in the back-end I find that OO causes me to jump through what I think are artificial hoops. Over the years I've spent a lot of time pondering why. My underlying sense is that there are some fundamental dualities in computational machines. Static vs. dynamic. Data vs. code. Nouns vs. verbs. Location vs. time. It is possible, of course, to 'cast' one onto the other, there are plenty of examples of 'jumping' particularly in languages wrt. nouns and verbs. But I think that decompositions become 'easier' for us to understand when we partition them along the 'natural' lines of what they are underneath. My thinking some time ago as it applies to OO is that the fundamental primitive, an object, essentially mixes its metaphors (sort of). That is, it contains both code and data. I think it's this relatively simple point that underlies the problems that people have in grokking OO. What I've also found is that that wasn't there in that earlier philosophy at Waterloo. Sure there were atomic primitives attached to each data-structure, but the way we build heavy-duty mechanics was more often to push the 'actions' to something like an intermediary data-structure and then do a clean simple traversal to actuate it (like lisp), so fundamentally the static/dynamic duality was daintily skipped over. It is far more than obvious that OO opened the door to allow massive systems. Theoretically they were possible before, but it gave us a way to manage the complexity of these beasts. Still, like all technologies, it comes with a built-in 'threshold' that imposes a limit on what we can build. If we are too exceed that, then I think we are in the hunt for the next philosophy and as Zed points out the ramification of finding it will cause yet another technological wave to overtake the last one. Just my thoughts. Paul. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
Pascal J. Bourguignon wrote: John Zabroski johnzabro...@gmail.com writes: Sorry, you did not answer my question, but instead presented excuses for why programmers misunderstand people. (Can I paraphrase your thoughts as, Because people are not programmers!) No, you misunderstood my answer: Because people don't pay programmers enough. I think that might be an inaccurate statement in two regards: - programmers make VERY good money, at least in some fields (if you know where to find good, cheap coders, in the US, let me know where) - (a lot of programmers) do NOT have a particularly user-focused mindset (just ask a C coder what they think of Hypercard - you'll get all kinds of answers about why end-users can't do any useful; despite a really long track record of good stuff written in Hypercard, particularly by educators) Note: This is irrelevant vis-a-vis Jon's question, however. The answer to why he can't find easy ways to upload files, is because he isn't looking. Miles -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
Paul Homer wrote: In software, you might build a system with 100,000 lines of code. Someone else might come along and build it with 20,000 lines of code, but there is some underlying complexity tied to the functionality that dictates that it could never be any less the X lines of code. The system encapsulates a significant amount of information, and stealing from Shannon slightly, it cannot be represented in any less bits. Of course, going from 100k lines to 20k lines might be a result of: - coding tricks that lead to incomprehensible code, particularly in languages that encourage such things (APL and perl come to mind) - re-writing in a domain-specific language (more powerful, but more specialized constructs that shift complexity into the underlying platform) Just saying :-) -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
On 16 June 2012 02:23, Mark Haniford markhanif...@gmail.com wrote: Paul, I found your post interesting in that it might reflect a fundamental problem that I have with normal, average OO, and that is that methods belong with data. I have never bought that ideaever. I remember feeling stupid because I could never grok that idea and then felt better when the chief scientist at Franz (who of course produce Franz Lisp) said that functions don't belong with data. So of course in Common Lisp we have generic functions. I also thought that so called OO is just a mere coupling of data and functions.. but after learning smalltalk and especially an image-based development, i came to conclusion, that it is often not necessary to separate those two, it's all just data or, if you like another word, - an information. Information describing some numbers or connections between multiple entities, or their groups, and information which describes how computer system operates with those entities. And that's IMO fairly easy to get. There's this continuous mental dilenma with me about what belongs in a class. It's just a big bowl of wrong (TM Jeff Garlin) where we have everything that can ever be done to a class belong to that class. So that's why I subscribe to anemic classes, despite what Fowler and others say. The exception I have is valid state (factories), but even then I find that I want to bring extension methods (in c#) back into the proper class. We're doing something wrong, but I'm just a joe-average programmer and like subscribing to newsgroups like this to hear what the big brains are saying :) On Fri, Jun 15, 2012 at 11:45 AM, Paul Homer paul_ho...@yahoo.ca wrote: 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 little bit of glue). My sense at the time was that the newly emerging concepts of OO were a way of entrenching this philosophy directly into the programming languages. When applied to tasks like building window systems, OO is an incredibly powerful approach. If one matches what they are seeing on the screen with the objects they are building in the back, there is a strong one-to-one mapping that allows the programmer to rapidly diagnose problems at a speed that just wasn't possible before. But for many of the things that I've built in the back-end I find that OO causes me to jump through what I think are artificial hoops. Over the years I've spent a lot of time pondering why. My underlying sense is that there are some fundamental dualities in computational machines. Static vs. dynamic. Data vs. code. Nouns vs. verbs. Location vs. time. It is possible, of course, to 'cast' one onto the other, there are plenty of examples of 'jumping' particularly in languages wrt. nouns and verbs. But I think that decompositions become 'easier' for us to understand when we partition them along the 'natural' lines of what they are underneath. My thinking some time ago as it applies to OO is that the fundamental primitive, an object, essentially mixes its metaphors (sort of). That is, it contains both code and data. I think it's this relatively simple point that underlies the problems that people have in grokking OO. What I've also found is that that wasn't there in that earlier philosophy at Waterloo. Sure there were atomic primitives attached to each data-structure, but the way we build heavy-duty mechanics was more often to push the 'actions' to something like an intermediary data-structure and then do a clean simple traversal to actuate it (like lisp), so fundamentally the static/dynamic duality was daintily skipped over. It is far more than obvious that OO opened the door to allow massive systems. Theoretically they were possible before, but it gave us a way to manage the complexity of these beasts. Still, like all technologies, it comes with a built-in 'threshold' that imposes a limit on what we can build. If we are too exceed that, then I think we are in the hunt for the next philosophy and as Zed points out the ramification of finding it will cause yet another technological wave to overtake the last one. Just my thoughts. Paul. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- Best regards, Igor Stasenko. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
