From Ruby to Crystal: A Quick Look - <AUTHOR> https://spin.atomicobject.com/2017/03/24/ruby-to-crystal-test/ <comment><USER2> Crystal could be a really powerful tool for enhancing existing Ruby code.

Imagine a world where you write your code in Ruby, but farm out the expensive operations to a Ruby-like Crystal extension (similar to what is commonly done with C or Rust). I think this is possible already (just after a quick Google search[1]), just not friendly for the average Ruby dev to implement.

[1] [https://www.slideshare.net/AnnaKazakova/how-to-write-ruby- ex...](https://www.slideshare.net/AnnaKazakova/how-to-write-ruby-extensions- with-crystal)

<comment><USER3> This is definitely possible-- I've done even more than basic PoC (Anna's slide deck was one of my starting points in fact).

[https://github.com/phoffer/crystalized_ruby](https://github.com/phoffer/crystalized_ruby)

<comment><USER2> This is great, thanks. It seems that it is incomplete, though. What can the community do to support further development?

</comment></comment></comment><comment><USER4> Outside of speed benefits as compared to ruby, one of the main things going for crystal is it's ability to use all of the robust tooling that already exists. This post mentions it in passing but Crystal gets the benefit of all the existing tooling without having to build it as part of delivering the language to developers. I think that's a huge win. I also think this is one reason why Crystal has grown fairly quickly. This could largely but due to the fact that it's built upon LLVM. Regardless, the community and documentation is pretty awesome. I can't wait to see what happens for the 1.0 release.

<comment><USER5> Can you be more specific on what you mean about "existing tooling"?. I work in a Ruby shop and am very curious to try Crystal.

</comment></comment><comment><USER6> Great writeup for the folks who are curious but lack the time to test Crystal.

</comment><comment><USER7> My biggest takeaway from reading this is that Crystal is _much_ more divergent from Ruby than I expected.

<comment><USER8> I'm confused by why there's so many small things that appears to be pointless differences. E.g. "property" vs "atter_accessor". It'd seem that ease of converting Ruby code is the major selling point, and especially with things like TruffleRuby + Substrate, it seems like it's about to face more serious competition that _doesn 't_ depend on rewriting your code nearly as much.

<comment><USER9> The idea behind crystal is not to make a faster ruby, but to make a rethought ruby for the modern age: compiled, statically typed and removed of warts.

Crystal should feel familiar to ruby developers in it's syntax and stdlib, but we have absolutely no problems with throwing away ruby's ideas when they are deemed substandard.

Crystal doesn't aim to draw in as many ruby developers as possible, it aims to create the best programming language possible. It just happens to have ruby as a conceptual starting point.

<comment><USER10> It seems like Ruby is a bit of a small community to target with this type of thing. Wouldn't Ruby developers be better served by moving on to one of the several other idealistic languages in widespread usage right now? TypeScript is getting good reviews and Python is great.

I know it seems harsh, but when I hear people talk about the "beauty" or "elegance" of Ruby, I just think of someone who started coding in the 2005-2009 era and started out with RoR, which was frequently presented as "the Mac of programming languages" around that time (and this description alone should give serious people pause).

These people got into the scene too late to remember trying to hack Perl, Ruby's own spiritual predecessor, and the pseudo-joke that it was a "write- only language". The two relics that remain from widespread Perl usage are regular expressions and Ruby.

Meanwhile, several other languages that are similar to Ruby in age and/or style have active communities and enjoy an increasing trend of innovation and market penetration. Even languages like Groovy, which have failed to gain a large independent following, continue to benefit from both technical and communal innovation on their underlying runtime platforms.

I don't think I've met many people who looked at Ruby in a time when the hype train wasn't going full steam ahead and came away with the evaluation that it was "elegant" or "beautiful". In fact, many reformed "Rubyists" whom I know are switching to other platforms, and RoR jobs are getting increasingly scarce (supplanted by the next large-scale server-side fad, node.js). Not many people seem to be using Ruby for new projects anymore.

Could you elaborate on why you chose Ruby as a reference point?

<comment><USER8> > I know it seems harsh, but when I hear people talk about the "beauty" or > "elegance" of Ruby, I just think of someone who started coding in the > 2005-2009 era and started out with RoR

I started programming in 1981, I detest Rails, and I picked Ruby for its beauty and elegance. I'm a language geek first and foremost; the syntax and presentation of a language is extremely important for my happiness when working with it, and nothing has so far gotten close to Ruby in that respect, and I've worked in more languages than most developers can name.

TypeScript and Python both looks awful to me. Neither are languages I'll work in given a choice. I don't think you'll find many Rubyists who'd consider them viable alternatives - those who have evaluated both and come down on the Ruby side tends to have strong opinions on the matter in my experience.

> In fact, many reformed "Rubyists" whom I know are switching to other > platforms, and RoR jobs are getting increasingly scarce (supplanted by the > next large-scale server-side fad, node.js). Not many people seem to be using > Ruby for new projects anymore.

My experience is the exact opposite. It's easier than ever for me to find work doing Ruby _even while avoiding Rails_. I'm too expensive to do Rails even I liked it. Yet I regularly find devops consulting gigs and the like where people are happy to find someone with Ruby skills.

If RoR jobs are indeed getting scarce, I suspect that's more an effect of the number of Ruby developers reaching the kind of saturation that PHP developers did years ago.

But these things are also highly dependent on _where you look_. I rarely come across people asking for node.js for example. Presumably because my network is tilted towards Rubyists.

<comment><USER10> Can you discuss some of the linguistic edges that you find in Ruby? Personally, I don't understand the attraction. It would help if you could articulate. I've always struggled to see the real merit that Ruby brought to the table.

Usually such explanations are things like "Look at all the esoteric symbols I can pack together to accomplish something on two lines, instead of the readable way that would've used six lines!" IMO, it's better to use a few extra bytes for line breaks, or for explicit wrapping of things like method arguments, and have your code more accessible.

Unless you're engaging in the above-referenced symbolic soup, Python and Ruby code usually end up looking pretty similar. I don't know how you can say that one "looks awful" v. the other.

<comment><USER8> > Can you discuss some of the linguistic edges that you find in Ruby?

Ruby is close to Smalltalk, but with an Algol-family syntax that goes to painstaking lengths to make visual clutter optional while being familiar.

There's nothing really new in Ruby in terms of semantics. What Ruby did was fuse a number of language concepts into something that _reads well_. _Syntax_ is the primary linguistic edge of Ruby.

We get the dynamism of Smalltak, in a more familiar packaging, that then goes to extremes to try to let you strip out ceremony.

This to me contributes to compact but _readable_ code. Outside of golfing, the Ruby community values readability very highly, and syntax is a big part of that.

A typical example is the block sytax, which seems trivial on the surface, given that it is just a very thin veneer over the lambda syntax. To give a (very) contrived example:

Ruby's "full length" lambda syntax:

        def foo l
          print "Hello "
          l.call
        end

        foo ->{puts "World"}

The block syntax:

        def bar
          print "Hello "
          yield
        end

        bar { puts "World" }

The first thing to note is that the full length syntax has become very compact too, and the difference on the surface looks rather pointless (though it used to be bigger), but reducing the visual clutter makes the block syntax acceptable in a lot of circumstances where lambdas would otherwise "look ugly". E.g. in Ruby there is "timeout", which is a method that takes a number of seconds, and a block, letting you write "timeout 5 { call_something }". You could do implement one with lambda's too, but you'd end up with "timeout 5,-> { call_something }" at the bare minimum, and in instances where () around the argument list becomes necessary, you end up with even more clutter, while the block syntax avoids it.

This probably seems very minor, and in a way it is, but in my experience when visual clutter disappears people think about code differently and use constructs more or less sparingly. E.g. you _can_ do most of the semi- functional stuff you do casually in Ruby in C++ too, but the extra ceremony and clutter quickly puts people off. Cutting down on the clutter matters.

Another example is the DSL functionality which in Ruby is often done by defining context classes with methods, or by injecting methods in the meta- class of the class you're defining.

In particularly defining methods on the meta-class to be executed _during_ the definition of a class. E.g. as a example from Sequel:

        class Movie < Sequel::Model
          plugin :validation_helpers

          ...
        end

"plugin" here is a method on the meta-class of Sequel::Model that pulls in the relevant methods of the specified plugin by running this code while defining the class. Being able to basically define a DSL to mutate the class while it is being defined leads to code where boilerplate very quickly ends up extracted into libraries in ways that tends to produce a lot of extra clutter in other languages.

> Unless you're engaging in the above-referenced symbolic soup, Python and > Ruby code usually end up looking pretty similar. I don't know how you can > say that one "looks awful" v. the other.

I agree it looks relatively similar, which is exactly why I believe most of those of us who have chosen Ruby tends to have very strong opinions about why Ruby works for us. For me the most immediate one is that I refuse to work with languages where significant indentation levels is a big thing. I both really want the visual indication, and really hate working with significant indentation (including things like YAML)

Part of the reason why I feel comfortable making that choice is exactly that the benefit of picking Python over Ruby to me is slim enough that I can afford to make that decision over issues that otherwise would be marginal, but that matters to me.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> 70x faster? If Crystal gets its own port of Ruby on Rails, oh boy.

<comment><USER8> 70x faster, with the caveat that the way that Ruby code is written really does not lend itself to speed.

E.g. using method calls inside the class instead of accessing instance variables instantly springs to mind, as does the "unsorted priority queue" which is basically a horrible abuse of Array but wrapped in a class that makes it even slower by adding additional method calls for every operation.

That's not to diminish the speedup Crystal gets, because it does illustrate how slow MRI's method calls are, but it'd be interesting in seeing a comparison with an astar implementation that was actually written to be fast in Ruby.

Also would be very interesting to see a comparison with jRuby+Truffle, of course.

<comment><USER12> Author of the article here. This implementation of A* was me playing around. It is definitely not optimized for either Ruby or Crystal It was merely a chunk of Ruby code that I had lying around. You are right about the unsorted queue being a hack around Array, but it was part of another experiment of using a "Fast Stack"[1] for the A* algorithm. It allowed me to swap in other Queue implementations easily.

The point of the article was merely "How much work does it take to port Ruby to Crystal" The performance differences were just fun to see, not the intent.

If I get time, maybe I'll run this through jRuby+Truffle as a comparison, that would be interesting to see.

[1] [https://github.com/SteveRabin/JPSPlusWithGoalBounding](https://github.com/SteveRabin/JPSPlusWithGoalBounding)

<comment><USER6> That would definitely be interesting if you run it on the same hardware.</comment></comment></comment></comment>


The Lithium Mine Buildup Is Outpacing the Electric-Car Boom - <AUTHOR> https://www.bloomberg.com/news/articles/2019-07-28/the-lithium-mine-buildup-is-outpacing-the-electric-car-boom <comment><USER2> The electric car industry hasn't _remotely_ boomed. Electric cars are still deeply strangled by two key factors: industry inertia and the cost/supply of lithium batteries. Once those two factors are solved (and a build-up of lithium mines is key to that) electric cars will go from being a niche within a niche to utterly dominating the market very, very quickly.

Within the next decade we might see companies like Hyundai/Kia, Toyota and Honda selling more EVs than ICE. Take the Kia Niro EV as an example: if the cost of batteries halved and the supply was unconstrained, there is little stopping that kind of product from dominating the market—starting with two-car households with off-street parking.

With their lithium cell investments, Telsa are well positioned to benefit from this boom, but they need to think carefully about their positioning. Right now they're a luxury brand with no serious competitors; when Telsa's drivetrain advantage is substantially neutralised, their mind share is likely to stagnate.

In my opinion Tesla needs to prepare to be in the budget space. They need to partner with an external manufacturer to sell a product with normal door handles that competes with Hyundai and Toyota. Because once the cost of batteries falls, I predict a substantial slice of their market will simply disappear to the economy manufacturers. I suspect that many people who love Telsa really just love the idea of electric vehicles and they'll be buying something more like the Kia Niro EV.

<comment><USER3> People HATE the maintenance requirements of cars. If Tesla can establish their cars as almost never needing service with a usable life of something closer to 1 million miles and decades of use then suddenly paying a premium for their models can be spread over much greater periods of time.

Personally, I wish they would decouple the platform from the comfort center. Have chassis form factors for various purposes (single person/roadster, crossover, truck, utility, etc) and branded "comfort centers" housing the human interface stuff. Make it so the comfort center can be changed out when ever and keeping the same underlying platform.

<comment><USER4> >If Tesla can establish their cars as almost never needing service...

I drive a 15 year old Volvo wagon that almost never needs service :)

Of course I exaggerate - I probably average $150/month in maintenance. Sorry, but the chances of Tesla doing the same over 15 years is zero.

<comment><USER5> Biggest long term maintenance expense in an EV is battery replacement, which best estimates right now put the industry at roughly a 15-30 year replacement rate. Depending on how you finance it, a battery replacement should be doable for <= $150/month average, and that's assuming a full replacement. (Depending on one's range needs/usage patterns some people might be able to make 20-50 years on the capacity degradation curve of a vehicle's original battery before needing a replacement, given current evidence.)

Electric motors have way fewer moving parts and fluids and currently are generally expected to outlast any car frame they are put in.

Most EVs advantage regenerative braking so break maintenance cycles are also longer to comparably sized ICE vehicles.

The other maintenance risks are the exact same between an EV and any other car, things like: HVAC, plastic degradation, rust, and accident damage.

The one unique Tesla risk on a 15-year horizon is their software updates. Their penchant for over-the-air software updates is handy in the short term, but possibly a risk in the long term lifespan of a vehicle. Though that's a risk Tesla would hopefully be incentivized to avoid (for bad PR at least), and possibly a mitigatable risk.

</comment></comment></comment></comment><comment><USER6> This seems like a bit of hype over very little.

Look at the graph in the article. Lithium cost $5000/ton 4 years ago. Now it costs more than $11,000/ton. The only difference is the period in between where the price of lithium was almost $21,000/ton.

Presumably the mines operation 4 years ago were profitable. Now there's all these additional mines, and demand still has the price doubled in 4 years. And yet somehow the story is that EVs aren't succeeding? I see just the opposite- EVs are succeeding so much that the industry supporting them is growing and profiting very nicely.

<comment><USER7> Note that this is the spot price of lithium, which no large consumer of lithium pays. All the big users of lithium (like Panasonic) buy it based on long term contracts with companies like Albemarle (which bought Rockwood Lithium just before the recent boom). Thus it's very misleading to look at spot prices for reaching any determinations about the prospective returns from lithium mine investments.

<comment><USER8> Fun fact, there is no spot market for lithium. Lithium is sold on a contract by contract basis and there isn't an equivalent of the London Metal Exchange price.

<comment><USER4> Any idea why that is?

<comment><USER9> Probably because most uses of lithium are heavily processed and it's not particularly useful or safe in it's raw form, so if you're going to use it you're more likely to need an oxide or something instead of the raw metal.

</comment></comment></comment></comment></comment><comment><USER10> This was so evident 2-3 years ago it's ridiculous.

I worked on a bunch of projects in 16/17 and what I told all my clients is get to production and lock down offtake agreements ASAP as the amount of projects coming online was huge for the short term (with regards to hard rock lithium) and even worse long term (salars etc).

Even the most optimistic of ev adoption rates showed oversupply by 2023.

Some other facts I remember just as points of interest:

* lithium market is opaque. No open market and all contract based so very difficult to price.

* one major unknown that will further add to supply is recycling, with some tech I remember showing cost effective recycling of up to 80% of lithium.

* major bottleneck in short to medium term are the converters ability to refine. Premium will be placed on higher % Li product to increase recovery rates.

So yeah no surprising at all. (Am a mining/mechanical engineer)

<comment><USER11> If you had to guess what will be the price of lithium once those big mines come online? 5000/ton Li2CO3 (at 99%) or even lower? And do you think there will ever be an open market with future contracts?

<comment><USER10> On the first question it's been a while so haven't really followed too closely, but once the salars come online depending on the agreements they have in place they really will have the ability to set the price to whatever they want (as they have been doing for past 3-4 decades). These hard rock mines are making serious money on the fact that the big 3/4 missed the boat (somehow) on the lithium/ev boom. I reckon they will be they will set production/prices to a point just below the number where hard rock equivalents are commercial.

With regard to opening the market I personally don't think so. If the market didn't have big players in it then yes it probably would have by now. That being said there were/are a lot of mid stage converters coming online that are disrupting the old guard and taking whatever is out there and not being secretive on pricing so maybe?

<comment><USER11> Thanks, that's interesting. And what do you think of this PFS? [https://www.share-talk.com/european-metals-hldg-aimemh- pfs-c...](https://www.share-talk.com/european-metals-hldg-aimemh-pfs-confirms- potential-low-cost-lithium-producer/)

People in .cz think this is a gold mine but investors don't seem to agree

<comment><USER10> I remember looking at that project back in the day and couldn't make the numbers work. Not sure if much has changed.

Firstly it's an underground mine which is inherently much higher risk/cost compared to open cut.

Second logistically it's a world away from customers (Asia etc)

Again if they had kicked it off back when, and were in production now they could have locked in some good terms from the starved customers and maybe set themselves up as a player, unfortunately I think they have missed the boat.

<comment><USER8> I'd that they don't have any measured resources on their list, it's half inferred and half indicated. So moderate uncertainty about everything down there.

</comment></comment></comment></comment></comment></comment><comment><USER12> It seems like people often forget how applicable EVs are to in city heavy commercial vehicles such as garbage truck, buses, service vehicles

The high torque nature and predicable nature (at least in the case of garbage trucks and buses) make them ideal candidates for EV. Arguably much more viable use case (at least initially) than household vehicles.

<comment><USER3> EVs are a clear winner for jobs like that. Has the prediction of EVs being low on maintenance bore out? If so, its further incentive for commercial and public use. Municipalities benefit greatly from predictable, constant expenses.

I know Leafs have had their service lives (at least for their batteries) revised up recently. Solid state is where it's at.

<comment><USER13> Although I agree, I was interested in the article about how poorly planned EV city owned equipment was a huge strain on the power grid that city planners didn't seem to understand how to do right. I look forward to what I expect to be the near future where cities start sharing best practices on this and collectively we do this right.

<comment><USER14> Depends on the location. In cities that have trams, metro and electric trains, the infrastructure shouldn't be that far out.

<comment><USER15> Taxis, city buses, UPS trucks, etc, all tend to be busy during the day. They get charged overnight, when grid demand is lower, and take advantage of low off-peak electricity prices.

The idea that these things place a "huge strain on the grid" as the poster above suggests just sounds like more made up FUD.

<comment><USER16> No, the poster above is right. There was an article about this a month ago or so. Anyways, the TLDR is that vehicles need to charge more often than just nightly and not just at the main depot. Transit agencies need to build heavy duty fast charging infrastructure scattered across many locations in the city. This has been so far a large upfront cost which holds transit EV expansion at bay.

<comment><USER15> If their vehicles need to charge more often than just overnight, then they need to consider whether they are buying the right vehicles for the job.

The examples I mentioned are from London, which has a growing fleet of hundreds of heavy electric vehicles (city buses, UPS trucks, etc). All of these charge exclusively overnight.

<comment><USER13> Why move a heavier battery pack around if you can have a charging station at both ends of your route? Certainly lower weight means lower cost battery packs and overall higher efficiency since you're not dragging around spare energy for most of your day.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> I think that a lot of people (including the authors) think that electric vehicles are only cars. You only need to walk around the streets of Beijing to notice that far more electric vehicles are scooters and busses. Not the Bird kind of scooters but the scooters that you see in very congested cities as well as the chaps who deliver your pizzas. They are completely silent, it's surreal. They also omitted obvious other uses of lithium batteries like electronic gadgets and solar farms.

</comment><comment><USER18> Something incredible just happened.

After a half century of jaw-boning about the need for renewable "green" energy, we now have a repeatable scalable tech template similar to the [oil well + refinery + piston engine] or [coal mine + pulverizer + furnace + turbine] tech templates that scaled fossil fuel energy. It is: [wind turbines and/or solar PV panels + lithium ion cells].

By repeatable and scalable tech template I mean something that no longer requires non-incremental forms of R&D. We no longer have to think that deeply about it. It's now in the realm of "see that stuff? Build more stuff like that."

The solar/wind+li-ion template can, _if scaled,_ power almost all current human industrial activity with the exception of long-haul heavy vehicles (land, sea, or air) and rockets. Those are important things but they're collectively less than a quarter of all fossil fuel use.

The key is "if scaled." We are going to need more lithium. Good news is that it's not really all that rare. Bad news is that until quite recently there hasn't been _serious_ investment in getting it. Look at what we invest in getting oil vs. lithium.

That's because until quite recently there hasn't been the demand to justify that investment. Now there is. Lithium prices have exploded, signaling the need for more. The price signals are working. Good.

It's normal during this kind of scaling to have periods where it looks like investment is outpacing demand and vice versa. Demand and supply don't scale at the same rate so you get price spikes in both directions. This doesn't change the underlying reality now in effect.

</comment><comment><USER19> There is already a backing up of IC car production in the luxury car markets as large numbers of people are delaying the purchase of new IC based cars in anticipation of a new EV supplanting it based on lower running costs, lower maintenance costs et al. In addition, these longevity factors are making EV buyers move up-market. This has gutted Mercedes and BMW sales, among others. [https://electrek.co/2019/07/24/tesla-model-3-outsellin- gas-p...](https://electrek.co/2019/07/24/tesla-model-3-outsellin-gas-powered- equivalents-combined/)

</comment><comment><USER20> Well, this topic went south really fast! I'm surprised the new Goodenough battery design hasn't come up!

Getting back to an actual discussion of _lithium_ , it'll be very interesting to see if the Goodenough solid electrolyte batter works well enough with sodium. If so, a lot of expensive lithium mines will be worth a lot less over time!

The Goodenough battery (he invented LiON batteries for those who don't know) looks to improve on LiON in most important areas:

      - higher energy density (~2x)
      - not flammable
      - faster charge rates
      - many more charge cycles (~100x more)
      - better performance in cold conditions
      - either lithium or *sodium* based glass electrolyte

Apparently 89 companies are evaluating the patents for production:

[https://www.texasmonthly.com/energy/all-charged-up-john- good...](https://www.texasmonthly.com/energy/all-charged-up-john-goodenough/)

<comment><USER21> It took me a while to get, that Goodenough is the name of the inventor (John Goodenough) and not a tacky brand name.

<comment><USER20> His name should already be famous, but it sure will be if this new battery works out.

Phones that fully charge in five minutes, then last twice as long...and can go for many thousands of charge cycles?

Count me in!

</comment></comment></comment><comment><USER22> Do people really build mines with a 5-year horizon? Of course it's going to outpace demand... initially.

The great thing about mines is that you can just leave the lithium in the ground if the current prices aren't right.

<comment> barry-cotter If you try and time the market at horizons greater than five years when that's your startup time from planning to production sometimes you'll win big and sometimes you'll discover you've made a genuinely awful investment. With a ten year turnaround time you could easily have the technical, social or economic environment just destroy the viability of your investment. Imagine you're investing in a new city somewhere in Malaysia or Pakistan and the government falls or there's a war. Imagine you're going to build a new auto manufacturing hub in Nigeria and the entire West African economy tanks because Ebola goes pandemic. Timing the marker is fantastic if your bet pays off but nothing is guaranteed.

<comment><USER23> The point is more to not try timing the market. There are all sorts of things one could reasonably say about what would be right or wrong for these unstable areas, but fundamentally the most long term good would be if they could engage in slow but steady development of both their natural resources and their infrastructure. I'm quite confident lithium will continue to be quite valuable for at least a generation. Remember, we still use NiMH and even _NiCad_ batteries in some cases. Even if science has already discovered the magic new battery chemistry that will replace lithium ion, you're most likely looking at 5-10 years before the very _first_ commercial applications come about.

I don't remember exact context, but I recall a long time ago someone was talking about shipping medicine and such to a particularly poor area of Africa, and the reply was basically "There are no roads here to ship the medicine on."

<comment><USER24> NiMH and NiCad batteries do have some useful properties. We still use Lead Acid too, despite it begin a truly awful battery in terms of energy density and based on fairly ancient designs because it's incredibly robust against environmental changes, can delivery incredibly high currents and don't care about how to charge them; you can comfortable load them up by plugging them into a 14.4V supply.

NiCad for example is great for low temperature environments and they can deliver almost 100% of their capacity at the maximum rated discharge. They are essentially lead-acid with a tad more energy density and being very sensitive about how they're charged.

NiMH don't have that great of a capacity at maximum rated discharge but they do have a very very low internal resistance while still (almost) matching Lithium batteries in energy density. Additionally, they are almost perfectly constant voltage until discharged, making them suitable for applications where you might not want a complicated voltage controller.

Lithium is actually a fairly difficult cell. Drawing maximum discharge will reduce capacity, they don't like shocks or extreme temperatures and their voltage stability is _meh_ at best. They also heat up a lot when charging or discharging, making cooling circuits required in some scenarios. They do have extraordinary energy density though.

Don't discount other battery types; battery chemistry dictates the behaviour of the battery under load scenarios, Lithium batteries aren't always the answer.

</comment></comment></comment></comment><comment><USER25> This is no big deal. Prices will tank and an equilibrium will be reached. This kind of stuff happens all the time when supply lags demand and then catches up and you have a little bit too much supply.

<comment><USER26> You also have to consider the percentage of the market controlled by China.

Look at what they've done with their control of rare earth metals.

Artificial scarcity and resource hoarding is something that needs to be considered.

<comment><USER27> But China doesn't have control of the lithium market.

</comment></comment></comment><comment><USER28> Aren't other metals like Nickel and whatnot are the main bottleneck for the vast numbers of batteries required for the electric car boom? Didn't we already know for the long time that lithium is very abundant, but it's those other metals (which are required much less by mass, but still required) that might be a problem, and this is why different companies are betting on different lithium chemical processes, because they don't know for sure which secondary metal will become the bottleneck?

<comment><USER29> Cobalt yes, kind of. Nickel absolutely not. Every single car, globally, could be electrified without making a big dent in nickel demand. Stainless steel is FAR more demanding of nickel.

Cobalt is tricky because in most places it's a byproduct of nickel mining, and it is only mined on its own in a couple places (notably the DRC). Despite that it's fairly likely that it will scale well, and it also becomes less and less relevant as electrodes reduce the amount of cobalt they use.

Virgin spheroidal graphite is another possibly-constrained supply, as it's a very particular kind of hard coal. Luckily it can be produced artificially- batteries use a roughly 40-60 mix and it costs roughly the same. IIRC natural graphite has a slightly higher power output and synthetic graphite has higher capacity, due to the nanoscale patterning of the graphite grains. As coal mining decreases graphite will probably just become more artificially produced, since it can be made from essentially anything.

</comment></comment><comment><USER30> Industrial battery will eat it.

<comment><USER31> Exactly. The potential market for grid storage for renewables will be similar in size to the market for EV batteries once the cost of battery-backed renewables falls below the cost of a grid connection. And once that does happen, power grids worldwide are going to rapidly enter a death spiral as their fixed costs are spread between fewer and fewer users.

<comment><USER32> Why? The role of the grid will still be arbitrage between power generation and power consumption. A flat in a high-rise in a city doesn't have anywhere to put solar panels; a factory couldn't possibly sustain its power consumption with on-site renewables, and no amount of on-site battery storage will change that. Somebody needs to buy power from net producers, and sell it to consumers.

<comment><USER33> A factory may put in batteries to prevent the cost of demand/surge power.

An apartment depending of where it is may put in batteries if it is in a location where power sagging/failures happen often.

Remember the entire world is not North America or Europe.

<comment><USER32> Yes, of course power sinks gain value from having their own power buffer, even if only to take advantage of fluctuations in energy cost. But why would this cause grid collapse? They still need the energy delivered, at some point. It puts whoever runs the grid in the quite enviable position of power market middleman. Far from collapsing, I would expect grids to do extremely well out of such a shift.

</comment></comment></comment></comment></comment><comment><USER34> There's so much energy waste in electric cars from the greater number of times energy must be transferred specifically where it's changing form. I don't really see how this can be minimized or changed enough to make and electric car world (or even hybrid electric) scalable in a way that isn't problematically energy-inefficient. So, I'm at least a little tired of the idea that electric cars are such a groundbreaking solution.

I have nothing against them/people who use them but I'm not convinced that it's the solution to the looming crisis/possibly explosive break up in our love affair with crude oil. Plus, I'm a little afraid that here in the US we're about a minute away from destroying Appalachia even moreso—I.e. due to particularly destructive coal mining practices and mountain topping, etc. So I'm apprehensive about increased strain on the power grid. (And I'm not keen on nuclear power either). But I welcome some kind of paradigm shift/future work that reveals I am wrong in this regard. It would be awesome if someone re-engineered and improved some aspects of these things rendering them more effective and less destructive.

(Edited at 2:24EST for typos)

</comment><comment><USER35> I would've been very excited about this back in the halcyon days of being able to carry spare batteries for my phone and laptop.

<comment><USER36> I bought a laptop with a replaceable battery, RAM, and HDD this year. A Lenovo T480. Most people don't _have_ to buy a MacBook (outside of iOS dev).

<comment><USER35> Good choice, since it's the last one which had the feature. The T490 drops support for removable batteries.

<comment><USER36> >The T490 drops support for removable batteries.

That's seriously disappointing :(

</comment></comment></comment></comment><comment><USER37> The electric car boom is in such early days now, I don't know that anyone can even discern the shape of the curve yet.

<comment><USER38> >I don't know that anyone can even discern the shape of the curve yet.

Now, you have: [https://assets.weforum.org/editor/large_opfwi0Tq43oLA- yv3bAv...](https://assets.weforum.org/editor/large_opfwi0Tq43oLA- yv3bAvJAPxmmvpzpeqDpa2HoienxQ.jpg)

One a country tells its population to go electric and put the infrastructure in place to support that, people adopt EVs at a pretty fast pace and end up pretty happy about it.

</comment></comment><comment><USER39> Hey. That looks like what happens with crude/natural gas/agriculture/any commodity. While it is worth being reported, this is Econ 101 supply and demand. Price volatility is part of the market.

</comment><comment><USER40> There are other problems arising for electric cars: road tax.

Electric cars are way havier than most cars and have so much traction that road maintenance will be much more expensive when everybody has an electric car.

This is why countries like Norway and the Netherlands are thinking about raising the road tax for electric vehicles.

I also think this is why brands like Toyota are still thinking about hydrogen cars. They still don't believe 100% in electric battery cars.

<comment><USER41> This is hilariously misguided with little real truth to it.

Are electric Cars heavier? Yes...but not really by much. Sure a Model S is heavy, but it is a full size car designed to compare with other 4000-pound range cars and a side effect of the platform's age meanwhile a Model 3 is less than 10% heavier than a BMW 3 series.

The traction idea is just absurd.

The real reason why Norway wants to raise the road tax is because the taxes they use on gas cars and gas itself is used to pay for road repair and if there are no gas cars then there is no road upkeep budget.

Also, Toyota wants to do hydrogen because they are materials-cheap, offer specific marketable advantages, and easy to build under current architectures enabling larger profits.

<comment><USER40> Well maybe this is different in the US but in Europe electric cars are easily 20% heavier than similar models.

The traction idea is not absurd. Tesla owners claim the tires last around 25000 kilometers instead of 60000 when the drive 'insane' all the time.

Takeshi Uchiyamanda was always talking about the environment when he talked about hydrogen. And even now he sees that battey cars are taking off he still stand by his point.

But that is all marketing talk?

<comment><USER41> The first two points don't really apply to future electric cars however.

Euro Electric car models (like the e-golf or such) are generally adapted gasoline models that require additional hardware to make the design work, this is obviously inefficient. To make it clear, the current non-tesla/Jag/Audi EVs are almost all examples of designs that will not be seen in the future so I don't think they are fair to compare. The VW ID3 would probably be the best example of a future euro electric car.

The traction idea is absurd for a few reasons: 1: fast cars exist currently. 2: There is no proof to the idea that accelerating hard has any effect at all on roads. 3: Tesla's Performance is incredible, sure...but that's a $100K car, it is not what will be sold mass market or bought mass market. It's priced near that of a Porsche 911 turbo, which accelerates somewhat near to the level of the Model S and has never been this kind of issue.

As for hydrogen, look at this Toyota-press chart: [https://insideevs.com/news/353600/toyota-six-global- bevs/](https://insideevs.com/news/353600/toyota-six-global-bevs/)

1: they are not all in on FCEV 2: Their own chart shows them believing that BEVs will eventually outsell Fuel Cell (but of course not before FC takes off..which it hasn't. )

</comment></comment></comment></comment><comment><USER42> OK, another worry out of the way.

</comment><comment><USER43> So first the SKY IS FALLING because demand is greater than supply and now the SKY IS FALLING because supply is (forecasted) to catch up to demand.

Sensationalist media articles win both ways :-)

<comment><USER44> _Please don 't use uppercase for emphasis._

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html).

</comment></comment><comment><USER45> Kinda useless build up. More material are been used to build dense battery and they don't use only lithium as major source for these new types of batteries.

<comment><USER27> No competing battery chemistry has been proven to work at scale. Plenty of research in the pipline, but no breakthroughs that scale so far.</comment></comment>


Special Cases Are a Code Smell - <AUTHOR> https://blog.conjur.org/special-cases-are-a-code-smell/ <comment><USER2> When there are multiple code smells, which should have preference?

FWIW, the "straightforward approach" is invalid when the list contains only one element, which helps support the argument that special cases are code smells.

However, the suggested solution - padding - assumes that such solutions are possible. That is, it assumes that there is enough memory to duplicate the array, and introduces a full copy as all the data is transferred, potentially twice. The result might be measurably and noticeably slower. There's also the overhead of instantiating the iterator object via map.with_index, and the double array indexing for each value - which may be slow depending on how the object implements array indexing.

I consider those to also be code smells, and worse code smells than special casing.

The following Python code also has special cases, because of the two 'yield' statements. However, it has none of the above mentioned downsides of the proposed proposed solution:

      def neighbor_sum(values):
         value_iter = iter(values)
         left = 0
         mid = next(value_iter)
         for right in value_iter:
            yield left + right
            left, mid = mid, right
         yield left

As far as I can tell, it produces the same results. It should also be faster and lighter in memory use than the equivalent Python implementation of the proposed solution.

The 'Down with evens' example is also going to be slower than it "should" be, because it creates and destroys unneeded temporaries. The argument is that "conceptually map is a better fit", but as a Python user I would implement it like:

      def down_with_evens(data_list):
        for x in data_list:
          if len(x) % 2 == 0: # even
             yield [x[0]]
             yield x[1:]  # or 'del x[0]; yield x' to match the original
          else:
             yield x

Isn't that clearer, and without the code smell of unneeded object creation causing performance slowdowns? Does Ruby have something comparable?</comment>


Figma Pitch Deck Template (12 Slide Free Version) - <AUTHOR> https://www.basetemplates.com/figma-pitch-deck-template?ref=hackernews <comment><AUTHOR> Hey Hacker News Community!

My name is Julian, and I'm an entrepreneur based in Germany. Over the past few years, I have been passionate about pitch decks as they are the one challenge every entrepreneur will face on his/her journey.

I recently started creating pitch decks in Figma because it allows my team and me to work simultaneously on the same project.

With the Figma Pitch Deck Template, it is my goal to help founders and entrepreneurs build their pitch deck fast, cost-effectively, and collaboratively.

Proven structure based on the analysis of the most successful pitch decks 100+ investor-ready slides 300+ pre-built elements Easy & Fast to Edit

For all of you who are just getting started using Figma or want to try it out there is a free 12 slide version to download.

I hope you enjoy this resource and get some value! Let me know any feedback you may have!

Will love to work on the next version of it!

All the best, Julian</comment>


Streaming Music Is Ripping You Off - <AUTHOR> https://medium.com/cuepoint/streaming-music-is-ripping-you-off-61dc501e7f94

<comment><USER2> That was a very interesting explanation on how streaming royalties are generated and distributed.

I think that the Silent September idea is good. I'd thought that the groups I streamed got a fair distribution of royalties. Now I see that I was completely mistaken on that count.

Perhaps it's better to download everything and send money directly to the groups :-)

</comment><comment><USER3> While the system is definitely a better solution, you also have to look at it from a database performance level. I would prefer the above, and to be honest my knowledge of databases is not strong enough to say that the below makes it impossible or difficult to implement but something that needs to be taken into account.

Spotify currently has a database that tracks the number 'Plays' each artist gets. They then roll that up into a combined number that gives them their royalty payout for the year. Have lets say 100,000 artists, that is 100,000 records accessed when they run their end of year report. On the user level (lets say you have a million users) you now need to keep track of the number of clicks per artist per user. Most likely through having each user have its own click counter table that has a record for each artist they listened to (probably through a foreign key) and then the number of clicks for that artist. When the end of the year report rolls around instead of simply looking at 100,000 records. You are now accessing 1 million records times the average number of artists a user listens too and then running calculations to figure out how much each artist gets by the user. I'm sure there is better database design then the above mentioned but you still run into a more power intensive process to calculate it.

Not something I think will completely stop companies like spotify from switching to this model but something worth considering...

<comment><USER4> Spotify already tracks user listening history. I can see a "Recently Played Artists" section on my profile, and I assume they're using some of it to generate the user-specific "Discover Weekly" recommended music playlists.

</comment></comment><comment><USER5> Why should I care as a consumer? The musicians aren't 5 year old children and should know for what they're signing. I pay the subscription and get the product, you really don't have anything more interesting to do than trying to find problems where there ain't none?

<comment><USER6> The same paying model would be used for consumers, but with subscriber share model presented in the article, the author argues would be a more equitable distribution for the artists. It seems simple in theory, but I would like to see some actual numbers of the users. I am not sure if the infographics in the article are based on real world numbers, or some assumptions.

</comment></comment><comment><USER7> While I understand the point of the author, I don't really see why paying per play is unfair. It seems to me that artists who creates a song that I love enough to play it 100 times in a year should get more than a song by a random artist listened to just once.

</comment><comment><USER8> When people criticise streaming services because it's 'not giving the artists enough money' it sometimes annoys me a little.

What would you prefer?

\- A service where people are able to freely access a huge music library from all their devices for a minimal subscription fee.

\- Having to buy albums one by one, where one album is more than a whole month of a streaming package.

Streaming stopped me pirating music. I have no reason to do so (other than the odd MP3 file for video editing/DJ practice etc.) any more.

Services like Spotify/Apple Music need to also take a cut for server management, developers and management staff etc.

Also the record industry takes massive cuts so the artist doesn't seem to see much of it at all, even with normal albums.

<comment><USER9> So you either didn't read the article or you are choosing to ignore the alternative proposed which I've felt is the better way to do this for some time. Each subscriber's $10 -> $7 (After _streaming service_ fees) is divvied up between the artists they listen to in a given month. I fail to see how this causes any issues at all and does not result in having to buy albums one by one and gives you access to a huge music library for a minimal fee.</comment></comment>


Hire the hackers - <AUTHOR> http://www.ted.com/talks/misha_glenny_hire_the_hackers.html?

<comment><USER2> I you want to support this kind of thing, get involved with Jonny Long's "Infosec Without Borders" project. <http://infosecwithoutborders.org/> The idea is to assign hackers to help non-profits around the world in exchange for professional references to get their "legitimate" careers off the ground.

<comment><USER3> I'm sorry, but the combination of the domain name with a Flash-only site/page I find a bit ironic. First step: Trust our Flash!

<comment><USER2> Yeah, you're not missing much. The site is obviously a placeholder thrown up to generate leads. They've got some big names already though, hopefully it will expand the Hackers for Charity project significantly over time.

<comment><USER3> Thanks for the clarification/qualification. Although, if they are pursuing lead generation, I would question the success and quality of the leads they will generate with this approach. Know your market...

To qualify my own comment: I didn't enable the Flash content. (Not that I'm a security guru, but I think the current design would be off-putting to others including those who are.)</comment></comment></comment></comment>


The Autonomous Astronauts Association (2015) - <AUTHOR> https://www.vice.com/en_us/article/3dkymw/smash-the-hotels-squat-the-moon <comment><AUTHOR> The story of the Autonomous Astronauts Association, which fought military- corporate control of space through dance parties.</comment>


The interesting ideas in Datasette - <AUTHOR> https://simonwillison.net/2018/Oct/4/datasette-ideas/ <comment><USER2> Great write-up. It's the classic innovations dilema (squared) all over again - the simple things e.g. SQLite, CSV, etc. work far better than modern "state- of-the-art" offerings. Also doing my fair share e.g. trying to improve CSV - CSV v1.1 anyone? -> [https://csv11.github.io](https://csv11.github.io) and collecting text to SQLite dbs for football -> [https://github.com/openfootball](https://github.com/openfootball) (aka football.db); beer -> [https://github.com/openbeer](https://github.com/openbeer) (aka beer.db) and the world -> [https://github.com/openmundi](https://github.com/openmundi) (aka world.db) All datasets / SQLite dbs in the public domain (no license, no copyright, no rights reserved), for example, and ready for use with Datasette. Thanks for the great (open) data publishing tool.

</comment><comment><AUTHOR> If you're excited about GraphQL you may enjoy this one: SQL as a query language for a JSON API: [https://simonwillison.net/2018/Oct/4/datasette- ideas/#SQL_as...](https://simonwillison.net/2018/Oct/4/datasette- ideas/#SQL_as_an_API_language)

</comment><comment><USER3> Worth it just for the thoughts on keyset pagination alone:

[https://simonwillison.net/2018/Oct/4/datasette- ideas/#Keyset...](https://simonwillison.net/2018/Oct/4/datasette- ideas/#Keyset_pagination)

[https://use-the-index-luke.com/sql/partial-results/fetch-nex...](https://use- the-index-luke.com/sql/partial-results/fetch-next-page)

I've implemented this myself (poorly) for mutable data as I slowly began to lose my mind. For example a feed of users' posts (ordered uniquely for each user based on their personal preference) that can be individually created and deleted, and you don't have enough memory to cache all of the query results to be returned to each user immutably. As far as I can tell, this is an open problem.

<comment><USER4> Not sure if I still agree with what I wrote here, but related article from many years back:

[http://cra.mr/2011/03/08/building-cursors-for-the-disqus- api](http://cra.mr/2011/03/08/building-cursors-for-the-disqus-api)

There's also an implementation in Sentry, that is probably too complex, awful code, and hard to read, but is open source if anyones curious:

[https://github.com/getsentry/sentry/blob/master/src/sentry/u...](https://github.com/getsentry/sentry/blob/master/src/sentry/utils/cursors.py)

</comment></comment><comment><USER5> Interesting how there is also another post on the front page on the thing I associate with Datasette:

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

<comment><USER6> This is an amusing coincidence that confused me quite a bit as I hadn't heard of either before...

</comment></comment><comment><USER7> I have been consistently impressed with your work. Keep it up!

This has been very, very nice for throwing up a quick explorer for some research data I use regularly.

You mention things about sqlite's JSON support; do you have plans for exposing more of this?

<comment><AUTHOR> I've been playing a bit with JSON in one of my more experimental plugins: [https://github.com/simonw/datasette-json- html](https://github.com/simonw/datasette-json-html)

I also have a feature where you can tell the JSON API "I know this field is JSON - don't give it to me as an escaped string, give me the JSON raw". Here's an example: [https://latest.datasette.io/fixtures- dd88475/select.json?_sh...](https://latest.datasette.io/fixtures- dd88475/select.json?_shape=array&_json=json)

</comment></comment><comment><USER8> I do think that if sql were to come out now, it would be like the hottest thing ever. It's funny how that works.

</comment><comment><USER9> One thing I'm interested in is a data format that's like CSV, so its streamable, has a binary compressed version, ascii version for viewing on the cli, and also fixed width per row so it can be memory mapped and have random access performed.

<comment><USER10> How about Flatbuffers?</comment></comment>


A native code to C/C++ decompiler - <AUTHOR> http://derevenets.com/index.html <comment><USER2> No source? The first thing I did was try it on itself... which I suppose is somewhat of an "acid test". It took a few minutes and an enormous amount of memory, but finally it told me that the function at the very beginning of the executable, definitely a nontrivial one, decompiles to...

        void fun_401000() {
        }

I'm sure I hit upon some edge case and much better output can be had from this tool if I play with it some more, but for a first impression, not so good. But I'm definitely going to keep this one around, it looks promising.

<comment><USER3> For all we know, that result is a complete facsimile of the original source. But then again, we don't have the source.

</comment></comment><comment><USER4> The original and the most powerful disassembler is IDA Pro. The project was started in the 90s and has been used for security analysis, antivirus work, protection analysis/research, hacks as well as normal dev work in the closed- source ecosystems.

[https://www.hex-rays.com/products/ida/index.shtml](https://www.hex- rays.com/products/ida/index.shtml)

The author has implemented a decompiler plugin over the top of IDA and it works on the real-world code. The point here is to annotate the disassembly bottom-up and then decompile.

[https://www.hex-rays.com/products/decompiler/index.shtml](https://www.hex- rays.com/products/decompiler/index.shtml)

I don't want to bash the author of Snowman - this kind of research is serious fun. Yet, IDA has an insane lead.

<comment><USER5> It's also expensive. I'm sure it's worth it from all I've heard, but it's unlikely I'll ever have the money for hobby work.

<comment><USER6> For what IDA does, it's incredibly _inexpensive_ , so much so that it's distorted the market for reverse engineering tools. Consider that people who use IDA on a day-to-day basis have $250/hr+ bill rates, and if they use IDA, they rely on it. Meanwhile, the set of people who use IDA on a day-to-day basis is very small relative to the whole industry.

I'm not saying you should buy IDA, just that I think IDA is severely mispriced.

<comment><USER4> I hear you. For the sake of completeness, here is the other side of the argument from students that use IDA for reverse engineering. Those activities are really about cracking freemium/shareware apps and the associated subculture is a little... well... special. I have heard countless times that IDA should cost $200 and the author should work with the community to improve the tool...

My stance is that the tool is very specialized, unique and the cost is reasonable for professional usecases.

<comment><USER6> I know I'm repeating myself here, but I want to make sure I communicate this:

IDA's price is so low that it actually harms the market for professional reverse engineering tools. Most useful products you can build --- tracers, visualizers, emulators, pattern matchers, debuggers --- fit into IDA's orbit. As products, as "feature/function/benefit" statements, they are subsets of IDA. But they're chained down by IDA's price. Just like IDA, they have to serve a small market of users who make tens of thousands of dollars _per week_ using the tools, but the market optics make it hard to charge even a significant fraction of the (low) total cost of IDA.

It's sort of hilarious to me to see what Hopper is doing to the market. "Ruining it entirely" wouldn't be far from the truth. I'm only sort of complaining. Viscerally, I'm thrilled that Hopper exists.

<comment><USER7> Who is making tens of thousands per week? Outside of selling exploits to government agencies or cybercrime. Or is that what you meant?

AV jobs pay shit.

<comment><USER6> The software security bill rate for people who are competent with IDA and can find bugs black-box with it exceeds $3k/day. Source: until Friday, I'm a principal at a very large software security consulting firm.

That's for projects denominated in billable days. Talented specialists do even better, on fixed-price projects for specific targets. Rates get higher for cryptographic work, as well.

I am _not_ talking about selling vulnerabilities. I have never sold a vulnerability to anyone, nor have I (to my knowledge) done any software security work for any division of the USG or any other government, nor would I.

Don't work in AV. There are worse things about AV than the pay scale.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> C and C++ are different languages. I only saw C examples. How would you even decompile to C++? The only C++ information you have in the object code is the mangled names. How do you use that to get C++ code?

<comment><USER9> And vtables, rtti data, systematic sequences of ops for invoking base classes, intrinsic/library functions emitted by the compiler in specific situations, exception handling tables, ...

<comment><USER8> But none of those is something only a C++ compiler would specifically do, right? How would you distinguish a vtable emitted by a C++ compiler from one hand-rolled in C? I suppose you could just offer a reasonable guess. I wonder if decompiled GTK+ code would end up turning into C++.

<comment><USER10> Most C++ platform ABIs are pretty trivial to recognize. A tool like this could distinguish a C++ binary by looking at its initialization/housekeeping sections, static constructors, __cxa_atexit, exception handling tables, linked libraries, etc.

For example, the Itanium C++ ABI ([http://mentorembedded.github.io/cxx- abi/](http://mentorembedded.github.io/cxx-abi/), perhaps Itanium's only real legacy) adopted by Linux/ELF and other platforms, leaves a huge amount of fingerprints on a binary. It'd take a very conscious effort, including hand- crafting linker scripts, to generate a C binary that a tool would incorrectly think was C++.

</comment></comment></comment></comment><comment><USER11> Interesting that gcc removes the \n from the string and calls puts() directly - this avoids the overhead of parsing the string for non-existent format specifiers.

The decompiler could do with a bit of work making dynamic library imports more symbolic. Following the puts call chain quickly disappears into a non-local jump to an address with no further references.

</comment><comment><USER12> Another native code decompiler, although apparently abandoned long ago: [http://boomerang.sourceforge.net](http://boomerang.sourceforge.net)

<comment><USER13> Thanks for sharing, did not know. Of course, aware'ing everyone on IDA Hex- Rays on this thread too: [http://www.hex- rays.com/products/ida/](http://www.hex-rays.com/products/ida/)

</comment></comment><comment><USER14> That "hello world" decompilation is complex!

[EDIT: Very informative replies below, thanks!]

<comment><USER15> It's because of the #include <stdio.h>, isn't it?

<comment><USER16> No, it's because its decompiling from _start downwards. From main downwards it's actually very straightforward.

You can also see that GCC did strength reduction of printf("thing\n") to puts("thing").

</comment></comment></comment><comment><USER17> Pretty impressive! I haven't used any disassembly tools in years and only remember last time I did I found it useless. Not sure if that was due to my lack of understanding or the generated output or rather a combination of both. This thing however: I fed it with an OpenGL test app which doesn't do much but still has hundreds of lines of modern C++ spread over different libraries and could clearly recognize lots of my functions in it and follow some program flow starting from main. Still hard but at least I didn't feel completely lost like years ago.

</comment><comment><USER18> This is extremely useful for analysis. Even if you understand x86 ASM, it allows you to quickly jump around a lot more efficiently than you otherwise would.

It won't, for me, recompile back into the source application. So that is a limitation, but even with that limitation it is extremely useful (and the fact it looks the C/C++ back to the ASM, makes altering the ASM directly trivial).

<comment><AUTHOR> This and also the fact it's available as an IDA plugin.

</comment></comment><comment><USER19> I'm wondering whether one could use machine learning and C/C++ code from GitHub to find reasonable variable names automatically.

</comment><comment><USER20> I wonder if statistical machine translation approach could be usefully applied here. Get tons of source from github, compile with every compiler available, train on the result. It would be challenging to compile automatically at scale, to align the code with the source, or to get a source representation invariant to identifiers, but should be doable.

<comment><USER21> It's both harder and easier. There is a mechanical transformation, without un- or approximately translatable idioms like natural language. On the other hand, the dependency chain is much more complex - with something like link-time optimization, a change to one part of the code can completely change the result (for instance, if it suddenly allows inlining of a function everywhere). There is also the problem of, if not "idiom translation", "idiom generation" \- people write code in a particular style that may not be captured by the generated output, even if it compiles the same.

Targeting something like Clang specifically, where you have access not only to the assembler & a potential source, but also a whole AST & intermediate data structures, would be pretty interesting.

</comment></comment><comment><USER22> I'm brand new to C, but wouldn't this from the hello world example always eval true?

if (__JCR_END__ == 0 || 1) { return;

<comment><USER23> If __JCR_END___ was always a boolean, yes.

<comment><USER24> Am I missing something? '==' has a higher precedence than '||', so it should always evaluate as true.

<comment><USER25> I think the catch he's getting at is that || imposes an ordering that the left side is checked before the right side. This also implies that any side-effects of the left side have to happen before the right-side is evaluated.

That said, I still don't know how you could get this code generated. If you make an equivalent piece of code with _JCR_END__ as a volatile int, you still get an infinite loop which has the mov op for reading the _JCR_END__ value but it doesn't bother to test it. IE. gcc still reads the variable but optimizes the loop to a while (1). I can't think of anyway to trick gcc into generating asm like this.

</comment></comment></comment></comment><comment><USER26> I'm kind of disappointed that there isn't a version available for IDA 5.0. Yeah, I'm cheap.

</comment><comment><USER27> This will totally fail for optimised code if it is just using object code without debug information. There is no information in the resulting machine code that can indicate whether some code has been inlined or not. Basically any optimisations performed by the compiler will throw this decompilation off.

I question whether you can get any real use out of this...

<comment><USER28> I don't think the market for this is to get the _actual_ original code. It's more like understanding what a particular program does: when you see it on a higher level it's much easier to understand the code than reading raw assembly.

<comment><USER27> Absolutely... I get that, but its only functional for non-optimised code. My point is that for anything non-trivial, its not going to be terribly useful. You're still gonna need to understand what really is going on, optimisers mangle the code out of all recognisability for this decompiler.

<comment><USER29> Unless the Assembly is using clever tricks like code rewriting, it is always possible to at very least decompile into some form of pseudo-code.

Just the fact of giving symbolic names to memory addresses and replacing Assembly opcodes by more meaningful instructions can make wonders trying to understand some code.

<comment><USER27> I disagree... inlining will remove all evidence that a function call existed. loop unrolling will remove all evidence that a loop existed (potentially). Those are basic optimisations, comiplers will transform the code out of all recognisability for a decompiler to be worthwhile.

</comment></comment></comment></comment></comment><comment><USER30> Why only windows ? i couldn't get it.

<comment><USER31> There's an enormous community of people who spend all their time worrying about the contents or behavior of Windows binaries. I've met some of them through my work, like malware analysts who deal with malware that's part of phishing attacks. The phishers will often prefer to create Windows-only attacks because Windows has such a commanding market share lead among most populations of phishing targets; in turn, that's what the people trying to defend against or mitigate those attacks will study. To folks in that sort of field, "binary" is virtually synonymous with "Windows binary"!

I guess also historically most of the tools for creating, modifying, and examining binaries for a given platform have been native to that platform, rather than cross tools. That's surely because most people (with the exception of embedded developers) do much more native development than cross development. I can get a small number of packages on my Linux machine that will deal with Windows executables in some relatively shallow way, but I have _tons_ of programs already installed that do complicated and specific things to Linux ELF binaries even though I don't typically use those programs on a day-to-day basis.</comment></comment>


Push notification click-through rates - <AUTHOR> http://andrewchen.co/2014/09/16/new-data-on-push-notification-ctrs-shows-the-best-apps-perform-4x-better-than-the-worst-heres-why-guest-post/

<comment><USER2> Apps that abuse it for ads have 100% immediate furious uninstall rate with me.

<comment><USER3> Yeah exactly this. If you want to tell me about something that's legitimately important to me, fine. But don't remind me to come play your game or advertise your other products via push. This will result in an immediate uninstall. Zynga games have been banned from my devices for this reason.

<comment><USER4> > legitimately important to me

Frankly even offering them the leeway to define what is legitimately important to you is too much in my opinion.

There will always be companies out there ready to argue 'but you DO legitimately need to know about our important new fubar app!'.

I would be interested in a site that collected reviews of the notifications- usage of various apps so that I could check there before downloading. In a perfect world there would be a rating option for this ('Notifications Abuse Rating') but that'll never happen.

</comment></comment></comment><comment><USER5> The article misses the fact that the notifications all have a CTA "slide to view" but have no affordance to dismiss. I don't have an iPhone so I don't know how to dismiss those messages without viewing the app. My Android, though, always has slide-to-dismiss and click-to-view.

How many of these 40% CTR are from viewers who are frustrated that they can't figure out how to dismiss the message without clicking-through?

<comment><USER6> Almost anyone who uses iOS on a daily basis certainly knows how to clear notifications. The lock screen doesn't offer such an option, but the slide- down Notification Center does: [http://tctechcrunch2011.files.wordpress.com/2013/09/notifica...](http://tctechcrunch2011.files.wordpress.com/2013/09/notification- center-ios7.png)

<comment><USER7> You can swipe notifications away in iOS8 from the lock screen

</comment></comment></comment><comment><USER8> I wish apple charged for each notification.</comment>


How Snapchat took over Yale - <AUTHOR> http://haufler.org/2013/02/05/how-snapchat-took-over-yale/

<comment><USER2> 4chan has a very similar dynamic vis-a-vis ephemerality and lowering social inhibitions. On 4chan nothing is saved (internally) and threads disappear minutes after people stop posting actively in them. This was the first thing I thought of when hearing (just now) about Snapchat: "Oh, it's like 4chan."

</comment><comment><USER3> My 12 year old and her group of friends are hooked on Snapchat. No idea it had reached the University/College level. My understanding is the kids love it because several parents insist that their children never delete their texts until the parent has reviewed all of them each night.

People will share more when they know that content goes away. Makes a lot of sense but would have never thought of it that way prior.

<comment><USER4> I am not one that checks my daughter's txts every night, but I do educate her that her actions can have farther reaching consequences than a young person might think at the time. Doesn't the false sense of privacy that this app creates give you concern that your daughter and her group of friends might overshare and create problems for themselves or others? The content does not go away, there is no way to prevent that. There have already been several workarounds (hacks) to persist the images being sent and I could think of a few more low tech solutions (second camera to take a photo of the snapchat screen is one that comes to mind).

<comment><USER3> A lot of things worry me about my daughter(s) and the technology that they use. It sounds like you take the same approach. I can't tackle each new app in a tactical fashion so I can only drive the 30,000 foot level stuff. "Would you be proud of this if someone else saw it? Do you think that's hurtful to other folks involved?" etc so that she asks herself those questions. Honestly the ones that seem most vulnerable are those ones where their parents are micromanaging - but that's probably just symptomatic of larger issues.

</comment></comment></comment><comment><USER5> _Since snaps disappear seconds after they are opened, users feel comfortable sending spontaneous and personal messages that they would not want ingrained into digital histories._

I donno but taking a screenshot and posting it on FB isn't very difficult. Do people really believe the images 'disappear'?

<comment><USER6> The key here is intention. While of course it's quite possible for images to be reproduced in one way or another, the fact that they _must_ be reproduced, and not simply 'shared' or 're-*ed,' changes the user's relation to the app.

I think this gets to the tone of the article, as communicating this way implies a level of trust and/or intimacy usually reserved for analog methods.

Snapchat is brilliant in this regard. I think we're going to see a lot more communication platforms built on limitations rather than sprawling features.

<comment><USER7> _I think we're going to see a lot more communication platforms built on limitations_

\-- This would be an interesting brainstorm.

<comment><USER8> lets do it! I'll go first: How about a chat program based on sharing websites? Or an email program without a subject line?

<comment><USER9> > Or an email program without a subject line?

What about email with only a 140 character subject line? Who would want to write more than that anyway?

<comment><USER8> I've been experimenting with text summarizers, but the content of email is so subjective that it is hard to make a meaningful summary. Anyone have experience/thoughtspace in this area?

</comment></comment></comment></comment></comment></comment><comment><USER10> Nice article - It seems lazy to me when people hastily assume snapchat is only used for sexting.

From my experience with younger siblings and their friends, it seems much more mainstream among high schoolers and is genuinely being used as a legitimate communication tool, not just a sexting app.

Is this true or do you think it does lend to more of a sexting crowd/behavior?

<comment><USER11> It does have those connotations at first when people use it I believe. It's just one of those things, I'm sure a lot of people use it for naughty behavior but there's not really a way to do know for sure except surveying. It does make it easy, but in my experience it can be used for non-sexting type things. Just a funny hello or capturing emotion of messages back and forth is quite fun.

</comment></comment><comment><USER12> the best part of this article is that we learn even yale undergraduates have no idea how statistics work. "i estimate that the contacts in my phone are a representative sample." based on what? the fact that you want to make generalizations?

<comment><USER13> Of a typical Yale student I assume be meant. And I don't see how you can fault the author for that.

</comment></comment><comment><USER14> I hope I'm not coming off as a conspiracy nut, but I can't see the US Government being too keen on something like this that's truly untraceable.

IANAL, but it seems to me that every service or software that is used for personal communication is forced by the Feds to allow accessibility for wiretapping circumstances.

Of course, I'm completely against it and I believe the situation is completely untenable for them to persist, but I don't think a social picture app will be the ones to stand tall on user privacy.

<comment><USER15> This hardly untraceable. Everything going through the networks is recordable and the Government has access to it all.

<comment><USER14> Right, but the same could be said about Facebook and other social networks. The FBI wants more specific access to social media services so that they can gather contextual evidence instead of just whatever is out there in the ether:

[http://news.cnet.com/8301-13578_3-57544139-38/judge-prods- fb...](http://news.cnet.com/8301-13578_3-57544139-38/judge-prods-fbi-over- future-internet-surveillance-plans/)

<comment><USER16> The point is that at a technical level, SnapChat imposes no barriers to an actor like NSA. It's not even designed to. So it's already far from "untraceable" and it's gratuitous to suggest that the government will kill the service or even need to change anything in order to see what you are sending on SnapChat when they want to.

</comment></comment></comment></comment><comment><USER17> I'm curious now, is anyone over college age (say, 25+) using this thing? The way it's based on impermanence intrigues me more and more, but no one I know's on it yet.

<comment><USER18> I have the same question. As a social phenomenon it intrigues me, but nobody I know uses (or at least, has admitted to using) Snapchat or Facebook Poke.

</comment></comment><comment><USER19> Given the fact you can send out messages to multiple recipients, how do they stop it from being bombarded by spammers?

<comment><AUTHOR> Users need to accept you as a friend before you can send them Snapchats

<comment><USER20> Unless it has changed recently, I think anyone can receive Snapchats until disabled. At least, that's how it was when I opened an account a few weeks back. That was discovered when I received an unsolicited snapchat from a name I didn't recognize (I have no friends on the service aside from the default teamsnapchat).

Rather than risk viewing something regrettable, I deleted the "message" and quickly found the setting to disallow unknown users from messaging me. :)

</comment></comment></comment><comment><USER21> quick tip for the author: If you are doing a 2x2 grid, the convention is you want better to be up and to the right. So you want snapchat to be in the upper right quadrant. I was initially confused when I glanced at your table and thought "Morse code is the best solution?"

<comment><USER22> Better in this case is subjective.</comment></comment>