AndyPatterson

I think the sincerity of this makes this the funniest thing I've read on HN.

I don't think it is.

For a start, it's not the lean/agile way to have a large capital cost for your idea. If the idea dies, so does all that money you've wasted.

Secondly, the example given is quite naive in design. You wouldn't serve directly from s3 because of costs so you would serve via caches/cdn; for instance, using aws cdn would cost 85 cents.

Going back to the first point though, you're putting a lot of money at risk.

The problem facing these tools is a catch-22 really - diagrams are useful when understanding big messy codebases but big messy codebases are hard to visualise.

For instance, I frequently build small paper diagrams of different code paths through a component and nearly always find leaky abstractions, mixed layers of abstractions, weird cyclical dependencies, etc. etc. and there really is no clear way to diagram this. Instead, you sort of have to make judgements and assumptions to make the diagram concise and understandable; the sort of decisions that machines just aren't that good at.

On the other side, when code is simple and easy to follow then the pay off of building a diagram just isn't there.

Just learn python, it has general applicability and is fairly easy to pick up.

Housing market is screaming out for a lot more regulation than this, so I welcome it.

Build it the stupid way first is short sighted imo but this might just be an exaggerated way of saying premature optimisation is wasteful.

Just putting it out there, but I think Knuth’s aphorism is being used and abused to the point that some folk believe system qualities are second to functional requirements when it’s not the case.

IMO a lot of teams can do CD but chose not to as they don't have the risk appetite or maybe the resources to handle problems occurred at deployment time. (Tests, however many we have, simply won't cover every scenario that could break a deployment).

SOAs when implemented correctly don’t have any of the issues Michael describes; for one, cascading errors shouldn’t happen and devs should test for this in their game days.

Years ago when I first graduated went to an interview for a Java dev role. Spent the full day there getting pulled apart by whiteboard interviews, exam papers, and daft questions that would have no real day-to-day use in a dev role. Even worse was I asked at the end of the day what kind of work I could be expected to do and found out there was very little actual dev work; maybe some maintenance tasks but mostly support. I became pretty bitter about tech interviews after that.

Sadly interviews like that became a regular fixture and some were even worse. In a few I even had take-home assignments where I was to implement a full-project from scratch then present it at the interview (as well as all that other crummy interview stuff). I even got heavily criticised/insulted in one for prioritising my current job over the assignment and was told if I really wanted the position I "should've moved heaven and earth" - pretty deranged to ask someone to risk their income for an unpaid assignment if you ask me but anyways.

With that being said, I do think interviews are becoming better. They're less about blowing smoke up the interviewers arse and more about judging how good a fit they are for the company. Interviews tend to feel more collaborative and white-boarding sessions aren't a test but a discussion, with the best language agnostic. Hopefully they keep going this way.

I work using R almost everyday and I think many of the problems that are unique to R could be solved by having a couple of experienced SWE in the core team to point R in the right direction. As it stands, I think R will be left behind until it fixes things like performance and scalability (e.g. intuitive byref semantics and a faster runtime) and a consistent scoping model and OOP.

Apart from that, I think there's a bigger challenge which still needs to be addressed is that analysis/modelling projects tend to be worked on by individuals and/or thrown away after the initial value is pulled out of them.

Going forward, I think we need to start identifying design methodologies that would make collaborating on this sort of work pain-free and more agile. Doing so should give us more value and sooner and for longer.

I wish folk would move away from the world war two nostalgia, it's debilitating and wasn't at all hard and fast, even if a 90 minute movie cut leads you to believe that.

Not familiar with game development but how would a continous delivery approach work in this case? surely the MVP that could be delivered is the complete game?

I’ve got one criticism in that the over generalisation remark shouldn’t really exist in well designed DRY code - if two function calls and one doesn’t even use most of the parameters then these aren’t covering then these should be separate functions

I don’t see how it can be both 1 and 9 though. In my mind it can only be 1 because anything to right of the division sign should be fully evaluated first before using the result in the division operation.

Its a certainty that given any prompt there will be likely one gnarly output, especially the longer that output becomes.

What I'd like to see is an estimate of the uncertainty of the output.

Skimmed the paper so couldn't possibly give it a fair review but I always feel there's something off when people make comparisons of ANNs to actual biological brains. Even more so when it's the other way about.

This simply isn't needed, and if it is it can be done by a charity or any group of people, not something that should be built into the infrastructure of the web itself.

You have to remember that while the little that the web provides is also its strongest attraction; it allows the web to be accessed and modified by anyone, they're on little bit of the web can be very different from someone elses.

So by adding on a way that the web must be indexed is kind of like moving closer to communism than liberalism. I guess if we start dictating to google where to get their data then we've moved to the full blown hammer and sickle stage :).

No idea where you got this statisti, but I guarantee no user would be happy to wait hours or (god forbid) days on a search result.

Off the top of my head I'm thinking that there's a serious lack of thought in these use cases, especially string manipulation which I could imagine becoming painfully slow as the database grows; any manipulation of the projection like this is going to incur a large performance overhead.

It would be quite good to see this blog post, or a response to it, evaluating the SQL codes performance on different datasets.