Hacker News Reader

Comment by jtolmar | Hacker News Reader

Top three takeaways for me: event-based logic, sets instead of loops, and using past tense instead of state. Events and linq-like queries are popular enough, that last one is interesting.

Especially in an environment where you mostly interact with objects via events, I think querying an object's past sounds pretty doable. Naively we could hold on to all events ever and query for one that matches what we're talking about. Less stupidly, these past tenses are usually in forms like "if this happened recently" or "if this happened ever" which a compiler could rewrite into a variable that the relevant event sets.

So, the compiler sees "if Pacman ate a power pellet within the last ten seconds" in whatever syntax it accepts. It goes to Pacman's "eat power pellet" function and appends code to set Pacman's last-power-pellet-eaten variable, which it has to introduce. The original conditional gets rewritten in terms of timestamp comparison.

View on HN

Using sets instead of loops is a sensible thing to do. After using LINQ or a proper functional language it's hard to go back.

Using past tense instead of explicit state handling is actually a very interesting idea that I don't see being commonly used. Wort thinking about.

But... Event-based logic is often the source of horrendous complexity and bugs due to timing and exponential complexity of dealing with various sequence permuations. This is one of those things that I firmly believe people should be conditioned to avoid at all cost by using either functional (immutability+recursion) or logic (rules+deduction) flavors of programming. This is one of those things that's really not intuitive to get started with but provides huge benefits in the long run.

The "sets instead of loops" one makes me think of Ruby, where operations on sets are a basic part of the philosophy in a way they aren't in a bunch of languages.

Even the basic "do this 5 times" is expressed in the same way as a set comprehension:

    this_set_of_items.each do |item|
      puts "hey, look at #{item}"
    end
 
    5.times do |index|
      puts "look, a line!"
    end

I took it more like the way you specify certain jQuery operations such as:

    $('.card').hide();

to mean "hide all cards", or

    $('.card.green').show();

to mean "show all green cards". It's really comfortable to think about operating on the set like this and not having to worry about looping on the individual items.

In fact thinking of it as a set frees computing to do things concurrently invisibly.

A lot of other comments here say "ah, but that's just JS iteration still"... but there's really nothing to prevent it being the equivalent of a Go routine... no order implied, no iteration implied, but all the things in the set will have the functions hide() or show() called.

I am not sure that would count as working on the set. It looks like iteration.

From the article:

a) 1___ 2___ 3___ 4___ 5___ 6___ 7___ 8___ 9___

Thinks of them as a set or subsets of entities and operates on those, or specifies them with plurals. Example: Buy all of the books that are red.

b) 1___ 2___ 3___ 4___ 5___ 6___ 7___ 8___ 9___

Uses iteration (i.e. loop) to operate them explicitly. Example: For each book, if it is red, buy it.

In your case it looks like you are operating on each item and not on the set.

It sounds very like array programming, eg APL and it's derivatives

That's just Array.forEach in JS. Or in Scala:

  (1 to 5) foreach { _ =>
    println("look, a line!")
  }

That's really nothing to do with Sets.

Logically it can be expressed as operating on the set {1, 2, 3, 4, 5} - I think that's the point: one can perceive it differently, either as a set operation or as a loop/iteration.

  module Numeric
    def times(&b)
      (1..self).each(&b)
    end
  end

It's really no different than the Scala you'd write for the same thing:

  implicit class LongHelpers(l: Long) {
    def times(f: => Any) = (1L to l) foreach f
  }

  10 times println("here's a line!")

To interpret that as a Set operation would make the definition of a Set operation so broad as to be useless IMO.

sets aren't ordered

The set of ordered sets is a subset of the set of sets. Totally ordered sets, which I think are synonymous with chains(?), are still sets.

But yes, I was talking loosely: my point was to differentiate between a mental model of iterating over a sequence (or ordered set) and applying a set-like transformation. My mental picture was of a field formed by a matrix operation on a limited space as being composed of the summation of a series of vector transformations; my maths language doesn't really allow me to properly describe it however. Loosely: you can break down a [subset of] 3D transformation[s] of a surface in to a series of 2D transformations performed iteratively, or you can apply a 3D transformation; they're different mental images of acquiring the same result.

> using past tense instead of state

Isn't Clojure's philosophical foundation almost exactly this? Adding the dimension of time to data structures? I vaguely recall a ConTalk by Rich Hickey from the early days about it.

You may be thinking of http://www.datomic.com/ a product by Cognitect where Rich Hickey works. However the Clojure data structures also have the time dimension in the context of the language's immutable structures but it is not something you typically concern yourself with too much.

I looked it up, it's this talk, which indeed is the first one about Clojure, and it's philosophical foundations:

https://github.com/matthiasn/talk-transcripts/blob/master/Hi... (slides)

http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic... (recording)

The opening lines are:

> So I’m going to talk about time today. In particular, how we treat time in object-oriented languages generally and maybe how we fail to. So I’m trying to provoke you today to just reconsider some fundamental things that I just think we get so entrenched with what we do every day, we fail to step back and look at what exactly are we doing.

Whoever downvoted my previous comment does not know their Clojure, that's for sure.

Well, the time stuff has to do with Clojure's different ref types (Ref, Atom, Var, Agent...) combined with the persistent data structures.

the past-querying sounds a lot like reactive programming, doesn't it? you lay out an expression (and you would be typically using set/aggregate operations there as well) and the expression kinda just sits there quietly, accumulates events until a certain condition or threshold is reached, when it fires a signal further down the chain...

This is a nice tl;dr, thanks

The 3 elements make sense even as a programmer, but of course you would need to do them yourself in your program logic and might opt for something simpler

Adding a variable is creating state. Defeating "past tense without state."

What you described, has ever, has recently seems like classical finite state machine.

The entire point is the model presented to the programmer, not the guts. Of course it's implemented in terms of state. Computing hardware is stateful.

This is really fascinating - our security folks are using even based history - must go talk to them again in this context

Thank you

> Especially in an environment where you mostly interact with objects via events, I think querying an object's past sounds pretty doable

Sounds a bit like Event Sourcing.

I can imagine logic like:

Do action "foo" if user_account has ever been in the "deactivated" state.

It's funny we make the presumption that the natural way is the best way.

Programs are for humans to read. That is their sole purpose.

Bah, the past tense in a summary is just bad grammar. It is regularly correct to use the present, also called the narrative present as wikipedia will have you know.

Reply on news.ycombinator.com