91–100 of 193 posts
Earlier quoted context omitted.
It's a joke / PoC project. Nobody should expect it to be maintained in any way. None of those PRs are important in that way.
> Nobody should expect it to be maintained in any way. Which is the exact problem of "I could rewrite this in a weekend!" scenario with curl, right?
What's frustrating is people who think that they can radically simplify something without knowing anything about it. The same people think they can implement a text editor in 1000 lines of code because that's how the first text editors were made. Why can't we go back to those simple days? We can't because modern software handles cases that those didn't. For example, rendering and editing text seems straightforward un…
"What's frustrating is people who think that they can radically simplify something without knowing anything about it." This type of mentality is also rampant in the world of entrepreneurship - Theranos et.al Sure, it's good to get new eyes on some problem, but it's the hubris that can kill.
You get development efforts with massive scope people brush off as nothing. I've worked with a lot of these sort of groups where someone entrepreneurial understands enough to think they can simplify and improve something. Then they get a developer, two, or small team that agree. They start the undertaking or even worse, do the work under contract for someone else where they have contractual deliverables. Some way in they start to realize just how shortsighted and cavalier they were about brushing off uncertainties they either knew or didn't know about. "It can't be that hard! It's just software, it's all virtual! We don't need a bunch of capital! We just need a little bit of math! ... "
All those uncertainties start to become quantities and they realize the absolute pit they dug themselves into. At that point they look for someone to swoop in and cleanup their mess. Usually it takes careful reading of the contract deliverables with liberal interpretation of what is stated and how those things can be minimally met. You really need people familiar with the types of software and systems involved and needed to achieve your goals to narrow down these uncertainties. If you don't then you're digging your own grave.
https://www.bitquabit.com/post/one-which-i-call-out-hacker-n...
Just a little tangent but I think everyone should know cURL… not postman, not httpie or any other more “friendly” tool. cURL is the standard, pre-installed, do-everything, scriptable tool to interact with web APIs. I could say mostly the same stuff about knowing Bash. It separates the barely effective from hyper-effective individuals on simple day to day (programming) tasks.
I really wish busybox would bundle curl instead of wget. In the age of containers, I often find myself having to use wget when operating inside of one with busybox as shell, and I get it wrong on first try. What usually trips me up is the syntax: `curl -O http://host/file ` (goes to stdout without -O) instead of `wget http://host/file ` (goes to file without -O)
Of course now I feel really icky if im ever forced to use wget. And curl’s feature of defaulting to stdout is of course a perfect thing and makes way more sense than the alternative (for many reasons).
What's frustrating is people who think that they can radically simplify something without knowing anything about it. The same people think they can implement a text editor in 1000 lines of code because that's how the first text editors were made. Why can't we go back to those simple days? We can't because modern software handles cases that those didn't. For example, rendering and editing text seems straightforward un…
I have a chunk of code for implementing pointers, cursors, button clicks, and drag-and-drop in games. It's some of the gnarliest code I've ever written. It's also some of the most resistent code to "good design patterns" I've ever seen. I've written it and tweaked it and rewritten it and thrown it away and started from scratch and it always comes out the same. When you're dealing with things that have to meet long-established user expectations, it's always going to be full of little edge cases that you can't abstract away.
What's frustrating is people who think that they can radically simplify something without knowing anything about it. The same people think they can implement a text editor in 1000 lines of code because that's how the first text editors were made. Why can't we go back to those simple days? We can't because modern software handles cases that those didn't. For example, rendering and editing text seems straightforward un…
We also saw this with COVID. Plenty of people with no knowledge in infectious disease stating that the public solution was stupid and wrong but instead the obvious, simple and effective solution would be to "just do ....".
Personally if that happens at work and somebody (often managers) tells us to solve a difficult problem by "why don't you just..." I usually tell them the code is available and they "can just do it" themselves. So far I have never had any takers.
Earlier quoted context omitted.
I think there's more truth to this comment than your presentation suggests. I bet at least a subset of people who think they could reimplement curl easily, think of curl as a CLI tool to make HTTP requests. It's just a little bit of python/requests or node/fetch code to cover some basics for that. I think these people simply aren't aware that their programming language's built-in libraries often call in to libcurl fo…
exactly, my point was, some people think they can build it in a day, because they see their favorite library already supports sending HTTP, they might not be aware that some of those libraries are wrappers around cURL library
Let's be honest here. Curl to 98% of people is http/1 requests with some post params and maybe json body, with some custom headers. Most language standard libs (which might be using libcurl) can facilitate writing that relatively quickly. And probably with a more 'modern' CLI. Curl though, is a very wide breadth project. It currently supports the following protocols: DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP,…
> SMB Woah. This is genuienly impressive.
The simplest solution would have been to give up the instant I started reading the catched traffic. I gave up after about 40 minutes of trying to figure out where to start.
Earlier quoted context omitted.
And in fact even the "simplest" editors seemed to take quite some time even for our heroes. Ken Thompson has stated [1] that he devoted a week out of a month for what I understand was the first version of ed(1): [...] [my wife] was gone a month to California and I allocated a week each to the shell, to the operating system, the shell, the editor, and the assembler, to reproduce itself [...] [1] https://www.princeton.…
An editor seems insanely simple until you realize that computers really don't like "inserting" data into existing data in memory, and then you're staring down the barrel of continuous memcpys.
Ah, darn. That'll teach me to comment without refreshing the page first. I refer you to the earlier DonHopkins post.