TRWTF is the entire JS ecosystem
-
@PleegWat said in TRWTF is the entire JS ecosystem:
More love for
longjmp
!I've actually seen multiple appropriate uses for that. (They were deeply nasty hacks that did stuff impossible otherwise, such as inverting a system event loop. Truly horrendous…)
-
@dkf A colleague told a story once about a third-party module which had a nasty habit of occasionally segfaulting. So they'd longjump out and reinitialize the thing rather than losing the process.
To me, longjmp seems like something where only after you've exhausted every other option imaginable and still can't solve your problem, you might consider using it.
-
@PleegWat Yes. It's got all sorts of potential side effects because it does. not. follow. the. rules of stack memory management, but it gains superpowers by doing so. OK, those superpowers are definitely of a distinct chaotic evil alignment, but sometimes it's the only way.
It's more evil than the implementations of green threads, exceptions and generators. Combined.
-
@dkf said in TRWTF is the entire JS ecosystem:
It's more evil than the implementations of green threads, exceptions and generators. Combined.
I have on occasion considered some of these things, but I've never gone beyond simple exercises to proof to myself I could do it. I guess I value my sanity too much.
-
I once saw goto implemented in Python, but I'm having trouble finding it.
-
@kazitor said in TRWTF is the entire JS ecosystem:
I once saw goto implemented in Python, but I'm having trouble finding it.
Because you don't know where it went?
-
@kazitor said in TRWTF is the entire JS ecosystem:
I once saw goto implemented in Python, but I'm having trouble finding it.
Was it this?
Personally, I prefer
comefrom
overgoto
-
@Jaloopa said in TRWTF is the entire JS ecosystem:
@kazitor said in TRWTF is the entire JS ecosystem:
I once saw goto implemented in Python, but I'm having trouble finding it.
Was it this?
Personally, I prefer
comefrom
overgoto
Well that’s implemented by every language that has exceptions... but INTERCAL did it frist.
-
@Jaloopa Yes, I think so. Nice sleuthing.
-
@Jaloopa said in TRWTF is the entire JS ecosystem:
Personally, I prefer
comefrom
overgoto
its use in production code is discouraged since it can lead to surprising behaviour.
-
@dkf said in TRWTF is the entire JS ecosystem:
exceptions
Didn't early implementations of exceptions in e.g. C++ use longjmp() et al.?
FWIW, longjmp can ve used to kinda emulate something like exceptions in C. Wouldn't really recommend it, it's not exactly painless. (IIRC Symbian did that plus a manual cleanup stack. It was terrible.)
-
@cvi said in TRWTF is the entire JS ecosystem:
longjmp can ve used ... it's not exactly painless.
Ve haff vays to make you not longjmp!
-
@cvi said in TRWTF is the entire JS ecosystem:
Didn't early implementations of exceptions in e.g. C++ use longjmp() et al.?
It's not that different really, except that the compiler inserts code to handle cleanup for you (including when an exception is just passing through; in reality, it very much doesn't but instead there's a stack of handlers that are peeled off one by one), and is a good deal less aggressive about saving all registers, which makes context saving enormously cheaper.
So actually not like
longjmp()
much at all.
-
@HardwareGeek Ze keys are right next to each other. And very tiny on mobile keyboards.
-
@cvi oh, are you using @Tsaukpaetra's nonsense?
-
@pie_flavor I have been summoned, and so I appear.
-
@pie_flavor I assumed HG was commenting on the typo in my post ("be" -> "ve"). But perhaps that escaped your attention? Because the "b" and "v" keys are indeed next to each other...
-
@cvi Yes. You have seen the keyboard @Tsaukpaetra uses, have you not?
-
@pie_flavor I don't think I have, so a link or picture from @Tsaukpaetra would be much appreciated.
-
@kazitor said in TRWTF is the entire JS ecosystem:
@pie_flavor I don't think I have, so a link or picture from @Tsaukpaetra would be much appreciated.
It's really nothing special....
-
@Tsaukpaetra Oh, that keyboard. I thought we were talking physical.
Mobile is different and all.
-
@pie_flavor Not really.
In my defense... If I were using that, I'd consider pointing out that two specific keys are close to each other somewhat superfluous.
@Tsaukpaetra :butwhy.xkb:
-
@cvi said in TRWTF is the entire JS ecosystem:
@Tsaukpaetra :butwhy.xkb:
Because I love all the extra screen estate saved. The arrow keys are also dismiss-able for even more savings!
-
@Tsaukpaetra My keyboard doesn't impinge on my screen space at all
-
@kazitor said in TRWTF is the entire JS ecosystem:
@Tsaukpaetra My keyboard doesn't impinge on my screen space at all
I've seen other's screenshots demonstrate that they have maybe two lines of text in the composer available to them. What magic are you using where this isn't happening to you?
-
@Tsaukpaetra I don't use mobile
(and I don't use the on-screen keyboard either, obviously)
-
@kazitor said in TRWTF is the entire JS ecosystem:
@Tsaukpaetra I don't use mobile
(and I don't use the on-screen keyboard either, obviously)
Oh, you should try it! (the on screen keyboard). In most machines in takes up minimum quarter of the screen!
-
@levicki generally it's called
goto fail
.
-
@levicki said in TRWTF is the entire JS ecosystem:
@Gąska said in TRWTF is the entire JS ecosystem:
@levicki I'm all for banning all human-written
JMP
instructions.You may not be aware but some humans are quite skilled with instruction scheduling and code optimization and can still beat a compiler generated code.
It was already a marginal difference ten years ago. And with each year it's only getting smaller. Better focus on big picture algorithms.
Compiler can recognize standard code patterns and optimize the shit out of those (basically instead of teaching people to not write bad code compilers are silently fixing it for them)
It's not 2001 anymore. Optimizing compilers are way more advanced than that. And I mean way more. Look at this list of optimizations that LLVM can perform (the "Transform Passes" section). Even if it is theoretically possible for a human to do all that by themselves, nobody is capable of consistently applying them across entire codebase that's hundreds of thousands or millions LOC worth of Java/C#/C++. And remember to look up a new edition of Intel Optimization Reference Manual and AMD Software Optimization Guide, to know what is optimal now and what isn't anymore.
Yes, I realize there are still some areas where nothing can beat hand-written assembly. But these are few and far between, and 99.9% of programmers will never encounter such case. The rules are for 99.9%. When you're that 0.1%, you most likely know what you're doing and when it's okay to break the rules (even scribbling over unallocated memory is okay sometimes).
If used right,
goto
is no worse than other language features.If used right,
malloc
is no worse than GC or smart pointers. But there's a very good reason why everyone sane has moved to GC and smart pointers long ago.The hate for it is just irrational.
It's a very handy rule of thumb. Teaching entire generations of programmers to never use goto has saved the IT industry tens if not hundreds of billions of dollars in dealing with fallout from fatal bugs caused by its improper use. Yes, you can write horrible buggy code with any language and any programming constructs, but goto makes it much easier.
I'll take goto programming over Christmas Tree programming any day.
Have you considered neither?
-
@Gąska said in TRWTF is the entire JS ecosystem:
Yes, you can write horrible buggy code with any language and any programming constructs, but goto makes it much easier.
Yes. And a blanket ban on goto (or any other feature that can be misused) is addressing the symptom, not the root of the problem.
It was once thought that better languages and tools would make it easy for everyone to write good code. Except it turned out that:
- bad developers will write bad code, no matter how clean and well-designed the language and tools they use
- improvements that make good developers more productive also make bad developers appear more productive, so the global quality of software doesn't rise (or even falls)
-
@Zerosquare said in TRWTF is the entire JS ecosystem:
improvements that make good developers more productive also make bad developers appear more productive
They are more productive. Unfortunately, they are more productive at creating .
-
@Gąska said in TRWTF is the entire JS ecosystem:
Yes, I realize there are still some areas where nothing can beat hand-written assembly. But these are few and far between, and 99.9% of programmers will never encounter such case. The rules are for 99.9%. When you're that 0.1%, you most likely know what you're doing and when it's okay to break the rules (even scribbling over unallocated memory is okay sometimes).
FWIW, I'm the sort of guy that has this situation (for some of my programs, the ones that are really time critical and running on custom hardware) so the probability that the rest of you do is really low.
-
@levicki said in TRWTF is the entire JS ecosystem:
succeedded1
succeedded2
succeedded3
From the people who brought you
Referer
-
Can someone point me to the 'PHP == TR ' so I can post this article and
-
@Flips said in TRWTF is the entire JS ecosystem:
Can someone point me to the 'PHP == TR '
Google says this:
-
@Zerosquare said in TRWTF is the entire JS ecosystem:
@Gąska said in TRWTF is the entire JS ecosystem:
Yes, you can write horrible buggy code with any language and any programming constructs, but goto makes it much easier.
Yes. And a blanket ban on goto (or any other feature that can be misused) is addressing the symptom, not the root of the problem.
If you cannot address the root of the problem (and you cannot address the root of this problem), addressing symptoms is the next best thing you can do.
It was once thought that better languages and tools would make it easy for everyone to write good code. Except it turned out that:
- bad developers will write bad code, no matter how clean and well-designed the language and tools they use
Bad, but still much better than what they would have written in C. At least you don't have memory safety issue every other line.
- improvements that make good developers more productive also make bad developers appear more productive, so the global quality of software doesn't rise (or even falls)
There are many kinds of productivity. One of them is how easy it is to shoot yourself in the foot. Goto has much higher foot-shooting potential than if/else. So does manual memory management over GC. If we forced everyone to write in Rust (and not allow them to use
unsafe
keyword), it would hugely reduce number of bugs in code, especially multithreaded code - because the language simply doesn't allow those bugs to exist in valid code. Even the worst of the worst programmers would produce less bugs. Won't eradicate all bugs, of course, and their code will be crappy as always, but at least it'd have less bugs.
-
@Gąska
What? You forgot that the last two pages is filled with offtopic conversations, by amnesia-struck people with the attention-span of a goldfish? And maybe, maybe... you are one of them
-
@dkf said in TRWTF is the entire JS ecosystem:
I'm the sort of guy that has this situation […] so the probability that the rest of you do is really low.
That's why I always put a bomb into my carry-on luggage. The odds of having two bombs on a plane are really really low!
-
@dkf Do tell us more.
-
@Flips said in TRWTF is the entire JS ecosystem:
Can someone point me to the 'PHP == TR ' so I can post this article and
At least A==B is always the same as B==A in PHP, whereas I'm not sure in some other languages (especially JS and C++)…
-
You can never have enough "PHP is TR " topics. I should know, I work with PHP code every day.
-
@dkf said in TRWTF is the entire JS ecosystem:
@Flips said in TRWTF is the entire JS ecosystem:
Can someone point me to the 'PHP == TR ' so I can post this article and
At least A==B is always the same as B==A in PHP, whereas I'm not sure in some other languages (especially JS and C++)…
You can do this in many other languages too. Special mention goes to Python, because it's been widely known that
==
can mean completely different things than the equality one might be thinking off (I'm looking at you, numpy).
-
@DCoder said in TRWTF is the entire JS ecosystem:
You can never have enough "PHP is TR " topics. I should know, I work with PHP code every day.
You might find this handy:
-
Might be too late for that…
-
@marczellm said in TRWTF is the entire JS ecosystem:
Do tell us more.
It's a neural simulation running on what's effectively an embedded core (where what it's embedded in is a very funky multicast hardware communications system). For various reasons, the innermost simulation loop has to be very very efficient in order to pack more individual neuron simulations in within a timer tick; we can spill the simulations across multiple cores but that causes cascading inefficiencies so we want to avoid it. And this is a CPU core without floating point support, so everything is in fixed point.
For one of the models we support, it is possible to do the update in an (amortised IIRC) 5 instructions per neuron, provided we take advantage of a great deal of knowledge of the overall program (including the fact that we don't have interrupts on at this point). The compilers we've tried (both gcc and armcc) don't find the instruction sequence that does this; IIRC the minimum they find is about 20 instructions per neuron, and on the particular CPU that this is running on (where we can calculate exactly how long everything takes), that takes around 4 times longer and greatly reduces the density we can run the system at. The instruction sequence we're using has the equivalent of things like gotos in it, and using registers that the standard ARM ABI says should be reserved for the caller or things that are called (but since we control everything including the hardware interrupts, we know they don't apply).
It's all slightly insane, but it's mostly insane in a good way and not a WTF way.
-
@Gąska said in TRWTF is the entire JS ecosystem:
@DCoder said in TRWTF is the entire JS ecosystem:
You can never have enough "PHP is TR " topics. I should know, I work with PHP code every day.
You might find this handy:
It's not a question about installing the JDK…
-
@levicki said in TRWTF is the entire JS ecosystem:
The hate for [
goto
] is justirrationalstatistical.Most languages have better "jump" constructs available for most situations.
goto
is very rarely an improvement over those.
-
@boomzilla said in TRWTF is the entire JS ecosystem:
Most languages have better "jump" constructs available for most situations.
goto
is very rarely an improvement over those.I had a correct use of
goto
today that wasn't building a state machine!We were rewriting some (horrible) code to add logging statements (to hunt down why things were crashing hard when we overloaded them) and had need to split this:
if (condA() || condB()) { if (condA() && condC()) { actA(); } else { actB(); } }
into this:
if (condA() || condB()) { if (condA()) { if (condC()) { log("this is place #1"); actA(); } else { log("this is place #2"); goto otherclause; } } else { log("this is place #3"); otherclause: actB(); } }
Of course, the real
cond…()
andact…()
were not simple, attaching a debugger was completely impossible as this was both inside an interrupt handler and highly timing-sensitive, and we wanted to edit the code as little as possible to avoid adding more screwups while debugging. By using thegoto
, we could replicate the old branching behaviour without cut-n-pasting the code, which was useful because we were running out of instruction memory too.(We'll refactor it next week now that we've found (what we think are) the bugs in it; that'll probably end up with this particular function actually looking more like the pseudocode above than it does right now.)
-
@Gąska might as well JMP! JMP!
-
@CHUDbert Go ahead and JMP