The MySQL MyISAM and InnoDB engines and a grocery checkout - <AUTHOR> http://blog.scoutapp.com/articles/2009/10/09/choosing-between-the-mysql-myisam-and-innodb-table-types There's plenty of discussions centered on the choice between the MySQL MyISAM and InnoDB engines. I've illustrated a case that has bitten me in the past. <comment><USER2> The analogy is helpful, but leaves some things out. In one of the grocery stores, you'll find that if the lights flicker off and for just a second, half the products on the shelves may end up unusable. And if your store gets past a certain size, a sinkhole may appear and suck most of your inventory underground with no warning.

The only reason I can think of for using MyISAM tables in a web app is the terrible default InnoDB settings in MySQL. Users unfamiliar with InnoDB may not realize that the awful performance is an artifact of bad configuration, and easily fixed.

<comment><USER3> Can you provide some info or a link on this config change.

Thanks!

<comment><USER2> This is handy: [http://www.mysqlperformanceblog.com/2007/11/01/innodb- perfor...](http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance- optimization-basics/)

Lots of good InnoDB-related posts on their site.

<comment><USER3> Good stuff to know. Thanks.

</comment></comment></comment></comment><comment><USER4> Man this is annoying:

1\. The MyISAM/InnoDB debate is so stale it stinks. If you're using MySQL, you should be using InnoDB unless you know exactly why you should use MyISAM. None of these issues are relevant until you have alot of concurrency and uptime/transactions/integrity are radically more important than potentially faster SELECT statements on MyISAM.

2\. Did HN really just put this flaccid article to the top of the list? Aren't we more technical than this?

<comment><USER5> I'd vote it down if I could, it's far too fluffy and short for my tastes. The only reason I could think of using MyISAM is if you need features that only it supports, like compression, MRG_MyISAM tables, or full text search.

Having said that, the newer InnoDB plugins support compression, with partitioning you don't need MRG_MyISAM, and you can use something like Sphinx for full text searching, which integrates nicely into MySQL.

</comment></comment><comment><USER6> I'm still not sure why folks still use MyISAM. I'm sure there may be some edge case where it makes more sense, but in generally InnoDB seems like a better choice (not just regarding row level locking). Or postgres:)

<comment><USER7> I've yet to find a good comparison of the two.

In fact, from what I've seen it seems better to use MyISAM when you don't need support for ACID transactions.

<comment><USER2> I don't agree. MyISAM tables are easy to trash, and the table locking on update can bite you. There's no real disadvantage to using InnoDB other than having to learn to tune it a litte bit, and your data will be much safer.

<comment><USER8> Define 'easy to trash'. I've been using MyISAM without problems for years now.

<comment><USER5> MyISAM is like the ext2 filesystem. You crash and you end up spending a long time doing an fsck, where you have to verify the consistency by walking all the data structures. InnoDB is more like ext3, where you can make things consistent by replaying the changes in the journal. Doing repair on a large MyISAM table can take hours and hours.</comment></comment></comment></comment></comment>


Made a small JavaScript library for smooth pretty drawing/handwriting on Canvas - <AUTHOR> https://github.com/jakubfiala/atrament.js <comment><USER2> I like it and would probably try to use it in a commercial project if it had a different license. It's a little laggy - when I draw a quick circle, starting at the top and letting go of the mouse button at the top again, I only get about 3/4s of a circle. Cool stuff though.

<comment><AUTHOR> To be honest I wouldn't mind switching to MIT. Let me know if you want to use it and I can relicense, no problem. Regarding lagginess, that should be a little bit better in the latest commit on master – it was because of the adaptive filter being too strong.</comment></comment>


Goodbye, Object Oriented Programming (2016) - <AUTHOR> https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53 <comment><USER2> I feel like the author doesn't understand the design part of OOD. Yes, you can inherit yourself into rigidity. OOP doesn't prevent you from making design choices that turn out to be bad, or are bad in the first place.

You can't reuse a class without reusing the whole world? That's the purpose of dependency injection and depending on interfaces instead of implementation. Decoupling.

Diamond problem? Okay, granted. But this still solvable in most languages with interfaces.

I'm not really drinking the OO Kool-Aid here. I lean functional when I get the chance, but this article reads like someone who's against rope because they hanged themselves.

<comment><USER3> If you have to tell too many people that they are "not doing it right", then perhaps its too hard to do it right. If you build a paradigm that only Sheldon Cooper can get right and complain when non-Sheldon's "can't use it right", there is a bigger problem. It was supposed to make software design easier and "more natural". If it takes lots of training to get right, that's not "natural".

In general, I find OOP fairly well suited for building utilitarian API's, but NOT for domain modelling. Domain modelling is where OOP failed bigly. When UI/GUI's got more complex, they outgrew OOP's ability also and became a mess. There seems to be a size/scope limit to OOP of subject matter.

</comment></comment><comment><USER4> I doubt there's very few OOP hardliners on here, I'm certainly not. So, let me play devil's advocate here a bit.

For the monkey-banana-jungle problem, it seems the developer started from a monkey-banana type in a previous project, rather than just the monkey. It seems in this case you would refactor the existing monkey-banana class, and extract a plain "monkey" class that satisfies both projects.

I've done things like this in the past, and it's a headache, but it's less painful than starting over from scratch. Most OOP languages will offer good type checking for the refactoring process, and can easily catch any errors. Also, dead code elimination can remove most of the unused methods and types from a large codebase.

Diamond inheritance is a bigger problem. However the example they give is terrible. Why wouldn't the powered device type be a common ancestor? One way forward here is to use composition plus an interface to satisfy a new top level type with shared functionality. It's ugly, but gives you some form of consistency over types that need to be loosely coupled.

The fragile base class problem is equally stupid imho. Counting is managed in two different ways from two different methods? Yikes! They also didn't think to test this, and the change passed all of existing automated tests? Yikes!

You can shoot yourself in the foot with functional programming as well. Anything that is shared can become fragile. Forming abstractions that cut across multiple concerns is still problematic and error prone. It's common to bring a jungle when you need a banana no matter what PL technique you use.

</comment><comment><USER5> Also see Yegor Bugayenko's essay, "What's Wrong With Object-Oriented Programming?"`

[http://www.yegor256.com/2016/08/15/what-is-wrong-object- orie...](http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented- programming.html)

and also the essay "Object Oriented Programming is an expensive disaster which must end" had an interesting conversation here on Hacker News:

[https://news.ycombinator.com/item?id=8420060](https://news.ycombinator.com/item?id=8420060)

</comment><comment><USER6> I can't wait for his "Goodbye, Functional Programming" article.

</comment><comment><USER7> This is overly simplistic and ranty. Sure, the OOP community got high on its own supply for a decade or two and is now getting some well-deserved criticism, but that doesn't make OOP the devil and it certainly doesn't make all of its claimed virtues null and void (no pun intended).

The "Banana Monkey Jungle" problem applies to any paradigm that involves defining things in terms of other things, including functions that call other functions. You avoid it by writing code that's well-decoupled, no matter what paradigm you're using.

The diamond problem is well-documented and has been solved or worked around by numerous variations on inheritance (referring to methods by their class explicitly, composition, etc.). It's a real problem with Java's "pure" inheritance, but the author doesn't really add anything new to that discussion.

The fragile base class problem is mostly a problem of poor interface definition (read: documentation). Assumptions were made because there was ambiguity, and then those assumptions went from true to not true.

"Object Oriented languages don't make Contain and Delegate easy to do. They were designed to make Inheritance easy." It's clear this author has spent most of his time in Java. It's true that vanilla Java makes it difficult/annoying to implement delegation, but C# can do it just fine, as can TypeScript and (I believe) C++.

The Hierarchy Problem, once again, is solved by composition.

The author naively suggests that encapsulation is bad, but what he really means is that hiding values behind their functions is bad (debatable, but not crazy). Encapsulation is an essential building block of writing any nontrivial amount of code. Functions themselves are encapsulation. Libraries are encapsulation.

Finally, in the Polymorphism section, he actually bothers to distinguish the principle from how it's been traditionally applied inside OOP, unlike throughout the rest of the article.

OOP is flawed. OOP as passed down by the Java priests from On High circa 1995 was extremely flawed. But I'm weary of reading people's rants about it, especially when they can't distinguish ideas like encapsulation and polymorphism from OOP, and can't distinguish OOP from Java 1.0. Essays like this throw the baby out with the bathwater. These days some of OOP's critics are just as zealous as its proponents were in the 00s.

</comment><comment><USER8> Golang solves the problems talked about in this article. Except for "encapsulation" which is really just... the author doesn't like pointers which is non specific to OOP.

Why is functional programming better? The author doesn't really delve into that

</comment><comment><USER9> Goodbye Larry, see you in 5-10 years when OOP is back in style!

<comment><USER10> Will it come back? Maybe it will be hot among the next generation of programmers that failed to learn from the past. Just like the mistake that is explicit asynchronous programming (e.g. callback hell in node.js) when (cooperative) multitasking has existed for 50 years!

</comment></comment><comment><USER11> I feel that whenever someone complains about OO, it almost always starts with "I tried mapping everything to a class" and I always want to ask "Why?".

<comment><USER12> In Java everything has to be a class.

I prefer C++/Python style where things don't have to be classes. They can just be independent functions.

</comment></comment><comment><USER13> Yes! This is basically why my new language is functional, and not OO. I bought in the OO dogma in college, but programming in functional languages is just so much easier.

<comment><USER14> Any chance you can talk more in depth about this? I'm really curious! FP seems wonderful, but there are few side-by-side code examples out there.

<comment><USER13> Sure. I presume you're asking about why FP is easier, though if you're wondering about my language there's more info at https::/darklang.com.

I think the quote about the gorilla and the banana and the jungle is a really important piece. It's just hard to compose things in OO languages unless they're designed to be used together. Whereas in an FP language, you focus on simpler primitives (arrays, hashtables, nullable types, and errors values typically, depending on the language), and you have a ton of functions that know how to work with those, so you kinda use them for everything.

A second reason is static typing (doesn't apply to the lisp family of FP). Good static typing makes it very easy to understand what's happening, and makes it hard(er) to make errors. For example, in OCaml, Elm and Haskell, it's impossible to have a NullPointerException, which is the biggest bug class in Java. Similarly, the biggest problem in a python/ruby codebase is "what exactly is this thing I have", a problem eliminated by the type system as well.

Of course, these features have a cost. It can sometimes be trickier to do things that are easy in dynamic OO languages like Python (and of course Haskell has layers of complexity so I don't recommend going near it), esp the learning curve if you're not familiar with FP. But being in deep in a functional codebase is much much easier than being in a deep in a java, ruby, python, js, etc, codebase.

If you're looking to check FP out, I recommend Elm, ReasonML, or Clojure.

<comment><USER15> > about my language there's more info at https::/darklang.com.

I find it slightly reassuring that someone is actually working on a language/compiler with PaaS features built in. I'd thought of doing that and jotted it down in my notebook.. assuming it was just a crazy idea.

When do you plan to release an alpha version? I'd be interested in seeing it!

<comment><USER13> Alpha is probably out this year. We send periodic announcements to our mailing list, there's a link at the bottom of Darklang.com. Also, we're hiring: [http://darklang.com/careers](http://darklang.com/careers)

</comment></comment></comment></comment></comment><comment><USER16> These posts are tedious, like a stereotypical newly converted non-smoker or vegetarian cornering you at a party.

The same arguments about the diamond inheritance problem, and blah blah blah. Funny gun-foot meme...check.

I'm not even saying it isn't true. I'm saying that it's boring. Functional programming has it's own set of stupidity and anti patterns. If your favorite language doesn't have any that spring to mind...give it time.

Queue the people saying OO is really message passing.

Then the Rust people. I guess the world has always been this way, but it makes me think we are screwed as a species.

<comment><USER10> People need to put it their way to learn. And to some readers these thoughts will be actually new. That's how opinion/experience/knowledge spreads.

</comment></comment><comment><USER17> Hello, OOP (2018)

I just recently wrote a Lisp compiler and assembler (for VM) using OOP.

[http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib/compil...](http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib/compiler.tl)

[http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib/asm.tl](http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib/asm.tl)

Even abused inheritance for logic re-use: see _defopcode-derived_ macro in the assembler.

The OOP system is my own---now compiled. :)

It's a pleasure to use and makes the code look good. No bo

</comment><comment><USER18> It is always seems kind of cute when someone discovers something new and thinks it's a silver bullet.

On a side note, .NET is not a language, it's a framework, like JVM. In fact F# runs on .NET and it is purely functional.

<comment><USER19> I'm shocked that in the 17+ years .NET's been around, we _still_ hear people say that .NET is a language.

<comment><USER3> They often really mean "common Microsoft languages such as C# and VB.net used with Visual Studio". There's no common short way to say that (yet). "Microsoft stack" is about as close as I can come.

</comment></comment></comment><comment><USER20> I get what he is talking about, but to be honest alI never encountered a situation where I intentionally or unintentionally got to diamond inheritance. I just didn't... As for the add/addAll example, the smart thing to do is just not put too much in the public method or just declare it final...

</comment><comment><USER21> This article is about OO+[bad language design/patterns].

You can do OO without sharing state with your parent(s).

</comment><comment> awinter-py not sure FP handles fuzzy categories better than OOP

isn't fuzziness why we have topic models and, more generally, ML?

</comment><comment><USER22> the year annotation on this article got me :)

</comment><comment><USER17> > _For efficiency sake, Objects are passed to functions NOT by their value but > by reference.

What that means is that functions will not pass the Object, but instead pass a reference or pointer to the Object._

This is confused garbage, and goes rapidly down hill from there.

Reference semantics is required for OOP. The reference is necessary because that _is_ the object. The object's "value" is a concept from the record or structure types of non-OOP languages like C and Pascal. If we pass the value, we are not passing the object, but a copy.

In high level languages, we don't even see the reference as a separately declared reference type; that is a low-level concept from "Blub OOP".

I'm surprised this blogger's Smalltalk experience didn't set him straight.

> _If an Object is passed by reference to an Object Constructor, the > constructor can put that Object reference in a private variable which is > protected by Encapsulation. But the passed Object is NOT safe! Why not? > Because some other piece of code has a pointer to the Object, viz. the code > that called the Constructor._

The charitable way to understand this bizarre nonsense is that because the caller of the constructor has a reference to the object, it has access through the reference to the object's "value", and by going through that reference, it should be understood as bypassing the encapsulation of the container which also holds that reference as a private variable.

This is laughably confused. Encapsulation means just that the binding is private: the newly constructed object holds that existing object in a private slot. Encapsulation doesn't mean that the embedded/aggregated object's contents are also private to the aggregator. Those are protected by that other object's class!

> _The Constructor will have to Clone the passed in Object._

Only in some very specific circumstances when it is necessary for this parent object to have its own instance of an object similar to the one which is passed in: either so that it can mutate this instance without having an effect elsewhere, or else so that it has a snapshot facsimile of the passed object which is immune from changes elsewhere.

Such a requirement doesn't always apply.

> _So much for efficiency._

When such a requirement doesn't apply, the construction of the similar object or 'deep cloning' will not just be inefficient, but _wrong_. For instance container object will expect the contained object to react response to events, but instead it actually has a dead copy which isn't receiving calls from anywhere.

It's clear from the semantics whether "we want to be composed of that actual object" or "we want to be composed of a similar one, in a similar state to that one's current state".

The second situation may require planning and design work. Indeed, not objects can be easily copied.

Some other solution may be required, like splitting that object into some state that is easily copied and some part that remains shared. This need not even require a split, just a suitable copy operation.

Linux has clone() system call for processes with a bazillion flags to copy this and not copy that; kind of the same thing. Sometimes we share the address space and file descriptors and signal handlers, sometimes we don't.

</comment><comment><USER23> [2016]

(not that it adds any credibility ....)

<comment><USER24> Updated. Thanks!

</comment></comment><comment><USER25> For anyone not wanting to read the opinion behind the click-bait-titled article, here's the TLDR: the author never learned how to write OO code and is now declaring it dead.

Every problem he brought up is easily solvable by writing good code. FYI, I'm a big proponent of FP, but I'm not a proponent of disparaging things I don't fully understand.

<comment><USER26> > Every problem he brought up is easily solvable by writing good code.

I'm curious, how? Would you mind use one of his examples along with some good code?</comment></comment>


The Truth about California: It's actually saving the rest of the USA - <AUTHOR> http://www.marketwatch.com/story/the-truth-about-california-2010-11-22

<comment><USER3> Interesting article.

One statement struck me as odd:

> Most of the states that have grown faster than California during that time > are farm states, riding an incredible boom in agriculture prices.

I suppose there is nothing wrong with this statement, strictly speaking. However, it suggests that CA is _not_ a "farm state". But it certainly is. CA is the number-one agricultural producer of all the 50 states. It's a clear number one in crops, and number two (after TX) in livestock.

<comment><USER4> I would imagine that the other states' economies depend much more on agriculture than California's does though. Thus, California has a lot of farmers, but it doesn't get as much from a surge in agriculture prices like the others do.

<comment><USER5> California %2 is agriculture. Texas is 0.8.

<comment><USER4> Really? That's actually somewhat surprising to me. Still, I don't really think of Texas as a farm state either. I'm thinking more along the lines of the Midwestern states like Kansas or Nebraska.

<comment><USER6> Texas has two of America's six largest cities in addition to all of its agricultural land. North Dakota has a city of less than 100,000. So its hinterland is a little more important.

<comment><USER7> The original article was about growth, so absolute size is not relevant to the argument.

</comment></comment></comment></comment></comment></comment><comment><USER8> Most criticisms of California target public sector backwardness, so it's not a refutation of that to point to the strength of the state's private sector. And "CA's private sector is strong, ergo it hasn't been harmed by the government" is a circular argument.

This is an argument over the precise extent to which bad policies are bad. Seems more useful to discuss what genuinely good policy looks like.

<comment><USER9> The argument that California's policies must be bad, regardless of the fact that they've produced the strongest private sector in the country, is equally fallacious.

<comment><USER10> Maybe I am mistaken, but it seems to me that California's private sector is strong despite its backward government, not as a result of it. California is an extremely desirable place to live. This attracts business owners and highly qualified employees alike. I would be interested to hear which of California's policies you believe play a significant role in the success of its resident businesses.

<comment><USER11> > I would be interested to hear which of California's policies you believe > play a significant role in the success of its resident businesses.

Its large subsidies for higher education played a significant role imo, especially during the era (up through the early 1990s or so) when they were larger. The state used to fund the UC and Cal State systems with a larger subsidy than today's (much larger if you account for population growth), and also indirectly supported the state's private universities, by providing very generous scholarships to CA high-school students with good grades, if they chose to attend any in-state university, public or private (the old CalGrants program, which still exists in name, but with much reduced scope).

The "ton of taxpayer money spent on higher education" policy doesn't _fully_ account for the highly qualified employee base and large number of university- research spinoffs and collaborations, but I think it probably accounts for some of it. Interestingly, Texas is another example, despite otherwise being more small-government than California: it imposed an oil-and-gas extraction tax in the early 20th century, with a significant portion of the revenues legally required to go to the state-university trust fund, which in part accounts for the strength of the UT and Texas A&M systems, and the high-tech concentration in Austin.

</comment></comment></comment></comment><comment><USER12> The author has a serious chip on his shoulder. Lots of politicking in this article that distract from the point being made.

Take a look at what the market thinks of the chances for a California default.

[http://www.economist.com/blogs/dailychart/2010/11/credit- def...](http://www.economist.com/blogs/dailychart/2010/11/credit-default- swaps_spreads)

As of a week ago, "The state with the biggest budget problems, California, is seen as slightly less likely to default than Spain but slightly more so than Italy."

Note that Spain is a total mess with an unemployment rate around 20%.

It's hard to default when your can print your own currency. I think the California bond holders will never take a haircut. The US will just print more dollars.

<comment><USER13>
      > Take a look at what the market thinks of the chances
      > for a California default.

This assumes that 'the market' is a rational actor. But it's proven time and again that it isn't.

<comment><USER14> The question around the [ir]rationality of markets is irrelevant. Markets determine the cost of borrowing. If California wants to lower the cost of debt, or maintain the current (low) cost, it must value the opinion of the markets.

The calculation of the author, with state debt costing $6billion a year, assumes a constant cost of borrowing into the future! Investors have been selling municipal debt in the past two weeks, which will result in higher borrowing costs [1]. The same thing happened and is happening with the PIIGS, where those in power have been complacent about their ability to service debt because of the assumption of constant debt servicing costs.

[1] [http://search.ft.com/search?queryText=muni&ftsearchType=...](http://search.ft.com/search?queryText=muni&ftsearchType=type_news)

November 25, 2010 US muni bond funds lose another $2.3bn November 18, 2010 US muni bond funds see record outflows November 16, 2010 US muni bonds see biggest drop since 2008

</comment></comment></comment><comment><USER15> _"Californians are so productive that every year they send billions of dollars in surplus dollars to the rest of America. Year after year they have sent vastly more in federal taxes than they ever get back in federal spending."_

So many seemingly educated Americans can't tell - or artfully avoid telling - the difference between state and federal taxation and spending. Also, here's the dirty secret: people in other states don't really "get back" any of that federal money unless they work at federal facilities, including military bases, common in the states accused of getting more federal money than they give. If they're _really_ lucky, they might get that money at a remove or two if they work in lower-end service jobs near a military base.

But then, that whole thing is a strawman. Some random idiot might be saying Californians are all lazy good-fer-nuthin's, but everyone else isn't talking about Californians, but an unsustainable state government.

" _California's a basket case? The state has one of the highest living standards in the country..._ "

I'm rather horribly reminded of global warming "skeptics" who hoot every time it snows.

<comment><USER16> "Also, here's the dirty secret: people in other states don't really "get back" any of that federal money unless they work at federal facilities,..."

People in these states don't drive on federally-funded roads, or have anything to do with anything else that receives federal dollars? Right-wingers are keen on talking about trickle-down when it comes to tax cuts, but mention nothing of the multiplier effect of the spending habits of the people who earn money which comes directly from the federal government. So yes, people in those states "get back" big from federal spending!

<comment><USER15> _"People in these states don't drive on federally-funded roads"_

They don't pay federal gas taxes, either? You might do better picking something better than federal road spending when trying to defend California, incidentally.

But that's the problem you face when you try to reduce distinctly different things like federal and state spending to "But California really has a surplus, honest!"

" _Right-wingers are keen on talking about trickle-down_ "

So? They're also big on "starve the beast" deficit spending, but that hasn't worked in California, either.

ETA: Suggestion - disengage from your partisan reflexes. Think. Remember than the Republican Party in California has been as much of a contributor to the problem as the Democratic one, at least in proportion to how much power they have had, if that helps.

California's in trouble. It'll certainly survive and improve, but the spending cuts and tax hikes that they'll have to have this time (or if they sweat and bluff it through a few more years, the _next_ time there's an economic downturn) will be far from fun.

</comment></comment></comment><comment><USER17> The gist seems to be that despite numerous stories predicting its demise, California:

\- is wealthy and talented

\- has more (people, VC, etc.) than it did in 1999

\- has been funding the rest of the country in federal transfers (he calls them bailouts, therefore you can't complain if CA asks for one)

\- has a small budget deficit relative to its budget

It leaves out $138B of unfunded liabilities for state employees until the end, and ignores companies like Facebook opening datacenters out of state, a growing number of people _leaving_ the state (I'm one of them), and its awful credit rating.

Unfortunately if I owe the bank money, I can't tell them how good of an investment I was up until 2008 and expect them to give me a pass. I need to figure out a way to come up with the money. California doesn't appear to be serious about that.

<comment><USER18> _and ignores companies like Facebook opening datacenters out of state_

Explain this to me. It seems obvious that companies would open datacenters outside of just California. What would be more obvious to me would be placing them close to 1) backbone hubs and 2) cheap electrical power.

<comment><USER17> Well that's fine, but don't tout that your state is an engine of economic growth when the companies you mention decide to "offshore" major chunks of their operations. Figure out a way to keep them in state, or generate some kind of equivalent growth, maybe even outside silicon valley.

<comment><USER19> > don't tout that your state is an engine of economic growth when the > companies you mention decide to "offshore" major chunks of their operations

You're clearly implying here that Californian companies are placing datacenters outside California because of state policies, which is simply incorrect.

While it makes sense to put one datacenter somewhere in the vicinity of California, datacenters should be geographically distributed. It's also common to place datacenters near rivers for cheap cooling, but good sites are relatively rare. Now consider competitive bidding from cities, cheap power, and wanting to locate datacenters near users. Basically, state policies have a relatively small impact.

<comment><USER17> I conceded that point about the datacenters, but we both know that a lot of tech companies in California offshore their manufacturing, call centers, etc. Get some of that to stay with state policies.

Reason has some more evidence why the article is bunk:

[http://reason.com/blog/2010/11/29/is-californias-decline- jus...](http://reason.com/blog/2010/11/29/is-californias-decline-just-mo)

</comment></comment></comment></comment></comment><comment><USER20> Fiscal facts aren't all that matters. Investors' perceptions can also have an impact--if California is perceived to be in trouble, investors demand higher premiums on bonds, and the costs for California to borrow money increase. This can lead to a detrimental cycle of destruction, akin to what happened to Lehman Brothers.

<comment><USER21> >akin to what happened to Lehman Brothers

there is also, more probable for a state, scenario of AIG/etc... - <USER2> government stepping in.

</comment></comment><comment><USER22> I thought it was a case of referenda being used to demand things be done but the voters not actually wanting to have to pay for them.

</comment><comment><USER23> The point about the State of California heading towards bankruptcy is not affected by either its tax rate compared to other states or the amount of venture capital dollars it sucks up. The primary driver for the state going bankrupt is its expected income vs. its expected expenses. Venture funding in California has little affect on its tax base as most profitable startups are incorporated in Delaware or have their revenue generators incorporated offshore.

Yes, they'll be good revenues from the employees but no windfall should be expected. (i.e. the state should not expect abnormal returns because of in state venture capital investment)

My point is that when you take look at expected income vs. expected expenditures you can expect to see the state go further and further into debt. It's anyone guess as to whether that will lead to filing for bankruptcy or not, but the direction the state's fiscal health is heading is clear.

Regarding the state's fiscal picture this article largely addresses a straw man. No one is arguing that the state will go bankrupt because it's tax rate is wildly out of whack, or because it is not getting enough venture capital funding.

People are arguing that the state will go bankrupt because the state already has a fair amount of debt relative to GDP, it runs large current accounts deficits relative to GDP, and has large unfunded pension mandates. This article addresses none of these points.

</comment><comment><USER24> IANAE (I am not an economist), but here's an observation from a born-and-bred Californian: whenever the economy is bad, the state budget takes it on the chin. California is big -- bigger than a lot of people realize. I mean this in terms of geography _and_ population. So it seems to me that national problems are magnified here in our microcosm.

Once the economy picks up, the state problems ease.

 _Tangential anecdote_ : I was at a JBoss conference a few years ago, talking with a guy from the company who'd never been to California before. I mentioned that I had just driven back here -- I'd been snowboarding over the weekend. He gives me a dubious look, and says, "You don't have snow in California."

<comment><USER4> Here's what strikes me as funny: California's budget crunch is $25 billion. Texas (a paragon of small government) is facing a deficit of... $25 billion. The fact that both states have similar deficits would seem to back your argument that this has more to do with the economy than budgetary policy.

[http://www.dallasnews.com/sharedcontent/dws/news/politics/st...](http://www.dallasnews.com/sharedcontent/dws/news/politics/state/stories/110410dntextxxgr.20cde75.html)

[http://articles.sfgate.com/2010-11-11/news/24826042_1_budget...](http://articles.sfgate.com/2010-11-11/news/24826042_1_budget- deficit-deficit-estimate-deficit-balloons)

<comment><USER25> The debt (read: accumulated past deficits) isn't the only, or even main, issue; rather it's the _future_ liabilities that are killers.

For example, California has unfunded pension liabilities of over $500 billion [1]. To put that number in perspective, it's almost seven times greater than all the outstanding voter-approved state general obligation bonds in California.

[1] <http://www.stanford.edu/group/siepr/cgi-> bin/siepr/?q=/system/files/shared/GoingforBroke_pb.pdf

<comment><USER26> This is the core of the problem. My problem with this article is that you can apply the same arguments and paint a picture where the US itself has a rosy economic future. But the problem isn't even merely today, November 29th, 2010, it's the scope of the future obligations we've taken on. It's not that the US or California has necessarily _that_ exceptional of a debt load _right this second_ , it's that the money we might be using to service it is already nominally allocated to other "untouchable" projects.

That's the big change; entitlements (and pensions as a subset of those worth calling out specially). To do an article about how glorious the California future is and to criticize not just the arguments but the motivations of those saying there are problems, but for neither the word nor the concept of entitlements to show up is just constructing a straw man and cherry-picking the budget numbers.

For that matter reading the article straight you might be mystified about why California has very recently resorted to the very legally-dubious IOU-money- but-not-quite-money scheme. If it was even half as rosy as this guy is arguing that shouldn't have been even close to necessary, but in the real world, it was.</comment></comment></comment></comment>


The problems with HTML5 audio - <AUTHOR> http://cromwellian.blogspot.com/2011/05/ive-been-having-twitter-back-and-forth.html

<comment><USER2> This is true, but that is not to say solutions are not on their way. From this script that was submitted yesterday (<https://gist.github.com/9c4955e5a3662e4cd5e1>):

<https://wiki.mozilla.org/Audio_Data_API>

[http://chromium.googlecode.com/svn/trunk/samples/audio/speci...](http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html)

Real-time audiosynthesis is coming, but it will take a while to reach the level that Flash currently offers.

</comment><comment><USER3> Audio is always a tricky topic because things like timing are so much more sensitive then the standard render-centric run loop. Audio control tends to fall outside the event based models that work so well for GUIs.

<comment><USER4> Though it comes at the expense of CPU usage, running a GUI on a strictly-timed frame-synced loop makes interaction much, much smoother.

</comment></comment><comment><USER5> Soundmanager 2.0: <http://www.schillmania.com/projects/soundmanager2/>

</comment><comment><USER6> A much too long article which basically says two things: HTML5 audio doesn't allow raw access to the audio data (which could be used for sample generation, making a spectrum analyzer, etc.), and doesn't have the fine control over timing that a game developer might hope for.

<comment><USER7> I said it shorter in tweets (@cromwellian), but the Microsoft IE9 guy didn't get it, hence the rant. It turns out, many people do not understand the timing issues as you might think. The Microsoft guy seems to think you can string together serial audio using Javascript's setInterval() despite non-determinism sources from Garbage Collection, browser style recalculation/layout, and other event-loop events interfering.</comment></comment>


Ask HN: should you bug or spam users who don't end up using your app? - <AUTHOR>

I signed up for an app just to check out their tool and interface. I didn't really get what their app does initially. After checking out, I realize that I have no use for it, but the founder sent me two emails straight asking for feedback.<p>Do you do that? Isn't that kind of spam? What's your thoughts? Isn't no-reply an answer on its own? <comment><USER2> Feedback is extremely important, even negative/dissatisifed feedback, so if you agreed to be contacted, then you should expect to be contacted.

Spamming people? (i.e. without consent) No, never. It just makes people angry.

On the other hand, if people agree to receive messages from you, then by all means, contacting them can be mutually beneficial. For example, you said you "didn't get" their app initially, but there's a chance it does exactly what you need but they failed to communicate that to you. Figuring out where they failed, and figuring out what you want (so they can provide it), is beneficial to both.

If you're curious, you should read just about everything from Patrick McKenzie (hn:patio11) on his blog: <http://www.kalzumeus.com>

<comment><AUTHOR> Thanks! Great comment!</comment></comment>


Pit of despair - <AUTHOR> http://en.wikipedia.org/wiki/Pit_of_despair

<comment><USER2> This reminds me of a bit of painful personal history.

When moving back from Canada to the Netherlands we took our dogs that we had acquired while in Canada back with us. Sarah, a three year old Irish wolfhound and Lisa, a 2 year old labrador / husky mix.

They went by plane, in crates specifically designed for the purpose.

On arrival the wolfhound had completely lost it, didn't recognize any of us and was totally out of it for at least two weeks, after which she slowly recovered. That was just 8 hours in a crate, not even close to the 'pit of despair' shown in the article, and anybody that willfully places an animal in such conditions just to see what damage will occur ought to be shot.

If I had had any idea something like that could have happened I would have gladly taken a boat with her, no matter how much longer that would have taken. It was incredibly sad to see her in that state, eventually she completely recovered though.

The other dog didn't show anything strange at all and took the whole thing in stride.

<comment><USER3> > anybody that willfully places an animal in such conditions just to see what > damage will occur ought to be shot

Are you talking about sadism or scientific curiosity? I detest the former but I'm comfortable with the latter.

<comment><USER4> Not to sound pedantic but you do realize that those two qualities are not necessarily mutually exclusive in people right? If we condone such cruelty to other living beings in the name of scientific curiosity, there is no limit to it. It's not ok to go around torturing others because one is 'scientifically curious'.

<comment><USER3> Our society is built on the backs of the less fortunate. We live in a country we've taken from weaker humans, we feed animals in factories until we're ready to kill them because it's cheaper than treating them humanely. We get our energy from coal mines where hundreds of thousands of workers have died and we stand by as genocides and famines wipe out entire regions. We buy products made by children who work all day every day in factories.

Given the circumstances, cruel experiments on animals (or even humans) to speed up scientific progress (and therefore welfare) looks like a really good deal to me.

Victims of science are just another statistic.

<comment><USER5> Well, then I hope for you you never become a statistic!

</comment></comment></comment></comment></comment><comment><USER6> A warning for those of a sensitive nature, that's some disturbing reading about animal experiments, mostly psychological torture of young primates.

<comment><USER7> Shit, it's making me depressed just _reading_ about it.

<comment><USER8> Same here. And I was expecting some levity (I thought it might be a Princess Bride reference).

<http://www.youtube.com/watch?v=z05StkAKKF0>

</comment></comment></comment><comment><USER9> This ... words fail me. I'm not against reasonable experimentation in animals (for drug research and related) but this seems just like some sick psycho's idea of research. The article says the experiments were controversial but check out Harlow's biography, he got two awards _after_ conducting these experiments. My view of psychiatry (clueless people trying random drugs to cure things they don't fully understand) has sunk to a new low. To me this is no different than Mengele's experiments. Do we take pity on _him_ because he was depressed.

Jeez, this article ruined a perfectly good morning for me.

</comment><comment><USER10> It really sounds like Harry Harlow was a sociopath (<http://en.wikipedia.org/wiki/Psychopathy>). I know a handful of academic science-types (some of which do experiments with animals) and I can't imagine any of them condoning so cruel a study. Ugh.

</comment><comment><USER11> That is unbelievable. The scientist in question exhibited a profound lack of empathy; he probably would have been an interesting subject for experimentation himself.

</comment><comment><USER12> What incredibly creepy experiments. Makes you glad we have ethics committees these days.

<comment><USER13> It doesn't make me glad. I think we could achieve much more significant progress in science if we weren't held back by ethical demagoguery.

<comment><USER14> Luckily for you, many PIs in the research field agree with you and have lax morals when it comes to torturing innocent defenseless animals. Compliance is a joke and doing whatever the hell you want to whatever creature you want (humans included, mind you) is as easy as checking a box on a piece of paper that nobody reads.

Our species is a virus, and we do whatever we can to protect our own kind until there is nothing else left.

</comment></comment></comment><comment><USER15> "Much of Harlow's scientific career was spent studying maternal bonding, what he described as the "nature of love"."

Apparently he was not very successful with his research - did he try to research that because he had no feelings to begin with?

Probably horrors like that and worse happen every day in a lot of research institutions. Some of the research is probably important and interesting. Still I have a hard time imagining how anybody can come up with and conduct such experiments.

<comment><USER12> From the article itself:

 _In 1971, Harlow's wife died of cancer and he began to suffer from depression. He submitted to electro-shock treatment and returned to work but, as Lauren Slater writes, his colleagues noticed a difference in his demeanor. [6] He abandoned his research into maternal attachment and developed an interest in isolation and depression._

His wife died, he got depressed and switched to the unpleasant experiments described in the article.

<comment><USER16> Wow. Yes, it seems like an awful lot of psychologists are in the field because they're trying to understand their own problems. This, ladies and gentlemen, is why you should never date a psychology student.

<comment><USER17> My psychology lecturer at the university told exactly that: many of those choosing psychology to study do that in hope to solve their problems.

</comment></comment></comment></comment><comment><USER18> Unlike other commenters I actually do see some useful results from this study. At what cost though? I can understand the argument for animal testing but something seems just that little extra bit off; when you're trying to study depression you end up having to inflict emotional pain, which is as literally torture as you can get. I've seen enough of the Internet not to be shocked often but this managed.

</comment><comment><USER19> I have long held that the worst way to die (IMO) would be to fall down a tube of gradually decreasing width, head first of course. It's appalling that someone actually did this to animals.

Why didn't he just setup experiments where he forced monkeys through a fine mesh screen to prove that their psychological disposition is less than satisfactory when their physical state is reduced to a puddle of goo. Lots of great science to unearth there.

Of course, like mice, perhaps he just hated monkeys for the sake of it: [http://www.theonion.com/articles/worlds-scientists-admit- the...](http://www.theonion.com/articles/worlds-scientists-admit-they-just- dont-like-mice,1256/)

<comment><USER20> Oddly enough, your first sentence describes human birth.

</comment></comment><comment><AUTHOR> The interesting thing for me was the effects, not the ethics of the research itself. It is interesting that the torturous aspects of this were primarily mental not physical and still disgust people. Contrast with <http://en.wikipedia.org/wiki/Unnecessary_Fuss> (linked from that article) and you'll get what I consider a true idea of torture. That is not to say there aren't ethical concerns etc., but most of the horrible actions were committed by the monkeys themselves and were presumably unexpected, in contrast with something like in Unnecessary Fuss where there was intentional infliction of harm.

</comment><comment><USER21> So is the internet a new age "pit of despair"? Is there enough social interaction for children these days or do they replace it with WOW and other "almost" social situations?

<comment><USER12> I'm not sure that those two situations are in any way comparable.

<comment><USER22> Actually the point was that lack of direct social contact leads to depression. Interacting with people though a digital interface also probably leads to a similar, albeit not drastic, of an effect.

Personally, even though I have access to more people and more information over the net, I am less social and that does have an effect on my mood. I have to make an effort to spend face-to-face time with family and friends to become "normal" again. (By "normal" here I just mean "not depressed"). Digital interface just doesn't cut it, there is some physical aspect to the interaction that cannot be transmitted even through a video conference. Anyway, I don't have anything to support this, just a personal opinion.

</comment></comment></comment><comment><USER23> Torturing monkeys to prove points about depression?

Depression sucks, and the worst versions of it could certainly be compared to torture in terms of the misery inflicted on the suffer, but I find it questionable that one could link externally-inflicted torture and depression in such a way that these experiments would have any value.</comment>


You don't need to put tape on your webcam - <AUTHOR> https://medium.com/@billychasen/you-dont-need-to-put-tape-on-your-webcam-b137e39edaa5#.6pagrdabf <comment><USER2> Do you work for the NSA?</comment>


Show HN: Spider - Easy-to-use web scraping tool, requires zero configuration - <AUTHOR> https://spider.amie-chen.com/ <comment><USER2> wow really cool, unfortunately i need chrome :( but very nice work!</comment>


Let's Encrypt's New Root and Intermediate Certificates - <AUTHOR> https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html <comment><AUTHOR> TL; DR:

> _For starters, we've issued two new 2048-bit RSA intermediates which we're > calling R3 and R4. These are both issued by ISRG Root X1, and have 5-year > lifetimes. They will also be cross-signed by IdenTrust. They're basically > direct replacements for our current X3 and X4, which are expiring in a year. > We expect to switch our primary issuance pipeline to use R3 later this year, > which won't have any real effect on issuance or renewal._

> _The other new certificates are more interesting. First up, we have the new > ISRG Root X2, which has an ECDSA P-384 key instead of RSA, and is valid > until 2040. Issued from that, we have two new intermediates, E1 and E2, > which are both also ECDSA and are valid for 5 years._

> _Notably, these ECDSA intermediates are not cross-signed by IdenTrust's DST > Root CA X3. Instead, the ISRG Root X2 itself is cross-signed by our existing > ISRG Root X1. An astute observer might also notice that we have not issued > an OCSP Signing Certificate from ISRG Root X2._

So:

* new intermediates R3/4, co-signed by current-X1 and IdentTrust; go-live soon

* new EC X2 root, signed only by current-X1

* new EC intermediates E1/2, signed only by new-X2</comment>


A Windows Defender bug was so gaping its PoC exploit had to be encrypted - <AUTHOR> https://arstechnica.com/security/2017/06/latest-high-severity-flaw-in-windows-defender-highlights-the-dark-side-of-av/ <comment><USER2> A comment on this article mentions a tool called "loadlibrary" used to discover this bug: [https://github.com/taviso/loadlibrary](https://github.com/taviso/loadlibrary). It allows fuzzing of Windows DLL files on Linux.

</comment><comment><USER3> Recently I approached a software project with the idea that I'd like to employ a fuzzer later when possible. What I found particularly interesting is that as soon as I had this idea in my head, my mind would constantly think of the code in a defensive "I-need-to-account-for-any-input" way.

Not just thinking about making the code work in the desired way, but also that any other input is walled of.

I think fuzzers are something that should get more attention, because it doesn't just help find critical bugs, it also changes your mind-set to defensive programming.

<comment><USER4> I went to a computer camp as a child and my first project was a number guessing game where the computer would pick a random number and then tell you hotter and colder as you guessed numbers.

I passed it to a friend to show off my work, and the first number he entered was "a", crashing the program immediately. Defending against rogue inputs was literally the first thing I ever learned about writing safe code.

<comment><USER5> That's my favorite software engineering joke:

A tester walks into a bar and orders a beer...

And orders 2147483648 beers...

And orders 0 beers...

And orders -1 beers...

And orders "banana" beers...

EDIT: I just thought, you might actually get a Bananenheizen if you order the last one in Germany...

</comment></comment></comment><comment><USER6> > Asked if Microsoft had previously fuzzed the Windows Defender component, a > company representative said yes.

> "Fuzzing is one of a number of techniques we employ to update and strengthen > our software," the representative said in an e-mail. "It is a standard > practice we use as part of the Security Development Lifecyle for our > products."

This journalist is naive. This answer says "sure we use fuzzing, but we have no idea if this particular bit of code was fuzzed." When you ask a binary question and a binary answer isn't provided, someone is usually trying to obfuscate the fact that they're on the wrong side of the binary.

<comment><USER7> That's awfully cynical. The answer they got is more indicative of the fact that they're talking to a representative rather than one of the engineers who would have actually been responsible for fuzzing it, so all the representative can really do is say what the policy is rather than answer the specific question of "was this particular component fuzzed"?

<comment><USER6> A good PR representative doesn't want to get caught flat-footed, and usually gets all the information they need from inside sources so that they can bullshit properly without (accidentally) misleading the public and causing the company legal trouble. Microsoft can afford good PR staff. If they didn't say yes, than the answer is probably no.

</comment></comment></comment><comment><USER8> > This full system x86 emulator runs as SYSTEM, is unsandboxed, is enabled by > default and remotely accessible to attackers.

Can anyone more familiar with these issues tell me why Microsoft is still running this stuff as SYSTEM? Seeing as Tavis has been poking holes in the same component for a couple of months now, I assume it's a design choice and there has to be some good reason for it. Right?

<comment><USER9> Are you asking about Defender itself or the emulation component? I'd think that Defender does need the higher privilege level for obvious reasons, though conceivably the more "risky" emulation could be done in a separate process with reduced privileges. It would be a pretty big undertaking though; just consider e.g. DoS on a multi-user system by attacking the process with dropped privileges. Not saying it's infeasible, but I think it would be complex.

<comment><USER10> > by attacking the process with dropped privileges

In what way is this not strictly better for the defender than if that same process was running as SYSTEM?

I don't think limiting the capabilities of a child process (even by running it as "SYSTEM_LITE") impacts its scheduling priority, security settings, etc. It would depend on the policy around the process.

<comment><USER9> > In what way is this not strictly better for the defender than if that same > process was running as SYSTEM?

You need to make sure there are no holes in the IPC. Like I said, it's presumably not infeasible, but it would have to be done _right_.

<comment><USER10> Why are there more likely to be holes in that IPC than the SYSTEM one?

Why are those holes more dangerous than having the entire thing happen in SYSTEM land?

Naturally, there's a danger that it's not bullet-proof and will lead to escalations/escapes. However, how is the _risk_ of that not a strict improvement over the situation where it's running as SYSTEM and doesn't even need to bother with that?

It sounds like it's strictly harder to weaponize faults in the component if they need to find a secondary problem in IPC encapsulation over just running code as SYSTEM as soon as they compromise the component.

</comment></comment></comment></comment></comment><comment><USER11> Somehow you gotta give it to security researchers for slowly pushing the industry towards formally verified software. How long it is taking to even notice any change at all is a testament to how awkward (or at least peoples conception of how difficult) it must be to write formally verified software with current methods.

<comment><USER12> Or a testament to how little the industry actually cares about security once you ask them to actually put their money on the line.

Windows Defender was new in windows 10; there is no conceivable justification for using the kind of programming language that leads to this kind of vulnerability. But, here we are.

<comment><USER13> Windows Defender has been around since Vista (XP, if you include systems it didn't ship with).

More important than that nitpick - do you really see no conceivable justification for using C++? _Really? None?_ The entire language is unsuitable for new development? And somehow, you captured this insight which managed to be overlooked by all the engineers working _at Microsoft?_

What do you suggest we do? Gather the whole world, hold hands as one and unite in abandoning the language? Cast it aside for...what, exactly?

<comment><USER12> > The entire language is unsuitable for new development?

Yes.

> And somehow, you captured this insight which managed to be overlooked by all > the engineers working at Microsoft?

Apparently. Astonishing that they didn't, but the fact that they managed to ship this bug is already astonishing, so any explanation of how that happened will also be astonishing.

> What do you suggest we do? Gather the whole world, hold hands as one and > unite in abandoning the language? Cast it aside for...what, exactly?

Mostly OCaml, probably - I guess F# in Microsoft's case. Maybe Rust or Ada in places where we absolutely need non-GC, if any of those turn out to actually exist.

<comment><USER14> There really aren't any codebases the size of Linux or Windows written in those languages. I'm not saying that there couldn't be, but there isn't currently. There is also a great deal of effort being put into making C++ more robust.

When there finally are large codebases written in Rust, it will be apparent that there are still some of the same issues.

I think that I agree with you though that there may not be real cases where GC won't work anymore.

</comment></comment></comment></comment></comment><comment><USER15> > At the same time, AV in many cases prevents infections that would otherwise > prove costly, particularly for less experienced users who aren't likely to > be individually targeted by state-sponsored hackers.

Is there evidence for this claim that is placed precariously at the end of an article full of detailed evidence for the exact opposite claim?

<comment><USER16> Well, most AVs just check icon + some data like sections, import table and only sometimes put some signatures on code. By using packer(not hard to find one) you can make almost any executable undetectable.

<comment><USER17> Which is why most av products will flag any upx or mpress binary as "Trojan unknown" etc.

They mostly use a whitelist approach to work around that. Ask me how I know sometime.

</comment></comment></comment><comment><USER14> AV is such as losing battle. Whitelisting, developer vetting, and code signing (the IOS store...I know you guys hate it) are the only things that have shown to be a reasonable defense.

</comment><comment><USER18> [http://www.cert.ssi.gouv.fr/site/CERTFR-2017-AVI-194/index.h...](http://www.cert.ssi.gouv.fr/site/CERTFR-2017-AVI-194/index.html)

</comment><comment><USER19> Also remember that on Windows 10, you cannot easily get rid of the insecure scanner. It will automatically reenable itself along with its insecure x86 emulator that runs as SYSTEM.

</comment><comment><USER20> Once again hats off, and thanks, to Project Zero.</comment>


Some Lisp books (2012) - <AUTHOR> http://blog.fogus.me/2012/07/25/some-lisp-books-and-then-some/ <comment><USER2> Two important newer Common Lisp books worth mentioning:

\- Common Lisp Recipes - [http://weitz.de/cl-recipes/](http://weitz.de/cl- recipes/) \- the de-facto go-to book on practical Common Lisp usage, for people with at least basic familiarity with the language.

\- Land of Lisp - [http://landoflisp.com/](http://landoflisp.com/) \- introduction to CL + overview of some more distinct aspects of other Lisps (often portable to CL as a library), teaching by means of writing small games; quite... peculiar.

Also, if someone wants to start with Common Lisp, then Practical Common Lisp (PCL) is usually _the_ book for it. The entire book is available on-line for free: [http://www.gigamonkeys.com/book/](http://www.gigamonkeys.com/book/).

</comment><comment><USER3> I'm not sure it should really count as a "Lisp book", but The Art of the Metaobject Protocol" is one of my favorite technical books ever.

It takes some knocks for not really containing anything about how to use CLOS. Instead, it's how CLOS is built. At a higher level, it's "how to build an object-oriented language/object system from scratch" using Lisp as a vehicle.

<comment><USER4> For how to use CLOS there is always Sonya Keene's book.

<comment><USER5> I think the Keene book should be avoided by all means. I don't think it is a good introduction into OOP or CLOS. My recommendation would be Peter Seibels Practical Common Lisp.

</comment></comment></comment><comment><USER6> Steve Losh's post on how to learn Common Lisp is an amazing resource. I encourage people to check it out!

It happens to include many of the books mentioned in the parent post.

Link: [http://stevelosh.com/blog/2018/08/a-road-to-common- lisp/](http://stevelosh.com/blog/2018/08/a-road-to-common-lisp/)

Accompanying HN discussion: [https://news.ycombinator.com/item?id=17852194](https://news.ycombinator.com/item?id=17852194)

</comment><comment><USER7> I always found "Lisp in small pieces" extremely heavy to read. It's not the content per se but I find the writing style baroque to say the least . I attempted to read it twice and never went further than the 2nd chapter. Am I the only one?

Instead I found PAIP the best introduction to Lisp for somebody that has already (plenty of ) experience with other languages. The introduction to the language is concise and smooth. I liked much only the chapters on the language though. The chapters on AI are too much outdated for me to find them entertaining even if the Lisp code is pedagogical for sure.

I didn't like OnLisp at all: the book wastes too much words on saying how much Lisp is great and the best thing in the universe rather than going straight to the point. I don't like this kind of style at all.

I found Practical Common Lisp too slow for my taste and would reccomend it only to a beginner.

For me the quickest way to learn Lisp for an experienced sw engineer is to start with PAIP reading only the first 4 chapters about the language and then to jump straight to a good reference guide such as "Common Lisp the Language, 2nd Edition"

Also I suggest anybody that is interested in CL to have at least a look at Julia. Since the relese of Revise.jl the interactivity of the REPL is second only to Smalltalk and CL but multithreading support is consistent amongst all platforms and the library ecosystem is already interesting. The language has a lot of momentum, is rapidly evolving and the community is small but helpful.

<comment><USER8> I agree entirely about Lisp in Small Pieces. It's one of those books that I've attempted to read many times and never get more than half way through.

</comment></comment><comment><USER9> I have been working through the examples and exercises in Paradigms of Artificial Intelligence Programming by Peter Norvig, the full text is available online, all code discussed in the book is LISP [https://github.com/norvig/paip-lisp](https://github.com/norvig/paip-lisp)

</comment><comment><USER10> The author on occasion also publishes a journal about " the Lisp family of programming languages and little-languages in general", which is worth a look.

[http://readevalprintlove.fogus.me/](http://readevalprintlove.fogus.me/)

</comment><comment><USER11> Don't forget CommonLisp Recipes by Edmund Weitz. Best Lisp book in years.

</comment><comment><USER12> You could also try the MIT SICP course with accompanying lecture notes, video lectures, exams, etc.

[https://ocw.mit.edu/courses/electrical-engineering-and- compu...](https://ocw.mit.edu/courses/electrical-engineering-and-computer- science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/)

<comment><USER13> I'd suggest instead taking Brian Harvey's lectures on same.

<comment><USER14> Could you share the URL for Brian Harvey's lecture.

<comment><USER6> [https://archive.org/details/ucberkeley-webcast- PL3E89002AA9B...](https://archive.org/details/ucberkeley-webcast- PL3E89002AA9B9879E)

</comment></comment></comment></comment><comment><USER15> There are some great books here. I can attest that Lisp in Small Pieces is _awesome_.

Odd that the link is to a footnote, though.

<comment><USER16> I can double on that.

Around the second chapter I was so amazed by the book that instead of reading it further I translated it into Russian, got the Professor's blessings, and to this day it warms my heart every time I see a new star on the repo.

It's definitely a good introductory _piece_ on Lisp history and its central ideas as well as on language runtimes and implementations.

</comment></comment><comment><USER17> Prior discussion: [https://news.ycombinator.com/item?id=4291570](https://news.ycombinator.com/item?id=4291570)

</comment><comment><USER18> Also, "The Joy of Clojure" is a great one!</comment>


Another non-argument in type systems - <AUTHOR> http://tratt.net/laurie/tech_articles/articles/another_non_argument_in_type_systems

<comment><USER2> I believe the example ("abc" + 123) given in the article is not 100% correct. Let's take C++ as a statically typed language and define a custom class MegaType. Then, in the whole program, we may use only variables of this single type. Any program can be trivially transformed to use just this single type. The piece of code would then look like MegaType("abc") + MegaType(123). When executed, it would behave exactly as a language with dynamic types. So, a dynamically typed language really is a specialization of statically typed language - you only need to define and use this one MegaType and implement all needed operators for this type (and they may of course work differently in runtime: "123" + 123 may result in 246 if you decide it should).

</comment><comment><USER3> > The following program (in pseudo-Python) shows a program which will fail to > type check in any sound static type system which I know of ...

I think (haven't checked) that the equivalent of that code will type just fine in Typed Scheme [1] and this kind of type system has been studied since the 70s as intersection types and have found a fair amount of application in type systems for compiler intermediate representations (because they fit well with optimisations involving type specialisation).

He's quite right to say that you can always find such untypeable examples for static type systems that are reasonable (esp. that they have an acceptable complexity for type inference).

[1]: <http://www.ccs.neu.edu/home/samth/typed-scheme/>

</comment><comment><USER4> Sure, having dynamic multityping allows one to express things that one cannot express in a dynamically unityped language. But I think the original point stands - a language with static multityping and dynamic multityping (not all staticly typed languages provide the latter, and they certainly don't all make it easy) is more expressive than one with static unityping and dynamic multityping.

<comment><AUTHOR> If you have a static type system and it's sound, it'll reject some programs that would execute without type errors, whereas a dynamically typed language will allow such programs to execute: it's what I called "dynamic expressivity". That's why saying "more expressive" without qualifying whether one is considering "static" or "dynamic" is problematic.

</comment></comment><comment><USER5> The concept of of a sum type is simple. It's just the type-theoretic notion of logical disjunction, how a particular language expresses that is sort of high- level implementation detail.

Java and its ilk _do_ have sum types: they're called abstract classes; the derived types are the variants.

In C# (and probably Java) you can easily define both open and closed sum types simply by marking the base class constructor as either `public` or `protected`.</comment>


Ask HN: How to prepare for a leadership role? - <AUTHOR> I'm currently evaluating a Head of and a VP role.
I know for a while that my next step is not going to be a purely tech role. Tech leadership has been part of my work for a while now and I've been taking more responsibilities in that direction and enjoy them a lot.
Going with Head of or VP role would be a new step for me. And last thing I'd want is to become an example of Peter principle.
So what does make a good Head of Engineering or VP of Technology in a software company? What are the lessons you've learned? And what books are mandatory read?
Any advice is highly appreciated. <comment><USER2> I'm not sure that this is exactly what you need, but I recommend "The Development Abstraction Layer" [http://www.joelonsoftware.com/articles/DevelopmentAbstractio...](http://www.joelonsoftware.com/articles/DevelopmentAbstraction.html)

<comment><AUTHOR> Another great one from Joel. Thanks, somehow I never read it before.

</comment></comment><comment><USER3> It seems like quite a big jump going from "tech leadership has been part of my work" (sounds like a lead developer role) to VP (all your direct reports are managers/directors). (In a tiny startup, maybe someone who manages developers might be given a VP title, but if the company grows, a VP will eventually end up managing managers.)

I'm not a VP, but I report to a VP of development, so I've observed them up close. The important skills for VPs seem to be:

\- People skills - most of their time is spent talking to other people (meetings and one-on-one conversations). They need to be able to communicate effectively with all types of non-technical people: executives, sales, marketing, product managment, customers, etc. - anyone who wants something from their development team.

\- Being able to envision the future path of the product. This involves more than knowing technology - you have to know the product you're building very well, and understand how users use it.

\- Understanding how the business works and what would make it successful.

\- Being able to deal with difficult decisions like laying people off when the company isn't doing so well.

<comment><AUTHOR> So what would be the lessons you've learned if I may ask that are you didn't know when you started your current position?

Things along the line of: it's better to make other person think they've come up with the idea so they are committed to it than to show off how intelligent I am.

<comment><USER3> Here are some things I learned:

\- No matter how busy you are, you should always make time to mentor your employees. Help them grow by delegating increasingly difficult work to them and giving them additional responsibilities. If you can't delegate to your employees with confidence, your own workload will eventually overwhelm you. Also, as your company grows, being able to promote existing employees instead of hiring from the outside means that you'll have managers who have a better understanding of your company's technology and business. (And if you want to be promoted in the company you currently work for, it's easier if you have someone who's ready to step into your current job.)

\- On the other hand, don't try to shield your employees from tedious or difficult tasks by doing them yourself. Some percentage of work is tedious or difficult, and it can be as much of a learning experience as more interesting work. Don't feel guilty about delegating this kind of work to others. It's part of the job.

\- Don't be friends with the people you manage - find friends outside of work or in other departments. (I don't mean that you should be unfriendly to them, but don't socialize with them or have deep personal conversations.) This might be a controversial opinion in work cultures where everyone in the office socializes with each other, but it makes it hard to make objective decisions about who should be promoted, who should be laid off, etc. At some point, you'll need to make these kinds of decisions, and they shouldn't be biased by the fact that some of your employees are your drinking buddies.

\- Learn how to manage your boss's expectations. Saying yes to every request will eventually lead to failure and burnout (of both you and your team). The end result will not be good for your company (projects failing, people quitting).

\- Pick your battles. Some fights are not worth the trouble it takes to win them.

<comment><AUTHOR> Thank you, great insights. I see already that 3rd point could be a tricky one for me personally...</comment></comment></comment></comment>


How To Become A Jedi Knight - <AUTHOR> https://www.linkedin.com/today/post/article/20140309152751-5858595-how-to-become-a-jedi-knight

<comment><USER2> Amazing how little you need to survive/thrive.

Also amazing how important our own beliefs/self-imposed limits impact our perception of the world . Neuro-linguistic progamming helps shed some light on this.

"Whether you think you can, or you think you can't --- you're right!"</comment>


Show HN: ViewDom.js, graphical tree view of rich html editors - <AUTHOR> https://natejenkins.ch/view-dom <comment><AUTHOR> Author here. I often find when working on rich editors that I want to see a graphical representation of the editor dom with the current selection and any hidden or hard-to-see characters. That's what ViewDom does. Unfortunately it still needs some work on mobile devices but I already find it useful.</comment>


Morgan Stanley's $9 Billion Check - <AUTHOR> http://www.andrewrosssorkin.com/?p=355

<comment><USER2> > "The payment was supposed to be wired electronically, but because it needed > to be made on an emergency basis on a holiday, Mitsubishi cut a physical > check"

So, on a holiday, the electronic systems were "closed", but the paper check could be deposited normally? Irony abounds.

<comment><USER3> But...

Paper checks don't actually move money around, computers changing numbers in electronic ledgers do. A paper check is just a device to trigger that process.

I'm not sure this story makes any sense to me.

<comment><USER4> The distinction is most probably legal. The transaction couldn't close until payment was received - and the paper check could be "received" but a wire transfer couldn't until the next day.

Likewise, they could put the funds on their balance sheet at the moment the check changed hands. I'm sure they also had accounts payable, so this allowed them to be solvent despite the fact that the check hadn't yet been deposited.

</comment></comment></comment><comment><USER5> Whatever you think about the rationale behind this check (I don't buy the story about electronic systems being down on a holiday either), I encourage you to read Rolling Stone's irreverent take[1] on Goldman Sach's role in this whole saga, as a valuable counterpoint to the fawning "all-nighter swinging dick" worship[2] as can be seen from the excerpt of this guy's book in Vanity Fair.

1\. [http://www.rollingstone.com/politics/story/29127316/the_grea...](http://www.rollingstone.com/politics/story/29127316/the_great_american_bubble_machine/print) 2\. [http://www.vanityfair.com/business/features/2009/11/too- big-...](http://www.vanityfair.com/business/features/2009/11/too-big-to-fail- excerpt-200911)

</comment><comment><USER6> Alternate Link:

[http://www.businessinsider.com/the-9-billion-check-to- rescue...](http://www.businessinsider.com/the-9-billion-check-to-rescued- morgan-stanley-2009-11)

</comment><comment><USER7> Interesting. Why was a Japanese bank willing to risk that much on a bank that made bad choices?

<comment><USER8> Japs are pretty heavily controlled by the American elite. There is actually a fairly big underground movement in Japan to throw them off and stop stuff like this from happening. Japanese banks and politicians though have been paying tribute to America for a long time.

<comment><USER9> references needed

<comment><USER8> It's a tough thing to reference. But I've read from many Japanese authors about the kind of reverence that Japan holds for America even today. It's almost a religious kind of awe, and so when American powerbrokers visit Japan there is a kind of unsaid understanding that the Japanese aristocrats will make concessions and "pay tribute". After WW2 all the current Mitsubishi Group banks very much became an international operation. And it holds tremendous power, and yet is extremely - almost inexplicably - conciliatory to America.

Some Japanese people are unhappy with this vassal kind of relationship between their most powerful institutions (which, let's face it, are the political Kingmakers of Japan just like the corporatocracy in America) and the Western Elite.</comment></comment></comment></comment>


The Computer Language Benchmarks Game - <AUTHOR> http://benchmarksgame.alioth.debian.org/

<comment><USER2> [http://shipilev.net/talks/jvmls- July2014-benchmarking.pdf](http://shipilev.net/talks/jvmls- July2014-benchmarking.pdf)

        Slide 6/75 Theory: Why would people benchmark?
        Slide 7/75 Theory: In the name of Holywar
        My favorite example: Computer Language Benchmarks Game

In the name of Teaching

Replace very-wrong ideas with less-wrong ideas.</comment>


How to Walk 100,000 Steps in One Day - <AUTHOR> https://betterhumans.coach.me/how-to-walk-100-000-steps-in-one-day-5087adbd4569 <comment><USER2> That's a lot of walking. Most I ever got was ~66K in a day and that was from running a 50K.</comment>


Show HN: BoilingSteam, My New Website Dedicated to Linux Gaming - <AUTHOR> http://boilingsteam.com/.

<comment><USER2> Really cool. Great layout and interesting articles. I'd post this on r/gaming and see if it gets some traction.

<comment><AUTHOR> Thanks for the support and the nice comments, appreciate it :)</comment></comment>