I’ve seen this same thing happen with Python’s type hints. Turns out giving an “escape hatch” type for devs who have no clue what the type actually is leads to a lot of useless type hints.
Yeah, it’s especially bad, when a library doesn’t provide type hints itself. It can be comically difficult to find out what the return type of a function is, because every if-else-branch might have a different return value, so you may need to read the function body in full to figure out what the type might be.
Add to that, that lots of the tooling around type hints isn’t as fleshed out / useful as it is in fully typed languages and I can definitely understand why someone might not immediately feel like it’s a valuable use of their time.
Toner’s role is being underplayed by the video. She’s potentially calling Altman out, for underrating the dangers of AI.
At least Altman is lying about something - about how much OpenAI is going towards AGI in the short term. The above might’ve bought the bullshit fully, while Sutskever knows that it’s bullshit.
I’m not sure if the board is also lying or not.
The boiling point was likely OpenAI potentially receiving some cash grant from some scummy party, that would be in a moral grey area considering the "non-"profit goals of the company.
Everybody will get a bit more of free popcorn for a while. 🍿 This mess is far from over.
I read in a different post that the code was misinterpreted to be a 5 second sleep before showing the video, but instead was waiting 5 seconds to execute some anti-ad-block script. Still pretty sleazy either way.
There’s a video going around of a guy using a useragent spoofer to prove that it only does this on non-Chromium browsers. So I don’t think it’s necessarily anti-adblock, but it could be interpreted that way when you consider Google’s plans to implement DRM in Chromium.
When I went rooting around to find it. I figured it was some QA process that starts 5 seconds after the video loads (the timer seems to be async and the code sends a promise off while it waits). Of course, it’s all minified JS so it’s a huge pain to read.
my website’s backend is made with bash, it calls make for every request and it probably has hundreds of remote arbitrary code execution bugs that will get me pwned someday, it’s great
edit: to clarify, it uses a rust program i made to expose the bash scripts as http endpoints, i’m not crazy enough to implement http in bash
it behaves like a static file server, but if a file has the others-execute permission bit set it executes the file instead of reading it
it’s surprisingly nice for prototyping since you can just write a cli program and it’s automatically available over http too
i thought it was neat how php lets you write your website’s logic with the same directory tree pattern that clients consume it from, but i didn’t want to learn php so i made my own, worse version
I’ve taken some precautions, it’s running in a container as an unprivileged user and the only writable mount is the directory where make writes rendered pages, but i probably should move it into a vm if i want to be completely safe lol
I know about the CGI standard, but mine does things a little differently (executable files don’t just render pages but also handle logging, access control, etc. when put in special positions within a directory), so I still think it was worth the afternoon i spent making it.
I’ll be sure to tell my boss to throw away all the work he already paid for and start over in a different language. I’m sure he’ll be very understanding
I don’t think you understand the concept of having a boss.
Earlier this week I proved to him that his new “more secure” password policy results in passwords that can be cracked in under a minute, and he didn’t care
Sneak in a library that makes things more sane when nobody is looking…
Also, that isn’t “having a boss” it’s having a shit boss. As an engineering manager I am happy to go to bat and make excuses for time my reports spend paying down technical debt and making things more maintainable (within reason of course, and if shits really bad I can usually sneak a sustainability project into the timeline).
We’ll always need to make some compromises for our workplaces, the perfect job doesn’t exist, but what you described is a huge red flag. You deserve respect at work.
Yo nodejs is just plain amazing. We should just keep improving on js and replace all other languages. Js is already on all browsers, by adopting it on the server you get huge efficiency as you can move code AND coders between backend and frontend. Of course you must make the right choices of practices and frameworks for this to be possible
Both Monday and Sunday are used as the first day of the week with quite some regularity. It’s a completely arbitrary standard no different to "the tenth month is the one called “October”. Or dividing a day into 24 segments which are each broken into 60 smaller segments of 60 even smaller segments. You can’t say either is “wrong” per se.
Personally, I was brought up learning Sunday is the first day of the week, but at some point decided that was bullshit partly because it’s the week end. But also just from a practical standpoint when looking at a calendar, it’s useful to have the weekend days grouped together.
Funny thing, september comes from the number 7, october from 8 and november and december from 9 and 10, as the year in ancient rome was starting around march. This problem is timeless.
Huh. I knew about the problem (that’s why I used October as my example, rather than, say, February), but I was mistaken as to the cause. The way I had always heard it told, September–December don’t match their current place in the year because of the addition of July and August. But I just looked it up and it seems you’re right. Those months are merely renamings of Quintilis and Sextilis, and the numbering issue comes from moving the start of the year from March to January.
JSON for serialization all the way. It’s simple and to the point. It does one thing and does it well. There’s little room for annoying surprises. Any JSON can easily be minified and prettified back and forth. If you want it in binary format you can convert it to BSON.
Yaml is too much of a feature creep. It tries to do way too many things at the same time. There are so many traps to fall into if you’re not cautious enough. The same thing can be written in multitudes of ways.
I would review it and immediately tell them to break it into bite sized PRs.
My coworker kept doing that. We had several talks about it. Other members of our team had talks about it with them, and even our manager. Finally, I marked the PR as needs work, told them to break it into several PRs. They weren’t happy, but I was tired of dealing with PRs that were 30+ files, unrelated in change, and over 1500 lines of code changes. They were pretty mad at me for a while. But it stopped shortly afterwards.
It shouldn’t take more than an hour to review a PR.
If this is a breaking change to a major upgrade path, like a major base UI lib change, then it might not be possible to be broken down into pieces without tripping or quadrupling the work (which likely took a few folks all month to achieve already).
I remember in a previous job migrating from Vue 1 to Vue 2. And upgrading to an entirely new UI library. It required partial code freezes, and we figured it had to be done in 1 big push. It was only 3 of us doing it while the rest of the team kept up on maintenance & feature work.
The PR was something like 38k loc, of actual UI code, excluding package/lock files. It took the team an entire dedicated week and a half to review, piece by piece. We chewet through hundreds of comments during that time. It worked out really well, everyone was happy, the timelines where even met early.
The same thing happened when migrating an asp.net .Net Framework 4.x codebase to .Net Core 3.1. we figured that bundling in major refactors during the process to get the biggest bang for our buck was the best move. It was some light like 18k loc. Which also worked out similarly well in the end .
Things like this happen, not that infrequently depending on the org, and they work out just fine as long as you have a competent and well organized team who can maintain a course for more than a few weeks.
The follow on. Lots and LOTS of unrelated changes can be a symptom of an immature codebase/product, simply a new endeavor.
If it’s a greenfield project, in order to move fast you don’t want to gold plate or over predictive future. This often means you run into misc design blockers constantly. Which often necessitate refactors & improvements along the way. Depending on the team this can be broken out into the refactor, then the feature, and reviewed back-to-back. This does have it’s downsides though, as the scope of the design may become obfuscated and may lead to ineffective code review.
Ofc mature codebases don’t often suffer from the same issues, and most of the foundational problems are solved. And patterns have been well established.
That’s seems awfully short no? We’re talking a couple hours of good flow state, that may not even be a full feature at that point 🤔
We have folks who can push out 600-1k loc covering multiple features/PRs in a day if they’re having a great day and are working somewhere they are proficient.
Never mind important refactors that might touch a thousand or a few thousand lines that might be pushed out on a daily basis, and need relatively fast turnarounds.
Essentially half of the job of writing code is also reviewing code, it really should be thought of that way.
(No, loc is not a unit of performance measurement, but it can correlate)
To be honest, I agree they should be able to be larger at times.
I had a lot of disagreements when I was on a new codebase, knew what I was doing and I was able to push a lot of code out each day.
The idea is to have them small, easily readable with a tight feedback loop. I argued that bootstrapping a project will have a lot of new code at once to lay the foundations and my communication with the team was enough feedback. If I split it up, each PR would have been an incomplete idea and would have garnered a bunch of unnecessary questions.
That said, I think it’s generally pretty easy to put out multiple PRs in a day, keeping them small and specific. As you say, half of the job is reading code and it’s nicer to give my coworkers a set of PRs broken down into bite sized pieces.
How’s it annoying? It’s easier to edit by hand than json as it allows for comments and there’s no trailing comma errors. I prefer it any day over json.
It’s just another syntax to learn. For someone who already has their head crammed full of a bunch of other syntaxes over the years, I didn’t want to learn a new one. YAML has kind of forced it’s way in anyways though.
There’s a lot of foot guns in YAML. The specification is way more complicated with hidden obscurities. JSON specification is just 5 diagrams. YAML speciation on the other hand is an 86 page pdf, so there’s more room for nasty surprises (which is not a thing you want in configuration files).
I’ve also seen many people struggle more than they need to with the yaml indentation.
I think the only upside to yaml is that it allows for comments, but other than that JSON all the way.
not at all. it’s used for configuration and stuff. having a lot of it can be a real bummer depending on the context. like a puppet config or perhaps a super weird docker compose setup. I’ve never heard anyone complain about the markup though. it’s like blaming json for a crap api or something or idk blaming the coffee cup for burnt coffee 🤷
It’s just another structured data format. It’s used for a lot more than config. It’s also how you define commands and etc for Ansible. Like how a Maven project is defined in XML or a NodeJS package has its JSON.
Sure they’re still “just” data formats on their own, but what they’re used for is genuinely just as important as what it is. I really doubt XML would’ve held on like it has without HTML being the web.
For some little config it’s fine, but it’s horrible when used when you have thousands upon thousands of lines of it. Lots of DevOps tools tend to use it like a fully-blown turing-complete programming language, and each has a different DSL of doing variables, loops etc. And that becomes an abomination.
I honestly think that JSON and YAML should be swapped due to YAML’s strict indentation rules whereas you can just pack an entire JSON object on one line.
Oh this is a good point - the syntax error on line one has ruined several productive days.
Of course the tool would happily prettify it for me, but it has to be valid json. Which I think would make it more enjoyable if it said in that message “Good luck, we’re counting on you.”
I think yaml’s need for indentation alone makes it chaotic evil. I’ve seen so many people struggle with the indentation than they really need to it’s not fun. Especially problematic with large configuration files.
JSON is easy to unpack with tools like jq or whatever.
There are 6 different combinations of “interpret multiline whitespace” character patterns. There are three types of single-line strings, and if you use “Yes” or “No” the data gets type cast.
Just because there are a lot of rules doesn’t make something chaotic in this system. The lawful-chaotic axis is a spectrum of how much of a stickler for the rules you are. YAML’s “one whitespace out of place and your whole config is fucked” attitude puts it squarely into lawful territory. JSON by contrast gives no shits about your file structure as long as your curly braces match.
I just learned yesterday you can do this, lol. You can use “//”: ‘’ once at the root level of a package.json file.
Had to put an override to block a dependency of a dependency from installing (@types/* stubs when the package now has native type defs that conflicted with the no longer maintained stubs).
Also where’s regex? Though that’s so troublesome because it’s a process encoded in a string, not really a structure with debatably obnoxious syntax… hmm
There are plugins that go back and forth between JSON and YAML so as you might expect it’s similar. Unlike JSON, spacing has semantic meaning, which can be a little annoying, especially when cutting and pasting. It’s nice in that configs aren’t cluttered up with open and close braces. It could be annoying AF if you’re a tabs instead of spaces person but idk because I’m a spaces person.
I like YAML for config over .config files but it’s not a big deal either way. It just encourages better organization of settings because the hierarchical structure demands it while .config let’s you just drop a setting anywhere in the file. But it’s valid to have the opposite preference for the exact same reasons.
The problem is that the current fashion of devops is done through piles and piles of badly defined YAML. If it used any other configuration language, it would be just as bad.
There are thousands of sci-fi novels where sentient robots are treated terribly by humans and apparently the people at Boston Dynamics have read absolutely zero of them as they spend all day finding new ways to torment their creations.
People think I’m crazy for apologising to my roomba when I trip on it and for saying please and thank you to Alexa and Siri, but I won’t be surprised at all when the robots rise up, considering how our scientists are treating them. I’ll have a track record of being nice, and that has to count for something, right?
Those are just brainless bodies, currently. They don’t have sentience and have no ability to suffer. They’re nothing more than hydraulics, servos, and gyros. I’d be more concerned about mistreatment of advanced AI in disembodied form, something we’re dabbling potentially close to currently.
I disagree. I care greatly about not mistreating anything with consciousness and worry of where that line is and how we’ll even be able to tell that we’ve crossed it.
I also recognized that a machinized body without a brain is exactly that - a cluster of unthinking matter. A true artificial intelligence wouldn’t be offended by the mistreatment of inanimate gears and servos any more than I would be. The mistreatment of an intelligent entity, however, is a different story.
Food for thought, though: we thought the same thing about all other animals until only a couple of decades ago, and are still struggling over the topic.
…Just no. Animals are complex organic beings. Of course, we don’t understand them. Machines, though? We built machines from the literal Earth. Their level of complexity is incomparable to that of anything made by nature.
Now, take a sufficiently advanced neural network that’s essentially a black box that no human can possibly understand entirely and put it inside of that machine? Then you’re absolutely right. We’ll get there soon, I’m sure. For now, however, a physical robotic body is just a machine, no different than a car.
Yes they are. We’re now learning many animals are just as emotionally developed as we are, with well-developed empathy and complex social lives. We don’t like to believe that because we eat most of them and that makes us feel bad, but it’s true.
Research animal psychology and sociology a bit and it will blow your mind.
The annoying thing is, when it’s happened it’s been like a day’s work tops. Making your initial declaration of “can’t be done without rewriting all of it” look very silly.
It usually involves working backwards from unholy abomination the sales team, your manager and the customer fucked into existence between them, and just find out what problem the customer actually wants solving.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.