Live data from Hacker News

Challenging projects every programmer should try (2019)

austinhenley.com

251–260 of 346 posts

Re: Challenging projects every programmer should try (2019)

#251
post #133
post #83

Earlier quoted context omitted.

This is like telling a student learning an instrument never to practice scales or études because there are other skills necessary for playing in an orchestra. Those other skills are important, but you have to develop your chops at some point, and being a better a programmer will certainly help with basically all those skills you listed anyway.

Nowadays (and increasingly, going forward) it's possible to be a very productive programmer without knowing much low-level stuff. This may seem unfair to those who spent years wrestling assembly and then C pointers but that's just today's reality. It's not possible to be a "productive" musician on a traditional instrument (i.e. excluding iPads) without knowing how to play scales, chords, etc.

Hard disagree. Those “productive” programmers are a nightmare, their code is a barely decipherable jumble of randomly gluing function calls together until they kinda sorta do something that approximates working some of the time. They cause an unfathomable amount of damage, lost productivity due to bugs and data nightmares, lost data, and headaches.

They do make idiot managers happy though, because look at all those features and scrum points they “finished!” That’s why armies of them will always be there in the software ecosystem, blithely and ignorantly a net drain on whatever unlucky company is currently employing them, busily making a mess for more diligent programmers to clean up for the rest of eternity. It’s called “job security.”

Re: Challenging projects every programmer should try (2019)

#252
post #206
post #76

Discussed at the time: Challenging projects every programmer should try - https://news.ycombinator.com/item?id=21790779 - Dec 2019 (297 comments) Also related: More challenging projects every programmer should try - https://news.ycombinator.com/item?id=25489879 - Dec 2020 (223 comments)

The external link for the second story 404's.

https://austinhenley.com/blog/morechallengingprojects.html

Re: Challenging projects every programmer should try (2019)

#253
post #57

A text editor can use an array as data structure. You only need it to be fast during the typing, where you are only changing one line. But for entering new lines, the extra latency needed for rebuilding the array after pressing enter is not noticeable for several million lines. The more challenging part of a text editor is making sure you only render what the user sees.

It is shocking to me how little known the rope data structure [0] and the order statistic tree [1] are. Especially in the context of text editors.

[0]: https://en.wikipedia.org/wiki/Rope_(data_structure) [1]: https://en.wikipedia.org/wiki/Order_statistic_tree

Re: Challenging projects every programmer should try (2019)

#254
post #107

Earlier quoted context omitted.

> Literally all of the listed projects, text editors, compilers, operating systems, and ray tracers, can exercise the exact same activities. In the linked article, these projects are all explicitly described as opportunities to learn about low-level stuff like how to efficiently store editable text. The difference with a web search engine is that nobody today can build such a thing completely from scratch, therefore…

>elitism and ego You know those car guys who will rebuild their engine, just because? Or those retro computer guys that will recap an ancient board rather than buying a modern pc? For you it is a job, for me it is a hobby. I have no interest in making something 'professional' I want to take it apart to understand how it works. Want to understand how a text editor works? Write one. What component of that is ego? It se…

> What component of that is ego?

Your lack of constraints on personal exploration in software is interpreted as hubris by people who came to software seeking high paying regimented recipe-following.

Re: Challenging projects every programmer should try (2019)

#255

Earlier quoted context omitted.

I enjoy reading your discussion and just wanted to add that some people write a big scale software from scratch nowadays - for instance Marginalia for web search and Andreas Kling and team for operating system and web browser

I guess the first step in writing large scale software is to become Swedish!

Long cold winters dimly lit by a flickering CRT.

Re: Challenging projects every programmer should try (2019)

#256
post #107

Earlier quoted context omitted.

> Literally all of the listed projects, text editors, compilers, operating systems, and ray tracers, can exercise the exact same activities. In the linked article, these projects are all explicitly described as opportunities to learn about low-level stuff like how to efficiently store editable text. The difference with a web search engine is that nobody today can build such a thing completely from scratch, therefore…

Please can you define "from scratch"?

I encountered some push back on this in my "code editor from the ground up" post[1]. I think the only reasonable definition of from scratch is:

Does not have domain-specific dependencies.

So a code editor based on ACE or CodeMirror would not be from scratch, obviously, but one that involves writing all of the domain-specific logic would be. Using generic libraries doesn't stop something being from scratch. (In my case Tree-sitter is arguably domain-specific, but an early version did use a hand-coded JavaScript tokeniser in its place.)

[1] https://news.ycombinator.com/item?id=34577246

Re: Challenging projects every programmer should try (2019)

#257

Earlier quoted context omitted.

>Not all hackers are overly obsessed with the most efficient Big O and various low level (sorry pun intended) details. A NAND gate is low level. Big O is just theory that anyone should know if he's worth something as a programmer.

Most of the time, big O is not relevant if you're not writing new algorithm. For the usual CRUD app? Not so much. Heck even for more involved work, you will not touch them because your solution will be called or will call some external tools. The good news is that, while still valuable, you won't have to lose time creating a new broken wheel. The bad news is that this part of CompSci is now mostly fundamental researc…

> Most of the time, big O is not relevant if you're not writing new algorithm

This attitude is precisely why we have computers thousands of times more powerful than we had in the 90s, and yet they perform the same tasks slower.

Re: Challenging projects every programmer should try (2019)

#258
post #142

Earlier quoted context omitted.

Going from O(n) to O(1) on an operation where n is 10 could be a performance downgrade. That doesn't mean it's useless, it just means there's more to it than the big O. Asymptotic complexity is about how things scale up. You should care about it when you're working with things that scale. Doesn't mean it's useless if your data is static, just means you need to understand when to go for the high scaling solution and w…

It can be useful in general, but it is hard to provide the type of tolerances expressed in physical units you’d expect in an engineered solution when all the constants are ignored.

I'm not sure what you mean. Sounds a bit like you might be misunderstanding what were talking about.

Re: Challenging projects every programmer should try (2019)

#259

On the text editor one: > The biggest challenge is figuring out how to store the text document in memory. My first thought was to use an array, but that has horrible performance if the user inserts text anywhere other than the end of the document. I guess this is only an issue in low level languages, as I just used a JavaScript string and I don't think it's been a perf issue in 2+ years using my editor full time. Ple…

[deleted]

Re: Challenging projects every programmer should try (2019)

#260

On the text editor one: > The biggest challenge is figuring out how to store the text document in memory. My first thought was to use an array, but that has horrible performance if the user inserts text anywhere other than the end of the document. I guess this is only an issue in low level languages, as I just used a JavaScript string and I don't think it's been a perf issue in 2+ years using my editor full time. Ple…

It's one of those things that show up at very large file sizes isn't it? Most programmers work with tiny text files 99% of the time.
Post reply on HN