That’s exactly my strategy as well (one light, one dense and one technical), I find it means I’m always in the mood to read something (otherwise I’ll resort to shallow articles and silly tutorials online).

I’ve also found the full Discourses more “diluted” than the Enchiridion and didn’t finish it. I definitely suggest you pick up the latter, if you haven’t already.

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.

Yeah, “don’t fight the platform” would be my advice. You have to relax and let the Windowsness of it all wash over you. Admittedly, I also find this impossibly difficult, but trying to turn Windows into a poor clone of a poor clone of a poor clone of AT&T Unix is probably a losing strategy in the intermediate run.

I think you get PSReadLine by default recently, as well as ssh (if you enable it).

System.String.Split predates Span et al; so it likely is allocating new strings instead.

.NET never shares substrings like Java or Go (the object layout is “Pascal-style”, length followed by content, so you can’t do this without changing representations)

Well, Wikipedia is a serious business. It is the foremost social verifier of our time. (If you don’t want to click, I quoted the relevant passage below.)

So: a social verifier is an institution, authority, Web 2.0 server, etc, etc, which collects and distributes information that its users trust. Wikipedia is a social verifier. So is the Catholic Church. So is the New York Times. So is UC Berkeley… So is the scientific peer-review system. And so on.

Deletionism killed it for me, I don’t bother any more except to fix small mistakes.

I was never a contributor but the deletionism thing would make me think twice for sure. Not about if my content was notable but about if I wanted to help Wikipedia.

I agree to some extent, except that Electron apps (and some web apps) are all but unusable on low-end/older hardware. Many (but not all) are severely lacking in keyboard control and other things that one might expect, too. Every Electron app seems to be oblivious to multilingual users and underlines every word, despite me switching input methods.

Couldn’t disagree more, and the reason is accessibility. it’s super trivial for desktop app developers to add keyboard shortcuts and other accessibility aids to their apps. Web developers, despite the fact that these standards like ARIA exist, seem unwilling to adopt them in any sizable number.

We can have this conversation again when the Hello World app produced by your average Java framework is Aria accessible, has keyboard shortcuts for everything, and works properly with screen readers.

As bad as GUI toolkits are, web tech is a lot more awkward to make GUIs with than any major cross-platform toolkit, simply because it’s a hack to draw anything with the DOM. (You’re literally live-editing the AST of a rich text document. It’s amazing that it works at all.)

I think it’s a philosophical difference:

Some developers write code to document to coworkers what they are doing, and some developers just want things to compile with the least effort possible.

Languages are funny. I’d consider defer to be a bad idea elevated to a language feature, but it’s in the “good” group 😀

Can you explain why you like this idea?

Especially during a weekend where many (at least Europeans) were traveling.

Also keep in mind that a lot of people outside the US (i.e. Europe) are on 500MB/1GB plans, so you burn through that with LTE very quickly. And not everyone can afford to buy extra data. This is extremely rude.

… I was wondering how I ran out of data 4 days early this month.

I, well, believe it should count as part of the experience.

You don’t RSS your mobile feeds?

That has a really ominous parsing for me.

I assume the intention is something like:

When needed, my skill and knowledge shall be given for the public good, without reservation.

And paid Id add. The markets and taxpayers that cover lots of unnecessary stuff should be able to cover these people working for the public good.

This is currently being updated. Here’s the latest draft (3). Here’s the diff for Draft 1 from the 1992 version.

I can take the ACM version more seriously, since it presumably entails some means of enforcing this contract. Without that, this is just… well, a nice expression of good intentions. But, ACM membership isn’t much of a requirement for practicing as a “computing professional”, nowadays.

When being kicked out of the ACM for violating their Code means that your career is effectively over, then we’ll be on par with the other engineering disciplines – doctors and lawyers aside. I think we’ll get there eventually, but it may take quite some time. The professionalization of civil engineering, for example, took many decades of collapsing bridges and the like.

If you’re serious about any of this, go study some history.

Well… it depends on what you mean by stable. All the numbers in the result will be, by definition, in order… but you may get new numbers that weren’t in the original array. The rate of those new numbers is 1/100000.

From what I can tell, this is kinda how the algorithm works:

    lookup = bloomfilter(numbers)
    for i in range(min(numbers), max(numbers)):
        if i in lookup:
            yield i

It’s important to note that because we’re using bloom filters, this scheme does not handle arrays with duplicate entries. That’s why they mention “unique elements” in the first statement.

It’s the i in lookup that has the 0.00001% error rate. The O(m) comes from the fact that we do range(min(numbers), max(numbers))…. the author has a really strange way of stating that with that set notation.

One last thing to note is that the rate of O(log(n)) is theoretical assuming an infinite number of available cores.

As this is a probabilistic sorting algorithm, you will have a small chance that the given array is not sorted after executing the algorithm. Therefore this algorithm shouldn’t be used critical operations.

I’m going to guess it isn’t stable :P

It doesn’t. This has very little to do with dependent types, but are more like smart constructors.

Here’s a translation into boring old C# to show that nothing particularly F#-specific (or very fancy at all, given C#‘s type system) is going on at the type level. (I’ve switched out Option for simple nullability.)

Aren’t the latencies due to electronics and not mechanical? That would explain why the ErgoDox places so average - because the firmware can do so many different things.

[Comment removed by author]

“Seeing X made me realize Y” is something we hear sometimes. “Made me” is not necessarily about a person forcing a person to do something.

But maybe the headline would have been less ambiguous (and less sensationalist) had it said “A note from rms made me …” or even more removed, “Reading a note from …”, or just “rms’s views made me …”.

It’s “made me change” in the sense of “convinced me to change”, not “forced me to”. (I’m suggesting the original title back…)

Also

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.

• Jamie Zawinski

hyuk hyuk hyuk hyuk

That said, this post inadvertently reminded me of how few people actually get what C# async and await do. If you look at the sample output in that example, the astute reader will realize that nothing happens in the asynchronous task until .Wait() is called. That’s because Main() is not itself an asynchronous method, and the author never set up a task runner, so this program actually runs entirely in a single thread.

This is largely inaccurate. ThinkAboutIt doesn’t run when Wait is called, it will immediately begin running on Main’s thread until it hits the first await (the one inside ReadTheManual), at which point control returns to Main, and the rest of the logical thread of control will be on a background thread (not on the initial thread).

You can verify this yourself by inserting a few prints of Thread.CurrentThread.ManagedThreadId.

The comment about sharing approaches that didn’t work made me want to share the docs for my favorite function in the Haskell world, a variant of unsafePerformIO: accursedUnutterablePerformIO

-- | This \"function\" has a superficial similarity to 'unsafePerformIO' but
-- it is in fact a malevolent agent of chaos. It unpicks the seams of reality
-- (and the 'IO' monad) so that the normal rules no longer apply. It lulls you
-- into thinking it is reasonable, but when you are not looking it stabs you
-- in the back and aliases all of your mutable buffers. The carcass of many a
-- seasoned Haskell programmer lie strewn at its feet.
--
-- Witness the trail of destruction:
--
-- * <https://github.com/haskell/bytestring/commit/71c4b438c675aa360c79d79acc9a491e7bbc26e7>
--
-- * <https://github.com/haskell/bytestring/commit/210c656390ae617d9ee3b8bcff5c88dd17cef8da>
--
-- * <https://ghc.haskell.org/trac/ghc/ticket/3486>
--
-- * <https://ghc.haskell.org/trac/ghc/ticket/3487>
--
-- * <https://ghc.haskell.org/trac/ghc/ticket/7270>
--
-- Do not talk about \"safe\"! You do not know what is safe!
--
-- Yield not to its blasphemous call! Flee traveller! Flee or you will be
-- corrupted and devoured!
--
{-# INLINE accursedUnutterablePerformIO #-}
accursedUnutterablePerformIO :: IO a -> a
accursedUnutterablePerformIO (IO m) = case m realWorld# of (# _, r #) -> r

Once you start writing quality code comments, you can use a tool like Sphinx or Javadoc to include them in your documentation.

I’ve seen this attempted, but I’ve never seen it work. I would be interested in hearing from people who have had this work on a non-trivial project at your job. So far I’m filing this in the “promising idea that didn’t quite work out” bin.

In at least the case of library/API documentation, I’ve never seen any other approach work. I’ve also seen this one fail frequently, but it’s at least better than the usual alternative, which is to auto-generate skeleton API docs without useful comments.

For example, the Java docs, which are auto-generated from comments, are pretty decent, far better than most API/library documentation. CPAN on average is also fairly good, since the Perl community seems to have a fairly strong culture of using POD. Among other things I’ve had the pleasure of using lately, they’ve all been auto-generated too, but by teams that evidently put less emphasis on writing good comments to auto-generate from: Google’s Firebase, Apple’s API docs, etc., all could use a little more time spent on the comments.

One distinction I sort of like is the Lisp one (adopted by a few other languages) where comments proper and docstrings are both conceptually and syntactically different. In good Lisp style, any function that’s externally callable is supposed to have a docstring at the top of the function, which explains in prose what the function does, and any gotchas/prerequisites/notes/etc. about its usage. This can be both used to auto-generate documentation, and queried at the REPL or whatever IDE you have hooked up. The actual implementation code interior to the function, though, is ideally supposed to be self-documenting, with relatively few comments only where really necessary.

I think a big part of the problem is that there’s no simple, widespread way to link code to documentation aside from comments. At least in the places I’ve worked, historical discussions, business case documentation, and bug reports are incredibly valuable for understanding and modifying code… if I know they exist and if I can find them. Similarly, most people don’t read the documentation I write. Comments are a terrible way to carry information but they’re also the only way that everybody knows and is supported everywhere.

It’s a field I keep coming back to and if there’s interesting stuff out there that escaped the “didn’t work out” bin I’d love to research it.

I feel this is closely related to fractional types, where 1/x is interpreted as a promise to receive some x. Then some type 1/x*y represents some computation that requires an x, produces an y. Clearly this post corresponds with that intuition.

See https://www.cs.indiana.edu/~sabry/papers/fractionals.pdf

MFC does a lot of what you’re asking, and has been supported by Microsoft since the 90s.