3 ms·

> Don't. Make. Me. Learn. It's not because I don't want to learn. I disagree. I. Don't. Want. To. Learn. Almost nothing in between me and getting my prob

by bsder 4y ago

> Don't. Make. Me. Learn. It's not because I don't want to learn. I disagree. I. Don't. Want. To. Learn. Almost nothing in between me and getting my problem solved is interesting nowadays. Everything I have to learn is just another yak I have to shave in between me and getting my problem solved. This is doubly irritating when the yak is infrastructure (configuration systems, build systems, source control systems, etc.) that has zero bearing on my problem. Here was one: "We want to add audio to our phone app." GROAN. App is in Flutter on Android which implies: 1) Flutter 2) Dart 3) Gradle (dear God, help me) 4) Groovy 5) Oboe (for sound on Android) implying 6) Android NDK 7) CMake (hey Satan, I'll take your help too) 8) C++ And I'm leaving out a bunch of stuff. And there will be even more for iOS. NONE if this is interesting to me. Only 2,5 and 8 are directly applicable to my problem. Everything else is a tower of garbage that I have to chop through with a machete in order to get to the task that I actually want to solve. And, as I understand it, somehow the web and Javascript universe is worse. So, no, I don't want to learn.

speed_spread 4y ago
Wow, that's a truly horrible tech stack. Flutter, not even once.
- bsder 4y ago
  Most of that isn't flutter. It's the Android tech stack. iOS isn't any better with Xcode, Swift, Cocoapods, Ruby, etc. Flutter and Dart are actually some of the more interesting things that I'm not so irritated learning.
  - ratww 4y ago
    This is a classic issue of leaky abstractions, so it is definitely "caused" by Flutter/Dart. What led to this might not be their "fault", but as it stands this is something that only Flutter/Dart can solve. It is not strictly necessary to use Gradle/Groovy to build an Android app, so to use it was Flutter/Dart's choice. Just as it isn't necessary to use Xcode, Cocoapods or Ruby (of course, you still need either Objective-C or Swift, but only one) to make an iOS one. Same for Oboe: it could be prebuilt rather than leaving it all to you (although depending on how you're using it, it's debatable if it's Flutter/Dart's concern). The bottom part of the stack doesn't have control over the top part. Gradle can't really modify itself so that Flutter's abstraction is no longer leaky. Save for some ruling by Google/Apple/etc, the reason you need the whole stack is not because of some fundamental need, but rather because it was a choice made by the tools at the top of it.
    - bsder 4y ago
      > It is not strictly necessary to use Gradle/Groovy to build an Android app, so to use it was Flutter/Dart's choice. Just as it isn't necessary to use Xcode, Cocoapods or Ruby (of course, you still need either Objective-C or Swift, but only one) to make an iOS one. This may all be technically and pedantically true, but I have never seen an app built without either of those stacks. And I've been doing this an awful long time.
      - ratww 4y ago
        Yeah, because of a technical choice made by higher level tools. And I've worked on a few games that didn't need some of those. On iOS's side there's Swift Build Sysyem and Swift Package Manager that almost remove the need for Xcode. And there's also things like Cordova where some of those things are used but fiddling with them isn't needed for 99% of the cases. It's funny how this is similar in the frontend where people constantly complain about the tooling, but as soon as they hear that apps can be built without bundlers/transpilers (because modern browsers support A LOT of things), but go "yeahhhhhh right but in practice you need webpack because I never seen anything without it in my super vast experience of building the same thing over and over and over". Well...
hintymad 4y ago
Good example. "Another yak to shave" is a great analogy too. I think we are saying the same thing: we don't want to learn anything that has no direct bearing on our problems. Learning how to design an infinitely scalable metadata service for a stateful service is a delight. Learning how to use Terraform is an abomination.

by bsder 4y ago

speed_spread 4y ago

Wow, that's a truly horrible tech stack. Flutter, not even once.

bsder 4y ago
Most of that isn't flutter. It's the Android tech stack. iOS isn't any better with Xcode, Swift, Cocoapods, Ruby, etc. Flutter and Dart are actually some of the more interesting things that I'm not so irritated learning.
- ratww 4y ago
  This is a classic issue of leaky abstractions, so it is definitely "caused" by Flutter/Dart. What led to this might not be their "fault", but as it stands this is something that only Flutter/Dart can solve. It is not strictly necessary to use Gradle/Groovy to build an Android app, so to use it was Flutter/Dart's choice. Just as it isn't necessary to use Xcode, Cocoapods or Ruby (of course, you still need either Objective-C or Swift, but only one) to make an iOS one. Same for Oboe: it could be prebuilt rather than leaving it all to you (although depending on how you're using it, it's debatable if it's Flutter/Dart's concern). The bottom part of the stack doesn't have control over the top part. Gradle can't really modify itself so that Flutter's abstraction is no longer leaky. Save for some ruling by Google/Apple/etc, the reason you need the whole stack is not because of some fundamental need, but rather because it was a choice made by the tools at the top of it.
  - bsder 4y ago
    > It is not strictly necessary to use Gradle/Groovy to build an Android app, so to use it was Flutter/Dart's choice. Just as it isn't necessary to use Xcode, Cocoapods or Ruby (of course, you still need either Objective-C or Swift, but only one) to make an iOS one. This may all be technically and pedantically true, but I have never seen an app built without either of those stacks. And I've been doing this an awful long time.
    - ratww 4y ago
      Yeah, because of a technical choice made by higher level tools. And I've worked on a few games that didn't need some of those. On iOS's side there's Swift Build Sysyem and Swift Package Manager that almost remove the need for Xcode. And there's also things like Cordova where some of those things are used but fiddling with them isn't needed for 99% of the cases. It's funny how this is similar in the frontend where people constantly complain about the tooling, but as soon as they hear that apps can be built without bundlers/transpilers (because modern browsers support A LOT of things), but go "yeahhhhhh right but in practice you need webpack because I never seen anything without it in my super vast experience of building the same thing over and over and over". Well...

hintymad 4y ago

Good example. "Another yak to shave" is a great analogy too. I think we are saying the same thing: we don't want to learn anything that has no direct bearing on our problems. Learning how to design an infinitely scalable metadata service for a stateful service is a delight. Learning how to use Terraform is an abomination.