Comment by nine_k | Hacker News Reader

Comment by nine_k | Hacker News Reader

Wat.

Of course learn the language you're going to use. But you can't expect to make do with just one.

In any case you'll face SQL; learn it. It's a language on its own, with interesting and non-intuitive concepts, a number of features, and great power.

Learn bash, because you'll have to talk to the OS somehow! (Yes, even macOS. But you don't normally deploy to macOS only.)

Learn some HTML and CSS, even if you're a backend developer, enough to show a simple status page for your service.

Read an intro into YAML, it's not that trivial! It's useful around great many modern tools. TOML is good to know, too.

These are all proper languages, worth knowing for a long time and learning. One could also say that Vi's system of commands is also a language, because it has syntax and is composable; worth knowing, too!

This is on top of your language of choice; for backend or mobile development you can usually make do with just one, for web frontend you have to know enough JS, HTML, and CSS at the least, TS is a really good idea, too.

Depending on what kind of work you do, it can also be helpful to learn at least the basics of various "back end" (or "system") languages and libraries out there.

For example, one of the following in each categories:

  - something for number crunching and statistics: Python or R (went with Python here, also has nice image/audio processing libraries)
  - one of the more popular higher abstraction level languages: Node, Python, .NET, Java, PHP, Ruby or another one
  - perhaps something for being able to create static executables and packaged tools/utilities: Go, C/C++, Rust
  - maybe something for GUI tools (opinions vary, I still like Lazarus/Pascal, most might go for Electron, others grokk Qt/GTK etc.)

Chances are, you won't need all of those in your day job for the most part... until one day suddenly a use case will present itself, where doing it in one of those languages will be easier than whatever you're using already.

Plus, it can make for a fun few weekends, if you have the curiosity and time to spare. If you can get your company to pay for you upskilling yourself and don't have to fall into the "1 year of experience, X times" trap by just fixing bugs, even better! Even better if you learn multiple of these and then can reason about which tool might be better for any given job.

My job/team might be the exception to the rule, but anyways:

"In any case you'll face SQL" -- there is no trace of SQL in our project. We're using a NoSQL database. This may change in the future, though.

"Learn bash, because you'll have to talk to the OS somehow" -- our language to talk to the OS is standard libraries. We do have a few bash snippets to glue together the build process, but they are vanishing more quickly than they appear because everybody in the team thinks that bash is inferior to typescript.

You're right about HTML+CSS, and this is a trend I've seen everywhere (replacing UIs with browser-based UIs).

YAML only exists in a single configuration file, and only because the tool forces us to, as well as a second rather obscure configuration file in a sub-part of the project because another tool forces us to. The tools suck hard, they report errors in the whole file even if it is totally correct.

Nobody is using vi, everybody is using either WebStorm or VS Code.

Thanks for sharing! I think it is just your team.

23.3% percent of respondents indicated that they use Vim in this year's Stack Overflow[1], noting specifically:

> PyCharm is used more by people learning to code (26% vs 16%) while Vim is used more by Professional Developers (24% vs 16%)

[1]: https://survey.stackoverflow.co/2022/#technology

So the question from the survey was: "Which development environments did you use regularly over the past year, and which do you want to work with over the next year? Please check all that apply. "

So respondents could check multiple. I would definitely check Vim, because I use it often, but I'm not using it as my primary text editor/IDE, but that would count towards Vim anyways - as I understand the survey. From my own experience, most developers use some kind of IDE, but that may be a Danish quirk. Most people still joke about not being able to exit Vim.

> I'm not using it as my primary text editor/IDE, but that would count towards Vim anyways

I don't think there was any mention of Vim as main editor in this thread. Just that it's helpful to know it, and I think that makes sense.

> Most people still joke about not being able to exit Vim.

Most people make boring jokes. To me that "exiting Vim" joke is becoming even more annoying than the "only 10 kinds of people" one.

Exactly, I think most people use vim when doing stuff on the command line. It's easier to open a config file in vim and make a change when you're poking around than it is to load it in VS code.

> there is no trace of SQL in our project

I presume (and hope) it's not your last project.

But I agree, programming is wider than this, and you may never face SQL e.g. if you do deep embedded development, but then an ability to read VHDL can be handy, or if you do game dev 3D graphics, but then you'll have to learn the shader languages, etc.

> everybody in the team thinks that bash is inferior to typescript.

Let's hope not for the sake of the team. TypeScript is great but it's not Bash. How much time and TypeScript code do you need to read, filter and write content from a text file? More than one line probably.

I have yet to see a language that matches Bash at what it does best. It's one of the biggest time-savers for me.

Lines of code are irrelevant compared to readability, and the latter is where bash loses hard. Time to write and maintain these scripts is far less with typescript.

The remainder of your arguments seems to be based on wrong assumptions about what our build scripts are doing. "Filtering text files" doesn't happen there.

OTOH, in typescript I can include a library for the deployment on various GCP cloud services in a single line in package.json -- how many lines is that in bash? (edit: the sarcasm might not be obvious. Nobody I have ever met knows about a GCP deployment library for bash, nor about an NPM-like platform for bash snippets. Installing command line tools via the platform's package manager doesn't work in practice for various reasons.)

>Lines of code are irrelevant compared to readability

They aren't irrelevant. LoC has influence on readability. Try reading a terse book versus a more condensed book if you don't agree. It's neither as easy as "make it as short as possible" nor "just write as elaborate as possible".

Knowing Bash is about more than just writing build scripts. I use it every day for one-off tasks and trying to use anything else instead would be a huge waste of time.

> GCP cloud services in a single line in package.json -- how many lines is that in bash?

My whole point was: use the right tool for the job. Sure nobody would do GCP stuff in Bash, just like it would be ludicrous to do certain tasks in TypeScript instead. The original statement was about Bash being a useful skill, and imho that's practically undeniable.

> Installing command line tools via the platform's package manager doesn't work in practice for various reasons

I wish installing dependencies via package.json and npm was as reliable, it would save me quite some time.

Reply on news.ycombinator.com