swatson741

It looks like most of those points are because you wouldn't necessarily be transmitting power over frequency like you would with AC. But, if we're transmitting over long distances wouldn't we end up transmitting the DC in frequency to avoid attenuation loss?

The article makes this seem like it's a US problem but, the interconnects lay in Canada and Mexico too. I'm guessing that unification is a low priority for them since it seems that the US stands to gain the most from it.

"DC power lines transmit power more efficiently than AC lines do"

This is not at all what is taught at school. Looking into this is interesting. 100 years ago people were debating about whether AC or DC is a better means of transmitting power and, it looks like answers still aren't clear now. I'm interested in knowing what an expert in this thinks.

This is the programming language equivalent of saying "My dad could beat up your dad."

Personally, I find his prose to be plain and boring but, his insight is really interesting.

"Now we would like to go a step further and extend the system to handle differenti­ation. This is a favorite problem, and one which has historical significance: in the summer of 1958 John McCarthy decided to investigate differentiation as an interest­ing symbolic computation problem, which was difficult to express in the primitive programming languages of the day. This investigation led him to see the importance of functional arguments and recursive functions in the field of symbolic computa­tion. For example, McCarthy invented what we now call mapcar to express the idea that the derivative of a sum is the sum of the derivative function applied to each argument. Further work led McCarthy to the publication in October 1958 of MIT AI Lab Memo No. 1: "An Algebraic Language for the Manipulation of Symbolic Expressions," which defined the precursor of Lisp."

PAIP is filled with writing like this. You could remove this paragraph from the book and, it wouldn't make the explanation any more or less comprehensible. The level of detail at which he provides this insight is interesting. It ends up being more than just amusing anecdotes. It's what makes the book worth reading imo.

"Esperanto Is Not Dead: Can The Universal Language Make A Comeback?"

I'm not trying to be that guy but, looking at the title for this piece I'm thinking: Esperanto is dead and, it is not a universal language.

"... Humphrey Tonkin, an English professor at the University of Hartford in Connecticut. He taught himself Esperanto at age 14, and then used it to travel across Eastern Europe and beyond."

I feel like this needs some clarification.

There's nothing quite like PAIP. It's more a book history than a book of programming. Although the programs are the main focus of the book it's not what gives the book quality. It's programs are relics but, it's content is not.

The unfortunate reality is that there probably isn't a google-free future for Mozilla. I don't see any way they can generate the same amount of capital that they get by partnering with Google, etc. But, that doesn't have to be a bad thing. As far as I know, Google doesn't pull Mozilla's strings and, the 2 companies can exist as competitors and partners.

This is a good article but, the author doesn't show the limitations of type systems. If our world is small enough types can be very useful. There are many situations where we want to work in a small world.

>type's have always been there

I've seen this argument before and, I disagree with this statement as presented. The implication is that there is a type system underlying a language's semantics. But, really that's not true. It's more correct to say that objects have always been there.

Just some basic algebra and calculus is the main prerequisite. You can probably get away with just linear algebra if you don't plan on going too deep into the subject.

Very impressive. Too bad they take 10 hours to yield. I'm excited to see how far they can take this in F1.

This was a funny read. I think a good way of thinking about this problem is: it's not a matter of shipping the product. That is, putting the product into market but, a matter of getting your product into customers hands. The market and shipping is really just a means to that ends. Also, knowing what features customers need and what features customers can do without helps a lot.