Microfeatures I'd like to see in more languages

Re:Microfeatures I'd like to see in more languages by jameshart on Thursday January 05, 2023 @09:01PM (#34269992)

> Frink has special syntax for date values. You can write # 2001-08-12 # to mean the date 2001-08-12

Frink? Frink?

This Visual Basic erasure can not stand. The #-delimited date literal syntax has been found all over the VB family: Visual Basic, VBA, VBScript, and it persists to this day in Visual Basic .NET.

Of course, being a VB syntax, it's completely cursed. You can put

    # 01/05/2023 #

in a VB file, and what date it represents will depend on what locale it's.. compiled? executed? evaluated? in? Maybe? Depending on which VB dialect you're in? Good luck. Some of those languages would also accept

   # 01/05/23 #

And they might even agree about what century it's in.

[ Parent | on HN ]

Re:Microfeatures I'd like to see in more languages by carlhjerpe on Thursday January 05, 2023 @10:26PM (#34270589)

We don't have to follow locale, we could just force ISO 8601 and there won't be any ambiguity.

[ Parent | on HN ]

Re:Microfeatures I'd like to see in more languages by rwmj on Friday January 06, 2023 @03:51AM (#34272499)

Yeah, but this is Windows we're talking about. Even the SCHTASKS program (kind of like /usr/bin/at) takes a date which is locale sensitive, making it absolutely useless for scripting. Check out this answer to a question about how to use it: https://stackoverflow.com/a/18730884

[ Parent | on HN ]

Re:Microfeatures I'd like to see in more languages by carlhjerpe on Saturday January 07, 2023 @02:11PM (#34291488)

The language doesn't have to care about $PLATFORM, if the spec says dates in source are ISO 8601 they're ISO 8601 or they're invalid.

[ Parent | on HN ]

Re:Microfeatures I'd like to see in more languages by yencabulator on Sunday January 08, 2023 @06:03PM (#34304324)

I think the argument here is that VB is cursed because Windows is cursed; it inherited the bias toward cursedness. Of course other languages can choose to do better.

[ Parent | on HN ]

Re:Microfeatures I'd like to see in more languages by catach on Thursday January 05, 2023 @10:40PM (#34270681)

The cursed aspect that you mention is a mighty fine argument for why the article should indeed choose Frink as the language to steal from.

https://frinklang.org/#DateTimeHandling

[ Parent | on HN ]

Re:Microfeatures I'd like to see in more languages by hinkley on Friday January 06, 2023 @12:12AM (#34271236)

But is that December 8th or August 12?

[ Parent | on HN ]

Re:Microfeatures I'd like to see in more languages by pooper on Friday January 06, 2023 @06:11AM (#34273440)

>> Frink has special syntax for date values. You can write # 2001-08-12 # to mean the date 2001-08-12

> But is that December 8th or August 12?

I didn't even think YYYY-DD-MM is a possibility. Maybe I can grant 08/12/2022 is ambiguous and so is 08-12-2022 but can we please agree YYYY-MM-DD can't have variations?

[ Parent | on HN ]

Re:Microfeatures I'd like to see in more languages by relaxing on Friday January 06, 2023 @02:55PM (#34280066)

The first rule of timestamps is, we agree on nothing!

Reverse-middle endian YYYY-DD-MM is used in Kazakh writing (https://en.m.wikipedia.org/wiki/Date_format_by_country )

[ Parent | on HN ]

Re:Microfeatures I'd like to see in more languages by hinkley on Friday January 06, 2023 @03:33PM (#34280636)

Anyone who packs multiple values into a single string hates the world and possibly themselves.

Nowhere is it written that we must use the same field separator between the ambiguous fields. We could fix this problem by using the separators as type signifiers.

We could also stop using day <= 12 in our examples, which would also help a ton.

[ Parent | on HN ]

Re:Microfeatures I'd like to see in more languages by swyx on Friday January 06, 2023 @12:37AM (#34271396)

> what date it represents will depend on what locale it's.. compiled? executed? evaluated?

oh VB. you were so close to perfection. never change.

[ Parent | on HN ]

Re:Microfeatures I'd like to see in more languages by int_19h on Friday January 06, 2023 @02:10AM (#34271841)

A VB date literal is and always has been locale-independent. Originally, they did make the mistake of making it always US-style, M/D/Y. VB.NET added more sane formats such as YYYY-MM-DD.

Now if you tried to convert a Date value to String at runtime, yeah, that would use the current locale. That was a constant source of bugs in VB6 apps running on non-US locales (including, famously, at least one Microsoft installer).

[ Parent | on HN ]

Re:Microfeatures I'd like to see in more languages by jameshart on Friday January 06, 2023 @09:35AM (#34275006)

Are you sure? Maybe for Visual Basic proper, but I thought the VBA date literal basically followed Excel date parsing rules, so was localized depending on your office inatall.

[ Parent | on HN ]

Re:Microfeatures I'd like to see in more languages by jameshart on Friday January 06, 2023 @09:42AM (#34275096)

Apparently I'm misremembering: https://www.engram9.info/excel-2007-vba-2/date-literals.html

Still, this violates the principle of least surprise for non-american developers, at least, so seems pretty on brand for VB.

[ Parent | on HN ]

Re:Microfeatures I'd like to see in more languages by Falkon1313 on Saturday January 07, 2023 @05:25PM (#34293626)

Or you could just use the standard '2001-08-12' with no special syntax needed and avoid the problem altogether. ISO-8601 or it's invalid. There's no reason to allow other formats or need other syntaxes when we have a 35 year old standard to use.

[ Parent | on HN ]

Re:Microfeatures I'd like to see in more languages by zeedude on Saturday January 07, 2023 @07:05PM (#34294497)

There’s a Java compiler plugin, manifold, that makes this type of syntax easy. There’s an example covering the date “literal” case…

https://github.com/manifold-systems/manifold/tree/master/man...

[ Parent | on HN ]