BiteCode_dev

People didn't know there was a fertile land of the other side. Just like we don't know if there is a good thing that will come out of mars. We just know the constraints.

It's not about what you know is there. It's the potential.

There is no point for Usain Bolt to run that fast. There is not point in building the tallest tower in the world once again.

Meanwhile, the mars goal already managed to bring us spaceships that land and divide the cost of putting satellites in orbit by 10.

No other path lead to it because there was nothing to motivate it enough.

I'm sure leaving a fertile land 100 000 years ago, crossing the desert on foot, having most people die in the process, not knowing if they was an end to that sand, felt the same.

Why would you do that?

Two centuries in the future, the benefit of going to mars will be obvious, because we will have progressed and gain things we don't know about now.

That's how humanity works. We try crazy stuff. And a lot of it is stupid, expensive and dangerous. Plus the result is disappointing.

But eventually something pays of big time.

And everybody says of course we should have done it retrospectively.

It's like people asking why we are still making purely theoretical math research. Surely it's no use, and it's expensive.

I have no doubt many people opposed to the moon landing as well on those grounds.

I expect fully the comments to answer "but this time it's not the same because...". But it's never the same.

It's always a different situation. That's the point.

That's what discovery is about.

Do you target big projects with heterogeneoud team ?

Is that the problem it's trying to solve?

Auth is included in your stack, e.g: django comes with it.

Plus you own the accounts, so you are not locked in.

Sync is the firebase kill feature, but most apps can live without it.

Managed services still require engineering efforts. I have never seen a transition to a cloud service that actually didn't end up requiring a new hire.

It's the dirty little secret of our industry.

Everytime I mess up a password, I click the "eye" button to reveal it if I'm alone, so it will likely go into the screenshot.

I type totp code that will be valid for 2 minutes, and they are clear.

I have emails, account numbers and emails.

I have contacts of my network, sites I visits regularly and nick names I use. Sometimes I paste sensitive content in encrypted chats, but hey, now they are in the screenshot.

Then there are nude pics of partners, intimate journaling notes, porn activity, how much I have in the bank, contracts with clients under nda, legal and illegal drugs I order, political alliances, and all the stupid stuff I may do...

All that conveniently centralized and searchable.

You can only grant something you have the rights to, so basically, they are asking you to do something you can't.

I don't have the rights of my client's product.

I want to see how it plays in court.

While trying to figure out why VSCode was hogging my file watchers, I came around this nice inotify explorer

You do need to compile it but it was easy enough, and it helped with figuring out my issue when my bash-fu failed me.

Honestly now with chatgpt, matplotlib terrible API is less of a problem.

In stawberry you make a method per field you want to retrieve, I would say it is indeed more complex and costly.

Sure but queries are crafted in the client, that may know nothing about this, while a rest api, the requests are restricted and the queries are more likely under control of the server, which mean the backend will likely decide what fetches what and when.

It takes a lot of work to actually ensure all possible combinations of graphql params hit exactly what you want in the backend, and it's easy to mess with it in the frontend.

But you actually don't need to keep modifying the REST endpoints for most projects, that's what everybody is saying.

The vast majority of projects don't gain anything from this flexibility, because you don't have suddenly a 1000 of farmvilles copy cat that need their own little queries. You just have bob that need an order by.

But then what's the point of using it if it's to get the limitation of REST?

You get something more complex, more expensive to maintain, consuming more resources, and configure it to basically be REST with extra steps.

I stand corrected, I'm the one with a distorted memory of the doc.

The simple fact you say

> React has always had good documentation

Tells me you rewrite the entire history.

In fact, for years, react didn't even tell in the doc you could use it without a transpiler so people had to learn a whole build chain before even getting to the hello world.

At this stage it's not "superficial understanding of the space" this kind of comment is guilty of, it's total denial.

And by the way, we have been doing components for UI way before react was a thing. jQuery could do components. Backend frameworks could do components.

As for immutable data, I've seen more small projects die from the small cuts of trying to maintain that purity that I've seen those exploiting the benefits like free time travel.

I assume you've been living HN bubble for too long.

You can do plenty of stupid stuff at a friend's home, in a forest, in a quiet street...

Unless you live in India/China, there are plenty of places where you can get privacy, and kids look for them.

Do you think they have sex in public?

Ah but that's the beauty of GraphQL, a query can actually fetch data from several systems: the db, the cache, the search engine, etc. It's all abstracted away.

But let's say you have a timeout, and they have a retry, then suddenly, your server is now spammed by all the clients retry again and again a query that worked a week ago, but today is too heavy because of a tiny change nobody noticed.

And even if it's not the case, you can now break the client at any time because they decide to use a feature you gave them, but that you actually can't deal with right now.

React was a blessing for the few creating apps that needed more than jquery, and that AngularJS 1 couldn't handle for perfs reason.

That was actually a very small parts of the projects in the world at the time, and in fact, a very small part of the number of projects that adopted react at the time.

I remember above all that:

- React was hyped to the roof by facebook. They had a fantastic marketing machinery for that.

- React sucked for years, with a terrible doc, a crippling webpack experience and breaking compact all the time.

- The JS community was moving from koolaid to koolaid, never assessing the new tech for their cost. They solely inflicted on the world slow and brittle preprocessors left and right, thousands of stuff you had to integrate manually because "libs > frameworks", and jumped on react, redux, graphql, docker, spa, microservices.

So I would say it was a loooot of hype for react, just like it was for graphql.

I'm going to feel like spamming at this point, but, remember when XML was the future?

https://www.bitecode.dev/p/hype-cycles

No, GraphQL makes sense at facebook because at their scale, dealing with the consequence of allowing all possible queries was less work that having to create dedicated enpoints for all the possible client queries.

People completely missed the point of GraphQL, which is you TRADE flexibility for the client for added cost on the server.

Which in a app and team as huge as facebooks' made sense, especially since they have the so-called facebook apps that could do... anything.

The problem is you delegate a lot of the query building to the client, hoping that it will not suddenly change your performance profile by being creative and that you will have not missed an obviously expensive use case coming.

That's a huge bet, especially given that GraphQL is expensive in the first place, and given that the more you grow the API in size, the less you can actually map the cartesian product of all request params.

Paul explicitly states they wanted him to stay.

Firing implies you want somebody gone.

Extend this logic to other thing you should ask about, and you'll see it gets creepy very fast.

Kids need to mess up, and do things outside of the sight of their parents to grow.

They need to be able to do things their parents disapprove from time to time, or just hide some behavior that they feel shy about.

Sex, meeting people outside of your social norms, attempting stupid stunts, and all that is part of growing.

The simple fact you can know where they are at all time steal those opportunities from them, and normalize spying so that they grow into citizens that will accept it in the future by the gov.

It also removes the parts of the day when they are on their own, and have to figure things out, then deal with the consequences of their action because the parents are not there to get them out of trouble.

Same. For it to be useful, I limit my intake of coffee at twice a week by myself, and one mate. Plus the occasional social one.

This ensures when I drink it, the difference is huge.

May explained why it's easier to avoid distractions when I'm using caffeine.

I've been repeating again and again that everywhere, but the sweet spot for beginners is to stick to the boostrapping method that will lead to the least possible modes of failure.

Because I don't want to repeat it every time, I eventually wrote everything down, so know I can just link to it:

For installing Python: "Installing and running Python: the bare minimum you can get away with"

https://www.bitecode.dev/p/installing-python-the-bare-minimu...

To manage deps: "Back to basics with pip and venv":

https://www.bitecode.dev/p/back-to-basics-with-pip-and-venv

And how I justify those very steps: "Why not tell people to "simply" use pyenv, poetry, pipx or anaconda".

https://www.bitecode.dev/p/why-not-tell-people-to-simply-use

At this point it kinda feels like spamming, but honestly, there is too much noise out there, and those points don't come across enough. Especially since most dev are either too little or too much experienced to be helpful.

Because it works.

We tried the alternative, and it's less productive.

At some point, there is the theory and practice.

Since LLM output are anything but an exact science from the users perspective, trials and errors are what's up.

You can state all day long how it works internally and how people should use it, but people I've not waited for you, they used it intensively, for million of hours.

And they know.

I have my own sense of morality developed over years of balancing life, I don't want a robot to remind me of the average moral construct present in its training data. It's noise.

Just like I don't want a hammer to keep reminding me I could hit my fingers.

I've tried many system prompts so far, and I'm underwhelmed with the result. Especially, I keep insisting to just give me answers with as little context as possible. E.G, if I ask for code, just give the code.

But the gpt does what the gpt wants.

It's a minor annoyance though, 1st world problem at its best.

System prompt.