Is that POST in the readme sending the password in the query params? Is this shorthand or literally adding them to the params?
I don't really feel the need for a curl replacement. In the past I've used httpie which is pretty slick but I end up falling back to writing tests in python using requests library.
Maybe I'm not the target audience here, but I should still say something nice I guess. It's nice that it's written in Rust, and open source tooling is in need of fresh projects ever since everyone started bunkering up against the AI monolith scraping all their work. We should celebrate this kind of project, I just wish I had a use for it.
The POST in the README is going to send the params in the request body "url form encoded" like a form in a web page. There are more samples on the doc site [1].
Regarding curl, Hurl is just adding some syntax to pass data from request to request and add assert to responses. For a one time send & forget request, curl is the way, but if you've a kind of workflow (like accessing an authentified resource) Hurl is worth a try. Hurl uses libcurl under the hood and you've an option `--curl` to get a list of curl commands.
> The POST in the README is going to send the params in the request body "url form encoded" like a form in a web page.
Is there a different POST request in the readme or are you saying that this example is going to send the "user" and "password" params in the request body?
That seems really surprising to me - how would you then send a POST request that includes query string parameters? The documentation on form parameters [1] suggests there's an explicit syntax for sending form-encoded request parameters
I see it more as a Postman replacement than curl. When I’m working on a set of APIs, I can quickly write a Hurl file with different combinations that I’m working on. There are usually editor integrations to run individual requests. Then I can share the same Hurl file to my team or commit it in the repo.
I don't understand this attitude. It's clearly more conducive to solving problems to be able to move around our environment more quickly. It's extremely useful (compared to a beginner who only knows insert and write quit) to understand the different vim modalities as well as a few commands to jump around a file or to perform regex or to call an external command.
When you're not proficient with the necessary tools, you're interrupting your flow with what you consider mundane. That you consider text editors mundane is more reason to move as much of that process into muscle memory as possible, not less!
Why are we pretending like mastery of our tools is unimportant? I hear this sort of opinion most eagerly expressed by engineers who in fact are quite handy with vim! Is this some new kind of flex where we're all pretending to take a purely academic approach to programming instead of becoming proficient with the tools of our trade?
I feel like at a certain point of efficiency there are diminishing returns. A good analogy is typing speed. You don't need to have 200 wpm to be productive. Everybody adapts to how efficient they need to be at what they do. Vim is not a requirement for being productive. If it was, it would be the most popular editor. I also don't think the person you are replying to is saying that it isn't important to "master" your tools. I think they are just saying the editor that you use isn't the most important thing and I agree with that sentiment.
You don't need to hit 200 wpm but I haven't seen too many programmers who hunt-and-pecks at the keyboard and can't touch type. Even on a Qwerty keyboard you should be able to get high double digits, if not hit/exceed 100 wpm. The two sites I like for practice are:
Typing fast for sport is fun, that I understand. But it's really weird (to me at least) how most developers say that measuring lines of code as a performance metric is an awful idea, and then there are others that more or less kinda shame people for not being good or great typists.
Am I crazy? Isn't it conflicting? Maybe those two groups don't overlap at all? Then do great typists believe measuring lines of code to be a good idea?
And being proficient at using your code editor doesn't require or exclude being fast at typing. Between the two I personally would chose mastery of vim/emacs or some other IDE over having a typing speed faster than 80 WPM. Sure, both would be great, but if I have to choose one I know which I prefer.
Full disclosure: I type on a QWERTY layout at an average of 65 WPM.
One thing I'd add is that some stuff like Home Row Mods, Caps Lock as ESC and enhancements like that seem to me like a larger productivity booster than the jump from 70 WPM to 100 WPM. But even so I might be wrong on that because I personally haven't experienced writing faster than 70 something WPM at my best.
Anyway, rant over and I apologize if I come off as rough. It's just something that's been nagging at the back of my mind and I still don't know how to properly put it into words.
Sure typing speed utility drops off pretty quickly but if it is a bit lower or makes just a part of your brain stop coding and think about more physical matters that should be in muscle memory then I think it has an effect on your ability to write a flow of code. (I saw this a great deal with regional keyboard layouts.)
Its hard to say if what you program will ultimately be better or worse as being used to micro interruptions can mean more diligence as much as they can mean forgetting an important caveat. But generally I think it means you are progressing at a slower rate toward an integrated group of skills.
For editors and IDEs it can be quite similar for refactoring, debugging and analysis of the code base. The worse you are at using them or the more indirect your proximity to the exact code base of the version you are working with, the more you rely on building/maintaining mental models which has its benefits and dangers.
I think its very hard to say anything is right or wrong. I do think that the question of where you expect to be in terms of needing each skill as your mastery of others grows is the question.
I don't see how they are related at all! Even the worst programmer can see that if we were to judge by LoC that they could add frivolous lines to juke the stats. LoC is stupid and I don't see how LoC is relevant to the conversation at hand. I do think that every programmer's had that stroke of inspiration where they can't type fast enough to get the code out of their head though
As far as typing speed, the difference between 10 wpm and 40 wpm is far greater than 70 wpm and 100 wpm. You don't have to hit 100 wpm to be a good programmer, but I have a hard time believing you can be one hunting and pecking at 10 wpm. (With exception made for the blind.)
> that measuring lines of code as a performance metric is an awful idea, and then there are others that more or less kinda shame people for not being good or great typists
I'm not on board with shaming people, nor do I think that lightning speed typing is needed. However, one I want to type my lines of code, no matter how few they might be, it's about translating thoughts into code as easily as possible. It helps not having to bother with the details of typing, but the typing more or less taking care of itself. Keeps the zone and the focus on the code, and not on the keys.
Touch typing seem like a useless skill to me. I use keyboard more for navigation than actual typing. I read many times more code than I write.
And when I write I just need to see the keyboard with the corner of my eye and my fingers just find the right keys as I'm pecking, purely through muscle memory that I've gained with zero effort just by years of experience.
I have to switch back and forth between french (azerty) and english (qwerty) many times a day. My typing speed has regressed. But I manage just fine without hitting 200 wpm. How does one practice the constant switiching?
He’s also looking at the keyboard, so maybe he’s unfamiliar with it. Perhaps when shooting the video they thought, hey, we need that cool clicky sound, and had him use a mechanical keyboard.
But in all, he types fast enough to write Linux.
Typing speed is important for typists. For programmers, I’d say that even a 50-80 wpm rate is adequate for getting your thoughts down on the file and off to the compiler.
VS Code with vim keybindings is extremely popular. If you don't know how to use vim, you just don't realize how much of a time/effort saver it is. I can't imagine not having wrist pain if I had to use the mouse every time I wanted to move my cursor around for more than a few characters/lines. Trying to not use vim feels like going back to the stone age whenever I can't use it. I like to use vim bindings even when I'm editing english.
I used vim for 5 years, afterwards I switched over to Emacs, and I couldn't disagree with you more. What's clumsy and slow is having to switch between insert mode, normal mode, and visual mode hundreds of times while working rather than just using modifier keys for special actions.
If you're entering normal mode for one or two commands at a time, that could be problem. However, if you're fast at entering normal (i.e. use jj, fd, Caps Lock as Esc, etc.), that's not a meaningful overhead.
On the other hand, having to constantly hold Control/Alt, including long chords (e.g. with prefix + count), feels much worse for me. I use Emacs keybinds on the terminal (outside of vim), but I can't imagine having to constantly press modifiers. It's not as comfortable as switching to a mode where those actions are explictly first-class.
i think what you're describing sounds a bit like visual mode which is just v
d and p for cut and paste if moving stuff around needs to be done (dd for whole line, 5dd for 5 lines, v and then j a few times in visual mode before d or y for yank (copy), etc...)
Note how you don't have to strain your pinky to hit ctrl for any of these?
I'm in two minds about this. Yes, wpm aren't everything (see the other discussion in this thread) and the same goes for the full range of your editor's functionality.
On the other hand, tools like Vim, Kakoune and Helix shouldn't be treated like your average Java IDE, for example, which shifts the line of what I'd say is reasonable learning investment. What you're dealing with there is a programming language for text manipulation. If you're fluid enough in it, you open your mind for solutions you'd never have considered before. I'd say you'd need at least intermediate Vim skills and should know macros until that effect kicks in.
I have quite some anecdotes about e.g. creating integration tests where my colleagues wouldn't test something properly just because doing so would involve 10 minutes of drudge work in their simplistic editors, instead opting for "deploy & pray" when the task was totally doable in a couple of seconds with a Vim macro. I find that at least in this regard (as for all programming languages), Benjamin Lee Whorf's quote certainly holds true: "Language shapes the way we think and determines what we can think about."
That's why I also think GP had a point. I would probably be much more in your line of thought if we were only talking about the usual contestants like refactoring snippets etc. here, although even having them handy will already influence how many of us work with our code.
Edit: As another analogy, I feel that modal editing has about the same effect on thinking as switching from roman numerals to arabic ones. The reason why it hasn't completely caught on is just that it's less intuitive and text manipulation is not as fundamentally important as calculations for our civilization.
> would involve 10 minutes of drudge work in their simplistic editors, instead opting for "deploy & pray" when the task was totally doable in a couple of seconds with a Vim macro.
I really very much doubt this. Sounds like an application of rose-tinted glasses and wishful thinking to some one-off task that then is extrapolated to all tasks.
Hey, I didn't say I do this every day. But I've had enough of these conversations that I can assure you that this low a bar is needed for some people to skip important jobs. If your doubt applies to the usefulness of knowing the system, I don't really know what to tell you -- if you can't take someone's word for it, I don't think anything less than you experiencing it yourself would convince you, anyway.
As for one-off tasks: Yes, that's what Vim bindings are good for. Just like AWK-Scripts are great for throw-away scripts. Being able to perform simple one-off tasks quickly is, incidentally, a skill I find to be far too rare even in programmers. I mean, I would've thought at least us techies see the benefit in knowing how to teach the computer to do the menial tasks for us.
> But I've had enough of these conversations that I can assure you that this low a bar is needed for some people to skip important jobs. If your doubt applies to the usefulness of knowing the system
No. My doubt extends to "omg vim is so amazing that these tedious tasks take seconds unlike in these primitive text editors".
Because my experience at work has been consistently the exact opposite: vim users routinely take longer time for most tasks precisely because it's a rather primitive text editor, and not a code assist tool.
Well, I'm not really sure if we're talking about the same thing. If you're talking about language integration, I've got no quarrel with that (see my earlier comment). The experiences I was referring to are more along the lines of text manipulation in general, not "rename class", "extract method" and the like. If you're talking about features like that, I'd readily agree with you: Trying to do the same thing with Vim macros is just picking the wrong tool for the job.
I won't beleive your assertion, however, that this invalidates the benefits of learning Vim bindings (especially since respective emulation layers are at least passable in pretty much any editor or IDE worth its salt).
If you're talking about normal minute-to-minute text handling and creation of text files without language assist (scripts, cucumber tests, any programming task not blessed by your IDE's refactoring integration) on the other hand, we're at the point where I have trouble believing you.
I get what you mean, but "minute-to-minute text handling" for me is pretty much always covered by my IDE's refactoring integration. Like, in the last few weeks, I've written a whole load of Python, Rust, and Typescript, where the IDE covers pretty much all my needs, and then maybe in total a day or so of fiddling with Dockerfiles and config files? None of which were really long enough or complicated enough that I needed anything complicated in terms of editing techniques, most of my time was spent waiting for builds to run and then trying something else out.
So yeah, you're probably right that Vim techniques are far better when you're editing those sorts of files, but those really do make up the tiniest fraction of my time, and everything else is covered by IDE refactoring tools. And if I had the choice, I would always rather have the better IDE tooling than the improved text editing, so this doesn't really sell me on the whole thing.
I would like to try Vim-mode for VSCode at some point, because I can imagine that being a kind of "best of both worlds" thing, but I've not really got round to it yet.
> If you're talking about language integration, I've got no quarrel with that
I am. Because we are talking about these mythical Java programmers who couldn't do something that Vim would have done in seconds
> I won't beleive your assertion, however, that this invalidates the benefits of learning Vim bindings
And the reason to learn them is because there's a fairy tale of some programmers not doing the job that we're led to believe could be solved in seconds in vim.
> If you're talking about normal minute-to-minute text handling and creation of text files
Are we? Let me remind you: "I have quite some anecdotes about e.g. creating integration tests where my colleagues wouldn't test something properly just because doing so would involve 10 minutes of drudge work in their simplistic editors, instead opting for "deploy & pray" when the task was totally doable in a couple of seconds with a Vim macro."
Oh look. We're literally talking about programming.
> we're at the point where I have trouble believing you.
Let's start with your fairy-tales before we come to believing or disbelieving what I wrote.
Ah, so we're arguing in bad faith. In this case, I won't try to keep some semblance of a useful discussion going. For your interest, most of our integration tests are written in a cucumber dialect and contain very verbose "business-y" messages passed in and out of the system under test.
But then, I'd guess from your tone that this won't stop you from misreading another comment of mine and accusing me of lying, so I'll just wish you a nice weekend instead.
I wrote a comment agreeing with your parent comment, but this probably applies to me:
> I hear this sort of opinion most eagerly expressed by engineers who in fact are quite handy with vim!
But to me, that makes me think that you should wonder whether there's something to that. For me, you're right, I did get really handy with vim at one point. After I had been using it to a very basic level for two or three years, I felt kind of sheepish and guilty and endeavored to learn it properly. So I bought into doing it "right" for awhile, wrote a bunch of custom script to customize it, the whole shebang. And my conclusion after that was that it wasn't really worth it. I went back to just using the basic stuff. This is also, importantly, supported in every IDE's keybindings, so I can use modal navigation and editing anywhere without needing to customize anything, which is pretty great.
It is not about only Vim as editor but Vim as keybindings too. Nowdays, most of all modern IDEs support Vim keybindings along well integrated IDE features.
This is true for tools in general but I've managed to master vim to the point I can be somewhat productive yet it never feels quite ergonomic. Moreover, I think vim-like UI is holding everyone back nowadays. Learning all the intricacies of vim feels like an exercise in brute-forcing a deliberately user-hostile design.
For example, is it really still OK to have little to no visual feedback when entering commands with range/count prefixes, or to have to fall back to custom commands and configs in order to search for strings containing "/"? Or have commands with tiny edit distance between them do radically different things (e.g. "w! " and "w !")?
Vim's modal editing implementation also can't handle non-Latin keyboard layouts so I find myself switching keyboard layouts all the time (e.g. normal mode->insert mode->layout switch->type some text->layout switch->normal mode).
It really isn't. I've spent a lot of time trying to tune langmap/keymap and looking into other options but the result is mostly unsatisfactory. Some of the issues: only translates the first letter of the command; doesn't support :commands; isn't expressive enough to remap punctuation.
Vim needs to be keyboard layout-aware in order to support non-Latin keyboards. It also needs to know whether the current input state is expecting text or a command (e.g. typing ":s/" from the normal mode should always be parsed using the Latin layout but the currently active input language should be used following the "/").
I’m definitely not going to try and endorse intentional incompetence.
I think it is just not so tricky in the first place. If you start out with “you can use hjkl for directions, and y for copy, d for delete, these can be combined with directions and prepended with numbers; remember the modes, and :w and :q” vim is already as good as most others editors. Then I’d just start using it, rather than trying to learn from the top.
My filter for when I should learn a new feature is when it solves a task I find repetitive and annoying (or I will make a post on Hackernews that says learning Vim is useless, to get a list of features that people actually use day to day). Since we all have different idiosyncrasies, this filter will be different from person to person, so I don’t really get the idea of a guide.
That said, I’m just describing what worked for me; if someone wants a guide they should go for it, we all learn differently after all.
> My filter for when I should learn a new feature is when it solves a task I find repetitive and annoying
There! You said it so well... that's the #0 reason why I go RTFM'ing, because most likely my problem fits a pattern someone already encountered and figured a solution for. Or nobody did and I put together a less annoying workflow to deal with it.
Sometimes the effort is worth it, but often it is just fun trying out new things/techniques.
If you're forced to work in the terminal, vim's great. But to get it to do something approximating an IDE, is it worth the time to tweak configs/plugins and memorize hotkeys, rather than just using a _real_ IDE?
Besides that, I just find the whole method of navigating (skipping words, skipping an X amount of lines) counterintuitive. It's nothing I can get used to, I will always miss the precision of just taking the mouse and getting the cursor exactly where I want it in one sweep and click.
> It's clearly more conducive to solving problems to be able to move around our environment more quickly.
Then vim ain't it.
My "vim-empowered" colleagues spend significantly more time trying to find symbols, related configs and tests, function definitions and interface implementations than I do. Because their hodge-podge collection of vim plugins and extensions rarely amounts to anything more than a full-text search across the whole project.
But sure, you can count the number of lines where you need to go and then the number of characters/words you need to move in the line and code it in 3 characters. By the time you've done that I've clicked there with the mouse, found the definitions and done project-wide refactoring.
He mentions building habits in part 2 of the article, using the boiling the frog analogy (imploring the reader to use it for good instead).
My question, though, is how does a good habit expand into a great habit, without motivation? For your tooth example, once you start flossing you might as well floss all your teeth. The upfront cost of getting started with the floss is the worst part of it, but once you're there it's easy. This isn't true for all habits though. For many it's easy to just bail out fast. If I started doing 5 push-ups a day will I eventually do 100 and then 1000? Or would I settle somewhere on a mediocre range because it's easy to stop? Is there some sort of recursion or positive feedback loop that kicks in that rescues me from mediocrity if all I have is discipline and not motivation?
If you start with 5 push-ups a day, you'll hit your limits fast just increasing push-ups by one a day, so spread out your improvements by increasing in several exercises, adding more if necessary. Not to do all of them at once every day, but ones to switch between daily. I started something like this years ago, and I'm still keeping up on it. If life happens and I have to take a break from it, I restart it later and reduce my goals so that it doesn't seem so bad trying to jump back into a routine I was maximizing earlier.
The key was to make it a habit I do every day, like brushing my teeth. If I've had a bad day and miss doing my "workout routine" (such that it is, I'm no Arnold), it feels weird to miss one and I look forward to doing it the next day. So in that way once you've made it to a certain point it's self-fulfilling.
One problem with DEI is that many ethnicities get thrown under the white or white-adjacent umbrella and aren't given the same opportunities simply because the popular view of history doesn't seem them as historically oppressed when in fact they were. For instance, Armenians are a historically oppressed group, even genocided, yet they are not afforded any DEI perks in their career paths. Palestinians are also not included in DEI because it isn't politically expedient to side with them, even though they have lost their homeland and are generally treated like dogs. Many, many such groups exist but because they don't come up during AP US History, they have no mindshare.
Another is that DEI seems to simultaneously accept that race is a social construct while also using race as a key criterion for purposes of inclusion, which is absurd. For example, a Black Swede, growing up in Sweden her whole life, would be considered a candidate that improves diversity in the workplace. However, I'm not aware of Swedes being an oppressed people. In fact, growing up in Sweden your life is probably better than in America. The judgment is made purely on skin color and lineage.
Lastly, I also want to say that I know this is an ugly situation, because high paying jobs are often about connections, which have a strong correlation with ethnic background in the United States. In that view, it makes sense to have something like DEI shine a light on power structures within the workplace and make them more fair. So despite the above, I support DEI if it helps underprivileged people. After all racism still exists, and it's virulent. Many people harbor racist views and will lie through their teeth in order not to be canceled.
I just hope eventually racism is extinguished so we could move forward to a purely merit-based system.
White-adjacent is one of the dumbest terms I've ever heard, and is downright offensive. But hardly the only one to come out of DEI-like minded movements. Latinx being another.
How many nodes (droplets) do you spin up that you need Terraform? I do something similar but I use a single script to spin up the Digital Ocean side and then I complete the setup in Ansible (with an all-in-one master script, since the DO droplets are fetched with a handmade inventory plugin).
Dell lost my confidence when their XPS 15 display couldn't display a pane of gray without flickering. I switched to a Macbook Pro and haven't looked back.
For me (personally) to consider Dell again, they would have to replicate everything that Framework does and ship Linux with support.
Edit: can I also add that they suck for business too? The slim form factor has NO place in business, slimming down the chassis and removing ports is an anti-pattern. I couldn't give a shit how thin my work laptop looks, my job doesn't involve taking pictures of unrealistically minimalistic office desks. With Dell you either get a dainty oversized netbook or a rugged behemoth (which is a little too rugged unless you're in telecom and roll in a van). Where's the middle ground? Nothing needed to change from the old thinkpad.
It's arguably the most important attribute for quite a significant chunk of the business world. Work laptops need to be transported at least twice a day and most business tasks aren't at all demanding.
My dad's work mandates that he has to replace his laptop at most every 3 years and he has always picked the lightest macbook Apple sells. For a long time, it was the 11" Macbook Air and then it was the much derided 12" Macbook with a single port which he loved. Now, he's on the extremely well reviewed 13" M1 MBA and it's the least favorite of all the macbooks he's ever owned and he keeps asking me if this is really the smallest laptop in Apple's lineup and to let him know when Apple launches a smaller one so he can switch immediately.
> can I also add that they suck for business too? The slim form factor has NO place in business, slimming down the chassis and removing ports is an anti-pattern
Define "business"? A salesperson that frequently travels to customers needs a thin laptop more than they need a powerful one. The opposite is true for a developer that would need more power but doesn't require the best GPU and screen, which a design person probably does. Dell offer all sorts of laptops fitting each of those use cases (unlike say Apple where e.g. the screen is non-negotiable).
I can confirm - I have a Precision 7670 in pretty much the top spec(i7-12850HX, 128GB ram, 3080Ti) and it's an absolute beast. It blows my previous HP Z5 workstation desktop out of the water, it improved my compilation times by half. Really made my work more productive thanks to the crazy spec.
You must be thinking of a different line of laptops - the Precision workstations are anything but thin. They are big and pretty heavy laptops with plenty of ports.
AMD did the same when they got an advantage through Ryzen. Intel quickly overtook them again and now they're back to being the underdog.
Threadripper got killed off because it was starting to compete with AMD's own products, performance increases started to diminish, AMD very much took a short break when were at the top again. The only difference is that Intel managed to stay on top with their Core architecture for so incredibly long.
That's not necessarily bad, of course. This behaviour has led to competition and competition is almost always good for the consumer.
The reason Intel gets more negativity here is that time and again they try to prevent fair competition. Itanium was an attempt to break AMD’s ability to sell x86, and each of the previous times AMD was providing better performance or pricing, Intel used their market position to require things like exclusivity or minimum volume commitments.
Given how well competition has worked for consumers, I do wonder if there’s some regulatory option here to reduce those back room deals. Given the way the world runs on microprocessors now there’s a decent argument that maintaining a robust market is like what we used to do to prevent one railroad or steel company from getting too much control.
You are right. Intel is terrible for competition. They had to be dragged, along with their SandyBridge, kicking and screaming into the future in order to keep up with AMD for the better part of a decade now.
I've owned AMD CPUs before. 386DX-40 and Athlon II and such.
But Threadripper was unreal. And seemed like it was going to be the norm for an era of HEDT.
But AMD got greedy on the promise of corporate desktop dollars, over-stratified, and let a flagship technology fade into "what about Threadripper? No, it's for Lenovo customers."
Openly an AMD fanboy, but this year's offerings by Intel were too good to pass up in comparison, as I was due for an upgrade. Same with NVIDIA - instead of AMD went with them.
I'd imagine a healthier version of something like: "Simpletons, relying on consumerism for their dopamine rush, they're no different from ants! Meanwhile I am a /creator/ of things!"
I'd say my version does not include comparison to others. I actually wish more people try their best to create great things even if what their creations are much better than mine.
My version would be more like :
"Owning a car is very circumstantial. It means you temporarily have some property right on it. It can break, it can be taken away from you. If you create something it's yours forever. Its existence is not independant of your will.".
At the end of their lives some people will have owned ten cars, others will have written ten books.
You can't hide in that idea because back in the real world, your friends receive all the love and admiration for owning great things (something like status), while you get a tap on the shoulder.
Not “the real world” but rather your perception of the world. “The real world” implies that it’s the same thing you describe for everyone. It is definitely bot.
We may live in different worlds. I don’t know anyone who buys a new car every year and if one starts to do so I will feel sorry about their poor financial judgment.
I don't really feel the need for a curl replacement. In the past I've used httpie which is pretty slick but I end up falling back to writing tests in python using requests library.
Maybe I'm not the target audience here, but I should still say something nice I guess. It's nice that it's written in Rust, and open source tooling is in need of fresh projects ever since everyone started bunkering up against the AI monolith scraping all their work. We should celebrate this kind of project, I just wish I had a use for it.