this post was submitted on 04 Nov 2023
96 points (86.4% liked)

Programming

17479 readers
221 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 1 year ago
MODERATORS
all 48 comments
sorted by: hot top controversial new old
[–] [email protected] 63 points 1 year ago (1 children)

Typing speed matters in programming the same way hammer hits per second matters when building a house. There's a little bit more to it.

[–] [email protected] 2 points 1 year ago (2 children)

Don't they use nailguns tho

[–] [email protected] 6 points 1 year ago (1 children)

Yes, but the best ones obviously use gatling nail guns.

[–] [email protected] 1 points 1 year ago (1 children)

It is the best one for houses vulnerable to quake damage. id rather avoid gatling nail guns though.

[–] [email protected] 1 points 1 year ago

It's also nice for keeping those pesky scrags away. Can't do carpentry on the Castle of the Damned without

[–] Anders429 44 points 1 year ago (4 children)

I'm a bit confused about the premise of the article. Does anyone assert that typing speed is a bottleneck at all? I've been in the industry for years, and have never heard that claim.

I do agree about the whole "less code is not always more", but I get confused when the author keeps bringing it back to typing speed.

[–] [email protected] 10 points 1 year ago

I've watched some slow typists program, and I think I have the answer. If it takes you a while to type the code out, you are much more likely to stick to the first approach that works, and not rewrite it as much.

[–] Piatro 5 points 1 year ago (1 children)

I've heard the argument as a positive of learning vim and while it did finally force me to touch type I can't say that it had any impact on my programming speed.

[–] [email protected] 2 points 1 year ago

Same. I think vim and touch typing are more about comfort tbh.

[–] [email protected] 2 points 1 year ago* (last edited 1 year ago)

The code that I suggest is too verbose. It involves too much typing.

This seems to be the whole premise and it's obvious that one does not follow from the other.

Overly verbose code is code that can be expressed more minimally for some benefit. I can't think why anyone would argue that one of those benefits is less typing.

The author can solve this easily though: ask them why verbosity is an issue. Then they will know the answer and won't have to presume something as tenuous as "amount of time spent typing".

[–] [email protected] 2 points 1 year ago* (last edited 1 year ago)

yeah the issue honestly is how much someone else has to read to understand your code. it's weird because the whole article is about making readable code for the next person and he never stops to address the fact that leaving 10x as much code to read might also make life more difficult.

I feel like he just wanted to make a point about how it's nice to make types immutable and suggest other techniques can be worth implementing too, which I agree with, but honestly his premise is a trainwreck.

[–] nous 42 points 1 year ago (2 children)

8,000 characters in five hours is 1,600 characters per hour, or 27 characters per minute.

This is irrelevant. Typing when coding is not evenly spaced out over those 5 hours. It is sporadic with most of the time thinking or reading documentation or reading source code and trying to figure out what you want to type. No good conclusions can be drawn from this logic and makes that whole part of the argument irrelevant.

If I were typing that slowly I would quickly forget what the hell I was even trying to do in the first place. Which is the bigger part - when you do need to type you want to quickly get the ideas you have down as fast as you can think them. Going too slow can cause your mind to wander and that can really hamper your productivity.

There is also the cost of context switching. And it is a context switch to go from writing ideas down to making sure I have all the boiler plate and syntax correct. The less of the need for doing that the better IMO.

And TBH I don't really understand the rest of their arguments. They introduce two bits of code, one very short simple class then one with lots of helper methods to set various things while creating a new object. And then concludes with a short paragraph on some real benefits without really explaining why. With the whole paragraph being more of an argument about immutable code being better rather than longer vs shorter code. Then follows up with an entire section on why his code increases maintenance as refactoring requires more points to update with his immutable code and thus prefers languages like F# where the immutable version is a one liner... Which defeats the whole argument that typing is not the bottleneck? I really don't follow his logic here.

Apparently, it has to be explicitly stated: Programmer productivity has nothing to do with typing speed.

I feel they have completely failed to convince me of this fact. Despite me already thinking it is not one of the more important factors of productivity and there are better things to optimise around.

My opinion is that code length is not that important a factor, but you should not go hog while and write the longest things you can either. Every extra bit of code should add some value somewhere. Like taking his examples, spending a bit of time writing the immutable version here lets you reduce the amount you need to write when using that code. Which is a trade-off that can be worthwhile - increasing typing now for reducing typing later. But also the reduced typing makes the where the code is used easier to read and clearer as to what is happening, get a copy of the object with one field updated. That is a nice concept to have and read. Without the need to refer to all the fields every time you want a copy.

[–] [email protected] 12 points 1 year ago (1 children)

Is it possible to be a productive programmer with slow typing speed? Yes. I have met some.

But…can fast typing speed be an advantage for most people? Yes!

Like you said, once you come up with an idea it can be a huge advantage to be able to type out that idea quickly to try it out before your mind wanders.

But also, I use typing for so many others things: writing Slack messages and emails. Writing responses to bug tickets. Writing new tickets. Documentation. Search queries.

The faster I type, the faster I can do those things. Also, the more I’m incentivized to do it. It’s no big deal to file a big report for something I discovered along the way because I can type it up in 30 seconds. Someone else who’s slow at typing might not bother because it’d take too long.

[–] [email protected] 4 points 1 year ago (1 children)

Also m, while I agree typing speed is an advantage, there’s nothing stoping you from laying out the whole program on paper or with psudo code and then filling it in which can reduce the need to keep it all in your head

[–] nous 3 points 1 year ago

IMO trying to write everything out in psudo code first is way slower. You are writing things out twice and you are not able to run things quickly. You just have to hope you got things right on the first pass and cannot quickly adjust things when you don't.

I prefer constant feedback from my editor, compiler and test framework to write things quickly and make sure I am not doing something that is fundamentally flawed. There is nothing worst than writing a whole program without running it only to run it and realise nothing is working how you thought it should.

[–] [email protected] 1 points 1 year ago

I type slowly so i just write my ideas down on paper first

[–] [email protected] 27 points 1 year ago (1 children)

I discovered this very quickly after breaking a finger. One-finger typing didn't slow me down at all. Turns out my brain was the bottleneck.

[–] miguelw -1 points 1 year ago
[–] lysdexic 14 points 1 year ago* (last edited 1 year ago)

From the article:

(...) but recently, another type of criticism seems to be on the rise.

The code that I suggest is too verbose. It involves too much typing.

This reads like a one-sentence strawman. Describing code as "too verbose" is really not about the risk of carpal tunnel syndrome. It's about readability and cognitive load.

The blogger seems to almost get the point when he writes the following:

In short, the purpose of source code is to communicate the workings of a piece of software to the next programmer who comes along. This could easily include your future self.

The purpose of source code is to communicate (...) to the next programmer who comes along.

If you make the mistake of going the "enterprise quality java code" meme approach, you're making the next programmer's life needlessly harder.

The blogger then tries to make his case with verbose code, and makes the following statement:

Which alternative is better? The short version is eight lines of code, including the curly brackets. The longer version is 78 lines of code. That's ten times as much.

I prefer the longer version. While it takes longer to type, it comes with several benefits. (...)

This is yet another strawman. The longer version is awful code, not because it's longer but because it's needlessly jam-packed of boilerplate code. Ignorign basic things like interfaces and contracts, It's been proven already that bugs in code are directly proportional to the number of lines of code, and thus the code the author prefers is likely to pack ten times more bugs.

The shorter code in this case would not be the 78-loc mess that the author picked as the thing he prefers. The shorter code in this case would be something like onboarding the project onto Project Lombok to handle all-args constructors, property methods, and even throw a builder in for free. This requires onboarding Lombok to the project, and add two annotations to the short example. Two lines of code, done.

After the blogger fails to make his case, he doubles down on the typing non-sequitur:

Perhaps you're now convinced that typing speed may not be the bottleneck (...)

This is a blog post that fails to justify a click. It's in the territory of "not even wrong".

[–] [email protected] 12 points 1 year ago (1 children)

Assuming this is C#, you could just make Reservation a record type, which can be defined with a one line primary constructor, is immutable and has value type equality. Second example is an insane amount of boilerplate.

[–] [email protected] 3 points 1 year ago

And you can use the with expression to create clones of the object with some properties modified.

[–] [email protected] 11 points 1 year ago (2 children)

Wrong. Yes, typing speed does not matter when counting up lines of code. Code programmers however are not just code monkeys. They write documentation and comments, communicate with peers and potentially users, take notes on their own thoght processes when pondering on the best solutions for hard problems, etc. On all of these point and many more, typing speed matters. People who can type and type fast(-ish) communicate more expressively, document more comprehensively, make less mistakes when spelling, etc.

So yes, typing skill matters.

[–] UndercoverUlrikHD 11 points 1 year ago (1 children)

People who can type and type fast(-ish) communicate more expressively, document more comprehensively, make less mistakes when spelling, etc.

That's just pure conjecture on your part though

[–] [email protected] -4 points 1 year ago (1 children)

Sure, if you regard scientific studies and statistics as conjecture, then your right, it's pure conjecture.

[–] UndercoverUlrikHD 8 points 1 year ago

Happy to be proved wrong if you cite your scientific sources though.

[–] [email protected] 4 points 1 year ago

People who can type and type fast(-ish) ... make less mistakes when spelling, etc.

I wish.

-Guy who types over 100WPM but still makes a lot of spelling mistakes.

[–] onlinepersona 6 points 1 year ago (1 children)

I agree, typing is not a bottleneck, repeating yourself is. All that boilerplate code in the example, shouldn't have to be written. It's wasted time.

[–] philm 1 points 1 year ago (2 children)

The curse of OOP (java style...).

I mean why do you need to write getter and setter methods. I have wondered at the beginning of university 10 years ago, and am still wondering why you would need something like that...

[–] [email protected] 9 points 1 year ago (1 children)

You let your ide generate simple getters and setters or utilize something that generates them during a compilation process.

Who ever writes them per hand needs to utilize their tooling better or needs better tooling.

[–] philm 3 points 1 year ago (1 children)

Yeah but why do I have to use an IDE to generate getters and setters in the first place? It just adds up to more mental overhead, because my brain has to process this boilerplate somehow, even if my IDE can generate it (I know it's simple code, but it's even simpler to not have that boilerplate code at all).

[–] [email protected] 3 points 1 year ago (1 children)

Access control and offering a sound interface.

You don't need getters and setters if every attribute is public, but you might want to make sure attributes are accessed in a specific way or a change to an object has to trigger something, or the change has to wait until the object is done with something. Java just has tools to enforce a user of your objects to access its attributes through the methods you designed for that. It's a safeguard against unintended side effects, to only open up inner workings of a class as littles as necessary.

In a language without something like private attributes you'd have to account for far more ways someone might mutate the state of objects created by your code, it opens you up to far more possible mistakes.

[–] philm 1 points 1 year ago (1 children)

I'm totally aware of the benefits of encapsulation, but the way java does it seems so unnecessarily boilerplatey (C# is better, functional programming makes encapsulation even simpler, but that's a different paradigm...)

I like how Rust approaches this via the module system and crates (you have pub for the public interface, pub(crate) for crate/lib wide access and no modifier for being only allowed to access in the current module and submodules of that module)

[–] [email protected] 2 points 1 year ago (1 children)

Not to aware of how c# works, or interested in defending java, especially ancient java versions, but what does it do better in that regard?

Only records for more or less pure data objects come to mind, but those are also in modern Java.

[–] philm 3 points 1 year ago (1 children)

It has Properties (basically syntax sugar...)

[–] [email protected] 1 points 1 year ago

And it's so good that Kotlin adopted them too in their journey to fix Java.

[–] [email protected] 1 points 1 year ago (1 children)

I write Java for a living and the places I’ve worked have used Lombok to cut down on the boilerplate code

[–] philm 1 points 1 year ago (1 children)

My condolences, haha (I'm honestly not a big Java lover ^^).

[–] [email protected] 1 points 1 year ago

It’s not so bad. I’m just a lowly webdev and my work with Java is mostly just basic CRUD operations

[–] [email protected] 4 points 1 year ago

Are people, their critics, really bothered with the writing aspect of verbose code?

Verbose code - and their example shows it quite well - is less concise. To me, their example and reasoning looks more overly verbose, over-engineered rather than well or thoroughly designed and safe.

What makes more sense depends on the context. Where is and will it be used? What is it being exposed to?

A simple data holding class for one "internal" layer to the next can have a very simple form, so it's easily understood. It may not be safe against misuse or mistakes, but the simplicity and clear use-case and intention much outweighs those costly safeguards to me. For maintainability, for readability, for clarity.

It's always a balancing act between simplicity and easy understanding vs safeguards and costs. If there's less risk you can make it much simpler - which reduces other, less obvious risks and costs.


The example made me immediately spot how C# quite a while ago introduced language constructs for what would otherwise be a lot of boilerplate programming like they do in their example.

public record Reservation(DateTimeOffset Date, string Email, string Name, int Quantity, bool IsAccepted);

no need for 78 lines of code with 9 methods.

C# also has the with keyword for copy-adjusting immutable types.

And required init syntax provides another alternative for an effectively immutable type.

public class Reservation
{
    public required DateTimeOffset Date { get; init; }
    public required string Email { get; init; }
    public required string Name { get; init; }
    public required int Quantity { get; init; }
    public required bool IsAccepted { get; init; }
}
[–] [email protected] 1 points 1 year ago

Even less so now that docstrings can be mostly written by AI

[–] [email protected] 1 points 1 year ago

Why would it be? It's one of the only ways to use your pc

[–] [email protected] 1 points 1 year ago

it's not a bottleneck to writing good code anyway