I think I know what makes a truly competent programmer

RaceProUK

@dkf said in I think I know what makes a truly competent programmer:

Accountants don't like that either.

So accountants want accurate figures, but don't want accurate figures?

...

wft

@RaceProUK said in I think I know what makes a truly competent programmer:

So accountants want accurate figures, but don't want accurate figures?

Exactly. That's humans for you.

And your job is to make them happy, or else.

darkmatter

@RaceProUK said in I think I know what makes a truly competent programmer:

So accountants want accurate figures, but don't want accurate figures?

The figures must be accurate but also consistent, even if that means they're not the same figures!

fun distinction - I once included a toggle switch for some sales displays that allowed users to choose "Accurate" or "Consistent", because the reporting application I was converting for them had previously rounded everything to the nearest whole $ but did so at the lowest level and then totaled the sales up after rounding. Which resulted in an inaccuracy of somewhere between $-500 to $500 (~up to half the number of records added to make the totals) compared to the amount you get if you added all the sales and then rounded the final total.

They could not grasp how that was incorrect (sadly) and refused to sign off on the work as correct unless it matched to the previous system (ie, consistent). I couldn't stand how awful that was, so I added the toggle to let them see that the numbers could match to their old system, but that the total would then be wrong.

dkf

@RaceProUK said in I think I know what makes a truly competent programmer:

So accountants want accurate figures, but don't want accurate figures?

They want the figures that you present them to be exactly identical to the figures that they calculate for you. Which will have started from a load of data that was entered by hand, but if they make a mistake it is your fault, and if they apply the wrong model it is your fault, and …

I despise being audited because the auditors are so stupid (and according to my brother, they're taught to be like that; he hated doing audits).

anotherusername

@wft The correct way to do that is to pay them 1024/7*months - payments made previously, rounded to the nearest cent. Each month your payment will correct, as closely as possible, for the rounding errors made previously.

You pay them as follows:

Month 1: $146.29
Month 2: $146.28
Month 3: $146.29
Month 4: $146.28
Month 5: $146.29
Month 6: $146.28
Month 7: $146.29
Total: $1024.00

This should result in the total always being exactly the same as the sum of the individual payments.

Code:

for (var total = 102400, months = 7, sum = 0, i = 1; i <= months; ++ i) {
  var p = Math.round(total / months * i - sum);
  console.log("Month " + i + ": " + ("$" + p).replace(/(..)$/, ".$1"));
  sum = Math.round(sum + p);
}
console.log("Total: " + ("$" + sum).replace(/(..)$/, ".$1"));

Alternately, you do that to correct the units of work done, so at the end of the project the total work is 10 fucktons of shit exactly. Then, instead of invoicing only for that month, you invoice each month for the total number of fucktons of shit done so far, and have a line item to subtract the payments previously made, resulting that the amount owed that month corrects for rounding errors. At the end of the contract, both the fucktons of shit and the amount paid should be exactly what was originally agreed upon.

wft

@anotherusername This is actually the most valuable post I have read in a while on the internets. Sorry I can only upvote it once.

Greybeard

In this industry, a "senior" developer is someone who isn't fresh out of high school. That's why they have to come up with all sorts of adjectives for the people with real experience.

staff
principal
distinguished

Or they use another profession entirely. (I am not an architect, I do not design buildings.)

FrostCat

@wft said in I think I know what makes a truly competent programmer:

In the first case, you end up overpaying 3 pennies, and underpaying 4 in the second case.

Any payroll software that isn't shit can handle that. My paychecks sometimes bounce up and down a penny to make sure I'm getting the right amount. I'm not sure the details but it involves either looking back at previous payments or looking forward to estimated future ones. It's a solved problem, though.

blakeyrat

@wft said in I think I know what makes a truly competent programmer:

This is actually the most valuable post I have read in a while on the internets.

... seriously? That function's in literally every software product ever made that deals with moneys.

(Except usually in a better language.)

anotherusername

@blakeyrat said in I think I know what makes a truly competent programmer:

... seriously? That function's in literally every software product ever made that deals with moneys.

...so you'd think people wouldn't constantly get it wrong, but...

And then to top it off, you've got to explain it to people who want to know why their paycheck goes up or down by a few pennies when the number of hours worked is exactly the same.

@blakeyrat said in I think I know what makes a truly competent programmer:

(Except usually in a better language.)

I spitballed something in the closest language at hand. Assuming you're reading this in a web browser, you probably have the capability to run it.

FrostCat

@blakeyrat said in I think I know what makes a truly competent programmer:

All my products have blades.

https://wiki.guildwars2.com/images/0/0c/Tempered_Spinal_Blades.jpg

FrostCat

@anotherusername said in I think I know what makes a truly competent programmer:

And then to top it off, you've got to explain it to people who want to know why their paycheck goes up or down by a few pennies when the number of hours worked is exactly the same.

At that point, you just tell them to watch Superman III, or Office Space. When they come back, you say "remember the half-pennies? That's what's going on. You earn $146.285 each paycheck, but we can't give you half a cent."

anotherusername

@FrostCat oh, sure, they'll want the half cents to add up when it favors them. But in the other columns, where the half cents are going to insurance/government...

FrostCat

@anotherusername said in I think I know what makes a truly competent programmer:

But in the other columns, where the half cents are going to insurance/government.

"Here is the front desk phone number for the IRS. Good luck."

Sometimes I play hardball. When I worked in a convenience store, I would from time to time get assholes trying to buy cigs or booze without ID. If the attempt to argue went on long enough, I would ask them if they were willing to pay the $1000 fine if I got caught, and find me a new job as well. (The other thing I used maybe once or twice was "look, I'm just the cashier; I don't make policy, but I do get fired if I break it, so I'm not going to. If you want to complain, then call the 800 number.")

Jaime

@anotherusername said in I think I know what makes a truly competent programmer:

And then to top it off, you've got to explain it to people who want to know why their paycheck goes up or down by a few pennies when the number of hours worked is exactly the same.

The evil side of me prefers to use a non-deterministic algorithm to make the explanation as awkward as possible.

blakeyrat

@FrostCat Dafuq. How is she holding that up?

blakeyrat

@FrostCat said in I think I know what makes a truly competent programmer:

At that point, you just tell them to watch Superman III, or Office Space.

One of the funniest gags in Office Space is how nobody understands what's going on until they explain it by saying, "you know, like in Superman III", then everybody immediately gets it.

flabdablet

@accalia said in I think I know what makes a truly competent programmer:

do everything in UTC

is not a blanket fix. If you're writing software that needs to specify times at which future events happen, it's safer to store those as localtime+tz. The possibility of essentially arbitrary tz and DST rule changes means you can never be completely sure that a future localtime converted to UTC now is going to come out the same as if it were converted to UTC then.

FrostCat

@blakeyrat said in I think I know what makes a truly competent programmer:

How is she holding that up?

A wizard did it.

blakeyrat

@FrostCat She's wearing an anvil necklace as a counter-weight.

FrostCat

@blakeyrat said in I think I know what makes a truly competent programmer:

She's wearing an anvil necklace as a counter-weight.

I figured the two round things on the backpack base were jet engines.

Sure, it raises more questions, but then you just repeat the MST3K Mantra.

flabdablet

@boomzilla said in I think I know what makes a truly competent programmer:

I thought javascript used UTF-16.

I think you thought correctly.

'💩'.length is a valid Javascript expression that evaluates to 2.

boomzilla

@flabdablet said in I think I know what makes a truly competent programmer:

@boomzilla said in I think I know what makes a truly competent programmer:

I thought javascript used UTF-16.

I think you thought correctly.

'💩'.length is a valid Javascript expression that evaluates to 2.

JavaScript’s internal character encoding: UCS-2 or UTF-16? · Mathias Bynens

ECMAScript, the standardized version of JavaScript, defines how characters should be interpreted:

A conforming implementation of this International standard shall interpret characters in conformance with the Unicode Standard, Version 3.0 or later and ISO/IEC 10646-1 with either UCS-2 or UTF-16 as the adopted encoding form, implementation level 3. If the adopted ISO/IEC 10646-1 subset is not otherwise specified, it is presumed to be the BMP subset, collection 300. If the adopted encoding form is not otherwise specified, it is presumed to be the UTF-16 encoding form.

In other words, JavaScript engines are allowed to use either UCS-2 or UTF-16.
...
JavaScript engines are free to use UCS-2 or UTF-16 internally. Most engines that I know of use UTF-16, but whatever choice they made, it’s just an implementation detail that won’t affect the language’s characteristics.

The ECMAScript/JavaScript language itself, however, exposes characters according to UCS-2, not UTF-16.

Ain't nobody got time for this unicode shit.

flabdablet

@RaceProUK said in I think I know what makes a truly competent programmer:

Windows does the same thing; it also uses UCS-2 internally

It really, really doesn't. Its native "unicode" text is indeed a 16-bit character type, and it was indeed first implemented back when Unicode had only 2¹⁶ code points, but you really can paste 💩 into a Windows text file and save it in Unicode mode, and what you get is a file containing the bytes FF FE 3D D8 A9 DC - the little-endian UTF-16 encoding of a byte-order mark U+FEFF and a pile-of-poo emoji U+1F4A9.

RaceProUK

@flabdablet If only I acknowledged that… oh wait, I did:

@RaceProUK said in I think I know what makes a truly competent programmer:

although IIRC a lot of the APIs do automagically treat UTF-16 correctly as well

flabdablet

@boomzilla said in I think I know what makes a truly competent programmer:

The ECMAScript/JavaScript language itself, however, exposes characters according to UCS-2, not UTF-16

The ECMAScript language does no such thing.

The only mention of UCS-2 in the spec is here:

A conforming implementation of this Standard shall interpret characters in conformance with the Unicode Standard, Version 3.0 or later and ISO/IEC 10646-1 with either UCS-2 or UTF-16 as the adopted encoding form, implementation level 3. If the adopted ISO/IEC 10646-1 subset is not otherwise specified, it is presumed to be the BMP subset, collection 300. If the adopted encoding form is not otherwise specified, it presumed to be the UTF-16 encoding form.

For characters inside the BMP - that is, all valid Unicode code points representable as single unsigned 16-bit ints - UCS-2 and UTF-16 encodings are identical. Every syntactical element of an ECMAScript program other than string literals is composed of just such characters, so the only way to decide whether UCS-2 or UTF-16 is "the" coding actually used by ECMAScript is to examine the rules for handling strings.

Turns out that an ECMAScript string value is a just a sequence of uint16 with no restriction at all on contents:

4.3.16 String value

primitive value that is a finite ordered sequence of zero or more 16-bit unsigned integer

NOTE A String value is a member of the String type. Each integer value in the sequence usually represents a single 16-bit unit of UTF-16 text. However, ECMAScript does not place any restrictions or requirements on the values except that they must be 16-bit unsigned integers.

When offering guidance as to how to interpret those values as text, the spec does mention UTF-16 and does not mention UCS-2.

Mathias Bynens is of course completely free to conclude that Javascript strings are "really" UCS-2 on the basis that Javascript strings used fixed-size characters that are the same size as those defined by UCS-2 and doesn't enforce the UTF-16 rules around values \uD800-\uDFFF, but he's wrong. It doesn't enforce the UCS-2 rules for those values either.

anotherusername

@flabdablet but String.fromCharCode specifies the operation ToUint16, which allows integer values in the range 0 through 2¹⁶−1, inclusive. Larger integers are reduced by modulo 2^{16^.}

@flabdablet said in I think I know what makes a truly competent programmer:

pile-of-poo emoji U+1F4A9

is not in the range 0 through 2¹⁶−1. So String.fromCharCode(0x1F4A9) won't work; 0x1F4A9 is reduced by modulo 2¹⁶ and it produces a string containing the code point U+F4A9 instead.

Awareness of surrogate pairs (and treating them like single characters instead of 2) and code points beyond 0xFFFF is pretty much what differentiates between UCS-2 and UTF-16. "💩".length == 2 is wrong in UTF-16.

flabdablet

@anotherusername said in I think I know what makes a truly competent programmer:

"💩".length == 2 is wrong in UTF-16.

Only if you assume that a length 1 Javascript string (Javascript doesn't have characters as a primitive type, only strings) can hold any arbitrary Unicode code point, which it can't. Javascript strings, when interpreted as text, hold the UTF-16 encoding of that text.

anotherusername

@flabdablet said in I think I know what makes a truly competent programmer:

Only if you assume that a length 1 Javascript string (Javascript doesn't have characters as a primitive type, only strings) can hold any arbitrary Unicode code point, which it can't.

By definition a UTF-16 string can hold characters of any arbitrary Unicode code point. That's the whole point. And the only difference is that UTF-16 tells you how to interpret one character where UCS-2 sees two different code points, because under UTF-16 they're one code point and one character.

flabdablet

@anotherusername said in I think I know what makes a truly competent programmer:

Awareness of surrogate pairs (and treating them like single characters instead of 2) and code points beyond 0xFFFF is pretty much what differentiates between UCS-2 and UTF-16.

In UCS-2, the character codes that define UTF-16 surrogate pairs (\uD800..\uDFFF) are simply illegal. It is explicitly OK to create Javascript strings containing those codes. Therefore, Javascript strings (and by extension Javascript itself) do not use UCS-2.

flabdablet

@anotherusername said in I think I know what makes a truly competent programmer:

By definition a UTF-16 string can hold characters of any arbitrary Unicode code point.

Which definition would that be? It's certainly not the ECMAScript spec.

Of course, if all you mean by "a UTF-16 string" is "arbitrary Unicode text encoded as a sequence of 16-bit values" then yes, that definition is true by inspection.

ECMAScript strings are, per spec, sequences of arbitrary 16-bit values. Consequently, they are able to hold UTF-16-encoded Unicode text, and in fact the ECMAScript spec explicitly states that this is what they usually represent.

They are able to hold all kinds of other stuff as well; you can safely use them as buffers for arbitrary data that has no textual meaning whatsoever.

accalia

@flabdablet said in I think I know what makes a truly competent programmer:

is not a blanket fix

no, but it's a hell of a patch.

@flabdablet said in I think I know what makes a truly competent programmer:

If you're writing software that needs to specify times at which future events happen, it's safer to store those as localtime+tz.

if i was writing that software, yes it would.

i don't write software for fun that does that nor do i write software that relies on itself for scheduling future events (that's the job of crontab or scheduled tasks depending on if you are *nix or windows

@flabdablet said in I think I know what makes a truly competent programmer:

you can never be completely sure that a future localtime converted to UTC now is going to come out the same as if it were converted to UTC then.

in fact you are guaranteed that it will eventually be wrong. good job for me that i sidestep that issue entirely and don't schedual future events by date time in my programs. i always do it by second deltas when needed, or as previously mentioned use a bit of existing functionality designed for scheduling tasks

:-P

anotherusername

@flabdablet said in I think I know what makes a truly competent programmer:

In UCS-2, the character codes that define UTF-16 surrogate pairs (\uD800..\uDFFF) are simply illegal.

They're invalid code points in UTF-16 as well, but "💩".charCodeAt(0).toString(16) produces d83d.

@flabdablet said in I think I know what makes a truly competent programmer:

It is explicitly OK to create Javascript strings containing those codes. Therefore, Javascript strings (and by extension Javascript itself) do not use UCS-2.

What should it do if it contains one of those illegal characters? Blow up? When in all likelihood there's no reason for it to care, and so it just pretends it's okay?

@flabdablet said in I think I know what makes a truly competent programmer:

ECMAScript strings are, per spec, sequences of arbitrary 16-bit values. Consequently, they are able to hold UTF-16-encoded Unicode text, and in fact the ECMAScript spec explicitly states that this is what they usually represent.

Yes, but all of the built-in ECMAScript functions that parse strings explicitly do not parse them as Unicode text.

You keep pointing out that they're sequences of arbitrary 16-bit values, and thus different from both UTF-16 and UCS-2. But apart for the fact that UCS-2 specified nasal demons for certain 16-bit values, and ECMAScript just silently pretends they're just like any other 16-bit value, there's no difference. Functionally, it's UCS-2.

flabdablet

@anotherusername said in I think I know what makes a truly competent programmer:

Functionally, it's UCS-2.

No it isn't. Functionally, it's a very thin abstraction layer over array of uint16.

flabdablet

@anotherusername said in I think I know what makes a truly competent programmer:

They're invalid code points in UTF-16 as well, but "💩".charCodeAt(0).toString(16) produces d83d.

That's because Javascript strings are not sequences of code points, except in the special cases where those coincide with their own UTF-16 encodings.

The surrogate-pair values \uD800..\uDFFF are perfectly valid encoding values in UTF-16. They have no meaning at all in UCS-2.

I will agree that it is unfortunate that names like charAt and charCodeAt imply that what you get by indexing a Javascript string would in general represent a single Unicode character or code point, as opposed to some part of an encoding for same.

flabdablet

@anotherusername said in I think I know what makes a truly competent programmer:

apart for the fact that UCS-2 specified nasal demons for certain 16-bit values, and ECMAScript just silently pretends they're just like any other 16-bit value, there's no difference. Functionally, it's UCS-2.

Apart from the fact that UTF-16 specifies that certain 16-bit values are to be interpreted in pairs, and ECMAScript just silently pretends they're just like any other 16-bit value, there's no difference. Functionally, it's UTF-16.

flabdablet

@accalia said in I think I know what makes a truly competent programmer:

i sidestep that issue entirely and don't schedual future events by date time in my programs. i always do it by second deltas when needed

That's functionally equivalent to doing it by UTC timestamp.

anotherusername

@flabdablet said in I think I know what makes a truly competent programmer:

@anotherusername said in I think I know what makes a truly competent programmer:

Functionally, it's UCS-2.

No it isn't. Functionally, it's a very thin abstraction layer over array of uint16.

Functionally, so is UCS-2.

Do you have an actual UCS-2 standard sitting somewhere that says otherwise?

@flabdablet said in I think I know what makes a truly competent programmer:

Apart from the fact that UTF-16 specifies that certain 16-bit values are to be interpreted in pairs, and ECMAScript just silently pretends they're just like any other 16-bit value, there's no difference

That IS the crucial difference between UCS-2 and UTF-16.

As far as I know, UCS-2 specified nasal demons, so ECMAScript's approach of simply pretending they're okay (16-bit code points) is a perfectly valid UCS-2 implementation.

RaceProUK

@anotherusername It's non-conformant UCS-2; that's probably the best way to describe it

blakeyrat

Let's all debate about whether JavaScript uses USC2 or UTF-16, this is a compelling and interesting discussion to have.

flabdablet

@anotherusername And yet '💩' is a completely valid ECMAScript string that has no UCS-2 encoding.

flabdablet

@blakeyrat said in I think I know what makes a truly competent programmer:

this is a compelling and interesting discussion to have.

Do feel free to join in!

flabdablet

@RaceProUK said in I think I know what makes a truly competent programmer:

It's non-conformant UCS-2; that's probably the best way to describe it

Why would you describe it a different way from what the spec does?

blakeyrat

@flabdablet I like USC2 because they really load up the guacamole. Then again, UTF-16 has that lovely mint sauce. Both pair well with a cinzano bianco.

accalia

@flabdablet yes, but again i'm explicitly requiring RELATIVE offsets. if you want an AT THIS TIME schedule i'll tell you to use crontab or scheduled tasks.

asdf

@blakeyrat said in I think I know what makes a truly competent programmer:

I like USC2 because they really load up the guacamole.

The guacamole thread is

flabdablet

@blakeyrat Technically that's not real guacamole.

RaceProUK

@flabdablet Because sometimes it's easier to understand if you describe it functionally rather than sticking to the rigidities of the spec

anotherusername

@flabdablet ...wtf is that even. It's NOT 💩, it's only every displayed as that. Internally, and to all of the string manipulation functions, it's 0xD83D, 0xDCA9; �, �; two completely distinct code points which DO have a perfectly good encoding if you ignore the nasal demons requirement. And, assuming your browser just ignored those two characters or displayed missing character glyphs, no nasal demons on your web browser, either.

flabdablet

@RaceProUK Functionally speaking, if you're coding in Javascript and you need correct results for text including code points outside the BMP, then understanding that Javascript strings contain UTF-16-encoded text, as opposed to sequences of Unicode code points, is vital.

@anotherusername said in I think I know what makes a truly competent programmer:

Internally, and to all of the string manipulation functions, it's 0xD83D, 0xDCA9; �, �; two completely distinct code points...

No, because those are code units, not code points. Unicode specifically leaves code points 0xD800..0xDFFF undefined.

When the code units 0xD83D and 0xDCA9 are adjacent in a Javascript string, and that string is interpreted as UTF-16-encoded text in the way recommended by the spec, they collectively represent the single Unicode character 💩 whose code point is 0x1F4A9.