Ask HN: Developer Quirks
4 コメント
Back in the 1980s you had TUI applications for DOS that wrote characters directly to the screen buffer and were 100% reliable at putting characters in the right location with the right attributes. Over serial lines terminals like the VT-100 were pretty good except for occasional line noise.
It's never been the same since we started using graphical terminals like xterm and Windows CMD.EXE, I don't expect any of them to work 100% whether it is outright bugs in the implementation, some weirdness in how I/O works, applications not really being coded right for variant screen sizes, etc. If I could at all avoid it I would not run vim and especially emacs over a graphical terminal and instead I'd use the GUI mode of gvim or xemacs because at least these draw properly.
I don't have a GUI terminal which I really believe in, I just have GUI terminals where the applications I use work 98% right and I can live with the faults. My assumption is that another GUI terminal at best works 98% right but the 2% wrong is different (prove me wrong!) but that some random GUI terminal might be completely broken. If it is joined at the hip to some other complex software the odds of it being SNAFU or FUBAR increase, for instance the terminal emulator for Jetbrains IDEs almost works but it is a lot worse than CMD.EXE. My expectation would be the terminal baked into VS Code is crap too.
It's never been the same since we started using graphical terminals like xterm and Windows CMD.EXE, I don't expect any of them to work 100% whether it is outright bugs in the implementation, some weirdness in how I/O works, applications not really being coded right for variant screen sizes, etc. If I could at all avoid it I would not run vim and especially emacs over a graphical terminal and instead I'd use the GUI mode of gvim or xemacs because at least these draw properly.
I don't have a GUI terminal which I really believe in, I just have GUI terminals where the applications I use work 98% right and I can live with the faults. My assumption is that another GUI terminal at best works 98% right but the 2% wrong is different (prove me wrong!) but that some random GUI terminal might be completely broken. If it is joined at the hip to some other complex software the odds of it being SNAFU or FUBAR increase, for instance the terminal emulator for Jetbrains IDEs almost works but it is a lot worse than CMD.EXE. My expectation would be the terminal baked into VS Code is crap too.
Im in the python world, but I refuse to use the vscode terminal as well, 100% of the time. Pycharm terminal is far less terrible, but I've probably used it a handful of times just for quick access to the project venv. 90% of the time I'm like this quirk. It's certainly a case of experience and pain from history.
I agree it's a quirk, but I also see it as the better optimization. I do wonder though is that there could be a point when these IDE terminals fix their problems, possibly already have, and I'll then be a dinosaur. But alas here we are.
I have a venv quirk as well where I ALWAYS have 1 in my project, but usually didnt use them beyond for the linter. I used to stick with the system py environment inside the docker instance that would be managed in requirements. But then Ubuntu 24 LTS suddenly started doing this --break-system-packages crap and forced me into a venv.
I also have the quirk of Functional programming >>>> object orientated, even when using a language like python. But I'm open to cases where object orientated has to be the way to go.
I have the quirk of being rather unhappy with list comprehensions. They are hard to read, hard to understand, especially if you're combining them.
I'm totally fine with integrating bash scripts and using python's subprocess module.
I'm totally fine with 'if something_list:' and not particularly checking types and such. Ive now been using py typing on my functions for years and not once have I found that useful at all.
Yes you do need __init__.py everywhere.
I agree it's a quirk, but I also see it as the better optimization. I do wonder though is that there could be a point when these IDE terminals fix their problems, possibly already have, and I'll then be a dinosaur. But alas here we are.
I have a venv quirk as well where I ALWAYS have 1 in my project, but usually didnt use them beyond for the linter. I used to stick with the system py environment inside the docker instance that would be managed in requirements. But then Ubuntu 24 LTS suddenly started doing this --break-system-packages crap and forced me into a venv.
I also have the quirk of Functional programming >>>> object orientated, even when using a language like python. But I'm open to cases where object orientated has to be the way to go.
I have the quirk of being rather unhappy with list comprehensions. They are hard to read, hard to understand, especially if you're combining them.
I'm totally fine with integrating bash scripts and using python's subprocess module.
I'm totally fine with 'if something_list:' and not particularly checking types and such. Ive now been using py typing on my functions for years and not once have I found that useful at all.
Yes you do need __init__.py everywhere.
I also prefer an external terminal. I can't articulate why. I don't care to change.
You described your quirks, right? I don't refuse using the vscode terminal but why would I change? What is the benefit of running it inside of vscode if it is exactly the same shell?
-> This feels extreme to me because most developer quirks and preferences tend to be about optimising things -> this doesn’t. People like vim because it makes code navigation super fact. Lots of dev’s like keyboard shortcuts a lot because against - faster.
But this preference makes me do a double take and makes me wonder - to what extent are our developer habits or quirks A bit out of “order”?
What are your quirks