ScottBurson

SVN has its limitations, but having used Perforce in my last job and now using Git, I wouldn't mind going back. It's a judgment call, as the two systems have different strengths and weaknesses, but I don't find Git to be an overwhelming improvement. For instance, in Git, if you merge from branch A to branch B while work is underway on both, then merge A to master — and assuming you're using squash merges, as is pretty much essential to get a readable commit history — and then merge from master to B, you're in merge hell, because Git doesn't remember that the squash-merge commit contains some of the changes that were already merged to B. Perforce gets this right: it gives you an equally clear master history, with a single merge commit each time you merge from a branch, but doesn't lose the relationship of that to the individual commits in the branch.

Or maybe the RX-8?

That's a great word!

Really interesting to read this now, almost 50 years later. So much has changed — and so little has changed.

The DEC PDP-10 was a 36-bit machine.

> The housing problem is a problem of demand

Prices are set by the balance of demand and supply. The demand isn't going away. The supply is what we can do something about.

Even building expensive luxury apartments helps, unless no one can afford them at all (which is not what the builder wants to happen). The people who rent those aren't taking up spaces others could have afforded.

Yeah, Prop. 13 is such a disaster.

Supposedly, the big selling point was that seniors on fixed incomes were getting priced out of their homes. But that would only happen because they have a substantial, appreciating asset. These aren't poor people who deserve our sympathy; they're relatively well-off people with a cash-flow problem! We could have solved their cash-flow problem without destroying our cities' tax bases by allowing them to defer some of their taxes [0] until their property was sold.

Here's a great article from 2014 that talks about it: https://techcrunch.com/2014/04/14/sf-housing/

As for cities profiting from allowing new housing, this might interest you: http://www.henrygeorge.org/pcontents.htm

[0] For example, the amount of tax due immediately could be allowed to grow at 2% annually, following the Prop. 13 formula. Also, the tax due at sale could be limited to, say, 70% of the gain on the sale. That limit would probably never take effect, in practice, but I've learned from previous occasions where I've proposed this that people tend to get hung up on the possibility that one might owe more in tax than one stood to make on the sale. In fact, if you run the numbers, it takes some very strange assumptions to make the deferred tax even approach getting that large; but this rule should assuage that concern. (Basically, you'd need several years of strong price growth followed by a sudden, huge collapse.)

That's why it's "YIMBY" and not "YIYBY" :-)

While I vigorously support more construction in the SF metro area, I think expectations need to be set correctly as to the amount of construction required to actually bring prices down, instead of just slowing their rate of increase. It's a lot. I don't recall all the numbers, but I believe I saw something suggesting that we need to increase the rate of housing starts by a factor of 4 just to stabilize prices. To actually bring them down would require even more than that. Again, we should absolutely do it, in my opinion, but if we were to only double construction — difficult as that will already be, politically — and prices didn't plateau, people might conclude that it doesn't work. We need to make sure they know what it's going to take.

It's not so much induced demand as it is pent-up demand. Lots more people would already love to live here — indeed, many have moved away solely because of housing costs.

Have you looked at FSet? https://github.com/slburson/fset

Glad you've found FSet useful! I'm curious what the difference is in map equality semantics.

Yes, and let me take the opportunity to thank you! (Have to do it here since you've done such a good job of hiding your email address :-)

I wish I had time for FSet work, but I just don't right now.

I used macro expansion for type checking in Zeta-C [0], the first C compiler for Lisp Machines, in 1983. Didn't write a paper about it, though.

Dependent types are certainly interesting -- I'll give this a read. Thanks!

[0] http://bitsavers.trailing-edge.com/bits/TI/Explorer/zeta-c/

There's always Common Lisp. Still portable 35 years on.

I recall once, not quite 20 years ago, porting a large CL program from a 32-bit implementation to one of the then-new 64-bit Lisps. Someone who didn't know CL thought that would be a hellish job, but it turned out to be quite straightforward.

The problem is thinking that there could be such a thing as a license for software engineers in general. That would be crazy, almost like having to be licensed to write English. Software is applied to too many different domains and tasks.

What could work would be licensing for software engineers in certain specific domains. For example, we could require election systems software engineers to be certified for that field. Same with automotive software, power plant software, etc. etc. I agree that we should do this. But it's going to apply to only a small fraction of all software engineers, because licensing Web app developers is not practical.

I'm not sure the solution to abuse of the legal system is more abuse of the legal system.

The vinyl gets noisier when it's recycled. The best pressings are on virgin vinyl.

Beats me. I still have a collection of LPs I bought in the 1970s and early 80s, and while many of them are pretty good pressings and I don't mind listening to them, some are pretty bad. I have a lot more CDs, and they almost all sound very good to excellent (any defects being in the master, not the medium, of course).

What I do get nostalgic for is music without compression. So many recent recordings I find unlistenable, even when I like the music, because they're compressed to within a dB of their lives. This is a much bigger deal to me than digital vs. analog.

You must not be aware of Newegg's success in defending themselves against patent trolls. They demonstrated that stonewalling can pay off.

Assuming you're in software -- study machine learning! It's going to be hot for a long time.

In fact, there is a pretty good circumstantial case to be made that the true (but unspoken) purpose of the amendment was to guarantee the slave states the ability to forcibly suppress slave rebellions.

https://www.nytimes.com/2018/05/24/opinion/second-amendment-...

To clarify: the Supreme Court did not say that assistance could not be restricted to single parents. The "Man in the House" rule said that a woman was not single if she even had a boyfriend who was not her children's father, if her boyfriend ever visited her house. That's the part that was struck down.

As for the restriction to single parents, I can certainly see the potential for unintended consequences. Paying people not to get married means fewer people will get married — just as paying people not to work, as the "welfare cliff" effectively does, means fewer people will work. I broadly support the idea of helping people who need help, but it needs to be done in such a way that it doesn't tend to trap them in their situations.

According to your first link, the rule had been in place in some jurisdictions prior to 1968, but was struck down by the US Supreme Court at that time.

No, because high-income people still have to be net payers. Otherwise, where does the money come from?

> Names should be easy to type. [emphasis in original]

I see. This is why your language is called "K".

Permit me to disagree. Reading code is harder than writing it. Names should be easy to read. Typing can be assisted by autocomplete in editors -- already an old technology.

A "dialect" of MacLisp, the page says. I doubt there was any code in common.

My 1993 Toyota is looking better by the day :-)

If anyone's still reading, I can't resist adding that I was doing type checking by macro expansion — a technique that was the subject of a 2017 POPL paper [0] — in 1983.

[0] https://www.ccs.neu.edu/home/stchang/pubs/ckg-popl2017.pdf

I don't know what your threshold for "cool" is, but an example of something that's straightforward in Lisp is if you want to generate a hierarchy of class declarations from a schema, so the classes have certain instance variables and methods defined in some regular way; for instance, you might want to auto-generate a method for each class that returns a collection of the values of certain of its instance variables. In most any language other than Lisp, you'd have to define your own schema syntax and write a parser for it and a generator that outputs the declarations in the target language. In a nutshell, it would probably be painful enough that you wouldn't bother; you'd just type in all the boilerplate manually. In Lisp, not only is writing such a schema translator relatively straightforward, but you get incremental recompilation for free.

Right, you can also do it that way. I should have said "all these things can happen in a single process in an interleaved manner".