What's the point

I have been studying this subject for 3 years now and would have thought that in this third and final year some indication as to its applicability in every day life would have been reached. I hope I am just missing the point. I really can't find a really practical use for all this boring theory.

I hate to say it, but if you've been studying
this module now for 3 years and don't see the
applicability, perhaps a different major might
be more to your taste?

This module is the embodiment of this field.
These modules (101, 201 and 301) put the
"science" in "computer science".

I've used the information here even before I had
to study it. Suppose you are called upon to write
a protocol stack to communicate with a remote
video streaming feed.

The protocol, no matter what form it is given,
can *always* be represented as a FA. Turn all
of the FA boxes into functions and use a comparison
of the current input to determine which function
to call next.

In fact, last year when I hadn't already registered
for this module (301), I was already attempting to
learn how to write grammars; I felt it was needed
for a project I wanted to do.

My suggestion would be to actually attempt to
write deterministic software.

goose

--
Learn something new - updated weekly

Thanks for the points. I was not knocking the subject on the contrary I am just as passionate as you are. It's the course material I find to be purely theoretical with little spare a few hints as to practicality. Your input has got me thinking of some ways I can put this all to good use. Thanks.
In my ten or so years in this industry I have probably written more than a few bytes of deterministic software though I have never caught myself thinking "A Context Free Grammar would sure be great right about now" Perhaps now I will.

Grant v Wrote:
-------------------------------------------------------
> Thanks for the points. I was not knocking the
> subject on the contrary I am just as passionate as
> you are. It's the course material I find to be
> purely theoretical with little spare a few hints
> as to practicality.

All theory is boring; thats just the way life is. Theory
only becomes valuble (not "interesting", just "valuable"
when you find something interesting to implement.

> Your input has got me thinking
> of some ways I can put this all to good use.
> Thanks.
> In my ten or so years in this industry I have
> probably written more than a few bytes of
> deterministic software

The difference, as I've often observed, between a
great developer and and superstar developer is this:

The developer who's merely "great" chooses the most
suitable language and then creates a solution. The
superstar, OTOH, chooses the most suitable solution and
then creates a language to express it.

> though I have never caught
> myself thinking "A Context Free Grammar would sure
> be great right about now" Perhaps now I will.

Maybe something more concrete will help: try writing
a program that connects your computer to the remote
dialup server that ISPs use. You can assume that modem
stuff is taken care off, all you do is negotiate for an IP
address, send username when prompted, etc.

goose

--
Learn something new - updated weekly

all this stuff is completely useless for computer graphics (ok, l-systems being a notable exception), my target field

lycium Wrote:
-------------------------------------------------------
> all this stuff is completely useless for computer
> graphics (ok, l-systems being a notable
> exception), my target field

Oh, I don't know about that; let me attempt
to convince you by dint of rational debate

What I *do* know is that OpenGL (target of
much ire from cos340 students is designed
and implemented as a state-machine. It has to be,
the specs say so.

State machines are more easily understood once
a grounding in computer science is achieved; for
example, I find it extremely helpful to design
my OpenGL proggys as state-machines within
state-machines, because then my program meshes
incredibly well with the graphics subsystem.

For example:

I've often, on usenet and in forums, met OO-heads
who sort of assume that if something is OO then it
must automatically be superior to non-OO (hell, I've
even seen that PoV in the cos340 phorum!). This
leads quite a lot of people down the path of
designing OpenGL programs with a class hierachy
for their representable (in OpenGL) data. Down that
path lies (eventual) madness; the state-machine
model is manipulated differently from the OO-model,
and the two do *not* behave well together. There is
no reason that they should, anyway, so they don't.

Hopefully, I've convinced you that cos301 is
not "completely useless", but perhaps not as useful
to computer graphics is it is to other fields.

Kind regards

--
Learn something new - updated weekly

i see what you're getting at, and yeah there are things like state machines all over the place. but really, small children can learn opengl and how it keeps state... then there's kleene's theorem. opengl's statefulness can be boiled to "just keep it in mind" (i got that from dave shreiner himself), writing stateful algorithms should come naturally or you'll never succeed at programming anyway, and so this business of writing huge language trees is not part of what we do in cg. the closest i've come is making infix->postfix expression conversion and evaluation, and even that doesn't need 1/1000th of the textbook.

it's plainly obvious how this stuff is useful when you're in an ivory tower imagining how to build a computer that can do anything, but really for the practice of doing computer graphics, it's not used.

lycium Wrote:
-------------------------------------------------------
> i see what you're getting at, and yeah there are
> things like state machines all over the place. but
> really, small children can learn opengl and how it
> keeps state... then there's kleene's theorem.
> opengl's statefulness can be boiled to "just keep
> it in mind" (i got that from dave shreiner
> himself), writing stateful algorithms should come
> naturally or you'll never succeed at programming
> anyway, and so this business of writing huge
> language trees is not part of what we do in cg.
> the closest i've come is making infix->postfix
> expression conversion and evaluation, and even
> that doesn't need 1/1000th of the textbook.
>

The problem, I think, is this module never introduces
anything practical; it's almost all theory. So all
students get a feel for is a vague "languages and
things"; they don't realise that all abstraction is
(or rather, should be) language manipulation.

> it's plainly obvious how this stuff is useful when
> you're in an ivory tower imagining how to build a
> computer that can do anything, but really for the
> practice of doing computer graphics, it's not
> used.

Like I said, not "completely useless", just not
as useful as in other fields. I have, in the past,
written OpenGL programs after doing a state-machine
design which came naturally.

Think about writing a simple game like the handheld
donkeykongs we had as kids in the mid-eighties. I
have trouble seeing a /clean/ OOP design for that within
OpenGL, but a /clean/ state-machine based design can be
drawn up in a few minutes, verified with the same pencil
and paper you used for the design and then implemented
in a programming language of your choice.

OTOH, writing a simcity-ish program with OpenGL
seems (at first glance) like it would be easier to
do in a class hierarchy(sp?). Of course, this is because
most of the work is spent on lots of little, but distinct,
objects. Rendering them might be a job for a state-machine,
perhaps, because subclassing a "render" member function
for thousands of objects in a certain hierarchy can get
a little hairy when you only have a 16 levels of the matrix
stack to use and a class hierarchy that goes beyond that.

What generally happens in that case is that the OOP
developer then starts hacking in state variables into
his classes.

yeah it'd be nice to have to actually *code* anything interesting/useful. an automatum that converts infix to postfix could be one such example, and a good excuse for making those migraine-inducing PDA diagrams. it's also a natural "first step of the way" to making a proper compiler, which i imagine to be the principal practical application of all this stuff.

> Like I said, not "completely useless",

ok, ok, ... let's compromise and say "mostly useless" note that "mostly harmless" does NOT apply!

> Think about writing a simple game like the
> handheld donkeykongs we had as kids in the
> mid-eighties.

heh, those old "game and watch" thingies yeah they rocked, and i can see how the whole thing is easily expressed as a state machine (probably as microcode in like a 4bit processor!).

however, and this is what i meant with "if you can't do it naturally you don't understand a damn thing about logic, let alone coding" (to unfaithfully paraphrase myself), something like that would have been coded exactly the same way even if all this automata stuff hadn't been introduced. it's the natural way to do some things, mathematicians just formalised the whole process and made it inaccessible to the public (that's their job ).

to give an analogy, the cashiers at supermarkets etc don't really need to know much about algebra, even if it's "the greater study of what you're doing", and if they don't know how to count they'll never master algebra

> What generally happens in that case is that the
> OOP developer then starts hacking in state variables
> into his classes.

state variables aren't a hack unless there are too many of them. remember the KISS principle: there are little state machines all over the place (all if statement blocks), there's no point throwing industrial-strength graph and automata theory at the problem if the result is exactly the same, the simple version is faster and more, um, simplererer. obviously there's a cutoff line, so it's more "poor judgement" than "grave error"

lycium Wrote:
-------------------------------------------------------
> yeah it'd be nice to have to actually *code*
> anything interesting/useful. an automatum that
> converts infix to postfix could be one such
> example,

Personally, I wouldn't actually consider that
"interesting" enough;

> and a good excuse for making those
> migraine-inducing PDA diagrams. it's also a
> natural "first step of the way" to making a proper
> compiler, which i imagine to be the principal
> practical application of all this stuff.
>

AIUI (and I may be wrong), the principle application
of all of this is merely abstraction when problem
solving.

> > Like I said, not "completely useless",
>
> ok, ok, ... let's compromise and say "mostly
> useless" note that "mostly harmless" does NOT
> apply!
>

"Mostly useless" I cannot fault (well, not in the
same way as "completely useless", and won't want to,
what with me having a brain bigger than a planet blah
blah blah


> > Think about writing a simple game like the
> > handheld donkeykongs we had as kids in the
> > mid-eighties.
>
> heh, those old "game and watch" thingies yeah
> they rocked, and i can see how the whole thing is
> easily expressed as a state machine (probably as
> microcode in like a 4bit processor!).
>

I've got a dual-screen donkeykong lying around
somewhere. Endless fun

> however, and this is what i meant with "if you
> can't do it naturally you don't understand a damn
> thing about logic, let alone coding" (to
> unfaithfully paraphrase myself), something like
> that would have been coded exactly the same way
> even if all this automata stuff hadn't been
> introduced. it's the natural way to do some
> things, mathematicians just formalised the whole
> process and made it inaccessible to the public
> (that's their job ).
>
> to give an analogy, the cashiers at supermarkets
> etc don't really need to know much about algebra,
> even if it's "the greater study of what you're
> doing", and if they don't know how to count
> they'll never master algebra
>
> > What generally happens in that case is that the
> > OOP developer then starts hacking in state
> variables
> > into his classes.
>
> state variables aren't a hack unless there are too
> many of them. remember the KISS principle: there
> are little state machines all over the place (all
> if statement blocks),

I really wasn't referring to overly trivial
things like conditional branches; nevertheless
I maintain that a little bit of CS grounding
can go a long way indeed, as it is platform-agnostic,
language-agnostic and implementation-agnostic.

> there's no point throwing
> industrial-strength graph and automata theory at
> the problem if the result is exactly the same, the
> simple version is faster and more, um,
> simplererer. obviously there's a cutoff line, so
> it's more "poor judgement" than "grave error"

It's a call the programmer has to make, but unless
he is familiar with all the options open to him,
he will certainly not properly evaluate some of them.

IME, most programmers think that the only alternative
to OOP is some sort of structured, procedural design
or, even worse, totally unstructured.

This is why you see so many people expousing the
100% goodness of OOP, when they cannot write non-trivial
functional or CS code. If they knew more than OOP
and procedural, they might take different decisions.

goose Wrote:
-------------------------------------------------------
> lycium Wrote:
> --------------------------------------------------
> > yeah it'd be nice to have to actually *code*
> > anything interesting/useful. an automatum that
> > converts infix to postfix could be one such
> > example,
>
> Personally, I wouldn't actually consider that
> "interesting" enough;

for a programming competition i once did, we had to write what basically boils down to an automaton (minimal set of state variables and a stack) that accepts or rejects a maze, based on whether it has exactly one entrance and one exit (which are connected). feel free to tackle that one if it blows your hair back, as it did mine when i was young and full of idontknowhat

i don't remember how the question was posed exactly, unfortunately.

> > and a good excuse for making those
> > migraine-inducing PDA diagrams. it's also a
> > natural "first step of the way" to making a
> > proper compiler, which i imagine to be the
> > principal application of all this stuff.
>
> AIUI (and I may be wrong), the principle application
> of all of this is merely abstraction when problem
> solving.

sounds like foreplay to me...

when i first looked into the subject in the context of programming, i saw all kinds of scary stuff about backus nauer (dunno sp anymore) form, or was it binus nauer? anyway, that together with parse trees and all the other weird data structures they used (which i didn't understand back then) has indellibly stamped "black art, not to be touched" in my mind

since then i've read bits of douglas hofstadter's "gödel, escher, bach", knuth's "surreal numbers" and a couple other interesting books. particularly the former helped me wrap my head around the formalism and it draws amazing parallels with science and art.

unfortunately, my writing style has suffered since reading that book see http://www.encyclopediadramatica.com/index.php/TL;DR

> "Mostly useless" I cannot fault

yeah that's a very difficult stance to take i can see it now, "for example, when shopping, you're obviously an automaton looking for ACCEPT states while avoiding the value meal REJECT states your stomache produces..."

> what with me having a brain bigger than a planet

too bad, a schlong the size of a planet would do you much more good here on earth.

> I've got a dual-screen donkeykong lying around
> somewhere. Endless fun

i had that very same one i think at the bottom you have to jump over rolling barrels if i'm not mistaken? that's another thing that's been etched into my mind (like german), even if i haven't used it in nearly two decades.

> It's a call the programmer has to make, but
> unless he is familiar with all the options
> open to him, he will certainly not properly
> evaluate some of them.

very true.