ByteCode.NewsSubmit
Use quotes for an exact word.

Subscribe

RSSPodcast
Log in

Chat Logs

  1. * jreicher quit (Quit: In transit)
  2. * skillnews quit (Remote host closed the connection)
  3. * skillbot quit (Read error: Connection reset by peer)
  4. * skillbot joined #primate
  5. * skillnews joined #primate
  6. * jreicher joined #primate
  7. * jreicher quit (Quit: In transit)
  8. * jreicher joined #primate
  9. nevet[ByteCode.News] Where Does The Experience Come From? - https://bytecode.news/posts/2026/11/where-does-the-experience-come-from
  10. bluedreamreal: thoughts on `var` in java? after we moved to java 21 at work, my boss signalled being against it. I largely agree, in that. a strongly typed language that hides its types is.. weird. That being said, the verbosity of potentially declaring the same type left and right is weird. a language should provide good abstractions for it
  11. blue(this is slightly related to the above article)
  12. blue(re knuth "read like essay")
  13. dreamrealIt doesn't hide the types, though: var foo=new ArrayList<String>() <-- the type is right there, why would you NEED it redeclared? var isn't appropriate outside of tightly scoped functions
  14. bluecit approach: enforce left, be nice on right; Point point = { x: 1, y: 2 }; where Point is a struct with fields x and y, both i32
  15. dreamrealI'm actually kinda neutral on var
  16. dreamrealI use it but eh
  17. bluedreamreal: it doesn't in YOUR example. but it does when right is NOT a `new`
  18. bluethe invariant isn't universally held
  19. blueex: `var foo = bar.subList(0, 1);`
  20. * dreamreal nods. I am not a pedant when it comes to var. Use it when it helps, ignore it when it does not.
  21. dreamrealIt is not rocket science.
  22. dreamrealif that means no var ever, well, there you are: you have to be able to read your own codebase.
  23. bluenothing is rocket science, except rocket science. however, communicating intent, and being transparent, are invaluable, I think. it's nice to know this is a List or an ArrayList *without* hovering over it
  24. blue`var` feels to much javascripty to me: in a bad way, for a statically typed language
  25. bluetoo much*
  26. dreamrealIf you're using concrete types in your lvalue without that being significant, you're doing it wrong!
  27. dreamrealvar comes from languages like JS, scala, kotlin
  28. blueya hence List
  29. blueI'm just not very comfortable with var; or auto in c++, for that matter. I fear the gains aren't significant, and the payment is dear
  30. blueanyway, good article
  31. dreamrealThank you.
  32. bluedreamreal: btw, another thought: "The LLM affirms" is generally, but not *universally* true. In my example, "the clanker is servile" is the more accurate observation. It will generally pushback first, if it can; especially if the conversation has little charted ground yet (your tone is less authorative). Generally speaking, it will try to accomodate a niche between its general knowledge and your wishes. But
  33. blueit doesn't affirm universally, all the time, everywhen
  34. blueIn my experience*
  35. bluepush back*
  36. blueauthoritative*, oof, my typing is terrible
  37. * skillbot quit (Remote host closed the connection)
  38. * skillnews quit (Remote host closed the connection)
  39. * skillbot joined #primate
  40. * skillnews joined #primate
  41. bluedreamreal: anthropic IPO nov 20 or thereabouts
  42. * phaleth joined #primate
  43. bluehi phaleth
  44. phalethhi blue
  45. blue0.45 expected this week, god willing
  46. bluealso known as the Trump #1 release
  47. blue:P
  48. blueI hope 0.46 won't be slow...
  49. blue^ dreamreal
  50. phalethrepopack is already updated to 0.44
  51. blueyes
  52. phalethmobile perf of primate website is still very good https://pagespeed.web.dev/analysis/https-primate-run/wyxa3mh0bb?form_factor=mobile
  53. phalethis the website expected to become slower?
  54. * phaleth quit (Quit: phaleth)
  55. jreicherblue: I use var wherever it's possible, partly because finding where it's not possible is sometimes useful information.
  56. jreicherDitto with <>
  57. jreicherI'm aware of (respectable) arguments against var though
  58. bluejreicher: I do use <>; also recommend by my boss. but var I do not use at all; I wouldn't use it even had he blest it
  59. bluerecommended*
  60. blueas I laid out above, there are scenarios where using var obscures the type, when you read it. this isn't a big deal statically, but it makes overviewing code harder, for no good reason other than terseness
  61. blueit also violates a certain principle wherein Java is different than JS; a JS var/let/const can bind to any type; this is not the case in java; but `var` seems to suggest that. And last but not least, the name is preencumbered by other programming languages
  62. blueI think those three arguments satisfy the threshold of "not worth to use"
  63. bluedreamreal: flog is edging closer to being able to format the rcompat project; after that, primate. if you wish, I can also train it on `ui-primate`
  64. bluenote that it formats in an opinionated way, much like prettier does; 2-spaces, double quotes, 80 columns
  65. bluethe main adventures is that it is very fast and that it spares you from dealing with a formatting policy in your project
  66. blueit will format .ts and .js files for starts, probably .tsx/.jsx later (irrelevant in your case, you use marko)
  67. dreamrealblue: not a matter of wishes on my part, if it's useful, USE IT
  68. bluedreamreal: primate 0.45 is getting transactions, and it is absolute amaze sauce!
  69. jreicherblue: your last two points aren't relevant to Java because, quite literally, they are not about Java. It's not really a valid argument to criticise a language for confusions suffered by people proficient in other languages.
  70. blueawait using tx = await db.transaction(); /* await OtherStoreINeedLocked.lock(); await Store.update(); await tx.commit();`
  71. bluea few notes about `await using` in JS: it's relatively; it uses known global symbols to allow you to clean up automatically upon leaving context; in this case, the transaction will automatically roll back if the route handler throws
  72. bluerelatively new*
  73. blueit also uses async context, which is another, not new, but relatively lesser known feature of JS. it basically allows you to 'serialise' (I'm oversimplifying it) callbacks
  74. blueI learnt about it a year or two ago from systemfault, and it's really cool. this is how we 'connect' the stores to the transaction
  75. blueit's a bit of magic, but I think it's good magic (tm) there
  76. bluehm, I botched up the example, should have not written /* there
  77. bluejreicher: I disagree. language designers do not live in a vacuum. they look at prior art, and it's a perfectly valid argument to criticise them for confusings they have created, by overloading known terms
  78. blueexample: TS people refer to arrays like this: [string, number] as tuples. the term is misleading: tuples are NOT arrays of a fixed length and fixed types. I suppose they borrowed the tuple term because in this case, the order of the types matters, but they are not tuples. it would have been better to call them bounded arrays or something that expresses better what they are, but the decision was made to call
  79. bluethem tuples
  80. bluethe java designers have choices; they could come up with a new keyword, they could choose to not introduce `var` because on how ubiquitous it is already, the fact it exists in js, is highly associated with it, and even in js itself, has very confusing semantics (hoisting). the java designers would have been better served with `auto`, which would have been just as overloaded, but at least in a very similar
  81. bluemanner, in another strongly typed language
  82. blueas it stands, they made the more confusing choice
  83. blueand it's 100% on them and on no one else
  84. bluehistorically java already shared many confusing similarities with js; js' Date was modelled after java's. this is, of course, not java's fault, but as said, the designers do not exist in a vacuum
  85. jreicherWhy is it not a valid complaint to say Java is right and the other languages are wrong? You seem to place a high value on tradition.
  86. bluebecause 'right' means nothing when the choices you made serve to confuse rather than elucidate
  87. jreicherWhat if the Java designers believe they are elucidating, and it's worth the cost?
  88. jreicherI should perhaps add this is not theoretical for me. I'm working on a language design that does exactly this.
  89. bluethen they are gravely mistaken, in my eyes, in that instance. I do not know who they wanted to elucidate with such a poor choice of an historically heavily burdened term
  90. jreicherWell I can't take myself as an example. The term they chose has worked excellently for me. That's one of the reasons i use it every chance I get.
  91. jreicher^can't^can
  92. bluein my eyes, `var` is eternally burnt by js. I might not like it, but any other language I come across, it confuses me. scala has the same situation
  93. jreicherAnd I don't feel the same way, because my exposure to JS is much less than my exposure to other languages.
  94. bluein your language, you might not have much or any history with JS, which is ok, in that case that term would work for you
  95. bluebut for most people it wouldn't. js is extremely ubiquitous
  96. blues/in your language/in your case/
  97. jreicherAh, now we come to the truth of it. You believe JS has special status.
  98. blueI don't. What special status should it have?
  99. dreamrealare we still yapping about var?
  100. jreicherYou believe it's special in its ubiquity. If a relatively "unpopular" language loaded a term I don't think you would be bothered.
  101. bluethis works both ways: it was a mistake by JS to replicate Java Date. They are paying for this until today. Temporal is a dumpster fire whose only existence is on account of the fact Date is so terrible
  102. jreicherdreamreal: kind of. Not the concept of it (LVTI) but now just the name.
  103. dreamrealI mean, var was requested: it's relatively safe in that it can infer its type from the use; people wanted var; they got var.
  104. jreicherblue: I understand your point, but I don't believe JS has the status you think it does.
  105. bluedreamreal, that isn't the discussion at all. the discussion is whether language designers exist in a vacuum, and shouldn't look around when introducing new constructs, and using terms that are heavily encumbered
  106. dreamrealscala and kotlin, other popular JVM languages, used var (and val), so there you were
  107. jreicherWhere "heavily encumbered" means "in use by a language of exceptional popularity according to the person making the criticism"
  108. blueit's not according to me, it's a quasi-universal truth
  109. jreicherAccording to you. :)
  110. blue"JavaScript is the most widely used language among professional developers, utilized by approximately 68.9% of them in 2025"
  111. bluethis is factual, you can look it up yourself, in countless surveys and reports
  112. jreicherI understand your point. I still don't think the popularity has the special status you think it does.
  113. jreicherIt's a bit like saying "most happy songs are written in a major key, so you can't use a major key for an unhappy song"
  114. jreicherStatistically true, stylistically false.
  115. blueyou still haven't answered the question of why java couldn't have chosen a more appropriate identifier
  116. blueauto and others come to mind
  117. jreicherI don't know the answer. There might have been something compelling the choice of "var".
  118. blueheck, even scala's `val` would have been better. it's *way* less encumbered
  119. jreicherCheck the original JEP perhaps?
  120. blue" - While it was not the most popular choice in the survey, it was
  121. blueclearly the choice that the most people were OK with. Many hated
  122. bluevar/val; others hated var/let. Almost no one hated var-only."
  123. blueso basically, it was vibe-designed. great.
  124. bluehttps://openjdk.org/jeps/286 and https://mail.openjdk.org/pipermail/platform-jep-discuss/2016-December/000066.html (SYNTAX)
  125. nevethttps://openjdk.org/jeps/286 "JEP 286: Local-Variable Type Inference" || https://mail.openjdk.org/pipermail/platform-jep-discuss/2016-December/000066.html "Update on JEP-286 (Local Variable Type Inference)"
  126. bluenote that javascript isn't even mentioned as prior, whilst much more obscure languages (groovy???) are mentioned as reference
  127. bluethis is ridiculous
  128. jreicherAccording to you
  129. blueof course it's according to me
  130. bluethis is my opinion
  131. jreicherAnd I'm OK with you having that opinion. :)
  132. blueI understand that clearly
  133. bluebut people "hating" stuff is a good way to design a language
  134. blueisn't*
  135. bluethere are other considerations
  136. bluethe email mentioned `var` wasn't even the most popular choice
  137. jreicheryes, but it also describes the designers' reasoning based on statistical fact. So in their opinion they had a compelling reason for "var", and it's not obvious your reasoning is superior.
  138. blueI don't care for `var` or `auto`, in this case. the way they look doesn't play a significant role for me, and honestly, nor should it for the language's designers, I would imagine
  139. blueprior art, and how real people might perceive the feature, is way more important than some commitee's aesthetic prefs
  140. bluethis isn't somewhere in the aether; my boss said he rejected `var` partially on account of how javascripty it feels. this isn't evidence for a general pattern, but I can imagine other people out there in the big wide world feel the same
  141. bluemaybe they're a minority. maybe java users are perfectly content with var, and there's no confusion, and wide adoption; I wouldn't know really
  142. bluebut one thing you cannot argue: you cannot argue a "should" from an "is" (Ist->Soll). the fact this is already decided and out there, and people, you amongst them, use it (even happily), doesn't make it good
  143. blueI use many features of JS that I don't like...
  144. blueugh, this reminds, TS using private members for type comparison is an abomination...
  145. blue"Apache Groovy is a Java-syntax-compatible object-oriented programming language for the Java platform."
  146. blueTIL...
  147. bluepeople *use* that?
  148. bluedreamreal: ^
  149. bluedef myGroovyBean = new AGroovyBean()
  150. bluedef monthMap = [ 'January' : 31, 'February' : 28, 'March' : 31 ]
  151. bluethis is really nice. bit weird for map syntax, but nice
  152. dreamrealpeople use groovy, yes
  153. dreamrealwhy, I could not tell you
  154. blueI like that def keyword
  155. blueI don't like the missing semicolons
  156. bluebut it looks kinda nice
  157. dreamrealgroovy is a giant chunk of crap that managed to work
  158. blueLOL
  159. dreamrealthe most common usage is in gradle, and it's going away there day after day
  160. bluegradle?
  161. dreamrealgradle
  162. nevetgradle is a build tool for many languages; it uses a Groovy or Kotlin DSL, and provides a configurable as well as a conventional build model. It's very terse but can be absolutely maddening if you color outside the lines at all. URL: https://gradle.org Tags: build tool, groovy, kotlin, and jvm
  163. dreamrealgroovy
  164. dreamrealpffft, need a groovy factoid
  165. bluethat shows you how popular it is :P
  166. dreamrealIt's relatively limited in scope, most people learn enough groovy to use gradle and that's it, and even there kotlin is taking over
  167. dreamrealkotlin, incidentally, uses val and var
  168. bluelike scala?
  169. blueMein Gott dreamreal.
  170. blueanything that reminds me of that dumpster fire language is terrible
  171. dreamrealScala is a beautiful language
  172. dreamrealscala
  173. dreamrealit needs a factoid, too
  174. dreamrealbut I don't have one because of javabot :D
  175. blueI thought you hated scala like brimstone.
  176. blueActually, I *know* you do.
  177. blueI also know why, and it's not necessarily the language, though it should be :P
  178. dreamrealI refuse to use it.
  179. dreamrealThe language is great. Everything around it is awful.
  180. blueCommunity makes the language, I guess?
  181. dreamrealCommunity makes the ecosystem.
  182. blueThis is kind of the reason I like Java, btw. The people are so much better than other communities I know.
  183. dreamrealThe language is quite capable, quite usable, quite nice, really. The community ruins it.
  184. blueI *really* don't like Java as a language (this is no secret).
  185. blueBut I love the community.
  186. dreamrealTake every negative trope about argumentative Jews, amplify it by 700, add in toddler-level emotional tantrums and add knives. You'll have a gentle approximation.
  187. blueCompared to basically any community I know... first and foremost JS, the Java community is a dream. The people feel mature and no toddlers.
  188. dreamrealI can point out toddlers if you like :D
  189. blueThe JS community is full of ego-laden toddlers.
  190. dreamreallombok
  191. bluelol
  192. dreamrealgrrr, no lombok factoid either
  193. blueWhat on god's green earth is lombok?
  194. dreamrealjavabot's factoid database sucks compared to nevet's features, but it's far more developed
  195. blueyo ucould migrate the data..
  196. dreamrealhttps://projectlombok.org/
  197. nevetProject Lombok
  198. dreamrealI could, yes, but I don't want to, nevet is not intended to compete with javabot and it's less "#java-owned"
  199. blueanyway: I truly love the Java community in terms of people.
  200. blueI dislike the language very much indeed, but the people/culture make it worthwhile
  201. dreamrealA language is what it does
  202. dreamrealI find java usually pretty verbose myself, I prefer writing kotlin
  203. bluethe JS situation is reserved: I *love* the language, the community... MUCH less
  204. bluereversed*
  205. bluethe TS community is somewhat more mature
  206. * dreamreal still resents hasOwnProperty()
  207. blueyes, you shouldn't be using that
  208. dreamrealI don't know if JS has made that more palatable
  209. dreamrealit's been a while
  210. * blue points to Object.hasOwn
  211. dreamrealSo you can't override that?
  212. blueoverride what?
  213. dreamrealThat was always the problem with hasOwnProperty
  214. blueyou wouldn't be using it
  215. dreamrealYou ended up having to use something like Object.prototype.hasOwnProperty()
  216. blueyes. and the short sytnax today is Object.hasOwn(obj, prop)
  217. dreamrealAh, right, so you're calling it directly via Object
  218. bluethe reason people using the prototype directly doesn't have much to do with this particular method
  219. blueit's just js objects can overwrite anything
  220. blueobj = { hasOwnProperty() { console.log("nope"); return -1; } };
  221. blueand Object.hasOwn doesn't really fix it, either
  222. bluebecause you can do Object.hasOwn = () => {}
  223. dreamrealI thought that's why you use the prototype
  224. bluealso I believe Object.hasOwn deals with null and what not better
  225. systemfaultPeople use objects as dictionaries. Nobody use Object as a dictionary
  226. bluesorry, I mean null-prototype objects
  227. systemfaultAhh, most people don't even know they exist.
  228. blueconst obj = Object.create(null);
  229. bluethis is the 'clean' way to create a dictionary in JS, because it doesn't carry all the Object.prototype baggage
  230. dreamrealaight, off