My hot take: Vi, make and C would have gone the way of COBOL a long time ago if it wasn’t for a lot of programmers thinking “my tools are more difficult to use, hence I’m a better programmer”.
Yeah, its so much more interesting to edit code with only your keyboard. Always switching back and forth from mouse to keyboard is just too cumbersome.
Bonus points for Neovim: It made me understand my tools (LSP, linting, CLI tools, TUI etc…)
Upvoted for make and c, highly disagree on vi/vim though. It’s significantly nicer not having to use a mouse for 95% of my work. Need to delete between two quotations to replace it? v, i, ", d does it. Whole line? d, d. Beginning of end of document? G or gg. There are keyboards to streamline just about any movement or operation, and none involve the mouse. I still need the mouse for clicking stuff in vs code, but that’s mostly just when committing.
Side shout out to emacs, it’s lost popularity over time, but it can do just about anything
Emacs editor commands are kind of clunky, you hold Ctrl or alt a lot and the movement commands are less intuitive and smooth than vi/vim keyboards imo. I’ve heard it described as: emacs has a text editor, vim is a text editor. Vim is great at editing and moving around in documents, selecting and editing text, and basically anything editor based. Emacs can do notes (org mode, linking notes, searching notes, etc), web browser, file browser, git (better git interface than vim), calendar, agenda, music playing, email… and that’s all without plugins
As a person uses neovim, make and exclusively programs in C I am indeed triggered. Maybe you could argue Make and C are hard but Vi definitely is not (atleast the basics aren’t).
I use the unholy IdeaVim and honestly… I love it. I won’t pretend that interacting with a heavy IDE while using vim is a great idea, but it makes editing so much more comfortable.
Also while you can use something like nano for editing files in the terminal, vi(m) is much faster for more in-depth editing.
TDD is overrated. Code coverage is extremely overrated. Both of these tend to lead to a morass of tests that prove the compiler works at its most basic level while simultaneously generating a surplus of smugness about the whole situation.
Tests have their place. Tests can be, and often are, valuable. But the easier the test is to write, the easier it would’ve been to just encode it into the type system to begin with.
Yeah creating tests for every single method is insane. If a feature changes it’s more difficult you either have to figure out how to implement the change without changing the method, or you change the method and have update the unit test. But if you’re constantly updating the unit tests, how do you know if you might’ve broken something else that the test was intended for.
It’s way better just to do integration tests that match the feature request. That way the feature that someone asked for will continue to work even if you decide to refactor the code.
Unit tests are only worthwhile if you refractor code or write the unit tests before writing the code. We started adding unit test for most everything where I work and I think it’s far more effort than it’s worth. It’s not that it catches nothing but it catches so little I don’t think it’s worth the time spent writing them.
I don’t think you understood my point. That’s exactly why I think unit tests aren’t all that useful. Most code changes require updating the unit tests so unless you change the unit tests first all that’s being done is saying, yep this works how I programmed it to work.
TDD as in religion is overrated. TDD done right is IMHO extremely effective.
The problem is, writing good tests is really hard, and I have seen/committed/experienced a lot of bad tests… just the top of my mind problems with TDD done wrong:
testing the implementation instead the interface
creating a change detector
not writing / factoring the tests in a good way
writing tests / TDD w/o having an overall design for the software
For every non trivial piece of software written w/o TDD, I always saw the same pattern: First few hours/days/weeks, rapid progress compared to TDD, afterwards: hours/days/weeks wasted in debugging, bug fixing etc… and the people can not even catch up with tests if they wanted.
Is TDD always the answer? Of course not, it is a tradeoff like everything else in technology. OTOH I have yet to see a project which benefited from not using TDD by any metric after a few days in.
Tools that use a GUI are just as good (if not better) than their CLI equivalents in most cases. There’s a certain kind of dev that just gets a superiority complex about using CLI stuff.
Indeed, the problem with gui apps is when you can’t script them!
I always loved alfred on osx, then loved scripting rofi on linux, only to come back to osx years later and find alfred can’t be invoked with stdin options. It’s damn shame….
I used to think something like this when I was younger. I spent an inordinate amount of time looking for good gui versions of cli tools. I have come to understand that this is not usually the case and cli tools are more convenient much of the time. I would not classify this as superiority complex, unless I’m being a jerk about it. I don’t care what you use, I just use whatever has the lowest barrier to entry with the most standardization, which is usually the original cli tool.
I agree only when your job function is specifically geared around those tools… Otherwise high quality guis are more valuable.
Just because I can do everything in gdb that I can do in visual studio doesn’t mean 99% of most debugging tasks isn’t easier and faster in visual studio. Now if my job was specifically aimed at debugging/reverse engineering there are certain things that gdb does better on the CLI… But for most software devs… CLI gdb isn’t valuable.
That’s the gold standard as far as I’m concerned. Haven’t used the ytdlp-gui yet, but it’s simple stupid… I might want a few more switches (more exactly the extract audio/subtitles) to turn
There are some massive intrinsic advantages of the CLI though, that apply for everyone, not just leetcoders:
The terminal can remember everything you ever did. Forgotten the command you wrote 2 months ago? You can do a search for it with a tool like fzfand run the exact same command again.
Communicating with others. GUI programs require step by step instructions, often accompanied by screenshots while CLI may be copy/pasted.
Combining programs together. There are a few different techniques for combining CLI programs to search/format output, use secrets without ever having them in the clipboard or on disk, monitor something frequently/constantly etc etc
So while I agree with you that there’s plently of elitism around the CLI, you do yourself a disservice if you try to avoid it.
Just no. CLI can be automated, which makes it superior. It’s not a superiority complex, it’s a fact. I’m not a minimal wage worker pushing buttons I don’t understand. I’m not a technician who learnt your shitty software to do the most basic tasks.
Aside from automation, CLI can support significantly more complicated apps reliably. It can also be tested more reliably.
GUIs are better for anything simple, and good UX designers can make a moderately complex one, but anything like server administration/git/configs are 100x better on CLI
This depends a lot on the GUI and the tool. Some cli tools are great alone or for accepting, others benefit from the extra attention to us and exposure of options that a GUI can offer
For git in particular, I encourage juniors to learn and use the CLI. I find that GUI git clients often do some or all of the following:
Use non-git terminology that ends up being confusing. “Sync” comes to mind as a frequent offender, I can think of several incompatible things that could refer to.
Ignore the useful ability to stage your changes
Don’t permit or encourage a review of the changes
Implement only the basics and make remediation of branching issues difficult
In the worst case, I’ve seen people end up using the git GUI like a “save” button, blindly commiting and pushing the current state of their code, including to-be-removed print statements and other cruft. Yeah, git cli is a bit complex compared to that, but you gain a lot for that added complexity.
That said, I’ve definitely jumped into a git GUI from time to time just for a visualization of whenever branching snafu I’m trying to untangle. None of the above invalidates GUIs if you take care to still understand the underlying tool properly!
We use too many libraries. This may be an actual unpopular opinion though. I find that the more a library tries to do, and the more dependencies it has itself, the more hesitant I am to use it. It just feels like a tower of cards ready to fall at any moment.
I’m not a very trusting person and work alone though so this might just be an emotional decision. But it is nice having a project be composed of code that does just what is needed and nothing else. It makes it easier to fix bugs and especially to maintain the code.
I do use libraries, but only if they’re absolutely necessary or if they’re very focused and don’t try to do a million things. It’s not about size but complexity.
I also feel better when I use less libraries, even if that may seem irrational sometimes.
I think part of the library craze stems from people who really only want to use the programming language as a tool to get fast results (which is legitimate, of course).
For example in academic contexts you have a lot of scientists who use R with a whole truckload of libraries, often unnecessarily. It reminds me of the plugin craze in the whole wordpress can of worms…
I’m not a very trusting person and work alone though so this might just be an emotional decision. But it is nice having a project be composed of code that does just what is needed and nothing else. It makes it easier to fix bugs and especially to maintain the code.
And that’s one of the reasons microservices are a thing.
I disagree (mostly). What’s the difference between library and language built-in? PHP and C++ has a ton of built-ins. It doesn’t make it less complex than using library.
Problems that look simple at the first glance are in most cases are complex with too many edge cases.
I think I have never written a single utility function that had no non-obvious bug, and imagine that in more complex problems
Not to mention in many cases any function you write is possibly dangerous.
Just take a look how many things you have to consider when checking for odd number in JS:
The difference is I trust the language. That’s one source I have to trust. With libraries I have to trust a ton of sources.
What I do is look around at existing utility functions and then adapt them to my needs. The difference is I know exactly what I’m adding, and I know it doesn’t have dependencies, and when changes are made, I know what they are because I made them.
This is also why having a strong standard library and/or framework is so important to a language. Otherwise you’ll end up needing a third-party library for every little thing, each coming with their own programming paradigms and dozens of dependencies.
I’ve learned to be very judicious about using libraries only if they’re well established (unless I’m working on a personal project and don’t mind taking a chance with a smaller library). I do think one should think very carefully before adding a dependency, especially in webdev where you have a million bloated frameworks that have a handful of things you actually need. That being said, a trusted dependency is better than trying to reinvent (and maintain) the wheel.
I started my career as C# dev and thought highly of Java because it’s what C# is ripping off of. Then I actually tried writing Java and had a new found appreciation for C#. This was over 10 years ago though.
My experience with people from university is that they have extremely strong opinions about things they don’t know very much how they work outside theory. There is this syndrome that you have to do everything from scratch with low level languages and keep shitting on anything that uses abstraction to make your life easier.
I don’t know why people in this industry have this need of feeling that they’re better than others.
I think this is because there is just such a vast amount of information that as humans, each of us individually can only know so much of, and it creates a bit of an imposter syndrome to know how little you know, so many people feel the need to convince themselves that their little section of information is better or more important than other sections of information
It could also be the “well I had to spend years learning how to do what I do and you’re using a tool you learned in 2 days so obviously it’s not that easy and something HAS to be wrong”
I see that particular issue as the same as sending a spaceship to colonize a planet many light year away, but when they get there, there’s been an established civilization for hundreds of years because they developed a better system of travel after the first one left. Same thing, person B got to the game later, but got their goal first, so person A thinks B isn’t a real programmer because they didn’t have to grind and struggle with interior tools and tech.
You absolutely do not need a computer telling you what types you can put in a collection. Put an assert, write some unit tests, if you aren’t sure where data sources come from and can’t write a one-line comment.
Dynamic typing makes you fast, it’s empowering. Try it and quit being so scared.
No matter how many unit tests or comments you write, it’s impossible to statically “prove” type correctness in a dynamically typed language - and it will eventually blow up in your face when you have to refactor. There’s a reason for the adage “testing can’t prove the absence of bugs.”
People like static typing because it offers strong guarantees and eliminates entire classes of bullshit bugs, not because they’re “weak minded.”
Incorrect. Static typing can prove many things, depending on the quality of the type system.
At the very least, it proves that your data is organized, stored, passed around and used in a logically valid and consistent manner. Make that proof impossible, and the compiler complains. (And with good reason - it doesn’t matter how good your program logic is if you’re feeding it bad data. Garbage in, garbage - or a runtime error - out.)
In a dynamically typed language, your program logic still implicitly depends on that proof holding - it’s just that you, the fallible human, has to make sure everything checks out. Python added type hints for precisely this reason.
Additionally, with more advanced static type systems, it becomes possible to issue guarantees beyond simple type safety. Patterns like typestate (found in TS, Haskell and Rust, off the top of my head) can be used to make illegal states unrepresentable at compile time. Try to write to a closed file or make an invalid state machine transition? The compiler will see it and say no.
It just creates bugs and crashes.
In what universe are runtime errors turned compile-time errors a source of bugs and crashes? A statically-typed program won’t blow up in production because some poor intern wasn’t able to keep the implicit type bounds of every single function parameter in his head.
There’s some math & CS papers you should read, Gödel’s incompleteness theorem, Turing’s halting problem. YOU CANNOT prove your way out of logic errors. You cannot make a universal type system. All you’re doing is wasting time with false confidence.
I agree, strong typing is for weak minds. I work with a weak mind so I want strong typing.
There’s no difference in speed between typing disciplines. In point of fact, there cannot be. You must know the structure of your data to program against it. Whether you write it down explicitly or implicitly changes nothing but the location you wrote it down.
It is cool to get things done quickly (and dirty), I will give it that.
But if you need to revisit it later or have someone else take it over / expand on it this opens up the gates of hell for errors and will fall on your feet. What time you gained by getting it done will be lost, and then some, and some more over the years to come.
Source: couple of years with Python and such problems. May not be the only one with that experience, and that may be the reason why they introduced type hints in 3.8.
I’m not any faster in languages without static types. It’s the opposite, I’m fastest when I can write accurate type hints, since it makes the editor experience much better.
All my career. They can’t program, they have no valid opinion about programming, as long as we finish the user stories. Which is several times faster in a nice dynamic language than a bondage language.
Types and unit tests are bloat that increase the maintenance cost of whatever code they are involved in. Most types force premature design/optimization. Most unit tests lock up some specific implementation (increasing cost of inevitable refactors) rather than prevent actual bugs.
Nil-punning in clojure has spoiled me rotten, and now every other language is annoyingly verbose and pedantic.
I do get where you’re coming from, however. Dynamically typed languages are great for prototyping and if you’re dealing with a small codebase, it can stay that way, but IMO large codebases without typing are not fun to navigate and understand.
“Which class am I dealing with now?” is such a common problem that I’d rather have it explicitly written than guessing or assuming to know.
Very happy to share this hot-take :) Definitely code-base and team-size are a huge factor, and I mostly work on my own projects, so each project is very different. still, I expect to get downvoted into oblivion by the last decade’s influx of typey-langs and -devs.
I think most love for types is folks being happy they don’t need to assert on the input to every function, i.e. static analysis and reduced unit-tests. It’s hard for me to not see types as asking folks to pre-design their entire system (by defining types first!), before you’ve even started writing a few functions, which are actually what the system should codify (behaviors, integration tests). It’s also frustrating b/c types don’t guarantee that the system does-the-thing, only that the type-system and compiler are happy, so it’s like pleasing the wrong boss, or some metaphor like that.
I like to work with behavior directly in functions, which should be the same regardless of the type passed in. Unfortunately most dynamic languages have their flaws (js,python,etc), so this kind of opinion suffers b/c of those languages… similar to type-favoring opinions suffering b/c of langs like typescript.
Nil-punning makes me very happy - that’s a hill I will actually die on. Almost every project i’ve worked on, there’s no reason to go out of the way to specifically handle every case of not the right input or oh-no-it’s-null! Whenever you have null, you just return null from this function too, and guess what, everything’s fine - no need to crash and blow up b/c one thing wasn’t there. Mostly this is a complaint about things completely crashing for no reason, rather than being incomplete (i.e. some data missing) but still working for the user.
Anyway, lots of different use-cases, and use the right tool for the job, etc etc. types and unit tests are useful for some things.
Meanwhile here I am thinking about pivoting my career from Python to Rust because I’ve grown to hate Python’s lack of typing. I also religiously write unit test even for minor personal projects.
I suppose i should at least caveat by saying i don’t by any means advocate for all dynamic langs over statically typed, and i agree types/unit tests are necessary for most languages. So please don’t make me write python over rust!
You can get the benefits of types/unit-tests via static analysis on a per-function basis with clojure and a library like malli, and for me that hits a minimalist sweet-spot.
Sorry, I liked this hot-take setup and I’m shooting from the hip a bit. Maybe i actually mean objects/classes, not types? Can’t everything just be a bag of key-values, like in clojure?
I have been building mostly prototypes (games and wm-tools) for a year, so most of my context is getting things working to see if they are useful rather than locking them down.
I thought about my argument a bunch, and while i have alot of complaints, it all sounds like non-specific whining to me, so i’ve decided to give up.
types and unit-tests have their place. Fine! I admit it! i was pushing a hot-take I’ve had on a few occasions, and I’m glad to see this programming community is alive and well! If you need me I’ll be in my clojure repl.
It’s also important to acknowledge how different is prototyping from writing production code which has to be extendable and maintainable for years by multiple developers.
Your take isn’t even very hot when we are talking about prototyping 😉
I’m a longtime fan of python, but honestly I don’t know how I lived with it before type hints. It still feels a little backwards from the original design philosophy of python, and it’s more verbose than other strongly typed languages, but it’s come to feel pretty natural all the same.
I disagree. What you’re saying is true for Java-like OOP languages because OOP is actually complete garbage if you want to design good abstractions. Types are way more elegant in functional or functional-inspired languages.
I think you’re right re:oop - let’s throw that in there too.
One problem is naming things - bad names/naming conventions can start things off in a bad direction, so you spend forever figuring one out… but do you really need this thing you’re naming after all?
Maybe the hot-take is more like: All code is bad, so less code is better…. what should we drop first?
types are bloat for maintenence? id rather get a compiler error in 0.1 seconds than spend hours tracking down where in the code my number was coersed into a string.
Refactoring is something that should be constantly in a good base, for every story. As soon as people get scared about changing things the codebase is on the road to being legacy.
Been with a lot of codebases that had no unit tests at all and everyone was afraid to change anything because the QA process could take weeks to months.
The result is you have a codebase that ages like milk.
Today I removed code from a codebase that was added in 2021 and never ever used. Sadly, some people are as content to litter in their repo as they are in the woods.
Why do you need time to refactor? It is just part of the work you need to do and should be accounted for when doing any other work. IMO a big mistake people make is thinking refactoring is some separate thing they need permission to do. You don’t, if you need to make a change in some area refactor it first to make it easier to accept your change, then add your change then refactor to clean up. This is not three separate tasks, just three steps in one task. You should be given enough time to do the whole task, not just part of it.
I guess I need to refactor for readability. What you just explained is the entire point of the comment I posted. Refactoring is part of the job. Don’t give your manager a choice on whether or not it needs done.
Composition over inheritance has become a meme that people repeat without understanding. Both have their uses, but if composition is all you use, then you’re using a hammer on everything. There is no silver bullet in life and most undeniably not in programming.
Also, electron has a reason for existing. If it didn’t have a use, it wouldn’t have the number of users it has. You can’t tell me in all seriousness that Qt, Gtk, Swing, Tkinter is easier to use than electron for the common developer.
While I completely agree with you about electron, I still don’t have to enjoy the fact that companies are outsourcing their lack of development in native tech to my wallet in terms of wasting resources on my device. Now perhaps the cost of the associated services would be higher if they had a native app which is a fair response. I still don’t have to like it.
Written as a user (and occasionally enjoyer) of electron based software.
It’s especially infuriating when you have a giant like Microsoft rolling Electron on their flagship applications (Teams), and then deprecating support for some platforms (Linux). What’s the point of your nice, memory-gobbling, platform-agnostic app framework if you’re not even going to use it to provide cross platform support?
I don’t enjoy it either and will go through the pain of writing GUI apps in anything but HTML,CSS and JS, but the ground beneath me doesn’t exist as no contributions are coming from my side to make an easier electron alternative. There are other places I am hypocritical though.
Absolutes in programming are most useful for clickbait and little else. Use what makes sense for your use case, following a trend will only lead to pain.
JS is horse shit. Instead of trying to improve it or using that high level scripting language as a compilation target (wtf?!), we should deprecate it entirely and put all efforts into web assembly.
I think it suffers from the same problem as SQL. A bunch organizations and companies would need to agree to make improvements, you don’t want to break compatibility, so nothing really improves. You just get some extensions to it here and there which just makes it messier.
Idk anything about web assembly but I 100% agree that JS is absurd and feels like it was created in a weekend by some schmuck who just wanted to be able to edit html on the fly because it was.
You can always solve a problem by adding more layers of abstraction. Good software design isn’t to add more layers of abstractions, it’s to solve problems with the minimum amount of abstractions necessary while still having maintainable, scalable code.
There are benefits to abstraction but they also have downsides. They can complicate code and make code harder to read.
Add comment