lgessler

> Much like the biomass from long ago which has become the oil of today, I'm pretty sure the plastic waste of today will simply become the oil of the future.

OK, but on that timescale virtually nothing about climate change or environmental issues matters. On the scale of millions of years, life on Earth will continue in some way or another. But what's important is how much suffering will be endured in the potentially cataclysmic coming 100 years, and plastics hold great potential for harm on that timescale.

What's the point of "safety" if it's not needed anymore, as it seems not to be under nogil? If that's right, then modulo regressions/bugs possibly introduced by nogil, the choice is really just between worse or better performance, and it's not important whether there are (more effortful, by the way) ways of getting much much better performance.

Moreover, to the point about writing performance-critical sections in $NOT_PYTHON, as Sam Gross explains in the nogil design doc, things aren't always so straightforward for scientific computing:

> Calling into Python from C requires acquiring the GIL -- even short snippets of Python code can inhibit scaling. Addressing this issue sometimes requires rewriting large portions of Python code in C/C++ to actually achieve the desired parallelism. For example, PyTorch rewrote all of the core automatic differentiation from Python to C++ to avoid acquiring the GIL in the backward pass.

I think GP's point is that immutable objects (which Clojure uses "by default") can be easily used in concurrent settings. Immutable objects can be shared without concern between threads, whereas mutable objects may need to be copied or have their operations synchronized somehow.

I'm bear on web3 but you can't seriously say that with a straight face. The average person doesn't, won't, and in a way can't use a password manager, and measures like 2FA which mitigate weak password security still yield imperfect results.

Again, I don't think German is exceptional in this regard: we have English "catbird" (so called for its call), "bush baby" (for a small primate which is not a baby), "lady finger" (a regional name for okra), "buttercup" (a kind of flower), "kangaroo paw" (a kind of flower), etc.

I'd be pretty shocked if a German speaker thought a tortoise had a Schild or really was a Kroete, in the same way I'd be shocked if an English speaker said that a bush baby was an actual baby. Non-compositional noun compounds occur in both languages.

It's ironic because English is just as compound friendly. Take a German compound like Sprachwissenschaft ("language-science", i.e. linguistics). Now consider an English compound like "Earth science". The only difference is that it is convention in English to put a space between the words in a compound, whereas in German they are written without spaces. Things only seem different because of the impressive length some single "words" can reach in German, but English is just as capable of crazy compounds. Take this example that was discussed in a linguistics paper: "gay clergy book row priest", i.e. the priest who was involved in a controversy about a book about gay clergy. Quite convoluted, but we're not as awed by it, just because it happens to be spelled with spaces in between each part.

That's certainly the intuition most people would have about this, but it's still interesting to see it borne out when in principle there could have been other, surprising signals that cats respond to in order to right themselves.

How do CRDTs work with denormalized data, or more generally, data where some fields have invariants that must be maintained between them? Let's say we have an object with an array of strings and a count of that array:

    {
        "words": ["a", "b", "c"],
        "count": 3
    }

Now suppose users A and B edit the document so that one word is deleted, and two words are added, respectively:

    {
        "words": ["a", "b"],
        "count": 2
    }


    {
        "words": ["a", "b", "c", "d", "e"],
        "count": 5
    }

What probably should happen now is that we reach the state where `words` is `["a", "b", "d", "e"]` and `count` is `4`, but is that really what would happen? That would require the CRDT to understand changes to `count` as increment/decrement operations, but aren't there also situations where you'd simply want one of the two values to win?

https//lgessler.com

Nothing fancy, just an academic website with a short bio and some pubs. Source is in org-mode, which I compile to HTML and host via github pages.

That's a reason not to use Oracle--GP's asking for a reason to use Oracle.

This is referred to as the varṇamālā: https://en.wikipedia.org/wiki/Devanagari#Letters

Here's a good explanation from Richard Salomon (2003), "Writing Systems of the Indo-Aryan Languages". Note the startling suggestion that this arrangement might have been systematized even before the advent of writing!

> In this system, usually referred to as varṇamālā ‘garland of letters’, the characters are divided into vowels (svara) and consonants (vyañjana), and each major set is further divided into subgroups, again on phonetic principles. Thus the vowels are subdivided into simple vowels and diphthongs, each set up as short/long pairs (a-ā-i-ī-u-ū, etc.), while the consonants are classified into the groups vargīya (comprising stops, sparśa, including nasals, anunāsika), antaḥstha (semivowels), and ūṣman (spirants, including ha). Within each consonant subclass, the individual letters are arranged by place and manner of articulation. Thus the largest set, the twenty-five vargīyas, is divided into five sets (varga) of consonants with the same place of articulation, arranged from the back to the front of the mouth: kaṇṭhya ‘velar’, tālavya ‘palatal’, mūrdhanya ‘retroflex’ or ‘cerebral’, dantya ‘dental’ and oṣṭhya ‘labial’. Each varga contains five types of consonants: unvoiced unaspirated, unvoiced aspirated, voiced unaspirated, voiced aspirated and nasal. This system may have originally been developed in a tradition of linguistic analysis before the use of writing, and only subsequently been applied to the written form of language in Brāhmī script. The earliest written specimens of the are found in terracotta plaques of about the second century BC showing a schoolboy’s writing lessons (Salomon 1990:271).

Cool project! Something to consider: "Transformer"[1] is already used to refer to a popular element of state of the art deep neural networks, especially ones that are used on natural language, i.e. text. That might make this name a little confusing for people who have a foot in that world, especially since "Universal" and "Text" are also words thrown around in similar contexts.

[1]: https://en.wikipedia.org/wiki/Transformer_(machine_learning_...

PyTorch has become the de facto standard for research (meaning cutting edge models often have their sole implementation in PyTorch), and TF has had a much more unstable and uh, baroque API. It should be mentioned that while some of that API mess probably could have been avoided, other parts of it are a consequence of TF's view of computational graphs as static rather than dynamic, which gives it a fundamental performance advantage over PyTorch. (You can think of this as vaguely equivalent to why compiled languages can run faster than interpreted languages.)

It makes more sense when you consider that this seems to be intended as an alternative to (Jupyter, etc.) notebooks, which are a major way of communicating methods in the data science segment of the Python community. Notebooks are linear sequences of cells with an arbitrary number of lines of code inside of them, and these cells can be executed one at a time in arbitrary order. A lot of the time the dependencies between these cells (whether it be conceptually, programmatically, etc.) is not linear. There therefore arises a lot of cognitive load in both trying to present (via comments, etc.) this structure as a writer and parse this structure as a reader.

I imagine that is the kind of problem this is meant to solve--drawing out and visually solidifying that structure. From this perspective, I'm not sure if there's much apparent value in making the 1 cell <==> 1 function call constraint the default.

Are you talking about the languages themselves, or the languages plus their ecosystems (of libraries, design idioms, etc.)? Because if you're just talking about the PL itself, I'd really disagree

I'm not a DB expert, but aren't most queries bottlenecked by disk bandwidth? If so, addtl queries might hurt more than help.

2x4TB WD reds[1] in RAID1 on an old (ca. 2008) desktop I turned into a low-spec Linux box. These days I just keep it powered off most of the time, so I don't even really pay for electricity. Unfortunately even though I'm using reds, which are designed for NAS use cases, I've had two drives fail since I set up this rig in 2015, which I suppose puts me at ~$30/year, though I use the 4TB for lots else as well. It's durable enough for me since it's easy enough to notice when a drive fails and very unlikely that the other will fail before you can replace it.

[1]: https://www.microcenter.com/product/634744/wd-4tb-red-plus-5...

Old Blizzard is dead and has been for almost a decade--the name's the same but their job now is not to make great games that push the envelope in game design but rather to manage cash-printing franchises. It's hard not to think this when so many of the people behind the original groundbreaking games (StarCraft, WC3, D2) have left the company and in some cases disavowed it.

Be happy that old Blizzard happened, I say, and look on with eagerness to new indie studios, many of which are being run by the same Blizzard vets.

"simple" -- I wish we'd retire this word. We're all in the desert, and there is not yet an oasis.

Programming in Haskell.

Jokes aside, do you really not understand what GP means? "Real-world constraints" are the things like having to make money or having to do something with only 2 other programmers to help you. Nobody's claiming that, for example, academics (who don't need to have products that money) don't have other problems (like grant writing or juggling academic responsibilities), but that isn't what people mean by "real-world constraints".

NLTK might not be the best example of this--it was originally written for pedagogical purposes[1]. One that was sorely needed, too, as in 2006 it was very difficult for a student in an intro to NLP class to easily track down and use existing implementations of various algorithms. NLTK continues to be useful for similar reasons today, as it provides the only relatively usable interface to some valuable but poorly engineered (by modern standards) academic resources such as FrameNet.

Anyway, original commenter seems to presuppose that there's no value in collating and polishing existing resources. Isn't that all, say, a Linux distro is? Is it true that "[Canonical] just wrap all the open source [code] into a [distro] and just want to sell the hype"? If it seems like curating and polishing has value on the market, maybe we ought to at least entertain the possibility that this value is not an illusion of marketing. That's why I agree with dang that OC is a facile dismissal.

Also worth noting that spaCy isn't just wrappers. spaCy's tokenizer, which is an original work, is used in at least two cutting-edge academic NLP libraries, AllenNLP (@AI2)[2] and Stanza (@Stanford)[3], presumably because using spaCy's tokenizer was better than the alternatives.

[1]: https://aclanthology.org/P06-4018.pdf

[2]: https://github.com/allenai/allennlp/blob/e0ee7f43d5da973e77d...

[3]: https://github.com/stanfordnlp/stanza/blob/68aa42653d656f613...

Why do you feel as though you ought to read it? Best to think of PM like any other academic text, I reckon: primarily in conversation with contemporary issues/works, brimming with presuppositions of shared knowledge because of this, and unlikely to be of any great interest to a non-specialist. PM of course is no ordinary academic text, but I don't think it's an exception here.

The core language itself and stdlibs, sure, it'd take just several dozen hours to pick it up. That goes for any high-level, C-family programming language around today, really. Can you do that and be nearly as productive in PHP (or any other language) as you are in your current daily use language? No: you need to invest in learning common design patterns, the library ecosystem, and tooling in order to be productive at a high professional level, and that is a task that takes longer and arguably never even really ends. Putting down real roots in a programming language is a large investment.

Dev communities are actually primarily for writing ad hoc documentation. From that perspective, the answer to which platform one ought to use for them is very clear.

by "everything" I think GP is referring to the JS ecosystem

Interesting that the HMM chapter has been moved to the appendix in the 3ed. A consequence of how deep neural nets (CRFs in particular) have supplanted them for most use cases.

As a counterpoint from a linguist, everyone who's intrigued by this or the (nearly a century old!) "Eskimos have 100 words for snow" trope should read Geoff Pullum's "The great Eskimo vocabulary hoax"[0]:

"The tale [...] is an embarrassing saga of scholarly sloppiness and popular eagerness to embrace exotic facts about other people's languages without seeing the evidence. The fact is that the myth of the multiple words for snow is based on almost nothing at all. It is a kind of accidentally developed hoax perpetrated by the anthropological linguistics community on itself."

"Among the many depressing things about this credulous transmission and elaboration of a false claim is that even if there were a large number of roots for different snow types in some Arctic language, this would not, objectively, be intellectually interesting; it would be a most mundane and unremarkable fact."

"Would anyone think of writing about printers the same kind of slop we find written about Eskimos in bad linguistics textbooks? Take a random textbook like Paul Gaeng's Introduction to the Principles of Language (1971), with its earnest assertion: "It is quite obvious that in the culture of the Eskimos... snow is of great enough importance to split up the conceptual sphere that corresponds to one word and one thought in English into several distinct classes..." (p. 137). Imagine reading: "It is quite obvious that in the culture of printers... fonts are of great enough importance to split up the conceptual sphere that corresponds to one word and one thought among non-printers into several distinct classes..." Utterly boring, if even true. Only the link to those legendary, promiscuous, blubber-gnawing hunters of the icepacks could permit something this trite to be presented to us for contemplation."

"The final words of Laura Martin's paper are about her hope that we can come to see the Eskimo snow story as a cautionary tale reminding us of "the intellectual protection to be found in the careful use of sources, the clear presentation of evidence, and above all, the constant evaluation of our assumptions.""

[0] http://www.lel.ed.ac.uk/~gpullum/EskimoHoax.pdf

Edit: like topaz0 points out, the point of the scholarly work this article describes is to preserve indigenous knowledge and language, which is great, though I think it's still important to raise Pullum's points as a tonic for the exoticism that inevitably arises here, arguably even within the news article.

Zipf's law has been found to be very robust empirically, so you can also assume the same holds (top 100 account for 50% of volume) for Inuit languages.

https://en.wikipedia.org/wiki/Zipf%27s_law

Link to the interop lib for Clojure you're referring to for people who don't know it: https://github.com/clj-python/libpython-clj

Really a remarkable feat of engineering. Here's its author giving a talk: https://www.youtube.com/watch?v=vQPW16_jixs

Regardless of whether they do, the tech that underlies modern image classification approaches (i.e. deep neural networks) is pathologically hard to understand to the point where it's practically impossible to provide the guarantees you're describing. For example, adding noise to a picture of a panda can make a network think it's a gibbon: https://towardsdatascience.com/breaking-neural-networks-with...

That's not to say, of course, that there's nothing to be done. People who aren't white have historically been laughably underrepresented in computer vision datasets, and while that's been changing, I gather that representation still isn't where it needs to be.