Programming thread

Relying on undefined behavior (in this case, browser-specific behavior we can't reliably predict) like this is problematic for the typical reasons undefined behavior is problematic. But most importantly, this ultimately creates a situation where one browser could render the BBCode differently than other, leading to users tailoring their setups to look best on their specific browser. So formatting will always look incorrect to somebody.

Fellow fossils in this thread will remember the days of IE's compatibility hell. Same core principle.
Where is the basis to believe your premise at all? You’re not thinking concretely about this and it’s why you get useless answers to a basic problem like this.

If I write some PHP or C and decide it’s going to transform BBCode into HTML styling tags, then that’s what it does. There’s no “undefined behaviour” here except the kind you made up in service of some preconceived theoretics that has no applicability here.

Just transform the text bro. No one cares about how it may not translate into markup languages that don’t exist.
 
Where is the basis to believe your premise at all? You’re not thinking concretely about this and it’s why you get useless answers to a basic problem like this.

If I write some PHP or C and decide it’s going to transform BBCode into HTML styling tags, then that’s what it does. There’s no “undefined behaviour” here except the kind you made up in service of some preconceived theoretics that has no applicability here.

Just transform the text bro. No one cares about how it may not translate into markup languages that don’t exist.
It's fine to be incorrect from time to time, but at least do some basic reading before doubling down.

ub.png
ub2.png

Despite the kinda shitty wording in that 2nd paragraph, both paragraphs are correct. A large number of critical web engine vulnerabilities are caused by web engines trying to repair and render malformed HTML. Jewgle spends inconceivable amounts of resources fuzzing Chromium's engine 24/7. Some browsers will stick a missing closing tag in a place that other browsers don't. It happens a lot more than you think. If you don't see how this sort of inconsistency extends past security and into simple shit like text formatting, I don't know what to say.

Why open the door to all of these problems when you can just write your parser properly? Part of properly "transforming" the text is ensuring it's well-formed.
 
Why are Go slices so goddamn retarded?
I think Go is fine for what it is, but anytime I look at slices I think, "why would anyone approve this?".
 
  • Thunk-Provoking
Reactions: y a t s
Why are Go slices so goddamn retarded?
I think Go is fine for what it is, but anytime I look at slices I think, "why would anyone approve this?".
Care to elaborate how they're retarded? They're extremely versatile, though you typically should use io.Readers to handle larger buffers.
 
  • Agree
Reactions: Marvin
Care to elaborate how they're retarded? They're extremely versatile,
They merge functionality of view and vector. So their versatility is my biggest gripe.
You can have two slices sharing underlying array and overwrite other by accident, or change underlying array also by appending.
In many cases you should pass slice by pointer(when you want it to act like vector), but it is often ignored.
And enforcing that you should not resize it is impossible afaik.

It just bizarre combination of two things that should not be the same.
Which leads to heavily relying on context, which is weird for language that were supposed to be as explicit as possible.
 
  • Like
Reactions: UERISIMILITUDO
They merge functionality of view and vector. So their versatility is my biggest gripe.
You can have two slices sharing underlying array and overwrite other by accident, or change underlying array also by appending.
In many cases you should pass slice by pointer(when you want it to act like vector), but it is often ignored.
And enforcing that you should not resize it is impossible afaik.

It just bizarre combination of two things that should not be the same.
Which leads to heavily relying on context, which is weird for language that were supposed to be as explicit as possible.
To quote one of my favorite programming proverbs (from here):
Share memory by communicating; don't communicate by sharing memory.

If you're using slices in a way where you're using them more like C arrays (i.e. raw pointers to memory regions), you should probably rethink your strategy. Yes, slices and maps and the like are pass by reference, but their inherent lack of thread-safety makes them ill-suited for anything beyond value storage managed by a single function.

Channels are almost always the way to go here. You can use them to very easily feed data from one routine to another. Bear in mind that you can define channels of channels (e.g. make(chan chan string, 1)). If you buffer your channels, then you can use them as a fixed-size thread-safe buffer that blocks new sends until there's space available—acting more like a queue. Here is a fantastic article about the concepts I'm discussing here, applicable directly to Go's model.
 
Last edited:
You can have two slices sharing underlying array and overwrite other by accident
Just don't have multiple mutable references to the same data at the same time, hold these references for the shortest amount of time you possibly can to get the job done, and don't hold pointers to items within re-allocatable data structures when you mutate the data structure. These are both error prone patterns. Your compiler warns you about this right? Mine does.
 
If you're using slices in a way where you're using them more like C arrays (i.e. raw pointers to memory regions), you should probably rethink your strategy. Yes, slices and maps and the like are pass by reference, but their inherent lack of thread-safety makes them ill-suited for anything beyond value storage managed by a single function.

Channels are almost always the way to go here. You can use them to very easily feed data from one routine to another. Bear in mind that you can define channels of channels (e.g. make(chan chan string, 1)). If you buffer your channels, then you can use them as a fixed-size thread-safe buffer that blocks new sends until there's space available—acting more like a queue. Here is a fantastic article about the concepts I'm discussing here, applicable directly to Go's model.
I think you are correct on strategy for multi threading. But I think it might become as an issue even in single threaded context.
It is just not clear what slices represent.

Also Rust slices cannot be expanded(afaik), and there is vector type. And that's my mine gripe with go slices.
 
I think you are correct on strategy for multi threading. But I think it might become as an issue even in single threaded context.
It is just not clear what slices represent.
Single-threaded contexts are less of a thing with goroutines, since they're scheduled. While we often call them threads, it's a bit of a misnomer since the goroutine doesn't occupy a thread in a traditional CPU/OS sense. Go gives you the ability to do things like use slices as C arrays, but you're heavily limiting yourself if you stick to that old paradigm. This is the programming equivalent of using a hammer when a screwdriver would do a better job. It's perfectly acceptable (and often encouraged) to run a quick anonymous goroutine to handle simple processing shit like this instead of doing fancy memory tricks.
 
All the procedural programmers ITT are so hung up on how checking for odd and even numbers should be implemented, whereas us enlightened corporate Java engineers™ understand that it doesn't even matter, because what's really important is wrapping the algorithm in several levels of OOP abstractions so that down-stream code can look like this:

Java:
ParityPredicateBuilderFactory<Integer> factory
    = ParityPredicateBuilderFactory.getInstance<>(Integer.class);

ParityPredicateBuilder<Integer> builder = factory.createBuilder();
builder.setTrait(ParityTrait.ODDNESS);
builder.setZeroHandling(ParityZeroHandling.ZERO_IS_NEITHER_ODD_NOR_EVEN);

Predicate<Integer> predicate = builder.build();

boolean numberIsOdd = predicate.apply(Integer.valueOf(number));

// Not shown: 10,000 lines of code implementing the above classes.

EDIT: Added more Java
Needs more annotations. If you're not boiling applications down to a series of increasingly-opaque AOP kludges, are you even writing enterprise Java?
 
Last edited:
All the procedural programmers ITT are so hung up on how checking for odd and even numbers should be implemented, whereas us enlightened corporate Java engineers™ understand that it doesn't even matter, because what's really important is wrapping the algorithm in several levels of OOP abstractions so that down-stream code can look like this:

Java:
ParityPredicateBuilderFactory<Integer> factory
    = ParityPredicateBuilderFactory.getInstance<>(Integer.class);

ParityPredicateBuilder<Integer> builder = factory.createBuilder();
builder.setTrait(ParityTrait.ODDNESS);
builder.setZeroHandling(ParityZeroHandling.ZERO_IS_NEITHER_ODD_NOR_EVEN);

Predicate<Integer> predicate = builder.build();

boolean numberIsOdd = predicate.apply(Integer.valueOf(number));

// Not shown: 10,000 lines of code implementing the above classes.

EDIT: Added more Java
Hey, at least it has types. I've met a couple of people that literally can not conceive of code not looking like the worst stereotypical Enterprise Java bullshit turned loose in Python and Ruby, reinventing the Java standard library verbatim along the way. It was enough to make one want to go full Butlerian Jihad on all computers.
 
Is it possible to make money by developing an open source tool?

Like how many people make income just from some niche plugin that you can install with npm or gh cli and adding a website with a donation link:thinking:
 
Is it possible to make money by developing an open source tool?
Definitely, besides having a sponsor option at GitHub, most projects I see monetize by either:

- Licensing at different levels for which companies above a certain revenue have to pay.
- Having additional premium features locked behind a paywall (e.g. Bruno)
 
  • Like
Reactions: UERISIMILITUDO
I don't think most open source projects receive any donations.

But some open-source developers offer paid consulting or support services related to the open-source software they develop, to companies that use the software (see e.g. SQlite).

There are also dual-licensed projects like the Qt software library, where on the one hand it's available for free under the GPL license, but on the other hand you can also buy a commercial license if you're a company that can't or doesn't want to abide by the restrictions of the GPL.

All of the above only really works for open-source projects that are importantenough for companies to want to pay for them.
For the average Joe open source developer, the only common way to "monetize" one's niche open-source work is to present it as a "portfolio" to prospective employers to help you get hired for closed-source work.
 
Last edited:
...unless you're trying to handle data with a zero-copy model. Sharing memory is the only way to do proper zero-copy, by definition.
me said:
Don't jump off bridges.
>...unless you're trying to jump off a bridge. Jumping off a bridge is the only way to do proper bridge jumping, by definition.
 
What does one need to know to write C optimization running on a super computer. Asking for a friend. I only ever learned about loop unrolling on higher level C++.
 
  • Optimistic
Reactions: UERISIMILITUDO
Back