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

21–30 of 191 posts

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

#21

Post by alacombe »

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…

There is plenty to re-use in C, eg. BSD's queue.h or linux' list.h for linked list alone. Because the author choose not to do so doesn't mean it is the fate of the whole language. Though, it is indeed a little harder than firing "npm".

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

#22

Post by pjmlp »

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…

> Oh, how the hoipolloi cried and crowed for the death of C developers back then. Oh, how they were wrong, oh so wrong!

Which is kind of true for us on Windows.

Most of the C has been replaced by C++, to the point that even the new C runtime library is actually written in C++ with extern "C" entry points.

Also for those of us on Android, where using the NDK is an exercise in patience writing JNI boilerplate, because Google doesn't want us using it more than strictly necessary.

Oh and the two most beloved open source C compilers (gcc and clang) are actually written in C++.

Now I admit that on traditional UNIX systems and embedded development on hardware constrained systems, getting rid of C is an impossible task.

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

#23

Post by jmaygarden »

coldtea wrote: post #14
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.

2MB of characters in Atom use 300MB of memory or more, so it's like 150/1 -- compared to 32/8 that's nothing.

OK, but Atom isn't pitched as a "lightweight vi." If I want to ssh into an embedded device and view a 2MB log file, then I sure wouldn't want that to require 300MB of RAM.

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

#24

Post by rvense »

alacombe wrote: post #19

It is not surprising that C gets that much of a bad reputation when devoloper show such poor capacity at managing errors; malloc(3) return values are never checked and everything is expected to always succeed, throughout the source tree.

On a modern Linux kernel in its default configuration this is AFAIK actually the case? The kernel overcommits memory.

http://www.win.tue.nl/~aeb/linux/lk/lk-9.html#ss9.6

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

#25

Post by pjmlp »

alacombe wrote: post #19

It is not surprising that C gets that much of a bad reputation when devoloper show such poor capacity at managing errors; malloc(3) return values are never checked and everything is expected to always succeed, throughout the source tree.

There are languages that don't allow the programmers to do such kind of failures.

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

#26

Post by innocenat »

> 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 is that unless you have React-like UI diff-ing library, it's gonna be a costly entire screen redraw event for the most simple update.

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

#27

Post by baybal2 »

alacombe wrote: post #19

It is not surprising that C gets that much of a bad reputation when devoloper show such poor capacity at managing errors; malloc(3) return values are never checked and everything is expected to always succeed, throughout the source tree.

Competent C devs are rare these days. Just too many did retire. At the very start of my professional career I thought of becoming embedded dev, but I was disheartened by the job market.

The very few jobs I found were like "Senior C dev, minimum 7 years subject matter experience, $65k" at the time when web dev roles were paying 85k+ and were so easy and dumb...

What distinguishes a good C developer? A high self discipline. That language gives you a lot of ways to introduce bugs, but unlike JS you do have clear realisation why they appear most of the time.

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

#29

Post by skywal_l »

What is the difference between Event Sourcing and the Command Pattern here? For decades the Undo/Redo functionality has been implemented by the Command Pattern it seems. And looking at what Event Sourcing is, it looks a lot like the Command Pattern which purpose is to encapsulate into an object a side-effect performed on some data structure. That object can then be executed at a later time, reverted, logged, etc...

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

#30

Post by mstade »

agentultra wrote: post #17

> 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(
Post reply on HN