Forbidden Technology

post by lsusr · 2020-04-25T07:20:17.829Z · score: 23 (9 votes) · LW · GW · 5 comments

This is a question post.

Contents

  Answers
    8 lc
    3 Rudi C
    2 maximkazhenkov
None
5 comments

Do you benefit avoiding certain popular technologies? What alternatives do you use?


Some technology (like flashcards) is good for you. Some technology (like heroin) is bad for you. As technology advances, both kinds of technology are on the rise.

This is especially obvious with regard to information technology. Over the course of a few years, I ran a series of experiments to figure out which mediums [LW · GW] make my life better and worse. This culminated with a one-year commitment [? · GW] to abstain from the bad stuff.

I've found it improves my quality of life to avoid specific non-media technologies too:

Instead, I use the following alternatives:

Everything on my personal list of forbidden technology is a commercial product optimized for ease of use. My alternatives tend to be cheap or free, but also skill intensive. It could be that the learning curve keeps most people away.

But that's not what really kept me away from these things for most of my life. It's not like growing tomatoes is hard or antimemetic [? · GW]. The real reason I didn't grow tomatoes for so long was simply because I didn't know how much better homegrown tomatoes taste. Having tasted them regularly, it's hard to go back.

Answers

answer by lc · 2020-04-25T09:03:24.425Z · score: 8 (6 votes) · LW(p) · GW(p)

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.

comment by Smaug123 · 2020-04-25T17:33:29.566Z · score: 2 (2 votes) · LW(p) · GW(p)

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.

comment by lc · 2020-04-25T23:30:47.426Z · score: 1 (1 votes) · LW(p) · GW(p)

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.

comment by Quentin Crain (quentin-crain) · 2020-04-25T20:21:40.639Z · score: 1 (1 votes) · LW(p) · GW(p)

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.

comment by Smaug123 · 2020-04-30T20:27:02.712Z · score: 3 (2 votes) · LW(p) · GW(p)

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.

comment by Quentin Crain (quentin-crain) · 2020-04-25T20:27:30.418Z · score: 1 (1 votes) · LW(p) · GW(p)

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?

comment by lc · 2020-04-25T23:19:00.730Z · score: 2 (2 votes) · LW(p) · GW(p)

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.

comment by Smaug123 · 2020-04-30T20:18:29.357Z · score: 7 (4 votes) · LW(p) · GW(p)

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.

comment by lc · 2020-05-01T03:22:35.882Z · score: 1 (1 votes) · LW(p) · GW(p)

You are very funny and have convinced me maybe possibly to try haskell again. But only maybe.

comment by philh · 2020-04-27T12:12:51.899Z · score: 2 (1 votes) · LW(p) · GW(p)

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.)

comment by Quentin Crain (quentin-crain) · 2020-04-25T23:43:22.819Z · score: 2 (2 votes) · LW(p) · GW(p)

" 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!!???!!

comment by lc · 2020-04-25T23:51:28.016Z · score: 2 (2 votes) · LW(p) · GW(p)

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.

comment by lsusr · 2020-04-25T23:57:32.076Z · score: 1 (1 votes) · LW(p) · GW(p)

What startup do you work on?

comment by lc · 2020-04-26T00:08:56.600Z · score: 2 (2 votes) · LW(p) · GW(p)

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.

answer by Rudi C · 2020-06-23T11:20:26.441Z · score: 3 (2 votes) · LW(p) · GW(p)

I suggest you try Doom Emacs. I switched recently and refactored my entire config to it. It's much better than Spacemacs. Faster, less buggy, less cluttered.

I also urge other people to take this post with some healthy scepticism. There are a lot of costs in switching the mainstream with a niche product, and it is almost always a tradeoff that you need to consciously think about and keep evaluating its empirical results over time. On the example of emacs, I personally went from a person who didn't know much about CLIs and the shell to a person who is better than most on zsh scripting and knows some sysadmining. (Of course, emacs only pushed me in the right direction. It began the process, and I rolled with it because CLIs rock.) I lost a lot of time over emacs though. I spent days fixing broken configs that were fundamentally broken software that could never work stably. I also lost a lot of time finding emacs in the first place. I have tried a lot of alternatives (with each "try" wasting days by itself.). All in all, know that there usually are good reasons why something is staying niche. The trick is to find the niche products that are suitable for you.

answer by maximkazhenkov · 2020-04-26T02:04:32.554Z · score: 2 (2 votes) · LW(p) · GW(p)

For me, the exact the same list, but backwards.

5 comments

Comments sorted by top scores.

comment by Jay · 2020-04-26T00:18:30.555Z · score: 4 (4 votes) · LW(p) · GW(p)

Personally I avoid smartphones and tablets. I had a tablet briefly, but it just felt incredibly shallow. Instead I use a blackberry-style phone for calls and texts and a desktop computer for everything else. Also a Kindle Paperwhite, which is basically a tablet optimized for the sorts of content I prefer to consume (books).

comment by Demen · 2020-05-04T17:43:39.504Z · score: 2 (2 votes) · LW(p) · GW(p)

Lsur said that they tend to avoid desktop GUI based Operating systems for PC's, like all modern versions of windows, what's your opinion on such operating systems as they seem just as shallow as Android or IOS. But they are significantly more user friendly then text based operating systems.

comment by Jay · 2020-05-03T21:37:03.770Z · score: 1 (1 votes) · LW(p) · GW(p)

Desktop GUIs are simple, but a click or three can open software that's complex enough not to annoy me. Part of it is the screen; you can fit much more information on a large screen (obviously). Part of it is the input; keyboard and mouse gives you many more potential actions at any time than a touchscreen (given realistic limits). I will admit I disliked the Windows model at first, but I quickly realized that it worked pretty well.

comment by romeostevensit · 2020-04-25T07:59:18.799Z · score: 3 (2 votes) · LW(p) · GW(p)

Being strategic about taste has been of great benefit. If there's something I don't want a lot in my life, like desserts, I cultivate very picky taste. On the other hand if something would be very expensive to develop taste in, I intentionally avoid appreciating up market versions.

comment by Smaug123 · 2020-04-25T09:37:14.104Z · score: 2 (2 votes) · LW(p) · GW(p)

You can buy good tomatoes (in the UK); they're just a bit expensive. Cheap tomatoes are nasty, but nice tomatoes are widely available; I get them from a company called Isle of Wight Tomatoes, and they're on Ocado.