4 ms·

The sad thing is nobody ever makes that complaint when talking about everything you'd need to know to build a bridge, or to place an IV, or even to build a tabl

The sad thing is nobody ever makes that complaint when talking about everything you'd need to know to build a bridge, or to place an IV, or even to build a table. There's a huge part of the software community that's self taught, but also a gigantic part with degrees in computer science. If there was enough value in these ideas and critical mass of wide adoption, we could just add it to the curriculum, and it'd just be yet another of those things you need to learn to get into the software industry.

moreaccountspls 6y ago
>The sad thing is nobody ever makes that complaint when talking about everything you'd need to know to build a bridge If we're talking about the software engineering equivalent of bridges, I think it would be much more valuable add TLA+ or similar to the curriculum.
- pwm 6y ago
  Why not both? They are not mutually exclusive and they both would advance the status quo.
  - moreaccountspls 6y ago
    If there was unlimited time, sure.
    - pwm 6y ago
      OP was complaining about having to understand Functors, Monoids, etc... like they are nuisances in the way of writing real code. In response 6gvONxR4sf7o and I were saying that programmers really ought to be taught these incredibly useful abstractions. After more than a decade of coding professionally in popular languages and then 4 years of writing Haskell I cannot begin to tell you how amazing it is that we have these abstractions to rely on. There are virtually endless data types out there and instead of having to study each and every one of them I can just look at whether something is a Monoid and immediately know that I can append them and there is a unit. I can look at whether something is a Functor and immediately know that I can map any function over it. I only need to know a few of these generic patterns and "magically" I can write functions that operate on any of the countless data structures out there. This is true code reuse. Not teaching these to future programmers, not exploiting the timeless, powerful knowledge behind these is in my opinion a disservice to them.
      - moreaccountspls 6y ago
        I've been writing Haskell for 12 years so I'm aware of the abstractions it offers. At the end of the day though, either we're building a bridge or we're not. If we're building a bridge (i.e. a distributed database, a real time system, fly by wire system, etc.) Haskell is useless if for no other reason than how it does memory allocation. Dependent types are also a dead end for building bridges in my opinion. Proving any non trivial invariants is basically impossible in the real world (http://web.archive.org/web/20200113205635/http://blog.paralleluniverse.co/2016/07/23/correctness-and-complexity/ http://web.archive.org/web/20200113205635/http://blog.parall...). And even if it wasn't, dependent types are for a program. But our "bridges" aren't programs, they're systems! If there's one thing that the Haskell community don't understand, it's that. The scary issues that crop up in large scale distributed systems aren't from the nodes, they're from the edges. So any system of correctness that is focused on the nodes [i.e. type systems] is avoiding the real issue. That's the power of TLA+ by the way. By modeling the system, you have a specification that gives you some confidence what you're building is correct before beginning to implement your bridge. And if we're not building a bridge? The business doesn't really care about correctness, they care about shipping features. Rollbacks are an acceptable cost. Our job is to sit down and bang out a solution to the problem at hand, not build the perfect abstraction to the problem. When we use languages like Haskell, we take that power out of product's hands.
        pwm 6y ago
        At work we're building a novel DSL and its ecosystem for a specific industry. Not sure if you consider that a bridge or not, the naive part of me likes to think it's akin to one but maybe i'm deluding myself. Of course we could use any language under the sun but imho Haskell is a really great fit for this project. It also helped hiring some truly great talent (I'm the hiring manager for this team so I know first hand). I don't have much experience with TLA+. From the little I know and learnt about it over the years I think it's brilliant which is why i agreed it should be taught and used more. For the record I've also been involved in multiple large-scale micro-service-obsessed projects in the past, none of them used Haskell or TLA+ and they all were a terrible mess of hidden entangled complexity. Not sure if there's any takeaway just an anecdote.
marcosdumay 6y ago
Honestly, there is already too damn much stuff to learn to get into the software industry. One can make a point in that senior developers could use different tools than juniors. That happens on other industries, and development avoids it like the plague, with clearly bad consequences. But the industry will never standardize on high-knowledge tools.
- 6gvONxR4sf7o 6y ago
  That sentiment is so strange to me. There's a ton to learn to get into the industry, but "too much" requires some real thought. If an extra month of full time study could fix some software issue 95% of the time, are there any issues that you can think of that would be worth raising the bar? I'm not advocating that learning monads is the thing, but that a high barrier to entry isn't in and of itself bad. I sincerely hope that software as a field matures to the point where maybe 50 years from now, hiring most of us working in it with our knowledge today would be like hiring a mathematician who never learned calculus.
  - clarry 6y ago
    I think it's true that there's too much in the way of faddy tools and products, frameworks, libraries, ecosystems.. and at the same time people are perhaps not investing enough into theory/fundamentals. Where programming languages fit on this spectrum is a bit controversial. I think most people treat learning a programming language as an ecosystem problem, but that's only because these people tend to consider only mainstream languages that just don't have a lot going for them in the "language proper." The result seems to be that if you propose a programming language a competent programmer can't pick up in a weekend or three (mostly by learning the syntax & types and then just applying prior knowledge from other languages), there's going to be a lot of complaining and whining about it. Maybe it's justified as long as we don't see advanced languages that really change software engineering in a big way; 'til then, a language is just another (more or less faddy) tool. If we had a language that could offer guaranteed productivity boost (without any nasty tradeoffs other than the required up-front mental investment) for anyone who takes a few months to study it, then hell yes we should! So it boils down to: is there really enough values in those ideas or not? I think not, or else both academia and the entire industry is just extremely dumb for not seeing that value. And I'm dumb too :( The other point to note is that some valuable concepts just slowly creep into mainstream languages over time. Like mainstream languages today have a decent set of constructs that you primarily associated with functional languages 2-3 decades ago. Those things are probably not valuable enough in isolation to justify switching languages.

moreaccountspls 6y ago

>The sad thing is nobody ever makes that complaint when talking about everything you'd need to know to build a bridge If we're talking about the software engineering equivalent of bridges, I think it would be much more valuable add TLA+ or similar to the curriculum.

pwm 6y ago
Why not both? They are not mutually exclusive and they both would advance the status quo.
- moreaccountspls 6y ago
  If there was unlimited time, sure.
  - pwm 6y ago
    OP was complaining about having to understand Functors, Monoids, etc... like they are nuisances in the way of writing real code. In response 6gvONxR4sf7o and I were saying that programmers really ought to be taught these incredibly useful abstractions. After more than a decade of coding professionally in popular languages and then 4 years of writing Haskell I cannot begin to tell you how amazing it is that we have these abstractions to rely on. There are virtually endless data types out there and instead of having to study each and every one of them I can just look at whether something is a Monoid and immediately know that I can append them and there is a unit. I can look at whether something is a Functor and immediately know that I can map any function over it. I only need to know a few of these generic patterns and "magically" I can write functions that operate on any of the countless data structures out there. This is true code reuse. Not teaching these to future programmers, not exploiting the timeless, powerful knowledge behind these is in my opinion a disservice to them.
    - moreaccountspls 6y ago
      I've been writing Haskell for 12 years so I'm aware of the abstractions it offers. At the end of the day though, either we're building a bridge or we're not. If we're building a bridge (i.e. a distributed database, a real time system, fly by wire system, etc.) Haskell is useless if for no other reason than how it does memory allocation. Dependent types are also a dead end for building bridges in my opinion. Proving any non trivial invariants is basically impossible in the real world (http://web.archive.org/web/20200113205635/http://blog.paralleluniverse.co/2016/07/23/correctness-and-complexity/ http://web.archive.org/web/20200113205635/http://blog.parall...). And even if it wasn't, dependent types are for a program. But our "bridges" aren't programs, they're systems! If there's one thing that the Haskell community don't understand, it's that. The scary issues that crop up in large scale distributed systems aren't from the nodes, they're from the edges. So any system of correctness that is focused on the nodes [i.e. type systems] is avoiding the real issue. That's the power of TLA+ by the way. By modeling the system, you have a specification that gives you some confidence what you're building is correct before beginning to implement your bridge. And if we're not building a bridge? The business doesn't really care about correctness, they care about shipping features. Rollbacks are an acceptable cost. Our job is to sit down and bang out a solution to the problem at hand, not build the perfect abstraction to the problem. When we use languages like Haskell, we take that power out of product's hands.
      - pwm 6y ago
        At work we're building a novel DSL and its ecosystem for a specific industry. Not sure if you consider that a bridge or not, the naive part of me likes to think it's akin to one but maybe i'm deluding myself. Of course we could use any language under the sun but imho Haskell is a really great fit for this project. It also helped hiring some truly great talent (I'm the hiring manager for this team so I know first hand). I don't have much experience with TLA+. From the little I know and learnt about it over the years I think it's brilliant which is why i agreed it should be taught and used more. For the record I've also been involved in multiple large-scale micro-service-obsessed projects in the past, none of them used Haskell or TLA+ and they all were a terrible mess of hidden entangled complexity. Not sure if there's any takeaway just an anecdote.

marcosdumay 6y ago

Honestly, there is already too damn much stuff to learn to get into the software industry. One can make a point in that senior developers could use different tools than juniors. That happens on other industries, and development avoids it like the plague, with clearly bad consequences. But the industry will never standardize on high-knowledge tools.

6gvONxR4sf7o 6y ago
That sentiment is so strange to me. There's a ton to learn to get into the industry, but "too much" requires some real thought. If an extra month of full time study could fix some software issue 95% of the time, are there any issues that you can think of that would be worth raising the bar? I'm not advocating that learning monads is the thing, but that a high barrier to entry isn't in and of itself bad. I sincerely hope that software as a field matures to the point where maybe 50 years from now, hiring most of us working in it with our knowledge today would be like hiring a mathematician who never learned calculus.
- clarry 6y ago
  I think it's true that there's too much in the way of faddy tools and products, frameworks, libraries, ecosystems.. and at the same time people are perhaps not investing enough into theory/fundamentals. Where programming languages fit on this spectrum is a bit controversial. I think most people treat learning a programming language as an ecosystem problem, but that's only because these people tend to consider only mainstream languages that just don't have a lot going for them in the "language proper." The result seems to be that if you propose a programming language a competent programmer can't pick up in a weekend or three (mostly by learning the syntax & types and then just applying prior knowledge from other languages), there's going to be a lot of complaining and whining about it. Maybe it's justified as long as we don't see advanced languages that really change software engineering in a big way; 'til then, a language is just another (more or less faddy) tool. If we had a language that could offer guaranteed productivity boost (without any nasty tradeoffs other than the required up-front mental investment) for anyone who takes a few months to study it, then hell yes we should! So it boils down to: is there really enough values in those ideas or not? I think not, or else both academia and the entire industry is just extremely dumb for not seeing that value. And I'm dumb too :( The other point to note is that some valuable concepts just slowly creep into mainstream languages over time. Like mainstream languages today have a decent set of constructs that you primarily associated with functional languages 2-3 decades ago. Those things are probably not valuable enough in isolation to justify switching languages.