In software engineering I find a strong tendency in myself to lean towards harder-to-understand tooling in order to keep from feeling bad or worrying about my own intelligence. After becoming aware of this habit, I started to prefer PaaS (Heroku) over Iaas (AWS) for everything it’s feasible to use it for, garbage collected languages (Go, Lisp, Python) over manual memory management (Zig, C, C++) for things that don’t run on toasters, dynamic languages (Lisp, Python) over well typed (Haskell, TypeScript) languages, languages with small amounts of core features and constrained architecture choices (Lisp, Haskell, Go) over languages with lots and lots of features (Java, C++, JavaScript, Python), and procedural (Lisp, Go) over object-oriented or purely functional progamming languages (Java, Haskell, C#).
I have come to realize that there’s a very big difference between technology that remains unused because it is hard to use, like Haskell, and technology that remains unused because it requires up front investment in the form of practice or study of arcane and uninteresting stuff, like Vim. I now pretty much religiously avoid use anything that involves ongoing intellectual effort on my part, as the tradeoff is almost never worth it. I might write a post about this and link it here.
I’m interested in your comment about “using dynamic-untyped rather than well-typed because it helps you not worry about your own intelligence”. I use well-typed languages religiously precisely for that reason: I’m not smart enough to program in an untyped language without making far too many mistakes, and the type system protects me from my idiocy.
I prefer dynamic and don’t particularly care about strong/weak since generally my programs don’t do what I want because they are semantically wrong, not syntactically.
I’m a big believer in “the types should constrain the semantics of my program so hard that there is only one possible program I could write, and it is correct”. Of course we have to sacrifice some safety for speed of programming; for many domains, being 80% sure that a feature is correct in 95% of the possible use cases is good enough to ship it. But in fact I find that I code *faster* with a type system, because it forces most of the thinking to happen at the level of the problem domain (where it’s easy to think, because it’s close to real life); and there are a number of ways one can extremely cheaply use the type system to make invalid states unrepresentable in such a way that you no longer have to test certain things (because there’s no way even to phrase a program that could be incorrect in those ways).
For a super-cheap example, if you know that a list is going to be nonempty, use a non-empty list structure to hold it. (A non-empty list can be implemented as a pair of a head and a list.) Then you can save all the time you might otherwise have spent on coding defensively against people giving you empty list inputs, as well as any time you might have spent testing against that particular corner case.
For another super-cheap example that is so totally uncontroversial that it probably sounds vacuous (but it is in fact the same idea of “represent what you know in the type system so that the language can help you”), don’t store lists of (key, value); store a dictionary instead, if you know that keys are unique. This tells you via the type system that a) keys are definitely unique, and b) various algorithms like trees or hashmaps can be used for efficiency.
You misunderstand me. I don’t use the simpler products because otherwise I worry about my own intelligence. What I found was that in order to protect my ego, and because I thought I was smarter than I was, I consistently used software engineering tools and platforms that were complicated to the point of hurting my ability to program.
I will remove Go from the above post because I think it doesn’t fit; I dislike Go’s genericless type system because it constrains my programs and not because I’m thinking about it all the time. With regard to “well-typed” programming languages, the problem isn’t that they don’t help me write more correct code—they do. The problem is that they make me think about types to a degree that’s often unnecessary or irrelevant to solving the problem at hand, and while performing exploratory programming I have to deal with these type algebras that are a context switch from my ML or infrastructure problems. Most bugs are problems with semantics and not syntax, so normally thinking very hard about types turns out to be wasted effort in the long run.
Wrt functional paradigm, do you think it has a higher cognitive load than procedural and/or OO?
I can’t tell: it does always take me forever to remember how to use reduce (in say elixir), but then my day job is python, so is it just because of the conceptual switch?
I actually find higher order functions like map/filter/reduce to be simpler in the long term than pervasive for loops, and my one major gripe with golang is its lack of generics that would let it have these. I don’t really understand the hate recursion gets either, and you have to learn to use it in procedural languages anyways. My issue with “pure” functional programming languages, and I’m speaking with a sample size of one here (Haskell), is that Monads and I/O seem comically difficult to use or explain. It’s possible that I just haven’t put in the hours reading through long detailed explanations of these concepts, and that if I did it’d “click” and I’d never have to think about them again, but I find statistics textbooks easier to read than the myriad monad “tutorials” I’ve been handed for this language.
I believe the world is this way because of the following two facts:
monads are very hard to get your head into;
monads are extremely simple conceptually.
This means that everyone spends a long time thinking about monads from lots of different angles, and then one day an individual just happens to grok monads while reading their fiftieth tutorial, and so they believe that this fiftieth tutorial is The One, and the particular way they were thinking about monads at the time of the epiphany is The Way. So they write yet another tutorial about how Monads Are Really Simple They’re Just Burritos, and meanwhile their only actual contribution to the Monad Exposition Problem is to have very slightly increased the number of paths which can lead an individual to comprehension.
My issue with “pure” functional programming languages, and I’m speaking with a sample size of one here (Haskell), is that Monads and I/O seem comically difficult to use or explain. It’s possible that I just haven’t put in the hours reading through long detailed explanations of these concepts, and that if I did it’d “click” and I’d never have to think about them again,
Fwiw, yeah, this is basically how it went for me. Or, well, maybe not so much “reading through long detailed explanations” as “reading through through long detailed compilation errors” (though I’m sure I did both). Actually trying to use them seems probably important, not just reading about them. But yeah, I’d say that by now they seem intuitive to me, to the point where I had to resist adding my own attempt at a monad primer to this comment, and I only occasionally have to think in detail about them.
(Also, not really important, but this is more about the type system than about being a pure functional language. I don’t recommend using Elm for anything serious, but that has a similar-but-weaker type system without monads or (in some important sense) IO, while remaining purely functional. Early versions of Haskell didn’t have monads or (in the same sense) IO either.)
″ higher order functions like map/filter/reduce to be simpler”: do you find most other programmers find this too?
my experience is otherwise: i get a ton of pushback asserting this stuff is too hard to read and thus should NOT be use in our shop; somehow in python even using filter is more difficult than a list comprehension with an if!!???!!
I don’t really know what most programmers are like ¯\_(ツ)_/¯, I’ve never held a real software engineering job and most of my experience comes from my current attempt at building a startup. So far my cofounder seems fine with it, but we mostly work on different codebases.
Leonard Recruiting. We’re a recruiting company for penetration testers, right now specifically web application pentesters. My cofounder and I have been working on the product part time for four months (way too long, I know) and we plan on launching our platform in about a week, which is an open, dynamic, live computer hacking exam. We haven’t even gotten seed funding yet, so it might be a little generous calling us a “startup”, though recently we’ve actually been getting some unexpected revenue by building out our exam platform for small businesses that my cofounder knows personally.
In software engineering I find a strong tendency in myself to lean towards harder-to-understand tooling in order to keep from feeling bad or worrying about my own intelligence. After becoming aware of this habit, I started to prefer PaaS (Heroku) over Iaas (AWS) for everything it’s feasible to use it for, garbage collected languages (Go, Lisp, Python) over manual memory management (Zig, C, C++) for things that don’t run on toasters, dynamic languages (Lisp, Python) over well typed (Haskell, TypeScript) languages, languages with small amounts of core features and constrained architecture choices (Lisp, Haskell, Go) over languages with lots and lots of features (Java, C++, JavaScript, Python), and procedural (Lisp, Go) over object-oriented or purely functional progamming languages (Java, Haskell, C#).
I have come to realize that there’s a very big difference between technology that remains unused because it is hard to use, like Haskell, and technology that remains unused because it requires up front investment in the form of practice or study of arcane and uninteresting stuff, like Vim. I now pretty much religiously avoid use anything that involves ongoing intellectual effort on my part, as the tradeoff is almost never worth it. I might write a post about this and link it here.
I’m interested in your comment about “using dynamic-untyped rather than well-typed because it helps you not worry about your own intelligence”. I use well-typed languages religiously precisely for that reason: I’m not smart enough to program in an untyped language without making far too many mistakes, and the type system protects me from my idiocy.
Wrt typing, we have:
Strict/strong: c, go, java, erlang
Strict/weak: doesn’t exist right?
Dynamic/strong: python, elixir
Dynamic/weak: Perl
I prefer dynamic and don’t particularly care about strong/weak since generally my programs don’t do what I want because they are semantically wrong, not syntactically.
I’m a big believer in “the types should constrain the semantics of my program so hard that there is only one possible program I could write, and it is correct”. Of course we have to sacrifice some safety for speed of programming; for many domains, being 80% sure that a feature is correct in 95% of the possible use cases is good enough to ship it. But in fact I find that I code *faster* with a type system, because it forces most of the thinking to happen at the level of the problem domain (where it’s easy to think, because it’s close to real life); and there are a number of ways one can extremely cheaply use the type system to make invalid states unrepresentable in such a way that you no longer have to test certain things (because there’s no way even to phrase a program that could be incorrect in those ways).
For a super-cheap example, if you know that a list is going to be nonempty, use a non-empty list structure to hold it. (A non-empty list can be implemented as a pair of a head and a list.) Then you can save all the time you might otherwise have spent on coding defensively against people giving you empty list inputs, as well as any time you might have spent testing against that particular corner case.
For another super-cheap example that is so totally uncontroversial that it probably sounds vacuous (but it is in fact the same idea of “represent what you know in the type system so that the language can help you”), don’t store lists of (key, value); store a dictionary instead, if you know that keys are unique. This tells you via the type system that a) keys are definitely unique, and b) various algorithms like trees or hashmaps can be used for efficiency.
You misunderstand me. I don’t use the simpler products because otherwise I worry about my own intelligence. What I found was that in order to protect my ego, and because I thought I was smarter than I was, I consistently used software engineering tools and platforms that were complicated to the point of hurting my ability to program.
I will remove Go from the above post because I think it doesn’t fit; I dislike Go’s genericless type system because it constrains my programs and not because I’m thinking about it all the time. With regard to “well-typed” programming languages, the problem isn’t that they don’t help me write more correct code—they do. The problem is that they make me think about types to a degree that’s often unnecessary or irrelevant to solving the problem at hand, and while performing exploratory programming I have to deal with these type algebras that are a context switch from my ML or infrastructure problems. Most bugs are problems with semantics and not syntax, so normally thinking very hard about types turns out to be wasted effort in the long run.
Wrt functional paradigm, do you think it has a higher cognitive load than procedural and/or OO?
I can’t tell: it does always take me forever to remember how to use reduce (in say elixir), but then my day job is python, so is it just because of the conceptual switch?
I actually find higher order functions like map/filter/reduce to be simpler in the long term than pervasive for loops, and my one major gripe with golang is its lack of generics that would let it have these. I don’t really understand the hate recursion gets either, and you have to learn to use it in procedural languages anyways. My issue with “pure” functional programming languages, and I’m speaking with a sample size of one here (Haskell), is that Monads and I/O seem comically difficult to use or explain. It’s possible that I just haven’t put in the hours reading through long detailed explanations of these concepts, and that if I did it’d “click” and I’d never have to think about them again, but I find statistics textbooks easier to read than the myriad monad “tutorials” I’ve been handed for this language.
I believe the world is this way because of the following two facts:
monads are very hard to get your head into;
monads are extremely simple conceptually.
This means that everyone spends a long time thinking about monads from lots of different angles, and then one day an individual just happens to grok monads while reading their fiftieth tutorial, and so they believe that this fiftieth tutorial is The One, and the particular way they were thinking about monads at the time of the epiphany is The Way. So they write yet another tutorial about how Monads Are Really Simple They’re Just Burritos, and meanwhile their only actual contribution to the Monad Exposition Problem is to have very slightly increased the number of paths which can lead an individual to comprehension.
You are very funny and have convinced me maybe possibly to try haskell again. But only maybe.
Fwiw, yeah, this is basically how it went for me. Or, well, maybe not so much “reading through long detailed explanations” as “reading through through long detailed compilation errors” (though I’m sure I did both). Actually trying to use them seems probably important, not just reading about them. But yeah, I’d say that by now they seem intuitive to me, to the point where I had to resist adding my own attempt at a monad primer to this comment, and I only occasionally have to think in detail about them.
(Also, not really important, but this is more about the type system than about being a pure functional language. I don’t recommend using Elm for anything serious, but that has a similar-but-weaker type system without monads or (in some important sense) IO, while remaining purely functional. Early versions of Haskell didn’t have monads or (in the same sense) IO either.)
″ higher order functions like map/filter/reduce to be simpler”: do you find most other programmers find this too?
my experience is otherwise: i get a ton of pushback asserting this stuff is too hard to read and thus should NOT be use in our shop; somehow in python even using filter is more difficult than a list comprehension with an if!!???!!
I don’t really know what most programmers are like ¯\_(ツ)_/¯, I’ve never held a real software engineering job and most of my experience comes from my current attempt at building a startup. So far my cofounder seems fine with it, but we mostly work on different codebases.
What startup do you work on?
Leonard Recruiting. We’re a recruiting company for penetration testers, right now specifically web application pentesters. My cofounder and I have been working on the product part time for four months (way too long, I know) and we plan on launching our platform in about a week, which is an open, dynamic, live computer hacking exam. We haven’t even gotten seed funding yet, so it might be a little generous calling us a “startup”, though recently we’ve actually been getting some unexpected revenue by building out our exam platform for small businesses that my cofounder knows personally.