nightlyherb

Would readers well-versed in physics be happier if the equation in the title were `g ≈ π² m/s²` instead of `π² ≈ g`?

Is there a way to read this style of C, without prior knowledge of APL, J, or K? Can people with prior knowledge read this more easily? I'm asking this because this is the first time I took the time to read that `j.c` and it wasn't really any more readable than normal C code. I was expecting to "read the C source in chunks" but that didn't really happen.

I'd like to add another point worth mentioning. When I read the other poster's post, I was thinking about the semantics of OOP, specifically encapsulated objects and messages. I may have misinterpreted the other poster, but I hope it at least makes my other messages a bit clearer. (I think it's a little unwieldy to use Matrices that encapsulate its state for Linear Algebra, for example.)

Okay, I see what you mean.

> Maybe you and the other poster have in mind specific fields of math,

Yes, because this is about Julia, I assumed we are talking about the specific fields of math that happen to be commonly used in mathematical and scientific computing, such as the ones learned in university math and science courses.

> Your implicit assumption that you can divide computer science into a different bucket from “real math” is incorrect, and gatekeeping.

It is regretful that we had a miscommunication. I agree with you that computer science belongs into the same bucket as "real math". The thing is, in the context of Julia it is not easy to read "math" as "math, but not only the domains that Julia is concerned in, but really all fields of math, including theoretical computer science". At least thanks to your comment, I see what you mean more clearly, and I think it'll help some other potential readers as well.

> but then you need to make claims for why those fields are sufficiently different as to be exempt from applicability of any of the advances in notation observed in other fields.

I'm curious to know specifically about the specific advances of notation observed in other fields. By this you mean dot notation for method application? I'm unsure if `a.method(b).anotherMethod(c)` is more advanced than `a |> method(b) |> anotherMethod(c)` (Edit: or `(anotherMethod(c) . method(b))(a)`) notation-wise.

I'm not the GP, but I'm sorry you felt gatekeeped. I don't think GP conveyed "real mathematicians should do FP", but rather something else, so I'll try my best to share what I understood from that comment. Hope this makes you feel better.

Even though the notation changed over the years, the paradigm of "numbers as immutable entities and pure functions" has been the dominant way that math is presented, compared to something like "encapsulated objects that interact with each other via sending messages".

I don't think this has to be this way, and I do think that "real math" can also be laid out assuming principles of OOP. However, I do suspect it's the way it is because the laws of nature are unchanging, in contrast to the logic of a business application.

Because Julia is a tool with the target audience of mathematicians and scientists, I think it's a sensible decision to embrace the usual way of thinking, as opposed to presenting a relatively different way of thinking which steepens the learning curve. Not because data and functions are fundamentally better than OOP, but because it's more pragmatic for the target audience.

As a person who respects many programming paradigms including OOP and FP, I beg to disagree. Specifically, I'm assuming you're talking about OOP the paradigm, not only the dot notation, for which the pipe operator is a viable alternative.

> The modern OOP-derived style of `array.mean().round(digits=2)` is just as exact in its specification, and arguably more semantically precise as well as it organizes the meaningful bits to be together.

I would have agreed with you if I were developing business applications. However, for the domain of math and science, every piece of material that I have seen assumes the paradigm of numbers as immutable entities and functions, not the paradigm of mutable encapsulated objects and interacting messages. To a mathematician or scientist the semantics of a `Vector` (as data) and a `mean` function that takes the `Vector` as input should be more natural than a black-box `Vector` object that can receive a `mean` method.

Hi, as someone who has been interested in functional programming for a while but who struggled to read point-free Haskell code until recently, I think it might be useful to share my perspective.

      gears = filter ((==2) . length)
            . map (neighbouringNumbers numbers)
            $ filter ((=='*') . fst) symbols

If this Haskell code does not look clear, it's because people are unfamiliar with point-free style, not because the this code is badly written, and especially not because the reader is stupid.

The given Haskell code reads naturally to me now. (I'm only a little uncertain because I can't write Haskell.) It would have been line noise to me before before point-free style clicked.

I tend to read Haskell code in articles from right to left, and it reads: "Choose the symbols whose first letter is '*', get their respective (neighboringNumbers numbers), and choose the results whose length is 2". I read (neighboringNumbers numbers) as if it were a noun.

I don't know how this clicked, but I'm pretty sure it has nothing to do with stupidity. Perhaps it was by chance, or perhaps it was by banging my head against the wall enough times.

Would I introduce point-free style in a JS codebase? Probably not. People are unfamiliar with this kind of style. Would I introduce this style in a Haskell codebase? Almost certainly, because it's clear and I think it reflects how Haskell programmers think.

Disclaimer: I'm a Korean native speaker.

It is interesting to see a perspective of someone who seems to have studied multiple languages.

I think it would be useful to clarify what is meant by "writing system". The term may refer to the alphabet or the orthography of a language. (or other things that's out of the scope here)

In the context of "Hangul hype", what is being discussed is usually about the alphabet, or, at least that is how I understand it. I do think Hangul as an alphabet is pretty intuitive and is modularized into components that compose well.

On the other hand, Korean orthography doesn't really seem to be the easiest to learn and the complexity has bled into writing and pronouncing Hangul, as in written Korean. I don't have experience with languages other than English to compare with, but if someone says Korean orthography is in the middle of the camp I'd buy that.

> Korean as a language cares more about aspiration than voicing resulting in, for a western ear, very minor differences that are explicitly expressed in the writing system and very big differences that are implied

That's a really interesting point. I think it has something to do with pronunciation more than a writing system. For example I can't disambiguate the pronunciation of "밥" from that of the last syllable in "보리밥". I've been told they're different.

Most of my use cases for string interpolation doesn't involve the concept of templates, so for me embedding the "data" inside the "template" is easier to read most of the time. Perhaps it's because the data and the "slots inside the template" are colocated? I had prefered keywords when `str.format` expression gets long anyway, so I guess I might not be the best person to judge.

I was curious why the author decided to call them "51 percenters." A google search of the term suggests that the skills of this group of employees are divided by 51% hospitality and 49% technical excellence. Please feel free to correct me if there is anything wrong in my interpretation.

Python seems to be popular for solving leetcode style interview questions, which might be something worth of note.

Current is about the throughput of electrical charge at a specific point of an electrical circuit, while what you're describing seems to be about the latency or the speed of electricity.

Security-wise, how is a server returning HTMX any different from a server returning HTML with forms? The clients both have the same capabilities, no?