goofballlogic's comments

I enjoy social media and use it to exchange information, observe trends in culture, and as a communication channel when convenient.

In my case the null state was "not yet processed" i.e. a decision pending

Exception i encountered recently was needing ternary state boolean. a set of flags where true and false indicates outcome and undefined indicates "not yet processed". I suppose some sort of 0 timestamp could work but... No, I think I'll stick with boolean.

As a human being he wasn't perfect, but I come back to images from his film in my head time and time again and they help me look up from my work and consider bigger things on an ongoing basis. His films create space in my head which I go to for help when I need it most.

It would be nice if we somehow had one to convert typescript back into _idiomatic_ JavaScript.

Agree. I don't use or like tiktok but it's sad to see the internet walls setting in. Inevitable perhaps, but sad nonetheless

One of the hard things to get right when writing one of these "Tips for being a great X" is that they're usually written from the point of view of someone who is a clear leader in their field.

With some exceptions, the people who write this sort of article have the confidence (or presumption) to see themselves as ahead of the pack. It is rare to see articles like this written by teams of people who, in cooperation, balance tasks like product management, architecture, engineering, operations and customer success between them. And yet that is, imo, the best way to do it.

When I read and article like this advising the reader to do X to "their team" (in this case let your team get on with work), it falls into this category where the "how to be a great X" applies to a particular structure - where "X" is somehow in control of the rest of the team, rather than an equal participant.

Is there any indication that the numbering change reflects a significant technical shift (eg preparing to target ARM specifically)? Or is this just aesthetics?

Main thing that would prevent me investing in this stack is that the runtime has been designed with typescript in mind. In a few years if the typescript thing blows over, you're left with a runtime and conventions skewed toward statically-typed programming patterns.

He had his scandals but this guy was a legend. A real defining influence on my teenage years.

While I agree with the concerns regarding arbitrary implementation of standard APIs, there are still a bunch of useful applications of PWA technology to enable temporary offline operation.

The more we use these, the more likely the APIs are to be fully implemented (and hopefully have features added to them).

A sad day I think. I wish more independent ecosystems were evolving, instead of consolidating.

Great idea. I was just thinking about how this would be a great idea the other day.

As a UI architect I've worked on both SPAs and also ROCA-style UI quite a bit. Like everything pros and cons to both.

As a general rule of thumb I find SPAs deliver much faster, but ROCA-style solutions are much more predictable. That is, getting a modest MVP out the door with an SPA terms to be much faster, but almost always reach a critical mass of functionality at which point they become hard to maintain. ROCA-style apps don't suffer with this as much.

I don't think this experience is just down to the architecture however. I just think it asks a lot more of a software engineer to structure and maintain an SPA well. Ultimately an SPA can be a more optimal architecture for many applications because the client-side environment is an increasingly powerful VM in its own right. However, I rarely see the engineering discipline required to do it right.

I tend to prefer ROCA-style because it fits better with the web's distributed integration architecture, but in practice I find building an SPA with a resource-oriented mindset is usually a good compromise.

What happened to Idris? As someone who knows absolutely nothing about Haskell, I thought Idris was essentially Haskell+dependent types?

"an engineer codes what someone else thinks they want" seems a fairly damning indictment of our industry although I think the author meant it tongue-in-cheek.

Lack of ownership of responsibility is still quite a big roadblock for many companies.

That had been my conclusions over the years. Erlang (or Elixir) are ironically one of the nicest environments for OO code these days (given they are usually categorized as "functional")

I think this is an issue which needs to be addressed a bit more holisticly. The fact is that HTML, JavaScript and CSS (to name three) all use an element's _className_ for slightly different purposes.

The author seems to consider BEM an example of a _semantic_ CSS scheme, but really the semantic needs to be clear across all the consumers of the API being implicitly established by the markup.

Ultimately HTML is the original source of a web page, with CSS and JavaScript often augmenting this. For that reason, I think it makes sense to opt for the HTML spec's definition of _className_ semantics when there is a clash.

The spec effectively balances the importance of both CSS and JavaScript (or other user agent) uses, but cites an example useful to both:

https://www.w3.org/TR/1999/REC-html401-19991224/struct/globa...

Does anyone know if the author completed other projects in Ada (or another language)? I'd be interested in reading some code as well as the specs.

I too struggle to like AMP. The rhetoric seems a little absent imagination in regard to offline. Are you really saying your handheld computer can't be useful without a worldwide network connection?