prestonbriggs

It does seem rather a shabby article. Out of all the ways we can imagine exercising, they compare 3 very mild approaches (plus not exercising) and someone proclaims one of them "the best"!?

If you want to find an "optimal" exercise, you'll need to specify a function you're trying to minimize. Might be time to run a marathon, or time to swim a mile in the ocean, or some blend of performance/hours_invested.

Of course, some people do this, e.g., folks trying to win Boston, etc. And even here, where the goal is clear cut, the absolute best approach is not at all obvious.

When I buy books, I intend to read them; I expect Eco does too. I think the point is the library of as-yet-unread books is more interesting than the library of already-read books. And it differs from Wikipedia or the Amazon catalog; it's a collection of books that interested me enough to lay out money and shelf space to have nearby.

A friend wondered how they can make their improvements to SAXPY and claim they're correct w/o using the restrict keyword.

Grrr. None of this (article or most of the comments) has much to do with Haskell. It applies to all languages, right? You implement an abstraction using an appropriate data structure, accounting for the frequency of various operation you plan to perform. Often a list will be the wrong data structure - no big surprise.

But if you'd like to implement a stack, perhaps with a lot of elements, then a singly linked list is a reasonable choice. But you need to think about the operations you need. If you're just pushing, popping, looking at the top element, checking for empty, then great!

If you need to check the length, then you'll need to keep a counter, otherwise you'll pay O(n) time. If you need to make a copy for read-only purposes, great, constant time. If you need to make a copy for destructive use, then you'll have to pay O(n) time. This is all Mom-n-apple pie.

Maybe.

I think it'd be an interesting thing to study. When I was young and running a lot, I could beat (recreational) cyclists uphill, but they would smoke me on downhills. So there might be the kernel of a fun study there.

I guess my hypothesis is that, given equally fit bikers and runners, there's an incline where they will climb at equal speeds. Furthermore, at steep inclines, the runners will be faster and at shallower inclines, the bikers will be faster.

Doesn't seem too unlikely (or interesting, actually), given the weight of the bicycle. But the general shape of the curves might be interesting.

For 100 meters from a standing start? He'd crush you. Time yourself someday.

It's easy to beat a compiler in the small - just takes time & patience. But such an approach doesn't scale. We don't write tiny routines and throw them away; instead, we write big programs made of lots of routines & classes, and we maintain them for years, probably porting them from machine to machine.

I encourage everyone to write some assembly; you'll learn a lot. But use a compiler for your work.

Tediously! See: http://ultrasparky.org/school/pdf/Rhatigan_Monotype_4-line_m...

This thesis actually describes a scheme Monotype developed to replace the older hand-setting approach (used through WWII). Nice intro to the subject though.

Preston

But consider Buffon's Needle https://en.wikipedia.org/wiki/Buffon%27s_needle

My favorite is "Tlön, Uqbar, Orbis Tertius". Still makes me smile to read it.

A lot of the fun of the Plan 9 compiler and source organization is that it doesn't optimize; instead, it compiles fast. Like the whole OS in about a minute (on a Raspberry PI). Or maybe it's 2 minutes, I don't recall.

The Go folks have adopted some of the same ideas (minimal optimization and no nested include files), and they build on the experience of the Plan 9 compiler to better divide the work between the "compiler" and "linker", so we gain more from parallel make.

Of course not. But when you finish implementing Forth, you'll know how to implement forth, but not much else. But once you build a parser, you'll know how to build a parser for most any language. You don't have to learn every sort of parsing technique; I only use recursive descent. And once you learn for to do data-flow analysis, you'll find it applies whenever you want to write an optimizer. Same for various optimizations and code generation techniques.

Indeed, I'd argue that Forth is best appreciated after you've worked on other compilers for a while. Then you have a basis to appreciate how clever it is.

Sure he does... Anyone advocating for assembly language necessarily cares about registers.

I disagree. Forth is cute and you'll learn some stuff, but you won't become a compiler wizard. You _need_ to learn how to do parsers and run-time systems and all the rest.

Besides, it's fun!

List seems inadequate. I guess it's enough to get you going working on compilers, but there's not much wizardly on that list.

Read papers. Learn about data-flow analysis and optimization. Learn code generation (instruction selection, register allocation, instruction scheduling). Learn about interprocedural data-flow analysis. Learn/build a garbage collector or 2. Parallelization, vectorization, type analysis. Write an optimizer for Go. Write papers or your own.

My wife cooks entirely w/o oil. Lots of vegetable broth. As a bonus, makes washing up a lot easier.

Tweets, schmeets. He can ignore 'em all the doo-dah day. Send him a letter.

Looking at Shutt's thesis (I've just started), he makes the point that Scheme is pretty 1st class, but not entirely: It has a few reserved forms, e.g., if, lambda, quote. This never particularly bothered me, but errhaps this is what Shutt is attacking.

One of Shutt's advisors (on his thesis) was Shriram Krishnamurthi who certainly understands Scheme deeply. Makes me curious to read the thesis in an effort to understand what's new and interesting here.

Chaitin published his stuff in the early 80s. Presumably the implementation is a bit older. But the idea of doing register allocation via graph coloring goes back to the late 60s and the idea of using graph coloring to minimize storage requirements generally goes back to around '63.

The interprocedural problem is mostly engineering - how to manage libraries, make files, etc., in a way that programmer will use it.

I've always liked Beta's approach to assignment, calls, and returns (whilst disliking most of the rest of its syntax, sigh).

Assignments work left to right, approximately like this:

    (x, y) => (y, x)

which swaps x and y.

Calls that return multiple values look like

    x => sincos => (sinx, siny)

and we can string together all sorts of things like this

    x => sincos => sum => y

Procedures looked something like

    sincos(double x) {
      ...
    } returns (sinval, cosval)

All this syntax is pretty approximate, but perhaps you'll get the idea. To me, it seemed attractive in that a tuple of values flowed in at the top of a procedure, then left to right on each line, and top to bottom between lines, and finally a tuple of values is returned. Seemed like a natural sugaring of CPS style.

Reminds me of Steele's Rabbit compiler (as noted by Appel and probably others). Always made a lot of sense to me, though I never worked out the details. I thought in terms of every basic block taking arguments (in registers), and every branch passing some arguments. Lexical scoping gives us a way to express common arguments. This should be interesting to read and think about.

Cdr-coding is a fine way to take advantage of locality with linked lists, especially when the garbage collector is doing it for you, transparently. https://en.wikipedia.org/wiki/CDR_coding

Knuth is posting source and you want the assembly?

Using LP, comments can be arbitrarily formatted, with TeX equation handling, beautiful figures, tables, cross references, indices, table of contents, etc.

Code can be presented in a way that best suits the reader (versus the writer or the compiler). Though Knuth's examples usually seem to dive right in, lacking the introduction to be provided by the latest stuff in TAOCP.

When I use it, I write it like a paper decorated with code, where the code can be extracted and run. I usually include the necessary make file and perhaps some test data. Entries in figures/tables are sometimes generated automatically by the program being described.

There are lots of old papers and critiques about LP, by Knuth and others. You should check 'em out.

Stress is the point. You apply stress to your body and it adapts. Antifragile and all that...

It's "Chomsky" of course, but I _really_ like "Chompsky"!

Hi Dennis. Yes, and hooray for Hacker's Delight!

I recently had occasion to reread one of Kernighan's older books and you remind me that I'll probably enjoy the Go book too.

More accessible: http://en.wikipedia.org/wiki/Data-flow_analysis

Before CP/M and such, he was a serious compiler guy who made contributions to data-flow analysis, etc. E.g., http://dl.acm.org/citation.cfm?id=512945