nocman

I second that recommendation.

If you have many years of experience with vim, evil-mode allows you to keep a lot of that and add good stuff from emacs.

There was a time when I had an equal revulsion toward languages with a Lisp-like syntax. However, dissatisfaction with the limitations of most other programming languages, and the influence of a bunch of very smart and effective developers was enough to convince me to give them another look (and try to be open minded about it).

As countless others have said before me, the parens really do cease to be an issue over time (and not really very long of a time either). The power and flexibility gained by writing code in Lisp/Scheme/Clojure or other Lisp dialects really is worth the effort, in my opinion. I'm not saying there are no bumps in the road - there definitely are. However, I have zero regrets about taking the time to learn those languages. Even if I never write another line of code in any of them again, it will still have been worth the effort.

Yeah, I wasn't really thinking of performance. I was thinking of the dislike I have for working with Java. Past experiences with "enterprizey" Java is the worst. AbstractWidgetFactoryBuilderLoaderMaker, etc.

Yeah, I wasn't suggesting the JVM was bad (on the contrary, I think it is quite good). I was just putting Java in the "crappy language" camp.

The best use of Java is implementing Clojure. Of that (Clojure) I am a fan.

> If sensor data were the problem, computers could easily outperform humans since we have sensors that generate much more detailed data than the human senses

I believe you vastly underestimate the amount of information the human brain processes continuously. Computers outperform humans by performing extremely narrow, focused computations at a high rate of speed. Despite years and years of research, I don't believe humans have even scratched the surface of understanding the human brain. In fact, I don't believe humans are capable of fully understanding it, since it was created by Someone so much greater than them.

The selling point of Electron is that it is cross platform, but that does come at a cost. The cost is essentially running a separate instance of Chrome for every application you run that is built with it. The runtime overhead for that is significant. It is a tradeoff that works for some applications, but there are a huge number of applications for which it makes them resource-sucking pigs that do not provide value significant enough to justify the resources they consume.

again, like the JVM

I am not particularly fond of Java (I know I am not alone :-D).

>> All good tools need getting to know them

> Wrong. Good tools don't require that.

So any tool that is complicated enough to use that it requires more than 5 minutes to understand can't be a good tool? That is just false.

Obviously vim is not the tool for you (and emacs probably isn't either). You don't like the way they work, so don't use them. They are not bad tools. They are both very good tools. They are just not tools that fit your preferences. They do fit other people's preferences.

> Vim and Emacs cannot compare to VSCode when it comes to productivity.

For me you are 100% correct. In either vim or emacs I am at least 10 times more productive than I would ever be in VSCode. No comparison.

> Not to mention that VSCode has countless other productivity boosters built in which would require plugin hunting or fiddling with configuration files for Vim and Emacs.

First, there are distributions of both vim and emacs that come bundled with sets of plugins, if that is the sort of thing you like.

Second, some people enjoy customizing their editor to work exactly the way they want to. You obviously prefer the "set up out of the box" experience, and that is totally fine. Others boost their productivity by customizing their tools. Different people work differently.

Everyone else is not like you. That doesn't make their preferences invalid.

I have known many developers over the years who use both editors, and are extremely productive using their tool of choice. I am certain many of them would not be more productive using VSCode - it simply does not offer them anything significant enough to them to make that big of a difference.

> Platform conventions matter because uniformity matters.

There are tradeoffs to using software that has different shortcuts for similar things you might do in other software. Uniformity is nice, but I don't find it to be so essential that there is no room for any different ways of working.

> It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser.

I don't think they "just accept" it. In the case of emacs (and I believe vim also), you can enable a CUA mode if you wish, and have keybindings that are more like the system. However, in my experience, users of both of those text editors (and indeed, I use both) often choose to use the normal keybindings of those editors intentionally. In my opinion, it doesn't "consume brain cycles for no good reason". There are two very different approaches between those two editors, both are perfectly reasonable and valid. The fact that "modern alternatives exist..." is not necessarily relevant. People have been using both of those editors for years, and they are well versed in how they work and can be very efficient using them. Suggesting that they should just switch to a modern alternative makes some broad assumptions. 1) That they would be happier using some "modern alternative". 2) That whatever value they get from using those editors with different keybindings pales in comparison to what they would gain from switching to an editor with bindings more consistent with the system.

I don't believe you can assume either of those things for most of the people who choose to continue to use either of those editors after working in them for a significant amount of time.

Don't get me wrong, I understand your viewpoint. It's just that not everyone finds that uniformity to be as important as you do.

I also think it is important to point out that both vim and emacs are in active development, so it is not as if either of them has been "mothballed". So while their user interface conventions are very different from much "modern" software, it is not as if they are abandoned -- both are still being developed. They obviously both have significant value to a lot of people.

> GPT-3 has taken away the need for programming acumen for most creators.

I strongly disagree. GPT-3 is impressive technology, but it isn't even in the same universe as a team of sharp experienced developers. It is a valuable tool for them to use in some contexts, but it won't be replacing them anytime soon (at least not at a company I would work for).

No. They have not. They deserve 0 stars. I am sure there is some truly 1.2 star company out there with better customer service and company policies.

> If there were no advantages gained from C99, it wouldn't exist (people don't release language updates for no reason).

That's not what the post said. He didn't say that C99 offered no advantages to anyone. He said no one could come up with benefits to the curl project that would be gained by moving to C99, therefore the risk introduced by doing so was not worth it for now (my paraphrase, obviously).

It sounds to me like a perfectly good reason to stay with the current standard for that project.

[edited to fix a typo]

I disagree that the tabbed interface makes no sense for apps. I think that's a matter of personal preference.

> There is a thing called web-development, emerged in the last couple of decades.

As someone who does web development, and has been doing it for longer than the last couple of decades, that statement seems unnecessarily dismissive.

> But most of the web pages that people use day to day are not "documents", they are apps.

While I would agree that the quantity of web pages people visit today that are 'apps' is substantially larger than it used to be, I do think there are a lot more plain HTML documents in use (particularly in boring corporate environments) than many who frequent HN would think.

Of course, if you are going to call anything that executes a significant amount of Javascript an 'app', I am not sure I'm interested in the argument.

My original response wasn't arguing about what was most common anyway -- you said "Web browsers are not hypertext documents viewers anymore." I was just pointing out that they still do a lot of that (and for things that I would not consider to be an 'app'). Admittedly the line between 'app' and 'document' is a bit fuzzy in some cases, but there are enough cases where (in my mind) it is not fuzzy that I still don't see your original comment as accurate.

> a few of the things that they say is lacking is simply not true.

I would be interested in hearing precisely which things you are referring to (just out of curiosity on my part).

> Web browsers are not hypertext documents viewers anymore.

I disagree. They still very much fulfill that purpose.

> we keep pretending that web apps are documents that need to be shown in tabs.

Browsers do both web apps and documents (and honestly, blur the lines between them all of the time).

Also, I for one wholeheartedly want tabs for both of those use cases (and I don't think I am by any means alone in wanting that).

I had just assumed that if someone was sending out 200 applications, it was pretty much the same resume going to all of them (no catering it to the individual interests of the employer) - with perhaps some exceptions to jobs the applicant was particularly interested in.

I can't imagine sending out that many having spent large quantities of time on each one.

[edited to fix typing the wrong word]

Not the OP, but your definition of "falling off trees" and mine are very different if it took 200 applications to land a job.

I'm not saying it's bad, I'm just saying I would never use that expression to describe it.

I think this is another case where the fact that you can't get a person's tone of voice via text causes people to take things the wrong way.

As another person said of themselves, I like the fact that people on HN point to other tools they use in a way that is related to the one being discussed in the comments. That makes HN a good place to find out about tools you hadn't heard of.

I didn't think the original comment was intended to be dismissive of zuo, but they were just pointing out their preference for a tool in that vein (which made sense to me since both are lisp-ish languages made for shell scripting).

I don't find reaperducer's comment to be jaded or cynical. It sounds perfectly reasonable to me.

Another way to avoid the ads yelling at you while you are trying to pump gas is to tap on the "Weather" or "Traffic" tabs on many gas pump interfaces.

I don't know how common it is elsewhere, but the stations I use that have at-the-pump advertising all have those features (and doing so on those pumps silences the audio at the pump).

[edited to mention the audio being silenced when the weather or traffic tab is selected]

> This is a strange program of [obscure provenance] ... that somehow, still manages to survive in the 21st century.

Perhaps it "survives" because people have been using it for decades for specific tasks for which it still still works just fine. Just because there are other ways to achieve the same results for some of the tool's use cases doesn't mean that said tool should be done away with. If you don't like it no one is forcing you to use it, and calling those who still use dd "The Cult of Dd" is just ridiculous, in my opinion.

I disagree. It's a little more complicated (due to SPF/DKIM/DMARC), and that's annoying. However, I have set up multiple mail servers in the past 10 years, and I don't find the complexity to have increased that much. It is more complex, but not "way, way, way more complex".

If you think Knuth's work is "unproductive" you obviously either don't know much about Knuth, or you just don't know what you are talking about. He has had a profound influence on the field of Computer Science - and everyone who has met him says he's one the nicest, humblest people they've ever met.

I for one would feel privileged to get to meet him.

That's not what arbitrary means.

Arbitrary means there was no logical reason behind the choice, they just picked one. You can dislike the reason all you want. You can disagree with their choice, or think there are more important reasons to choose what you think they should have chosen, but that doesn't make their choice arbitrary.

I strongly disagree. The decision was not in the least bit arbitrary. Language designers chose zero-based indexing because they believed its advantages outweighed the advantages of one-based indexing.

And it still does, in my opinion. In the end, no matter how high level your programming language is, you'll eventually be computing offsets to a base address in RAM using indexes that are zero-based. Having that be consistent at every level has great value.

Except for elements that change enough between page loads that it can't recognize them as the same content (which happens far too often).

> My point is: no one knows what is a great e-commerce website

I disagree. I know what is a great e-commerce website -- in the sense the article is talking about.

  - loads fast
  - makes items easy to find quickly
  - has a simple, efficient shopping cart mechanism
  - gets me in, order placed, and out in the shortest time possible
  - is run by a company with great customer service

Yeah, there's probably an item or two I've forgotten from that list, and yeah, other people likely to order from a site might have a slightly different list. But I have no doubt that I would recognize the same qualities on other websites that I and many (probably most) people would recognize as great -- or at the very minimum, as websites that don't suck.

Wow, Jameco -- I haven't thought about them for a long time. When I was a kid I used to get those paper catalogs full of electronics parts and browse through them, wishing I had both

1) the money to order whatever I wanted from them and 2) the knowledge to make cool things with all of those parts.

One of these days I'm going to find some time and do a few electronics projects. I've always been interested, and I did a fair amount of simple experimentation as a kid, but as an adult life has kept me busy with other pursuits.