mkleczek

Yes - that's one of the issues with structured exception handling. Relying only on exception type itself is not enough as information is lost (ie. the actual source of exception)

> No, that's not it. The same problem is true for other error-handling types, such as the "either" or "result" types. Languages without union types or a similar mechanism are unable to define the error types adhoc and force the developer to define them in advance, which is very unergonomic

We are saying the same thing, aren't we?

But it is not only about exceptions. Other effects have the same problem and you need a mechanism to define effect polymorphic functions.

When structured exception handling was becoming popular (C++ in nineties?) the idea was that immediate error handling (like when you have to check return values for errors) makes the main flow (happy path) blurred and unreadable.

You cannot have both at the same time, I'm afraid.

Checked exceptions failed in Java because they don't play well with parametric polymorphism. Union types might help (exception list declaration is actually a union type) but I don't think it would succeed anyway as it is not general enough.

Handling effects and effect polymorphism in programming languages is an active area of research and there are some new languages that try to approach the problem (ie. Koka).

Haskell has several effect libraries (effectful, cleff, eff, polysemy) that look quite nice.

Idris with its dependent types allows precise definition of effects in function signatures.

This is only because you use exceptions incorrectly. You can (and should) write:

try {

  final var fResult = f(g());

  //do something with fResult 

}

catch (E1 e) {...}

catch (En e) {...}

That's the main idea of exceptions in all languages: main flow is kept together and exceptional flows are separate.

I am afraid it requires "echo" runtime environment, doesn't it?

> Code smell is usually used to describe code that is suspicious or uses practices that are known to be highly unreliable (e.g. regex)

I think this sentence illustrates very well the root of our disagreement.

Saying "are well known to be highly unreliable" without any backing _facts_ is the sad state of affairs in IT industry.

I am keen to see a research done with scientific rigour that would show that regex is highly unreliable.

> That's not a bold thing to say. There are plenty of areas that are really hard to study through experiments, but we can still learn things through experience. The whole field of psychology is just on the edge of being amenable to experiment, but it's not like we know nothing about human psychology. Management is another field where it's more or less impossible to do scientific experiments to determine what makes the best manager, but again that doesn't mean we know nothing about management.

And yet in both these cases we at least _try_ to come up with quantifiable results of our observations. The point is that without them we are not really capable of coming up with any meaningful conclusions.

> Very occasionally there are great scientific studies of software

For me it seems the body of software available to analyse empirically is large enough now to start doing it and it is happening. What's important is that none of the empirical studies I know measure anything named "technical debt".

>> Talking about "technical debt" of software system is no more useful than talking about its scent.

> Why do you think talking about its scent is not useful?

Because it does not provide any meaningful insight into what should or should not be done to improve it.

> It's because measuring those things is impossible. It's not like people haven't tried - look up cyclomatic complexity for example.

Quantification is the basis of scientific process. Are you claiming programming or software systems cannot be a subject of scientific process?

That would be a really bold and blatantly false statement.

But if you mean "technical debt" is not measurable then we are in complete agreement and what I am saying is that if that's the case then talking about "technical debt" is useless and we should try to find other terms which would be more useful to describe software systems and allow us to base our decisions on more than feelings and intuitions.

Talking about "technical debt" of software system is no more useful than talking about its scent.

The longer I am in this industry the more I am disappointed about the fact that instead of using disciplined, quantifiable processes we are more and more in the realm of poetry with "analogies" or "metaphors".

This kind of language - while sounding deceptively smart - does not help in any decision making because the terms are neither measurable nor actionable... Just meaningless.

What we need are answers to questions like: how do we measure maintainability of software systems? How do we compare solutions and select them? How do we decide on what investment in making the software better is worth pursuing?

Is "tech debt" even something that can be measured and actioned upon? How do we know if our changes to the software made it bigger or smaller? How do we know its impact on the bottom line?

Not sure what language you are talking about. For Java there is an awesome https://www.jooq.org/doc/3.19/manual-single-page/

Having said that: I stopped using it as writing plain SQL seems much more effective.

One of the most exciting developments (among a few others) in PostgreSQL ecosystem just reached public beta. Congratulations!

> 2PC tends to have limited throughput due to the participants needing to hold a lock between the voting and commit phase

Scalability depends on lock granularity, what's more...

> Sagas [...] can have high throughput

There is no real difference as sagas in practice implement locking in disguise - take the scenario of flight/hotel/car booking:

Once you book a hotel - this particular resource (a room at a particular time) is effectively locked. Cancelling the booking (because other participants failed in saga) is effectively releasing the lock. The room (resource) is locked for the duration of the whole process anyway (as no other customer can book it during this time).

The downside of sagas is that a programmer is forced to explicitly handle all failure scenarios - which costs development time, is error-prone etc.

A long, long time ago we used to have two-phase commit protocols and XA. I am afraid most of sagas are 2PC in disguise - just requiring a programmer to explicitly implement rollbacks.

The situation is similar to the whole "database inside out" hype that drives application programmers to re-implement proper DBMS.

I am pretty sure the IT hype wheel will turn around and someone will sell 2PC as a new shiny thing.

KISS is good... until it isn't.

At my work I struggle with the opposite: all problems are being squeezed into "let's put it into static JSON on the CDN" - which ends up with a complex custom JSON based language (schema) to support sharing information between apps, subsetting information (ie. search) etc - ie. implementing an ad-hoc one-file database. Ahh... and don't forget about complex CI/CD pipelines and Git setup that allow business users to manipulate data in these files.

I found "just use Postgres for everything" a much saner default in the end.

This begs the question: what data is going to be used as a training set? How do we make sure our black boxes don't become just echo chambers giving us answers we already know?

At the end of the day it is always: garbage in, garbage out.

I must say not mentioning two phase commit and distributed transactions in this context seems strange.

It looks like nowadays people forgot about XA and that MQ and DBMS can participate in a distributed transaction.

You can in PostgreSQL and it is very useful: https://www.postgresql.org/docs/current/queries-with.html#QU...

Maybe https://github.com/sraoss/pg_ivm might be of help?

> I’d love to see B-Tree primary storage option. Aka store the row data inside the primary index.

It is coming: https://github.com/orioledb/orioledb

I will say it again: please, reconsider JEP411. SecurityManager helps:

https://xeraa.net/blog/2021_mitigate-log4j2-log4shell-elasti...

Ahh, I misread your comment. Indeed, halting is not very interesting property of programs.

No, dependent types are no the answer - read (or watch) this: https://pron.github.io/posts/correctness-and-complexity

The need for trust increases risk. Higher risk is higher cost.

Thanks for this!

> You still get full access to everything the app can see - all Confluence content.

No (with proper policy in place). That's the whole point of SecurityManager. Even if you can execute code - it is sandboxed and has limited (or none at all) permissions.

Not long after log4shell yet another example of why JEP 411 (removal of SecurityManager) is a very questionable decision.

Running applications under SecurityManager would have prevented a lot of these vulnerabilities (or rather - their severity would be much lower).

“Complexity is the business we are in, and complexity is what limits us.”

Yet, just as Turski recognized, some people seem to be philosophically offended by this notion, and try to fight the proven limitations. They are under the impression that the world — and I’m not just talking about computing now — is essentially simple, and it the stupidity of people and institution that needlessly complicate it (or, in the case of software, “stupid” programming languages). If we apply careful mathematical reasoning, we could find solutions to anything.

Computer science is the very discipline that proved that essential complexity can arise even in the smallest of systems. Yet sometimes it is computer scientists and software developers who attempt to challenge the very foundation of their own discipline. Complexity is essential. It cannot be tamed, and there is no one big answer.

The quote is from excellent https://pron.github.io/posts/correctness-and-complexity and it would be really good if the authors read it carefully first.

Here in Poland it is 30 CAD.

No.

From the fact that we know how to write programs that halt you cannot deduce we know how to write programs with arbitrary (or even just useful) property, because there is no general procedure to do that.

In other words: you cannot use the algorithm of writing programs that halt to write programs computing nth digit of Pi :)