w_t_payne

I wonder if this is something to do with temporal integration periods in the HDR or AGC processing in the camera, in which case it might be an algorithm developed by an camera imager supplier (for example someone like OmniVision) rather than Tesla themselves. Does anyone know which imagers Tesla uses in the cameras on their cars?

Snobbery is widespread among humans.

It's an intrinsic part of our pack-animal heritage to divide the world into an in-group and an out-group and then to fabricate arbitrary moral rules to justify that division.

Everyone is different. I've spent three or four years working remotely, and I'd say I do better in an office. I like the routine that it gives me, and I like the human face-to-face contact. I especially like the energetic creative discussions clustered around whiteboards that you never seem to get so much when working from home.

Having said that, without endless meetings and distractions, working from home can definitely be a lot more productive ... it's just that after a while (a year or so) I start to feel hollowed out without human company.

Modulo the HUGE computational cost of simulating these things, not to mention the non-trivial task of determining network parameters.

Surrogate models are a thing though, and it's going to be an interesting time as we gradually figure out what approximations and optimizations are 'acceptable', and what computations really are necessary for "intelligence" (whatever that might be).

Given the state of the world, and a desire to be as helpful as possible, the latter feels quite appealing to me right now.

Have you tried Panda3D, because I've been experimenting with it recently, and it seems to work pretty nicely ...

Every C++ shop that I've worked in has done the same thing.

Both dynamic languages and static languages have their place. Personally, I'm a big fan of an iterative refinement process where an algorithm prototype in a dynamic language is gradually transformed into a production implementation in a typed, fast static language.

At that point, the state is as criminally brutish as those it seeks to morally disparage and demean, and has lost any right to even be listened to.

A nuanced and sophisticated approach should be able to identify and address the more problematic aspects of this activity whilst also acknowledging that people engage in it for many valid reasons.

So, for example, it would be heart-warming to see efforts like this coupled with measures to help tackle some of the underling/driving issues that affect individuals such as unmet emotional needs, loneliness and emotional insecurity. Harm-causing factors from the broader social context also need to be explicitly identified and tackled, such as those social and cultural systems that weaponize and exploit naturally occurring human behaviours in service of various systematic and abusive control mechanisms.

Either way, you've got to do the tooling work to make your chosen approach work. There's no free lunch here.

I'd love to have a chat at some point. I'm trying to (slowly) bootstrap some tools for the embedded space, and we're trying to get a grasp on (a) what our MVP should look like, and (b) how to go about approaching customer #1.

It's always a good sign when a debate moves beyond 'x' is better than 'y' to a more nuanced discussions of the circumstances and conditions when 'x' provides more value, and the circumstances and conditions when the converse is true.

I've used Simulink a lot in the past, and the things that it gives you (as well as it's limitations) are a big driver for my attempts to build tools in this space (I think I'm trying to do a similar thing to you -- causal reasoning using data flow information and other graph-structured engineering data such as requirements traces).

I believe that diagrams are at their most useful when they are deployed as a communications tool. When discussing our software, we commonly draw a diagram to help illustrate how functionality is divided up among components, and to show which components are impacted by particular functional chains. They are a powerful tool for communicating and coordinating the work of multiple people or multiple teams. If our software does not provide us with diagrams itself, then we will commonly create them ourselves in our technical documentation or on whiteboards as an aide to collaboration.

However, as we descend in our system towards finer and more detailed levels of granularity, two things happen. First of all, fewer people are impacted by very ‘local’ design decisions, so the importance of communication diminishes. Secondly, the frequency of change increases, so the importance of mutability and ease-of-editing increases.

The requirements that we place on our engineering tools depend largely on what we are trying to do with them. Communicating and coordinating work across a large engineering organization places fundamentally different requirements on our engineering tools than does, say, working alone to solve a challenging problem that requires the creation of new concepts and abstractions.

There are many different ways to work with software, and although each share much of the same flavor (dealing with informational complexity), the nature of these challenges is often distinct enough that the different requirements may lead to vastly different solutions.

For my part, I have a lot of faith in the general utility of tools which allow for the easy generation of diagrammatic representations of high-level structure, but which naturally decay to a more conventional textual representation at finer levels of granularity.

Yeah. I liked that last bit as well.

I burned myself out a couple of years ago. A combination of 4-5 years of extreme workplace toxicity and 17+ years of relationship toxicity proved too much for my mind and body to handle effectively.

As a result, I'm super familiar with that cold, dead, leaden feeling of not caring about anything, not really able to feel any of the excitement and buzz that I know, intellectually, I should be able to feel. It is taking a long old while to return back to a position of health, and while that's happening the only thing I've really had to draw on is grit, determination, and a sort of psychotic single mindedness.

I'm now in a much MUCH better place than I was before, but I've been able to keep pursuing my side project (and hopefully eventual startup), and able to keep making some kind of progress ... but it's really only been sheer bloody-mindedness that's kept me going. (I'm hella stubborn when I want to be).

Happily I'm feeling a lot better now, and progress is definitely picking up again now that I can actually smell the victory that's so tantalisingly close to being in my grasp.

I don't think having an unregretted attrition rate 'target' is necessarily a bad thing, but *if* you are going to go down this sort of route, then the "hiring manager" and the "firing manager" should be working to competing objectives, and not colluding in this way. The hiring manager could, for example, be incentivised to meet a lower UAR rate than the firing manager, and the decision to fire should be made based on some sort of objective measure which is difficult to game without actually impacting productivity (Maybe a metric which is hard to predict by virtue of being complex, compound and nonobvious -- which sounds like a perfect fit for a neural network of some sort -- of course, this seems all perfectly horrendous and dystopian - neural networks trained to decide who to fire? ... creepy.)

Ooooh! Thank you!

Is there anything similar for Python?

There are multiple ways we can frame the solution to this. Other developers (all of whom are much more capable than I am) have attempted to address this problem by designing new languages, or by designing new development environments. (Eve, LightTable, SmallTalk etc..).

It seems to me right off the bat that the nature of the visualisation required is very much an application dependent thing, making it hard to design a general-purpose solution for any but the most trivial of use cases. Secondly, moving to a new programming language (or even a new development environment) is not something that most of us have the freedom to do in our daily work, and overcoming that inertia is a real challenge.

The vision is, however, compelling enough for us to persist. Besides, giving up is never something that I like to countenance. Perhaps there's an easier and quicker way?

Dynamic languages like Python (and anything else with an 'eval') certainly offer the ability to reload program logic on the fly, and it's not terribly difficult to monitor the file-system and trigger re-loading functionality when it changes. Couple this with a data flow framework that guarantees determinism (e.g. a Kahn Process Network), and you've got the beginnings of something that can run and re-run chunks of program logic and compare the outputs. Couple this with some nice building blocks for program-state introspection and visualisation ... and I think you get a significant distance of the way towards the vision of interactive, dynamic, graphically rich (and distributed!) programming.

I.e. rather than looking for a panacea or a magic bullet, we can just try to use the tools that we have today to get as close as we can to the vision that so many of us share.

I wrote a Python library for model based systems engineering, because existing tools (e.g. Simulink) don't coexist nicely with mainstream version control systems, and don't generally have such a nice interface for system level meta-programming and design optimisation.

My friends also have this electric propulsion startup:- https://www.radpropulsion.com/

I've been working on something somewhat related. Would be happy to have a chat if you like.

I've experienced an abusive boss exactly once in 20 years of industrial experience.

DOTS is not ECS. "Unity Classic" is ECS. DOTS is a more cache-efficient architecture designed to support larger numbers of entities.

It seems to me that this precedent potentially kills off a big chunk of the ad-supported app economy.

How are investors reacting to this?

The truth is that human beings need a huge amount of investment - time, money and love - to get us to the point where we can function effectively - and once we fall off the train, it can be nearly impossible to climb back on again.

Human misery is a systems problem.

Perhaps the most productive way of tackling it will be to bolster and expand the mechanisms which enable people to avoid poverty and homelessness. E.g. helping a recently-redundant person quickly find another job, or giving someone at risk of becoming homeless another three or four months of breathing room so they have a chance to turn things around.

It's not just about financial support, either. Social, emotional and psychological support is essential, as it's so incredibly hard to keep a clear head when you are in distress.

Another alternative is building both up and down. Taller buildings for more residential space, and buried infrastructure for more room at the surface. Planning regulations need to acknowledge this reality though.

This is the fundamental design flaw of the system.

Fixing it isn't going to be easy, though. Look at the amount of effort that the scientific community tries to put into improving the quality of communication:- peer review, standards for content ... and there's still nagging issues with reproducing results and even outright fraud in some cases.

Whatever solution we come up with will likely increase friction in the user experience, but there's lots of room for innovation here.