Live data from Hacker News

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

lpan.io

111–120 of 191 posts

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

#111

Is the (pseudo?) code there for state mutation representative of a widely used pattern? It looks like using a pattern from a functional programming book, but applied to mutable data. What I mean is this snippet: function handleAddTodo(state) { if (!newTodoField) { state.error = 'Empty field!' } state.todos.push(state.newTodoField) state.newTodoField = nil return state; } This looks like a function newState = fun(oldS…

Vuex works like this: you actually mutate the state instead of creating a new one as it's expected with Redux. But this mutation takes place is a single, controlled place (in the store mutation functions), so you get the benefit of centralising the state management code and avoid the cumbersome immutable transformations patterns which Redux requires.

That said, after having worked with Vuex, I much prefer the immutable newState = f(oldState) pattern used with Redux.

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

#112
post #57

It's worrying how sometimes the most basic programming concepts can appear revolutionary to web developers. So much so, they've recently stumbled across the concept of a read input-update-render loop, and are now trying, with frameworks like React, to contort the DOM tree, just to get back to how UI was programmed since decades. There's a fairly old concept called "immediate mode UI", which even gets rid of the tree…

Battery life would take a dive if everyone adopted immediate mode UI for apps.

The compromise is something like Win32, where the OS tells you which rectangles in your app to repaint so most of the time you're not doing anything.

Both of which are a ton of code if all you want to do is display a list of TODO's with custom styling vs. in markup.

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

#113

Is the (pseudo?) code there for state mutation representative of a widely used pattern? It looks like using a pattern from a functional programming book, but applied to mutable data. What I mean is this snippet: function handleAddTodo(state) { if (!newTodoField) { state.error = 'Empty field!' } state.todos.push(state.newTodoField) state.newTodoField = nil return state; } This looks like a function newState = fun(oldS…

That's an unfortunate example. What you described as `newState = func(oldState)` is (conceptually) how practically all of this generation's state management libraries are modelled.

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

#114
post #57

It's worrying how sometimes the most basic programming concepts can appear revolutionary to web developers. So much so, they've recently stumbled across the concept of a read input-update-render loop, and are now trying, with frameworks like React, to contort the DOM tree, just to get back to how UI was programmed since decades. There's a fairly old concept called "immediate mode UI", which even gets rid of the tree…

I don't know how many times my colleagues and I have half-jokingly suggested just throwing out most HTML and CSS and just draw everything to a canvas.

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

#115

Earlier quoted context omitted.

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?

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

I went to a school that is very far away from CMU, MIT, Stanford, Berkeley, etc and my core requirements were A LOT more than 4 or 5 courses. I'd have to check by I can name at least 8 core requirements off the top of my head.

> which you can for sure cram into 6 months if that's all you're studying

So your suggestion is for people to look at a CS syllabus and find a way to teach themselves all of the core courses?

I have my bachelors in CS. I never really programmed until college. 6 months into my BS I had barely wet my feet with Scheme, learned a little bit of discrete math, and had a VERY basic introduction to formal logic. I knew exactly one programming language.

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

#116
post #95
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.

Why can't you learn to sail a small boat properly after learning to sail a big boat? I don't see how the example works in the first place.

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

#117
post #95
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.

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 in difficulty, and thus that becomes one logical path for learning. I'm not saying this path satisfies all learning use-cases, merely perhaps the majority in 2017.

I'm not familiar enough with sailing to say whether the same principle transfers to boats...

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

#118
post #70

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

Most students have close to zero programming training of any kind before getting to university in Canada.

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

#119
post #110

Earlier quoted context omitted.

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

Assumption is...

I actually wasn't making an assumption, I was talking from my own experiences. Myself and my friends did learn about event-driven programming prior to university.

We were taught both Visual Basic and Pascal and taught the difference between event driven (VB) and procedural (Pascal). Though weirdly we were never taught about OOP, but it was a fairly average UK college and a pretty general computing course so there was a lot to cover in 2 years.

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

#120

Earlier quoted context omitted.

The reverse is true. I meet quite a lot of low to middle level programmers that stick to what they know because it's "the basics", and hence completely lack in experience in: 1 - Writing elegant modern code Working with experienced C / Java coders to write proper Python is a challenge. They tend to use twice to many lines, ending up with slower and less readable code. They don't use the additional productivity to pro…

1) You're talking about familiarity with the language and the ecosystem. Take a Python dev and put them into C, and you'll get a buggy, illegible mess. Give your C developer a few years to grok Python, and they'll be as elegant as anyone who cut their teeth on Python (if not more so, for having experience in more than just Python). 2) Funny, there's a near-constant stream of articles on how companies who succeed have…

All the points you raised actually prove mine. You have a mind set on details that are important to your missions, but in many ones those are waste of time and resources. There is a reasons both profiles exist: they all serve different yet useful purposes.
Post reply on HN