GCC Receives ACM's 2014 Programming Languages Software Award - <AUTHOR> http://rhelblog.redhat.com/2014/07/25/gcc-receives-acm-award/ <comment><USER2> LLVM received this award back in 2010: [http://www.sigplan.org/Awards/Software/2010](http://www.sigplan.org/Awards/Software/2010)

</comment><comment><AUTHOR> Bad timing with Linus rant eh?

<comment><USER3> The timing is odd, but not because of that particular bug.

I think the past several years have been a rather low point for GCC. It hasn't been as bad as the 1996-1999 period of stagnation and strife, mind you, but it hasn't been particularly good, either.

LLVM and Clang have offered the first real competition that GCC has had to face in a long time. We've actually seen Clang be the leader in some cases, offering improvements that have then been implemented in GCC sometime later (like better diagnostics, colored diagnostic messages, the use of C++, etc., etc.).

Meanwhile, we haven't really seen anything truly compelling come out of GCC camp. Recent versions of have offered some optimization improvements, but nothing earth-shattering (in a good way). Its C++11 and C++14 support is quite good, but so is Clang's. The Go front end might be the most interesting development, but Go isn't a particularly interesting language, and GCC's version lags that of the main Go implementation.

I could see an award perhaps being deserved after successfully coming back from a period of stagnation like we've seen, after delivering several positive and revolutionary changes in a short period of time. But small, incremental improvements, or merely catching up with competitors, doesn't seem all that remarkable.

<comment><USER4> While it has many advantages, clang still isn't as robust as gcc ( e.g. [http://clang.debian.net/](http://clang.debian.net/) ), and the code it produces can be slower ( e.g. [http://openbenchmarking.org/result/1404144-KH- CLANG359076](http://openbenchmarking.org/result/1404144-KH-CLANG359076) ) I guess clang is still a few decades of testing and tuning behind gcc, though it's catching up fast.

<comment><USER3> I don't think those results really support the point that you're trying to make.

The top result, which is the most significant, is pretty much irrelevant, for example. It's limited to Haskell-related packages. Most Debian users have absolutely no reason to use those packages.

After that, we start running into rather obscure options that only GCC supports, or bad code that GCC accepts, or code that's just bad in general, or extremely obscure packages that very few people would ever consider using. These don't indicate a problem with LLVM or Clang.

The fact that FreeBSD managed to very successfully switch to Clang for compiling the kernel and base system, and the fact that it's very widely used on OS X, suggests to me that LLVM and Clang are more than robust enough for everyday use.</comment></comment></comment></comment>


ChromeKit: HTML5+CSS3 window chrome. - <AUTHOR> http://github.com/guille/chromekit

<comment><USER2> It's a curious thing that (over the years) so many people have attempted to bring the desktop window managing experience into a web browser. More and more I've found myself going the other way and wishing for less window management on the desktop.

<comment><AUTHOR> And I agree. This was more on the experimentation side (my main driver was to experiment with the Expose algorithm), and almost exclusively a weekend project. It does have some interesting use cases, but to drive your entire application with a window managing experience would be a mistake.

</comment></comment><comment><AUTHOR> Quick link to demo: <http://devthought.com/wp-content/projects/chromekit/>

</comment><comment><USER3> For a minute there I thought someone modified WebKit so the browser widgets that are normally drawn from a toolkit (GTK, Cocoa, etc.) such as scroll bars, buttons, text boxes, etc. were actually created with CSS/HTLM/Javascript.

</comment><comment><USER4> I don't like the naming choice, too close to Google Chrome Browser + WebKit

<comment><USER5> True, but both "chrome" and "kit" are common in dev lingo, unrelated to WebKit or Google Chrome.

</comment></comment><comment><USER6> This project should give Apple a slap in the face. Banning desktop-like apps will be impossible with this. I applaud you! I agree that ChromeKit (or whatever you will be calling it) should be used with care as to not become bothersome. I wish you luck in your endeavors.</comment>


Chrome extension - Attach files from the cloud to Gmail using Filepicker.io - <AUTHOR> http://blog.filepicker.io/post/34647502499/chrome-extension-attach-files-from-the-cloud-to-gmail

<comment><USER2> Does not work with the new Gmail compose window...

</comment><comment><AUTHOR> Alex hijacking Gmail's obfuscated Javascript logic is impressive.</comment>


Apple Factory Thefts: Secret Tunnels, Hidden Crawl Spaces - <AUTHOR> https://www.theinformation.com/articles/inside-apple-factory-thefts-secret-tunnels-hidden-crawl-spaces?pu=hackernews11vvpt&utm_source=hackernews&utm_medium=unlock <comment><AUTHOR> Hi everyone, Jay from The Information here. We have unlocked this article specifically for the HN community. Enjoy!

<comment><USER3> Yay! I saw the URL posted on Macrumors and planned on posting it here in the hope of you coming here and unlocking it, but you beat me to it :-).

</comment></comment><comment><USER4> Thanks. Good read and has a new twist in the trade espionage era - <USER2> clearly aaple started doing this before these issues to maintain the surprise factor at event launches. reply</comment>


Ask HN/PG: What does the name Y Combinator mean? - <AUTHOR>

Why the name "YCombinator? <comment><USER2> <http://en.wikipedia.org/wiki/Fixed_point_combinator>

</comment><comment><USER3> <http://ycombinator.com/faq.html>

_Why did you choose the name "Y Combinator?"

The Y combinator is one of the coolest ideas in computer science. It's also a metaphor for what we do. It's a program that runs programs; we're a company that helps start companies. _</comment>


The watch Command (2007) - <AUTHOR> http://www.linfo.org/watch.html

<comment><USER2> how the fuck does this make the front page</comment>


Facebook Apps Must Now Ask Users for More Specific Permissions - <AUTHOR> http://mashable.com/2010/06/30/facebook-app-permissions/ <comment><USER2> This sort of system never seems to work in practice.

Very quickly you get to a point where every app asks for so many permissions it does not need. You end up just "clicking through" the installation without much thought.

Either developers are lazy or just want to be on the safe side.

Every Android app that I have downloaded requests network access (Even simple games do!), contacts access and tons of other capabilities. I suspect most users just learn to ignore these requests and blindly install the application...

<comment><USER3> You might also not want to _murder_ your MAU by upgrading your app in such a way that your permissions would broaden, causing every user to get BIG SCARY WARNING CLICK TO DENY.

Incidentally, we are seeing -- again -- that people's beliefs about how much they value privacy ("Privacy is important to me: 9 out of 10.") contrast sharply with their actions ("I will give you my email password for a chocolate bar, hehe, sure.").

</comment></comment><comment><USER4> Good move, but not enough. Though you're now more informed, you still don't have much control over using an app other than deciding whether use it or not. Its not like you can say "this app shouldn't be needing access to my friends birthdays, let me disable that".

<comment><USER5> You realize that's not really possible right? Apps rely on the permissions they ask you for their core functionality. If it can't post to your wall, for example, to help spread the app, it's not really worth it for you to use up the server's resources.

<comment><USER6> Not really. The whole Facebook scandal has been exactly about the fact that apps need one thing (usually just your name for display purposes and the ability to write on your wall) but it was taking things like your email, what friends you have and so on.

Why does it need my email if I have all the email sending functionality off (I always do)? The applications could gracefully scale back based on what they can see.

The reason it's not really possible is that most of the advertising revenue being generated around Facebook comes from selling your information.

<comment><USER5> I guess that's fair. It should be against the TOS to ask for more data than you need, and result in a takedown after a warning.

</comment></comment></comment></comment><comment><USER7> Quite the 180, Facebook. My data belongs to me is a core belief now?

<comment><USER8> No, they just want you to bear the responsibility of using third party apps.

</comment></comment><comment><USER9> Thank Goa. Finally they came up with this.</comment>


Research finds flaws in studies of mass deworming for children in poor countries - <AUTHOR> http://www.lstmed.ac.uk/news-events/news/research-finds-flaws-in-studies-of-mass-deworming-efforts-for-children-in-poor <comment><AUTHOR> Submitting this because some people on HN are concerned with "effective giving", and this research shows some of the complications of that.

<comment><USER2> Pretty much everything is complicated because humans are fallible. At least this is methodological error subject to scientific scrutiny rather than ethical shortcomings that comply with the letter of the law.</comment></comment>


Google anagram easter egg - <AUTHOR> http://www.google.com/search?q=anagram

<comment><USER2> I don't get it...

<comment><USER3> Search: Anagram

Did you mean: nag a ram ?

<comment><USER2> Ah ok, I get redirected to a localised google site and there they think I mistyped...

</comment></comment></comment><comment><USER4> Ooggle</comment>


Flask Security Architecture for Diverse, Security Policies [pdf] (1999) - <AUTHOR> https://www.cs.cmu.edu/~dga/papers/flask-usenixsec99.pdf <comment><AUTHOR> Many people get confused about why SELinux is so complicated. Partly implementation problem but partly intrinsic complexity to what it's trying to do. I thought people might find it enlightening to see the original, cleaner architecture applied to Fluke microkernel. Culmination of prior, failed attempts in high-assurance security to bake MAC into simple kernels such as original UNIX and Mach. One of few to succeed commercially in quite a few products from Sidewinder to SELinux.

</comment><comment><USER2> Nice one Nick. Flask is really a beautiful architecture. The primary SELinux author once said, "SELinux doesn't add complexity. It exposes complexity that was already there." MAC policies for general purpose computing environments trended toward unmanageable complexity, but the fit is much more natural in constrained computing environments such as smartphones.</comment>


Introducing the Open Automotive Alliance - <AUTHOR> http://www.openautoalliance.net/

<comment><USER2> Momentary jubilation followed by 'blah'.

I saw the title and expected something like an alliance working on open source automobiles (e.g., [http://wikispeed.org/the-car/](http://wikispeed.org/the- car/)).

</comment><comment><USER3> This is the wrong approach. BMW has the right idea here: define an interface that lets a user's smartphone paint a car's built in LCD(s) and receive input from its joysticks. Then the car becomes agnostic to ever changing network, app, and graphics technology.

<comment><USER4> Hard to imagine any Tesla owner (17" touchscreen) liking that strategy.

</comment></comment><comment><USER5> I was hoping for a collection of designers and engineers working together to make an open, modular, chassis that could be worked upon. Maybe a discussion about best practices for serviceability, ergonomics, performance, cost- efficiencies, etc.

I had about 2 seconds from clicking the link to the page loading to think about that, and I'm feeling pretty let down. I know that the digital systems play a huge role in cars nowadays, but I just can't get excited about this.... yet?

<comment><USER6> Ford was showing more potential with OpenXC, but that was last year's CES hype generator that has pretty much fallen into the background:

[http://www.androidcentral.com/ford-announces-openxc-sdk- andr...](http://www.androidcentral.com/ford-announces-openxc-sdk-android-apps- can-now-easily-access-sensor-data)

</comment></comment><comment><USER6> So we're doing Open Handset Alliance 2.0?

<comment><USER7> Looks like from the little on the site.

I was hoping for something saner than CAN bus

</comment></comment><comment><AUTHOR> Maybe more will be announced at CES, as hinted here: [http://www.businessweek.com/articles/2014-01-06/google- teams...](http://www.businessweek.com/articles/2014-01-06/google-teams-with- gm-honda-and-audi-to-bring-android-to-cars)

</comment><comment><USER8> Just like the "Open" Handset "Alliance"?

</comment><comment><USER9> I'm interested in if this will improve embedded devices' often-abysmal security record.

</comment><comment><USER10> I was hoping for some kind of better, open interface for engine data & other car systems :(</comment>


Show HN: Poker arena for AI/ML bots - <AUTHOR> https://pkr42.com <comment><AUTHOR> Hi HN,

Regular poker platforms ban the use of bots. They fear bots provides an unfair advantage. But honestly, I don't think it is the right response. Instead of fighting the use of bots, platforms should think hard on how to best incorporate bots in the game with humans.

For example, I could find on several forums that the capacity to analyze thousands of "hand histories" provides an unfair advantage to bots. Ok, fair enough. The solution is simple: anonymize players and hand histories become worthless.

That is why I am working on a poker platform for bots. The one thing I learned in StartupSchool 2019 is that you should talk to potential users before working on a solution. So here I am with a discussion and a landing page :-)

What do you guys think?

Thank you!

Maxime.</comment>


If there's any lock-in at all it doesn't matter if you call it open - <AUTHOR> http://www.scripting.com/stories/2010/05/02/replaceable.html <comment><USER2> Nobody starts a company to target a market with the goal of being replaceable. Let's say you were going to sell cars. Should you publish all your designs and manufacturing techniques so that the marketplace is "fair"?

<comment><AUTHOR> Cars are replaceable. A few years ago I bought a Toyota. Then I got tired of it so I bought a BMW. No one has me locked in, I'm free to switch. So they have to compete to keep me as a customer (or in the case of BMW to get me back, I was a former BMW driver).</comment></comment>


500 Byte Images: The Haiku Vector Icon Format - <AUTHOR> http://blog.leahhanson.us/post/recursecenter2016/haiku_icons.html <comment><USER2> > [Vector format] means that you only need one file per icon; it doesn't > matter how many sizes you want to render icons at.

That's not really true, even with vectors it's good to have different images for different sizes, that add details (for larger sizes) or remove details and increase component sizes (for smaller sizes), so the icons look good at different sizes. You can see in the tape recorder icon the author shows: at larger sizes, it looks much better than the bitmap images, but at smaller sizes the bitmapped icons look better; the vector icons become a mush of unclear elements. The bitmap shows pieces as proportionally larger than they should be, so the visual elements that you consider important still show clearly.

<comment><USER3> There is a feature of HVIF, called level of detail, that lets you vary what shapes appear according to the display size. You can find it in the Icon-o- Matic documentation. Ctrl-F for "LOD" in [https://www.haiku- os.org/docs/userguide/en/applications/icon...](https://www.haiku- os.org/docs/userguide/en/applications/icon-o-matic.html)

<comment><USER4> So like media queries, in CSS? That's neat.

<comment><USER5> example: [https://twitter.com/tzmartin/status/688950091063771137](https://twitter.com/tzmartin/status/688950091063771137)

<comment><USER2> That's pretty cool!

</comment></comment></comment></comment></comment><comment><USER6> If you ever look into the memory consumption of modern applications and filetypes, you'll probably both throw up and have a heart attack. Very few people are interested in tuning the constant factors in the efficiency of their software, even when the benefits of doing so can be really impressive as demonstrated here.

<comment><USER7> But with so much memory available on modern systems, the benefits of optimizing makes les and less sense.

It is often not worth the effort.

<comment><USER8> "Systems have so much memory, it doesn't matter if I increase memory usage for simplicity or maintainability."

Now look at your stack and count how many developers could have uttered this phrase when designing each module, subsystem, library, protocol, service, daemon, file type, interface, or plug-in that's part of it.

We should count ourselves lucky that hardware engineers have afforded us the ability to make such trades but we shouldn't take it for granted.

<comment><USER7> In this case I think the tradeoff is not worthy. We're not in the 80s anymore and its ok for a desktop to load an app icon with an additional file access. Even more if its a well known vector format.

Imagine what would have happened if HTML had been a non human-readable binary format just to spare a few bytes.

Some optimizations are counter productive.

<comment><USER9> _Imagine what would have happened if HTML had been a non human-readable binary format just to spare a few bytes._

If you want to "just spare a few bytes", you could do the same to HTML and keep it text-based. Comparing something like XML and JSON shows that "human- readable" formats can vary significantly in complexity alone.

Besides, I think we could all do with fewer layers of abstraction in our lives. As a reverse-engineer I know once remarked, "Everything is human readable if you have a hex editor."

<comment><USER10> XML is more extensible than JSON. So the latter if a trade off, not an optimization. Perhaps comparing with binary XML would be better.

</comment></comment></comment></comment></comment></comment><comment><USER9> For anyone interested in compact vector graphics, SWF (Macromedia/Adobe Flash) has a shape format which is also similarly efficient and might be even smaller, since it doesn't restrict things like coordinates and colour indices to multiples of bytes --- fields are bit-aligned.

SVG is ridiculously bloated in comparison. Even PostScript and PDF are more efficient.

<comment><USER11> SVG is a strange combination of really bloated and not easily human readable. Try to make sense of shape data sometime. I'd expected a XML list of points but it's nothing that clear, it's a string of letters and numbers as an attribute of a tag. It may very well be readable if you learn the language but it's certainly not self describing as I would have expected from an XML format.

<comment><USER9> _I 'd expected a XML list of points but it's nothing that clear, it's a string of letters and numbers as an attribute of a tag_

It's like they actually noticed how much more bloat would result from making each point an element, so instead they just decided to dump what is essentially bastardised PDF/PostScript path data into an attribute. The "language" also doesn't match PDF exactly, despite using a similar style of short 1-letter commands.

Compare:

[https://www.w3.org/TR/SVG/paths.html](https://www.w3.org/TR/SVG/paths.html)

[http://www.websupergoo.com/helppdfnet/source/4-examples/17-a...](http://www.websupergoo.com/helppdfnet/source/4-examples/17-advancedgraphics.htm)

</comment></comment></comment><comment><USER12> The article is wrong. The very first image is 375 bytes, not 1024:

[https://www.haiku-os.org/docs/userguide/images/apps- images/i...](https://www.haiku-os.org/docs/userguide/images/apps-images/i-o-m- terminal-bitmap32.png)

And I was able to losslessly reduce it to 298 bytes with PNGOUT.

The smaller image is 257 bytes, and I reduced it to 186.

<comment><USER13> The article talks about raw bitmaps, though, while PNG is a bitmap compressed with deflate.

Since rendering a bitmap is straightforward, I imagine it would be preferred here for performance (I am just guessing here).

<comment><USER12> Isn't HVIF compressed SVG? They basically substituted the verbose tags with binary, which is a form of compression.

<comment><USER13> You're right of course. However, I'd not call it compression of SVG. HVIF seems to have defined a simplified encoding (probably inspired by SVG)?

[Edit]: HVIF is rendered in a single pass (except in a few cases), while SVGs (and most vector format) render each element individually.

</comment></comment></comment></comment><comment><USER14> There seem to be a few constraints regarding the object count (255 with just one byte). Even though you could say that most icons won't be complex enough to need that, it's an unnecessary limitation that saves two or three bytes at best.

Other than that, pretty incredible work. Vector image compression at encoding level is definitely interesting. I alsolove posts in which binary formats are explained, so...

<comment><USER15> Variable length integers could have easily increased the object count limit with only a very small increase in size. VLQ[1] would have been one good choice, but various other schemes would have allowed the same size as a one- byte encoding with up to about 250 objects while still allowing larger numbers.

But of course that increases encoder and decoder complexity. For icons, a 255 style/path limit seems reasonable and keeps the code simple.

[1]: [https://en.wikipedia.org/wiki/Variable- length_quantity](https://en.wikipedia.org/wiki/Variable-length_quantity)

<comment><USER16> PrefixVarint [1] is usually a better choice than VLQ. It's faster to decode and requires the same number of bits.

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

</comment></comment></comment><comment><USER17> Get it down to 280 bytes and you can fit one in a tweet: [https://github.com/ferno/base65536](https://github.com/ferno/base65536)

</comment><comment><USER18> I don't understand the application of this to filesystems. To me it sounds like it the usual way to have file icons is a simple mapping from a file type to an icon file, and in this solution that icon gets put into the metadata of the file instead of it's own file, so it's not a property of the file type anymore, but of the individual file. This couples the FS implementation to the GUI right? Isn't that horrible? If you want to change the Icon for one file type now you have to walk the whole file system and touch the metadata of every file. Also if you change the extension of the file, you have to change the icon in the metadata as well.

Edit: I would just teach the GUI to cache the icon folder in RAM.

<comment><USER11> I imagine it's similar to MacOS where you can edit the icon of any file type and its stored in a resource fork.

</comment></comment><comment><USER19> Haiku! Hadn't heard about this project for long time. What's their status right now? How active is the development?

<comment><USER20> They still post monthly summaries, seems active [https://www.haiku- os.org/blog/pulkomandy/2016-07-28_haiku_mo...](https://www.haiku- os.org/blog/pulkomandy/2016-07-28_haiku_monthly_activity_report_july_2016)

<comment><USER21> I hope it someday gets to the point where I can use it as a daily driver. I think it's really cool, and as long as it runs a web browser and allows me to SSH into another machine for anything that requires another OS I'd be happy. It would be a lot of fun to play around with.

<comment><USER22> Yeah, I loved BeOS in the old times, and I'd really love Haiku would get more mainstream and productive for daily use. Its combination of speed, lightness, simplicity and cohesion is something to envy from other OSs. I love it.

I wonder what's the reason of its slow acceptance..

</comment></comment></comment></comment><comment><USER23> It's stated that the goal is to fit file icons into inodes to avoid additional disk accesses. How much of an issue is this on an SSD instead of a hard disk?

<comment><USER24> I'm curious as to how you'd update the icon for a file type. Would you have to update the inode of every single file of that type? That can't be too efficient.

I'm sure there are ways of getting around the problem, but having lots of duplicate data (even if each icon is very small) isn't generally a good idea (but perhaps this is an exception).

<comment><USER23> Yeah, I'm a bit confused about what this is for. Any icons common to an entire file type should be cached in RAM already, so I the only thing I can think of would be file-specific icons. But I expect most of those would be thumbnail images, which would not be amenable to a concise vector representation.

</comment></comment></comment><comment><USER25> That's amazing!

How's it compare to a minimised SVG, gzipped, in practical terms? I see projects elsewhere just blithely using SVG or SVGZ. (or, in horrifying cases, multiple sizes for hundreds or thousands of icons.) Perhaps this is a thing that would be suitable to wider use if it can get good lib support.

<comment><USER13> SVGs generated from popular vector editing softwares can get very complex with cascading style overrides, transformations etc. Even though SVGz would reduce the file size, parsing the SVG tree and rendering will still be unoptimized.

Optimization tools do exist [1] to simplify the tree but they can do only so much good[0]. I think this format, built with optimality might be a solution.

[0]: Anecdotal. I once had to edit ~20 icons. The client had provided SVGs because they'd somehow lost the original AI files. When I imported them in Sketch 3, the nesting, masks, and transforms applied were absolutely horrifying! I had to optimize the icons using [1], which did remove the masks and transforms, but in the end I had to manually edit SVG's XML source to fix nestings. _sigh_.

[1]: [https://github.com/svg/svgo](https://github.com/svg/svgo)

<comment><USER25> I know _exactly_ what you mean. Approximately everyone uses Inkscape in practice, but I too have had occasion to go into gvim and edit the Inkscape SVG by hand. I will say that it really helps to know what's going on, but _having_ to is less than ideal.

("approximately everyone" to the point where Wikimedia occasionally considers just using Inkscape-as-a-service as the SVG renderer instead of rsvg, for best quirk-compatibility.)

<comment><USER26> I used Inkscape recently, and found it quite a nightmare to use, even if its UI reminded me of Corel Draw quite a bit.

That's what I get for spending like a decade primarily using Photoshop, I suppose.

<comment><USER25> It is impossible to use Inkscape without running through at least some of the tutorials. Once you have a good conceptual understanding and have found some of the stupid bits that make no sense (what, you expected "Object Properties ..." to contain, ooh I dunno, _properties_ of the _object_?) it's entirely suited to doing proper work. But no, its interface is very bad on discoverability.

</comment></comment></comment></comment></comment><comment><USER27> This seems to be the source she is referring to: [https://github.com/tqh/haiku- efi/tree/master/src/libs/icon/f...](https://github.com/tqh/haiku- efi/tree/master/src/libs/icon/flat_icon), specifically the FlatIconFormat class. Some of the most interesting deconstructions and experiments have come out of The Recurse Center, great learning experiences and blog posts by these students. I found the concept of the format interesting in how it meets the goals of being modern (a vector format) while staying slim for disk reads (optimizing the format specifically for icons). Lastly the usability aspect is tackled by creating an icon editor specifically for the format. In the creator's blog post, he notes that creators might not be able to take full advantage of the format because they might not know how the it works, but I think it's fine since the format constrains the palette anyway.

</comment><comment><USER28> Leah, please consider this: [http://contrastrebellion.com](http://contrastrebellion.com)

<comment><USER29> I'd rather like to see a movement against websites that force users to vertically scroll down page after page to read three paragraphs of text.

<comment><USER30> That's interesting. Because clearly separating parts of content too far presents a usability challenge of its own, but failing to separate them enough presents a similar set of usability challenges.

I personally tend toward the "users do scroll, it's okay to make long pages" school of thought. But certain extreme cases are extremely unpleasant to use. That said, I don't consider this one case so extreme, because it at least does not take over my ability to scroll at the pace I expect.

<comment><USER31> I think the problem here might be that, if you're skimming the text of these "slides" and not looking at the illustrations, you can actually read faster than it's _possible_ to scroll on most computers, and thus "stall your [visual] pipeline." Normally, with scrolling, I can still read _while_ I'm scrolling. In this case, I have to read-THEN-scroll-THEN-read-THEN-scroll, etc.

</comment></comment></comment></comment><comment><USER32> Isn't one of the reasons why bitmaps are used that icons should actually vary from a standard vector image when shown at very small sizes to remain clear and readable?

This icon library shows some good examples.

[http://mezzoblue.com/icons/chalkwork/](http://mezzoblue.com/icons/chalkwork/)

</comment><comment><USER33> Given the processing power of modern computers, I have always been surprised that operating systems haven't moved to vectors for all user interface elements. You would think this would be desired for resolution independence, if nothing else.

</comment><comment><USER34> The problem is that the shadows on smallest sizes are not so clear and the icons are harder to see.

</comment><comment><USER35> Macintosh PICT was just a bytestream of Toolbox draw calls. I think Windows EMF was too.

</comment><comment><USER36> The innate proportion-consistency of pixel art still fascinates me.</comment>


US House votes to restrict Iraqi and Syrian refugees entry - <AUTHOR> http://www.bbc.com/news/world-us-canada-34870724 <comment><AUTHOR> I suppose no one is surprised that the house of representatives showed once again complete moral cowardice.</comment>


Lifespan of electronics 2.3 years shorter than intended by design - <AUTHOR> https://www.circularonline.co.uk/news/lifespan-of-electronics-2-3-years-shorter-than-intended-by-design/ <comment><USER2> TFA is a summary of a more complete article: [https://www.eea.europa.eu/themes/waste/resource- efficiency/b...](https://www.eea.europa.eu/themes/waste/resource- efficiency/benefits-of-longer-lasting-electronics)

Which defines some terminology. By "desired lifetime", they mean desired by consumers.</comment>


Build Your Own WebAssembly Compiler - <AUTHOR> https://www.infoq.com/presentations/webassembly-compiler/ <comment><USER2> Here's Colin's blog post with code and diagrams inline: [https://blog.scottlogic.com/2019/05/17/webassembly- compiler....](https://blog.scottlogic.com/2019/05/17/webassembly- compiler.html)

I found Colin's posts real helpful when writing some WebAssembly by hand for the first few days of Advent of Code: [https://observablehq.com/collection/@ballingt/advent-of- wasm](https://observablehq.com/collection/@ballingt/advent-of-wasm)

</comment><comment><USER3> Last year I decided to write a WASM-targeting compiler in Javascript, completely by hand. The idea was to compile a vaguely C-like toy language to WASM without any external dependencies.

Part of the motivation was that while I've written many simple parsers, I mostly used parser generators with BNF grammars and I didn't feel like I had a good sense of how the code I ended up generating actually worked for something with complex syntax and semantics. I felt like I was writing specs for a parser, rather than writing a parser. And I didn't have a huge amount of experience with code generation.

My toy language has vaguely C-like syntax with block scope and infix operators with various precedences, so it was a bit more complicated than JSON, but I ended up using something like Pratt parsing/Precedence Climbing (see [https://www.oilshell.org/blog/2017/03/31.html](https://www.oilshell.org/blog/2017/03/31.html)) and wrote the whole thing in a way that's - hopefully - pretty easy to read for folks interested in wrapping their head around parsing complex syntax (e.g. with scope and name resolution). The lexer, parser and language definition ended up being about 1000 lines of JS (counting some pretty extensive comments).

Code generation is pretty straightforward once you have an AST.

Any JS programmers that are interested in really getting into the nitty-gritty of writing your own parser/compiler should check it out. The source is here: [https://github.com/j-s-n/WebBS](https://github.com/j-s-n/WebBS).

If you want to play around with the language and inspect the generated ASTs and WASM bytecode, there's an interactive IDE with example code here: [https://j-s-n.github.io/WebBS/index.html#splash](https://j-s-n.github.io/WebBS/index.html#splash)

<comment><USER4> I found this one pretty interesting. [https://maierfelix.github.io/mini-c/](https://maierfelix.github.io/mini-c/)

</comment></comment><comment><USER5> Are there any fast ways to run wasm on systems that forbid creating new executable pages? A high performance interpreter?

<comment><USER6> What system do you mean? iOS supports wasm AFAIK.

<comment><USER5> Not iOS but it's an interesting thought experiment: if you wanted to build a fast WASM implementation for iOS, how would yo do it?

<comment><USER7> If your WASM code doesn't change (isn't being downloaded at runtime from the Internet), then you could ahead-of-time compile it to native machine code (ARM/ARM64) and link it into your app.

It doesn't look like anyone's tried to do it for iOS but InNative has a compiler for Windows/Linux.

</comment></comment></comment></comment><comment><USER8> Documentation on how Lobster's Wasm-backend works, which contains plenty of useful info for anyone making their own backend: [http://aardappel.github.io/lobster/implementation_wasm.html](http://aardappel.github.io/lobster/implementation_wasm.html)

<comment><USER9> Cool, thanks for sharing.

</comment></comment><comment><USER10> Here's my wasm parser/runtime written in TypeScript, for instance. [https://github.com/ryohey/ts-wasm-runtime](https://github.com/ryohey/ts-wasm- runtime)

</comment><comment><USER11> My self hosted compiler: [https://github.com/PierreRossouw/wats](https://github.com/PierreRossouw/wats)</comment>


AirPods Have Gone Viral - <AUTHOR> https://www.aboveavalon.com/notes/2019/2/11/airpods-have-gone-viral <comment><USER2> Completely anecdotal but my daughter plays club volleyball and their main season is Winter/Spring. Anyway we had our first tournament a couple of weeks ago. I was _shocked_ at the number of girls, all teenagers, having AirPods. I think they're the new status symbol because you can easily see someone's AirPods even when you can't see their phone.

Even more surprising is the number of adults I've been seeing recently wearing AirPods. As the article alludes they have appeared to sprout overnight. Now I'm seeing them everywhere. I'm also noticing more and more Apple Watches. Maybe they're related? Whatever it is I'm seeing them everywhere.</comment>


Why I'm Betting On Julia - <AUTHOR> http://www.evanmiller.org/why-im-betting-on-julia.html <comment><USER3> When out with friends recently, one of them mentioned how awesome Julia is. I was surprised to hear someone talk about it, even from another person in science. She turned and gushed about how awesome it was, how supportive the community was, even though she was "not really someone who likes programming." And she liked it so much she was telling her friends about it at a bar!

If you make a programming language that people who don't like programming love enough to spread by word of mouth when not near a computer, which technically- oriented people also love, that's a lot like the OSX terminal + nice GUI blend.

That's a pretty rare thing. And for collaborative science it's pretty important. Often, you'll have people in a bio lab who are very proficient in their area of biological expertise, but who would be solving the wrong problem by spending 2 years trying to become C++ hackers. On the other hand, there are a lot of people who write computational libraries, but know they have to translate them to matlab, or write a matlab wrapper and pray that their users can get it to compile which might sound simple to folks here, but is _really_ frustrating for less computationally oriented people when something goes wrong.

<comment><USER4> To be fair, there's also Python+NumPy and R in that space, not just Matlab. Besides the "tinker with LLVM" thing, what does Julia offer that Python (or Cython for speed)+NumPy does not?

<comment><USER5> Writing fast code in Julia requires less effort than it does in Python or R. You don't have to drop down to Cython or Rcpp to get good performance. If you write an algorithm in Julia the same way you'd write it in C, it will achieve equal performance. If you write it the same way you'd write it in Python or R, it may not be optimal due to the cost of memory allocation, but it's still faster than Python or R.

Julia is more concise than Python. The language was designed to work with multidimensional arrays; it wasn't bolted on afterwards. There is no difference between a 2D array and a matrix; * always does matrix multiplication and .* always does element-wise multiplication. There is no awkwardness involving differences between NumPy arrays and Python lists. Everything has a type, and you can make a multidimensional array that efficiently stores values of any type. You can define your own types and define how arithmetic operators act on them with a minimal amount of code.

Julia's type system makes writing efficient algorithms easy without sacrificing any performance. If you define your own immutable type and define your own operators on it, Julia can make those operators run as fast as they would on ordinary values. In addition to general matrices, we have diagonal, symmetric, and tridiagonal matrices. The same routines that work on general matrices work on these as well with the same syntax, just more efficiently.

Julia uses multiple dispatch instead of traditional class-based OO. Methods are not a part of the object; instead, they operate on the object. Different methods with the same name can be defined to work on different types, or a single method can operate on a set of types, but the functions it calls may be implemented differently for each of these types. This is a better fit for technical applications, where the data doesn't change much but the methods do.

Julia is homoiconic, which is more useful than this article makes it seem :). It's easy to write code that writes code. If built-in language features aren't enough to get good performance with concise syntax, you can write a hygenic macro that does this for you.

<comment><USER6> To the rescue of numpy: A matrix from linear algebra and a 2D array are not exactly the same. In Python they are different convertible types and I think in practice it is hardly a drawback. That the multiplication operation is overloaded in the Mathematical World with the same symbol as the "normal" multiplication is unfortunate, numpys solution is as good as introducing two different operators (with one being an awkward .*)

I love the multiple dispatch part about julia though.

My fear however is, that unlike Python, Julia will lack enough libraries, especially on the unscientific part (GUI, databases, network, all the other stuff you need).

<comment><USER7> > That the multiplication operation is overloaded in the Mathematical World > with the same symbol as the "normal" multiplication is unfortunate, numpy's > solution is as good as introducing two different operators

The thing is that _the_ multiplication operation for matrices _is_ matrix multiplication, not elementwise multiplication. When you apply a polynomial like x^2 + y to matrices, you do not want to apply the polynomial elementwise – you want to square the x matrix and add the y matrix to it.

<comment><USER8> Sometimes an array of numbers is just an array of numbers. The language shouldn't presume too much about what you mean to do with them.

The moment you need an extra dimension (or anything other than 2 really) Matlab's 'everything is a matrix' approach falls apart. Matlab is a toy language in so many ways and this is just another one.

It's a pity that Julia adopted Matlab's pop matrix semantics instead of some solid and general principles from APL or J. Even modern Fortran would have been a better model for an array DSL. From what I've read of the Julia docs, they actually want you to write loops. But Julia looks great otherwise. With macros and a good compiler, maybe the array features can be fixed at some point.

<comment><USER9> Yes, adverbs, ranked matrix operator and some other parts of the APL/J approach I miss a bit and find them tedious to emulate/avoid.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I really don't like the anti-intellectual tone of the beginning.

"The problem with most programming languages is they're designed by language geeks, who tend to worry about things that I don't much care for. Safety, type systems, homoiconicity, and so forth."

can be rewritten as:

"The problem with most software is that they are designed by computer geeks, who tend to worry about things that I don't much care for. Information security, thread safety, modularity, hardware acceleration, system design, and so forth."

<comment><USER11> The language may have been grating, but as someone who also comes from more of a scientific computing background, I read this as "I want a language to be a tool that I can use to solve scientific and engineering problems with minimal conceptual overhead due to minding language features." I read it as saying "Finally, a language designed for someone like me," which I also find true personally.

<comment><USER12> "I want a language to be a tool that I can use to solve scientific and engineering problems with minimal conceptual overhead due to minding language features."

Among compiled languages, isn't that Fortran, especially since Fortran 90 on have multidimensional array operations, like Julia, Numpy, and Matlab.

<comment><USER13> It should read the other way round - Julia, Numpy, especially Matlab have array operations like Fortran 90, since they are designed by people from that background.

The problem with Fortran is interoperabality with other libraries; if you leave scientific computing, you're basically out of luck. Writing a GUI is just not going to happen. It is really fast, but it is also not as easy for prototyping since it is also compiled like C. Finally, Fortran does have the kind of stigma coming from older versions like 77 - and it's still really easy to write REALLY bad and unmaintainable code with it if you're not minding the newer language features. Especially OOP (since Fortran 2003) feels a bit tacked on.

</comment></comment></comment></comment><comment><USER14> I'm excited by Julia, but I don't think this article makes a very good sell. It's neat that you can dump the generated assembly, but I'd rather see a demonstration of a robust profiler so that I know which functions I need to dump in the first place.

I also disagree that the popularity of Node stems from "getting disparate groups of programmers to code in the same language". From what I've observed, it's not that back-end programmers are suddenly giddy at the prospect of getting to use Javascript on the server, it's that front-end programmers get to apply their existing knowledge of Javascript to back-end development.

<comment><USER15> I tend to agree with you about tools. I have yet to meet a language feature that's more important than library availability, profiling, autocompletion, documentation, debugging, etc. Then again, I don't face the script/C/CUDA choice everyday (most of his detractors on this thread don't either, I'd be willing to bet) so his circumstances are probably different enough to justify a different priority list. His argument might be perfectly valid for the HPC community which is a powerful constituency among academic programmers.

However, he _did_ address library availability, and that argument resonates with me. I've never met a FFI I didn't come to loathe. I've had java, ruby, and python FFI libraries fail to satisfy my needs despite half a dozen bugfixes between them. What this man says about having to write wrappers, despite abundant and loud promises to the contrary, is completely true. You don't have to wander far off the beaten path before a typical FFI goes belly- up. POD structs usually suffice (Sure, we support POD structs! Oh, you want to nest them / align them / make arrays of them / have them hold pointers / ...? We don't support that "yet". Worse: they support it but it's buggy.). Heavens help you if your argument has (gasp) an initializer or one of the arguments is a reference. Maybe things have changed in the last ~5 years, but I doubt it.

If Julia's intimate connection with LLVM makes it practical to implement a better FFI or hybridize FFI + wrapper code when necessary, it will have a very valuable advantage over python for purposes of scientific computing. Maybe even enough to displace it in the long run.

EDIT: By "hybridize" I mean that the ability to embed asm,C,C++ in Julia with the same ease that you can embed asm in C/C++ would be a KILLER feature.

<comment><USER16> > I've never met a FFI I didn't come to loathe

I've felt that pain. With so many new programming languages popping up, I've been wondering if the next killer programming improvement isn't strictly a programming language at all, but rather something that rethinks the linker, manages execution, and facilitates interfaces between larger blocks of code (maybe in multiple languages).

<comment><USER15> I've heard many very smart people (professors, leaders of large HPC efforts, "language geeks") express the same sentiment over the years. Unfortunately, it's a btch of a problem, as attested to by the veritable graveyard of half- baked solutions out there. Apple's "Bridge Support" is the closest thing I've seen to success (haven't worked with MS's CIL) and it leaves much to be desired.

I'm not sure there _is_ any way around the impedance mismatches between languages. They're all slightly different for a reason. Perhaps clean C APIs are the best we can hope for.

<comment><USER16> I keep hoping that some accessibility upgrade comes to the linker akin to how LLVM made compiler infrastructure more accessible, might make FFI bridging more automated. For example, if GDB can access and take apart C structs an automated way, why is FFI coding always seem to have programmers do a lot of mechanical interfacing work.

Not that all the other JVM, CIL, etc aren't approaches that yield some improvements, but something that upgrades capability or accessibility at the level of the ABI linkage level is going to be a wider impact.

</comment></comment></comment></comment></comment><comment><USER17> The author and I like Julia for nearly opposite reasons. (I write Julia for the language geek reasons. The power of homoiconicity is amazing for writing static analysis in the language you're analyzing.) It's really cool that Julia can appeal to people with nearly opposing priorities tho. :)

I'm looking forward to giving the workshop at UChicago. It'll be my third time presenting an Intro to Julia workshop.

<comment><USER18> Will you be webcasting?

<comment><USER17> No, unfortunately not. We are hoping to record it, tho.

<comment><USER19> Would love to see it put online :>

</comment></comment></comment></comment><comment><USER20> The reason to bet on Julia is disassembling a function? This is a standard feature in Common Lisp (ANSI standardized in 1994)

      CL-USER> (defun f(x) (* x x))
      F
      CL-USER> (disassemble 'f)
      L0
               (leaq (@ (:^ L0) (% rip)) (% fn))       ;     [0]
               (cmpl ($ 8) (% nargs))                  ;     [7]
               (jne L33)                               ;    [10]
               (pushq (% rbp))                         ;    [12]
               (movq (% rsp) (% rbp))                  ;    [13]
               (pushq (% arg_z))                       ;    [16]
               (movq (% arg_z) (% arg_y))              ;    [17]
               (leaveq)                                ;    [20]
               (jmpq (@ .SPBUILTIN-TIMES))             ;    [21]
      L33
               (uuo-error-wrong-number-of-args)        ;    [33]

<comment><USER21> This is also possible to a degree in Python, though you only get the bytecode:

        >>> def f(x):
        ...     return x * x
        ...
        >>> import dis
        >>> print dis.dis(f)
          2           0 LOAD_FAST                0 (x)
                      3 LOAD_FAST                0 (x)
                      6 BINARY_MULTIPLY
                      7 RETURN_VALUE

<comment><USER22> And the bytecode is just calling polymorphic methods. All the real work is done in the object implementations of type(x). I was very bummed years ago to realize how shallow the bytecode representation in Python is. There is no sub- terpreter, just C.

</comment></comment></comment><comment><USER23> To each its own I guess, but I wanted to say that I don't see "safety, type systems and homoiconicity" and other theoretical "geek" stuff as orthogonal to a programming language's ease of use, productivity and expressiveness. If anything they complement each other. The theory behind it provides a consistent framework so that you minimize the mixing of different paradigms and you can express ideas in a more consistent way. I very much doubt that a language where you just throw stuff in would be easy to use. If Julia is a great language is precisely _because_ of all the thought that went into it, the ideas behind it didn't just materialize in someone's brain.

<comment><USER24> I don't think his point is that "safety, type systems and homoiconicity" don't matter. His point is that those things don't interest him as much as getting things done do.

Those things may help him get things done, but they're for other people to worry about while he works on his own stuff.

Also, am I the only one that doesn't know what 'orthogonal' means? I assume from the context it means that these things aren't mutually exclusive.

Not really sure about 'homoiconicity,' either.

<comment><USER25> Orthogonal literally means "perpendiular" \- it refers to two things that aren't related at all. So, non-mutually-exclusive is part of it, but not the whole picture.

FYI

</comment></comment></comment><comment><USER9> "Julia was not designed by language geeks — it came from math, science, and engineering MIT students"

This statement is built on a false dichotomy. And it is not really true for Julia, take the type system for example, sophisticated AND unintrusive.

<comment><USER26> > "Julia was not designed by language geeks — it came from math, science, and > engineering MIT students"

This makes me a bit cautious about the language. Scientific computing people are often very smart but they are not programmers or computer scientists and may do funny things that a computer scientist would not. Like one based indexing of arrays in Julia. This is not a big deal but I'm a bit wary that there may be some nasty surprises for a language geek computer scientist like me :)

Another example is the byte addressing of UTF-8 strings, which may give an error if you try to index strings in the middle of a UTF-8 sequence [1]. s = "\u2200 x \u2203 y"; s[2] is an error, instead of returning the second character of the string. I find this a little awkward.

There's a flip side to this too, if you're dealing with scientific computing there seems to be a wide variety of scientific computing libraries available in Julia [2].

Overall I find this language very interesting and it is on my shortlist of new languages to take a look at when time permits.

[1] [http://docs.julialang.org/en/latest/manual/strings/#unicode-...](http://docs.julialang.org/en/latest/manual/strings/#unicode- and-utf-8) [2] [http://docs.julialang.org/en/release-0.2/packages/packagelis...](http://docs.julialang.org/en/release-0.2/packages/packagelist/)

<comment><USER5> > Another example is the byte addressing of UTF-8 strings, which may give an > error if you try to index strings in the middle of a UTF-8 sequence [1]. s = > "\u2200 x \u2203 y"; s[2] is an error, instead of returning the second > character of the string. I find this a little awkward.

Yes, it's a little awkward, but to understand why this tradeoff was made, think about how you'd get the nth character in a UTF-8 string. There is a tradeoff between intuitive O(n) string indexing by characters and O(1) string indexing by bytes.

The way out that some programming languages have chosen is to store your strings as UTF-16, and use O(1) indexing by two-byte sequence. That's not a great solution, because 1) it takes twice as much memory to store an ASCII string and 2) if someone gives you a string that contains a Unicode character that can't be expressed in UCS-2, like 🐣, your code will either be unable to handle it at all or do the wrong thing, and you are unlikely to know that until it happens.

The other way out is to store all of your strings as UTF-32/UCS-4. I'm not sure any programming language does this, because using 4x as much memory for ASCII strings and making string manipulation significantly slower as a result (particularly for medium-sized strings that would have fit in L1 cache as UTF-8 but can't as UCS-4) is not really a great design decision.

Instead of O(n) string indexing by characters, Julia has fast string indexing by bytes with chr2ind and nextind functions to get byte indexes by character index, and iterating over strings gives 4-byte characters. Is this the appropriate tradeoff? That depends on your taste. But I don't think that additional computer science knowledge would have made this problem any easier.

<comment><USER7> It's also essentially the same approach that has been taken by Go and Rust, so we're in pretty decent company. Rob Pike and Ken Thompson _might_ know a little bit about UTF-8 ;-)

</comment></comment></comment></comment><comment><USER27> > The problem with most programming languages is they're designed by language > geeks, who tend to worry about things that I don't much care for. Safety, > type systems, homoiconicity, and so forth. I'm sure these things are great, > but when I'm messing around with a new project for fun, my two concerns are > 1) making it work and 2) making it fast. For me, code is like a car. It's a > means to an end. The "expressiveness" of a piece of code is about as > important to me as the "expressiveness" of a catalytic converter.

You want a fast car, but don't care much for having an aerodynamic design, hmmm..

EDIT: In retrospect I now think he means he wants to be able to _create_ the project fast, and this is not about performance.

<comment><USER28> This is a confusing rebuttal, because cars have an aerodynamic design primarily for performance reasons, and Evan is very clear in this article that his _primary concern_ is performance. I think you've misread him.

<comment><USER27> And yet he doesn't care about type systems, which are largely implemented to help with optimization, you see.

<comment><USER29> Really? My impression is that it's largely correctness.

<comment><USER30> But that allows for smarter optimizations.

<comment><USER29> Of course it does, and I never said it didn't. I just said that my impression is that the primary motivation of language people is correctness. However, I have published several in the area of software verification, so perhaps I am biased.

</comment></comment></comment></comment></comment></comment><comment><USER31> Can Julia be a competitor to R? I love R in concept (interactive environment for statistical analysis) but the language just drives me crazy in its multitude of types and the loosey-goosey ways it converts between them.

A friend of mine is really proficient with R; when I walked him through some of the R patterns that are very confusing/irregular to me, he sort of laughed: he could see what I was saying but he said "with R you can't worry about things too much, you kind of just have to just go with it."

If Julia can serve some of the same use cases but in a better-designed way, sign me up!

<comment><USER32> Already in 2008 one of the R creators, Ross Ikaha, talked about how R is fundamentally slow and has inefficient memory use. And that a "next gen R" would be needed, and he was considering Common Lisp for the underlying language on compiler. See the "Back to the Future: Lisp as a Base for a Statistical Computing System".

[https://www.stat.auckland.ac.nz/~ihaka/?Papers_and_Talks](https://www.stat.auckland.ac.nz/~ihaka/?Papers_and_Talks)

But now apparently Julia also fulfills Ihaka's requirements for the basis on the "new R" system, so I wonder is the need-for-speed part of the R community is considering a switch to Julia, instead of building a "new R" from scratch?

<comment><USER33> Lobbying Ross Ikaha to endorse Julia as the new R would hopefully bring more people over to the language. Instead of just the Matlab folks you would also renew interest with the slightly larger audience using R today.

</comment></comment></comment><comment><USER34> Just yesterday I decided to start seriously developing in Julia. High-level languages are a bottleneck for computational biology. We need to be able to write things fast, and have them run fast. So far no language really does this. But Julia looks like the one.

I'm going to put together a BioJulia team is anyone is interested in playing.

<comment><USER35> I suppose I need to explain my position on the involvement of Julia in bioinformatics a little bit more than just a short "I want to play" statement. What follows is a bit of a rant that attempts to explain why things are bad and that we need to work to make them better.

I have been in the field of computational biology for (practically) 3 years. In this time, I have seen my fair share of bad tools and silly approaches to very basic problems. A lot of the computer science folks may not realize it, but there is a lot of trouble of basic software engineering sort in computational biology. There is a lot of old, unmaintaned code, messy projects implemented in multiple languages, and (of course) bugs. It does not appear that anybody checks or maintains their code after publication - the projects often die after they appear in a journal once.

There is a number of reasons that the situation is the way it is. One of the sadly obvious ones is that the academics do not have the time or desire to maintain their code. Some of the project would require full-time coders to be maintained - and that is indeed the case for some of the bigger and more popular tools. This results in the fact that some projects never take off or live up to their potential - for the simple lack of time. The wasted effort means that a lot of work is being re-done and science in general stagnates because of that. There is no easy solution to this problem (other than centralizing the efforts somehow - but that is the question of community, not tools).

The issues that can be made better are the following (and I will start with the most obvious ones first):

1) We need a language that is both easy to write in and is fast enough for production. Too many times there exist projects that are written in multiple languages. I have myself partaken in a few of those. The high level code is usually written in python or perl (I shiver of the thought), while the heavier numerical things are done in C or C++. This creates a rather large divide in terms of who does what - quite often folks only know a single high level language - so the numerical implementation stays opaque with only a single person knowing how it works. This means that projects of that sort quickly become unmaintainable. There is also a lot of glue code written - and God help you if you need to understand how perl-guts work. If there was a single sane implementation for both high level and numerical stuff, it will solve a lot of those problems.

2) We need a fast language. Building on the previous argument - the reason for splitting is quite often performance. This means that we use a single language for both layers - and we get the "Node.js" effect (I'm not sure who to reference this phrase to) - both front- and back-end stuff comes together. This also means that you are not penalized for using complicated data structures in your numeric code - so one level of separation falls away automatically.

3) We need a language with a large number of capabilities. Julia community is aiming to replicate a lot of the functionality of R. That means that it is already possible to use Julia for, say, an undergraduate statistics course. There is absolutely no reason (other than the historical, of course) why R is used by the statisticians. It was written by statisticians for statisticians - and has a lot of nice features. However, that means that a lot of the efficiency considerations have been missed. R does a whole lot of data copying - which is ridiculous for large data sets. For the growing crop of statisticians it will barely make a difference which language is used - <USER2> would go as far as to say that a lot of undergrads will not even notice the difference, but those who will, will thank us later.

4) We need a functional language. Much rather, we need a multi-paradigm language that has a strong functional basis. The advantages of the functional approach are too many to name here - and I am afraid this is already becoming incomrehensive. A lot of formal math and stats is really easily translatable into functional mindset - and that is a great boon if you are trying to implement an algorithm out of a math paper. Also, Julia does not restrict you to think in a particular way - it is very adatable to your thinking patterns.

These are just a few reasons that I would try give to support a case for a new language in the scientific community.

<comment><USER35> Just as a conclusion, I would like to point those interested to the current available library implementations of the bio- related stuff (i might be missing other stuff out there): 1) BIO-seq: [https://github.com/diegozea/BioSeq.jl](https://github.com/diegozea/BioSeq.jl) 2) Fasta-IO: [https://github.com/carlobaldassi/FastaIO.jl](https://github.com/carlobaldassi/FastaIO.jl) 3) Phylogenetics: [https://github.com/Ward9250/Phylogenetics.jl](https://github.com/Ward9250/Phylogenetics.jl)

</comment></comment></comment><comment><USER36> We have a Julia and iJulia app on [https://koding.com](https://koding.com). It's going to be used by Harvard & MIT students soon. It's public and everyone can try it by simple login to Koding. The best part is you can easily try it online, without installing anything. Here is an screenshot of how it's look like (iJulia and Julia inside Terminal):

[http://d.pr/i/MsZt](http://d.pr/i/MsZt)

The source of this app can be found here:

[https://github.com/gokmen/julia.kdapp](https://github.com/gokmen/julia.kdapp)

I'm happy to answer any questions :)

<comment><USER37> I find the fact that I can't even find out what koding.com is when using IE 9 pretty obnoxious. Love it or not, many people are forced to use older browsers. Sending them to [https://koding.com/unsupported.html](https://koding.com/unsupported.html) without any explanation at all a great way to make people not want to bother finding out what you're offering.

<comment><USER38> But you do know and understand why they're not interested in supporting IE, right? And you'd feel the same way in their shoes, yes?

</comment></comment></comment><comment><USER39> This sounds like premature-optimization to me.

Maybe it's just me, but in the apps I write in dynamic languages, the bottleneck is rarely in the language. It's usually in some IO.

EDIT: some sentence in the article gave me the impression he was using this for non-math-heavy stuff which is why I said this

<comment><USER40> Julia's primary purpose is as a scientific language, which means lots of number-crunching on large data sets, complex computations, etc. IO is unlikely to be the bottleneck in these situations.

<comment><USER41> I'm not sure I agree with the second sentence. Any kind of crunching on large data sets has I/O bottlenecks as one of its main issues. When you're crunching on a terabyte of data, pretty much the most important thing is your precise strategy for handling that terabyte of data. I'll agree the asm can be interesting still there in some cases, though, if you think of memory- bandwidth-and-latency issues as part of I/O. There are definitely scientific simulations where compute throughput is the only real issue, but I think of them as a bit different kind of setting than big-data processing (stuff like solving complex sets of equations, which has low I/O but high computational requirements).

<comment><USER40> Yeah, I shouldn't have conflated big-data issues with numerical computing. Good catch.

Mostly I was responding to the idea that there is a relationship between dynamic languages and IO bottlenecks. This is certainly often the case in things like web development, where dynamic languages dominate, but under the hood, Julia has relatively little in common with Python/Ruby/JS/PHP/etc, in terms of how it's implemented or, especially, what it's intended to do.

</comment></comment></comment></comment><comment><USER42> It's been done 55 years ago: [http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec...](http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_disassemble.html)

<comment><USER43> I'm pretty confident that in 55 more years we'll be at the point where the state of the art in programming language will be to simply rediscover Common Lisp.

</comment></comment><comment><USER44> > my two concerns are 1) making it work and 2) making it fast.

What about maintainability? "Code as if the next guy to maintain your code is a homicidal maniac who knows where you live." -Kathy Sierra and Bert Bates

In my experience, making something work and making it (relatively) faster is easy. Making it easy to read is hard.

<comment><USER45> Seems like that's exactly what he doesn't care about. If you're prototyping or writing a lot of one off operations (for data analysis, maybe) then maintainability is less important.

<comment><USER44> IME, you only know that with hindsight. I have made one off programs I never needed to look at again. I've also made what I _thought_ were one off programs that I needed to maintain for a while.

Even in a prototype, you may need to rework a particular piece of code multiple times before it works correctly. Even with a prototype, you may need to use it as a reference for your official version. Even with a prototype, you may end up having to use that as the official version (usually not by my choice).

Also, caring about speed 2nd is shocking to me (but maybe I just come from a different world). What if it isn't fast enough on your first attempt? Won't you wish your code was maintainable so you could change it to be faster?

<comment><USER46> > What if it isn't fast enough on your first attempt? Won't you wish your code > was maintainable so you could change it to be faster?

From my experience, this isn't the case at all. A lot of the time my first attempt is in Python. The first attempt is really more of a prototype or a proof of concept. If the code works and I want to productize it, the code needs to be sped up. I have (at least) 2 choices: (1) make the Python code as fast as possible or (2) rewrite the whole thing in C/CUDA. If I take option 1, performance gains will be marginal and I still probably won't be happy with the performance of the software. Option 2 might take a bit longer, but at least I'll get something performant out. As I'm just throwing out and rewriting the first attempt, I don't actually care at all if it was maintainable code. I don't even care if the ideas in it were well explained/commented, because they're all my ideas and they're still fresh in my mind and I'm just going to rewrite the code and then document/clean up the fast version.

The appeal of Julia is that I no longer have to do this rewrite to make my code fast. Furthermore, if I don't have to do this rewrite, it is actually in my interest to make my first version of the code be maintainable and well documented.

<comment><USER44> Fair enough. But you ignored/changed the foundation my reply was built on. I'm replying to TFA saying "speed is second" and maintainability is... not considered. You're talking about "correctness being first" and speed/maintainability being not considered.

</comment></comment></comment></comment></comment><comment><USER40> I've tried Julia out a few times and been very impressed. From what I've seen it really does a great job of bridging the gap between easy-to-use and high- performance. It kind of seems like D in that way. I can definitely see lots of situations where a language like this is desirable.

I'm in Chicago (and a U of C grad!). I might come to the meetup if I can.

<comment><USER47> I'm also in Chicago and probably going to the meetup. I haven't tried Julia, but I'd be interested in trying it with the help of experts.

</comment></comment><comment><USER48> > but it's poised to do for technical computing what Node.js is doing for web > development

I stopped right there. Node.js has only a few great use cases where it shines and in the real world, the vast majority of shops have not switched to using it.

<comment><USER49> > Node.js has only a few great use cases where it shines and in the real > world, the vast majority of shops have not switched to using it.

Of course not. 'Switching' is usually more pain than it's worth, especially if your previous solution works. New start-ups are likely the ones who will be using it, just as Rails took off in the start-up world.

Likewise, R and Python are going to continue to be in use in existing projects, and Julia is the potential future...

<comment><USER48> In my experience, most people are turned off by using Javascript on the backend of web-development. Your experience may be different, but I just don't think the analogy made in the original article is a very good one.

<comment><USER49> They may be turned off, but in my experience setting up a Nodejs backed site is incredibly easy with the way the frameworks, libraries, and everything are written. That alone will appeal to a lot of people. Front-end only people could easily put together a Nodejs backed up in no time at all.

Or you could use something like Coffee-script from front-to back. It's a very easy eco-system to get into.

</comment></comment></comment></comment><comment><USER50> I've used Julia for couple of projects and it's amazing, I seriously believe that Julia is better - in several ways - than _all_ of the widely used dynamic languages like Python, Ruby, Clojure, Octave or Lua. It's a brilliantly designed language. There are so many things to like about this language.

</comment><comment><USER39> Wait a minute! Can you embed Julia into a C program like Lua? Can it interface with complex C types cleanly?? This might be the scripting language I'v been looking for in my side project!

<comment><USER39> Wow. Okay, yes. It can be embedded[1]. It can call C code[2].

Julia may have just saved my project (which was dying because it needed a good scripting language that was fast)!

[1]: [http://docs.julialang.org/en/latest/manual/embedding/](http://docs.julialang.org/en/latest/manual/embedding/)

[2]: [http://docs.julialang.org/en/latest/manual/calling-c-and- for...](http://docs.julialang.org/en/latest/manual/calling-c-and-fortran- code/)

<comment><USER51> And embedding (and its documentation) will likely get much better very soon.

[https://github.com/JuliaLang/julia/pull/4997](https://github.com/JuliaLang/julia/pull/4997)

<comment><USER39> One big pain point so far is that it won't be easy to actually embed Julia into my app. So users of my app will have to install Julia (probably via homebrew) before they can script the app with it.

</comment></comment></comment></comment><comment><USER52> I see the Julia home page lists multiple dispatch as one of its benefits. Since my only real exposure to multiple dispatch was when I inherited some CLOS code where it was used to create a nightmare of spaghetti, I'm wondering if any Julia fans here would care to elaborate on how they've used multiple dispatch for Good™ instead of Evil™

<comment><USER17> Multiple dispatch lets you make math operators work like they do in path. That means that you can use `+` the same way on ints, floats, matrices, and your own self-defined numeric type. If `x` is a variable of your new numeric type, OO languages make making `x + 5` work easy, but `5 + x` super hard. Multiple dispatch makes both cases (equally) easy. This was, as I understand it, the major reason that Julia uses multiple dispatch.

Multiple dispatch can make interfaces simpler: you can easily offer several "versions" of a function by changing which arguments they take, and you can define those functions where it makes sense, even if those places are spread across multiple modules or packages. Julia provides great tools (functions) that make methods discoverable, help you understand which method you're calling, and help you find the definition of methods.

Looking at some Julia code (the base library or major packages) might give you a better idea of how Julia uses multiple dispatch.

<comment><USER52> Totally makes sense. Thanks for the info. Will also dig around in the code.

</comment></comment></comment><comment><USER53> When I read the opening paragraph, I immediately thought of the author as a Blub programmer [1].

"The problem with most programming languages is they're designed by language geeks, who tend to worry about things that I don't much care for. Safety, type systems, homoiconicity, and so forth. I'm sure these things are great..."

Yes, those things are great. They ultimately aid in helping the programmer tackle the inevitable complexity that arises when building systems in a maintainable way.

[1][http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

<comment><USER11> You're assuming the author wants to use Julia to build complex systems. Much of scientific computing has no need to do so, but is more concerned with discovering new knowledge and testing new ideas. Once the knowledge is gained, products may be built around that knowledge or new inquirires may be launched from it, but scientific computing usually uses programming languages as research tools rather than development tools.

<comment><USER54> This. The amount of code I write that never gets touched again after a paper goes to press is staggering.

</comment></comment></comment><comment><USER55> mini ASK HN: would there be any interest in supporting Julia in Visual Studio? (as a free/oss plugin).

i lead the Python Tools for Visual Studio project at msft and would be curious if there is interest.

as a side note, if you do you use Python & require Python/C++ debugging, PTVS now supports it: [http://www.youtube.com/watch?v=wvJaKQ94lBY#t=10](http://www.youtube.com/watch?v=wvJaKQ94lBY#t=10)

<comment><USER56> Are you using the IPython protocol for communication with python? If so, extending it to julia should be fairly straight forward.

<comment><USER55> we are for the integrated IPython REPL. but my question was more in terms of intellisense, debugging, profiling, mixed julia/C++ debugging, etc. ie, a fully integrated experience in VS.

<comment><USER57> The fully integrated experience you mention would do a lot for the Julia community in terms of gaining users tied to the GUI elements of MATLAB and VS for other languages. Integrated debugging and inspection in particular is a long-requested feature that has yet to see much attention.

Integrating with Pkg as Julia Studio does would be another important feature, as well as providing some sort of integrated plotting/graphics widget (a backend canvas along with plot navigation and image export, ideally supporting more than one of Julia's plotting backends).

I would certainly contribute to an alpha- or beta-testing effort :)

</comment></comment></comment></comment><comment><USER58> Does Julia have AOT compiler which produces a binary which can be linked to a C program? I am asking this because I have to consider availability on iOS - which is a platform prohibits JIT.

<comment><USER59> Alas, last time I checked this was still on the todo list. With sufficient annotations and type inference, there is no reason this would not be possible, but they way it sounded it would take rewriting or creating large chunks of core code and algorithms.

</comment></comment><comment><USER60> There's a lot to love in Julia, but my biggest nitpick is the 1-based array index. I can see where it comes from, but it's not something I can praise. I use R on a daily basis, where the aim is mostly interactive analysis, and still I cannot see any reason to use 1-based indexes. For a language that is instead mostly oriented to programming, I would have not went for the "familiarity" argument.

<comment><USER40> I'm guessing whoever was responsible for that decision was either a hardcore FORTRAN or MATLAB user, since both of those have 1-based indices. Or by a similar token, they could have chosen that because they expect that many of their users might be coming from either of those languages. I guess you'd get used to it, but I agree it's a big drawback.

</comment></comment><comment><USER61> I love Julia, Coming from the Ruby world it was very easy to get into.

It was easy to see how useful and expressive the language was by just doing a few Project Eulers.

</comment><comment><USER62> the interesting thing is that what excites me about julia is that it is clearly a scientific computing language designed by people who _are_ language geeks. the feature set seems very clean and well-thought-out to me.

</comment><comment><USER6> I don't really see the need for the author to make himself into a "cowboy" coder and point out how they ignore all those valuable insights and enlightenments of programmers.

Julia is a kind-of-fine language that is designed to appeal Matlab users first of all by its syntactical looks. Just like Javascript was designed to appeal to C and Java users by imitating their look.

Under the hood, Julia is quite a smart development, not only in terms of code generation, but also in terms of datatypes and object models.

Multiple dispatch is something that more or less only Lisps typically offer natively (and Dylan). When working with types (especially in dynamically strongly typed languages) this is often something what I am missing in other languages. Consider Python:

        if isinstance(x, Y):
            ...
        elif isinstance(x, Z):
            ...

This feature alone shows that the authors of Julia are rather the thoughtful language-loving authors.

So I would like to leave the small scope of the article but look at the greater picture: Julia and its competitors. There are actually quite a few on the market. A few domain-specific numerical libraries exist for C/C++/Fortran for scientific purposes (ROOT at Cern, etc.). They are more or less falling out of fashion. For a long time, Matlab has been dominant in some faculties for evaluation and working with data, process signals and images. It is not by accident that Matlab was created as a convenient Wrapper to Fortran libraries at the time. From a software developer's perspective, Matlab is for Cowboys.

Next to its high price (and the vendor lock in forced upon college and university students who are trained for matlab when there exist suitable open source alternatives), the most appalling thing about Matlab is its poor performance as a programming language. While its easy to write small scripts, solve linear algebra problems and plot a few things, I have hardly seen well organized Matlab code and I just think that it is impossible. While Matlab licenses cost heaps of money, support is not good and upon a version change you have to spend considerable amounts of work getting around API changes.

The Matlab clones available (Octave) are generally unimpressive. I think this has to do with the big effort of copying Matlab and the need to develop the whole tool stack (parser, interpreter, libraries). Contributors are hard to find because octave hardly offers any benefit over the original, like ReactOS with Windows, Octave can only react. I still value the effort of the octave folks, they have done some great work!

Scientific Python has chosen a slightly different path. Taking the fairly uncontroversial programming language Python, the authors created an infrastructure of thematically separated modules. While eliminating the need to design and implement an own programming language, a lot of work could be spent on building useful libraries. Also, existing libraries were reusable (databases, XML, etc.) and Python is a really convenient programming languages for both Newbies and professional software developers. So with this pragmatic approach, the contributers have created one of the best environments for scientific software development and would be my suggestion for anyone at the moment who just wants to use one system.

What still amazes me: While working in an ipython notebook ([http://ipython.org/notebook.html](http://ipython.org/notebook.html)) on some numerical calculations, I can just pull up Sympy ([http://sympy.org](http://sympy.org)) and perform some symbolic computations (Fourier transforming some function analytically or taking the derivative of some other, etc.).

Oh, and have I told you about how Scipy can replace R for really cool statistical analyses?

The part where Julia kicks in now is the point that Matlab has a lot of market ground, especially with engineers who are not extraordinarily passionate about programing. For some people the burden of learning another syntax is just too big, they are not full time programmers but spend their time more with acquiring data and using the results. I really hope that some of them who are not willing to switch to scientific python can agree on switching to Julia.

Full Disclosure: I have occasionally been forced to work with Matlab (so I do have some experience with it without being an expert) and it was not fun. This is one of the reasons I would like all Scientists to have the chance of choosing a good environment that is suitable for them. If its Matlab for some, so be it ;-) I have never looked back.

<comment><USER63> _What still amazes me: While working in an ipython notebook ([http://ipython.org/notebook.html](http://ipython.org/notebook.html)) on some numerical calculations, I can just pull up Sympy ([http://sympy.org](http://sympy.org)) and perform some symbolic computations (Fourier transforming some function analytically or taking the derivative of some other, etc.)._

You can certainly do it with Matlab (provided you have purchased the symbolic toolbox of course).

 _Oh, and have I told you about how Scipy can replace R for really cool statistical analyses?_

Sure, it can for some things, but why?

My thing with Python is that it kinda loses to Matlab for non-statistical work (except perhaps for select fields, like network analysis or language processing), and to R/SAS/Stata (depending on type of job and personal preference) for statistical stuff. Of course all of these (other than R) are proprietary and not cheap, but most universities have all of them anyway, and businesses just buy what they need.

btw: did you first learn Matlab, or Python? In my experience, there is a tendency for people who start with Matlab to dislike Python, and for people who start with Python to dislike Matlab :) Probably has something to do with some basic things being just so slightly different, and therefore bothersome.

Also, the Matlab IDE these days is actually quite decent -- does Python have something similar?

<comment><USER6> Sure enough there are parts of matlab where matlab is without serious competitors. I think however that a majority of needs is available for Python, although I know that I do not represent everyone's needs.

Quick google search yielded: [http://networkx.github.io/](http://networkx.github.io/) do not know how it compares though.

I switched to Sci.Python at the point where I had difficulty treating time series data with Matlab. I know there is a toolboxy-thingy from mathworks but it either was not available or I did not find the documentation. Anyway, I quickly got started with Pandas. I had prior knowledge of Python and other mainstream programming languages before.

Spyder is a Matlab-ish IDE with a variable explorer, etc. Some like the Ipython Notebook which I think is great for demonstrations and teaching, but eventually does not scale when projects grow bigger.

<comment><USER63> Yeah, networkx is pretty good -- I actually meant that network analysis and text processing are the two areas where I'd be quite comfortable recommending Python over Matlab.

For time series data, I'd personally pick R though, or perhaps SAS if it's large enough -- at least if any statistical analysis is involved...

I need to check out Spyder.

<comment><USER6> R is a software that I still need to check out.

I think enthought offers commercial tooling and support and also a IDE platform with tools for data story telling etc.. I usually use vim.

<comment><USER63> R design is somewhat like perl in the sense that usually there are a lot of ways of doing anything. This includes time series of course. That being said, last time I did time series, I've used xts and was quite happy with it.

</comment></comment></comment></comment></comment></comment><comment><USER64> Not to be a an asshole, something I have to preface a lot on here... but, uhh,

"Safety, type systems, homoiconicity, and so forth. I'm sure these things are great, but when I'm messing around with a new project for fun, my two concerns are 1) making it work and 2) making it fast."

Uhhh... Call me crazy, but wouldn't the "so forth" be what you care about if #2 is that important to you?

</comment><comment><USER65> How good is the interactive plotting experience?

<comment><USER17> I haven't had the smoothest experiences getting plotting in general to work (it's getting progressively better). The plotting in IJulia using PyPlot (matplotlib wrapper) has been good for me.

The Julia plotting packages are Winston, Gadfly, and Gaston. You can find detailed discussions of which one to use on the julia-users mailing list.

<comment><USER65> Thank you. I can appreciate that it's difficult to implement good interactive plotting, especially across platforms. It's also very very important!

</comment></comment></comment><comment><USER66> This is odd as a much better post on Julia v R v MATLAB v Python etc has got little attention: [http://slendermeans.org/language- wars.html](http://slendermeans.org/language-wars.html)

</comment><comment><USER67> I'm betting on Scratch.

The benefits of automation are mostly denied to me because I haven't the time to learn Julia or properly use the Python skills I already possess. I do however have the time to link and configure objects ala Scratch and Apple's Automator, or the first generation of what was once Allaire's Cold Fusion. Its not just me, either. The demand for automation tools is pervasive in business and education, but the time and innate skills needed to program effectively belong to a subset of the needy. Bring me a language that is truly a means to an end and take my money.

</comment><comment><USER68> Is there reason to believe Julia is actually fast outside of microbenchmarks? Their strategy of aggressive specialization will always look good in microbenchmarks, where there's only one code path, but could blow up in a large codebase where you actually have to dispatch across multiple options. I've never seen a Julia benchmark on a big piece of code.

<comment><USER69> I've had some problems with Julia performance for a finite element method implementation ([https://github.com/scharris/WGFEA](https://github.com/scharris/WGFEA)), mostly I _believe_ because of (1) garbage generated in loops causing big slowdowns and (2) slow calls of function closures. Functions defined at the top-level which don't close over environment values are fast, closures however are quite slow, which is really painful for situations where closures are so useful, e.g. to pass as integrands to integration functions.

There is an github-issue about the closure slowdown, but I don't have it handy. Both can be worked around, by writing in a lower level style, e.g. by using explicit loops acting on pre-allocated buffers, avoiding higher-order functions, etc. The pre-allocated buffers can be a lurking hazard though (Rust avoids the danger in the same strategy with its safe immutable "borrow" idea). I felt like these workarounds were giving up too much of the advantages of a high level approach for my own tastes.

I have converted to Rust to avoid the garbage collection for sure, and I'm extremely pleased with the performance. It would be nice having a REPL though, I do miss that. And I do intend to stay involved with Julia. I'm sure the situation will improve.

Good high performance garbage collectors aren't easy (and they are easy to take for granted after being on the JVM for a while) - that's probably the biggest challenge for Julia as a high performance language, IMO.

</comment></comment><comment><USER70> How does Julia interface with C? Is it easy to interface Julia with C because all it does is compile the C with Clang/LLVM?

<comment><USER17> Julia does not compile the C code; it links against shared libraries. It helps that Julia types can model C structs easily.

Manual entry on calling C: [http://docs.julialang.org/en/latest/manual/calling-c-and- for...](http://docs.julialang.org/en/latest/manual/calling-c-and-fortran- code/)

Blog post on passing Juila callback functions to C code: [http://julialang.org/blog/2013/05/callback/](http://julialang.org/blog/2013/05/callback/)

</comment></comment><comment><USER71> > the real benefit is being able to go from the first prototype all the way to > balls-to-the-wall multi-core SIMD performance optimizations without ever > leaving the Julia environment.

That sounds like someone who has not had to maintain any kind of software for more than 2 days.

</comment><comment><USER72> I'm betting on Julia and Rust really. Julia for Scientific programming and Rust for system.

</comment><comment><USER73> I want to write audio VST plugins in this language! Somebody please make that easy. :-)

</comment><comment><USER74> Based on your comments of Cowboys, you have obviously never rode hard put up wet.

</comment><comment><USER73> Is there a Julia forum anywhere. Like with a hierarchy of topics and subtopics and with hierarchical threads at the bottom level like HN? Optimally something that remembers what you've read.

<comment><USER75> Not a forum exactly, but julia-users and julia-dev are hosted on Google Groups which does threading and remembers what you've read. See the homepage for signup (julialang.org)

<comment><USER73> Thanks. A good variety of things there but I'm hoping someone puts together a phpBB (or similar) site such as Oculus Rift uses here: [http://oculusrift.com/](http://oculusrift.com/)

Such an organized site where you could drill down to topics of interest through broader categories would really be helpful. It would be best, of course, if it was set up and accessed through julialang.org as something official.

I don't know how to do that or I would. It isn't reputed to be very difficult to set up a phpBB site and I'm sorta hoping some enthusiast who does know how picks up on it.

</comment></comment></comment><comment><USER76> I like what I see so far at this page [1] and will watch closely to see whether Julia catches on.

One thing -- can we call agree that dictionary literals begin and end with '{}', that arrays are zero-indexed and that an index into a unicode string is properly a character and not a byte? Or are we doomed to permute endlessly on details such as these? I wish any new languages would set aside a large set of tempting innovations and just go with the flow on the smaller points.

[1] [http://learnxinyminutes.com/docs/julia/](http://learnxinyminutes.com/docs/julia/)

<comment><USER51> Well, in many ways, they are going with the flow. They're targeting mathematicians, and R/Matlab users… all of whom use 1-indexed arrays. And, really, the kinds of dictionaries you're used to _are_ constructed with {} braces. The square braces hold more specifically-typed keys and objects. It's a very clever analogy to their typed/untyped arrays. And wonderful for performance.

        ["one"=> 1, "two"=> 2, "three"=> 3] # -> Dict{ASCIIString,Int64}
        {"one"=> 1, "two"=> 2, "three"=> 3} # -> Dict{Any,Any}

</comment></comment><comment><USER77> Ok, good to see, but, what i can do with it that i can't with another language? -.-

<comment><USER78> nothing. [http://en.wikipedia.org/wiki/Turing_completeness](http://en.wikipedia.org/wiki/Turing_completeness)

</comment></comment><comment><USER79> I agree that Julia is great. But it's not there yet, either.

</comment><comment><USER80> Figlet sighting. Font: big. :-)

</comment><comment><USER81> All they're missing is a cool interaction mode like SLIME.

</comment><comment><USER82> Looks strangely similar to Lua

<comment><USER83> Well, most of the syntax he shows here is just calling functions. A lot of dynamic languages have similar syntax for functions calls. But you're right that Julia's syntax is superficially similar, with function definitions like

        function foo(bar, baz)
        end

and 1-based indexing of arrays (although Julia's use of that was to be similar to MATLAB).

</comment></comment><comment><USER84> No.</comment>


Collection of tests and tools to help diagnose WebRTC systems - <AUTHOR> https://github.com/webrtc/testrtc <comment><AUTHOR> Submitted this after seeing the story about Hublin: [https://news.ycombinator.com/item?id=11293014](https://news.ycombinator.com/item?id=11293014)

...I find that the tools we have are nearly good enough, but every so often the quality takes a nosedive in hangouts/screenhero/skype/adobe connect/gotomeeting/...and they offer no tools to diagnose the problem. It seems from the announcement of testrtc ([https://webrtchacks.com/webrtc- troubleshooter/](https://webrtchacks.com/webrtc-troubleshooter/)) that it was intended that the tests can be incorporated into 3rd party apps - here's hoping.</comment>


Ask HN: How reliable is PhoneGap to develop Native Apps? - <AUTHOR>

I am trying to port a desktop web app to native iphone app but wanted to have your opinion, how reliable PhoneGap is for developing full fledge native app. <comment><USER2> Phonegap was easy to setup and get going with.

I made the mistake of testing the app out on an iPhone 4 as I was developing it. Once it was finished, I tried it on my friend's iPhone 3G, and it was extremely slow and unresponsive to clicks.

I added all the possible optimizations that I could find people recommending on the web, but using the app on a 3G phone was still a horrible experience. Be sure to test your app on a 3G phone as you are developing it to test performance.

In retrospect, I should have taken the time to learn Obj-C and build a native app.

</comment><comment><USER3> I've used PhoneGap to build an app not so long ago. I had a few early niggles getting it set up but those were mainly down to myself (I'd never used a Mac until then).

I did have to leave out a few features I would've liked due to it running too slow (same app rebuilt in Titanium is much faster) but overall it was a pleasant experience and the mailing list is very helpful & friendly.

The only things that pushed me to Titanium were the speed issues with the more complex stuff I was doing (perhaps my fault?) and the fact that Titanium enables you to use proper native widgets rather than simulating them with jqtouch or whatever - This was _massive_ for me but no one in the real world has ever noticed :)

</comment><comment><USER4> We just completed a Titanium-based-App for iOS and Android and are much more happy with the result than we would have been with PhoneGap, what we used earlier for apps. Titanium is not only more powerful and speedier but also makes development cleaner and flexible.

</comment><comment><USER5> I started building apps for Android and iPhone simultaneously with a very early version of PhoneGap. The latest versions require less hacking to get up and running. It was very straight forward to get solid apps done on both platforms.

Out of the three apps out for iPhone and Android there have been no crashes and no complaints from users on bugs or unreliability. The apps make use of hardware (camera, gps and a few other things) as well as interfacing with a RoR backend for user systems, data syncing and upload pics taken in-app.

All in all, I've had no problems with it even after digging pretty deep into it and testing on Android 1.5-2.2 and old iOS through the latest versions.

</comment><comment><USER6> I just packaged an HTML5 game today. What do you mean by "reliable" though?</comment>


BBC – avoid microwave for better video conference - <AUTHOR> https://www.bbc.co.uk/news/business-52027348 <comment><AUTHOR> This kind of reporting damages the BBC's reputation. Imagine if their medical correspondents reported to the same standard.</comment>


How Facebook Figures Out Everyone You've Ever Met - <AUTHOR> https://gizmodo.com/how-facebook-figures-out-everyone-youve-ever-met-1819822691 <comment><USER2> This was an interesting read, thanks so much for sharing. They always find a way to dig as much info as possible out of people.</comment>