1. 4

    hm, I think a few examples would be really useful. My first thought is that people’s requirements for the same project would be too specific for anyone to be satisfied with another’s implementation.

    That and software tends to take forever to develop - like sometimes years if someone doesn’t have a specific deadline and is writing it solo in their spare time. I know the idea was to have smaller projects than that, but people are likely to underestimate by orders of magnitude

    1. 2

      I cut the samples out because I have a pretty strong (and maybe unusual) bias in what I want. And this idea is meant to be more general.

      For all programs, here’s the general property I want.

      In my case, on top of documentation (or even instead of it), I’d like to have enough instructions for rebuilding the whole thing from scratch. This means favouring simpler internals and fewer large list of cases.

      For servers, we know to have script and configuration setup to restore state when the machine reboot. This would be the human version of that.

      As a bonus, on top of describing what works, add a few remarks about what’d be lost with some “obvious” simplifications to the system.

      I really only need the program or library to prod it to check and understand the properties it has.

      This means the language and library used doesn’t matter as much although being able to read the source without too much experience is definitely a plus.

      As I’ve said in that post, I still need to think of projects of that scope to add myself. So what follows need more thought.

      • A PEG grammar for Python 3. I want to use my own parsing library but don’t mind if it uses a different library. It has to be a parsing expression grammar (PEG) using ordered choice though. The parser itself need not be written in Python, although that’d be nice. Bonus points for concision.

      Definitely not for this time frame:

      • An extensible low level editor for interactively create low level programs (in C and assembly). I want something more visual and better than a debugger (workflow-wise, not necessarily feature-wise). Let me set/view regions of memory while the program runs or is paused.

      The editor itself needs to be “simple” with relying on its extensibility (which also means making it “easy” to extend).

      For a more doable project, even a much smaller (in terms of complexity, not resource use) gdb or lldb would be a good start.

      That and software tends to take forever to develop - like sometimes years if someone doesn’t have a specific deadline and is writing it solo in their spare time.

      Indeed and I’m unfortunately well acquainted with this problem. But this phenomenon is worst with two pieces of software, or three, or more…

      In some sense, these trades are a solution to this problem although it does not face it head on.

    1. 7

      Laziness is neat. But just not worth it. It makes debugging harder and makes reasoning about code harder. It was the one change in python 2->3 that I truly hate. I wish there was an eager-evaluating Haskell. At least in Haskell, due to monadic io, laziness is at least tolerable and not leaving you with tricky bugs (as trying to consume an iterator in python twice).

      1. 6

        I had a much longer reply written out but my browser crashed towards the end (get your shit together, Apple) so here’s the abridged version:

        • Lazy debugging is only harder if your debugging approach is “printfs everywhere”. Haskell does actually allow this, but strongly discourages it to great societal benefit.

        • Laziness by default forced Haskellers to never have used the strict-sequencing-as-IO hack that strict functional languages mostly fell victim to, again to great societal benefit. The result is code that’s almost always more referentially transparent, leading to vastly easier testing, easier composition, and fewer bugs in the first place.

        • It’s impossible to appreciate laziness if your primary exposure to it is the piecemeal, inconsistent, and opaque laziness sprinkled in a few places in python3.

        • You almost never need IO to deal with laziness and its effects. The fact that you are conflating the two suggests that you may have a bit of a wrong idea about how laziness works in practice.

        • Haskell has the Strict language extension which turns on laziness by default. It’s very rarely used because most people experienced enough with Haskell to know about it prefer laziness by default. This is experimental evidence that laziness by default may actually be a good idea, once you’ve been forced to grok how it’s used in practice.

        1. 1

          Haskell has the Strict language extension which turns on laziness by default. It’s very rarely used because most people experienced enough with Haskell to know about it prefer laziness by default. This is experimental evidence that laziness by default may actually be a good idea, once you’ve been forced to grok how it’s used in practice.

          I am not quite sure whether this is really evidence. I actually never tried to switch it on. Iwonder whether that option plays nicely with existing libraries, I gues not many are tested for not depending on lazy-evaluation for efficient evaluation. If you use Haskell and Hackage, I guess you are bound with rolling with the default.

          1. 2

            It works on a per-module basis. All your modules will be compiled with strict semantics, and any libraries will be compiled with the semantics they chose.

        2. 3

          Idris has strict evaluation. It also has dependent types, which are amazing, but strict evaluation is a pretty good perk too.

          1. 2

            I thought there were annotations for strictness in Haskell.

            1. 3

              yes, but I consider it to be the wrong default. I’d prefer having an annotation for lazy evaluation. I just remember too many cases where I have been bitten by lazy evaluation behaviour. It makes code so much more complicated to reason about.

              1. 1

                Do you happen to remember more detail? I enjoy writing Haskell, but I don’t have a strong opinion on laziness. I’ve seen some benefits and rarely been bitten, so I’d like to know more.

                1. 1

                  I only have vague memories to be honest. Pretty sure some where errors due to non-total functions, which I then started to avoid using a prelude that only uses total ones. But when these occured, it was hard to exactly find the code path that provoked it. Or rather: harder than it should be.

                  Then, from the tooling side I started using Intero (or vim intero). (see https://github.com/commercialhaskell/intero/issues/84#issuecomment-353744900). Fairly certain that this is hard to debug because of laziness. In this thread there are a few names reporting this problem that are experienced haskell devs, so I’d consider this evidence that laziness is not only an issue to beginners that haven’t yet understood haskell.

                  PS: Side remark, although I enjoy haskell, it is kind of tiring that the haskell community seems to conveniently shift between “Anyone can understand monads and write Haskell” and “If it doesn’t work for you, you aren’t experienced enough”.

            2. 2

              Eager-evaluating Haskell? At a high level, Ocaml is (more or less) an example of that.

              It has a sweet point between high abstraction but also high mechanical sympathy. That’s a big reason why Ocaml has quite good performance despite a relatively simple optimizing compiler. As a side effect of that simple optimizing compiler (read: few transformations), it’s also easy to predict performance and do low-level debugging.

              Haskell has paid a high price for default laziness.

              1. 2

                As a side effect of that simple optimizing compiler (read: few transformations), it’s also easy to predict performance and do low-level debugging.

                That was used to good effect by Esterel when they did source-to-object code verification of their code generator for aerospace. I can’t find that paper right now for some reason. I did find this one on the overall project.

                1. 1

                  Yes, however I would like to have Typeclasses and Monads I guess, that’s not OCaml’s playing field

                  1. 1

                    OCaml should Someday™ get modular implicits, which should provide some of the same niceties as typeclasses.

                    1. 1

                      OCaml has monads so I’m really not sure what you mean by this. Typeclasses are a big convenience but as F# has shown are by no means required for statically typed functional programming. You can get close by abusing a language feature or two but you’re better off just using existing language features to accomplish the same end that typeclases provide. I do think F# is working on adding typeclasses and I think the struggle is of course interoperability with .Net, but here’s an abudantly long github issue on the topic. https://github.com/fsharp/fslang-suggestions/issues/243

                    2. 1

                      F# an open source (MIT) sister language is currently beating or matching OCaml in the for fun benchmarks :). Admittedly that’s almost entirely due to the ease of parallel in F#.
                      https://benchmarksgame.alioth.debian.org/u64q/fsharp.html

                    3. 1

                      Doesn’t lazy io make your program even more inscrutable?

                      1. 1

                        well, Haskell’s type system makes you aware of many side-effects, so it is a better situation than in, for example, Python.

                        Again, I still prefer eager evaluation as a default, and lazy evaluation as an opt-in.

                      2. 1

                        Purescript is very close to what you want then - it’s basically “Haskell with less warts, and also strict” - strict mainly so that they can output clean JavaScript without a runtime.