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

61–70 of 191 posts

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

#61

Post by megous »

rvense wrote: post #24
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

It can still fail. Also it is not very bright to depend on some kernel configuration in order not to crash unpredictably. Also it's not portable. Some targets don't have MMU.

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

#62

Post by fnl »

mcjiggerlog wrote: post #56
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?

Unfortunately HN can be unnecessarily negative sometimes. Thanks for the interesting article!

Sorry, don't get me wrong - I'm not the author; I just wanted to know why HN had voted this article to #1, and then was even more confused by the tone in the comments. Hopefully, the productive comments will end up on top, eventually!

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

#63

Post by hackits »

sbov wrote: post #45
hackits wrote: post #37

Earlier quoted context omitted.

You can use my own experience as a little bit of anecdotal evidence. I started out of collegue and started programming in C/C++ as a game dev. I started at 40K AUD in Sydney in 2002 just before the housing boom here in Australia. Granted stayed with the business for 4 years. During the time my colleges got a job in web development CRUD application systems for the web. Their starting salary was 85K. I remember walking…

Game dev is built on the backs of people sacrificing salary for "working in games". You really can't compare it to any other job. All my friends who worked with C/C++ in game dev that moved out of game dev, but still used C/C++, at least doubled their salary.

A job is a job. For me the simple truth of the matter is I couldn't support the quality of life I wanted to live working in games and the salary and rewards they where offering. It was fun, but going back to C/C++ is something I would avoid at all costs, although if the salary doubled over night I would put up with C++ although I think I would take up drinking.

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

#64

Post by megous »

bradfa wrote: post #58
rvense wrote: post #24

Earlier quoted context omitted.

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

Do other *nix systems behave differently regarding overcommit of memory and malloc() really only erroring out when virtual memory is exhausted (which basically never happens)?

It can happen, I had various issues with my VPS provider which set limits on virtual memory use in his virtualization solution. Programs would crash with malloc failures despite overcommit being enabled.

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

#65

Post by megous »

raverbashing wrote: post #41
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.

The reason for not checking malloc is that it's most likely to kill your program instead of returning a failed allocation

The program will crash on null pointer dereference most likely. Malloc will not abort. Some libraries (like glib2) wrap malloc so that it aborts on failure, but standard malloc will never crash.

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

#66

Post by raverbashing »

icebraining wrote: post #54
raverbashing wrote: post #41

Earlier quoted context omitted.

The reason for not checking malloc is that it's most likely to kill your program instead of returning a failed allocation

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

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

#67

Post by mmjaa »

jnbiche wrote: post #18
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 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.

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

#68

Post by donkeyd »

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 consider myself a self-taught professional developer, since it's become the job that pays my bills, but I've never had any formal education on the subject. I regularly find out things like this, because I haven't been educated on the subject and because I don't have infinite spare time to study programming patterns. I know they exist and when I feel the need to, I look them up, but otherwise, yeah; "npm -i " all the time.

I don't feel bad about this at all, since my colleagues describe me as a competent developer and my employer can't find enough people for all the work we have to do. If we only wanted to hire developers who understand C, we'd have a really big issue.

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

#69

Post by fnl »

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

LOL! :-)

As I said elsewhere, I think this is clearly an article for a junior audience. But I think he did an good enough job at explaining his main concepts to his peers/readers. In fact, the whole "I coded an editor in C" is at best a irrelevant eye-catcher, as you can copy-paste about a gazillion implementations from anywhere. So because of that, any seasoned dev should probably not fall for such a "catchy" header in the first place... :-)

http://viewsourcecode.org/snaptoken/kilo/ http://www.cprogramming.com/texteditors.html http://jwu.50webs.com/Archive/src/simted3/simted3.pdf ... [ad nauseam]

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

#70

Post by jasode »

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

>I'd expect anyone working as a developer in IT to have learned this much before calling themselves a professional.

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

If majority of HN readers feel this article was beneath their skill level and a waste of time, that's more on the submitter (mxstbr) for misjudging its value to the HN audience rather than the article's author.

(Although at this time, the article does have 110 upvotes while simultaneously, the top-voted comment (poster mmjaa) is critical about its simplistic banality. So maybe the submitter got the pulse correct for half of the HN split-personality?)

[1] http://lpan.io/

Post reply on HN