Mass-unprefixing in Firefox 16 - <AUTHOR> http://paulrouget.com/e/unprefixing-in-firefox-16/ <comment><USER2> I hope I will not see many more of this kind of news.

Dear browser makers, please, enable your prefixed CSS properties only in dev/night/beta builds. Leave only unprefixed CSS properties in the release stable browsers. With this you will be able to test new features, show them to web developers and, at the same time, save them from the madness of maintaining five different slightly different versions of new CSS properties. How many developers do you think will not remove the `-moz-` prefixes from they CSS? Who do you expect to say "from now on we will only support Firefox 16, let's drop the prefixed version used by older versions"?

Prefixes are for testing, not for stable applications.

<comment><USER3> From the first bug linked from the article (at <https://bugzilla.mozilla.org/show_bug.cgi?id=762302>):

        The CSS Working Group has agreed to give the go-ahead to browser implementers to unprefix CSS3 Transitions, Transforms, and Animations:

        http://lists.w3.org/Archives/Public/www-style/2012Jun/0105.html

So contrary to your comments, they're doing this because the W3 said that it's time to do so.

<comment><USER2> > So contrary to your comments, they're doing this because the W3 said that > it's time to do so.

My point is that support for prefixed CSS properties should not be available in stable releases at all.

What they should have done from the beginning (and from other comments seems it will be done in the future) is to enable experimental prefixed CSS properties only in dev builds (to demonstrate to the W3C working group the feasibility of those new properties) and remove such properties from stable releases. In this way the stable releases will have _only_ W3C approved prefixes, not the current mess of draft + CR + TR support.

</comment></comment></comment><comment><USER4> I personally think we should cut down on prefix use. Whilst it may be impractical to completely eliminate them, they are a PITA for developers, and have made the mobile web too heavily reliant on WebKit.

<comment><USER5> I know, i am using transitions/gradients on my project and i have to write 5(!) different rules just to set one property. This is for production code.

      background: -webkit-linear-gradient(#fff, #fdd 75%, #fcc);
      background: -moz-linear-gradient(#fff, #fdd 75%, #fcc);
      background: -ms-linear-gradient(#fff, #fdd 75%, #fcc);
      background: -o-linear-gradient(#fff, #fdd 75%, #fcc);
      background: linear-gradient(#fff, #fdd 75%, #fcc);

And this is used _every_ time i have to set a gradient. I really wish there were some better options than prefixes. I am not surprised at all if developers move to supporting just webkit. This is a lot of work and maintaining. And without css variables, it is a mess to change a color. It is very tempting to just use the -webkit- version and probably a non prefixed one for future compatibility. 2 is far better than 5.

Edit: And i should mention, this is not a mobile website, it's a desktop site.

<comment><USER6> Missed one:

        background: -webkit-gradient(linear, 0 0, 0 100%, from(#fff) color-stop(75%, #fdd) to(#fcc));

(I hope I got that syntax right.) This one should go above webkit-linear- gradient.

And it's also an example of why prefixes were invented - the syntax is totally different.

I think vendors should unprefix the moment their prefix matches the spec.

<comment><AUTHOR> >>I think vendors should unprefix the moment their prefix matches the spec.

most of the time when all prefixed version are the same it means there isn't a CR for the spec, and it is therefore in flux. unprefixing it would mean sites would break if and when it is changed before reaching recommendation.

<comment><USER6> Don't know what "CR" is (community recommendation?), but obviously I mean once the spec is finalized, not just when the spec is proposed.

<comment><USER7> Candidate Recommendation; the state of a W3 recommendation where they call for vendor implementations.

</comment></comment></comment></comment></comment></comment><comment><USER8> -moz-border-radius and -moz-box-shadow were both unprefixed in 13, I only know because I had a personal html page themed for firefox exclusively which was affected. There doesn't seem to be much comment on this unprefixing from Mozilla in any Official capacity, when my personal page was affected it was only by accident that I ran across this page <https://developer.mozilla.org/en/Firefox_13_for_developers> that mentions it. Just thought I'd mention this in case anyone was affected.

</comment><comment><USER9> In other words: same as IE10. [http://blogs.msdn.com/b/ie/archive/2012/06/06/moving-the- sta...](http://blogs.msdn.com/b/ie/archive/2012/06/06/moving-the-stable-web- forward-in-ie10-release-preview.aspx)

</comment><comment><USER10> Firefox 16 will hit the mozilla-release channel on October 9: <https://wiki.mozilla.org/RapidRelease/Calendar>

</comment><comment><USER11> The problem with all those prefixes is the w3c. They are stuck in the web of the 90.

</comment><comment><USER12> None of the bug links are working for me.

<comment><USER13> Should work now.</comment></comment>


A Gentle Introduction to Data Compression - <AUTHOR> http://bertolami.com/index.php?engine=blog&content=posts&detail=fundamentals-of-data-compression

<comment><USER2> I think that for beginners it's far better to talk about the LZ-style algorithms first, since they are much easier to understand without requiring any discussion of probabilities and the associated maths; the idea of replacing repeated strings with a reference to them is very intuitive, and so is the implementation of an LZ compressor/decompressor. In fact, an in-memory LZ decompressor core can be written in less than two dozen bytes of x86 instructions, and can easily outperform the fastest Huffman decompressor.

When I was interested enough in compression to read about it, the majority of the information I could find seemed highly theoretical and made me think that Huffman was a good first step so I managed to write a simple static/dynamic Huffman compressor/decompressor, but that didn't work so well. It was "fast enough", but the compression ratio was disappointing. When I discovered LZ the difference was amazing: an _extremely_ simple algorithm, requiring about an order of magnitude less code in implementation, that compressed much better than Huffman for data which would intuitively be compressible.

In retrospect, it's quite clear that Huffman and other "variable length code" techniques only work because of nonuniformity in symbol probabilities, so it is ineffective on data containing repeating patterns but uniform probability. E.g. take a string 256 bytes long containing all the byte values 0, 1, 2, ... 253, 254, 255; and repeat that string multiple times in a file. LZ can easily compress that pattern but Huffman can't. (Does LZ rely on probability nonuniformity? It doesn't look like it.) The fact that many common methods like FLATE use Huffman only to compress the output of LZ on their input probably reflects this, but I don't think I've seen such an intuitive explanation for it before.

<comment><USER3> I agree. Transforms (LZ77, BWT, RLE, ...) are generally more interesting and productive than entropy coding. [http://mattmahoney.net/dc/dce.html](http://mattmahoney.net/dc/dce.html)

</comment></comment><comment><USER4> Very nice introduction.

Recently I've been following the progress of the Finite State Entropy algorithm[1]. From the readme on the github project [2]:

>FSE is a new kind of Entropy encoder, based on ANS theory, from Jarek Duda.

>It is designed to compete with Huffman encoder and Arithmetic ones.

>While huffman is fast but can only represent probabilities in power of 2 (50%, 25%, etc.) arithmetic coding can represent probabilities with much better accuracy, but requires multiplications and divisions.

> FSE solve this dilemma by providing precise probabilities, like arithmetic > does, but using only additions, masks and shifts.

> This makes FSE faster, on par with Huffman speed, and even suitable for low- > power CPU environment.

[1]: [http://fastcompression.blogspot.com/2013/12/finite-state- ent...](http://fastcompression.blogspot.com/2013/12/finite-state-entropy-new- breed-of.html) [2]: [https://github.com/Cyan4973/FiniteStateEntropy](https://github.com/Cyan4973/FiniteStateEntropy)

<comment><USER5> Well, if it's as good as claimed, then maybe it needs to be described as a new category, alongside Huffman, arithmetic & Rle

</comment></comment><comment><USER6> I found Compressor Head quite enjoyable: [https://www.youtube.com/watch?v=Eb7rzMxHyOk&list=PLOU2XLYxms...](https://www.youtube.com/watch?v=Eb7rzMxHyOk&list=PLOU2XLYxmsIJGErt5rrCqaSGTMyyqNt2H)

</comment><comment><USER7> Well written! I was just looking for the Shannon Minimum Coding Rate definition the other day, so it was nice to have a quick refresher on the basics.

This also highlights a fundamental issue: the coding scheme is tailored to the expected data input. That's why there's no one-size-fits-all compression algorithm, and you can achieve far greater efficiency if you have a good model of the shape of the input data. (The same applies to lossy)

The MCR is also a nice way to demonstrate how random data can't be compressed. Let's say you have 256 symbols, each with probability 1/256 (independent etc). The Shannon Entropy = -sum(P(x) * log2(P(x) for x in 0..255) = -2^8 * 2^-8 * -8 = 8 bits. No compression possible.

</comment><comment><USER8> Pet peeve: dark gray text on light gray background, see [http://contrastrebellion.com/](http://contrastrebellion.com/).

Otherwise a great text, just its presentation is a bit distracting (at least for my taste/eyes).

</comment><comment><USER9> Is there any value in thinking of the data to be compressed as a big integer, and trying to come up with an expression or program that, when evaluated or executed, produces the desired integer?

<comment><USER10> In some sense, this is exactly what decompression does. The question, if I understand you correctly, becomes one of "how is this decompression program designed?" Does it require any particular inputs? etc.

Although somewhat different than what you're describing, you might be interested in arithmetic coding, which encodes data to a single numerical value that can later be recovered by an inverse process.

</comment></comment><comment><USER11> This is a great article, but it fails to mention Weissman Score - the gold standard of compression measurement.

</comment><comment><USER12> Huffman encoding reminds me of UTF-8. What is the connection there? Is UTF-8 based on Huffman encoding?

<comment><USER13> It's not based on it, but the fact that English takes 1 character and the rest take 2 does resembles the same concept, since English is more common than other languages in general.

</comment></comment><comment><USER14> lz77 is a little hard to explain, but I don't have any degree in CS nor math and I managed to understand it a little, not that I could really be able to reproduce it.

isn't lz77 the most efficient text compression algorithm ?

<comment> ryan-c LZ77 is usually more efficient when combined with Huffman coding (this is what DEFLATE does).</comment></comment>


C Compiler from Scratch - <AUTHOR> https://github.com/DoctorWkt/acwj <comment><USER3> I've been sort of working on a compiler side project for years, and my observation of the materials out there is that they all seem to get caught up in bikeshedding. Parsing just isn't that hard of a problem, and with a vague understanding of what a recursive descent parser is, just about any reasonably-skilled developer can figure out how to write a good-enough parser. EBNF, parser generators, etc. is just noise, yet this is where every compiler tutorial I've come across spends most of its time.

The real meat of any compiler is generation, and that's _hard_ , starting with the fact that if you're new at this you probably don't know assembly. And assembly is death by a thousand cuts: sure, you can probably figure out how to do loops and ifs pretty quickly, but the subtleties of stack allocation, C-style function calling convention, register allocation, etc. all add tiny bits of "messiness" that each add a little bit of complexity to your code. Managing that complexity is the real challenge, and I haven't come across a compiler course that really addresses this.

<comment><USER4> I couldn't agree more with this, it's very frustrating. I recently worked through most of the "make a lisp" guide [0], and it was excellent introduction to a simple lisp interpreter. But now I want to try my hand at a compiler (either producing machine code or maybe custom VM bytecode) and the lack of resources for that is bewildering. Just as you say, I've found that most online texts on compilers seem to spend most of their time on parsing, which is something I already feel relatively comfortable with.

Does anyone know of a good resource on how to transform an AST to machine code? I've skimmed Crafting Interpreters and the Bytecode VM section seems to spend an inexplicable amount of time on not only parsing, but minutia having nothing to do with compilers (e.g. writing a custom dynamic array implementation in C).

[0] [https://github.com/kanaka/mal/blob/master/process/guide.md](https://github.com/kanaka/mal/blob/master/process/guide.md)

<comment><USER5> Check out "Modern Compiler Implementation" by Appel and also the Red (Purple?) Dragon book.

<comment><USER3> _sigh_

Have you actually done this? Do you really think we haven't?

The Appel book in particular is very good, but it only covers assembly generation at a high level. None of the examples target a real-world architecture.

<comment><USER5> I don't know what you have done. The red dragon book goes over targeting an intermediate form that's basically assembly language, it also covers register allocation in depth. As far as I can tell, most of the texts after that is in research papers and real world examples ([https://c9x.me/compile/](https://c9x.me/compile/))

</comment></comment></comment></comment></comment><comment><USER6> I'm learning from the Compiler course offered freely from Stanford [0] and the dragon book. I still feel great about it. And I think this GitHub project submitted will be an excellent practical source for analysis of how real world compiler might looks like from its beginning.

[0]: [https://lagunita.stanford.edu/courses/Engineering/Compilers/...](https://lagunita.stanford.edu/courses/Engineering/Compilers/Fall2014/about)

<comment><USER7> Interesting. But you have to register for this.

Does anyone have any links to some good compiler classes on YouTube or elsewhere?

<comment><USER8> Is that an issue given the course is free?

<comment><USER9> Yes. Not everyone likes to give away their personal information - <USER2> (paradox) in exchange for access to a free resource.

<comment><USER10> Junk email accounts are helpful for this.

</comment></comment></comment></comment></comment><comment><USER11> This is fantastic work. I believe learning to write a compiler is similar to learning a functional programming language. It completely changes the way you approach problems.

I'm curious why BNF was chosen vs EBNF. I'm new to parsers and grammar. Isn't EBNF easier/simpler to write complex rules?

<comment><USER12> > I'm curious why BNF was chosen vs EBNF. I'm new to parsers and grammar. > Isn't EBNF easier/simpler to write complex rules?

I can't speak to the specific reasons the OP chose, but I can speak to generalities.

Generally speaking, every parser engine out there that supports EBNF supports different extensions of EBNF [+]. They aren't portable from one to another, and that can lock you in. So if you get frustrated with the engine at some point and want to ditch it, it becomes harder to.

BNF does make it harder to write complex rules, but if your goal is a self- hosted compiler, like this one appears to be, you might use BNF for the host compiler, and then choose something more expressive now you can use the language you've built.

There are tradeoffs in everything. BNF tends to be faster, and more portable with more documentation. EBNF handles more complex cases, but you might have to learn one specific tool rather than a standard you can use everywhere.

[+] There is an EBNF standard. However, parser/lexer engines still extend it in their own incompatible ways. ISO tried to standardise it, and just ended up adding to the chaos, and now even they don't recommend their own.

<comment><USER13> For the curious, the ISO standard is ISO/IEC 14977. It is available here: [https://standards.iso.org/ittf/PubliclyAvailableStandards/](https://standards.iso.org/ittf/PubliclyAvailableStandards/)

Direct link to the standard: [https://standards.iso.org/ittf/PubliclyAvailableStandards/s0...](https://standards.iso.org/ittf/PubliclyAvailableStandards/s026153_ISO_IEC_14977_1996\(E\).zip)

But of course, as shanka commented, it isn't a standard that is followed practically. This is just a demonstration of [https://xkcd.com/927/](https://xkcd.com/927/) in real life.

</comment></comment></comment><comment><USER14> This might be relevant

A Retargetable C Compiler: Design and Implementation by David Hanson and Chritopher Fraser

[https://www.amazon.com/Retargetable-Compiler-Design- Implemen...](https://www.amazon.com/Retargetable-Compiler-Design- Implementation/dp/0805316701)

Written in a literate programming style.

<comment><USER15> Happy new year to you Ravi!

<comment><USER14> Thanks Jacques. Same to you, (and everyone on HN!)

</comment></comment></comment><comment><USER16> Do you know of similar types of tutorials / repos except for language parsers (like markdown or json) ?

How difficult would it be to implement in comparison to a compiler ?

Where should I start looking ? (I want to build a compiler at some point but I want to get my feet wet building a simple language parser first)

Thanks in advance

<comment><USER17> Try the first few chapters of [https://inf.ethz.ch/personal/wirth/CompilerConstruction/Comp...](https://inf.ethz.ch/personal/wirth/CompilerConstruction/CompilerConstruction1.pdf) and apply it to the grammar at [https://www.json.org/json- en.html](https://www.json.org/json-en.html)

<comment><USER16> Thanks for the resources !!

</comment></comment></comment><comment><USER18> Writeups like this are helpful for people who find compiler theory books a bit dry. This is great!

</comment><comment><USER9> I remember the time when writing a compiler for Pascal - complete with a code generator (for 8086) - was a routine assignment for CS students at the end of the first semester of the second year.

<comment><USER19> Granted is was for a toy language, not Pascal, but I had to write a complete compiler for my CS undergrad ~3 years ago.

</comment></comment><comment><USER20> I feel that many introductions to scanning and parsing are based on old techniques when memory were scarce. In those times storing your files in memory, was simply impossible. But we live in times where we have gigabytes of ram and there are not many projects that could not be read into memory. (Tell me about a project that has a gigabyte of source files, please.) So, why not assume your input to be stored in a string.

<comment><USER21> A complete debug, unoptimized build of LLVM/Clang requires about 50GB of disk space. And LLVM/Clang is on the smaller end of large projects; the Linux kernel, OpenJDK, and Mozilla are larger open source projects, and the private repositories of people like Microsoft, Facebook, and Google are an order of magnitude, or two, above those.

Keeping the entire program string in memory doesn't really buy you anything. You still need your AST and other IR representations, and location information that is stored as a compressed 32-bit integer is going to be more memory- efficient than a 64-bit pointer anyways. Furthermore, scanning and parsing is very inherently a process that requires proceeding through your string linearly, so building them on an iterator that implements next() and peek() (or unget()) doesn't limit you.

<comment><USER20> Yes, I agree with you. For production compilers, with hand-coded parsers, it is a waste of space to store all files in memory. Please note that I was talking about introductions to scanning and parsing. I just feel there is no need to make things more complicated than they need to be, when you are introducing somebody to parsing and scanning. Most people who study computer science, will likely, when they need to do some scanning and parsing, not having to deal with files, but have strings at hand. For an introduction to parsing and scanning, I even would suggest to begin with a back-tracking recursive decent parser, to talk about the essence of parsing. Please note that if you add a little caching, such a parser can have descent performance for many applications that an average software engineer will encounter. For all other applications, standard libraries and/or compilers exist. See [https://github.com/FransFaase/IParse](https://github.com/FransFaase/IParse) for an example of this approach.

Anyway, please do not compare disk space to build with source code size. (I understand that the debug version of uses a lot of static linking with debug information.) I understand that the Linux kernel is 28 million lines of code. Even with 80 characters per line, when I think an average of 40, is far more realistic, that will be under 2 GB. So, yes, you can store all source file in RAM on any descent computer. (I did not find any recent number of lines of code for LLVM/Clang, but extrapolating it, I guess it is in the same order as the Linux Kernel.)

</comment></comment></comment><comment><USER22> I've been itching to write one of these myself. The looks like a good guide to get started.

</comment><comment><USER23> A fantastic book along these lines is Allen Holub's "Compiler Design in C". It's old (1990) and out of print, but you can get the PDF for free from Holub's site [1].

Over the course of the book, a C compiler is developed. To handle lexical analysis and parsing, tools similar to lex and yacc are developed.

Here's an excerpt from the preface to give an idea of the approach:

> This book presents the subject of Compiler Design in a way that's > understandable to a programmer, rather than a mathematician. My basic > premise is that the best way to learn how to write a compiler is to look at > one in depth; the best way to understand the theory is to build tools that > use that theory for practical ends. So, this book is built around working > code that provides immediate practical examples of how given theories are > applied. I have deliberately avoided mathematical notation, foreign to many > programmers, in favor of English descriptions of the theory and using the > code itself to explain a process. If a theoretical discussion isn't clear, > you can look at the code that implements the theory. I make no claims that > the code presented here is the only (or the best) implementation of the > concepts presented. I've found, however, that looking at an implementation- > at any implementation--can be a very useful adjunct to understanding the > theory, and the reader is well able to adapt the concepts presented here to > alternate implementations.

> The disadvantage of my approach is that there is, by necessity, a tremendous > amount of low-level detail in this book. It is my belief, however, that this > detail is both critically important to understanding how to actually build a > real compiler, and is missing from virtually every other book on the > subject. Similarly, a lot of the low-level details are more related to > program implementation in general than to compilers in particular. One of > the secondary reasons for learning how to build a compiler, however, is to > learn how to put together a large and complex program, and presenting > complete programs, rather than just the directly compiler-related portions > of those programs, furthers this end. I've resolved the too-many-details > problem, to some extent, by isolating the theoretical materials into their > own sections, all marked with asterisks in the table of contents and in the > header on the top of the page. If you aren't interested in the nuts and > bolts, you can just skip over the sections that discuss code.

...

> In a sense, this book is really an in-depth presentation of several, very > well documented programs: the complete sources for three compiler-generation > tools are presented, as is a complete C compiler. (A lexical-analyzer > generator modeled after the UNIX lex utility is presented along with two > yacc-like compiler compilers.) As such, it is more of a compiler-engineering > book than are most texts-a strong emphasis is placed on teaching you how to > write a real compiler. On the other hand, a lot of theory is covered on the > way to understanding the practice, and this theory is central to the > discussion. Though I've presented complete implementations of the programs > as an aid to understanding, the implementation details aren't nearly as > important as the processes that are used by those programs to do what they > do. It's important that you be able to apply these processes to your own > programs.

[1] [https://holub.com/compiler/](https://holub.com/compiler/)

<comment><USER24> Thanks for the link. Looks like an excellent resource and one that is not too far out of reach for most of us.

</comment></comment><comment><USER25> I misread and thought someone created a C-compiler _in_ Scratch. That'd have been extremely impressive... :))

<comment><USER26> That sounds like a challenge someone might actually try...

Along the same lines, you may find this amusing: [https://news.ycombinator.com/item?id=7882066](https://news.ycombinator.com/item?id=7882066)

</comment></comment><comment><USER27> Any ideas what subset of C this supports? Or is it fully C89/C99/C11 compliant?

<comment><USER21> The introduction states: > Instead, I've fallen back on the old standby and I'm going to write a compiler for a subset of C, enough to allow the compiler to compile itself.

Just from cruising the lesson titles and poking around a few of them, substantially less than full C89. I don't see floating point, bitfields, or function pointers anywhere. Apparently, variadic functions and short (!) aren't supported either. Most of the new things in C99 (save perhaps //-style comments, mixed declaration and code, and long long) are unlikely to be supported, let alone C11.

Judging from its reference to C-, it might also well not support the full C declarator madness.

</comment></comment><comment><USER28> IMHO, you shouldn't write a compiler 'from scratch". You should write it using lots of libraries offering supporting functionality, such as:

* Grammar-based parsing

* Tree and graph representation, traversing

* (Possibly) A tree or graph grammar library

* Cross-platform filesystem support

* Combinatorial algorithm implementations (some of them may get used in various optimizers)

* terminal support (for formatted output)

and so on. And of course - there's the standard (C) library which one should also not count as "scratch".

Now, as an exercise, it is not-uninteresting to also implement parts of some of those, but it's not clear that "from scratch" is the most pedagogically- useful approach.</comment>


Your Laptop is Not Private or Secure at US Customs - <AUTHOR> http://associatesmind.com/2011/04/11/your-laptop-is-not-private-or-secure-at-us-customs/

<comment><USER2> It's become routine for law offices to provide their lawyers with clean installs when they take a laptop across the border. They can then just download the encrypted client files when they arrive at their destination. It's not such a great idea to be crossing the border with encrypted files on your computer like the article suggests. Even if the border guards can't decrypt them, it still makes you look like someone who is, rightly or wrongly, avoiding their scrutiny.

For those of us without an IT department, Dropbox works nicely. Just remember to scrub the folder before you travel.

<comment><USER3> Except the US says the border radius covers something like 100 miles inwards from all locations so basically everything is covered.

</comment></comment><comment><USER4> The EFF's guide to protecting your electronic devices at border crossings:

[https://www.eff.org/deeplinks/2010/11/effs-guide- protecting-...](https://www.eff.org/deeplinks/2010/11/effs-guide-protecting- devices-data-border)

</comment><comment><USER5> > Be aware that if you fail to provide a passphrase or decrypt information > upon request, there are a number of possible consequences...[t]he agent may > detain you at the border.

Encryption should always be accompanied by steganography when dealing with the government if you're concerned about your personal well-being as well. Preferably have an innocent-looking dummy OS that boots up by default.

Does anyone know of a way to boot a different OS based on what BIOS password is entered?

<comment><USER6> _> Does anyone know of a way to boot a different OS based on what BIOS password is entered?_

<http://www.truecrypt.org/docs/?s=hidden-operating-system>

<comment><USER7> Is anyone concerned about travelling with an encrypted OS - but not a shadow one - and upon decryption, being accused of only decrypting a shadow OS? How would you prove that you're _not_ hiding something?

<comment><USER6> It is impossible to prove either way.

<comment><USER7> Which might prove to be a concern when Evil Men With Sticks are standing over you, trying to make sure you're not a spy.

Sounds like traveling with a wiped drive is the safest alternative.

</comment></comment></comment></comment></comment><comment><USER8> whys this guy's name in green?

<comment><USER9> <http://news.ycombinator.com/item?id=2434424> Also check out the parent thread.

<comment><USER8> hmmm. Never realized that before. Thanks!

<comment><USER10> It's an experiment, may stop happening.</comment></comment></comment></comment>


Let's not use HTTP over TCP for mobile apps anymore - <AUTHOR> https://packetzoom.com/blog/

<comment><USER2> IETF is working on better stuff – and it will be _standard_.

RFC 7413 TCP Fast Open, already deployed on Android and Chrome OS.

RFC 6824 Multipath TCP, already deployed on iOS.

And the most important upgrade: HTTP/2.

Sorry, I'm not using commercial proxies with proprietary protocols. I believe that anything as low level as transport layer shouldn't have a "pricing" link.

P.S. QUIC is an interesting experiment, maybe it will become a standard like SPDY became HTTP/2\. But UDP can't always be used... My university's WiFi just blocks all UDP completely, for example.

<comment><AUTHOR> Just to get the pricing thing out of the way, the pricing is not to license a protocol but to actually distribute app content -- from our servers worldwide. And our current customers are finding that it's pretty comparable to what they maybe already paying for such a service to other providers.

Agreed that the standards will get there at some point. And it'll be a joyous day for all. But I'll have to humbly disagree with you that TCP Fast Open or Multipath or HTTP/2 provide the answer for the mobile app use case today.

TFO will save you one round-trip for the handshake.. but that's about it.

Multipath is only available for Apple's own use the last I heard so it's not really a factor... but even if it does become available, it's still TCP.

And in both cases, TCP is still hampered by the usual problems outlined in the blogpost. No concept of a session, slow-start, exponential backoff, unrealistically long timeouts etc. etc.

I guess the meta point here is that TCP is designed for the general case and it's great for what it is meant for. But by narrowing the use-case to native mobile apps, one can constrain the problem domain and gain more freedom in what you can design.

</comment></comment><comment><USER3> It all sounds very interesting, however, the tone of the web site comes across like some crappy download accelerator. When you follow the "nerdy details" link you don't get anything meaningful, just bland assurances and pretty animations, i.e. entirely non-nerdy. Nowhere do I see basic technical info like "It's a new IP transport protocol used in place of TCP", or "It's compatible with existing networks because...", or "It's (better than|different to) (HTTP/2.0|QUIC|SPDY) because...".

The discussion here, while short, has been much more informative than the site itself. I don't see any good reason to dumb-down the site like that - you're selling a protocol layer, so you're not going to have any non-nerdy customers!

Why are resumable downloads done in that layer? I have no trouble with downloads resuming across network switches when handled by higher-level protocols like chunked HTTP or even FTP.

Similarly, why would you even think about bundling multiple resources in one transfer at that level? Surely that's a higher level thing (like HTTP/2.0), and thus independent of transport? There appears to be a lot of layer-leakage going on - not that it's necessarily bad, but the reasons for it need to be clearer.

<comment><AUTHOR> _" It all sounds very interesting"_

Thanks. I'll take this positive beginning at face value :-)

 _" Nowhere do I see basic technical info like "It's a new IP transport protocol used in place of TCP", or "It's compatible with existing networks because...", or "It's (better than|different to) (HTTP/2.0|QUIC|SPDY) because..."_

I'm sorry if the material on the site is not technical enough for your taste. We've just launched and consider the site and the blog a work in progress. (Follow us on twitter at @packetzoom and me personally at @IAmChetanAhuja for updates).

Having said that, our customers are not necessarily people following the network protocol worlds closely. The stuff that you find "bland" and "pretty" is actually very helpful for a large portion of our target audience.

Now of course, those who click on the "Learn" link and don't find enough in- depth info are welcome to, and do, contact us directly. Every single mail we get on info@ or support@ addresses is read by a human in our (rather small) team and yes, we respond. Just as I'm responding to more detailed technical questions here.

 _" You're selling a protocol layer, so you're not going to have any non-nerdy customers!"_

No we're not selling "a protocol layer". We're selling a drop-dead simple way to speed up downloads. Some of our customers are more interested in details of the protocol than others. But the majority of them want their apps to be fast and couldn't care less about, or even want to know about QUIC/SPDY/HTTP2.0 or whatever. Their questions are more like -- How easy is it to integrate? (very). Do I have to rewrite my code? (No). What do I have to change on the server side? (nothing).

And those of our customers who do want to go in-depth into details of the technology, do. They just talk to us and we explain what we're doing to the extent it doesn't reveal trade secrets.

 _" a lot of layer-leakage going on - not that it's necessarily bad, but the reasons for it need to be clearer"_

This seems to be the crux of your issues with what we're doing. The reasons are ultra clear to us. Apps are faster and users are happier. That the only thing that matters.

We've found that merging layers allows us to handle, say, out of order delivery or dropped packets more smartly and more naturally. For far too long, user experience has been held hostage to diktats from the ivory tower. It's about time we start thinking from the ground up to create technology suited to what the users needs and not because we want to maintain some platonic ideal of "layer separation".

</comment></comment><comment><USER4> I have seen a demo and there was a huge speed increase (the app loaded content much quicker) with their technology. Is it the perfect solution? I have no idea, I am not a network person. But if you are looking to speed up your app I would check it out.

My big question is price, do I need to be a big company to afford this? It seems like it could get expensive.

Yes there are other people (as floatboth and jhugg pointed out) working to solve the same problem, but that is awesome! I want some competition, companies pushing the limits, standards organizations making it work everywhere and academics researching it. Who knows maybe one day my phone will load content so fast that I believe ATT really does have 4g in my area

<comment><AUTHOR> _" Who knows maybe one day my phone will load content so fast that I believe ATT really does have 4g in my area"_

Heh... let's start with acknowledging a pretty good burn right there.

And thanks for the vote of confidence. Much appreciated.

As for price, we're working with a whole bunch of customers right now who've been using various solutions for serving content from the cloud (aws, cloudfront, CDN's... what have you) and they find the price to be comparable to what they're already paying. In addition, they find as users find the app experience more pleasant, the engagement goes up.

Note that as an app starts using our system to do content delivery, our caching proxy means that your other backend bandwidth bills drop off. So overall, most customers find us very affordable for the value they get.

</comment></comment><comment><USER5> So, if I understood correctly:

If I use an HTTP 1.0/1.1 with PacketZoom, I'll be communicating on the internet with HTTP 1.0/1.1 over PacketZoom?

What if I want to communicate on the internet with other protocols such as WebSocket, SPDY, or HTTP 2.0? Does it work the same way?

<comment><AUTHOR> Actually the way it goes is, the application code makes some HTTP calls through common libraries and Packetzoom framework, if linked in the app, can intercept these requests and reroute them to our proxy through packetzoom's own protocol. So we're not intercepting any particular wire protocol as such... the interception happens at a higher level. So your existing stack shouldn't matter.

</comment></comment><comment><USER6> Does it do anything to solve router congestion when it does happen and how can it tell the difference? Cell towers are often bandwidth limited on their uplinks; is this protocol going to out-compete TCP for bandwidth and slow everyone else down?

<comment><AUTHOR> Currently we're focusing on the download portion of the transfer so I'd refrain from commenting on the uplink protocol for the time being.

But the general question about router congestion handling is a valid one. And the answer is No, we're not just flooding the network with a blast of packets. Apart from anything else, that strategy is full of fail for throughput anyway. Since a busy router will likely generously drop packets from the UDP queue before it loses stuff from the TCP queues.

So we rely on precise knowledge of network conditions at a fine grained level (the grain gets finer as we add more users to our network) to utilize the available bandwidth. We also use other techniques to predict queue congestion on the network path _before_ it gets to the level of dropping packets. Note that (most) TCP implementations _rely_ on packets loss to discover usable link capacity. We don't! One of the advantages of creating your own protocol is that you can use the state of the art research in congestion control strategies without being constrained by legacy concerns.

The upshot is, our protocol is actually fairer to competing traffic compared to TCP on the whole. Hope that alleviates your concerns.

</comment></comment><comment><USER7> Totally lazy commenting by me here, but isn't there a mobile shell that was designed to work well over high latency, iffy connections.

This? [https://mosh.mit.edu](https://mosh.mit.edu)

Maybe we're talking about the same problems.

<comment><AUTHOR> Hey it's not lazy if you actually found the link ;-)

Yeah I've used mosh and it comes under the general category of UDP based protocols (of which, there are many). The purpose of designing the PacketZoom protocol (and it's attendant infrastructure) is to design something particular _for_ the mobile native apps use case. Including things like app session based sessions, moving around between networks without breaking the session, take a single round-trip to setup the session and zero round-trips thereafter to start file transfers etc.

And then, once the transfers are started, taking care of the packet drops with a more measured backoff and retransmit policies than are available with TCP. E.g., PacketZoom protocol packets don't have to arrive in order. The receiving side can send feedback back to the sender with an exact list of what packets went missing. The sender can then make decisions about backoff on not just the fact that a packet dropped, but how many and in which locations.

Lots of other details like this allow us to handily beat TCP in all varieties of networks all over the world in speed and user experience.</comment></comment>


I'm dyslexic and I program - <AUTHOR> http://vicapow.tumblr.com/post/36035742233/im-dyslexic-and-i-program

<comment><USER2> A friend of mine is dyslexic, and he coded a disk mirroring program in a weekend way back in high school.</comment>


What the Boeing-747's troubles mean for airlines and other planemakers - <AUTHOR> http://www.economist.com/news/business/21569746-what-dreamliners-troubles-mean-airlines-and-other-planemakers-bad-dreams-all-round?fsrc=scn/fb/wl/pe/Baddreamsallround

<comment><USER2> "Japanese firms make about 35% of the Dreamliner, under a novel system of global outsourcing that cost it years of production delays."

This is not "novel," Boeing has been doing this for decades.

I also doubt that this outsourcing _itself_ is responsible for the delays, but I don't know.

</comment><comment><USER3> The venerable 747 series has troubles too, in addition to the Dreamliner? You probably mean 787.</comment>


Keras and He and Adam Breakthrough - <AUTHOR> https://obilaniu6266h16.wordpress.com/2016/04/12/keras-he-adam-breakthrough/ <comment><USER2> The author's name struck a chord. Turns out that he is likely a great-nephew (and name-sake) of a physics professor of mine many years ago. [0]

[0] [http://oleksabilaniuk.blogspot.com/2009/04/oleksa-myron- petr...](http://oleksabilaniuk.blogspot.com/2009/04/oleksa-myron-petrovych- bilaniuk.html)

<comment><USER3> Indeed I am his great-nephew and namesake! Impressive of you to connect the dots!

<comment><USER2> Memory quirks – a memorable name, combining with internet search.</comment></comment></comment>


Are Google and Samsung Announcing a "Nexus Two?" - <AUTHOR> http://www.readwriteweb.com/archives/are_google_and_samsung_announcing_a_nexus_two.php

<comment><USER2> I'm betting it's just that new Verizon phone with the useless second LCD. I spoke with someone months ago at Google who said they were working on a "Nexus Two" device, but he could have been referring to the G2 for all I know.

Here's what I've been waiting for in an Android phone since they started pumping them out: thin, no keyboard, responsive touchscreen, iPhone4-quality camera, accurate GPS and stock Android or easily rootable. Pretty much, I don't want any compromises, and no one seems to want to do it. Every single model skimps somewhere. If it's got a nice camera, the GPS doesn't work. Otherwise, the camera is crap or it's 3/4 of an inch thick with a keyboard I won't use. The Nexus One is so close, but the touchscreen sucks and the camera is beyond terrible.

<comment><USER3> +1 for stock Android. I sure as heck don't want carrier modifications. Note to carriers: your job is radio frequencies and call routing. That's all I want you for. You are not a software company. It sucks to be a commodity, but it sucks more to be an anchor on an airplane, which is what you are for the quality of your phones. Give them a connection and free reign.

<comment><USER4> I was under the impression that the carriers and manufacturers modified their phones so they could differentiate themselves. There's the revenue opportunities, sure, but they have to do something to stand out.

Now here's the crazy part: no one is selling a device with stock Android. If your phone was straight Android 2.2, it wouldn't look like any other phone on the market. The minute Motorola or LG realize this, they get 100% of the nerd phone market.

<comment><USER5> It's usually not up to Motorola or LG. It's the carriers that add (or ask to add) these additional/non-stock features. I'm curious what the state of Android is outside of the US - do carriers in other countries add the likes of V-Cast or a NASCAR app?

<comment><USER6> In Australia, the biggest carrier Telstra generally adds a tonne of crapware, and several people I know with htc desires have links to various telstra features that are broken on the default firmware. I seem to recall the reason telstra didnt get into the iphone game until significantly after the other carriers was because of the iphone impeding sales of telstra 'services'.

We also have the more budget oriented virgin mobile who have generally little to no customization depending on the phone.

</comment></comment></comment></comment></comment><comment><USER7> I certainly hope so. And it makes sense that they'd focus more on Europe this time, which hasn't been as infected with phone subsidies and lockins as the US has.

<comment><USER8> what makes you think it would be focused on europe? the event is in NYC.

<comment><USER7> Not Europe exclusively, but more available there, as indicated by the potential Carphone Warehouse deal. IIRC Google didn't sell the Nexus One directly to Europeans, even though they're much more willing to pay up front for unsubsidized phones than Americans are.

</comment></comment></comment><comment><USER9> I hope it has a keyboard and a front facing camera.

Those are the two differentiators I'm looking for to pick an android phone.

<comment><USER10> I like the front facing camera idea, but I actually hate having a physical keyboard on my phones nowadays. Seems to just make the phone bigger and heavier. I also had the original Verizon/Motorola droid which had a completely worthless excuse for a keyboard. Perhaps that soured me on physical keyboards.

Now that I have Swype, not to mention the normal android keyboard, I'm pretty satisfied.

<comment><USER9> Well, I want the phone also as a mini laptop. I read that it's hard to do things like ctrl-s on the virtual keyboard.

<comment><USER11> Is a bluetooth mini-keyboard good enough?

<comment><USER9> It might be actually. Are they small enough that I can fit both the phone and the keyboard together in my pocket?

Wouldn't it be smaller if the keyboard was integrated into the phone?

</comment></comment></comment></comment></comment><comment><USER12> Two things killed the Nexus One for me: 1\. Two versions of the device. I travel to the UK a lot and I wanted to pick up a Nexus One so I wouldn't have to unlock my iPhone. Being forced to choose between 3G in the US (on AT&T) or 3G in the UK made me choose neither. 2\. Skype is a Verizon exclusive. Yay artificial fragmentation!

#1 can hopefully be fixed by the Nexus Two. Not so sure about #2.

<comment><USER13> What aspect of skype is Verizon only? It's in the marketplace for me, and I'm on Sprint.

</comment></comment><comment><USER14> I'd like to see a front-facing camera but what I need the most is larger internal memory.

I want to install more apps but with Nexus One's meager 512MB flash memory, I hit the limit already. Now, I don't even install apps that are more than 2MB. A lot of developers also have not enabled SD card storage for their apps.

</comment><comment><USER15> What? They can't even put a reliable date on Froyo for the Galaxy S line in the US but they're already shifting resources to a new hotness?

Could this be interpreted as a call to abandon the Galaxy S ship?

<comment><USER16> For what it's worth, Engadget's original article about the Samsung press event suspected that it would announce the Samsung "Continuum" - a Galaxy S branded phone with two OLED displays. Considering the stock tickers in the background of the press image, and the fact that the secondary OLED display on the Continuum is called the "Ticker", I think this makes the most sense: [http://www.engadget.com/2010/10/25/samsung-to-unveil-new- and...](http://www.engadget.com/2010/10/25/samsung-to-unveil-new-android- device-november-8th/)</comment></comment>


The Auto-Pilot iPad App - <AUTHOR> http://www.popularmechanics.com/technology/gadgets/reviews/the-auto-pilot-ipad-app <comment><USER2> Austin is the author of x-plane, an FAA certified flight sim. It's the only sim that actually calculates lift and drag available to consumers. MS flight sim is just a joke relying on rubber-band type lookup tables. If there's anyone who can do it, it's Austin.

However, relying on the ipads gps and gyros seems like a poor choice. I wouldn't trust the ipad to have the necessary precision to pull off a landing. If you could interface the ipad with onboard GPS/gyro's then I'm all for it. The ipad has a plenty fast cpu for this sort of thing. But then so does a 286. or a PCjr for that matter.

<comment><USER3> I think the iPad's GPS is just to find a nearby waypoint as a starting point for the automatic approach and landing. Once you have decided upon a route, it's a simple matter of tuning the aircraft's nav radio to the VOR or ILS. From there, you have the full precision that you would normally have on an instrument approach/landing. The innovation is that the passenger doesn't have to know what an instrument approach is.

(I wonder if the code on the iPad gets the audio stream from the radio so that it knows it's tuned to the right channel.)

As an aside, I've read on the X-Plane forums that X-Plane doesn't actually do a full simulation as you say it does. If you try to spin the default C172, for example, you can't do it, because the aerodynamics near the boundary cases are not calculated correctly. (Either that, or the spin recovery for a C172 consists of letting go of the controls and waiting, which is not what the manual says. But I have not tried it.)

<comment><USER4> A 172 will recover from an upright (non-inverted, non-flat) spin by simply centering the flight controls and waiting.

Anti-spin inputs (power idle, center controls, opposite rudder, elevator down) make the recovery much quicker, but I was taught (and shown) that if you don't know which rudder to use to stop the spin, to just center the controls and the 172 will stop spinning on its own.

Disclaimer: I'm just a pilot and not a CFI; if you go spin one into a smoking crater following procedures other than the book, don't blame me, etc.

<comment><USER3> Interesting. Hopefully I will get to try this in the not too distant future :)

</comment></comment></comment></comment><comment><USER5> From the App Store Review Guidelines,

      4.2   Apps that use location-based APIs for automatic or autonomous control of
            vehicles, aircraft, or other devices will be rejected

Hmm...

<comment> X-Istence But if it connects to the aircraft, it could use the aircrafts instruments, at which point it doesn't use the location based API's :P

</comment></comment><comment><USER6> Very neat idea, but good luck with getting FAA approval.

This will probably count for a whole new type of approach: an automated mostly-hands-free 0-0 landing.

Even if it's just for an emergency, and even if you make all kinds of disclaimers and have folks sign all kinds of documents, you'd have better luck teaching monkeys to play in an orchestra than you'll have trying to use this legally in an airplane.

Of course, you can always sell it and say it's for "demonstration purposes only" or some kind of silly shit like that. But still, anything to do with certificated airplanes has this crazy no-risk bar that makes it almost impossible to implement.

There's a reason why planes work pretty much the same now as 50 years ago, even though technology has vastly changed. The industry and government regulators are almost (but not totally) impervious to change. Lots of lawyers filing lots of lawsuits for doctors who bent their Bonanzas have seen fit to that.

<comment><USER2> You can legally test and use this on experimental-amateur built aircraft. Which is what Austins Lancair evo is.

</comment></comment><comment><USER7> If that product doesn't get certified, there's probably an opportunity to integrate that feature in existing glass cockpits. I mean, why not a "Land Safely" red button on the passenger board? The reliable autopilot/GPS/software is already here and certified, + then you don't need an iPad for it!

</comment><comment><USER8> I prefer Otto:

<http://www.imdb.com/name/nm1290293/>

</comment><comment><USER9> Let's be honest here. How many times is this really a concern? Why would the FAA approve use of something like this and why would I install it when the chance of use is probably extremely rare?

Seems like too much trouble than it's worth.

<comment><USER2> Have you seen the cirrus aircraft? Unskilled, but rich people are willing to pay > $500K for a plane with a parachute and a button that auto-rights them.

The result is a 6x fatality rate compared with the average for general aviation. That's including some horribly twitchy aircraft in that average.

<comment><USER10> The envelope that ballistic parachutes provide a life-saving emergency resolution vs a well executed power-off glide is pretty narrow. The studies show that far too often it is abused by providing a false sense of security, encouraging pilots to take risks they otherwise wouldn't have.

<comment><USER2> Yup. It doesn't help that they use the parachute to sell to nervous but status conscious celebrities/generic-rich-guys.

The cirrus is a terrifying plane[1], whenever I see one coming I run for my life. You should too.

1\. In the hands of a trained pilot, flown for the long range missions it's designed for it's a fine plane. But 90% of the people buying these things aren't well trained, don't have the experience and don't do the sort of flying appropriate to the Cirrus.

</comment></comment></comment></comment><comment><USER11> I don't see why this software is written on an iPad when it could be implemented more effectively in the plane's own control system.

<comment><USER2> You don't get to run apps on the planes EFIS systems. They're sealed, controlled units for /very/ good reason.

Aircraft aren't like hacking on some webapp, you don't move fast and break things. You test, test, validate, prove, test then finally ground test. Then test in parallel in the air. then expand envelope, only then do you get to think about relying on it.

<comment><USER11> > Aircraft aren't like hacking on some webapp

Exactly, so why do you want to have an iPad control an airplane? Wouldn't it make sense to add this to the EFIS systems so that the code is held to the same standards as any other flight system?

The fact that a device can link directly to the plane's control system will lead to numerous, potentially deadly exploits.

<comment><USER12> Seems like the fact that a device can link directly to the plane's control system has lead to a potentially-very-useful development that wouldn't be possible otherwise.

What danger is there in allowing things to connect? There's plenty of advantages, from making your own specialized sensor displays to making autopilot algorithms, but what's the disadvantage?

</comment></comment></comment></comment><comment><USER13> I think this is actually against the license of the iPad's OS

I predict it may get pulled from the store.</comment>


Ask HN: Fishy Travel Post-Booking Request - <AUTHOR>

This is my first post on here, but I thought it might be interesting. Here's the skinny:
Two flights were booked with an online service, let's call it "Woohoo". The name on the credit card used in the transaction was the same as the name on one of the tickets. This person also purchased a ticket for a second person.
From my experience using any service to book flights online, they simply send a confirmation email and ticket combo.
So here is where things went fishy. They sent an email with a subject saying "3rd PARTY URGENT - CREDIT CARD AUTHORIZATION REQUIRED FOR BOOKING". The entire structure of the email is very poor and unprofessional (only writing, no logos, varying size of font, 3+ font colors, CAPS, *, etc). Now the smelliest bit of info in this email is as follows:
__________
By accepting the terms and conditions during the reservation process, you have agreed to submitting the following required information.
In order to release the tickets we require all of the following information faxed or scanned and emailed:
From the credit card holder: 1) A legible copy of a photo identification.  We will only accept the following: Valid Passport or Valid Drivers license 2) A letter stating that the cardholder (by name) is authorizing WOOHOO to charge the credit card on behalf of the passenger travelling (by name).  The booking number and the amount to be charged must also be in the letter. 3) A legible signature from the cardholder must also be present on the letter. 4) A legible copy of credit card used front and back
From the passenger: 1) A legible copy of a photo identification.  We will accept the following: Valid Passport, Valid Drivers license or Valid birth certificate.
This information must all be faxed to XXX-XXX-XXXX attn: Web Department
You can also scan and email the information to email@example.com __________
What's your thoughts? I can vaguely imagine the need for such a confirmation, but it looks shady! Imagine a page including a valid identification of you, the front and back copy of your credit card, and your signature getting into the wrong hands. And also, the thought of faxing a page like this is troubling. I'm under an assumption that "reputable" online companies will protect customer credit card numbers in a fairly thorough manner, but it's acceptable to fax this info along with other valuable info...? I wonder what their security is like around a fax machine.
Let me know if I am out to lunch on this, otherwise, how would you handle this? Hope this was interesting and sorry for the novel :) <comment><AUTHOR> Turned out for the worst. This wasn't someone working their end of the system. This is an actual practice of their because of fraud in the past. Supposedly this confirmation allows them to sleep better at night.

Not very impressed. I thought companies were not allowed to keep records of a customer's credit card number? Wouldn't this be breaking that very rule and than some?

</comment><comment><USER2> Sounds fishy enough to me that I'd back out of this transaction and book with another company.</comment>


The Dunning-Kruger effect is (mostly) a statistical artefact - <AUTHOR> https://www.sciencedirect.com/science/article/abs/pii/S0160289620300271?via%3Dihub#f0005 <comment><USER2> Social psychology is one trainwreck.

Almost everything we thoght we learned from it sooner or later does not replicate

</comment><comment><AUTHOR> The full title is "The Dunning-Kruger effect is (mostly) a statistical artefact: Valid approaches to testing the hypothesis with individual differences data" which is too long to fit in the title bar.</comment>


What killed the dinosaurs? Dark matter, says theoretical physicist Lisa Randall - <AUTHOR> http://www.theage.com.au/world/what-killed-the-dinosaurs-dark-matter-says-theoretical-physicist-lisa-randall-20151210-glkwt9.html <comment><USER2> The perils of science reporting:

"That was a 18-metre-wide chunk of space rock weighing 10,000 metric tons. By way of comparison, the meteor that hit the Yucatan 66 million years ago was more than 14 kilometres long.

That may not sound like a big difference in size, but you're forgetting about Einstein's famous equation for translating mass into energy."

Einstein's famous equation (e = m * c^2) isn't relevant. The equation for kinetic energy is relevant: e = 0.5 * m * v^2.

The issue is mass. 18 meters is roughly 1/1000 the size of the Chixclub asteroid. Therefore, since mass is related to the cube of the average radius, the dinosaur killer was roughly 1,000,000,000 times more massive - and the same factor applies to the released energy.</comment>


What Should We Call the Language of Mathematica? - <AUTHOR> http://blog.stephenwolfram.com/2013/02/what-should-we-call-the-language-of-mathematica/ <comment><USER2> Without even reading it (and avoiding looking at the comments here), I predict that he'll advocate 'Wolfram'.

Edit: Yep... <http://imgur.com/KRyN97S.png>

I love the ramp up, first it's just mentioning that the name of the company is Wolfram... then going underground before coming out, in bold, with Wolfram Language, then four paragraphs before concluding that "At this point, we pretty much have to have 'wolfram'—or at least some hint of it—in the name." and there goes the rest of the article.

Why not just call it Wolfram and be done with it. We know there's a big ego involved and we can't possibly bear Stephen Wolfram strain himself so much as to not name the language after himself. Anything else would be inhumane :)

And considering the good he's done with both the quality product Mathematica and Wolfram Alpha, it's only justified.

<comment><USER3> Am I missing something or is that just a surreal picture?

<comment><USER4> I think it's marking the positions of the word 'Wolfram' on the document.

</comment></comment></comment><comment><USER5> Wolfram has written a lot of egotistical, boring things before. I have to give it to him: this time he's outdone himself.

Why not just outsource the naming to a flunky and then take credit for it if s/he comes up with a good one?

</comment><comment><USER6> As far as I was aware everybody was already calling this language "Mathematica".

<comment><USER7> With projects like Mathics[1], that aim for Language compatibility with Mathematica, on the horizon it makes sense to want to separate the language from the implementation.

[1] <http://news.ycombinator.com/item?id=5196551>

<comment><USER8> Seeing this post hit HN just a few days after Mathics gave me a paranoid feeling. Why now? Is Wolfram feeling the heat and looking for a new trademark to deny his competitors?

<comment><USER9> And Mathematica 9 just came out, so maybe it was _Mathics_ feeling the heat! Despite the vacuum-like nature of our internal HN-eval-post loop, the rest of the world isn't standing still. It's actually a little surprising that they're only talking about this _now_ , given how long Mathematica has been around.

</comment></comment></comment></comment><comment><USER10> good post, but it seemed like he dismissed "tungsten" far too lightly ("And in the direction of whimsical, there are also words like Tungsten"). it seems like the best choice to me - it has the "wolfram" association, as well as fitting in with the general mineral theme while differentiating itself from the gemstone cluster. also it's easy to pronounce and rolls off the tongue fairly readily.

<comment><USER11> You beat me by one minute. Tungsten works for me.

<https://en.wikipedia.org/wiki/Tungsten> \- "Tungsten, also known as wolfram... the free element is remarkable for its robustness, especially the fact that it has the highest melting point of all the non-alloyed metals and the second highest of all the elements after carbon. Also remarkable is its high density of 19.3 times that of water, comparable to that of uranium and gold, and much higher (about 1.7 times) than that of lead.... It is the heaviest element known to be used by any living organism."

Not bad.

</comment></comment><comment><USER12> Egotistica. (ld;o)

</comment><comment><USER13> I wouldn't have been surprised to learn it were already named Lingua Mathematica, and I submit that as the best reason to give it that name (and not some other).

<comment><USER13> I thought the grammar might be wrong there, and it turns out, it is:

[http://english.stackexchange.com/questions/103916/it-were- ve...](http://english.stackexchange.com/questions/103916/it-were-versus-were- i-the-proper-subjunctive-for-this-statement)

The corrected versions are: "I wouldn't have been surprised if it were already named Lingua Mathematica..." or "I wouldn't have been surprised to learn it was already named Lingua Mathematica..."

</comment></comment><comment><USER14> I propose "Stephen"

I have found Mathematica to be super simple learn and use, so by calling it "Stephen" it shows how friendly and approachable the language is while maintaining the connection to the founder's ego.

<comment><USER15> I've never heard anyone refer to Stephen Wolfram as "friendly and approachable," and naming the language based on that reason would be both amusing and disturbing.

<comment><USER16> I, for one, don't remember Mathematica being especially "friendly and approachable" either. Maybe for basic stuff, but my introduction to it was a grad-level computational neuroscience class, and it was the source of a great deal of misery in my life for a semester.

Maybe for amusement value it /should/ be named Stephen.

<comment><USER14> This is a common complaint, but I don't understand it. Most of my peers that didnt like it had no exposure to programming, though.

I have tried to teach myself Ruby and Python before but I have never gotten really far. I am pretty competent in Mathematica though. The key is getting used to their documentation center where they have lots of examples.

</comment></comment></comment></comment><comment><USER17> How about "Leibniz" in honor of the mathematician who independently invented calculus and, compared to Newton, used a superior notation (which he took great pains to make nice)

Or, Zinbiel.

<comment><USER2> I'd agree, but unfortunately "Leibniz" is not, nor does it rhyme with or even allude to "Wolfram" and is therefore out of the running.

</comment></comment><comment><USER18> I think Aleph is nice name. There is already Wolfram Alpha, and Aleph, while it is related to it, is IMO more appropriate for general purpose language.

It sounds to me mystical and abstract/mathematical at the same time as it reminds me of Blaise Pascal's definition of Nature (or God) as "an infinite sphere, whose center is everywhere and whose circumference is nowhere" (because Jorge Luis Borghes has a story with the same name in which he cites the Pascal's quote :)).

</comment><comment><USER19> Wolfram prefers "Wolfram." Telling.

</comment><comment><USER20> A New Kind of Language

</comment><comment><USER21> One of the names he dismissed is actually a pretty good word to use to describe the blog post: Wolframble.

</comment><comment><USER22> Ego.

</comment><comment><USER23> M

<comment><USER24> W

<comment><USER25> There is already a programming language called W [1]. It's not related to the language of Mathematica but you could say has a little bit of relevance to scientific computing since it was created for the HP-95LX and the HP-200LX DOS-powered programmable calculators.

I used to have a decent collection of subroutines for it.

[1] <http://www.vttoth.com/CMS/index.php/projects/49>

</comment></comment></comment><comment><USER26> My December PLT Game's entry was actually called Wolf: <https://github.com/JD557/Wolf>

Thank god he didn't chose that name, then I would be the one that would need to think of a new language name.

Anyway, as stated in other comments, Tungsten seems like a nice choice.

</comment><comment><USER27> 1\. Mathematica or 2\. Just pick a random cool name, how about: pipe | (they use pipe in wolfram|alpha)

</comment><comment><USER28>
        > In the years since, the name Mathematica has been widely imitated (think Modelica, for example).

...or Metallica, for example.

Seriously, isn't sticking 'a' (or 'ica') onto the end of a word some kind of Latin thing?

Britannica!

<comment><USER29> The Romans were just copying Stephen Wolfram.

<comment><USER30> They were pre-covering him. Like all the pre-covers of the songs from Glee....

</comment></comment></comment><comment><USER31> To me, "language" implies freely available to use. This is not a critique of mathematica nor its pricing, but merely when I think of "computer language" I think of python or c++ or java etc.

</comment><comment><USER32> Ask Umberto Eco <http://books.google.co.uk/?id=2sDMxqbibS0C>

</comment><comment><USER33> FORMATH!

<comment><USER34> FORGREATJUSTICE!

I'll get me coat.

</comment></comment><comment><USER35> Why not return the favor and call it "Jobs"?

</comment><comment><USER36> "Steve" would have been better, as a nod to both men.

</comment><comment><USER37> Mathematicall

</comment><comment><USER38> "Wolf"?

</comment><comment><USER39> Wolfie ?

</comment><comment><USER40> Mash

<comment><USER21> Weird, that's the name of a language I worked on at a former job. It was seriously awesome, it was like a functional version of Python mixed with assembly, and was much clearer and also faster than C++. Shame that it will probably never see the light of day (though I have plans for a similar replacement).</comment></comment>


Measuring UX testing improvements using Google Analytics - <AUTHOR> http://whatusersdo.com/blog/measuring-ux-testing-improvements-using-google-analytics/ <comment><USER2> I am using Hooked model to improve UX which I am doing. It is because it can not be said that improvement has been achieved unless the user keeps using it. In the measurement, we set the action contents of the user (creation of account, preview of music, etc.) as tasks and set it as "Time on Task Rate", "Error Occurrence Rate", "Task Success Rate".

Measurement tools use Google Analytics and BI Tool / Tableau.

I think that this method is the best for now, but is there any other good way?</comment>


Meet the Insane People Still Planning Cruise Ship Vacations - <AUTHOR> https://www.thedailybeast.com/meet-the-insane-people-still-planning-cruise-ship-vacations-despite-coronavirus <comment><USER2> My parent's are on a cruise right now. They were told that people from certain countries would not be allowed on the boat. This announcement was after they booked, which was before everything got crazy.</comment>


Drawing Entrepreneurs to Canada: Entrepreneur Visas - <AUTHOR> http://www.bcbusinessonline.ca/2011/04/04/welcoming-entrepreneurs-to-canada <comment><USER2> "We have a lot to offer startup founders, including a beautiful environment, multicultural society, publicly funded health care and a strong economy"

This mindset seems to be a big part of the problem. There's apparently a mindset amongst we Canadians that people should want to come to Canada simply because we're so great. We're like America, but not as screwed up.

We fundamentally miss the point in being so self-congratulatory. When trying to attract tech entrepreneurs, why not stress the thousands of students graduating from schools like UofT, Waterloo, McGill, UBC, and the like? Streamlining visas and making them internationally competitive is one thing, but why do we consistently try to sell Canada on quality of life when trying to attract entrepreneurs? We should be focussing on why Canada is a great place to start a business, and fixing whatever issues prevent it from being one.</comment>