338 karma · joined July 10, 2019
New hypothesis: Some practices make all the sense in the world in huge enterprise projects, and no sense at all in small utility projects.
But that premise is well-known to be in conflict with established reality. Identifying specific individuals from these sorts of data points is famously, disturbingly easy to do. People even do it just for fun, almost like it were an Advent of Code challenge. That's the reason why there will never be another Netflix Prize.
Also, Google's revenue isn't necessarily derived from what ads provide the highest ROI; it's derived from what ads people want to buy. Regardless of what anyone at Google thinks about contextual vs. behavioral ads, it's in Google's interest to go nuts with behavioral ads simply so that they aren't letting all the other adtech companies keep all the behavioral ad spend uncontested.
I'd feel better assuming that question's answer is simply unknown until a few different people have performed a few different field experiments.
For my part, for example, I pretty much never click on ads, because they typically get shown to me at a time when I'm already busy doing something else. But, if I later perceive a need to buy a product of that kind, there's a decent chance I'll remember the name, and therefore be more likely to Google them or take a closer look when I see them mentioned on Wirecutter. I have no idea how typical I am on that front, but, tangentially, I do at least suspect that, if clicks were really the end-all-be-all of hawking product, then there wouldn't be quite so many billboards by the side of the highway.
If you do get enough profit from directly traceable conversions to cover the campaign, yeah, that's a gimme - you may not know your actual ROI, but you do know that its lowest possible value is still positive. That said, I don't work in adtech, so I don't really have any way of knowing how common that is.
Which will work out just fine, so long as your advertising client isn't someone like RStudio.
A reasonably large number of the bugs I encounter relate to the order or number of formatting arguments not matching the slots in the format string. It's pretty hard to make that kind of mistake with an fstring.
All of which are ones that I once thought were quite enjoyable to work in, and still think are well worth taking some time to learn. But I submit that the fact that none of them have really stood the test of time is, at the very least, highly suggestive. Perhaps we don't yet know all there is to know about what kinds of programming language constructs provide the best tooling for writing clean, readable, maintainable code, and languages that want to try and remain relevant will have to change with the times. Even Fortran gets an update every 5-10 years.
I also submit that, when you've got a multi-statement idiom that happens just all the time, there is value in pushing it into the language. That can actually be a bulwark against TMTOWTDI, because you've taken an idiom that everyone wants to put their own special spin on, or that they can occasionally goof up on, and turned it into something that the compiler can help you with. Java's try-with-resources is a great example of this, as are C#'s auto-properties. Both took a big swath of common bugs and virtually eliminated them from the codebases of people who were willing to adopt a new feature.
FWIW, I tend to think of comparisons to Perl as being a lot like Nazi comparisons, only for programming languages. And I do think there's some wisdom to the Godwin's Law idea that the first person to make a Nazi comparison is understood to have automatically lost the argument.
It's just that, at this point, Perl is both so near-universally reviled, and so well-understood to be way too optimized for code golf, that any comparison involving it is kind of a conversation-killer. As soon as it shows up, your best options are to either quietly ignore the statement in which the comparison was made, or join in escalating things into a flamewar.
Waiting for the fire department to show up and start spraying the structure with high-pressure hoses in order to contain a fire that got much larger in the intervening time because it wasn't being mitigated by a sprinkler system, on the other hand, doesn't seem to have damaged the structure at all.
Hindsight really is 20/20.
It's also interesting that fire mitigation measures were discarded in the interest of historic preservation. The charpente being a part of the building that basically nobody ever sees, the question arises, "preserving it for who?" Or had the preservation become an end in and of itself?
Pointing out that they also sell red envelopes wasn't much of a consolation.
It relies on word sense disambiguation, which tends to be one of those very language-specific things, and so I'd expect (but haven't verified) that, like other techniques that rely on language-specific bits, it wouldn't work as well on most non-English text. And the most interesting polysemy problems aren't to do with part of speech. They're things like "apple-as-in-food" vs "apple-as-in-computer", or figuring out that "The Big Apple" doesn't have anything to do with either of those. What would be really interesting is dealing well with jargon, slang, and terms of art.
As far as those notebooks, is there one in particular I should be looking at? I might have missed something, but the stuff I saw basically just demonstrated, "Hey, we can handle a lot of training data really fast." What I'd be more interested in seeing is, "Hey, plug us into your document classification pipeline and your performance (as in accuracy) metrics won't know what hit them."
edit: For a more concrete example of what I'd like to see, and going back to the analogy task: The holy grail I'm looking for isn't "king - man + woman = queen". It's more like "software engineer = programmer", and also "software engineer != software + engineer".
My own sense is, the real problem that the space needs to contend with isn't that the math isn't elaborate enough. It's that we're still waiting for someone to come up with a really good way to deal with polysemy, and with multi-word phrases that form a single semantic unit.
† Because it doesn't measure performance at something people typically want to do with these models in real life - there's a strong "party trick" component to the word analogy stuff.
Subtextually, there seems to be a peculiar double standard being presented: Paying retail prices for in-kind donations, which implicitly covers the wages of all sorts of retail and distribution workers associated with the grocery store, as well as lining the pockets of the grocer store's owners and, if it's a public company, shareholders, is just fine. But providing cash donations is bad, because then the charity might use some (presumably less) of that money to pay its own employees to do those jobs? And paying them money is bad, because they should be getting all that labor for free?
It's hard for me not to see that as a tacit allegation that one's time and labor are inherently less valuable when they're being given to an organization whose mission is to help others instead of one whose mission is to make its owners as rich as possible. Which, personally, I think that my opinion runs close to being the exact opposite of that.
If you want to spend your free time helping others, that's awesome. If you want to make a career of helping others so that you can spend even more time doing it, hey, that's awesome, too. And, the world's distributions of wealth, free time and skills being what they are, supplying the money that enables people to go that route can quite easily be the most effective option still other people have for giving back, so that's awesome, too.
The OO system is absolutely weaker. Depending on your situation, that can be a big advantage. I work in a mixed Java/Scala codebase, and, while I generally like Scala, one of our more annoying bits of yak-shaving is making sure outward-facing Scala code doesn't do anything to make itself overly awkward to consume from Java. I haven't worked as extensively in Kotlin, but, from what I've seen, you've got to spend a lot less time worrying about it there, because Kotlin stays much closer to Java's OO semantics.
My sense is, if type erasure or lack of parametric polymorphism are really causing you pain, yes, Scala is for you. Pattern matching, too. If your Java pain points are more prosaic than that, Kotlin is a less radical change that is likely to address most of them them without introducing too many new ones.
It's almost certainly much more recent than recognizing a face, but still something humans have been doing for a long time, and is a near-universal human behavior. Like the others, though, it needs to be learned, has a strong cultural component, and tends to happen with the help of others.
It's also interesting because there's an entire academic field devoted to its study, and, at least from my peripheral perspective, they seem to be constantly bumping up against Polanyi's Paradox. I've seen more than one academic argue that the set of grammatical rules that we can accurately describe is a subset of the grammatical rules that we use when communicating. Which, if true, is pretty interesting, since language is a social construct - the implication is that we can fabricate and reliably transmit information that we can't actually express.
They all have their shortcomings, of course. Possibly the most universal one is that none of the ones that I'm aware of seen do a good job of capturing the word stress system in English pronunciation. By contrast, for all its failings, the the current orthography does encode clues that a very experienced speaker of the language can use to infer word stress with a reasonable degree of accuracy.
It mostly only sold kits, drones, 3D printers, stuff like that. Very little in the way of individual parts and tools. Which always struck me as a bit of a problem -- it more-or-less sold a strict subset of the actual DIY stuff that you could get at competing retailers. So maybe they'd sell someone their very first Arduino starter kit, but it must have been really hard to retain repeat customers. Having bought that Arudino kit and completed all the introductory projects, when the time comes to start getting more creative, you're going to have to go somewhere else to buy, say, an LCD display or a fistful of capacitors. And you'd presumably stay there, since there were so few things you could get at Makershed that you couldn't also get somewhere that sells the other stuff you need.
In short, it was kind of a lot like what Radio Shack had become in the end, only even more so.
"Dwindling creativity" because all these expensive tools are creatively limiting. For example, 3D printing is cool, but, compared to lower-tech methods, it can also be a lot to wrangle. Once upon a time, if you needed to make a part, you'd hand-carve it, or cast a rough version and then finish it. There's very little between you and the act of creation. With 3D printing, you've got to worry about what kinds of shapes your printer can and cannot make, and have to spend a whole bunch of time on CAD, calibration, etc, etc. My own suspicion is that, oftentimes, the thing you're making is just a by-product, an excuse to play with the expensive toy.
"Access to equipment" -- yup. Once upon a time, DIY was about doing things on the cheap, and there was a lot more stuff being done with inexpensive hand tools, many of which could readily be acquired at estate sales and the like. Now you apparently need to blow a typical person's monthly entertainment budget on a makerspace membership in order to get access to laser cutters and CNC lathes.
"Bringing your product to market" just isn't a part of the DIY I originally loved. To me, DIY is a hobby you do for fun, and a creative outlet, not a yet another form of startup incubation.
One thing that has historically put me off about the maker community is these artificial distinctions where materials and ways of making things that have historically been considered "girl stuff" get less respect, or sometimes don't even get recognized as making at all.