bradrn

How is it crazy? This behaviour always made sense to me.

I’ve done something like this before to call Haskell from C++ (in [0]), so that I could build my GUI using Qt. It worked pretty well, except that I ran into various difficult-to-resolve linking problems on both Windows and Linux. After a year or two of trying to maintain it, I gave up and switched to a protocol where both sides pass JSON over stdin/stdout. This particular piece of software doesn’t require a huge amount of communication or shared data, so it works well enough.

The really nice thing about the original interop code, though, is that GHC’s new WASM backend uses essentially the same foreign function interface to export functions to JavaScript. So with only some minor modifications, I was able to get the same program working on a webpage [1], which I think is pretty cool.

[0] https://github.com/bradrn/brassica, and see in particular the old version of https://github.com/bradrn/brassica/blob/93d4353c5736018ec094...

[1] At the risk of DDOS’ing my poor little home server: https://bradrn.com/brassica/

> I don’t disagree on any of your technical points. But I also think for practical purposes you’re missing the forest here. I agree with the sentiment of the article - I think the big trend in general purpose PLs is a blend of multiple classical paradigms.

You’re not wrong. That may even be the sentiment of the article. But the article certainly doesn’t phrase it that way — it’s saying that modern programming languages are ‘beyond paradigms’. That’s clearly wrong, and that’s what I’m arguing against.

I agree with all of this. But I’ll point out that ‘the paradigms can be prioritised’ wasn’t intended to be my main point there. I wanted rather to refute the argument that Rust etc. aren’t ‘post-paradigm’ at all: on the contrary, they fit in quite well with existing paradigms.

> Even two of the most similar languages there are, at least in terms of language spec, Python and Ruby, demonstrate significant differences in the orientation of the library ecosystem in some of their philosophies.

Hmm… I feel you can get a lot more similar than that. Python and Ruby are actually rather different to my mind. Rather, you could take OCaml vs SML, or Scheme vs Racket. The differences are still there, but it’s much more subtle.

To add to my parent comment, I think there’s another point to be made here: ‘post-paradigm’ is, to some extent, a contradiction in terms. You can’t build a language without its basic structure implying some paradigm (or possibly more than one).

There’s a perspective I find useful here. I tend to think of different ‘programming paradigms’ as different approaches to solving problems. In imperative languages, you solve problems by modifying values in sequence until you get to the answer; in functional languages, you solve problems by building up a function which gives you back the answer; and so on.

The key thing here is, you do need to give yourself some way of solving problems. That translates directly to the paradigm which your programming language adopts. If you give yourself more than one way of solving problems, then the language becomes multi-paradigm. In rare cases, you might even end up inventing a totally novel problem-solving approach, and hence a new paradigm… but even that’s not ‘post-paradigm’, it’s just another paradigm.

> Many programs in these languages look significantly different than just statements and procedures.

Like I said, they’ve certainly adopted features from other paradigms… but the basic, underlying structure of programs in these languages is still statements, sequenced one after another. It’s not like Haskell or Scheme where nearly every operation is ultimately done through function calls. And it’s certainly not ‘post-paradigm’ as the article claims.

> Moreover, all three languages support structural pattern matching (borrowed from functional programming) as a core control-structure.

As for this: people often associate functional programming with pattern-matching, but I’ve never really understood why. The only relationship is that it originated in the ML language family, which also happens to be functional. There’s many functional languages which lack pattern-matching (e.g. most Lisps), and there’s many non-functional languages which have it (Java, C#, Python).

> The unifying aspect of new languages such as Rust, Nim, and Gleam is that they were designed from the beginning to be beyond paradigms.

I really don’t think this is correct at all. Rather, Rust/Nim/Gleam are first and foremost imperative languages. They may have some functional and Lispy features thrown in, but that doesn’t change the fact that programs in those languages involve writing statements to be executed one after another — the defining aspect of imperative languages.

If you really wanted to, I guess you could define this particular combination of ‘imperative+functional+macros’ as its own new paradigm. These languages are consistent enough with their design that that might actually make sense. But it’s certainly not ‘post-paradigm‘ in any meaningful way.

Key sentence (quoted from a letter of Feynman’s):

> The worthwhile problems are the ones you can really solve or help solve, the ones you can really contribute something to. A problem is grand in science if it lies before us unsolved and we see some way for us to make some headway into it.

> As with everywhere else in the developing world, there are also a bunch of cheap Chinese imports […]

Note: the images below this text actually show Korean writing, not Chinese.

I think the intention was to place ‘700°C’ within the arrow, like so: -(…)->.

You’re welcome!

> I've used R for some data visualization in the past, but I'm not sure I was fully aware how R scopes work.

You might be interested in this description, then: https://adv-r.hadley.nz/environments.html

This sounds almost exactly like how environments work in R, then… is that correct?

> with some different details around contexts (rebol's bindology)

Could you perhaps summarise how contexts work in Rye? On the Ren-C forum we’ve recently been discussing binding a lot, and I’d be interested to learn how Rye does it.

This was already posted just yesterday: https://news.ycombinator.com/item?id=39714502

It’s also extremely similar to R and Rebol.

(In fact, R isn’t just ‘extremely similar’: it does use fexprs, though without mentioning the term.)

Interesting, thanks!

Something better has indeed been written… that being his expanded print edition of the same guide [https://www.zompist.com/lckbook.html], plus the various other books on the subject he’s written. I don’t know of anything better for learning how to conlang, and even just for learning about linguistics it’s very good.

Consulting Wiktionary, it lists several words for ‘aunt’ in Mandarin: depending on the precise relation, it can be gūmǔ, bómǔ, shúmǔ, yímǔ, jiùmǔ, plus some other dialectal synonyms. None of these sound anything like ‘ah-yi’.

Looks like a typo for ‘ClearType font display technology’.

Or Haskell!

Link to paper: https://www.pnas.org/doi/full/10.1073/pnas.1410162111

For context, this is a really great newsletter about the Haskell ecosystem which gets published every week. I have no idea why this issue in particular was posted here, though.

Looks like there’s two follow-up articles to this:

https://allvisibleobjects.substack.com/p/the-leg-dilemma-par...

https://allvisibleobjects.substack.com/p/extracts-ahabs-leg-...

No, they’re different. ‘Shaping’ is deciding how to combine adjacent characters, mostly by changing their forms as needed, and secondarily by adjusting their horizontal or vertical positions. ‘Layout’ then involves taking those shaped characters and placing them on the page to form words and sentences. There’s some overlap — e.g. you could use shaping to implement the mojikumi rules in section 3.1.2 here — but by and large they’re separate things.

You can do it with evil-mode (or vim) too: :%v/pattern/d runs ‘d’ on all lines which do not match the pattern. (The opposite is :%g/pattern/d.) I believe it works with any command, though I’ve only ever used it with ‘d’.

He claims it is homoiconic, though: https://xlr.sourceforge.io/#homoiconic-representation-of-pro...

> it's more like pattern matching and replacing patterns with expressions

Scheme macros use pattern-matching.

> loop Body is { Body; loop Body }

This, though, is definitely strange. I’m not quite sure how it works.

More Lisp than Prolog… I don’t see any constraint-solving here, just macros.

I use Haskell as my main language. I’m very familiar with its concepts. I’ve also used Python, so I’m familiar with that too. And this Python code strikes me as singularly unreadable, both compared to its ‘non-functional’ equivalent, and to the corresponding Haskell.