Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons learned from implementing a text editor related to front-end development

lpan.io

Post reply on HN
Print view View original

121–130 of 191 posts

Re: Lessons learned from implementing a text editor related to front-end development

#121

Post by widdershins »

arximboldi wrote: post #59

Very interesting work! It seems that educational text editors are becoming a trend after Antirez published his :-) Excuse me the shameless plug, I'd like to show mine too: https://github.com/arximboldi/ewig It is written in C++, but using a style that is unlike what most C++ developers use: it is composed mostly of pure functions. The architecture is very much like that of Elm programs, and there is even a `store` cl…

Very nice, I've been wondering when someone would implement some Clojure-like data structures in C++. I will be playing with this next weekend.

Re: Lessons learned from implementing a text editor related to front-end development

#122

Post by olddevanon »

robotresearcher wrote: post #118
olddevanon wrote: post #100

Earlier quoted context omitted.

> According to author's webpage[1], he's a "student at the University of Waterloo, class of 2021". > So probably age 17 or 18. He's not passing himself off as a "professional". Fair enough, though I am still surprised he hadn't learned that in formal education already. I was taught about event driven programming before I got to university. The schools I went to weren't particularly good either so it's not like I had…

Most students have close to zero programming training of any kind before getting to university in Canada.

Maybe this is where regional differences come out as most students in the UK have had some programming lessons before starting uni (albeit they often haven't done any recreational programming).

That was my observations at the time anyway. Things may have changed and/or I might have introduced selection bias by hanging around with the nerdier kids. Who knows - too late to find out now.

Re: Lessons learned from implementing a text editor related to front-end development

#123

Post by disquist »

I am a novice in this area, so forgive me if I am missing something, but I have some questions regarding the two approaches in the article, specifically if there is a performance trade-off being made between them.

To my untrained eye, the initial version seems to be doing a minimal set of updates based on the input it receives, whereas the latter version will call the monolithic render procedure no matter how small a change is made to the state.

Does each of the sub-procedures in renderTodo! check internally if the state actually changed (by keeping a copy of the previous state?), or do they just unconditionally re-render the entire UI? If the latter is true, then doesn't this supposedly better way of structuring code come with a large performance penalty? Or is it simply the case that this penalty is outweighed by the added test-ability and improved consistency of the state?

I believe that React and similar frameworks run a diffing procedure to find out which parts of the UI actually need to be updated (so a more minimal set of updates is actually applied). In the first version, however, it seems like the same diff occurred naturally as part of the code's structure - only a subset of the render* functions are called - and therefore the diff does not need to be computed at run-time.

Is this something worth being concerned about, or is letting the framework compute the diff on every state change not that big of a deal?

Re: Lessons learned from implementing a text editor related to front-end development

#124

Post by innocenat »

clarry wrote: post #76
innocenat wrote: post #26

> 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…

Write a game or an editor with support for macros and see if it isn't faster to first mutate the state and then finally render, rather than doing thousands of ad-hoc screen updates, most of which won't be visible in the end anyway.

And then we arrive at dirty marking, etc. Unless you also consider that state manipulation (which I don't think it is).

Re: Lessons learned from implementing a text editor related to front-end development

#126

Post by smallhands »

Sacho wrote: post #116
taneq wrote: post #95

Earlier quoted context omitted.

My grandad used to say if you learn to sail a small boat properly, you can then learn to sail a big boat, but if you learn to sail a big boat first, you'll never really learn to sail a small boat properly. I think the analogy holds here.

Why can't you learn to sail a small boat properly after learning to sail a big boat? I don't see how the example works in the first place.

what the grandfather is trying to say by my own understand is learning to sail small boat when big boat sinks small boat sailing skill is the only thing that will save your hide.the old man is wise

Re: Lessons learned from implementing a text editor related to front-end development

#127

Post by dreta »

whowouldathunk wrote: post #112
dreta wrote: post #57

It's worrying how sometimes the most basic programming concepts can appear revolutionary to web developers. So much so, they've recently stumbled across the concept of a read input-update-render loop, and are now trying, with frameworks like React, to contort the DOM tree, just to get back to how UI was programmed since decades. There's a fairly old concept called "immediate mode UI", which even gets rid of the tree…

Battery life would take a dive if everyone adopted immediate mode UI for apps. The compromise is something like Win32, where the OS tells you which rectangles in your app to repaint so most of the time you're not doing anything. Both of which are a ton of code if all you want to do is display a list of TODO's with custom styling vs. in markup.

The rate at which you have to update, and what you have to update doesn't change between retained and immediate mode. The only difference is that, with retained mode, the library you're using has, by design, all the knowledge it needs, so it can manage all of that for you. The whole point of using immediate mode is to get rid of this black box from your program, so that you can explicitly state what you want to happen, when, and in what order. It's only "a ton of code" if you write everything from scratch, so i fail to see how that's an argument.

Re: Lessons learned from implementing a text editor related to front-end development

#128

Post by eplanit »

YSFEJ4SWJUVU6 wrote: post #82

A cursory look into the linked github pull request changes made me spot this, and I must admit that never in a million years would I've thought to erase the possible endline character of a string returned by getline with this: line[strcspn(line, "\n")] = 0; I don't think I'm going to start, either, even if it is a nifty oneliner. Anyway, I've always found this kind of little projects a good sport.

Wise choice.

Re: Lessons learned from implementing a text editor related to front-end development

#129

Post by Silhouette »

olddevanon wrote: post #122
robotresearcher wrote: post #118

Earlier quoted context omitted.

Most students have close to zero programming training of any kind before getting to university in Canada.

Maybe this is where regional differences come out as most students in the UK have had some programming lessons before starting uni (albeit they often haven't done any recreational programming). That was my observations at the time anyway. Things may have changed and/or I might have introduced selection bias by hanging around with the nerdier kids. Who knows - too late to find out now.

Maybe this is where regional differences come out as most students in the UK have had some programming lessons before starting uni

At the level of professional-standard software architecture for UIs?

There have been some positive efforts in the UK over the past few years to introduce programming as a more serious subject at secondary school level (roughly, ages 11-18). I think it's great if kids get to write a simple mobile app to chat with their friends or make a simple game, instead of only learning things like how to use a word processor or graphics program. I think it's great if there are teachers in schools who themselves have the skills and knowledge to help the kids do that, too.

However, there are plenty of new starters entering the industry who have just graduated with degrees in CS or related subjects from good universities and still won't have been exposed to these kinds of ideas at more than a trivial level. I'd be surprised and impressed if I had a school-leaver turn up for an interview for a programming position with more than a passing knowledge of these subjects.

For what it's worth, I don't think the original author does themselves any favours by inflating their experience as they do. The way they describe themselves in the introduction on their web site seems rather out of proportion to their actual experience, and their CV screams "I read a guide to how to write impressive-sounding CVs and I'm trying way too hard". But as a card-carrying member of the "I thought I knew everything at the start of my career and tried way too hard" club, I think you just have to see that as a combination of genuine enthusiasm and understandable immaturity, and give them credit for having a go and sharing their experience. I'm happy to see someone at that stage in their development taking an interest and spending the time to experiment and discuss and learn, and surely we should all be encouraging the next generation of programmers along that path?

Re: Lessons learned from implementing a text editor related to front-end development

#130

Post by mmjaa »

jasode wrote: post #105
jnbiche wrote: post #88

Earlier quoted context omitted.

I do understand the semantic disagreement we're having here, but most of all I'm upset ( really upset this morning) about the tone he/she and others here have toward someone who is exploring new CS ideas and techniques and learning things, for God's sake. And also, taking the time to write up what they learn, which is a step farther than I get on most weeks. It just makes me sad to think that "Hacker News" is so down…

>I'm upset (really upset this morning) about the tone he/she and others here have toward someone who is exploring new CS idea [...] It just makes me sad to think that "Hacker News" is so down on someone who seems to be the prototypical curious hacker I totally understand your frustration. This 17 or 18-year-old[1] didn't meet mmjaa's standards[2] to write about programming and apparently, many HN'ers feel the same wa…

> exploring new CS ideas and techniques

The point is, this isn't a "new CS idea and technique" - in fact, this technique is as old as computer UI's themselves.

I have no idea how old this developer is, my only issue is that there is a re-invention of terminology and a whole new ontology being defined here, for something that has been a stock-standard CompSci concept for decades.

Its one thing to call me out as a grumpy old fart "not on my lawn"-ist - but its another thing to call out people who constantly re-invent the wheel and give it a new coat of paint, too. That is really my only motivation: to indicate that there is very little to be gained, productively, from ignoring the lessons of the past, "re-discovering" something, then slapping a new label on it. This doesn't do our industry any good - yet the practice is rampant. It seems, ever generation of CompSci graduates or so, someone gets the idea to invent something cool, which they've never heard of before, and proclaim that it is a unique insight into the field - whereas the fact is, its just a new coat of paint over an empty hole where the understanding should be.

We go through this psychosis every 4 or 5 years or so, in the computer world - so many times, we've re-invented the wheel and given it a new lick o' paint, calling it cool. I would, personally, like to see a bit more care given to this aspect of things by newcomers to this field - and rest assured, you can sit on my lawn as long as you cut it first.

Post reply on HN