All i can say is "watch this kid!". He is showing the motivation, perspectives, insight and intelligence to be able to do important work in the future. Great article and the C code worth reading to learn from. Thanks for sharing and looking forward to reading future blogs and seeing what you create.
Lessons learned from implementing a text editor related to front-end development
181–190 of 191 posts
Re: Lessons learned from implementing a text editor related to front-end development
#182Earlier quoted context omitted.
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 - tha…
Implementing efficient datastructures in Rust often requires `unsafe` code. Unlike in C, though, you can use Traits (which provide both static and dynamic dispatch, depending on usage) to provide a safe, zero-cost interface.
Even using unsafe I couldn't figure out how to pull it off in rust without doubling my heap allocations.
Each item in the skip list has an associated randomly sized list of next pointers. In C I store that list at the end of the node data structure, and dynamically allocate the struct based on how much memory I need (basically, size of static array of characters + size of dynamic nexts array). In Rust in theory I can make my struct unsized to do the same thing. (Well, it pushes the nexts height out into the pointer but that's not too bad). But there doesn't seem to be any syntax to initialise the values in my unsized struct array itself once I've allocated it - even in unsafe.
If you can figure out simply how to initialize a custom heap-allocated unsized struct I'll happily keep working on it. My conclusion at the time (and, still, after trying out tokio) is that rust isn't mature enough to replace C yet.
Re: Lessons learned from implementing a text editor related to front-end development
#183Earlier quoted context omitted.
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.
You still might accidentally invent the command pattern on your own.
Re: Lessons learned from implementing a text editor related to front-end development
#184Earlier quoted context omitted.
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…
irrelevant, we are looking for +100k C++ devs and can't find them.
Interesting may I ask location and positions you're looking at filling?
Re: Lessons learned from implementing a text editor related to front-end development
#185Earlier quoted context omitted.
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 reg…
>not update until input or app state changes
That's the hard part that callbacks try to make easier.
Re: Lessons learned from implementing a text editor related to front-end development
#186Earlier quoted context omitted.
> I'm talking about the set of courses that are 1) offered by the CS department and that 2) every student must take. As I said, that was a dozen courses at my school.
12 CS courses, offered by the CS dept , and that everyone takes means that either A) your department was internalizing a LOT of service courses; B) left very little room for differentiation within your major; or C) provided very little time for exploration outside of your major. Either way, that level of straight-jacketing and/or in-sourcing is atypical. Even at top schools that number is usually below 10. E.g. CMU 6…
> is atypical
I don't think it's very atypical, for example take a look at this course requirement for City College of New York under CUNY :
https://www.ccny.cuny.edu/sites/default/files/csc-prereqs-04...
Under the CS parts, only the elective in category A, B, and C is where student can pick and choose. Everything else under the grey curve across the pdf are:
> courses offered by the CS dept, AND that everyone takes.
Re: Lessons learned from implementing a text editor related to front-end development
#187It 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.
Wasn't in the case on Linux due to overcommit that allocations always succeed anyway? So a novice C developer, working on 64-bit Linux may assume that malloc calls never have to be checked.
Re: Lessons learned from implementing a text editor related to front-end development
#188It'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.
Well, that is the approach of the new Fitbit smartwatch.
It makes use of only SVG, CSS and JavaScript.
Re: Lessons learned from implementing a text editor related to front-end development
#189It'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.
I'm currently working on an web ide that use the Canvas instead of the DOM. The Canvas is very nice to work with, it's high level and hardware accelerated.
Re: Lessons learned from implementing a text editor related to front-end development
#190Earlier quoted context omitted.
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.
Well, that is the approach of the new Fitbit smartwatch. It makes use of only SVG, CSS and JavaScript.
The Canvas is much more fun and easier to work with then SVG though.