People put up pages because they want to express themselves and/or receive views or engagement.

AI kills the first half, and trying to sell my attention kills the second half.

I don't stick around for it. I click into "the secret romantic lives of elephants", hit popup hell, then realise I really didn't care. I often can't even remember what I clicked on as soon as I hit back.

  Let’s be honest: Lisp is a language designed by and for elite hackers, not for the masses.

  Python is best for novice coders, machine learning, and versatility.  [https://www.boot.dev/blog/python/c-sharp-vs-python]

  Golang: Simpler and minimalistic language with fewer features, making it easier for beginners and experienced developers to learn and use effectively.  [https://charleswan111.medium.com/java-vs-golang-a-comparative-insight-into-usage-performance-and-industry-preferences-533a24013230]

  JavaScript is also considered to be more user-friendly and easier to learn than C++.  [https://www.c-sharpcorner.com/blogs/cpp-vs-javascript-programming]

Well, which is it? Testing a function, a class, or a module?

I didn't give my definitions of testing. I said when you go out into the OO worldview, different people will call it different things, so ignore it, it's not important. Sometimes one person will call it two or three different things. E.g. Unit testing is a function testing vs. unit testing is class testing.

Demeter: That's the thing I called wishful thinking.

Encoding desired sequence of behaviors into a type doesn't prevent errors: That's the value proposition of Choreographic programming. If it's wrong from the outset, simply disregard it.

It's led to Mockito-style testing (some people call it 'unit', others call it 'integration'). You decide that the behaviour of file.read() is that it returns a string of its contents. You judge your software correct on the basis of how it processes the returned string. Then you launch, and in the real world, the behaviour of file.read() is to return a FileHandleNotOpen exception, so you fix your code, improve your mocks to cover the opening/closing scenario, and re-release it. Next time you run it, it throws a FileNotFound exception. So you fix your code, then extend your mocks to cover that scenario too. Later still, you call read() twice in prod, and hit a FileHandleAlreadyClosed exception (apparently the first read closed the file for you). Fix the mocks again.

You wanted Mockito to lead reality, but it lags it. Rather than Mockito being a useful tool to get your prod system working well, your prod system is actually a useful tool to get your Mockito mocks working well.

Choreographic programming lets you specify this protocol in one place. "The file will be opened, the file will be read, the file will be closed, etc." Then the different parties can't guess/assume or come up with their own half of the protocol incorrectly.

  The more open source software out there the better. And the more open weights or even over source AI stuff the better too right?

Encoding your ideas into a programming language is easy. Understanding that your ideas are bad is hard.

You have clients with multiple devices connecting to your backend simultaneously, while you mediate their interactions with your partner systems. Their versions might not be up to date. It's a distributed system. When was the last time you cracked open a distributed systems textbook?

When was the last time you built a system and stared reality right in face, that is: - can't trust your clocks - pick 2/3 of CAP - exactly-once delivery impossible - the code will need to be altered and released without downtime - hackers will try to exploit you for fun and profit - your manager doesn't want you wasting time getting the above right

Coding is the easy bit.

If you wrote your standard lib in whatever was better-than-C at the time, you might have settled for sized strings (who needs strings longer than 65535 bytes?) instead of \0, and you might have had utf32 or some kind of wide char representation.

Looking at the linked URL parser, why doesn't it look like

  url = do scheme
           authority
           path
           query
           fragment
  where
  scheme = ...
  authority = ...
  etc.

All your problems start when you try to modify your current state representation in response to hearing the USER_ADDED or USER_BLOCKED events. Just don't. Leave them as events. Any time you have a new stupid edge case (double send, out-of-order, add-then-delete-then-add), this becomes one new unit test, where you can soberly decide what it means, and update your read path to understand it.

If you bake the nonsense into the current db state every time a new event arrives, your first step in any debug or reasoning scenario is to unbake it: what events led to this mess? If you don't throw away the events, your debugging is done for you.

It's like fixing all the problems with democracy by putting everyone in charge of their own 1-person election.

https://www.youtube.com/watch?v=zHiWqnTWsn4

1:00:00 - Open/closed principle and 1:13:52 - Liskov substitution principle.

Both are given in terms of Shape, but it's to paint the picture that things are more complicated than you thought, even with something that should have been as simple as shapes. (As opposed to "shapes are easy, just model the world like that and it will be easy too")

Comments URL: https://news.ycombinator.com/item?id=49171243

Points: 2

# Comments: 0

This is one of the most uncritically parroted memes in these parts.

They can't even represent Fuse's Functor example, i.e.

  f: A -> B, x: F[A]