Live data from Hacker News

Challenging projects every programmer should try (2019)

austinhenley.com

331–340 of 346 posts

Re: Challenging projects every programmer should try (2019)

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

If you want to build a compiler from scratch, you must first invent the universe. Peeling back abstractions to see how things could or should work is perfectly fine, even for professionals. Case in point, I've spent a year excising bloated frameworks from my stack at work and replacing the few corners we needed from those frameworks with, e.g. 50 lines of curl calls. The C compiles instantly and is tailored for our t…

My experience as well. The more dependencies I remove, the fewer problems I have. It is a massive productivity boost.

Having said that, there are libraries there are high value/cost. So I keep those. But the dirty reality is that most libraries are pretty bad.

Re: Challenging projects every programmer should try (2019)

#332
post #130

Earlier quoted context omitted.

> If you are only using ready-made building blocks, there is a lot of great software you just cannot write. And I think we all see that, because there isn't much great software around. I claim that the opposite is true: The reason there are so few software projects that are really great is because high-level skills, not low-level ones, are in short supply. Every CS graduate can implement Paxos. The number of people w…

I guess it all depends on your definition of low-level. High-level can also be low-level, just with different building blocks, if the building blocks are based on well-specified abstractions. I am actually currently writing a novel text editor, and I can guarantee you, my requirements mean that an AI cannot help me with that directly, because the underlying mechanisms I need don't exist yet. The AI is still helpful t…

No AI needed. I use a custom code generator to generate 80% to 90% of the code I need in CRUD applications. And I can actually trust the code unlike code written by an AI.

Re: Challenging projects every programmer should try (2019)

#333

Earlier quoted context omitted.

This is also the reason a computer with 4GB of RAM can't run Gmail and Spotify at the same time.

Google and Spotify are supposed to get among the best / most productive developers though

According to what evidence? I have worked with developers who later ended up working for Google and they were OK but not great. They didn’t stand out in any way.

Re: Challenging projects every programmer should try (2019)

#334
post #230
post #24

While writing a text editor, a compiler, an operating system, or a raytracer might make you a better programmer, it won't make you a better software engineer. In fact, it might make you worse at software engineering, because it embodies the disastrous "Not Invented Here" doctrine. Hackers like to obsess about Big-O, data structures, HoTT, and other high-theory stuff, yet the following skills, essential for software e…

> Identifying high-quality libraries and frameworks that meet your project needs This is a really important skill that I find difficult and frustrating. Does anyone have good advice or resources?

It’s simple really: write libraries and frameworks yourself and use them for real projects. It will give you a great understanding of what makes a quality library/framework and make you a better programmer.

Re: Challenging projects every programmer should try (2019)

#335

Earlier quoted context omitted.

I guess it all depends on your definition of low-level. High-level can also be low-level, just with different building blocks, if the building blocks are based on well-specified abstractions. I am actually currently writing a novel text editor, and I can guarantee you, my requirements mean that an AI cannot help me with that directly, because the underlying mechanisms I need don't exist yet. The AI is still helpful t…

No AI needed. I use a custom code generator to generate 80% to 90% of the code I need in CRUD applications. And I can actually trust the code unlike code written by an AI.

Yes, indeed, that's what I would expect as well if I was in the business of CRUD applications.

Re: Challenging projects every programmer should try (2019)

#336

Earlier quoted context omitted.

Yet you have time to browse hn. That reminds me, I’ve got a side project that needs attention.

Browsing hn is a little bit easier than writing an OS.

This is exactly my point.

Re: Challenging projects every programmer should try (2019)

#337
post #62

Earlier quoted context omitted.

And the most challenging part is making a text editor that actually works well from a usability perspective. Which has almost nothing to do with data structures and optimization. I've used dozens of text editors. I have never once thought "man, that thing is slow". But I have thought "man, that thing is a bug-ridden, unintuitive piece of garbage" many, many times.

> I have never once thought "man, that thing is slow". You’re either lying or incapable to detect typing latency. Try typing while CLion indexes stuff in background or open couple hundred thousand line file in VS Code with Vim plugin and let me know how it goes.

That will not be because of an array data structure for the lines.

When properly done, plugins/extensions are in separate process which do not hang the main UI thread. It helps if these processes has a low priority. Also, ionice is good when processing many documents.

Another flaw of many extensions/language servers have, is the lack of abort controller implementation. This means that debouncing doesn't work. So if there are many document updates, the server would hang.

Re: Challenging projects every programmer should try (2019)

#338

Earlier quoted context omitted.

Simple methods of search like exact matching are very fast using textbook algorithms. There are well known algorithm like suffix tree which could search in millions of documents in milliseconds.

That's not enough. It needs to be sharded and handle things like 10 search terms, each of which match a million documents and you're trying to find the intersection. Across shared results from 20 servers. Quickly. That's not a textbook algorithm.

Yeah, it is textbook. It was textbook a decade and a half ago already.

Add docids to sorted update lists. Zipper merge and arithmetic coding once lists get large, is the textbook baseline from back then.

Tack on a skip list, and you have fast intersections.

This is well trodden ground.

Re: Challenging projects every programmer should try (2019)

#339
post #230

Earlier quoted context omitted.

> Identifying high-quality libraries and frameworks that meet your project needs This is a really important skill that I find difficult and frustrating. Does anyone have good advice or resources?

It’s simple really: write libraries and frameworks yourself and use them for real projects. It will give you a great understanding of what makes a quality library/framework and make you a better programmer.

Are you perchance working in academia? Your suggestion seems to assume unlimited time and resources to write everything yourself, while the purpose of using third-party components usually is to save time and resources.

Re: Challenging projects every programmer should try (2019)

#340

Earlier quoted context omitted.

20,000 fewer lines of code, faster compile / deploy times, significantly less interfacing / translation between "their" types and "their" apis, and a much better control over types and structure across our codebase b/c we didn't need "their" types and structure anywhere. It had crept everywhere. It's just faster, cleaner, and easier in a few cases to do precisely what you need right now, rather than anticipate a mill…

Yeah, the problem / benefit is never the one framework you added / removed, it is the mindset of reaching for another dependency as a default which leads to a behemoth which no one enjoys working with.

I also think a person who has had to strip out or replace dependencies is more likely to be careful when choosing them in the future. This is definitely the case for me, at least.
Post reply on HN