10 ms·

Barriers to entry are invisible. They are invisible to people on the inside and most frequently invisible to people who have a hand in creating those barriers.

Barriers to entry are invisible. They are invisible to people on the inside and most frequently invisible to people who have a hand in creating those barriers. I once had a conversation with a founder about their signup flow. This founder had aspirations to be a global player. They said that step 2 of their flow included entering a credit card number. I had to stop them. "What about people who don't use credit cards?" They were nonplussed. "You know, China, much of Africa ..." they had never actually thought about whether people had credit cards because every single person they interacted with had one. Back to languages. If you've never taught an introduction to computer programming for a general audience you are blind to what does and does not matter about a language. You look at things like `foo.bar()` and think "Yeah that's a simple method invocation" and have no idea how many people you just lost. Never underestimate how much ease of use matters. We, as a community, have selected for decades against people who care about language ergonomics because they get hit in the face with a wall of punctuation filled text and turn away. We fight over where braces belong while not realizing how many hundreds of thousands of people we've excluded. Ease of use is the most important part of a language. It's just that the barriers to entry are invisible and so the people who happen to be well suited to vim vs emacs debates get to talk while the vast majority of potential programmers are left on the outside. We create barriers to entry accidentally because we design for people like us. To us the barriers are invisible.

onlydeadheroes 6y ago
I agree completely and I would add that the less mental effort you are spending on your language, the more you are using on your problem. This can have big effects on code and design quality, and allow you to grasp harder problems.
solosoyokaze 6y ago
A programming language is a tool. I don’t think it should really be optimized or designed around how easy it is to teach someone who is at step zero, basic programming concepts. I do think Go is a decent language to teach up and coming professional devs precisely because it doesn’t hide the real complexity of what’s going on, but I’d probably opt for something a bit higher level as the absolute intro to programming.
- itake 6y ago
  I've been coding for 10+ years in primarily ruby and python. I switched to golang recently for work. While its an interesting language, it takes forever to express what I want the code to do, unlike the previous languages. Go's simplicity forces developers to introduce insane amounts of complexity.
  - solosoyokaze 6y ago
    Ruby and Python are notorious for being difficult to read because of all the foot guns in place. Monkey patching, duck typing, metaprogramming... and that's not even talking about structural limitations like the GIL. Go is definitely more verbose and less "fun" to write, but it's 10X easier to reason what's going on in a large application. Of course, it's also the correct kind of solution for some types of problems. If you need a compiled language (many do), the competition to Go isn't Ruby and Python, it's C++ and Rust.
    - cb321 6y ago
      Or Nim or Zig or ... Actually, I feel like Zig may be most in the compiled-but-keep-it-simple-like-C headspace as Go. I don't know either Go or Zig super well. From what I do know, Zig seems not quite as stubborn as Go about forcing code to be "simple to reason about" (which is also subjective, though maybe less so than "easy to do things").
      - dnautics 6y ago
        I would say Zig is interesting in that "safe things are easy and pretty", "unsafe things are difficult and ugly", thus drawing eyes to the code that needs it. It's four lines of nasty looking code for me to convert a slice of bytes to a slice of (f64/f32/i32)... Which the compiler no-ops. This is dangerous because the alignment and byte count must be correct.
      - solosoyokaze 6y ago
        I would say both of those are interesting languages, but lack the amazing standard lib of Go and definitely the tooling and industry support. Personally, I find Swift to be a really great language, but can't deal with the Apple eco-system, XCode, raw Linux support...
sangnoir 6y ago
Programming has and almost infinite depth to it, depending on the complexity you are tackling/modeling. In a way, it is like mathematics in the way you have layers acting as foundations/abstractions for more complex representation. Introduction to mathematics is counting discrete things, then the number line, addition, which is a foundation for/abstracted by multiplication, which is in turn a foundation for/abstracted by exponents, etc. and in no time, you're at the level of multi-variate calculus and n-dimensional hypercubes. Each level requires notation that is concise (so it can fit in short-term memory to be actually useful) - one cannot expect graduate-level mathematics to share the same notation/symbols as beginner (elementary) maths. Programming languages have to trade off which level they are biased towards, I do not believe in a universal language that is both easy for beginners while being concise for advanced users. Back on topic - Go is not an easy language, it is a simple language, those 2 things are not the same.
- Zababa 6y ago
  > Back on topic - Go is not an easy language, it is a simple language, those 2 things are not the same. I often see this point here, but I always wonder what people mean by it. Could you elaborate on that point?
  - sangnoir 6y ago
    To me, what makes Go simple language is limited set of building blocks, and being very opinionated - this mostly relates to syntax and what the core language provides out of the box. With Go, you only need to understand looping, branching, channels, slices and you're mostly good to go. Ease is measured by how a language may be used to solve a problem. As an example, text-wrangling with Perl is easy - but you may have to do it using complex (i.e. not simple) representation. Back to Go - channels are a simple concept, but are not (always) easy to work with if you do not put a lot of thought into your concurrency model. Edit: I just thought of another way to express the difference between "simple" and "easy". The notation of adding "1+1=2" is simple, however proving that "1+1=2" is not easy (at least at the level of elementary students).
  - epicide 6y ago
est 6y ago
> You know, China Another thing I find very interesting is Go is very popular in China https://blog.jetbrains.com/go/2021/02/03/the-state-of-go/ https://blog.jetbrains.com/go/2021/02/03/the-state-of-go/ the US ranked #7, it barely had more devs than say, Belarus.
- edoceo 6y ago
  But the metric was credit cards in China
jodrellblank 6y ago
I don't think you can write that much of a rant using the term "ease of use" without explaining your view on what "ease of use" is; does "use" really only mean a beginner using it for the first time? You mention languages with punctuation, what alternatives do you see instead? You claim "ease of use is THE most important part of a language", but why is it the most important?
numlock86 6y ago
> "What about people who don't use credit cards?" > "You know, China, much of Africa ..." Oh, you don't even have to go that far. Of all the people I know maybe 1 out of 10 has a credit card. The irony in regard to your post: Most of them got one because "it was needed for something online" at some point. This is in Germany.
- svara 6y ago
  Maybe your sample is really biased, but the actual credit card ownership rate in Germany in 2017 was 53% and growing YoY, so it's likely quite a bit higher by now. https://www.statista.com/statistics/865943/credit-card-ownership-rate-germany/ https://www.statista.com/statistics/865943/credit-card-owner... You may need to copy & paste the title of that page into Google and access the page from there to see the data.
joshspankit 6y ago
> Back to languages. If you've never taught an introduction to computer programming for a general audience you are blind to what does and does not matter about a language. You look at things like `foo.bar()` and think "Yeah that's a simple method invocation" and have no idea how many people you just lost. I keenly remember in college when they were first starting to teach me C++ and I asked something like “Ok: I hear what you’re saying that this is a function, and that’s a parameter, but my question is how does the computer know that you’ve named it [whatever the variable name was]? The teacher had no understanding that this was a conceptual barrier. Of course now I know that the answer is “because order of the syntax tells it so“, but stuff like that made those classes much harder than they needed to be.
cannabis_sam 6y ago
> Barriers to entry are invisible. They are invisible to people on the inside and most frequently invisible to people who have a hand in creating those barriers. I just want to say that I really, really like this phrasing. I have a lot of opinions on how programming languages could be improved, and however much I disagree with Rob Pike on types, I still think Go hit a real sweet spot.
allenu 6y ago
> Ease of use is the most important part of a language. It's really a matter of who your target audience is and what they're trying to achieve, though, isn't it? You might make a language easy for the whole world to use, but simultaneously make it hard for specific tasks. Likewise, a language might be easy to use for experts who are trying to achieve a specific task, but difficult for newbies. That's totally okay. BASIC was super easy to understand and helped me get into programming, but there's no way I would use it for anything serious today.
rowanG077 6y ago
I feel completely the opposite. While I do agree that we should make the barrier to entry as low as possible. A lot of times the barrier to entry is in conflict with the usefulness of a tool. We should lower the barrier to entry without losing any usefulness and not any further.

onlydeadheroes 6y ago

I agree completely and I would add that the less mental effort you are spending on your language, the more you are using on your problem. This can have big effects on code and design quality, and allow you to grasp harder problems.

solosoyokaze 6y ago

A programming language is a tool. I don’t think it should really be optimized or designed around how easy it is to teach someone who is at step zero, basic programming concepts. I do think Go is a decent language to teach up and coming professional devs precisely because it doesn’t hide the real complexity of what’s going on, but I’d probably opt for something a bit higher level as the absolute intro to programming.

itake 6y ago
I've been coding for 10+ years in primarily ruby and python. I switched to golang recently for work. While its an interesting language, it takes forever to express what I want the code to do, unlike the previous languages. Go's simplicity forces developers to introduce insane amounts of complexity.
- solosoyokaze 6y ago
  Ruby and Python are notorious for being difficult to read because of all the foot guns in place. Monkey patching, duck typing, metaprogramming... and that's not even talking about structural limitations like the GIL. Go is definitely more verbose and less "fun" to write, but it's 10X easier to reason what's going on in a large application. Of course, it's also the correct kind of solution for some types of problems. If you need a compiled language (many do), the competition to Go isn't Ruby and Python, it's C++ and Rust.
  - cb321 6y ago
    Or Nim or Zig or ... Actually, I feel like Zig may be most in the compiled-but-keep-it-simple-like-C headspace as Go. I don't know either Go or Zig super well. From what I do know, Zig seems not quite as stubborn as Go about forcing code to be "simple to reason about" (which is also subjective, though maybe less so than "easy to do things").
    - dnautics 6y ago
      I would say Zig is interesting in that "safe things are easy and pretty", "unsafe things are difficult and ugly", thus drawing eyes to the code that needs it. It's four lines of nasty looking code for me to convert a slice of bytes to a slice of (f64/f32/i32)... Which the compiler no-ops. This is dangerous because the alignment and byte count must be correct.
    - solosoyokaze 6y ago
      I would say both of those are interesting languages, but lack the amazing standard lib of Go and definitely the tooling and industry support. Personally, I find Swift to be a really great language, but can't deal with the Apple eco-system, XCode, raw Linux support...

sangnoir 6y ago

Programming has and almost infinite depth to it, depending on the complexity you are tackling/modeling. In a way, it is like mathematics in the way you have layers acting as foundations/abstractions for more complex representation. Introduction to mathematics is counting discrete things, then the number line, addition, which is a foundation for/abstracted by multiplication, which is in turn a foundation for/abstracted by exponents, etc. and in no time, you're at the level of multi-variate calculus and n-dimensional hypercubes. Each level requires notation that is concise (so it can fit in short-term memory to be actually useful) - one cannot expect graduate-level mathematics to share the same notation/symbols as beginner (elementary) maths. Programming languages have to trade off which level they are biased towards, I do not believe in a universal language that is both easy for beginners while being concise for advanced users. Back on topic - Go is not an easy language, it is a simple language, those 2 things are not the same.

Zababa 6y ago
> Back on topic - Go is not an easy language, it is a simple language, those 2 things are not the same. I often see this point here, but I always wonder what people mean by it. Could you elaborate on that point?
- sangnoir 6y ago
  To me, what makes Go simple language is limited set of building blocks, and being very opinionated - this mostly relates to syntax and what the core language provides out of the box. With Go, you only need to understand looping, branching, channels, slices and you're mostly good to go. Ease is measured by how a language may be used to solve a problem. As an example, text-wrangling with Perl is easy - but you may have to do it using complex (i.e. not simple) representation. Back to Go - channels are a simple concept, but are not (always) easy to work with if you do not put a lot of thought into your concurrency model. Edit: I just thought of another way to express the difference between "simple" and "easy". The notation of adding "1+1=2" is simple, however proving that "1+1=2" is not easy (at least at the level of elementary students).
- epicide 6y ago

est 6y ago

> You know, China Another thing I find very interesting is Go is very popular in China https://blog.jetbrains.com/go/2021/02/03/the-state-of-go/ https://blog.jetbrains.com/go/2021/02/03/the-state-of-go/ the US ranked #7, it barely had more devs than say, Belarus.

edoceo 6y ago
But the metric was credit cards in China

jodrellblank 6y ago

I don't think you can write that much of a rant using the term "ease of use" without explaining your view on what "ease of use" is; does "use" really only mean a beginner using it for the first time? You mention languages with punctuation, what alternatives do you see instead? You claim "ease of use is THE most important part of a language", but why is it the most important?

numlock86 6y ago

> "What about people who don't use credit cards?" > "You know, China, much of Africa ..." Oh, you don't even have to go that far. Of all the people I know maybe 1 out of 10 has a credit card. The irony in regard to your post: Most of them got one because "it was needed for something online" at some point. This is in Germany.

svara 6y ago
Maybe your sample is really biased, but the actual credit card ownership rate in Germany in 2017 was 53% and growing YoY, so it's likely quite a bit higher by now. https://www.statista.com/statistics/865943/credit-card-ownership-rate-germany/ https://www.statista.com/statistics/865943/credit-card-owner... You may need to copy & paste the title of that page into Google and access the page from there to see the data.

joshspankit 6y ago

> Back to languages. If you've never taught an introduction to computer programming for a general audience you are blind to what does and does not matter about a language. You look at things like `foo.bar()` and think "Yeah that's a simple method invocation" and have no idea how many people you just lost. I keenly remember in college when they were first starting to teach me C++ and I asked something like “Ok: I hear what you’re saying that this is a function, and that’s a parameter, but my question is how does the computer know that you’ve named it [whatever the variable name was]? The teacher had no understanding that this was a conceptual barrier. Of course now I know that the answer is “because order of the syntax tells it so“, but stuff like that made those classes much harder than they needed to be.

cannabis_sam 6y ago

> Barriers to entry are invisible. They are invisible to people on the inside and most frequently invisible to people who have a hand in creating those barriers. I just want to say that I really, really like this phrasing. I have a lot of opinions on how programming languages could be improved, and however much I disagree with Rob Pike on types, I still think Go hit a real sweet spot.

allenu 6y ago

> Ease of use is the most important part of a language. It's really a matter of who your target audience is and what they're trying to achieve, though, isn't it? You might make a language easy for the whole world to use, but simultaneously make it hard for specific tasks. Likewise, a language might be easy to use for experts who are trying to achieve a specific task, but difficult for newbies. That's totally okay. BASIC was super easy to understand and helped me get into programming, but there's no way I would use it for anything serious today.

rowanG077 6y ago

I feel completely the opposite. While I do agree that we should make the barrier to entry as low as possible. A lot of times the barrier to entry is in conflict with the usefulness of a tool. We should lower the barrier to entry without losing any usefulness and not any further.