LeafStorm

That presumes that either (a) they have time to spend doing substantial work with open source outside of their day job and other obligations, or (b) they have a day job which allows them both the time and the regulatory freedom to contribute to open source. For many programmers with the desire to contribute to open source and substantial work experience, this is not the case.

Actually, that's part of the issue. Most of Parrot's semantics are exactly those of Perl 6 (right down to the opcodes for Boolean testing), and those don't get along well with most languages.

> One prerequisite for something being scientific is that it must be testable, and this sort of thing is not. So it's not science and I don't waste time conflating it with what actually is science. It's an interesting philosophical question.

As a dualist, I agree that the question of whether experience exists (and whether there is a soul of some type powering it) is not answerable by science. But many of the people I discuss this with take the attitude that because it can't be answered by science, it's not even worth discussing as a possibility. It feels like a physicist approaching a mathematician with a theory based on experimental results, and being rebuffed for not having a proof.

I haven't even read the original article, much less the HN comments, but based on what I've read here (and on my past experience discussing similar subjects on HN), a similar attitude is likely to be at play.

My preferred definition of LUA is "Lua Uppercase Accident." ;-)

Yes: []

But that's only because it hasn't been used for anything worth suing over.

I'm pretty sure suing you if it causes damage counts as "what the f--k they want to."

Have you looked at Inform? There's a paper on its Web site [1] discussing its approach to modeling the world.

[1] http://inform7.com/learn/papers/

They use different object file formats, different system calls, different library loading procedures, and on and on. Even if Mac OS X had the actual Linux kernel, the windowing interfaces are completely different.

Yeah. But if you're not publishing it to the entire world, you probably won't run into them. And there are many other applications where databases are useful, that aren't network servers of any kind.

According to Wikipedia [1], the more conventional abbrevation for "the" in Old English was "þe." ("þ" [thorn] generally transcribes as "th," with "ð" as "dh.") On the other hand, the article for ð indicates that when making puns on the word "the" in Icelandic, one would use "ðe."

In either case, I don't think a separate symbol for "the' would really be useful unless, unless it signified a return to the use of þ or ð for additional words like "þat," "þey," "þere," and so on. (I have never been the biggest fan of the ampersand.)

[1]: https://en.wikipedia.org/wiki/The#Definite_article

[2]: https://en.wikipedia.org/wiki/%C3%90

While I don't necessarily trust an external company with all my emails, I also don't trust myself to maintain the myriad daemons involved in this setup without doing something subtly wrong that results in my server not sending/receiving all the mail it should -- or, worse, being used for spam.

What would be useful is a pre-assembled virtual machine image or other form of appliance that allows you to deploy and test a mail server within about an hour or so, without having to duct-tape any of this together yourself.

I was about to do that. But then the stranger awakened, and then, the game becomes far more interesting.

Except generating a random salt and the proper hash format to provide as input to crypt() is surprisingly difficult, especially in a cross-platform way. I recently replaced my custom crypt wrapper with the userland implementation of these functions, and in the process I discovered my custom wrapper had some rather non-obvious bugs.

That's still the recommended way to install Distribute (for Python) [1] -- though they at least don't recommend you pipe it to sh directly.

Composer (for PHP) [2] also uses this install method, but you can just download the Phar file from their Web site directly -- all the sh script does is check PHP settings and dependencies.

[1]: http://pythonhosted.org/distribute/

[2]: http://getcomposer.org/

The problem with using Git push to deploy is that when you're first setting up your deployment, if you make a mistake in the settings, you can't amend the commit to fix it, because it's already been pushed - so the mistake stays there for all eternity. And if you try to fix it and your fix doesn't work, that's another bad commit.

I deployed my first project to Heroku a few weeks ago, and now my project history has a handful of permanently unremovable junk commits, which I made solely to force Heroku to rebuild my app.

The funny thing is that according to Freshwater Railway's fictitious "history of Michigan Central Station" page [1], 2013 is the year that the Marouns sold the station to Freshwater Railway Corporation to begin constructing a commuter rail depot.

[1] http://fwrail.org/mcs.htm

I haven't written one, but I contributed a few patches to nanoc [1]. But if nanoc didn't exist, I probably would have written my own.

And now that you mention it, I have been looking for an excuse to learn Clojure...

[1] http://nanoc.stoneship.org/

That's because the syntax was redesigned to be more orthogonal. So $ is always followed by a word to expand a variable and not an arcane symbol, % is used for a wide variety of ways to get process ID's, and it's easy to set up arrays besides just $argv (plus if you do $argv on its own, it creates one word for every item in the array, without you having to worry about bizarre quoting).

Most of these differences, and why they were made, are explained in the manual.

> Early in the development of RethinkDB, we made the design decision to be extremely conservative about durability and safety of users's data.

I'm glad that the Rethink engineers are taking this approach to development instead of "let's win all the benchmarks!" Overall, it's apparent that they are really thinking through the consequences of their decisions and the tradeoffs in database systems, and that they want to build something that will last instead of something that will just become popular in the short term.

Or by using every other Unix command ever.

(Disclaimer: This is a hyperbole.)

Yeah, I did. Sorry about that.

This reminds me of something my assembly instructor said in class once (paraphrased):

"Once, I was interested in finding out how a C compiler would handle the div instruction. So, I opened up my editor, and wrote this C program:

    void main () {
        printf("%f", 14.0 / 3.0);
    }

I compiled it, and took a look at the generated assembly. How many div instructions do you think it used?

[Various guesses, mostly "one."]

The correct answer is "zero." The compiler figured it out at compile time, and put a constant in instead. So, I decided to put it in a function:

    float divide (float a, float b) {
        return a / b;
    }
    
    void main () {
        printf("%f", divide(a, b));
    }

Guess what happened next.

[Various guesses.]

The f--king compiler optimized it out again!"

In my assembly and computer architecture class (CSC 236 at NC State University), the instructor grades us on efficiency - sometimes it's the number of instructions written, sometimes instructions executed. Additionally, he posts the all-time efficiency records for each program.

The end result is that I am now addicted to assembly programming. There's so many clever tricks you can use, like:

* Manipulating the addresses your code assembles at so that the addresses in a jump table can overlap.

* Using `lea` on data values to convert ASCII numbers to their normal equivalent while in motion.

* Making a 128KB lookup table.

* Unrolling all the loops in the program.

* Reusing as many registers as possible (including using bx as a frame pointer) just so you don't have to pop them.

And when you're studying your code, and you suddenly have the flash of inspiration about how to make it faster, there's this feeling of, "Oh, that's so brilliant, but so evil..."

(Of course, then you have to debug it all. :-P)

Too loud. (But if drugs were involved, that certainly wouldn't help.)

Because it's a popular, well-written framework with a huge volume of existing code, and integrating WebSockets into Django means you don't have to maintain two codebases if you want to have a realtime Django app.

Also, it's fun.

The stack is an abstraction used in the C API. If you look at the actual bytecode generated, it's all register-based.

I love the idea behind this project. I think Python is a superb language for learning programming, and the implementation of algorithms and data structures is not discussed enough in the Python world.

However, I'm not a big fan of the fact that all the collection ADTs are strict ports from Java, with far too many getSpam/setSpam methods and not enough __double_underscores__.

I meant "only support homogeneous arrays," or "do not support heterogeneous arrays," and apparently got the two wordings mixed up. Thanks.

I note that, like many erstwhile specs, TOML does not document the escape sequences accepted in strings. Nor does it exhaustively specify integer formats and float formats - rather ironic for a spec that advertises "TOML is designed to be unambiguous and as simple as possible."

The limitation on array types seemed fairly arbitrary at first glance, but after thinking it over I realized it aided compatibility with languages that do not support homogeneous arrays. Though as far as the types go, I would add boolean and perhaps non-quoted strings for single-word values.

Now that the technical criticism is out of the way, holy crap this guy is arrogant.

The implication there was that because Salesforce owns Heroku, they would be able to pay up major cash if Rap Genius got some other Heroku customers involved in the lawsuit.