> hope some typescript-like "typed shell" becomes mainstream someday
The trouble with trying to invent a new, more robust shell language is you basically just end up re-inventing any number of scripting languages (eg Perl, Python, awk, ...), so you might as well use one of those.
Most regular programming languages aren’t well suited for shells because they have a verbose syntax due to their readability goals. But with a shell, the vast majority of times you’re typing in stuff that you have no intention of reading back ever again.
I’ve done a fair amount of research here and I actually think we do need a new programming language for the shell (and then I created one).
Excellent article, thanks for the link. I do agree with the premise. But every time I write some Bash code and think there should be a better way to do this, I ask myself why I don't just learn Perl. I dunno. Feels like inventing another solution would just hit the old "there are now 14 standards" problem where it would solve some problems but introduce others (see: PowerShell).
If you’re vastly more productive using these alternatives then it would be silly not to use them.
If your colleagues want to reuse the same scripts then they can install the runtime too. It doesn’t mean they need to write all their future scripts using that runtime.
Did someone say... Xonsh?! It's tough to give up the niceties of zsh and it's various plug-in ecosystems, but I would love to be able to use Xonsh [1] as a daily driver for exactly the reasons stated. It is already the language I lean on over bash for most utility scripts with its kitchen sink built-ins.
Powershell syntax is worse than bash argument quoting and it’s half-hearted participation in .Net instead of being designed as built-in makes it annoying to do anything advanced, plus its security defaults are almost never what is wanted to actually get stuff done.
> why? unless cloudflare's CEO is a friend of cloudflare people, so just want to financially them bail out...why acquire and kill?
Aquihiring is a time-tested strategy to build out a team. The Deno folks likely have a bunch of experience that Cloudflare is well placed to make use of
> Unless you dangle HEFTY stock options with incremental maturity dates
That is indeed how this whole thing works. I used to work with several folks who were kicking around FAANG for 4 years till their acquisition stock fully vested
When you consider how much time/money it takes to hire an experienced engineer, and how quickly they are liable to jump to the competition, acquiring an existing team of experienced engineers and tying them with the golden handcuffs is not a bad deal
If the talent wanted to work at Cloudflair, they'd apply there. Being acquired is a loss of agency and the project you care about is shut down. Several public research papers say retention is hard.
Which also leads to considerable questions about if the thing being shut down in the acquirehire was the real purpose and any momentum of the team itself moving to new projects a bonus.
that just means they might not be actively looking to join cloudflare but are willing to do it if the price is right. nothing wrong with that, it's how employment works for the most part. likewise retention in these cases is typically solved via golden handcuffs, another "the price is right" thing.
> methods for using the level change every week or so
hmm doesn't mean noob will become better? if what I'm "learning" about AI is going to get deprecated every week... then it doesn't make sense to "keep up"
Here's how I think about it. There's two different things "knowing how to use AI effectively" and "knowing how to leverage effective AI to improve your project".
1. Both are multipliers on skills you already have. A "noob" will be at a disadvantage.
2. The second one is a complex blend of technical skill, domain knowledge and human factors (knowing your user-base, knowing your product/project, understanding UX/DX/whatever) that you probably will always have an edge on.
No decent engineering firm is going to want to work with FBX or Blender files. In fact they probably wouldn't even know what to do with them. Even proper model formats such as STEP files don't give you the details that are on a drawing that you actually need to do anything useful with these.
I’ve only dabbled with cad for 3d modelling in Onshape. It seems that there all kinds of ways to add measurements in the render files. Not sure about blender.
MBD is a thing, however that doesn't really matter here, for making accessories you can more or less just assume all dimensions are perfect since you need some compliance for the accessory to be installable. What I'm talking about that can't be encoded in a model easily are things like the keepout area for the camera.
The reason you don't want Blender files at all in any sort of engineering is because it's a mesh. You can't pull any useful information, even something simple like a radius, from a mesh.
sometimes, its footguns seem worse than javascript...
hope some typescript-like "typed shell" becomes mainstream someday
reply