4 ms·

> Prepare for 1.0 next release So this will soon be a stable API? Great work. The documentation is extensive. I am personally a big fan of toolz[0], which i

> Prepare for 1.0 next release So this will soon be a stable API? Great work. The documentation is extensive. I am personally a big fan of toolz[0], which is clojure inspired. This object method chaining Scala inspired approach is different, and interesting. It might be fun to make sort of comparison matrix of the difference in approach between this library, toolz, and the venerable fn[1] which also has a Scala influence (and apparently already implements the '_' lambda form). [0] http://toolz.readthedocs.io/en/latest/ http://toolz.readthedocs.io/en/latest/ [1] https://github.com/kachayev/fn.py https://github.com/kachayev/fn.py

emmelaich 9y ago
... and functools/itertools for completeness?
catnaroek 9y ago
From https://github.com/kachayev/fn.py https://github.com/kachayev/fn.py : > There are theoretical and practical advantages to the functional style: > - Formal provability This is bollocks. To prove things about your programs, you need a formal semantics for the language you're using.
- bionoid 9y ago
  > This [Formal provability] is bollocks. How precisely does modularity, composability and ease of debugging improve from this module? Not at all. It may have benefits, sure. But to claim these as general attributes is just sophistry in my personal opinion.
  - catnaroek 9y ago
    Agreed. I just felt a stronger need to comment on the zeroth bullet point in the list.
- lmm 9y ago
  Functional style makes it easier to have a natural semantics that corresponds directly to the language proper: you can use a small-step semantics where evaluation is just reduction, and you then have a very simple and natural denotational semantics (the denotation of an expression is just the value it evaluates to) that obviously corresponds directly to your operational semantics. All that is much harder to do with programming styles that make use of pervasive, implicit state.
  - catnaroek 9y ago
    A semantics is a property a programming language, not the style you happen to program in. --- @lmm > In practice no practical language provides formal semantics for the entire language Programming languages are mathematical objects and always have a formal semantics, regardless of whether someone has taken the trouble to write it down or not. What I'm saying is - the formal semantics that most languages have preclude the existence of compound values. Without those, you can't define interesting functions, and thus you can't program in a functional style.
    - lmm 9y ago
      In practice no practical language provides formal semantics for the entire language, only for restricted subsets of it i.e. particular styles within the language.
    - lmm 9y ago
      Responding to edits: > Programming languages are mathematical objects and always have a formal semantics, regardless of whether someone has taken the trouble to write it down or not. Not true for the usual plain-english meaning of "programming language". Plenty of things we call programming languages take a "the implementation is the spec" view, or simply can't be assigned any useful semantics in a way that's at all aligned with the defining characteristics of the language in question. Even in, say, Haskell, io explicitly lacks formal semantics. > What I'm saying is - the formal semantics that most languages have preclude the existence of compound values. Without those, you can't define interesting functions, and thus you can't program in a functional style. Python tuples are perfectly cromulent compound values. Python has a bunch of builtin classes for which the equality operators that are available in the language are all kind of useless, sure, but that's true in almost all languages.
entilzha 9y ago
Author here. 1.0 has been out for a while now, and I'm very committed to API stability. 1.1 (or 1.0.1) should be out as soon as I have some time with mostly minor fixes here and there. I hadn't considered doing a comparison matrix, but I haven't done a '_' lambda since it seems redundent with the one in fn.

emmelaich 9y ago

... and functools/itertools for completeness?

catnaroek 9y ago

From https://github.com/kachayev/fn.py https://github.com/kachayev/fn.py : > There are theoretical and practical advantages to the functional style: > - Formal provability This is bollocks. To prove things about your programs, you need a formal semantics for the language you're using.

bionoid 9y ago
> This [Formal provability] is bollocks. How precisely does modularity, composability and ease of debugging improve from this module? Not at all. It may have benefits, sure. But to claim these as general attributes is just sophistry in my personal opinion.
- catnaroek 9y ago
  Agreed. I just felt a stronger need to comment on the zeroth bullet point in the list.
lmm 9y ago
Functional style makes it easier to have a natural semantics that corresponds directly to the language proper: you can use a small-step semantics where evaluation is just reduction, and you then have a very simple and natural denotational semantics (the denotation of an expression is just the value it evaluates to) that obviously corresponds directly to your operational semantics. All that is much harder to do with programming styles that make use of pervasive, implicit state.
- catnaroek 9y ago
  A semantics is a property a programming language, not the style you happen to program in. --- @lmm > In practice no practical language provides formal semantics for the entire language Programming languages are mathematical objects and always have a formal semantics, regardless of whether someone has taken the trouble to write it down or not. What I'm saying is - the formal semantics that most languages have preclude the existence of compound values. Without those, you can't define interesting functions, and thus you can't program in a functional style.
  - lmm 9y ago
    In practice no practical language provides formal semantics for the entire language, only for restricted subsets of it i.e. particular styles within the language.
  - lmm 9y ago
    Responding to edits: > Programming languages are mathematical objects and always have a formal semantics, regardless of whether someone has taken the trouble to write it down or not. Not true for the usual plain-english meaning of "programming language". Plenty of things we call programming languages take a "the implementation is the spec" view, or simply can't be assigned any useful semantics in a way that's at all aligned with the defining characteristics of the language in question. Even in, say, Haskell, io explicitly lacks formal semantics. > What I'm saying is - the formal semantics that most languages have preclude the existence of compound values. Without those, you can't define interesting functions, and thus you can't program in a functional style. Python tuples are perfectly cromulent compound values. Python has a bunch of builtin classes for which the equality operators that are available in the language are all kind of useless, sure, but that's true in almost all languages.

entilzha 9y ago

Author here. 1.0 has been out for a while now, and I'm very committed to API stability. 1.1 (or 1.0.1) should be out as soon as I have some time with mostly minor fixes here and there. I hadn't considered doing a comparison matrix, but I haven't done a '_' lambda since it seems redundent with the one in fn.