There’s nothing obsolete about text. Visual languages don’t work. They’ve been tried hundreds of times, to no avail, because GUIs are fundamentally bad user interfaces for experienced users. Text is a better interface for power users, and programming languages are for power users.

Bret Victor explains the persistence of textual languages as resistance to change, drawing an equivalence between users of textual languages now and assembly programmers who scoffed at the first higher-level programming languages. But this thread is evidence that at least some people are interested in using a language that isn’t text-based. Not everyone is fairly characterized by Bret Victor’s generalization. So then why hasn’t that alternative emerged? There are plenty of niche languages that address a minority preference with reasonable rates of adoption. With the exception of Hypercard, I can’t think of viable graphical programming language. Even Realtalk, the language that runs Dynamicland (Bret Victor’s current focus), is text-based, being a superset of Lua. I keep hearing about how text-based languages are old-fashioned and should die out, but I never hear anything insightful about why this hasn’t happened naturally. I’m not denying that there are opportunities for big innovation but “make a visual programming language” seems like an increasingly naive or simplistic approach.

Nix and/or NixOS experience is super useful too. We use it to ship all of our team’s software.

Indian nationals only?

I am located in bangalore. How can we discuss this further?

I KeePassX together with SyncThing on multiple Ubuntus and Androids for two years now. By now I have three duplicate conflict files which I keep around because I have no idea what the difference between the files is. Once I had to retrieve a password from such conflict file as it was missing in the main one.

Not perfect, but works.

Duclare, using ssh instead of SyncThing would certainly work since the database is just a file. I prefer SyncThing because of convenience.

I use Keepass for a few years now too. I tried other Password managers in the meantime but I never got quite satisfied, not even pass though that one was just straight up annoying.

I’ve had a few conflicts over the years but usually Nextcloud is rather good at avoiding conflicts here and KPXC handles it very well. I think Syncthing might casue more problems as someone else noted, since nodes might take a while to sync up.

I use NixOS on everything and completely agree. It’s a massive investment. It was worth it for me, but it shouldn’t have to be a massive investment. Need better tooling and docs.

You basically need to read all the nix pills (https://nixos.org/nixos/nix-pills/), the nix manual, the nixpkgs manual and the nixos manual in a loop gradually filling in what is going on… which takes a long time.

I’ve tried reading all of this but I found it all horribly confusing and frustrating — until I read the original thesis on it, which I still think is (perhaps surprisingly) still the best resource for learning how nix works. It’s still a pretty big investment to read, but imho it’s at the very least a much less frustrating experience than bouncing from docs to docs.

(I wonder if the same is true of the NixOS paper?)

How do you manage secrets in configuration files? Passwords, ssh keys, tls certs and so on. If you put them into a nix-store they must be world-readable, right?

One could put a reference to files outside the store in configuration files, but then you loose a bit of the determinism of NixOS and it’s not always easily possible with third-party software to load e.g. passwords from an external file anyways.

Besides the learning curve, that was the single big problem which kept me from diving deeper into the nix ecosystem so far.

Nix is one of those tools where you don’t know what you aren’t getting until you get it. There are so many things wrong with this post

I have to disagree, but not with the second sentence - I was sure as I wrote the post that it was full of misconceptions and probably outright errors. I wrote it in part to capture those in the hopes that someone can use them to improve the docs.

But to disagree with the first sentence, I was keenly aware through the learning and writing that I was missing fundamental concepts and struggling to fill the gaps with pieces from other tools that didn’t quite fit. If there is indeed a whole ‘nother level of unknown unknowns, well, that’s pretty disheartening to me.

Offtopic: Excuse me.

I think it depends on some conditions, so not everybody is going to see this every time. But when I click on medium links I tend to get this huge dialog box come up over the entire page saying some thing about registering or something. It’s really annoying. I wish we could host articles somewhere that doesn’t do this.

My opinion is that links should be links to some content. Not links to some kind of annoyware that I have to click past to get to the real article.

What is the keyserver’s privacy policy?

i totally agree, it has been bothering me as well, i am in the middle of considering starting up my own self hosted blog. I also don’t like mediums method of charging for access to peoples stories without giving them anything.

Haskell has no syntax in the core language to sequence one expression after another.

It has quite a few alternatives actually. Depending what you mean by “syntax in the core language”, there are some things with specific grammar rules in the Haskell98 and Haskell2010 standards; there are some “userspace” functions/operators (i.e. their syntax is a special case of functions/operators) which are nevertheless mandated by those standards; there are some things which the de facto implementation GHC supports (e.g. via commandline flags); etc. Here are a few:

• a : b is the expression a followed by the sequence of expressions b (all of the same type)
• a ++ b is the sequence a followed by the sequence b (again, of the same type)
• [a, b] is a sequence of the expression a followed by the expression b (of the same type)
• (a, b) is a sequence of the expression a followed by the expression b (can be different types)
• f . g is the expression g followed by the expression f (input and output types must coincide)
• g >>> f is the expression g followed by the expression f (same as above but their order flipped)
• a -< b is the expression b followed by the expression a (must have compatible input/output types)
• do { a; b } is the expression a followed by the expression b
• f <$> x is the expression followed by the expression f (must have compatible input/output types)

These all define a specific order on their sub-expressions. They’re not all identical, but they follow roughly similar usage:

• a : b tells a Prolog-style interpreter to perform the computation/branch a before trying those in b
• a ++ b generalises the above to multiple computations (the above is equivalent to [a] ++ b)
• [a, b] is a specialisation of the above, equivalent to [a] ++ [b]
• (a, b) generalises [a, b] to allow different types. We can use this to implement a linear sequence (it’s essentially how GHC implements IO). Somewhat surprisingly, and completely separately to anything IO related, it also represents parallel composition
• f . g is a rather general form of composition
• g >>> f is the same as above
• a -< b is is part of arrow notation and desugars to a mixture of sequential and parallel composition (using lambdas, >>>, (a, b), etc.)
• do { a; b } is a generalisation of b . a, corresponding to join (const b <$> a), which is the most similar form to the ; operator of other languages you refer to: both because it has the same syntax (an infix ; operator) and a similar meaning (generalised composition). This can also be written as a >> b, and is related to a >>= b and a >=> b which are also built-in sequencing syntax, but didn’t seem worth their own entries.
• f <$> x is generalised application of f to x. That generality also makes it a composition/pipeline operator

The reason I’ve listed all these isn’t so much to say “look, there are some!”; but more to point out how many different meanings the word “sequence” can have (a list of values, an composition of functions, a temporal ordering on side-effects, etc.); how many different implementations of sequencing we can build; and, most crucially, that they all seem to overlap and interminge (e.g. the blurring of “container of values” with “context for computation”; how we can generalise a single thing like “composition” in multiple ways; how generalising seemingly-separate ideas ends up at the same result; etc.). This tells us that there’s something important lurking here. I don’t think investigating and harnessing this makes someone a wanker.

Monads only matter for representing sequential execution in extremely constrained languages, like haskell. (Some people believe monads are useful for other things, but I’m not interested in that debate, I’m just talking about where monads are certainly important.)

This is not true. Monads are critical for code reuse. I’ve used the concept of a monad in many areas, but explicitly and critically in Scala.

Haskell has no syntax in the core language to sequence one expression after another.

Yes it does: do-notation. You can even use semicolons if you don’t like newlines. It’s the syntax to sequence expressions which can be sequenced. You can’t use semicolons to sequence things that can’t be sequenced in other languages, either.

And why talk about Maybe but not MonadPlus, free monads, transformers…? All you know is Maybe and IO? Of course it’s boring to you. In stead of writing blog sized posts about how blog tutorials don’t teach you everything you could read up, but oh well you do you.

By changing each stage to take and return a fat outer type holding the entire context, you can just as easily achieve the cool pipeline effect by defining >>= as function composition rather than bind.

With bind you don’t have to change each stage.

Understanding how to write programs which allow change without triggering catastrophic rewrites is pretty useful.

Understanding why some programs are easy to modify is pretty useful.

Having language to discuss why some programs are easy to modify and others are not; also pretty useful.

The original post is about how thinking in terms of Monads can make a program which is hard to modify into a program which is easy to modify, it’s a useful post.

Some people believe monads are useful for other things, but I’m not interested in that debate, I’m just talking about where monads are certainly important.

First of all, by far the most popular monadic interface in modern software development is not Haskell’s IO type, it’s JavaScript’s Promise type, together with similar systems for writing asynchronous logic in other languages. If we’re talking about use cases where monads are “certainly important,” I think it’s worth mentioning the large number of programmers writing monadic code on a daily basis in languages which certainly do not lack native support for semicolons.

I love monads and find they’re actually among the most useful and important tools I’ve ever acquired as a programmer, but I agree that the PLT and functional programming communities could do a better job communicating exactly why monads are actually important. The use of monads as “extendable semicolons” does have some narrow but critically important use cases, such as asynchronous code, exception handling, and recursive backtracking, but I actually believe that the exotic forms of control flow you can express with monads is of only secondary importance.

In my experience, the most important consequence of modeling side effects with monads is that it allows you to reliably distinguish between pure and impure functions. The features which you claim make Haskell “extremely constrained” in fact give it an entirely new dimension of expressive power, because whereas most languages only have one form of function, which is implicitly allowed to perform side effects, Haskell has two forms of functions: functions which may perform side effects, and functions which may not. Given that a function’s interaction with an environment is an extremely important aspect of its semantics, this is information that you would be informally documenting and keeping track of anyway; Haskell just allows you document it in a precise, machine-checked format with great integration with the compiler.

This immediately allows you to separate functions which perform IO from those which do not, but that’s not actually the coolest part. The coolest part is that once you start defining your own monad types, you can express much much more precise and interesting classes of side effects, like “a function that interacts only with a random number generator” or “a function that interacts only with my database state” or “a function which interacts only with a sequential-identifier generator.” This is the real power of monads: the ability to make fine-grained guarantees about the data dependencies and side effects of a function given only its type signature.

I’ve been using NixOS everywhere around me for about 3.5 years and totally agree. I now work on Atlassian Marketplace which deployed using Docker images that are built from Nix.

Yes, Nix solves the “rollback” problem, and it does it for your entire OS not just packages installed (config files and all).

With Nix you can also have different versions of tools installed at the same time without the standard python3.6 python2.7 binary name thing most place do: just drop into an new nix-shell and install the one you want and in that shell that’s what you have. There is so much more. I use FreeBSD now because I just like it more in total, but I really miss Nix.

EDIT: Note, FreeBSD solves the rollback problem as well, just differently. In FreeBSD if you’re using ZFS, just create a boot environment before the upgrade and if the upgrade fails, rollback to the pre-upgrade boot environment.

now pacman Syu is almost guaranteed to break or change something for the worse

I have the opposite experience. Arch user since 2006, and updates were a bit more tricky back then, they broke stuff from time to time. Now nothing ever breaks (I run Arch on three different desktop machines and two servers, plus a bunch of VMs).

I like the idea of NixOS and I have used Nix for specific software, but I have never made the jump because, well, Arch works. Also with Linux, package management has never been the worst problem, hardware support is, and the Arch guys have become pretty good at it.

I have quite a contrary experience, I have pacman run automated in the background every 60 minutes and all breakage I suffer is from human-induced configuration errors (such as misconfigured boot loader or fstab)

How often were you updating? Arch tends to work best when it’s updated often. I update daily and can’t remember the last time I had something break. If you’re using Windows, and coming back to Arch very occasionally and trying to do a huge update you may run into conflicts, but that’s just because Arch is meant to be kept rolling along.

I find Arch to be a fantastic developer system. It lets me have access to all the tools I need, and allows me to keep up the latest technology. It also has the bonus of helping me understand what my system is doing, since I have configured everything.

As for rollbacks, I use ZFS boot environments. I create one prior to every significant change such as a kernel upgrade, and that way if something did happen go wrong, and it wasn’t convenient to fix the problem right away, I know that I can always move back into the last environment and everything will be working.

Can you show an example where a monad is useful in a Rust program?

(I’m not a functional programmer, and have never knowingly used a monad)

And even if you don’t make mistakes, most people will misunderstand their own process and come up with unhelpful things like monad tutorials: https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/

But now Joe goes and writes a monad tutorial called “Monads are Burritos,” under the well-intentioned but mistaken assumption that if other people read his magical insight, learning about monads will be a snap for them.

Came here to say something similar to this.

Learn new technology through writing a tutorial about it, but don’t publish it.

There’s so much misinformation by well-intentioned learners.

I’m not trying to diminish the importance of journaling either! Journaling != Tutorials.

I can’t help but imagine how different Android would be if various concepts from guix (or nix I guess) had predated Android 1.0.

They did! The original Nix paper came out in 2006:

https://nixos.org/~eelco/pubs/phd-thesis.pdf

I’m always impressed that these ideas were explored 12 years ago. There’s been lots of thinking, and it’s paid off :)

Software Foundations is also good, and online for free.

+1 for this. I’m using TaPL in my PL class this quarter and it’s awesome. Super well written and ML is great for this class - the work involves writing successively more complex interpreters for successively more complex toy languages. We’re not sticking strictly to the book, but the sections our prof has pointed us to have been great.

I also highly recommend TAPL.

I’ve been recommended TAPL before, but seeing as this isnt a class thats strictly about type systems, I’d like to get a more general one and read TAPL later.

TAPL isn’t just about types neither - it’s types AND programming languages.

Practical Foundations for Programming Languages is also very good.

There are lots of examples in this book, which I have found very helpful.

@hwayne you can call people bulldogs but I’m still super confused why you used leftpad as a “challenge” for functional programmers after seeing my functional version. Obviously it can be done. What’s the challenge?

As I said in both the Twitter thread and the full blog post, the problem with your submission is that you assume all your stdlib functions conform to your spec. That means the prover is taking it as true without verifying it. It’s the equivalent of mocking everything out in a unit test.

I told you that this, and your response was basically “it would be easy to fix but I’m not going to do it.” The people who actually tried to fix it found it much harder than you thought.

In the worst case we can just take your code and embed it as pure functions. This fact exists irrelevant to me completing your challenge or not.

As everybody who completed Fulcrum admitted, “embedding it as pure functions” was incredibly difficult and took several days to prove. It took one of the core developers of Liquid haskell almost four days to complete functionally. I hammered out my imperative proof in an afternoon.

Oh sorry before people ask for source, this is what I’ve pushed so far:

https://github.com/puffnfresh/megadrive-palette

https://github.com/puffnfresh/kosinski

Similarly, pipelines in shell scripts let you avoid naming intermediates.

(Pipelines are a combination of pointfree style and array language style, in that well-designed pipelines are side-effect-free and the programs in the pipeline mostly implicitly iterate over their input.)

There’s also a tool called Pointfree which auto converts code into “pointfree style” - e.g.

\a b c -> b * c

const (*)

And there’s also Pointful, for the other way around.

I think Haskell strikes a very fine balance here. Both point-free and pointful styles are very ergonomic, so you tend to name precisely those things that would be better off named.