> > Socially? As in people don't get out enought and meet in > > meat-space? Or our interactions, even on-line? > > Well I was thinking more about social infrastructure. Things like bank > personell being able to help you in any way if their computers go out. > I understand why it's become that way, but it'd be nice to think that > there would be some kind of backup system, like they could make a > phone call to another central authority for the bank who could verify > your available funds, etc. Or that the personell at your own bank
This is exactly what that article about loose abstractions was getting at. See, the problem never goes away, no matter the level. Say there was a backup system. Nothing says that that backup system will accomplish it's goal. Even if we go back to the days of paper, what happens when they are all out of "official" forms? To be clear, the human element is the only way to get around the disconnect. People are just lazy, and it's easier to say "the computer is down" than call up Joe, have him dig up the paperwork, etc., etc.,. But I feel in my heart of hearts that we don't NEED computers to survive. Or paperwork, for that matter. At least until we go borg. :-) It bugs the hell out of me, but "who you know" still matters . If you were chums with the main bank dude, you'll see a different aspect of the whole process than when you're just joe schmoe. I don't see that changing for a bit, if ever. Guess it keeps people cordial. Eh. My jury is still out on that. And all that aside, there are times when "the system is down", plain and simple. If you realize that, you can contain the leaks, so to speak. Damn the circular nature of this idea. ;-) I'll have to check out the Asylum book. Heard enough people who's thoughts I appreciate, mention it. Someday I'll take advantage of Amazon or something similar for a book list. The little "note" in my PDA just isn't cutting it no more. :-) our code generators are for more specific purposes, that's true, but I > still shy away from it on the thinking that it's liable to lead to > handcuffing me in some way, re: what you just described about the old > mac OS or the couple of examples above. Although there have been a > couple of occasions on which I felt there was too much abstraction in > something, more frequently I find myself being limited and/or required > to do more work as a result of a lack of abstraction. I think the real pain comes when you have no way to translate the abstraction. I don't see much difference, so long as you have a "getter" and a "setter" of generated content, between a function that gets and sets things in memory, vs. on-disk. Like my attempt at using the single table per data type idea- I had an inkling that I might have to use DB tables at some point, whether to extract/import data (why I first wrote in/out) or as a storage medium. I was just sure to have relatively easy ways of transforming to and from my "preferred format" and other more standard formats. So long as you can do that, you can use pipes, and transform data into whatever format you like. Within reason, I guess. ;-) Abstractions are ideas. You can make a wrapper for something and 'vwalla', you abstracted it - If you wrote the wrapper "right", right being in a form that give you the most use. Even if you just did the same stuff the thing being wrapped did, it's still an abstraction of sorts. Just by the fact that it's now "in your language", so to speak. I guess it's more how good of an abstraction, than abstraction itself. "How good" is a many factored equation, involving opinions and other riff-raff. A "good" abstraction maybe spot on for one person, and not even close to being "done to a turn" for another. Or I could have the whole idea of abstraction wrong. Or a weird definition. I'm thinking along the lines of a representation of something that is easier to "do stuff" with than the "actual" thing. But I really have to give them credit for > making my life easier. :) Same here. Of course I'm one to talk, I used to look down on people who wrote code in Basic. It's hard not to stick to that mentality. "But you could write yer put pixel 300x faster in ASM!" :-) Don't get me wrong, if you have a big enough "snippets" lib, I think you could be pretty fast, even with low level stuff. But I like how you can replace the built-in putpixel with your "optimized" ASM routine. Seemed like it was the best of both worlds. When I realized that, it all sorta... Seems sorta like 6 of one... maybe not so much the "framework", as it is the mind behind the code... Eh. What this has to do with anything... =-p Oh there's certainly value in understanding some of the lower theory, > but an individual programmer can only learn so much. Not that an > individual programmer can't learn whatever they want to learn, but you > know, there are only so many hours in a day. :) In the long-run, you > have to weigh the value of having that low level insight against the > value of getting work done during the hours that you would be > studying, and there's enough low-level imo you could study forever > before you got started on an actual project. :P Indeed. I could learn forever. With luck, I will. Stupidly, I learn a lot while I work. Not very pro, I know, but it keeps me working. [= And everyone has their style of learning. Styles, even. Cross-disciplinarianism, so to speak, is pretty useful though. > Sometimes stuff doesn't work, even tho we're told at the > > high level it should. Then what. :-P Ya gotta dig in. > > If you dig that kind of stuff. I guess you could also just > > say, "hey person who's thing my thing doesn't work with, > > why aren't you "standard"?". Or wait for the person who's > > job it is to do that part figures it out. > > Yep, and people make those kinds of decisions fairly frequently in > this industry. Same as the teller saying, "sorry, computer is down", neh? ;-) This just means we need to define our terms. :) When I talk about > optimization I generally limit that word to issues of mechanical > efficiency unless we're talking specifically about a user-interface > issue. Issues of human efficiency when using the application are in my > experience usually discussed under the heading "usability" or > sometimes "human factors". [...] Ah, that's cool. Separating them out makes them easier to manage. That's how I come to the conclusion that we're in transition -- the > Star Trek computer is optimal for humans, although it may not be as > mechanically efficient as today's machines (actually I would expect it > to be less efficient). It's optimal for human use because it accepts > input in a way that is natural for humans (conversational speech). > It's mechanically inoptimal because a human won't notice the > difference between mechanically optimal and mechanically inoptimal > software by then as a result of much more powerful hardware. Well, I am pretty impressed with the voice recognition already available today, (apparently pretty cheap, my phone has it) I've seen some people actually set up their mac to where it talks and vice versa. Phar out, but the tech is definitely there. And It's come so far in such a short time. In 20 years, I bet most code will be basically self-optimizing, and while some things will stay the same (like yummy coffee!), other stuff... we wouldn't even recognize today. [.. data-type table idea ..] > I think the jury's still out (at least it is for me) on the benefit of > that abstraction. That article about the database and how it handled rows and whatnot, kind of sealed the deal for me. It's a swell idea, and easy to abstract, but there is no need to do it at that level, that's like totally wasting the power of the database. Might as well let it do what it was designed to do. Or whatever, they're pretty sick, they can handle a lot. But it would probably be a better idea with something other than MySQL. [-; Sheesh. "Yeah dood, it's like, totally sick man". I sound like I'm in a VW commercial, about to get SMASHED! (Those are kind of disturbing, neh? Give some old fart a heart attack prolly. I kinda like 'em. "Safe Happens" LOL! ) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:237671 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
