[deleted]
Lessons learned from implementing a text editor related to front-end development
161–170 of 191 posts
Re: Lessons learned from implementing a text editor related to front-end development
#162not C, but probably very C useful http://scienceblogs.com/goodmath/2009/01/26/ropes-twining-to...
I made one of those in C, using skip lists instead of trees so it wouldn't need rebalancing: https://github.com/josephg/librope It could happily do 5M random single character edits / second on my old laptop. Its wild what you can pull off with C. Much more memory efficient too (it uses about 4 pointers of overhead per 180 characters). I'd love to see a version which supported traversal using more methods though - tha…
Implementing efficient datastructures in Rust often requires `unsafe` code. Unlike in C, though, you can use Traits (which provide both static and dynamic dispatch, depending on usage) to provide a safe, zero-cost interface.
Re: Lessons learned from implementing a text editor related to front-end development
#163The more I read, the more I felt that the author was long-windedly discovering FSM's, only describing them using the language de-jour - i.e. JavaScript-ecosystem-ism's. Is this the state of things today - that kids start off as highfalutin' "developers", whereby 95% of their apps are written by others (because: "npm -i "), and then .. eventually, from the top-down, trickle through the stack learning "the things", giv…
It's a general trend. Many young developers rediscover old things and describe them using familiar terms. At first it amazed me, then I understood it's more or less natural and there's nothing we can do. It's like when your son discovers the Beatles and gets excited.
Re: Lessons learned from implementing a text editor related to front-end development
#164Earlier quoted context omitted.
> The core requirements for a cs major at a typical university (read: not CMU,MIT,Stanford,Berkeley) and especially at a non flagship is basically 4 or 5 courses, which you can for sure cram into 6 months if that's all you're studying. Huh? That's an incredibly terrible CS curriculum. 4-5 courses is at most 20 credit hours. A typical undergrad degree requires about 120 credit hours of courses before you can graduate.…
Please see my other comments. I'm talking about the set of courses that are 1) offered by the CS department and that 2) every student must take. Not even the entire set of cs courses. Just the ones every student must take. > A typical undergrad degree requires about 120 credit hours of courses before you can graduate* Obviously you cannot get an entire degree in 6 months. You can't even finish all of the required cou…
> I'm talking about the set of courses that are 1) offered by the CS department and that 2) every student must take.
As I said, that was a dozen courses at my school.
Re: Lessons learned from implementing a text editor related to front-end development
#165> In other words, UI programming is about mapping incoming events to a series of effects. Sort of like programming with Monads . This is one of the reasons why programming with Monads is so powerful: the programmer can explicitly compose and control effects. Good on the author for digging in and learning new things. I'd recommend following up with reading the source to vi and doing some research on programming patter…
I've tried to push pretty hard for writing rationales for any project we make, and we've also tried to adopt making records of "big decisions" including a tl;dr of the context. Unfortunately, these tend to take a backseat to "moving tickets from left to right on a board" and in prioritizing what gets on the board, unfortunately writing things down for posterity simply never makes the cut. :o(
Those who cannot remember the past are doomed to repeat it.
And as I like to say: software is built in the image of the organization and processes that created it.
If the organization I work for doesn't openly condone it I still journal what I work on and spend time on documentation and specifications before we work on an important feature or project.
If we make a mistake or forget why a certain architectural decision was made I've found it immensely helpful to have context for those decisions. It helps make planning changes much easier.
Re: Lessons learned from implementing a text editor related to front-end development
#166Earlier quoted context omitted.
Please see my other comments. I'm talking about the set of courses that are 1) offered by the CS department and that 2) every student must take. Not even the entire set of cs courses. Just the ones every student must take. > A typical undergrad degree requires about 120 credit hours of courses before you can graduate* Obviously you cannot get an entire degree in 6 months. You can't even finish all of the required cou…
> I'm talking about the set of courses that are 1) offered by the CS department and that 2) every student must take. As I said, that was a dozen courses at my school.
12 CS courses, offered by the CS dept, and that everyone takes means that either A) your department was internalizing a LOT of service courses; B) left very little room for differentiation within your major; or C) provided very little time for exploration outside of your major.
Either way, that level of straight-jacketing and/or in-sourcing is atypical.
Even at top schools that number is usually below 10. E.g. CMU 6 (well 7, but really 6); Berkeley 4-6; MIT 8; Standford 6.
These are all off the high end of my 4-5 estimate, but only because they ALL in-source a course that at most places would be farmed out the math dept and therefore not counted by my criteria. And MIT also a comm course. Plus, there's the other extreme of places that only require the intro sequence and an algorithms course, leaving all else to the students.
In order to get up to 12 at any of these places you'd need to only offer one course for a lot of the "breadth" requirements, or else in-source the calculus sequence (or similar silly things).
Again, I'm counting courses offered by the CS dept, AND that everyone takes. The minimum viable "common knowledge" we can reliably assume is shared among all CS majors, as offered by the CS dept. IME 4-5 is pretty typical. Maybe 6.
Yes, we also assume some background in other fields of study from CS graduates (some calculus, reading/writing skills, etc.) But those courses are not the ones I was referring to with my 4-5 count. They were also addressed in my original comment.
Re: Lessons learned from implementing a text editor related to front-end development
#167> In other words, UI programming is about mapping incoming events to a series of effects. So I guess the word `event-driving programming` is lost in time. And I don't think the Unidirectional pattern described is suits for C programming. When I see people use C, I think performance, and unless the compiler optimized it away the state mutating function is gonna cost a lot of unnecessary memory copy. And worst offender…
> unless you have React-like UI diff-ing library, it's gonna be a costly entire screen redraw event for the most simple update. He's using ncurses, which actually does that - it only redraws the parts of the screen that change. It can require a bit of coxing at times to ensure that things get redrawn properly but I'm pretty sure he's good - I didn't see anything in his code that would force a full redraw every update…
> He's using ncurses, which actually does that - it only redraws the parts of the screen that change.
Heh, when I first read about React, my immediate reaction was like, "oh so it's like ncurses for the web, cool, makes sense."
Re: Lessons learned from implementing a text editor related to front-end development
#168Earlier quoted context omitted.
Thank you, for this! I could not say it better/nicer. I was getting upset with the overwhelming negativity here. Monday morning syndrome?
It's because the challenge he set himself isn't hard and he didn't do a particularly good job of it either (other comments have covered that so I wont reiterate it) yet he is soapboxing his experiences as if the topic isn't entry-level stuff. And I mean "entry-level" quite literally as you learn about event-driven programming in high school or equivalent IT classes. This isn't something you need a CS degree to learn.…
Would you please not tear other people down like this on Hacker News, regardless of what you think of their project? Even if you're right on some underlying points, it degrades the community badly.
Re: Lessons learned from implementing a text editor related to front-end development
#169Earlier quoted context omitted.
I made one of those in C, using skip lists instead of trees so it wouldn't need rebalancing: https://github.com/josephg/librope It could happily do 5M random single character edits / second on my old laptop. Its wild what you can pull off with C. Much more memory efficient too (it uses about 4 pointers of overhead per 180 characters). I'd love to see a version which supported traversal using more methods though - tha…
Implementing efficient datastructures in Rust often requires `unsafe` code. Unlike in C, though, you can use Traits (which provide both static and dynamic dispatch, depending on usage) to provide a safe, zero-cost interface.
Just to nitpick, Traits aren't (just) what make Rust fast. There's a lot of help from the compiler and the type system that allows the final compiled code to remove bounds checks in a safe manner.
Re: Lessons learned from implementing a text editor related to front-end development
#170Storing every character in a doubly linked list seems like an extremely inefficient use of memory. Depending on your architecture, that could use 24 bytes per ASCII character (if the char in the struct is padded with 64-bit pointers). I imagine that vi wouldn't have gotten very far if it had been that memory constrained.
Right. Wouldn't it be smaller to even use UTF-32 and just jump forward and back in 4-byte blocks?
Yes, a common way to store the text in editors is a gap buffer[1]. It allows efficient text insertion/deletion in one point and doesn't have too much overhead.