For checked exception, as you mention, "throws *" is throws Exception, then people can refine it on implementation.

As many language feature, checked exception are often misused and/or misunderstood. Too many time I have seen people blindly propagating checked exception above, and you end up having a controller method exposing a SQLException. Then for sure, it is better to use unchecked exceptions overall

I am pretty sure you can create a mess with Haskell too

For me it is not concept to oppose. You can write optimized code but still name your variables "first_item" instead of u_fp_64_ptr like I often see in "optimized code"

When code needs to be heavily optimized, the fact that some variable is a pointer to a 64bit unsigned floating point number may well be more relevant for understanding the code than the fact that it points to the first item in some list.

But that is explicitly known by the type, we are not writing 90s era microsoft office (hungarian notation really should not be used).

The name of a variable is supposed to contain the most relevant information someone needs when looking at an expression. If the most relevant information is the type, then that should be name. The fact that the compiler knows the type doesn't help me understand the code if I have to scroll two screens up to see what it was.

Imagine you see some code masking the first 40 bits from the location pointed to by first_item. Does the name "first_item" help you understand why they are doing that, or would it be more useful to know that it is the first forty bits of an u_fp_64, so it's masking the mantissa and just keeping the exponent?

> The fact that the compiler knows the type doesn't help me understand the code if I have to scroll two screens up to see what it was.

Doesn't your IDE allow you to effortlessly see the type of a variable, either through inline hints, some sort of keyboard shortcut or at the very least, by hovering your mouse over it?

Admittedly I haven't professionally worked in C/C++ since university, but my understanding is that small functions can be (are?) inlined, removing the function call overhead. If that's the case, couldn't you write a 1-line function like "maskMantissa", which would clearly communicate what the code is doing without overhead?

While skimming over the repo, I am seeing a couple of warnings that indicate leaking abstraction/boundaries :

* there are imports for Spring in the domain code (is Spring part of your domain?)

* you are using a mock framework in some domain tests

Also I am not sure I understand the "domain" and "ddd" packages. I am a huge supporter of splitting a "domain" package from a "application" package like you did, but then not sure where the ddd stands

Q: there are imports for Spring in the domain code (is Spring part of your domain?) A: At only one place in order to be easy to replace it. I followed Vaugh Vernon example of mixing it: https://github.com/VaughnVernon/IDDD_Samples/blob/master/idd...

Q: You are using a mock framework in some domain tests A: Yes. Can you write some pros/cons regarding to this.

"domain" is real domain that contains business logic, "ddd" should be extracted to a common library (according to this example https://github.com/VaughnVernon/IDDD_Samples/tree/master/idd... and this one https://github.com/dddshelf/ddd)

Maybe somebody from soundcloud ? https://developers.soundcloud.com/blog/roshi-a-crdt-system-f...

TDD is "just" a technique, and being dogmatic about it, is as you say totally pointless. Still I would consider knowing and practicing this technique a "must known" in the industry. When I look back to my 15 years coding :

- the time I lost creating bad designed code and manual testing is huge

- all the companies and projects I have joined always have terrible designed/unmaintainable code, made sometime by 10y+ experienced people and explaining at least how to write proper test and how to design a code that is testable is always the game changer to increase a project velocity and down the defect rate

I never regretted throwing away badly designed code. The learning experience was always useful.

Manual testing is indeed a waste of time for the most part.

I have worked in the ad industry for 10+ years. Firefox, strict mode but no ad blocker for web. What I would not do though, is using an android or ios phone (or anykind of smartphone where I don't know what the system nor the application do). I am not sure that people realize how many power and data are used on these phones, for things totally unrelated to their personal usage

So you don’t use a smartphone at all? Or am I misunderstanding?

Yes, until recently where I have a Pinephone, but at the end of the day, I do mostly a "phone" usage rather than data/camera/social usages

Why not just use an Android phone with Firefox and the same exact settings that you use on desktop?

I guess it is doable as long as you are doing only that with your phone. If it is linked to a google account for example, the OS and "embedded" google application will still report tons of data that will be then use for advertising

With GraphQL and single page apps, people tend to move their business logic to the frontend side. I am not sure it is a good idea seeing how moving are the frontend tech

Interesting observation, because my own experience has been the opposite. With GraphQL I've been able to more easily push business logic to the server.

I disagree, we are using Hasura heavily and most of our business logic is in stateless functions called via db triggers and hasura actions.

It is very easy to provide additional graphql schemas that expose business logic as a remote schema.

My experience have also been the opposite. With GraphQL I can normalize queries and mutations the way it is more fit to the frontend and de-normalize/re-normalize it in the backend.

I'd say it's the opposite. GraphQL allows you to move data fetching and composition logic to the server (resolvers) instead of doing it in the client.

Can you provide more details? I've seen the exact opposite.