I find the same. Even those who are interested in it in theory hit a pretty unforgiving wall when they try to put it in practice. Learning TLA+ is way harder than leaning another programming language. I failed repeatedly while trying to "program" via PlusCal. To use TLA you have to (re)learn some high-school math and you have to learn to use that math to think abstractly. It takes time and a lot (a lot!) of effort.
Now is a great time to dive in, though. LLMs take a lot of the syntactical pain out of the learning experience. Hallucinations are annoying, but you can formally prove they're wrong with the model checker ^_^
I think it's going to be a learn these tools or fall behind thing in the age of AI.
I think the "high school math" slogan is untrue and ultimately scares people away from TLA+, by making it sound like it's their fault for not understanding a tough tool. I don't think you could show an AP calculus student the equation `<>[](ENABLED <<A>>_v) => []<><<A>>_v` and have them immediately go "ah yes, I understand how that's only weak fairness"
Fictional, but it captures something about work and life in that unique way that art is supposed to.
One of my favorite scenes:
Peggy: "You never say thank you!"
Don: "That's what the money is for!"
It captures a lot of the mismatch in perspective between employer/employee boss/subordinate. You're there to do something for someone who is paying you to do it. That's as far as it goes (despite the constant human pull to perceive it as more).
FWIW, even with the "simple explanation," I'll echo OP's statement that the README doesn't really explain what it is or what it's solving. "Generates new versions of the structures" might mean something really clear to you, but even the phrase "data modeling" is enough to trigger lots of conflicting baggage in my head. Also: it took awhile it realize it's for Scala. I initially assumed this was a Smithy-like competitor.
It looks neat (once I found your docs)! Show what it is and what it solves in your README! The structural inheritance is slick.
It's not for Scala. Currently there are Scala and C# backends, TypeScript and Python are on the way.
We did everything to make it easy to add new backends. As much as that can be considering the feature set.
> Smithy
Little bit different. Smithy is more an RPC tool. Baboon is not (or not yet), it allows you to model your data structures and derive conversions (migrations) between versions.
As someone who runs data analyses on experimental data, my first thought that this was a tool to automatically data munge, and perform analyses. My current impression it is a tool to convert database type information structures to new formats. None of these are probably correct.
It destroys the value of code review and wastes the reviewers time.
Code review is one of the places where experience is transferred. It is disheartening to leave thoughtful comments and have them met with "I duno. I just had [AI] do it."
If all you do is 'review' the output of your prompting before cutting a CR, I'd prefer you just send the prompt.
> Code review is one of the places where experience is transferred.
Almost nobody uses it for that today, unfortunately, and code reviews in both directions are probably where the vast majority of learning software development comes from. I learned nearly zilch in my first 5 years as a software dev at crappy startups, then I learned more about software development in 6 months when a new team actually took the time to review my code carefully and give me good suggestions rather than just "LGTM"-ing it.
I disagree. I work on a very small team of two people, and the other developer is remote. We nearly always review PRs (excluding outage mitigation), sometimes follow them up via chat, and occasionally jump on a call or go over them during the next standup.
Firstly, we get important benefits even when there's nothing to talk about: we get to see what the other person is working on, which stops us getting siloed or working alone. Secondly, we do leave useful feedback and often link to full articles explaining concepts, and this can be a good enough explanation for the PR author to just make the requested change. Thirdly, we escalate things to in-person discussion when appropriate, so we end up having the most valuable discussions anyway, which are around architecture, ongoing code style changes, and teaching/learning new things.
I don't understand how someone could think that async code review has almost zero value unless they worked somewhere with a culture of almost zero effort code reviews.
I see your point and I agree that pair programming code reviews give a lot of value but you could also improve and learn from comments that happened async. You need to have teammates, who are willing to put effort to review your patch without having you next to them to ask questions when they don't understand something.
I (and my team) work remote and don't quite agree with this. I work very hard to provide deep, thoughtful code review, especially to the more junior engineers. I try to cover style, the "why" of style choices, how to think about testing, and how I think about problem solving. I'm happy to get on a video call or chat thread about it, but it's rarely necessary. And I think that's worked out well. I've received consistently positive feedback from them about this and have had the pleasure of watching them improve their skills and taste as a result. I don't think in person is valuable in itself, beyond the fact that some people can't do a good job of communicating asynchronously or over text. Which is a skills issue for them, frankly.
Sometimes a PR either merits limited input or the situation doesn't merit a thorough and thoughtful review, and in those cases a simple "lgtm" is acceptable. But I don't think that diminishes the value of thoughtful non-in-person code review.
> I work very hard to provide deep, thoughtful code review
Which is awesome and essential!
But the reason that the value of code reviews drops if they aren't done live, conducted by the person whose code is being reviewed, isn't related to the quality of the feedback. It's because a very large portion of the value of a code review is having the dev who wrote the code walk through it, explaining things, to other devs. At least half the time, that dev will encounter "aha" moments where they see something they have been blind to before, see a better way of doing things, spot discontinuities, etc. That dev has more insight into what went into the code than any other, and this is a way of leveraging that insight.
The modern form of code review, where they are done asynchronously by having reviewers just looking at the code changes themselves, is not worthless, of course. It's just not nearly as useful as the old-school method.
This doesn't deserve to be downvoted. Above all else, code review is the moment for pair programming. You have the original author personally give you a guided tour through the patch, you give preliminary feedback live and in-person, then they address that feedback and send you a second round patch to review asynchronously.
In the beginning, there was the binary, and it was difficult to change.
Then the golden age of ascii encoded source, where all was easy to change.
Now we've forgotten that lesson and changed to ascii encoded binary.
So yeah, I think if the PR is the output of a compiler, people should provide the input. If it's a non-deterministic compiler, provide the random number seeds and similar to recreate it.
> It is disheartening to leave thoughtful comments and have them met with "I duno. I just had [AI] do it."
This is not just disheartening - this should be flat out refused. I'm sensitive to issues of firing people but honestly this is just someone not pulling their weight for their job.
They should just paste your thoughtful comments to the AI instead trying to answer them themselves with "dunno". It's very likely that AI could act on them way more appropriately.
People do. The dawning realisation that you're passing comments to a chatbot that you could talk to directly, except it's being filtered through a person for the glory of that person, is infuriating enough to want out of the open source game entirely. Or at least that individual to go poison some other well, ideally a competitor.
I mean I totally get what you are saying about pull requests that are secretly AI generated.
But otherwise, writing code with LLM‘s is more than just the prompt. You have to feed it the right context, maybe discuss things with it first so it gets it and then you iterate with it.
So if someone has done the effort and verified the result like it‘s their own code, and if it actually works like they intended, what’s wrong with sending a PR?
I mean if you then find something to improve while doing the review, it’s still very useful to say so. If someone is using LLMs to code seriously and not just to vibecode a blackbox, this feedback is still as valuable as before, because at least for me, if I knew about the better way of doing something I would have iterated further and implemented it or have it implemented.
So I don‘t see how suddenly the experience transfer is gone. Regardless if it’s an LLM assisted PR or one I coded myself, both are still capped by my skill level not the LLMs
I’ve noticed in empirical studies of informal code review that most humans tend to have a weak effect on error rates which disappears after reading so much code per hour.
Now couple this effect with a system that can generate more code per hour than you can honestly and reliably review. It’s not a good combination.
One of the surprising things about working inside of $MegaCorp is that if you knock on enough doors, you'll eventually find that each org has, like, one dude* with a spread sheet that powers everything else. Teams will get spun up to try to "automate" this spreadsheet, but, on a long enough time horizon, the spreadsheet wins.
Similar to the author’s cases:
I’ve sat through several presentations of small teams who worked for 6-10 weeks to create a web app that does something (the details vary slightly from case to case) where at the end of the presentation, my first thought is “what a waste of effort and money; that would have taken 2-4 hours if they’d just used a spreadsheet”.
This speaks more to the complexity of web and web development than as a pro of spreadsheets.
You can create a super quick Python app with visualization and whatnot in about the same time as a spreadsheet. But then it's not online. And it's not best practice.
Web is just a fucking beast and then developers go in and add additional complexity.
It would probably be a much simpler web app if you made it just, like, a bunch of PHP scripts thrown in a folder. But they won't do that.
I don't think you can capture the complexity of the world with a single variable. I'm at Amazon. We all make about the same. Some more than me. Some less. However, while I don't have to worry about changing jobs, or _not_ having a job (for awhile), they do. They're working with an entirely different set of pressures and constraints.
For me, I can hop ship, decide I don't like it, boomerang back or take some time off no worse for the wear. That level of autonomy doesn't exist when you've got 60 days to land a job or uproot the life you've been building. Salary is a minor part of the picture. If changing jobs is a gamble that might end in "leave the country," the employer gets a certain kind of "loyalty" that salary cannot buy.
It’s pretty easy to change jobs on an H-1B if you are high skill. I love hearing folks, who aren’t on an H-1B, tell me things like this. Or that I’m paid less when I’m paid more.
I know these abuses happen, no system is perfect. But I feel the bias in the US against H-1Bs from random citizens not from employers. And the government today has quite strong bias against immigrants.
you are the edge case. for you, it is easy to change employers. For a lot of folks, it is not, despite being equally skilled. it is pretty crass to hand-wave away the real risk of being forced to uproot your life because of the risk that your visa may not be renewed.
About 20% of H1B visas go to indian outsourcing firms. You know the culprits here. Are you really going to argue that these firms are not abusing the system and underpaying employees?
> If changing jobs is a gamble that might end in "leave the country," the employer gets a certain kind of "loyalty" that salary cannot buy.
I agree, but on the flip side: the point of applying for an H1-B visa is to come and work for a company in a specialised field. If you're trying to use it to get yourself permanently into a country, then that's the wrong visa type to apply for. I've worked overseas on a visa, and it was stressful for this reason, but I was under no illusions about that when I applied for it.
What other mechanisms are there to move to a country that has a quality of life you seek, and work for a company that you feel excited about? Because that's most of the motivation from the people (like me) that lived in an under-developed country, are qualified, and wanted to work on the top of the industry.
You work a bit out of college, some day you get an invite to an interview from a FAANG, you take the interview, and next thing you know you're moving to another country, working for a great salary, and in a huge company. You do life. You meet people, maybe a partner, maybe get married, maybe have a kid (after all, life doesn't stop). All this while on a temporary status with no easy way to progress out of it other than via time.
I have felt this pressure of not wanting to switch jobs and/or having to be extra careful in order to not put myself at risk of losing it. Specially with the current state of the industry. It has put me (and still does) at a disadvantage with my local peers. I am not saying this is necessarily good or bad, but it is a reality. The 'visa choice' is fictional, and not the most relevant part of the process.
A country doesn’t owe you the right to relocate there, just because they offer the top opportunities in your field or your desired standard of living. At its most extreme, if they decide to make you a b**h to their own citizens à la Qatar, and you take the deal anyways, that’s your own fault
In the case of immigrant workers in Qatar, the deal they're offered very often ends up looking very different from their lived experience once it's accepted and they move into the country to perform the work. If the deal was clearly stipulated ahead of time I'd agree with you.
I similarly half-joke about the same thing. Being "replaced by AI" would be the kick in the pants to finally make a run of it.
In Seattle, I feel like I could get really far on a dumb, single-issue platform: "I will fix the potholes on 1st ave." I won't talk about anything except that. I'll only try to accomplish that. And then I'll leave.
Now is a great time to dive in, though. LLMs take a lot of the syntactical pain out of the learning experience. Hallucinations are annoying, but you can formally prove they're wrong with the model checker ^_^
I think it's going to be a learn these tools or fall behind thing in the age of AI.
reply