HN user

holmak

182 karma
Posts3
Comments27
View on HN

In "The Evolution of the Unix Time-sharing System" by Dennis Ritchie, he writes:

Although it was not until well into 1970 that Brian Kernighan suggested the name ‘Unix,’ in a somewhat treacherous pun on ‘Multics,’ the operating system we know today was born.

I like this paper for its thorough description of the very earliest versions of the operating system.

Their market analysis, just like every other discussion of commercial space exploration I've ever seen, is circular. Space solar power, space manufacturing, space mining, space refueling... the only reason to do any of those things is if you have some other reason to be in space in the first place. (And in this case, near the moon!)

SDL is written in C, and it has a much more pleasant way of dealing with heterogeneous event types. There is a struct called SDL_Event, which you fill by calling SDL_PollEvent() until there are no more events to read. The struct is a (discriminated) union of all the possible event types. (It even wraps the Win32 API, so it is very directly comparable -- it is returning the same events!)

https://wiki.libsdl.org/SDL_PollEvent

I don't have any trouble with pointers. I can understand C programs just fine. But Modern C++, as the evangelists love to point out, is specifically about avoiding raw pointers in favor of smart pointers, value semantics, etc. That's the stuff that I find difficult to use.

I did buy Stroustrup's post-C++11 book, "A Tour of C++", which is supposed to be the compact "how to do Modern C++". It provides tips, but as I mentioned above, I did not find it comprehensive enough. Terse recommendations like "Prefer returning by value" may be great small-scale recommendations, but they don't explain how the big picture is supposed to come together.

Sorry, I misunderstood your comment. I think the original poster was referring to the Plan 9 team's strong preference for C over C++. Plan 9 was written with a modified version of C, and the developers seemed to be very interested in evolving the C language. As far as I can tell, they never used C++.

In the presentation before the awarding of the Japan Prize today, you were quoted on the distinction between research and development. [The former, Thompson stated, was directionless, whereas development had a specific goal in mind.] So in that context, is Go experimental? Yes. When the three of us [Thompson, Rob Pike, and Robert Griesemer] got started, it was pure research. The three of us got together and decided that we hated C++. [laughter] [1]

It looks like you were half-right about the early Go compiler being partly written in C++: There were two compilers, and "gccgo" had a C++ front-end, while their homemade compiler "gc" was written entirely in C. [2]

[1] http://www.drdobbs.com/open-source/interview-with-ken-thomps...

[2] https://golang.org/doc/faq#What_compiler_technology_is_used_...

I tried to learn "modern" C++ style, and watched many, many videos from cppcon, but I just don't feel like I understand how to do it. I started a C++ project, #included <vector> and all the rest, and tried to do things the way the experts recommend, but I had no confidence that I was doing any of it right.

I know all the copying and moving and whatnot is supposed to "just work", but as far as I can tell, there's no easy way to verify that your program is doing what you intend. There also aren't any compact guidelines -- "follow these N simple rules and the STL won't explode!". With most other languages, I can at least think through the program to figure out if it is going to do what you intend, but the way that the STL is implemented to support all the modern C++ behavior requires a brain the size of a planet to understand.

I'm sure Stroustrup and the committee can write Modern C++, but I sure can't. Not with any confidence, anyway.

I wonder what fraction of male Computer Science majors also come into their first semester with no programming experience. When I was a freshman, it seemed like absolutely everyone in my CS classes had been programming for years, but surely that's not the case for everyone?

Anyway, the bit about (comparatively) experienced programmers intimidating the other students in freshman classes is a real and terrible thing. I thoroughly support shoving all those students into a different class; it is disruptive to have them in an intro course.

Regardless of how you categorize the system, having more money flowing through an organization increases the incentive for the members of that system to do something unethical to take advantage of it.

I noticed that too. It amuses me that it just takes a couple of tasteful red and blue stripes to make something look official!

I agree that the names are confusing or misleading to modern readers. The strange choice of words in both cases seems to be due to the terms being used in a technical sense with a more specific meaning than in plain English. Plus, they are both based on terms coined long ago, and the connotations (or definitions) of English words do tend to change over the centuries.

From the Wikipedia page on moral hazard:

[...] the term dates back to the 17th century [...] Dembe and Boden point out, however, that prominent mathematicians studying decision making in the 18th century used "moral" to mean "subjective", which may cloud the true ethical significance in the term.

From the Wikipedia page on rent seeking:

The word "rent" does not refer here to payment on a lease but stems instead from Adam Smith's division of incomes into profit, wage, and rent. The origin of the term refers to gaining control of land or other natural resources.

The article suggests that the discussed behavior is a problem because it does show up in code that "regular users" have to look at:

This paper tries to shed some light in the dark corners, and explores whether the language can be cleaned up so that good template documentation does not drag obscure language-lawyer details into the domain of the regular user.

I have seen it claimed that null-terminated strings were encouraged by the instruction sets of the time -- that some instruction sets make null-terminated sequences easier to handle than length-prefixed ones. The article's error-message-printing code snippet is a good example. Does anyone think there is any truth to this?

I've been thinking about this lately, and there might be a great advantage to modern democracy even if it is a sham run by oligarchs. Unlike an old-fashioned monarchy or dictatorship, if you want to take over the country, you just have to pay a bunch of money to take control of legislative seats and/or the presidency. This is way less disruptive than having a civil war with armies rampaging about.

It may be nowhere close to the popular ideal of democracy, but the reduced violence and destruction would probably make it a worthwhile innovation anyway.

The concept presented here of "seeking justice by appeal to the majority" reminds me of the Twitter phenomenon in which people learned that the only way to get customer service from Google/Ubisoft/Bank of America/(insert giant faceless company) was to tweet a grievance publicly. It seems to work well, at least in a few high-profile cases. At least, it worked a few times when private requests failed. Perhaps people are learning by example?

The old-fashioned ("culture of honor/dignity"?) style of one-on-one negotiation is often futile when you are dealing with a company.

I often think about the strange coincidence that English is the easiest language to represent in a computer. Only 26 characters, with no accents, all independently placed in series. The only awkwardness is the existence of both capital and lowercase. (How much simpler would things be if case-sensitivity wasn't a consideration?) But at least capitalization is one-to-one in English, unlike German's "ss" rule. All this makes it easy to make a keyboard for English typing, too. Every other language and script I can think of is more difficult to handle in software. Perhaps Cyrillic is similarly computer-compatible, but I don't know enough about it to be sure.

It is just strangely convenient!

I agree with your assessment -- utility with respect to time is the first explanation I thought of as well. People (and firms) have a limited ability to anticipate or defer purchases. (I can't wait 50 years to buy a lifetime supply of food to feed myself!)

You also mention that this limited ability to defer purchases in the face of deflation is what makes short bouts of deflation not catastrophic -- it is somewhat difficult to get the deflationary spiral going if you can't actually wait to purchase things.

Given all this, the interesting question to me is, how much deflation does it take to actually cause a deflationary spiral? The answer is likely complicated, given that it depends on the specific utility functions for each consumer of all the goods and services that they consume.

Empirically, we seem to be able to cope with a decent amount of deflation, at least when it is limited to certain goods, like video game consoles, computing power, other manufactured goods, etc. (In some cases, even over very long timespans.)

Ask yourself: why buy today what can be bought tomorrow cheaper?

I know the the correct, rational answer to this question: "I won't buy it today, or ever, because it will always be cheaper the next day." (And then the deflationary spiral begins!)

But if this is really true, why has anyone bought a Playstation 4 or Xbox One? They will undoubtedly be cheaper in two or three or ten years. Well, consumers might be totally irrational; what about firms? Why has any company in history ever bought a computer when the price of computing power has been falling rapidly and (mostly) predictably for fifty years?

I don't think the question "Why buy today what can be bought tomorrow cheaper?" fully explains the behavior of people in the face of increasing purchasing power; there seems to be something else going on. Any thoughts?

> European pharma co. Novartis made in 2012 revenues of $19.7bn in Europe vs $18.6bn in the US (and a total of $56.7bn). Novartis invested 21% of sales into R&D.

> U.S. pharma company Pfeizer, total revenues of $59bn in 2012, U.S. was $27bn and international $36bn. Pfeizer invested $7.9bn in R&D (c. 13% of revenues).

Do you know what fraction of those revenue figures are profit? It is entirely possible that the companies could have different profit margins in different areas.

Whenever the income inequality of the US is discussed, I wonder about the global income distribution. The US is no longer a closed system, so it may not be meaningful to consider the US income distribution on its own. Does anyone here know how income inequality is doing globally?

Those alternatives are indeed all taxpayer funded, but not all act as a subsidy to employers. There was a paper contrasting EITC and guaranteed minimum income, and one of the notable differences is that EITC is a slight subsidy to employers, while GMI is actually the opposite. GMI creates (some) disincentive to work, requiring employers to pay more to attract the same employees.

> it feels like Clojure went all liberal on one end, just to get super-conservative on the other.

In the brief time that I used Clojure, I also thought that the contrast between immutability and dynamic typing was very strange. Ultimately, I think it makes more sense than having the entire language be highly dynamic (or highly static).

I think Clojure's choice is not inconsistency, but that there is a kind of budget for craziness in a language. In Clojure, you can go crazy with dynamic types on the foundation of immutability, transactions, etc. In Haskell, you can go crazy with really awesome static typing tricks that would be utterly unfathomable if the language wasn't very rigid in every other way -- immutable, referentially transparent, side-effect-tracking. These two pack all their craziness into one corner of the language.

On the other hand, other languages -- Python, Javascript, Ruby -- seem to spread the craziness (I am not sure I picked the best word for this!) around, instead of having one super dynamic feature and everything else very inflexible. These languages tend to lack the really big flashy features: macros, typeclasses, etc.

It seems that you have a lot of flexibility as a language designer on how you spend your craziness budget, as long as you don't go too high (and become incomprehensible) or too low (Java?).

This is backtracking a bit, but what are the goals of raising the minimum wage?

The implied goal seems to be to help the poor, but as others have pointed out, other policies (EITC, guaranteed minimum income, negative income tax) are better suited to that goal. So, do proponents of the idea have a different (or additional) goal in mind? Do proponents believe that these other policies are not more effective solutions?

I would like to hear others' opinions on the answer to this question, especially if you support the raise.