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 »

Opinion Haver: Apr 9, 2007

pseudorandom name posted:

The could've made format strings use "yyyy", "mm", "dd" etc. instead, which would be both easy to remember and easy to read.

Minutes or months?

# ? Apr 12, 2012 01:16

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 11:21

leterip: Aug 25, 2004

pseudorandom name posted:

The could've made format strings use "yyyy", "mm", "dd" etc. instead, which would be both easy to remember and easy to read.

Why is using a bunch of different character codes that necessarily will have overlap (minutes vs months, the number of different ways of shortening a day/month) easier to read than reading a date in the format you want it to look like?

I don't see why its such a terrible idea. It feels like the backlash against it is just because it's different.

# ? Apr 12, 2012 01:17

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

Every time I use strftime or its ports in a language, I have to look the format up. I'd be happy with something that took an example format and translated it to the equivalent format.

If you're going to use placeholders no matter what, though, I see the logic in making them resemble an actual time.

# ? Apr 12, 2012 01:22

Catalyst-proof: May 11, 2011; better waste some time with you

pokeyman posted:

Every time I use strftime or its ports in a language, I have to look the format up. I'd be happy with something that took an example format and translated it to the equivalent format.

If you're going to use placeholders no matter what, though, I see the logic in making them resemble an actual time.

http://strfti.me is your friend, friend.

# ? Apr 12, 2012 01:24

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

Thanks! That gets me halfway there.

# ? Apr 12, 2012 01:33

pseudorandom name: May 6, 2007

yaoi prophet posted:

Minutes or months?

yyyy/mm/dd
HH:MM:SS

The main problem with the Go formats is they chose a completely retarded date format for the 1234567 ordering, although I guess they had to in order to avoid using 1 AD as the year.

# ? Apr 12, 2012 01:37

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Actually, that's a pretty clever idea and I like it, assuming it works for edge cases like "20060102" where there are no clear delimiters.

# ? Apr 12, 2012 02:20

Opinion Haver: Apr 9, 2007

pseudorandom name posted:

yyyy/mm/dd
HH:MM:SS

What about names for days of the week/months? What if you want to put other text in there like "He was assassinated at 4:03:23"; how do you stop that from turning into "He was a23a23inated at 4:03:23"?

# ? Apr 12, 2012 02:27

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

Fren posted:

Really? Of all the loving things to fall for NIH syndrome. Who doesn't know the strftime codes by heart? Is there some horrible flaw with strftime that I'm not aware of?

It has codes you have to know by heart or look up. For Go, all you need to know is "01/02 03:04:05PM '06 -0700" and it's self-documenting in your source code too.

# ? Apr 12, 2012 02:27

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

yaoi prophet posted:

What about names for days of the week/months? What if you want to put other text in there like "He was assassinated at 4:03:23"; how do you stop that from turning into "He was a23a23inated at 4:03:23"?

Some of their example formats:

code:

const (
    ANSIC       = "Mon Jan _2 15:04:05 2006"
    UnixDate    = "Mon Jan _2 15:04:05 MST 2006"
    RubyDate    = "Mon Jan 02 15:04:05 -0700 2006"
    RFC822      = "02 Jan 06 1504 MST"
    RFC822Z     = "02 Jan 06 1504 -0700" // RFC822 with numeric zone
    RFC850      = "Monday, 02-Jan-06 15:04:05 MST"
    RFC1123     = "Mon, 02 Jan 2006 15:04:05 MST"
    RFC1123Z    = "Mon, 02 Jan 2006 15:04:05 -0700" // RFC1123 with numeric zone
    RFC3339     = "2006-01-02T15:04:05Z07:00"
    RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00"
    Kitchen     = "3:04PM"
    // Handy time stamps.
    Stamp      = "Jan _2 15:04:05"
    StampMilli = "Jan _2 15:04:05.000"
    StampMicro = "Jan _2 15:04:05.000000"
    StampNano  = "Jan _2 15:04:05.000000000"
)

# ? Apr 12, 2012 02:28

Opinion Haver: Apr 9, 2007

BonzoESC posted:

Some of their example formats:

code:

const (
    ANSIC       = "Mon Jan _2 15:04:05 2006"
    UnixDate    = "Mon Jan _2 15:04:05 MST 2006"
    RubyDate    = "Mon Jan 02 15:04:05 -0700 2006"
    RFC822      = "02 Jan 06 1504 MST"
    RFC822Z     = "02 Jan 06 1504 -0700" // RFC822 with numeric zone
    RFC850      = "Monday, 02-Jan-06 15:04:05 MST"
    RFC1123     = "Mon, 02 Jan 2006 15:04:05 MST"
    RFC1123Z    = "Mon, 02 Jan 2006 15:04:05 -0700" // RFC1123 with numeric zone
    RFC3339     = "2006-01-02T15:04:05Z07:00"
    RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00"
    Kitchen     = "3:04PM"
    // Handy time stamps.
    Stamp      = "Jan _2 15:04:05"
    StampMilli = "Jan _2 15:04:05.000"
    StampMicro = "Jan _2 15:04:05.000000"
    StampNano  = "Jan _2 15:04:05.000000000"
)

Sure, I believe that Go's thing can parse it. I just don't think you can extend YYYY/MM/DD hh:mm:ss to cover it.

# ? Apr 12, 2012 02:30

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Suspicious Dish posted:

They're considering adding a promise/Deferred to the standard library instead of using continuation passing, which should help things a bit. Unfortunately, you can't emulate inlineCallbacks.

Event loops aren't that big a deal when debugging, you just have to learn to deal with asynchronous programming.

There are two major problems with node.js in my opinion: 1) that JavaScript has no facilities for asynchronous programming outside of continuation passing (if you use Mozilla JS, they have generator, which means that you can implement a simple trampoline). And 2) this may have changed considerably since 2010, but when I last tried to implement an application in node I felt like I was catching up with very rapid stdlib changes. I was handling multipart uploads, and twice in 2-3 months _ry decided that the multipart form API wasn't good enough, and rewrote it from scratch.

I don't think _ry ever wrote anything based on node.js in that timeframe that was in production. This goes back to my belief that when you're not working in the trenches of your own platform every day, you cannot possibly know what the best addition to your own platform is.

And that's why C# is adding async/await. Let the compiler turn your code inside out later.

# ? Apr 12, 2012 04:30

pseudorandom name: May 6, 2007

yaoi prophet posted:

What about names for days of the week/months? What if you want to put other text in there like "He was assassinated at 4:03:23"; how do you stop that from turning into "He was a23a23inated at 4:03:23"?

"Day" → "Wed"
"Fullday" → "Wednesday"
"Mon" → "Apr"
"Month" → April

And Go's format has the same collision problem with its own magic character sequences.

# ? Apr 12, 2012 04:44

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

pseudorandom name posted:

"Day" → "Wed"
"Fullday" → "Wednesday"
"Mon" → "Apr"
"Month" → April

And Go's format has the same collision problem with its own magic character sequences.

So don't use the time formatter as sprintf.

- Steve

# ? Apr 12, 2012 04:47

Catalyst-proof: May 11, 2011; better waste some time with you

What about with other natural languages? Can I replace Monday with понедельник and have it work?

# ? Apr 12, 2012 05:12

pseudorandom name: May 6, 2007

Nope, nor is the result of time.Format localized.

# ? Apr 12, 2012 05:18

Opinion Haver: Apr 9, 2007

I'm not advocating for Go's format, I'm advocating for strftime. It'd be neat to build a strftime format generator that works on Go's algorithm, though.

# ? Apr 12, 2012 05:36

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Ender.uNF posted:

And that's why C# is adding async/await. Let the compiler turn your code inside out later.

Note that the latest working draft for ES.next includes dummy syntax for generators, but says that semantics of what it means aren't in the current draft. They also have a reference to a YieldExpression under 11.13, but don't provide a definition.

But at least that with these primitives, you can build a simple trampoline.

code:

function sleep(ms) {
    return function(callback) {
        setTimeout(callback, ms);
    });
}

function step(g) {
    try {
        let func = g.next();
        func(step.bind(null, g));
    } catch (e if e instanceof StopIteration) {
        /* just leave normally */
    }
    /* Raise every other exception normally. */
}


function main() {
    yield sleep(1000);
    print("Look ma, no blocking the mainloop!");
    yield sleep(2000);
    print("Wee! Trampoline!");
}

step(main());

Collecting results is a bit more complicated (uses Generator.prototype.send). I've been considering taking a Deferred implementation from MochiKit/Dojo/Closure and integrating it with a trampoline line this.

# ? Apr 12, 2012 05:36

The Gripper: Sep 14, 2004; i am winner

Lonely Wolf posted:

yeah, those format by example strings shook me the first time I saw them and I have to check the docs to write them but they do have the nice property that if I see

t.Format("2006-01-02")

in some code it's far more obvious what that will look like than the usual strftime format strings that I have to look up to read and write. v:(v

leterip posted:

I don't see why its such a terrible idea. It feels like the backlash against it is just because it's different.

If you look at code with a datetime format string from any other language you immediately know "hey, that's the format of a datetime".

With this, it looks like the date and time are significant rather than the format of the date and time, it's confusing to anyone new to Go and to anyone just skimming code it's easy to get mixed up. Consider: http://play.golang.org/p/Vkbx2djlF5

I wouldn't hesitate to say most people would expect t.Format("2006-01-02") to be doing something with the date 2006-01-02, not creating a datetime format string from it.

# ? Apr 12, 2012 09:24

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

The Gripper posted:

I wouldn't hesitate to say most people would expect t.Format("2006-01-02") to be doing something with the date 2006-01-02, not creating a datetime format string from it.

I agree, it seems like a good idea but they should have called it something like "FormatByExample" instead of just "Format".

# ? Apr 12, 2012 09:31

leterip: Aug 25, 2004

The Gripper posted:

If you look at code with a datetime format string from any other language you immediately know "hey, that's the format of a datetime".

With this, it looks like the date and time are significant rather than the format of the date and time, it's confusing to anyone new to Go and to anyone just skimming code it's easy to get mixed up. Consider: http://play.golang.org/p/Vkbx2djlF5

I wouldn't hesitate to say most people would expect t.Format("2006-01-02") to be doing something with the date 2006-01-02, not creating a datetime format string from it.

So your argument is that because it's different people might be confused by it? There's only one way to format dates in Go with the standard library, so if you're familiar with Go that's a non-issue. Imagine if Go was the standard way and they came out with strftime. You could make the same argument the other direction.

# ? Apr 12, 2012 11:29

The Gripper: Sep 14, 2004; i am winner

leterip posted:

So your argument is that because it's different people might be confused by it? There's only one way to format dates in Go with the standard library, so if you're familiar with Go that's a non-issue. Imagine if Go was the standard way and they came out with strftime. You could make the same argument the other direction.

My argument is that using an actual date/time as a format string is confusing, because everywhere else (and I mean everywhere, not just in Go) a written date or time means "this date or time" not "any date that fits this format". Using HH:nn:ss also has the benefit of differentiating a format string from a date or time; in Go the meaning of "12:34:56 2006-01-01" different (literal datetime or datetime format string) depending on where it is used.

Edit; it's a novel idea and simplifies creating format strings, but in practice it is confusing (hang around in the #go-nuts irc channel and see how often people come in confused about this exact thing).

Also I wasn't arguing that it's confusing because it's different to strftime, just that when I see a date I expect the interesting part to be the date, not the formatting of it's elements.
(and since it wasn't mentioned, the format strings can't be just any date/time, they have to be a datetime constructed from it's formatting rules e.g. rather than remembering that %H is hour in 24-hour time, you have to remember "15" has that meaning. I can't find a page that actually lists the meaning of each set of digits, but off the top of my head 15 = 24hr hour, 04=minutes, 03=seconds, 2006=year, 01=month, 02=day. This instead of %H, %M, %s, %y, where mistakes are immediately obvious).

It's really just a bad, confusing system.

The Gripper fucked around with this message at 13:43 on Apr 12, 2012

# ? Apr 12, 2012 13:03

leterip: Aug 25, 2004

The Gripper posted:

My argument is that using an actual date/time as a format string is confusing, because everywhere else (and I mean everywhere, not just in Go) a written date or time means "this date or time" not "any date that fits this format". Using HH:nn:ss also has the benefit of differentiating a format string from a date or time; in Go the meaning of "12:34:56 2006-01-01" different (literal datetime or datetime format string) depending on where it is used.

"12:34:56 2006-01-01" doesn't have a different meaning. That is just a string that specifies a date. It isn't a valid formatting string, and that was easy to see by inspection.

To not be pedantic, the only time the context changes is when it is used in a specific method of a specific type. It's not like format strings are littered throughout code confusing people as to if they are specifying a date or not. There are literally two functions that accept a layout and in both cases it is clear from the local context that it is a format string, if not just by the calling method, but by the fact that it is specifying a specific date/time that if you are familiar with Go is clearly a format time.

The Gripper posted:

Edit; it's a novel idea and simplifies creating format strings, but in practice it is confusing (hang around in the #go-nuts irc channel and see how often people come in confused about this exact thing).

But how many of those questions are because someone confused the format string with a date string in the code, as you suggest is the problem? From looking at my logs, it seems most were confused by the system because it was new to them. I don't think a single person has mixed up the meaning in the way you describe.

The Gripper posted:

Also I wasn't arguing that it's confusing because it's different to strftime, just that when I see a date I expect the interesting part to be the date, not the formatting of it's elements.
(and since it wasn't mentioned, the format strings can't be just any date/time, they have to be a datetime constructed from it's formatting rules e.g. rather than remembering that %H is hour in 24-hour time, you have to remember "15" has that meaning. I can't find a page that actually lists the meaning of each set of digits, but off the top of my head 15 = 24hr hour, 04=minutes, 03=seconds, 2006=year, 01=month, 02=day. This instead of %H, %M, %s, %y, where mistakes are immediately obvious).

It's really just a bad, confusing system.

Indeed, it is just another way to write a formatting system, except instead of having to remember what %H means because some programmer decided it, you can derive what the 24-hour time format code is by remembering what date they used, which was chosen to be trivial to remember. It is just a very simple and logical method of creating a timestamp format specification. Isn't that amazing that you could define what those were off the top of your head with minimal exposure?

# ? Apr 12, 2012 15:11

The Gripper: Sep 14, 2004; i am winner

leterip posted:

Isn't that amazing that you could define what those were off the top of your head with minimal exposure?

I honestly couldn't tell you which digits represent minutes and seconds, and the same with which digits represent days and which represent months. I could have them backwards, I just guessed at their order. Compared to strftime where mixing up %M and %s is obvious, mixing up 03 and 04 in go is not.

quote:

But how many of those questions are because someone confused the format string with a date string in the code, as you suggest is the problem?

There have been numerous that have mistaken the use of Format() and related methods, maybe not mistaking the format string with date in the code, but definitely mistaking the required parameter as being "a date" rather than "a format string".

Honestly it tries to solve a problem ("time format strings are confusing") and instead makes a carbon copy of the problem with more confusing element names (digits instead of %X). It's a net negative for the developer (you still need to know the substitutions as you would with strftime, however they no longer have a letter attached that gives it meaning) and there's marginal benefit to an observer (you can see what the result will look like immediately).

I prefer strftime formats over Go's implementation because it is better, not because I'm opposed to positive change.

# ? Apr 12, 2012 15:34

leterip: Aug 25, 2004

The Gripper posted:

I honestly couldn't tell you which digits represent minutes and seconds, and the same with which digits represent days and which represent months. I could have them backwards, I just guessed at their order. Compared to strftime where mixing up %M and %s is obvious, mixing up 03 and 04 in go is not.

%m vs %M

The Gripper posted:

There have been numerous that have mistaken the use of Format() and related methods, maybe not mistaking the format string with date in the code, but definitely mistaking the required parameter as being "a date" rather than "a format string".

So because they were unfamiliar with this different system they had an issue with how the format was specified. Once they learned about how the system worked, there were no more problems. There could be an argument for better documentation on the methods that take a layout, but that's not a problem with the system.

The Gripper posted:

Honestly it tries to solve a problem ("time format strings are confusing") and instead makes a carbon copy of the problem with more confusing element names (digits instead of %X). It's a net negative for the developer (you still need to know the substitutions as you would with strftime, however they no longer have a letter attached that gives it meaning) and there's marginal benefit to an observer (you can see what the result will look like immediately).

I prefer strftime formats over Go's implementation because it is better, not because I'm opposed to positive change.

Code is read a lot more than it is written. Being able to see exactly what the output format will look like is a huge win. You're right you still have to know how to format strings. There is no formatting specification that would remove that need. The point in that instead of having to memorize how strftime works or go look it up, you can just derive it because it is totally logical with no arbitrary decisions in what letters or capitalization means what. There are actual technical problems with this format (you cant easily get the week number, or the numeric day of the week, cross language specifications, but strftime loses it's ease of remembering there), but I don't think it being confusing is one of them.

# ? Apr 12, 2012 15:45

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

leterip posted:

Code is read a lot more than it is written. Being able to see exactly what the output format will look like is a huge win.

Quick! Is "02/01/06" DMY or MDY?

# ? Apr 12, 2012 16:02

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

leterip posted:

%m vs %M

...you can just derive it because it is totally logical with no arbitrary decisions.

01/02/2006 vs 02/01/2006
"Wait is it day-month-year because it'd make sense numerically or is it month-day-year because it's made by Americans who somehow believe their system is the most intuitive?"

edit: bah

# ? Apr 12, 2012 16:04

The Gripper: Sep 14, 2004; i am winner

leterip posted:

Being able to see exactly what the output format will look like is a huge win. You're right you still have to know how to format strings. There is no formatting specification that would remove that need. The point in that instead of having to memorize how strftime works or go look it up, you can just derive it because it is totally logical with no arbitrary decisions in what letters or capitalization means what.

It's more of a problem when you have a format string without regular dividers, something like "%H%M" in strftime or "0304" in Go, or a format string where you don't know how the date is ordered (y-m-d or y-d-m?). Any of the regular formats you can easily tell just by the dividers or order (hh:mm:ss etc.).

I don't think this is a argument either of us can win, so let's agree that we both like different things!

# ? Apr 12, 2012 16:10

biznatchio: Mar 31, 2001; Buglord

Ender.uNF posted:

And that's why C# is adding async/await. Let the compiler turn your code inside out later.

There's TameJS for node that gives you the same concept for doing inline callbacks with a slightly altered syntax design. I haven't used it myself so I can't vouch for quality, but OkCupid is using it in production, so it must be decently stable.

# ? Apr 12, 2012 16:38

Brecht: Nov 7, 2009

Janin posted:

http://golang.org/pkg/time/

Are you kidding? That's awesome and elegant.
edit: oops, missed a page of jabber

Brecht fucked around with this message at 18:33 on Apr 12, 2012

# ? Apr 12, 2012 18:31

Strong Sauce: Jul 2, 2003; You know I am not really your father.

https://bugs.php.net/bug.php?id=54547

With rasmus reply!

# ? Apr 12, 2012 20:20

tef: May 30, 2004; -> some l-system crap ->

Well php users can't count that far on their hands so why would their scripts ever need to?

# ? Apr 12, 2012 20:26

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Apparently all database columns are varchar too. That sure explains a lot of the MySQL databases I see. Foreign keys? Pfffffft, that's for losers.

# ? Apr 12, 2012 22:44

Huragok: Sep 14, 2011

Ender.uNF posted:

Apparently all database columns are varchar too.

Wait, all textual columns are varchar, or all columns are varchar?

# ? Apr 13, 2012 04:30

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Huragok posted:

Wait, all textual columns are varchar, or all columns are varchar?

All. That's the only explanation I can think of for why auto-converting all string comparisons to numbers "makes things easier" when working with a database. My naive approach would be to store numbers in the database and convert the request parameter to a number explicitly, thus performing a basic sanity check against a random value submitted from an anonymous internet user, but then again I'm not a PHP developer.

# ? Apr 13, 2012 07:13

geonetix: Mar 6, 2011

Ender.uNF posted:

All. That's the only explanation I can think of for why auto-converting all string comparisons to numbers "makes things easier" when working with a database. My naive approach would be to store numbers in the database and convert the request parameter to a number explicitly, thus performing a basic sanity check against a random value submitted from an anonymous internet user, but then again I'm not a PHP developer.

The mysql lib returns values as strings for all columns, but stores them correct internally. It requires extra queries to find out what type a column actually is (or storing them in your application somehow) for properly casting the values to their right types.

That is still not an excuse to do type-mangling the way PHP does, but at least they're correct about MySQL's behaviour.

# ? Apr 13, 2012 07:40

Strong Sauce: Jul 2, 2003; You know I am not really your father.

Yeah not sure why you assumed PHP forced some kind of weird internal MySQL representation, but you can create tables with ints, varchars, text, dates just like normal, it just pulls them out as strings since the reasoning is you're just going to output them to HTML.

# ? Apr 13, 2012 08:35

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

I was making a joke about people who just create varchar columns for everything because I (wrongly) assumed the mySQL API couldn't be that stupid.

Then I made a joke about the "naive" approach because even an entry-level programmer should know that you should both perform sanity checks and validity checks on *anything* sent to you, especially when it comes from the web.

My attempt at humor has been outfoxed by awful open source software yet again.

# ? Apr 13, 2012 20:57

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Well, without a custom boxing system (I shudder at the thought of mysql_val_t), I can't see how a library could do better.

In fact, it seems sane to send number types over the wire as strings in case the application language's type system and the library language's type system don't correlate 1:1. For instance, Python's integer type has no upper limit, and if they sent BIGINTs as 32-bit integers over the wire, then you'd lose a bit of data. And even if they sent a custom variable-length byte representation like protocol buffers, it's still technically strings :cobert:.

Postgres does the same thing as well. It looks like a WTF at first, until you realize the decision here.

# ? Apr 13, 2012 22:33

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 11:21

Malloc Voidstar: May 7, 2007; Fuck the cowboys. Unf. Fuck em hard.

Oracle PL/SQL:

code:

declare
    x varchar2(1);
begin
    x := '';
    if x = '' then
       dbms_output.put_line('PL/SQL does not suck');
    else
       dbms_output.put_line('PL/SQL sucks');
    end if;
end;

> PL/SQL sucks

# ? Apr 14, 2012 00:51

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 »