adamgravitis

Other than the opportunity for a misplaced pun on the term “spiral”, why would you take an otherwise linear-in-time graph and make it radial? Why would age 0 to 50 be somehow cyclical?

I'd rather they be able to run mail servers. SMTP lends itself to intermittent delivery.

Orig article has lowercase ‘n’ in ‘next’, which makes more sense…

Because it was perfect…

The author is displeased with the sort of discussions present on networks built on a couple different technologies. Unclear how the third technology magically makes them “happy.”

I concur. The term obviously refers to another sort of thing entirely.

"In short: this author is endorsing a funding model focused on low initial investment and faster profitability."

-> so basically, Canadian "venture" capital. They don't even want to talk to you unless profitability is there or within a few months. So, basically, it distills to a barely riskier than usual bank loan, except you pay the loan with equity.

This is the furthest thing from the truth. That a human has a certain capability does not in the slightest imply that “DNA”, at least as commonly understood, encodes that capability, at all.

A bunch of molecular recipes encoded in a few gigs of nucleotides with some crude feedback loops do not a human make.

Quite apart from epigenetics as it’s commonly presented (methylation, and all sorts of histone antics), you might recall that DNA itself doesn’t magically grow up: you do need a cell.

It’s somewhat (and only poorly) analogous to being handed the source code to a C compiler written in C, without knowing C. Does the C code really encode C? Well, not without the compiler it doesn’t....

There’s then a very interesting discussion around how it’s even possible for a mammalian nervous system to bootstrap itself. Figuring out walking seems perhaps emergent: it’s a learnable technique based on not falling. But how do dog breeds retain intrinsic high-level behaviours even if they’ve never observed them? What makes a Shepherd so concerned when his assumed flock becomes dispersed?

We are a tremendously long way from answering these questions, but I would caution anyone who thinks it just “in the DNA”.

I would just point out that HN does this in the title of every link posted, and has been doing this for years.

Toronto’s tech talent is keen... but relatively green. Since few companies have had to deal with scaling networks, users and data to the same magnitude as is common with Valley companies, it’s almost impossible to find senior engineers worthy of the title. Plenty of options for junior and intermediate, though.

I agree this is an abysmal article.

A much much more rigorous proposal was put forward by an American mathematician several years ago regarding the geometry of trajectories of computer programs, which holds considerably more promise than whatever flimflam this author was going on about:

https://rd.springer.com/content/pdf/10.1007%2FBF00046564.pdf

Are you guys going to release something describing your concept of "category oriented programming" any time soon?

To be fair, I do insist on calling Deloitte "Deloitte Dot".

Reducing the number, length and complexity of regulation is a valid goal, and that hasn't changed in thousands of years:

"The more numerous the laws, the more corrupt the government." - Tacitus

The main computationally intractable problems around drug discovery surround protein folding and identifying macromolecule shapes. This is necessary to infer receptor sites for potential drug targets.

The problem is massively intractable. QC could revolutionize the space.

Basic income is absolutely one route, but I can think of a few others. A startup could thrive in a smaller city where their employees could achieve a high quality of life without extraordinary expense. You'd still have to solve the recruiting problem, however, and employees would be wary of lock-in effects.

Cities are largely about people, and people are largely about the difficult-to-describe sense of 'opportunity'.

Cities reflect networks effects as strongly as anything, which is why the same cities that were important 100 years ago are, by-and-large, the same cities that are important today: there has been no doubling of exciting, the-place-to-be kind of cities in at least North America despite huge increases in population.

Because of this, our generation is stuck on the wrong side of the supply/demand bit for property. Property in uninteresting cities is very cheap, because nobody wants to be there. Property in Silicon Valley or Toronto is on fire because it's the place to be.

I think there's a critical mass kind of problem. In many ways, my quality of life in a smaller (or even very small) city could be several times higher than it currently is -- except for the people. And, for better or worse, it's the people that matter. I don't have any real desire to be the best educated, or most creative, or most entrepreneurial person in a city: I want to be surrounded by them and call them my friends.

So perhaps there's some kind of Kickstarter-like critical mass sort of system that could be put into place to kickstart small cities whereby 50 or 100 mutually interesting people committed to moving to a more remote city iff their compatriots did as well.

Of course, to make that work, there would be have to be some kind of "opportunity", which is why I'm happy to see yC-folks looking into the problem.

Hi Alan,

I've heard you frequently compare the OOP paradigm to microbiology and molecules. It seems like even Smalltalk-like object interactions are very different from, say, protein-protein interactions.

How do you think this current paradigm of message-sending could be improved upon to enable more powerful, perhaps protein-like composition?

Then there'll definitely be ads.

...with just really bad inter-node bandwidth.

For sures. The ECEs are very much complicit too. Perhaps this is a ECE<->software team communication or power problem? ECEs invent the systems architecture and some poor chap has to attempt to secure the thing? Or maybe the software guys have no avenue to push back against bad systems-level design.

So, it's becoming abundantly clear that vehicle companies (autos, jets...) have approximately zero knowledge how to hire software engineers. Presumably they're somewhat more successful hiring mechanical engineers because that's always been their "thing".

It's all well and good for us to chuckle at the terrifying software/systems decisions being made by these teams, but how do we address the root of the problem? It's very clear that entire meta-categories of horrific errors are being made at a very fundamental level. Is this a problem of outsourcing? Of confusing "coders" with engineers?

And how do we solve it? Shame the software team such that they can never get hired in a serious role again anywhere? Professionalize the job into a strictly licensed regime like other branches of engineering?

Whenever I read these types of articles, my main thought has always been, "so who, the hell, wrote the code?" It'd be interesting to know their story.

I just noticed this was authored by Michael Nielsen... co-author of the text on quantum computation, and now a huge open-academia advocate. And he's open-sourced the micro-lisp he wrote in this article: https://github.com/mnielsen

My understanding was that the greater losses in today's tech tend to lie at the VDC->VAC conversion panel-side.

Also, I agree that the USB Power Delivery spec is a very good candidate for modern homes/vehicles.

The rule of thumb with this kind of thing is you try to use plausible data in your screen shots. Having "moar project" and "even more project", and "super project" and "new project" makes it hard to envision what your product is really useful for.

I am, however, sympathetic to Chris' point that just teaching people how to code doesn't necessarily accomplish anything.

I think this concern actually strikes at the core of the difference between programming as a "trade", versus the more engineering or scientific side of programming (under its various names). One may be perfectly proficient at working with, say, the entire iOS API, while still having little idea (or concern) about representing any sort of non-trivial problems.

Having taken both college-level and subsequently university-level engineering courses in programming/CS, I think the difference between the two roughly aligns with the trade vs modelling point-of-view.

I'm not sure it's a perfect analogy. People might ask Ford to go faster, people are asking technology to let them work longer before it dies. I think the sentiment is pretty clear: this doesn't mean we need better Li-ion batteries per se, but either we need hugely longer-lasting sources of power, or we need hugely more efficient displays/radios/processors.

I massively disagree with the importance of swappable batteries. While I suppose there are people who are pretty happy hauling around a bunch of batteries with them, I haven't considered such a thing since camcorders were cool. A big part of keeping technology mainstream is to not require a utility belt.

(n.b. I don't mind if they're user-removable for replacement once they've totally died, but this also seems to have become rather rare for what I assume are manufacturing reasons)

He taught our Calculus II course a few years ago, which had rather famous exams.

A couple years later I was poking around the library and found a book he'd just published entitled something like "50 challenging undergraduate mathematics problems", of which I was annoyed to recognize several :-)

"an iconic font made for developers, code jedis, ninjas, HTTPsters, evangelists and nerds."

Urgh. Why do people do this?