dwc

Reading this article I immediately saw a couple of drawbacks. Since then I've thought of a few more. But several of the points made were not lost on me. This article made me think a bit, and I'm still thinking about it. That's worth something right there.

To anyone out there who clicked through to these comments and is thinking it's not worth reading the article, please go ahead and read it. It's short enough. You may or may not use fewer if-statements in the future, but it might give you a better sense of why you choose to do things one way over another.

I'm from Arizona, but I love that NC vinegar sauce!

> Google ... are also at fault

Primarily at fault.

About 10 years ago I was in Italy. Stopped for a quick meal at a kiosk set up in the middle of the airport. The caprese sandwich I got was totally amazing. The flavors! From a kiosk in an airport! Such a simple thing but so, so good. The other meals I had over the week were also very good. There's something to be said for food purity laws: when you can't add all sorts of crap you have to focus on the quality of what you have, and it makes a huge difference.

In 2000 I spent a couple of weeks in the Shrewsbury area, and most lunches were had at small, out of the way village pubs. The food was surprisingly good, both traditional and continental. Not just surprisingly good for England, but for anywhere in such venues. The only bad experience was our first shot at getting fish & chips, which were rubbish. Second try at a different place fixed that.

I agree with you, but I also still agree with me:

Making Delphi or Common Lisp the next hotness is pretty much a lost cause, and has been for a long time. The people using those things tend to be heavily invested in them, and still making money. If you're not making enough money to spend US1.5K on your primary tool then you're not really making money.

Most of the people who balk at $1,500 will probably still pick the free option rather than pay $19.99.

Even though there are good free options (in the case of common lisp there are multiple good free options), there's still no gaining of traction.

So these companies charging money have defined their target market as people already using the language professionally, and they've found a price point that lets them stay in business and provide quality tooling (specialized IDEs, debuggers, GUI frameworks, et al). If they lowered their prices to $19.99, rather than attract loads of new mindshare they'd simply go out of business.

> Erlang generated a lot of buzz several years ago but aside from the recent success of WhatsApp it never quite stuck.

Erlang is quietly running a lot of stuff out there. It's almost certainly running some bits of infrastructure that you use daily, or in a supporting role for it. People who are not old Erlang hackers are picking it for new projects.

Erlang hasn't been and probably will never be quite mainstream, but to say it "hasn't stuck" might be missing the point: it's a mature and performant language that has some very nice standard features in OTP that are lacking or less mature in other languages. If your problem domain is smack in the middle of Erlang's strong points then it's worth considering. It's not going away any time soon.

Jeff wrote about Pascal quite a bit in his columns, as well as some books. He wrote about anything he found interesting, but Pascal was his weapon of choice for most things so he covered it pretty well over the years.

That depends. As long as I've been in the game there have been relatively expensive options. Back in the day I kept hearing about SmallTalk and I saw the price tag in an ad in Dr.Dobbs. Sticker shock! But "serious" pricing is still alive today. Check http://www.lispworks.com/buy/prices-1c.html for instance.

For some languages, lower prices won't significantly increases sales volume. And 1.5K is not a barrier if it's your bread and butter language. It's in the same ballpark as a developer machine.

Theories serve multiple purposes. A theory can be useful to make calculations about things you already know. Or to make predictions about things you don't yet know. String theory has been adapted over time to be able to calculate things we already know. But we already had that without string theory. But the predictive part is where string theory really falls down. It's track record there is abysmal.

On the other end of the predictive spectrum there's Einstein. Somebody fiddles with the equations and says, "if this is right then there could be black holes!" And then... they find black holes. It seems that every few years there's some confirmation of an odd corner case that shows the predictive power of Einstein's theories.

That string theory can calculate the known might still be useful, if it's a more convenient way to get the results than other theories. Plain old Newtonian physics is still hella useful today, for instance, even for space missions. AFAIK, string theory is not more convenient.

Take this with a grain of salt, because I haven't kept up on what string theory has been doing lately. As a matter of personal triage I stopped following it until such time as I heard that someone predicted something interesting with it, and it was confirmed in observation or experiment. If that happened then I missed it, and would love to hear about it.

Yeah, well, we did a lot of things our own way. We tried some things. Some of them stuck, some of them we adapted to suit us, and other things we dropped.

> The person typing should not be driving.

What's the reasoning behind this? My guess is that it's to prevent pair programming from turning into lone programming with an observer. If that's the case it wasn't a problem for our specific situation. No matter who had the keyboard, there was collaboration. Why separate the keyboard from the person who can fastest/best get the code on screen for consideration?

> Also, if you are not the person currently at the keyboard, you are not allowed to just take over. We used strict time boxes at first to make sure that this didn't happen

Why? Of course you shouldn't snatch the keyboard out of someone's hands, but such behavior should be addressed in other ways than by making rules. I suspect it's not that, but something else. Even so, I have to wonder if it's a social issue that would still be better addressed in other ways than by imposing rigid structure.

Anyway, switching when we wanted did not seem to pose any problems. If we missed out on some benefits then I'd like to know about them.

> I'm pretty sure this is against zoning.

Perhaps, but you might be surprised. Years ago I kept chickens and checked the zoning here (suburbs of Phoenix). No problem with a flock of hens. Roosters have restrictions. Many places are similar.

In my limited experience pair programming it usually went like, "How about if we combined these and frobbed before...aww, let me drive and I'll show you." Who had the keyboard might stay the same for hours, or might switch every 15 minutes, depending.

> In 2016 I would also heavily consider Java 8 for the same team usage vs when I started using Scala in 2011.

Out of curiosity, would Clojure be up for consideration? Why? Why not?

You're overthinking it a bit. What it does it remove the worry that you're going to starve or have no place to live, or take you from subsistence to a level that you can invest in the future. That's all. Perhaps that's enough.

Whether this "solves" anything depends. Initial experiments are very limited, but fairly positive. Giving money to people in rural India may not translate too well to giving money to people in New Delhi, much less people in Cleveland. But I think it's worth a try to see how things work out.

> I'm not so sure building a robot capable of killing toddlers 'does something for the USA' - at least not anything positive.

I think that's the point. Rather than building a kick ass military bot, they'd be building a lame domestic servant. People who thought they'd be doing the former may not find satisfaction in the latter.

You can see M42 with just binoculars!

I could get NGC 7635 in my meade LX90 from my light polluted suburban backyard.

Really dunno where this moon and planets only thing comes from.

1) Spot on. If you won't bother to learn at least a few prominent bits of the sky first then a telescope will be fun about twice and then gather dust.

2) Subscribe? Er, see if you can buy individual copies first. I dropped my subs because, well, the articles all started to become pablum. Probably worth picking up a few issues when you start out.

3) Yes, join a club or tag along. There's no better way to get an idea of what it's about than to meet some enthusiasts and look through their scopes. And a really friendly and helpful crowd, in my experience.

Binocs: I bought 10x50s, and I wish I had bought 7x50s. The higher magnification is nice and all, and I can hold them steady enough...for a little bit. You can use 7x50 without strain for a lot longer. Also, yes, do buy binocs. You'd be amazed what you can see with a pair of 7x50s that you can't see with naked eyes. It's a great, cheap, convenient way to get started.

Telescopes: buy one that you can afford and that you will use. Like my binoc choice above, I bought something actually nice but big enough that it was a pain to haul around and set up. Save that for later. Buy something that you will pull out on a whim and have a nice evening. This is a very individual choice, of course. If you live in a fairly dark place and the farthest you will take your scope is to your back yard, by all means get that light bucket. :)

Overall very solid advice in the article.

There's a better way.

    (/ 2 3)   ; => 2/3
    (/ 2.0 3) ; => 0.6666667

Ok, for those cases I have to agree with you. :)

(Lack of) discussion here yesterday: https://news.ycombinator.com/item?id=11691086

I have mixed feelings. For a return value, retval et al are completely appropriate. Same for count. Tmp/temp borrow meaning from whatever they are a temporary for. These are all fine.

But "value" is horrible. You really don't know what it is? You might as well name it "variable". "Str" is in the same boat, unless it's short for "tmpstr".

> I'm just getting started on setting up an OpenBSD router that I want to be the basis for making sure much of my data is secure.

A bit of warning... I've seen this go wrong when people who don't know OpenBSD do this. Adding an additional OS means learning and "supporting" it.

* If learn your way around, get it set up well, keep your system updated the way you do for anything else, then you'll be in good shape.

* If you learn just enough to get it working and then set it on the back burner for when you can find the time to learn more, don't update it, etc., then you're better off going with an OS that you know and can keep secure.

I'm not trying to dissuade you, but I'd like you to evaluate if you will devote the time to using a new OS on a border device that it deserves. If you will then I think you'll be quite happy with your choice. :)

I would call it a fluke.

Two things to keep in mind:

* Don't compare JAXA (or anyone else) to NASA at this point. We (the US) have a ton of experience, some of it bought the hard way.

* This isn't Japan's typical performance. They have a nice string of very good space science missions. And don't forget things like the Mars Climate Orbiter[1], where ground based commands sent it through the atmosphere due to a unit mix up.

1. https://en.wikipedia.org/wiki/Mars_Climate_Orbiter

This is the key passage:

    The spacecraft then automatically switched into a safe
    mode and, at about 4:10 a.m., fired thrusters to try to
    stop the rotation. But because the wrong command had
    been uploaded, the firing caused the spacecraft to
    accelerate further. (The improper command had been
    uploaded to the satellite weeks earlier without proper
    testing; JAXA says that it is investigating what
    happened.)

Going into safe mode is a thing. It happens with NASA stuff, ESA stuff, whatever. The spacecraft failed to stabilize and went into safe mode, and that's proper. Whatever glitch in the systems, this would have saved it and allowed for recovery.

But the uploaded command to shed rotational velocity was wrong. This is what caused the loss of the spacecraft. I'm sure there will be a pretty heavy postmortem on how this happened.

There are too many projects of any name (most never see the light of day), but somehow all these Krakens get released.

I'm as bad at those kind of picks as the next person. I wasted time and money figuring that out, though.

The only time I buy in is when the market overreacts to some bit of bad news or something and I see the undervaluation. Of a strong, established company.

Agreed, with one exception: when you as an individual have fairly deep knowledge about something and spot a market opportunity based on that knowledge, you might be able to correctly judge whether you can take advantage of it.

I've done this several times and made good money. Two times I approximately doubled my money over the course of several months. Yeah, not day trading but buying and waiting for the market to figure out what I already knew. The thing about that is, it only happens when it happens. Most of the time my money is sitting in index funds quietly getting solid but undramatic returns, and I don't have to pay much attention at all.

IIRC, Card wrote Ender's Game in high school and later dusted it off, fixed it up, and published it.

> Some of those systems come from vendors who have very competent teams and invest heavily in their systems, and some have tried fancy, expensive JVMs with supposedly better real-time performance and have failed to get them to work.

This is very important. There's far too much No True Scotsman in typical discussions around this. The fact remains that really good teams try and fail to meet needed performance criteria, even though their app/service meets all other requirements, is well architected, well coded, and the team has experience in GC tuning, pitfalls, etc.

> Maybe it can be done, but that doesn't mean that you're going to be able to do it, especially if you don't design all parts of your application from the beginning to operate within the constraints of real-time GC implementations.

Because... unless your solution is one where you can simply avoid doing a few stupid things that make the GC unhappy, you have to wade deep into managing memory, except you can't do it directly. You have to understand/infer how seemingly innocent code impacts GC, and then suggest/cajole/plead with the GC to do what you want. It required the kind of intimate knowledge that GC is supposed to save you from, but doesn't have the direct manipulation tools.

There are large classes of problems where GC is perfectly fine. Great even. But there are other problem domains where sluggishness or pauses are not acceptable, and not just realtime or soft realtime.