CS etc

[r_transpose_p]

I'm slowly getting the impression that the field I knew of as "computer science" when I was an undergrad (remember when the undergraduate catalog listed a "scientific computing track"? CS majors don't do that shit anymore) is slowly schisming into a bunch of only-tangentially-related fields

Comments

[soong]

I once learned a dozen different ways to sort. Now I just call any language's standard library sort function with my array of data and my compare function. I can imagine having to write a merge sort by hand because of needing to manage the IO carefully. I will sometimes write a bubble sort because it's so very few lines of code, easier than using the standard library, and isn't going to process enough data to need to be more efficient

[rmitz]

I'm not convinced that if you don't have the basic understanding of how a sort *works*, what its algorithmic complexity is, you have any real ability to think in programming at all, though.

[angelbob]

Well, yes. The way we usually transfer that information (basic understanding of runtime and fairly generic algorithms) is with a small number of examples including sorting that we feel most people will need to do at some point.

I'd argue that sort isn't a lot better for it than many other choices, though. There's a natural tension between "this illustrates different programming techniques" and "this is something you will actually use", and sort is more at the sweet spot of those things intersecting than the best possible example of the first category.

[r_transpose_p]

How long do you think until "sorting" is considered a systems topic?

Also, I wonder if we'll all start having to use something like "distributed sort" in the future.

I have n networked computing units, each of which stores about k things, and I'd like the first k on the first unit, the next k on the next unit, etc...

I think, so long as sending 10 numbers takes 10 times the time of sending 1 number, some distributed version of quicksort still comes out pretty good...

[angelbob]

Good question. You're right, sorting is already mostly a systems topic in practice.

Distributed sorts are interesting because I don't think there will be just one -- I think there will be at least two or so common ones, and probably more as we work out when to use them.

Simple sorting will look a lot like QuickSort, yes, but I imagine you'll see a lot of distributed equivalents of topological sorts mostly, because that's usually going to be a much better way to distribute tasks among nodes than having to do an exact sort-and-division. The problem with exact sort-and-division is that in a distributed environment you'll often have new items arriving or modifications to old ones. You'd like your sort 'order' to be pretty resilient to that, where possible. Exact sorting-and-division where you assume you know exactly what is on what node fails that test.

So I think a lot of distributed sorts are going to look more like rough grouping.

[rmitz]

I mean, it's the classic "code monkey" argument. Just because you don't have to code assembly by hand doesn't mean you shouldn't have the understanding in the back of your mind.

[soong]

This came up in a recent discussion and was phrased as 'A+ programmers doing B- tasks' (in a discussion between a bunch of self-identified A+ programmers frustrated with doing too much menial glue code). I think we agreed that better programmers can do the other stuff better, if you can keep them happy and not bored. The degree to which they do it better probably has something to do with better understanding of what's going on in all the parts of the system.

[zml]

I love doing tasks other people find dumb, and bringing some sanity to many areas where people don't dare tread. I think this is also true for the most successful people that I know.