lgessler

Idk, that isn't the sense I got from "It is absolutely trivial to show Hyp2 is false", but sure, I agree with you that this evidence certainly ought to tip the scales one way and not the other.

This is a false dichotomy. It's not the case that models are truly capable of reasoning if and only if they are insensitive to irrelevant perturbations to input. In other words, the mere fact that sensitivity to names sometimes causes significant degradations in model performance doesn't mean that we've observed models are incapable of anything we might call "reasoning"—leaving aside the matter of how we'd define that.

Used to write MUMPS at a certain company, and there were lots of "wtf" moments but this is one I'm particularly fond of. In the system, all dates are represented as an integer starting from an arbitrarily defined earliest date represented as 0, December 31, 1840 (http://www.mumps.cz/gtm/books/pg/UNIX_manual/webhelp/content...). OK, fine, whatever. But another fact about MUMPS is that associative arrays (= Python dictionaries, or Java maps) are automatically sorted. Weird language feature, and probably a questionable one, but also on its own, not the worst thing in the world.

However, these two facts put together mean that date-keyed associative arrays are always ordered from earliest to latest, and for reasons that I've forgotten, it was at least at one point inefficient to use the MUMPS facilities for reverse traversal of the associative arrays.

The solution? Defining another date format, which is `121531 - $d` where `$d` is a value in the standard MUMPS date representation. This was then used instead of or alongside the standard representation for indexing associative arrays.

Practically, this was a huge hazard for code correctness as you needed to be absolutely sure of which format the date number was in. This additionally marks Monday, September 27, 2173 as the festive occasion of date sorting doomsday, as it is the date on which the secondary format would cross over into negative values and probably start causing all kinds of subtle bugs throughout the system. Let's hope we will have moved on to better systems by then!

I've got some bad news for you about how papers published at NLP conferences are reviewed.

> Deep learning systems don't store their computational graphs, the graphs are implicit in their computation process

I'm not sure about other frameworks, but in PyTorch, I think it's fair to say that while graphs are implicit in the sense that they are dynamically constructed at runtime (as opposed to statically defined at compilation time as with TF), they are not implicit in the sense that they are not directly represented by PyTorch's data structures: PyTorch does store the computational graph. After a backward pass, you can ask each Tensor in the graph, for example, for its associated Node: https://pytorch.org/docs/stable/autograd.html#autograd-graph

I used XTDB on a side project (written in Clojure) a couple years ago and was blown away by something that I think isn't even really stressed as a headliner feature for XTDB. That was the ability to treat queries as first-class data. XTDB's datalog queries can be provided as just native Clojure data structures, and that allows you to build complex queries using code. What this means is that it's much more DRY than copy-pasting and editing SQL templates, there's no ORM gumming up your performance and expressivity as your queries get more complex, and there's no half-baked implementation of an API for query composition: the _programming language_ is your tool for query composition. I couldn't tell you if there are other ways of getting this, as I'm not really a software engineer anymore, but it was a jaw-dropping experience for me to see how easy it could be to write a database layer, and far and away the best experience I've ever had writing one in any programming language.

I suppose what's at the heart of this, more than anything, is that Datalog has a near-trivial syntax that can transparently be accommodated by two simple data structures: lists and hash tables. Not so with SQL, whose COBOL-y nature obscures its syntax and makes it less straightforward to represent in everyday data structures.

Some unusual systems documented on these pages, pointed out by Gaston Ümlaut in his StackExchange answer[1]:

* Orokaiva (Trans–New Guinea): digit-tally system https://lingweb.eva.mpg.de/channumerals/Orokaiva.htm

* Fas (Fas): binary system (base 2) https://lingweb.eva.mpg.de/channumerals/Momu-Fas.htm

* Pazeh (Austronesian): quinary (base 5) https://lingweb.eva.mpg.de/channumerals/Pazeh.htm

* Amis (Austronesian): decimal (base 10) https://lingweb.eva.mpg.de/channumerals/Amis.htm

* Ron (Afro-Asiatic, Chadic): duodecimal (base 12) https://lingweb.eva.mpg.de/channumerals/Ron-Chadic.htm

* Barapasi (East Geelvink Bay): vigesimal (base 20) https://lingweb.eva.mpg.de/channumerals/Barapasi.htm

* Meyah (East Bird Head-Sentani): mixed-quinary/vigesimal https://lingweb.eva.mpg.de/channumerals/Meyah.htm

[1]: https://linguistics.stackexchange.com/questions/2652/which-m...

Yeah, it's too heavy for some things, but it's situationally very awesome. Fulcro takes the fantasy of "reusable components" very seriously, more seriously than any other frontend framework I'm aware of, and designs from the ground up to allow for that. Be sure to go to #fulcro in the Clojurians slack with any questions/comments--it's a very friendly community in there.

> Is that still tied to that google closure abomination ? I've not been in CLJ ecosystem for >5 years now but last time I used CLJS I remember they went all in on google Closure and it was a major PITA to use the rest of JS ecosystem because of it.

This has been solved now--there's a blessed CLJS solution[1][2] as well as a third-party compiler with NPM support[3] which many prefer.

[1]: https://clojurescript.org/news/2017-07-12-clojurescript-is-n...

[2]: https://cljs.github.io/api/compiler-options/npm-deps

[3]: https://shadow-cljs.github.io/docs/UsersGuide.html#npm

> I like Clojure, but unfortunately for web development, there isn't a great stack

What do you feel is missing? Certainly there are options (something as frameworky as Fulcro, something as barebones as a React wrapper like Reagent), so there must be some itch you can't scratch?

You might be curious to know that philosophers and linguists would see your (good) examples as violations of the Gricean maxim of quantity. More: https://en.wikipedia.org/wiki/Cooperative_principle

Full-throatedly acknowledging that people with nonstandard language practices are discriminated against is not really the look I think you want to have.

It is true that it will make one's passage through society easier if they are able to reproduce standardized spellings. Insofar as this sign is a signal that teachers are failing to equip students for life in that way, sure, it's concerning.

Spelling is different from other domains of education like mathematics, however: an explanation of "correct spelling" is not to be found in natural law, but rather in a Katamari ball of historical contingencies of chance, intervention, and everything in between. (Why'd we keep the _-ough_ in words like _through_? What if the Simplified Spelling Board had succeeded in its aims and totally reformed English spellings? What if Scots, not the English, had had linguistic dominion over the United States? Etc.) Moreover, in large part because "correct spelling" is derived from one very peculiar and privileged variety of English that not everyone speaks, your ease of access to correct spelling is going to be facilitated or hindered by facts about your SES, race, and ethnicity.

This is why I don't really care when I see a spelling error anywhere, unless genuine confusion results, or stakes are high enough that adherence to a rigid standard must be maintained. In many ways, nothing is gained from imparting it to a small child compared to something like basic arithmetic. And moreover, in some contexts I think it's not unfair to call an evaluative insistence on standardized spelling a vehicle for linguistic and therefore ethnic chauvinism.

I understand your original reaction--having proper spelling is a display of fitness to teach, in the same way that, say, having won some Kaggle tournaments is a display of fitness to do data science. But spelling is a rather peculiar thing to insist on, and I'd have been much more interested if the teachers had been writing out multiplication tables on sandwich boards. Spelling is sociologically thorny, and there are bigger fish to fry.

Or nobody ever cared, since forming an opinion of someone or an organization solely based on whether they can reproduce standardized spellings is myopic at best.

Speaking as someone who works in AI and as a linguist: this is really impressive, but be aware the grammatical phenomena involved here are common enough that they were surely well represented in linguistic texts in GPT3.5's training corpus. I'd be more curious to see how it would perform if you gave ChatGPT high-level instruction on more exotic grammatical phenomena, such as sandhi, split-ergativity, and Austronesian alignment.

Zbigniew Herbert wrote an excellent poem commemorating Laika and her grim treatment: https://www.best-poems.net/poem/first-the-dog-by-zbigniew-he...

Is there any empirical backing for this narrative? Some of this reads as pretty counter to intuition.

Most suspicious in my mind is the core presupposition (not a contention, a presupposition--the article doesn't even argue for it!) that rich people will step up to the opportunity to fulfill their noble obligation to give more to the less wealthy. Having known some pretty stingy wealthy people (and some very generous blue-collar people), it's not obvious to me that this is true.

I think the author's referring to the multiple implementations of persistent maps (i.e. APersistentMap). Clojure's generated docs[1] say there are four implementations (PersistentArrayMap, PersistentHashMap, PersistentStructMap, PersistentTreeMap), and this Stack Overflow answer[2] explains that the latter two are rarely used, and the former two make up the bulk of actual APersistentMap instances, with the language's core functions for persistent maps changing implementation used under the hood as it likes in order to do what it thinks is best for performance (basically, using PersistentArrayMap if the number of keys is small, and using PersistentHashMap otherwise). You can see this, for example, in PersistentArrayMap's implementation of assoc[3], which replaces itself with a PersistentHashMap if the number of keys has grown over the hardcoded threshold of 16.

So like you say, your experience as an "end user" makes it seem like it's just one data structure at least in interface, though in implementation it's actually doing some performance optimization stuff which, I think I'm willing to grudgingly grant to the author, does make performance harder to reason about in principle. Though in my (very unserious) experience, I think I've enjoyed languages that take a possibly incomplete stab at getting performance right over ones that draw a line leaving it entirely out of scope and declare victory.

I'll equivocate a little and share that I have been bitten by these internals before, though the fault was mine: one time, I was unwittingly relying on an implementation detail of PersistentArrayMaps, which is that they preserve insertion order. PersistentHashMaps don't, and my code was mysteriously breaking when number of keys grew beyond 16 until several hours later I learned much of what I've just shared above.

[1]: https://www.javadoc.io/static/org.clojure/clojure/1.10.1/clo...

[2]: https://stackoverflow.com/questions/16516176/what-is-the-dif...

[3]: https://github.com/clojure/clojure/blob/5ffe3833508495ca7c63...

So did it seem like some kind of weird scam, or what?

Genuinely curious: for what reason?

I think you misread GP

You mean Ashish Vaswani et al.?

I always thought so too, but I think what's actually going on is that MDN is like an engineering professor, and w3schools is like a high school shop teacher. The former gives you information that is more correct and deeper but can linger too long on technical minutiae. The latter has a more superficial understanding of technicalities but a stronger grasp of practicalities and how to get things done. This characterization seems mostly fair from what I'm reading in this thread (beginners prefer w3schools, seasoned hackers prefer MDN), and it may well be that w3schools doesn't even need to do any advanced SEO hacking to overtake MDN because amateur web devs outnumber veteran professional web devs.

Hm, is this really a dangling modifier? Something's a dangling modifier when its modificand is unexpressed or ambiguous, but "for cancer research" has a clear modificand, the noun phrase headed by "minutes".

Rather, I think this is just some ambiguity about what the "few minutes" are for.

> Paradoxically the core API is really stable to a degree that bugs aren't fixed that are a behaviour userland code might rely on.

Can you give an example? As a medium user of Clojure I struggle to think of anything in the core that could rightly be considered a "bug" and fits this description.

Didn't we try behaviorism out until in the 50's we decided this notion of "context" was either too small or too intractably expansive to be useful, let alone explanatory, and that it was necessary to start thinking about internal cognitive processes instead?

Did AllenNLP ever support any other engine? For the past couple years at least I think they've only supported PyTorch

GP's point is that while yes, we know since `f` has arity 1 there's no ambiguity, in general you might not have the arity of any given function fresh in your head, and therefore can't tell (in Ruby) just from looking at `f f 1` whether it means a single invocation of an arity 2 function, or two invocations of an arity 1 function

There are many, many victimless crimes that people are unreasonably incarcerated for.

> 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.