Lessons learned from implementing a text editor related to front-end development • Hacker News Board

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

#151

Post by pjmlp » Mon, Aug 28, 2017, 5:25 PM UTC

nodivbyzero wrote: post #146

pjmlp wrote: post #104

Earlier quoted context omitted.

I bet you didn't use any of VCL, Windows Forms, QML or XAML on your C++ front end.

How about MFC or WTF or WinAPI?

They are good if one likes to write boilerplate with lots of C style coding in a C++ application.

MFC always suffered from not being as high level as OWL or VCL, because the internal devs at Microsoft thought that Afx (the original implementation) was too high level.

By WTF, I think you actually mean WTL, which is based on ATL, full of templates and low level COM style programming. Another one that gives no pleasure using.

WinAPI was already out of fashion on the Win16 bit days, I was already using Turbo/Borland C++ with OWL on those days.

The only reason to use Win16 directly was to wrap APIs not exposed to OWL.

Sadly due to how Borland got themselves mismanaged, OWL lost to MFC in the early 32 bit days, and only enterprise customers with deep pockets adopted C++ Builder with VCL, which allows for VB/Delphi style programming with C++.

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

#152

Post by mivanchev » Mon, Aug 28, 2017, 5:27 PM UTC

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

Very much this! As a person who recently completed a medium-sized C project I can say the author's work is simply IMPRESSIVE on so many levels. It's true that there's no error checking and there's undefined behavior, but please note that the author is rather young and this project is in a usable state. All of these issues can be added/fixed with time as the author learns more about the language and programming in general. The author got good experience and this is what counts here. Clearly, the author is willing to get some practical coding experience next to the theoretical foundations he learns about at the university. I can only support that and sadly I didn't have this mindset while studying CS.

The way I see it, the author had an idea, sat down, put it to practice and implemented a functional prototype which can easily be expanded upon. This is probably how all these arcane *nix tools we use today came into existence. I don't imagine anyone wondering "should I use a rope or something more efficient, let me just spend 2 months trying out different structures" while coding one of the first text editors. Also, what the author did would not be simple to achieve in ANY language, because no language out there has a ProduceVimLikeEditorWithMinimalFeatures() function.

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

#153

Post by mercurial » Mon, Aug 28, 2017, 5:34 PM UTC

disquist wrote: post #123

I am a novice in this area, so forgive me if I am missing something, but I have some questions regarding the two approaches in the article, specifically if there is a performance trade-off being made between them. To my untrained eye, the initial version seems to be doing a minimal set of updates based on the input it receives, whereas the latter version will call the monolithic render procedure no matter how small a…

> I believe that React and similar frameworks run a diffing procedure to find out which parts of the UI actually need to be updated (so a more minimal set of updates is actually applied)

That's true. React diffs the virtual DOM and applies the changes to the actual DOM. However, the fastest is still to diff the actual data to be rendered, and determine whether the render function needs to run at all (this is opt-in via React's shouldComponentUpdate() lifecycle method).

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

#154

Post by njharman » Mon, Aug 28, 2017, 5:42 PM UTC

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

I don't think that is just today (except the blogging aspect). That is how it always has been. Developers learn from experience, learn from doing.

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

#155

Post by throwawayjava » Mon, Aug 28, 2017, 5:47 PM UTC

pjmlp wrote: post #136

throwawayjava wrote: post #133

Earlier quoted context omitted.

> I doubt very much you could cram that much in 6 months. No, you cannot cram an entire degree into six months. Hence the second paragraph under my second point. But the core CS sequence? 4-5 courses is a rough semester, but it is a semester ! And if you already have some mathematics or especially some programming background, the sequencing that causes those courses to stretch into 1.5 years is already resolved.

Well, 4-5 courses was the minimum we had per semester, with enough deliveries to keep us rather busy, starting with 3rd year. Some people managed to jungle a few more courses. I don't see such a program being much more than simple introduction to CS.

Yes, that's exactly my point. You can get a simple introduction to CS in six months, especially if you already know how to program.

No, you're not going to be publishing papers or talking through OS implementation details with CMU grads or designing computer vision systems with Berkeley grads. But you'll have the baseline knowledge that agumonkey is referring to in their comment.

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

#156

Post by simonh » Mon, Aug 28, 2017, 5:48 PM UTC

jdc0589 wrote: post #139

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?

No, its every day syndrome around here for this type of thing, I've seen it frequently. A lot of people on HN are not receptive to someone posting a blog entry about their experiences re-implementing something for learning purposes if it isn't super advanced stuff. I don't really get it, but there are a lot of people who can't read a technical blog post from the perspective of someone with less experience than them t…

>I don't really get it, but there are a lot of people who can't read a technical blog post from the perspective of someone with less experience than them trying to learn new stuff.

I strongly suspect a lot of posters of negative comments really aren't any more capable, but are just showing off by picking holes in other people's work. No advanced project like this gets done perfectly first time. Anyone who's worked on a complex project, especially on their own, would know and appreciate that.

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

#157

Post by DarkTree » Mon, Aug 28, 2017, 5:54 PM UTC

zbtaylor1 wrote: post #140

jnbiche wrote: post #71

Earlier quoted context omitted.

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

> It's frustrating. It really is. This "community" can be very unwelcoming. I'll never understand what motivates people to shit all over content they consider below them. Is it really that hard to pass by without shouting "I'm smarter than you!" at everyone?

> I'll never understand what motivates people to shit all over content they consider below them.

Almost always rooted in the person's own insecurities

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

#158

Post by simonh » Mon, Aug 28, 2017, 5:54 PM UTC

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

From the article.

"viw helped me understand what UI development is really about."

Nobody writes something like that if he is 'soap boxing his experiences as if the topic isn't entry level stuff'.

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

#159

Post by [deleted] » Mon, Aug 28, 2017, 5:59 PM UTC

Nursie wrote: post #93

alacombe wrote: post #21

Earlier quoted context omitted.

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

Is it? On (Debian) linux boxes apt-get install -dev and away you go, there's literally the whole platform ecosystem there for you to use.

[deleted]

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

#160

Post by [deleted] » Mon, Aug 28, 2017, 6:08 PM UTC

whowouldathunk wrote: post #137

dreta wrote: post #127

Earlier quoted context omitted.

The rate at which you have to update, and what you have to update doesn't change between retained and immediate mode. The only difference is that, with retained mode, the library you're using has, by design, all the knowledge it needs, so it can manage all of that for you. The whole point of using immediate mode is to get rid of this black box from your program, so that you can explicitly state what you want to happe…

I'm using "immediate mode" to mean: while (true) { processInput() updateState() paint() } That will kill battery unless you write code to not update until input or app state changes, in which case you're building up to your own retained-mode system.

[deleted]