-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Complexity, Verbosity #110
Comments
Thanks a lot for sharing your opinion. This is definitely worth talking about. I think I understand you are coming from, but it would be very useful if you would share a bit more details about what you find complex and verbose. With API surface area do you mean the number of functions, the number of types, or the complexity of each type or function? Do you mean the API of Hareactive, or Turbine, or both? Any part of the API in particular that you felt was unnecessarily complex. With regards to verbosity, which TodoMVC examples did you compare to? Any parts, in particular, that triggers your intuition about the library being verbose? Do you think the email validator is verbose? Or do you only think the verbosity creeps up in other examples? Personally I think Turbine is only adequately complex and, most of the time, I don't think it is verbose. I actually think it can be very consice. But, before I write a more comprehensive response I'd love to hear you point of view in more detail 😄 |
This seems to be sort of related to some of the concerns I have brought up over the time with @paldepind. However I mostly agree that it is not overly verbose. I also think it would be awesome if you could share the code examples that you used for the comparisons, it is definitely something I would like to look at. |
Yes, I partially am talking about the large API import { fgo, sequence, IO, combine } from "@funkia/jabz";
import {
Behavior,
sample,
snapshot,
Stream,
performStream,
changes,
lift,
snapshotWith,
accumCombine,
moment,
shiftCurrent,
empty
} from "@funkia/hareactive"; But, to me this isn't the biggest deal. I think optimizing for long-term productivity is more important than short-term productivity. If I worked with Turbine regularly I'm sure the API wouldn't be a problem. Few weeks ago I did some counting. This isn't meant to be taken too seriously, just a quick check. I understand it's not some objective measure. Some may have been changed from when I counted, I removed some comments, may have missed a comment here or there, etc. Some are typed. Some aren't. Some are split across files, so there's some extra characters for duplicate imports, etc. cwws = characters without white space Turbine (split across files. Very modular. Many types.): I think comparison with Svelte and Elm is interesting. Svelte: untyped, reactive, impure. Elm: typed, pure. Turbine: typed, functional reactive, pure. Personally, the Svelte example seems the easiest to grok, not least because of the terseness. These comparisons lead me to reflect: how much is purity worth? Is it worth 10x verbosity? 5x? 2x? What are the advantages of Turbine vs Elm? Are there ways to simplify and tersify Turbine? How would these verbosity numbers look for a larger app like RealWorld app? Any plans to implement that with Turbine? https://github.com/gothinkster/realworld |
Hi again @deklanw. Here's a small reply.
Ok. I'm glad that we agree on that one. Turbine isn't an attempt at making the simplest thing possible and Hareactive has a large API because those functions are useful. I think developers can handle that. Lodash has a large API for arrays and Bluebird has a large API for promises. That is exactly why those libraries are useful. As long as an API consists of many othorgonal functions I think an API of some size is acceptable.
Sparked by this thread we've started implementing some ideas that take us in that direction. The key idea is this: take the current |
Hi again @deklanw. I think we have now answered "yes" to your question:
We've made quite a few changes to Turbine in order to cut down on complexity and verbosity and we've found on an alternative to generator functions. This has made the API simpler and cut down on the line count in the examples. If you have the time please take a second look at the TodoMVC example. I think that it is now very competitive in terms of verbosity when compared to other full implementations of TodoMVC (note that some of the implementations you mentioned above miss certain functionality/has bugs). |
That was fast! 350 lines, 7362 cwws. A huge improvement, definitely. I'm not totally sure what |
The start and on are still not explained. Typescript lets you comment on types, and you can then produce docs from that. Cyclejs does it. |
This is just an observation. Turbine seems to me to be both complex and verbose.
Complexity: The API surface area just to get started is large.
Verbosity: Just intuitively the library feels verbose to me. I compared the TodoMVC example in lines and characters to a few other libraries. It was the longest by both measures.
It's not clear to me how much is accidental complexity or whether the verbosity can be fixed anywhere.
The text was updated successfully, but these errors were encountered: