Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simple Is Not Small

jyn.dev

Post reply on HN
Print view View original

41–50 of 95 posts

Re: Simple Is Not Small

#41

Post by embedding-shape »

pianopatrick wrote: post #35

I've been thinking about a new AI based dimension to this. If your program is split into smaller decoupled "modules" then all the code for each "module" can fit into an AI context window. In this way the AI can have all the context to edit a "module" by just loading all the code for that "module". You would not need things like vector search as much. If we assume 20 tokens per line of code and the AI context window i…

> then that would argue for having "modules" between 5,000 and 50,000 loc, depending on which AI model you are using.

FWIW, I set hard limits to 200 LOC for every single source code file in any AI-related projects, also with restrictions on "formatting hacks" and other golf-like stuff.

I think beyond 5000 LOC in a single file and all available models already get lost frequently, even if the "context limit" theoretically is way above that. Maybe aim for like 1K LOC at max unless you want to have lots of misunderstandings.

Re: Simple Is Not Small

#42

Post by leecommamichael »

I was surprised that the author didn’t translate the piped representation of the first program to a procedural program with explicit calls to subprocedures. It’s bigger, but it’s dead-simple and easy to slip instructions in the middle of.

Re: Simple Is Not Small

#43

Post by JoachimSchipper »

FattiMei wrote: post #30
JoachimSchipper wrote: post #19

The general point is true, but the shell pipeline gets a lot more elegant if you use the sort-and-accumulate paradigm that the classic shell utilities were written for (which uses O(1) memory, by sorting on disk). Using mostly the author's own code, and adding --count to uniq: tr (Where the final awk papers over the fact that we're mixing tabs and spaces here; obviously, awk is also good at doing the accumulation ste…

Very interesting solution, and in the spirit of the original article. If I understood the snippet right, you are sorting the input sequence on the first column (the words) and then on the second one (the frequencies) It is nevertheless "complecting": the uniq assumes the data is sorted and the columns of your data structure move together. Maybe this algorithm is already complex regardless of the implementation. btw,…

The sort is on line numbers, as aozgaa said. Again, the paradigm here - and this is designed for a different time - is that your data most definitely does not fit in RAM, so you use sort(1) to sort on disk and run your software using only constant memory. (In modern software, databases can and do sort on disk, but few programs do.)

In detail, for input "foo bar FOO qux FOO foo", we convert to

[1 foo, 2 bar, 3 foo, 4 qux, 5 foo, 6 foo]

(with newlines instead of commas, obviously), then sort by word (then line number) to

[2 bar, 1 foo, 3 foo, 5 foo, 6 foo, 4 qux]

at which point the uniq invocation gives , i.e.

[1 2 bar, 4 1 foo, 1 4 qux]

albeit with an ugly mix of tabs and spaces. One final sort by gives us

[4 1 foo, 1 2 bar, 1 4 qux]

and then it's just a matter of formatting the output:

[foo 4, bar 1, qux 1]

The generally-useful point is that the classic shell utilities really do work pretty well if you're operating within their paradigm, which isn't "throw everything in a hash table". (That's the paradigm of later scripting languages.)

Re: Simple Is Not Small

#44

Post by stephenlf »

Twey wrote: post #37

> The reason for this is that in Rust, a struct couples type-checking to a fixed data representation. You can't get one without the other. > Clojure decouples data representations from type checking. This is funny to me because seen from the other side, (this) Clojure couples runtime type information to data structures: you're no longer allowed to define a data structure that doesn't have some runtime type informatio…

Yeah that example was pretty flimsy and contrived.

Re: Simple Is Not Small

#45

Post by JoachimSchipper »

aozgaa wrote: post #40

Another solution to the pipeline example, this time making use of a subprogram for the frequency/accumulation: If you don't allow `awk` in your "pure bash" then ofc this is not satisfactory. But it has the upside that the associative arrays are pretty explicit data structures (for the ordering and counts, respectively).

Nice to see more people getting nerdsniped by the sh code. ;-)

Yes, associative arrays work well. I think it should even be possible to use bash associative arrays. But at that point you're no longer doing classic sh - awk is basically halfway to Perl. (And pretty awesome.)

Re: Simple Is Not Small

#47

Post by diegocg »

Snarwin wrote: post #20

> There's no native Unix equivalent to frequencies, this sort | uniq -c is the closest we can get. Not only is it less performant (it has to collect the full input into memory before continuing), but it ties aggregation to ordering. One of the core features of the Unix command-line is that it is user-extensible. If there's no "native" command equivalent to frequencies, you can write your own, and it will be given the…

Yeah, that point was weak. The argument went from "Unix pipelines are not simple" to "unix based operating systems don't have an equivalent to Clojure's frequency function by default so it's worse"

OK but how would it look like if you had such a program? Shells are not known for having the extensive set of functions that real programming languages have.

Re: Simple Is Not Small

#48

Post by wnoise »

leecommamichael wrote: post #42

I was surprised that the author didn’t translate the piped representation of the first program to a procedural program with explicit calls to subprocedures. It’s bigger, but it’s dead-simple and easy to slip instructions in the middle of.

How is the clojure program given not that?

Re: Simple Is Not Small

#49

Post by sgarland »

aozgaa wrote: post #40

Another solution to the pipeline example, this time making use of a subprogram for the frequency/accumulation: If you don't allow `awk` in your "pure bash" then ofc this is not satisfactory. But it has the upside that the associative arrays are pretty explicit data structures (for the ordering and counts, respectively).

You can skip `tr` as well - works on BSD awk and GNU awk.

    {
        $0 = tolower($0)
        gsub(/[^[:alpha:]]/, "\n")
        for (i = 1; i

Re: Simple Is Not Small

#50

Post by basilikum »

jerf wrote: post #18

Honestly, having watched people argue about what simple is for about the last 10 years, I've pretty much settled on it not being a well-defined term. We know complex when we see it for sure, at least when it is present in quantity, but simplicity is not just the absense of complexity. There's at least three concepts we're all trying to stuff into the same word, and they are not only not "orthogonal" they are often in…

Could you try to define these three separate concept?
Post reply on HN