Discovering Dennis Ritchie’s Lost Dissertation • Hacker News Board

Re: Discovering Dennis Ritchie’s Lost Dissertation

#61

Post by P-NP » Sat, Jun 20, 2020, 2:14 PM UTC

mettamage wrote: post #21

searchableguy wrote: post #12

Earlier quoted context omitted.

> Andrew Tanenbaum: I said that his work was amazing and thanked him. He shrugged me off. I think he felt busy or didn’t care. I was happy that he listened. I have the same reaction to people thanking me out of nowhere especially when I am deep into my own thoughts and it's awkward to say something after the shrug. The realisation comes latter. So there is a chance he did appreciate your thank you but couldn't reply…

Ah, that's also an explanation. I tend to take the most optimistic interpretation.

> So there is a chance he did appreciate your thank you but couldn't reply back properly.

> I tend to take the most optimistic interpretation.

Yes, always take the most optimistic interpretation compatible with the known facts. Best way to stay happy.

Re: Discovering Dennis Ritchie’s Lost Dissertation

#62

Post by rsc » Sat, Jun 20, 2020, 2:16 PM UTC

dang wrote: post #10

> My graduate school experience convinced me that I was not smart enough to be an expert in the theory of algorithms and also that I liked procedural languages better than functional ones. I wonder if that last bit was as unfashionable a statement when he made it as it would be now.

Is it an unfashionable statement now?

The vast majority of the world's programs are written in procedural languages, and that situation does not look likely to change for the foreseeable future.

Re: Discovering Dennis Ritchie’s Lost Dissertation

#63

Post by brmgb » Sat, Jun 20, 2020, 2:29 PM UTC

shpongled wrote: post #56

ratww wrote: post #48

Earlier quoted context omitted.

Ah, funny thing: I worked with Haskell professionally for a while. I even enjoy the laziness. My biggest gripe with it is not so much the language itself but the culture: it favours bloated and pompous solutions much in the same way Java/Spring does. Monad Lifting, Lenses, Aspects and FactoryFactories occupy the same space in my head. I guess I just prefer both the simple side of functional and the simple side of imp…

OCaml/Standard ML are both pretty nice because you can still use mutation, and the languages are significantly simpler than Haskell. My only gripe with them is that there seems to be a culture of having zero type annotations (due to HM), which can make reading other people's code difficult.

> the languages are significantly simpler than Haskell

I don't think that's quite true.

Ocaml has plenty of advanced features (the module system, GADT, structural typing in the object system) but the community relationship with them is very different than how the Haskell community uses the language. For the most part, the Ocaml community tends to dislike gratuitous complexity and be non dogmatic (I fondly remember a lens library announcement on which the top comment could be boiled down to "just use mutations").

> My only gripe with them is that there seems to be a culture of having zero type annotations (due to HM), which can make reading other people's code difficult.

Interfaces tend to be annotated (mli files) but usually people rely on the tooling to know types inside files. Merlin is a blessing. It is a very fast type-checker which keeps working on incorrect files.

Re: Discovering Dennis Ritchie’s Lost Dissertation

#64

Post by dri_ft » Sat, Jun 20, 2020, 2:32 PM UTC

rsc wrote: post #62

dang wrote: post #10

> My graduate school experience convinced me that I was not smart enough to be an expert in the theory of algorithms and also that I liked procedural languages better than functional ones. I wonder if that last bit was as unfashionable a statement when he made it as it would be now.

Is it an unfashionable statement now? The vast majority of the world's programs are written in procedural languages, and that situation does not look likely to change for the foreseeable future.

But fashion != popularity. Indeed, the most popular thing in a field is almost definitionally unfashionable.

Re: Discovering Dennis Ritchie’s Lost Dissertation

#65

Post by hellofunk » Sat, Jun 20, 2020, 2:33 PM UTC

dang wrote: post #10

> My graduate school experience convinced me that I was not smart enough to be an expert in the theory of algorithms and also that I liked procedural languages better than functional ones. I wonder if that last bit was as unfashionable a statement when he made it as it would be now.

Having used functional languages extensively in a job setting and now using C++ more and more, I find that there's nothing wrong in just writing procedural code if that's easier. Easier both to write and easier to read later. I've seen people take 20 minutes to write a single line of functional Javascript or Kotlin, when the underlying work is obvious and just writing the loop directly would be faster to create and much easier to understand later by you or anyone else who has to read the code.

The move to functional-style code the last many years seems a bit silly to me. Even C++ has been moving in a well-known trend of "no raw loops" in favor of the algorithms header in STL. I don't find there is a significant reason to abandon easy code most of the time. If you actually need to use the functional paradigm to swap out behavior in a polymorphic fashion using functions instead of inheritance, for example, then great.

Re: Discovering Dennis Ritchie’s Lost Dissertation

#66

Post by u801e » Sat, Jun 20, 2020, 2:41 PM UTC

dzdt wrote: post #35

unixhero wrote: post #20

Earlier quoted context omitted.

Except every non programmer with a business degree seem to love functional programming: Microsoft Excel

Excel is at its core a declarative programming language. Entering formulas in cells that reference other cells declares the relationship of the calculated cells to its referents. It is not an imperative language: the user does not tell the computer which order in which to carry out computations. It is not procedural: there is no notion writing of procedures within its cells. It is not functional: while there are buil…

> while there are built-in functions users cannot write their own in the same way.

It's been a while since I've used Excel, but I thought you could write custom methods using VBA that could be called in a given cell.

Re: Discovering Dennis Ritchie’s Lost Dissertation

#67

Post by shpongled » Sat, Jun 20, 2020, 2:43 PM UTC

brmgb wrote: post #63

shpongled wrote: post #56

Earlier quoted context omitted.

OCaml/Standard ML are both pretty nice because you can still use mutation, and the languages are significantly simpler than Haskell. My only gripe with them is that there seems to be a culture of having zero type annotations (due to HM), which can make reading other people's code difficult.

> the languages are significantly simpler than Haskell I don't think that's quite true. Ocaml has plenty of advanced features (the module system, GADT, structural typing in the object system) but the community relationship with them is very different than how the Haskell community uses the language. For the most part, the Ocaml community tends to dislike gratuitous complexity and be non dogmatic (I fondly remember a…

Ah, I have more experience with SML than OCaml, I just kinda (ignorantly) lumped them together.

I should put some more time in with OCaml, Merlin sounds nice.

Re: Discovering Dennis Ritchie’s Lost Dissertation

#68

Post by mercer » Sat, Jun 20, 2020, 2:50 PM UTC

atrettel wrote: post #52

I am not surprised about the effort it took to find a copy of Ritchie's dissertation. Dissertations tend to be difficult to find if they are not already listed on WorldCat or in ProQuest. But the museum used the best method in this case: talk to people close to people who had a copy at one point. In my experience when all else fails, this strategy is the primary one that ends up working. It doesn't work all the time,…

Out of curiosity: what 'ancient' technical reports are you looking for (plus who knows someone here might know something)?

Re: Discovering Dennis Ritchie’s Lost Dissertation

#69

Post by gwern » Sat, Jun 20, 2020, 3:09 PM UTC

Taniwha wrote: post #18

So what would happen if we took up a collection, produced a bound copy, and sent it off to Harvard?

I like this idea. So I took a look at their policies and it seems the official Harvard thesis printer (https://www.hsph.harvard.edu/student-handbook/dissertation-g...) is Acme, which has an individual-oriented website: https://www.thesisondemand.com/ Using their calculator, a single 181pg\* BW printed thesis is ~$45. That seems cheap enough for a joke for me! But it looks like one will need to add some additional metadata to follow the dissertation guidelines...

If anyone wants to discuss this further, email me.

\* The first copy of the thesis linked in OP is 179 pages but it's very dirty and would need to be printed in color; the second copy, https://archive.computerhistory.org/resources/access/text/20... , is in much better shape and can be printed in BW.

Re: Discovering Dennis Ritchie’s Lost Dissertation

#70

Post by RHSeeger » Sat, Jun 20, 2020, 3:17 PM UTC

hellofunk wrote: post #65

dang wrote: post #10

> My graduate school experience convinced me that I was not smart enough to be an expert in the theory of algorithms and also that I liked procedural languages better than functional ones. I wonder if that last bit was as unfashionable a statement when he made it as it would be now.

Having used functional languages extensively in a job setting and now using C++ more and more, I find that there's nothing wrong in just writing procedural code if that's easier. Easier both to write and easier to read later. I've seen people take 20 minutes to write a single line of functional Javascript or Kotlin, when the underlying work is obvious and just writing the loop directly would be faster to create and m…

I tend to go with whatever makes the code the most readable; best expresses the intent. If I'm iterating over a list, mapping each element to a lookup somewhere, and then removing those that weren't found... that's a good choice for functional. If I'm iterating over a list, if it matches one thing do something, otherwise filter it some more and do something else... I tend to find procedural is easier to read. Maybe it's a transform vs act-on type of thing; I'm not sure.