cuddlecake

Saw that you tweeted an example of error log improvements, which is exactly what I meant with the 20+ lines of error messages with only the last one being relevant.

Now I just need to wait until Typescript 3.7 trickles down to all my dependencies so I can get that goodness. Sigh.

Sigh.

> If you've got examples of cases where we can do better, feel free to file an issue! We want to do better

Thanks for letting me know.

> 2. I think the boilerplate is good in making things explicit.

I think Boilerplate is the lack of a more succinct way of expressing your intent. So, boilerplate is never good in making things explicit, it's just the (current) shortest way possible to accurately expose your intent.

For example, in TypeScript, if I delve into making datastructures `algebra-ish`, I always have the boilerplate of defining a `tag` field in my objects, and lengthy switch-constructs to match on the tag field. It's not good in making things explicit, it's actually just the only way (at the moment).

> I'm giving my opinion. Please understand some people think differently than you and that's fine.

What does that mean? Should he have NOT responded to your comment? Does that then mean that you should have not responded to his comment? Does that mean I should have not responded to your comment? Does that also mean that you shouldn't have made a comment, since Evan directly expressed his thoughts and opinions in his post? Should we stop communicating at all and become Loopless One-Directional Communication Graphs? Who shall be the original Opinion Holder? Adam or Eve?

Anyway.

> Should the compiler also correct the user if they write `#import <set.h>`? Or `open Set`? Or `from Set import `? Again, in my opinion* this is neither relevant nor desirable.

If it can, why not? Why not tell the user: Hey, you've got `xyz`, but you can only do `zyx` with those literals. Having detailed Errors is not a detriment. I remember my first Segmentation Fault in C. Man, I cried.

Programming languages have users, and caring about the User Experience of a language (i.e. Developer Experience, I supposed) is commonly desirable. There is no downside to a good error message, neither for something as trivial as imports, nor for common things like using the wrong key names in a Record.

I make heavy use of types in TypeScript, but the error messages when something is out of order (ever so slightly) is just so brutal at times, with error messages being 20+ lines long, where only the last line might be relevant. I, for one, welcome our helpful error message overlords.

I remember when I started with Java at University.

Like, "hello, what is a method? What the hell is a class? Come on, stop kidding me, objects have methods???? How do I call them? Wait, how do I _write_ a method?"

> Human brains are object oriented, so OOP is very easy to grasp.

Can I cite you on this? Because I have only ever seen this explained in Programming 101, where Java is the language they teach.

I wonder where this sentiment comes from. I imagine it came from marketing.

¯\_(ツ)_/¯

Just realized that I never use the drag and drop I implemented in my application.

Wonder if it actually still works.

What's "FUD"?

Are you replying to the wrong link? The link is about programming fyi

I can relate to that.

Sounds weird if you phrase it in a weird way, yes.

Just like communicating with strangers via on-demand electric currents is weird as well, if you phrase it like that.

What I see in Germany is that some of the startups are basically contracted by larger companies, tasked to develop complex solutions for a fraction of the price that an established company would require for the same task.

At least that's my experience so far.

There are a lot of per-query optimizations that can be done, and I think I have read somewhere that Hasura does them very aggressively, ensuring performance even on complicated queries.

In any case, you won't have to worry about N+1 Query problems with Hasura.

On the other hand, it also does not mean that inefficiency to some degree is not acceptable.

And if it is not acceptable, you can still optimize the living excrements out of your GraphQL resolvers.

Also, the burden of doing more than one round trip usually moves to the client. So there's always some trade-off to be made.

Well, but that's not breaking down GraphQL as an abstraction, isn't it?

> This is where the abstraction breaks down.

No. In REST, the client is responsible for resolving IDs into entities.

In GraphQL, that responsibility largely moves into the backend.

This is not "breaking the abstraction", this is exactly what GraphQL is good for.

Don't fall into the trap of "This is criticism of something popular merely because it is popular"!

Hehe, no offense, just talking to myself.

... buuuuut you don't have to learn how to:

1) deploy your code 2) deploy your datastore 3) manage your datastore 4) shard your datastore 5) deploy your infrastructur3

Among many other things. The value of Dark Lang lies not just in the programming language and the IDE, but in the holistic experience for backend development it provides, since _all_ of the overhead required to actually move to production and make new releases completely vanishes.

Reducing the entire idea of darklang to "vendor lock in, lol naw" is missing the point, but also kind of nailing it.

By reducing options, you gain the freedom to focus on the problem you set out to solve in the first place.

Of course, it's not a silver bullet right now, but it's an interesting bullet nonetheless.

Isn't that how most regulations come to be? People die and people realize it can be avoided?

Bad actors are sometimes involuntarily so.

Checking this app out I was immediately frustrated. Just switching between the tabs of a pot always takes like 500ms. The FAB immediately glitches because it's not sticking to the bottom of the screen immediately.

Also, clicking on the same tab again also causes annoying friction.

I used SettleUp for a while, for writing down food expenses (small amounts, frequent, and different amounts per person)

It was such a hasslr that I decided to set up a transaction log (person A paid X for Person B for item Y) in Google sheets instead, which automatically tracks debts per combination of persons.

It's so much easier since I can parse and note down a receipt within one minute, compared to doing calculations in my head and writing the debts down in an App.

Edit: After giving splitwise a quick look, it also doesn't solve my grocery debts problem.

Well, you do write CSS classes, but those classes are based on your configuration. This is not a reinvention, it's a framework addressing certain issues in a certain way. It might seem counterintuitive at first, but to me it's a tool. I prefer it over SCSS (since I often rebuild in SCSS what TailwindCSS provides)

TailwindCSS does have that:

https://tailwindcss.com/docs/extracting-components

TailwindCSS can be abused to resemble inline styles, but part of TailwindCSS is the fact that you have some sort of design system you can quickly set up and build upon. For example, I could define a color called "primary" and use it anywhere without caring what the actual color is.

Furthermore, styled buttons are such a common occurrence that TailwindCSS encourages users to extract common CSS patterns into component classes[0].

0: https://tailwindcss.com/docs/extracting-components

Is there any sort of fallacy that the saying "use the right tool for the job" in the context of programming languages / datastoring technologies etc. can be categorized with?

I always have a feeling that this might be a fallacy, because tools are usually defined as "carrying out a specific function", but there is no specific function in regards to programming languages or datastoring technologies other than "make machine do" and "store data" respectively.

The rest just seems to be sideeffects. Kind of like you can either insert a nail into wooden board or produce a gaping hole in a Human's skull, whereas the function of a hammer is just to apply force to a relatively small surface (more or less). There are many right tools for inserting nails into wooden boards or producing gaping holes on human skulls, which is why I'm starting to think that the phrase "Use the right tool for the job" is preemptive hindsight.

You could always choose the right tool - so why didn't you do that?

I have one colleague who used to constantly name-drop the pareto-principle, as an argument to stop working on something.

To be fair, a site can go down in any language...

Phoenix LiveView is basically server side rendering in real time.

The user's actions are sent to the Backend via WebSocket, and the Backend rerenders (parts of) the view and sends them to the user.

I think it is an anti-pattern to design a system where each domain object is a process. Sometimes data is just data and should be managed as such.

I think what makes actor models so nice is the explicit ownership of state. It is not possible to declare "var x = 1" in one file, and access x in another file. You always have to retrieve state explicitly, otherwise it won't be accessible within the scope of your function.