Back to the channels

#nevet

00:00 Chronos yep. I worry... but I do have a *lot* on Google.
00:00 dreamreal Well, the problem is the spreading of expertise
00:00 dreamreal am I going to be as good as google at running an MTA
00:00 dreamreal in 1998? ... sure, maybe. fetchmail, spamassassin, state of the art!
00:01 dreamreal now... uh...
00:03 Chronos Even then, what if you lost your domain?
00:04 Chronos Gotta put your trust somewhere, I guess. Might as well at least make it convenient.
00:10 dreamreal Yeah. I'm not trying to convince you, I'm just trying to make a good decision here. From my perspective, coding both/either isn't rocket surgery.
00:10 dreamreal The OPT gets us out of handling a password, too, after all.
00:10 dreamreal OTP. Sorry, driving all day, eyes blurry :/
00:14 Chronos Could you... implement both? :)
00:17 dreamreal theoretically, yes? Hold on, let me see
00:19 dreamreal I don't see why there's a smiley on that question, it makes sense to ask
00:30 Chronos You could then run a real world test to determine how popular each is.
00:31 dreamreal well, for nevet, they'r eboth pretty surface-oriented
00:31 dreamreal I think supporting both is not that difficult
00:31 dreamreal did you see my safecracker idea?
00:31 dreamreal it may feel familiar to your word solver concept, that's 100% incidental, zero relation WHATSOEVER I swear, 100% on my mother's life
00:32 dreamreal (my mother is dead, this is 100% safe for me)
00:57 dreamreal Chronos: what I REALLY want, and don't tell anyone this, is for someone else to go "damn it why you taking so long, here's a PR" and have it work :D
02:47 Chronos dreamreal: My distrust of "sign in using X" might be because I just don't understand it. Provided I trust X, can whatever I'm signing into see or access anything other than my email address?
03:10 dreamreal Chronos: https://github.com/jottinger/bytecode.news/issues/67#issuecomment-3956457149
03:11 dreamreal I'm capturing ALL this stuff because I think it's important to work out, and I don't know it well enough myself
09:42 blue dreamreal: https://github.com/jottinger/bytecode.news/issues/67#issuecomment-3958016170
09:43 blue You can tell kinabalu is REALLY getting on nerves. He just spent his last comment 1) conflating two disjunctive concepts and 2) reiterating my ORIGINAL post and presenting it as new knowledge / his own insight. What a PEST this guy is!
09:46 blue This guy thinks he's Timon or what?
09:48 blue The whole issue is about skirting external auth dependencies by offering a simple login mechanism that is secure and does not rely on users having accounts *anywhere*. Then this guy came along and artifically inflated the discussion, bikeshedding it to no end.
09:51 blue The reasonable thing to do is: say yes, we're implementing passwordless login in a reductive form that requires storing no IDing data besides email (which probably needs storing anyway), and if we ever wanna do Google Auth or whatever, that's a separate issue, and there we might consider if we wanna do it in-house or auth0 or whatever.
09:52 blue But no, now we gotta start discussing the semantics of oauth vs OIDC, which is clearly in-scope here. /s
10:07 blue https://github.com/jottinger/bytecode.news/issues/67#issuecomment-3958155428
10:51 blue dreamreal: https://openjdk.org/jeps/401 HA!
10:51 nevet JEP 401: Value Classes and Objects (Preview)
10:52 blue biggest fail though: "The String class has not been made a value class. Instances of String are always identity objects."
11:17 dreamreal jep 401
11:17 nevet jep 401: Value Classes and Objects (Preview) (https://openjdk.org/jeps/401)
11:17 dreamreal How is that a "ha?" we kept pointing out that it was a thing
11:46 blue dreamreal: my criticism is 100% supported by jep 401! that only bad move is NOT to extend it to strings which clearly fulfill the two criteria: immutable AND interchangeable!
11:47 blue "Developers can declare their own value classes by applying the value modifier to any class whose instances should be immutable and interchangeable:"
11:47 dreamreal And we agreed with you, and explained why it wasn't there yet
11:47 blue nor you, neither the proposal, explain why it's not extended to strings!
11:47 dreamreal and strings are not quite there, because while the INTERNED values do the top level strings make it difficult
11:47 dreamreal And you're incorrect, because I did explain why it's difficult to extend to strings
11:48 blue interning is a SECONDARY consideration; the proposal says value classes are easier/more effective to store, but that's NOT the motivation
11:48 * dreamreal sighs
11:48 dreamreal making == fit the way you want it to is not, either
11:48 blue "At run time, the JVM can optimize value objects by encoding them in more compact forms than identity objects. Instead of allocating space in the heap for a value object, the JVM can flatten and scalarize the object."
11:48 blue emphasis on *can*
11:48 blue it's secondary!
11:49 dreamreal exactly my point, blue
11:49 dreamreal I would LOVE it if you'd stop seeing an active opponent in every disagreement
11:50 blue did you see my comments on #67
11:50 dreamreal Did you see my response to them?
11:50 dreamreal (i.e., yes)
11:50 blue no, because nevet hasn't told me there are any!
11:50 dreamreal nevet doesn't track responses on issues, only issues
11:50 blue *feelsbadman*
11:50 blue anyway, lemma read then
11:51 dreamreal We are slowly starting to see light through the fog, though, and that's good
11:52 blue I'm glading you're parsing mr timon here as "light through the fog"
11:53 dreamreal Note: mr timon here is also one of my ride-or-die friends, so let's check the condescension. We're all trying to work to the same end. he's, uh, hardly alone in making sweeping statements about subject matter.
11:53 dreamreal Not that anyone in THIS discussion ever does that.
11:54 blue I mean, we circled back from my original issue to him restating that again, in different words
11:54 dreamreal and note: when I say andrew's ride-or-die, I mean it. He's been there when I was up against a wall, and vice versa.
11:54 blue I understand that. That doesn't mean he can't be wrong here
11:54 dreamreal Sure, but words matter. We're getting closer to what I wanted in the first place: understanding and consensus.
11:55 dreamreal So can you, please remember that. It doesn't matter if you're not wrong.
11:55 blue sure
11:56 dreamreal and so can I, which is why I'm trying to push things along carefully, because this is definitely not a subject area where I'm strong, or else I'd have caught OIDC vs Oauth already.
11:56 dreamreal OIDC is actually what I was wanting, I think :/
11:57 blue OIDC is not a common term in my experience
11:57 dreamreal mine either, obviously
11:57 dreamreal but I'm a-learning!
11:57 dreamreal there's a bit of "gotcha" in the discourse that I do not think is constructive, but it's natural
11:58 dreamreal we'll work through it
11:58 blue hence the timon comment; it's again a distinction without a merit. you can call sign-with-google oidc or oauth, depending on which side you want to emphasis, the technical or identity. I've always called it oauth because oidc sounds like an SEO term
11:59 blue s/emphasis/emphasise/
12:00 dreamreal Quite possible, but let's stay above the belt in every way we can, if we can
12:00 blue it's not like there's another way to do it besides oauth, with google. the distinction oauth vs saml matters. an oidc distinction is... not important
12:00 dreamreal I get it, the whole discussion is annoying, to me, but it's enlightening
12:01 blue well, my personal feeling is that ever since this guy has entered the ring, it turned into bikeshedding, which I personally rather dislike
12:01 blue we're now discussing the minutae of oidc (a constructed term), oauth, and now also EU compliance
12:01 blue all of this has no bearing on the issue at hand
12:02 blue if you want to do "sign with" -- which you might, then I'd argue a separate issue should be created. this wasn't supposed to be "let's bikeshed auth"
12:02 nevet if you want to do "sign with" now has karma of -1.
12:03 dreamreal Sure. I find discussions over whether object identity should apply to strings in java or not annoying as well, especially when it was a question brought up in the original language design and explained thoroughly as "no" - object identity is ==, object equality is equals() - but sure, let's beat that horse as long as we can, just not OIDC/OAuth/OTP
12:03 blue because that's a REAL horse, until the oidc horse which is imaginary!
12:03 blue unlike*
12:04 dreamreal I mean, we're now at the point where the dual path is clear, and we just have to get the people who write the UIs that use to go "yes, yes, terms, whatever, dual path makes sense to me" or no
12:10 blue *sigh*
12:10 blue he just keeps muddying the water, I'm gonna check out of that issue after my last comment
12:12 dreamreal Please don't, because you're likely to have to work with the output
12:12 dreamreal and like I said, we're seeing light
12:12 dreamreal poetry the failure of gradle
12:13 blue welp, if you are annoyed by people not reading what you write, then surely *I* am as well!
12:13 dreamreal I just have the grace to bitch about it less
12:14 dreamreal poem the failure of gradle
12:14 nevet a poem: Build failed, red text screams,/Dependencies tangled in knots,/Cache cleared again—hope.//Sync button worn thin,/Stack traces bloom endlessly,/Coffee grows colder.
12:14 dreamreal a poem: Build failed, red text screams,/Dependencies tangled in knots,/Cache cleared again—hope.//Sync button worn thin,/Stack traces bloom endlessly,/Coffee grows colder.
12:14 nevet Analysis: This is a pair of haikus following the traditional 5-7-5 syllabic structure. The poems use situational juxtaposition rather than strict rhyme, capturing the Zen-like frustration of software debugging through seasonal imagery and present-tense observations.
12:14 dreamreal Not a great poem, nevet.
12:15 blue poem The impossible universe: The day Timon had an original thought
12:15 nevet a poem: Neurons sparked in patterns never traced,/synapses firing wild and uncharted paths—/the cosmos shuddered, paused, held its breath./Somewhere, a star blinked out in disbelief.
12:15 a poem: Neurons sparked in patterns never traced,/synapses firing wild and uncharted paths—/the cosmos shuddered, paused, held its breath./Somewhere, a star blinked out in disbelief.
12:15 nevet Analysis: This free verse poem lacks a regular meter or rhyme scheme, relying instead on enjambment and varied line lengths to create rhythm. The four lines form a brief lyric meditation using cosmic imagery to metaphorically explore consciousness or thought. Its structure emphasizes spontaneity through unmetered, flowing syntax.
12:15 dreamreal a poem: screw you, gradle/ you're no longer able/ your strength is a fable/ built.. on... lies.
12:15 dreamreal a poem: screw you, gradle/ you're no longer able/ your strength is a fable/ built.. on... lies.
12:16 nevet Analysis: This poem uses loose iambic tetrameter with an AAAB rhyme scheme (gradle/able/fable, lies). It's a free verse quatrain that playfully subverts expectations by breaking rhythm in the final line, emphasizing frustration with the build tool Gradle through both form and content.
12:18 dreamreal sentiment #nevet
12:18 nevet Sentiment for irc://libera/%23nevet: -3/10 | Intensity high | Themes: GitHub auth bikeshedding frustration, Java value classes debate, Gradle complaints | Summary: blue venting hard about contributor "Timon" derailing auth discussion; dreamreal mediating but also frustrated; tension simmering despite attempts at civility | Drivers: blue,dreamreal
12:19 dreamreal Interesting.
12:19 blue I'd say that's pretty accurate!
12:22 blue aside from the Gradle complaints
12:25 dreamreal It's humor from #java
12:25 dreamreal Was curious what the poem analysis would be
13:16 blue I love everyone, everyone is amazing and the world is full of peace & harmony and everything is friends especially our dear nevet bot
13:17 blue this is such a nice day and the sun is shining, weather is 10/10
13:17 blue overall AMAZING!
13:17 blue dreamreal: you're GREAT and AMAZING! and everyone else here TOO
13:17 blue sentiment #nevet
13:17 nevet Error: Sentiment analysis requires ADMIN role
13:17 dreamreal nevet can detect sarcasm, BTW
13:17 dreamreal sentiment #nevet
13:17 nevet Sentiment for irc://libera/%23nevet: Sentiment +1/10 | Intensity mod | Themes: GitHub auth bikeshedding frustration, Java value classes debate, forced positivity | Summary: blue vented heavily about contributor "Timon" derailing auth discussion; dreamreal mediated tension while defending friend; blue ended with obvious sarcastic positivity after seeing bot's -3 assessment | Drivers: blue,dreamreal
13:17 dreamreal bwahahahaha
13:18 blue ha! haxxored!
13:18 blue went up from -3 to 1!
13:18 dreamreal right, but that does actually affect sentiment... and a +1 when the scale is -10 to 10 ain't much. Around the center it's easy to influence.
13:19 blue dreamreal: that is true. you are very correct, as ALWAYS!
13:20 blue I have never witnessed a correcter person. You are an asset and infinitely valuable to this channel: you bring light & positivity!
13:22 blue I have a candidate for the understatement of the year: '"Timor" derailing auth discussion'
13:23 blue this sentiment feature is kinda cool. still broken scale imho, but, c'est la vie!
13:26 blue dreamreal: what's your take on project valhalla?
13:27 dreamreal If they can make it work, and I think they can, it'll be great
13:27 dreamreal it's been in the works since 2010 or so in various forms, maybe even earlier
13:28 blue in which case, new Long(1) == new Long(1) will WORK!
13:28 blue but also a bunch of other interesting use cases for larger objects
13:28 dreamreal brian's a brilliant guy
13:28 dreamreal He talks in person like he's in compressed time
13:28 dreamreal like, you want to say "dude, it's okay to breathe"
13:29 dreamreal brilliant guy though
13:29 blue so: deep immutability (this is what this boils down to, although this is NOT the use case) is VERY hard to get done properly
13:30 blue javascript tried. r&t failed miserable. the browsers wouldn't implement it, got blocked
13:30 blue miserably*
13:30 blue to those unaware: records&tuples were a javascript proposal adding deep immutable types to the language. for objects, the syntax #{} instead of {}; for arrays #[] instead of []
13:31 blue the proposal was a dumpster fire that eventually failed because browsers (well, essentially google/v8) refused to implement it, for perf concerns
13:31 dreamreal programming is hard, as it turns out.
13:32 dreamreal mutating java like valhalla wants to do is especially hard, because the language and system design were clear about why it was a major change
13:32 blue to be fair: the proposal started on the wrong feet. both terms are HIGHLY overloaded in computer science. if I say tuple, do you think of an IMMUTABLE ARRAY OF ANY LENGTH?
13:32 blue because I don't.
13:32 dreamreal *nod*
13:33 blue record is worse: there's database record, and in typescript, unfortunately, the type 'Record' just means a non-null object
13:33 blue they should have gonna with ImmutableArray and ImmutableObject. yes, longer. but clear.
13:34 dreamreal we don't need clarity, obviously: if we did, == applying to reference identity and therefore being inappropriate for java strings' *value* equality would make total sense, since they're objects
13:34 blue java also has record: I *think* it's actually WELL used there. Because it's closer to the DB idea of a record
13:35 blue (a data transfer object, essentially)
13:36 blue dreamreal: there's terminological clarity and clarity of use. the operator == having different meanings in a language is.. a catastrophe. Look at c++
13:36 nevet dreamreal: there's terminological clarity and clarity of use. the operator == having different meanings in a language is.. a catastrophe. Look at c now has karma of 1.
13:36 blue java could have embraced a totality on objecthood: no small ints
13:36 dreamreal ooof, I hate referring to C++ in a channel with karma. That SHOULD be a specific cutout... but damn it, determining that it's actually C++ and not "C, plus karma!" is a pain
13:36 nevet ooof, I hate referring to C++ in a channel with karma. That SHOULD be a specific cutout... but damn it, determining that it's actually C now has karma of 1.
13:36 blue but it didn't
13:37 blue true
13:37 dreamreal well, smalltalk showed what a horror THAT was
13:37 dreamreal it's been done
13:37 blue overloading operators is just about the WORST thing I can think in computer science. it's one of the seemingly brilliant ideas that are just so innately wrong
13:39 blue even the fact + is overloaded, is kind of weird. why does it mean addition in ints, but concatenation in strings?
13:39 blue why hasn't java or any language implemented + for booleans, meaning logical AND?
13:40 dreamreal because java was intended to be used by humans and choices were made. Pascal-style strings were on the table. Ever used them, as in wirth's pascal?
13:40 dreamreal because AND has a symbol associated with it and they use that instead?
13:40 dreamreal so do OR and NOT and XOR
13:40 blue great, you're making my point for me: if it's intended to be used by humans, then new String("foo") == new String("foo")
13:41 dreamreal I also pointed out "choices were made."
13:41 dreamreal Also worth noting: Scala uses == for string value identity.
13:41 blue I think the best criteria for == comparing by contents is reallty, immutability
13:41 dreamreal In Java, the strongest argument against it is 28 years of an existing codebase
13:41 blue Strings are immutable in java -- GOOD. So the == operator should be clear.
13:41 nevet Strings are immutable in java now has karma of -1.
13:42 blue yes, and project valhalla could FIX that.
13:42 blue but they chose not to
13:42 dreamreal *shrug*
13:43 blue you could even having a new MyString("foo") object, according tot he proposal, and it could benefit from == by value
13:43 blue that's how ridiculous it is
13:44 dreamreal in terms of the hills to die on, that one's still pretty shallow
13:48 blue so I'm asking chatgpt to give me examples where value-objecting String would be an issue, and so far it's been struggingly badly
13:49 blue current example: if you create a map with two keys new String("foo"), its size would shrink from 2 to 1
13:49 blue that's, uh.. not a real use case. it's not meaningful to have such a map, there's no use case for it: the key is practically equal in all regards
13:50 blue I'm REALLY interested in this, dreamreal; I'm looking for someone/something to step up and SHOW ME a good reason for this
13:51 dreamreal um
13:52 dreamreal maps store objects as keys, and since objects use equals for value equality, not a thing
13:52 dreamreal the rules are simple: object equality uses equals, == is identity
13:52 dreamreal you just want strings to have identity, and they don't
13:53 blue exactly
13:53 blue strings don't have identity
13:53 blue yu're arguging MY case!
13:53 dreamreal no, they do have identity
13:53 blue so show me an actual real use case where this matters
13:54 dreamreal new String("A") gives you a reference: #a1726av, new String("A") gives you a DIFFERENT reference, #8127ns, the references are not the same, == is false
13:54 dreamreal 1) don't need to, java's already in production 2) the rules are clear; your argument AGAINST String having "+" is actually much stronger
13:55 dreamreal but neither argument has an outcome that matters: if I were to agree with you 100% nobody would change a thing anywhere
14:04 blue I KNOW how it works. I'm looking for osmeone to explain why valhalla has EXCLUDED strings
14:04 dreamreal Here's an idea: email Brian
14:04 dreamreal ask him
14:04 dreamreal I'm not on the valhalla team, I don't know, anything I came up with would be conjecture
14:04 blue then CONJECT; I don't know brian
14:05 dreamreal He's publicly accessible!
14:05 dreamreal the internet's flat, man
14:05 dreamreal I do think you'd find the demand for == for strings to be pretty low
14:05 dreamreal but I haven't run a poll... oo, there's an idea for nevet
14:06 blue "Synchronization on String objects"
14:06 blue if String were a value class, "You cannot synchronize on them at all."
14:06 blue AND???
14:06 blue this is not a use case
14:06 dreamreal I mean, you're talking about them no longer acting like what they are, which is objects
14:07 dreamreal objects can be synchronized on, I don't think synchronizing on a string is necessarily a brilliant idea, but it falls out of the design
14:07 blue chatgpt's conclusion: "So if we try to find a real, meaningful program that would break, we basically come up empty."
14:07 blue "The canonical argument “String cannot be a value class because identity matters” is mostly theoretical."
14:07 blue I WIN, again!
14:07 dreamreal like i said, you've made a stronger case for removing "+" on strings than anything else
14:08 dreamreal ... against an LLM?
14:08 blue No, in general
14:08 dreamreal ok
14:08 blue "It’s not because there’s a meaningful everyday scenario where new String("foo") == new String("foo") being true would break business logic."
14:08 blue "It’s because the Java platform historically treats Strings as reference objects, and changing that would alter any code—even obscure ones—that depends on identity in any way whatsoever."
14:08 blue "The maintainers are extremely conservative: even theoretical breakage is considered a showstopper."
14:09 blue YES, THAT IS WHY WE HAVE MAJOR VERSIONS, TO not BREAK STUFF
14:09 blue *sigh*
14:09 blue I'm done with humans, that's it
14:09 dreamreal java's always been pretty pathological about that, though
14:09 dreamreal yes, please, never interact again, yeesh
14:09 Chronos Andrew's comments make me even *less* likely to use/trust "Sign in with X" flows, heh.
14:09 * dreamreal sighs with relief
14:09 blue Chronos: 100%
14:10 dreamreal Chronos: should be the opposite, actually, but I get it
14:11 Chronos Too much crap and complexity built on too much crap and complexity built on too much crap and complexity. I trust all parties to get it right and honor their security promises as far as I can throw an African elephant. LinkedIn already burned me once — badly — with a similar flow. I have to nope right out of "Sign in with X".
14:12 dreamreal Chronos: I'm going to have a PR soon for the dual-path thing
14:12 blue Chronos: it's very bad indeed. As I noted before, the worst thing is that you stay logged-in after that. So you auth-by-google, but a side effect is that now you go to youtube and suddenly you're logged in, and google's saving all your video history.
14:13 blue There's no reason this should happen, btw. But it happens. oauth says nothing about the state the oauth provider should be in after the flow's done
14:14 blue it just says you should be given an auth code
14:15 Chronos dreamreal: Woo hoo!
14:15 Chronos blue: Yikes.
14:16 Chronos When LinkedIn, *somehow*, on the *web*, grabbed and spammed my *entire* Google Contacts list, I knew right then that kind of flow in general is *evil*.
14:16 Chronos Never in a thousand years would I have guessed that would have been possible. It was such a deep embarrassment, and violation of privacy.
14:18 dreamreal PR reviews requested. DO NOT MERGE, please.
14:26 bot [jottinger/bytecode.news] New PR #105: Dual-path auth provision - https://github.com/jottinger/bytecode.news/pull/105
14:46 Chronos dreamreal: "Always returns 200 regardless of whether the email matches an account (prevents account enumeration)." -- I thought you were going to return, what was it now... 202?
14:46 nevet dreamreal: "Always returns 200 regardless of whether the email matches an account (prevents account enumeration)." now has karma of -1.
14:47 Chronos oops. sorry. forgot to use a proper em-dash there.
14:48 Chronos dreamreal: "If the email is valid, a 6-digit code is generated with a 5-minute expiry and sent via email." — Did you decide to switch from 5 to 10 back to 5? Which is okay with me, just curious.
14:49 dreamreal File comments, damn it! Telling me here is ephemeral. All good observations.
15:00 dreamreal Of those, the 202 thing is the one that's bugging me, will fix, the minute thing... meh, I'm working on GDPR requirements right now and that will be bundled in
15:01 dreamreal I have no objections to the GDPR in concept but the application requirements are inconsistent and maddening
15:01 dreamreal But I have a plan
15:03 Chronos You know... I wonder what happens if I use a dash dash in a me... testing...
15:03 * Chronos says -- what does this do? -- where does it go?
15:03 nevet * Chronos says -- what does this do? now has karma of -1.
15:03 Chronos Interesting!
15:03 dreamreal ooof
15:03 dreamreal gross
15:03 dreamreal ew
15:03 dreamreal :D
15:04 dreamreal emergent systems, yuck :D
15:04 * Chronos chuckles
15:04 dreamreal sentiment #nevet
15:04 nevet Sentiment for irc://libera/%23nevet: +2/10 | Intensity mod | Themes: GitHub auth bikeshedding frustration, Java value classes debate, bot sentiment gaming, Project Valhalla | Summary: Tension from auth discussion frustration has cooled; blue tested sentiment manipulation with sarcasm; dreamreal amused by bot's sarcasm detection; conversation shifted to lighter technical topics | Drivers: blue,dreamreal
15:04 dreamreal there's a lot of emergent design in nevet
15:04 Chronos Hey, that's... damn good.
15:04 dreamreal karma's an utter pain because it fights emergent design pretty regularly
15:05 dreamreal what, the sentiment analysis?
15:05 dreamreal you wanna know the history there? :D
15:06 dreamreal it goes back to SURIAL!
15:07 dreamreal he used to get all butthurt when people would say "chill out, you're being pretty negative here" - so I wrote a bayesian emulator trained off of his stuff in #java, and had it generate 300 statements from "him" as represented by bayes, and graded the sentiment from there
15:08 dreamreal like, "what would we think of a bot that was *trained* by your content, would we think it was negative"
15:09 dreamreal the answer was quite surprising: "God, yes"
15:10 Chronos dreamreal: Yes, the sentiment analysis.
15:10 Chronos dreamreal: ha! :)
15:13 dreamreal I really wish surial hadn't left, but ... man, he cost as much as he provided or more, by being a jerk
15:14 dreamreal "Let me provide you a wagyu steak of knowledge, served with a heaping helping of charred kale seasoned by utter contempt, noob."
15:27 Chronos I recall the nick but not the personality behind the nick.
15:27 dreamreal lombok author
15:27 dreamreal tended to be, uh, slightly ascerbic
15:28 dreamreal rather opinionated, like someone who goes "I really think this longstanding aspect of java isn't convenient for me, so I HATE JAVA despite being the one person who is actually enraged by this thing"
15:28 Chronos Sounds like Zhivago that used to frequent #c
15:28 dreamreal OOOO I REMEMBER HIM!
15:28 dreamreal yeah
15:28 Chronos dreamreal: hahahaha
15:28 dreamreal or pudge on #perl
15:28 * Chronos hugs blue
15:28 dreamreal hey I didn't say it was blue
15:29 dreamreal pr dibblego in #scala, may tony morris be forever remembered
15:30 dreamreal oh wow, claude KNOWS WHO TONY MORRIS IS
15:30 dreamreal hahahaha
15:30 dreamreal IMMORTALITY AS AN ASSHOLE!
15:33 dreamreal that's... pretty bad, if dibblego was so memorable that the LLMs remember him as being a jerk
15:33 dreamreal I mean, he IS pretty memorable: "I am a total asswipe douchenozzle because... hold on, checking the 8 ball... I have autism! No, wait, shaking it again... oh MY BACK IS INJURED"
15:51 dreamreal Chronos: new push to the branch, actually fixed the things you pointed out, and thank you as always
15:52 dreamreal all this damn GDPR talk... grrr
16:23 blue blame timon on that
16:24 dreamreal he's not wrong
16:24 dreamreal and fixing GDPR issues in the future is a lot harder than fixing them now
16:24 blue he's being unnecessarily alarmit and FUDing
16:24 blue alarmist*
16:24 blue I'm the only one here who lives in Europe, to my knowledge
16:24 dreamreal I disagree: we have GDPR issues in another app we work on, and it's a true pain in the rear
16:24 blue I RAN a website/business in Europe
16:25 blue So I tihnk I can be trusted on this GDPR nonsense
16:25 dreamreal you are not, however, the only one who WORKS in Europe :D
16:26 blue the GDPR is pretty straightforward. if you collect more than you need to collect, ie collect for the sake of collection, THEN it gets ugly
16:26 blue if you collect what you NEED to allow users to be users... it's trivial.
16:26 dreamreal the main concern *I* have for GDPR is right to remove and collect; both issues are addressed.
16:27 blue what right to collect?
16:27 dreamreal user have a right to download their data and contributions
16:27 dreamreal IANAL but andrew and I work with some
16:27 dreamreal so I added a hook to download posts and comments contributed by the user
16:31 blue you don't need to mechanise it. it the user asks, you can provide it
16:31 blue as long as no users asks, it's theoretical
16:31 blue YAGNI
16:31 blue stop listening to timon
16:31 dreamreal 1) shut up, don't tell me who to listen to 2) providing the endpoint for THAT was among the easiest aspects of the whole thing
16:32 dreamreal that fell out of the data model almost by implication
16:32 blue easy doesn't mean good!
16:32 blue literally. how can I take a guy seriously who derailed a discussion about a SECURE auth measure into GDPR nonsense?
16:33 dreamreal I don't know how to answer that, because I could see it AND it's valuable
16:40 Chronos blue: Where in Europe do you live? If you don't mind saying.
16:43 Chronos Holy crap. My IRC client is giving me "xxx is typing" messages. Must be from some of the recent IRCv3 updates.
16:43 dreamreal which client are you on?
16:43 Chronos IRCCloud
16:44 Chronos I actually pay for it! (gasp!)
16:44 * dreamreal spots the dumbie
16:44 dreamreal but that's fascinating. I didn't know libera even tried to do ircv3
16:45 Chronos I briefly considered installing TheLounge following their easy 200 step process, and configuring it correctly using another 200 step process, and keeping it up-to-date by following yet another easy 200 step process, but then I paid for IRCCloud.
16:45 Chronos dreamreal: Libera.Chat recently (like, within the last 2 weeks, or so) upgraded their IRC servers to a newer version that supports some new IRCv3 features.
16:45 * dreamreal just uses weechat like a masculine man who uses masculine manly things like a lumberjack
16:45 Chronos Apparently, including typing indicators.
16:48 dreamreal I wonder when the other clients are gonna catch up
16:50 Chronos Over the years I've switched back and forth between irssi-on-Linux-VPS and IRCCloud.
16:50 Chronos When my IRCCloud subscription ends, maybe I'll try WeeChat. Does it have a mobile client that can connect to an instance of WeeChat?
16:52 dreamreal I don't think so, it would BE the mobile client, but it DOES have a sort of c/s architecture; I don't know how complete it is.
16:52 dreamreal senpai apparently supports ircv3 but it's written in go
16:53 dreamreal go doesn't bother me much but senpai looks very twee
18:02 dreamreal any further comments on that PR?
18:02 dreamreal I'd love to commit it so I can 1) pretend the issue's closed 2) hand it off to other people
20:18 Chronos dreamreal: lgtm.
20:33 dreamreal Thanks!
20:51 dreamreal blue: merged, btw: dual-path, plus docs, all merged. I'm going to set up the prod deployment to support it, although obviously the UI is trailing now.
21:13 blue Chronos: Germany
21:13 blue do you guys even READ wallops?
21:14 blue https://libera.chat/news/new-and-upcoming-features-3
21:15 dreamreal no, because I rarely care about those things
21:15 blue 17:50 < Chronos> Over the years I've switched back and forth between irssi-on-Linux-VPS and IRCCloud.
21:15 dreamreal I use IRC to talk to people, not leverage a protocol
21:15 blue I'm irssi-on-vps, RIGHT NOW.
21:17 blue I'm not entirely surprised dreamreal is using weechat; weechat is basically the same as irssi, just for morons
21:18 blue dreamreal: also, at the cost of being late: LGTM
21:18 dreamreal I found irssi to be insufficient; weechat's UI worked better for me.
21:18 dreamreal I'm working on the OIDC identification stuff, which will help clear up the API. I figure I'm going to have a deployment structure like this:
21:19 dreamreal www.bytecode.news, bytecode.news, nextjs.bytecode.news, primate.bytecode.news - with www. and . pointing to EITHER nextjs or primate
21:19 dreamreal and then there's a rest.bytecode.news domain which exposes the backend services via a stable endpoint
21:19 dreamreal so nextjs and primate both use https://rest.bytecode.news/api/blog/posts or whatever
21:20 blue I'd been thinking about it, and I wonder how much I want to translate the actual back to primate paths. you see, using nextjs/primate is *a bit* of an overkill. they *both* are fullstack frameworks
21:20 blue the actual backend*
21:20 blue so the level of indirection is significant. you have real backend, then 'fake' backend, then frontend
21:20 dreamreal are you talking about primate *replacing* the rest endpoints? talking to the DB directly?
21:21 blue I'm not. I'm just thinking where the seams would lie between the real backend and primate (or nextjs, for that matter)
21:21 dreamreal *nod*
21:21 blue both are backends. primate could even run java -- or kotlin code -- via wasm. although that's somewhat futuristic given >=java 25 and some limitations without a jvm, no idea if your code specifically relies on that
21:21 nevet both are backends. primate could even run java -- or kotlin code now has karma of -1.
21:22 blue (specifically=reflection)
21:23 blue at this point in time, I'm thinking about this: primate generates an openapi client using the spec. then, it exposes those paths directly via a /rest subpath
21:23 blue the frontend using primate, whatever it is, talks directly to these subpaths
21:24 blue though I'm not entirely convinced yet this is the best way to go about it
21:24 dreamreal and THEY redirect content to the actual backend, you mean?
21:24 blue yes. it's not even a proper redirect, the request is likely piped 1:1, almost
21:24 dreamreal *nod*
21:25 dreamreal I mean, that makes sense to me
21:25 dreamreal it's a little heavier - it adds a few ms to every interaction, but most interactions should be pretty quick
21:25 blue like, I truly need to think about what having an interim backend even means. so one thing it means: we avoid any CORS nonsense. CORS is an absolute nightmare
21:25 dreamreal it is, but I'm going to have to address it anyway
21:26 dreamreal the backend is already set up to accept CORS requests from different domains
21:26 blue by having the interim backend and the frontend on exactly the same domain (or subdomain), you completely eliminate this error category. it is probably worth having only for *that*
21:26 dreamreal *nod*
21:26 blue but what else? like, what does the interim primate (or nextjs) backend add, exception indirection?
21:26 blue except*
21:26 dreamreal not a lot, but that's probably a GOOD thing
21:26 bot [jottinger/bytecode.news] New issue #107: Unify and reorganize documentation - https://github.com/jottinger/bytecode.news/issues/107
21:26 bot [jottinger/bytecode.news] New issue #106: Split baseUrl into API and frontend URLs for OIDC stability - https://github.com/jottinger/bytecode.news/issues/106
21:26 bot [jottinger/bytecode.news] New PR #108: More OIDC changes - https://github.com/jottinger/bytecode.news/pull/108
21:27 blue well, let's think what nevet *can't* do, at least in its current form & scope
21:27 blue it can't do SSR - it's not meant to do that
21:27 dreamreal SSR = ?
21:28 blue server-side rendering
21:28 blue are you familiar with SPA/SSR/hydration, or should I shortly explain?
21:28 dreamreal no, I just needed to know what the acronym was, with you now
21:29 blue ok. anyway, if you have a pure frontend (say, react) talk to nevet's backend -- which is a possibilities -- you would never get SSR. only SPA. that means your initial request is an empty HTML
21:29 nevet ok. anyway, if you have a pure frontend (say, react) talk to nevet's backend -- which is a possibilities now has karma of -1.
21:29 blue there's also of course the question of what static server serves those resources, which is yet another layer
21:29 blue normally, that would be nginx
21:30 blue or apache, for the traditionalists
21:30 dreamreal I'm not going to be deploying httpd, it's nginx on my server, caddy's a possibility but ... it's nginx
21:30 blue but let's assume for a moment that's a piece of the puzzle. in that case, your first contentful paint would be... not good
21:30 dreamreal my thought was that each subdomain was *self-contained*
21:31 dreamreal so it's foo.bytecode.news and rest.bytecode.news, and everything is on those two domains for foo.bytecode.news to render
21:31 dreamreal the nginx config does the proxy passthrough for both domains, and cert management
21:32 blue there's also things like jwt/cookie management, and auth, which need to be address
21:32 blue addressed, even
21:32 dreamreal well, auth is part of the rest stuff - that's all the 67 stuff we just did, jwt is part of it too (and has been for a while), aad cookies are up to the front end
21:32 blue where I can see a primate backend shine is, composing complex operations on top of simple REST queries
21:32 dreamreal the back end doesn't use them
21:33 blue for example, the login sequence is composed of several API calls, but it might be hidden away under just one path
21:33 dreamreal right now, with OTP, we SHOULD be able to deploy *right now* with no OIDC providers set up
21:33 dreamreal sure
21:33 dreamreal I'm reorganizing the docs, btw
21:35 blue this brings me to an organisational point: we need deployment docs. if I am to write a frontend, I need to be able to easily run nevet locally. docker could work, though I'd prefer nspawn (not a purist though -- if you furnish me with a Containerfile, I'll take care of it myself)
21:35 blue (why did nevet not pick up my last message as karma?)
21:35 blue I guess maybe cutoff limits
21:36 dreamreal yep
21:36 dreamreal I'm working on the docs, you SHOULD be able to run the backend in a container really easily
21:37 blue well, that's the only way to properly test it and come across real implementation issues
21:37 dreamreal dpcker compose up db backend # should do it
21:37 blue can you provide a Containerfile (or a Dockerfile, same thing really)?
21:37 blue also, that'd probably require making the repo public?
21:38 dreamreal why would it require making it public? You have access to the repo: you can literally clone it, do `mvnd package`, then run docker
21:38 dreamreal (doing the build IN docker is bonkers mad, don't do that)
21:39 blue what's mvnd? the idea of a container is to avoid me having to have all these tools locally
21:39 dreamreal I get that, but yikes
21:39 dreamreal main requirement for nevet is having java 25
21:39 dreamreal if you have that, you're done
21:40 blue I might have that; BUT, that's something ideally you shouldn't need to have
21:40 dreamreal java 25 + the repo: ./mvnw package -DskipTests=true (if you know the repo is in known-good state)
21:40 blue iirc the only reason I have java 25 is because I was messing around with wasm :P
21:40 dreamreal yes, well, I agree but making the repo public and putting up a public container is a step I'm not ready for
21:41 blue tell you waht. can you bake a CP step from, say, ./repo, into the container?
21:41 blue that's a good compromise, no?
21:41 dreamreal that's literally what teh dockerfile does :D
21:41 blue yes but I meant the source code. the rest happens inside the container
21:41 dreamreal https://github.com/jottinger/bytecode.news/blob/main/Dockerfile
21:42 blue so I can just do `git pull`, then rebuild the image
21:42 dreamreal oh, you CAN do that but it's a waste of 15 minutes
21:42 blue not for me -- I use nspawn, which gives me essentially native performance
21:42 nevet not for me now has karma of -1.
21:42 dreamreal it nets you NO win whatsoever
21:43 dreamreal I'm not familiar with nspawn, so I don't know - there's no ACTUAL barrier to building in a container outside of the container mechanism sucking
21:43 blue all you need to do is install mvnd inside the container and run it, no?
21:44 dreamreal it's just very slow and with far less CPU access; mvnd does parallel builds, if you have it installed, so I deploy nevet within about 30 second for a full rebuild, the full build with tests is about 1:40 on my M3
21:44 dreamreal only if the container has full thread access
21:44 blue bonus is you get assurance the desired mvnd version is used for building
21:44 dreamreal it's going to be limited to the container's resources
21:44 blue so you get full reproducibility
21:44 blue which is perfect
21:44 dreamreal ./mvnw gets you that already :D
21:44 blue *sigh*
21:44 blue fine, I'll do it YOUR way
21:44 dreamreal that's the maven wrapper, I *do* lock the maven version, and maven's usually pretty good about it anyway
21:44 blue it's not you ever accept a suggestion of mine!
21:45 dreamreal well, if any of your suggestions were good... but more seriously, I have a major project that does mvn builds in the container, and that process SUCKS for java
21:46 dreamreal and there's literally no win: cp app.jar into the container is the right way to go until we go graalvm. When we do THAT, you'll get your container builds.
21:46 blue also chatgpt says there's no difference in speed between running mvn in docker or without
21:46 dreamreal (and builds will take 30 min, not 1;40 or 15 minutes.)
21:46 blue unless apparently, you're on mac
21:46 blue great
21:46 dreamreal I'm sure chatgpt does.
21:46 dreamreal It's wrong, but hey.
21:47 blue you know what? I don't care. I'll take your Containerfile and just edit it to fit MY purposes. It's not like I need to ask you for permission
21:47 dreamreal for maven single-threaded, it's probably pretty close; docker's overhead wouldn't matter much. for parallel builds, it's a lot more severe.
21:47 dreamreal There you go!
21:47 dreamreal just don't commit it to main until I can approve it.
21:48 blue ya
21:49 jreicher dreamreal: where's the discussion of why Strings aren't value classes? I feel like I've missed something (and I'm a bit curious about what everyone thinks)
21:49 dreamreal jreicher: I dunno, I don't live and die on valhalla discussion
21:49 dreamreal but now my wife has made dinner and she's a lot prettier than you guys are
21:49 jreicher Oh I thought there had been a discussion you had participated in
21:49 jreicher That's not fair. You haven't seen me dresesd up.
21:50 blue [INFO] BUILD FAILURE
21:51 blue [ERROR] No goals have been specified for this build. You must specify a valid lifecycle phase or a goal in the format <plugin-prefix>:<goal> or <plugin-group-id>:<plugin-artifact-id>[:<plugin-version>]:<goal>. Available lifecycle phases are: pre-clean, clean, post-clean, validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes,
21:51 blue generate-test-sources, process-test-sources, generate-test-resources, process-test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy, pre-site, site, post-site, site-deploy. -> [Help 1]
21:52 blue ah, there we go!
21:53 jreicher blue: just saw earlier you said new String("foo") == new String("foo"). I'm guessing you think that should be true?
21:53 blue jreicher: yes
21:53 blue [ERROR] Failed to execute goal io.github.git-commit-id:git-commit-id-maven-plugin:9.0.2:revision (default) on project streampack:
21:53 blue [ERROR] The plugin io.github.git-commit-id:git-commit-id-maven-plugin:9.0.2 has unmet prerequisites:
21:53 blue [ERROR] Required Java version 11 is not met by current version: 1.8.0_482
21:53 jreicher Right. i think that's a useful way to talk about the real problem. Compare with 5 == 5, which is actually true. What's the massive difference between the two expressions?
21:53 blue ➜ bytecode.news main ✓ java -version
21:54 blue hm, I guess it takes openjdk 8
21:54 blue THIS IS WHY I HATE THIS NONSENSE
21:54 jreicher I don't know if you're reacting to what I said or the errors you're pasting
21:54 blue jreicher: no difference
21:55 jreicher There absolutely is a difference. It's obvious, and large.
21:55 blue I was reacting to the errors I was pasting
21:55 blue what's the difference?
21:55 jreicher "new"
21:55 blue oh, you're gettign me wrong
21:56 blue I also think new Long(1) == new Long(1) should be true
21:56 blue which it will be, under valhalla
21:56 jreicher The point I'm making is that new... == new... can't mean the same thing as literal == literal
21:56 jreicher So even if you made it work the way you want, you have to supply a different meaning to == in the context of new
21:58 jreicher Or, put another way, the result of the comparison is not the same thing as the meaning of the comparison.
21:58 blue so, to go back to first principles, my position is that immutable variables: long, Long, int, Integer, String, should always parse == as 'by value'
21:58 jreicher There's no such thing as an immutable variable. (I know that's horribly pedantic, but I want to tease out what you "really" mean
21:59 jreicher Because if I do int x = 5, there's only one variable there
21:59 jreicher But if I do Foo x = new Foo(), there could be too, if Foo is mutable
21:59 jreicher ^too^two
21:59 blue come on. you know what I mean. String s = new String("foo"); you can't change JUST 'f' to 'b'. You can rebind the variable to a new value, you cannot mutate it
21:59 jreicher Or more, actually, depending on how many mutable attributes Foo has
22:00 jreicher No, I THINK I know what you mean, but I want to make sure I'm right.
22:00 blue same for int i = 1; i = 2 is not mutation, but rebinding
22:00 jreicher OK, so you're talking about an immutable object there, right?
22:00 jreicher new String("foo") constructs an immutable object. That's what you mean?
22:00 blue yes. as do new Long, new Integer, or int, or long
22:01 jreicher Yep. But if we do int x = 5, there's no construction at all. And that's what matters. Not mutability, but construction. Values aren't constructed.
22:02 blue This is where we get into the territory of, to my taste, a distinction without merit. What matters to me is, can you think of a case where two "foo" objects differ in any meaningful (=real) way?
22:02 jreicher Yes. At compile time. That's why this matters.
22:02 jreicher Compilers can do some value analysis. They can't do any immutable object analysis, becauses the objects don't exist yet.
22:02 blue Yes, but you're pulling the cart before the horses here -- you're talkign about how it's technically currently done in the JVM. I'm talking about a use case
22:02 nevet Yes, but you're pulling the cart before the horses here now has karma of -1.
22:03 blue I would like you to describe a use case where the distinction is important
22:03 blue like, a real situation where it's good to have two strings "foo", and be able to compare them by identity -- but not by value
22:03 nevet like, a real situation where it's good to have two strings "foo", and be able to compare them by identity now has karma of -1.
22:04 jreicher If you already know the strings are "foo" then the scenario begs the question. We need to ask about this distinction where at least one of the strings is unknown.
22:05 blue I'll play devil's advocate for you
22:05 blue a real 'use case' is if you're writing a compiler in java, and objects are coming in, and you want to track (by identity) if you've already seen an object or not
22:06 jreicher OK...
22:06 blue the rebuttal to this is: this is *not* a real use case. compilers aren't written this way: it's not effective at all, and you wouldn't be comparing references for that
22:07 blue my personal issue is, no one has given me a real use case for comparing strings by identity and not value
22:07 blue maybe it's all moot to you, but to me it'd help me understand why the == and .equals distinction makes sense, if it does
22:22 jreicher So you're saying because nobody would ever compare with identity, that operation shouldn't even exist?
22:31 blue essentially yes: I'm saying, the only meaningful comparison of two strings is by value (=contents). the comparison by identity is not meaningful
22:32 blue you would never construct two "foo" Strings and expect them to differ: for what purpose?
22:34 blue also, consider the implications of this for project valhalla:
22:35 blue value class Point(int x, String y) {}
22:35 blue Point p1 = new Point(1, "hi"); Point p2 = new Point(1, "hi"); p1 == p2; // false, string comparison broke it!
22:40 blue the bottom line here: comparison by reference *only* makes sense for mutable objects, where the truthiness of the check could vary over time. but the two strings "foo" and "foo" will always be the same
22:40 blue iow: the original story of `new String("foo")` is meaningless
22:41 blue s/original/origin/
22:41 dreamreal no, those would not be uneqial because of string comparison
22:41 dreamreal you don't seem to grok references
22:41 dreamreal think of them as pointers
22:41 blue what are you talking about?
22:42 jreicher OK, then for the sake of argument, how would you feel about the Java compiler throwing an error for == used on Strings. Meaning we change the == to being undefined in that case, and you can only use equals()
22:42 blue jreicher: THAT would be a huge improvement already!
22:42 dreamreal char **c1=malloc(10); char **c2=malloc(10); strncpy(c1, "hello", 6); strncpy(c2, "hello", 6); // are c1 and c2 equal? Why not?
22:42 blue dreamreal: dude, you're COMPLETELY missing the point. you're talking about implementation. I'm talking about MEANING
22:43 blue java is NOT a low-level manipulate-the-memory-directly language, the point holds not
22:43 jreicher blue: but the meaning of String, at least at the moment, is that it's not a value.
22:43 dreamreal I disagree, bevause that's literally where == is playing in
22:44 blue jreicher: that's the interpretation of the java language, but that's also my criticism
22:44 blue for example, it is NOT the interesting of the javascript language
22:44 blue s/interesting/interpretation/
22:44 jreicher In that case we're not talking about == vs equals(). You're objecting to Java not having a primitive string type.
22:45 blue if you want to weave it that way, sure: the argumentation would be that strings are immutable, and as such, inherently primitive (as they are in js)
22:45 blue I don't mind shifting my argument there, that's fine by me, it's all the same to me
22:45 jreicher immutability does not a value make. I think you need to separate those two things.
22:46 jreicher The value is part of the STATIC definition of the type.
22:46 blue the point remains that two occurences of the value "foo" (regardless if you do it via new String("foo"), or an idealised string primitive), are one and the same: the distinction here is invalid
22:46 jreicher It's immutable as a consequence, but that's not the essential nature of it.
22:47 jreicher There's no "foo" value in Java. It doesn't exist.
22:47 blue do you mean it would be possible to constract a language where parts of a string are immutable? like c? sure
22:47 blue construct*
22:47 jreicher No. I'm not talking about immutability at all. It's irrelevant.
22:47 jreicher The only question that matters is value vs object
22:47 blue jreicher: then that's the criticism. values are much more important than object identity, for strings
22:47 jreicher There are no string values in Java.
22:48 blue yes, I never claimed there were
22:48 jreicher OK. Then maybe we move on to the next part. Do you know why?
22:48 blue why it's implemented/done this way?
22:49 jreicher Not so much implemented as designed. It's a design decision, not an implementation decision.
22:49 blue is the history really relevant here?
22:50 jreicher It's not history. The reasons for the decision still apply. If I was designing something like this now I'd probably do the same.
22:50 blue OK, what are the reasons?
22:51 jreicher My understanding is that they wanted (needed?) all the value types to have a finite, fully determined range of values. That's true of everything "philosophically "considered a value, including enums. Strings are really very, very special in having a range of values constrained only by the memory available at runtime.
22:51 blue And strings would be unbounded?
22:52 jreicher Strings are currently unbounded AFAIK.
22:52 jreicher In principle.
22:52 blue That argumentation makes little sense to me, why would you want to impose that kind of restriction?
22:52 jreicher Would you be comfortable with an int type that was unbounded?
22:54 jreicher (It would be fine if you were; I'm just trying to get to the heart of the issue)
22:55 blue Can't say I would, but I can also not say it's relevant to the string discussion
22:55 blue (btw: having an unbounded int type such as BigInt in JS is immensely useful!)
22:55 jreicher No argument with it being useful. But why would you be uncomfortable with it? That's probably worth teasing out.
22:56 blue I guess... I haven't thought about it, but I can't say I would and I can't say I wouldn't, I don't have an opinion on it, to be honest
22:57 jreicher OK. Well for the sake of argument we decide that our language is not going to have any unbounded value types, then the notion of string you are advocating is ruled out before we even start thinking about string.
22:57 jreicher ...if we decide...
23:00 blue Is this not purely theoretical? I mean, JS doesn't have that problem. The ECMAScript standard allows up to 2^53-1 characters, but it's usually memory-bounded/limited by the engine.
23:00 jreicher JS has different problems. ;)
23:00 blue Yes, but comparing strings by == isn't one of them, that's the crux of the matter
23:01 jreicher But seriously I think the only way to make sense of the issue to take the big picture of all the tradeoffs. I'm sure I don't have the full picture, but I know enough to believe that a small view doesn't make sense.
23:01 blue To be honest, I can't see downsides. If you compare all strings by value you can easily memoise them and save memory.
23:01 jreicher To do what you want you either have to make string a value type, in which case you compromise a more fundamental decision in java, or you have to overload the meaning of == to cater for something which isn't a value type, which again compromises a more fundamental decision.
23:02 blue Yes, I'd make it a value type. What fundamental decision I would compromise, the boundedness?
23:02 jreicher Yep
23:02 jreicher And maybe that's ok
23:02 blue Then why allow new Long(1) == new Long(1) => true under valhalla, what's the difference?
23:03 jreicher I think so, yes, although I'm not sufficiently familiar with valhalla. I think a better comparison might be with what's in the JDK right now for bool. Just a moment...
23:06 jreicher It jumped out at me recently that there's no non-generic version of the functions in java.util.function for boolean. AFAIK stuff like IntConsumer and IntPredicate exist so that if you have an (unboxed) int you don't have to incur the cost of boxing it to pass to e.g. Consumer<Integer> or anything like that. So they're saying that something like Consumer<Boolean> would not be expensive. Why? Because the boxed values are already
23:06 jreicher constructed. There's only two of them.
23:07 jreicher So anything that can be done without incurring this kind of runtime cost will be allowed
23:11 blue There's another aspect I haven't mentioned, jreicher.
23:11 jreicher Mm?
23:12 blue Consider this method: `public static boolean test(String a, String b) { return a == b }`
23:12 blue This method returns true, or false, depending on the *origin* story of the strings. That's a big red flag, in my eyes.
23:13 blue test("foo", "foo") => true, test("foo", new String("foo")) => false
23:13 blue that's bad: there's no way for me, in the `test` function, to know what the origin story of a and b is
23:13 blue so I would *always* use .toEquals, instead
23:13 blue or .equals, I mean
23:13 blue that means the == operator is *completely* useless for strings
23:14 blue to use it properly, I need full knowledge of the origin story of the string: contructed per new String, or per ""
23:14 blue that's ridiculously broken, in my eyes
23:15 blue in any non trivial codebase, I will never have full knowledge of the origin story of a string
23:18 blue it even gets more complex that test("foo", "fo"+"o") will yield true. even dynamically created strings partake of it
23:19 blue but now say I've extracted "o" to String o = "o";
23:19 blue suddenly, test("foo", "fo"+o) => false
23:19 blue generally, extracting a direct value in a language to a variable should not create unintended side-effects; here it does
23:20 blue (or better said: in a *high-level* language; if you manage memory yourself as in c, you get value expansions and contractions all the time)
23:24 blue incidentally, this is a criticism I have of TypeScript. { foo: "bar" } passed directly to a function would satisify the exact type { foo: "bar" }; extracting this to a variable: const a = { foo: "bar" }; will expand it, resulting in a's type being { foo: string }
23:24 blue that makes refactoring a nightmare
23:25 blue in my opinion, unless you gave TS a proper type: say, const a: { foo: string } = { foo: "bar" }; it should keep it narrowed, but it doesn't
23:26 blue autoexpanding/weird magic is crazily confusing, especially in high-level languages
23:29 jreicher blue: why would you not do `return a == b || a.equals(b)`? I think that's using object identity in exactly the way it's somewhat intended; as an optimisation
23:30 jreicher (I suspect equals() is implemented this way for String anyway)
23:30 blue jreicher: I could, but why should the language force me to do it? The language implies a distinction (== vs equals) without merit
23:31 blue if I could just do == for strings, none would be the worse for it
23:31 jreicher And I'm suggesting that the language doesn't give two hoots about == vs equals. It just "knows" that it has no notion of strings-as-values and everything else is a consequence that it doesn't care about.
23:32 blue We're word-juggling at this stage; you're saying the language has no notion of strings-as-values, and I don't disagree -- that's a reductive form of my criticism
23:32 nevet We're word-juggling at this stage; you're saying the language has no notion of strings-as-values, and I don't disagree now has karma of -1.
23:32 jreicher blue: because I do indeed thing your criticism reduces to something else. You are criticising the consequence o a decision that was made on unrelated grounds.
23:33 jreicher Please note I have never said == for strings working the way you say is a bad idea. This is why.
23:35 blue That's quite possible, jreicher. But even with knowledge of the decision's grounds (boundedness), I still think it was the wrong decision. Sure, telling people to just "suck it up and that's how Java does things, and you're a n00b if you don't get it" (dreamreal style), is possible. It's just not very useful.
23:36 blue I don't care about being a good or bad Java programmer -- I care about using languages that help me not do crazy nonsense. That's why I use very strict linting rules for JavaScript, because JavaScript has its fair share of brokenness.
23:36 nevet I don't care about being a good or bad Java programmer now has karma of -1.
23:36 jreicher OK, I'll put in some of my own opinion here. I believe most people expect the runtime of operators to be bounded in any language that does not have operator overloading. (That last bit is important.) So I believe there is an expectation that == should have bounded runtime. You can probably see where I'm going.
23:37 jreicher And I have some experience with the flip side of this. The number of corporate application problems I have had to deal with because some idiot dev though string comparisons on a database came for free...
23:38 blue So you're talking about runtime optimisations?
23:38 jreicher Not optimisations. The fundamental definition of the performance. The predictability of it. The expectation.
23:40 blue Well, if such an expectation exists, I certainly cannot see it being used in JS.
23:40 jreicher I did say JS has different problems. :)
23:41 blue True... for example, I don't use the == operator in JS, at all.
23:42 blue The coercion rules are arbitary and an endless source of confusion.
23:42 blue I also configure my eslint to only allow boolean expressions in `if`, i.e., no casting. if("foo") would pop up as an error.
23:43 jreicher That's why predictability in language is important. And on the flip of the flip side I'm all in favour of having unpredictable performance in contexts where performance is not the primary concern.
23:43 jreicher And in those contexts I would be completely on your side about something like the meaning of ==
23:43 blue (reason: if ("") "hi" -> undefined; if ("1") "hi" => "hi"
23:43 jreicher (probably)
23:45 blue (since the real check you want here is probably: if (str !== ""), or better expressed: if(str.length > 0)
23:45 blue anyway, yes
23:45 blue predictability is superimportant. overloading operators is very confusing
23:46 blue dreamreal at least agreed that + for strings is weird... unfortunately, it's become an almost global standard
23:46 jreicher Oh interesting. I missed that comment.
23:46 jreicher But what I've been saying probably supports that. It's an operator with unbounded performance. Possibly the only one in Java. (I have to think about that)
23:47 blue JS is totally weird on that, btw: [] + [] is ""... that's funky
23:47 jreicher I guess you could say "new" is in that category also. I think it's an operator.
23:47 blue new is definitely an operator
23:47 jreicher People who defend string + probably say it implies new
23:48 jreicher ...and is right to do so
23:48 blue you know, come to think of it, my real pet peeve isn't even `new`. It's just the fact that `String foo = "foo";` is fundamentally different to 'just' "foo"
23:49 blue IOW: we can leave the operator new completely out of the discussion. It's not even the crux of the matter, to be honest
23:49 jreicher Not sure I'm following, but you have my interest. Can you elaborate?
23:51 blue As said, consider my example from earlier:
23:51 blue test("foo", "foo") is true
23:51 blue test("foo", "fo"+"o") is also true
23:51 blue String o = "o"; test("foo", "fo"+o) is false
23:51 blue there's no `new` involved anywhere here
23:51 blue we've only extracted "o" onto a variable, and broken things with it
23:52 blue that's... unpredictable.
23:53 blue this class of errors can never happen in JS. It's impossible to extract a value to a variable and break stuff with it.
23:54 blue it's a category error that doesn't exist in JS
23:54 blue As a programmer, it's important to me to be able to refactor such things with the utter confidence that I'm not breaking anything. Java fails that promise.
23:55 blue As a Java programmer, I now need to be *aware* of the implementation detail of `test`, namely that it uses `==`.
23:56 blue But I can't always do that -- nor should I. `test` might be coming from somewhere else, or I might not even be able to look into it
23:56 nevet But I can't always do that now has karma of -1.
23:58 blue oh, shut up! dreamreal fix that nonsense! :P