00:00:00 --- log: started forth/07.01.27
00:23:31 --- quit: JasonWoof ("off to bed")
00:33:48 --- quit: nighty (Remote closed the connection)
01:58:42 --- quit: virl (Remote closed the connection)
02:50:23 --- join: snowrichard (n=richard@12.18.108.130) joined #forth
02:50:27 <snowrichard> hi
03:04:29 --- join: Cheery (n=Cheery@a81-197-54-146.elisa-laajakaista.fi) joined #forth
04:10:14 --- quit: snowrichard (Remote closed the connection)
05:01:46 --- quit: cmeme (Connection reset by peer)
05:02:20 --- join: cmeme (n=cmeme@boa.b9.com) joined #forth
05:54:18 --- join: Jules__ (n=jjacobs@cp550544-a.landg1.lb.home.nl) joined #forth
06:24:42 --- part: Jules__ left #forth
06:54:05 --- join: Raystm2- (n=NanRay@adsl-68-93-122-194.dsl.rcsntx.swbell.net) joined #forth
07:09:59 --- quit: Raystm2 (Read error: 110 (Connection timed out))
07:18:09 <Quartus> Hey.
07:25:26 <grub_booter> hi
07:25:36 <Quartus> How goes the wall o' videos?
07:25:52 <grub_booter> :-) - pretty good
07:26:07 <grub_booter> actually going to buy a projector... :-)
07:26:17 <grub_booter> got a huge clear wall in my new office...
07:26:19 <Quartus> so you can use the actual wal?
07:26:46 <grub_booter> yup - with the blinds down, the room is amazingly dark...
07:29:31 <grub_booter> projectors are hellishly expensive though - cheapest i found today [in town] was 899 euro - am averse to buying that kinda thing online (risk of transit damage, possible problems with parts/bulbs and the fact that i like talking to salesman [and being an awkward customer :-)])
07:29:57 <Quartus> heh
07:30:06 <grub_booter> i've hit the grumpy old man stage of my life...
07:30:10 <grub_booter> and it's great :-)
07:30:25 <Quartus> :)
07:34:31 <Raystm2-> I'm with ya, brother.
07:34:42 --- nick: Raystm2- -> Raystm2
07:35:44 <Raystm2> No I'm not. Nan's home from work and expects to snuggle herself to sleep so... brb. :)
07:36:08 <grub_booter> heh :-)
07:36:51 <grub_booter> in all seriousness, i find there's nothing quite like winding up salespeople - esp. the fresh faced types in the big chain stores - they're generally clueless and lack any kind of initiative :-)
07:40:02 <grub_booter> (the last time i tried it, i lost though :-/ - i wanted to buy a laptop in antwerp, and for some reason, they only stock azerty keyboard types... just over the border in holland, they sell qwerty... all very odd, esp. since the antwerp side of belgium also speaks dutch... got nowhere fast though, and ended up taking a trip over the border myself... and yeah, i did buy it from the same chain... sigh..)
07:40:52 <grub_booter> mind you, all fuel for my grumpiness which just makes the next time even more fun :-D
08:28:20 --- quit: crest_ ("Leaving")
08:31:23 --- join: virl (n=virl@chello062178085149.1.12.vie.surfer.at) joined #forth
08:41:26 --- join: Crest (n=crest@p548968F2.dip.t-dialin.net) joined #forth
09:28:00 --- join: BirdReynolds (n=mhx@f233149.upc-f.chello.nl) joined #forth
09:29:04 --- quit: BirdReynolds (Client Quit)
09:30:38 --- join: BirdReynolds (n=mhx@f233149.upc-f.chello.nl) joined #forth
09:31:01 --- quit: BirdReynolds (Client Quit)
09:34:11 --- join: BirdReynolds (n=mhx@f233149.upc-f.chello.nl) joined #forth
09:35:35 --- quit: BirdReynolds (Client Quit)
13:27:36 --- join: JasonWoof (n=jason@c-71-192-30-169.hsd1.ma.comcast.net) joined #forth
13:27:36 --- mode: ChanServ set +o JasonWoof
13:30:44 <Quartus_> hey
13:33:46 <JasonWoof> hi :)
13:34:21 <Quartus_> what up, j-dawg?
13:34:36 <JasonWoof> woof!
13:34:59 <JasonWoof> I'm deciding between babysitting and going to a Lindy Hop dance with a cool little lesson at the begining
13:35:21 <JasonWoof> I think the weather just tipped the scales
13:35:31 <Quartus_> heh
13:35:49 <JasonWoof> and the check for $250 in my pocket certainly helps
13:36:07 <Quartus_> big money?
13:36:48 <JasonWoof> what's big, is that for once I don't need it for my end-of-the month expenses
13:37:23 <JasonWoof> it's bigger than usual too, the previous two weeks it was $151.25
13:38:27 <Quartus_> good deal
13:38:59 <JasonWoof> (which got me worried that I'd printed the wrong invoice)
13:39:21 <JasonWoof> but it turns out that I just did the same number of hours at the same rates
13:40:11 <Quartus_> heh
13:48:30 --- quit: Quartus_ (Read error: 131 (Connection reset by peer))
13:56:07 --- join: frunobulax (n=mhx@f233149.upc-f.chello.nl) joined #forth
13:58:25 --- quit: frunobulax (Client Quit)
14:07:30 --- quit: Cheery ("Download Gaim: http://gaim.sourceforge.net/")
14:54:43 --- join: Quartus_ (n=Quartus_@209.167.5.1) joined #forth
14:54:43 --- mode: ChanServ set +o Quartus_
14:56:59 <Quartus_> did I miss anything good?
14:57:27 <Crest> you missed nothing
14:58:13 <Crest> at least no in this channel
15:03:02 --- join: snoopy_17 (n=snoopy_1@dslb-084-058-158-191.pools.arcor-ip.net) joined #forth
15:03:37 <Quartus_> ho-k
15:04:17 * grub_booter received a funny email exchange today...
15:05:17 <grub_booter> revolved around a job offer i turned down...
15:05:40 --- join: slava (n=slava@CPE0080ad77a020-CM000e5cdfda14.cpe.net.cable.rogers.com) joined #forth
15:05:40 --- mode: ChanServ set +o slava
15:06:13 <Quartus_> Oh?
15:06:17 <Quartus_> hey slava
15:06:47 <Quartus_> you missed some classic poppavic blither in ##c today
15:07:14 <slava> oh, darn
15:07:14 <grub_booter> mebbe i'll post the rather juiciest quote in private - it kinda makes your hair curl...
15:07:56 <Quartus_> heh
15:15:27 <JasonWoof> whatia think of my new business card design: http://jasonwoof.com/downloads/card_v1.html
15:16:22 --- quit: slava ()
15:16:46 <Quartus_> I like the ninja throwing star
15:16:52 <JasonWoof> :)
15:17:39 <JasonWoof> I tried pasting in the start from my website border
15:18:05 <JasonWoof> but it seemed too simple in a not-terribly elegant way
15:18:32 <JasonWoof> I'm starting to over-use dashes
15:18:42 <Quartus_> business cards are a tad out-of-date nowadays
15:18:43 * JasonWoof tries to control himself
15:19:17 <JasonWoof> they work for me
15:19:22 <JasonWoof> I don't give that many out
15:19:33 <JasonWoof> but I think it makes me look like I have my *#$@# together
15:19:57 <Quartus_> I guess.
15:20:00 <JasonWoof> people start scrounging around for a pen or something, and I hand them a card
15:20:32 --- quit: Snoopy42 (Read error: 110 (Connection timed out))
15:20:38 --- nick: snoopy_17 -> Snoopy42
15:22:06 <JasonWoof> I like having little slips of paper in my pocket with my phone number and e-mail address on them
15:22:48 <JasonWoof> and I think it pays to have it look professional when I'm giving one to a prospective client
15:23:42 <Quartus_> whatever helps fill the wheelbarrows with money :)
15:24:11 <JasonWoof> I'm not dancing on tables, I'm making and hosting websites :)
15:24:53 <Quartus_> I dated a dancer. She had a business card. :)
15:25:03 <JasonWoof> hehe :)
15:25:04 <grub_booter> heh
15:25:15 <JasonWoof> lol
15:25:38 <JasonWoof> I was refering there to the wheelbarrows, not the cards
15:26:06 <Quartus_> ah
15:26:55 <JasonWoof> heh, xmms scipped when I set my clock back 2 minutes
15:27:46 <JasonWoof> my alarm clock was back two minutes, and my computer was ahead 2 minutes
15:28:23 <grub_booter> that's kinda odd tbh - most sound card drivers provide a better clock than the system one..
15:29:03 --- join: Raystm2- (n=NanRay@ppp-70-248-35-240.dsl.rcsntx.swbell.net) joined #forth
15:32:07 <grub_booter> i've got hooked on amarok these days
15:32:19 <JasonWoof> what's that?
15:32:46 <grub_booter> a kde audio player
15:32:57 <JasonWoof> ahh
15:33:09 <grub_booter> it's the only kde app i run
15:33:11 <JasonWoof> I don't particularly like xmms
15:33:18 <JasonWoof> but it seems to work better than the others I've tried
15:33:23 <grub_booter> xmms is showing its age
15:33:34 <grub_booter> i wrote a plugin for it once...
15:34:03 <JasonWoof> I ran konqueror for a while
15:34:19 <JasonWoof> then firefox stopped being so broken at version 2.0
15:34:29 <JasonWoof> and now I don't use it much
15:35:44 <grub_booter> never been very impressed with kde apps (or kde in general) - too much emphasis on frills - not enough on basics
15:36:48 <grub_booter> can appreciate why people like it, but prefer the gnome style (with a couple of exceptions - spatial for example)
15:38:13 <grub_booter> but amarok is a bit of an exception - kinda pretty and relatively intuitive 
15:38:21 --- quit: Raystm2 (Read error: 104 (Connection reset by peer))
15:38:28 <grub_booter> (still a bit excessive though)
15:38:38 <Quartus> "I.... Am... AMAROK!"
15:38:39 <JasonWoof> looking cool is cool... but not if it's instead of working well
15:39:07 <grub_booter> ah - no - works pretty well
15:40:05 <JasonWoof> sheesh, it requires xinelib
15:41:19 --- join: arke__ (n=chris@pD9E04F19.dip.t-dialin.net) joined #forth
15:41:45 --- nick: arke__ -> arke
15:42:12 <grub_booter> you can run it via a gstreamer back end as well
15:42:15 <JasonWoof> I don't want my music player to play movies
15:42:28 <grub_booter> it doesn't :-)
15:42:41 <JasonWoof> why does it need xine-lib and ffmpeg to build then?
15:43:02 <JasonWoof> on gentoo
15:43:14 <JasonWoof> whatever, that's OK
15:43:18 <JasonWoof> I'm going to try it anyway
15:43:25 <grub_booter> that's kinda normal - most apps gravitate to a multimedia framework of one form or another
15:43:39 <grub_booter> saves wheel reinvention
15:43:51 <JasonWoof> yeah, and makes them take 10 years to start up
15:44:49 <JasonWoof> it's hard to avoid when you're writing an app that supports 18 different file formaths though
15:45:00 <JasonWoof> formats
15:45:01 <grub_booter> yup - that's the price of reuse
15:45:28 <JasonWoof> dynamic linking is a killer
15:46:27 <grub_booter> hmm - don't think so - most of these frameworks have a relatively sane small core payload, and additional stuff is loaded on demand
15:46:46 <JasonWoof> cool
15:47:01 <JasonWoof> glad to hear that
15:47:08 <grub_booter> would be slower to load a static link with everything, than a dynamic load on what you need
15:47:26 <JasonWoof> yeah, if it's set up right
15:47:34 <grub_booter> yup
15:47:37 <JasonWoof> what's really slow is dynamically linking everything
15:47:47 <JasonWoof> I tried one player that took twice as long to start up as firefox
15:47:59 <JasonWoof> I thought it was broken
15:48:04 <JasonWoof> then later the UI popped up
15:48:36 <Quartus> Isn't sourceforge 98% badly-written mp3 players?
15:49:13 <Quartus> Some of which are undoubtedly slow to start up, it's part of the 'bad'. :)
15:49:40 <JasonWoof> heh
15:49:51 <grub_booter> heh - i've been working on one media player with a very slow start up time - but that's down to the fact that python is used to drive the app
15:50:00 <JasonWoof> there's a lot of graphics libraries and game frameworks too
15:50:18 <Quartus> well sure. If it's python (or worse, ruby), you can expect slowness.
15:50:40 <grub_booter> yup - you gain flexibility, lose speed
15:50:47 <grub_booter> always a trade off
15:50:50 <JasonWoof> yeah, I think that's why gentoo is slow as hell too
15:51:00 <Quartus> I don't know about the flexibility gain.  It's the flavour of the month, and it's slow.
15:51:03 <JasonWoof> not worth it in my book
15:51:45 <grub_booter> depends on what the app is - i've been playing with a python based media server (very fast start up time)..
15:52:10 <JasonWoof> I wrote a script in ruby to find an e-mail address in my address book
15:52:16 <JasonWoof> it took way way too long to start up
15:52:19 <grub_booter> ui based stuff (qt in particular) - much slower
15:52:33 <JasonWoof> so I turned it into a little daemon
15:52:38 <JasonWoof> (which was amazingly easy)
15:52:52 <JasonWoof> that kills the startup time, and the time spent parsing my address book
15:53:05 <JasonWoof> trouble is, it usually get's swapped out before I use it again
15:53:14 <Quartus> both huge and slow, eh?
15:53:37 <grub_booter> indeed - same advantage with the media server - daemon based process, works on demand
15:53:38 <JasonWoof> so I end up waiting just as long for it to be swapped back in from virtual memory as I spent waiting for the startup+parsing time
15:54:49 <JasonWoof> at least with the daemon if I'm sending to a few people, the subsequent searches are quick
15:55:51 <grub_booter> yup - and the flexibility of scripting languages allows easy migration between styles of execution
15:56:09 <grub_booter> lose some, win some
15:56:27 <Quartus> JasonWoof is pointing out that it sucks in both styles.
15:58:14 --- quit: arke_ (Connection timed out)
15:58:40 <grub_booter> not really - depends on the task...
15:59:27 <grub_booter> if your daemon process is in high demand, it remains responsive
15:59:31 <Quartus> Which tasks are better served by a bloated and slow language implementation?
16:00:33 <grub_booter> well, i would generally look at is a step on the way to defining an optimal solution - a fully featured prototype really
16:01:23 <grub_booter> you get flexibility to change things round quickly - clients and servers become well defined, and can thus be reimplemented on a needs basis
16:02:03 <grub_booter> and sometimes you find that part of a system really doesn't need to be changed at all...
16:02:24 <grub_booter> ie: it's fast enough to satisfy the demand
16:03:00 <Quartus> which wouldn't come up as an issue at all if you instead prototyped in something, oh, say, an order or two of magnitude faster.
16:03:34 <grub_booter> ... and potentially an order of many times that more time to develop
16:03:45 <grub_booter> like i said - it's a trade off
16:04:31 <grub_booter> scripting tools provide rapid development and are easier to make wholesale sweeping changes in
16:04:49 <grub_booter> once you know what you want, that is the time to optimise
16:04:54 <Quartus> You're saying that in #forth.  Forth is known for rapid development times.
16:05:01 <grub_booter> :-)
16:05:01 <Quartus> And it's fast, and small.
16:06:14 <grub_booter> indeed - and it's also a high level language which suits prototyping (and optimisation at the same time) - but it's a niche language... i like it, you like it... many don't even get it
16:07:06 <Quartus> Its relative popularity doesn't exclude it from being a counterexample.
16:07:40 <grub_booter> and again, that's a trade off - it's easier to put a (say) java coder in front of ruby or python than it is in front of (relatively complex) forth
16:08:07 <JasonWoof> I'm just saying, in the case of my address-book lookup thing, neither method worked well
16:08:15 <JasonWoof> I need it in a language that can actually do something in 100ms
16:08:46 <Quartus> grub_booter, if you're talking about what will make an incompetent coder most productive... I suggest a change of profession.
16:08:54 <grub_booter> heh
16:09:18 <grub_booter> unfortunately, the world is full of incompetent coders
16:09:36 <Quartus> Which makes my suggestion more relevant.
16:09:43 <grub_booter> and sometimes, you have to work with them :-/
16:10:23 <grub_booter> well, no, not really... reality is never an ideal
16:10:48 <Quartus> If there's a program to write, Ruby is going to lose out on the grounds that it's slow (really slow) and bloated.  It's not going to be the language of choice because it's the only thing Lumpy Rutherford knows how to code in.
16:11:20 <Quartus> If that's the only argument for it, we need to fire Lumpy.
16:12:07 <grub_booter> but if the problem is well defined enough to defined enough such that given a certain number of inputs and an expected output, Lumpy can probably do the task... 
16:12:36 <grub_booter> and the implementation is disposable
16:12:38 <Quartus> Lumpy can learn a programming language that isn't the IT equivalent of blunted scissors and Crayolas.
16:12:46 <grub_booter> :-)
16:13:33 <Quartus> You can prototype in whatever you like, but if you have to prototype in something other than your target language, you're doing the work twice.
16:13:45 <Quartus> Says something about your choice of target language.
16:13:48 <grub_booter> ah - define 'you'?
16:13:56 <Quartus> You. Lumpy. Anybody.
16:14:53 <Quartus> A language's suitability for rapid prototyping need not be at odds with its performance.
16:17:31 <grub_booter> if the project is large, 'you' can be 20 people... it is better to have all 20 being productive on specific tasks which interoperate to make the whole than to force many of them to become unproductive blobs (losing confidence along the way as they struggle to take on a different mechanism to code in) - give em small well defined tasks, give em freedom to complete it in what they know, then mop up afterward once the whole system is proven
16:18:33 <Quartus> "Ok boys! Set to it!  Pick any languages you like, write part of it fast!  We'll paste it all together later."
16:18:48 <Quartus> I can believe it.  It's stupid, but I can believe it.
16:18:56 <grub_booter> indeed - that's the corporate world...
16:19:03 <grub_booter> it works precisely like that
16:19:06 <Quartus> And this is your argument for why Ruby should be used for prototyping?
16:19:29 <grub_booter> it's my argument for why it shouldn't be disallowed :-)
16:20:32 <Quartus> Even embracing your argument, I can't think of a worse way to manage a team of incompetent programmers than to let each one pick his own implementation language and try to knit them together afterward.
16:20:44 <grub_booter> it all depends on the level of interoperability between the components (and languages) and the definition of the task
16:21:58 <grub_booter> and in all seriousness, when you're looking at the corporate world, this is common practice - it's not intentional - it just happens - components are developed over many, many years...
16:22:16 <grub_booter> you get mainframe apps written in cobol in the 60s and 70s...
16:22:37 <Quartus> You're changing what you're talking about.  Prototyping a new app is not the same thing as incrementally adding to an existing app over a period of 30 or 40 years.
16:22:37 <grub_booter> interoperating with client/server rpc based apps from the 80s
16:24:49 <grub_booter> ah - but you don't have the flexibility... rewriting what's there is not always an option - just as architecting the perfect homogeneous system isn't either (due to lack of resources in the right technical sphere, time, budget, whatever)
16:25:20 <grub_booter> you can theorise about a perfect world if you wish...
16:25:27 <grub_booter> won't make it happen though
16:25:49 <Quartus> Ok. So various constraints may cause you to pick a crappy language for prototyping?  I'll buy that.
16:26:23 <grub_booter> and i would argue that it's better to embrace it than let it bite you on the arse :-)
16:26:48 <Quartus> Doubtless overlapping with the constraints that caused you to hire incompetent programmers, and the personal constraints that make it seem like a good idea to re-write the app in a different language later.
16:27:35 <Quartus> I hope you see the absurdity in suggesting you need the blunt scissors for your app developers, but that those same developers will have the skills to optimize the required components later.
16:31:05 <grub_booter> well, i don't really - most (complex) systems are built up over a long period - tech changes almost as often as the staff doing the task do (in fact, new staff tend to bring in new technology as things evolve)... the realistic view is that while 'you' may have a perfect vision of what you're trying to achieve in a single unified homogenous optimised environment... the chances of your replacement (and you will have at least one, believe me 
16:31:41 <Quartus> If you've got somebody competent to do the second-generation rewrite, hire him up front.  Don't give Lumpy a copy of Ruby and a lollipop and hope for the best.
16:33:41 <grub_booter> like i said - it's irrelevant - you won't have enough control.. there is one alternative though - rapidly prototype the complete system (using all available skill sets - including Lumpy) and refactor
16:34:00 <Quartus> Refactor using somebody smarter than Lumpy.  So find that guy first.
16:34:43 <grub_booter> well, you could.... if you want to tie yourself up in an HR job...
16:35:01 <Quartus> Here's an analogy.  You want to build a suspension bridge.  Do you set a bunch of incompetent Lumpies to work building bits of it any way they can with materials they find laying around, and then go back over the job later to replace the important parts with steel?
16:35:57 --- join: nighty (n=nighty@sushi.rural-networks.com) joined #forth
16:36:08 <grub_booter> ah - not a good analogy - replacing parts of a physical structure is a complex task - a logical structure is easier
16:36:34 <grub_booter> a better analogy..
16:37:07 <Quartus> I think it's an excellent analogy.  You need proper design at the outset.  The infinite-number-of-monkeys thing is not a recommended method of writing plays.
16:37:48 <grub_booter> you're writing a novel - you want to get from beginning, middle and end quickly - some chapters are more complex than others, so you drop in a temporary 'character X does this and character Y does that'
16:38:12 <Quartus> Hang on.  You're suggesting gathering a team of incompetent writers, and letting each one write a chapter.
16:38:35 <grub_booter> no - i'm talking about you as an individual author...
16:39:00 <grub_booter> and as an architect, that's what you are...
16:39:10 <Quartus> Different animal.  Software written by a single author is not the same thing as software written by a team.  However, all large projects need to be contained in a single head; there needs to be one coherent vision, which goes back to what I'm saying about proper initial design.
16:40:06 <grub_booter> absofuckinglutely :-)
16:40:29 <Quartus> So you can't set your lumpies free to build whatever bit of the bridge they think they can manage, using whatever techniques they think are applicable.
16:40:54 <grub_booter> but a software designer does not need to be responsible for each part - he only has to say which part does what
16:41:00 <Quartus> Hoping that what they build will either hold up through sheer luck, or that you can go over it with baling wire afterward to shore it up.
16:41:14 <grub_booter> no - that is design...
16:41:20 <grub_booter> not implementation
16:41:42 <grub_booter> a designer says 'you have these inputs, i want these outputs'
16:41:50 <Quartus> Design dictates implementation.  The fact that each support on a bridge must meet certain tolerances doesn't mean each one should be built out of different materials.
16:41:56 <grub_booter> no
16:42:10 <grub_booter> design does not dictate implementation...
16:42:15 <grub_booter> not even close
16:43:08 <grub_booter> design dictates inputs and outputs - that's all
16:43:08 <Quartus> Very close. They're coupled.  You're suggesting design as a controlled act, and then implementation as a best-you-can-do hodge-podge effort.
16:43:32 <grub_booter> no - not coupled - not even closely
16:44:56 <grub_booter> inputs and outputs/interfaces - that's design
16:45:12 <grub_booter> what happens under the hood is up to the implementation
16:45:36 <grub_booter> and it can jump through hoops to achieve the task
16:46:05 <Quartus> If you want to constrain the meaning of 'design' to stop before materials selection (in the case of a bridge) or development-platform (in the case of software), that's your arbitrary choice of semantics.  What name do you give to that process?
16:46:18 <grub_booter> bridge = bad analogy
16:46:30 <grub_booter> we're talking logical, not physical
16:46:42 <Quartus> How is the distinction relevant?
16:47:37 <grub_booter> in order to explain that, we need a common task in mind...
16:48:33 <Quartus> If you find it difficult to explain why the distinction is relevant, forget the analogy.  What name do you give to the development-platform selection process, if it doesn't fall under 'design'?
16:48:48 <grub_booter> your call - name one (but don't say build a bridge :-) - something small - like copying a string)
16:49:33 <grub_booter> there are many ways to copy a string...
16:52:12 <grub_booter> but as an architect, if i say 'i want a mechanism which copies a string and it must conform to this c function interface - char *strcpy( char *, const char * )' then what stops the implementer from doing the implementation in say, shell, or ruby or python?
16:52:56 <Quartus> What stops a contractor from building every wall of a building from a different material?
16:53:15 <grub_booter> availability of materials?
16:53:26 <grub_booter> knowledge of what they're working with?
16:53:28 <Quartus> Bingo.
16:53:47 <grub_booter> well, yeah
16:54:43 <grub_booter> you break any sufficiently complex project down into tasks for 20 people, and you're going to end up in the same situation...
16:55:10 <Quartus> If the incompetence of your team is reflected in the incompetence of its management, then yes.
16:55:25 --- join: zpg (n=user@90.241.26.221) joined #forth
16:55:45 <grub_booter> no - the architect has got *precisely* what is required...
16:55:53 <zpg> hey.
16:55:59 <grub_booter> the way they do it - that's up to them
16:56:03 <grub_booter> hey zpg
16:56:09 <Raystm2-> Problem with this is... with a bridge, there is definately and architech and definately a worker. With software, everybody thinks he's the architech.
16:56:12 <Raystm2-> zpg :)
16:56:20 <grub_booter> Raystm2-: :-)
16:56:23 <zpg> hi grub_booter, Raystm2- 
16:56:47 --- nick: Raystm2- -> Raystm2
16:56:56 <zpg> the dehyphenator!
16:57:08 <Raystm2> hehe. ;)
16:57:19 <Raystm2> my cat walks across the wonky connection...
16:57:34 <grub_booter> Quartus: but you get my point about the separation between design and implementation, right?
16:58:29 <grub_booter> (christ i need to go to bed... 2am here)
16:58:32 <Quartus> I get that you exclude development-platform from 'design', but you haven't said where you put it.
16:58:46 <zpg> hey hey Mr Q
16:59:02 <Quartus_> hey zpg
16:59:08 <grub_booter> ah - i leave that in the hands of the HR guys and who they can provide ;-)
16:59:18 <zpg> from hyphens to underscores.
16:59:25 <Raystm2> :)
16:59:27 <grub_booter> but at least i'm moving forward
17:01:38 <zpg> grub_booter: toward?
17:01:54 <grub_booter> zpg: long story :-)
17:02:03 <zpg> heh, ok.
17:14:49 <zpg> i'm consistently amazed by the stuff discussed on usenet, essentially in the format "forth sucks because..." and offering a few petty alterations. the impression being that none of these quasi-critics are actually writing forth.
17:16:10 <Raystm2> Forth sucks because people who don't write it are allowed to comment about it on usenet.
17:16:56 <Quartus_> zpg, something specific?
17:17:05 <Raystm2> Forth sucks because, while it can do anything you want, you usually don't know what that is. 
17:17:05 <zpg> just recent reading on BASE and Forth Projects.
17:17:19 <Quartus_> oh. Doty.
17:17:20 <zpg> getting irked by people saying "forth doesn't include this" etc.
17:17:23 <Quartus_> he's an ass.
17:17:50 <zpg> Quartus_: not sure, none of the recent posts are his, but it's not so much the individual offerings as the general subject matter that are the issue. he could well have originated the thread.
17:18:51 <zpg> i'd still agree that a 'standard forth library' would be neat, but it's no biggy.
17:19:10 <Raystm2> I think it would be an implementation nightmare.
17:19:27 <Raystm2> Everybody wondering what a standard model is...
17:21:29 <Raystm2> What is to be done? Copy c? Start fresh? I don't pretend to know and it confuses me that somebody would want this. This is people asking other people to write their code.
17:22:32 <Raystm2> "Forth sucks because I have to learn it to use it."
17:22:33 <Quartus_> The standard model is well defined.
17:23:31 <Raystm2> Is it? Personally, I don't think I've run across it. Does anyone have a link to help me learn it?
17:24:14 * Raystm2 googles
17:24:46 <zpg> isn't it in the topic?
17:24:59 * Raystm2 /topics
17:25:35 <zpg> i'm not talking about implementing a standard, rather a standard library. for one thing, the comus stuff would be a nice starting point. not wholly necessary of course. a matter of convenience
17:25:39 <Raystm2> Oh well the Forth standard, sure, but what about a definition of what's to be included in a standard library of operations.
17:25:48 <zpg> yes, that's up for grabs.
17:25:55 <zpg> a Scheme scenario, perhaps.
17:26:26 <Raystm2> My point exactly. Who to copy. 
17:26:55 <zpg> no need to copy. it's a matter of cross-sectioning toolbelts.
17:27:31 <zpg> take one example: a neat, flexible array library. i recall Quartus_ demonstrating his as being particularly neat.
17:28:41 <zpg> did i mention that it was neat?
17:29:57 <Raystm2> I believe you may have, yes.
17:30:18 <zpg> :)
17:30:24 <zpg> the real question is one of approach. 
17:30:41 <zpg> "generalisation" and "chuck moore" aren't exactly well paired.
17:30:48 <Raystm2> As many of those as there are forth coders. 
17:30:49 <Raystm2> hehe.
17:31:43 <Raystm2> I believe that to be a result of intense factoring ad infinitum.
17:33:37 <zpg> well, there's a reason for that.
17:33:58 * Raystm2 is baited...
17:34:56 <zpg> but factoring in turn provides a clean interface, a simple set of useful words. so if i write a bit of array or list code, suitable for use in multiple projects, that implies that it could be usefully generalised.
17:35:39 <zpg> again, the problem being the diy mentality underpinning much forth coding. "nice toolbelt, but i prefer my own way of doing things". i don't think there's much harm in offering a bunch of useful words though.
17:35:42 <Raystm2> I definately agree with that. Even find it in Chucks work.
17:41:48 <Raystm2> With colorforth we have this process...
17:41:48 <Raystm2> A macro can be created in a block of code. These are either inlined machine code or well factored words. 
17:41:48 <Raystm2> Should a well factored macro prove useful in other applications these macros find themselves moved to a general macros area of blocks to be initialized on boot. 
17:42:43 --- quit: virl (Remote closed the connection)
17:43:27 <Raystm2> So in colorforth the library is 4 blocks of well used macros.
17:46:10 <Raystm2> But then maybe my definition of library is wrong. 
17:46:22 <Raystm2> I suppose it means...
17:47:10 <Raystm2> code for email, web servers, mathematics, sorting routines... on and on.
17:47:47 <Raystm2> Standard browser.
17:49:41 * Raystm2 waits to be educated by people with more experiance. Goes back to looking for a definition of standard library.
17:50:49 * Raystm2 finds c standard library.
17:51:31 <Raystm2> Wait a minute.
17:51:41 <Raystm2> Forth does most of this already, doesn't it?
17:52:46 <TreyB> Does most of what, exactly?
17:53:27 <Raystm2> http://www.utas.edu.au/infosys/info/documentation/C/CStdLib.html
17:55:56 <TreyB> C has no intrinsic I/O.
17:56:47 <Raystm2> I remember reading that. 
17:57:04 <Raystm2> If you need I/O you must include stdio.
17:58:38 <TreyB> Yep.
18:00:12 <TreyB> It has basic integer, floating point, and logic  operators, flow control, and the ability to define and call functions.  Everything else comes from some library.
18:01:54 <Raystm2> i see. Seems to me, in light of that, that for is a tad more complete out of the box. Looking at what's in this library, I see things forth has, has not, and has not need of.
18:02:11 <Raystm2> "that, that forth"
18:03:24 <TreyB> Well, the C standard mandates the "standard libraries", much like the Forth standard mandates the CORE wordset (and defines other wordsets).
18:04:23 * Raystm2 nods in agreement.*
18:05:23 <Raystm2> I suppose my confusion is that the requestor of this 'forth standard library' has not truely defined for me what it is exactly he needs to proceed.
18:06:01 <Raystm2> I guess there is an idea of what a standard library consists of, and i'm grossly missing the point.
18:07:12 <Raystm2> I account that to having wasted time in toy implementations where things tend to be all inclusive.
18:08:15 <TreyB> I think they want a library of code written in standard Forth, and not so much a Forth standard library.
18:09:26 <Raystm2> That would appear to be the view. Then, what are the processes that a library written in the forth standard should provide? Is there a clear idea?
18:10:27 <TreyB> Not that I know of :-)
18:10:52 <Raystm2> Okay, thank goodness for that. Thought I was more then just dence.
18:11:02 <Raystm2> That being possible.
18:13:21 <Raystm2> I think i'm back to thinking that someone is wanting someone else to do his homework.
18:13:36 <Raystm2> I'm a bit for that. :)
18:13:39 <TreyB> It sounds like it a lot.
18:14:00 <Raystm2> I like to read good code. I don't find enough of it. 
18:14:25 <TreyB> I write decent code, but mostly for folks that pay me not to publish it :-)
18:14:26 <Quartus_> there's a clear idea. Two, really. One notion of a standard library is actual code; the other is a wordset definition.
18:15:31 * TreyB ducks out to put his kids in bed.
18:15:39 <Raystm2> TreyB Congradulations. I wish to be doing that someday, I suppose. I'm a salesman and have hated it from the begining, doing it because it afforded the best business education.
18:16:16 <Raystm2> Quartus_ has anybody defined either, competently?
18:16:30 <Quartus_> I don't know what you mean.
18:17:24 <Raystm2> I mean, can I find a page on the web where everybody in the forth community points to it and says "yeah, That defintion of actualy code or wordset". ?
18:18:14 <Quartus_> I'm still not following.  Standard programs meet certain requirements as outlined by the standard.  
18:19:48 <Raystm2> I see. The answer to the posters question when looking for a standard library is to look at ANS.
18:20:15 <Quartus_> ... What question are you referring to?
18:26:29 <Raystm2> It was this ( follows ) one, but i realize now that i've miss read the post. http://groups.google.com/group/comp.lang.forth/browse_frm/thread/f2e287e6b9120c20?hl=en
18:26:52 * TreyB returns, but focuses his C coding work.
18:47:25 <Raystm2> I've only been reading the c.l.f. for a very short period. If this were my introduction to forth I'd worry that I was joining a society of the mentally challenged.
18:48:16 <Raystm2> Someone mentioned S/N ratio lately... shesh I'd say noise is very high there.
19:01:22 --- part: zpg left #forth
19:03:54 <Quartus> It runs about 70-30, signal-to-noise, by my estimate.  Not too bad.
19:08:58 <Raystm2> It is good that it tends to be recognizable.
19:09:10 <Raystm2> Same posters.
19:09:15 <Raystm2> Same topics.
19:42:09 --- join: ttuttle (n=tom@gentoo/contributor/ttuttle) joined #forth
19:42:19 <ttuttle> Quartus: Hey.
19:55:51 --- quit: ttuttle ("leaving")
20:12:31 --- quit: segher (Nick collision from services.)
20:12:42 --- join: segher (n=segher@dslb-084-056-167-047.pools.arcor-ip.net) joined #forth
20:21:06 --- join: edrx (n=Eduardo@201.5.13.223) joined #forth
20:56:04 --- quit: edrx (Remote closed the connection)
20:56:53 --- join: bjorkBSD (n=bjork@ip70-178-168-191.ks.ks.cox.net) joined #forth
20:57:33 --- part: bjorkBSD left #forth
22:33:59 --- join: crest_ (n=crest@p548944A0.dip.t-dialin.net) joined #forth
22:44:20 --- quit: Crest (Read error: 110 (Connection timed out))
22:45:59 <JasonWoof> software development is very much like designing a bridge
22:46:29 <Quartus> I thought so.
22:46:48 <JasonWoof> it's not like building a bridge, it's like designing a bridge
22:47:25 <Quartus> I don't know, the building process is analogous to the implementation process
22:48:54 <JasonWoof> I hope there aren't too many decisions to make in the construction phase of a bridge
22:49:52 <Quartus> The fewer the better; likewise in process of software implementation.  For a team of developers, the choice of which language to use to write any given component should not be a free variable.
22:50:07 <JasonWoof> certainly
22:50:16 <Quartus> That was my whole point.
22:50:49 <JasonWoof> you also were hitting on the fact that there's no point in hiring software people who aren't good
22:51:23 <Quartus> Well, yeah.
22:52:12 <JasonWoof> I learned ruby recently
22:52:13 <Quartus> I was suprised to discover that that point needed arguing.
22:52:21 <JasonWoof> it's way way easier to do web scripting in than PHP
22:52:24 <JasonWoof> but it's too damn slow
22:52:29 <JasonWoof> so I have no use for it
22:52:59 <JasonWoof> yeah, people seem to think that these more "user friendly" languages are good because then people who suck at programming can write stuff
22:53:07 --- join: ygrek (i=user@gateway/tor/x-e036bc807aa4513d) joined #forth
22:53:09 <JasonWoof> they don't seem to realize that the things those people write still aren't worth using
22:53:17 <Quartus> Right, it's glacially slow.  I was a bit surprised to find anyone defending it as a tool, and actually suggesting it should be used in a production context.
22:53:58 <JasonWoof> oh, you can get around the startup time by leaving it running
22:54:05 <Quartus> Only the startup time.
22:54:17 <JasonWoof> I just don't feel like dealing with the administrative crap
22:54:42 <JasonWoof> maybe if I had some system set up so that it would notice when I changed the files and reload itself
22:55:20 <Quartus> The idea that you should hand an interface specification to a dozen programmers and tell them to go nuts and use whatever they like to build each component ... well.
22:55:57 <JasonWoof> it is much much nicer to write in. I'd guess that it would cut my time to write something in half. so it's tempting. except, waiting for the startup times would extend the development time...
22:56:11 <JasonWoof> Quartus: yeah, that's rediculous
22:56:49 <JasonWoof> your api specification is useless without enough context
22:57:20 <Quartus> Even with the context.
22:57:38 <Quartus> Picking a single development platform is a pretty darned good idea.
22:57:50 <JasonWoof> yeah, that was the example I was thinking of
22:57:56 <JasonWoof> who cares if someone wrote some module in ruby
22:58:05 <JasonWoof> if the target platform doesn't have ruby...
22:58:46 <Quartus> "write one to throw away" doesn't mean you should deliberately make that one a pile of crap.
23:03:07 <JasonWoof> well, there is one reason to
23:03:57 <JasonWoof> sometimes the client or manager sees the prototype, and just wants you to fix it so it's 100% right instead of 80%
23:04:01 <JasonWoof> and doesn't want you to start over
23:04:21 <JasonWoof> so it's sometimes a better strategic move on the part of the programmer to make the prototype in such a way that it cannot possibly be used
23:04:23 <Quartus> all the more reason not to make your prototype out of blocks of government cheese
23:04:38 <JasonWoof> such as by writing it in a language that is not available on the target platform
23:05:00 <Quartus> right, so instead of a customer who wants you to reinforce the prototype, you get a customer who thinks you're utterly incompetent.
23:05:32 <JasonWoof> well, there's two solutions to this. one is to write a prototype that can't be used, the other is to design your prototype well, knowing that you'll probably be stuck with it for the rest of teh project :)
23:07:07 <Quartus> I'm not particularly enamored of the 'write one to throw away' edict to begin with, but if you are, I'm saying that writing it incompetently because you know it's not going to be around forever is a bad idea.
23:07:39 <JasonWoof> right
23:08:12 <JasonWoof> the only good reason I can think of to write it incempetently is if that's your stratagy for making sure that it is in fact thrown away
23:08:22 <JasonWoof> but it's risky. they may make you fix it anyway
23:59:59 --- log: ended forth/07.01.27