|
If it was truly the good timeline nuget wouldn't exist either.
|
# ? Mar 17, 2020 00:18 |
|
|
# ? May 30, 2024 14:20 |
|
npm itself is basically fine these days. They fixed the awful performance, added package deduplication, and fixed the broken version pinning. The remaining issues are mostly JS ecosystem things rather than problems with the tool.
|
# ? Mar 17, 2020 02:32 |
|
RobertKerans posted:Naming is hard: The idea that its just a north american slur is flat out wrong. Since we dont have racoons in australia the *only* context of that word here is a racial slur thats considered considerably worse than the N word. You start using that word in public, someones going to break your jaw. Programmers are the worst goddamn people sometimes.
|
# ? Mar 17, 2020 07:34 |
|
duck monster posted:The idea that its just a north american slur is flat out wrong. But what about coon cheese duckmonster?
|
# ? Mar 17, 2020 08:08 |
|
leper khan posted:GitHub is Microsoft right, so npm is Microsoft? Yeah it can only be a good thing I reckon. With .NET Core over the last few years Microsoft has really proven themselves capable of delivering really solid tooling.
|
# ? Mar 17, 2020 08:09 |
|
Coon (spelled Koen) is a perfectly valid dutch name, I have many Coon friends.
|
# ? Mar 17, 2020 10:18 |
|
Beef posted:Coon (spelled Koen) is a perfectly valid dutch name, I have many Coon friends. Cool, good job Anyhow, the author wound up changing the name of the package to "enot" (Russian for raccoon) and it sank into obscurity shortly thereafter.
|
# ? Mar 17, 2020 12:59 |
|
Winter Stormer posted:Anyhow, the author wound up changing the name of the package to "enot" (Russian for raccoon) and it sank into obscurity shortly thereafter. Should have picked badger
|
# ? Mar 17, 2020 16:50 |
|
The cowboy guy called it cowboy because "cowboys kill apaches." There is no reason to expect anything but absolute poo poo takes from him
|
# ? Mar 17, 2020 18:40 |
|
redleader posted:if c was meant to be a portable assembly, then c compilers wouldn't do any optimising, since assemblers don't do any optimising as far as i'm concerned, C doesn't have types. it has things that look like types, but really they are just instructions to the compiler on how much memory to allocate. they don't otherwise resemble an actual type system
|
# ? Mar 17, 2020 23:40 |
|
DELETE CASCADE posted:as far as i'm concerned, C doesn't have types. it has things that look like types, but really they are just instructions to the compiler on how much memory to allocate. they don't otherwise resemble an actual type system
|
# ? Mar 18, 2020 00:07 |
|
That's true unironically. It automates adding offsets and shifts everywhere when accessing memory which is extremely handy.
|
# ? Mar 18, 2020 04:00 |
|
DELETE CASCADE posted:as far as i'm concerned, C doesn't have types. it has things that look like types, but really they are just instructions to the compiler on how much memory to allocate. they don't otherwise resemble an actual type system I've used the following definitions forever and I find them extremely useful and clear and I was surprised to learn they were not an agreed-upon definition: Static vs dynamic typing: are types checked at compile time? If I assign a Foo value to a Bar variable, will I get a compile error? Strong vs. weak typing: are types checked at runtime? If I assign a Foo variable to a Bar value, and assuming I managed to compile and start the program (either by using a dynamically-typed language, or by using an explicit unsafe cast in a statically typed one), will I get some kind of exception, or will it just happily run with it until something bad happens down the line (e.g. segfault, or just a number silently becoming truncated / rolled over / etc.). Most high-level languages are strongly typed, whether statically (C#) or dynamically (Python). Most low-level languages like ASM or Forth are dynamically and weakly typed. C is a statically- and weakly-typed language. So is C++; dynamic_cast and the like allow you to perform a runtime type check, but you need to manually invoke them in your code, they're not embedded in the runtime. So is Rust; it has much more extensive static type checks, but inside an unsafe { } block you can e.g. invoke mem::transmute that will happily alias a bunch of bits like you're writing K&R C in 1979. NihilCredo fucked around with this message at 12:25 on Mar 18, 2020 |
# ? Mar 18, 2020 10:18 |
|
NihilCredo posted:and so is C++ (dynamic_cast and the like are functions, not language features). huh?
|
# ? Mar 18, 2020 10:50 |
|
Xarn posted:huh? I mean that if you don't explicitly call dynamic_cast in your code, it won't perform the runtime type check.
|
# ? Mar 18, 2020 10:57 |
|
I hope in the future languages evolve to make static analysis easier, so bugs are found and fixed even before you compile your code. But language evolution is slow and people try to force it creating new languages, but that rarely works.
|
# ? Mar 18, 2020 11:55 |
|
Tei posted:I hope in the future languages evolve to make static analysis easier, so bugs are found and fixed even before you compile your code. Functional languages with a strong type system are basically this. Of course they can't prevent all bugs but they do prevent you from making mistakes that are easy to make in an imperative language with dynamic typing.
|
# ? Mar 18, 2020 11:57 |
|
[dumb OOP fan post deleted here]
|
# ? Mar 18, 2020 12:00 |
|
A sufficiently advanced type system can let you statically prove, well, anything decidable about your code. It's just that at some point correctly specifying your type transforms becomes at least as hard as correctly writing the program. Haskell-style monadic encapsulation of state is already more strict type checking than I think most programmers are willing to deal with and tends to trigger a lot of shouting "but obviously I meant [x] you jerk" at GHC as is. As type complexity increases you'll also start introducing bugs in your type properties that can cause your buggy code to compile. At least you have to make the same mistake twice, but it's not foolproof. There's nothing about formal correctness that's incompatible with OOP either -- not that anyone was actually saying that. One of the theorem provers I've tried was for java. You would define formal class invariants and prove that they held after any invocation of the class API, that sort of thing. It's just that if you know your corner cases well enough to formally specify them and prove your code correct then you know them well enough to write some tests for them (or do the quickcheck thing and autogenerate tests that validate the invariants) in about a tenth the time. In conclusion, type systems are a land of contrasts.
|
# ? Mar 18, 2020 14:40 |
|
code:
|
# ? Mar 18, 2020 23:08 |
|
I want one of those to be off-by-one, #define TEAM_PREFIX_NAME_LENGTH_128 129
|
# ? Mar 18, 2020 23:14 |
|
After investigation, it looks like someone took the prohibition against magic numbers a little too far. Apparently they thought that char keyName[64]; was much worse than char keyName[TEAM_PREFIX_NAME_LENGTH_64];. I want a drink.
|
# ? Mar 18, 2020 23:27 |
|
ultrafilter posted:
To avoid magic numbers, shouldn't these be: TEAM_PREFIX_NAME_LENGTH_TEAM_PREFIX_NAME_LENGTH_... Oh no
|
# ? Mar 19, 2020 00:07 |
|
code:
|
# ? Mar 19, 2020 00:35 |
|
Maybe do some tests for all of the existing values to make sure there are no discrepancies?
|
# ? Mar 19, 2020 06:26 |
|
So many small horrors in today's Microsoft environment. One that keeps puzzling me is the start menu search:
|
# ? Mar 19, 2020 07:55 |
|
NihilCredo posted:I mean that if you don't explicitly call dynamic_cast in your code, it won't perform the runtime type check. Without a cast, you cannot downcast at all though. C++ code:
|
# ? Mar 19, 2020 09:37 |
|
pokeyman posted:
This is unironically cool & good though, you're effectively tagging the magic number with a searchable label. Xarn posted:Without a cast, you cannot downcast at all though. Yes, that's a compile-time check though, not a runtime check. If you cast to void* and back, you should get your bits aliased without any runtime cast errors until you try to actually use the cat as if it were a dog and everything explodes, right?
|
# ? Mar 19, 2020 11:57 |
|
Ola posted:So many small horrors in today's Microsoft environment. One that keeps puzzling me is the start menu search: I've seen that sort of thing as well. Is it because they are using a machine learning approach, rather than just doing the obvious thing (matching prefixes of names and keywords)? The most annoying thing to me about the Windows start menu search is how if you type something in, it thinks about it for a moment after each character typed before changing the options it displays - and it very often changes the options in response to the final typed character just as you've decided to click on an item. So you end up clicking on something that isn't what you wanted. The phenomenon of "I clicked on something, but it isn't what I intended to click on because the computer changed what it was displaying after I had made the decision to click but before I had actually executed the physical motion of clicking" is one that irks me a lot in dealing with GUIs. All of the GUI systems we have come up with are based on the simplifying assumption that if a mouse click occurred over some UI element, then that's what the user intended to click on - even if it's been there for less than a human being's reaction time. It's a very widespread failing of design, although I'm not sure how a system that deals with the phenomenon properly might work.
|
# ? Mar 19, 2020 13:52 |
|
So much UI bullshit would vanish immediately if blind/impaired usability was truly cared about.
|
# ? Mar 19, 2020 14:10 |
|
Ola posted:So many small horrors in today's Microsoft environment. One that keeps puzzling me is the start menu search: Please don't get clever with search functionality devs when did predictability stop being an important metric of UX?
|
# ? Mar 19, 2020 14:13 |
|
NihilCredo posted:This is unironically cool & good though, you're effectively tagging the magic number with a searchable label. I'm going to need you to explain this one, because this seems just as searchable as [^\d]64[^\d] and just as useful.
|
# ? Mar 19, 2020 14:27 |
|
Volmarias posted:I'm going to need you to explain this one, because this seems just as searchable as [^\d]64[^\d] and just as useful. code:
code:
|
# ? Mar 19, 2020 14:43 |
|
Volte posted:I've had this happen while trying to open VLC where if I type "VL" the autocomplete is "VLC" and if I type "VLC" the autocomplete is "VLC (delete all user preferences)" or something like that. It's not unique to Windows either as I've had macOS Spotlight do a similar thing. Another infuriating behaviour is on my Pixel phone where you can search for an app from the home screen and get 2-3 immediate results, and then 1-2 seconds later more results come in and shuffle around the initial ones, usually just as your finger is about to push one of them. Trying to open the YouTube app and accidentally opening YouTube VR like 5 times in a row because it popped in at the last millisecond is probably the worst thing that has ever happened. I'm glad I'm not the only one who cares about this Volmarias posted:I'm going to need you to explain this one, because this seems just as searchable as [^\d]64[^\d] and just as useful. If you use that constant wherever the number 64 is being used in that specific capacity, as opposed to being used in some other capacity, then I guess it lets you search more specifically for that. Like if you search for TEAM_PREFIX_NAME_LENGTH_64 then you don't get any results for TEAM_MAXIMUM_DILDO_COLLECTION_SIZE_64 or w/e even though they're both 64
|
# ? Mar 19, 2020 14:46 |
|
Hammerite posted:The phenomenon of "I clicked on something, but it isn't what I intended to click on because the computer changed what it was displaying after I had made the decision to click but before I had actually executed the physical motion of clicking" is one that irks me a lot in dealing with GUIs. All of the GUI systems we have come up with are based on the simplifying assumption that if a mouse click occurred over some UI element, then that's what the user intended to click on - even if it's been there for less than a human being's reaction time. It's a very widespread failing of design, although I'm not sure how a system that deals with the phenomenon properly might work. This is fixable. You can do things like ignore clicks if the UI changed such that the point underneath the cursor was something different a moment ago. It's also a lot of effort compared to not doing that.
|
# ? Mar 19, 2020 14:50 |
|
Jabor posted:This is fixable. You can do things like ignore clicks if the UI changed such that the point underneath the cursor was something different a moment ago.
|
# ? Mar 19, 2020 14:53 |
|
Hammerite posted:I've seen that sort of thing as well. Is it because they are using a machine learning approach, rather than just doing the obvious thing (matching prefixes of names and keywords)? My thinking would be to lock out clicks on an element until the element has been on screen in that location for an appropriate length of time (100ms or so). This should apply everywhere a list is dynamically populated.
|
# ? Mar 19, 2020 14:55 |
|
Jabor posted:This is fixable. You can do things like ignore clicks if the UI changed such that the point underneath the cursor was something different a moment ago. Are you saying here that this has been implemented and I'm not aware of it? At the OS level (which OSes?), or at the application level? Or just observing that in principle, this is something you could do? because I am aware of that. quote:It's also a lot of effort compared to not doing that. Yes. Worthwhile effort, IMO. If you don't want to go to the trouble, though, it can be mitigated by not creating a UI that contains elements that change or jump around unpredictably while the user might be trying to interact with them!
|
# ? Mar 19, 2020 14:57 |
|
Dr. Stab posted:My thinking would be to lock out clicks on an element until the element has been on screen in that location for an appropriate length of time (100ms or so). This should apply everywhere a list is dynamically populated. That's a good start, but it has the problem that it could frustrate a user who has faster than normal reaction times and did actually intend to click on the thing - and sees their click have no effect. It's also possible that a user who is well-used to a particular workflow within your UI would begin to anticipate when something is going to appear and achieve clicks on that thing at faster than normal reaction time. That user would also be frustrated. I think at minimum, there would have to be some visual indication of when the thing is actually ready to receive clicks.
|
# ? Mar 19, 2020 15:02 |
|
|
# ? May 30, 2024 14:20 |
|
Hammerite posted:Are you saying here that this has been implemented and I'm not aware of it? At the OS level (which OSes?), or at the application level? Or just observing that in principle, this is something you could do? because I am aware of that. It's something that HCI folks have been ragging on forever, but I'm not aware of it being done for you in a commonly-used framework or anything. In our UI designs we mostly try to avoid reflowing existing content like that - but when it's inevitable, we have an appearance animation and clicks get ignored during that animation.
|
# ? Mar 19, 2020 15:03 |