Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • FWIW, back at Uni we actually have the following classes: Programming Paradigms I, II, III and IV.

    What we learn in these classes is, respectively, Functional, Imperative, Logic and OO programming.

    In my case, this was done mostly with Haskell, C, Prolog and Java (sometimes they change the languages).

    There was also a teacher who used to say that databases are a paradigm on its own.

    Also, I was first introduced to Perl in the classes of "Scripting as a Programming Paradigm".
    • > What we learn in these classes is, respectively,
      > Functional, Imperative, Logic and OO programming.

      Yep, those are the four that I identified in my last post. However, I argue that OO is an "abstraction style", and not a "control style", which is what I'm looking for.
      • If you want a control style, where does event-driven programming fit? What if it's asynchronous?

        • > If you want a control style, where does
          > event-driven programming fit? What if it's
          > asynchronous?

          I define the control paradigm by the input (code) and the output (what happens when you run it). In the event driven case, you give it actions to execute when certain things happen. But the first part is the important part, you're giving it actions, and it tells you what happens when those actions are executed, even though those actions are triggered rather than sequenced. Therefore, I think event-driven programming is a form of imperative, which isn't surprising, since most programming these days is imperative (it is a, er, logical thing to program in, because it maps most closely to what the computer actually does).

          However, the point of this little exercise was to identify the binary dimensions on which the different languages lie. So maybe event-driven programming is one of those dimensions:

                  Event-driven functional: Compute what properties of the world change as objects are introduced and removed (this is what I called forward-chaining logic [luqui.org], and I want a system that does it badly!)
                  Event-driven logical: Compute the set of objects satisfying a property continually as objects are introduced and removed
                  Event-driven imperative: Do stuff to the world as you detect it change
                  Event-driven logiparitive (or whatever this fourth control style is called): Compute the changes the world is undergoing as it changes

          Some of those are a little bit stretchy, but it kinda seems to work.

          As far as asynchronous programming, I think that's definitely a binary dimension, as it is referring to the *order* in which things are done (which serial or parallel), and the control style doesn't refer to that at all. I have also seen asynchronous functional languages and logic engines, so it seems like it can be put into any paradigm (though async Haskell is all within the IO monad, so it's arguable whether it really fits in the functional world).