oddthink

Calling it "AI" is a stretch, it's more like using the TensorFlow infrastructure to do Bayesian inference. Here's a presentation on the process: http://hyperion.usc.edu/UQ-SummerSchool/pres/Langmore.pdf

Thanks. My question really wasn't focused well, and it was easily read not as "please help me understand" but as "hurr durr Python is better".

I think my reaction comes from the dissonance between people saying "Deno is the best thing ever for CLI apps!" then following up with "Here are the ways it's better than Node!", without acknowledging all the other scripting languages out there. But I think I need to read that first line as having an implicit "...in the JS/TS ecosystem", and then it all makes sense.

Since clearly one of Deno's draws is that it improves on the package management of Node, I was wondering why JS projects so often end up with such a long list of dependencies, compared to the Python/Go/C++ projects that I'm more familiar with. That's probably explained just by NPM making it easy, so people did it. (Sort of like how Java grew convoluted DI schemes because OO + GC + reflection made it possible.)

One of these days I should learn more JS than having read through the Good Parts once. :-)

This may be inviting downvotes, but I still don't understand the use-case of Deno. Why would I use this over something like Python?

In Python, I find I can do most things I want with the standard library plus a handful of well-known packages, so even just downloading the tarballs and installing manually isn't all that onerous.

Why do I want a "browser for code"?

I may just be out-of-touch, as a purely backend/machine-learning/quality engineer. Clearly, this is a real need in the front-end / JavaScript space, but coming from the outside I just don't quite understand yet the value proposition here. Can anyone explain?

That looks super fun! Are they still using this? I was at MS a few years before that, still dealing with a few legacy things in A+. There were hopes that we'd switch to something like F#, but we ended up just re-doing most of the mortgage analytics in kdb/q, which was fun in its own way.

Oh, yes. In the olden times, I could hop on the subway for 20 minutes and get to a magical place with free food, good coffee, an actual full-sized desk, a monitor bigger than a 12" portable, and no fights breaking out every 45 minutes or small people coming in and saying "Dad? Daaad?" just as I had a hold of an idea.

That probably suggests there's an urban / suburban divide, too, where the people with enough real estate to set up a full-on home office are much happier with the results. I don't even know where I'd stick a 27" monitor if I ordered one.

"Old and quirky" is an understatement. It's a god-awful mess, with semantics so murky that people end up just copying patterns and hoping that it'll do what they want it to do. And it can't be killed, because every bit of those implementation-defined semantics are used by someone.

But one of the examples of adding maps would be for it to mean "upsert", rather than "use the monoid for the value types". I think that's still a perfectly good monoid over maps (it's not commutative, but that's not a requirement).

And yes, you can argue that using "+" implies commutative, and I can see that, but I think it's still a plausible meaning in this context.

(I'm probably rabbit-holing here, but it's interesting.)

Yeah, I agree. I wrote some mortgage prepayment models in q for a while, but didn't dip into K itself. Q is fantastic as a database query language (assuming you have time-series databases and are mostly doing fairly simple operations.) Implementing a full model in it is fine, but can get hard to maintain.

Also it has (or had, maybe they fixed it) a bunch of weird quirks, like "sum foo" skipping all the NAs in a list while "+/foo" didn't, resulting in NaN. (Or maybe it was +/ over an int array didn't work while a double array did. I forget.) Arrays of dicts were immediately turned into tables, which didn't work the same as an array of dicts, etc.

But, yeah, it's not crazy implementing things in q/K, as long as they're mostly linear things. Trees are hard, iterative methods are hard, and it's really hard to skim code, other than to just rely on names and comments.

Ugh, this. I still fail to understand how a device from 2019, even a phone, could show any rendering delay when scrolling to page 200 of a 400 page static document. I thought PDF was less programmable than PostScript, but there's still got to be some kind of non-local semantics in there.

Yeah, I have a physics / GR background, so MTW is the lens through which I see all of this. That and Schutz's Geometrical Methods of Mathematical Physics.

I agree that we don't need coordinates. Things are things.

But what always got me about the geometric algebra stuff was that they used bivectors for areas, which seems like the wrong thing. If you're integrating a vector field over it, you want a 2-form, not a bivector. I suppose the distinction doesn't matter as long as you're just in Euclidean space, but even then, if you need to drop down to coordinates and do the actual integral, you're still going to want to have changes of variables that work. That leaves me with a kernel of doubt that they're doing the right thing.

So, like many things, this is both true and false. The object isn't the coordinates, but you do need two kinds of things to make physics work. (Maybe you don't for geometry, though, not sure.)

If you have a displacement vector, and a potential gradient, they can't be the same "kind" of thing (i.e. both vectors), because their dot-product should be preserved. If the slope gets half as long, it's twice as steep.

Thanks, this is basically what I had concluded. The exterior algebra exists on both the tangent and cotangent space, and that I was mostly used to seeing it in the cotangent world, due to its applications there.

Does anyone have a good summary of how this relates to the differential geometry world with its n-forms and n-vectors? For example, I'm used to thinking of the wedge product as operating over n-forms and requiring a metric (or volume element) transformation to work over vectors. Similarly, I don't see any discussion of behaviors under coordinate transformations.

Because caps lock is already control. :-)

Atoms don’t work in that kind of a field, let alone molecules. Nothing wants to go across field lines, just along them.

For radio pulsars, I didn't think it was that mysterious. (Not like accretion-powered things, where I don't know how that works.) You've got an intense magnetic field that beams emission. At the low level any moving matter is pinned to a field line, like a bead on a wire, and that sets the direction.

I worked on pulsars in grad school, and I always groused that I had to deal with ultrarelativistic plasma physics and pair-production in curved spacetime. There's a reason it's hard to come up with solid answers for these things.

It's about nuclear density. Neutron stars are held up by neutron degeneracy pressure.

Another fun fact is that the magnetic field energy density alone near the surface of a pulsar (1e12 gauss and up) is about that of lead. (~40 g/cm^3).

Yes, thank you. I was thinking of Kent Pitman's critique that unwind-protect didn't have the right semantics when implemented with dynamic-wind, and that (in general) it seemed like fluid-let and unwind-protect wanted different sorts of continuations to implement them. (And now I need to go read more about one-shot vs multi and delimited continuations.)

Someone (I forget who) had a critique about dynamic-wind itself that (IIRC) involved capturing continuations from within the before- and after-thunks of dynamic-wind, but that seems more like an edge case.

Does anyone have a good link to the state of the modern thinking on continuations?

I remember from back in the Scheme R5RS era there was a conflict between call/cc and dynamic-wind.

If you have a dynamic extent (like for example a try {} finally {} block that does resource allocation/deallocation), and you exit, but then jump back into the block, how far do you try to re-wind the state? You probably don't re-open files, but you would probably want to re-set any dynamic-scoped variables.

I don't remember seeing this raised as an issue recently, so it must have been solved somehow, and I'm just wondering how.

I like the phrase, too. I'm on the "sick of programming languages" side, and I like go, for the things I'm using it for: CLIs, simple debug web-servers, calling out to RPC services. (Read a CSV file, run everything through translate / grammar parsing / etc.)

I'm in that age of folks that did pascal in high school, C and Scheme in college, C++ and python in grad school while futzing around with ocaml and common lisp and sather and other fun things. Programming languages are fun.

But, oh, I have so much other stuff to pay attention to. I write C++ a few days a week, which is barely enough to keep move semantics in my head. I also write SQL and analysis docs and internal DSLs and configuration files and python.

At this point, C++ is barely earning its keep, in terms of mental complexity for reward. Go feels a lot nicer, since I can just get in, do my thing, get out, and it'll at least work and give me a compile error if one of the APIs change when I don't look at it for a year.

I'm not about to jump into rust.

So, at least for me, go hits a pretty good sweet spot.

[Edit: I'm not trying to point fingers at rust in particular. It looks fun. If I weren't still working on getting my hobbyist-Haskell better, I'd probably be playing with it. But that would be at home, for fun, not where I have to have the thing in my head for production issues.

It reminds me a bit of the old statement about perl, that it was a fantastic language if you used it every day, but not if you don't. And I don't get to use these things every day any more.]

Not in my experience. I have both a CVS and a normal grocery store (a Morton Williams) across the street. CVS beats the grocery store on milk price (e.g. Horizon) by ~$0.50/gal and on breakfast cereal (e.g. Cheerios) by ~$1.

Whole Foods 365 brand organic milk is slightly cheaper than CVS, but it's a slightly longer walk and has longer lines and is in a basement, so I tend not to bother. (I probably should go there more often.)

I don't know if JVM is a problem; the issue that caught me in my few-weeks of experimenting with the language was the lazy semantics of sequences.

I know the problem, and I've danced around this same issue in things like Haskell with strictness annotations, and I've run into the same problem in R, but I'd like to just be able to read and parse a ~1GB CSV file without blowing out RAM with a giant list of thunks.

This was many years ago now, so maybe they've fixed it, but I'm tired of fighting that particular battle.

I don't know about overqualified, it's more that the job is hard in a different way. I'm not a CS grad, but it's not as if I'm actually using my numerical analysis or computational fluid dynamics coursework either.

However, I do jump between discussing if a trie is the right way to implement something, discussing whether the "simple" model should be a SVM or boosted tree, trying to figure out if we've covered the major abuse angles in our product, coordinating with all the other teams we're collaborating with, analyzing the experiment results, etc, etc.

Having at least some actual CS certainly helps fill in the gaps, even if it's not what I'm doing most of the time.

Is that nested-define common racket style? I know it's been legal, at least since R4RS, but I've never seen it actually done.

Interestingly, the APL community (or at least the kdb/K community) and the Forth community (from what I hear) often push in the exact opposite direction. They seem to love to take advantage of any accidental regularity in the problem as given to simplify the code as much as possible.

The logic is that often the specs don't change, and if you make the code concise enough, you can just rewrite it if you need to make it more general.

I always thought there was something almost magical about this one.

I think there are self-reinforcing pockets out there. I'm a manager also, and I know if I heard any of this I'd stamp it down immediately. Heck, if I didn't, I wouldn't be doing my job, and I'd (hopefully) eventually be called on it myself.

Despite my griping, I liked kdb+ and q. As a database query language, q is awesome, if you are doing a lot of time-series analysis (running sums, etc., nothing fancy). As a language, the table type in q is very nice, a bit like what pandas or data.table wish they could be.

For a while there was a freely downloadable version to try out, and you can look at "q for mortals", http://code.kx.com/q4m3/, to get some flavor.

About 10 years ago, A+ was just used as the communications protocol for fixed income. Nothing (that I knew of) used it, but C++ ceremoniously created A+ objects, sent them over the wire to another C++ process that decoded them.

Around that time, we moved much of the mortgage models over to kdb and q, which was fun. Lots of weird dark little corners in that language. (List of dicts? Nope! It's a table now! 'sum x' drop NAs, while 0+/x was NA if any value was NA, but maybe only for ints, not floats, etc. Ugh.)