Re: A couple of questions about goops method parameters

[Nala Ginrut <nalaginrut@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2283 bytes --]

2014年9月6日 上午4:10于 "Panicz Maciej Godek" <godek.maciek@gmail.com>写道：
>
> <dthompson2@worcester.edu>:
> >> http://elm-lang.org/learn/What-is-FRP.elm
> >>
> >> Using FRP, we can model with mutable state in a pure, functional way.
>
> OTOH, when you take a look at the example code (Mario), you can trace
> the notion of objects. E.g.
> mario = { x = 0, y = 0, vx = 0, vy = 0, dir = "right" }
>
> What else is that, if not an object?
> "Well, it's a structure", one could say -- because it has no methods.
> However, this is just what the most rudimentary GOOPS objects are -- a
> named tuple (provided that you use no virtual slots). I think that it
> is a big problem of Scheme, that it does not have any noncontroversial
> and commonly accepted way for creating named tuples.
>

Doesn't assoc-list fill the gap?

> Furthermore, instead of using explicit side effects, as one would
> normally do, the Mario example first defines a step function, and
> calls "foldp step mario input". Although I do appreciate efforts like
> in "How to Design Worlds" book or "Introduction to Systematic Program
> Design" course, to avoid explicit mutation (because as SICP shows, it
> complicates the model of computation), I don't see so many benefits of
> avoiding mutation in complex realtime systems.
>

I partly agree with you. For stateless makes things complex. Yes, it could
be complex.
But, no, it depends on need and scenario. The advantage of stateless is to
provide a more reliable and understandable system to users and maintainers.
If your system is constrained by hard  realtime need, go ahead with
side-effect, it's cool. But most of the time, it's not the story from
reasonable users.
If you doubt stateless party exaggerated the truth, I'll recommend this
paper: <<Out of the tar pit>>

> Actually, when I look at the Mario example, I have a feeling that the
> code would be much cleaner and easier to follow if it was written in a
> more traditional imperative/callback style.

It's fine if you think imperative is still cool in FP, me too, since most
people living in non-FP land.
But if you're expecting imperative way in FP land rather than learning and
trying it in FP way, why not choose non-FP lang for it? :-)

[-- Attachment #2: Type: text/html, Size: 2867 bytes --]