bvrmn

Yey! Let's speedup project downfall to crap abyss even more!

You either care about project and do reviews. Or yolo vibe code. This middle ground has little sense.

Oh boy. There were (and are) hordes of enterprises requiring us to support SAML and were quite amazed to know Entra and all big auth providers perfectly support OIDC.

Ahah. In my days SOAP libraries were kinda shitty up to the point I had to write my own to handle "non-standard" (actually very standard) WSDL definitions. SOAP consumption in one lang was okeish, especially Java or .NET. But interop — oh boy. The biggest issue were services exposing SOAP interface based on code-first approach, when you write some declarative code with annotations and library transforms it into WSDL and proxy endpoints.

Oh gosh. I could only imagine how many apps in chain crafts and parses soap envelopes with adhoc code with mandatory info loss.

You could take any pills and have any fantasies in your small coding corner. But saying very strong word "better" has very distinctive aftertaste.

> could we throw the definition into context and tell the LLM to avoid it?

Every IMPORTANT RULE WHICH MUST BE FOLLOWED STRICTLY to not to do something from my AGENTS.md and skills are violated without any hesitation from LLM. Glorified autocomplete doesn't work this way. Positive rules are more stable on this regard.

Did your clanker reach 40k CLOC?

Without tailwind LLMs tend to use inline random colors, random sizes and radiuses. Project becomes an unmaintainable design soup really fast. Even with tailwind first priority is to define dark/light theme with semantic colors. After it's a smooth sail (sort of, routing, forms, state ownership and persistent url state are still an alien concept for clankers).

I'm quite versed in CSS but tailwind has convenient abstractions on top. It's like "why you need C if you have assembler". I don't remember when I wrote raw CSS last time. Even global styles I tend to express via @apply.

Hm it's interesting perspective. The paper adds sorting into the mix. Like sorting moves cells and thus prone to issues with references. For me sorting always moves values in cells and I even can't imagine how you could sort formulas. It doesn't make sense.

ArrayList is a very generic (pun not intended) structure and could be stretched quite freely in any direction with useful property of owning underlying slice. Like readonly preallocated ArrayList is a thing.

Examples don't show much more composability comparing to SQL. Even more Prela is heavily based on tuples and has same operation semantics as SQL.

Shameless plug: https://github.com/baverman/sqlbind-t

Since pipewire landed in arch all my issues with sound magically vanished. It's a really great piece of software. Maybe it's even worth to change the distro.

It's funny I'm currently creating a TUI. A mutt like mail client. I didn't have any second though to consider GUI for the project because it's so ridiculous.

It's inherently cross-platform (msys under windows). It allows to copy any part of UI. It doesn't require dependencies other than curses.

Shameless plug (link to the repo) of your extension :)

People nowdays have no shame and completely forget the art of plug.

It's by LLMs definition, duh. You are dummy charmed by "reasoning".

it's quite interesting scoring and conclusions. For me Gemini renders are definitely top outliers for all combinations.

Demo works quite strangely. For example "how to use typescript with createContext" show only typescript entries on top. Similarity search failed.

Nice one. gcc/clang are smart enough to get .ok condition statically. I'm very curios how complex an expression could be.

That's the reason language/compiler should directly support optionality.

You can't fool yourself and have to handle all cases: https://godbolt.org/z/4GqMdPej3

I like maybe_value dereferences NULL with SIGILL and you have at least a backtrace with exact invalid access position.

Yes it is.

1) Most of pointers in real apps are non-nullable and it's nice to have enforcement from a compiler.

2) Good compilers verify you actually check nullable (optional) values have a corresponding check. In particular Zig literally forces you to unwrap value, so no unexpected state.

It's a really amazing QoL.

And no, optionality doesn't make type system any harder. Also C lacks alignment enforcement on type level and it's a real footgun which Zig also fixed. Zig has many warts but this part (optionality, alignment and slices) makes a big difference comparing to C without Rust/C++ level of type acrobatics.

> I also once believe that complex type systems are the answer, but over time I realized this is not really true.

It's suboptimal decision, you load your brain with stuff compiler should resolve for you.

Edit: ahah, just noticed your nick. Really appreciate your work on C improvements. Please ignore my yapping :) I literally know nothing comparing to you.

It's quite a delusional take from Bill. Wow. Using non-nullable (a sane language default) pointers in Zig is liberating experience. And it's still as low level as in C but instead of ship-and-pray you could state your intention with a type system.

NULL as a concept is fine. Inability to declare something as non-null is not.

There is a huge gap between developer expectation "it's pointing at something known" and hard reality confirmed by zillions of CVE. That's the reason optionality is prevalent in modern languages and type checkers (python, typescript), nowdays even Java has sane non-nullable types.

I'm a happy user of android with animations turned off. It's the only mean to make it somewhat "snappy". IMHO lag is always worse than lack of fancy transient state in input -> UI change context.

I really like Zig's approach to UB. Especially alignment is a part of type. And all this wordy builtins for conversions. Starring to it makes you think what you doing wrong with data model it requires now 3 lines of casting expression.

Another book tactically missing memory and ownership design for modern c++ apps. I think there is no more important topic for teaching. There are some slides in advanced sections but it's quite ironic one needs to know about it from the start!! Who owns memory? How to pass it? Move? Borrow? How to communicate it for readers? It's like a tribal knowledge.

Every time I touch enterprise C++ codebase it's a freakshow heavily struggling with memory management.

As reference the material could be good, as study it's very questionable.

Just in case, I'm completely fine with the policy as-is. Even more, I'm ok with making no-sense project policies. I have no business to judge how to govern other's projects.

I've assessed half a dozen before writing my own with following results:

    - 2 are python resource hog
    - 2 from AUR don't compile with modern GCC.
    - 1 uses gtk battery icon, but uses dark version on dark taskbar, unreadable.
    - 1 shows just black square.

Like I spent more time on assessment than I got a first working my tray. Amazing times.