Fork me on GitHub
#off-topic
<
2020-01-24
>
hindol08:01:22

Since I write C# at work, cannot help but think the following. If mainstream OOP languages had a tag line, it would be, "Why write 1 line when you can do the same thing in 100 lines?".

👍 4
p-himik08:01:53

"Common sense can be abstracted away."

😂 12
mloughlin09:01:24

Don't forget to noodle around getting your generic constraints juuuuuuuuust right

hindol09:01:11

I feel enterprisey languages spend too much time making itself idiot proof. Then there's the onslaught of unwritten rules you have to Google every damn time (IDisposable for example.) Ever tried coding in a straight jacket? While it's certainly possible, it's not recommended.

mloughlin10:01:07

you're right! I'm guilty of idiot-proofing my own code but as soon as I try and use someone elses idiot-proofed code that insists on implementing 5 different interfaces I start cursing the heavens

mloughlin10:01:06

since picking up Lisp(s) I try not to get involved with type system puzzle solving any more

hindol19:01:34

Exercism is looking for maintainers. Perhaps you can help out with fleshing out the Clojure track? https://twitter.com/exercism_io/status/1215288391656448000?s=20

Alex Miller (Clojure team)19:01:26

worth a post in #announcements imo

hindol20:01:23

Posted there as well.

sveri19:01:10

Hi, I wonder how everyone stores time. My preferred way to carry time over the wire has become the ISO 8601 format. I guess it makes sense to store that with timezone in the database. Like Postgresql supports timestamp with timezone for instance. Any opinions on that?

dharrigan20:01:22

We store in UTC ISO 8601 timestamp with timezone on postgresql (the server timezone is set to UTC)

jumar09:01:00

Beware the it's often only offset that is stored in the db, not the actual timezone. This may be a problem with daylight savings and timezone changes. Especially when you're making an app for planning events in the future or similar. This is a good read: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/

sveri10:01:38

Thanks for the link. I decided to store timestamp with time zon and not utc after reading some more.

dharrigan20:01:43

DateTimeFormatter/ISO_OFFSET_DATE_TIME

valtteri20:01:32

I prefer storing timestamps always in UTC. Dealing with timezones is error prone and I want to limit those errors to the presentation layer and leave db and business logic free from that.

👍 12
jumar09:01:34

Yes, I've just linked it in another thread 🙂

paulocuneo19:01:15

my experience from fixing dates in a database: • Brasil gov decided to backdown on the DST hour change, so we got to update 2M of entries which will get invalid dates after nov 2019. • the source for the date was expressed in local time, but developer decided it would be better store them in UTC. Ghost hours can not be converted on runtime back to local time. Conclusions: • Store the data faithfull to the source. • Do convertions on runtime, don't store the converted dates • Is you're not scheduling processes represent dates as string. • Rather than writing a smart update clause, just go entry by entry by id, it will take more time, but you will know what you change in case you mess up

sveri20:01:22

@valtteri Thanks I am looking at it. Back then I used the same approach, Timestamp in utc on the server, but since I started using the ISO format everyhwere it is tempting to store it like that in the database too.

valtteri20:01:46

Also remember to have the server and JVM configured to UTC

hindol20:01:24

How about UNIX timestamps, i.e. seconds since epoch? That's timezone agnostic as well, right? I am not an expert and genuinely curious.

dharrigan21:01:50

Well, until 2038 should be okay, for epoch until then 🙂

seancorfield21:01:30

Someone at work was testing some stuff last month and entered a date twenty years in the future... and things broke... I hope to have retired from software development well before then 🙂

andy.fingerhut21:01:59

y2k38 is only 18 years plus change away! 🙂

dominicm21:01:54

2038 is already here. Take out a 20 year mortgage

😄 4
Lennart Buit21:01:00

Long to the rescue!

sveri21:01:57

I wonder if we will see the day where IPv6 is running out of adresses when all the planets in our solar system are under bot control and every nanobot has its own IP.

Lennart Buit21:01:43

You can assign an IPv6 address to each grain of sand on approximately 340 billion planets like earth according to https://skeptics.stackexchange.com/questions/4508/can-every-grain-of-sand-be-addressed-in-ipv6

👍 4
andy.fingerhut21:01:24

I'm sure IPv8 will be created with larger addresses, when it is needed. And then will take decades after that to become mainstream.

hiredman21:01:23

one can only hope by then we are finally off ip and using some kind of named data networking