> In the 90s, before the web really took off, stuff like this was hen's teeth. Anything you found, via BBS, Usenet, or the nascent web, you'd pore over in detail and make sure to fastidiously back up in case you never found it again.
To be honest, backing up stuff makes sense even today. Websites do disappear. You never know when your favorite blog may disappear. There is the internet archive machine that fights link rot quite well. But it wouldn't hurt to take back ups of your favorite online articles.
With the advent of capable editors like Visual Studio Code, is Vim still a relevant skill to have?
Is SLIME still the state of the art for Lisp development environment? Is there no way to get started with Lisp programming without having to learn Emacs or Vim?
Vim, the text editor, might be relevant if you want a powerful text editor that's installed on basically any *nix system ever. Nano has become nearly as ubiquitous so it's unlikely that you'll need to know vi/m on most hosts these days.
Vim, the editing paradigm, is a relevant skill if you value trading time to learn a way of editing text that is vastly different from traditional. It's a faster way of editing that once you grok it will probably make you annoyed about editing text in editors that don't support it. VS Code has a pretty good vim implementation, though. I personally think it was worthwhile, but people value different things. You might not like the investment of time it takes to become proficient or may not find it as useful as I have.
I can't speak to what is the state of the art for Lisp development. I'm confident that you can use editors other than Emacs or Vim for it, though.
I have no idea why you were downvoted for your questions. Weird. I will try to answer your questions:
One killer application of Vim and Emacs is development on powerful remote servers, for example, you might want 16 cores, a powerful GPU, and 64gig memory for a task so remote exploration and development makes sense. (VSCode does have a remote mode but I haven’t tried it.)
I have been using Emacs for 20+ years with Lisp. I just use Vim for quick edits to I can’t speak to using Lisp dev Vim support.
For local development on my laptop, I now use Emacs or VSCode about equal amounts for Common Lisp, Racket, and Haskell depending on what I am doing. Both are fantastic dev environments.
EDIT: Slime may be old, but it is tried and true technology. LSP is more modern and is a common autocomplete, etc. interface for many languages.
Just want to mention since it's not obvious from your comment, that there are both Vim and Emacs plugins to offer LSP support, and also Neovim is getting a built-in LSP implementation.
Here's one maybe-reason and one definitely-reason VSCode cannot replace vim for me:
1) Logs are often compressed. Can VSCode open .gz files? Vim behaves pleasingly unixy: 'zcat logs.gz | vim -' opens the file pretty quickly in vim. No fuss with explicit de/recompression. This also ties in to the usual "but ssh" argument, since of course you're likely to be getting logs on remote machines.
2) Bash pipelines are usually an iterative affair. It has some tricks in place to mitigate the issues of very long commands. C-x C-e will open vim to allow you to enter a command, and fc will open vim with the previously executed command already there (short for fix command).
Lastly, vim has an expansive collections of extensions. So much so that if vim is ever "not enough", then neither is VSCode, and I should just use a full IDE.
I just use zless and then press v to invoke vim if I need to edit. I don't usually edit logs, mind you. But for other .gz text files, that I might read and then decide on a whim to edit, definitely.
> With the advent of capable editors like Visual Studio Code, is Vim still a relevant skill to have?
That's such a weird dichotomy to present, what feature of Vim did other text editors lack that VS Code managed to replace? Vim is a "relevant skill" because it is a better editing paradigm. VS Code is no more competition to it than Nano or Emacs were.
Disclaimer: I'm a long-time Vim user who can't stand editing text without the modal editing paradigm anymore.
Emacs is a competition to Vim, because it has a couple things that Vim does not have:
1. It can understand that a certain part of a file is written in one language and another in another language; and then give you appropriate syntax highlighting, indentation etc. in these specific parts. Vim can't do that.
2. It is an actual GUI application as opposed to GVim which is basically a terminal with vim and a toolbar. It (Emacs) can render proportional fonts, which is really nice when you edit org/LaTeX documents.
3. Its scripting language is a lot nicer to work with.
For these reasons, whenever I can, I use Emacs with evil-mode. For the occasional editing of a file on a server or an embedded device I will still fire up vim (or vi in the latter case, since then vim will usually not be available). I encourage you to try it.
> [Emacs] can understand that a certain part of a file is written in one language and another in another language; and then give you appropriate syntax highlighting, indentation etc. in these specific parts. Vim can't do that.
Sure it can! Here[1]'s an example of someone using it for html embedded in heredocs.
> [Emacs'] scripting language is a lot nicer to work with.
This is not a fundamental limitation. E.G. neovim uses lua. (I'm not counting python and lua embedded in vim, because afaik they're a total pain to work with.)
I actually recently started transitioning from vim to emacs recently, but I don't think any of your arguments in favour of it are particularly strong. I do, however, agree that vim and emacs are at the cutting-edge of text editing, possibly along with some more niche editors like vis, sam, and kakoune.
I don't know about VSC but most IDEs are rather difficult to extend. VIM makes it quite easy to create a plugin or prototype new ideas. If you don't need clever code completion etc., VIM is still very useful. Other than emacs, VIM also has some guidelines wrt to code organisation (pack, plugin, autoload, ftplugin, syntax etc.) that make things easier. vimscript is a simple language that has its warts but actually is quite useful in the context of this editor. To some extent, you can write (parts of) your plugins also in python, ruby, lua, mzscheme etc.
So, to some extent it's still useful and relevant. VIM also runs on your android phone, VSC, Idea, Eclipse etc. don't.
WRT to learning lisp, I'd recommend racket. It's scheme and unfortunately mzscheme lacks the libraries, e.g., common lisp has. It's very useful nevertheless.
Vim and Emacs have a bunch of features that you won't find on editors like VS Code. VS Code has some features you won't find on Vim and Emacs.
One of the great advantages of these "old-school" text editors is the extent to which they can be customized. This is even more true about Emacs, which is mainly written in its own "scripting" language. Almost everything on Emacs is exposed to the user during runtime. It's very easy to make both temporary and permanent changes. Emacs is self-documenting: there are handy commands to find keybindings, variables, and functions definitions. If this is not good enough, you can go straight to the source code and redefine whatever you want. You just need to evaluate the code for it to become available at runtime: no reboot necessary. Once you get used to this level of freedom, it's hard to get used to other platforms.
One thing I'd like to point out is that, even though Vim and Emacs are old, this doesn't mean they're stuck in time. They are constantly updated to support all the current technologies that people might associate with newer text editors like Atom and VS Code.
As you say, there are some really great editors like VS Code available these days and I have used many, if not most of them but I keep coming back to Vim. The reason is that I feel so much more productive in it. I can do things with three simple keystrokes that are quite a bit more involved in other editors. And that’s pure, stock Vim without any plugins. It’s astounding what I can accomplish with the addition of some plugins.
Really, in the end, it’s just another tool that fits me well. It may not fit you as well and that’s ok. But there is definitely still a place for old-school editors like Vim and Emacs in a modern developer’s toolkit.
As an aside; I don’t know why OP was downvoted so heavily. There is absolutely nothing wrong with asking a question such as this. I have to account for the possibility that it was edited to be less caustic by the time I read it but, if that wasn’t the case, I think all who downvoted it should re-evaluate their decision to do so. We should celebrate the desire to understand something and, from what I can see, that’s all this person is trying to do.
In my mind the main reason why Vim still has relevance today is for seat-of-your-pants SSH'ing, which admittedly shouldn't be done but it still is. Outside of that...
I still have hope for structural editing but I don't see Vim as the innovator in that space anymore.
I think you should use the environment that makes you the most productive (and happiest).
For me that is vim.
But I also have the questionable (and questioned) opinion that, for that matter, you can write a state of the art program in Fortran. If you happen to find a O(n) algorithm for prime factorisation, and you write it in Fortran, would it not be state of the art?
SLIME has a successor now called Sly, but yes that's still state of the art for Lisp programming.
No, you don't have to learn emacs to get started with Lisp though. You'll just have an inferior experience.
As a side note, if you do start to learn without emacs, please use something like this[1] for formatting your code. Most editors lack a Lisp indentation plugin, and any time you ask a question online, whomever answers it will have to reformat otherwise.
I don't think it's fair to call it a successor since it intentionally doesn't implement all the features of Slime.
I'm specifically talking about presentations which were removed because the author of Sly never uses them. For the first people who do, however, Sly can never be a successor to Slime.
It may be an alternative, and a pretty good one, but not enough a successor.
Vim is highly customizable, the one you get on most unix systems are engines and transmission only.
The engines and transmission are incredibly powerful, the only problems is you sit on top of metal with a stick as your wheel.
But you can turn all that into a fully working luxury car/truck/whatever you like by digging in and customizing it. In the age of "don't build the wheel", you can also do that by installing component that other people have built already.
I don't think learning GNU Emacs using a window-based version would be too difficult. The obvious advantage is better tool support via SLIME for interactive Lisp development with SBCL.
Support for development with Common Lisp in Visual Studio is relatively primitive and has very little momentum - at least that's my impression.
I don't really see why you would write any lisp in an editor that isn't Emacs. Visual Studio Code is very capable... of jumping in to a hot loop periodically to crash or require you to kill it, sapping your battery at idle, and making rookie mistakes long-since corrected by the 40-year editors.
If I were looking to replace Emacs, replicating CIDER is a tall order, especially CIDER over TRAMP. Tell me when you can automatically shell into your high-memory remote machine with an editor running locally, and get a full REPL with inline evaluation on the remote machine.. and it "just works" (i.e. install the package from MELPA, and it works out of the box).
You make a very good point. I think the biggest factors that can determine happiness at work are the immediate boss and the immediate teammates, two things that are very hard to assess until you have already joined the new place. But the money is easy to assess and guaranteed because it is written on paper and it is legally binding. A boss with a good attitude, however, isn't guaranteed, no matter how rosy things look during the interviews. So it makes sense to never take a pay cut unless there are other compensating factors that are also guaranteed. Working 4 days instead of 5, or 6 instead of 8, seem like those things that can be guaranteed by the contract and would be worth taking a pay cut for.
This reminds me of a personal story when I interviewed for a very popular startup in the valley. They boasted of working 12 hours every day. I had a competing offer from a non-startup which required me to work about 7 hours every day. The CTO of the startup agreed to pay me 20% more than the non-startup. I politely explained the CTO that I could work for 12 hours every day, however, I would need a 70% more pay than the non-startup's offer, so that I feel I am being compensated commensurate to the time and effort I spend on the company. The CTO, now visibly upset, said, "If you like working 7 hours every day, please do join that other company!" while completing missing the point that I am okay to work for 7 hours or 12 hours as long as the pay is commensurate. Needless to say, I joined the other company for lesser pay and lesser working hours, and I am quite happy about the decision because it leaves with me a lot of time in the evenings to pursue my hobbies and also pick up new fun technologies to learn.
> because it leaves with me a lot of time in the evenings to pursue my hobbies and also pick up new fun technologies to learn.
As someone who has hired developers in the past. This "12 hours CTO" missed a good opportunity. It's much better to work 7/8 than 12. As frequently, developers when they get home. The itch will get too much and then start tinkering and learning new things in their personal time.
Of which, the time spent will benefit the company and they can put those new skills to use in a professional environment. Win-win for everyone.
I think it was pretty nice of you to use a linear scale. If a company wanted that much more of my time I would have quoted them a premium (just as an hourly employee might make overtime in such a situation).
Exactly. The utility of income is not linear. The first 10,000 dollars are much more useful than going from 190,000 to 200,000 a year. That's why the tax system has a progressive structure. If you want me to work 10% more then you need to pay me more than 10% more.
And that does not even consider that my free time is very limited. If I have say 2h of completely free time everyday (24 hours minus work, commute, chores, gym, household crap, etc) and I need to work just 1 hour per day longer, then that cuts my free time per day in half. That is HUGE. You better pay me a lot for that.
There utility of disposable income is perhaps not linear. But I can tell you I enjoyed my second raise a lot more than my first. My first raise gave me just enough to start saving money over time, no room for quality of life improvements. My second raise is what allowed me to start spending money to enjoy myself.
What the tax system doesn't respect is that my life might be better and more productive if I spent a year earning 200,000 and then took a year off, then if I worked a 100,000/year job the entire time.
I thought someone would say that :), that's a combinatorial optimization that happens to work in the exact scenario I described, and assuming no further constraints.
But you lose out if you instead want to do 2 years on 2 years off, or if your one-year employer doesn't want you to work July to June, or if your year-off plans don't work July to June, or any number of more complicated scenarios. My point stands that the system isn't designed to support this kind of irregular high-income work.
if the company routinely requires 12hrs working days, i would stay away from them anyway
that just ensures low quality code,high pressure environment and people always on the edge ,not to mention high turnover and constant burnout and low morale
unless this is for a specific period,this is not a sustainable policy
I was also made to log in via a recaptcha today. The recaptcha widget appears just below the HN login form so pretty sure this is added by HN, not Cloudflare.
If people are complaining about it on this thread, I would also like to register my complaint with it. I think Recaptcha has two major problems:
- It's Google. I would want it to be technically impossible for someone in Google to link my HN profile with my Google profile.
- The Recaptcha widget is plain abusive to Firefox users. If I log in with Chrome, I can get past the Recaptcha hurdle in just one attempt. But if I am Firefox user, I am forced to submit like 5 Recaptchas, then be greeted with a "Please try again" message, then submit like 5 more, and only then be allowed to log in. No I don't want to do this amount of work for Google for free. I urge everyone to please stop supporting Recaptcha.
- Privacy and security enhancing techniques make the captcha harder or impossible. For example, the tracking protection built into firefox blocks the recaptcha.js (in a certain view even rightfully so, because google will use that for tracking)
- Apps do not work anymore. This cannot be solved. For recaptcha, one needs a working browser steered by humans. Apps necessarily act like robots.
This comes in line with increased usage of "2"-factor authentication.
For example, amazon now requires a browser cookie to login. If you don't have such a cookie, you need to enter a code received via e-mail or SMS. If you delete your cookies (maybe automatically), you
This comes under the pretense of security but really is used to fight user privacy.
One general point: Businesses uses machines to provide services.
Why shouldn't we as consumers be allowed to rely on machines to consume said services? 15 years ago there was this "semantic web" fad with "intelligent agents". This mess is a huge step backwards.
The root-cause of this is two-fold:
- advertising-based business model. If every "bot" needed to pay for the service as well as any other user, revenue will not be hurt by "bots".
- other misuse
- "Dumb users" as more computer-illiterate people are using these services, it gets easy for businesses to dismiss user choice.
If this should not end in a dystopian nightmare, we will need:
- Privacy-preserving login protocols that are stronger than user/password
- Privacy-preserving and low-friction micropayment (e.g. Taler)
- Some privacy-preserving way to fight misuse. I have no idea here. Maybe some crypto-social-network with zero-knowledge-foo?
Same happens on Safari, I feel I have to do the recaptcha a lot more frequently on Safari than on Chrome. I cannot find any serious study to back this though ...
Although I recommend WordPress to most people in my Technical Blogging book, I also discuss Hugo which is what OP used here. Technically you could get any blogging engine to produce a blog that looks like that, but if you're after the minimalistic look, Hugo is really not a bad way to go.
Thanks for the reply. I have tried Hugo earlier but found it confusing due to so many locations for template files (_default/? baseof.html? single.html? list.html? hard to remember all this stuff). What would be a good alternative tool where I can just place a few template files in a single location and it would be sufficient?
I have also looked at Jekyll but it is Ruby-based. I know Python. If the tool is Python-based then it would help me because it would allow me to customize its functionality or make it do some niche things that the tool does not support by writing some Python code. I have looked at Pelican too but customizing it seemed daunting to a beginner like me.
So I guess I am looking for a something simple, written in Python and easily customizable. Any suggestions?
I decided to go with Pelican for my blog, http://nil.wallyjones.com. If you are comfortable with a little HTML and CSS then you can whip up a simple minimal theme in a fairly short period of time. Honestly, I don’t even consider mine finished and tend to add to it as I write posts (which isn’t very often). If you have any questions about getting pelican up and running, let me know. You can also check out my theme, https://github.com/imwally/niltheme, as a reference for a staring point.
What is the motivation behind writing tools like these in JavaScript? Not everyone is going to have Node or NPM. I don't want to first install NPM to install a utility.
But Perl/Python/Ruby are very likely to be present on more number of systems (Windows being an exception). Why aren't more of these utility tools written in Perl/Python/Ruby?
Perl and Python perhaps, but what systems ship with Ruby by default.
But anyway even if your OS ships with perl/python/ruby installed by default (and also the right version) it probably doesn't ship with whatever Postgres library they're using so you'll still have to deal with extra dependencies anyway. And talking about Windows, installing node tools on Windows with npm is on the whole much easier than doing the same with Python/Perl/Ruby, so there is that.
If you want to make an argument that it should have been written in some language that easily compiles down to a single binary you can just download and run, then perhaps people would agree with you. But I cannot see how Node is in any way worse, harder or less common than Perl/Python/Ruby.
Perl and Python perhaps, but what systems ship with Ruby by default.
OSX comes with Ruby and has for ages, although I think that's being phased out.
But I cannot see how Node is in any way worse, harder or less common than Perl/Python/Ruby.
Node has been notoriously difficult to get running on FreeBSD, for instance. Patches were submitted and just sat on by the maintainers. Something like Perl/Python/Ruby let you target a POSIX-ish system easily, Javascript does not (case in point: electron).
Can you expand on how electron relates to the argument that JavaScript does not easily target POSIX? Isn’t the issue the runtime (Node) not some GUI “library” (electron)?
> What is the motivation behind writing tools like these in JavaScript?
I mean it's probably as simple as the person writing it being most familiar with JavaScript. There are a LOT of javascript developers who have never used perl/python/ruby before. They're not going to learn another tool just to write the tool they want.
From a technical perspective, node also has much platform support (notably on windows) than perl/python/ruby.
This wasn’t a hate post. It was a legitimate question. My systems have python by default. Why do I want to add another dependency for node plus it’s inherent requirement for internet access to drag all the dependencies?
The answer is: because the author of the tool is comfortable in the language, wrote it for their use case and have NPM and node already set up. They were nice enough to share it so other people can use it too or port it to their favorite language.
Sure they have python, but which version of python do they have? 2? 3? 3.5? 3.7?
Arguably writing command line tools in Node.js has similar problems (8? 10? 12? 12.9?) though it has the advantage that not having a baked in version into your OS distribution means you have to install one yourself (which hopefully will match).
I think Go is a better choice for this type of thing as the end result is a copy-and-run-anywhere staticly linked binary.
To be honest, backing up stuff makes sense even today. Websites do disappear. You never know when your favorite blog may disappear. There is the internet archive machine that fights link rot quite well. But it wouldn't hurt to take back ups of your favorite online articles.