Hacker News Reader

Comment by Jarwain | Hacker News Reader

I think what the author did here hits hard on why hacker news is such a great resource. To quote:

> Most fields have a problem with ‘ghost knowledge’, hard-won practical understanding that is mostly passed on verbally between practitioners and not written down anywhere public. At least in programming some chunk of it makes it into forum posts.

I'd be incredibly interested in seeing a series of posts like this, where authors mine hacker news and other forums for insights that they consolidate (then repost here).

What other topics do y'all think HN provides unique insight on?

View on HN

I agree that this type of compendium/synthesis is useful. I was amused to open this thread and see comments focused on visual programming rather than the meta-aspect.

As for what HN could be mined for, a big topic is software languages. There are ways to subdivide that: by language, by optimization aspect (e.g., comparative performance). Geographic topics like cost of living and quality of life. Remote work pros and cons.

Another way of identifying topics worth mining would be identify posts where @dang provides a link to previous posts and those previous posts have a sufficient number of comments.

> What other topics do y'all think HN provides unique insight on?

Career managment I think (not sure if it's the good term for it). I see lots of people in their 40's or more that quit some FANG job for another job that earns less but is more aligned with how they want to live their life. I see lots of people advocating to quit jobs as soon as you see red flags. I think both of these are good wisdom.

On the other hand, a point that's still a mystery to me is "programming language choice". I've learned useful heuristics like you can do web backend in pretty much anything, if you have no libraries for something that needs them like an AWS SDK you're going to suffer, what helps in the long run slows you down at first, but that's about it. I don't know if it's because I'm too young in this field, because I don't understand/missed something, or because there is no big truth to find.

Personally I think programming language is about a compromise between performance and convenience.

For instance, I program in Python if speed is irrelevant. Rust if it is very relevant. C# if I want a large project where performance is somewhat important.

I think there are a wide range of languages for each "category" where I put Python, C# and Rust above, but those 3 are my current favorites.

Certain languages are very well suited to specific tasks. You learn these with experience. Initially I loved python because it was a joy to slice and dice strings in it. I understand that Ruby is popular for the same reason. Closure is great if you want lots of agents processing stuff on a network stack.

If I were you, I'd just focus on making fun projects in your favorite language.

> Personally I think programming language is about a compromise between performance and convenience.

That's one dimension, but what about popularity, maintainability, being able to hire, productivity, being able to tackle precise problems, etc.

I think concern about “ability to hire” is a bit overblown: I’ve worked at a couple places now that have taken the “hire people that know what they’re doing and they’ll figure out the language” approach, and it’s generally successful for most business applications: this is true even when the team is using unusual languages like Clojure.

The problem is really about tooling, you also need people who can fix bugs/port to new arch in the compiler and related tools. For a very popular language you can always find the right people for this task or even offload this task like they do with oracle.

Those are layman’s concerns. Programmers love to learn new things and are typically good at it. If a given tech has merit and some unique advantages.

Edit: I didn’t read the comment right. Productivity and being able to solve precise problems are essentially why you’re choosing a technology in the first place?

> Those are layman’s concerns. Programmers love to learn new things and are typically good at it. If a given tech has merit and some unique advantages.

I don't think that's true, I believe most programmers are either dark matter developers [1] or people doing Java (or equivalent) all their life for a software service company. There is nothing wrong with that, but that would explain why less popular languages and ecosystem still have lots of stuff. For example, Rust has ~60k crates on crates.io, while Maven Central has ~400k packages. I believe Java is used by more than 10 times the number of people that use Rust. But the people writing the libraries in the first place are usually the people that are open to trying out new languages.

[1]: https://www.hanselman.com/blog/dark-matter-developers-the-un...

I concur, though most of the traits you mention are not problem-specific.

When putting a language into "your toolbox" you indeed SHOULD focus on "popularity, maintainability, being able to hire."

However, when picking which of the languages you have learnt to apply to a given problem you need to know their relative strengths.

Most of the strengths you mention help you pick the "best in class" language. But only the problem can tell you which subset of langauges you are picking from. Sometimes the best possible tool for your problem is going to be unpopular.

That’s true for conventional languages, you can trade off some performance for a bit of productivity. However, if you want significantly more productivity, we hit walls quickly in PL design where trading off performance is no longer effective. So ya, Kotlin is slightly better and slower than C, but both languages are fundamentally still in the same ballpark that we don’t know how to get out of yet.

> I don't know if it's because I'm too young in this field, because I don't understand/missed something, or because there is no big truth to find.

I'm pretty young in the field as well, but my impression so far is that there aren't really any big truths, just a lot of little ones

The only big truths are things that seem obviously one way, but in reality are the other way due to a myriad of non-obvious sub-things.

E.g. Productive person-hour scaling as a function of team headcount

The technical term for “ghost knowledge” is https://en.wikipedia.org/wiki/Tacit_knowledge

Reply on news.ycombinator.com