1. 4

    I greatly enjoyed this post. Abstractions are so important and I liked how reflective this post is.

    In the context of the post I ask a question - aren’t all abstractions singular? And what does a faceted abstraction look like? Maybe I’m misunderstanding the terms.

    Here is an example. I want to design the API for an online blob storage service like S3 and minimize the costs of running the service. But I’m used to using local file systems that obey rules like “I can list the contents of a directory efficiently”. Blob stores are designed to make GET and PUT data operations efficient and cheap, and in the interest of cost savings I do not want my blob store to efficiently support things that are easy for a local file system to do like efficiently list directory contents, which might require some complex metadata storage and indexing.

    Is the blob store API singular or faceted? Is the local file system’s interface singular or faceted? Have I misunderstood the problem?

    1. 1

      Yes, singular abstractions are always faceted.

      Take the example given in the text, Palmer Eldritch who turns out to be a demiurge. While Dick can tell us in various ways how Eldritch’s reality overlays and overtakes our own, he can only do so using examples of which there are many. If the experience were truly singular, you couldn’t convey it with words. So we’re left to imagine such a state of being.

      Of course, my point isn’t to say that in some far-off future we couldn’t have our reality take over somebody else’s, it to to say that such an event would be past the ability of human language to adequately describe. (Simply imagine such a thing happening to a deaf-mute, or an intelligent animal). At best we can just hint around at what such a thing might be like and hope that our readers will use their faceted abilities at understanding and manipulating reality to extend to this possibility.

      None of that would matter except for the fact that we’re talking about coding abstractions, which, by definition, are created in some form of machine-human syntax. So we’re back to words, and we’re back to not having any sort of truly singular knowledge.

      Oddly enough the same isn’t true with multi-sensory input aside from language. Anybody who’s ever played a really cool procedurally-generated game has been in a world that completely overlays their own, just not entirely. Over time we’ll get better and better at this, bringing in more senses and making it all more immersive.

      It just won’t work with language. Or code (because of it’s relationship to language)

      tl;dr code is not existence

      1. 1

        Yes, singular abstractions are always faceted.

        I guess the whole article reminded me of George Berkeley’s subjective idealism: to be is to be perceived, nothing exists external to the mind. A ludicrous but powerful argument.

        1. 1

          Things exist external to the mind, of course, but (so far) we only have words to describe those things, and all words are “leaky”. So I can never, ever describe to you what my experience of “blue” is. Over time, if we talk, we might be 99.99% aligned on some concepts (mostly scientific ones), but it’ll never be perfect.

          So if you look at that 99.99% number and say “there is an external reality that we all share and it’s ludicrous to think of ourselves as brains in a vat”, you’re not wrong, but that line of reasoning works only for scientific concepts, and only after a lot of level-setting is done among participants. If you look at the “we’ll never ever be absolutely aligned” part and think “nothing exists external to the mind”, you’re not wrong either.

          We use human, spoken language to align in social groups to agree on formal systems (maths) that we use to explore the common shared reality around us. The human part and the math part are completely different universes of stuff with different rules and ways of thinking. (Apologies for the rambling. It’s early.)

      2. 1

        The distinction drawn in the essay is focused on how abstractions are adopted, extended, and discarded, rather than the abstractions themselves.

        1. 1

          I see, thanks!

      1. 2

        The thing I would really like to understand – and somehow no one is able to explain – is how equality and identity works with specialized generics and value types.

        E. g. if you have code like this:

        class Cell<T> {
            T value;
            Cell(T val) {
                value = val;
            }
            boolean contains(T that) {
                return (this.value == that) || (this.value.equals(that));
            }
        }
        

        … and now make it specialized:

        class Cell<any T> {
            T value;
            Cell(T val) {
                value = val;
            }
            boolean contains(T that) { ??? }
        }
        

        How would the implementation of contains look like?

        What would be the semantics?

        Would Cell<Double> and Cell<double> behave identical?

        1. 1

          My guess would be that every value type can be boxed, much like the existing primitives.

          1. 1

            But in which situations would it be boxed?

            Will == be boxed? If yes, how would you recover IEEE equality for floating points, and if it wasn’t boxed, then all generic code would subtly change behavior when people start specializing their generics.

            1. 2

              Maybe I’m misunderstanding your point, but since generics assume everything extends Object, you’d use .equals() instead of ==, and the boxed value type would generate the appropriate logic inside of .equals().

              1. 1

                But how would that “appropriate logic” look like?

                I think the problem is that == does two completely different things on reference types and value types, and while you can implement equals for value types (even without boxing), you can’t really recover == in a generic context that allows both reference and value types.

        1. 3

          I’m about halfway through the implementation of https://github.com/lacuna/bifurcan , which has functional/persistent data structures in Java without all the language ecosystem baggage that usually comes with it. Yesterday I confirmed that my hash-map is (slightly) faster than Java’s HashMap, which is promising.

          1. 10

            This is a really great talk, highly recommended even if you don’t care about graphics or game development.

            1. 5

              All Casey’s talks are awesome.

              1. 3

                His sense of humour is all sorts of absurd and lovely. He’s the same way on the Handmade Hero stream.

                1. 3

                  You should hear Jeff and Casey show, it’s the best podcast ever.

                  1. 1

                    I think I prefer Idle Thumbs and the Diecast, although I do skip to the bits I like, anything mentioning Far Cry 2 for example :) So I actually only listen to about 50% of each episode for each of those.

                    1. 1

                      I tried that a month ago, actually, and I didn’t find it enjoyable in the same manner. Not sure why.

                    2. 1

                      You should hear Jeff and Casey show, it’s the best podcast ever.

                1. 9

                  Ask Lobste.rs: Any videos you particularly liked? If so, why?

                  1. 6

                    I really liked “End-to-end encryption: Behind the scenes” – it was quite a well-coordinated performance. :-)

                    1. 3

                      “Rusty Runtimes: Building Languages In Rust” by Aditya Siram.

                      Aditya implements a klambda-to-Rust compiler in Rust! Very cool. Also exciting because klambda is what powers the Shen lisp language.

                      1. 2

                        Here’s one list of recommendations.

                      1. 3

                        I once worked at a company where the PM defined the difference between senior and junior developer in terms of providing better estimates for the business. Nothing about knowing how computers work, how large codebases evolve, what works and what doesn’t in terms of security or performance or maintainability or anything else, or having a broad-based knowledge of computer science. (You know, actual senior engineer stuff.)

                        That company had substantial layoffs, a few months later.

                        1. 6

                          I often use a slightly broader version of that definition, which is “senior engineers reduce risk”. This can encompass technical risk (everything you list), but also cultural risk (who do we hire, how do we deal with failure) and business risk (how do we deliver features and products in a timely manner).

                          It makes sense that a product person would focus on the business side of things, just like fresh CS grads tend to focus on their volume of code - it’s the most visible artifact of a complex process. It can be annoying to work with people who are so myopic, but opening their eyes to the bigger picture is just another thing that a senior engineer can and should be expected to do.

                          1. 1

                            Oh, that’s really cool framing. Thank you.

                        1. 5

                          I’m starting work on a talk about a neat little monitoring tool I’ve been building for Fitbit: http://conf.researchr.org/track/pmldc-2016/PMLDC-2016#Invited-Talks

                          1. 5

                            Given all of the controversy leading up to lambdaconf, and about the presenter, you would think that this talk is all about white supremacy, or slavery. IT IS NOT! IT IS SAFE TO WATCH!

                            1. 15

                              As someone who was significantly disappointed at the inclusion of this presenter at LambdaConf, I am in no way surprised that the talk was entirely technical without references to that crap (though I didn’t actually watch the video, so I’m going on faith here).

                              My objection was not to the possibility of the presenter “slipping” on accident or on purpose, though that would suck. My objection was in giving a place of honor to someone who strongly proselytizes that people are inferior based on their skin color. I don’t care how good he is at programming; we, as an industry, have no obligation to further his career.

                              1. 12

                                We used Nazis to get to the moon. Haber has a Nobel Prize despite being pivotal in developing chemical warfare.

                                It’s shortsighted to ignore the accomplishments of people because you disagree with their politics.

                                People like you, unable to recognize the intrinsic value of others' work because of prejudice, are the same folks who hurt folks like Turing. Same mechanism.

                                EDIT: Folks, please don’t downvote something as “troll” just because you disagree with it–that’s what “incorrect” is for.

                                1. 16

                                  Intolerance and intolerance-of-intolerance aren’t equivalent. An open society isn’t required to let hate speech stand freely next to everything else.

                                  I like weird software. I think Urbit is interesting. But I’m also not one of the groups Yarvin has spewed bile at, and I’m not willing to exclude all of them and their ideas just to give him a chance to prove Urbit’s worth.

                                  1. 6

                                    Is it necessary to exclude people in order to evaluate Urbit? Why?

                                    1. 17

                                      Because Yarvin’s presence has side-effects.

                                      Or, at least, that’s the case to be made; I recognize that opinions differ on whether it’s true and to what extent.

                                      We had this conversation a month or two ago, and it was productive but demanded a lot of attention, so I would like to leave it at that, this time around. :)

                                  2. 6

                                    As someone who is probably somewhat in agreement with listrophy here, I want to be clear that I don’t think anyone should feel bad for participating with Urbit technically. I don’t think it should be ignored. I do think that someone’s politics is not so inseparable from their person, though, so I feel we should question the politics of those who represent and lead parts of our communities.

                                    I also disagree about the Turing, bit. Turing wasn’t hurt, to my understanding anyway, so much because we failed to recognize the impact of his ideas, but instead because we believed that his person was morally indecent and that the state had a right to act to destroy these indecencies. I question Yarvin’s position because he reflects ideas similar to that one—but I’m more than happy to investigate Urbit in the mean time.

                                    That all said… I think if we want to continue this conversation, it’d be better to do it in email rather than in this thread.

                                  3. 2

                                    Can you or someone else summarize his opinions on race?

                                    When you say “are inferior based on their skin color”, are you referring to the belief that black people generally have lower IQs than white people, or that white people have lower IQs than asians? Or is there more to it than that?

                                    I see the slavery stuff, but I also see him denying any support for slavery as an institution.

                                    1. 8

                                      I believe what he literally said is that some races are better suited to slavery, particularly of the agricultural plantation variety, in much the same way that some breeds of horse are better suited to pull a plow than others. There is then considerable debate and disagreement about what he really meant because the whole topic of race is rife with dog whistle politics, such that he can say one thing but everybody “knows” what he’s really talking about. https://en.wikipedia.org/wiki/Dog-whistle_politics

                                1. 1
                                  • Data and Reality
                                  • A Timeless Way of Building
                                  • Patterns of Software
                                  • Seeing Like a State
                                  • Invisible Cities
                                  1. 4

                                    All of these “obelisk-shaped” fields require expensive, highly stratified education, and involve some sort of “up or out” early career filter. There’s only a lot of room at the top when you ignore all the people who tried to get there, and failed. There are an enormous number of lawyers who are unemployed or doing doc review, even though they have a JD and passed the bar.

                                    If we redefine “software engineer” to be everyone at some sort of Cravath-style consultancy, I’m sure we can create an obelisk, but that neither solves the larger problem nor supplies the volume of engineers needed to solve the existing set of software problems.

                                    1. 3

                                      All of these “obelisk-shaped” fields require expensive, highly stratified education, and involve some sort of “up or out” early career filter.

                                      This is true of the actuarial sciences as well, which I think is the field that provides the best model. People who struggle with the exams leave and do other things. I like that barrier better than parental capital.

                                      There are an enormous number of lawyers who are unemployed or doing doc review, even though they have a JD and passed the bar.

                                      Law has been poorly managed, it’s true. There are too many law schools and too many lawyers and that has created a legal underclass (doc review) as well as increased the importance of the elite law schools (“top 14”; I have no idea why it has to be 14 and not some other number).

                                      The Cravath model is old and it actually worked for a long time. It relied somewhat on Cravath’s reputation, though: if you didn’t make partner, you’d be put on a partner track somewhere else. Boomer greed is what killed it: rich partners wanting to become even richer cut the number of partner positions and the likelihood of promotion to partnership plummeted (into the single-digit percentages, by some accounts). Imagine that, rich Boomers ruining something. Nothing lasts forever; if you create something good, some greedy generation will come along later and kill or squander it. However, a system that improves the situation of engineers for the next 100 years would almost certainly outlive me. ```

                                      I’m sure we can create an obelisk, but that neither solves the larger problem nor supplies the volume of engineers needed to solve the existing set of software problems.

                                      If we’re needed in volume, then we should be doing something with that demand. We should be earning more than the VPs and we should be able to work whereever we want, rather than being crammed into open-plan steerage. And we certainly should be able to kill the infantilizing “Agile” micromanagement fad.

                                    1. 5

                                      Last week I released the first chapter of my book Elements of Clojure, and since some people actually gave me money I have to start working on the second one.

                                      Honestly, though, I had forgotten how much I enjoy writing. I have three or four half-complete essays/posts that have been sitting around for a year or more, and I may try to finish them up while my head’s in the right place.

                                      1. 5

                                        If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea. –Antoine de Saint-Exupéry

                                        This is an interesting book.

                                        It’s interesting because it doesn’t try to be another Clojure tutorial. There are books about that already. Instead, it tries to capture the fundamental ideas behind the language. It’s much like what the language author Rich Hickey does in his talks: he doesn’t try to convince people to use his language because it’s “amazing”.

                                        Instead, he talks about essential ideas, like immutable data structures, concurrency, state, and identity, only presenting Clojure as something that embodies those ideas and concepts.

                                        So it’s very much like a Clojure book that really “gets” the language, but like the criticism on HN I think some of the wording is a bit vague. Or not vague, but sometimes very detailed and other times quite stilted. I think this reflects more the language design itself than ztellman’s writing, since at times I get the feeling that the language design itself can be a bit vague. It was, after all, designed by an experienced Common Lisp programmer. Similarly, this book is written by an experienced Clojure programmer, and in both good and bad, it shows. Mostly good.

                                        Sadly, I cannot offer any better criticism than that, but I look forward to reading the whole thing once it’s finished.

                                        1. 3

                                          Thank you for your thoughts. I’m glad you think it’s worthwhile, despite any shortcomings.

                                          I’m trying to interleave abstract and concrete advice, and it’s pretty difficult to strike the right balance. I’m certainly not completely happy with the chapter, as it stands. I think the vague and stilted elements reflect at least a little on my writing, but they’re impossible to avoid entirely unless I take out all the abstract bits. Maybe I’ll have it figured out by the time I finish the other chapters.

                                        1. 4

                                          I’m writing a book on Clojure, and am about 2/3rds of the way through the first chapter. It’s a bit of a slog.

                                          1. 0

                                            It’s too bad this still targets the obese and slowly disappearing JVM. The one thing really holding back Clojure is the fact that it uses a heavy-weight dinosaur technology instead of something like LLVM to compile directly to native code.

                                            Edit: “Troll”? Really? How is any of that trolling, please explain. I’ve used Clojure and have watched The State Of Clojure surveys as they come out every now and then. Consistently this issue is brought up again and again.

                                            1. 13

                                              Some facts about Clojure:

                                              • It relies on having a high-quality GC implementation
                                              • It relies on having high-quality concurrency primitives and a well-defined memory model
                                              • A huge part of its value proposition is being effective glue for an existing ecosystem

                                              The JVM provides all of these, while LLVM provides less than all of these out of the box. I have no doubt someone could write their own pared-down version of the JVM for Clojure to run on, but that’s clearly not a priority for the people running the core project, nor for anyone else I’m aware of in the Clojure community. Other than aesthetic objections to the JVM, I’m not sure why it’s worthwhile to pursue. Feel free, though.

                                              1. 2

                                                Other than aesthetic objections to the JVM

                                                Let’s not be disingenuous, nobody is making “aesthetic objections” to the JVM. They are making technical objections to the JVM on the grounds that it is a poor virtual machine. Its various significant flaws include:

                                                1. Very long startup time that leads to decreased developer productivity and poor deployability
                                                2. Poor platform support (those great days when this was not true are long gone)
                                                3. Large memory usage

                                                I stopped using Clojure because of it, and I’m certain many others have as well.

                                                It would’ve been better to implement this language as another transpiled-to-JavaScript language and leverage the asynchronous Node runtime than to use the JVM. Even better would be to fork the Go runtime.

                                                The JVM is Clojure’s biggest handicap, and it is not helpful to Clojure to be in denial about this fact.

                                                1. 10

                                                  The JVM is far from perfect, but has best-in-class GC and tooling for monitoring and debugging complex production issues. If you compare V8 and JVM for backend services and find the JVM wanting, I’m not quite sure how to respond to that. Likewise, the Go runtime is still significantly behind the JVM on both these counts.

                                                  I’m sorry if you feel it’s unfair to characterize your focus on footprint and startup time as aesthetic complaints, but these are not things that have been at all relevant to my extensive production use of Clojure. I freely admit that my use cases are not representative of everyone else’s, but I think your assertion that the JVM is Clojure’s biggest handicap misses the point of Clojure and what sorts of problems it’s trying to solve.

                                                  1. 5

                                                    I feel like the issue here is that those use cases are heavily constrained by the JVM’s limitations. There was a time when Java applets meant to run in the browser were commonplace. It was fairly brief, because of that startup time. Indeed Java is heavily used today for server-side situations, where startup time is not a constraint.

                                                    I do see your point that this is a choice about the audience of Clojure, and one which was made intentionally. I personally feel rather irritated that there was an excellent standard and portable Lisp, which has not attained the popularity that Clojure has. (Yes, there are several JVM implementations of Common Lisp.)

                                                    I mean, I know that it would be highly unfair to blame Clojure for being popular. And, actually, I feel that I understand the cultural factors (related to a culture of writing code with the expectation others will reuse it) that have gotten Clojure more mindshare than CL has had in a long time. But I still understand being wistful about things that didn’t happen, and I think that’s where @itistoday is coming from.

                                                    1. 3

                                                      That is more of a dismissal of my comment than an actual reply.

                                                      People want a fast, lightweight, portable language. The JVM makes that impossible. Lots of people would jump at the chance to use a Lisp like Clojure to develop games for iOS or beautiful desktop applications, but they can’t (or they can, but only by jumping through some insane hoops few are willing to go through). Even server apps are rarely done in Clojure because of the high memory demands and poor platform support. Why? The JVM.

                                                      1. 6

                                                        You seem more critical of the JVM than Clojure, and you’re conflating your resentment for the former as distaste for the latter.

                                                        Certainly Clojure’s lack of adoption at scale has nothing to do with its reliance on the JVM, on the contrary, that if anything has helped it to become popular. If anything that is slowing Clojure down is either its strangeness (yes, people don’t like Lisps) or lack of promotion. It’s growing in popularity, but still shrouded in relative obscurity.

                                                        I do not think your resentment for the JVM is well-founded. It has its drawbacks, but they aren’t in performance or memory consumption. Startup times aren’t relevant on server side programs, hot swapping on the other hand is.

                                                        Say what you want about the rising popularity of other languages, but the JVM isn’t disappearing. The new G1 garbage collector is unrivaled in sophistication and performance. What is more, the addition of specific value types to Java9 will boost its performance even more yet keep language interoperability easy (reified generics, which it is not getting, would make this difficult). Compound this with the rising popularity of Scala, Kotlin and Clojure and other JVM languages, the popularity only growing.

                                                        1. 2

                                                          you’re conflating your resentment for the former as distaste for the latter.

                                                          I have no distaste for the latter. Don’t know why you’re getting upvotes for what is an obvious straw man.

                                                          performance

                                                          I didn’t mention performance.

                                                          or memory consumption

                                                          Memory consumption is a big problem when a tiny web app takes up a hundred of megs of RAM.

                                                          the popularity only growing.

                                                          OK, I have not seen evidence of that.

                                                    2. 4

                                                      If you want Clojure but on Node, you can use Clojurescript, which is an almost-Clojure that compiles to JS. Its primary motivation was to run Clojure in the browser, but since it exists, people are also using it out-of-browser on top of Node. Its upsides are faster startup time and exact equivalence between the in-browser and out-of-browser VMs, if you want to run the same code both places. Downsides are generally worse performance on longer-running code, and a more limited set of concurrency primitives (e.g. no STM).

                                                      1. 1

                                                        If you want Clojure but on Node, you can use Clojurescript, which is an almost-Clojure.

                                                        I did ClojureScript development as well, however development still required using the JVM, and the code it generated was oddly bloated & convoluted. That said, yes, the fact that the end-result doesn’t require the JVM is quite nice.

                                                        EDIT: One major drawback though (last I checked) is that it’s not designed to target or work well with Node.

                                                        1. 2

                                                          I’ll point you to Sibilant

                                                      2. 4

                                                        Even better would be to fork the Go runtime.

                                                        My understanding is that Google’s Go runtime doesn’t allow loading new code at runtime. Sounds like a disastrous choice for interactive development.

                                                        1. 1

                                                          Interesting, didn’t know that. I also don’t know whether, if true, that is a difficult thing to fix or not. Other runtimes that could be worth exploring include LuaJIT, Julia, and yes, V8.

                                                          1. 1

                                                            There was a GSoC project a couple years ago to port to Lua. No idea how far it got.

                                                            Suggesting the mainline development should just stop because some people prefer the tradeoffs of other runtimes is pretty bonkers though.

                                                            1. 1

                                                              Suggesting the mainline development should just stop because some people prefer the tradeoffs of other runtimes is pretty bonkers though.

                                                              Good thing I didn’t suggest that.

                                                    3. 7

                                                      The value add of Clojure (and Clojarr) is simply developer efficiency relative to Java in using Java tools and libraries. Same as Scala or JRuby or Kotlin or what have you. Given this goal, criticizing Clojure/arr for not targeting bare metal is frankly silly since bare metal performance has little to do with the utility of the projects.

                                                      Thanks to @ztellman for articulating the related performance concerns much better than I was able to.

                                                      1. 3

                                                        I agree with other commenters that a huge part of Clojure’s value proposition is the fact that you can interoperate with a huge existing ecosystem of libraries. This is a really interesting project and I’m glad to see a Clojure fork that adopts community-driven development in the vein of other languages like Rust.

                                                        From a purely experimental/shits-and-giggles perspective, I’ve been thinking about the ramifications of implementing a Clojure-alike on top of a Swift-based runtime/interpreter:

                                                        • Clojure’s persistent immutable data structures map surprisingly cleanly to Swift’s copy-on-write value type collections
                                                        • The fact that data structures are immutable makes it a lot more difficult to produce the circular references that RC doesn’t handle well
                                                        • Swift doesn’t have a proper concurrency model yet. I looked briefly into using GCD to implement the (non-STM) concurrency primitives but didn’t get very far before having to drop the project
                                                        • Community-driven development hopefully can steer parts of the Swift project in a way that deficiencies for this use case (e.g. anemic reflection support for interop) can be addressed eventually
                                                      1. 2

                                                        This is cool. It reminds me of PyPy or Rikes. Have you looked at Janino ?

                                                        1. 1

                                                          I haven’t, it looks very much in line with my interests, thanks.

                                                          1. 1

                                                            I could see Janino being used to lazily generate a forrest of code from a combinatorial type explosion, one could also start to do profile guided optimizations for the platform at hand. Always gotta find ways to lengthen those boot up times!

                                                          1. 3

                                                            I’m finishing up an instrumented, adaptive thread pool for the JVM: https://github.com/ztellman/dirigiste. I haven’t been able to find anything like it, which is surprising to me, given how mediocre the default offerings are.

                                                            1. 1

                                                              How is the instrumentation accessed ? Can I query it via JMX? Is it controllable via JMX? How are governors implemented for clients that consume your library?

                                                              1. 2

                                                                The readme is pretty detailed w.r.t. how the instrumentation can be accessed and how the control loop works. No JMX hooks are provided, but you could easily propagate to it.

                                                                1. 1

                                                                  Just went back and checked it out. That readme is a specimen in excellence.

                                                              2. 1

                                                                That’s really cool! I tried to do something similar in the past, but ended up building a terrible autopilot instead to learn PID control. Never came back to it unfortunately. Every other threadpool doesn’t do quite what I liked with retiring unneeded threads. I only wanted it to expand to provide for peak load and then follow it back down again. Watching with interest.

                                                              1. 7

                                                                I wrote Clojure that writes Java that improves the implementation of Clojure. I’m waiting to see what people’s reaction will be. If it’s positive, I’ll do it some more.

                                                                1. 7

                                                                  Better advice is to not use regular expressions, but use parser combinators, since they actually compose.

                                                                  1. 5

                                                                    The power of a regex is that it can be compiled down to an FSM, which can be significantly faster. As a personal plug, I wrote an FSM generator that uses combinators: https://github.com/ztellman/automat. I haven’t seen anything else in this vein (even Ragel is a DSL rather than composable pieces), and I’m not sure why.

                                                                    1. 1

                                                                      Oh you’ve just reminded me we need an equivalent of automat for Haskell. Thanks.

                                                                      1. 1

                                                                        There are already some libraries for this:

                                                                        http://hackage.haskell.org/package/regex-applicative

                                                                        More would be even better.

                                                                        1. 1

                                                                          Does it compile to a FSM?

                                                                          1. 2

                                                                            Yes, it compiles to a nondeterministic FSM.

                                                                            1. 1

                                                                              Why non-deterministic? A deterministic one would be much more useful.

                                                                              1. 1

                                                                                Would it? Doesn’t the powerset construction say it doesn’t really matter?

                                                                                1. 3

                                                                                  An NFA by itself doesn’t give you anything. You need to transform it into a DFA, minimize, and define an (efficient) execution model for the DFA. Anything shy of that is just a homework exercise.

                                                                    2. 3

                                                                      Agreed. And really no more trouble to use. The example at the end could have been expressed using a peg library with barely any more typing.

                                                                    1. 10

                                                                      I’m putting the finishing touches on the initial release of Manifold, which is meant to sit at the intersection of the n-many synchronous and asynchronous JVM stream representations. Anyone who has an opinion on Clojure or stream abstractions is welcome to give feedback.

                                                                      1. 2

                                                                        This looks like a great way to deal with asynchronous operations in Clojure! Will definitely be using this in upcoming projects.