I am interested in programming languages, functional programming (especially Haskell), domain-specific languages, static analysis and program synthesis.
I am working on apply programming language ideas to supply chain planning.
I worked on supply chain optimization at Target for several years, and co-authored a textbook on reinforcement learning based on that experience.
When I've been in that position, I've just trusted junior folks to figure out the tooling-specific way to do things like that, and it's worked out perfectly well. If anything, it leaves people happier and learning more.
And, instead, I can focus on the fuzzier, higher-level things that involve non-trivial tacit knowledge rather than things somebody can resolve with a Google search (or just ask Claude).
For one, there might be trade-offs against dimensions other than safety and expressiveness. Performance, corporate support, libraries, popularity, learning curves, similarity to other languages...
For two, popularity is simply not strong correlated to quality. Popularity is a social function driven by, well, social factors. It's heavily path-dependent and noisy. There is absolutely no guarantee, not even close, that the "best" thing in any sense will be the most popular, or popular at all.
It isn't nearly as much of a trade-off as people say. Languages like Haskell are both remarkably expressive and provide a lot of safety. (And, of course, languages like Python, Java and Go are the opposite.)
It's interesting how people view software as a distraction and an annoying side quest/cost center, but never apply that to, say, 90% of what management does. None of that "directly" makes money either!
That tells us a lot more about the leadership and management philosophies at modern companies than anything fundamental about what kind of work actually matters.
Kicking out 2% of your existing customers in a physical venue violates people's expectations, so it's going to get you disproportionate bad reviews and word-of-mouth.
Good thing that we've managed to keep everybody's expectations a hell of a lot lower for software quality then :)
I mean, it has definite Borg Bill Gates vibes, doesn't it?
It's totally reasonable for tech folks to be leery of a company using a strong market position from one system (Windows/Claude) to push mediocre complementary software (IE/CC).
The US has a notion of "disparate impact"[1] that means you can be liable for discriminating based on a protected characteristic on the basis of correlation. This is why HR departments are very hesitant to use things like IQ tests for screening candidates, for example.
Property based testing is useful for finding bugs even in these kinds of CRUD heavy apps. There can be a surprising number of bugs and unexpected behaviors in the interaction of multiple sub-systems or APIs, and one way to find those bugs is to come up with properties on traces of calls.
For example, I saw a paper on using metamorphic testing (a particular technique for defining properties to test) to find bugs in the web APIs of Spotify and YouTube[1]. I don't have time to reread the paper just now, but I remember that they found weird behavior in pagination of search results. Not a big deal in that particular case, but I've definitely seen internal APIs with behavior that could be similarly wrong but with a much larger real-world impact.
Personally, I see property-based testing and formal specification more as tools for design and debugging more than full-on correctness. Even with AI models it's still really hard to fully prove something correct, but having even a partial logical specification can let you trade design time for debugging time and lets you find inconsistencies or potential edge-cases when you're initially figuring out a system, rather than waiting until you have a massive codebase to debug and redesign in production.
It's not a panacea and you still have to be careful at the boundary between your nicely modeled system and the real world, but, once I got the hang of working in that style, having some formal properties or partial logical specifications of the behavior I needed has been really nice to have, as much for saving effort as for ensuring correctness.
I've mostly worked in slightly different domains, but I've found property-based testing useful both as a tool to catch bugs but also as a tool for communication. I spent a couple of years building and supporting a supply chain simulation at Target, where I frequently got requests for new metrics from the supply chain planning team. By teaching them how to specify either the whole metric or, at least, some of the expected behaviors of the metric as mathematical properties, it took far fewer back-and-forth conversations to correctly implement the metric in the simulation. We could then test these things by checking these properties over a bunch of random simulation traces. Day-to-day this saved a bunch of time in debugging small simulation mistakes. In the longer-term, having this test suite also let us rewrite the simulation code in a new style in Rust to drastically increase performance. All of this would have been possible without the set of properties, it would have just involved a whole lot more slow, tedious work.
The neat thing with Emacs is that the core concepts of the system are all first-class programming entities with their own documentation. So if you want to know what your current mode does, you can use C-h m to get a bunch of information including commands, key-bindings and links to code. If you have a key command, you can use C-h k, enter the keys, and you'll see exactly what function that command runs. You can get info about functions with C-h f and variables with C-h v; coupled with some kind of fuzzy-find-autocomplete (which, unfortunately, isn't set up by default), it's usually pretty quick to find the functions and config options that are relevant to whatever you're trying to do.
I still use web searches to look up Emacs things occasionally, but the built-in help commands are still useful because they're naturally tied to (and organized by) the core code entities that power Emacs.
Counterpoint: I absolutely give credit to Sonic for being a great ISP and recommend them to everyone. I got my parents to switch when Sonic finally rolled out to their neighborhood.
If online comments are anything to go by, I'm not alone.
If you're in the Bay Area and you can get a Sonic fiber connection, I would highly recommend them over AT&T/Comcast/etc.
I am interested in programming languages, functional programming (especially Haskell), domain-specific languages, static analysis and program synthesis.
I am working on apply programming language ideas to supply chain planning.
I worked on supply chain optimization at Target for several years, and co-authored a textbook on reinforcement learning based on that experience.
contact: http://jelv.is, [email protected]