this is a hilarious take. It's certainly more serious for their customers, but is it more serious for the responsible parties (the board of directors)? It seems clearly not.
You know 'enough money to live very very very well' isn't enough for people who climb to the top to be on the board of such of a corporation. They care just as much about reputation, further ability to work to make more money, and more money.
> Do you have their names memorized? If you met one dining with their family at a country club, would you know what they did?
> Their personal reputations are still largely intact.
Well person who would be attending country club would know that they raised shareholders value and more than likely helped to them to gain X millions of Dollars.
I don't think the main problem backend developers have with frontend work is the language. As you say, Typescript is a really good language - in many ways better than Python. I don't think it's even the tooling, although becoming basically competent with two very large tooling stacks is not a trivial matter either.
I think there's a fundamental verbosity to the way most SPAs do data management - I've seen it said elsewhere that when you build a SPA, you basically end up having to reinvent the database, by which it is meant that an inordinate amount of your code is dedicated to extracting data from the backend via an API and then keeping track of that state using mountains of front end code.
At some point, you have to decide - is this really two separate applications (a backend and a frontend), or is it actually just one? If you don't have a need for multiple different clients, and you already have a backend written in Python (or some other backend language, e.g. Elixir, Kotlin), then maybe you can get away with writing a whole lot less code if you can find a framework that fills in that whole in-between layer for you and lets you stick with the language you already have.
Ah! A real criticism of FE development, I agree with your problem statement.
When you jump into the world of single-page applications, things get complex pretty quickly, because the use case for needing an SPA pushes the web app into a full desktop application.
Ultimately, for a highly interactive and dynamic "desktop-class" user experience, there is added complexity. I think that's why so much movement within the FE world has moved away from "SPA for everything" and into these mixed dynamic apps. Islands, React Server Components, NextJS, they all help create a middleground between a document-based website with no dynamic elements with a full blown desktop app experience. They all have real tradeoffs, in particular adding an entirely new backend service to serve the front end.
For many projects, react + react-query is probably enough.
Having said that, my argument from https://bower.sh/dogma-of-restful-api still stands: when you build an API that is RESTful (1:1 mapping between endpoint and entity) you are unknowingly pushing the complexity of data synchronization to the FE, which requires a well thought out ETL pipeline.
This probably doesn't help my case but I've been building a simplified middle-layer for react to bridge the gap between react-query and full blown SPA: https://starfx.bower.sh
an interactive shell really _doesn't_ need to be interoperable between users in the first place, but even a scripting shell doesn't need this either.
This is what the shebang in your scripts is for. If you need to write a script that is going to get shared, you have (at least) two perfectly good options:
- use bash (or some lowest common denominator)
- use a fancier (better?) shell, like fish/xonsh/nushell/oil and just require that everyone have that shell installed (they don't have to use it as a daily driver).
xonsh is not really any different from other shells - it can be installed as an isolated environment with its own runtime (in this case Python)
A third and usually better option is to use a dedicated scripting language - this is of course an opinion, but many people have recognized that anything longer than ~50 lines and that will need to be iterated upon in the future is a bad fit for a shell-like language.
based on the article, it doesn't sound like this has anything specifically to do with temperature - the issue is more about whether there is moisture in the air.
If it were just a temperature thing, you'd think it could be automated, but I don't think that's really the main thing they're dealing with here.
In theory this means switching the system off when you exit the clouds.
This is usually pretty noticeable, but maybe less so at night, since you might be breaking out into a pocket or a clear layer between other layers, without visibly seeing much of anything outside.
I would hesitate to comment on the feasibility of this beyond what the interviewed persons have said, precisely because they're not clarifying (to the readers in any case) what the actual thresholds here are. And the interviewees don't seem convinced that this is a reasonable/safe requirement.
i think the concept of "source code as AST" or something like that is basically a fine one, but the devil is in the details. your "true source" must continue to support (just off the top of my head):
- precise "decompilation" to readable, idiomatic text
- comments
- line numbers or some semantic equivalent
The goal should be to store the inputs the user has provided. If your no code solution uses png files to encode the input, then store those, not an intermediate textual representation of them.
but would they have liability if they submitted their "output" to a senior artist, who immediately shot it down as obviously infringing? Surely not. It's not illegal to draw Mario - just illegal to make money off your drawing.
I think the real question is whether OpenAI should be allowed to charge for generating infringing content. Even though the unit cost of the Mario drawing is negligible, the sum total of their infringing outputs may be making them a lot of money.
>I think the real question is whether OpenAI should be allowed to charge for generating infringing content.
Well, are they really doing that?
If I rent a server to host a minecraft instance, is the company "charging for a minecraft server"? It is not clear to me that by charging users for AI usage they are complicit for whatever is generated. We don't require Adobe to prevent people from drawing Mickey either.
there are a lot of interesting legal questions here, but surely in the Adobe/Mickey case, it's the user's input that's infringing. In the examples provided here, the user's input is obviously not infringing, so that leaves... the model's output?
you don't have to make money off it, you just can't publish it, except as a parody or commentary or possibly a tutorial on how to draw mario if the judge is having a good day
but "making money = infringement" is folk wisdom. you could certainly say making money attracts attention and increases likelihood of legal action
Making money off it doesn't just draw more attention, it also makes a fair use defense harder. Non-commercial use isn't necessary or sufficent for fair use, but it does help.
yeah, I appreciate this clarification. "publishing" seems like a nebulous concept to me and the general act of publishing something rarely seems to be what draws the attention of the lawyers (whereas making money seems clearer-cut).
So I suppose the question will hang on whether OpenAI is "publishing" if it returns similarly infringing results for the same prompts, even though those results are individually generated for a given user query.
I don't think we had many, if any, disputes about whether anyone had been tagged, even without the belt flags.
I love the "ball flag" idea.
reply