oddthink

I work at Google, though not in the Bay Area, in Maps, and we recently had a program where every engineer was encouraged to participate in a user study on features they worked on. The goal was just watch regular people sit down and use the product, see what they liked, see what they didn't, and build some more user-empathy.

I found this pretty awkward, but rewarding, and have let it help guide my personal prioritization. In this case, having a few anecdotes was a lot more powerful than the dry aggregated data.

Me, I long for the days when I could just download a tarball and be done. :-)

Seriously, as a mostly C++/python/R developer, maven was a PITA to set up for experimenting with Java, and I still don't feel like I entirely understand the npm/bower/yarn ecosystem. (Will they install globally or locally? What permissions do I need? etc. etc.)

It's certainly not something that I can't learn, or something that's really all that complex, but it's another barrier to just messing around with a new project. It's better for the frequent-users than the infrequent.

As an infrequent user of Java/Javascript, I'm fine with just downloading a tarball or cloning a single all-inclusive repo, and dealing with it being harder to update or to push a change back to the source project.

Even in python, I just maintain a local global install and occasionally update numpy/scipy manually. I'm not saying it's the best setup, but it's pretty easy to download verson X.Y.Z, config/make/make install, and done.

I agree that Go makes infrequent use easy. That was part of why I went for python over perl; I just didn't use perl often enough for it to stick in my head. There are similar issues with Haskell, just because of all the many libraries of abstractions and operators to memorize.

I still don't see why dependency management has everyone so up in arms for Go, though. Especially for infrequent use, it's hard to beat just copying the lib into your source tree and re-fetching from git every now and then.

Thanks for the links. I've been looking for something where I can save executable snippets (shelling out to things or making RPCs to services) in a smalltalk-like browser, and it looks like this might work. I tried Amber a few months back, but couldn't figure out how to get node to shell out, so I went back to TCL+tk.

Yep, all corporate use. Subway works pretty well to get people there. And honestly, I'm pretty pessimistic about just building enough housing capacity to be comfortable. There's been a ton of residential building in NYC, but it's all been "luxury" 1-bedroom and studios. The incentives just aren't there to build "family condo" units, at least in Manhattan.

But even in the US, there are other options.

I'm in the Google NYC office, which occupies most of a building that's a full city block and 15 stories high (https://en.wikipedia.org/wiki/111_Eighth_Avenue) and that sits on top of a major subway station. We also have floors in a few of the neighboring buildings (Chelsea Market, etc.).

It seems to work really well. The density means that it's not that physically far to go to meet with another team, and that you hear what's going on with completely unrelated divisions.

I'm a little surprised that Silicon Valley overall has stuck with these relatively low-rise, sprawling campuses.

Whenever I look at the Tcl source code, I'm impressed by how clean it is: https://github.com/tcltk/tcl

Yeah, I have a hard time imagining this working. If anything, I'd like to be able to get back to working the 8-6 days I could before I was doing school dropoff in the mornings.

It's not like there's any dead time, for me at least, although it probably varies by industry. Back when I was in finance, we needed to be around whenever markets were open, if only to be able to run one-offs and answer questions for the traders.

In tech, there's always more to do. The bulk of the hard stuff isn't raw programming, it's doing the data analysis to figure out where problems are, trying to come up with experiments to run, documenting them so you don't repeat yourself six months later, and so on. On top of that, there's whiteboarding out ideas with people, teaching interns and more junior folks, meetings with aligned teams to share knowledge, manager-stuff (1:1s, planning), writing up docs (also to share knowledge), trying to learn how something works, etc.

I don't think I can manage more than a few hours of raw code time myself, but that's a pretty small slice of the things that need doing.

Yeah, the ML parts aren't in Go. I'm working in TensorFlow, so it's C++ scripted by Python. But there's a lot of incidental stuff that needs to be done, most of which I don't want to spend cycles on thinking hard about, and Go does a good job there, in that narrow niche where I want something that runs on one machine but find python too slow.

At a previous gig, I had done a lot of F#, and I think that's close to my personal sweet spot, but I'd have to use it frequently to keep it in my head. Go is small enough that I can load it into cache when I need it.

I like it. My brain's already pretty full with trying to get a ML pipeline optimized and launchable, and if I need to write something to read a CSV file, make some RPC calls to a service for each row, and dump the results to a file, go just works.

Sure, I could use something like Haskell, but then I'd have to worry about whether I'm accumulating a giant stack of thunks that'll blow up. go just works, and less of it will bit-rot than the comparable python script, thanks to at least some types.

This is why the SREs seem to be fans, e.g. https://talks.golang.org/2013/go-sreops.slide#1

I agree, I don't know why they make it so easy to wipe everything. I was thinking of getting my son (8) a chromebook, install minecraft on it, basic Linux, etc., but that splash screen makes it a non-starter. It's almost guaranteed that a little brother will get his hands on it and wipe the drive within a week.

Yep, you're right. I was playing too fast and loose there. The Bernoulli likelihood definitely suggests the odds as a natural space, but it's not required.

I'm sorry, that seems like the most backwards explanation of logistic regression I've ever seen. It uses the sigmoid function because it's logistic regression. The statistical model is a Bernoulli distribution. Write down the likelihood, maximize it, and you get the sigmoid.

Type information is one. CSV is slow, since it has to parse everything on load. CSV has no random access, since rows can be arbitrary length. CSV takes up a lot of disk space, since a 8-byte double gets expanded into a 15+ digit string.

Interesting. In what industries is Oracle so dominant? You say government is one, but where else?

In industry, all I've ever seen is Sybase, SQL Server, and MySQL (ok, technically Oracle). (My background is finance and technology.)

Adventure playground is there, but most of the tunnels are blocked off. You can't go inside any of the pyramids any more. It's still a great space, but it's not a free-wheeling as it was perhaps intended to be.

If you have a seminar-like class with a different lecturer every week, then, yes, it's a problem if they can't get consistent notation. I'd hope that's rare in undergraduate courses, though.

And meaningful variable names would be absolutely horrible for anyone trying to calculate with them or visually comprehend them. Energy = lorentzFactor * restMass * speedOfLight^2? You'd be writing all day to get anything done, and it would be hard to see the forest for the trees.

See also the brevity of notation in J, q, and APL, and the "tacit" style of J and "point-free" style of Haskell.

I doubt it, to be honest. In my experience, universities are locally consistent: the E&M class isn't going to contradict quantum, at least by much. And once you're out of undergrad, it's pretty easy to figure out what's going on, given the context.

If we try to standardize, we'll end up with some awful compromise position that no one likes. For example, I still dislike the push for MKS units where CGS would work much better, such as E&M, plasma physics, and much of astrophysics.

I use it in little ways, here and there. Its syntax inspires any tool-command syntax I write (see http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html). I have a few Tk scripts around to launch tasks (generate a new data repo, run various forms of regression tests, etc.); nothing beats Tcl+Tk for "build your own tool" GUIs. When experimenting with C code, it's useful to just embed a Tcl interpreter to run bits of it. Sure, I could use Lua, but Tcl's even easier.

None of those are legacy projects, but none of them are the primary focus of my work, either.

I'll try to give a pragmatic example. At work, we've got a lot of analytics code in C# for model-estimation, pricing, etc. I spend a lot of time tweaking models, running them, then extracting and analyzing the results. F# works very well as a scripting language for me, where otherwise I would be using something like IronPython.

The results-processing I could do from anything (R, python), but scripting the run (running N random samples of something, doing simple cross-validation, manually hacking a pseudo-hierarchical model, etc.) is much easier when I have direct access to the C# API.

Since the codebase is always-evolving, the type checks of F# (as opposed to IronPython) are useful when going back to an old script.

I also just enjoy using F#. I'd been hoping to learn a ML-family language for years and working at a F#-friendly shop has let me do that.

I knew of it, yes, but thanks for mentioning it in this thread, since I don't know how well-known it is.

For my purposes, kx got it entirely right: I can barely scratch my own nose with <2 GB of data. :)

IMHO, q's (and K's) big advantage over J is that they have tables and dictionaries as an available data type. This makes basic tasks like reading csv files and merging different data sources much easier in q. q also has a nicer syntax for anonymous functions. Of course, q is also very expensive, and it tries to be too clever at times: I remember running in to all sorts of weird corner cases, with things like NAs being skipped in float arrays, but not in int arrays, etc.

I do that all the time in the interpreter, especially when slicing pandas DataFrame objects, e.g.:

    df_subset = df['date buyer nwidgets'.split()]

That is far easier to type than the explicit list, with all its punctuation. Now, it's definitely weird that they did a `split(" ")` rather than just using the default, but the idea is the same.

I do try to strip stuff like that out before I put it into a script, replacing it with the explicit list, but I'm never sure if that actually improves anything. It's not as if the explicit list is any easier to read.

Nope. In GR, energy has as much "gravity" as the equivalent mass, so it won't affect anything. (Energy is more tied to the expanding universe, though, as the wavelength increases too, so it's an important distinction in early-universe cosmology.)

Rest mass is mass. Photons have zero mass. "Relativistic mass" is more confusing than helpful and is generally not used in modern GR.

Cite: ask any actual physicist. I hate to appeal to authority, but this is the view I was taught in grad school (PhD, UCB, 2001), and I have never spoken to anyone in physics or astrophysics who thought "relativistic mass" was helpful.

"Relativistic mass" is one of those concepts that was considered, bandied about in the 70s for a while, then ultimately discarded as not helpful.

Photons have no mass, period. An ensemble of photons may have a non-zero invariant mass, but there's just no way in which it's correct to say a photon has a mass.

This has nothing to do with saying that you can't convert mass to energy. Electron-positron pair creation from ultra high energy gamma rays has been a known thing for a long time. Pulsars are thought to run partly off of pair creation off the magnetic field, etc.

Wait, what? Photons have no mass, but they have energy. Ergo, that "both of which have mass" is flat-out wrong. Methinks wikipedia has problems.

It's definitely encouraging. I don't know what the current state of the art is, but one of the main conclusions of the NIST Java Grande working group back in 2000-2003ish was that lack of a complex type was one of the big things holding Java back for numerical work.

There was a wave of excitement about doing numerics in Java around 2000ish, but it seems like everyone has since moved on.

Well, in emacs you can try out evil-mode, which will get you the basic vim commands. I flip back and forth between the two: the vim commands are great when I'm focused on a single document, usually a hunk of code, and just have to make some something happen. On the other hand, if I'm flipping between editing a latex write-up, recording progress in org-mode, moving files around in dired, flipping between two different interpreters and several shells, the web browser, database query front-end, etc., then I start to get annoyed by the modes and prefer the flow I can get by not having to worry about editor state.

Right now I'm mostly using modeless interactions, but every now and then it feels good to get the vim muscles moving.

The real problem with data.table is that it has too much magic. It's great for interactive use, but it's hard to program to.

If, for example, you want to aggregate a table using a list of supplied variable names, like if you wanted to abstract out some aggregation code, you need to descend into horrible quote/substitute/etc. hackery to make it work.