21–30 of 31 posts
This isn't even an article, just a guy saying the people complained about OOP back in the day.
It doesn't even say what kind or what reactive programming is - just throws out some random words ...
... having channels doesn't have anything to do with Reactive Programming ( http://en.wikipedia.org/wiki/Reactive_programming ). The implication that channels were added to Go to support it seems dishonest. There is a very long thread on the Go list of a guy who is a fan of dataflow grumbling about how design decisions made in Go make it a poor fit for dataflow.
Mostly agree, in the sens that, from my limited pratical experience & knowledge of Reactive Programming (RP), I understand that RP isn't bound to a particular "parallel execution model" (maybe s/parallel execution model/threading model/ ?).
> There is a very long thread on the Go list of a guy who is a fan of dataflow grumbling about how design decisions made in Go make it a poor fit for dataflow.
I can't find it in https://groups.google.com/forum/#!searchin/Golang-nuts/React...
A blog post might be better fit for that (so far I was unsuccessful getting constructive feedback that way). Anyway here are more thought, based on my experience dealing with GUI app:
- "parallelism", even if simpler with an event-loop, is still a significant burden especially when performance matters
- Class based OOP, especially not JavaScript, is very helpful to group a sequence of callbacks to help fight spaghetti code.
- Explicit State Machines are a praised black art wrongfully dubbed useless overhead because "it's possible to do otherwise"
- «yield/await/async» as been recently recognized broadly as the way forward cf. https://news.ycombinator.com/item?id=4732924
All the points mentionned above have in common that they try to handle correctly with fine grained priority and different "paralellism" patterns with ease.
RP mean to provide much more than "yield", it's pattern that is similar to the explicit state machine intent. The declarative paradigm/syntax arguably provides an ease of use that is competitive both in terms of performance and dev efforts even if mileage may vary. See by yourself:
>>> HackerNewsPost.rank = HackerNews.upvote_count * MAGIC_NUMBER
This one might be better expressing the actual behavior, even if the ranking algorithm is "hidden":
>>> HackerNewsPost.on_change(HackerNewsPost.position).update(HackerNewsPost.rank).maximum_frequency(timedelta(seconds=60*60))
The above can not be expressed in "one line" using "yield" and whatnot.
May be of interest to you:
- https://speakerdeck.com/ryanartecona/a-unified-model-of-asyn...
- http://swannodette.github.io/2013/12/17/the-future-of-javasc...
- Observable/Observer, pub/sub & signaling patterns
- Search for "AngularJS performance issues"
- http://en.wikipedia.org/wiki/UI_data_binding
Reactive Programing can abstract the underlying "threading model" and all the above patterns... I am biased.
edit: typo & more rigorous "API" in second one-liner
> Now OOP is taken for granted and assumed that all languages should be able to produce objects. Not really. There are OOP languages, there are multi-paradigm languages that include OOP stuff, and then there are languages that don't have OOP at all. That last category includes functional languages like Haskell and some Lisps. Should every language support at least some OOP? Maybe. I think it's too soon to tell. We ma…
What Haskell lacks is hierarchies of subtyping. It certainly can be used for OOP. I've written object-oriented code in Haskell. It's not common, but it's not hard. And on rare occasions it's the best solution to a problem.
Earlier quoted context omitted.
What Haskell lacks is hierarchies of subtyping. It certainly can be used for OOP. I've written object-oriented code in Haskell. It's not common, but it's not hard. And on rare occasions it's the best solution to a problem.
Perhaps we have different definitions of OOP. To me, it's not OOP without subclasses and private mutable state. What does OOP mean to you? I'm guessing you're thinking of Haskell's typeclasses as an analogue to Java's interfaces. Any other features?
Can someone tell me the key differences between the actor model and reactive/dataflow programming? I haven't seen any references to erlang in conversations about Reactive programming, which seems odd to me as erlang's lack of shared state and message-passing seem like they fit the definition of reactive programming.
They're basically unrelated. The actor paradigm is basically imperative programming, with boundaries being put up between the actors, and the way you cross the boundary is with a message. If that sounds too foreign, bear in mind that while OO doesn't have to be an "Actor" and an actor doesn't have to be "OO", they share a certain structural similarity, in that one of the primary characteristics of working with an "ob…
I think that may be a significant, fundamental problem with reactive programming. The way these graphs are constructed is typically (necessarily?) buried within the reactive programming framework, giving the programmer poor visibility into what's actually happening. Maybe that problem can be solved, but I suspect it might be intrinsic to reactive programming.
> I know the Haskell world has been fiddling with FRP but I'm still underwhelmed by the efforts.
I've test-driven some of those projects. Last I checked, the documentation was extremely sparse, and the only examples were trivial. I haven't yet seen an example of a useful Haskell app built with FRP. FRP has sometimes been described as the silver bullet for doing stateful apps in a pure FP way. Maybe it is, but for now, I'm sticking with pseudo-imperative Haskell for those purposes.
> Now OOP is taken for granted and assumed that all languages should be able to produce objects. Not really. There are OOP languages, there are multi-paradigm languages that include OOP stuff, and then there are languages that don't have OOP at all. That last category includes functional languages like Haskell and some Lisps. Should every language support at least some OOP? Maybe. I think it's too soon to tell. We ma…
What Haskell lacks is hierarchies of subtyping. It certainly can be used for OOP. I've written object-oriented code in Haskell. It's not common, but it's not hard. And on rare occasions it's the best solution to a problem.
Earlier quoted context omitted.
What Haskell lacks is hierarchies of subtyping. It certainly can be used for OOP. I've written object-oriented code in Haskell. It's not common, but it's not hard. And on rare occasions it's the best solution to a problem.
What's that old chestnut about design patterns just being workarounds for missing language features? Multi-paradigm languages: I'll admit they're usually woefully lacking in sex appeal. When it comes to getting @$#@% done and moving on with your life, though, they be awesome .
Earlier quoted context omitted.
Perhaps we have different definitions of OOP. To me, it's not OOP without subclasses and private mutable state. What does OOP mean to you? I'm guessing you're thinking of Haskell's typeclasses as an analogue to Java's interfaces. Any other features?
You can implement private mutable state (and dynamic polymorphism behind an interface) with records of closures. Depending on what you mean by "subclasses" here, they may follow trivially. Haskell typeclasses are a poor match to OOP, as you say.
Interesting. Can you point me to an example?
Earlier quoted context omitted.
You can implement private mutable state (and dynamic polymorphism behind an interface) with records of closures. Depending on what you mean by "subclasses" here, they may follow trivially. Haskell typeclasses are a poor match to OOP, as you say.
> with records of closures. Interesting. Can you point me to an example?
http://okmij.org/ftp/Scheme/oop-in-fp.txt
http://stackoverflow.com/questions/2954642/methods-and-prope...
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-20.html
Some examples. The first is a discussion on it. The second and third have examples in scheme. I'd type more but I'm on my iPad. If I get time later I'll steal time on someone's computer to type up more.