What Tool Can You Never Remember or Get Good At?

What program, application, or shortcut have you never been able to get behind, even though most people tout up as the best thing for developing? It could be either because you don't care to learn/use it, or because you always forget how to use it.

For me, its tmux. I realized it today when I kept complaining about my ssh session crashing and having to start again. My teammate reminded me that tmux has persistent sessions, but after 3 or 4 times of trying to use it more often, I just find it frustrating and never really use it. Maybe one day I'll actually get good at using it, but for now it just seems like a lot of trouble and time that will slow me down in the short term.

Some other honorable mentions:

• vim / emacs: I know the basics of vim, but holy heck am I slow at making changes
• curl: I basically need to relearn curl every time I want to make a simple request from the command line

Comments

[Hao]

Redux while using React. I don't know why it's popular. It's just so verbose and unnecessary in my opinion...

Also, TypeScript is overrated? I don't think additional type checking helps that much, and also it reduces the flexibility of JavaScript, which I think is the best thing of it. But maybe I was wrong.

[Pacharapol Withayasakpunt]

TypeScript is just a pre-compiled JavaScript, just like JSX. It helps integrate with the IDE. (And you can write you own helper as well.)

However, TypeScript lulls into false sense of security, especially with user input, REST API, as type, and any type. Microsoft denied to put this into TypeScript. (Yes, sometimes IDE type checking is wrong.)

[Nikola Stojaković]

Flexibility is nice till your project hits a certain size and you start to wonder why your object property is suddenly undefined even though it wasn't last week.

[Bryan Winter]

Honestly, I'll take undefined over type errors getting in the way of a refactor, or when another developer before you defines an object too rigidly and you need to do something complicated on a deadline.

JavaScript was fundamentally designed to be a dynamically typed language, and you lose half the features of JavaScript. Actually Typescript is lying to you about how JavaScript works.

Class isn't a thing in JavaScript ( for now ). You have functions. Functions are everything. Private isn't a thing either. You CAN get actual private behavior using closures, but it's a strange paradigm for alot of people.

I will say JavaScript needs an answer to the question that classes answer in other languages, but I'm not sure that answer is classes. Half the code in an angular project are import statements and you can't solve any problem without diving 20 levels into some complex hierarchy of rigid, interconnected objects, when 99% of the time you can solve your problem by typing x.newMethod = () => {}

Python actually did this right. It's still dynamically typed, with type-hinting and optional typing. Of course your going to start seeing massive bloated, verbose, unreadable python code bases now because Developers sometimes just like to type things - but hints are very useful in certain cases.

I'd argue over-defining things in the era of the web causes far more problems than it solves. We should let data be data. Excess abstraction is worse than no abstraction. However, the fight of typed vs. untyped is a silly one - the real danger is we are trying to make Javascript into something it isn't, and lies are never a good way to design.

[Nikola Stojaković]

Honestly, I'll take undefined over type errors getting in the way of a refactor, or when another developer before you defines an object too rigidly and you need to do something complicated on a deadline.

If something is getting in the way of refactoring it means there was a design mistake - this doesn't have to do with languages being strongly typed or not. Sadly, doing things quick to meet deadlines is most often the cause of creating software which will become hard to maintain later.

JavaScript was fundamentally designed to be a dynamically typed language, and you lose half the features of JavaScript.

You don't lose any feature of the JavaScript because TypeScript is a JavaScript with additional features (more precisely, a superset of JavaScript). Yes, you will lose features like adding strings to numbers, but if you need that, you're doing something horribly wrong.

Actually Typescript is lying to you about how JavaScript works. Class isn't a thing in JavaScript ( for now ). You have functions. Functions are everything. Private isn't a thing either. You CAN get actual private behavior using closures, but it's a strange paradigm for alot of people.

Umm, this would be like saying that JavaScript 2015 (ES6) lies to you about JavaScript because class keyword was introduced in it. Yes, it is just a syntatic sugar for prototypes, but again, it's a construct already present in the JavaScript.

I will say JavaScript needs an answer to the question that classes answer in other languages, but I'm not sure that answer is classes. Half the code in an angular project are import statements and you can't solve any problem without diving 20 levels into some complex hierarchy of rigid, interconnected objects, when 99% of the time you can solve your problem by typing x.newMethod = () => {}

I have wrote medium sized e-commerce system in TypeScript with Nest.js (which uses Angular philosophy for the project structure and the way some things work) and I haven't stumbled upon such problem. The only slight inconvenience I had was having to forward references few times, but I'm pretty sure I could have avoided that if I thought better about module structure (but I don't say what you described doesn't happen).

Python actually did this right. It's still dynamically typed, with type-hinting and optional typing. Of course your going to start seeing massive bloated, verbose, unreadable python code bases now because Developers sometimes just like to type things - but hints are very useful in certain cases.

TypeScript has optional typing too. You can start converting your JavaScript project today by annotating your variables with any and specifying types later on as you progress with transition.

I'd argue over-defining things in the era of the web causes far more problems than it solves. We should let data be data. Excess abstraction is worse than no abstraction. However, the fight of typed vs. untyped is a silly one - the real danger is we are trying to make Javascript into something it isn't, and lies are never a good way to design.

With all due respect, I will say opposite is the case. Understanding what something is and what it does helps you to write more predictable software, less bug-prone. This has been proven over and over in the practice. Sure, it's the overkill to use strongly typed language for writing scripts for automating things or some basic CRUD applications, but once your application starts becoming more complex benefits of strong / static typing outweigh benefits of dynamic typing by a great margin.

[Bryan Winter]

I can't go point by point on this,

From JavaScript docs
JavaScript classes, introduced in ECMAScript 2015, are primarily syntactical sugar over JavaScript's existing prototype-based inheritance. The class syntax does not introduce a new object-oriented inheritance model to JavaScript.

But again with Closures, I don't think we need class at all, and I think class is step backwards. I'm not just pulling this out opinion out of no where. I'm of the Douglas Crockford school of JavaScript. Use a subset of everything, strip it to the bare minimum, aim for readability and not clever. Class is too clever of a thing in my mind, because it isn't actually a class in the way that OO languages actually use class. I have to use it now, everything modern and new uses it, but there was a much better way.

Interfaces however, are fantastic, and something we should use everywhere. So it's not all bad.

I really think classes are an error in JS, and we should be using a paradigm that reflects prototypal inheritance and how it works. IE, your objects are composed, dynamic, living things, and not dead rigid objects, in a rigid hierarchy that we never define correctly. Prototypes work really well with composition style of development, where you have a thing that isn't a single type, but many types or no types.

I keep hearing the scaling argument - but I honestly have my doubts. I've worked on big complicated projects in both dynamic and strictly typed languages, and I find it way easier to fix problems and refactor. I'm not against typing it all, but I do think it's way too overused, and eventually it creates a mess of boilerplate that is hard to reason about. Your mileage will vary.

This reminds me of circular arguments with regards to something like Wikipedia. Harder to screw up, or harder to change? pick one.

I pick easy to change every time, for the reason that you pointed wisely out : you can't control what other people write, only what you write.

[Daniel Starner]

I agree with TypeScript. I haven’t done enough front end work to justify learning it, and if you are trying to strongly type a back end, why not use something faster and more tuned than a JS-esque engine?

[Jeremy Forsythe]

There is a huge benefit to isomorphic TS when training juniors as full stack engineers. I love TS and we use it to build a distributed microservice backend. We don't have much pain with it. Maybe because we forbid the any type?

[Pacharapol Withayasakpunt]

Precisely because JSON is dynamic in nature, and TypeScript can always escape to JS-esque dynamicness. Also, NPM got what I wanted, Flask-esque Express.js, which feels quite standard.

JS/TS seems to integrate with the IDE better than Python.

I actually like Kotlin, but I have never done well with Spring Boot, and I hated (someone-else made) boilerplate. Though, I have used Spark Java quite well, but it is not quite standard, so not much tutorials. Also I attempted to use Kotson for dynamic typing in a real static typing language.

Dart for web server feels quite nice, although I haven't dive into it much. Also, less tutorials and Heroku support...

I haven't dive into Golang and Rust much. Perhaps I should try...

Though, for TypeScript on the server, I hate ESM vs CommonJS, and the need for "build process".

[agtoever]

I keep looking up the options for most networking tools: netstat and nmap: great tools, but when not used frequenty, hard to master.

Two suggestions for all struggling with the command line:

• I use screen instead of tmux. No tiling, but cycling through persistent ssh sessions. For me this works.
• When you switch to zsh, you can get a handy list of commandline options, which you can even navigate through using the cursor. Just hit tab twice after <command> -

[Ken Simeon]

You nailed it with Curl. I'm always looking at the Man Page for Curl. That's why I end up falling to wget. 😂

The other big one is starting & stopping services on Linux systems. There is and has always been inconsistencies between a RedHat/CentOS/Fedora based systems vs Debian/Ubuntu systems.

Staying on the Linux topic. Package managers . . . the moment I forget i'm on a Debian based system I totally forget how to search for and/or install a new package.

Typing up both of those last two statements reminds me that I need to get off of MacOS and go back to running a Linux distro on the daily.

[Peter Storch]

jq for commandline json parsing and processing. It's very powerfull and saved my life several times. But it's CLI is not very intuitive and I only need it once in a while. So I forget it and have to read the tutorials and man pages over and over again.

[rhymes]

This! Every time 😂

[Anna Rankin]

Oh man, I also need to re-learn curl pretty much every time. There are also certain SQL concepts, like keyset pagination, that I swear I look up every six months but then my brain garbage collects the information 😭

[SyntaxSeed (Sherri W)]

RegEx.

And Apache's mod-rewrite rules despite having worked with them a TON.

[Fulton Browne]

I can never get cli editors, people say I should use them, but I can never really get the hang of it. I am more productive in VS code or an IDE

[James]

The entire JavaScript ecosystem. I'm sure you JS Devs are having a lot of fun out there, but I'll stick to C and Python.

[Mateusz Jarzyna]

If you can't remember how to use the command line app, I've recommended to using tldr tool

[Olivier JM Maniraho]

Same here with tmux first it took me a couple of days to know how the ctrl+b thing works then I have to look up the rest of other shortcuts, I keep the cheat sheet close to me.