2 ms·

> though typically with an in-house “framework” rather than a language, which is a better approach anyway. I think that having a framework written in general p

> though typically with an in-house “framework” rather than a language, which is a better approach anyway. I think that having a framework written in general purpose language is part of the problem because it allows for things to turn into horrific balls of mud. > The reason is that the “smart” people building the framework end up spiraling off into ivory tower land. I don't think this is about smart vs. not smart. It's about different disciplines and abilities. Product developers should also be doing more (or all) product work and interacting with customers. > They also become disconnected from customer reality. Computer engineers who are creating a language and runtime should be servicing the specific domain of that the product. Part of the disconnect with DevOps is that it is solving for deploying general purpose tools rather than a specific domain. Have the computer engineers responsible for creating domain specific tools as well as deploying those domain specific tools and everyone should be more connected to the final outcome.

KptMarchewa 4y ago
>I think that having a framework written in general purpose language is part of the problem because it allows for things to turn into horrific balls of mud. Yeah, the problem definitely is that people are able to write code that gets thing done, instead of being unable to perform their work.
- williamcotton 4y ago
  I'm not sure how you got "unable to perform their work" from what I was suggesting. A/B testing, analytics, CRUD, etc, are all features that are ancillary to any products that need to be made. Imagine if a language had A/B testing baked right into it. You define a couple of functions annotated for A/B testing and they are automatically A/B tested. Putting all of this inline with product functionality is generally what causes these balls of mud in the first place.
  - jdlshore 4y ago
    I think you’re overestimating the value of building such support into a language, rather than using libraries/frameworks, and underestimating the difficulty of creating bespoke languages. Speaking as someone who’s actually tried what you’re suggesting—in a production project—and learned not to do it again, this whole conversation smacks of theory-crafting rather than practical experience. But I invite you to try it!

KptMarchewa 4y ago

>I think that having a framework written in general purpose language is part of the problem because it allows for things to turn into horrific balls of mud. Yeah, the problem definitely is that people are able to write code that gets thing done, instead of being unable to perform their work.

williamcotton 4y ago
I'm not sure how you got "unable to perform their work" from what I was suggesting. A/B testing, analytics, CRUD, etc, are all features that are ancillary to any products that need to be made. Imagine if a language had A/B testing baked right into it. You define a couple of functions annotated for A/B testing and they are automatically A/B tested. Putting all of this inline with product functionality is generally what causes these balls of mud in the first place.
- jdlshore 4y ago
  I think you’re overestimating the value of building such support into a language, rather than using libraries/frameworks, and underestimating the difficulty of creating bespoke languages. Speaking as someone who’s actually tried what you’re suggesting—in a production project—and learned not to do it again, this whole conversation smacks of theory-crafting rather than practical experience. But I invite you to try it!