<das_j>
ajs124: We could switch to the ugly kernel coding style (own lines for {}), would also result in a lot of lines...
<etu>
das_j: Why not gnu coding style?
<ajs124>
Or, hear me out, how about we do not do that? Crazy idea, I know.
<etu>
:D
<Taneb>
jD91mZM2: nice!
<das_j>
B O R I N G
<eyJhb>
joepie91: https://twitter.com/mathew/status/1147160163490631680 summarises why I am not a fan of frontend. Fell out of touch with it, and when I cam back there was 10.000 tools that needs to work together and bundle everything up...
ajirx has quit [Quit: Leaving]
<__monty__>
eyJhb: My issue with it is more the reactions like "Surprised X was around a year before Y." and "Here's my list." No one seems to perceive it as criticism. They all think "Wow that's a lot of things and they're coming out faster and faster *.* : D" rather than "Why is frontend development one of the rare places where the hypecycle's measured in months rather than decades?"
<eyJhb>
Quite so. I just haven't gotten the hang of it.. I remember when you just linked to jQuery, and that was it.. Wrote some css, linked to that, done... :/ - I really don't fancy when I will soon have to make something.. Pretty frontend wise... Hoping I can outsource it to someone at Uni, if he has the time
<eyJhb>
With my fancy 0,- DKK budget
<manveru>
i pretty much try to only use mint or elm for my own stuff... the dependency insanity going on at work is just silly
<manveru>
and you can still write just some plain html with a tiny bit of css sprinkled on top... never goes out of style ;)
<manveru>
but then, i also enjoy writing GUIs in TK, i might just be getting old
<joepie91>
eyJhb: you can do the exact same thing today
<joepie91>
like, it's not like you need to use newer tools
<joepie91>
if you are okay with the tradeoffs of not using any modern tooling - and those tradeoffs are severe - then that is absolutely an option that is available to you today
<joepie91>
so I never really find this criticism to be particularly strong, because it implies that that option no longer exists, which is false
<joepie91>
there *are* valid criticisms regarding UI stuff (because let's call it what it is), but it's not "there are so many tools that need to be made to work together"
<joepie91>
because that just isn't true
<joepie91>
if you choose to use those tools, then you need to make them work together with the other tools you also choose to use, but at that point the discussion becomes a lot more nuanced and you need to look at how different tools have different designs (some of which more interoperable than others), and at how the real problem that most people run into is a lack of discovery and too much (undeserved) hype around tools
<joepie91>
eh, discoverability*
<joepie91>
and that is ultimately a culture problem, and not a technical problem
<joepie91>
(also, while I'm pretty happy with JS as a language, and the modularity and single-responsibility-ness of its ecosystem, and you'll certainly see high dependency counts in my projects... you'll also find that I rarely use the libraries you see scrolling by in all the Medium posts and whatnot, because the vocal hype-y bandwagon just isn't representative of your options in the broader ecosystem)
<joepie91>
(and the hyped things are rarely actually good)
endformationage has joined #nixos-chat
<ldlework>
joepie91: there's a meme somewhere about how people talk about the availability of libraries in an ecosystem when considering using a language, and then having the opposite take when they look at javascript
<joepie91>
ldlework: can't say I've seen that contradiction particularly strongly - what I *have* noticed is that the people who loudly proclaim the virtues of the 'unix philosophy' are quite often the same people to loudly complain about how dependencies work in JS (which is literally that philosophy)
<joepie91>
like, "do one thing and do it well" is pretty much the design ethos of JS libraries, with a few exceptioins
<joepie91>
exceptions*
<ldlework>
joepie91: you've never experienced or witnessed the idea of using of a new language but saying something like "it isn't production ready as there are not enough libraries for things" or whatever.........?
<joepie91>
ldlework: oh sure, of course, I just haven't seen that overlap a lot with people who complain about JS
<joepie91>
I'm sure that some indetermine amount of overlap exists, it's just not something that has registered to me as a strong/common contradiction :P
<ldlework>
it seems more like a principled contradiction more than something any single person is obviously blamable for
<joepie91>
whereas I see the unix philosophy thing constantly
* samueldr
looks at grep command line options
<joepie91>
how do you mean?
<ldlework>
joepie91: having existing libraries in an ecosystem doesn't seem like a personal preference, rather than generalized practical notion
<ldlework>
it's not like any given person is running around zealously claiming the idea that a rich ecosystem is good for getting things done, but rather, one shared by anyone trying to get things done
<ldlework>
right?
<joepie91>
ldlework: in the sense that it's a commonly held preference/metric, yes
<ldlework>
right, and so anyone complaining about the atypical state of affairs in JS goes against this practical notion
<ldlework>
while there may be a value dip to any given programmer in that it is hard to keep up with such an ecosystem, that value dip is riding the wave of a much larger more fundamental value add
<joepie91>
I would generally agree with that, yes - but that agreement is not widely held
<ldlework>
that's for sure
<joepie91>
(though in my experience, those who don't agree with that almost never have any actual experience trying to make use of that value add)
<ldlework>
or seriously giving a go at trying to build a modern SPA (or whatever) by just linking to jQuery, etc
<joepie91>
exceptions exist of course, but the vast majority of people who I've had this discussion with and who disagreed with that, were arguing purely on hypotheticals and assumptions (often obviously wrong ones)
<joepie91>
and they had no comprehensive understanding or even practical experience of the process
<joepie91>
a really good example is the ever-recurring argument - usually implicit, not explicitly stated - that dependencies have a significant cost, in and of themselves, and therefore more dependencies is a higher maintenance cost
<joepie91>
which makes sense in a lot of other ecosystems, but not in JS; but people don't validate that assumption
<ldlework>
when an ecosystem shifts it's perception of the top-shelf solution for a given domain problem to something new, yes it means some new api learn, but it also means the solution for the domain has been incrementally improved
<ldlework>
sometimes i wonder if people would rather stagnate domain solutions in order to avoid learning new apis
<ldlework>
sometimes i feel this way myself, but in a better mood, i can see it is selfish and largely silly in a grander scheme of progress
<joepie91>
ldlework: well, yes and no. JS *does* have a problem with new tools appearing that are not actually an improvement over the previous options, but just push people's buttons better in terms of marketing :)
<joepie91>
see eg. Webpack and Browserify
<ldlework>
everything has that though
<ldlework>
and stepping backwards is progress
<joepie91>
sure, but it means you also can't assume that a new tool is automatically an incremental improvement
<ldlework>
you need to make mistakes and have the wrong ideas sometimes in order to eventually random walk towards progress
<ldlework>
and that goes for whole ecosystems too
<ldlework>
joepie91: definitely not
<ldlework>
but when I look at the last 15 years or so of javascript i see upwards progress on the whole
<ldlework>
a growing up and sophistication of formalizing their domain problems, at least relative to itself
<joepie91>
I would agree with that
<ldlework>
:D
<joepie91>
though to be fair, that is a not a very high bar, given 15-year-ago javascript :)
<ldlework>
heh we both had the same idea
<joepie91>
also, the entire discussion about browser-side JS and HTML and CSS always needs the caveat that UI stuff is difficult and nobody has actually figured it out yet, so you're pretty much bound to end up with something complex if you want a usable UI
<ldlework>
joepie91: in that sense though, thank god even for the steps backwards
<joepie91>
and it changes a /lot/ because we're all still figuring it out
<ldlework>
joepie91: this is the only way i can get through the day when i'm heavy into doing UI work for Unity. "no one has solved this. it isn't better anywhere else. this intrinsically sucks."
<joepie91>
a perennial source of amusement for me is when people complain that CSS is so crappy and bad and difficult
<ldlework>
"just keep typing. don't jump out the window"
<joepie91>
yet are unable to name a better option, and are surprised when I tell them that basically every single major native UI toolkit nowadays supports CSS or a derivative thereof
<ldlework>
joepie91: i am someone who simultatneously respects the problem CSS is trying to solve, and absoltuely resents every second i have to spend using it
<joepie91>
as it is the least bad option...
<ldlework>
i agree
<joepie91>
oh, absolutely, CSS is not pleasant to use, but that's a property of the problem domain, not of the solution to it :P
<ldlework>
indeed
<joepie91>
interfacing with humans is difficult
<joepie91>
perhaps I should start using the "inverse pitch" technique when explaining JS modules to people
<joepie91>
explaining and discussing the concepts and benefits of it first, before naming it as "that's what JS modules are"
<joepie91>
that has worked well for me so far, with other concepts where people have wildly incorrect preconceived notions
<joepie91>
about what a concept means or does
<joepie91>
like for example, almost nobody will think that "anarchy" is a remotely good idea when you pitch it to them... unless you start by describing the concepts first without ever using the word "anarchy" and only give it a name after people have already agreed that it sounds like a good idea
<joepie91>
then suddenly it's totally fine!
<ldlework>
joepie91: like you said, the people who are not thankful for whatever progress is made, arnt the one actually building non-trivial stuff, so who cares anyway.
<joepie91>
ldlework: well, it does matter, especially for ecosystem-y stuffcf
<joepie91>
stuff*
<joepie91>
it needs broader adoption to stay healthy
<ldlework>
the web has a monopoly though
<ldlework>
people not doing web stuff balking about having to learn new js apis all the time are the people i'm suggesting we ignore
<ldlework>
they're memeing
<joepie91>
unfortunately, those memes stick
<joepie91>
and they discourage people from even trying out or considering things
<joepie91>
as a concrete example: there's a reason why almost no language core team really took notice when some module on npm got compromised
<joepie91>
it was shrugged off as "well, it's JS, of course it's terrible" and so it wasn't recognized as a deeper and more fundamental problem to dependency management
<ldlework>
this is different than "ugh, I just learned angular, now I have to learn 'react'!?"
<joepie91>
these kind of memes are taken seriously by entirely too many people, and that has real consequences; not just for JS and its ecosystem, but also for the potential of software development as a field to move forward and improve things
<joepie91>
ldlework: I don't think it is; it's just on a different vector
<joepie91>
for example, there is an incredible amount of time and effort wasted maintaining monolithic monster dependencies, yet people continue doing it because of the memes that small dependencies will Make Hell Rain Down(tm)
<joepie91>
and that perception largely originates from people making fun of JS
<joepie91>
other languages have no reason to try and improve their dependency system, for example, because even trying to accommodate single-responsibility dependencies will very likely result in crowds with pitchforks and torches
<joepie91>
I can see the hackernews comments already - "why would you want to be like JS"
<joepie91>
and I bet that there have been maintainers of language cores idly wondering "hmm, would it be worth it to try and improve this towards modular deps", and dismissing the idea because it's not worth the potential pain to them
<joepie91>
and I find it difficult to blame them, with the mob that usually descends on people who try to publicly argue for single-responsibility deps
Drakonis has joined #nixos-chat
Drakonis has quit [Quit: WeeChat 2.4]
<Ralith>
people screeching 'left-pad' whenever you publish something below some arbitrary threshold of code size is frustrating, for sure
<joepie91>
yeah, that :P
<joepie91>
Ralith: OTOH, the mention of 'left-pad' is a great flag to determine when somebody doesn't know what they're talking about, since *that specific incident* had literally nothing to do with module size
<ldlework>
hehe
<joepie91>
somebody with a valid complaint is far more likely to bring up event-stream, or some obscure small module
<joepie91>
I guess it's a sort of anti-shibboleth?
<infinisil>
Modules/packages should have a decent size imo, big enough that the cost of having another module is less than the benefit of using it. If there's not enough related functionality to justify an entire module for it, one can collect such things into a utils module containing lots of small things
<ldlework>
you can't release a personal util lib like that, and then you have the problem of your own use across your own projects
<ldlework>
at work do we use Ben's util lib, or Mary's, or do we create one for FooInc
<ldlework>
Do we share one util lib across the company or do organizations have their own?
<ldlework>
We automated the management of packages
<ldlework>
We should use it
<infinisil>
I feel like that's a bit different of an issue. With public and open-source libraries having a single utility module should work well
<ldlework>
How could it? It's such an arbitrary umbrella for functionality. What about that one function that isn't in the library?
<ldlework>
Which functions shouldn't go in the library?
<infinisil>
Add it!
<Ralith>
infinisil: the point is that it's a fallacy to assume that "the cost of having another module" must necessarily be high
<infinisil>
As long as it's useful for a lot of things
<infinisil>
Application-specific helper functions of course aren't very general usually
<ldlework>
infinisil: i think there's a reason such libraries basically don't exist with high-popularity in basically any ecosystem I've used
<ldlework>
there's like functional-libs which have pure or lazy versions of everything you'd find in the core of a stdlib but not a legit "Random Util Functions Library"
<ldlework>
What would go in it? That could cover the entire domain of programs and use-cases?
<ldlework>
It seems unrealistic.
<infinisil>
I have seen such a library on hackage at least
* infinisil
looks for it
<ldlework>
What's it's popularity?
<ldlework>
For any given utils library, there's an infinite number of domain-agnostic functions that arnt in it.
<ldlework>
And likely a large percent of functions you wont need for a given program.
<ldlework>
I think Ralith has the idea. As the cost of "another module" goes to zero, the sensibility to use more and more specific packages to maximize modularity goes up.
<joepie91>
infinisil:
<joepie91>
"a really good example is the ever-recurring argument - usually implicit, not explicitly stated - that dependencies have a significant cost, in and of themselves, and therefore more dependencies is a higher maintenance cost"
<joepie91>
"which makes sense in a lot of other ecosystems, but not in JS; but people don't validate that assumption"
<joepie91>
about 1:30 hours ago :)
<joepie91>
the reality is that - in JS - modules themselves do not have a cost
<joepie91>
trusting additional parties has a cost, adding a given amount of code complexity has a cost, but neither of those things correlate to your module count
<joepie91>
this is not true in a lot of other ecosystems where every dependency you add significantly increases the risk of a dependency conflict (because their dependencies exist in a flat unversioned namespace)
<joepie91>
but the assumptions from those ecosystems do not transfer over to JS
<joepie91>
and having "a utils module containing lots of small things" is worse in literally every way than having a separate module for each of those small things
<joepie91>
it is more difficult to fork, version, audit / review, you are introducing unnecessary complexity into your codebase
<joepie91>
(namely: utilities that you don't use)
<joepie91>
and that's not even going into the more-difficult-to-define overhead such as the maintainer having to constantly think about "is this utility similar enough to these other things to go here, or isn't it"
<Ralith>
an interesting case study here is the rust ecosystem, which has high quality automated dependency management and, in principle, great support for interoperating with foreign libraries too. In practice, experienced rust users in many domains are far more reluctant to add foreign dependencies because they drastically complicate the development workflow, even on the margin.
<joepie91>
ldlework: there *is* a misc-util library in popular use, btw, underscore/lodash
<joepie91>
it is also a nightmare to deal with
<joepie91>
and it's usually one of the first things I rip out of a codebase I work on
<ldlework>
that's not a misc-util library though
<ldlework>
i mentioned those fp libs that implement fp versions of things you'd find in the stdlib
<joepie91>
that's not what lodash/underscore do though
<joepie91>
their scope is much broader
<joepie91>
(mentioning them together because lodash is a fork of underscore)
<ldlework>
i've used lodash
<ldlework>
it's very much a fp-versions-of-stdlib-primatives
<joepie91>
it's not :)
<joepie91>
it originally didn't even have any FP-y constructs
<joepie91>
and its scope goes well beyond what the JS stdlib offers, which is why people have been using it as a sort of 'better stdlib' for a long time prior to modules becoming a thing
<ldlework>
it's got fp goodies, and array/string/etc extensions
<joepie91>
yes, I know that
<ldlework>
and the point stands there are an infinite number of "util" functions that lodash would reject
<joepie91>
what I'm saying is that that isn't what it was specifically designed for
<joepie91>
it was a later addition
<joepie91>
and sure, there are things that it would reject, but that is true for ~every utility library, even internal to companies
<joepie91>
I still consider it a utility library simply because it doesn't have a well-defined scoppe
<joepie91>
scope*
<ldlework>
yes, and taken to the limit is left-pad
<ldlework>
because there are obvious ontological categories within lodash itself
<ldlework>
they even allow you to specifically just load the array extensions, for example
<joepie91>
if you mean the code in that screenshot, that's a bit misleading; while it technically "just loads" a specific part, that is pretty much irrelevant from a pragmatic perspective because you're still drawing in the entire library and you'd still need to review the entire thing
<joepie91>
so it doesn't really reduce any costs to do so, other than maybe a few KB of RAM?
<joepie91>
and maybe a little parse time
<ldlework>
what doesn't
<joepie91>
loading a specific subset of lodash
<ldlework>
the point is clearly lodash is implemented such that you can use just parts of it
<joepie91>
at least, via the method displayed in that screenshot
<ldlework>
so theoretically those parts could be different packages
<joepie91>
sort of.
<joepie91>
this is actually already the case, for much of lodash
<joepie91>
but the design is monolithic, not modular
<joepie91>
yes, they can be - and often are - technically separate packages, but it's all still tightly coupled
<ldlework>
you take a universe in which the cost of another module has approached the limit of zero, there's no reason to continue to group things together along arbitrary ontologies
<joepie91>
sure, I agree with that
<ldlework>
ah ok
<ldlework>
imaginging it for a moment, it's almost like the whole userbase of the ecosystem become the maintainers of one big library
<ldlework>
at the limit
<joepie91>
well, yes :) a shared public commons
<infinisil>
Hm yeah so I don't have any JS experience
<joepie91>
infinisil: right, so then I'd recommend learning about how its module system (and associated costs) work first :P
<infinisil>
I didn't really intend to discuss js-specificness though
<joepie91>
probably the main point is that the combination of (conceptually) nested dependencies and the lack of static typing means that 'dependency conflicts' are not a thing, outside of plugin mechanisms (where it is inevitable, conceptually)
<joepie91>
which is what reduces the cost of a module to zero
<infinisil>
But yeah I'd probably have to learn about it if I want to understand your opinions on it (and justify having my own)
<joepie91>
that is, the base cost
<infinisil>
joepie91: Oh
Myhlamaeus has joined #nixos-chat
<joepie91>
there are of course costs to adding code complexity in general, and trusting more people, but those vary by module and they depend on who you're already trusting for example, so they're not module base costs
<infinisil>
Not sure if I like that lol
<joepie91>
infinisil: it is effectively a less flexible form of the dependency model that Nix implements
<joepie91>
(there is also pnpm, which is almost equivalent to Nix' model)
<joepie91>
less flexible because the standard dependency model in JS supports deduplication upwards in the tree, but only if there are no conflicting versions, because the dependency folders themselves are not versioned
<infinisil>
Aren't there problems due to the dynamic nature of everything?
<joepie91>
so if you have conflicting versions, only one gets deduplicated fully
<joepie91>
infinisil: how do you mean?
<infinisil>
Like, random stuff failing at some point because updating changed the api somewhat
<infinisil>
And only at runtime you're even getting to those code paths
<joepie91>
infinisil: that's not really related to the dependency model, rather to the language's design
<joepie91>
where dependencies are concerned, this is addressed via semver
<infinisil>
Hm alright
<joepie91>
and while people love to yell about how unreliable that is, the reality is that incorrect semver versioning is actually pretty rare
<infinisil>
It is?
<joepie91>
it does happen, but for most people the cost of dealing with it will be lower than explicit API review for every update, and lower than having to statically declare everything
<joepie91>
yeah
<joepie91>
semver has been a part of npm pretty much from the start
<joepie91>
so it's ingrained in the culture, more or less
<joepie91>
and "not using semver" is a real reason for people to avoid dependencies :P
<infinisil>
And people really do update the major version for every breaking change?
<joepie91>
generally, yes
<ldlework>
the ver is more important than the sem, in semver
<ldlework>
pinning is the largest mechanism by which you productively use dependencies
<infinisil>
Hehe alright
<infinisil>
Good to know
<joepie91>
infinisil: there *is* a significant chunk of the ecosystem that camps at 0.x, though
<joepie91>
which can be a bit annoying
<joepie91>
but it's better than pretending to be doing semver but not actually :P
<infinisil>
joepie91: Yeah, same for the Haskell ecosystem
<ldlework>
if your program successfuly utilizes version N of some dependency, and pins to it, then upgrading to newer versions of that dependency can be controlled, whether or not the author of the dependency adheres strictly to the semantics of semver
<ldlework>
it's all about the breadth of breakage
<ldlework>
if you take the version N+1 of the dep, all you really care about as a consumer is how much broke
<__monty__>
infinisil: That's not true about Haskell. PVP doesn't have semver's 0.x
<ldlework>
the semantics may give you a loose sense at breakage across the history of a project by looking at the version numbers used, but that's just like a small heuristic
<ldlework>
you're still gonna have to look anyway
<joepie91>
infinisil: also, a bigger problem - though that has been rapidly getting better in the past few years - is that a lot of projects, while they adhere to semver, don't actually publish clear changelogs
<joepie91>
which... somewhat limits the utility of communicating a breaking change :P
<joepie91>
"okay, something broke, BUT WHAT"
<__monty__>
If JS makes heavy use of pinning versions, how do you deal with security updates?
<joepie91>
__monty__: realistically? not. and this is precisely the reason I've complained a lot about making package locks a default
<joepie91>
because it was 'solving' a problem that rarely occurred, at the cost of removing the last thing that kinda sorta accidentally upgraded stuff over time
<ldlework>
I mean if you have to upgrade a package you have to upgrade a package. The point is, you'll still have to investigate the breakage between the version you're using and the security release.
<joepie91>
the closest thing is `npm audit` which consults a DB of known vulns
<joepie91>
but it's way too noisy so people are starting to ignore it
<ldlework>
The semantics of semver are not going to help in a significant practical sense
<joepie91>
and update tooling is still lacking
<infinisil>
__monty__: What's 0.x in PVP?
<infinisil>
Because a lot of packages on hackage are in that range (from my experience at least)
<__monty__>
infinisil: It doesn't exist. 0.x in semver is basically "SEMVER DOES NOT APPLY HERE", PVP doesn't have such a thing. As soon as you version something under the PVP you're obligated to adhere to the rules, major breakage? -> major bump.
<infinisil>
Ah, and even 0.1 -> 0.2 is a major bump right?
<__monty__>
infinisil: No, that's because in x.y.z.w, *both* x *and* y together form the major component of the version.
<__monty__>
Yes, exactly.
<infinisil>
Gotcha
<__monty__>
"x" is often used to indicate "epochs", so where other ecosystems would publish "superCoolDoodad2" or "uberCoolDoodad," with the PVP you just increase "x," rather than "y."
<samueldr>
the way so many semver projects never go over 0.* makes me think it doesn't matter to those and they should have just as well gone with monotonically incrementing version numbers
<__monty__>
joepie91: Btw, what concerns me about the leftpad incident has nothing to do with the technical aspects of the JS module system (none of my criticisms do in fact). It just makes it look like npm is the stackoverflow of package collections.
<__monty__>
Which has major culture implications.
<joepie91>
food just arrived, so response time will be delayed :)
Jackneill has quit [Remote host closed the connection]
<eyJhb>
I feel like this started a debate. I should properly never mention JS again
<__monty__>
eyJhb: Wouldn't call it a debate really. Just a discussion. And as long as we can keep it to a dialogue all of the participants can walk away smarter : )
<eyJhb>
What I meant :p - Yeah. I still dread doing UI, but that is for any.. language.. I like my terminal
<ldlework>
I only use TypeScript these days anyway
<ldlework>
:)
<eyJhb>
ldlework: well, I don't have a strong oppinion on anything currently... Only thing I am quite certain of, is I want to us UIKit and VueJS
<samueldr>
good thing to know: don't let others bully you into choosing
<ldlework>
it's just nice getting C#-like intellisense over static types when doing webcrap
<samueldr>
at some places it seems common "why would you do X when Y does Z?!?"
<samueldr>
and make sure you're comfortable with doing the things the way the framework(s) you chose does, nothing worse than fighting against the framework
<eyJhb>
The thing I miss the most with most other languages, is how Golang doesn't allow me to do crap like unused variables, mixmatch variable types, etc. etc..
<__monty__>
eyJhb: Check out elm as well, it's interesting.
<eyJhb>
And actually, 90% of the time when my Go code compiles, it actually works
<eyJhb>
Whereas my Python might work, until it hit this very function and screws up
<__monty__>
Philosophy's similar to go in broad strokes.
<eyJhb>
samueldr: seems like a good idea :p
<eyJhb>
Actually ... My main thought currently is.. Should I make the website be able to function without JS?
<samueldr>
maybe
<samueldr>
the answer should be "yes"
<samueldr>
but depending on what you build sometimes making it work at 100% without JS becomes costly
<eyJhb>
Like, it is just a basic HTB thing, but more open source..
<__monty__>
Yeah, *always* try to have graceful degradation.
<eyJhb>
It should be fairly doable, but that also involves using server side template rendering
<samueldr>
and going 80% without JS might be worse than not working without JS depending
<samueldr>
but strive to make it work without JS
<samueldr>
it generally ends up giving stuff out "for free" that you would have to re-do in JS in or against a framework
<samueldr>
(in my experience)
<eyJhb>
Aw.. I had a dream of making a VueJS website which just interacted with a REST API :(
<eyJhb>
But yeah, come to realise it would be nice if it worked without JS
<eyJhb>
Hmm yeah, might be right
<eyJhb>
Is has been forever since I have done real web stuff... Especially in Go (read never)
<eyJhb>
The last big thing I did involving web was the AKU Aalborg Map I made
<eyJhb>
Yes. She seemed QUITE surprised when I told her.. No... :p
<eyJhb>
Reminds me.. Need to buy two domains and report my income in my company...
<joepie91>
<freenode___m "joepie91: Btw, what concerns me "> I'm not sure I follow this argument - it seems to imply that npm's package collection is of especially poor quality? I would agree that npm *itself* is of especially poor quality, but its package collection is AFAICT not meaningfully different in quality from basically every other package collection, and 'quality of packages' was wholly unrelated to the left-pad incident
<joepie91>
<freenode_eyJ "Actually ... My main thought cur"> if you call it a "website" (as opposed to a "webapp"), the answer is usually "yes" :)
<__monty__>
joepie91: It's not really about the package quality as much as about what sort of packages the community acutally uses.
<samueldr>
joepie91: well said (website vs. app)
<joepie91>
__monty__: I still don't quite see the argument - leftpad solved a concrete problem?
<joepie91>
samueldr: fwiw, the inverse is not true; a lot of people call their website a webapp...
<joepie91>
:P
<joepie91>
so if you call something a webapp, that really says nothing about whether it should work without JS or not
<__monty__>
Not really. It solved as much of a problem as too many of the java stackoverflow answers.
<samueldr>
go to my webappblogpersonalsitepage made entirely in react with a 99.99 SLA k8s cluster(fuck)
<samueldr>
hm s/react/frontend-du-jour/
<samueldr>
(if I want to be fascetious, let's go to 11)
<joepie91>
samueldr: the way I usually present this when people ask about the more general case, is: can you express the logic of your application as request/response things? if yes, make it work without JS. if no, it's an app and not a site, and you shouldn't bother making it work without JS.
<joepie91>
that explanation /usually/ works.
<joepie91>
(though not always)
<joepie91>
__monty__: ?
<joepie91>
how is "I have a string that I need to pad to a fixed width" not a concrete problem to solve?
<joepie91>
(and further, even if it isn't, how does this have anything to do with the incident?)
<samueldr>
joepie91: "shouldn't bother" I generally go with "might be costly to make it work right without js just as well"
<samueldr>
(so yeah, shouldn't bother for some/most cases :))
<joepie91>
samueldr: well, I'm simplifying somewhat here, but for me the context is often people who don't really understand much of anything yet and whose views on software development are entirely shaped by medium posts and bootcamps
<samueldr>
yeah :)
<joepie91>
so... decisive answers with a "you'll know when this seems wrong" tends to work better for those
<joepie91>
I do usually include a caveat somewhere that subtly signals that things are not always so decisive
<joepie91>
but unfortunately, there being a lot of articles that sound a lot more sure of themselves than they should justifiably be, tends to make people expect decisive answers :/
<joepie91>
it's a constant battle against the shitty Tutorials(tm)
<__monty__>
joepie91: It's something any programmer worth his salt just knows how to do. I haven't come across any other language where people reach for a dependency to achieve that. Or, when they do, it's actually a formatting library that solve's quite a more difficult problem, like text justification.
<joepie91>
__monty__: I'm not sure you understand why people use dependencies.
<__monty__>
joepie91: Doesn't need to have anything to do with the incident. The incident just brought leftpad to my attention.
<joepie91>
it's not because they "don't know how to do" a thing - it's because it's a wsate of time and energy to reimplement a solution that others have implemented before, and rediscover all the obscure edge cases
<joepie91>
waste*
<joepie91>
if somebody refuses to use a dependency on the grounds that "I know how to do this myself", that is frankly a huge red flag to me
<Ralith>
any programmer worth his salt knows how to build a number of standard data structures, and knows not to actually do so
<joepie91>
there can certainly be valid reasons not to use dependencies, but that ain't one of them
<adisbladis>
I know how to do a lot of things I use libs for...
<joepie91>
(and unlike stackoverflow answers, dependencies can be versioned / managed / etc.)
<adisbladis>
There are other factors determining this
<joepie91>
also, to expand on this: the reason it's a huge red flag to me, is because it almost certainly means that that person is wasting time, and in a commercial setting that means throwing away money
<joepie91>
waste is generally undesirable in commercial environments :)
<joepie91>
(in non-commercial environments this gets a little fuzzier)
<__monty__>
The fact that "leftpad" is used, rather than something that actually does something useful or a naive "80-length(string)*space ++ string". Tells me that when most people look for a dependency in JS they just do "NPM search: left pad", then pick whatever turns up. Rather than actually think about whether they might need to do any more formatting in the rest of the program.
<adisbladis>
joepie91: In non-commercial environments no one cares if I waste a few hours tuning a silly function :P
Myhlamaeus has quit [Ping timeout: 248 seconds]
<joepie91>
__monty__: and this is a problem... why, exactly? you're implying that this is a bad thing, but never actually making a concrete cost / tradeoff analysis as to *why* it would be.
<adisbladis>
joepie91: It is a bit of a problem though... You get a lot of attack surface when you're pulling in 1000 deps in a project
<joepie91>
adisbladis: well, not necessarily. in projects involving multiple people, or projects that a lot of people depend on, it can certainly be a problem
<joepie91>
adisbladis: no, you don't
<joepie91>
"1000 deps" is an irrelevant metric
<joepie91>
I went through this like an hour ago, please read back :)
<__monty__>
You don't see a problem with people just writing code without thinking?
<adisbladis>
No it's not an irrelevant metric.
<joepie91>
actually more like 2 hours by now I think
<joepie91>
__monty__: that is a misrepresentation of what is happening.,
<joepie91>
so I'm not going to engage on that.
<joepie91>
adisbladis: really, please read back. I am not going to rehash this topic for the third time in a single conversation...
<adisbladis>
joepie91: I read the backlog. I just don't agree.
buckley310 has joined #nixos-chat
<__monty__>
Except, not really. How was leftpad *ever* a thing? The absolute minimum functionality I'd expect from a library that does leftpad is right, centerstring and just outside of the bare minimum is justification of full paragraphs, because what if the string doesn't fit?
<joepie91>
you haven't addressed the point at all, so "I just don't agree" is non-actionable information to me
<joepie91>
__monty__: you're quick to conclude that if somebody came to a different conclusion, they must have been "writing code without thinking".
<joepie91>
and like I said, I am not going to engage on that line of reasoning.
<joepie91>
I'll happily address any concrete concerns/costs/tradeoffs/etc., but this is a discussion path I have no interest in.
<__monty__>
That's fine. If you think "leftpad" is a perfectly valid library all on its own I don't think we *can* get anywhere.
<joepie91>
that sounds suspiciously much like an admission that you're arguing dogmatically, not rationally :)
<__monty__>
It does? Then point out why.
<adisbladis>
Lol, is-number is at version 7.0.0
<adisbladis>
How can something like that have 7 major versions
<joepie91>
__monty__: you're excluding discussion on the basis that the party you're discussing with has a different view.
<joepie91>
adisbladis: this is devolving into bashing, let's not go there.
<__monty__>
joepie91: You're the one who didn't want to engage. All I did was conclude that, indeed, if you're adamant about leftpad being a useful library we won't get anywhere. Because the crux of my point is that it's not.
<joepie91>
__monty__: if the "crux of your point" is the conclusion, that means that you don't have an argument.
<joepie91>
a view can't support itself as its own argument
<joepie91>
ie. dogma
<__monty__>
"Leftpad shouldn't be a library" is not my conclusion. My conclusion is there's too many incompetent people getting paid to program JS, to put it bluntly.
<joepie91>
__monty__: okay, so since the subtle hints are evidnetly not getting across: you're behaving like an arrogant asshole right now. your entire reasoning so far reeks of "these people have made different decisions from what I would do, therefore they are idiots".
<joepie91>
you're not merely criticizing particular practices (without solid technical arguments, I might add) -- you're directly attacking entire groups of people
<joepie91>
so like, maybe not do that?
* joepie91
really has no patience for exclusionary bullshit today
<__monty__>
joepie91: I'm fine with dropping this. It's really hard to have any sort of discussion with you where you disagree. You just call me an asshole within 10 responses every time. The Raylan Givens quote comes to mind.
<joepie91>
__monty__: this discussion went fine until you joined in. perhaps you should consider that the reason I keep calling you an asshole, is because *you're constantly behaving like an asshole*.
<joepie91>
as this certainly isn't the first time you've taken an arrogantly dismissive stance like this
<joepie91>
(you'll also notice that I don't say these things to other discussion participants)
Myhlamaeus has joined #nixos-chat
<__monty__>
You got awful close with adisbladis, who disagreed. And no one else disagreed.
<joepie91>
__monty__: infinisil disagreed on some points
<joepie91>
no issue with them
<joepie91>
and again, this is not the first discussion where this happens
<joepie91>
I also didn't call adisbladis an asshole
<ldlework>
there's just not a lot to work with when it comes to low-effort cynical tech memeing
<__monty__>
I don't see how I'm being dismissive btw. I'm not saying anything JS in general or the module system. I'm not saying there's no competent people writing JS. All I said is that things like leftpad look like symptoms of the SO-type of coder getting into industry. And that colors my views of JS because whenever I need to use a JS project there's this voice in the back of my mind going "Are you *sure*
<__monty__>
this wasn't written by one of those, 'copy, paste, works?, move on,' kind of programmers? The implication being that'll all too often turn your life into hell."
<__monty__>
s/anything/anything about
<joepie91>
__monty__: you're being dismissive because you're not considering the possibility that other people might legitimately have had different - but equally valid - experiences that have led them to different conclusions
<joepie91>
you're shittalking entire groups of people because their practices don't match your own, without bothering to really understand why those practices don't match
<joepie91>
'dismissive' because you're not considering other people's experiences and rationales, 'arrogance' because you're assuming that whatever conclusion you ended up at must be the correct one, and the process by which you got there the right one
<ldlework>
also i thought i put out a pretty well-made case the context in which left-pad (and a potentially infinite number of libraries like it) can be come justified and useful
<__monty__>
Feel free to pinpoint where? Oh, so you're just taking my generalizations and pretending I hold them as fact?
<joepie91>
if your argument is that there are bad practices in JS-land, and that argument is actually legitimate and supportable through rational arguments, you can make that argument just fine without attacking swathes of people
<__monty__>
ldlework: Yes, in the hypothetical universe where dependencies have zero cost.
<joepie91>
that you choose to attack people instead of arguments is the problem
<ldlework>
it's just an argument then of how close we are to the limit
<ldlework>
is the cost of a nodejs library very high?
<ldlework>
isn't the proliferation of tiny libraries evidence that it is, at least, relatively low?
<ldlework>
scoffing at incompetence of hundreds of thousands of developers is just effortless cynical tech memeing and is definitely dismissive
<ldlework>
it's fine to do it, but don't stand it up as a serious engagement of or submission to an on-going discourse
<__monty__>
When did I attack people? I stated that this influences *my* perception of "JS users." If sharing an opinion is equivalent to an attack then I don't know how to have any discussion at all.
<ldlework>
huh? you called a portion, which is too large in your estimation, of the JS developer base, "incompetent"
<joepie91>
"You don't see a problem with people just writing code without thinking?" "My conclusion is there's too many incompetent people getting paid to program JS, to put it bluntly." "The fact that "leftpad" is used, rather than something that actually does something useful or a naive "80-length(string)*space ++ string". Tells me that when most people look for a dependency in JS they just do "NPM search: left pad", then pick
<joepie91>
whatever turns up. Rather than actually think about whether they might need to do any more formatting in the rest of the program."
<joepie91>
__monty__: the better question is where you *didn't* attack people.
<joepie91>
that's just three obvious quotes, not even counting the unspoken subtext in a lot of your other comments
<joepie91>
(which is unsurprisingly consistent with those quoted explicit statements)
<infinisil>
eyJhb: Man I sure love statically typed languages
<infinisil>
Just yesterday did a mediocre refactor of a smallish Haskell codebase, and I just had to fix compilation errors until no more left
<infinisil>
And it worked again after that :)
<__monty__>
joepie91, ldlework: Maybe you're reading something into that that I'm not? All of those are talking about my impression of JS developers.
<ldlework>
infinisil: I'm so over dynamic languages!
<joepie91>
__monty__: I'm running out of ways to explain to you that it is not okay to attack broad classes of people like this.
<joepie91>
I understand perfectly well what you are talking about, and that is precisely the problem.
<__monty__>
joepie91: Then maybe move past that one issue. Take another tack. A single disagreement shouldn't prevent any and all discussion.
<joepie91>
__monty__: I've attempted to do that several times by telling you that I was not interested in going down that particular discussion path. you then responded with "If you think "leftpad" is a perfectly valid library all on its own I don't think we *can* get anywhere." -- stating clearly that *YOU* had no interest in discussing further.
<joepie91>
this is on you, not on me.
<joepie91>
and you really need to look inward instead of assuming that the problem is with other people.
<__monty__>
I interpreted each of those occasions as you saying "The discussing ends here for me unless you agree that leftpad's ok."
<joepie91>
that is also on you, not on me. I've even explicitly stated that, quote, "I'll happily address any concrete concerns/costs/tradeoffs/etc." -- which directly contradicts your interpretation.
<joepie91>
(I do make these sort of explicit statements for a reason...)
<__monty__>
But you won't address my concerns about JS culture. So that statement seems rather vacuous.
<joepie91>
you have given me no concrete, actionable, rational points to address.
<joepie91>
but if I missed one, feel free to repeat it
<__monty__>
My concern that leftpad's existence implies a significant portion of JS developers aren't skillful enough to do what they do, and therefore are costing companies worldwide tons of money and worse yet users everywhere, time, *is* rational.
<ldlework>
literally anything on my path to what i need to do that's already done is at least a potential benefit to me
<joepie91>
__monty__: I already addressed that point.
<__monty__>
ldlework: But you can't blindly trust that a library claiming to do something actually does said thing.
<__monty__>
joepie91: You did?
<ldlework>
that's what we do all the time, continuously
<joepie91>
"it's not because they "don't know how to do" a thing - it's because it's a wsate of time and energy to reimplement a solution that others have implemented before, and rediscover all the obscure edge cases"
<ldlework>
and the smaller the library, the more likely it's going to do the right thing
<joepie91>
yes, it was more or less the first thing you asked I believe
<joepie91>
and I answered it right away once I got back from my dinner
<buckley310>
The dev team at work recently build a proof-of-concept app in nodejs. this particular app has a handful of direct dependancies, but i mapped the thing out and it depends on over 800 dependancies total. this level od dependancy sprawl is completely out of control IMO. as someone trying to look at it from a security perspective all i can do is throw up my hands and hope all the modules are fine
<ldlework>
the same is true in Python, or Ruby, or basically any ecosystem
<joepie91>
buckley310: this is the fourth time in this single discussion that somebody brings up the "number of modules", and once again I am going to point back to when I addressed this point several hours ago
<ldlework>
in that they're well over the threshold of realistically continuously auditing
<ar>
/36
<joepie91>
the number of modules does not matter
<buckley310>
sorry i jumped in late :)
<ldlework>
hehe
<infinisil>
buckley310: (note that it's spelled dependEncy :))
<joepie91>
it has no direct relevance to auditability, trust, code complexity, performance, or any other metric you actually care about
<joepie91>
what matters is primarily a) how much code complexity you are adding, and b) how many new people you are trusting
<joepie91>
fine-grained modules actually improve upon A, because since it is more granular, you are drawing in less (or not) complexity that your application doesn't need, you only 'pay for what you use'
<ldlework>
besides, you might not care about all your transitive dependencies, but the projects for which those transitive dependencies are concrete dependencies, care
<joepie91>
B is a more tricky topic, but often mitigated by a lot of common dependencies being from the same few authors
<ldlework>
why do you care if there's three people maintaining your three concrete each independently caring about their own independent concrete dependnecies, instead of one person?
<ldlework>
is that intrinsically better?
<joepie91>
resultingly, it is easier to actually properly audit dependencies in a JS project [that uses single-responsibility modules] than in a typical Python/Ruby/whatever project, because you only need to audit the code that is actually used in the project, not a pile of unrelated framework boilerplate that you can't be quite sure isn't being used
<ldlework>
isn't the opposite intrinsically better? wouldn't it be better if there were one person responsible each for each tiny dependency?
<joepie91>
(of course auditing deps still generally sucks due to lacking review tooling, but that is universal across ecosystems)
<joepie91>
in the end, the auditing/reviewing cost is in the amount of logic that your codebase, in full, contains - exactly how many slices that is cut up into isn't really relevant, other than that larger prefab slices means you're probably adding more logic you don't need (but other users of the slice do)
<infinisil>
joepie91: In Haskell-land, there's SafeHaskell, which allows you to be sure that the types express exactly what they do. So with this you don't even need to audit the source code (from libraries that are IO-free at least), because the compiler does it for you :)
<joepie91>
infinisil: the "from libraries that are IO-free at least" caveat seems to make this a bit useless, since that is generally precisely the part that you care about security-wise :P
<joepie91>
IO, that is
<ldlework>
haha
<infinisil>
Nono, not at all
<infinisil>
Libraries can have effects without needing IO
<infinisil>
Well in the end everything is IO yes, but with the type system you can restrict it arbitrarily
<joepie91>
yes, I get that, but most real-world attacks try to do something to the effect of "execute code" or "dump a database", both of which - as I understand it - qualify as IO in Haskell
<joepie91>
er
<ldlework>
i'm surprised the halting problem doesn't come up there, but i probably don't understand "the types express exactly what they do" means
<ldlework>
or how that's possible
<joepie91>
read 'execute code' as 'execute an external binary'
<__monty__>
joepie91: The github comment you linked seems to argue that "single-line/function libraries aren't bad," but that's besides the point. Unless you believe the same arguments that apply to negative-zero also apply to leftpad?
<infinisil>
ldlework: In normal Haskell there are some escape hatches to the types, like unsafeCoerce, or unsafePerformIO
<infinisil>
ldlework: In SafeHaskell all those are disabled
<joepie91>
anyway, buckley310, see above for a summary of the module count thing
<joepie91>
__monty__: yes? they are not arguments for negative-zero, they are arguments for single-responsibility modules, of which both negative-zero and left-pad are examples
<ldlework>
infinisil: sounds cool
<buckley310>
eh, breaking packages down as far as npm does still just rubs me the wrong way
<__monty__>
Btw, imo negative-zero being a thing is a consequence of a language wart. Not a great example of a good single responsibility dependency.
<buckley310>
leftpad specifically, i would impliment myself because it seems like less effort
<buckley310>
but then leftpad is kind of a meme to everyone arguing against npm
<joepie91>
__monty__: I don't see why not. regardless of the reason *that* normalization is needed, it is a very obvious example of a library that handles edge-cases that you might not have thought of.
<joepie91>
and explicit examples like that are didactically useful.
<joepie91>
because it is much easier to show than "hey look at this one API that does something weird in this edge case that is so obscure that we need two hours to explain what it even means"
<joepie91>
buckley310: how would it be less effort to implement yourself?
<__monty__>
joepie91: I'm not arguing against single-responsibility modules. My argument is that this specific one is a symptom of something. And I can't explain that something any other way than laziness (best case) or incompetence (worst case).
<__monty__>
The specific one being left-pad.
<__monty__>
Why do I conclude this? Because before the left-pad incident I had never even considered depending on an external dependency for such functionality.
<joepie91>
I haven't seen you 'explain' anything, frankly - you just seem to be assuming the worst in people, and operating off the assumption that leftpad is Bad, Somehow without ever actually turning it into a well-supported rationale about concretely what is wrong with it
<joepie91>
which goes back to my earlier comment that this sounds like dogmatic discussion, not rational
<buckley310>
joepie91: its a simple one-liner to impliment myself, and its a solution i can reason about. i see no reason to delegate the functionality to an external black-box if the box just contains two cogwheels that are completely simple and comprehensible.
<joepie91>
I feel like you've already drawn a conclusion and are now trying to backfill it with vaguely plausible-sounding rationales that don't actually make a technical point
<joepie91>
buckley310: why wouldn't you be able to reason about leftpad?
<buckley310>
i can. thats my point
<joepie91>
and however 'simple' you think it is (and it probably isn't), it still won't be simpler than calling a single function with two arguments
<joepie91>
ah, right, I get what you mean with that now
<joepie91>
misinterpretation on my part, sorry :0
<joepie91>
:)*
<joepie91>
that second point stands though
<__monty__>
What's wrong with leftpad is that it's too specific, I've said this already. How often do you need to pad strings on the left but not the right? And heaven forbid wanting to center them.
<buckley310>
to me, leftpad is a meme, and event-stream is a more concrete example
<joepie91>
__monty__: "too specific" by what metric?
<joepie91>
needing to pad strings on the left but not the right is quite common actually
<joepie91>
for aligning numeric values in particular
<buckley310>
event-stream is a project that is an indirect dependency of tons of stuff, and a hacker got a hold of it.
<joepie91>
correct
<__monty__>
joepie91: But *why* can't it be a function like pad("left/right/center", string, width)?
<__monty__>
That's objectively *more* useful imo.
<__monty__>
And it's not any harder to use, but maybe that's subjective.
<joepie91>
__monty__: left and right may have been justifiable because the implementation complexity would barely increase. center-padding, however, is a lot more difficult, and should be its own module (because now you need to start thinking about how to round uneven padding, for example)
<joepie91>
the auditability benefits that I mentioned earlier, for example, only apply if you really do have single-responsibility modules, and their internal complexity reflects that
<joepie91>
if you only need to left-pad, and you grab a module that can center-pad, now you have considerably more added complexity to review ( / that could break) in your codebase that you don't actually need because you didn't need to center-pad
<joepie91>
and that's an unnecessary cost
<__monty__>
I argue it shouldn't be its own module. Because it's such a simple combination of a right and a left pad. And that decision you would call "opinionated" and be done with it. If it's really such a big deal for someone they can use left and right themselves. *Or* you can add a flag and not have the discussion at the cost of making the web less uniform.
<joepie91>
__monty__: what you're basically saying here is "/I/ don't care about the overhead"
<joepie91>
which is all good and well, but not a useful stance on an ecosystem scale
<joepie91>
and therefore not a valid argument here
<__monty__>
That's not what I'm saying. I'm saying that either choice would be good enough as the default.
<joepie91>
except some people will think it's not
<joepie91>
and now you're back to where you started, with complex multi-responsibility dependencies
<__monty__>
Only if you subdivide the "padding a string" responsibility.
<joepie91>
the whole value of the ecosystem is in the fact that modules are /not/ opinionated, that they do precisely what they say on the tin, nothing more, nothing less, and make no assumptions about your usecase or requirements
<joepie91>
__monty__: which I have, because like I already explained, center-padding is considerably more complex than left/right-padding
<joepie91>
on a relative scale
<joepie91>
and thus not a defensible addition to a left/right-padding library, on grounds of unreasonable complexity creep
<__monty__>
Btw, the argument that smaller but more modules make for easier auditing isn't quite that simple. If you modularize a component you not only have to audit each module but you also have to audit *every* possible interaction, which is n^2 worst-case. (Just a reason why I'm reluctant to accept that argument at face value. I know this isn't super intuitive and frankly it sucks but it's the way it is.)
<joepie91>
__monty__: this is only true when components are tightly-coupled
<joepie91>
when each component has a well-defined responsibility and loosely coupled assumption-free API, that does not hold true
<joepie91>
(of course, if the API of something is /not/ well-defined, that introduces an additional auditing cost, but that is generally true of all code)
<__monty__>
joepie91: I don't think it's unreasonable. You fix the problem once in the library and most people don't have to worry about it any longer. On the other hand if you have a left/right pad module and two or more center-pad modules, now the developer has to make a choice as to which one to use. And I don't have confidence in developers to make the right choice every time.
<joepie91>
__monty__: what choice? either you need left/right pad and you pick that module, or you need center pad and you pick that module
<joepie91>
there is literally no difference in that aspect
<__monty__>
But you just said there can't be *one* center-pad module because there's varying trade-offs and not everyone needs the same one.
<joepie91>
"you fix the problem once in the library" is true of any kind of dependency, it isn't exclusive to bundling multiple responsibilities
<joepie91>
__monty__: sure, but that holds true regardless of whether the implementations are bundled or not.
<joepie91>
because that's what this all comes down to.
<joepie91>
you have the same amount of implementations regardless, the difference is whether they are all forcibly bundled into a single module, or split into separate modules
<joepie91>
either way you have to select the correct implementation for your requirements
<__monty__>
I'm saying there *should* be one clear standard way to center-pad, decided on by experienced programmers and promoted by being included with the left/right pad so most devs automatically use that one. If they *know* they need another one I'm much more at ease with trusting them to pick the *right* other one.
<joepie91>
and bundling them has the additional downside of forcing people to import the implementations into their codebase that they /don't/ need.
<joepie91>
__monty__: there isn't one clear standard.
<joepie91>
and there won't be.
<joepie91>
because usecases vary.
<joepie91>
these sort of ideal-world arguments are useless from a pragmatic perspective, they don't address real-world developer requirements
<joepie91>
sure, wouldn't it be nice if everybody's usecase could be handled by a single standardized approach? but it can't, and tools will have to deal with that reality
<joepie91>
and then you have a choice of either a) building your tools so that they can deal with that reality, as best as possible, or b) pretending that the world is ideal and building your ideal implementation and then finding that it causes pain
<__monty__>
Their the opposite of useless from a pragmatic pov. Either one choice is obviously the right one in the majority of cases and you pick that one *or* none is clearly the right one and then it doesn't matter which one you pick.
<__monty__>
*They're
<joepie91>
that's... not how requirements work.
<joepie91>
there is no law that says there is always a majority case.
<joepie91>
nor is there a law that says that if there isn't, it must not matter which you pick
<__monty__>
Also, doesn't minification throw out all the functions that are unreachable?
<joepie91>
these are not universal truths
<joepie91>
no
<joepie91>
and 'minification' is not a thing outside of browsers anyway
<joepie91>
(or not commonly, anyway)
<joepie91>
nor does it matter for auditability because you audit inputs, not build products
<__monty__>
JS doesn't have culling of unused code?
<__monty__>
You definitely have to audit build products. Otherwise you might as well not be doing anything.
<joepie91>
there are tree-shaking implementations, but it's not possible to *reliably* shake out unused code, since what is "unused" can be undetermined until runtime
<joepie91>
(this is generally true for programs, it's just more obvious in JS' design)
<joepie91>
(and more expensive to automatically analyze)
<joepie91>
so whatever dead code culling you do, it will never be perfect
<joepie91>
and even if it were, it still wouldn't really help much with auditability :P
<joepie91>
at least, unless you were to re-process every dependency every time the code was changed
<__monty__>
I don't know why this discussion escalated so quickly in the first place btw. The last ~30min seem to have gone alright. And it sounded like we were in agreement on culture problems around JS before I said anything.
<joepie91>
well, you've generally stopped attacking people and started focusing on technical/pragmatic arguments :) so now there is an actual constructive discussion to have
<joepie91>
that having been said, it's getting late and I do need to sleep soon
<gchristensen>
I miss being in my regular TZ. being in America/Los_Angeles means my EU friends go to bed while I'm at lunch.
<__monty__>
See my pov on this is very different. Rather than getting attacked I got to have a discussion.
<__monty__>
gchristensen: Did you relocate?
Jackneill has joined #nixos-chat
<gchristensen>
I'm at a client
<joepie91>
__monty__: right, but that is why I said you should look inward more. there's a reason you're getting a discussion now
<joepie91>
I'm not an RNG
<joepie91>
or at least, not a very good one :P
<infinisil>
gchristensen: Well, I'll still be awake in your evenings :P
<gchristensen>
oh?
<gchristensen>
some people are waking up when I'm going to sleep
<__monty__>
joepie91: That's the thing though. I didn't change my behavior. Your impression of my behavior may have changed but I did not act any differently.
<joepie91>
__monty__: your intentions perhaps didn't change, but your behaviour did. whether that is due to conscious choice or just where the conversation took you, that's something I can't determine for you.
<__monty__>
infinisil: How do you pull off this magic? You're often awake while I am.
<joepie91>
but I do want to strongly suggest taking the feedback on board, and reviewing the conversation later
<__monty__>
gchristensen: More cool top secret nix work for Target?
<gchristensen>
I'm not at Target :)
<infinisil>
__monty__: I like being alone, I can avoid a lot of people if I stay awake very late lol
<infinisil>
And being unemployed helps too I guess
<joepie91>
infinisil: you might find headphones with active noise cancelling to be a good investment
<infinisil>
Or being a student
<infinisil>
joepie91: I already have ones, they're pretty great, use them all the time
<joepie91>
ah, right :)
<infinisil>
Bose QuietComfort I think
<joepie91>
turns out silence can actually be bought
<joepie91>
infinisil: QC-35 probably>
<joepie91>
?*
<infinisil>
That might be it yeah
<joepie91>
I have the same ones
<joepie91>
they work shockingly well
<infinisil>
Ah nice :D
<__monty__>
I thought it didn't really work unless they get to make noise.
<joepie91>
not /perfect/ but quite good
<__monty__>
?
<joepie91>
__monty__: yeah, that's what the 'active' in active noise cancelling is about :)
<joepie91>
microphones + inverse soundwaves or w/e that effectively 'cancel out' environmental noise
<infinisil>
They are best at cancelling actual noise, like white noise
<infinisil>
Random sounds not as much
<joepie91>
yeah
<__monty__>
No, I mean they only work when producing sound, as in music.
<joepie91>
well, depends on the frequency
<joepie91>
__monty__: no
<joepie91>
I mean, it'll work better of course, even at low volumes, since there is something to distract your brain
<joepie91>
but the cancellation itself works with or without music
<joepie91>
literally turning them on and putting them on your head without being connected to anything, means instant silence
<joepie91>
(on the frequencies it filters)
<ashkitten>
tbh i really want some low-profile headphones that don't obstruct outside noise
<joepie91>
cancels out white noise, low rumbly noises, and severely mutes a lot of other annoying things
<ashkitten>
do they make those?
<__monty__>
That's exactly what I mean. The brain's a fickle mistresse.
<joepie91>
ashkitten: that's most, really?
<ashkitten>
hmm
<ashkitten>
like
<joepie91>
like, get a cheap $10 set of headphones and they'll leak like a sieve :P
<ashkitten>
yeah, i guess
<ashkitten>
i don't want bad headphones tho
<joepie91>
you can get good ones for $20
<infinisil>
The QC ones can also relay the sound from outside i think
<joepie91>
they can?
<ashkitten>
i just want something for when i'm laying down but want to be able to hear if anything happens
<joepie91>
is that one of those things you need the app to enable?
<infinisil>
joepie91: Ah yeah, needs app, i think
* infinisil
checks
<ashkitten>
are those low profile?
<joepie91>
ashkitten: I wonder if there's a headphone version of whatever the Oculus Quest does
<joepie91>
(VR headset)
<ashkitten>
i can't use in-ear headphones because they irritate my ears
<joepie91>
they've somehow integrated speakers into the headband or the headset edge, I'm not really sure, directional ones
<__monty__>
As in, it lowers the noise floor and therefore random distracting sounds, even though they're muted still stand out.
<ashkitten>
so i want something that won't be uncomfortable when i'm lying on my side
<joepie91>
and so you get to hear sound at a significant volume, in good quality, with zero outside sound obstruction
<joepie91>
nothing over your ears
<joepie91>
it's bizarre how well it works
<infinisil>
joepie91: ah no, i can only turn off noise cancelling, not relay sound from outside
<__monty__>
Is VR more than a passing fancy yet? I want it to be but so far it seems like it's a gimmick that wears off for most people.
<joepie91>
but yeah, I wonder if there are any headphones with a similar construction, just a directional speaker basically, with whatever magic they do to make it sound immersive
<joepie91>
__monty__: I bought a Quest like a month ago (grudgingly, because Facebook) and I don't regret it one bit
<joepie91>
the reason I finally gave in is that it's a zero-setup, self-contained unit
<joepie91>
so it's literally put the headset on in whatever empty space you have, and play
<joepie91>
and imo that's put it into the "this is viable as a mass-market gaming product" territory
<joepie91>
I mostly play beat saber, but there are a bunch of pretty good games for it already
<joepie91>
and I think that it's reached the point where it's a viable long-term thing
<Ralith>
beat saber is probably the best VR game, and I don't say that as an insult to VR
<Ralith>
it is just really goddamn good
<joepie91>
I certainly don't expect myself to get bored with it any time soon :P
<joepie91>
Ralith: aye, it's become my primary form of exercise actually
<ashkitten>
i want a vr setup just so i can get beat saber
<joepie91>
finally exercise I actually enjoy lol
<ldlework>
Leo are you the leo60228 on github?
<Ralith>
the new Valve hardware is expensive but very nice, and it even runs on linux
<joepie91>
Ralith: downside is that it's wired
<ldlework>
Ralith: have you sideloaded custom songs?
<Ralith>
I got a vive at release and have been using it regularly ever since then
<Ralith>
joepie91: inorite
<ldlework>
There are packs called "Songs With Great Flow" or something like that
<Ralith>
the wire is not a big deal
<ldlework>
I got em all, and they are really great
<__monty__>
You're still in the honeymoon period though.
<joepie91>
__monty__: oh, I should note, the tradeoff of the Quest is that it's essentially a mid-range phone, specs-wise, so don't expect graphical marvel
<joepie91>
but it's more than good enough
<ldlework>
joepie91: you got the quest?
<joepie91>
ldlework: aye
<Ralith>
ldlework: yeah I've been working my way through those lately
<ldlework>
nice me too
<Ralith>
__monty__: I got my vive literally years ago
<infinisil>
Damn, just looked at some Beat Saber gameplay
<ldlework>
joepie91: you gotta take it to a huge field after dusk
<joepie91>
__monty__: nah, I get bored with fads a lot faster than this :)
<Ralith>
haven't played a 2D game since
<infinisil>
That game looks pretty sick
<ldlework>
unlimited space
<ldlework>
it's so fun
<joepie91>
ldlework: does that actually work? without fucking with the tracking?
<ldlework>
infinisil: it's not a bad workout either
<joepie91>
AIUI empty spaces are a big issue
<ldlework>
joepie91: it works awesome
<Ralith>
it is super sick
<joepie91>
oh, huh, maybe I should try it
<ldlework>
joepie91: it tracks grass just fine
<joepie91>
interesting
<joepie91>
ldlework: out of curiosity, do you have the right controller tracking miss issue as well
<Ralith>
you will annihilate your arms using it
<Ralith>
low light will be an issue with the quest
<joepie91>
it's apparently a common-ish issue
<joepie91>
and it gets very annoying at Expert+ :P
<joepie91>
(in beat saber)
<ldlework>
joepie91: for me sometimes both controllers will go straight through a block
<ldlework>
but it's not frequent so i barely notice
<joepie91>
ldlework: right, so for me the failure mode is that one of the controllers is suddenly hovering in the air, and it's rotating like I rotate it, but not moving
<joepie91>
predominantly the right controller
<ldlework>
i'm playing expert and expert+ and i'm well satisfied with the tracking
<joepie91>
and apparently the same has been happening for a lot of people, also the right controller
<ldlework>
joepie91: yeah super rarely
<joepie91>
so I'm starting to suspect an accelerometer manufacturing fault
<ldlework>
can't say whether its one more than the other
<ldlework>
joepie91: when you're swinging them, sometimes the force can depress the battery holding the spring in place
<Ralith>
if you're into minecraft at all, the "vivecraft" mod for the java version is better than most made-for-VR games
<joepie91>
this also happens rarely for me, but it's annoying when you're going for a full combo..
<joepie91>
ldlework: wait wut
<ldlework>
turning the controller off for a moment
<joepie91>
.... seriously
<joepie91>
how fix
<Ralith>
ldlework: I hear a lot of complaining about that in beat saber play, yeah
<Ralith>
no known reliable fix
<ldlework>
no idea, some felt in the battery case?
<joepie91>
tougher spring?
<__monty__>
Ralith: You might be on the other end of the spectrum. Too into it to see the flaws?
<Ralith>
except soldering the batteries in place probably
<ldlework>
__monty__: do you have one?
<ldlework>
Ralith: lol
<joepie91>
Ralith: with the rate at which you need to replace batteries? fuck no lol
<joepie91>
Ralith: that thing eats batteries faster than a damn gameboy did
<Ralith>
__monty__: I mean, you can rationalize any positive report away if you want :P
<ldlework>
it's 2019 get rechargables and get them on rotation
<Ralith>
joepie91: not a serious suggestion, indeed
<joepie91>
I don't really want to desolder and resolder my battery every few days :P
<__monty__>
ldlework: No, would have to clear space. Get a new computer and invest in something.
<Ralith>
a strong enough spring would probably risk damaging the casing
<joepie91>
ldlework: Quest requires 2x2m play space, no wiring or towers required
<joepie91>
eh
<joepie91>
__monty__: ^
<joepie91>
sorry ldlework :P
<joepie91>
so if you can push furniture aside and free up 2x2m space, that's enough for it
<ashkitten>
the quest has all the components inside? how good is performance?
<Ralith>
I would favor a tethered setup over a quest if you have any patience for technology; there's a much richer ecosystem outside of the walled garden
<ldlework>
ashkitten: not as good as a PC with a 1080 will ever be, but surprisingly good
<joepie91>
ashkitten: yep. performance is great, *but* the games have (sometimes somewhat obviously) been downgraded to run smoothly on the hardware
<__monty__>
2x2 is actually a problem.
<ashkitten>
ah
<ldlework>
yep
<joepie91>
ashkitten: it's almost literally a mid-range smartphone, specs-wise :)
<ashkitten>
and it's a walled garden i assume? can't use regular pc games?
<joepie91>
sooooorta kinda
<ldlework>
well it's android
<ldlework>
so you can sideload android stuff
<joepie91>
it runs Android, sideloading can be enabled relatively trivially, but they could technically disable that
<joepie91>
the store itself is a walled garden
<ldlework>
there's also ALVR / VirtualDesktop which lets you stream VR games running on your PC to your headset
<joepie91>
there is a side-loadable thing for playing games on a SteamVR system
<joepie91>
right, that lol
<ldlework>
Which with a modern 5ghz router works surprisingly well
<ldlework>
I played some Redout
<ldlework>
:O
<ldlework>
Also Google Earth
<ldlework>
Nice thing about quest too, is the display is finally high enough resolution to make Virtual Desktop minimally usable
<ldlework>
my CV1 is just under that minimum threshold
<Ralith>
sideloading android apps is not playing regular PC games :P
<joepie91>
ashkitten: also, there are still some teething problems wrt the hardware/software; a very occasional bug in the ADC(?) that distorts the sound until you restart the unit, aforementioned controller tracking loss issue, the controller's ergonomics are pretty shit for fast-paced games and require a mod, etc.
<ldlework>
Ralith: no i was handling the "walled garden" aspect of their question at that point
<joepie91>
it's pretty Just Works but not perfectly
<joepie91>
and mirrors really fuck shit up :P
<ldlework>
you can stream your PC games though with Virtual Desktop no problem though
<joepie91>
as does bright sunlight
<joepie91>
(it's best played in a darkened room with artificial lighting, I've found)
<ldlework>
joepie91: the audio distortion restart thing is annoying heh
<ashkitten>
how well does game streaming work?
<ldlework>
way better than I expected it to
<joepie91>
ldlework: I've only had it once, was really surprised to discover that it is apparently a software issue, not hardware
<ashkitten>
over wifi, yeah?
<ldlework>
yeah
<ldlework>
i played Redout which is like the classic Wipeout hover racing game and it was working pretty well
<ldlework>
and then they improved it
<ldlework>
cut like 20ms
<ldlework>
sometimes when you're streaming VR games, there's compression.
<ashkitten>
redout is nothing like wipeout imo
<ldlework>
let me tell you, video compression looks really strange in VR
<ldlework>
:D
<ashkitten>
it's more like if you crossed f-zero with wipeout
<ldlework>
ashkitten: i mean, they're in the same genre of games.. i was just trying to relate in case you didn't know of it :)
<ashkitten>
ah, yeah. if you want an actual modern wipeout clone btw i recommend ballisticng, it's made by people that actually worked on the original wipeout games
<infinisil>
ldlework: Ohh I loved Wipeout
<ldlework>
infinisil: yeah Redout is that in VR :D
<infinisil>
Played it a whole bunch on my PSP
<ldlework>
feels crazy, doing drifts around a corner while hovering
<ldlework>
you know there's no haptics but your brain can really make you feel some motion sometimes
<ldlework>
infinisil: nice
Jackneill has quit [Remote host closed the connection]
<ldlework>
joepie91: Ralith you ever play Thumper?
<Ralith>
yep
<Ralith>
didn't finish it
<joepie91>
Thumper?
<Ralith>
it's decent for what it is, but what it is is not all that interesting
<__monty__>
Isn't PSP wipeout already pretty far from the original?
<__monty__>
Am I old?
<ldlework>
I mean, it's fairly simple, but it is also quite challenging and aesthetically and sonically pleasing..
<Ralith>
you steer with your face and interaction is shallow
<ldlework>
joepie91: yeah i've seen footage, from the documentary
<Ralith>
ldlework: last time I tried, though my GPU is pretty meh so 🤷
<joepie91>
ldlework: I recommend watching at least a good chunk throughout part 1 and 2 of that video series, they did some really cool shit merging environments and real video
<joepie91>
ldlework: if it's the documentary I think it is, they didn't show much of it :P
<Ralith>
someday I'll upgrade my GPU and get an Index HMD and give it another try
* joepie91
looks for an example of the video
<ashkitten>
speaking of hmds i wanna get a cheapish hdmi one and use it with my cosmo communicator once i have that