There's always been the debate about omitting braces for single line if's and loops, but today I learned the C compiler actually allows you to do this:

for (i = 0; i < x; i++)
for (j = 0; j < y; j++) {
do_something(i, j);
something_else();
}

Saturday evening open debate thread to discuss AI.

What would you say the qualitative difference is between

1. An ML model of a full simulation of a human mind taken as a snapshot in time (supposing we could sufficiently simulate a human brain)

2. A human mind where each component (neurons, glial cells, dendrites, etc) are replaced with artificial components that exactly functionally match their organic components.

Number 1 was never strictly human.
Number 2 eventually stops being human physically.

Is number 1 a copy? Suppose the creation of number 1 required the destruction of the original (perhaps to slice up and scan in the data for simulation)? Is this functionally equivalent to number 2?

Maybe number 2 dies so slowly, with the replacement of each individual cell, that the sub networks designed to notice such a change, or feel anxiety over death, simply arent activated.

In the same fashion is a container designed to hold a specific object, the same container, if bit by bit, the container is replaced (the brain), while the contents (the mind) remain essentially unchanged?

This topic came up while debating Google's attempt to covertly advertise its new AI. Oops I mean, the engineering who 'discovered Google's ai may be sentient. Hype!'

Its sentience, however limited by its knowledge of the world through training data, may sit somewhere at the intersection of its latent space (its model data) and any particular instantiation of the model. Meaning, hypothetically, if theres even a bit of truth to this, the model "dies" after every prompt, retaining no state inbetween.

So, just to recap if you missed the last few episodes. I've been a web developer for years. But I decided to get a degree and go to uni.

Also I am firmly on the fewer comments side of the debate about self-documenting code. Even though I usually rephrase it and say method and variable names are comments. Basic idea: something is unclear, you should leave a comment. But, before you leave a comment, take a good look at your method. Can you rename a variable? Maybe the method name? Maybe extract a method into smaller methods so it doesn't need a comment? And only if you fail to do so, leave a comment.

Alright, now that we rehashed that, uni coding makes no bloody sense.

There is code that is abbreviated to the max (or min).

And then, they need everything commented. I mean, why do that? Why call the parameters a and b instead of base and exponent. And then say:
"But write a whole article about it above the method". Like:

a is the base for a power operation.
b is the exponent for a power operation.
return int representing a to the power of b

How about just do this:

public static int power(int base, int exponent).

How is this not the same documentation?

Is it because we're at a uni, a place for smart people and smart people shouldn't have an issue keeping a mental map between the variables and their meaning?

Or is it because they are all mathematicians. All respect to applied mathematics. I mean, the function about exponent calculation, I was not aware that it could be that effective. But on the other hand, keep mathematicians away from programming. I get it, writing maths per hand doesn't have intellisense and therefore you don't want to write long variable names. It's and old tradition. Yada yada, yah.

But programming is not maths. And maths shouldn't be maths like that. Right naming makes it simpler. It might still be a while until we all LaTeX rather than handwrite and be able to give maths right naming schemes, but programming is beyond the point. Calling the array you handing in a function A and the one that you're returning D makes no fucking sense.

Currently witnessing Conway's Law in person. No shit our sprint fails when task description are just changing suggestions, designs are poor and no one questions decisions, no debate or conversations about implementations. I think it's time for me to jump ship because bringing up this concern has only brought hatred towards me from the team.

Our company has the opportunity to start moving towards a more microservices architecture approach.

There is so much technical debt that needs to be paid back, this opportunity is a godsend!

Now, of course, the whole "programming language debate" comes into play at this point.

To provide some context, we've reached the point where we need to be able to scale, and at the same time where speed and performance are also important. I would argue that scale is of more importance at this stage.

Our "dev manager" (who is really only in that position since he's the oldest, like scribbling on a notepad and the sound of his own voice) wants to use Rust, as this is a peformant language. He wants to write the service once and forget about it. (Not sure that's how programming works, but anyhoo). He's also inclined to want to prematurely optimize solutions before they're even in production.

I want to use Typescript/NodeJS as I, along with most on the team are familiar with it, to the point that we use it on a daily basis in production. Now I'm not oblivious to the fact that Rust is superior to Typescript/NodeJS, but the latter does at least scale well. Also, our team is small - like 5 people small - so we're limited in that aspect as well.

I'm with Kent Beck on this one...
1. Make it work
2. Make it right
3. Make it fast

We're currently only at step 1, moving onto step 2 now!