121–130 of 146 posts
Earlier quoted context omitted.
The GitHub page states: "The project is in alpha stage and was written in just a few hours taking code from my other two projects, load81 and linenoise." https://github.com/antirez/kilo
Yes, thanks for pointing that out. I'm more interested in total time. Not time to write. :)
Earlier quoted context omitted.
The syntax highlighter isn't really a parser, per se . It's just a lexer / tokenizer / scanner / what-have-you, which tend to be fairly compact state machines. As an aside, I agree with your edit. As someone who started programming back in the DOS days, whenever I do Web development, I'm always floored by how much it feels like one step forward and two steps back. So many simple things just aren't simple when it come…
I started programming in the same era, and feel the same way about "web apps" being a step backwards. The problem is we're building apps on top of a platform originally intended as a document viewer, with kludge upon kludge piled on...
Earlier quoted context omitted.
A while back I'm sure I saw a HTTP state diagram posted here that showed writing a HTTP parser is anything but simple. I guess if you only have to be a (reverse) proxy you might get away with it.
You're thinking of https://github.com/for-GET/http-decision-diagram
Earlier quoted context omitted.
Well, not really. My system doesn't have vi installed. Vim, of course, any time of the day. Stripped Vim (vim-tiny, as Debian calls it), sure, just after installation. But vi -- no, I don't have it installed. For quite a long time Linux didn't have vi even ported . There were several clones, like Elvis and nvi (and Vim, of course). Few years ago I learned that somebody took the effort and actually ported traditional…
You are being needlessly pedantic. The point is that typing "vi" into a terminal runs some application that implements a "vi-ish" interface. Whether it is ported vi or vim or vim-tiny has some effect on how nice that interface is to work with, but I would argue that most vim users would be able to get their configuration fixed or whatever
I assure you I am not pedantic needlessly. The claim was "vi has some issues with arrow keys". Now tell me: which vi clone was elsurudo talking about? Because those are different projects. And Vim doesn't have a smallest issue with arrow keys (unless with "compatible" option set, I think, but I didn't use it for years and I may remember wrong).
> Let’s say this again, “email client”. The notion of email client itself is gone at this point. Really? Is it lame to be using an email clients these days? I still use an email client (Thunderbird) because I can't stand the thought of all my mail sitting forever on Goggle's or whoever's servers. Yes, I know that they could have secretly archived all of my email the moment it was sent or received, and that my privacy…
I've actually been working on a new email client, and a terminal one at that. Shameless plug: https://github.com/SirCmpwn/aerc
Earlier quoted context omitted.
Or you're making assumptions based on your own skills? Have you seen what e.g. Notch can do in a few hours of live coding?
If you create a screencast I assume you give it your best. Look at the typing skills demonstrated in the screencast accompanying this project, https://asciinema.org/a/90r2i9bq8po03nazhqtsifksb Judging from the screencast he use around 10 seconds per line. That would be, (10s * 1000 loc)/3600 = 2.7 hours just to type 1000 lines of code. Programming is of course not typing, but a mental activity first and foremost. Let…
You'd be surprised. Especially if you have done C for 1 or 2 decades, you can write 1000 lines in 5-6 hours easily, even without thinking, especially since those lines are for a very specific, and not surprising domain and functionality. It's not like you need novel thinking or to solve some unique challenges to build a text editor of this level. It reads and saves text files, moves the cursor around, and does some crude syntax highlighting. Big fucking deal.
Most of those lines, of course, are also quite easy to fill given C's verbose nature, e.g implementing a few standard data structures you'll need can easily fill 200 or more lines.
>And of course I know that "a few hours" is just something one say to look cool. I just don't think it is cool.
You keep insisting that he lied, without proof. That's untactful. You also keep acting as if this is some huge feat that nobody can pull off and people can only claim to do for "coolness factor".
Are moderns developers so out of touch with C?
Antirez's posts are hardly ever really "useless" :) Awesome stuff, as always.
Earlier quoted context omitted.
FastCGI/SCGI were obsoleted by having app servers simply speak HTTP; the web gateway just needs to function as a simple reverse proxy. HTTP is about as simple as it gets to parse - you can write a passable (not quite production quality, but works) parser in about 10 minutes. A lot of the difficulty in webapps is because every webapp is inherently a distributed system, which are always hard. Single-page apps with no c…
A while back I'm sure I saw a HTTP state diagram posted here that showed writing a HTTP parser is anything but simple. I guess if you only have to be a (reverse) proxy you might get away with it.
Anyone up for converting it to Swift (3) or Rust?