lol, he's so reminiscent of Trump. He can't help but make it all about himself. "I was the prime mover behind OpenAI". Everything is always all thanks to him.
A few people have touched on it here, but I'll add my voice. I firmly believe that there are programmers who are better described as a "1 vs. 0" programmer. Some programmers have a creative talent in them that leads them to create elegant solutions that literally a team of 50 average programmers would not.
I completely understand that you need to start with epub books. But do you have longer term plans to partner with the proprietary ebook providers? There are a lot of older Kindle eBooks without audio versions that I would love to listen to during my commute.
We do! Currently we are working with web serial authors to help create narration for their works. Support for azw, mobi formats are coming soon. There is a newsletter box near the bottom. If you subscribe, we will let you know once we launch support for those formats.
God, HN can be so cynical at times. (I'm not really directing this at just you, scarface74, but the overall tone of responses here). Docker and Kubernetes are not just about padding your resume. Why would I not want to use a solution for orchestration, availability, and elasticity of my services?
Why wouldn’t you? Easy: because you probably don’t have enough “services” to make the costs of kubernetes worthwhile.
If you do, then congratulations, you’re in the top 5% of dev teams, and you presumably also have a well-funded organization of people supporting your complicated deployment.
Otherwise, it’s the common case of bored devs overcomplicating systems that can be deployed more
cheaply and safely with simpler technology.
I’m not saying you wouldn’t. I am saying that you get elasticity, orchestration, and availability by using AWS/Azure/GCP and managed services where appropriate and its a lot simpler. I’m not saying the cloud is always the right answer and if I were to do an on prem/colo, I would probably go for K8s if it were appropriate.
As far as Docker, it is the basis of both Fargate, ECS, and CodeBuild in AWS. I’m definitely not saying that it’s not useful regardless.
But why am I cynical? I consider myself a realist, no job is permanent, salary compression is real and the best way to get a raise is via RDD and job hopping.
How much hiring and interviewing have you done? I've seen countless resumes with 25 years of stated glorious achievements, and they couldn't write a for loop.
I've done quite a bit and have never had any difficulty sniffing out "gloss" with just a few minutes of questions over the phone using the applicant's resume as a starting point for the conversation.
When you're focused on system implementation, delivery and maintenance you can pick one of the past projects listed and start probing. It's not hard to quickly get a picture of what the candidate did and didn't do on the project and whether or not they're blowing smoke.
Exactly. Of course, we do have to be a bit careful how we ask about past projects, to avoid the appearance of being exposed to IP, but it's doable. We can also just talk about hypothetical design problems (and they can learn about us based on the questions we ask, even if we're not doing a collaborative exercise). But no whiteboard CS101 coding negging.
I took a look at your Wikipedia page. Are you actually a practicing Quaker? I know it’s none of my business. It’s just so unexpected to see from a UC Berkeley PhD, computer science prodigy, that I find it fascinating.
Yes, quite seriously - I go to worship most every week, annual session most every year, am on several committees, including the one that does memorial services. There are actually a few computer people at our meeting.
Having a spiritual practice really helps keep me grounded. Keeping it relevant to the article, it's something I would recommend.
Thanks for the reply. I will admit I live in a bit of an atheistic bubble, so it’s interesting to hear a different perspective, especially from someone as incredibly accomplished as you.
2 things I'm not seeing in the article or in the comments so far:
1) The virtual DOM is an abstraction that allows rendering to multiple view implementations. The virtual DOM can be rendered to the browser, native phone UI, or to the desktop.
2) The virtual DOM can, and should, be built with immutable objects which enables very quick reference checks during the change detection cycle.
There are other ways to represent a UI as data that don't require a diff. JSX's default compiler output throws away information needed to do efficient updates, and instead requires diffing the entire old and new trees.
Immutable objects may optimize for checking for data changes, but only if you do that, as in shouldComponentUpdate or checking inside render(). They don't optimize the _diff_, which is done against the DOM.
On point #2, ClojureScript not only provides immutability out of the box, but also has libraries for replacing JSX with the same stuff everything else is built with. It's an insanely beautiful way to work with React.
1: there’s no reason at all why VDOM should be the abstraction over the multiple view implementations; there’s no need: it’s all duck typed, so make DOM (or at least the subset of it that Svelte will generate) the abstraction that other things must implement. I believe this is how Svelte Native works.
Furthermore, as a compiler, Svelte is well placed to render to multiple implementations, efficiently—though implementing it is likely to take more effort if you’re dealing with a different-shaped API. This is demonstrated by the fact that Svelte has two compilation targets at present. First, dom, which is designed for client-side DOM operation; and secondly, ssr, server-side rendering, which is based on emitting strings, and never constructs a DOM.
2: even if you can do things that way, you’re still doing more work than is necessary, because you’re calling the whole render method and performing even simple comparisons that just aren’t necessary. VDOMs render methods are allocation-heavy, because they deliberately create new objects all over the place. In the words of the article, which I assert does deal with this, albeit obliquely: virtual DOM is pure overhead.
