![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Orchid XP v8" <voi### [at] dev null> wrote in message
news:485be54d$1@news.povray.org...
>
> Some people will be on a course because they employer sent them there,
> but they themselves don't think they need it and it's a waste of their
time.
Even then, you don't get the same behavioural problems as with children. I
know a couple of people who do that kind of training. Serious behavoral
issues are rare.
Ok, there's sometimes a know-it-all who's out to prove he knows more than
the instructor or a person that doesn't care in the slightest. The 1st isn't
hard to manage, the second can be ignored.
Or so I'm told.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 wrote:
> going over TCP/IP, and the subject of class-A/class-B/class-C networks
> came up.
Did anyone point out that nobody uses class-A, class-B, or class-C
routing any more? :-)
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 wrote:
> I meant that you could write the loop and the processing logic as a
> single function, if you really wanted to.
I've done that, by declaring a lambda that I then pass somehere else.
It's uglier in Erlang, is all.
> True, but there shouldn't be very many of those.
It's still bad engineering. :-)
>> I.e., since looping requires recursion, every time you change what
>> data persists between iterations, you have to change all the recursive
>> calls. Maybe the state monad helps, and you could probably do the same
>> thing by wrapping your stuff in a record in Erlang, but that's just
>> really covering up the problem, in some ways.
>
> Not sure what gave you that idea... Add a field to the data structure,
> and only the places that use that new field have to care about it. It's
> a lot less work than passing lots of parameters individually.
For one, you wind up passing everything in the record to every function,
whether it needs it or not.
Say I want a counter for how many times I call X. That goes in the
record, and X increments it. But it also gets passed to Y and Z.
> Parsec allows you to write parsers without needing to explicitly build
> state machines.
Yeah. Erlang has the same sort of thing, called gen_fsm.
It's still not obvious when you're actually using the control flow
(i.e., the program counter) as part of your state how the control flows.
That's probably my problem - still used to using the PC as part of the
program state.
> Hmm, let's see:
>
> word <- untilM valid_word ask_for_word
> numb <- untilM valid_numb ask_for_numb
>
> (Haskell has a function called "until", but there is no untilM function
> for some reason. However, it is not hard to implement.)
>
> Depending on how complex the validity and requesting code is,
Part of the problem is that you're supposed to crash out in Erlang if
you get an error. So saying "did you read an integer" at all is a mess.
> Well... I guess it depends on just how complex your flow control is.
Yeah. I actually even wrote up the control flow, somewhere. Anyway,
just saying, that's the problem right now. Every choice winds up being
nested and nested, unless i'm just doing something wrong. </rant>
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
>>> Er... last time I checked, Google doesn't even *employ* people in the
>>> UK! :-P
>>
>> http://www.google.co.uk/intl/en/jobs/index.html
>
> Damnit, I'm *sure* I looked into th- oh, wait. London.
>
> I wouldn't work in London if you *paid* me for it! :-P
Well, no one was suggesting you work for free...
--
recursion, n.: see recursion.
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawaz org<<<<<<
anl
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> going over TCP/IP, and the subject of class-A/class-B/class-C networks
>> came up.
>
> Did anyone point out that nobody uses class-A, class-B, or class-C
> routing any more? :-)
No. ;-)
Well, I suppose you could argue that virtually every network you're ever
likely to touch in your entire life will be a class-C network... Unless
you work for a Tier-1 carrier anyway.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
>>> Er... last time I checked, Google doesn't even *employ* people in the
>>> UK! :-P
>>
>> http://www.google.co.uk/intl/en/jobs/index.html
>
> Damnit, I'm *sure* I looked into th- oh, wait. London.
>
> I wouldn't work in London if you *paid* me for it! :-P
>
...and what's wrong with London (apart from the fact that Stephen and I
both live here)?
Incidentally, I live literally five minutes walk from Belgrave House.
I'm sure I mentioned it when we met in Sin City ;-)
John
--
I will be brief but not nearly so brief as Salvador Dali, who gave the
world's shortest speech. He said, "I will be so brief I am already
finished," then he sat down.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 wrote:
> Well, I suppose you could argue that virtually every network you're ever
> likely to touch in your entire life will be a class-C network...
Or smaller. Or unless you have an internal network at a corporation, say.
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> I wouldn't work in London if you *paid* me for it! :-P
>>
> ...and what's wrong with London?
Heh. Where to start?
It's old, dirty, overcrowded, expensive, and it looks like the decaying
ruins of a fallen civilisation. What's to like?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> True, but there shouldn't be very many of those.
>
> It's still bad engineering. :-)
Abstract it out then. Make it a seperate function.
>> Not sure what gave you that idea... Add a field to the data structure,
>> and only the places that use that new field have to care about it.
>> It's a lot less work than passing lots of parameters individually.
>
> For one, you wind up passing everything in the record to every function,
> whether it needs it or not.
>
> Say I want a counter for how many times I call X. That goes in the
> record, and X increments it. But it also gets passed to Y and Z.
And this is bad because...?
> It's still not obvious when you're actually using the control flow
> (i.e., the program counter) as part of your state how the control flows.
> That's probably my problem - still used to using the PC as part of the
> program state.
OK - well that's a fairly low-level way of thinking about flow control.
> Part of the problem is that you're supposed to crash out in Erlang if
> you get an error. So saying "did you read an integer" at all is a mess.
Yeah, Haskell's default compiler-generated stuff for parsing expressions
assumes the program will just crash if the string isn't valid. (There is
a hack - you can ask it to parse a list of values, and if it's not
parsable you'll get an empty list. But now how do you tell the
difference between a parser error and an empty list?)
Fortunately, you can use Parsec to do "real" parsing with actual error
messages and so forth if necessary.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Mon, 23 Jun 2008 09:07:27 +0100, Invisible <voi### [at] dev null> wrote:
>>> I wouldn't work in London if you *paid* me for it! :-P
>>>
>> ...and what's wrong with London?
>
>Heh. Where to start?
>
>It's old, dirty, overcrowded, expensive, and it looks like the decaying
>ruins of a fallen civilisation. What's to like?
It's got character, it's exciting and the streets are paved with gold.
It is also bad form, old chap to slag off in public, where people
live. (Social etiquette rule #10)
--
Regards
Stephen
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |