When the reviewer doesn't understand my Javascript it's his fault

gleemonk

Dear diary

In the last days of 2018 I got pulled into a style war that had apparently been waged under covers for a month.

Personae:

We really started out well
I'll do my best
I know JS!
I'll just get my tickets done
What is this? (me)

It went like this:

: Now that we have the visual design done, can start coding as everybody else is busy.
: I don't know frontend JS but I have domain knowledge.
weeks pass
: I wrote this code.
: Now can take over to implement the rest of the features
: This code of has no style! I'll use my own style because it's the best.
weeks pass
: Hey I can't really work all that much coming months. Didn't see that coming or anything.
: Let's add to the team!
weeks pass
: Hey please review these pull requests for me
: What the fuck ? in every file you touch you change all comments to use /*...*/ instead of // ...
: Progress! Use the .editorconfig
: I'm just going to ignore any of that.
: Hey your code doesn't follow the style!
: Your's doesn't either!
weeks pass
: What about my pull-requests?
: Hey I don't want to review commits that mix style changes with code changes!
: Say can you help me with some code-reviews?
: Sure. What is it?
: Both and work on this project, but refuses to do code-reviews with . They're piling up.
: I'll do a functional review and merge regardless of code-style to get things moving again.
: Fine by me, we'll do the code-style discussion next year.

Now at this point, I merge a few pull-requests of which are written in a style of his own devising. Company policy for Javascript would be AirBnB. But hey, discussion delayed. (Will probably just use an autoformatter in the future.)

Then I get to the pull-requests of .

: Say why do you write your local variables in ALL_CAPS?
: Ah you see these are constants. You probably don't know const yet. It's a new feature.
: I know what const is, but why are the names ALL_CAPS?
: Because constants are written in ALL_CAPS, you know that don't you!?
: Well, there's the convention to write global names in ALL_CAPS to differentiate them from local variables
: Yes see? Those are constants too!
: Well but these local variables are not constants!
: Are too! Because I used const to declare them. It really helps preventing errors! You really should learn some modern JS!
: I'm all for the use of const but I have a hard time reading this code...
: I get it you don't have much experience with JS
: No I mean that from my experience ALL_CAPS is used for globals and I get really confused reading this code
: You'll get used to how modern JS is written
: Nobody except you uses this style!
: How do you know? You're just lacking experience in the field.
: I've never seen code written like this...
: ...because you don't have the experience
: Forget it. I'll ignore code-style now so we'll have this discussion some other day. I'm also troubled by this long method.
: This is how JS is written
: It interleaves widget configuration data with network requests and their callbacks.
: Not my fault if you can't follow modern Javascript code
: It's over 200 lines and nests for more than ten levels!!
: That's because it uses closures!
: That's not a reason!
: Look here I define the callback to this request as a closure. Easy!
: Extract it and put it somewhere else!
: But then I don't have access to the local constants!
: All these variables in scope makes it really hard to follow the logic.
: It's constants! Get used to it! That's how JS is written now!
: And all this chart configuration data you can build in another function.
: But I need access to local constants! You really don't know how closures work do you?
: Pass them as parameters nice and explicit
: It's better to have them in local scope for speed
: Sigh. Why do you use timeouts to schedule network requests here?
: Because the chart library gets confused when data is loaded in parallel
: But then if one network request is delayed it will still get confused?
: Well no, I made the timeout really long, see here? 1.5 seconds!
: So it's slow for everybody...
: there's no other way
: ..and still it'll break if the responses are delayed for long enough
: But that's unlikely
: Unacceptable
: If only we could use promises!
: What do promises have to do with it?
: So we wouldn't get back the responses in parallel.
: JS doesn't have parallel execution
: Does too!
: No I mean the browser VM doesn't have parallel execution
: Read up! Promises are the future!
: What happens if the user interacts with the interface while it's loading?
: What should happen?
: I mean, wouldn't the requests interleave then?
: That's why this code is in onload
: Not after the first request, see if I do this while it's loading?
: Yeah it breaks, you should wait till it's loaded properly.
: Unacceptable
: We could disable the interface till it's all loaded but that's a lot of work
: Hacky but that would work.
: Ah if only we could use promises, would fix it instantly
: No it wouldn't.
: You don't know promises

Fucking insufferable type! I ended up refactoring and then fixing his shit.

kazitor

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

It's better to have them in local scope for speed

JS should definitely be written for clarity over speed unless benchmarking has already demonstrated a necessity. Like people saving array.length "for speed" even though modern engines cache it automatically.

Well no, I made the timeout really long, see here? 1.5 seconds!

Problem solved

If only we could use promises!

Is there a reason you can't? Browser compatibility? to look up specifics but const is also pretty new, possibly around the same time.

Promises are the future!

if only we could use promises, would fix it instantly

They don't really add functionality callbacks don't already provide; just make things neater.
But then it's new! shiny! Can't have JS without using All The Latest™.

That's why this code is in onload

Like, window.onload or the body's onload attribute? Are event handlers too difficult or something?

Zerosquare

A textbook case of Javascript Syndrome: the patient think (s)he's more clever than everyone else, while (s)he's in fact creating substandard equivalents of existing stuff (at best) or straight antipatterns (at worst).

(yeah, yeah, I know you can find people like this for any language. But the JS community seems to encourage this behaviour.)

Gribnit

@Zerosquare said in When the reviewer doesn't understand my Javascript it's his fault:

the JS community seems to encourage this behaviour.

Arguably the JS community is based on this behavior, starting from the language itself.

kazitor

@Gribnit "I'm a computer programmer! I must be smart!"

kazitor

@kazitor said in When the reviewer doesn't understand my Javascript it's his fault:

[Promises] don't really add functionality callbacks don't already provide; just make things neater.

Explanation for those who don't keep track of all of JS's latest adventures:

is claiming that

take_your_time(data, more_data).then(function callback(result) {
  console.log('got ', result);
});

solves a problem that

take_your_time(data, more_data, function callback(result) {
  console.log('got ', result);
});

apparently doesn't.

Promises are mostly for keeping things neat when multiple callbacks are being chained.

pie_flavor

@kazitor Well, that and having a standardized API for all that. I look at JS methods with random function parameters the way I look at C void *.

anotherusername

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

Why do you use timeouts to schedule network requests here?
: Because the chart library gets confused when data is loaded in parallel

: If only we could use promises!
: What do promises have to do with it?
: So we wouldn't get back the responses in parallel.

The fact that he thinks that promises would help with that is making my head hurt.

gleemonk

@kazitor said in When the reviewer doesn't understand my Javascript it's his fault:

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

It's better to have them in local scope for speed

JS should definitely be written for clarity over speed unless benchmarking has already demonstrated a necessity. Like people saving array.length "for speed" even though modern engines cache it automatically.

Yeah I omitted that exchange from the dialogue. It didn't go well:

: It's better to have them in local scope for speed
: Did you try?
: I know this! Saves RAM too.
: You have to measure it before you make that claim
: But how to measure?
: Check the browser console. I'm sure it's negligible.
: Why quibble? There is no time for this. We really must just avoid bloat wherever we can.

Well no, I made the timeout really long, see here? 1.5 seconds!

Problem solved

The good old sleep() to counter race-conditions.

If only we could use promises!

Is there a reason you can't? Browser compatibility? to look up specifics but const is also pretty new, possibly around the same time.

I'm not sure whether he meant browser support or he just didn't get around to implement it that way. There was code comments that had an example of how it would look with promises.

Oh no! Now I remember why he wants comments to be /*...*/: Because he needs to distinguish them from commented-out code:

: Using // ... is really standard for one-liners. Why change it?
: To distinguish them from commented-out code?! See if I comment-out a whole section here my editor will do the right thing.
: Well we don't keep commented-out code so I don't see how it's relevant.
: What if I want to leave my good ideas to the next guy?
: It makes the code harder to read! Put it in an experimental branch
: But then I don't find it anymore?!
: Exactly! If I have qualms to delete clever code I just stash it and then forget about it.
: But that would be really unproductive if I already figured it out. See the promises example here?
: Trivial
: You don't understand promises

I just went through and deleted all buried code when I refactored. Made the files 20% lighter.

Promises are the future!

if only we could use promises, would fix it instantly

They don't really add functionality callbacks don't already provide; just make things neater.
But then it's new! shiny! Can't have JS without using All The Latest™.

Apparently he's read about them but hasn't used them. Funny thing is I have. Just not on a project for this company.

That's why this code is in onload

Like, window.onload or the body's onload attribute? Are event handlers too difficult or something?

It was the DOM-loaded event. Another area where he was fuzzy with his knowledge, claiming that it was the same as window.onload. He's got that thing going where he claims indefensible absolutes and when you show him where he's wrong he'll just go "ah in that special case".

@anotherusername said in When the reviewer doesn't understand my Javascript it's his fault:

The fact that he thinks that promises would help with that is making my head hurt.

He's got this idea that promises can do done() for you once all requests are responded to. I couldn't get through to him that this still needs code from him. It's really a problem of lacking experience but refusing to accept that. When you show him there is a better way he'll refuse it for an invented reason or claim he just didn't get around to it.

wft

Do we work in the same team?
Nah, we never even dropped the “AirBnB style” name, but most other things check out.

PJH

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

I ended up refactoring and then fixing his shit.

I await the next round when he has to something small, and spends 95% of the 3 months doing it to revert all that refactoring...

boomzilla

@kazitor said in When the reviewer doesn't understand my Javascript it's his fault:

They don't really add functionality callbacks don't already provide; just make things neater.
But then it's new! shiny! Can't have JS without using All The Latest™.

Whenever I learn or get access to something new I find myself trying to use it all over. Sometimes it really does improve over my older way of doing things but I'm certain I over do it for a while during the period of time when it seems cool and fresh.

gleemonk

@wft said in When the reviewer doesn't understand my Javascript it's his fault:

Do we work in the same team?
Nah, we never even dropped the “AirBnB style” name, but most other things check out.

Or maybe I just anonymized that part and used AirBnB as a replacement?

Seriously though, you find that type everywhere. To some significant degree, I'm like that guy myself. It's just that I know my co-workers won't take my shit. So I don't push it like this JS "specialist". He'll have to adapt, or he won't work much longer with us.

@PJH said in When the reviewer doesn't understand my Javascript it's his fault:

I await the next round when he has to something small, and spends 95% of the 3 months doing it to revert all that refactoring...

Well also complained about having introduced some structure without his consent. To his credit, while complaining, he mentioned off-hand that the abstraction was probably a good thing. So it was not all bleak and I'm not too pessimistic on that front.

@boomzilla said in When the reviewer doesn't understand my Javascript it's his fault:

Whenever I learn or get access to something new I find myself trying to use it all over. Sometimes it really does improve over my older way of doing things but I'm certain I over do it for a while during the period of time when it seems cool and fresh.

It's necessary to explore how a new hammer works different nails. This guy was selling promises as a miracle cure before having tried them

PleegWat

For some reason, I'm reminded of my hatred of the phrase "It's not rocket science" when applied to software development.
Well, no. It's not. It's computer science. Which is an entirely different ballgame.

Benjamin Hall

@PleegWat said in When the reviewer doesn't understand my Javascript it's his fault:

For some reason, I'm reminded of my hatred of the phrase "It's not rocket science" when applied to software development.
Well, no. It's not. It's computer science. Which is an entirely different ballgame.

And rocket science isn't particularly difficult. It needs insane bravery (especially to formulate liquid fuels) and good, careful engineering, but it's not like QFT or any of the particularly abstruse fields of science.

Gąska

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

: Forget it. I'll ignore code-style now so we'll have this discussion some other day. I'm also troubled by this long method.
: This is how JS is written
: It interleaves widget configuration data with network requests and their callbacks.
: Not my fault if you can't follow modern Javascript code
: It's over 200 lines and nests for more than ten levels!!

Is it possible for you to just stand your ground on this and refuse to approve PR until he changes it no matter what?

dcon

@PJH said in When the reviewer doesn't understand my Javascript it's his fault:

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

I ended up refactoring and then fixing his shit.

I await the next round when he has to something small, and spends 95% of the 3 months doing it to revert all that refactoring...

Nah. He'll just continue working from his branch. "When I tried merging, I had all these conflicts. I know my code is right, so I'll just stay on my branch. You can merge it."

anotherusername

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

He's got this idea that promises can do done() for you once all requests are responded to. I couldn't get through to him that this still needs code from him. It's really a problem of lacking experience but refusing to accept that. When you show him there is a better way he'll refuse it for an invented reason or claim he just didn't get around to it.

Right, and they could... and so could callbacks. Depending on whether the callbacks have to be done sequentially, or just have to be processed sequentially to avoid confusing the chart API, there would be some way to set up a queue or something. You could write an AJAX function that fired off a whole bunch of requests in parallel, cached each response as it finished loading, and then when every request had completed, executed a callback and passed all of the responses in the order they were originally supposed to be in. You could even make it synchronously return a "wish-it-was-a-promise" and your code could mimic the .then chaining of promises.

In fact, that would almost be a trivial bit of code to write. The problem is that he can't come up with a solution to his problem, not that the language is missing features that would solve that problem for him. He'd have the same problem using promises because as @kazitor said they're just an extension of the callback concept. If he can't figure out how to synchronize a bunch of separate load event handler callbacks, then he'll have just as much trouble trying to synchronize a bunch of separate promises.

Gribnit

@Benjamin-Hall said in When the reviewer doesn't understand my Javascript it's his fault:

@PleegWat said in When the reviewer doesn't understand my Javascript it's his fault:

For some reason, I'm reminded of my hatred of the phrase "It's not rocket science" when applied to software development.
Well, no. It's not. It's computer science. Which is an entirely different ballgame.

And rocket science isn't particularly difficult. It needs insane bravery (especially to formulate liquid fuels) and good, careful engineering, but it's not like QFT or any of the particularly abstruse fields of science.

"Just throw the ball to where the receiver's gonna be when it gets there! It's not rocket science!"

DCoder

@Benjamin-Hall said in When the reviewer doesn't understand my Javascript it's his fault:

It needs insane bravery (especially to formulate liquid fuels) and good, careful engineering

According to Ignition and Things I Won't Work With, it also requires solid ice in your veins and, ah, a sense of adventure.

All you have to do is take the hexanitroisowurtzitane, which you have to have military connections to get ahold of apparently, or at least I should hope so, and some 98% hydrogen peroxide, no thank you, and co-crystallize from acetonitrile. <…> The experimental section of the paper is worth a read, and again, you can tell that Matzger’s group has good technique because everyone made it intact to the writing of the manuscript.

But I have to admit, I’d never thought much about the next analog of hydrogen peroxide. Instead of having two oxygens in there, why not three: HOOOH? Indeed, why not? This is a general principle that can be extended to many other similar situations. Instead of being locked in a self-storage unit with two rabid wolverines, why not three? Instead of having two liters of pyridine poured down your trousers, why not three? And so on – it’s a liberating thought. It’s true that adding more oxygen-oxygen bonds to a compound will eventually liberate the tiles from your floor and your windows from their frames, but that comes with the territory.

There’s a report from the early 1950s of a one-ton spill of [chlorine trifluoride]. It burned its way through a foot of concrete floor and chewed up another meter of sand and gravel beneath, completing a day that I’m sure no one involved ever forgot.

Gąska

@Benjamin-Hall said in When the reviewer doesn't understand my Javascript it's his fault:

@PleegWat said in When the reviewer doesn't understand my Javascript it's his fault:

For some reason, I'm reminded of my hatred of the phrase "It's not rocket science" when applied to software development.
Well, no. It's not. It's computer science. Which is an entirely different ballgame.

And rocket science isn't particularly difficult. It needs insane bravery (especially to formulate liquid fuels) and good, careful engineering, but it's not like QFT or any of the particularly abstruse fields of science.

Yeah, but try explaining to common folks why QFT is hard. It's no coincidence that the proverbial hardest thing in the world is actually relatively simple.

izzion

@Gąska
The hardest part about QFT is finding forum posts that are worth the quote AND true. Most of the time, forum posts are a combination of drivel and total bullshit.

Gąska

@izzion the hardest part about TLAs is warding off cheap trolls who deliberately choose to use the wrong definition even it's been explicitly stated earlier which one we're talking about.

Tsaukpaetra

@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:

@izzion the hardest part about TLAs is warding off cheap trolls who deliberately choose to use the wrong definition even it's been explicitly stated earlier which one we're talking about.

That's not the hardest part, I assure you!

The_Quiet_One

@Benjamin-Hall said in When the reviewer doesn't understand my Javascript it's his fault:

@PleegWat said in When the reviewer doesn't understand my Javascript it's his fault:

For some reason, I'm reminded of my hatred of the phrase "It's not rocket science" when applied to software development.
Well, no. It's not. It's computer science. Which is an entirely different ballgame.

And rocket science isn't particularly difficult. It needs insane bravery (especially to formulate liquid fuels) and good, careful engineering, but it's not like QFT or any of the particularly abstruse fields of science.

I've always thought rocket science was more about calculating the proper trajectory to have a rocket meet its target than merely building the rocket itself. Which is "simple" if you're going to the moon, but far more crazy if you're trying to intercept a comet or asteroid.

The_Quiet_One

@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:

@Benjamin-Hall said in When the reviewer doesn't understand my Javascript it's his fault:

@PleegWat said in When the reviewer doesn't understand my Javascript it's his fault:

For some reason, I'm reminded of my hatred of the phrase "It's not rocket science" when applied to software development.
Well, no. It's not. It's computer science. Which is an entirely different ballgame.

And rocket science isn't particularly difficult. It needs insane bravery (especially to formulate liquid fuels) and good, careful engineering, but it's not like QFT or any of the particularly abstruse fields of science.

Yeah, but try explaining to common folks why QFT is hard.

I'd probably start by simply... explaining what QFT is. Every time I watch something like PBS Space Time on the topic, I'm left with the conclusion that QFT is fucking hard.

boomzilla

@izzion said in When the reviewer doesn't understand my Javascript it's his fault:

The hardest part about QFT is finding forum posts that are worth the quote AND true

QooC thread has you covered.

Benjamin Hall

@The_Quiet_One said in When the reviewer doesn't understand my Javascript it's his fault:

@Benjamin-Hall said in When the reviewer doesn't understand my Javascript it's his fault:

@PleegWat said in When the reviewer doesn't understand my Javascript it's his fault:

For some reason, I'm reminded of my hatred of the phrase "It's not rocket science" when applied to software development.
Well, no. It's not. It's computer science. Which is an entirely different ballgame.

And rocket science isn't particularly difficult. It needs insane bravery (especially to formulate liquid fuels) and good, careful engineering, but it's not like QFT or any of the particularly abstruse fields of science.

I've always thought rocket science was more about calculating the proper trajectory to have a rocket meet its target than merely building the rocket itself. Which is "simple" if you're going to the moon, but far more crazy if you're trying to intercept a comet or asteroid.

These days, that's a solved problem. The orbits are well plotted and while the orbital math is obnoxious, it's merely classical Newtonian physics.

Here's a passage from an intro to a QFT book:

And those are the baseline equations. Comparing those to the Hohmann equations found on https://en.wikipedia.org/wiki/Hohmann_transfer_orbit.

pie_flavor

@Benjamin-Hall Spooky symbols. Spoooooooky.
They don't, on the whole, look hard per se, it's just notation I don't know yet.

Benjamin Hall

@pie_flavor said in When the reviewer doesn't understand my Javascript it's his fault:

@Benjamin-Hall Spooky symbols. Spoooooooky.
They don't, on the whole, look hard per se, it's just notation I don't know yet.

There's a lot of detail embedded in those equations. And those are the ones that you have to be automatically familiar with to begin the course. The actual equations are much much nastier.

And compressed notation often hides a lot of issues. Take, for example, the Einstein Field Equations from general relativity:

That's 10 coupled, non-linear, partial-differential equations. And to even begin to solve them, you have to specify T_μν, a tensor (called the stress-energy tensor) that describes the distribution of matter and energy in the region over which to solve the equations. Which is a function of time.

cvi

@pie_flavor said in When the reviewer doesn't understand my Javascript it's his fault:

They don't, on the whole, look hard per se, it's just notation I don't know yet.

The key thing is the "recognize" part. The equations themselves don't say that much out of context, but are meaningful and central in their (sub-)fields. It's basically a simple self-test on whether or not you're familiar the prerequisites. The equations are simple enough that even though I'm familiar with different notations for some of them, I can guess/translate what they are (or at least know where I should start reading)*.

On a side note, if you're not familiar with bra-ket notation, that one is actually worth studying and understanding if you intend to do anything mathy even if it's unrelated to quantum physics. It's a very nice and general abstraction that helps bridge linear algebra and analysis.

(*) The one that really escapes me is the one with the J_{\pm}. It's been a while, though.

Benjamin Hall

@cvi said in When the reviewer doesn't understand my Javascript it's his fault:

(*) The one that really escapes me is the one with the J_{\pm}. It's been a while, though.

That's the raising/lowering operators for angular momentum states, dealing with conservation and allowed states. It's quantum.

cvi

@Benjamin-Hall said in When the reviewer doesn't understand my Javascript it's his fault:

That's the raising/lowering operators for angular momentum states, dealing with conservation and allowed states. It's quantum.

Ah, ok. Figured it'd be quantum stuff (if not for the notation, then for the raising/lowering of indices). The double indices made me think of spherical harmonics/orbitals, so didn't get that quite right then.

Benjamin Hall

@cvi said in When the reviewer doesn't understand my Javascript it's his fault:

@Benjamin-Hall said in When the reviewer doesn't understand my Javascript it's his fault:

That's the raising/lowering operators for angular momentum states, dealing with conservation and allowed states. It's quantum.

Ah, ok. Figured it'd be quantum stuff (if not for the notation, then for the raising/lowering of indices). The double indices made me think of spherical harmonics/orbitals, so didn't get that quite right then.

It is the spherical harmonics, just for more complex things than simple 1-electron orbitals. |j,m> are the equivalents of |l,m> for total angular momentum (rather than for a single orbital)

topspin

@Benjamin-Hall I feel that’s a weird take on it. Yeah, the trajectory equations may be solved, but it’s still pretty fucking hard engineering. According to Wikipedia, just 3 years ago SpaceX managed to land the first stage rocket for the first time, and landing the second stage is only just planned for the future.
And surely, almost everything that’s not beyond the standard model is “solved” if you just apply enough of (idk really, you’re the expert) the Schrödinger equation to everything. Which obviously won’t get you anywhere that’s not completely trivial.

Benjamin Hall

@topspin said in When the reviewer doesn't understand my Javascript it's his fault:

@Benjamin-Hall I feel that’s a weird take on it. Yeah, the trajectory equations may be solved, but it’s still pretty fucking hard engineering. According to Wikipedia, just 3 years ago SpaceX managed to land the first stage rocket for the first time, and landing the second stage is only just planned for the future.

But that's rocket engineering, not rocket science . As I said, the engineering is hard but the fundamental science is well-understood. It's one of those simple but difficult things.

And surely, almost everything that’s not beyond the standard model is “solved” if you just apply enough of (idk really, you’re the expert) the Schrödinger equation to everything. Which obviously won’t get you anywhere that’s not completely trivial.

That's the problem. The Schrödinger equation only gets you a tiny bit of the way--it's not even relativistic. For that you need the Dirac equations (which are more of a beast). And that's only the tiniest toe-hold to QFT. CF the Feynman diagrams. QFT is weird and the math starts at way-too-hard and gets worse from there.

cheong

Kind of reminding me of a previous attempt to "async everything".

If the program logic require something to be done in sequence, let it be synchronous operation. Using things like Sleep() will just make everybody's head hurts and create non-debug-able problem when there is off-site user with slow internet speed(because the problem would not be reproducible on your end).

Similarly, if an operation will make your application/webpage in inconsistent state so the user really shouldn't interact in between, protect it with model dialog or some kind of BlockUI() call.

Taking general advice and think it should apply to everything is plain stupid. You really don't understand a rule until you know when the rules shouldn't apply.

topspin

@Benjamin-Hall I'm sure there's still a lot of actual science happening to enable that engineering, even in the pedantic reading of science.
And the point I was trying to make was: the standard model is (supposedly) well understood, so you could in theory solve everything (that doesn't go beyond it) going from there if you just do enough number crunching on the maths. Which, of course, you actually can't, because the required processing power explodes immediately.
(The best way to simulate the universe would probably be to build the universe)

Maybe this discussion should get Jeffed?

Gribnit

@topspin said in When the reviewer doesn't understand my Javascript it's his fault:

Maybe this discussion should get Jeffed?

Somehow this must tie back to using Javascript that you don't understand yet then claiming nobody understands it, is the alternative. Doesn't seem exactly a fridge too far, really.

dkf

@Benjamin-Hall said in When the reviewer doesn't understand my Javascript it's his fault:

And those are the baseline equations.

That's a bit nastier than MHD, which is itself very nasty.

(Magnetohydrodynamics — basically plasma physics and solar/stellar physics — is non-linear and non-local, and both in ways that mean you can't really use any sort of linear approximations in any cases you care about. I know a little about it from a previous project, where we tried very hard to not require running simulations because of the difficulty of getting them right…)

HardwareGeek

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

Now I remember why he wants comments to be /.../: Because he needs to distinguish them from commented-out code

gleemonk

@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:

Is it possible for you to just stand your ground on this and refuse to approve PR until he changes it no matter what?

That was the case originally because didn't want to touch his branches. Tough actually would have had more luck with than me getting convoluted code into master. Had there not been the style disagreements, he might have gotten off easy.

But actually, managed to get his code through! In the end I opted to merge it with his promises to clean up after. Not because I expected much to happen, but because I was tasked with implementing a feature he didn't get around to anymore. In the end I knew I'd refactor anyways to get the parts I needed. To his credit, he did start extracting some code from that god-method. Just didn't get very far before I went through with a hacksaw.

Zerosquare

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

In the end I opted to merge it with his promises to clean up after.

I see what you did there...

gleemonk

@cheong said in When the reviewer doesn't understand my Javascript it's his fault:

Kind of reminding me of a previous attempt to "async everything".

Yeah when Nodejs came up i wondered why not just introduce parallel processes, would be easier and a solved problem. With better scaling too.

If the program logic require something to be done in sequence, let it be synchronous operation. Using things like Sleep() will just make everybody's head hurts and create non-debug-able problem when there is off-site user with slow internet speed(because the problem would not be reproducible on your end).

Similarly, if an operation will make your application/webpage in inconsistent state so the user really shouldn't interact in between, protect it with model dialog or some kind of BlockUI() call.

The part about the user interaction during loading introduced a little complexity into my rewrite, but not much. In the end if you don't stubbornly try to cram all logic into a single function, it becomes easy to solve these issues. The problem was with not accepting it was a non-trivial problem. He had to make amendments for special cases everywhere and things broke left and right as a consequence.

Once you start setting up event-handlers within event-handlers it's time to take a step back and restructure the code.

Taking general advice and think it should apply to everything is plain stupid. You really don't understand a rule until you know when the rules shouldn't apply.

Amen.

gleemonk

@Zerosquare said in When the reviewer doesn't understand my Javascript it's his fault:

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

In the end I opted to merge it with his promises to clean up after.

I see what you did there...

That was entirely unintended I promise.

boomzilla

@topspin said in When the reviewer doesn't understand my Javascript it's his fault:

Maybe this discussion should get Jeffed?

We're currently working on solving the equations required to make this happen.

cvi

@boomzilla said in When the reviewer doesn't understand my Javascript it's his fault:

We're currently working on solving the equations required to make this happen.

I'm guessing that the added ~~boundary condition~~central equation of work_mods = 0 eliminates most well-known solutions.

topspin

@boomzilla said in When the reviewer doesn't understand my Javascript it's his fault:

@topspin said in When the reviewer doesn't understand my Javascript it's his fault:

Maybe this discussion should get Jeffed?

We're currently working on solving the equations required to make this happen.

I hear they’re highly non-linear and involve bending the knee.

coderpatsy

@topspin said in When the reviewer doesn't understand my Javascript it's his fault:

I hear they’re highly non-linear and involve bending the knee.

The mods are using Enlightment?

HardwareGeek

@coderpatsy I don't think anyone would accuse our mods of being enlightened.