The Hugging Will Continue Until Morale Improves - <AUTHOR> https://blog.codinghorror.com/the-hugging-will-continue-until-morale-improves/ <comment><USER2> "People understand you cannot possibly protect them from every single possible negative outcome at a conference." Actually, they do.

</comment><comment><USER3> (December 2015)</comment>


Wildfire forecast from your mobile device - <AUTHOR> https://crowdprocess.com/demo-fire-embers

<comment><USER2> Only three parameters for such a simulation? Does this make sense?

<comment><AUTHOR> The model has lots of parameters, but you can only fiddle with three of them. Terrain and vegetation data is provided to the model by a database in a webservice. This is a function of the geographic location.</comment></comment>


Selfiexploratory - <AUTHOR> http://selfiecity.net/selfiexploratory/ <comment><USER2> Very interesting, though I would love to see more data in there. 3840 is such a small number for what is actually out there.

I noticed that a lot of the automated stuff, like glasses, is getting a pretty high false positive rate. ~25% of the 'glasses' ones are actually no glasses. Would be very cool to see more out of this though.

Also, don't they need to attribute the image back to where they got it on instagram to comply with the API usage terms?

</comment><comment><USER3> Hmm, if I click (only) on "eyes closed", most of the resulting images are with eyes open still.

<comment><USER4> Only the age and gender are determined by humans, the rest is automatic face analysis, so somewhat more prone to errors.

</comment></comment><comment><USER5> Very cool visualization... I wonder how they get their data?

<comment><USER6> According to [1], they collected half a million photos from instagram, selected 20,000-30,000 photos from each city from that, then filtered the set down by using Mechanical Turk.

[1] [http://selfiecity.net/#dataset](http://selfiecity.net/#dataset)</comment></comment>


First impressions of an Amazon bookstore - <AUTHOR> http://www.idealog.com/blog/first-impressions-amazon-bookstore/ <comment><USER2> It sounds like something out of the song "In the Year 2525".</comment>


What's new from Firebase at Google I/O 2017 - <AUTHOR> https://firebase.googleblog.com/2017/05/whats-new-from-firebase-at-google-io.html <comment><USER2> Comments moved to [https://news.ycombinator.com/item?id=14362756](https://news.ycombinator.com/item?id=14362756).</comment>


Show HN: Board Game AtlasBoard Game Atlas – A Map to the World of Board Games - <AUTHOR> https://www.boardgameatlas.com <comment><AUTHOR> I also built an API to access all the data that I just released as well: [https://www.boardgameatlas.com/api/docs](https://www.boardgameatlas.com/api/docs)

</comment><comment><USER2> This is simply another aggregating list with a search function, and while another database is nice, this is quite clearly nothing at all like a map, and not even a guide.

<comment><USER3> This. I was hoping something of the sorts of "if I like X game, I might also like Y game"

Another suggestion, have more pictures of the games. Specially of the board, mid-game. It's a nice way to have a sort of feel for the game.</comment></comment>


Membase, The Database Powering Farmville - <AUTHOR> http://www.readwriteweb.com/cloud/2010/08/membase-the-database-powering.php <comment><USER2> What an uninformative article. Basically it resumes to

1\. Farmville uses Membase.

2\. Membase is related to memcached.

You have to go to Wikipedia (<http://en.wikipedia.org/wiki/Membase>) to find some relevant info (seemingly picked up from marketing materials, though). Such as: they seem to aim for easy installation and management.

</comment><comment><USER3> I'm curious if other shops are deploying Membase, as it being the backend behind Farmville attaches more negative connotation than positive for me.

My girlfriend has a ludicrous Farmville addiction, and I don't think she's gone more than a few hours at a time without it messing up and loosing whatever she'd just spent the past twenty minutes doing. If that happened to me more than once, I'm pretty sure I'd stop playing that game.

<comment><USER4> I don't like Farmville much, but attaching some sort of negative reaction to Membase because Zynga uses it is pretty silly IMHO.

If anything, I'm impressed that Membase is standing up to the torturous load of all those strawberry harvests and ponies. :)

We're in the middle of doing some testing with it at Loggly, and we've found them exceedingly responsive to our requests.

<comment><USER5> The specific point that m0nastic just said (and which you seem to have ignored) is that it /doesn't/ stand up to it, with an anecdote that aomeghing glitches up every 20 minutes. Your response makes it sound like it was an ad hominem attack of the form "Zynga is addictive, they use membase, therefore I hate membase due to negative connotaion", as opposed to "Zynga's data seems fail, Zynga uses membase, therefore membase may be suspect as it could be contributing to those failures (making Zynga a weird example to choose)".

</comment></comment></comment><comment><USER6> It would be interesting to hear about the design of membase. I wonder if someone has a architectural overview somewhere. EDIT: It seems like a article with a little more information is at <http://www.infoq.com/news/2010/06/membase>

</comment><comment><USER7> For those on OSX, I just hacked together a homebrew forumla for membase beta 2 yesterday:

<http://groups.google.com/group/membase/t/69a47f80a2b772b8></comment>


Startup surrealism - <AUTHOR> http://xkcd.com/1032/

<comment><USER2> I was going to say the most quirkily/avant garde-like creative people are more successful than those who think inside the box. Though that may just be an opinion.

</comment><comment><AUTHOR> This reminds me of Color. As though someone has managed to create money out of spin and thin air.

<comment><USER3> I wouldn't say they _created_ any money. Took investor's money? Yes

<comment><AUTHOR> Fair enough, but the jarring disconnect for observers is the same.</comment></comment></comment>


Microsoft doubles down on Kubernetes for Azure - <AUTHOR> https://blogs.dxc.technology/2017/11/21/microsoft-doubles-down-on-kubernetes-for-azure/ <comment><USER2> Edit: Thanks to replies explaining that in fact AKS doesn't charge for the master! I'm leaving the rest of this comment standing because it's an honest reply to the article posted - Microsoft isn't disingenuous, this article is just wrong.

> Be that as it may, Microsoft is offering AKS for free. You will only pay for > the virtual machines (VM) that you use for managing your Kubernetes cluster. > Microsoft says, "Unlike other cloud providers who charge an hourly rate for > the management infrastructure, with AKS you will pay nothing for the > management of your Kubernetes cluster, ever. After all, the cloud should be > about only paying for what you consume."

This is disingenuous. We're talking about k8s, so GKE is the comparison point. Yes GKE charges a flat hourly fee for cluster management, _regardless of the number or size of the nodes_ [0]. But GKE doesn't charge for the master instances (which are hidden away behind the GKE product). So AKS will not charge for the cluster management, but will charge for the master instances. Neither pricing model is more "for free" than the other.

Also, if we have to think about the master instance sizes on AKS because we're paying for them, then that's one thing we have to manage on AKS that we don't have to manage on GKE - GKE adds more value by more completely managing our cluster.

[0] pedantic: there's actually _no fee_ for clusters of less than 6 nodes.

<comment><USER3> > Also, if we have to think about the master instance sizes on AKS because > we're paying for them, then that's one thing we have to manage on AKS that > we don't have to manage on GKE

This is entirely premised on your speculation which turned out to be false. Curious that you're willing to call this blog post disingenuous when you're the one spreading falsehoods?

<comment><USER2> "You will only pay for the virtual machines (VM) that you use for managing your Kubernetes cluster."

</comment></comment></comment><comment><USER4> This is a good thing; Microsoft will increase competition in this space by applying its expertise in dev tools to Kubernetes.

I just hope that MS doesn't add in too many platform-specific pieces that would encourage vendor lock-in.

For example k8s ingress right now is based on controllers and GCE controllers support/don't support a wide variety of things compared to nginx ingress... these areas of Kubernetes make me worried about potential future switching costs.

<comment><USER5> Fortunately there's a bunch of ingress controllers you can use: Traefik, Voyager, HAProxy, and probably several others. And it's surprisingly trivial to write your own.

So ingresses is not currently a weak point in relation to vendor lock-in happens. And Kubernetes already supports plenty of non-Google tech; as an open source project, Kubernetes is refreshingly non-Google-focused (there are a bunch of players, notably Red Hat and Microsoft, ensuring this).

As an aside, the current ingresses (including the Nginx one and Google's own GLB one) all have annoying deficiencies (subpar support for TLS and per-route timeout settings among the biggest). Ingress support is, and has been for a long time, Kubernetes' weakest point. For example, GLBs max out at 20 TLS certs (ridiculous if you're hosting many customers on a SaaS solution) and default to a timeout of 30 seconds (you can't control this using ingress annotations; you have to manually go in and edit the backends via API or UI) (which doesnt work for big streaming requests and WebSockets). These are also very trivial problems compared to the complex ones that are being solved by big new features in Kubernetes proper, so it's a bit surprising that ingress implementations are lagging to this extent.

<comment><USER4> >> As an aside, the current ingresses (including the Nginx one and Google's own GLB one) all have annoying deficiencies

Agree, this is along the lines of what I meant. For example GCE ingress allows you to reference a global static IP while this is not possible with solely nginx ingress due to limitations with the TCP load balancer. There are separate ingress annotations for GKE/nginx/haproxy, etc. If I want to use the global-static-ip GCE annotation, this will make it a little harder to move to Azure.

<comment><USER6> Totally fair points, and vendor lock-in is something to be highly vigilant of.

For some context, though: the ingress functionality is rather recent in Kubernetes and is still fleshing out in terms of demands in the market and across cloud providers. Another year or two will do a lot for equality and saner networking solutions for small-scale and bespoke K8s deployments.

I got a little shock that I had to set up an ingress controller on each of my nodes (on our VMWare cluster), but going through the nuts and bolts of it I can see why it's hanging a bit behind the rest of the product. I think the devs are being smart letting the ecosystem mature a little instead of pushing out something half-baked and prematurely limiting.

</comment></comment></comment></comment><comment><USER7> Whenever I look at Kubernetes, I can't help myself but think that it's overcomplicated, with too many moving parts. Almost as if to incentivise using the hosted solutions instead of rolling it on your own on some VPSs. I can deploy a HA Swarm Mode cluster anywhere in minutes, while I'm not sure even where to start with Kubernetes. Do I use juju (recommended Ubuntu way), or do I use kubeadm? Which network add-on do I use? How do I upgrade (the procedure seems to be different with each version)?

<comment><USER8> If you're not prepared to dedicate a small team to running Kubernetes, I'd say it's too much for your needs.

Read the Borg paper for an idea of what k8s is meant to solve. If you have hundreds of services spread across 10s/100s of nodes, then the complexity of k8s starts to become amortized. Similarly if you have 100s of devs without a consistent way to do deployments, k8s starts to make sense.

Source: tech lead for a team managing a large on-prem and cloud k8s cluster.

</comment></comment><comment><USER9> I really, really hope aws joins the game. re:invent is around the corner.

<comment><USER10> Well, you can use something like kops, although it's a little more difficult to get started, I guess. This new tool from Azure is basically the same thing.

It's a little interesting since they already have ECS, which isn't that bad either, but it seems like everyone just wants Kubernetes. Will they do both, or provide a migration path?

<comment><USER9> ECS is okay, used it quite a bit recently. It definitely has some quirks to it, like having to use CloudWatch events to figure out the port given to the container when using bridge network. Maybe if the service discovery story was a little bit more defined, ECS would be easier to use. There's lots of little manual things one has to do around it to make it work as swift as other solutions available.

With regards to k8s on AWS, I do not have a problem running it myself but some backing from AWS definitely help defining k8s as "the solution" for running containerized workflows. Here's one hoping.

</comment></comment></comment><comment><USER11> So restaurants give you ketchup for "free" too, but turns out you're paying for it.

This is stupid to say the management node is free, you're just paying for it in another way. Now if they said they were able to run the node so cost effectively that it's just included in the hourly node cost, then that's a plus.

<comment><USER6> For SMBs and smaller dev shops kicking off their forays into container development, not to mention customer deployments, the simplified cost models make it more management friendly and more understandable to non-IT actors.

Whether it is absolutely cheaper than GCE or whatever, and if master management is a requirement, is a separate comparison based on the solution. Cutting out the management node costs removes a barrier to entry and creates a more streamlined product.

Oh, it also makes their Kubernetes services usable within the free credits they give out on Azure via their MSDN subscriptions... so suddenly millions of devs can use AKS for demos and temp-hosting "for free", which is huge in creating mindshare in the Enterprise...

<comment><USER11> I'm sure you're right, but not understand economics to that level wow.

</comment></comment></comment><comment><USER12> I hope they don't embrace, extend, extinguish.</comment>


Multi-tenant databases for software as a service: schema-mapping techniques - <AUTHOR> http://www.systemswemake.com/2010/11/18/multi-tenant-databases-for-software-as-a-service-schema-mapping-techniques/

<comment><USER2> _This paper describes a new schema-mapping technique for multi-tenancy called Chunk Folding, where the logical tables are vertically partitioned into chunks that are folded together into different physical multi-tenant tables and joined as needed. The database's "meta-data budget" is divided between application-specific conventional tables and a large fixed set of generic structures called Chunk Tables._

Interesting idea.

It is a clear weakness with most (if not all?) popular frameworks that they don't support multi tenancy (of hosted business services) in any way what so ever.

</comment><comment><USER3> We use a more secure model here at ClearDB to ensure that customers (and code) cannot accidentally mix between two different data sets. As such, we don't rely so much on meta programming at the business level. Food for thought though.</comment>


Linus on git, central repositories, and commit access lists - <AUTHOR> http://lwn.net/Articles/246381/ Linus responds to various questions about Git, development methodologies and tools.
<comment><USER2> I've been using SCMs for close to a decade and I really like git and I recommend it to a lot of competent devs. But there are some issues that irk me too much about SCMs ad they're fundamental enough to make me wanna start something that fixes these issues.

Anyone else interested in transforming SCMs? Contact me (info in profile).

<comment><USER3> What's one of your fundamental issues with SCMs?</comment></comment>


Show HN: A library I wrote to perform statistical analysis - <AUTHOR> https://github.com/subiabre/phpmetro/ <comment><AUTHOR> Hey, there! First time posting to HN. A little info about what and why is this package, and the future of it, in hopes that it catches some attention and gets to help other php developers out there.

I wanted to calculate several statistics about a project I was working on, ideally wanted to write and perform them the same way you write and perform tests with PHPUnit, and I was baffled to discover there wasn't already any existing library to do that, not libraries to do it like PHPUnit, but any library at all.

I created PHPMetro to allow me to just write cases extending from a base case, add data on setUp and automatically perform test methods from console. And I think my library does a pretty good job at it's task.

Despite being an statistical analysis tool it does not provide any methods to perform statistical calculations, there are already very good libraries that do that.

Instead PHPMetro lets you create stacked analysis cases with contained samples that are dinamically generated, and perform and obtain a result from as many tests as you want.

I'm currently working on improving the current run performance, i.e reduce time and memory consumption. Since it's main ability consists in generating sampled data makes sense that it's good at doing that at large scale (samples in the hundreds of thousands in size).

Of course, feel free and welcome to join and contribute to this package if you spot anything that could be fixed and/or improved, I'd also love to receive some feedback about it of people who find it useful/interesting/etc.</comment>


At $300 The Xbox One Will Win - <AUTHOR> http://omarismail.com/post/51063102575/at-300-the-xbox-one-will-win

<comment><USER2> Considering I stopped watching broadcast TV entirely a couple of years ago, the Xbox One has already lost.

I'd say you measure the success of a video game console in how well it lets you play video games, not gimmick features that arent available outside the US.</comment>


Why we like what we like - <AUTHOR> https://www.nationalgeographic.com/science/2019/08/why-we-like-what-we-like-a-scientists-surprising-findings/ <comment><USER2> Indian Yogic system has interesting stake on this. check this video - [https://www.youtube.com/watch?v=QQn8X4FbpTM](https://www.youtube.com/watch?v=QQn8X4FbpTM)

</comment><comment><USER3> The biology content is interesting, but the discussion of freedom/agency is so painfully amateurish that I had difficulty finishing the article.

</comment><comment><USER4> Good article, reminded me the book "the selfish gene".</comment>


Cleaning bad code - <AUTHOR> http://www.gamasutra.com/view/news/176218/Indepth_Cleaning_bad_code.php <comment><USER2> See also "Working Effectively with Legacy Code" book by Michael Feathers, IMHO __the__ book on this topic.

[http://my.safaribooksonline.com/book/software-engineering- an...](http://my.safaribooksonline.com/book/software-engineering-and- development/0131177052)

<comment><USER3> Very nice book. I use it often too. Highly recommend it.

</comment></comment><comment><USER4> My favorite technique for taming legacy code is to define facade interfaces [1] that carve out new modules. When I'm trying to decipher old code (or a big new library), the facade captures my understanding in a simpler API using terminology familiar to me. I can quarantine ugly code and "discover" modules that may have evolved out of the original code. Facades are also a great place to insert debug logging and assertions.

With a well-placed facade, I'm like Alexander cutting the Gordian Knot of code dependencies. :)

[1] <https://en.wikipedia.org/wiki/Facade_pattern>

</comment><comment><USER5> I'm cleaning code right now and do it 90% in line with these good advices.

However, I differ on the over engineering issue. It is not enough to say YAGNI. With YAGNI people will put a value in a new column of table, then later on they will need another one, another column, then in fact we need to know when these value where set, by who, and you get a table with 600 columns, while what you needed to do from start was a simple event table, but YAGNI, you know.

So, no, you need to think carefully for some parts of your code about what the future might look like, specially for data structures and storage part. You need to avoid the many traps, and only with some careful consideration and some experience will you be able to do "the simplest thing that works" the correct way.

So what is the correct way? This can be easily seen in examples: to me vim, git, Linux, gnu coreutils, python, seem to be designed the correct way, even after a long life (but git) they still have many user, the base is solid and can support many fast changing projects.

<comment><USER6> I don't think that's how YAGNI should be applied. I've always found it to be a great rule of thumb provided you're also constantly refactoring.

So in your example, perhaps the first column addition is justified. When it comes time to add the second column, _that_ is the time to take a step back and think of a more general abstraction. This is because you've just proved for the first time that you actually need one. If you can't absolutely predict future requirements (and humans generally speaking are bad at this), perhaps you'd only ever have needed that one column in the first place. That way you keep a clean, simple codebase until you know a more complicated framework or pattern is required.

Of course, a rule of thumb is just that; I've seen YAGNI far too religiously applied too. And I'm in absolute agreement about being careful to think ahead carefully about the overall design and architecture of what you're working on - otherwise it's easy to become trapped in local minima of your solution space. It goes without saying different projects are suited to different approaches - YMMV.

</comment></comment><comment><USER3> One thing that I often do when dealing with old code that's performing low- level operations and outputting some binary format is to md5 the output. After that, I can change the code and I often do this when people ask for less memory usage, better over-all performance, etc. Once the code has been changed, I can prove that it uses less memory/CPU/whatever, and verify the md5sum of my output against the original output so I know the code still outputs as intended.

<comment><USER7> It's a good trick, but you can't md5 all possible outputs. How do you choose the inputs?

</comment></comment><comment><USER8> Most of this is really great advice. However I have run into horror stories that would shock you. For example:

1) Delete most of the comments 2) Stuff breaks. WTF? The code was processing its own comments!

Also I would add a third option here (the option we chose with LedgerSMB) which is:

"Localize the bad code, and replace with good code, a block at a time."

Some code can never be cleaned up effectively. In this case, you separate out, rewrite, and live with the fact that this will break some stuff while you get something that, on the whole, is more robust. Now in this approach the thing that is critical is you make _as few changes to the legacy code base as you can._ You also look for other layers at which you can implement things like new, needed security controls, or API's and you do everything you can to avoid putting new stuff through the legacy sections.

<comment><USER2> > 1) Delete most of the comments 2) Stuff breaks. WTF? The code was processing > its own comments!

My campfire story: change method name, stuff breaks. Method names had been parsed in a wrapper object (Python's __getattr__ being abused) so that calling 'setFoo()' triggered a 'Foo_changed' event. In fact, the method names constituted a mini-language with its own grammar and semantic. Apparently someone had gotten high on reflection.

<comment><USER9> Corollary: AOP is the enemy of refactoring.

You unwittingly changed one of the (seemingly unused/unnecessary) pointcuts and your aspects aren't firing anymore. While not impossible to track down, these problems are difficult to resolve.

<comment><USER10> This worries me every time I use AOP, but I mitigate that risk by writing integration tests which assert that the aspects are doing what they are intended to, and also to raise an alarm if somebody unknowningly breaks them.

</comment></comment></comment></comment><comment><USER11> >> On the other hand, the long-term effects of never cleaning your code can be devastating. Entropy is the code-killer.

I love that quote.

Can I have "Entropy is the code-killer" on a T-Shirt please.

<comment><USER12> You can make one on CafePress. Here's one that I just made: [http://www.cafepress.com/cp/customize/product2.aspx?from=Cus...](http://www.cafepress.com/cp/customize/product2.aspx?from=CustomDesigner&number=687278700)

It's a little pricey for a t-shirt---probably because they only expect one sale. I don't know if there's a better way to design custom t-shirts.

<comment><USER11> I was not expecting that. :-)

</comment></comment></comment><comment><USER13> I find the 7th point to be really great piece of advice, I simply love the subtle way, in which author is pointing out advantages of functional programming.

</comment><comment><USER14> You could pretty easily title this "writing code right the first time" and some adjustments to tense, I don't think anyone would know the difference. Great article.

</comment><comment><USER15> I like the part about objects. Never thought about it like that before.</comment>


ThinkPad X1 Yoga (2017) (AKA ThinkPad X1 Carbon Touch Convertible) - <AUTHOR> http://shop.lenovo.com/us/en/laptops/thinkpad/x-series/x1-yoga/ <comment><AUTHOR> I am super excited about this:

\- USB-C (w/Thunderbolt) (hello great docking solution)

\- 14" WQHD OLED (2560 x 1440) Touch 300 nits

\- Convertible, keys retract when converted in tablet mode

\- Up to 16GB ram

\- Up to 1 TB SSD PCIe TLC OPAL2

\- I7-7650U Intel® Core™ i7 vPro™ processor

\- Touch fingerprint reader (like a Pixel or Nexus, not swipe)

\- Dockable, rechargeable pen/stylus (great if you give technical presentations

\- MicroSD

\- WWAN + MicroSIM (great for a no-extra monthly charge, free data only SIM on Project Fi)

\- Trackpoint touchstick for those who love it (myself)

\- Still has a full size HDMI port

\- Starts at 3lbs

\- Black or Silver (not aluminum)

\- Thunderbolt 3 USB dock available

Cons:

\- Ships with Windows only, no option to ship without an OS

\- No factory GNU Linux options available (Ubuntu etc.)

\- Webcam doesn't jump out at being great, will probably still use my Logitech c920

</comment><comment><AUTHOR> Only video I can find so far. [https://www.youtube.com/watch?v=PO38KmaPIuY](https://www.youtube.com/watch?v=PO38KmaPIuY)

<comment><AUTHOR> Another video from a Lenovo ambassador via CES 2017 - [https://www.youtube.com/watch?v=As1TcYVkqNo](https://www.youtube.com/watch?v=As1TcYVkqNo)

<comment><AUTHOR> \- Charge stylus pen for 15 seconds, 80% charge

\- 4,096 levels of pressure sensitivity</comment></comment></comment>


Why you don't need much math to learn data science - <AUTHOR> http://www.sharpsightlabs.com/blog/math-for-data-science/ <comment><USER2> Math is the easy part. Having the intellect to understand what the numbers coming out of the sausage machine is harder. As always, the incentive is to ignore all that difficult stuff ... Look ma, I am soooo machine learned!

</comment><comment><USER3> Sometimes I feel strange in the "data science" field. I did a sociology degree in a small Spanish university (UDC) and I found the Multivariate Statistics course way harder than almost anything out there.

I do struggle with programming though. Not really the logical part, but even in R plotting something that would be simple in Excel or SPSS is quite tricky. Maybe it is because I'm not a native english speaker but how stuff is named is weird and doesn't make much sense to me, so it becomes harder to memorize.

For example, why did they choose str() for a quick view of data frames? To me that reads naturally like "string()", so it would make sense to use it for doing stuff with strings.

That's why, while I do use R, I really love tools like KNIME above all. Maybe it's just a matter of keep doing it, but while other people seems "fluent" with R o Python I really can't do much without documentation, and some trial and error.</comment>


Version-bump your software with a single command - <AUTHOR> https://github.com/peritus/bumpversion

<comment><USER2> My version numbers live in setup.py, which I can get within the code by the following:

      import pkg_resources
      version = pkg_resources.require("my_package_name")[0].version

So a version bump means editing a single file.</comment>


ETFs, Volatility and Leverage: Towards a New Leveraged ETF - <AUTHOR> https://smabie.github.io/posts/2019/10/04/vol.html <comment><USER2> Leveraged ETFs are not leveraged in the traditional since as one might expect. The article misses this point and the author should rectify and clarify immediately.

Leveraged ETFs promise the daily return. They are reset every single day. So your return over N days is completely path dependent.

Even a positive return of the benchmark may result in a negative return in a leveraged ETF if that path was volatile...

Leveraged ETFs are trading tools. Do not hold them in your portfolio for more than a few days.

<comment><USER3> Just curious, what does it mean to say that they are reset everyday?

<comment><USER4> You have to return the leverage at the end of the work day. Meaning the shares have to be sold at the end of the day and then brought again the following morning.

Meaning you are getting 3x the increase from the start of the work day until the end of the work day but also 3x the potential loss.

The problem is that you are exposed to volatility and cannot just ride out a storm. This is a day trading feature and not something for the long term investor.

If you have a crystal ball and know that you'll have more up days than down days, then you are good. Otherwise it is akin to speculating rather than investing.

They are probably good for a late stage boom cycle (if you could time the bust).

(Based on the Leveraged ETF's I have found)

</comment></comment></comment><comment><USER5> Existing leveraged ETFs are a scam, designed only to fleece "muppets" (as a Goldman Sachs guy once called us).

Here's a real life example. You can buy a financial instrument that purports to hold gold bars on your behalf. Its symbol is GLD. In the past year GLD price has moved from roughly $123 to $153, more or less equal to the price change in 0.1 oz of gold.

But that movement isn't enough for some people. They want leverage. So two leveraged instruments were invented. Cleverly named NUGT and DUST. Purported to achieve 2x moves in Bullish and Bearish gold directions, respectively.

But let's look at NUGT price from 1 year ago to now. $20.75 -> $7.72.

DUST is even worse. $17.33 -> $2.56.

A lot of this under-performance is because of the friction involved in leveraged ETFs borrowing and using futures. (This has been explained in great detail by others, I won't attempt it).

Summary: GLD (the commodity) 24% gain, NUGT 63% loss, DUST 85% loss.

Yes yes, the purveyors of NUGT and DUST will tell you that they're not meant to be held for 1 year. They're for very short term. But they're just trying to mislead you. The fact that both directions lost so much money means that these products do nothing but scam muppets.

The SEC should never have allowed ETFs like that.

<comment><AUTHOR> Hi, I wrote the post. I'm wondering exactly what your issue is with leveraged ETFs? What, mathematically, makes them unsound? I think my post covers the risks and benefits of them while also proposing a new kind of leveraged ETF that might help mitigate the volatility drag associated with leverage.

Edit: I'm not familiar with the leveraged gold ETFs you mention, but I am familiar with UGLD, which tracks the 3x daily return of gold. Comparing UGLD vs GLD:

[https://www.google.com/search?client=firefox-b-1-d&tbm=fin&s...](https://www.google.com/search?client=firefox-b-1-d&tbm=fin&sxsrf=ALeKk00j4-E-gQA5dxmzjSRZx_SB9q3wIw:1586139494836&q=NASDAQ:+UGLD&stick=H4sIAAAAAAAAAONgecRoxi3w8sc9YSndSWtOXmNU5-IKzsgvd80rySypFJLkYoOy- KV4ubj10_UNU8oMM5Irs3gWsfL4OQa7OAZaKYS6-7gAAGxIYxJKAAAA&sa=X&ved=2ahUKEwiWo52J3tLoAhVJmnIEHehlCwQQ3ecFMAB6BAgPEBM&biw=1517&bih=891#smids=/g/11bbrnsz0j&wptab=COMPARE)

UGLD is up compared to GLD. Moreover, UGLD is correctly tracking the 3x daily move of GLD.

Also, the use of futures and leverage aren't really related. Sure, that's how most leveraged ETFs work, but there's no reason why there couldn't be a leveraged ETF that simply borrowed the money.

Edit2: both DUST and NUGT are based on the Gold Miners Index, which isn't the same as GLD (which tracks actual gold).

<comment><USER5> My issue with leveraged ETFs is, quite simply, the 30,000 foot view of results: They suck.

Even though NUGT and DUST are from the same fund company and purport to do the opposite of each other, they both lost substantial amounts of muppet money over the last year!!!

You're trying to analyze these things mathematically, I'm just saying "look at the actual results over a years time".

I suspect (without checking in detail) that UGLD is doing better is because it's an ETN and not an ETF. Usually an ETN is a debt obligation of a financial counter-party, in this case Credit Suisse.

How Credit Suisse manages their debt agreement (the ETN) is up to them. These can be black boxes to the outside world. It's possible that CS is buying or selling physical gold or gold futures to hedge their exposure, but they don't have to be. It's simply a financial contract.

Right now CS is a good financial risk. But the same might have been said about Lehman Brothers before the great recession. They were counter-parties to some ETNs and people who owned those were screwed when Lehman went bust: [https://www.etf.com/sections/features-and-news/lehman- bros-e...](https://www.etf.com/sections/features-and-news/lehman-bros-etn- fallout)

I agree with you that a leveraged ETF they can simply borrow money to increase leverage. (Not much different from how leveraged hedge funds operate). But for some reason they don't operate that way. So it must be somehow advantageous for them to use futures. Maybe because it's difficult to "short" something like e.g. WTI crude in a standardized way on an exchange? You can be long or short a futures contract for gold or WTI, that's a liquid market. But shorting the physical commodity might be harder?

</comment></comment></comment><comment><USER6> " This strategy also greatly reduces the risk of ruin, as the S&P 500 would need to lose at least 1/3 of its total value in a single day for the fund to be wiped out. Though certainly imaginable, this event is unlikely as the biggest single day loss in the history of the S&P 500 was Black Monday in 1987, in which around 20% of value evaporated from the S&P 500 in a single day."

That didn't age well (article is from last October)

<comment><USER7> How? The recent losses were nothing compared to Black Monday, especially after a massive 2019.

<comment><USER8> It dropped 12% on one day in March, not as big as the 20% on Black Monday but not "nothing". And the bull market of 2019 isn't really relevant when the article focuses on ETFs that leverage single-day moves.

</comment></comment></comment><comment><USER9> Your analysis kind of matches with Kelly's betting. 3 times is the optimal: [https://seekingalpha.com/article/4230171-how-to-apply- card-c...](https://seekingalpha.com/article/4230171-how-to-apply-card- counting-strategies-to-etf-portfolios)

</comment><comment><USER10> Three questions:

What is the cost of the leverage and how does that affect returns

What is the friction cost of all the trades needed?

Where is part 2?

</comment><comment><USER11> Wow, I couldn't even get myself to finish reading this article. This is based on a very dangerous, ignorant understanding of how markets work. Whatever "advice" there is, please ignore it.

<comment><USER12> Could you expand a bit further on what you think the OP's misunderstanding of the market is?

<comment><USER11> One huge example is an assumption that portfolio returns are normally distributed. That's not a minor nitpick, this invalidates every formula that goes after.

<comment><USER13> Well, you did say you didn't finish it. So would it surprise you to learn that topic is addressed directly?

<comment><USER11> Thats a fair assumption. But I did skim to the part that attempted to address non-normality—it doesn't. Under non-normality, not a single formula in this post holds ("standard deviation" does not exist).</comment></comment></comment></comment></comment>


Twizzler: An Operating System for Next-Generation Memory Hierarchies [pdf] - <AUTHOR> https://www.ssrc.ucsc.edu/Papers/ssrctr-17-01.pdf <comment><USER2> Very cool.

I'm convinced access to persistent large addressable memory will fundamentally change the way we program.

Less optimistically, I imagine it's going to take a lot of time for this paradigm shift to happen. The idea of the cache hierarchy is a long held one and permeates both education and industry.

<comment><USER3> Didn't the AS/400 (IBM iSeries today) pioneer this architecture with its single-level store?

<comment><USER4> Yes, and many other things. Ahead of its time.</comment></comment></comment>


Reddit has shut down its nascent cryptocurrency project - <AUTHOR> http://www.theguardian.com/technology/2015/feb/02/redditcoin-quietly-killed-off-and-lead-developer-fired <comment><USER2> Not sure where the author got "redditcoin" but here's what we're actually doing with redditnotes (I said the same thing to fortune when this rumor first arose):

We will be issuing redditnotes.

Our research leads us to want to wait until the law and technology around cryptocurrency are further along before deciding exactly how. We want to make sure we can give the community the full value of the equity when they receive it in the future, and today we haven't been able to find a way to do that within existing regulations.

Edit: here's the last official blog post on the subject. [http://www.redditblog.com/2014/12/announcing-reddit- notes.ht...](http://www.redditblog.com/2014/12/announcing-reddit- notes.html?m=1) We were not contacted by this guardian reporter didn't contact us for comment. So it goes.

<comment><USER3> You should be issuing an official blog post stating this in explicit, unambiguous terms, as there's a lot of confusion around just what exactly are RedditNotes.

EDIT: A new post, to reflect the fact that the current cryptography plans have been halted.

<comment><USER2> We did in December. This is still a work in progress. Thanks, I've updated my comment.

<comment><USER3> Ah, I meant issue a new post, to reflect the fact that there are no cryptographic plans currently.

If you read the corresponding Reddit thread to that blog post ([http://www.reddit.com/r/blog/comments/2pt25f/announcing_redd...](http://www.reddit.com/r/blog/comments/2pt25f/announcing_reddit_notes/)), there's a lot of skepticism on whether RedditNotes is actually legal (including in this very HN thread), and there is speculation that the laying off of the one person who could actually implement it indicates that the project is dead.

<comment><USER4> don't tell alexis what to do

</comment></comment></comment></comment></comment><comment><USER5> I'm glad they killed this project. I can't see how integrating a crypto- payment system into reddit would have worked out into anything other than a disaster.

First of all, if it became commonplace that reddit accounts might contain some sum of crypto-money, the bustling onslaught of salivating hackers would become so tremendous that the site would likely be crippled under the weight of user grievances and brute-force traffic. I'm sure mandatory MFA would be put in place to increase security, but it wouldn't change the fact that reddit would become a major target for hackers, and many people would lose their money, despite MFA.

Next, I think the incentives for shit and spam posts would rocket off the chart as scammers, beggars and cam-models would likely flood the site with crap so that they can extract tips from anyone willing to toss penny shavings in their direction. Karma is already a sufficient reward mechanism, adding money into the fray is totally unnecessary and would almost certainly lower the quality of discussion.

Finally, this may be a stretch, but I fear that integrating crypto-money into the site would open the door for pay-to-subscribe/pay-to-view/pay-to- comment/pay-to-vote subreddit mechanisms. I understand that reddit is a business, but I think that this would be objectively bad, and even worse if subreddit mods were able to get a cut of it.

In the end, I don't think reddit needs crypto, it doesn't make the site better in any conceivable way.

<comment><USER6> Quite a while ago i saw a thread "How to make Reddit worse". Besides adding avatars, signatures, etc, one of the most popular suggestion was to give karma a monetary value. I'm really glad it didn't happen.

<comment><USER7> Gold is kinda that. Reddit has started encouraging users to "gild" each other for outstanding posts, so it's essentially used like karma.

<comment><USER8> Gold is thankfully not exchangeable for any goods or services though - it's really just another tier of karma.

With just karma/gold alone there's already a lot of people who spend a ridiculous amount of time farming it. Imagine if Imaginary Internet Points were redeemable for actual things.

</comment></comment></comment></comment><comment><USER9> Reddit is a great site in what it does. And due to its nature, it has tremendous amount of niches, some of which are worth a lot of money if handled properly.

For instance, /r/watches is an active area for discussion of watches. The people who post there often share their new Rolex or their treasured Patek Phillipe. /r/watches is just one of many, many such niches on the site which have a lot of potential value.

My thinking has been that reddit could focus on developing the value in its many product oriented subforums.

Also, interestingly enough, reddit has already sort of created its own new cybercurrency - dogecoin. Though it may not be doing well, I think most of the value in dogecoin was how easy it was to use on reddit.

reddit does need to find a way to monetize. I think it could do so quite successfully due to the nature of it having many high value niches.

I say all this as a big fan of the site and have even been considering making a subreddit finder (so that someone who is a fan of the TV show Suits, for instance, can know that there is /r/suits to discuss the show, which they would have simply no way of knowing if they just landed on reddit's homepage with pictures of Very Round Eggs, to use a current example).

<comment><USER10> To your first point, I always wondered if there was a way to monetize the individual subs and allow moderators of these subs to somehow take a part of the cut. There are a million risks in this, and I assume the biggest fear would be that it would destroy a lot of the current culture and increase "MOD CONSPIRACY" fears; but it would still be interesting to test.

Regarding the subreddit finder, Pinterest has the perfect model for your first login where it asks you about your interests and subscribes you specifically to those types of things. Reddit should most certainly do the same thing as it did take me a while to get into the site, and the best day on Reddit was discovering that I could unsubscribe from the defaults I didn't care much for and find the communities I cared about.

<comment><USER11> My issue is most subreddit moderators are young guys who, for the first time in their life, have some small authority over a group of people and are total shitheads about it. They have no credentials other than having thought to make the subreddit before anyone, and have done nothing to deserve a cut of profits of anything. If I owned reddit, I wouldn't want these people to work for me.

<comment><USER12> This is essential-- mods already have way too much power, and are constantly found to be doing naughty things on a very reliable basis. Selling sidebar links, keeping funds from "charity drives", squashing certain domains, outright selling mod accounts to industry marketers (/r/android) and these are just the things we know about! Moderator powers need to be restricted with constant vigilance by the admins and community.

Adding the potential for monetary rewards will not move this problem in the correct direction.

</comment></comment></comment></comment><comment><USER13> Ryan X. Charles here. AMA.

<comment><USER14> Why isn't this being brought to Reddit's userbase? This seems like something where a lack of transparency will really hurt the company.

<comment><USER13> Why isn't what being brought to the reddit userbase? That they fired me? That reddit notes is now paused? They are probably waiting for the right time to make an announcement I guess. They probably didn't realize that by firing (or letting me go, whatever) that they would draw the interest of the media.

<comment><USER14> Sorry - it's really all of the above. To be more clear, I will break this into some sub-questions that are hopefully less obsequious.

The "reddit is giving 10% of its shares to its users" thing was very positively received. My understanding was that redditcoin was part of that effort. Is the 10% thing still going to happen in some way? If not, why not?

Regardless of the answer to the question above, hearing that redditcoin is being cancelled would likely lead members to conclude the new leadership doesn't want the community shares system that was so touted previously. Is that the case, if you know?

And then the final, more meta question is: Why would Reddit's staff, of all people, think they could do something involving Reddit quietly?

<comment><USER13> > The "reddit is giving 10% of its shares to its users" thing was very > positively received. My understanding was that redditcoin was part of that > effort. Is the 10% thing still going to happen in some way? If not, why not?

I think they intend to make the 10% thing happen eventually, although the project is currently paused. I estimate 1+ year before any aspect of the project resumes. However, I am not privy to the conversations the executives have had about it, so I don't really know.

> Regardless of the answer to the question above, hearing that redditcoin is > being cancelled would likely lead members to conclude the new leadership > doesn't want the community shares system that was so touted previously. Is > that the case, if you know?

I don't know.

> Why would Reddit's staff, of all people, think they could do something > involving Reddit quietly?

Ha. No idea.

<comment><USER14> Interesting. I appreciate your candidness!

</comment></comment></comment></comment></comment></comment><comment><USER15> How far did the implementation of the currency go, and will what remains of it be released as OSS, if it's worthwhile to do so?

<comment><USER13> If you know much about the bitcoin world, implementing a new "cryptocurrency" is not exactly a technical challenge. I never created one because I could have done so during any one-week or so period of time. The problems were entirely legal.

Also note that my primary goal, misunderstood by everyone but Yishan, was not just to make reddit notes work, but build reddit's cryptofinancial system. p2p payments on reddit had enormous potential, now substantially delayed.

</comment></comment><comment><USER16> Only 125 days since I posted this: [https://news.ycombinator.com/item?id=8390136](https://news.ycombinator.com/item?id=8390136). I thought it was a cool idea... but I also thought BTC was a worthy investment at $400.

</comment><comment><USER17> Reddit seems a bit without direction lately. Maybe they cannot make as much from their popularity as they expected.

<comment><USER18> Why do they need direction?

<comment><USER17> Because they are a for-profit company. Generally investing in stuff and then scraping it immediately before it could possibly work, is not a very good idea.

<comment><USER19> > _Generally investing in stuff and then scraping it immediately before it > could possibly work, is not a very good idea._

Seems to work for Google... and Microsoft.

<comment><USER17> It doesn't, they just can afford to bleed cash all over the place do that thanks to their monopoly money, which is virtually an endless resource.</comment></comment></comment></comment></comment>


4 US diplomats incl. the US Ambassador killed in the militia/mob raid in Libya - <AUTHOR> http://www.bbc.co.uk/news/world-africa-19570254

<comment><USER2> The following is probably the inflammatory movie trailer:

<http://www.youtube.com/watch?v=qmodVun16Q4>

It was uploaded over 3 mo ago under a user name identical to the name (Sam Bacile) of the man the BBC identified as the producer of the movie.

Huffington Post says the trailer has been dubbed into Egyptian Arabic, which of course means there are other copies of the video online, which explains why this particular YouTube video has a relatively small number of hits.

</comment><comment><USER3> When I see news like this it makes me think of a quote, "Nothing makes a man angrier than to be wrong and know it."</comment>


Gatwick Airport closed for 24 hours now as drones keep breaking perimeter - <AUTHOR> https://www.bbc.com/news/uk-england-sussex-46640033 <comment><AUTHOR> This makes it to the top 3 most interesting news of the year for me. Someone has been able to fly some kind of heavy duty drone over the runway for 24 hours now. They called in the army but not only they can't arrest him, they are unable to stop those incursions too.

He must be flying from several kilometers away and the airport is already expecting disruptions most of tomorrow, so I would argue they already tried a GPS/ISM jammer and it must have been ineffective. Is this guy using some kind of inertial navigation system?

So basically a skilled someone managed to destroy the holidays of hundreds of thousands of people.</comment>


Exceptions should be Exceptional (2016) - <AUTHOR> http://mattwarren.org/2016/12/20/Why-Exceptions-should-be-Exceptional/ <comment><USER2> When your main argument for not using exceptions for every kind of error handling is performance instead of architecture, then maybe it is a sign that exceptions should simply be constructed to be more performant instead of giving people advice that isn't and can't ever be consistent.

As the writer of a library (or just other utility functions), you simply cannot know whether something is an exceptional situation or not, because that is a property of the program and the environment, not the function. Being unable to parse a string to a number, or to create a socket, or to even allocate memory can all be exceptional or not exceptional depending on the context, and often you simply do not know the context this code will run in, or the code will actually run in multiple directly contradictory contexts.

<comment><USER3> As a library writer you can let the caller the responsibility to determine if something is worth throwing an exception for or not.

1\. return an error code

2\. if the caller consider the issue to require an exception, they will do it themselves

You can also have entrypoints to the library that will throw exceptions, and other versions that won't, and let the caller decide what they want to use.

Though of course that's more work.

Regarding the point of performances, that makes me think of [https://news.ycombinator.com/item?id=22483028](https://news.ycombinator.com/item?id=22483028), discussing "Low-cost Deterministic C++ Exceptions for Embedded Systems". It would definitely be very interesting to see what is now possible if exceptions are cheaper.

<comment><USER2> The problem with doing that as a library writer is that exceptions, used well, generally change the entire interface and to some extent programming model. It starts with simple things like returning values instead of an error code (and setting value by reference) and goes through having to make "factory" functions for classes (if you want to use error codes) and ends with all sorts of considerations like copy constructors in C++.

So in many cases, if you don't want to compromise on design and architecture, you essentially need to write the entire library twice, or at least the entire interface. Not really a great state.

>discussing "Low-cost Deterministic C++ Exceptions for Embedded Systems"

This exact reason is why I think that paper is great and also how exceptions should have been implemented in C++ in the first place.

</comment></comment></comment><comment><USER4> An exceptional condition is arguably anything that means some call in your program can't do its job.

Passing error conditions up the call stack to the control layer that displays and/or logs a relevant message is a pain.

Exceptions make it less painful.

 _Catch_ blocks should be used sparingly, sure. If you're using them close to where the error is thrown then maybe you should consider an error code- oriented approach. But catch blocks in controller code (or better yet, meta- controller code)? Sure.

<comment><USER5> The problem is that one person might think an exception is acceptable for OpenFile, whereas another thinks it's not. It's this ambiguity that makes for all sorts of conflicting ideas and recommendations.

Fun Fact: the Windows API uses HRESULT to return success/failure of a particular call. The COM API uses the same. VB6 was the first platform by Microsoft to implement exceptions throughout the code (that I'm aware of)... and beneath it, it used COM. So that means that VB6 generated an exception whenever a COM status code returned E_FAIL or similar, and didn't if it was classed as SUCCESS (eg S_OK, S_FALSE, etc).

The original .NET implementors clearly used the VB6 model when developing the codebase (it was nearly a one-to-one match from VB6 to VB.NET) and very easy to port over.

That said, when I read the article, "Exceptions are the primary means of reporting errors in Frameworks" vs "Do not use exceptions for the normal flow of control, if possible" I see this never ending problem appear. Most things we do in our programs use Frameworks, which throw exceptions, which may or may not actually be _exceptional_ for the case of the calling function. Nevertheless, it must be handled.

However, back in the C++ Win API and COM world, you could easily use: `HRESULT hr= SomeFunc(); if (FAILED(hr)) return hr;` to bubble up a failure code, or if you handled it in other ways, you can safely ignore the return code and continue on. In the .NET world exceptions must always be handled otherwise they ripple all the way up and end up as a crashed application. Of course, some think this is a good design principle to have it so: Others are not so convinced.

And so, the debate continues.

<comment><USER6> Exactly. I am certainly in the "exceptions should be _really_ exceptional" camp and therefore I didn't "agree" with Python's open function:

[https://docs.python.org/3/library/functions.html#open](https://docs.python.org/3/library/functions.html#open)

"Open file and return a corresponding file object. If the file cannot be opened, an OSError is raised."

in the sense that in a program that is not only a few lines, I would prefer such kinds of library functions not to produce exceptions, thank you very much, so I had to wrap all such. But it is not optimal not being able to directly use language primitives as much as possible.

On another side, writing really short programs gets to be faster: if I write only a few lines, having an "implicit" error handling shortens the code.

And that's what I think is the main reason for many ills and misunderstanding in many popular languages: the practices that look good for small examples (or in the books) aren't the same as those which work well for large projects. Python's not detecting the typos in the variable names in compile time is also a typical bias towards the short programs.

For large projects detecting as much at compile time and having only very exceptional exceptions and unsurprising control flow (visible reading ifs, and with a guarantee that there can't be "landings from anywhere" like in exceptions) is of huge advantage.

<comment><USER7> Exceptions when opening a file has been chosen because they have the nice propery of encouraging a race condition free EAFP rather than a hard to get right LBYL.

It also fits nicely into the context manager pattern.

Besides, remember exceptions are cheap in python. So cheap that for loops are basically syntaxic sugar for a try/catch.

<comment><USER8> LBYL can easily be enforced by Maybe types, leaving exceptions for really exceptional things (which a nonexisting file definitely isn't). So we see how not having a real type system hurts and deforms a language in ways unrelated to types.

<comment><USER9> That's still EAFP (you didn't check the precondition before trying), just through a different mechanism.

</comment></comment></comment></comment></comment></comment><comment><USER10> "Exceptional" has no reasonable objective definition, especially not at the library level. When you try to open a file by name and it doesn't exist, is that exceptional? It depends on context. Whether something is "predictable and intentional" can even change with product evolution. It's a recipe for bikeshedding. This is a crazy criterion to try to make coding decisions by.

Different applications need different trade-offs, and not every API will be suitable for all users. Standard libraries will make decisions according to what kind of applications the language targets. Libraries making other trade- offs can be written to cater to people with other needs.

I get that some people are repeatedly encountering situations where they feel like exceptions are used in ways that reduce readability and performance, and they feel like this is a rule that could improve the situation by reducing the use of exceptions across the board, but please, apply your usual criteria of clarity, readability, and performance! If you believe that exceptions are the clearest way of expressing a certain bit of logic in your language and codebase, and that they are acceptably performant, don't get distracted from that by bottomless, ultimately insubstantial arguments about what it means to be "exceptional."

Edit: Just wanted to add that I really enjoy the more expressive type systems that make it ergonomic to use return values in a lot of situations where exceptions are otherwise the most readable choice.

</comment><comment><USER3> Maybe the issue is that "exception" is a really confusing name. Go has the keyword "panic" for errors that stop the current flow and unfold the stack, that makes it clear that you shouldn't use them for anything else than exceptional situations, and they can be "recovered" if they have to be handled explicitely.

[https://blog.golang.org/defer-panic-and- recover](https://blog.golang.org/defer-panic-and-recover)

<comment><USER11> From my (admittedly limited) experience, Go has the worst story for error handling, where functions end up repeatedly checking for error return conditions from called functions.

It feels trapped between "We don't want exceptions" without going full "Result<T> or Maybe<T>" functional style that might be more typical of something like elixir.

But I didn't try Go for long and that itself was years ago, so perhaps modern Go has better paradigms.

<comment><USER3> I'm just mentioning the naming, not the general approach to error handling. Panic are roughly similar to what an "exceptional exception" is (stop control flow, unfold stack until being handled), but the naming is slightly better IMHO.

I personally like Go's approach, but that's not for everybody (I'm also quite fond of the monadic approach though).

</comment></comment></comment><comment><USER12> Relatedly, I'm a strong proponent of debugging with "break on all exceptions" enabled. It's very easy to miss bugs if you're not aware of exceptions being thrown but for this to be practical the code must only throw exceptions exceptionally or it's a nightmare to debug.

</comment><comment><USER13> Fact 1: There are always bugs or unforeseen events in software.

Fact 2: When there is an unforeseen event, the developer did not consider what to do.

Fact 3: Developers often deal with other people's buggy code.

It's clear that exceptions aren't the perfect solution to anything, but given these 3 facts, exceptions are around to stay.

</comment><comment><USER14> I wonder why callbacks aren't a more popular way for languages to handle exceptions. What if each type of exception registered a weak link to a function with a name like `IOExceptionHandler` which prints a noisy error if it isn't overridden with other behavior?

I guess it would be harder to use a single exception callback if you had a lot of similar "try/catch" blocks in different areas of your code, and you'd still probably need to collect some sort of stack trace, but it might work out alright if you go with this article's advice and recommend that people keep exceptions out of their program's normal control flow.

I dunno, maybe it's a dumb idea and I've just been spending too much time with microcontrollers lately. They use interrupt callbacks for all kinds of hardware triggers and software events, and I kind of like how you can compartmentalize error handling into a few predictable event handlers.

That Java stack trace image at the end of the article also brings back some memories...but I'm feeling much better these days.

<comment><USER15> That is sounds more appropriate for either terminating the program or resumable exceptions like division by zero. In languages with a try-catch construct (specially C++), the complexity of implementing exceptions has to do with stack unwinding. This is where you don't want to restart in an outer context, but want to guarantee cleanup for the call frames you are abandoning.

<comment><USER14> Hm. Good point, I guess you couldn't easily clean up things like local memory allocations from a common exception handler, huh?

Oh well, they can't all be winners.

</comment></comment></comment><comment><USER16> For Ruby there's this book, by the exceptional Avdi Grimm [https://pragprog.com/book/ager/exceptional- ruby](https://pragprog.com/book/ager/exceptional-ruby) it's a fantastic resource on the subject.

</comment><comment><USER17> > So exceptions should be exceptional, unusual or rare, much like a asteroid > strike!!

That's a super huge misread of the text recommendation.

I watched a live presentation directly from Jeffrey Richter at the bay area .net user group, oh god about 15 years ago when he described how he came up with this text. In fact it was a call to use exceptions a lot more than we used to, and to avoid error codes. So no, exceptions are not supposed to be rare like that.

His main point was to throw if the method name was not achievable, except in specific situations where that breaks user expectations too much, like getting null from missing map entries.

</comment><comment><USER18> Anecdotally one of my stumbling blocks with clojure was how to deal with errors. The language style heavily pushes to just coding the happy path and using nil punning, instead of exceptions, but sometimes you need to signal errors, so some libraries use keywords for error codes - but now that we have spec the community seems to be shifting opinion to "exceptions are ok-ish if a result of not conforming". Both error codes and nils make spec definitions ugly, thus all the "maybe not" opinion by Rick... it seems someehat overwhelming, to be honest.

</comment><comment><USER19> Don't .NET dictionaries throw when a requested key isn't found?

<comment><USER20> Yes and probably make the most sense as .Net has no "undefined" value. If the dictionary has a the key with a null value it returns null, but no key throws.

With generic dictionaries (which everyone uses now days) you have TryGetValue which is a little weird since it uses a out parameter but pretty natural after c# 7 inline out params.

<comment><USER11> I often think it's a shame there isn't a "GetOrDefault" for dictionaries.

An extension like

> dict<k,v>.GetOrDefault(k key,v valueIfNotPresent)

Would be really helpful. It's easy enough to write your own extension to do this, but something built in would be the kind of nice to have method that has been creeping into .net.

<comment><USER20> Yes I agree, ImmutableDictionary has GetValueOrDefault, GetOrAdd is nice on ConcurrentDictionary and FirstOrDefault is nice in Linq.

</comment></comment></comment></comment><comment><USER21> Can't we all just agree that Maybe/Optional types are actually a great idea that generalizes all of this at minimal cost?

<comment><USER22> No. In the same way that my directions to the mall don't include "maybe take this turn" at all turns.

That is, in many (all?) imperative lists of steps for how to accomplish something, I often _do not_ want to acknowledge that every step could fail. Rather, I would like for a failure to be something I can touch and reason with. Possibly restart from.

Why did I not take that turn? Because I need gas. Or the kids need to use the bathroom. Doesn't matter, too much. I'm the user. Give me my options at this point. (And as a real user of maps, also give me the option of "piss off for 10 minutes.")

(Yes, I like the condition/restart system of common lisp...)

<comment><USER23> _> No. In the same way that my directions to the mall don't include "maybe take this turn" at all turns._

I think that's a really poor and simplistic comparison. You're content not considering every possible outcome of trying to go shopping because in the face of changes to your circumstances, you can easily come up with a new strategy and adjust your goals on the fly.

 _> I often _do not want* to acknowledge that every step could fail.*

That's what you want, but I have often found that the demands of quality software are different. I've seen too much software end up in strange and unconsidered failure modes because it threw up at the wrong time.

<comment><USER22> I should say that my want there is local to the directions. For the trip, I definitely want them handled.

So, for the function, I want to be able to say the happy path. I would also like to be able to say what could go wrong, with advice to the user on how to proceed.

</comment></comment></comment></comment><comment><USER24> I've taken Go's approach to error handling in new typescript projects. I want to force my team into thinking about IO errors. I want failures to be part of the domain since stack traces only kinda work in Node. We will only throw exceptions if someone didn't program for bulls properly. Everything else is a Failure instance passed up the call chain. Annoying, but our testing and code- thoughtfulness have gone up.

<comment><USER25> Go handles it shitty, like the past five decades of computer science and PL design never happened. For imperative languages, exceptions are perfectly fine as a way to encode failure as part of the domain of operations. If you're in functional fantasy land, the correct approach is to use a Maybe monad or, better yet, an Either monad. But Go supports neither of these and that's one of many reasons why it sucks for modern development. In TypeScript you can do better and, for the sake of others who have to maintain your code, you _should_ do better.

<comment><USER26> > Go handles it shitty, like the past five decades of computer science and PL > design never happened.

This has generally been my complaint with Go. Go is... fine. It offers a lot of features that seem revolutionary if you've never seen them before, but mostly feel like someone took the best parts of every language, and then implemented the least interesting aspects of those features.

\- Interfaces are like typeclasses, but without actually offering any sort of higher-kinded polymorphism.

\- Goroutines are kind of like Erlang processes, but without any notion of supervision and with shared mutable state.

\- The error handling feels like it's trying to emulate an Either monad, but in a way that doesn't actually allow for the compositional properties that make an Either monad useful.

I know that Go's goal was never to innovate on language design, but I feel like it ignored a lot of low-hanging fruit in modern language design.

Obviously you can do worse than coding in Go, but for everything Go is good at, there's likely an even better tool for the job. I'm not convinced that there's any domain where Go is the best choice available, but it's definitely average at most jobs, and maybe that's where it finds its niche.

Edited: I had missed the word "higher-kinded" in front of polymorphism. Thanks donatj!

<comment><USER27> > Interfaces are like typeclasses, but without actually offering any sort of > polymorphism

Can you explain what you mean by this? I certainly use them in a manner I would consider polymorphic.

<comment><USER26> You're completely right; I accidentally dropped the word "higher-kinded" in front of polymorphism.

Go's interfaces provide structural typing, which offers polymorphism over values. Typeclasses in comparison, offer polymorphism over types themselves. The distinction is subtle, but it drastically limits the sorts of abstractions that you can write with Go. In Go's defence, this is a limitation that even functional languages like F# and Elm face too. This sort of polymorphism is what makes ideas like monads and functors so powerful in a language like Haskell, and what causes those same ideas to lose some of their lustre in a less expressive language.

Unfortunately it's really difficult to find good articles on higher-kinded types, since anything written about them already assumes a ton of knowledge about the subject. This StackOverflow thread has some good insight though: [https://stackoverflow.com/questions/21170493/when-are- higher...](https://stackoverflow.com/questions/21170493/when-are-higher- kinded-types-useful)

It's entirely likely that in the real world these sorts of limitations don't actually matter, but my general frustration with Go stems from the fact that it's so close to being so much better than it is, and it saddens me that we as an industry chose to be so excited by something that's a tiny step forward, when there exist so many other options that are entire leaps and bounds forward.

<comment><USER28> Yeah, HKT is a godsend. It surprises me that Scala, one of the few languages that actually supports it, doesn't really use monads and all that good stuff in the base language. Like the fact that Scala uses duck-typing for the 'for' construct (it just looks for map, flatMap, filter) has always seemed odd.</comment></comment></comment></comment></comment></comment>


An Introduction to Tensors for Students of Physics and Engineering (2002) [pdf] - <AUTHOR> http://www.grc.nasa.gov/WWW/k-12/Numbers/Math/documents/Tensors_TM2002211716.pdf <comment><USER2> There is also a similarly titled, much longer (92 pages vs. 29 pages) introduction to tensors by the same author, also hosted by NASA, and released ~3 years later: _Foundations of Tensor Analysis for Students of Physics and Engineering With an Introduction to the Theory of Relativity_

[http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/2005017...](http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20050175884.pdf)

The pdf.js in my Iceweasel 31.2 seems to be choking on the pdf document, though it looks fine in other readers.

<comment><USER3> Unreadable in pdf.js in my FF 33.1.1, too.

Interestingly, in this longer document the author gives (more or less) an actual definition of "dyad" which isn't the same as "tensor product of two vectors", and with that definition the statement that "every tensor is a dyad" is (more or less) correct.

I need to qualify everything here with "more or less" because the author is trying to do mathematics but fairly clearly isn't actually a mathematician, and so a lot of what he says doesn't really quite make sense, but one can see what he's trying to say. (E.g., he says "a dyad is any quantity that operates on a vector through the inner product to produce a new vector with a different magnitude and direction from the original". Except that actually I'm sure he wants ii+jj+kk to count as a dyad even though it doesn't change either magnitude or direction, and except that he hasn't actually said explicitly what the "inner product" is except for the special case where the dyad is a tensor product of two vectors, and in order to say what the inner product is for a vector and a dyad one already has to know (at least kinda) what a dyad is...)

On the other hand, if you ask a pure mathematician to explain this stuff you'll generally get something nice and elegant but incomprehensible to most physicists and engineers, and much less suitable for symbolic calculations than the physicists' coordinate-based approach. (A tensor field is a section of a product of the tensor product of some tensor power of the tangent bundle of your underlying manifold, and some tensor power of the cotangent bundle. What do you mean you don't know what a section of a tensor power of the cotangent bundle of a smooth Riemannian manifold means? _Bozhe moi_!)

</comment></comment><comment><USER3> This document tells an important lie: it says (e.g., at the top of page 8) that every rank-2 tensor is an outer product of two vectors. This is flatly untrue and is an easy misconception for a student to acquire even if the thing they're learning from doesn't explicitly say it.

I skimmed through looking to see if at some point the author says "oh, by the way, I told you a lie earlier", but it doesn't look like he does.

(If anyone reading this has difficulty believing that there are more rank-2 tensors than outer products ("dyads") of two vectors, note that in 3 dimensions you can specify two vectors by giving 6 numbers, but it takes 9 to specify a rank-2 tensor because it can be represented by an arbitrary 3x3 matrix.)

<comment><USER4> > If anyone reading this has difficulty believing that there are more rank-2 > tensors than outer products

Small nitpick: Unless you have tensors over a finite universe, there aren't really "more" of the large ones that the small ones..

So we have to argue in some other way. Anybody's got a counter example? (matrix that is probably not a dyad?)

<comment><USER3> Yeah, there really are more, provided you define "more" right. They form a topological space, and the rank-2 tensors are a 9-dimensional space versus a 6-dimensional space for the outer products.

Alternatively, any matrix whose determinant isn't zero is a non-dyad.

<comment><USER5> But the cardinality of the set of all points in a 9-dimensional space is not larger than the cardinality of the set of points in a 6-dimensional space, or even between 0 and 1 in the 1-dimensional real line.

And the set theoretic cardinality is the normal way to define what "more" means, or to compare sets of an infinite amount of objects.

How would you define "more", to get e.g. R² have "more" points than R?

<comment><USER3> There are lots of ways to define "more" (or "bigger" or whatever term one chooses to use). Which one is most appropriate depends on what kind of things you're working with.

Working with vector spaces over a given field: "bigger" means "higher dimension". Working with manifolds: "bigger" means "higher dimension". Working with sets: "bigger" usually means "larger cardinality" but could sometimes mean "proper superset".

In general, you can take "X is bigger than Y" to mean "Y is isomorphic to some substructure of X, but not vice versa". If "isomorphic" means "in bijection with" and "substructure" means "subset" then this is cardinality. If they mean "isomorphic as vector spaces over F" and "vector subspace" then it's dimension. If they mean "homeomorphic" and "topological subspace" then actually it isn't true that lower-dimensional manifolds are always "smaller than" higher-dimensional ones (so maybe we actually want a different definition) but in this particular case the rank-1 tensors are a lower- dimensional proper subspace of all the tensors so the definition gives the "right" answer.

</comment></comment></comment></comment></comment><comment><USER6> Excellent, thanks for sharing! I found particularly useful the explanation that dF = SdA implies that the tensor S must convert the area vector dA in a force vector dF and that vector can have any direction.

But something that I miss is a visual representation of what kind of change of directions tensors do. I can see in my mind how a vector multiplication works, but I haven't the same intuition for tensors. For example, if I have a cube of marble and I put a heavy weight over it, qualitatively how the tensorial space in the cube? What kind of values I would see near the top? Which ones near the bottom? What's the direction of dF if I chose a dA parallel to each side of the cube? which one if I chose an arbitray vector, say one at 45° of one side?

</comment><comment><USER7> Last night I came across this tutorial on Tensor diagrams:

[http://research.microsoft.com/pubs/79791/usingtensordiagrams...](http://research.microsoft.com/pubs/79791/usingtensordiagrams.pdf)

I love the way Jim Blinn writes.

</comment><comment><USER8> Clear discussion of the basic concepts. Coincidentally, I was reading this two days back and before this link was posted.

<comment><USER9> Me too, i was reading it a few days back. Trying to understand the math behind relativity.

I was inspired by 'Interstellar'.

</comment></comment><comment><USER10> > inner product of a matrix and a vector

how does that work?

<comment><USER11> The inner product in the context of tensors is a rank-contraction operation[0]. The IP you know and love contracts over the covariant and contravariant indicies of two rank-1 tensors (vectors). You need a metric to do this so you can raise one of the contravariant indicies to be covariant. If your metric is the normal one (all 1's) then you just add the product of all coefficients. Though if you have the Minkowski metric (like in special relativty) then you negate the time coordinate (or all the space coordinates) and add. Here the matrix might be regarded as a rank 1,1 tensor (one covariant, one contravariant index) that you contract with the vector.

[0] [http://en.wikipedia.org/wiki/Tensor_contraction](http://en.wikipedia.org/wiki/Tensor_contraction)</comment></comment>


Pricing is hard.  We need your help. - <AUTHOR> http://blog.keen.io/post/32269955563/pricing-is-hard-we-need-your-help

<comment><USER2> Because your customers are going to be more technical I would do the utility pricing. Pay per unit of usage.

If you need help with pricing, email me. Our company does algorithmic pricing via a REST API, I'll give Keen access for free.

To address your listed cons to utility style pricing:

1) Products aren't turned into a commodity because of how they are priced. They are commoditized when many perfect substitutions exist in the market.

2) I'm not sure if "not predictable" will go over well with your audience. Maybe you could use your own product to help people predict their bill with you. It would be a neat application of your software.

<comment><USER3> You _vastly_ underestimate the value of predictability in billing to a business's "Chief Fretting Officer".

If you asked companies if they'd rather pay a random amount between 100$ and 500$, or always pay 500$, 9 out of 10 would opt for the latter. And if you don't understand why, then you've never spent any amount of time pondering a business's cash flow.

<comment><USER4> "pay a random amount between 100$ and 500$, or always pay 500$, 9 out of 10 would opt for the latter"

Why so ? You are perhaps referring to a business's ability to project/forecast cashflows which is critical but even then, if the number is always going to be less than or equal to 500, I would rather choose the first option.

<comment><USER5> At my old day job, my boss _literally_ instructed me to pay $200 rather than rand(10..40) because otherwise he would have been committing to a minute of work every month updating an ERP entry. Plus, not _his_ money, but certainly his minute...

<comment><USER6> New pricing strategy: the low-end tier is metered.

That's also a big argument in favor of formulating seat-based pricing models as blocks as opposed to per seat. It reduces the update frequency.

<comment><USER7> Metered low-end looks similar to what AWS does, doesn't it ? Spot prices are metered, but if you want to get a flat fee per month, no worries, you can get the reserved instances. Which also have a better bang per buck.

<comment><USER8> reserved instances aren't totally flat fee. Reserved instances allow you to pay a fixed cost up front for a reduction for the rest of the month.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> It would be nice to have an explanation of what Keen.io does in the article. Actually, even after browsing your site I still don't have any idea what you guys do, besides collect data and visualize it. There also doesn't seem to be any indication of -how- you guys do visualization. It's hard for me to think about pricing for your service when I have no idea what you offer.

<comment><AUTHOR> Good point. We're not released yet, and there are probably < 100 people who have a good enough idea of what we're doing to really dig in and give us feedback

We'll edit the blog post to add a bit more background

update:

here's the working copy:

\--

We make three kinds of APIs:

      -data collection APIs
      -data analysis APIs
      -data visualization APIs

For instance, if you had a social-local-mobile shopping app for the iPhone, you'd probably want to insert a rich event into Keen every time a user does one of the following actions: opens the app, does Facebook connect, likes/comments/shares an item, adds an item to their shopping cart, and completes a checkout. You send us this data using the _collection APIs_ ([https://keen.io/static/docs/data_collection/data_collection....](https://keen.io/static/docs/data_collection/data_collection.html))

Once your app is sending us stuff, your product manager may ask you to make her a little analytics dashboard, so she can agonize over it every morning. For instance, this dashboard could have answers to questions like "How many people opened the app each day over the course of the last week?" That question (and many way more advanced ones) can be answered using one of our _analysis APIs_ (in this case, the Series API <https://keen.io/static/docs/data_analysis/series.html>)

Finally, suppose a few weeks later she's tired of staring at numbers and wants to see this information graphed visually in a line graph. That can be done using our visualization APIs (not yet released).

<comment><USER10> I think the what here might be less important than why for pricing. It's easy to get a sense of your platform from your website, but who is your target customer and why are they paying you? Does this save them time? Money? Make them money? Got any scenarios or customer sketches?

<comment><USER11> (Disclosure: I wrote the post)

These are all great questions. Thinking long-term, the answer should be yes to all of those questions. We should save time (and therefore money) and be a vehicle for increased revenue. And, we intend to do a lot more writing about how folks are using/could use/should use our product. At the same time, in the long run, we're all dead. So, in the present, we're looking to work with Series-A type companies who are in the midst of early product development. We want to work alongside them to understand their analytics needs and tweak our roadmap accordingly.

Those customer sketches/white papers are extremely important to us. We're still learning (and probably always will be). It's my hope that we will be in a position to blog about customer experiences soon. Dominos are certainly lining up for that.

<comment><USER12> _who is your target customer and why are they paying you? Does this save them time? Money? Make them money? Got any scenarios or customer sketches?_

In addition to these questions, I'd also think about how to reach a point where customer feels a high switching costs. It seems that a service like yours can be offered by many, but the important competitive advantage is that the more customers have stored data on your service, the more 'expensive' for them to switch.

What part of your service increases in value the longer someone uses it? Is it the historical data of the customer's own app, or is it the cross-sectional data of apps in other categories? As mentioned above, mixpanel is a good example, so is new relic.

</comment></comment></comment></comment></comment><comment><USER13> Whether you price by usage or have tiers, always do value pricing, not cost- plus pricing.

<comment><USER14> Agree; it's most in line with what the customer wants, facilitates segmentation in a way that's fair to both parties involved, and allows upselling when material changes in product or service take place.

Even if you use utility pricing, it's still best to frame it in terms of something meaningful to your customers.

</comment></comment><comment><USER15> I've helped a number of companies put together pricing plans, and the first thing I usually say is "talk to your customers", so it's great that you are already doing that. However, the real question is not "how should I price this?" but "why is this awesome to you? (what is the value?)" You should absolutely price based on value-- if your value is greater than your cost, you can win. If not, you need to fix something. If you don't know what that value is, spend your time there, and the pricing will flow from that. As mentioned by others, you can always grandfather existing customers if you decide to change.

(That said, I'm guessing that simple tiers + custom enterprise plans if needed will be the way to go. The trick is figuring out how to set them up.)

</comment><comment><USER16> I think the description of what you do is just too vague to give any feedback on how to price it. "collect, analyze, and visualize" data could mean almost anything. I even browsed through the docs and couldn't figure it out.

Do you have a full blown example use case of how a customer would use keen.io?

The getting started page shows an example of inserting an "event" and counting it, but I'm not sure what that means, or what the end goal is, exactly.

<comment><AUTHOR> We updated our description to make more sense and include an example

What do you think of it?

</comment></comment><comment><USER17> Our pricing at Repustate.com is fixed fee for a fixed quota of API calls. Usage-based billing sucks because of the unpredictability on both sides, plus it makes invoices much easier for us. Like others have mentioned here, predictable costs are good.

</comment><comment><USER18> Keen looks to be another Mixpanel. I looked at mixpanel's pricing, and it sis nicely structured into tiers so one can estimate quickly how much it will cost based on the size of the business.

Mixpanel's pricing is utility based under the hood (they automatically pro- rate or upgrade the plan based on what is cheaper), but the marketing copy is tier based. That looks to be a good approach.</comment>