4 ms·

Are there projects we can undertake to intentionally hit those walls and measure ourselves?

kybernetikos 9y ago
Like the equivalent of 'memory-hard' problems - 'lines-of-code' hard problems. I suppose that's close to what https://en.wikipedia.org/wiki/Kolmogorov_complexity https://en.wikipedia.org/wiki/Kolmogorov_complexity is.
- theSage 9y ago
  Ah no. I meant what task can we undertake to see this in action? For example, writing your own compiler is bound to make you hit the 1k wall. If you're able to write it chances are you have passed the 1k wall some time in your past. That kind of measurement.
  - kybernetikos 9y ago
    Part of the problem is that people who are good at dealing with large codebases tend to write fewer lines of code if they can at all get away with it.
  - sifoo 9y ago
    I would say writing your own non-trivial interpreter is a pretty good metric from my own experience. That will take you into 10k land, and the problem is complex enough to lure beginners into creating a tangled mess. The reason I'm fairly sure, is that I just did; and I had to use most tricks I've learned to get this far: https://github.com/basic-gongfu/cixl https://github.com/basic-gongfu/cixl
deleted 9y ago
[deleted]
Cthulhu_ 9y ago
I think it's only something you really encounter in either your day to day work, or some OS projects but those have, I think, a very different day to day structure.
lmm 9y ago
My experience is that exercises don't capture the skills you need - the hard part is understanding the domain and descoping the problem as much as possible, if you start with a well-defined exercise you've already taken out the essence of the problem. The only way to hit the walls is to try to solve a genuine problem - and even then, if you don't hit the wall there's no way to know whether the problem was too easy or you were too good. Maybe none of the problems we currently solve with computers actually demands beyond-the-wall programming, if we just used tools that were good enough. Certainly most of the time when automating business processes I would find it very hard to believe there was 20k lines' worth of essential, irreducible complexity in the task. It's just that with today's tools most of the lines we write are ceremonial, with relatively little describing the essence of the problem.
dahart 9y ago
Yes, but you'll need to have users who aren't yourself, and after the 20k wall, probably a manager and other coders on your team and a year or two horizon. At this scale, the easiest way to practice this is to do it as part of your work, get involved in larger projects, not attempt it yourself or as a side project.

Like the equivalent of 'memory-hard' problems - 'lines-of-code' hard problems. I suppose that's close to what https://en.wikipedia.org/wiki/Kolmogorov_complexity https://en.wikipedia.org/wiki/Kolmogorov_complexity is.

theSage 9y ago
Ah no. I meant what task can we undertake to see this in action? For example, writing your own compiler is bound to make you hit the 1k wall. If you're able to write it chances are you have passed the 1k wall some time in your past. That kind of measurement.
- kybernetikos 9y ago
  Part of the problem is that people who are good at dealing with large codebases tend to write fewer lines of code if they can at all get away with it.
- sifoo 9y ago
  I would say writing your own non-trivial interpreter is a pretty good metric from my own experience. That will take you into 10k land, and the problem is complex enough to lure beginners into creating a tangled mess. The reason I'm fairly sure, is that I just did; and I had to use most tricks I've learned to get this far: https://github.com/basic-gongfu/cixl https://github.com/basic-gongfu/cixl

deleted 9y ago

[deleted]

Cthulhu_ 9y ago

I think it's only something you really encounter in either your day to day work, or some OS projects but those have, I think, a very different day to day structure.

lmm 9y ago

My experience is that exercises don't capture the skills you need - the hard part is understanding the domain and descoping the problem as much as possible, if you start with a well-defined exercise you've already taken out the essence of the problem. The only way to hit the walls is to try to solve a genuine problem - and even then, if you don't hit the wall there's no way to know whether the problem was too easy or you were too good. Maybe none of the problems we currently solve with computers actually demands beyond-the-wall programming, if we just used tools that were good enough. Certainly most of the time when automating business processes I would find it very hard to believe there was 20k lines' worth of essential, irreducible complexity in the task. It's just that with today's tools most of the lines we write are ceremonial, with relatively little describing the essence of the problem.

dahart 9y ago

Yes, but you'll need to have users who aren't yourself, and after the 20k wall, probably a manager and other coders on your team and a year or two horizon. At this scale, the easiest way to practice this is to do it as part of your work, get involved in larger projects, not attempt it yourself or as a side project.