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

171–180 of 191 posts

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

#171

Post by dreta »

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.

Immediate mode is simply a way of designing your API so that there's no creation, destruction, callbacks, etc. It's a convenience to the programmer, because they can explicitly express what they want to happen at a given moment, and the application state is known at any given time. It's a general concept that can be applied to any code you write, and it most certainly doesn't forbid you from keeping track of dirty regions between frames, that would be ridiculous.

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

#172

Post by carapace »

DarkTree wrote: post #157
zbtaylor1 wrote: post #140

Earlier quoted context omitted.

> 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

Some of us are just tired of people who don't respect the people and work that came before them.

There was a guy at the second-to-last place I worked who didn't know who Alan Kay was! What's worse, he wasn't ashamed of his ignorance.

At the last place I worked someone was refurbishing an old "expert system" written in CLIPS [1], he asked my advice and I said, "Consider using Prolog." He said, "What's Prolog?"

These are guys getting paid six figures and they do not care to educate themselves on the background of their chosen field. It's lame.

Could you imagine a physicist who didn't know who Newton was?

[1] https://en.wikipedia.org/wiki/CLIPS

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

#173

Post by carapace »

taneq wrote: post #95
yaseer wrote: post #78

Earlier quoted context omitted.

Is this the state of things today...from the top-down, trickle through the stack learning 'the things' Yes, the path most people will take today is from high-level languages and high-level abstractions, down to low level abstractions. It's not any better or worse than a bottom-up approach for learning. The fact that people are going down through the stack, trying to learn and understand things as they go is to be cel…

My grandad used to say if you learn to sail a small boat properly, you can then learn to sail a big boat, but if you learn to sail a big boat first, you'll never really learn to sail a small boat properly. I think the analogy holds here.

Thomson's Rule for First-Time Telescope Makers: "It is faster to make a four-inch mirror then a six-inch mirror than to make a six-inch mirror."

-- Programming Pearls, Communications of the ACM, September 1985

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

#174

Post by WalterBright »

Another C tty oriented text editor is the classic MicroEmacs:

https://github.com/DigitalMars/me

I learned a lot about programming from reading the source code to it. It's a gem of clarity and design (and you could reasonably argue that many of my changes to it messed it up).

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

#175

Post by nv-vn »

sametmax wrote: post #75
nv-vn wrote: post #74

Earlier quoted context omitted.

There's a lot I could address with your comment, but since I'm short on time here, where are you getting servers that they all cost the same amount regardless of specs?

I don't, I'm just oversimplifying for the sake of the demonstration.

I think server operation costs are a very legitimate concern, though. People always say "well, you're not Google so it's not that important," but that's precisely the issue. No small company has the budget to splurge on the biggest and best server infrastructure. A small DigitalOcean/AWS/Heroku plan is probably the most any small business could hope for (dedicated servers = hardware costs out of pocket + maintenance costs + power fees + ISP fees) and any relatively complex server is gonna eat through that quickly. Micro-optimizations may not be worth it, but just switching from an interpreted language to a compiled language can often reduce the performance overhead by an order of magnitude.

The amount of oversimplifying you're doing seems to skip every flaw in your argument in my opinion. That's not to say you're necessarily wrong... a C programmer probably isn't worth it over a Python programmer. But writing code with double nested loops for no reason or ignoring basic algorithms is going to cost you big time in the long run.

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

#178

Post by sametmax »

nv-vn wrote: post #175
sametmax wrote: post #75

Earlier quoted context omitted.

I don't, I'm just oversimplifying for the sake of the demonstration.

I think server operation costs are a very legitimate concern, though. People always say "well, you're not Google so it's not that important," but that's precisely the issue. No small company has the budget to splurge on the biggest and best server infrastructure. A small DigitalOcean/AWS/Heroku plan is probably the most any small business could hope for (dedicated servers = hardware costs out of pocket + maintenance…

I usually have far lower server bills than my colleagues because i don't pick up saas when i don't need too. This is the an optimization that does save money : knowing when to manually setup servers vs going aws/firebase/whatever.

As for the doubled nested loops, as usual, it depends. Data size, boudaries, number of concurrent operations, cpu costs, acceptable loading time...

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

#179

Post by Raphmedia »

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…

What can I say? Learning the language du-jour landed me a high paying job right out of school.

I had a choice at one point : Join the workforce doing web work (and make money right now) vs. spend more time in school and learn more while gaining debts and making no money.

Right now I am debt free, living a good life writing modern JS.

In my free time, I try to learn more low-level CS knowledge. It's however hard to justify the time spent doing this since none of it is of use during my day job.

If University was free and we didn't have to work to eat, I would know everything from the ground up. Sadly, this is not the world we live in.

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

#180

Post by taneq »

yaseer wrote: post #117
taneq wrote: post #95

Earlier quoted context omitted.

My grandad used to say if you learn to sail a small boat properly, you can then learn to sail a big boat, but if you learn to sail a big boat first, you'll never really learn to sail a small boat properly. I think the analogy holds here.

you'll never really learn to sail a small boat properly This analogy lost its sway for me with the word 'never'. It's not impossible, in either case. Perhaps working with a small boat / low-level language is indeed 'harder', so you may be better equipped to deal with the higher-level easier language, after learning the low-level language. Teaching high level languages down to low level languages would be an increase…

I think I somewhat misremembered the quote - it should have been "If you learn to sail a small boat, you can sail a big boat. If you learn to sail a big boat, you can't sail a small boat."

It's not about easier/harder. It's about responsibility and understanding.

Sailing a small boat is a "full stack" activity, from trip planning to navigation to the low level mechanics of jibing and tacking, even the act of physically keeping the boat upright if you're using a centerboard.

Sailing a large boat usually sees you in a specific role, doing a specific niche thing, and you never get an overview of the whole process.

The same applies to working in a large team of any sort, which is why you see software developers who can't write FizzBuzz but who nonetheless do fine in their particular niche.

Post reply on HN