On Thu, Aug 6, 2020 at 4:24 PM Chary Chary <chary...@gmail.com> wrote:
> Are you also planning to define beancount "API" more clearly and safely? Roughly speaking the same data model and similar access to data structures, special containers, and functions, via Python. We touched upon the subject in this discussion: > https://groups.google.com/g/beancount/c/UatQey1X0OY/m/0FGCrY5fAwAJ > > Would it not be logical, that by using defined API (I think you called it > "a contract") user is not able to "break" something, the API would simply > not allow this to happen? > This is a new major revision, I do want the freedom to evolve things and make them better, at least a bit. It won't be perfectly the same as before, but it'll be very close, at least conceptually. I know this may be a naive question (as I am not professional), but why > doesn't beancount use object-oriented approach? So you have an object, > representing all transactions, and user can manipulate them (add / delete) > through methods, but implementation of the class does not allow unsafe > changes / operations? > That's a much longer discussion to have an out of scope for this forum, but I can offer a view. Essentially, OO in general was a rather unfortuitous and pointless 20 year detour in the history of programming application, a gigantic waste of time, whose promises never yielded tangible benefits, and I don't like it. It never became an accurate realization of Alan Kay's original concept for OO either. What people call OO today encourages side-effects on the object's private attributes, which is barely less worse than mutating global variables (in terms of making programs difficult to understand), so in a sense, by moving to OO we only trade one form of evil for another. Every mature software practitioner eventually comes to appreciate that mutation is the central aspect of what we do that makes programs difficult to reason about and the one that matters most above all; the whole game of programming eventually reduces to an act of balance, whereby you have to mutate *something* to get anything done, but every mutation of data inserts a little bit of extra complexity in your programs--and makes it that much harder to maintain, so the focus is shifted mostly to structuring where and when you do choose to break the rules (and mutate) in order to keep your designs simple and isolated so that they're easily testable and maintainable. Academics are lagging behind - many of them don't practice large-scale development - so students are still trickling out of schools with aspirations to do OO Java or OO Python; this is a mild tragedy, but redemption is usually quick if they choose to go work somewhere that has adopted a good amount of discipline and rigor. Moreover, most of the large "big tech" companies have all drifted in that direction over time, i.e., much of the codes in these companies consist of distributed systems passing around "write-once thereafter read-only" data structures (e.g., protocol buffers or equivalent) with only a little bit of transient mutable state contained here and there. Distributed batch computation pipelines (i.e., cascades of MapReduce) are similarly usually functional in nature. This is in sharp contrast to the style of "OO" we used to do in 1995: lots of object references and threads and mutexes and shared access coordination all over the place--it was a debugging disaster regularly, and a kind of perverse fun for those of us who got good at it. Nowadays, I seem to hardly ever use tracing debuggers anymore--something really has changed in the culture, even if we use the same languages (e.g., C++). A subset of people "get it" early on - those inclined toward principles, e.g., usually people whole enjoy rigor and math - and commit themselves to absolutes, choosing to program in languages which provide lots of support and constraints for controlling mutation tightly (e.g. Haskell), or programs whose data structures are all immutable (e.g., Clojure). Others, like me, follow a more pragmatic approach (at least in this particular project), sticking with deeply popular and well-established languages but choosing to use them in somewhat limited and unorthodox ways (I call this the "functional-ish" style), avoiding mutation most of the time (thus getting most of its benefit) but also harvesting the much broader set of existing library code and tools those languages offer, due to their much higher level of adoption. So Beancount has that style. This isn't a religion for me, I just really like to build nice things that work... but I'm not alone going slightly askew in that way - e.g., Google's internal style guide has been conservative w.r.t. the broader C++ community for a long time for instance ( https://google.github.io/styleguide/cppguide.html), and a subset of the Python community mostly stays away from classes and OO as well. As a programmer one does have the freedom to avoid entire subsets of idiomatic language features... Inheritance is on the menu? Thank you sir, but I won't have any. > On Saturday, July 4, 2020 at 8:34:50 AM UTC+2 bl...@furius.ca wrote: > >> Hi, >> Today I'm starting development on Beancount v3. >> >> This is going to be a pretty big change and will take a while. >> I've laid down the details in this document: >> >> https://docs.google.com/document/d/1qPdNXaz5zuDQ8M9uoZFyyFis7hA0G55BEfhWhrVBsfc/ >> <https://docs.google.com/document/d/1qPdNXaz5zuDQ8M9uoZFyyFis7hA0G55BEfhWhrVBsfc/edit#> >> >> This file describes the new set of dependencies for it: >> >> https://docs.google.com/document/d/10R-msZljuqFY8nckUnR1jVxMX1ol7rJUCMZo7w7QUQs/ >> <https://docs.google.com/document/d/10R-msZljuqFY8nckUnR1jVxMX1ol7rJUCMZo7w7QUQs/edit#> >> >> And there is a dedicated installation file for the in-development version: >> >> https://docs.google.com/document/d/1WwZYqsp28Uuk5eFqHQ1u1zqdjghymy8S_Yo-OJENoa4/ >> <https://docs.google.com/document/d/1WwZYqsp28Uuk5eFqHQ1u1zqdjghymy8S_Yo-OJENoa4/edit#> >> >> The short version is that v3's core is going to be ported to C++ using a >> Bazel build, and the codebase will be sectioned between core and the rest. >> I just merged the new build definition in master. >> >> The current head will be branched as "v2" and maintained stable. >> It will build with both setup.py and Bazel. >> Backward compatible fixes to it will be done there and merged into v3. >> v3 development will occur on branch "master" and breaking changes will >> occur there. >> >> Comments appreciated (on the docs, or here if you prefer), >> >> -- > You received this message because you are subscribed to the Google Groups > "Beancount" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beancount+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beancount/7cbcaa0d-7556-4c26-a41c-c4f325d1ab93n%40googlegroups.com > <https://groups.google.com/d/msgid/beancount/7cbcaa0d-7556-4c26-a41c-c4f325d1ab93n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to beancount+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhP2sgGvPig-zWveJWsY4c56aovGK5uSJL%3Djcud8WBuBXQ%40mail.gmail.com.
