Live data from Hacker News

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

lpan.io

31–40 of 191 posts

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

#31
I'd like to post a purely positive, encouraging comment here :-)

Thanks for the article, and good job implementing an entire editor from scratch in C! That's impressive.

Also, as a very accomplished programmer who happens not to have done much recent UI programming, who has read quite a bit about React/Redux/Rewhatever, Elm, The Haskell School of Expression, etc., I find articles like this extremely helpful: you took a simple example, and clearly and straightforwardly demonstrated the underlying goals and principles of "Unidirectional UI". While I mostly "get it" already from reading articles on React-based architectures, clear reiterations of the idea are a huge aid in getting the concepts solid.

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

#32

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

> This is one of the reasons why programming with Monads is so powerful: the programmer can explicitly compose and control effects.

Yes, it's true, but lest anyone come away confused by this statement, monads are about much more than effects. I understand that's not what you're saying here, but my first months of dabbling in Haskell were marked by a deep misunderstanding that monads were used for side effects, and nothing more.

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

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

All this screams to me "education". The self taught diy thing is great, but on mass scale it's inefficient. If all these devs (I could include myself) could spend 6 months doing all this together sharing the common patterns and then go out fixing other problems ? Also SICP/HtDP

One, who just has a free 6 months? Two, do you honestly think you can fit a comprehensive CS education that would satisfy people like you in six months?

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

#35
post #9
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…

> since everyone knows that C is a greybeard language and, therefore, not cool.

As a person who works as a front-end developer but after hours writes almost exclusively in Rust I think I could shed some light on what's going on here:

Since JS is so accessible a lot of the folks who work with it don't even have a formal education in Computer Science(like the author, who's a CS student), so many of them never touched a compiled language in their life, not to mention subjects regarding CS.

To these people most of the concepts in C(like manual memory management) are entirely foreign. It's not that they don't _like_ C, it's that they're utterly unaware of the mindset one has to have to write things in it.

EDIT: grammar.

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

#36
Once you move to making mobile or desktop front end you appreciate how easy front end web dev really is.

Contrary to popular opinion I think the DOM, HTML, and CSS, are an awesome way of defining and styling a scene graph. When I did some C++ front end I missed them every day.

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

#37
post #27

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…

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 into the CTO/CEO office at the time asking how much they valued experienced C/C++ developers. They honestly said at the time that (frank) who had 10+ years doing game dev they couldn't see any point in paying him anymore than 60K a year. I thanked them for their time and went back to my desk.

Next day I walked in and handed in my resignation. Both the CEO/CTO was shocked. The next week I walked into a web development shop (oracle/java/javascript) and tripped my salary.

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

#38

Earlier quoted context omitted.

All this screams to me "education". The self taught diy thing is great, but on mass scale it's inefficient. If all these devs (I could include myself) could spend 6 months doing all this together sharing the common patterns and then go out fixing other problems ? Also SICP/HtDP

One, who just has a free 6 months? Two, do you honestly think you can fit a comprehensive CS education that would satisfy people like you in six months?

Good points but what these people learn in segments in random order would probably fit into 6 months. I don't even believe CS education fits in 5 years anyway. I was just trying to suggest how to avoid diy lib chaos.

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

#39

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

I made one of those in C, using skip lists instead of trees so it wouldn't need rebalancing:

https://github.com/josephg/librope

It could happily do 5M random single character edits / second on my old laptop. Its wild what you can pull off with C. Much more memory efficient too (it uses about 4 pointers of overhead per 180 characters).

I'd love to see a version which supported traversal using more methods though - that library needs to support searching by line as well as character count.

I tried porting it to Rust a few times but unfortunately couldn't figure out how to port it without introducing indirection everywhere. Modern 'C replacement' languages don't let you do the same funky memory management tricks. (Like using a dynamically sized array at the end of a struct allocated in the same block.)

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

#40
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'm not trying to be overly critical, but for a lot of us, "discovering that C-based apps are, weirdly, similar to what us React-ites are doing" sure seems like a step backwards from real stack competency.

This is something that I try to impart on all new hires. Collective we have been making great strides in this industry lately, and in my experience, the more inexperience devs tend to get blinded by all of the shiny. This isn't inherently bad; a lot of CS breakthroughs are tough to learn without the appropriate domain knowledge. But practical stuff that most devs use ins't anything fancy. It's the same concepts from years ago with config files attached to it.

We don't stress learning algorithms so that you can write a perfect quicksort implementation from memory. We want you to know the fundamentals so that tomorrows new technology becomes trivial to learn.

Post reply on HN