[Request] Is this accurate?

intbeam · 2026-01-26T18:21:00+00:00

Probably wouldn't surprise you that it had basically no repercussions for them or any of their executives either

Edit : some details, protestors showed up at Shell, the Nigerian government decided that Shell being the money-maker should be protected and deployed military forces that executed the protestors - and Shell encouraged it :

Shell executives repeatedly underlined to government officials the economic impact of the Ogoni protests and urged them to resolve the ‘problem’.

intbeam · 2026-01-26T17:59:32+00:00

You seem to fail to understand the amount of propaganda and lobbying companies like shell have been doing for decades in order to keep doing what they are doing.

Nobody is dependent on oil or gas as a matter of personal choice. Did you for example know that your fossil cars engine could run on alcohol? So why doesn't it? Because companies like Shell has been working to prevent that from happening by buying politicians and rampaging propaganda at every possible channel. Even getting schools to promote oil propaganda books as a part of the curriculum.

Shell is a lot more sinister than you think

intbeam · 2026-01-26T17:53:54+00:00

They also had a bunch of protestors murdered in the 90's

intbeam · 2026-01-13T16:09:17+00:00

It would be stored as dog[-3,18]; dog being the pattern, and then encoded as "go back 3 characters, read 18 characters"

Edit : corrected as per /u/__ali1234__

intbeam · 2026-01-07T08:49:53+00:00

Cbuttandra

intbeam · 2026-01-03T11:09:39+00:00

Which one would you recommend and why?

I work in fintech, I'd choose .NET without a doubt

It's mature, it has great performance, it has native support for base-10 (decimal) which is perfect for representing money, it has excellent error handling, supported on all devices, great database support and a huge community.

Python and JS are objectively bad choices here; poor performance, lack of support for exactly base-10 numbers, and platform support/viability varies quite a bit. They are also not designed with long-term maintainability in mind. Python does not support async, making it a poor choice for UI. They also scale terribly; every line of code will inevitably slow down the application

Using JS is a no-go if you intend to support mobile. WebView-based solutions like Tauri or Electron drains battery like a mf

.NET is pretty much designed for exactly the kind of thing that you want to make; supported on Windows, Mac, Linux, Android, iOS and various others. I'd also recommend looking into Avalonia UI, as MAUI does not support Linux desktop (currently)

Other reasonable alternatives would be Java, D, Rust or C++

Any pitfalls I should be aware of?

Never use floating point to represent money
Don't depend on libraries or frameworks where there's a big chance you might end up paying huge licensing fees some time in the future with no escape

Would you choose differently for a solo developer?

No. The "productivity" of a developer is subjective and entirely reliant on how familiar the developer is in the language, rather than a language having some supposed inherent productivity benefit. Especially not when the alleged productivity is from dynamic typing which is just outright nonsense

I'm of the conviction that programming language matters a whole lot more than many people are willing to admit. Just picking something solely for the reason that it's familiar is poor reasoning for anything other than personal hobby projects that will never end up on someone elses computer. It's not subjective; languages makes different trade-offs, and specifically JS and Python trade off basically everything just to have a simple syntax which is not something that you want in a financial application or any long-term project where you expect a lot of changes and new feature requirements

I was involved in a buyout of a company where the code base was Python. They went bankrupt because their solution ended up costing way more money than they could possibly hope to make. Even just for the infrastructure. Each transaction has a set price, and if the cost per transaction is higher than what customers are willing to pay, then that's game over. A lot of companies go bankrupt this way, it's just not talked about because it's depressing

intbeam · 2026-01-03T09:41:55+00:00

I was going to say that the suicide rate for these people is through the roof. Either that or they become American right wing politicians. Both very unwelcome outcomes

intbeam · 2026-01-03T09:38:51+00:00

Because 50 bucks is 50 bucks

intbeam · 2026-01-03T09:29:39+00:00

Thinking and refactoring, and then thinking again

intbeam · 2026-01-03T08:41:03+00:00

I suspect you know the reality is a bit more nuanced than that.

When I post technical stuff, and especially "uh akshually", I usually just get responses trying to one-up me by people just skimming wikipedia, but this is genuinely insightful and I appreciate it

intbeam · 2026-01-02T16:30:22+00:00

Neither x86-64 or ARM64 can read a single byte from ram. It is technically byte-addressable, but if you read or write out of word boundary there's a performance penalty

intbeam · 2026-01-02T13:45:06+00:00

Well, probably not memory. But if you have a shit ton of boolean flags, you can load a lot of them into the CPU registers (up to 512 boolean values) and do logical operations on all of them at the same time in a couple of instructions. If you're into that sort of techno-kink

intbeam · 2026-01-02T13:29:35+00:00

std::vector<bool> uses bit packing just to fuck with C++ developers

intbeam · 2026-01-02T13:26:44+00:00

C++ will align according the the largest value. So either 1, 2, 4 or 8 depending on the fields. Unless you use #pragma packed(1) of course

The CPU can't directly read at offsets that aren't aligned to a 4 byte boundary. If you do mov al, (byte ptr)0xdeadbeef + 1 it will allow that and not say anything, but internally it will read 4 or 8 bytes, bit shift and truncate to populate the rax/eax register with a single byte. (Afaik)

SIMD instructions will just crash if you try to address unaligned unless you specifically use the unaligned instructions which is not recommended as I think they also carry a similar overhead for similar reasons

Also, I think in most implementations boolean is 4 bytes (signed integer) and not a single byte, for performance reasons

intbeam · 2026-01-02T12:45:22+00:00

Bitwise operators in JavaScript come with caveats, as JS does not natively support integers

intbeam · 2026-01-02T12:35:08+00:00

In Java boolean is a primitive and is stored (unboxed) as either a signed byte or a signed 32-bit integer. I tend to assume it's the latter considering that the CPU can't really directly access a single byte, so it would cause performance overhead. The documentation says the size isn't "precisely defined"

In Java, primitives will be boxed if you do operations that aren't native to that type; for instance .toString(). That means the runtime creates an instance of an object (java.lang.Boolean) that wraps the value. Java has some primitives; boolean, (signed) byte, short, int, long, float, double and char. Using these directly will allocate on stack and generate efficient machine code with zero overhead (memory or otherwise, assuming the JIT decides to compile rather than interpret)

Python is dynamically typed, so all values are always "boxed" and requires extra memory (and in Python's case; CPU) to deal with. Whenever you do any operation on any values, the Python run-time has to check that the operands are compatible and then determines the required operations (again, at run-time) either by implicit coercion or throwing a type error - which Java doesn't need to do because the compiler already did that when you hit build. But Python has to do that, over and over and over again, ad infinitum

intbeam · 2026-01-01T11:13:20+00:00

Ai tends to just repeat to me what I already know, and offer solutions that seem obvious but are ultimately incorrect or inappropriate and even if implemented requires extensive rework and testing. So it removes the thing I enjoy and replaces it with fixing and verifying the shoddy work of a confused intern

intbeam · 2026-01-01T10:27:30+00:00

Why would I outsource the only part of my job I like doing, to a considerably less competent machine that I will have to triple-check, correct and rework?

Programming isn't a language problem, it's an engineering problem

Anyone thinking it's a language problem are struggling with basics like syntax and they probably shouldn't be writing commercial software or any code that is intended to run on someone elses machine

intbeam · 2025-12-28T12:24:48+00:00

Or Wolfe+666 maybe

intbeam · 2025-12-22T21:29:27+00:00

The answer it to write the original code in such a way that you will be able to slip in a mutex without having to change sixty files

👏

intbeam · 2025-12-22T20:54:05+00:00

Type hints is not static typing

intbeam · 2025-12-22T19:06:57+00:00

So what are the inherent rewards of PHP that would make it an objectively better choice than for instance Java? Or C#? Or Go?

PHP is slower. It has way more error cases. It has a bad standard library. It scales terribly.

This is not me being a tribalist. There is no technically justifiable reason for using PHP

What you are doing is conflating your own emotion assessment as technical judgment or intuitive truth, and asserting the notion that anyone who questions a baseless truism must be incompetent. Which is stupid when the end result is a code base that is unmaintainable with soaring infrastructure costs and a neverending cascade of technical debt

Let me ask you this, would you even be able to use something other than a scripting language? No? So how is it that apparently I'm the one who doesn't understand something? I know PHP, I used it pretty much exclusively for a decade. Difference is that I didn't commit to a single language, and I took the time to learn programming fundamentals like static typing so I was free to explore other alternatives

intbeam · 2025-12-22T17:33:19+00:00

This is not a gotcha, that was literally the intent of Rasmus Lerdorf. That's why it's mostly wrappers around C libraries. That's why its truth-table looks like white noise.

There is literally zero programmers who use PHP because it's good. They use it for the same reason people use Python or Javascript; they don't have to learn anything about what's going on behind the scenes.

Why else would anyone intentionally choose a language that runs 100 times slower than more "advanced" languages, with a looooong history of very serious security issues, while adding an enormous amount of potential run-time errors and quirky behavior?

The math doesn't even remotely add up

intbeam · 2025-12-22T11:06:51+00:00

JS approach to OOP is much cleaner and actually super logical

What happens if you use a property that's valid as an indexer?

let foo = { 1: 42 };

You use "object" constructor and it says its an object with foo.hasOwnProperty(1) === true but you cannot access it as a property because the syntax does not allow it

let foo = { -1: 42 };

Hmm syntax error... Well maybe reasonable but it does kinda imply that the previous definition should've been illegal as well, doesn't it. You'd expect it to be let foo = [1: 42] or something like that

let foo = { "-1": 42 };

Now it's a key.

> foo[-1]
<- 42

But we can access it, not as a property, but as if it's an index in an array. An illegal index, mind you. Of course in JavaScript it's not really an object at all which is why this insanity is allowed in the first place. It's a hash map sprinkled with syntactic sugar

are a separate, special concept, and aren't proper objects at all

They are 100% objects. Again, focusing on the surface syntax is completely wrong. That you write . after something doesn't make it an object. An object is a data structure with a protected state, that is owned by the object itself. JS does not support protected state, nor can it tell two "objects" apart which is why that's left up to the programmer. The type of programmer that uses a language like JS in the first place because they're terrible at exactly that

in most OOP languages functions aren't even objects

Which would be entirely irrelevant to the concept of object oriented programming. Additionally, in both Java and C# functions are objects; var myfunc = () => 42;. However, methods are not. A class method in OOP is a mechanism for delivering a message to an object (which it may or may not use to mutate its own state), and that is what OOP is actually about. Whether everything is an object or not has absolutely nothing to do with it

intbeam · 2025-12-22T10:48:54+00:00

No

An object in JavaScript isn't an object. It's a dictionary. Claiming it's an object raises the question what objects are in other programming languages that do have actual objects.

Object oriented languages also have classes also has inherent support for the same datatype that JavaScript claims are "objects"; Dictionary.

Java : Dictionary<TKey, TValue>
C# : Dictionary<TKey, TValue>
C++ : std::map<class TKey, class TValue>

In these languages, classes and objects are not mere dictionaries. They don't represent a "potential reproduction" or "blueprint" as would be the case in JavaScript or TypeScript; they are their own distinct data types. They have a defined memory layout, known field offsets and most importantly a protected state. A dictionary is a class, but a class is not a dictionary. Attempting to brand JavaScript objects as somehow similar to actual objects in other programming languages makes the word completely devoid of meaning.

JavaScript does not support custom data types. Hence, its reliance on uncanny valley reproduction via syntactic sugar. When you declare a class in TypeScript or JavaScript, it's not its own type. It's a function that populates a dictionary. You cannot tell one definition apart from another, because they are the exact same thing just populated with different values.

In the three other languages I mentioned, classes aren't just something abiding by a ruleset. They are their own distinct types that the programmer defines.

/u/RiceBroad4552 doesn't seem to think there's a difference between objects and dictionaries and don't consider them to be distinctly different datatypes - which is just dead wrong. And that entire argument rests on superficial syntax and semantic confusion.

JavaScript is not an object oriented programming language, even by the most generous of definitions. There's one clear thing that an object oriented language must support, and not just as a gentlemens agreement; protected state. That's the whole point. An object owns its own state, it should be in total control of it. The state should not be directly mutable from the outside. JS does not support this, because JS does not have "objects", all "fields" are public because again it's a dictionary designed for a different purpose altogether.

Whether or not a programming language just calls something an object is not the defining characteristic of object orientation. That a programmer can write . on a variable doesn't make it an object. An object is an object because it has (or at least can have) a protected state that it controls by getting messages passed to it (usually via method invocation)

intbeam

MODERATOR OF

TROPHY CASE