sahrizv

Compact Sparse Merkle Trees (CSMT) [1] is an already existing scheme for shorter proofs, which introduces the new CSMT data structure and was also posted on HN a while ago.[2]

This[3] is the implementation(in Elixir) of the above paper by the author for those interested.

Also, here [4] is an interesting discussion between the author of Compact Sparse Merkle Trees and Vitalik Buterin, the creator of Ethereum on their research forum.

I have posted these links because it seems disingenuous at best and malicious at worst, to not cite this original work which has been extensively discussed and documented before, anywhere in the current paper.

[1] https://eprint.iacr.org/2018/955.pdf [2] https://news.ycombinator.com/item?id=18166298 [3] https://github.com/ZanjeerPlatform/csmt [4] https://ethresear.ch/t/compact-sparse-merkle-trees/3741

Fair point, but the medium changes the message sometimes. :-)

The tweet resonated with a sizeable part of the developer community hence linked here.

I recently tweeted about these abstractions over abstractions here: https://twitter.com/sahrizv/status/1018184792611827712

Not downplaying the team's effort and the immense utility of this to many companies.

I think a global style file helps when the same HTML markup is repeated in several parts of your application.

However, a component based architecture, by definition represents the reusable HTML markup of your application. Since such a component brings along its own styles wherever it is used, there is negligible loss of reusability of styles.

This is in theory of course, but my experience (with Vue.js) has been the same in practice too.

With Vue.js at least, you have the optional "scoped styles" feature which gives you tuneable reusability in case you really need it. Most of the time, I find my self writing

  <style scoped>/*styles here*/</style>

 in my component files.

This would be done programmatically using webpack or some other front end build tool. I doubt I'd ever need to do that TBH.

Agree that's a big way to create more jobs. Currently building for myself, hope to do it for others too in the long run.

waits restlessly for elixir jobs... :)

Seriously, left my decently paying Tech Lead job in Bangalore to take a break and work with Elixir/OTP.

Would be nice to see an upward trend in Elixir related remote jobs.

I think a good way to increase creativity and productivity is to use the right abstractions of thought and craft. Every good(non leaky) abstraction expands the creative envelope further and lends itself to creation of new higher order abstractions for the next generation.

Having coded in imperative languages like Java, Python and C++, I had been on the lookout for a practical general purpose language which provides good abstractions/high expressiveness. Elixir appealed to me more than Go in that regard. It's been six months since I started writing Elixir and it's been a pleasure.

Thanks for the heads up. I'll move to Google Apps on the first sign of trouble.

I set up free email with custom domain on Zoho, yesterday. You can set up to 25 free accounts IIRC.

Yes, definitely build up a good runway or you'll find yourself negotiating from a position of weakness when you look for a job with urgency.

Another thing would be that employer preferences differ with regional factors, so get opinions from some local friends who have done this.

Finally, as you might already know, you must realize that this is a gamble. I'd play in a way that I have some guaranteed upsides(learning, fun, experience, autonomy), bounded downsides(loss of income, loss of seniority, stress) and unguaranteed, unbounded upsides($$$..$$$).

Personal Anecdote: I've been on a planned break since June '16 to build stuff, among other things. I get approached by top Indian startups once a week on average and nobody seems to lose interest when I tell them I'm on a break.

I have come to love a language called Elixir while working with it during the break and potential employers take it as a positive when I mention this fact.

Before I quit, I was a Tech Lead at an early stage startup(now Series B funded) for 6 months and I'll be looking for employment soon. I do not see this being a problem in my case.

Context: I quit my job in June 2016 to take a break from my career and among other things, build a product end to end. Money has run out now but passion hasn't and I'm close to first launch. I'm in Bangalore so I'm able to keep burn rate below $400/month.

Advice: I'd say go with the tech you know(exceptions only apply if your core differentiator is technological superiority, but that's rare). You'll have full days to yourself, so separate work time from leisure time, do physical exercise, be in touch with friends, don't reveal your plans/progress to many people, involve target users as soon as possible(most important). Lastly, enjoy the ride!

I found the writeup valuable in terms of provoking deeper thought and discussion.

However, I think perhaps the author is mixing up 'both wits' (logical vs emotional thinking) with the two systems thinking from the TFaS book(intuitive vs logical thinking), at least in the writeup.

I am more inclined to believe that intuition and logic based thought processes are superior to one that has an emotional dimension, at least for running a business.

As an example, I think if in the Cheezburger case the author was less emotional, he would have responded rather than reacted to the perceived threat- which is arguably a better way to deal with the situation.

Lack of affect(especially fear) is a defining quality of psychopathy, which happens to be very common amongst CEOs [1].

[1] https://en.wikipedia.org/wiki/Psychopathy_in_the_workplace#C...

Agree with you. Ability to code and moreover an ability to contribute to the company codebase is something that should be present even at senior levels for a tech focused company.

At the same time, IMHO, somebody in a techno-managerial role with responsibilities of one or more tech teams may find it hard to devote more than 20% of their time to coding.

Submitter here. I have been witnessing the recent rising expectations of being able code irrespective of seniority, especially in younger companies. I have been curious to know HN's take on this.

Perhaps this article can provoke some discussion.

I agree with the core insight that we sometimes ignore the risk taking of high achievers while looking at their life in hindsight. However, I would not say with certainty that Newton was pursuing these fields with the mindset of betting on them. He could have been certain about the validity, value and fruitfulness of intellectual pursuits in those fields.

Interestingly, this is the second time in the past 24 hours I've encountered the idea of comparing a VC (Marc's reference) with another class of high achievers. (previous one, a comparison with entrepreneurs: https://news.ycombinator.com/item?id=13371813)

Got it. Thanks for taking the time to revisit and answer!

I'll outline an approach of mine:

Step 1: Offload the initial selection task to the hype machine. This gives me a smaller set of candidates to work with.

Step 2: Go through the language guides/documentation to understand the core ideas and USP of the languages in the above set.

Step 3: Try to guage the long term viability. This is usually based on some data points but mostly intuition and experience.

Step 4: How does it feel to work with. Is it suitable for the kind of problems you want to solve? Does it provide some technological leverage for the business problem you want to solve, if you are looking for such leverage.

Step 5: Start tinkering with the language(s) that made it past step 4, and be open to update your evaluation during some probation period.

If you want to know my reasoning behind those steps, feel free to ask. :)

Since you seem to measure the difficulty by the odds only(ignoring the sweat/time put in by the entrepreneur), then I'd argue that being a VC is 10x to 100x easier than being a good Powerball (lottery) player. :)

Agreed on all counts.

However, I was more focused on the comparison with building REST APIs in Ruby. I wondered if using Absinthe to wire up all the GraphQL schemas and resolvers was a better experience in itself compared to building APIs the traditional way.

Or maybe it's a tradeoff which resolves positively in favour of GraphQL when a more expressive API is required in contrast to traditional REST when a limited API is required.

An "expressive" API as used above can be roughly understood as one with relatively large number of unique API endpoints.

Thanks for pitching in, jon-wood! Can you elaborate what are the major wins with the GraphQL approach using Absinthe (in contrast to REST) which gives you the "superpower" feeling? This is not a rhetorical question.

I agree. Thanks for your comments!

I agree on that.

Maybe one of these will fit our sensibilities:

"NYPD's actions suggest they can label all mosques as potential terrorism organizations."

"NYPD's actions suggest they have a right to secretly or openly spy on men praying in any mosque in New York."

"NYPD's actions suggest they are overriding constitutional rights of Muslims praying in mosques, in the name of security."

(All of these are straightforward conclusions from the article.)

From the original article from Time: http://nation.time.com/2013/08/28/nypd-designates-mosques-as...

"NYPD lawyers proposed a new tactic, the TEI, that allowed officers to monitor political or religious speech whenever the “facts or circumstances reasonably indicate” that groups of two or more people were involved in plotting terrorism or other violent crime." and

"Doing so allowed police, in effect, to treat anyone who attends prayer services as a potential suspect. Sermons, ordinarily protected by the First Amendment, could be monitored and recorded." and also,

"And under the new Handschu guidelines, no one outside the NYPD could question the secret practice."

While I agree that the NYPD explicitly hasn't labeled all mosques, the laws mentioned above allow them to treat all mosques as potential trrorst organizations. And no one can question them.

That's because the said data framework is still far from being production ready and complete. I fail to see why it is a sad thing. It is actually good for the Ember ecosystem that other options are available even when the core team is forced to distribute efforts on all fronts, leading to a slowly evolving data library.

Mine worked in Chrome 29 after giving it some time after load( ~30 secs)...

The most compelling reason to use Objective-C for iOS development is to make use of the vast array of device-native APIs provided by Apple, most of which are not available to webapps as of now. While you can use PhoneGap/Cordova to wrap your webapp in a native container, and access many native APIs, the process is convulated to say the least. Besides, with Apple releasing new API's(1500 new APIs for iOS 7 [1]) with every upgrade, the likes of PhoneGap cant really keep up with natively available functionality. Performance is another big reason which comes to my mind.

[1] http://www.macrumors.com/2013/06/12/upcoming-ios-7-apis-gami...

I chose Ember mainly for its promise of supporting the creation of large, production level apps, through its robust architecture and well thought out library.

On the other hand, "AngularJS is a toolset for building the framework most suited to your application development." Both Angular and Backbone would have required me to learn other stuff for front end development, which I don't want to do right now.

I wanted a single cohesive framework which would be capable of handling all frontend aspects of a large app. Ember is made for that.

P.S Sorry for the late reply. I'm new to HN and didn't know old threads can be active.

Yeah, same with the ember.js guys. Churning out releases and RCs under such restricted timelines.

This post could well have been written by me as I am also in the same boat as you :-)

Anyways, I have chosen to stick to Django for backend( and Ember for frontend). My reasons mainly are the relative unsuitability and incompleteness of Node when compared to Django. If you are onto learning stuff, and not doing some serious (shippable) stuff, I'd say relish the beauty of JavaScript from both ends.