Lisanna has quit [Remote host closed the connection]
<jcrben>
given all the griping online about GPG, it doesn't seem to be improving much. but they are breaking stuff with updates from things like 2.1 to 2.2, like https://github.com/StackExchange/blackbox
<jcrben>
still hunting around for some sort of value/policy statement from the gpg team on how the why behind their how, and not finding it. but I see they have weekly standups, including one tom https://dev.gnupg.org/E380 so maybe I could try to crash one
<jcrben>
joepie91: that google doc's first link is https://twitter.com/robertjhansen/status/996076985972600834 which is funny because my current gripe is breaking backwards compatibility without calling them out explicitly. or even better, semantic versioning, altho I know some people don't like semantic versioning
<joepie91>
jcrben: well, there are always some people who don't like X for any value of X :D
<joepie91>
my experience is that the vast majority of people who don't like semver don't fully understand its purpose and what it does (and doesn't!) guarantee; and I've spoken to a handful of people who are just unhappy about the lack of tooling for preventing semver mistakes, which is a valid complaint
<joepie91>
well, and the occasional 'sentimental versioning' oddball who *insists* that their version number must reflect their personal feelings on what constitutes a 'major update'
<joepie91>
for... usually unclear reasons
<jcrben>
in reading "Will gpg 1.x remain supported for the foreseeable future?", chuckled at "When I try to use gpg to manipulate secure apt repositories in the
<__monty__>
How about we just all standardize on the PVP, then that pun doesn't work ; )
<joepie91>
lol
<joepie91>
jcrben: also, one particularly persistent misconception about semver is that it's somehow meant to communicate every detail of every change in the version number, which... I don't really understand where people are getting this idea from, but I've seen it expressed more often than I'm comfortable with
<joepie91>
and it's often used as a way to discount semver as "doesn't work"
<joepie91>
it's really weird, I've never been able to track down where this particular idea comes from
<jcrben>
joepie91: docker doesn't use semantic versioning, but they are pretty good about calling out the breaking changes (with warnings logged out in code for 3 releases) https://docs.docker.com/engine/breaking_changes/
<joepie91>
jcrben: right, but the value of semver is in the ability to indicate breakage in a fail-safe manner in the version number, so that automated tooling knows what to do (or rather, what not to do) with it
<joepie91>
helping *humans* understand what has changed is pretty easy and flexible, just document it somewhere
<joepie91>
the point of semver is to help *machines* understand whether there were changes that need to be reviewed by a human :P
<joepie91>
(in a standardized way)
<jcrben>
yep, I'm a semantic versioning fan. I think some aversion is just a reflection of the fact that maintaining backwards compatibility is hard and slows you down
<jcrben>
and when you break it a lot, you end up with annoyingly large numbers
<joepie91>
right, but the 'annoyingly large numbers' is kind of tied into the whole sentimental versioning thhing
<joepie91>
like, it's one of those fairly arbitrary numbers that people assign a value to that it doesn't have
<samueldr>
though, semver would be best used for machines writing code
<simpson>
And yeah, version numbers either need to be for machines or for people, but not both.
<joepie91>
high version numbers really do not matter
<samueldr>
how often will a human accidentally break something in a non-major version
<joepie91>
(in and of themselves)
<samueldr>
but "not really an accident"
<joepie91>
samueldr: not that often, in practice
<jcrben>
in 2016 Rich Hickey did a talk (Spec-ulation https://www.youtube.com/watch?v=oyLBGkS5ICk) where he proposed never breaking backwards compatibility? not sure if that went anywhere
<samueldr>
like, changing something, which doesn't cause a bug, but changes a less-often used workflow
<samueldr>
as long as humans decide the versions number, they will be arbitrary, and a best-effort
<joepie91>
best-effort, yes; arbitrary, no
<samueldr>
I was not specifying semver in there, and semver is arbitrary as all version numbers are
<joepie91>
the rationale isn't that difficult; if the documented behaviour changes in a way that *could* break code written against the old documented behaviour, that is a breaking change and therefore a major bump
taktoa has quit [Ping timeout: 276 seconds]
* samueldr
verifies the definition of semver
<samueldr>
uh
* samueldr
verifies the definition of arbitrary
<samueldr>
ah, sorry, I was under the impression that arbitrary wasn't forcibly "based on random choice or personal whim, rather than any reason or system"
<joepie91>
right :P
<samueldr>
I was searching for a word that meant "based on a choice, personal or otherwise"
<samueldr>
"which can be logical or not, whatever"
<joepie91>
er, I know the word you mean
<joepie91>
tip of my tongue
<joepie91>
ah well, doesn't matter, I get your point
<samueldr>
though, I prefer the best effort of semver than the no effort of wildly varying version numbers
<joepie91>
but yeah, semver is definitely something that can be messed up; but in practice, if you look at eg. the Node ecosystem, such breakage is pretty rare
<samueldr>
and I prefer the constant incrementing versions (e.g. chrome) than arbitrary versions
<joepie91>
right, that
<samueldr>
(now using arbitrary the right way!)
<joepie91>
I'd like to see more tooling for *verifying* version bumps
<joepie91>
(you don't really want to derive them from the code, because breakage assessment should be based on the documented behaviour, not the implementation)
<samueldr>
documented behaviour including API I assume
<joepie91>
yeah
<samueldr>
e.g. C library public functions
<joepie91>
nevertheless it's helpful to have something that says "hey, you made this a patch bump but I'm seeing an API change, are you sure that's meant to be patch?"
<samueldr>
yeah, I could easily change the meaning of some of my API which completely change an existing (un?)defined behaviour
<joepie91>
to distinguish between "yes the API changed but that was to bring the API in line with the docs", and "the API changed because I forgot I changed it and it should really be a major"
<jcrben>
change versions or break backwards compatibility, whatever
<joepie91>
jcrben: that's based on the presumption that automated tests verify that something works correctly, which is false :)
<joepie91>
it can reduce unexpected issues, sure
<joepie91>
but it will not eliminate them
<jcrben>
joepie91: haha - I do TDD pretty much exclusively at work these days, so I know what you mean
<joepie91>
most important takeaway with automated testing is that it verifies consistency, not correctness
<samueldr>
your app is 100% tested and does nothing right \o/ success!
<joepie91>
and consistency is still useful, but you shouldn't expect to have defined the full set of correct and incorrect behaviour in your tests
<joepie91>
yet that's an assumption that a lot of people make
<joepie91>
"tests pass, so it's fine"
<jcrben>
joepie91: my tests run at a pretty high-level (similar to the user), with unit tests for pure algorithms - it's pretty reliable
<joepie91>
nevertheless it's still consistency testing
<joepie91>
like, you're not testing that "the code does what I intend", rather you're testing "the code behaves how it behaved before for X set of testcases"
<jcrben>
what do you mean? we do have a gap when it comes to the styling part of the UI, but we can ensure that all the buttons work and stuff shows up fairly reliably
<joepie91>
which may or may not be a complete set of testcases, and almost certainly isn't
<jcrben>
when you break it down, a the featureset of many apps isn't actually that large or complex
<joepie91>
so automated tests will give you the guarantee that *the specific cases you're testing* are still behaving like you'd expect, but it will absolutely not give you the guarantee that there aren't still bugs
<samueldr>
joepie91 talks about testing semver I think
<jcrben>
I think you might be alluding to the fact that many tests are very loaded with implementation details
<joepie91>
no, automated testing in general
<joepie91>
no, I'm talking about the nature of automated testing
<joepie91>
at least, current-generation widely used tools for it
<jcrben>
there's always combinations which get difficult to test
<joepie91>
the problem are the combinations that you didn't realize existed :)
<jcrben>
I work at http://brightidea.com/ which is an enterprise SaaS and we have cross-cutting concerns which get difficult to test, especially due to all sorts of permissions
<jcrben>
not difficult in that writing them is hard, but time-consuming to enumerate and hit them all...
<jcrben>
I've watched a bunch of Bernhardt's talks, but that one has a summary which bothers me a bit too much to watch it closely...
<jcrben>
not sure how someone could possibly think that unit tests become unnecessary with type systems, or vice versa (unit tests make types unnecessary)
<joepie91>
both of these are common beliefs :P but that's not the reason I linked it
<jcrben>
I'd like to see the poll - altho I believe you, I think that's hopefully fading. what's your biggest takeaway from that talk?
<jcrben>
a user doesn't care about types at all, so in that sense if you theoretically had 100% coverage, you don't really need static types. they
<jcrben>
types are very ergonomic tho...
<joepie91>
jcrben: my biggest takeaway - although not the reason I linked the talk - would be that the software development community is rife with tribalism and ideology-based decisionmaking, and that automated testing vs. typing is just one example of that... although that's also a takeaway that's informed by several years of looking into these topics myself :)
<joepie91>
jcrben: btw, to provide a bit more context of where I'm coming from with my perspective... there's this saying about how if you want to get rich during a goldrush, you need to be the guy selling the shovels... it's kind of like that, except I want to *fix* the shovels for programming :P
<joepie91>
I'm quite unhappy with the current state of software development tooling, the tribalism, misconceptions and ideologies, etc.
<joepie91>
my interest in NixOS is for a very similar reason
<joepie91>
but basically, I think that tooling could be *so much* better than it currently is, without getting lost in pointless turf wars about typing vs. tests, testing methodologies, etc.
<MichaelRaskin>
First of all we need better soldering irons. For extracting the actual requirements from the users.
<jcrben>
ah yeah, just like every community of humans - look at the packaging world :) - I'm nearly finished with Ray Dalio's Principles audiobook which is kind of focused on that and I recall he has a spot where he talks about the law of trivial differences https://en.wikipedia.org/wiki/Sayre%27s_law
<joepie91>
jcrben: I'm... not sure why that wiki page does not reference 'bikeshedding' :)
<jcrben>
the state of software tooling provides more jobs and an opportunity to outcompete those stuck in bad practices, altho I'm afraid the big winners have already figured it out fairly well... been thinking about how get more into business and out of the software engineering ratrace, myself
<jcrben>
MichaelRaskin: I would submit to a bit of torture for GnuPGP if they would do a user study (as I read https://arxiv.org/abs/1510.08555) - I wonder if they do those...
<MichaelRaskin>
Well, they are more of an infrastructure project…
<joepie91>
shrug, "more jobs" is not really a relevant factor to me, I just want better tooling :P
<jcrben>
joepie91: if I was financially independent, I could do a lot more open-source stuff
<jcrben>
and right now, my financial future is largely driven by the supply and demand for software developers
<joepie91>
jcrben: my income currently largely comes from open-source contract work
<joepie91>
(freelance)
<joepie91>
I'm rather swamped with work at the moment, but it means that I can usually free up plenty of time to fix issues outside of paid work
<andi->
what kind of jobs are those? Integrating OSS into some custom solution? Adding features to the project because your contractor needs them?
<joepie91>
andi-: anything from maintenance on / changes to open-source software, to building new software, to building stand-alone libraries that can be used elsewhere, to working on proprietary software that is then released as open-source :P
<joepie91>
certainly not an easy market, but very possible to earn a living in it, with enough persistence
<joepie91>
key insight turned out to be that most people just genuinely _do not care_ about the license
<joepie91>
they just want to insert money, receive software (usually for internal use)
<joepie91>
and if that software happens to be available to other people, eh, sure
<joepie91>
so I'm not so much selling 'open-source software development', as I'm selling 'software development where open-source is one of the contract terms'
<joepie91>
andi-: also, with open-source contract work I really do mean that the contract work itself is open-source, not just "here's some money to integrate $ossThing with $proprietaryThing", because that'd be work on proprietary software :P
<MichaelRaskin>
Well, blurry lines are blurry. If you write an open-source convertor from the format of something old and proprietary to a sane format, this is open-source work, but the customer probably thinks about «finally integrating this locked-in pile of junk with something modern»
<joepie91>
MichaelRaskin: they're less blurry than you might expect; basically, it's not my concern how a customer intends to *use* the resulting software, so if they want to use it in a proprietary setup then that's not a problem; but I won't be doing the integration work
<joepie91>
I generally design my things to have generic interfaces anyway
<joepie91>
in practice, the integratable things I build are usually used in either OSS projects or proprietary greenfield projects, so the integration happens on the side of the consuming project
<jD91mZM2>
joepie91: That semver idea of yours would be useful for me. I recently almost rewrote a program of mine and then out of habit bumped the patch version lol
<jD91mZM2>
Sure, it was still compatible, so no biggie. Phew.
<joepie91>
heh
<joepie91>
jD91mZM2: I've been working on a generic code analysis toolkit for JS, and it should be possible to build this kind of tool with it once it's done
<joepie91>
as well as a bunch of other missing tools
<joepie91>
general error-detection tooling, better autocompletion, that sort of thing
<jD91mZM2>
Sounds good! Just one thing...
<joepie91>
though autocompletion is one of the last things I'll be worrying about because I'm not optimizing for performance
<jD91mZM2>
... JS? D:
<joepie91>
yes, JS :P
<jD91mZM2>
oh noes
<joepie91>
why?
<simpson>
Why not?
<jD91mZM2>
Don't mean to get too negative, but I'm not a fan of JS' type system and stuff. I also feel like that language should have stayed in the browser
<joepie91>
jD91mZM2: I have a number of complaints about JS' type system, but they're not the ones that people love to complain about
<joepie91>
and JS has a number of very interesting tradeoffs that make it very suitable for a lot of usecases
<joepie91>
more so than many other popular languages
<jD91mZM2>
Examples?
<joepie91>
half the reason I'm building a code analysis toolkit for JS is to deal with the things that really *are* problems :)
<adisbladis[m]>
jD91mZM2: Not many people actually like to work in js.. We just do it because we have to.
<jD91mZM2>
Array(16).join("wat" - 1) + " Batman!"
<joepie91>
jD91mZM2: so this is one that most people don't even realize, because they bail out on JS before they use it seriously enough to encounter it: abstractions in JS are *incredibly* cheap to build, to the point that it can be a significant boon to both reliability and maintainability/readability of your code; part of this is down to its object model (which relies on not being statically typed, for example)
<joepie91>
jD91mZM2: the problem with the tradeoffs that JS makes is that the downsides are often ones that are immediately visible and easy to describe, but the upsides are ones you only encounter down the line and that are difficult to explain without a lot of context
<simpson>
joepie91: Could be cheaper. The E family boasts object literals with bound methods and no `this` insanity, so that e.g. in Monte you *can* just create an object. No classes, no prototypes.
<joepie91>
of course this doesn't include such braindead design decisions as implicit type conversions or not having integers
<joepie91>
those are just mistakes :)
<simpson>
joepie91: What's surprising is that people are willing to put up with such mistakes in their languages. I suspect that people only do so because they don't understand how to build their own languages and escape the pit.
<joepie91>
simpson: hm? `this` has nothing to do with classes or prototypes, so I'm not really following your point
Lisanna has joined #nixos-chat
<jD91mZM2>
adisbladis[m]: I wish that was just it, but then I heard about Node and now I have given up the last bit of hope for humanity I ever had
<simpson>
joepie91: Right, `this` is an *additional* bit of sadness, alongside prototypes, which are also sad.
<jD91mZM2>
JS multiple times bit me - well, technically didn't bite me - in the butt for using the wrong number of arguments. So much time wasted.
<joepie91>
simpson: re: people being willing to put up with it, this is the irritating tribalism I was describing earlier :)
<simpson>
jD91mZM2: Node's not especially bad. They draw from Python's Twisted and Ruby's EventMachine. I suspect that the worst part of Node is JS itself.
<adisbladis[m]>
jD91mZM2: My biggest problem with js is how `undefined` is treated
<joepie91>
people are too busy disliking other people's broken languages to fix their own broken languages, basically
<adisbladis[m]>
Nodejs is actually a quite amazing runtime
<jD91mZM2>
simpson: Well it's basically one giant copy paste of google's JS code because people somehow loved a language so much they couldn't leave it in the browser
<simpson>
joepie91: Uh, to the extent that I belong to any tribes, I belong to the tribe that has secretly infiltrated the ECMAScript steering committee and is deliberately introducing capability-aware concepts into the language. I'm on your side. Or at least "your side."
<joepie91>
simpson: wasn't an accusation towards you, rather a reference to the phenomenon you described of people putting up with broken languages :)
<adisbladis[m]>
And the node packaging system is far less broken than a lot of others
<simpson>
jD91mZM2: And? People also love Lua, PHP, C++, C, and many other terrible languages. People can love just about anything.
<gchristensen>
aren't we all a little broken?
<jD91mZM2>
simpson: Yes but that amount of dedication is just sad
<gchristensen>
jD91mZM2: hey now
<adisbladis[m]>
gchristensen: Just a little?
<simpson>
gchristensen: There's a difference between loving a three-legged puppy and loving PHP.
<joepie91>
jD91mZM2: honestly I'm not really interested in getting stuck on the historical path that a language took, at least not beyond the extent to which it influenced its current design; far more important is what languages can offer *now*, and to what degree they or their ecosystem can be moved forward
<joepie91>
in that sense, JS definitely has a future
<joepie91>
hence why I'm trying to do my part in building tooling to cope with the parts of the language that can't be fixed
<jD91mZM2>
gchristensen: I mean they somehow love a language without a proper type system, without proper errors for using the wrong function arguments, where `[] + [] == Object` SO MUCH that they copy-paste Google's code to a standalone program so they can use that language more
<joepie91>
jD91mZM2: that is a gross oversimplification.
<gchristensen>
sure
<gchristensen>
jD91mZM2: and who cares? why do you care? it isn't your life to live
<simpson>
jD91mZM2: Lemme get out my psych couch and you can tell me about your preoccupation with "Google's code". What is it about Google that bothers you so much?
<jD91mZM2>
That this is an oversimplification is what makes it so sad. They take so much of their time porting a broken language to desktops so more people can write stuff in it
<MichaelRaskin>
gchristensen: well, network effects mean that overuse of JavaScript does hurt other people
<jD91mZM2>
Then in came Electron and basically invented a way to make `chromium --app <url>` even less efficient
gchristensen has left #nixos-chat ["WeeChat 2.0"]
<joepie91>
jD91mZM2: I can't find a more polite way to say this than this: you are part of the problem
<joepie91>
this kind of dismissive "just complaining, not understanding" attitude (and the associated tribalism) is why languages stay broken
<joepie91>
you are not making any effort to understand _why_ Node.js is really a thing, why people continue to use it voluntarily, why Electron is a thing
<jD91mZM2>
simpson: I don't find anything wrong with Google?
<joepie91>
what problem people believe it solves, whether that might point at problems elsewhere
<simpson>
jD91mZM2: Then why are you so angry?
<joepie91>
instead, you're throwing out rhetoric
<joepie91>
this fixes neither JS nor your favourite ecosystem
<jD91mZM2>
simpson: I'm not angry?
<simpson>
jD91mZM2: Okay. So why is it "sad" when people use JS?
<jD91mZM2>
I just find it a little sad that people bothered to write the whole NodeJS project
<simpson>
I used to think that the average JS or PHP user must wallow in sadness, but then I remembered how *I* felt when I learned those languages as a teenager, and I realized that it's very much an ignorance-is-bliss situation.
<simpson>
Maybe "sad" is your way of indicating that you feel judgemental towards them?
<simpson>
Node.js started as a personal project. The projects that inspired it, Twisted and EventMachine, also started out as personal projects.
<jD91mZM2>
Maybe ¯\_(ツ)_/¯
<jD91mZM2>
joepie91: What about both complaining and understanding?
<jD91mZM2>
Or, well, that depends on what there is to understand. Why it's a pain to work with?
<simpson>
jD91mZM2: What work have you done in proglang design or theory, BTW? I'm working on a language that happens to be cousins to JS, and it's on our roadmap to become available in the browser at some point.
<joepie91>
jD91mZM2: totally possible (and it's what I frequently do!), but I'm seeing no understanding in your remarks, just assumptions and complaints
<joepie91>
like, for example, this remark: [19:56] <jD91mZM2> Then in came Electron and basically invented a way to make `chromium --app <url>` even less efficient
<joepie91>
I doubt that you honestly believe that people are using Electron because they went "hey, I want a less efficient way to use chromium!"
<joepie91>
as that's obviously not a rational decision
<jD91mZM2>
joepie91: No, they want to be able to use NodeJS and write native apps easier
<joepie91>
so... why did a presumably rational human being decide to use Electron?
<joepie91>
okay, so that's a start, but let's look at 'easier'
<joepie91>
why is it easier?
<jD91mZM2>
Well they don't have to comply with the system's style
<joepie91>
or rather, why is it perceived to be easier?
<joepie91>
you don't have to do that with Qt either
<simpson>
Every Electron adopter I've talked to has either emitted a pile of pro-JS memes or been convinced to adopt Electron because it is socially popular and trendy right now.
<jD91mZM2>
^ keyword "perceived" is a good touch
<joepie91>
it leaves you quite free to design your own insane styles :)
<jD91mZM2>
You don't have to, no, but it's easier to break with CSS because the default styles aren't even the system's styles
<adisbladis[m]>
And didn't libuv come out of nodejs? That's some pretty cool stuff :)
<joepie91>
simpson: my experiences are definitely different; the #1 reason I've heard is "because non-Windows UI toolkits are a pain to work with"
<jD91mZM2>
To write an Electron application you can just copy-paste your existing website and "compile" it
<joepie91>
which, from my own experience, I can only agree with
<joepie91>
jD91mZM2: if you're packaging a website in Electron, you're definitely doing something wrong
<simpson>
adisbladis[m]: To a point, yeah. libuv isn't perfect, but it's become very decoupled from the rest of Node, which is nice for folks who reuse it. We use it in the Monte reference interpreter.
<jD91mZM2>
simpson: Sorry for replying late to your question about what I've done with programming language design/theory. None, heh
<joepie91>
jD91mZM2: anyhow, see above; the #1 reason I've heard for using Electron (and I'm discounting the cases of following-the-hype, because those are not a useful indication for anything) is that native UI toolkits are just *too difficult to work with*
<joepie91>
this is the deeper problem it points at
<simpson>
joepie91: I have heard stories like "we had an Ember champion, so we chose Ember/Electron, but then he left," or "our competitors were poking at Electron, so we ended up trying Angular on Electron" or "we wanted to deploy a copy of our website as a desktop app, so we designed our site to work in browsers and Electron"
<joepie91>
and it's not like it's inherently difficult to conform to a system's style
<joepie91>
it's just unnecessarily difficult to work with them.
<joepie91>
often lacking documentation, outdated bindings, version issues across platforms, oddities in specific themes
<joepie91>
simpson: right, those are the hype cases, and those are the cases where I tell people "don't do that"
<simpson>
joepie91: Hype cases? These are just conversations I've had with folks while looking for a job in a big metro area in the USA.
<joepie91>
simpson: I'm talking about the reason why technologies were initially chosen.
<joepie91>
"they be doing it too"
<jD91mZM2>
joepie91: Sure, you don't have a default GUI and have to create a window yourself, but that's because it's general purpose. After you have a window it's just a matter of adding some buttons and stuff.
<joepie91>
jD91mZM2: except... it's not. having attempted on several occasions to work with native UI toolkits from various languages, my experience is that it's roadblock after roadblock.
<joepie91>
and generally poorly designed layout models.
<jD91mZM2>
joepie91: Thing is people really want to break the system's style. Most Electron apps look nothing like native apps or even close to the default theme. People really like their own designs.
<simpson>
joepie91: Something can be trendy despite next to nobody doing it. There's lots of sad examples in USA history, like the Salem witch trials, but also funny examples, like D&D mass panic during the 1980s.
<jD91mZM2>
joepie91: What toolkit were you trying?
<joepie91>
jD91mZM2: Qt, GTK (2 and 3), WxWidgets, at various points in time.
<joepie91>
in Python, JS and Rust.
<joepie91>
don't recall the exact permutations.
<joepie91>
every single time I've run into roadblocks of some sort.
<simpson>
joepie91: I get your point, but I think that it's a lot of post-hoc combined with your personal feelings on Electron. I'll gladly concede that GTK+ and Qt are not fun to target, but I'll also note that people have been using SDL for *decades* to port games.
<joepie91>
and this is not just my experience.
<joepie91>
simpson: porting games is easy because you barely have to actually touch a UI toolkit, if at all.
<joepie91>
that's not really relevant to the problem here.
<jD91mZM2>
joepie91: I mean, it's always going to be a little more difficult to write a GUI in a general-purpose language rather than a markup language. This is what GUI designers are for.
<joepie91>
and I'm basing this in both my own experience and years of conversations with others.
<simpson>
joepie91: Perhaps UI toolkits were a mistake
<joepie91>
jD91mZM2: right, like Glade, which can't seem to keep running for more than 30 minutes without segfaulting.
<simpson>
~
<joepie91>
and has rather unintuitive UI itself.
<joepie91>
which is *also* a complaint that I've heard from many people.
<joepie91>
the thing is, every time these kind of issues are brought up, the same thing happens: people start trying to dismiss them.
<joepie91>
it must be your fault, it must have been bad luck, whatever.
<joepie91>
this means they don't get fixed.
<joepie91>
the average user, after being told that it's their fault three times in a row, is going to say "fuck this shit", throw the native UI toolkit into the bin, and grab Electron where things Just Work because HTML/CSS/JS are generally well-documented and it's easy to get help for them.
<joepie91>
and hey, they tinkered with it a few years ago for a website so they already kind of understand the lay of the land.
<samueldr>
I want to bring up the fact that using most toolkits outside of their native C/C++ language is generally a mess, it's almost always a poor layer of almost-no-abstraction over the native code
<jD91mZM2>
joepie91: And what they should have done is improve the toolkit or create their own
<joepie91>
and that is how you get people building 'desktop applications' with what amounts to a Chromium frame with system bindings.
<samueldr>
keyword: almost
<simpson>
Can't fix people. In both ECMAScript and in Python, I have talked to people in charge (steering committee, core dev) about their recent template-literal features. The features come straight from Lisp, from E, and are known to be extensible by users. *But* in both languages, in both cases, those user-extensible bits were left out. Same reason, too; because *people on the committee didn't understand why
<joepie91>
jD91mZM2: like they do in Electron, you mean?
<simpson>
anybody would ever want that feature*.
<joepie91>
jD91mZM2: and "improve the toolkit" is a completely unreasonable expectation when the problem is that *they don't understand the toolkit in the first place*
<jD91mZM2>
joepie91: Electron would be fine if it would be properly compiled and efficient
<joepie91>
jD91mZM2: 'properly compiled'?
<jD91mZM2>
Instead of making every native app contain a copy of chromium
<jD91mZM2>
It's like Jar2Exe all over again
<joepie91>
I don't see what any of this has to do with compilation, really.
<joepie91>
also, aside from the ballooning-memory-allocations issue, the vast majority of problems with Electron-based applications does not lie in them using Electron at all
<jD91mZM2>
The HTML isn't compiled to native code, it's just packaged within a native binary along with a huge runtime
<joepie91>
performance problems*
<joepie91>
jD91mZM2: why is this a problem, HTML not being 'compiled to native code'?
<simpson>
jD91mZM2: Serious question: How big *should* a universal platform like Electron, or like JVM, or like Go, be?
<simpson>
And why?
<__monty__>
joepie91: Are you sure? I haven't come across a performant electron app. It sure looks like electron's the problem.
<jD91mZM2>
simpson: I'm not sure what you mean
<joepie91>
__monty__: yes, I'm sure.
<joepie91>
__monty__: to give a practical example, I've been working on fixing an application called LaserWeb4, which is lasercutter control software that runs in Electron. it has notable performance issues
<simpson>
jD91mZM2: I know it's kind of a mind-bending question, but go with it. How many lines of code *should* it take to implement a platform upon which you can reliably use a high-level language without worrying about choice of OS?
<joepie91>
__monty__: one of the issues was that importing or rendering an SVG file with curves would take seconds to minutes; the fix turned out to be to change *a single number* because the developers had selected the wrong precision for linearization; suddenly it was fast.
<__monty__>
joepie91: Then what is it about electron that attracts developers who don't (seem to) know what they're doing?
<joepie91>
__monty__: similarly, I have been tracking input latency issues, and I still need to implement a fix, but based on my profiling the problem lies entirely in it re-rendering the entire view unnecessarily all the time.
<joepie91>
which is also an application concern.
<jD91mZM2>
joepie91: It makes me a little annoyed to see a native binary basically just being an embedded runtime and the source code, yeah. It's like they're hiding from their inability to make a real compiler.
<simpson>
jD91mZM2: What does that mean? What tasks must a *real* compiler do?
<jD91mZM2>
simpson: I don't really think there should be a limit on that
<joepie91>
__monty__: combination of factors most likely, including the fact that most companies using electron are startups where everybody builds everything on the latest macbook and performance isn't really a priority in the first place because gotta move fast; as well as general accessibility, which means that the bar for building something in Electron is very low... which also means that it's easy to get assigned to working on an Electron app even
<joepie91>
though you normally do wordpress plugins and you have no idea what you're doing but they needed the manpower.
<jD91mZM2>
simpson: I think a real compiler should actually compile stuff to assembly, or at least bytecode
<simpson>
jD91mZM2: Okay. Electron does that; there's a JIT in there.
<jD91mZM2>
simpson: Not juust embed the entire chromium and do all the things at runtime
<joepie91>
jD91mZM2: every modern JS runtime has a JIT compiler.
<simpson>
jD91mZM2: JITs are compilers too.
<jD91mZM2>
And that's the problem. JIT. You're packaging a JIT compiler in a native binary.
<simpson>
What's the problem with JITs?
<jD91mZM2>
The problem is embedding them
<jD91mZM2>
`./electron script.ec` wouldn't make me as annoyed
<simpson>
Oh, okay.
<simpson>
Please wait for about 2yrs for the Monte language to be ready for you. /join #monte for status updates.
<__monty__>
Ready for production use in 2 years? o.o
<joepie91>
__monty__: an additional, more indirect problem is that technologies that have at one point been hyped, tend to have accumulated mountains of *horrible* third-party documentation, of the "build an X with Y and Z" type, that totally gloss over anything that doesn't involve making things happen on the screen, such as performance, security, and so on.
<simpson>
__monty__: Well, yeah. Nobody's paying us, so launch readiness is a very slow process.
<joepie91>
Electron is unfortunately one of those technologies.
<joepie91>
jD91mZM2: I mean, you can build v8 snapshots and run those in Electron?
<joepie91>
theoretically you could even totally remove the JIT then
<joepie91>
downside is that everything gets slower, sometimes significantly
<joepie91>
because now you don't get runtime optimizations anymore
<__monty__>
simpson: You call 2 years slow? Haskell has taken decades.
<samueldr>
turns out that sometimes the issues aren't entirely technical, which makes things hard *sigh*
<jD91mZM2>
joepie91: If compiling it makes it slower I think it's doing it wrong
<joepie91>
but if that's the tradeoff you're willing to make for the ability to not ship a JIT, then you absolutely can do it with relatively minor changes
<joepie91>
jD91mZM2: no? this is completely to be expected
<joepie91>
and JIT compilation is "compiling" too
<joepie91>
it just does so at runtime, and generally recompiles during the running of the application as behavioural patterns are observed
<joepie91>
to compile more efficient versions of the code for particular code paths
<simpson>
__monty__: Sorry, I didn't know that it was a competition~
<joepie91>
this kind of 'runtime intelligence' does not exist if you're compiling ahead-of-time
<simpson>
jD91mZM2: To put it politely, *why* should a compiler be expected to speed up most programs fed to it?
<joepie91>
so it's quite logical that if you move from just-in-time compilation to ahead-of-time compilation, your program gets slower
<__monty__>
jD91mZM2: AOT compilers can result in slower code than JITs. That doesn't mean either one is "doing it wrong."
<jD91mZM2>
Interesting
<samueldr>
is it okay if I don't care how it is fast, just that it's fast?
<jD91mZM2>
What could be an example of such an optimization?
<samueldr>
(and demonstrably fast/faster)
<__monty__>
jD91mZM2: Monomorphization of a polymorphic function.
<simpson>
Monomorphization is *the* optimization that JITs have available to them. In particular, polyvariant call sites can be annotated in the typical JIT toolkit, *promoting* them at runtime to monomorphic call sites via specialization. This is what's known in literature as "the trick".
jtojnar has quit [Remote host closed the connection]
<jD91mZM2>
Am I understanding it correctly if I say it copy-pastes generic functions for each type?
<jD91mZM2>
Because a few AOT compilers do that too. Would be pretty darn difficult, if not impossible, to do in JS though
<__monty__>
JS JITs definitely do this.
<__monty__>
AOTs can't the same way JITs can. It can make for a pretty big difference.
<simpson>
jD91mZM2: AOT compilers can only do it for types which they know about at compile-time. The entire point is that, when a program is running, there's *more* type information available.
<jD91mZM2>
So Rust doesn't have that problem for example?
<__monty__>
Why wouldn't it?
<simpson>
PyPy, the best Python JIT, generates type information for *user-defined classes*, including attribute information.
<jD91mZM2>
__monty__: Because it knows all types and stuff at compile time
<__monty__>
It's not a problem, it's a trade-off.
<jD91mZM2>
And generics is done by copy-pasting generic functions
<__monty__>
If everything's monomorphized then that wouldn't be an advantage for the JIT>
<__monty__>
However, trade-off is code bloat.
<jD91mZM2>
Large binary, yeah
<simpson>
jD91mZM2: Anyway, there's an entire other class of optimizations that apply if the program can be *partiall evaluated*; that is, if large portions of the input are static.
<jD91mZM2>
But Electron doesn't exactly have a smaller binary by embedding the entire JIT compiler heh
<__monty__>
Also, sometimes you don't need to specialize all the way, JITs can un-specialize a code path to the ideal granularity. That's something that AOTs cannot.
<simpson>
*This* is what you want, I think, or at least the output of a partial evaluator, where everything's gooshed together into a big amalgamated junkball, is what you want.
<joepie91>
"big amalgamated junkball" - thanks, that's going to be the name for my code analysis toolkit
<joepie91>
:D
<joepie91>
(nah, kidding)
<jD91mZM2>
lol
<jD91mZM2>
Anyway, I didn't mean to make this such a big argument, I really just don't like the way Electron apps look like native binaries but aren't. It'd be fine to invoke it as `./electron <file>` or stuff, but this just feels wrong (also takes up a lot more space). I also dislike how it doesn't follow the general system design rules but eh that's not a huge deal.
<joepie91>
jD91mZM2: that is generally exactly how it's invoked
<joepie91>
and it's perfectly possible to distribute just the application code without the runtime
<joepie91>
the application code is a separate directory or file
<__monty__>
Why doesn't anyone seem to be doing this?
<jD91mZM2>
woah
<joepie91>
distributing just the application code? because they have an interest in having it work out of the box for as many people as possible :)
<__monty__>
Is it avoiding bug reports from users with a different electron version than they're developing with?
<joepie91>
but generally if you download it from the vendor, it's either a zip with a generic electron binary + application assets, or those things packed together with a packer or in an appimage or whatever
<jD91mZM2>
TIL I've been mad at Electron when I really should've been mad at Discord or Mattermost
<joepie91>
and it should be relatively trivial to extract the application bundle from that
<joepie91>
__monty__: nah, it's more that if you're Discord, you're not going to say "here's the application, oh and btw you need to manually install a dependency too"
<simpson>
jD91mZM2: nixpkgs should have a way to do a common Electron with whichever application you want to use.
<simpson>
But don't be surprised if Discord doesn't care~
<joepie91>
commercial/proprietary vendors virtually always package the kitchensink just to avoid it not working on some system
<joepie91>
because they want to maximize onboarding/conversions
<__monty__>
joepie91: But that's how java apps work, and python, and C#, and...
<joepie91>
and most users don't care about a few extra MB
<joepie91>
__monty__: difference being that everybody has Java; C# and Python for commercial end-user applications are almost always distributed as either a single binary or an installer that includes any dependencies
<joepie91>
this is why stuff like py2exe exists :P
<joepie91>
C# applications and such usually just have a .NET framework installer bundled into their own installer
<joepie91>
Linux-targeting games usually come with Mono bundled
<joepie91>
and so on
<joepie91>
bundling the kitchensink is super common in proprietary software because it's just the obvious economic decision to make
<joepie91>
jD91mZM2: simpson: re using a shared electron runtime; find a way to get at the application bundle (ASAR) of the application you want to run, and then just install electron and do `electron /path/to/foo.asar` (or package it as such with Electron as a dep)
<joepie91>
unless it's written for a wildly different version of Electron it'll probably work
<joepie91>
honestly, if you can do it in a browser, there shouldn't be an Electron app for it
<joepie91>
but I have the same criticism about most mobile apps :)
<jD91mZM2>
It's safer too, all code is sandboxed :D
<joepie91>
I believe you can enable the sandbox in Electron too, under some circumstances
<jD91mZM2>
I personally do not think everything should be browser apps. But I think making an Electron app which is basically just a web version of the site is just wrong.
jD91mZM2 has quit [Quit: WeeChat 2.0]
<jcrben>
meanwhile, I'm trying to move entirely to electron (reuse my web dev skills, huge ecosystem, great tooling for everything including performance) and just got out of messing around in the devtools of hyper
<jcrben>
and not only performance... without the DOM I'm not even sure how to do TDD the way I like, unless I jump on the openQA train and start using opencv - which I looked into enough to decide against
<jcrben>
also hoping to help out with KDE a bit at the foundational level some point to provide a stable platform. but ideally the only desktop apps I have are an editor, a terminal and a browser - I'm also big fan of selfhosted apps (for irc, https://github.com/thelounge/thelounge) and kinda addicted to vimium for clicking links and stuff