Athas

I don't know if passport data is supposed to be confidential (i.e. if it can be misused), but I have no compunctions about sharing my salary information. Last month I made the equivalent of $5615 (after deducting pension payments), from which I paid $1886 in taxes.

It's ultimately subjective what counts as "personal information", but my income is not me, nor is it particularly about me. I think it would be fine for it to be public by default, as in Norway.

From an academic point of view, most parser combinator libraries are basically LL parsers with backtracking. This is eminently practical (especially if the backtracking part is done well), but from an academic point of view that means they're not very interesting - really just a nicer way of implementing recursive descent parsers.

There is of course plenty of academic work specifically on how to implement parser combinator libraries efficiently, how to make them invertible (so they can also produce prettyprinters), provide good error messages, etc.

While I agree that there's much of the UHHB that is still valid (and what's not valid is still funny), I don't think that's a good example. Modern kill allows you to provide the signal name if you wish. I don't think it's a particularly good criticism of kill that it also allows you to use a numeric shorthand if you wish (even if that shorthand is very popular).

I think the UUHB is mostly worth reading to understand the absolutely dismal state of proprietary Unix in the 90s. It explains why technical reasons contributed to the growth of both Windows NT and GNU.

Would it be viable to mine the remnants of civilization? Would a garbage dump or the ruins of a 20th century skyscraper be a viable source of iron?

Not all systems have bash as /bin/bash. A shebang line of '#!/usr/bin/env bash' would be even more portable.

This is probably less readable than it has to be due to the lack of whitespace. I don't know the language (Scala?), but I don't think it's too hard to work it out. First, the '[F[_], A, B]' part are type parameters, where I assume the 'F[_]' part is just a bad notation for a type of kind '* -> *' (i.e. a higher-ranked type). The next value parameter has type 'Option[A]', and after that we have 'A => F[B]'. This confirms my suspicion that 'F' is a higher-ranked type - and probably a functor or something. The 'f' parameter is a function for converting a value of type 'A' into a value of type 'F[b]', which looks like it's tranforming a value and putting it into a functor or something. The final '(implicit F: Applicative[F])' hints at deep problems in the language, but I think it basically just says something like 'the higher-rank type F must implement the trait/typeclass/whatever Applicative'.

That's the type. The expression makes little sense to me, but I suspect you removed a bunch of dots and maybe some parens, and it should actually look like this:

          fa.map (a => F.map(f(a))(Some(_): Option[B])).getOrElse(F.point(None))

So this function essentially just operates on an option value inside of some functorial context. This seems like a building block function that you might use often, but probably not write very frequently.

(If you didn't remove anything, then I suppose this language has infix 'map' and 'getOrElse' operators. I think that's bad, but it's not related to the type system.)

I suppose it depends on how long that CS 101 course would be. At our department, we used to have an initial half-semester course that taught computational problem solving and programming using Standard ML. It was necessarily based on functional programming, although Standard ML is impure enough that we could also do simple IO. In the next course, they were taught object-oriented design and programming in Java. This has been replaced with a single course that uses F# (a multi-paradigm language) to teach a mixture of functional, imperative, and object-oriented techniques. It is not my impression that the students are left with a very clear conception of these ideas afterwards. Mostly they just seem to loathe F# - more than prior generations loathed Standard ML, even though F# is far more practical and has far better tools.

There can be many reasons for this, but I think people completely new to programming do not have the maturity to juggle multiple paradigms within such a short period of time, and within the same language. Perhaps switching to a materially different language when switching concepts actually helps them, so they don't mix up things too much.

> Counterpoint: it's become a fairly multi-paradigm language at this point, and a multi-paradigm language is exactly what should be the defacto language in curriculums

I'm surprised you would say this, as it is the exact opposite of my experience as university teacher. I think we should teach concepts, and concepts appear much more crisply in small and focused languages. I think students gain more from being exposed to specialised languages than to more muddled multi-paradigm languages. For example, functional programming is much clearer in a language such as SML or Haskell than in Scala or F# (although the latter isn't that bad), because you can actually teach the whole language without any part of it muddling the concepts. Similarly, I would rather teach object-oriented design and implementation with, say, Smalltalk than OCaml.

Now, industrial usage is a different matter - here I have no problem with multi-paradigm languages.

While this is true, it should be noted that:

* Implicit parameters are a language extension, not part of standard Haskell (although extensions are so ubiquitously used that this does not matter much).

* Implicit parameters are rarely used[0]. I would not be surprised if most experienced Haskell programmers have never used them, and while they may know they exist, they might not even remember the syntax or semantics. I belong to that category myself. In Haskell, type classes tend to be used for what other languages might do with implicit parameters.

[0]: https://gist.github.com/atondwal/ee869b951b5cf9b6653f7deda0b...

Damn, messed up again. I guess I should run more code and write less text.

You're right! I fat-fingered that example and nobody noticed (or pointed it out) before you. Fixed!

I read them by their LaTeX names, which are "ocross" and "odot". Sometimes I will just read them as "cross" or "dot", or even "add" and "times" when applicable.

What is impractical about recursion?

Sometimes the absence of features is itself a feature. SML is a much smaller language than OCaml and F#. Offhand, I can't recall anything it has that OCaml doesn't, although it does some things differently (e.g. structurally typed immutable records).

I'm not sure there is much reason to use SML itself today, given that it has stagnated since the late 90s, but it is an excellent language for teaching programming because you don't have to sweep anything under the rug. But if you want to use it, then it does actually have well-maintained pretty good compilers. MLton probably generates faster code than OCaml and F# in many cases. The main problem with SML is that there are not a lot of SML programmers around, and hence very few libraries, particularly for handling modern protocols and formats.

As I understand it, an important point of software citations is to help academic researchers who are (unfortunately) measured by citation metrics. Will whatever tools the bean counters are using connect "the <project> contributors" citations properly to people? I don't see how they could.

I'm all for citing software. I still don't understand the guidelines for who to list as an author, though. In modern open source projects, you're going to have a very long tail of drive-by contributors. Some of these might not even touch the software itself, but merely fix a typo in the README or similar. Should the citation list all of these? As for myself, I'm very much in favour of crediting anyone for any contribution, no matter how small, but standard scientific practice is more exclusive. And what about names? When I look at the author list that Zenodo generates for my own main project [0], it's not only very long, but contains lots of online pseudonyms and even a few duplicates, due to differences in spelling or inclusion of middle names and such. My background is in the hacker community, so I think this is great, but I don't think a journal editor would agree.

I could manually curate a list of the "main authors", which would be much smaller, but I'm not particularly enthusiastic about being the arbiter of when someone's contributions are major enough to become a "main author".

[0]: https://zenodo.org/record/5062209

Many of these algorithms are bandwidth- or cache-limited on modern machines, so you can get significant speedup by storing your data in fewer bytes, even if you expand it in registers before actually doing computation on it.

Do you have more details? I read https://gcc.gnu.org/onlinedocs/gcc/Half-Precision.html which made it look like a rather exotic feature that would not be available on all systems (and https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html#Float... also makes it sound like __fp16/_Float16 is only supported on AArch64).

What happens on overflow or 0/0 with this format?

Sure, why not. I don't think it would be that difficult, and can be emulated with single-precision just as well as fp16 for the systems that don't support it in hardware.

> ROCm from AMD has its restrictions, but... it really is easier to program than OpenCL. Its a superior model: having a single language that supports both CPU and GPU code is just easier than switching between C++ and OpenCL (where data-structures can't be shared as easily).

ROCm isn't a programming language or programming model - it's a collection of tools and libraries. Which language are you specifically referencing here? HIP?

If you took SML and removed reference cells and the parts of the standard library that involve IO, then you'd have a pure language (depending on whether you consider exceptions to be effects). It would not be useful for application programming, but would be fine for teaching functional programming.

Certainly, it reduces to reverse-mode AD on fairly arbitrary (although usual scalar) code. You definitely need a compiler or preprocessor to do that for you.

Could you naively compose the distance functions and then use automatic differentiation to compute the gradient? As long as the distance functions are differentiable, so should their composition be.

> So, when adding a regular fBM, sine wave or any other displacement function to a "host" SDF, we don't get a valid SDF anymore (we violate the principle that the gradient of an SDF must have length 1.0).

Can someone elaborate or point to an elaboration of this point? I guess there must be a good reason why the gradient cannot just be normalised, but I don't know what it is.

> If a major company invested in the SML ecosystem, it would take over the programming world.

I like SML both out of nostalgia and for its actual merits, but I don't think that's true. SML was far ahead of its time, but it's showing its age now. Its simplicity is also correlated with an absence of handy features (e.g. ad-hoc polymorphism). Many companies invest in OCaml, which is slightly more crufty but with a (much) more healthy ecosystem, yet it hasn't taken over the world.

I do wonder what would have happened if SML had "won". In many ways it was pragmatically engineered in the early 90s, at a time where no other functional language was comparable (except maybe Caml). Its much-vaunted formal specification does leave a few pragmatics-shaped holes, however. For example, SML has no standardised way of splitting programs into multiple files. Each compiler does their own thing (although at least MLton and MLKit both support MLB files).

Presumably, if someone took that kind of control over Ethereum, its value would rapidly become zero.

You don't go through the TTY model, but read directly from devices (if the kernel allows it). But people will hate you for it, since it doesn't fit with the abstraction layers that are commonly used, one of which is that only characters matter, not keypresses. Consider how such a TUI that directly interacts with keyboard devices (because it wants to detect keyup events) would work over SSH. It cannot. Abstraction layers limit certain functionality, but they also allow workflows to exist that otherwise could not (or would be much more complicated). You have to judge in every instance whether the correct balance has been made, but I don't think this aspect of the Unix terminal design is awful.

`.cpp` is very common. I never understood the point of `.C`; even ignoring issues with case sensitivity, it is too easy to visually confuse with `.c`, and doesn't even have much of a mnemonic connection to the name C++.

No, because this makes it seem like they are not making the right decisions because they are right, but only because doing the wrong thing made them unpopular. It makes you wonder what other wrong things they do that doesn't elicit enough of a popular response to make them reconsider.

It's not like the environmental impact of Bitcoin was a subtle or obscure issue when they first made the decision. They should have known better, and it remains worrying that they did not.