4 ms·

Stick with languages, tools, and techniques that respect the math theory. Category theory, type theory, set theory, relational algebra, 1st order predicate calc

Stick with languages, tools, and techniques that respect the math theory. Category theory, type theory, set theory, relational algebra, 1st order predicate calculus, 2nd order predicate calculus. The OP has intuitively gravitated to this side. Theory isn't going to have an answer to every question, just don't willfully oppose it. Everything else (best practices, fads, etc.) is a convention at best, sometimes useful, but should never be regarded as having special significance. And in this regard, don't micro-services fly in the face of Occam's Razor? Or as the OP stated Monoliths are pretty good in most circumstances

sam0x17 6y ago
This is why I lean towards serverless monoliths these days. It works great.
rebeccaskinner 6y ago
In a lot of cases Microservices are the cheaper option. Keeping your code in a monolith requires a lot more investment in tooling (to manage a large monorepo, because apparently our industry has collectively forgotten that you can actually build separate libraries and keep them in different repositories) and coordination between multiple teams working on a single large project. The simplest solution is often for management to throw their hands in the air and let each team stake out their own territory and own their own services. You certainly pay a cost for it in terms of overall infrastructure complexity, but maybe if you're lucky you get some resilience and scalability out of it.
- ozim 6y ago
  That is what I am usually annoyed by when reading discussions like that. Someone assumes a context and throws in his experience like it would be applicable to every company and every project. Using their own definitions for industry buzzwords and by that making it more confusing for others, where those others start doing the same again as a response which brings nothing to the general understanding of things. When reading article I assumed author was not going to tackle project with multiple teams. I expect he was writing about a lot of projects that don't ever live to need more teams. You have a lot of projects where you have 10-15 devs as one team on it and those are huge projects but there are no downsides of a monorepo because it still works fine and is single repo/application. I would say monorepo should be defined as: repo where you have all projects for a company that don't need to be linked in any way. Because what I understand gave start to the term was Google having such use case, where they wanted ALL things in one repo. Having one project in one repository cannot be named "monorepo" that is just normal repository and that's what monolith in a single repo is.
mint2 6y ago
Not having a formal cs background, the comments on HN that wax about predicate calculus and algebras always raise questions for me. Is it a higher plane of programmer thinking or just abstract technical jargon and ideas that are suited for hard core technical cs research but bear little value in practical programming tasks? Like knowing the Latin names and full phylogenic tree and exact relation of humans to the animal snuffling outside when all most people need to know is whether it’s a small animal like a raccoon or is large like a grizzly bear. Like in the course of writing a feature engineering pipeline, tuning a ML model, and then deploying it as an api or as a scheduled batch predictor for another pipeline, at what point should one start thinking of parts of this in terms of “1st order predicate calculus” during the day to day tasks? At what point in working on a feature card does someone generally think of relational algebra? What tools don’t respect these things? What will happen by using them? Like can anyone give an ELI5 of the day to day use of explicitly using these concepts to guide average programming tasks?
- jackfoxy 6y ago
  It kind of boils down (for me) to choosing a strongly typed functional language and relational database by default, justified by the theory behind those. I can be convinced, by myself or others, that a particular project calls for something else. Because I'm familiar with them and satisfied with the tools my defaults are F# and SQL Server.
  - mint2 6y ago
    Wait so are you saying that all that terms like predicate calculus and algebra boil down to in practical terms is use a strongly typed language and and relational database? Okay so aside from choosing databases and languages, do these concepts explicitly come up in day to day programming or are regularly thought about?
    - jackfoxy 6y ago
      It's more like I don't need to think about these things. F# gives you immutability by default (but let's you use it if you really need it for a more efficient algorithm) and eliminates nearly all null values. Nulls can still leak in from an RDBMS. Working in an environment like this gets you to if it builds, it works (once you get used to FP thinking). You have to experience it to believe it.

sam0x17 6y ago

This is why I lean towards serverless monoliths these days. It works great.

rebeccaskinner 6y ago

In a lot of cases Microservices are the cheaper option. Keeping your code in a monolith requires a lot more investment in tooling (to manage a large monorepo, because apparently our industry has collectively forgotten that you can actually build separate libraries and keep them in different repositories) and coordination between multiple teams working on a single large project. The simplest solution is often for management to throw their hands in the air and let each team stake out their own territory and own their own services. You certainly pay a cost for it in terms of overall infrastructure complexity, but maybe if you're lucky you get some resilience and scalability out of it.

ozim 6y ago
That is what I am usually annoyed by when reading discussions like that. Someone assumes a context and throws in his experience like it would be applicable to every company and every project. Using their own definitions for industry buzzwords and by that making it more confusing for others, where those others start doing the same again as a response which brings nothing to the general understanding of things. When reading article I assumed author was not going to tackle project with multiple teams. I expect he was writing about a lot of projects that don't ever live to need more teams. You have a lot of projects where you have 10-15 devs as one team on it and those are huge projects but there are no downsides of a monorepo because it still works fine and is single repo/application. I would say monorepo should be defined as: repo where you have all projects for a company that don't need to be linked in any way. Because what I understand gave start to the term was Google having such use case, where they wanted ALL things in one repo. Having one project in one repository cannot be named "monorepo" that is just normal repository and that's what monolith in a single repo is.

mint2 6y ago

Not having a formal cs background, the comments on HN that wax about predicate calculus and algebras always raise questions for me. Is it a higher plane of programmer thinking or just abstract technical jargon and ideas that are suited for hard core technical cs research but bear little value in practical programming tasks? Like knowing the Latin names and full phylogenic tree and exact relation of humans to the animal snuffling outside when all most people need to know is whether it’s a small animal like a raccoon or is large like a grizzly bear. Like in the course of writing a feature engineering pipeline, tuning a ML model, and then deploying it as an api or as a scheduled batch predictor for another pipeline, at what point should one start thinking of parts of this in terms of “1st order predicate calculus” during the day to day tasks? At what point in working on a feature card does someone generally think of relational algebra? What tools don’t respect these things? What will happen by using them? Like can anyone give an ELI5 of the day to day use of explicitly using these concepts to guide average programming tasks?

jackfoxy 6y ago
It kind of boils down (for me) to choosing a strongly typed functional language and relational database by default, justified by the theory behind those. I can be convinced, by myself or others, that a particular project calls for something else. Because I'm familiar with them and satisfied with the tools my defaults are F# and SQL Server.
- mint2 6y ago
  Wait so are you saying that all that terms like predicate calculus and algebra boil down to in practical terms is use a strongly typed language and and relational database? Okay so aside from choosing databases and languages, do these concepts explicitly come up in day to day programming or are regularly thought about?
  - jackfoxy 6y ago
    It's more like I don't need to think about these things. F# gives you immutability by default (but let's you use it if you really need it for a more efficient algorithm) and eliminates nearly all null values. Nulls can still leak in from an RDBMS. Working in an environment like this gets you to if it builds, it works (once you get used to FP thinking). You have to experience it to believe it.