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

71–80 of 191 posts

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

#71

Post by jnbiche »

fnl wrote: post #47
mmjaa wrote: post #2

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

I don't think the article was that bad for "junior-JS-to-JS-dev talk", which I think is clearly the main audience. Yes, I'd agree, for any seasoned dev, an article about the basics of functional programming, state machines, and the basics of unit testing and API design is a tad boring ;-). But that's no reason to get that upset about an article that clearly wasn't written for such an audience. Rather, such a response…

> such a response is not exactly encouraging those "kids" to learn complex programming concepts/languages in the first place, I think, and instead seems a bit offensive, to be honest.

Yes, exactly. I mean, this dev is someone who clearly is working toward a deeper level of understanding of CS concepts, and here some people seem to be criticizing him for that. It's frustrating.

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

#72

Post by clarry »

olddevanon wrote: post #60
fnl wrote: post #53

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

> It feels like frontend development is a place where people go if they like the idea of coding but can't be bothered to learn how to actually programme.

Maybe they go into it because of the incredible demand.

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

#73

Post by tcfunk »

mmjaa wrote: post #9
keyle wrote: post #4

Earlier quoted context omitted.

It's true that today's devs are glorified plumbers. On the other hand, so much gets done, it would be insane to go back to "C for all the things!". It's a trade off, you're either a high level hacker, piping stuff together and watching for leaks, or your a low level system guy, squeezing the carpet.

I would argue that a lot more of the worlds productive plumbing depends on C-based apps/libraries/frameworks than we would care to admit - its just that its 'not sexy' enough for the young-uns to get behind and start using, since everyone knows that C is a greybeard language and, therefore, not cool. The same argument ("so much gets done") was made for Visual Basic back in the day, you know. Oh, how the hoipolloi cri…

In my purely anecdotal experience, learning web-based technology over C/C++ was not a choice I made personally. It was a career path that was foisted upon me by job availability and hiring requirements.

I have yet to see a job posting for a fresh-off-the-boat C developer. It's nearly always 5-10 years industry-related experience required. Web, on the other hand, seems more willing to take on the new guys.

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

#74

Post by nv-vn »

sametmax wrote: post #46
mmjaa wrote: post #2

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

The reverse is true. I meet quite a lot of low to middle level programmers that stick to what they know because it's "the basics", and hence completely lack in experience in: 1 - Writing elegant modern code Working with experienced C / Java coders to write proper Python is a challenge. They tend to use twice to many lines, ending up with slower and less readable code. They don't use the additional productivity to pro…

There's a lot I could address with your comment, but since I'm short on time here, where are you getting servers that they all cost the same amount regardless of specs?

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

#75

Post by sametmax »

nv-vn wrote: post #74
sametmax wrote: post #46

Earlier quoted context omitted.

The reverse is true. I meet quite a lot of low to middle level programmers that stick to what they know because it's "the basics", and hence completely lack in experience in: 1 - Writing elegant modern code Working with experienced C / Java coders to write proper Python is a challenge. They tend to use twice to many lines, ending up with slower and less readable code. They don't use the additional productivity to pro…

There's a lot I could address with your comment, but since I'm short on time here, where are you getting servers that they all cost the same amount regardless of specs?

I don't, I'm just oversimplifying for the sake of the demonstration.

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

#76

Post by clarry »

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.

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

#77

Post by clarry »

jmaygarden wrote: post #3

Storing 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.

> Depending on your architecture, that could use 24 bytes per ASCII character (if the char in the struct is padded with 64-bit pointers).

Quite possibly much more than that because of allocator overhead. Main sources of overhead are rounding (i.e. the allocator might give you a 32-byte slot when you ask for 24 bytes) and bookkeeping (it needs to keep track of all allocations, which tends to require the storage of addresses and bitmaps .. in some kind of a data structure).

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

#78

Post by yaseer »

mmjaa wrote: post #2

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

Is this the state of things today...from the top-down, trickle through the stack learning 'the things'

Yes, the path most people will take today is from high-level languages and high-level abstractions, down to low level abstractions. It's not any better or worse than a bottom-up approach for learning. The fact that people are going down through the stack, trying to learn and understand things as they go is to be celebrated, not to be rued.

A top-down approach for learning makes logical and logistical sense in 2017, given the demand for developers operating on high-level abstractions. The bottom-up approach made sense, circa 1972 when C appeared. Neither approach is 'better', IMO.

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

#79

Post by jnbiche »

mmjaa wrote: post #67
jnbiche wrote: post #18

Earlier quoted context omitted.

> The more I read, the more I felt that the author was long-windedly discovering FSM's Then you missed the main point of the post, which was event flow, not state management. I'm wondering if sometimes older devs (I'm one) read these posts in anticipation, just waiting to find something that they recognize from elsewhere, just so they can say "aha, that's just X, nothing more!". In this case, you did recognize that y…

>Are you suggesting that in this case, unidirectional UI flow is just another name for a FSM? Yup. The UI reads its current-state data, which comes in on an event queue, and renders the display accordingly. This is a state machine.

Well, as someone else said, just about anything physical could be modeled as a state machine. That doesn't mean we use the term state machine to describe just about everything physical.

Are you seriously suggesting we abandon terms like "unidirectional UI flow" and just describe those architectures as state machines? You would be missing the most important part of the term, which is the flow of events. State machine says nothing about that.

I mean, if you're reducing the event flow of a UI to a state machine, why use the term MVC, right? It's just a state machine at heart, right? A lexer? Oh, that's just a state machine, forget about the term lexer. The various Markov models? Oh, just a state machine. etc. etc.

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

#80

Post by srean »

agumonkey wrote: post #16

not C, but probably very C useful http://scienceblogs.com/goodmath/2009/01/26/ropes-twining-to...

Since there is only a passing mention of the gap-buffer datastructure in the post you linked to, I am leaving this here https://en.wikipedia.org/wiki/Gap_buffer

Super easy to implement and gets you a long way. I am a little surprised that it has not come up yet on a thread on editor implementations.

In fact the author of the blog post talks about it in his very next post. Here's his lede

    Last week, I promised to continue my discussion of ropes.
    I’m going to break that promise. But it’s in a good cause.
http://scienceblogs.com/goodmath/2009/02/18/gap-buffers-or-w...
Post reply on HN