If you plan on allowing future employers to look at your Github profile, you might want to change the way you write your commit messages.
> REFACTOR: :hocho: future queue (I was retarded)
Not exactly an appealing commit message.
Lessons learned from implementing a text editor related to front-end development
141–150 of 191 posts
Re: Lessons learned from implementing a text editor related to front-end development
#142Earlier 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.
Yes, if you were concerned about battery life, you'd typically not update until input or app state changes.
As for building up to your own retained mode system: not really, at least not in my view. Whether you update at a constant rate, or update only in response to user input (or whatever), you're still doing the key things that differentiate immediate mode-type GUIs from retained mode-type GUIs: firstly, you're regenerating the entire UI from scratch each time; and secondly, you're handling the input events while doing the regeneration.
This is what makes immediate mode-type GUIs so easy to use in many cases. You never have to make sure each widget is linked up with whatever it relates to, and you never have to ensure the widget list is kept in sync with the list of things, and so on. You're always building the widget list from the (authoritative) list of things, and processing the related input events at the same time.
Re: Lessons learned from implementing a text editor related to front-end development
#143Earlier quoted context omitted.
>I'm upset (really upset this morning) about the tone he/she and others here have toward someone who is exploring new CS idea [...] It just makes me sad to think that "Hacker News" is so down on someone who seems to be the prototypical curious hacker I totally understand your frustration. This 17 or 18-year-old[1] didn't meet mmjaa's standards[2] to write about programming and apparently, many HN'ers feel the same wa…
> exploring new CS ideas and techniques The point is, this isn't a "new CS idea and technique" - in fact, this technique is as old as computer UI's themselves. I have no idea how old this developer is, my only issue is that there is a re-invention of terminology and a whole new ontology being defined here, for something that has been a stock-standard CompSci concept for decades. Its one thing to call me out as a grum…
What a petty thing to get uptight about.
This is how humanity works. Language is invented and re-invented for personal needs.
This person isn't making anything that matters. They'll familiarizing themselves with a new landscape and set of terms.
The reality is, at least partially, they ARE having a unique insight into the field FOR THEM. That is, again, HOW HUMANS LEARN.
But sure, go on and extrapolate this specific situation into a generalized notion within the industry, based upon your anecdotal experiences. Cause there is a field and there are rigid terms that define what you seem to be talking about. But you're using them all wrong. How dare you.
> It seems, ever generation of CompSci graduates or so, someone gets the idea to invent something cool, which they've never heard of before, and proclaim that it is a unique insight into the field - whereas the fact is, its just a new coat of paint over an empty hole where the understanding should be.
So what?
It sounds like you're less interested in rigor in a general sense, and more interested in everyone talking to your understanding.
Formality only matters in critical applications, IMO. Medical equipment, rockets, bridges, and the software tools we use to design those.
We go through a psychosis like YOURS all the time. "Previous generations thinks the next generation is beholden to THEIR TRADITIONS -- literal or figurative."
Maybe you should stop considering every Medium and blog post where someone is all "All I made this new thing!" so seriously.
Re: Lessons learned from implementing a text editor related to front-end development
#144Earlier quoted context omitted.
>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 (mxstb…
> 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". Fair enough, though I am still surprised he hadn't learned that in formal education already. I was taught about event driven programming before I got to university. The schools I went to weren't particularly good either so it's not like I had…
Are you kidding me? At his age I didn't know what programming was.
Give him a break.
Re: Lessons learned from implementing a text editor related to front-end development
#145> 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…
> unless you have React-like UI diff-ing library, it's gonna be a costly entire screen redraw event for the most simple update.
He's using ncurses, which actually does that - it only redraws the parts of the screen that change. It can require a bit of coxing at times to ensure that things get redrawn properly but I'm pretty sure he's good - I didn't see anything in his code that would force a full redraw every update.
Re: Lessons learned from implementing a text editor related to front-end development
#146Once 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.
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?
Re: Lessons learned from implementing a text editor related to front-end development
#147Earlier quoted context omitted.
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 (mxstb…
A student in the class fo 2021 in software engineering at Waterloo would currently be about to go into their 2A term:
https://uwaterloo.ca/software-engineering/current-undergradu...
(click on course sequence)
The first year of SE is almost purely mathematics and electromagnetism. The first year programming courses are simple and are designed to simply get people up to speed who may have never programmed before (most already have).
The course which focuses on even-driven programming for user interfaces is 'CS 349 User Interfaces' which isn't until the 3A term. This is the course where students are exposed to MVC, observer pattern, avoiding polling etc. Second year term is also where you would get a lot of exposure to state machines.
As a note to the author of this post: Don't take any criticism that appears elsewhere in these comments too harshly. People who comment here often don't take much time to pay attention to the person who actually made their contributions, and as a result their level of expectations are usually the same regardless of whether a piece of work is created by someone who is a tenured professor, or a first year university student. If you continue to write and work on projects like this, you'll turn out great in the long run. You'll also grow thick skin.
Re: Lessons learned from implementing a text editor related to front-end development
#148Earlier 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…
Might be a bit of selection bias too. The people who had a neutral-positive reaction may not feel like they have much to add beyond "thanks" or "nice job", which sometimes feel like platitudes.
Re: Lessons learned from implementing a text editor related to front-end development
#149Earlier quoted context omitted.
1. Most westerners born outside the USA. And in the USA anyone willing to take out a loan. 2. The core requirements for a cs major at a typical university (read: not CMU,MIT,Stanford,Berkeley) and especially at a non flagship is basically 4 or 5 courses, which you can for sure cram into 6 months if that's all you're studying. Personally, I'd rather work with people who learn some part of that on their own (or even no…
> The core requirements for a cs major at a typical university (read: not CMU,MIT,Stanford,Berkeley) and especially at a non flagship is basically 4 or 5 courses, which you can for sure cram into 6 months if that's all you're studying. Huh? That's an incredibly terrible CS curriculum. 4-5 courses is at most 20 credit hours. A typical undergrad degree requires about 120 credit hours of courses before you can graduate.…
Please see my other comments.
I'm talking about the set of courses that are 1) offered by the CS department and that 2) every student must take.
Not even the entire set of cs courses. Just the ones every student must take.
> A typical undergrad degree requires about 120 credit hours of courses before you can graduate*
Obviously you cannot get an entire degree in 6 months. You can't even finish all of the required coursework.
That's why I said "core CS sequence", not "a degree".
Re: Lessons learned from implementing a text editor related to front-end development
#150Very 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
I tried a rust one as well [1], (antirez based). It's a decent amount of fun, would like to try implementing some of the more interesting features/data structures.