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

81–90 of 191 posts

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

#81

Post by clarry »

baybal2 wrote: post #27
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 discip…

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

This is a big problem. I love C. I'd love to have a C job. I don't even mind the salary as much.. but practically nobody is looking for C devs, and the few that are, seem to require incredible credentials.

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

#82

Post by YSFEJ4SWJUVU6 »

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.

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

#83

Post by jnbiche »

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…

Awesome project, you're inspiring me to pick back up a text editor project I had started to learn Rust a while back. Yours is much more featureful, however!

By the way, if anyone else is thinking about doing the same, HN had a great discussion on an article (also very useful) on the various data structures one can use for text editors: https://news.ycombinator.com/item?id=11244103

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

#84

Post by jasode »

jnbiche wrote: post #79
mmjaa wrote: post #67

Earlier quoted context omitted.

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

>just about anything physical could be modeled as a state machine. [...] Are you seriously suggesting we abandon terms like "unidirectional UI flow" and just describe those architectures as state machines?

Fyi ... a meta observation about this type of discussion: https://en.wikipedia.org/wiki/Lumpers_and_splitters

It's an invisible underlying theme of many programming debates and the participants often don't realize it's happening.

(Personally, I like "splitting" for communication of nuance to others but I also like "lumping" to understand that many things are variations of an underlying principle. E.g. a "file system" is a "database" which is lumping but if I want to communicate to others, splitting is better and I'll call it the "Mac HFS file system" instead of "Mac database" which would just confuse the hell out of everyone.)

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

#86

Post by arximboldi »

jnbiche wrote: post #83
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…

Awesome project, you're inspiring me to pick back up a text editor project I had started to learn Rust a while back. Yours is much more featureful, however! By the way, if anyone else is thinking about doing the same, HN had a great discussion on an article (also very useful) on the various data structures one can use for text editors: https://news.ycombinator.com/item?id=11244103

Thanks for the link and the encouragement! You have your Rust project somewhere online? I'd love to take a look at it.

I sometimes fantasize about rewriting Ewig in Rust, as a learning project (have been reading about it but didn't dare to write code in it yet). But I'd like to use RRB-Vector there too. Sadly, this data-structure is not really trivial to implement... (the concat algorithm in particular). Maybe one day I'll find the time :-)

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

#87

Post by vostok »

tcfunk wrote: post #73
mmjaa wrote: post #9

Earlier quoted context omitted.

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.

I think they're more willing to take new people mostly because there are more jobs and not enough programmers in Web.

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

#88

Post by jnbiche »

jasode wrote: post #84
jnbiche wrote: post #79

Earlier quoted context omitted.

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…

>just about anything physical could be modeled as a state machine. [...] Are you seriously suggesting we abandon terms like "unidirectional UI flow" and just describe those architectures as state machines? Fyi ... a meta observation about this type of discussion: https://en.wikipedia.org/wiki/Lumpers_and_splitters It's an invisible underlying theme of many programming debates and the participants often don't realize…

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 on someone who seems to be the prototypical curious hacker who is just starting out his programming career.

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

#89

Post by alacombe »

baybal2 wrote: post #27
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 discip…

irrelevant, we are looking for +100k C++ devs and can't find them.

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

#90

Post by icebraining »

raverbashing wrote: post #66
icebraining wrote: post #54

Earlier quoted context omitted.

Why would a system do that? Either it overcommits, in which case the malloc won't fail (programs get killed only when they try to actually use the memory) or it doesn't, in which case there's no reason to kill it.

https://www.memset.com/docs/additional-information/oom-kille...

Yes, I know about the OOM killer, but it doesn't trigger when you malloc(), only when you actually try to use the memory. In fact, that's the point of the OOM killer: since many applications allocate more memory than they actually need, Linux lets them allocate more memory than what is in fact available, and only kills 'em off when the bluff fails.
Post reply on HN