Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

Xik: Mar 10, 2011; Dinosaur Gum

If it was truly the good timeline nuget wouldn't exist either.

# ? Mar 17, 2020 00:18

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 20:00

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

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

duck monster: Dec 15, 2004

RobertKerans posted:

Naming is hard:

http://erlang.org/pipermail/erlang-questions/2018-February/094769.html

This collection of absolute loving morons on show here is...something I guess.

(tl/dr guy who wrote the Erlang webserver Cowboy releases a package manager. It's called Coon. Mononcqc politely suggests that this a bad name. Cowboy guy plants his flag on his hill, several other fuckwits join him, someone suggests if it gets on Reddit front page any publicity would be good publicity, yadda yadda yadda)

Edit: Cowboy guy didn't release it, he just seems to be staunchest defender of the name

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

Xerxes17: Feb 17, 2011

duck monster posted:

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.

But what about coon cheese duckmonster?

# ? Mar 17, 2020 08:08

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

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

Beef: Jul 26, 2004

Coon (spelled Koen) is a perfectly valid dutch name, I have many Coon friends.

# ? Mar 17, 2020 10:18

Winter Stormer: Oct 17, 2012

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

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

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 :smith:

# ? Mar 17, 2020 16:50

Achmed Jones: Oct 16, 2004

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

DELETE CASCADE: Oct 25, 2017; i haven't washed my penis since i jerked it to a phtotograph of george w. bush in 2003

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

it also wouldn't have types

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

Achmed Jones: Oct 16, 2004

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

Spatial: Nov 15, 2007

That's true unironically. It automates adding offsets and shifts everywhere when accessing memory which is extremely handy.

# ? Mar 18, 2020 04:00

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

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

Xarn: Jun 26, 2015

NihilCredo posted:

and so is C++ (dynamic_cast and the like are functions, not language features).

huh?

# ? Mar 18, 2020 10:50

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

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

Tei: Feb 19, 2011

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

Carbon dioxide: Oct 9, 2012

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.

But language evolution is slow and people try to force it creating new languages, but that rarely works.

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

Tei: Feb 19, 2011

[dumb OOP fan post deleted here]

# ? Mar 18, 2020 12:00

Xerophyte: Mar 17, 2008; This space intentionally left blank

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

ultrafilter: Aug 23, 2007; It's okay if you have any questions.

code:

#define TEAM_PREFIX_NAME_LENGTH_4 4
#define TEAM_PREFIX_NAME_LENGTH_6 6
#define TEAM_PREFIX_NAME_LENGTH_8 8
#define TEAM_PREFIX_NAME_LENGTH_10 10
#define TEAM_PREFIX_NAME_LENGTH_12 12
#define TEAM_PREFIX_NAME_LENGTH_16 16
#define TEAM_PREFIX_NAME_LENGTH_24 24
#define TEAM_PREFIX_NAME_LENGTH_32 32
#define TEAM_PREFIX_NAME_LENGTH_64 64
#define TEAM_PREFIX_NAME_LENGTH_128 128
#define TEAM_PREFIX_NAME_LENGTH_256 256
#define TEAM_PREFIX_NAME_LENGTH_512 512

I don't know. I don't know.

# ? Mar 18, 2020 23:08

taqueso: Mar 8, 2004

I want one of those to be off-by-one,
#define TEAM_PREFIX_NAME_LENGTH_128 129

# ? Mar 18, 2020 23:14

ultrafilter: Aug 23, 2007; It's okay if you have any questions.

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

Kilson: Jan 16, 2003; I EAT LITTLE CHILDREN FOR BREAKFAST !!11!!1!!!!111!

ultrafilter posted:

code:

#define TEAM_PREFIX_NAME_LENGTH_4 4
#define TEAM_PREFIX_NAME_LENGTH_6 6
#define TEAM_PREFIX_NAME_LENGTH_8 8
#define TEAM_PREFIX_NAME_LENGTH_10 10
#define TEAM_PREFIX_NAME_LENGTH_12 12
#define TEAM_PREFIX_NAME_LENGTH_16 16
#define TEAM_PREFIX_NAME_LENGTH_24 24
#define TEAM_PREFIX_NAME_LENGTH_32 32
#define TEAM_PREFIX_NAME_LENGTH_64 64
#define TEAM_PREFIX_NAME_LENGTH_128 128
#define TEAM_PREFIX_NAME_LENGTH_256 256
#define TEAM_PREFIX_NAME_LENGTH_512 512

I don't know. I don't know.

To avoid magic numbers, shouldn't these be:
TEAM_PREFIX_NAME_LENGTH_TEAM_PREFIX_NAME_LENGTH_...

Oh no

# ? Mar 19, 2020 00:07

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

code:

#define TEAM_PREFIX_NAME_LENGTH(n) n

No worries boss, DRYed it right up.

# ? Mar 19, 2020 00:35

taqueso: Mar 8, 2004

Maybe do some tests for all of the existing values to make sure there are no discrepancies?

# ? Mar 19, 2020 06:26

Ola: Jul 19, 2004

So many small horrors in today's Microsoft environment. One that keeps puzzling me is the start menu search:

# ? Mar 19, 2020 07:55

Xarn: Jun 26, 2015

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:

struct Base {};
struct Derived : Base{};

void foo() {
    Base* bptr = nullptr;
    Derived* dptr = nullptr;
    bptr = dptr; // upcasting, always ok
    dptr = bptr; // compilation error
}

# ? Mar 19, 2020 09:37

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

pokeyman posted:

code:
#define TEAM_PREFIX_NAME_LENGTH(n) n
No worries boss, DRYed it right up.

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.

C++ code:

struct Base {};
struct Derived : Base{};

void foo() {
    Base* bptr = nullptr;
    Derived* dptr = nullptr;
    bptr = dptr; // upcasting, always ok
    dptr = bptr; // compilation error
}

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

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

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

ynohtna: Feb 16, 2007; backwoods compatible; Illegal Hen

So much UI bullshit would vanish immediately if blind/impaired usability was truly cared about. :smith:

# ? Mar 19, 2020 14:10

Volte: Oct 4, 2004; woosh woosh

Ola posted:

So many small horrors in today's Microsoft environment. One that keeps puzzling me is the start menu search:

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.

Please don't get clever with search functionality devs :sigh:

when did predictability stop being an important metric of UX?

# ? Mar 19, 2020 14:13

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

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

Volte: Oct 4, 2004; woosh woosh

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.

In this particular case I don't see why it's better than just

code:

#define TEAM_PREFIX_NAME_LENGTH 64

but the idea isn't terrible in general. The idea isn't to search for occurrences of the magic number 64, but to search for occurrences of a particular type of magic number, regardless of value. For example you could have something like

code:

#define BUFFER_SIZE(n) n

and find occurrences of that symbol to locate all the places that a buffer is being allocated, regardless of what the specific buffer size is, and on the other side, know what a particular value represents just by looking at it. In a functional programming language you might have a "BufferSize" type constructor that just wraps an int so that buffer allocation functions can't be called with magic numbers. This is kind of a similar thing in spirit, even if it doesn't actually interact with the type system.

# ? Mar 19, 2020 14:43

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

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.

Please don't get clever with search functionality devs when did predictability stop being an important metric of UX?

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

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

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

Volte: Oct 4, 2004; woosh woosh

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.

It's also a lot of effort compared to not doing that.

The easier fix is to just make sure new results come in under the old ones so they aren't constantly reflowing the results. In the event of changing constantly, your suggested fix might make it difficult to click the thing you want even if it stops you from clicking the thing you don't want.

# ? Mar 19, 2020 14:53

Dr. Stab: Sep 12, 2010; 👨🏻‍⚕️🩺🔪🙀😱🙀

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)?

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.

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

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

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

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

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

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 20:00

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

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

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »