sahrizv's comments

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.

Edit: Regarding performance, I believe it could potentially be an issue on mobile devices (for now), and if so I would solve it by creating a global stylesheet by merging all individual stylesheets and appending the component name as a prefix in all selectors in both the styles and the markup.

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.