Hacker News Reader

>Don't waste your time with what is hip

Wouldn't that apply to git? You can probably get 90-95% of the benefit of git using mercurial with a fraction of the effort in learning. Life is too short to spend learning the internals of one version control system.

This idea of "Don't waste time on X focus on more valuable Y" has no real end. Don't waste your non-work time on learning computing related stuff and instead spend time on social connections and physical fitness first. Pays off way more than emacs, git, vim, lisp, or programming paradigms. See how easy it is to make such pronouncements?

> You can probably get 90-95% of the benefit of git using mercurial with a fraction of the effort in learning.

You absolutely cannot.

Even if we pretend that Mercurial is simply outright better than Git, there's a lot of value in learning Git specifically, as it's what most development teams use. Employers value proficiency in Git. If you mention your Mercurial proficiency in an interview, it's likely to be scored up as cute but irrelevant.

If you always work alone, sure, Mercurial might work great for you, but the real value of these version-control systems is in enabling teams to work effectively. Most teams these days use Git, so you need to know Git.

(Of course, if your team does use Mercurial, you'd better become proficient in Mercurial.)

> Life is too short to spend learning the internals of one version control system.

I agree that learning the intimate internals of Git's codebase isn't something that's likely to pay off in the day job, but short of that, Git's 'useful skill-ceiling' is pretty high.

> Don't waste your non-work time on learning computing related stuff and instead spend time on social connections and physical fitness first.

Depends on your working situation. If your work offers no opportunity to learn new skills, and you don't want your CV to get stale, you have little choice.

>there's a lot of value in learning Git specifically, as it's what most development teams use. Employers value proficiency in Git. If you mention your Mercurial proficiency in an interview, it's likely to be scored up as cute but irrelevant.

Given that the person I was responding to was advocating not spending time on things for the reason that employers are looking for them, and is advocating things almost no workplace uses, I find your comment strange. Perhaps you should be responding to the comment I'm responding to?

>Depends on your working situation. If your work offers no opportunity to learn new skills, and you don't want your CV to get stale, you have little choice.

You do have a choice, and you made your choice. In the US, in this era, SW professionals are near the top when it comes to freedom to change jobs and change locations. When I know several people who make half of what I do, are relatively unskilled, and have to work much longer hours than I do, who made a very clear choice in favor of physical fitness and social relations, I am not going to claim I don't have a choice.

Having said that, this is all orthogonal to my point, which was how easy it is to make (reasonable) lists of things one should focus on that are almost exclusive to one another.

After programming for 50 years and having a successful career, I’m not really going to need serious git skills. I still write code, all the time, but it’s for fun and personal projects.

Yes Mercurial is easier to use than git, and really fossil is even better for me, someone that works solo. However git is what I use. I know that if I am going to help someone with source code control (like my daughter who is studying CS) git is what they will need help with. Personal use of git is to me the only way to ensure that I can give pertinent help.

> Wouldn't that apply to git? You can probably get 90-95% of the benefit of git using mercurial with a fraction of the effort in learning. Life is too short to spend learning the internals of one version control system.

I haven't used mercurial much, but it seems like you would have to understand the same amount about the core data structures to do something in mercurial as with git [0]. The really simple activities you do day to day don't require any deep knowledge. And when you want to do more complicated things you have to know what you are doing.

Its similar to writing simple C++ programs vs complex ones. You may not need to understand smart pointers to write small programs, but understanding smart pointers or at least the concepts behind them is critical to write large programs.

[0]: There are minor differences between the two that probably make git harder to pick up. Among them being the staging area, and rather obtuse UI. However, the market effects of git are hard to ignore.

I'd disagree a bit here: mercurial does a much better job of abstracting over the underlying data structures.

Git is a DAG navigation tool that can diff text, and the API shows it.

Mercurial is a version control system that happens to abstract over a DAG. The API, similarly, shows it.

> Git is a DAG navigation tool that can diff text, and the API shows it.

That seems like a relatively accurate characterization.

> Mercurial is a version control system that happens to abstract over a DAG. The API, similarly, shows it.

I am unfamiliar with the details of mercurial. Could you explain or link to something detailing that point?

Social connections and physical health are also such multipliers, just as vim or git or lisp. If you have been asocial and unhealthy in the past and now were able to change you will also experience this increase in output, e.g. because you can suddenly ask others for help and can focus for longer periods of time. Maybe you will even come into less situations where you use git and vim and programming languages, because others also value your ability to focus and your connections more than your ability to produce code. Then it paid of even more to focus on these multipliers. Great.

That doesn't mean either of the other multipliers are not multipliers though. They are just more topic-focussed instead of generally applicable.

And no, mercurial can't do more than 5% of what git can. That's just a fact. Just like you probably wouldn't waste time explaining a flat earther why the earth is round I won't explain this to you. If you are smart (and I assume so from your comment) you will go out and fact check that by yourself from the assumption that you just might be mistaken and maybe this random dude on the net might've been correct.

Hope I'm right in that assumption. Then you'll have an awesome time of a lot of WOWs ahead of you. Enjoy it.

And if not, there's not much lost. Some humans will fly to Mars even if some others believe the Earth is a disk.

One thing that life tought me is that you can be the best dev in the company but still your boss is going to give the promotion to one of his buddies he likes.

Personal connections and social engineering is 10times as important as your actual skills.

Its unfortunate looking at current state of the world, but thats how it simply is. And I understand some may not agree with it, but please look around yourself and tell me Im wrong..

While it's nice you're agreeing with me, I did not suggest it as a way to improve your career, and my advice stands even if it has no chance of helping your career.

>If you are smart (and I assume so from your comment) you will go out and fact check that

Exactly how do I fact check this? Most Google searches give two types of results: Either pro git or meh they're mostly the same. Virtually every pro git page has basic facts wrong about mercurial and are criticizing the mercurial of a decade or longer ago(0) The very few exceptions cover use cases that really do fall into the 5% category.

And I assume you meant 95% and not 5% that you wrote. If you really did mean the latter I suspect you know little of mercurial.

(0) Branches are a classic example. Although I do think git has slightly better branch handling pretty much most pages criticizing mercurial branches expose their ignorance of beaching in mercurial

I'd argue they got it right: when 95% of projects use Git, then why learn anything else? I think the last time I used Mercurial was almost a decade ago at this point, and I don't know of any major project that uses it (outside of Mozilla, who has most of their newer projects are on GitHub, and OpenJDK, which maintains a GitHub mirror).

After Googling, it's pretty dire actually: https://www.mercurial-scm.org/wiki/ProjectsUsingMercurial Many of these are dead links or links to repos that haven't been updated in years.

>when 95% of projects use Git, then why learn anything else?

I remember my University days: "I don't know anyone else who doesn't use Windows. Why do you use Linux?"

That is ignoring my point with a deflection. This isn’t 1999 with Linux as a (relative) newcomer and on the upswing, the adoption rate has clearly dropped over time. I did miss the fact that Facebook uses Mercurial internally, but their public-facing repos are all on Github (including, ironically, their re-implementation of Mercurial, Mononoke). Open Source software doesn’t exist in a vacuum, it needs a community to support it and use it.

> You will never code lisp in your job. Promised.

I believed this too, but then Clojure happened. It's not my ideal Lisp, but I can get paid to write it at a mainstream company.

Ditto, Clojure gets work done, and there are hardly any Fortune 100 companies left without someone using it on the job. It's become part of my job.

What is Clojure's wheelhouse -- what is it used for?

Anything that Java is used for

All sorts, but I believe it was born out of frustration at unnecessary complexity arising from standard enterprise development.

Hickey’s choice of hosting it on the JVM was ingenious, gives access to one of the largest most battle tested ecosystems in modern day enterprise engineering.

It’s much more versatile these days with the likes of ClojureScript, it’s being used in anything from real-time multimedia projects to SPA JavaScript work.

Basically anything other than operating systems. I've been working on an optimizing compiler for spreadsheets, and an event sourcing system with a WebSocket gateway in my current work.

According to TIOBE index, Clojure is not a thing outside HN bubble, is it?

Great to read that. I also know one other person who writes Clojure professionally. Gives clojure to some of who hoped for people to get this opportunity at some point.

There are also rock stars, but that doesn't mean we should give advise that anyone could become a rock star. Those who will become rock stars will become it anyway even if you tell them they won't.

I code in lisp for work everyday! This is a bad promise, but I agree lisp is amazing. I've recently been learning to love macros and reading let over lambda is fantastic!

While I agree in principle, this is a nice way to quickly become unemployed.

We live in a hype oriented industry, where momentum and programmer enthusiasm (free man hours or work) and not technical merits predict whether a given technology will thrive or not.

> Don't learn the hippest UI IDE, learn vim or emacs.

In some circles, these are equally as 'hip.' Idea: learn the tools you need to get the job done. Study theory to supplement your skills.

> Don't learn the hippest UI IDE, learn vim or emacs.

This jars. Why not recommend really learning Cocoa and AppleScript or VB for Applications? Or really dig into Smalltalk's code browser? vi and emacs have a long track record, and I still use both because I sank the time in to learn them years ago, but I wouldn't recommend them as fundamentally changing someone's view of computing.

Well, Emacs may not have changed my view of computing, but it definitely changed how I _use_ computers...

>learn the meaningful stuff, you will never code in your job implying the code that can be thrown away is the code they get paid for hmmmm