lambda

Really? I haven't heard of any bugs in the command line calculators. Do you know what kinds of bugs they were talking about? One thing to note is that they use arbitrary-precision decimal arithmetic (well, base-100 arithmetic internally, but that's equivalent), rather than fixed precision binary floating point arithmetic, so that may surprise some people (though it also reduces surprise for those who expect decimal arithmetic).

Interesting tidbit, it seems that dc is the oldest language on Unix; it was ported before even an assembler was. (https://en.wikipedia.org/wiki/Dc_%28computer_program%29#Hist...)

I'm not familiar with the fraction button. Is this common on calculators? I don't see it on most of the basic function calculators that I look at. Hmm, taking a look around, it looks like it might be present on a lot of scientific calculators, but not the basic calculators I see. I had switched to RPN by the time I started using scientific calculators, so I guess I never became familiar with this button.

Parentheses are common on scientific caclulators and graphing calculators, but as you demonstrate, they add a lot of extra button presses, and you even left out the final "=".

To do this on an RPN calculator, you need nothing beyond the basic 4 functions and the enter key, while you need extra specialized keys like parens or a fraction button to do it on an infix calculator. Taking a look at various infix scientific calculators, they mostly seem to have both parens and a fraction key, so using up the space of 3 keys that an RPN calculator doesn't need and can use for more actual functionality.

Here's how you do it on RPN:

3 <enter> 4 + 5 <enter> 6 + / 7 <enter> 8 + 9 <enter> 2 + / +

You wrote it in Polish notation rather than Reverse Polish Notation, and had left out the enter key that is used as the delimiter between two numbers (pushes a number to the stack, so you can start entering the next number).

I generally just use dc on the command line. Pretty bare bones, but gets the job done.

M-x calc in Emacs is a very full-featured RPN calculator.

On Android, I use Droid48, a great HP48 emulator: https://play.google.com/store/apps/details?id=org.ab.x48 ; I also have RealCalc (https://play.google.com/store/apps/details?id=uk.co.nickfine...) installed, which I figured I'd use more due to the bigger buttons by default, but I still reach for Droid48 most often.

Hmm. This seems to focus on a few issues that neatly fall into a sense of "progress" in social change, in which something changes in a number of states culminating in a Supreme Court decision that causes that change to affect the entire country.

However, it ignores some issues that don't fall into such a pattern. For example, the issue of teaching evolution vs. creation in public schools; where teaching about evolution has never been questioned (as far as I know) in some states, while others have had laws on the books, and there is continuing pressure and laws that offer limited "workarounds" of the supreme court decision in order to promote "teaching the controversy", so it's not really a clear cut case of progress.

Another that isn't covered is capital punishment; some states have never had capital punishment, some have repealed it over the years, and the Supreme Court briefly suspended it nationwide but it was reinstated later, and many states still practice it.

Abortion, which is used as an example in this article, faces a similar problems as teaching of evolution. While abortion was allowed nationwide by Roe v. Wade, states are slowly introducing laws that restrict it so heavily that it's not available to a large fraction of people who need it. The turning point nationwide is being slowly turned back by laws that skirt the existing precedent.

It seems like picking these couple of issues, to show how "it may happen again", is a bit disingenuous without also covering major cases in which change hasn't followed this pattern, or has backslid since the original change.

Oh, I know why it keeps on happening, but it leads to a frustrating and fragmented experience. That's why it would be nice to have a common core package manager, that handles all of the tasks that any package manager will need to handle (metadata, versions, dependencies, dependency resolution, conflicts, features, fetching packages, verifying packages, managing an archive of packages, etc), plus the ability to hook in at appropriate places to provide the distro or language specific hooks necessary, and the ability to have cross-archive dependencies (including union dependencies like "either these three Debian packages, these two Fedora packages, or this Homebrew package"). That would then let you focus on solving the common problems in one place, and leave each language or distro to only have to focus on its own particular glue and policies.

The pattern is generally that Clang and GCC will have partial support when the standard is release, and full support a couple of years later. Intel will lag behind a year or two after that. Microsoft will be behind another year or two.

So, let's say that C++17 does come out in 2017. It will probably be the case that some of the features will be ready to use in GCC and Clang right away, and around 2019 or so they should have full or nearly full support. 2021 for Intel. 2023 for Microsoft.

So that gives you a range of answers. Depending on which features and which compiler, you could start using some of them immediately (or even before 2017, many of the features are implemented experimentally in advance), but if you want full support across the range of commonly used compilers, you're probably going to be waiting until the early to mid 2020s.

It's frustrating having the proliferation of different package managers.

Each one can work well in isolation; but when you then need to integrate with your platform package manager or another language's package manager, you get a combinatorial explosion of possible interactions.

One example that I've been particularly frustrated by recently is Python/Emacs integration. I have Emacs and Python installed via my system package manager (apt). Then there are a bunch of Emacs modes that I need to install via the Emacs package manager (elpy and its dependencies). Those in turn have dependencies on Python packages (rope/flake8). And finally I have a bunch of different python packages that I work on that are all linked to from a virtualenv so that they'll all resolve properly in all of those tools.

If I upgrade one part of that system (apt, emacs packages, python packages), it frequently breaks other parts, because there aren't any proper dependencies between them. I then have to spend a while fiddling with the whole setup to get it back up and running again.

Basically, the more package managers you have, the less value they have. The whole point of package managers is to manage a whole set of packages together, so you don't have to manually go through and resolve all of the dependencies yourself, manually figure out which version of this package goes with what version of that package. But every time there is some dependency between two different package managers, that breaks down.

Another part of the frustration is that they are all basically doing the same thing, but with slightly different implementations. In the end, a package manager's purpose is to let you figure out which packages you need, by resolving dependencies while honoring version constraints, fetch those packages from an archive somewhere (and verify that they are intact and haven't been tampered with), unpack them and install the files in the right places, and run some glue code to set up indexes, documentation, and so on appropriately. The only part of that task which really needs to differ between package managers is that glue code, plus the policies for inclusion in the centralized archive; everything else is basically solving the same problem in a whole bunch of slightly different ways (different ways of representing and comparing version numbers, different ways of verifying package integrity, different ways of doing local mirrors, etc), and so you get a whole bunch of incompatible and differently buggy implementations of the same kinds of things, or some functionality just missing from certain package managers.

What I would really like to see is a single unified package manager core, that handles all of the basic functionality that they all set out to solve, with the ability to utilize multiple different repositories (so that different projects could have their own policies for inclusion and sets of packages that are designed to work together), and appropriate places to hook in all of the language (or distro) specific glue that you need. I've been mulling over trying to write such a package manager, but of course when doing so you need to be careful or you will run into this problem: https://xkcd.com/927/

It looks more schizophrenic than bot to me.

1000 times this.

If you really don't care about the license, just use MIT. It has the best combination of simplicity, compatibility with every other license, and it's already known and used in just about every collection of any sizeable amount of free or proprietary software.

Trying to go even further by using a weird, probably not legally enforceable declaration like this one, or other oddball things like public domain dedications, the Unlicense, the WTFPL, or CC0 is just likely to lead to more confusion, more problems with legal ambiguities in different jurisdictions, simply more time spent reading and evaluating the licenses to make sure there's nothing hidden or that it does have legal meaning in your jurisdiction, etc.

Yes, there are a few prominent examples of public domain dedication that are widely used, like SQLite. They make it work out by actually having all contributors sign an affidavit, and additionally charging a fee for people who really do want or need a license rather than the public domain dedication. Thus, being public domain is actually more work and more friction for the project than if everyone just licensed their contributions under a permissive license like MIT.

> Some scholars really grok grammar, and are excellent at teaching it, yet they haven't written great novels. I'm thinking of William Strunk Jr (of "The Elements of Style" fame), for example.

Not sure that Strunk, or the successor Strunk and White, are good examples here; they didn't "really grok grammar", in fact, they were pretty bad at both understanding it and teaching it, and their advice consists of a lot of incorrect information and vague platitudes. E. B. White was actually a good writer, but much of his writing violates the prescriptions in The Elements of Style.

Geoff Pullum has a good rant on the subject, if you want more detail: https://chronicle.com/article/50-Years-of-Stupid-Grammar/254...

So, this is exactly why it's an interesting question to test if the suggestions in the "Effective C++" series are actually good suggestions, or are just someone expounding rules that sound good in theory but don't actually help in practice.

So, where is the evidence that it is a handy first approximation? That is, that it makes any kind of testable predictions? Even if they don't always hold, there should be some correlations with some kind of quantifiable metric. So what quantifiable metrics to these personality categories correlate with?

When Go was first announced in 2009, I thought "this is a nice idea, but I really wish it had generics and non-nullable references". Then Rust was announced a few months later, and I thought "wow, this is what Go should have been."

However, in the intervening time, Rust has diverged farther from Go. It no longer has green threads nor emphasizes message-passing based concurrency. In addition, Go was ready to use much sooner; by having a much simpler type system, and less ambitious concurrency story, Go has been ready to use and build up a library ecosystem for many years now, while Rust is only just now hitting stability to the point where you can write code and not have it break if you don't constantly keep it up to date with the latest nightly.

So, I think that they are both valid strategies. There has been lots of good code written in languages which don't provide as many safety guarantees or as strong a type system as Rust has; it's not an absolute requirement for all code to be written with such guarantees.

By staying simpler and not trying to solve as many problems, Go has been ready for production use for quite a lot longer, and I think that there are many things for which it is still simpler and easier to use.

That said, I do prefer Rust now that it's actually hitting a stable and usable state. I wish it had been ready sooner, but that's the price you pay for needing a lot of time on iterating on how to make these stricter semantics actually usable in practice.

It is actually linked to from the front page of http://www.rust-lang.org/; it's the "more examples" link under the example. But I guess that's just far enough down to be easy to miss; it's just below the fold on my screen.

In part because the "cottage industry" for photographers rights is based on getting people to pay, while most free software authors aren't actually interested in being paid for it, they are just interested in keeping it free. When the focus is on getting paid, a cottage industry can form that is based off the revenue from extracting royalties, but getting injunctions that apply until someone comes in compliance with a license is expensive due to lawyers fees and court costs, without any revenue to offset it.

Because the failure conditions are worse.

Let's see, here are the possibilities:

1. Someone means well, you interpret it as them meaning well and respond accordingly. Everything is fine and dandy, everyone's happy. 2. Someone means well, and you interpret them as meaning ill, and respond accordingly. Now you are angry for no reason, they have had the experience of making a well meaning comment and being shot down for it. Everyone is miserable. 3. Someone means ill, and you interpret it as them meaning ill, and respond accordingly. Now they have gotten the thrill of getting through to you (remember, they mean ill, so that is their intent), and you are angry (for a good reason). You've made yourself miserable and a troll happy. 4. Someone means ill, and you interpret it as them meaning well and respond accordingly. Now they don't get the pleasure of having bothered you, you have shrugged it off an it's not great loss to you. You are now happier than option 3, and they haven't had a chance to hurt you like they meant to.

Of course, real life isn't quite a simple as that; but that does cover a very large number of possible interactions on the internet. By biasing yourself toward the most charitable interpretation of others comments, you reduce the risk of a simple misunderstanding leading to everyone being unhappy, reduce the risk of just giving a troll exactly what they want, and contribute to a more positive environment in general.

It really does help out in an awful lot of cases, and reduces friction dramatically if you always assume good faith unless you have very compelling evidence to the contrary.

Or choose free software. If it's free software, even if the original developer goes away, you can hire someone to keep working on it, or someone else can decide to make a business supporting it, or the like.

I'm using Firefox on a Retina MacBook Pro, and I get low-DPI rendering; Chrome also does low-DPI rendering, but with better anti-aliasing. The text rendering looks even worse on Safari; it doesn't even appear to do proper hinting, so the widths of characters come out all uneven, though oddly it seems to antialias the largest text, your name, but not any of the rest of the text.

From worst to best, Safari appears to have inconsistent antialiasing and no hinting, Firefox has no antialiasing, while Chrome looks the best with antialiasing. They all look fairly blurry and out of place.

It's not searchable.

I can't copy and paste text off of it.

It's not accessible; screen readers can't read anything off of it.

It renders at half the DPI of my screen.

At some point, I wound up on a blank screen with no way to go forward or backward to anything but the "create a free website" banner. Haven't reproduced that to give you repro steps, but it happened.

It was frequently janky on my machine; animations would hang occasionally.

It doesn't work at all on my mobile browser (Firefox); I just get a white screen with the banner at the bottom (it did work on Chrome, but the "Back" button was frequently hard to hit).

All of this could be done by animating actual HTML content using JavaScript or CSS animations, in a way that would degrade gracefully for people who couldn't use those for some reason, and which would render at the full DPI of my screen, be copy/pastable, searchable, accessible, and so on.

By the way, the editor on makemake.io is fairly impressive. But it seems like it would be more appropriate for it to edit HTML with JavaScript or CSS animations, or SVG, rather than a custom rendering engine using Canvas.

If you are not producing any academic output, are not producing any commercial output, and are not even producing any patents, all you are producing is high-level handwavy talks, how do you distinguish that from a charlatan?

Ideas in a vacuum are not worth much. I have some random ideas for systems that I think would work better than current systems that people use all the time; stuff I would like to get to some time to develop into something real. However, without actually either rigorously formalizing those ideas and having them reviewed against the current literature, or producing a shipping implementation that demonstrates their feasibility empirically, they're pretty much worth the cost of the paper they are (not) written on.

  How does the data account for variation in development 
  procedures (e.g. some projects use master as their 
  bleeding edge branch)?

That shouldn't matter. You should always be able to successfully check out, build, and pass all tests on master. Otherwise, how are people expected to get development done? If you aren't able to build and run tests because you need to be fixing something that someone else committed broken, it will be a lot harder to ever make real progress.

Even if it's "bleeding edge", master should always build and always pass at least the minimal "fast" test suite; some projects may have more thorough "full" test suites that take many hours to run, and requiring that those be run on every change would slow down development too much, but at the very least, the quick "sanity check" test suite should always pass before something can land on master.

"Researcher" is appropriate for someone who actually produces academic output. It may not be immediately practical, but it consists of new ideas that have been formalized and tested sufficiently to pass peer review of other researchers.

Has the Mill architecture done that? Are there any actual papers about it? Anything beyond marketing fluff?

It seems like there are some ideas behind the Mill that seem interesting when you hear about them, but I haven't seen anything rigorous enough to even be reviewable.

And it doesn't look like that is the intent, either. Rather, from all appearance, it looks like they are trying to drum up interest for investment.

Dude, it's not like there is major prize money involved.

This is just a "just for fun, do something cool by forking something that already exists and we'll show off the best."

Relax, have fun, make a cool game.

A long time without access to hardware documentation, and even now that that is sometimes more forthcoming, simply a lot fewer resources than the proprietary drivers have. The proprietary drivers have many years worth of several full-time developers, testers, access to hardware engineers to solve problems together, etc.

The open source drivers have frequently been written by volunteers, or professionals who do it as only a small part of their job, have had to spend more time and effort reverse-engineering rather than having documentation and the ability to talk to hardware engineers, and are perpetually at least a few months to a few years behind the proprietary developers who had access to all of this before the hardware even came out.

It's impressive what the open source drivers have managed to accomplish, and they are improving, but they are severely handicapped compared to the proprietary drivers.

This excludes, of course, Intel, but Intel focuses on lower end integrated graphics rather than high-end discrete graphics, so it's not quite comparable.

  These are the vanishingly few people who have actually 
  seen the source to a game, the driver it's running on, 
  and the Windows kernel it's running on, and the full 
  specs for the hardware. Nobody else has that kind of 
  access or engineering ability.

One option is to release the source of the drivers, making it possible for motivated engine developers to do this without explicit access to AMD developers.

If they did this on Linux as well, then developers would have access to the full stack, in order to be able to learn about how the lower levels work and more easily track the problems down without simply a whole lot of trial and error on a black box.

They are obligated to display the odds on each machine, so people have at least a fair chance of evaluating their changes (even if they odds are always in the house's favor). In this case, the odds they posted didn't take into account the poor suggestions given by the autoplay feature.

So the question is, does the fact that the player has a choice that would allow them to improve their odds to what was posted mean that they met their obligation in posting the odds, or does an autoplay feature that most users choose, because it speeds up the game and requires less thought, determine the odds that they are statutorily required to post.

The rules (http://arcweb.sos.state.or.us/pages/rules/oars_100/oar_177/1...) state: "A close approximation of the odds of winning some prize for each game must be displayed on a Video LotterySM game terminal screen or a help screen. Each game also must display the amount wagered and the amount awarded for each possible winning occurrence based on the number of credits wagered on a game play." So this will likely depend on whether this is determined to be a close enough approximation, and whether autoplay suggesting a sub-optimal play that reduces your odds is considered to be a problem, if you do have a choice that would let you avoid that.

Yes, I read that.

I would love to improve our hiring process, and include more realistic work samples as part of it.

However, I don't feel that a full-fledged work-sample test is realistic, especially if every employer started requiring it. Imagine applying to a few different jobs, and each requiring you to do 20 hours of learning of their material followed by some open ended realistic problem, that could take many hours to complete. If you were looking around at a few different employers, this would be a full-time job itself; some candidates would skip it because they could find a job which required less effort up front easily enough, some would simply not have the time because they are working a full-time job while doing it.

On the other hand, if there is a shared work-sample test like this one, that will be used by a number of employers, it means that it can be more in depth than any single employer could do, while simultaneously wasting less of the candidate's time as they do the one test, rather than one per potential employer.

So yes, in a way I am viewing this as a replacement for a technical phone screen, because I am interested in improvements to that process but haven't come across any potential improvements which seem viable, but this one sounds like it could have potential.

The "read the resume, read their existing code samples, and do a phone screen" approach covers a lot of ground in a little time, so while there are a large number of problems with it, it's pretty hard to improve on without spending a lot of the candidate's time to get up to speed on a more realistically sized problem, and a lot of good candidates aren't willing to devote that much time unless they really, really want to work for that particular employer. We're a small company, working in a niche business, so it's hard to get that kind of dedication from a single candidate.

On your "About Us" page, you say "We're especially interested in talking to you if you will be hiring 10+ engineers in the next year, as we may be able to help you out with that. Get in touch with any of us."

Does a company need to be hiring 10 or more engineers to make it worth it to talk to you?

I'm at a small company, that has been trying to hire engineers for the last couple of years, and not having much success; we've hired a couple, had a couple take other offers, lost a few to attrition.

We would love to be able to get some candidates who have already passed a technical screen; less time for us, scheduling an hour with a bunch of candidates who don't pan out, less time for them, only focusing on one more in-depth set of problems rather than a whole bunch of different phone screens.

But we're not hiring 10+ developers any time soon; that would double the worldwide size of our dev team. We're looking for maybe 3 or so at this point.

Would you consider working with smaller companies as well?

Yes, that is the meaning of plain old "game theory", and I also think that's the meaning that the person you were replying to meant; I just wanted to point out that there is something with "game theory" in its name which is much more applicable to Go.

Exactly this. A "pass" on that question consists of mentioning HTTP, DNS, and (perhaps with some prompting about what protocols underlie HTTP) TCP. A strong pass involves being able to tell me that DNS is usually UDP based, and being able to describe what distinguishes TCP from UDP. A very strong pass involves being able to describe in detail recursive DNS queries, talk about the fact that DNS can use TCP rather than UDP for queries or replies larger than what fit in a single packet, being able to tell me a bit about how TCP congestion control, sequence numbers, acks, Nagle's Algorithm, and the like work.

I should point out that I recently talked to a college junior who got a "very strong pass" on this question as a front-end intern candidate. If she can do that as a front-end oriented candidate with only a couple of years of experience in school, I don't think it's unreasonable to expect a professional with several years of experience to have at least the basic knowledge that TCP exists.

Some people are stronger in one area than another; so I cover a number of areas, and expect them to do well on a majority, but not all, of the questions. Even if you fail this question, just saying that you don't know anything about networking, if you do well at all of the others we will bring you in for the in-person interview; we have recently hired someone who simply said "I don't know" on this question, and was a bit fuzzy on the big-O questions, but did fine on on all of the rest.

  Ajax doesn't go wrong.

Except when it does. Did you miss the bug report I linked, in which it went wrong in one way when Firefox sent something as two separate packets, which caused IIS's HTTP implementation to break, and then when that was fixed the fix caused other regressions:

https://bugzilla.mozilla.org/show_bug.cgi?id=137155

And this is only one of many such bugs; I've seen others in practice as well. It requires no special use of JavaScript to hit such bugs; just an unfortunate interaction between the particular browser and back-end server, of which there are many possible combinations, especially when you add transparent proxies into the mix.

By the way, when I'm looking for a frontend developer, I'm also not looking for someone to do the very most basic CRUD app plus some JavaScript for interactivity. I'm looking for someone to be able to do a rich, desktop-style app that pushes the boundaries of what can be done with HTML5 video. This is an area where you will be running into browser bugs on a regular basis, and need to know when to stop trying to solve the problem yourself and push the bug report upstream to the browser vendors, and in order to be able to do that it helps to have a knowledge of what is going on at that level. For this application, we accept that we will only be running on the very latest releases of a few select browsers, until interoperable support for the kind of stuff that we're working on becomes more widespread.