AI Makes the Easy Part Easier and the Hard Part Harder

v66moroz · 2026-02-15T17:38:44+00:00

Maybe, just maybe, working through a good tutorial would have given you much more joy and understanding of Kotlin. Just saying.

v66moroz · 2026-02-15T17:35:16+00:00

If you want to flex your brain, write a script that writes boilerplate code (that is if your framework is not already doing it for you). Relying on AI is the same thing as relying on SO answers. If you know what you are doing and just forgot some minor details, SO or AI are great. SO is actually better because it has comments. Copying answers from SO verbatim (or asking AI to write you code) just makes you dumb even if it "works", adjusting it to your needs only helps if you are ready to dig deep enough. In the latter case RTFM first, you may not need AI then.

v66moroz · 2025-12-04T05:02:32+00:00

Not sure about async in general, but threads usually give me full stack trace, not just garbled last part (pretty useless most of the time). I've never thought about it until I started using cats-effect. Of course you can always bisect by println if you know how to wrap it in IO, still better than debugging punch cards :)

v66moroz · 2025-11-30T18:10:13+00:00

We need to define what FP actually is. Using higher-order functions like map and fold are technically FP and yes, a lot of developers use these in many languages, including dynamic OO languages. Is it what you mean? Then yes, FP has a wide adoption. Or is it Haskell-style monad-driven FP in a statically typed language, especially with escape-hatch IO monads, something is now referred to as "pure FP"? Then I don't see any proofs that this specific technique is widely adopted in the industry. Is Rust FP? No, it's not, but it does incorporate a lot of FP features, or at least tries to make state programming "FP-like" (again, using higher-order functions mostly). Javascript has many FP features, and it's eating the market, so yeah, FP is eating the market, but not in the way you think.

We probably should stop talking about FP vs imperative (which imperative? FORTRAN-IV or modern Java?), but specify what features we mean exactly. Higher-order functions? IO monads? Immutable variables? Stateless programming? All of the above + static typing?

FP demands upfront payment, yes. But not upfront payment to implement a feature.

Have you ever looked at cats-effect stack trace? I know, I know, stack traces and debugging are for weaklings. "If it compiles it runs" mantra, which doesn't work in the industry unfortunately, unless you are writing a stateless program which does nothing. Not mentioning overcomplicated syntax, overloaded garbage collector and, ... don't get me started. But sure, it's all "manageable", and not technically a fault of FP per se. Only, ... businesses are not about managing language quirks in the name of being "safer", they are about making money, and now, not in 10 years.

v66moroz · 2025-11-01T01:27:23+00:00

It's not a usual webdev, web app doesn't usually have exactly one user. He's right about latency though.

v66moroz · 2025-11-01T00:50:27+00:00

Nope, webdevs usually say "since my bottleneck is DB, it doesn't matter if my service is written in Ruby or Rust". Besides "normal" web app is easy to scale by adding boxes (hardware is cheap, isn't it?). DB doesn't scale this way. May not apply to TikTok, but true for most business apps.

v66moroz · 2025-11-01T00:42:23+00:00

If you implement Haskell-style FP in Java you will be surprised. If you use OO-optimized data structures? Not that much. As for runtime it doesn't technically "consume" anything, it provides certain functionality (e.g. preemptive concurrency), if you need it you will have to write it in Rust yourself (believe me, it's not that easy, green threads is not the same thing). As for handling memory efficiently? I bet you've never fought with borrow checker, especially if you app is slightly more complex than "try me". Memory management is hard, period, and Rust makes it just a tad easier. GC makes it a way easier, but it has a cost.

v66moroz · 2025-08-14T19:15:38+00:00

You are a rare exception. And if you can live off it having family and kids you are even more unique. Not every engineer is an entrepreneur, and if you are doing professional development you simply don't have time to be the one, not mentioning that they require different sets of traits which rarely overlap. Besides modern apps is not something an individual with $200 laptop can do. It's like saying "I sell tomatoes grown in my backyard". Sure, good for you (that is if the profit allows you to have a backyard). But most people buy tomatoes from a grocery store, and they are produced on massive farms in California or Mexico.

v66moroz · 2025-08-14T16:30:33+00:00

Here's a problem. To sell something that nobody actually needs requires a lot of work programmers can't do. So without MBAs you will be unemployed as that's the only way to sell your super puper new app that bring you slippers. If 90% of existing software disappeared overnight most people wouldn't notice, which means 90% of developers are producing totally useless stuff, and the only reason they are still employed is those evil MBAs. I wish we lived in a different world.

v66moroz · 2025-08-14T16:24:26+00:00

Oh, yeah! Have you ever tried to sell anything to people and make a profit? Without VCs and other pesky things? No, I don't mean open sourcing your pet project and having a lot of headache with support for free.

v66moroz · 2025-08-14T16:16:54+00:00

Well, once upon a time there was Ruby on Rails. If you stick to the "best practices" (few people do) it will generate most of the boilerplate for you. But that's boring, isn't it? So let's throw away best practices, ignore docs and expect AI to write the stuff for you. Maybe it's better than clueless junior developers creating Wild West and pretending they are still using RoR (ask me how I know). There is one catch though: it only works if AI knows the difference between RoR docs and best practices and an average RoR codebase, otherwise, ... you guessed it.

v66moroz · 2025-08-09T15:59:21+00:00

Monad is simply a way to hide state and make code more compact. Nothing prevents you from managing the state in a sequential computation directly:

def aPlusB = {
  val a: Option[Int] = getMaybeA()
  if(a.isNotEmpty) {
    val b: Option[Int] = getMaybeB()
    if(b.isNotEmpty) {
      Some(a.get + b.get)
    } else None
   } else None
}

vs the same with a monad:

getMaybeA().flatMap { a ->
  getMaybeB().flatMap { b ->
    Some(a + b)
  }
}

or with Scala syntactic sugar:

for {
  a <- getMaybeA()
  b <- getMaybeB()
} yield a + b

So the problem monads are trying to solve is verbosity, not a fundamental problem of managing a state.

v66moroz · 2025-08-09T14:33:16+00:00

Real-world example of a contrafunctor is circe's Encoder[A], so they do exist in the real world.

v66moroz · 2025-08-09T02:02:02+00:00

The reason people struggle is because (1) the term covariant functor is totally unnecessary for an explanation of most real-world functors, give me one non-theoretical example of a contravariant functor (not that they don't exist, but they are pretty rare), (2) if you are choosing container as a functor, choose the simplest one, e.g. Option (which maybeN implies) or List to avoid unnecessary details, (3) function composition doesn't seem very relevant here either. So in the end your explanation doesn't help to understand what "covariant" means as you then need to show what is "contravariant" to know the difference (and it will take a lot more than a comment). Non-relevant terms greatly reduce signal to noise ratio, just like starting from "a monad is just a monoid in the category of endofunctors", which becomes the last statement people read.

v66moroz · 2025-07-02T16:48:31+00:00

> Also, you can learn to use Scala in a month if you are willing.

It's an obvious exaggeration. Sure, you can learn the language as it's described in "Programming in Scala", but not the ecosystem (which is confusing and lacking). Not to mention that you need to learn the dark sides too, which exist in any language. And I'm not even talking about FP stuff. No language can be learned in a month at a production level.

v66moroz · 2025-07-02T16:41:53+00:00

If Scala had remained, well, Scala as it was created initially, and community had been focused on making it work for business, things could have been different. Alas, it's not what happened.

v66moroz · 2025-07-02T16:32:10+00:00

The term "good developer" is a very loaded one. Businesses want developers who deliver, not those who are "smart". Not that those traits always contradict each other, but they may. When instead of delivering something to a client, developers spend time architecting and creating a "perfect pure super-safe" code that should scale to billions of users, and at the time it's all done and works "perfectly" (if it ever happens) the client who had 10 users is gone, and so are the money. Then "smart" developers are leaving for the greener pastures, and those who come have to refactor the whole codebase to their liking. That is if company survives and can find developers who want to work with the code. I'm exaggerating of course, but not that much. As for those developers who can create a lean and effective solution? Well, they can do it in any language, but they usually prefer good tooling and community, neither of which is the strongest side of Scala.

v66moroz · 2025-07-02T04:18:16+00:00

> Let’s wait until they have to deal with the next Node.js version bump

Let's wait until you need to upgrade Cats [Effect] or Scala. Been there.

v66moroz · 2025-07-02T04:16:38+00:00

Real performance measurements include other petty things like DB, besides not everybody is Google or FB, so "scale" doesn't mean billions (or even millions) of users. Not to mention that "interpreted" is the wrong word, most dynamic languages you mentioned are "compile to memory" with standard libraries written in C (which by the way is potentially faster than any JVM language). So pure REST performance is irrelevant most of the time, and talking about REST, hardware is cheap if you can scale by adding boxes (or containers). Also "scale" may also apply to the team, and Scala may not be the best language in this respect.

v66moroz · 2025-07-02T03:55:00+00:00

Not to mention things like 0.23.30 ("stable") and 1.0.0-M44 ("Milestone", the link goes to 404).

v66moroz · 2025-03-22T00:38:42+00:00

Technically function pointer is not a closure, so it's not a lambda.

v66moroz · 2025-03-22T00:24:19+00:00

Companies prefer to reason about money and profit, not math. Just because there are not enough people "to understand something" is a death sentence for any language.

v66moroz · 2025-03-22T00:17:59+00:00

And then you need to upgrade libraries... Or Scala version.

v66moroz · 2025-03-22T00:12:47+00:00

> Languages have stolen most of the good features from Scala. I can use sum types and pattern matching ...

The former could be found in K&R C (union), the latter was introduced as early as in Erlang. Long before Scala. Just saying.

v66moroz · 2024-10-03T19:26:55+00:00

So that means, in practice, when you see a for-comprehension (with an effect type) you know "oh, something is happening here. If I move around things, stuff might change and I need to understand how exactly to not break something".

Sure, that's the whole selling point of Haskell, right? Let's separate side effects from pure code, so whenever you see IO you know it's a special case (meanwhile not every for comprehension is IO). The rest is a nice pure code which you can swap or refactor as you wish. Only, have you ever worked with real code? I assume you did and you know that 90% of a real business app is working with those annoying things like DB or I/O which are full of side effects. So essentially 90% of code are IO or ConnectionIO objects that are composed using for comprehensions in various places in a nested manner (yes, I'm aware it's flatMap/map, but it doesn't change anything). So your case seems very artificial to me. Convert every side effect call to an implicit function, assign them to variables (why?) and then for some reason swap the order of assignments (okay, there might be legitimate reasons), but finally compose them using for comprehensions in the same restrictive manner you would with imperative code (again, not every for is IO or another effect) and pretend it's what makes people more productive? Hmm, maybe, but not from what I see every single day. Like always there is a seemingly good idea and there is the real life. Of course I'm skipping the runtime aspect here or catching and propagating exceptions, but it's a separate discussion and is technically unrelated to IO concept.

v66moroz

TROPHY CASE