mpweiher

And 2 electron apps.

I think the idea is correct, but hard to retrofit, you sort of have to have it there from the start.

Objective-Smalltalk runs on the Objective-C runtime, so Objective-Smalltalk methods look like Objective-C methods accessed via objc_msgSend() to the entire rest of the system, including to other Objective-Smalltalk code.

That means it doesn't really matter to the rest of the system if any particular method is interpreted, AOT-compiled or JIT-compiled. They can't tell, except for execution speed.

And of course the execution model includes machine primitives, which the interpreter also deals with but doesn't make faster, but the native compilers do.

I think you may have missed the main findings:

• Stereotypically feminine sentences are consistently attributed to female writers.

• Stereotypically masculine sentences are often attributed to female writers.

• Forms of violence central to the gender parity debate are deemed less acceptable than objectively worse forms of violence.

• Inclusivity efforts may have generated unintended forms of discrimination.

They don't have to "compete" with Starlink. They just have to provide similar capabilities.

And Ariane used to be the dominant commercial launch vehicle, beating the US alternatives by a mile.

There is also Eutelsat Web with > 600 satellites in place.

https://en.wikipedia.org/wiki/Eutelsat_OneWeb

And Iris2, with launches to commence in 2029:

https://defence-industry-space.ec.europa.eu/eu-space/iris2-s...

https://en.wikipedia.org/wiki/IRIS²

They are:

https://www.techradar.com/phones/network-providers/europes-m...

And Europe can get things done if it wants to. Ariane had reached 50% of commercial GTO launches in 2010.

...the Arianespace consortium "all but invented the commercial launch business in the 1980s" principally "by ignoring U.S. government assurances that the reusable U.S. space shuttle would make expendable launch vehicles like Ariane obsolete.

https://en.wikipedia.org/wiki/Space_launch_market_competitio...

SpaceX has disrupted that, but once the innovation is out there it can be replicated.

Possibly relevant:

The experiment in designing a language that resembled natural languages (English and Japanese) was not successful. -[1]- William R. Cook, AppleScript, HOPL IV

Now our new LLMs are different, because they don't use "language the resembled natural languages", but actual natural language. But the lesson is instructive nevertheless, because it gives us some empirical evidence to compare to Dijkstra's theoretical arguments.

And this is that natural language is at best a two-edged sword. Yes, there are benefits, but there are also huge drawbacks. And one problem is that the benefits are front-loaded and the drawbacks are long-term problems.

To me, one thing we are missing is that what LLMs do for us actually has 2 parts.

1. It allows us to use natural language, allowing us to be fuzzy.

2. It allows us to specify what we want at a much, much higher level than usual.

With our LLMs, these two are intrinsically linked. I think the whole would be much, much more valuable if we could separate them.

[1] https://dl.acm.org/doi/10.1145/1238844.1238845

Ports are a general feature of components in the software architecture literature (and corresponding systems).

In addition, connectors also become structured.

Objective-Smalltalk uses polymorphic connectors to adaptively and mostly automatically choose the level of granularity you want to operate at.

https://dl.acm.org/doi/10.1145/3689492.3690052

---

That aside: really cool article! Dataflow just pops up everywhere as a really, really useful abstraction, and our languages don't support it well as a general mechanism.

Instead we tend to have specialized dataflow-y tooling for one area of programming where the advantages are so significant that the impedance mismatch is worth it nonetheless.

> any classical C style programming will segfault as in plain C.

As I wrote, you wrap those in an Objective-C container that manages that pointer, and delegate the C access to that container.

So not:

    c_pointer = [container getPointer]
    <munge on pointer>

But rather:

    [container doSomeMungingOnYourCData];

Which is, of course, how you should be doing things in OO style anyhow. So that works out just fine.

But yes, some people do insist on doing things the hard, slow, nasty way. They get punished.

'tsAll Goodman.

I don't think "non-determinism" is the right metric.

Unpredictability is.

I can have a process that is formally 100% deterministic, but that doesn't help me if I have no clue as to what inputs produce desirable outputs.

And it's not that unpredictability isn't bad enough as is, but with an AI it might produce something great, and it might ... not.

And as long as we don't want to touch the code, that same unpredictability is also in any mitigation measures.

When there is some level of predictability in my mitigation measures, I have some confidence that they will eventually converge.

When there isn't, I don't. Doesn't mean that it can't or won't. Just that my ability to get it to converge is at best limited.

Hmm...these are the primarily military reactors I was referring to, even if they also produce some electricity. At that point, France had a military nuclear program.

The civilian nuclear program started in earnest in 1974 with the Messmer plan, and that was based on the purely civilian Westinghouse reactors I mentioned.

> not null-checking properly,

Fortunately, the run-time does this for you: it ignores messages to nil.

And the framework provides container objects for "bags of bytes": NSData.

So it is actually surprisingly hard to dereference a null pointer, and surprisingly easy to avoid mechanically without being perfect.

Just make sure that you delegate any manipulation of raw data to methods of the object holding the data.

https://blog.metaobject.com/2014/05/the-spidy-subset-or-avoi...

While it is certainly possible to circumvent this if you put your mind to it, it is remarkably safe in practice.

This turns out not to be the case.

Like all nuclear powers, military use preceded civilian use in France.

In addition, the military actually pushed for a French-made dual-use reactor design for the civilian program, but instead a purely civilian Westinghouse design was chosen.

Objective-C is still a sweet spot for this, if you wield it right.

It can get you most of the Smalltalk (Python/Ruby) conveniences with most of C's speed. In fact, if you do it really well you can leverage them together to get better than both. Simultaenously.

Doesn't mean that people don't manage to wield it in such a way as to get all the convenience of C combined with the performance of Python/Ruby. Which always baffles me. You .... did .... WAT?

To me the Right Thing™ here always seemed the obvious and simple thing to do, as in: just don't spend extra effort to mess it up and you'll be fine. YMMV.

Plug: my book gives fairly detailed instructions on how to achieve the positive combination. [1]

Other plug: Making it easier to get this right is the 2nd of the four stages of Objective-Smalltalk. [2][3]

[1] https://www.amazon.com/Cocoa-Objective-C-Performance-Tuning-...

[2] https://blog.metaobject.com/2019/12/the-4-stages-of-objectiv...

[3] https://objective.st/

> The logic of "there could be bugs here, therefore it's safer to restrict it" ends in an empty safe subset.

What Alan Kay called "the Wirth school of non-programming".

"...for running untrusted code (model output, ..."

Hmm...

> Even if LLMs would produce perfect, high quality code all the time,

Microsoft just introduced MXC:

"...for running untrusted code (model output ..."

https://github.com/microsoft/mxc

You forgot: Objective-Smalltalk is the best, because Agents need architectural guidance to avoid turning your codebase to mush and Objective-Smalltalk lets you express the architecture (and its constraints) directly in the code.

It also allows for coding at a higher level, meaning that code is closer to the prompts.

Is it actually true? OF COURSE IT IS!!!

So no idea, but after long dismissing that idea precisely because it looks like a "just so" explanation for my obvious favorite choice I am starting to come around to the idea that it might just be true in spite of the obvious bias...and definitely worth testing.

https://objective.st

QED.

> If you lay it out like that, does it make what you say more true?

No.

It was just as true before as it is after.

> You were the one using that phrase.

I was using that phrase to describe what people were doing. Do you understand the difference between doing something and describing that thing that people are doing?

>> I did not present the Google answer as "the truth". I presented it only as what it is: "what Google said".

> Oh baloney.

That is literally what I wrote: "Because I sure couldn't find any. So I asked Google. This is what Google said:"

Again, if you can't tell the difference between "this is what Google said" and "this is the truth" then that is most definitely a you-problem. On three levels:

- first, they are literally and undisputably different words.

- second, believing that those two different sets of words mean the same thing is..."interesting".

- third, even if you yourself believe that these words mean the same thing (which, again, "interesting"), assuming that others partake in that interpretation is at best presumptuous.

That would an incorrect conclusion.

As I wrote before: your "claims" are largely just your opinions, some misunderstanding/misinterpretation of the relevant information, but most importantly they are irrelevant.

And I won't engage in your Gish gallop.

Of course, you could have understood that the first time I wrote it.

But feel free to further demonstrate your lack of understanding.

Your call. ¯\_(ツ)_/¯

1. If what you claim were true, if LLMs represent "what people are saying" it would still mean that the claim people here were making about "what people are saying" is false.

2. What you claim is false. The processes are quite different.

3. I did not present the Google answer as "the truth". I presented it only as what it is: "what Google said". In the context of "I couldn't find any online corroborations of the previous poster's claims".

If you confuse "this is what Google said" with "this is the truth", that's a you-problem.

4. What can be asserted without evidence can also be dismissed without evidence. -- Hitchen's Razor https://en.wikipedia.org/wiki/Hitchens%27s_razor

The claim that ABWRs are "unprofitable" has now been asserted several times without any evidence whatsoever. Therefore, the only thing I actually have to do to dismiss that claim is say "wrong".

I am not going to participate in your Gish Gallop.

If you answer on point to the point, we can have a discussion.

Otherwise: gish along...

So you figured out this glaring hole in their plans that all the idiot companies doing SMRs missed?

Maybe not.

For example, Aalo Atomics has split the construction process in such a way that the on-site pour that happens after the reactor is delivered from the factory is (a) very simple (b) standardized, and (c) non-nuclear. In addition, the site work that is required is very repetitive, so you get a positive learning curve, again without the slowness of nuclear construction.

Copenhagen Atomics has heavy thorium salt shielding inside the nuclear core and a "Cocoon" that is delivered in 12 prefab parts installed on a regular concrete pad. So on-site construction is making the non-nuclear concrete pad, installing the pre-fab cocoon on pad and then placing the reactor core inside the Cocoon.

Westinghouse apparently ships the entire eVinci microreactor pre-assembled with shielding.

X-energy puts the reactor in a hole underground.

etc.

That also is almost entirely untrue and has virtually nothing to do with your original claim.

> whether they'll be able to hit their 12-18 month licensing approval goals.

The very license TFA is about took 14 months.

The NRC completed its review in 14 months—four months ahead of schedule—after concluding that TVA’s application met applicable safety requirements.

https://thebreakthrough.org/press/release-the-nrc-approves-c...

You need to take into account

a) backup/firming, both day/night and seasonal.

b) lifetime of plant.

c) land use.

When looking at costs, you have to also take into account the lifetime of the plants.

The current US plants are all getting extensions to 80 years of operation, and experts see no problems with going to 100.

How many times do you have to fully replace the panels in that timeframe?

How many times the batteries?

And what about seasonal storage?

What you did there has nothing to do with logic.

Something not being 100% certain does not imply the opposite being 100% certain.