Works on my machine
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
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.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.
It's fine to be incorrect from time to time, but at least do some basic reading before doubling down.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.
Care to elaborate how they're retarded? They're extremely versatile, though you typically should useWhy 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?".
io.Reader
s to handle larger buffers.They merge functionality of view and vector. So their versatility is my biggest gripe.Care to elaborate how they're retarded? They're extremely versatile,
To quote one of my favorite programming proverbs (from here):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.
Share memory by communicating; don't communicate by sharing memory.
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.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.You can have two slices sharing underlying array and overwrite other by accident
I think you are correct on strategy for multi threading. But I think it might become as an issue even in single threaded context.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.
Also Rust slices cannot be expanded(afaik), and there is vector type. And that's my mine gripe with go slices.
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.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.
Needs more annotations. If you're not boiling applications down to a series of increasingly-opaque AOP kludges, are you even writing enterprise Java?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.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
Definitely, besides having a sponsor option at GitHub, most projects I see monetize by either:Is it possible to make money by developing an open source tool?
...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.Share memory by communicating; don't communicate by sharing memory.
...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.
>...unless you're trying to jump off a bridge. Jumping off a bridge is the only way to do proper bridge jumping, by definition.me said:Don't jump off bridges.