9 ms·

Things Unlearned

190 points by lycopodiopsida 5y ago

nineplay 5y ago
> It's ok to think that things have flaws or could be improved. But it's a trap to believe that solutions are trivial and everyone else is just too enfeebled of character to push the miracle button. I feel this so much. I've worked on products which many people insist could be done just as well by spreadsheets. I've worked in areas which people believe are overcomplicated - which they are - and therefore could be replaced with something simple. It is never that easy. I see it all the time in other fields and I just shake my head. If you ever find yourself saying "Why don't they just..?" you almost certainly don't understand the problem.
- burnished 5y ago
  I agree with you, but I also kind of hate that "Why don't you just..?" has become so tainted, because it is a great question to ask if you want to learn more about the heart of the matter. What went wrong when the 'obvious' solution was tried is interesting! Or, huh, just spitballing here, I suppose one could rephrase it as "have you considered..?" to ask the same question without the implicit assumption that the task is easy and the person being asked has overlooked something/is an idiot.
  - nineplay 5y ago
    The problem specifically is "just". "Why don't they use containers instead of tarballs?" is a excellent question which can help you understand a system better. "Why don't they just use containers instead of tarballs?" strongly suggests that containers are obviously superior and there must be some flaw in the system that's keeping the tarballs around.
    - burnished 5y ago
      I think you are correct, thank you for pointing that out to me.
    - jfrunyon 5y ago
      "Just" suggests that containers appear better for the purpose at hand from the questioner's perspective. Which is also suggested by the question being asked at all.
    - musicale 5y ago
      I think "just" is supposed to imply that the proposed solution might be simpler or easier in some way, not that it's obviously superior overall. [Of course in the case of containers vs. tarballs ... it might actually make the system more complex and more difficult to implement, use, and maintain - something which might be nice to state explicitly along with the reasons why. >;-)]
  - _carbyau_ 5y ago
    I agree with you that "questioning why" it generally a good thing for understanding. The issue here is one of communication, whereby the connotations of "just" may be taken differently by Asker and Responder. A Responder could take the use of "just" as implying "obvious thing you personally missed" which derides your efforts/understanding/intellect/ego. Whereas I see the use of "just" as saying something about the Askers mental model. The Asker knows their mental model says this is easy. The Asker knows you did not do [easy thing]. They want to know why there is a disparity. Anecdotally, I have been hobbying away when my wife walks in - is given a brief explanation of what I am doing - says "Why don't you just [xyz]?" She has limited information. She knows it. I know it. We both know her mental model is not like mine. But through her building it how she wants we can explore options. When she says "just" it is because her mental model says this should be easy. And sometimes I eat humble pie because it is. Because my mental model was built from scratch from a different direction and my perspective means I didn't see [easy thing]. Not often. But often enough that I appreciate every time my wife asks. Maybe the issue is who/how often you are asked the "just" question. Are you being bothered by too many people who don't-really-know/don't-really-care ? Then the Nth person coming up saying "why don't you just?" is another time/attention sapping interaction.
  - tehnub 5y ago
    Post from a little while back where someone really really thought this through. IIRC, they concluded that there's no good way to ask it, lol. https://news.ycombinator.com/item?id=21675717 https://news.ycombinator.com/item?id=21675717
  - jeffffff 5y ago
    i like to phrase this sort of question as "i'm assuming you considered this simpler solution, why was that not sufficient?" sometimes the answer is that they didn't consider it and now feel dumb for not thinking of it, but i've never seen anyone get defensive or offended or upset when phrasing it that way.
- rnoorda 5y ago
  > I see it all the time in other fields and I just shake my head. If you ever find yourself saying "Why don't they just..?" you almost certainly don't understand the problem. A political corollary to this that I enjoy came from an old professor of mine- "If your political opinions require large amounts of people to be stupid or evil, you don't understand the issues well enough." (A rough quote, I don't remember exact phrasing.)
  - nineplay 5y ago
    I wish that was the banner at the top of every political discussion forum. Maybe with some auto-flagging on posts which can be condensed down to "everyone who disagrees with me is an idiot" The world would be a better place.
  - codeisawesome 5y ago
    Hmm. But isn’t there some merit to the idea that groups of people behave differently when put together vs. how they would act individually?
    - deleted 5y ago
      [deleted]
  - bryanrasmussen 5y ago
    this seems to discount historically known political movements in which almost everyone involved, with the benefit of hindsight, was obviously stupid or evil. Probably these are outliers, so also probably your professor's quote fits well enough most of the time, and only some of the time returns false when it should return true.
    - Jensson 5y ago
      Usually those movements intend to remove "evil" people. "We weren't evil, how can attacking evil people be evil?" You can see people say things like this even today. The evil in these cases was done by the people convincing the masses that the other group really is evil and needs to be attacked, not by the masses. The masses will attack and punish whatever they think is evil, everyone knows that, doesn't mean that they are evil, rather it is always evil to label large groups of people as evil since it encourages the masses to attack those.
- TeeMassive 5y ago
  https://xkcd.com/793/ https://xkcd.com/793/
- dehrmann 5y ago
  The other side of this is that kids don't know what's impossible yet.
- anotherevan 5y ago
  Isn't that the same people who say, "I could write that in a weekend..."?
ssivark 5y ago
Here’s a meta question to the author: Having been around the circuit once, do they at least feel a little more humble about their opinions this time around, or are they just as strong but only in a different direction? :-) IMHO, while the author has undoubtedly grown wiser, I think there’s just as much truth to their earlier opinions as the later ones; the value lies in being able to disambiguate the context in which each is valuable — not so much in trading one set of opinions for another. That humility, to me, is the bigger takeaway.
- jamii 5y ago
  It did take me a while to write this (~20 hours, I think) because I kept worrying about that exact problem, and I kept catching myself writing generic advice rather than concrete experiences. I tried as much as possible to only write things where I could think of multiple concrete examples in my own experience.
  - mattbaker 5y ago
    Your writing was very good and the time you spent on it was clear to me, this was exceptional.
  - dgb23 5y ago
    It reminded me of this: https://gist.github.com/prakhar1989/1b0a2c9849b2e1e912fb https://gist.github.com/prakhar1989/1b0a2c9849b2e1e912fb
Scarbutt 5y ago
Thanks for the reality slap and bucket of cold water buddy.
coyotespike 5y ago
As a new programmer, I was also seduced by the FP hype, and learned web development in ClojureScript without knowing JavaScript. This was a really hard way to learn, and once I finally went mainstream I found that the messaging about how bad other languages were was much exaggerated. In general I think the ecosystem trumps the language quality, and the senior developers who think otherwise generally underestimate the difficulty for a junior developer of working on the bleeding edge. Pragmatism over purity (while keeping enough purity-focus to keep the codebase clean). I also think JS is absolutely fine as a language and its warts are not that hard to work around.
- rimliu 5y ago
  JS may be fine, but I start do doubt the same can be said about the ecosystem.
  - kansface 5y ago
    I really enjoy writing JS/TS - I find that eg arrow functions mixed with React allow for really concise and expressive solutions. You are correct about the ecosystem... maybe not per se, but that supply chain attacks are hopelessly intractable at the moment. How could you possibly go about writing a modern SPA that notionally cares about security when the third party software you must rely on is impossible to verify? I would love if browsers let you run JS in a sand boxed mode wherein you could just pass a bundle of vendored upstream software without the ability to touch the window, network, global state, etc.
  - skinkestek 5y ago
    > JS may be fine, If you compare JS (not TS, TS is fine) and PHP (I have extensive experience in both) you'll find that once you go beyond the syntax on the top you'll find the same flaws in some form or another. Yes, PHP is uglier, but that is about it. > but I start do doubt the same can be said about the ecosystem. JS is a horrible language that works because of the tireless effort of its community that has created an ecosystem so rich that even JS can be programmed efficiently. The ecosystem might be flawed but it is the only reason why JS is usable at all.
- 5y ago
chubot 5y ago
Great article, I was nodding my head with almost every point! Although I think you also have to consider that the author has a strong math background, which both improves and warps your view of programming. If you don't know any math, then this post is probably less relevant to you (e.g. learning a bit Haskell or ML is probably a good idea in that case). ------ As a nitpick about the theory of automata, I would draw a big red line between regular languages and context free grammars. Regular languages have very useful engineering properties: they have predictable (linear) performance and give you "free" lookahead. (That is, nondeterminism is a math-y idea that many programmers are not comfortable with, but it's useful for engineering.) They are better than Perl-style regexes for building reliable and understandable systems, which "blow up" on a regular basis. In contrast, context-free grammars have almost no useful engineering properties by themselves. (There are subsets like LALR(1) that do, but they come with a bunch of tradeoffs.) As the article mentions, learning about recursive descent parsing first is probably more practical. Also, you're MUCH more likely to encounter a regular expression in real code than a context free grammar. In 15 years of professional programming I probably dealt with regexes on a weekly or monthly basis, but had to write or modify a grammar exactly zero times. It does help to be more familiar with regexes and regular languages. This post/sketch elaborates on related points: Comments on Eggex and Regular Languages http://www.oilshell.org/blog/2020/07/eggex-theory.html http://www.oilshell.org/blog/2020/07/eggex-theory.html
- jamii 5y ago
  > If you don't know any math ... learning a bit Haskell or ML is probably a good idea This is very much counter to the point I was making. I didn't find that learning haskell or ml was anything like learning math, especially the kind of math that I've seen people get use out of in day-to-day engineering, and I don't understand why this idea is so persistent. If you don't know any math, it might be worth learning some of whatever kind of math is applicable in your field. It's probably not haskell. > It does help to be more familiar with regexes and regular languages. Regexes are certainly useful, but I don't think that learning a lot about automata theory is a particularly efficient way to get better at using regexes in practice, compared to eg doing a bunch of drills on https://www.executeprogram.com/courses/regexes https://www.executeprogram.com/courses/regexes
ChrisMarshallNY 5y ago
> It's so easy to think that simple solutions exist. But if you look at the history of ideas that actually worked, they tend to only be simple from a distance. The closer you get, the more you notice that the working idea is surrounding by a huge number of almost identical ideas that don't work. This brings to mind, two of my favorite H. L. Mencken quotes: "There's always an easy solution to every human problem; Neat, plausible and wrong." "The fact that I have no remedy for all the sorrows of the world is no reason for my accepting yours. It simply supports the strong probability that yours is a fake." He was an acerbic S.O.B.
- jerf 5y ago
  Simple solutions do exist... it's just, they're simple, so people solve them very quickly and nobody else even has time to start processing them as a "problem". If people are still arguing about something ten years later, it's because it's not simple. But there's lots of stuff we don't argue about, because it's solved, because it was simple.
  - ChrisMarshallNY 5y ago
    That's a very good point!
    - jamii 5y ago
      Now I have to figure out how to fit that into the flow of the article somewhere...
  - habitue 5y ago
    Simple solutions can be really hard to find sometimes (you know P != NP and all that). The thing you're talking about is solutions that are simple to think of.
zubairq 5y ago
Hi Jamie, really nice piece of writing. I always enjoy reading about your work. Zubair
paganel 5y ago
> Being fluent in the core language of mathematics (basic logic I have been programming for a living for 15 years, I'm most definitely not as good a programmer as OP is, but the least I can do is double-vouch for that advice. I first heard it a little over 20 years ago, at the end of my first calculus class at uni. After scaring us, his students, about all the things that we will have to learn during the next semester I remember the professor telling us that we should be really learning what the NOT, OR and AND logical operators really do and stick that piece of information firmly in our heads, because that is really important for our jobs. He also bitched a little about our older colleagues for not remembering that stuff anymore (and causing different computer bugs because of that) and I remember saying to myself: "how stupid can one be in order to un-learn this stuff? It is easy!". Like I said, 20 years have passed since then and I found out that even though it's easy lots of people seem to forget how basic logic actually works when it comes to programming.
- int_19h 5y ago
  Statistics is another area where solid understanding of a few very basic concepts gets you far in a practical sense.
ithrow 5y ago
By way of counter-example, check out this ICFP contest retrospective. Nikita is using clojure, a pretty niche language, but has built up incredible fluency with both the language and the ecosystem so that he can quickly throw out web scrapers and gui editors. Whereas I wouldn't be able to quickly solve those problems in any language after flitting around from ecosystem to ecosystem for 12 years. The thing with niche languages like Clojure is that you can leverage existing ecosystems(reducing the risk of getting stuck) unlike other languages that start from scratch. Probably the same for languages like F#, Kotlin and even Zig (using the C ecosystem). Of course, I found the article great with lots of good advice(ex: I still wouldn't use Clojure if Javascript can get the job done perfectly fine) so don't let this nitpick distract you or look the other way ;)
unixhero 5y ago
If his baseline was Haskell. It was his first programming language. Then of course coding something else won't make him a better programmer. He is already a genious.
Jensson 5y ago
> Being fluent in the core language of mathematics (basic logic, sets, functions, proof techniques) makes it easy to pick up domain-specific tools when I need them eg statistical relational learning when working at relational.ai, bidirectional type inference for imp. I feel the most important part of learning higher math for programming is that you learn what it means for a statement to be true. Most people, even most programmers, don't really grasp that which makes most harder problems intractable to them as you can't build a stable tower on "basically true" statements. Also even higher math is all about creating new useful abstractions for solving new problems, that is basically the same kind of thinking as writing useful reusable programming libraries.
pikseladam 5y ago
I used to think working hard means working long time. I strongly disagree to that now. Overworking is almost certainly a sign for a bigger problem.
dgb23 5y ago
Peter Norvig in his essay "Teach Yourself Programming in Ten Years"[0] wrote this: > Learn at least a half dozen programming languages. Include one language that emphasizes class abstractions (like Java or C++), one that emphasizes functional abstraction (like Lisp or ML or Haskell), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), and one that emphasizes parallelism (like Clojure or Go). There is also similar advice from other well respected veterans. Being able to choose from a smallish deliberate set of languages that introduce some powerful concept each or have some unique reach. Then there is "Beating the Averages"[1] by Paul Graham. > A suspicious person might begin to wonder if there was some correlation here. A big chunk of our code was doing things that are very hard to do in other languages. The resulting software did things our competitors' software couldn't do. Maybe there was some kind of connection. I encourage you to follow that thread. There may be more to that old man hobbling along on his crutches than meets the eye. I think this hint is important and relates to the above. There are things that you can do in X, that are "very hard" to do in Y, probably vice versa. It is powerful and helpful to know a heterogeneous set of languages and tools. The distinction between say Java, C# or Typescript is almost arbitrary from a technical, real brain "juice" kind of perspective. The distinction between say SQL, C or Lisp however lets you see a problem in a whole different light as each introduce things you cannot do easily in the other. Example: Why does a particular Blub webapp suck? Because it runs slow, changes to it take too much time, it has data consistency issues that it moves to the user or introduces as bugs? Hint: There are solutions to these problems and some technologies make them just fall out, almost for free, if one has taken the time to learn them. I don't yell this down from an ivory tower. I say this as someone who has went through the pain repeatedly, because I and most people around me didn't get this. Pragmatism is not always "what everyone else does." And coming back to the article; I don't say the ecosystem and the culture around a language or platform don't matter. It is just one factor of many. When looking at these things I found it is _useful_ to consider languages (and so on) that are slightly niche and opinionated enough so they make particular things easy that would otherwise be hard. --- [0] https://norvig.com/21-days.html https://norvig.com/21-days.html [1] http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
bitzlab 5y ago
Woow! https://natrmd.com https://natrmd.com There are so many things we should learn. For example, I personally want to learn how to grow my website traffic and this is why you see this comment! :D Cheers!
hinkley 5y ago
The tension here is that we all understand the concept of being 'too close to the problem'. It's the opposite fence-post from Dunning-Kruger, and the truth likes somewhere between them, not between DK and some center line. It's not universally the case that an unbiased observer is lacking critical details that explain why the problem hasn't been solved better. The observer has different frames of reference, one that might include wisdom from other problem domains that have already solved a similar problem. The observer is unbiased or differently biased. They have no sunk cost fallacy. They have not attached their sense of identity to the existing work. Best of all, they have not attached their sense of self to the struggle that got us where we are today. People who identify with their suffering resist attempts to fix it. Aggressively. Because if they sit with the idea that it could have ended years ago if only we had done X, that means they needlessly suffered. It makes them feel foolish, and small. The suffering has to mean something, other than that we were just grinding our gears.
silexia 5y ago
> Life is short and you don't get to learn more than a tiny fraction of the knowledge and skills available, so if you want to make really cool stuff then you need to spend most of your time on the highest-leverage options and spend only a little time on the lottery tickets. Solid gold advice, and this summarizes the whole article.

> It's ok to think that things have flaws or could be improved. But it's a trap to believe that solutions are trivial and everyone else is just too enfeebled of character to push the miracle button. I feel this so much. I've worked on products which many people insist could be done just as well by spreadsheets. I've worked in areas which people believe are overcomplicated - which they are - and therefore could be replaced with something simple. It is never that easy. I see it all the time in other fields and I just shake my head. If you ever find yourself saying "Why don't they just..?" you almost certainly don't understand the problem.

burnished 5y ago
I agree with you, but I also kind of hate that "Why don't you just..?" has become so tainted, because it is a great question to ask if you want to learn more about the heart of the matter. What went wrong when the 'obvious' solution was tried is interesting! Or, huh, just spitballing here, I suppose one could rephrase it as "have you considered..?" to ask the same question without the implicit assumption that the task is easy and the person being asked has overlooked something/is an idiot.
- nineplay 5y ago
  The problem specifically is "just". "Why don't they use containers instead of tarballs?" is a excellent question which can help you understand a system better. "Why don't they just use containers instead of tarballs?" strongly suggests that containers are obviously superior and there must be some flaw in the system that's keeping the tarballs around.
  - burnished 5y ago
    I think you are correct, thank you for pointing that out to me.
  - jfrunyon 5y ago
    "Just" suggests that containers appear better for the purpose at hand from the questioner's perspective. Which is also suggested by the question being asked at all.
  - musicale 5y ago
    I think "just" is supposed to imply that the proposed solution might be simpler or easier in some way, not that it's obviously superior overall. [Of course in the case of containers vs. tarballs ... it might actually make the system more complex and more difficult to implement, use, and maintain - something which might be nice to state explicitly along with the reasons why. >;-)]
- _carbyau_ 5y ago
  I agree with you that "questioning why" it generally a good thing for understanding. The issue here is one of communication, whereby the connotations of "just" may be taken differently by Asker and Responder. A Responder could take the use of "just" as implying "obvious thing you personally missed" which derides your efforts/understanding/intellect/ego. Whereas I see the use of "just" as saying something about the Askers mental model. The Asker knows their mental model says this is easy. The Asker knows you did not do [easy thing]. They want to know why there is a disparity. Anecdotally, I have been hobbying away when my wife walks in - is given a brief explanation of what I am doing - says "Why don't you just [xyz]?" She has limited information. She knows it. I know it. We both know her mental model is not like mine. But through her building it how she wants we can explore options. When she says "just" it is because her mental model says this should be easy. And sometimes I eat humble pie because it is. Because my mental model was built from scratch from a different direction and my perspective means I didn't see [easy thing]. Not often. But often enough that I appreciate every time my wife asks. Maybe the issue is who/how often you are asked the "just" question. Are you being bothered by too many people who don't-really-know/don't-really-care ? Then the Nth person coming up saying "why don't you just?" is another time/attention sapping interaction.
- tehnub 5y ago
  Post from a little while back where someone really really thought this through. IIRC, they concluded that there's no good way to ask it, lol. https://news.ycombinator.com/item?id=21675717 https://news.ycombinator.com/item?id=21675717
- jeffffff 5y ago
  i like to phrase this sort of question as "i'm assuming you considered this simpler solution, why was that not sufficient?" sometimes the answer is that they didn't consider it and now feel dumb for not thinking of it, but i've never seen anyone get defensive or offended or upset when phrasing it that way.
rnoorda 5y ago
> I see it all the time in other fields and I just shake my head. If you ever find yourself saying "Why don't they just..?" you almost certainly don't understand the problem. A political corollary to this that I enjoy came from an old professor of mine- "If your political opinions require large amounts of people to be stupid or evil, you don't understand the issues well enough." (A rough quote, I don't remember exact phrasing.)
- nineplay 5y ago
  I wish that was the banner at the top of every political discussion forum. Maybe with some auto-flagging on posts which can be condensed down to "everyone who disagrees with me is an idiot" The world would be a better place.
- codeisawesome 5y ago
  Hmm. But isn’t there some merit to the idea that groups of people behave differently when put together vs. how they would act individually?
  - deleted 5y ago
    [deleted]
- bryanrasmussen 5y ago
  this seems to discount historically known political movements in which almost everyone involved, with the benefit of hindsight, was obviously stupid or evil. Probably these are outliers, so also probably your professor's quote fits well enough most of the time, and only some of the time returns false when it should return true.
  - Jensson 5y ago
    Usually those movements intend to remove "evil" people. "We weren't evil, how can attacking evil people be evil?" You can see people say things like this even today. The evil in these cases was done by the people convincing the masses that the other group really is evil and needs to be attacked, not by the masses. The masses will attack and punish whatever they think is evil, everyone knows that, doesn't mean that they are evil, rather it is always evil to label large groups of people as evil since it encourages the masses to attack those.
TeeMassive 5y ago
https://xkcd.com/793/ https://xkcd.com/793/
dehrmann 5y ago
The other side of this is that kids don't know what's impossible yet.
anotherevan 5y ago
Isn't that the same people who say, "I could write that in a weekend..."?

ssivark 5y ago

Here’s a meta question to the author: Having been around the circuit once, do they at least feel a little more humble about their opinions this time around, or are they just as strong but only in a different direction? :-) IMHO, while the author has undoubtedly grown wiser, I think there’s just as much truth to their earlier opinions as the later ones; the value lies in being able to disambiguate the context in which each is valuable — not so much in trading one set of opinions for another. That humility, to me, is the bigger takeaway.

jamii 5y ago
It did take me a while to write this (~20 hours, I think) because I kept worrying about that exact problem, and I kept catching myself writing generic advice rather than concrete experiences. I tried as much as possible to only write things where I could think of multiple concrete examples in my own experience.
- mattbaker 5y ago
  Your writing was very good and the time you spent on it was clear to me, this was exceptional.
- dgb23 5y ago
  It reminded me of this: https://gist.github.com/prakhar1989/1b0a2c9849b2e1e912fb https://gist.github.com/prakhar1989/1b0a2c9849b2e1e912fb

Scarbutt 5y ago

Thanks for the reality slap and bucket of cold water buddy.

coyotespike 5y ago

As a new programmer, I was also seduced by the FP hype, and learned web development in ClojureScript without knowing JavaScript. This was a really hard way to learn, and once I finally went mainstream I found that the messaging about how bad other languages were was much exaggerated. In general I think the ecosystem trumps the language quality, and the senior developers who think otherwise generally underestimate the difficulty for a junior developer of working on the bleeding edge. Pragmatism over purity (while keeping enough purity-focus to keep the codebase clean). I also think JS is absolutely fine as a language and its warts are not that hard to work around.

rimliu 5y ago
JS may be fine, but I start do doubt the same can be said about the ecosystem.
- kansface 5y ago
  I really enjoy writing JS/TS - I find that eg arrow functions mixed with React allow for really concise and expressive solutions. You are correct about the ecosystem... maybe not per se, but that supply chain attacks are hopelessly intractable at the moment. How could you possibly go about writing a modern SPA that notionally cares about security when the third party software you must rely on is impossible to verify? I would love if browsers let you run JS in a sand boxed mode wherein you could just pass a bundle of vendored upstream software without the ability to touch the window, network, global state, etc.
- skinkestek 5y ago
  > JS may be fine, If you compare JS (not TS, TS is fine) and PHP (I have extensive experience in both) you'll find that once you go beyond the syntax on the top you'll find the same flaws in some form or another. Yes, PHP is uglier, but that is about it. > but I start do doubt the same can be said about the ecosystem. JS is a horrible language that works because of the tireless effort of its community that has created an ecosystem so rich that even JS can be programmed efficiently. The ecosystem might be flawed but it is the only reason why JS is usable at all.
5y ago

chubot 5y ago

Great article, I was nodding my head with almost every point! Although I think you also have to consider that the author has a strong math background, which both improves and warps your view of programming. If you don't know any math, then this post is probably less relevant to you (e.g. learning a bit Haskell or ML is probably a good idea in that case). ------ As a nitpick about the theory of automata, I would draw a big red line between regular languages and context free grammars. Regular languages have very useful engineering properties: they have predictable (linear) performance and give you "free" lookahead. (That is, nondeterminism is a math-y idea that many programmers are not comfortable with, but it's useful for engineering.) They are better than Perl-style regexes for building reliable and understandable systems, which "blow up" on a regular basis. In contrast, context-free grammars have almost no useful engineering properties by themselves. (There are subsets like LALR(1) that do, but they come with a bunch of tradeoffs.) As the article mentions, learning about recursive descent parsing first is probably more practical. Also, you're MUCH more likely to encounter a regular expression in real code than a context free grammar. In 15 years of professional programming I probably dealt with regexes on a weekly or monthly basis, but had to write or modify a grammar exactly zero times. It does help to be more familiar with regexes and regular languages. This post/sketch elaborates on related points: Comments on Eggex and Regular Languages http://www.oilshell.org/blog/2020/07/eggex-theory.html http://www.oilshell.org/blog/2020/07/eggex-theory.html

jamii 5y ago
> If you don't know any math ... learning a bit Haskell or ML is probably a good idea This is very much counter to the point I was making. I didn't find that learning haskell or ml was anything like learning math, especially the kind of math that I've seen people get use out of in day-to-day engineering, and I don't understand why this idea is so persistent. If you don't know any math, it might be worth learning some of whatever kind of math is applicable in your field. It's probably not haskell. > It does help to be more familiar with regexes and regular languages. Regexes are certainly useful, but I don't think that learning a lot about automata theory is a particularly efficient way to get better at using regexes in practice, compared to eg doing a bunch of drills on https://www.executeprogram.com/courses/regexes https://www.executeprogram.com/courses/regexes

ChrisMarshallNY 5y ago

> It's so easy to think that simple solutions exist. But if you look at the history of ideas that actually worked, they tend to only be simple from a distance. The closer you get, the more you notice that the working idea is surrounding by a huge number of almost identical ideas that don't work. This brings to mind, two of my favorite H. L. Mencken quotes: "There's always an easy solution to every human problem; Neat, plausible and wrong." "The fact that I have no remedy for all the sorrows of the world is no reason for my accepting yours. It simply supports the strong probability that yours is a fake." He was an acerbic S.O.B.

jerf 5y ago
Simple solutions do exist... it's just, they're simple, so people solve them very quickly and nobody else even has time to start processing them as a "problem". If people are still arguing about something ten years later, it's because it's not simple. But there's lots of stuff we don't argue about, because it's solved, because it was simple.
- ChrisMarshallNY 5y ago
  That's a very good point!
  - jamii 5y ago
    Now I have to figure out how to fit that into the flow of the article somewhere...
- habitue 5y ago
  Simple solutions can be really hard to find sometimes (you know P != NP and all that). The thing you're talking about is solutions that are simple to think of.

zubairq 5y ago

Hi Jamie, really nice piece of writing. I always enjoy reading about your work. Zubair

paganel 5y ago

> Being fluent in the core language of mathematics (basic logic I have been programming for a living for 15 years, I'm most definitely not as good a programmer as OP is, but the least I can do is double-vouch for that advice. I first heard it a little over 20 years ago, at the end of my first calculus class at uni. After scaring us, his students, about all the things that we will have to learn during the next semester I remember the professor telling us that we should be really learning what the NOT, OR and AND logical operators really do and stick that piece of information firmly in our heads, because that is really important for our jobs. He also bitched a little about our older colleagues for not remembering that stuff anymore (and causing different computer bugs because of that) and I remember saying to myself: "how stupid can one be in order to un-learn this stuff? It is easy!". Like I said, 20 years have passed since then and I found out that even though it's easy lots of people seem to forget how basic logic actually works when it comes to programming.

int_19h 5y ago
Statistics is another area where solid understanding of a few very basic concepts gets you far in a practical sense.

ithrow 5y ago

By way of counter-example, check out this ICFP contest retrospective. Nikita is using clojure, a pretty niche language, but has built up incredible fluency with both the language and the ecosystem so that he can quickly throw out web scrapers and gui editors. Whereas I wouldn't be able to quickly solve those problems in any language after flitting around from ecosystem to ecosystem for 12 years. The thing with niche languages like Clojure is that you can leverage existing ecosystems(reducing the risk of getting stuck) unlike other languages that start from scratch. Probably the same for languages like F#, Kotlin and even Zig (using the C ecosystem). Of course, I found the article great with lots of good advice(ex: I still wouldn't use Clojure if Javascript can get the job done perfectly fine) so don't let this nitpick distract you or look the other way ;)

unixhero 5y ago

If his baseline was Haskell. It was his first programming language. Then of course coding something else won't make him a better programmer. He is already a genious.

Jensson 5y ago

> Being fluent in the core language of mathematics (basic logic, sets, functions, proof techniques) makes it easy to pick up domain-specific tools when I need them eg statistical relational learning when working at relational.ai, bidirectional type inference for imp. I feel the most important part of learning higher math for programming is that you learn what it means for a statement to be true. Most people, even most programmers, don't really grasp that which makes most harder problems intractable to them as you can't build a stable tower on "basically true" statements. Also even higher math is all about creating new useful abstractions for solving new problems, that is basically the same kind of thinking as writing useful reusable programming libraries.

pikseladam 5y ago

I used to think working hard means working long time. I strongly disagree to that now. Overworking is almost certainly a sign for a bigger problem.

dgb23 5y ago

Peter Norvig in his essay "Teach Yourself Programming in Ten Years"[0] wrote this: > Learn at least a half dozen programming languages. Include one language that emphasizes class abstractions (like Java or C++), one that emphasizes functional abstraction (like Lisp or ML or Haskell), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), and one that emphasizes parallelism (like Clojure or Go). There is also similar advice from other well respected veterans. Being able to choose from a smallish deliberate set of languages that introduce some powerful concept each or have some unique reach. Then there is "Beating the Averages"[1] by Paul Graham. > A suspicious person might begin to wonder if there was some correlation here. A big chunk of our code was doing things that are very hard to do in other languages. The resulting software did things our competitors' software couldn't do. Maybe there was some kind of connection. I encourage you to follow that thread. There may be more to that old man hobbling along on his crutches than meets the eye. I think this hint is important and relates to the above. There are things that you can do in X, that are "very hard" to do in Y, probably vice versa. It is powerful and helpful to know a heterogeneous set of languages and tools. The distinction between say Java, C# or Typescript is almost arbitrary from a technical, real brain "juice" kind of perspective. The distinction between say SQL, C or Lisp however lets you see a problem in a whole different light as each introduce things you cannot do easily in the other. Example: Why does a particular Blub webapp suck? Because it runs slow, changes to it take too much time, it has data consistency issues that it moves to the user or introduces as bugs? Hint: There are solutions to these problems and some technologies make them just fall out, almost for free, if one has taken the time to learn them. I don't yell this down from an ivory tower. I say this as someone who has went through the pain repeatedly, because I and most people around me didn't get this. Pragmatism is not always "what everyone else does." And coming back to the article; I don't say the ecosystem and the culture around a language or platform don't matter. It is just one factor of many. When looking at these things I found it is _useful_ to consider languages (and so on) that are slightly niche and opinionated enough so they make particular things easy that would otherwise be hard. --- [0] https://norvig.com/21-days.html https://norvig.com/21-days.html [1] http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html

bitzlab 5y ago

Woow! https://natrmd.com https://natrmd.com There are so many things we should learn. For example, I personally want to learn how to grow my website traffic and this is why you see this comment! :D Cheers!

hinkley 5y ago

The tension here is that we all understand the concept of being 'too close to the problem'. It's the opposite fence-post from Dunning-Kruger, and the truth likes somewhere between them, not between DK and some center line. It's not universally the case that an unbiased observer is lacking critical details that explain why the problem hasn't been solved better. The observer has different frames of reference, one that might include wisdom from other problem domains that have already solved a similar problem. The observer is unbiased or differently biased. They have no sunk cost fallacy. They have not attached their sense of identity to the existing work. Best of all, they have not attached their sense of self to the struggle that got us where we are today. People who identify with their suffering resist attempts to fix it. Aggressively. Because if they sit with the idea that it could have ended years ago if only we had done X, that means they needlessly suffered. It makes them feel foolish, and small. The suffering has to mean something, other than that we were just grinding our gears.

silexia 5y ago

> Life is short and you don't get to learn more than a tiny fraction of the knowledge and skills available, so if you want to make really cool stuff then you need to spend most of your time on the highest-leverage options and spend only a little time on the lottery tickets. Solid gold advice, and this summarizes the whole article.