It has two! — http.client and urllib.request — and they are really usable.
Lots of people just like requests though as an alternative, or for historical reasons, or because of some particular aspect of its ergonomics, or to have a feature they’d rather have implemented for them than have to write in their own calling code.
At this stage it’s like using jQuery just to find an element by css selector (instead of just using document.querySelector.)
Sure historical popularity is a good reason for people who are already familiar with it to keep using it.
That is not really an excuse for why the standard library docs for the clients you mentioned link to requests though (especially if they were actually good, rather than just being legacy). If they really were good, why would the standard library itself suggest something else?
Teachers are there to observe and manage behavior, resolve conflict, identify psychological risks and get in front of fixing them, set and maintain a positive tone (“setting the weather”), lift pupils up to that tone, and to summarize, assess and report on progress.
They are also there to grind through papers, tests, lesson plans, reports, marking, and letter writing. All of that will get easier with machine assistance.
Teaching is one of the most human-nature centric jobs in the world and will be the last to go. If AI can help focus the role of teacher more on using expert people skills and less on drudgery it will hopefully even improve the prospects of teaching as a career, not eliminate it.
I’m sorry to read this — it just doesn’t feel grounded in my own lived experience.
Many of the best Engineering and Computer Science departments, around the world, operate a revolving door for people to go in and out of industry and academia and foster the strongest of relationships bridging both worlds.
Look at Roger Needham’s Wikipedia page and follow his academic family tree up and down and you’ll see what I mean.
Miniature, in-line sh scripts are also fine as long as you use the provided parameter substitution.
If you’re averse to this:
q(“select x where y = ‘“ + v + “‘“)
And instead do this:
q(“select x where y = %s”, v)
Then you should be averse to this:
x(“foo --option ‘“ + v + “‘“)
And instead do this:
x(‘foo --option “$1”’, v)
This is particularly useful when it’s expedient to have one thing piping into another. Like it or not the sh DSL for pipes is excellent compared to doing things natively with execve() and pipe(), just as doing group by and count is far more concise in SQL than doing so natively.
Most SQL libraries give you something like q. Writing your own x is as simple as calling sh correctly. In Python, for example:
Neither of those are equivalent to variable binding, which is what most SQL libraries provide, specifically because they don't actually solve the problem since they're still doing string substitution. Putting a double quotes in $1 in your "good" execute example will allow you break out of what's expected and then you're Bobby Tables.
Your python example at the bottom is correct, in that each separate element is more correct in that it allows each arg to be passed as an element, so there's no option to break out through quoting characters. SQL binds are like that in most ljbraries, even if they don't look like it. The parser knows a single item below there so if it passes it along as such. You cannot escape it in the same way.
That requires you quote the param in the sintr to ensure that params are groups as expected. E.g.
# cat pvars.sh
#!/bin/bash
echo "\$1=$1"
echo "\$2=$2"
echo "\$3=$3"
# sh -c './pvars.sh "$1" $2 $3' -- 'a b' 'c d'
$1=a b
$2=c
$3=d
The whole point of passing in an array and using something like exec (or system(), if provided as it handled the fork and wait for you) is that you avoid the overhead of the shell starting up at all and parsing the command line, and it lets you define each param exactly as needed since each param is its own array item. You don't need to worry about splitting on space or the shell splitting params on space, or quoting to group items. If you want the param to be:
foo "bar baz" quux
as one singular parameter, you just make that the contents of that array item, since no parsing need be done at all.
If you have an array of params and you're jumping through hoops to make sure they're interpreted correctly by the shell you call execute a process, you're likely (depending on language and capabilities) wasting both cycles and over complicating the code when you can just call the program you actually want to execute directly and supply the params. Alternatively, if you have all the params as one long string and you want it to be pased as a shell would, then execute the shell and pass that as a param. e.g.
# perl -E 'system("./pvars.sh","a b","c d");'
$1=a b
$2=c d
$3=
# perl -E 'system("./pvars.sh","a b","c","d");'
$1=a b
$2=c
$3=d
Thanks for explaining. I feel like we’re talking past each other but it’s my mistake. I should have said it is only useful (not “particularly useful”) if one has compound statements like a pipe or multiple commands. Invoking sh just to run a single command is superfluous and you are right that reaching directly for execve() is better.
Ah, yes. If you want to take advantage of piping commands together through the shell as a subcommand of your program, then a way to make params behave more consistently regardless of content is useful.
The Dream Machine from Cockroach and of course The Neverhood from Doug TenNapel are some fantastic prior art here. TenNapel even reused his skills to make Armikrog two decades later.
I wonder if the creators of these physically rendered games ever get together to talk shop, or even host a conference, on the topic of non-linear animation and storytelling. It’s the sort of thing that I, as someone who merely consumes their content and is absolutely nowhere near being able to replicate their skill, would love to take part in.
Comic-Con but for games done the hard way. Thimbleweed Park, another remake in the animated adventure game genre, actually has a scene in it that’s based on a conference for real-life point-and-click games developers.
Hylics by Mason Lindroth is the only other thing I'd ever seen do the "physical art" thing in a videogame. I love it a lot, so now curious about the other games you've mentioned! Thanks for the recs.
With respect to Doug TenNapel’s contribution to the field, Armikrog is only of interest I think to die-hard nostalgia fans. Maybe one day it will be (or already has been?) remastered into an even better game, but when I played it on release it was more like a mise en place of a great meal than a great meal itself.
The Dream Machine is all out body horror excellence from an indie studio in the truest sense. The fact that they saw the project through to the end, in real time, over the course of several years and while communicating the whole time with their Kickstarter backers is just as impressive as the game itself. Pure brilliance.
Harold Halibut isn't stop motion at all; they made physical puppets and then scanned them into Unity and tried to replicate the look.
It's a gorgeous game, but I was really disappointed in the gameplay. I wouldn't even call it a game; it's basically a movie where you sometimes interact with things, but everything is scripted.
Edit: although maybe there's a good idea: catapult or winch launch for electric aircraft would massively reduce the power and energy storage requirements to be carried onboard.
Being constrained to a ship makes things harder though. If it was simply very long (runway length), I reckon an abort would be fine. There are probably a lot of different ways to do it.
But yeah, much harder than a regular runway. Probably not economical.
Considering how thick fast charging cables for cars are, I don't think it will fly, literally. We could make the cables thinner with high enough voltage I guess. But then we would actually need two wires with proper separation, because unlike with trains, you obviously can't use the ground for the return path. Loose high voltage wires may be a safety problem too.
By comparison glider launch wires are quite thin and light.
A lot of people will agree with you and a lot of people will disagree with you because the subject might as well be food and for some people that’s coleslaw and for others that’s master chef.
Both have their place. On the topic of greatness (your example, Linux, as opposed to say a build script for vending machine firmware) I couldn’t agree more with both you and the people disagreeing with you.
For me, the hacker super power — the one worth carrying forward as you progress in leadership — is being able to prototype something that works and proves a concept.
Realistically, a proof of concept is also only 20% of the work an engineer needs to do in order for a change to become production worthy and I respect that my sketched ideas need a lot more care and craftsmanship than I have time to give them. Where I can help other ICs is having that initial 20% idea around which they can then build a working idea, and do so autonomously.
It feels very cringey to write — oh brave new world that has such people as me in it! — but I can easily reassure myself by remembering all the times earlier in my career where I was very grateful to be initially pointed, with quite a lot of prompting, in a particular direction and then being given the chance to deliver on it.
I’m just a lead, but I can imagine part of being a CTO takes the same form as what I’ve described.
Someone once said that looking for a ship on the ocean is like trying to find your car keys in a field with a pair of binoculars.
Obviously this applies less to littoral waters (1.5 dimensional instead of 2 dimensions of open water) but still: how does scale factor into trying to task sea drones with hunter/killer roles?
Also, always worth pointing out that while tactical warfare is a technological battle — in which drones may indeed be superior — war is also a strategic, political act and as such the presence of large scary ships — even 250t ones — is often enough to achieve ones strategic aims.
Love that analogy. But on the topic of your final point - I agree with you, but I do think we're rapidly approaching the era where ships of this size will be difficult to defend from a mass drone strike, easily coordinated via a combined air/surface/submerged drone swarm.
At that point, the asymmetric reward of sinking one of those large scary ships is going to be irresistible for both state and non-state actors, specifically for those same strategic and political aims.
Or they just use Phalanx-like [0] close-range defensive aid suites which already exist?
Sure, that will consume a lot of bullets but swarms of defensive kamikaze drones will also get used up and need resupply. In which case the resupply ships themselves also become high-value targets.
I thought the Phalanx was exactly the type of defense system that drone swarms were more or less designed to penetrate. Sure, it can put out an unreasonable amount of lead (tungsten? uranium?) downrange but the number of disparate targets it can engage per second is actually quite limited. It's vulnerable to being swarmed.
I agree that a Phalanx can be swarmed but I'm having problems envisaging drone-on-drone attritional combat involving a capital ship lasting for vey long. If you (capital ship owner) are attacking a peer state it can probably afford to swarm you repeatedly over several days also throwing in plenty of additional standoff missiles, perhaps something ballistic, a sub or two, probably others I haven't thought of.
You'd probably get away with it handling intermittent Houthi attacks in the Red Sea but in a serious war I think the logistics would get you in the end.
There are multiple different drones. I bet phalanx will do nothing against small 10" drones which can target communications and sensors of the ship in a first wave. And second wave could have much heavier payload to target ship's structure
The person you're responding to basically says that “big ships won't be cost effective against small droneship” but they fail to realize that these “small” droneship themselves must be pretty bulky if they want to carry a warhead big enough to destroy a big ship at long distance, and they will be pretty cost-effectively be dealt with by much smaller kamikaze drones that will be protecting the big ships.
> Someone once said that looking for a ship on the ocean is like trying to find your car keys in a field with a pair of binoculars.
That is true if you try to look for a ship visually. But nobody would do that. Everyone uses radar. The radar can be mounted on the shore, on a rig, on a ship, on an airplane, or on a satellite.
Or you use underwater microphones. Those can be mounted on the ocean floor, or a ship, or a submarine.
Neither of these share much with looking for your car keys with a pair of binoculars. The keys don't emit sound and the field does not transfer the sound as well as oceans do it. And the keys don't light up as nicely as a ship on a radar image. So i'm not sure what aspect of maritime surveillance does that saying illuminate.
Just based on the wikipedia page it doesn't sound like it was lost?
"After the ship's seizure the Malta Maritime Authority stated that the security committee—composed of Maltese, Finnish and Swedish authorities—were aware of the ship's ___location at all times, but withheld the information to protect the crew."
Certainly a murky situation but doesn't feel like it demonstrates the complexity of finding a ship. Sounds like right away once someone wanted to find the ship they could find the ship no problem. Presumably using Synthetic Aperture Radar satellites and then the frigate's own radar.
> how does scale factor into trying to task sea drones with hunter/killer roles?
The Black Sea is a good example of how that went down; using US intelligence - could be sattelite imagery, radar, or a combination thereof - they were able to pinpoint the Russian ship(s), giving their drone ships enough guidance to head there. And as long as there's no signal jamming, it could be remote controlled to its final destination if needs be.
Lots of people just like requests though as an alternative, or for historical reasons, or because of some particular aspect of its ergonomics, or to have a feature they’d rather have implemented for them than have to write in their own calling code.
At this stage it’s like using jQuery just to find an element by css selector (instead of just using document.querySelector.)