Kotlin extension functions charm; JavaScript prototypes get an HR complaint
Description
Two-panel Sunny Street comic edited for dev humor. Header reads "SUNNY STREET" with sub-banner "KNOW THE WORK RULES." Panel 1, marked "APPROPRIATE," shows a smiling male coworker whose torso is replaced by the colorful Kotlin logo; his speech bubble says "Extension Functions." A woman at her cubicle blushes and replies "AWWW, YOU'RE SWEET" with a red heart floating beside her. Panel 2, marked "INAPPROPRIATE," reuses the scene but the man now sports a bright yellow square with bold black "JS" letters; his bubble says "Prototypes." The same woman, alarmed, grabs the phone and shouts "HELLO, HUMAN RESOURCES?!" The meme contrasts Kotlin’s tidy extension-function syntax with JavaScript’s sometimes maligned prototype chain, poking fun at how certain language features feel elegant while others feel sketchy in large codebases. Cartoon style is colorful with light blue background and thick black outlines; original credit "SUNNY STREET © 2013 Max Garcia" sits in the footer
Comments
22Comment deleted
Some teams call it "extending a class"; others call it "modifying Object.prototype" - one gets code review kudos, the other triggers a P0 incident and an HR lecture on boundaries
The real HR violation here is that someone's still defending prototype manipulation in 2024 when we have proper class syntax, TypeScript, and a dozen better patterns for extending functionality without risking the entire global object chain
This perfectly captures the industry's collective PTSD from explaining JavaScript's prototype chain in interviews versus the relief of just adding `.also {}` to literally anything in Kotlin. Extension functions are the syntactic sugar we didn't know we needed until we stopped accidentally mutating `Object.prototype` at 2 AM and calling it 'dynamic programming.'
Kotlin extensions: politely augmenting classes. JS prototypes: mutating the global object graph until HR intervenes
Extension functions are compile-time sugar with scoped receivers; prototype patching is shared mutable state at runtime with a blast radius wide enough that your first responder is HR
Extension functions feel like polite, namespaced sugar; prototypes are the coworker who patches Object.prototype in prod - now the incident commander and HR both page you
The first one was more fun. Comment deleted
Implicit type conversion in JS: Eww, did you see what happens if you add an array to a string while comparing the result to a number? Weird... JS is so awful. Implicit type conversion in literally any other language: Nice! What? You didn't expect that int + float isn't the same as float + int? Learn to code! Comment deleted
JS designers be like: This type conversion works in the most ridiculous and counterintuitive way? Approved and documented, next! Comment deleted
Sure, these conversions are very human Comment deleted
> sure > ascii code > garbage value > integer division Comment deleted
Yes, it's very human... if the human was abducted and raised by wild compilers Comment deleted
I'd prefer being abducted by C compiler rather than JS Comment deleted
It is not like I hate JS, but I cant eat bananas anymore Comment deleted
lmao it gets even better with floats nan == nan -> false js: eww so weird literally any other language: rtfm ieee 754 it's the basics Comment deleted
Meanwhile "counterintuitive" JS... Comment deleted
Don't offend believers in JS supremacy, they're also humans Comment deleted
gee, I wonder how many people will find 1 + +"4" intuitive after getting "14" several times in a row Comment deleted
+ is a unary operator that converts a numeric string into a (float) number, ppl should actually go over the features before criticizing the language Comment deleted
and character literal in c is a u8 number. i am not criticizing js, i am criticizing this guy's example of js being very intuitive compared to c. you cannot in good faith complan about c bullshit and then give js bullshit as an example of completely intuitive language design Comment deleted
When you "+" a string with anything, the result is a string. When you "+" two numbers, the result is a number. If you want to use a string as a number, you need to explicitly typecast or convert it, as you would in any modern programming language - JavaScript isn't unique in this behavior. However, C handles these cases in a very specific way due it's low-level nature logic. P.S. In some languages, like Perl, the "+" operator is reserved exclusively for numerical operations, so "Hello" + "World" is 0 Comment deleted
brother, nobody is asking what type conversion is. you chose the example to illustrate a point, showing that js is more "human" and "intuitive" when compared to c, and this example is at best not a strong one. nobody was arguing that c is very human and intuitive, using different logic (not converting to a number in c vs converting to a number in js) undermines your entire point, and "+" operator being used to convert strings to numbers is not intuitive to anyone who's not familiar with js and ecmascript-based languages (to be fair, chars being treated as numbers and strings being treated as pointers is also not intuitive for anyone who's not familiar with c or assembly, but that's not relevant to the discussion) Comment deleted