Yes, a long time ago [0]. Depending on your needs, stack might still have advantages as the direct tool used by the developer (as it uses cabal underneath anyway).
You don't need switching to Stack (as other commenters suggest) to have isolated builds and project sandboxes etc. If you want to bootstrap a specific compiler version, a-la nvm/pyenv/opam, use GHCup with Cabal project setup: https://www.haskell.org/ghcup/
and the cyclists still don't respect pedestrians and abuse their privilege and oftentimes cut them off on pavements and zebra crossings when they feel like it.
It's a weird context for the bet. What's your point on cyclists not respecting pedestrians even though when they've got more bike lanes? I bet their attitude hasn't changed with the grown number of dedicated lanes. Are you arguing that as long as pedestrians are not being killed at the same rate, being disrespectful to them and causing danger by another kind of a higher risk vehicle is fine?
I've seen plenty of pedestrians just begging to get run over - no spatial awareness, just randomly dancing across the shared path or straying into the bike lane.
I'm paranoid though and just assume hostile intentions. I slow down to walking speed or even just stop until I'm certain they're clued in.
I've seen plenty of cyclists just begging to get run over by cars or collide with pedestrians - no spatial awareness, just randomly chosing their way, without realising they use a higher risk vehicle, and that pedestrians have a natural right to higher priority on shared use paths and in crossings, by the virtue of using the most basic and harmless means of moving in space.
Cyclists shouldn't take the pavements whatever the reason, they operate a higher risk vehicles, and spreading those risks on pedestrians who didn't chose to pick a higher risk for the purpose of moving around is exactly the disrespectul attitude I mentioned in my original comment.
Are you serious? How can you say that? Cars are, by themselves, much higher risk than bikes. If bikes are dangerous at all is because of cars. The main--heck, I'd say the only--spreaders of dangerosity are cars. In a car-free city, none of the main causes of premature death would be traffic-related.
For several years now I have commuted almost exclusively by biking and walking to & from work, and I can say that both the pedestrian and biker populations have a small but very noticeable number of idiots in them who just don't seem to care.
On one long bridge here, pedestrians and bikes have dedicated roads, on the opposites sides. I regularly see bikers use the sidewalk side, and the same with pedestrians on the biker side; neither is "fun" nor safe. I've actually been yelled at by a biker on the pedestrian side for not noticing him zipping by me... ¯\_(ツ)_/¯ Elsewhere, I regularly see people walking in the middle of the bike lane, where it's a mixed use sidewalk. The road is clearly marked, yet these people are walking there, playing chicken with each cyclist, on purpose.
The reality is that these people are a fairly small minority, but we tend to notice them. So, I wouldn't make blanket statements.
I've been told to get off the pavement by a pedestrian while on a shared path with an actual sign up right in front of us both - I pointed at it and laughed at him.
Cyclists use a higher risk vehicle, pedestrians have a natural right to higher priority on shared use paths and in crossings, by the virtue of using the most harmless means of moving in space. That means giving way to pedestrians when they need it, keeping a safe distance, and not causing dangerous situations for them. If you think otherwise, by that same token you'll have to convince all the cyclists around you that cars overtaking cyclists on shared roads, or cutting them off on turns is a fine attitude as well.
you made up a story in your head and then ran with it.
I did not do anything to put said pedestrian cunt at risk. the shared path was wide enough for 5 people, and I passed far enough away from them that I was in no danger of hitting them. I also passed them at barely over walking speed, because I always slow down when passing potentially inattentive creatures.
he, like you, assumed too much and make a fool of himself.
Why would you want a special longer syntax for something that's universally accessible by map/filter/fold in all FP languages and a growing number of imperative ones?
> And yes the lawyers are probably overly conservative, but that's because there often isn't a way to know for sure whether something is actually a violation until you end up in the courtroom.
You've outlined a justification based on a kafkaesque stockholm syndrome vibe. The system doesn't work as well as it's being advertised, does it?
No, it's a bad design that doesn't use type composition to restrict invalid representations. People are given type hints, but they still practice the same dynamic typing mistakes as before, including the authors of the lib.
Instead, it should distinguish between persisted entities and value objects:
class Entity(Generic[A]):
pk: int
val: A
class Hero:
name: str
secret_name: str
age: None | int = None
class Service(Generic[A]):
def persist(self, x: A) -> Entity[A]:
pk = self.execute(insert(x))
return Entity(pk, x)
def select(self, *cond) -> Iterable[Entity[A]]:
...
def copy(self, x: Entity[A]) -> Entity[A]:
return self.persist(x.val)
def delete(self, pk_ent: int | Entity[A]) -> A:
...
It should be obvious how the same model extends to different PK types too: serial ints, UUIDs, etc.
> Oh, you want to know the naive UTC datetime in Python, to interface with something like PostgreSQL that recommends naive times?
Postgres never recommended naive datetimes. A TZ-aware datetime is semantiacally the same as a tuple of (<location/agreed offset>, <time in the moment since unix epoch defined in terms of UTC>). Those who recommended dropping the knowledge of the first part from that pair did it because they didn't know better.
It's a perfectly fine strategy in some situations to only store UTC in the database and handle time zones on display. It's your database, you know what's in there. As an added bonus it allows easily flagging non-UTC timestamps as errors on some level to make sure you don't get tangled up in time zones.
> It's your database, you know what's in there. As an added bonus it allows easily flagging non-UTC timestamps as errors on some level to make sure you don't get tangled up in time zones.
I think you're mixing rendering (and for that matter - time ordering) with the initial information providing, that is a precise data input that doesn't rely on anything external.
Postgres ALWAYS stores timestamps in UTC [1]. When you submit data for persistence from your application, you have a choice of either:
- informing the DB about the recorded location/offset at the point of persistence (even if it's the zero offset) so that the input conversion happens without any reliance on the underlying OS-level or configuration setting [2]
- or omitting that information and therefore 1) losing precision at the point of data input and 2) delegating the location/offset inference for the internal purpose of Postgres to the external global configuration: both side-effects are bad from consistency/reliability perspectives.
I've never seen a single application that would win anything from (2) compared to explicitly providing the offset of the observed moment, even if the entire business domain is in UTC at all times. In fact, I've seen many business applications that explicitly record the offset in a separate column next to the provided timestamps for any future analysis and retrieval. And it's partly by design of the underlying abstractions: the unix epoch is defined in terms of UTC too, so when you design your program around implicit UTC you are not gaining much - the offset information is still there, it's just your data types don't make it clearly visible to everyone. But the moment you start integrating your data with the real world that cares about global time ordering of your recorded data events, you get a whole bunch of silent mistakes and issues that you won't have enough data to fix reliably until you switch to explicit offsets in all timestamp evaluations.
You're describing a world that doesn't exist from my experience writing booking systems.
Getting time zone conversions right all the way through the stack is far from trivial, which is why I prefer to do it in one place and keep the rest of the system out of it.
reply