00:00:00 --- log: started forth/05.06.27 03:03:12 --- join: crc (crc@pool-151-197-232-43.phil.east.verizon.net) joined #forth 03:03:33 --- mode: ChanServ set +o crc 03:29:51 --- quit: crc (Read error: 110 (Connection timed out)) 05:18:09 --- join: PoppaVic (~pete@0-1pool75-250.nas24.chicago4.il.us.da.qwest.net) joined #forth 05:18:28 Mornin' 06:06:27 --- join: madwork (~madgarden@derby.metrics.com) joined #forth 06:06:39 Hi 06:07:15 HI 06:07:38 lo 06:08:00 Greetings, Programs. 06:08:15 I am your personal greetbot. 06:08:33 I had a few brainfarts the other day 06:08:42 Don 06:08:49 Don? Is that you? 06:08:57 Don't stink up the place! 06:15:17 --- join: virl (Phantasus@chello062178085149.1.12.vie.surfer.at) joined #forth 06:25:00 madwork: well, the ideas started perkin' faster than I could figure out where to shovel them (and how) 06:26:19 More thought about your func-tagged stack.. Considering a Wlist container ala' gforth 06:28:26 Also considering dumping the word[threads] array entirely.. Just use an avl or rb-tree and be done with it. 06:29:28 For code? Sounds bloaty. 06:29:38 which? 06:29:44 Using a tree for threads. 06:29:55 nah, KISS principle. 06:30:03 ? 06:30:18 What's simpler than an array? 06:30:21 since I use vtables anyway, another for dbase behavior makes it easy 06:32:11 Thus, a system could use a list, a DLL, a file, a tree, a skiplist - all we care about is them providing the proper vtable and functions. 06:32:55 but, it's yer damned func-tagged stack idea that's messing with my head. 06:33:45 Because, it's pretty obvious that it needs to be a vtable ptr or a switched func. 06:33:48 Heh. Yea, well it's a good idea. ;) 06:34:29 You do realize the damned idea made me immediately see we could define new - TRUE - 'types'? 06:34:32 Maybe I'm confused though... I thought you just described creating threads ("compiled" code) using trees instead of simple arrays of addresses. 06:34:42 TRUE? Like boolean? 06:34:47 nono - dictionary/wlist lookup 06:34:53 Oh, OK. Phew. ;) 06:35:25 And yea, you can define new types quite easily using the type interface. 06:35:27 And, it's tempting to immediately consider a token-threaded lang. 06:35:50 Yep... good for pickling. 06:36:07 ..but I think ptr-threaded is prolly better, and then write a pickler/decompiler/translator, etc 06:36:29 Yep. Forthy is "pointer" threaded... ITC. 06:36:39 what I am considering is... 06:36:47 Then you can just write out offsets into the dictionary with a few special codes. 06:37:15 1) I can live either way for the immediate project; but, 2) I can envision generating .s files for GAS and such. 06:38:05 the prob with token-threaded is that you need to gather all the 'objects' into arrays to index, or a ll, or something - and use an ID# for _everything_ 06:39:18 Also, I've been mulling over the pass/timeslice/mode/state idea and getting a bit irked. 06:39:56 Gather the objects into arrays to index? Why? 06:40:18 I've been thinking of on_lex() on_rule() and on_pcode() - but it may not be that clear 06:40:42 madwork: so the id#'s get compiled consecutive, etc 06:41:08 otherwise yer calling an eval/compile on everything and wasting time 06:41:34 I don't see the problem? If the object lives in a variable in the dictionary, then it's just like anything else. 06:42:30 ok.. let's back it up a sec. 06:42:54 The 'token' is like the XT some shit uses, right? 06:43:15 An otherwise meaningless - but unique - vale? 06:43:17 value? 06:44:01 Something, somewhere has to associate the (serialized) unique 'token' with realities. 06:44:32 Yep. 06:44:43 It's an index into the dictionary array. 06:44:46 basically. 06:44:47 On the whole, gcc doesn't much care to increment a special ctr as it compiles. Unless yer in an array 06:45:19 so, somewhere in the core .c's is this monsterous array 06:45:46 This doesn't really thrill me much. 06:45:50 ? 06:46:25 I'd rather remove that step from this module and let some OTHER module worry about a token/ptr database 06:47:02 UNLESS you can see some vastly simple way to make it all happen nice and clean. 06:47:07 This "array" is just the wordlist. You're using indexes into it as XT's instead of addresses. That's all. How you construct the array is up to you. 06:47:16 right 06:47:25 Sure... use an array of word headers, and realloc() as you go. 06:47:28 So far, there is no XT array 06:47:50 to be honest, I am ambivalent about XT's 06:48:40 I'm not sure it does much for us UNLESS we are compiling pcode 'objects' to run on another system. 06:49:09 In that case, use address-threaded and not token-threaded. 06:49:29 It's more direct and to the point. 06:49:48 maybe relocatable-code issues, too - but you can't insure tokens unless you accept a socket-like <1024==system logic 06:50:21 madwork: yeah, I think the core needs real ptr-threading. 06:51:42 Yea, just hand out the pointers inside your word-list table. 06:51:48 yep 06:52:02 and that brings me to the gforth wordlist idea 06:52:30 I was goin' nuts, trying to relagate bootstrapping vocs and vocs versus wordlists and - well, it sucked. 06:52:47 ..THEN I noticed how gforth handled those damned wordlists. 06:53:34 In terms my code would use: there is a systemic wlist container, and all you ever know about it is the key/token to access it. 06:54:15 this enables anonymous wordlists and vocabularies built above them 06:55:20 twisting that, I have bitfield-flags that let me look at those structs to see if it is even possible to >body or .voc 06:55:48 ..at least, that's the current mess. 06:55:58 heh 06:56:50 I might beat it some more... It seems likely that I now have enough new ideas to run up a whole new idiocy. 06:57:07 Now, lemme' ask something odd.. 06:57:41 Currently, I define the "dictionary" early.. It actually looks like a system-core as well. 06:58:10 However, I'm beginning to think that the script-module (pcode compiled shit) shouldpreceed it. 06:59:07 Describe the basics; then describe how we'd store 'lists'; then describe the dictionary; then initialize it. 06:59:30 It's another form of chicken/egg issue, I think 07:00:52 Is there a benefit? 07:01:56 I don't really know.. I'm trying to write logically-ordered files of .h and .c, the most irksome is the forwards file. 07:02:33 Given apropos forwards, the rest is fairly easy to read and clear. 07:02:48 (I hate using void* to obviate forwards) 07:11:19 hrmmm 07:20:22 madwork: you see any reason to disembody name from head - reduce replication - but as-is, it looks like tons of shit just extend names for new names. 07:27:34 hmm 07:27:57 the tag-vtable would make life interesting 07:28:33 ..because we THINK in terms of C-funcs, but later might think in terms of colon-words 07:32:10 madwork: you do realize, I hope, that we are damn-nearly looking at a paradigm-shift? 07:39:37 --- quit: ianp (Remote closed the connection) 07:44:41 If you plan to re-use that many names, then I guess you want a string table. 07:44:54 A... paradigm shift? 07:44:57 yeah, I am thinking about that 07:45:22 Yeah, this melding of C and forthish and considering OUTPUT as well as read & run 07:46:14 On one level we still have C - and maybe asm - primitives, and another level is pcode "lists" - and all of it portable. 07:46:57 Yep. That's standard scripting fare though, non? 07:47:16 It's not lisp, or forth - fig OR ans - or pforth, or anything else. And, bound to my plan for a simple shell under a Metabuilder, this makes it all rather intriguing. 07:48:18 One of the comments I've read is that forths trade parsing-complexity for lexing. And I find neither really satisfying. 07:49:09 in fact, it makes me wonder if you need a lexing-stack AND a parsing-stack. 07:50:20 or maybe a lexer/parser stack for input and a datastack for ops 07:50:46 Forth doesn't really need to lex anything, other than looking up in the dictionary. 07:51:04 But yea, an input stack is useful for nested file inclusions and such. 07:51:08 Meanwhile, yeah.. paradigm-shift... We are trying to relocate into a new place in the universe 07:51:08 Forthy uses one. 07:51:23 madwork: I'd diagree 07:51:26 disagree 07:51:44 The typical lexer for forths is downright dumb 07:51:53 It's all that's needed. 07:52:06 so, I have to wonder how my .l file compares. 07:52:25 no, it isn't - which is my point 07:52:39 forcing the whitespace issue SIMPLIFIES the CODE 07:52:48 but not the source 07:52:53 interesting 07:52:54 --- join: Herkamire (~jason@c-24-218-95-147.hsd1.ma.comcast.net) joined #forth 07:52:55 --- mode: ChanServ set +o Herkamire 07:53:02 lo, herk 07:53:17 hi hi 07:53:32 I've given some thought as to the merits of per-character parsing, executable delimiters, etc. It would allow you to extend the language more easily. 07:53:51 madwork: you have to force yerself to think in terms of lex/yacc and char-by-char, yeah 07:54:00 But it's not necessary to talk to the machine, which is what Forth aims at doing first and foremost. 07:54:11 so, I have to wonder if the forth 'parse' is sufficient. 07:54:34 madwork: sure, and I agree - we CAN live with "as-is" 07:54:37 You can always write a parser on top of Forth to do what else you need... ie words like ( 07:54:52 right, I'm pondering that. 07:55:30 --- join: tathi (~josh@tathi.bronze.supporter.pdpc) joined #forth 07:55:35 You've got control of the input stream, so you can write the appropriate words to do what you want. 07:55:41 I have no real prob thinking 'lexing' - I have probs when I hit yaccish "parsing" 07:56:22 I definitely agree forthish "parsing" - L-R immediately - is a shitload easier 07:57:03 but the whole delimiter versus allowed issue is where I was glaring. 07:57:31 Yep. 07:59:42 I'm almost thinking about a cascading-list of "does this match?" read/putback. 07:59:58 I really like being able to use a bunch of the symbols in word names 08:00:14 especially - and ? 08:00:17 sure, but then the parser would remain simple 08:00:25 sorry, "lexer" 08:00:28 and @ and ! 08:00:37 Your delimiters can be scoped via vocabularies. 08:00:51 madwork: yeah, that's what I was thinking 08:01:24 Herkamire: I can agree I like flexibility... I also hate being forced to space/tab all the damned time. 08:01:32 You could flag words as being delimiters or not, so that the parser searches the dict for each character its parsing. 08:02:02 Further, we could also (finally) support such as "foo::bar" or "foo->bar" 08:02:04 PoppaVic: you're planning on going to an infix syntax then? 08:02:09 tahi 08:02:09 Then the delimiter can execute, do whatever it needs to do. 08:02:12 no. 08:02:19 right, madw 08:02:20 --- join: sproingie (~chuck@64-121-15-14.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth 08:02:34 Delimiters should be allowed to be multiple characters, too. ie. your :: 08:02:44 madw: the voc can even specify delimiter sets/rules 08:03:00 Yea, or the delimiter itself, since it's a word, it can have code too. 08:03:32 tathi: mostly, I'm brainfarting and noodling over ancient mindsets and porting/flexibility 08:03:47 You really don't have to do anything extra special to support it, other than tweaking the parser a little. 08:04:16 madw: well, I often use strchr() in reverse - and sscanf() as well. 08:05:14 yeah, basically: writing a lexer/parser set of words and making 'vocs' (or something new) use them. 08:05:59 1) the core is deferred/vectored; 2) the new "scope" would offer alternatives to those defaults. 08:06:11 to be able to search for multiple char sequences, you'll have to set asside certain chars as delemeters, you can no longer just search the dictionary for every character 08:06:13 interesting 08:06:25 it would take too long to search the dictionary for every character seqence in each word 08:06:30 right, herk - this is understood 08:06:57 no,no... You missed the pt 08:07:02 you trying to write a scope resolution operator? 08:07:15 Well, multiple-char delimiters can be handled in the code of single-char ones. 08:07:41 you'd write std lexer/parser words ala' forth. you COULD add rules to vocs/whatever - it would depend on your search order. 08:07:53 ie. the : delimiter parses ahead for another : to match the actual delimiter as :: 08:08:01 yep 08:08:25 you might even flag the pseudo-voc as "infix" 08:08:28 If the delimiter doesn't match, then the input is rewound and regular word-finding continues. 08:08:41 Well just name it infix and have infix parsing words in it. 08:09:06 This is the diff between our beloved interpreter and real "compiling" 08:09:24 infix{a=2+3} 08:09:31 Further, you might lex first - buffering finds - to run all sequencial 08:09:51 oh, good idea :) 08:10:00 (the : searching for another : thing, clever) 08:10:07 hm. i've wondered about a language that let you flip between concatenative and applicative 08:10:10 This is how I was coding my minish 08:10:32 Executable delimiters. :) 08:10:36 haskell is almost like that when you do point-free style, but haskell comes with a few, ah, restrictions 08:10:55 We've far too many programmers with far too much experience with far too much time - to suffer a flat-out "this is the way it is". 08:11:36 madwork: that tag-vtable? how about a '.' function and such? ;-) 08:11:39 FIPS lets you push arbitrary extra parse steps and define prefixes that can be "executed" 08:12:11 well, look... Lexing can be simple (forth) or complex (c). 08:12:34 lexing is pretty simple in C too. parsing not so much 08:12:39 But, I still fail to see why the hell we can't add complexity here, but not there, etc. 08:12:42 forth requires no lookahead 08:12:48 right 08:13:22 matter of fact, forth doesn't even lex. it's part of the parser 08:13:32 the above example of math was fairly simple 08:13:37 I know 08:14:41 The infix/adjacency idea is worth considering. As is a 'stack' of lexers. 08:14:41 i suppose feeding words at a time instead of chars counts as lexing tho 08:15:11 See? we presume the SYSTEM gets "a word" 08:15:46 but, why would you not as easily presume a voc fetches a "word"? 08:15:50 well that system is typically "softcoded", some forth to scan the TIB 08:16:07 yeah, antiquated concepts 08:16:15 I don't even consider a TIB 08:16:27 I either input or don't 08:16:28 eh, TIB's just an antique term for input buffer 08:16:41 pretty much every parser uses one 08:16:47 well, the ancient TIB was a place as well 08:17:34 I simply think it's time to get past the artifacts and see where to get shit up to speed 08:17:36 sure, the parser's just very reflective. perl could probably get at the input stream address if it wanted to 08:17:54 I wouldn't trust perl with my neice 08:18:00 niece, two 08:18:19 BUT, neither here or there. 08:18:35 don't imagine python could... no source filters or BEGIN blocks or the like 08:18:48 The first issue is: I love 'words' and 'vocs' and even 'wordlists' - extensibility. 08:19:13 just curious, what's the diff between vocs and wordlists? 08:19:14 But, as written, most forthish stuff is dead dumb as far as lexing. 08:19:46 An' dats the way we's likes it! 08:19:50 sproingie: according to what I see in gforth: a wordlist is an anon-ID any program can use, but a voc sets context, etc. 08:19:55 forth's parser is dead dumb .. that's why it parses so fast 08:20:24 * PoppaVic sighs 08:20:38 I have issues with the every-whitespace gig 08:20:38 it's about as smart as a macro assembler, which is usually pretty fast too 08:20:52 ?? 08:20:57 asm uses embedded comma's and such 08:21:09 we are right back where I went earlier 08:21:10 sure, but beyond that it's still pretty dumb 08:21:52 yeah, well, you're kind of talking to a room of people who mostly *don't* have issues with the whitespace thing 08:21:55 so what do you expect? 08:22:12 the whitespace thing in ... forth? 08:23:16 Most language syntax is just personal preference and confusion. 08:23:22 tathi: not much, but I try 08:23:37 yeah 08:23:51 How many folks here use a forth as their shell? 08:23:55 my only bugaboo with whitespace in forth is strings. forth, being untyped, doesn't really even have strings 08:24:10 * madwork raises hand. 08:24:16 sproingie: nor C, we've argued that for weeks 08:24:33 madwork: really? which is yer nix shell? 08:24:37 sproingie, my little Forth-in-C toy has 'em. 08:24:49 right, C doesn't either. C++ does because the type system extends to std::string like any other object 08:24:55 no 08:25:04 C++ fakes it with classes 08:25:10 PoppaVic, I use bash. But I've written some shell-like stuff for Forthy that I use at work, for remote interactive testing and debugging. 08:25:12 c++ classes are not "fake" 08:25:12 there is no "string type" 08:25:15 they are part of the type system 08:25:26 no, sorry 08:25:29 they are no more fake than "int" 08:25:40 no, sorry, go back to school and learn what a type system is 08:25:48 ok, ok.. C++ rules.. I'll pass 08:26:22 madwork: yeah, I expected that 08:26:35 factor has strings too. 'course it has a full-blown type system with a numeric tower, generics, and predicate types 08:26:47 that's nice 08:27:02 arguably it's a wholly different language than forth 08:27:12 it's more like a concatenative scheme 08:29:56 Slava is a mad genious. :) 08:30:58 gotta get going ... 08:30:59 * sproingie & 08:31:03 bah, he just works hard. :) 08:31:38 Yea, I wish I had that kind of time and energy. 08:31:52 (him and crc) 08:31:59 yeah, me too. 08:32:30 hmm...I think crc might use retroforth as a shell. 08:32:48 but then, I gather he uses a really minimal system all 'round. 08:34:41 aaa! stupid bastards. 08:34:59 prob is, (to my mind), a shell has at least 3 purposes; and most forth focus on one or MAYBE 2 08:35:01 hate tarballs that spew files all over your current directory 08:35:12 good thing I checked 08:35:22 the culprit: ficl 08:35:23 Herkamire: oy... not subdired? 08:35:32 yeah, mc is handy 08:35:39 the site doesn't seem to say what it's like to use, so I guess I'll have to try it 08:36:02 I have it around, but I never tried to _use_ it 08:36:42 The 3 purposes being... ? 08:37:10 programming; generic-programming; IPC 08:37:37 --- quit: swalters (Read error: 104 (Connection reset by peer)) 08:37:54 --- join: swalters (~swalters@2416457hfc118.tampabay.res.rr.com) joined #forth 08:38:06 I get sort of tired of folks treating shells as generic-languages 08:38:40 whereas the shell is supposed to facilitate execution, and IPC 08:39:23 but, that's me.. after years of wondering why folks like sticking their dicks in the disposal. 08:39:41 rrrr... 08:39:48 ficl doesn't seem to be documented at all 08:40:02 I don't see anything anywhere about how to actually execute programs 08:40:04 ficl is weird, maybe the docs are another tarball? 08:40:21 there's no documentation section on the website 08:40:26 well, ficl is SUPPOSED to be 'embedded' - lord knows 08:40:29 the tarbal has a doc directory, but it's just a dump of the website 08:40:34 ugh 08:41:10 ANother reason it was never seriously adopted, eh? 08:41:17 hows business herk 08:41:27 pretty depressing 08:41:36 business is good 08:42:13 well, hell... I guess I'll go take a snooze and recogitate. Stay well, folks. 08:42:17 --- quit: PoppaVic ("Pulls the pin...") 08:44:46 recogitate 08:49:42 ficl's docs aren't that great, but it ficl sees some real use 08:49:45 bootforth comes from ficl 08:51:27 what docs? 08:51:31 I couldn't find any 08:52:53 the website looks to be about it 08:52:58 like i said, lousy docs 08:53:20 don't know what beyond bootforth uses it 08:53:53 I really didn't see anything. like how to execute a program 08:54:09 i think there's an interpreter 08:54:18 i forget. been a long time since i've used ficl 08:54:30 never did anything with it other than fire it up 08:54:43 enter 2 2 +, quit, you get the idea 08:55:41 yeah, I don't need another forth system 08:55:54 I've got my own, and gforth 09:04:26 --- quit: sproingie ("Konversation terminated!") 09:31:45 --- quit: onetom (Read error: 148 (No route to host)) 09:42:55 --- join: onetom (~tom@ns.dunasoft.com) joined #forth 10:09:25 * madwork has played with FICL a fair bit, and browsed its source code. 10:09:30 poor forth, nice but everytime wrongly implemented. 10:10:36 on systems with an OS. 10:10:52 :'( 10:11:10 Instead of being the OS. 10:11:12 someday someday 10:12:03 Somedaaaaay over the Forth-bow... 10:13:22 forth has some big advantages in comparison with other interpreted languages, why don't using them? 10:14:13 Because people think it syntax is too backwards. 10:14:30 too backwards? 10:14:39 Plus, they don't want to juggle the stack, it hurts their brains. And, "true" forthers won't allow the use of variables. 10:14:42 Yea, RPN. 10:14:47 "Backwards." 10:15:42 hey, I think RPN is much easier to read than infix equations. 10:16:04 Sure it is. 10:16:17 But, you can't convince people who haven't first learned RPN that. 10:17:50 that must be very lazy and stupid people... 10:18:44 to learn that it only takes 1 minute, for the slow one. 10:18:50 Yea. 10:18:57 Still, the stack juggling confuses them more. 10:19:54 hey, me sometimes also. but thats a good way to train ones brain. 10:20:42 Yep. But anyway, variables make it easier for the brain. 10:20:52 ie. locals 10:20:58 BUT, of course most Forthers shun them. 10:25:33 because they are 'easy' and that isn't a challenge. :) 10:26:00 And beginners to programming don't want a challenge, they want to understand. 10:26:16 So, such elitist ideas deter people from using Forth. 10:26:27 Also, when you want to be productive, you don't want a challenge. 10:26:39 You want the challenge to be in solving the problem, not fighting the language. 10:29:52 I think forth isn't a language for the real (dumb) beginner, there are a lot of other languages out there which claim to be that language. and so I think forth balances that out. :) 10:30:37 bs 10:30:51 bs? 10:30:52 If that's the case, then they have no interest in learning Forth afterwards. 10:30:53 forthers use variables 10:31:03 Herkamire, sorry, I meant locals. 10:31:05 true forthers don't use _local_ variables 10:31:08 ahh, ok 10:31:23 * Herkamire does the happy dance 10:31:28 Heh. 10:31:40 >R R@ R> is as close as they like to get. ;) 10:31:50 people aren't quick to switch to forth because it involves a switch in the way you program 10:31:55 not just learning syntax 10:32:13 forth is extremely easy to learn compared to say C 10:32:29 Yep. 10:32:41 but I dare say it's harder to become a good forth programmer if you know C already 10:32:54 * madwork is a C programmer. ;) 10:33:01 me to... 10:33:01 And yea, old habits die hard. 10:33:08 dunno if that's true, but I've seen some horribly forth that looks like C 10:33:26 quite possible it's not true, I know C first 10:33:29 And in some cases, I just don't care about the purism, and some code to be either readable or finished. 10:33:51 s/and/and want/ 10:34:04 BASIC -> C -> lots (perl, php, bash, C++, python, etc) -> forth 10:34:12 my path through life ;) 10:34:45 yeah, I still run into a lot of compromises 10:35:08 BASIC -> Pascal -> C -> C++ -> C -> Forth 10:35:10 :) 10:35:17 heh 10:35:33 C++ annoys me. 10:35:38 haha and my path: div -> java like game language -> java -> C++ -> C -> (html, php, etc.) -> assembler -> forth 10:35:40 I did a bit of that C -> C++ -> C 10:36:21 yeah, I can't stand C++ anymore 10:36:28 I find that C++ is just a language full of restrictions, touted as a language of freedoms. 10:36:30 * madwork shrugs 10:36:38 when I was learning C I was a bit intoxicated by the possibilities of C++ and learned a lot 10:37:03 but then I found out that it doesn't work like it should, and it creates too many other problems, like it's impossible to look at the code and find out what is actually going to get executed in what order 10:37:20 I like the class system of C++, much more than that of smalltalk. 10:38:22 I like C's class system. 10:38:30 ie. function pointers. 10:38:31 :) 10:38:40 me too. 10:39:12 C++ coders seem terrified of them. Oh no, it might break encapsulation! It's too direct! It needs an accessor! Blah blah blah... 10:39:41 under some conditions I would agree to that. 10:39:59 Yet, I can have a more dynamic run-time polymorphism when I can directly control the interfaces to any data in whatever way I want. 10:40:24 with forth? 10:40:28 C 10:40:31 (and of course Forth) 10:40:41 But aside from all that, C++ programs seem to end up being more complicated than necessary. 10:41:09 The code becomes convoluted, er... "clever" . 10:41:32 do you mean 'complicated' in a sense of too object orientied? 10:41:56 that, and hard to read, doing too many unnecessary things, etc. 10:42:16 Much of the cleverness is simply working around restrictions. 10:42:31 And then there's the excessive use of new/delete... such a waste. 10:43:16 Don't even mention templates/STL. ;P 10:43:23 Convolution++ 10:43:41 I don't want to know how many times these constructs are too often used in performance hungry applications like games. 10:44:52 Yep. And how much extra bloat the game experiences, thus requiring 8x more RAM. 10:45:19 "Oh, but RAM is abundant these days!" 10:45:41 hate it when people say that computers/speed/ram is cheap 10:45:45 Imagine if we said the same about food... "why are you just eating 1/4 of your food, and throwing the rest out?" 10:45:57 "Oh, it doesn't matter, it's so cheap!" 10:46:01 yep, everytime I hear this saying I'd like to kick some asses. :) 10:46:02 ACTUALLY, I don't want to buy a new computer every couple years because they're "cheap" 10:46:10 Me either. 10:46:14 spending hundreds of dollars to buy something you already have is not "cheap" 10:46:34 A computer system should be enduring, not cheap. 10:46:48 * madwork misses the 80's computer era. :'( 10:47:00 computers are incredibly fast _now_ 10:47:22 with very few exceptions, anything that is slow, is coded badly, or being used for something it wasn't designed for 10:47:40 My C64 still booted 50x faster than my Windows/BSD etc. box now. 10:47:41 and there is absolutely no excuse whatsoever for the human interface to lag 10:47:51 hey, and even my 750 mhz duron is incredibly fast compared to that power of that time 10:48:10 yep, like the good old amiga. 10:48:40 AmigaOS... nice sufficient OS/GUI. 10:50:23 I had never an amiga, but screenshots looked much more acceptable than most of modern oses today. 10:51:02 I've got a couple in the basement. 10:51:20 Enjoyed my Amiga quite a bit. 11:03:35 today we are wasting the power of computers. 11:07:28 So, we need slower computers then. ;) 11:07:57 heh 11:08:46 In Soviet Russia, computers waste you? 11:09:56