@Lensflare Re: ObjC abomination

I did not find it quite so objectionable. I was forced into it for a project and while it felt like leaving a 6-speed sports coup w/ racing clutch to drive a 4-door Mercedes; it was at least a Mercedes I guess🤷🏻‍♂️.

Apple did their best to restrict drifting (so to speak) but I found ways to mod my ride without risk of malfunction. I found I could have a very full personal library that crossed assembly, C, C++ and ObjectiveC. But with Swift, I am at the complete mercy of Apple, and all the hype, or so it seems.

@iiii I had ObjectiveC shoved down my throat but it was not really horrible... just pointless. C++ and multiple inheritance was so much more powerful but...

So I would agree... different for the sake of being different is not better. A treatise of Apple engineering that they clearly do not observe.

Next we delve into the folly of closures!

@Lensflare *sigh* this has nothing to do with booleans and evaluation to false/true.

Exactly my point. "if" is therefor inappropriate.

@CoreFusionX so you are telling me that nil is real? Please do explain how this works at the machine level, given that you say I am wrong... there must be some kind of "no value" that you can put into a CPU register? Please do enlighten me.

@Lensflare @lorentz re: try COBOL or FORTRAN:

I happen to be conversant in FORTRAN :-) as well as a number of other non-data-processing languages. I don’t think you meant COBOL as it is more like Swift than it is like FORTRAN.

Scripting languages are not my source of comparison but it seems that Swift is more like a scripting language than an actual engineering language. 🤷🏻‍♂️

But Apple says we can do bare metal firmware with it so we will see! I will be surprised if it achieves anywhere near the efficiency of something like C or C++ as Swift seems to require much more scaffolding in its attempt to hide the machine… even the lighter scaffolding in ObjC made it unattractive for actual embedded work. 🧐

@lorentz not about skipping over tokens, it is about consistency in defining a language and readability without inferring invisible operations.

It is “if something is true” or “if something is false”. It is not “if this operation was successful by some definition within the operation itself” operator.

My foundational logic is “exceptions are bad”. So having “if” operate on Boolean and then mean if not nil by adding “let” is by definition an exception to the definition of “if”

@lorentz Re: not what happens in Swift at all. "if let" is _defined_ in terms of optional.

Doesn't that obfuscate things?

Consider that:

if( bool x = y ) {/* */}

means:

1. define x for the {/* */}

2. set x to y's value

3. if x is true then execute {/* */}

but in swift...

let y: Bool? = true

if let x = y {/* */}

would visually suggest the same thing but because of the overloaded meaning of "if", it becomes self-undocumenting.

instead it could have been:

iflet x = y {/* */}

to clearly indicate a new interpretation. AKA, it is neither a common "if" (which operates on boolean values) nor a common "let" (which can include a type...)

But to make it more readable it could have at least been:

when let x = y {/* */}

To try and differentiate from standard "if" using a boolean in generally *every* *other* *language*.

"when let" would require two whole extra characters tho! 😱

@BordedDev Re: Also := will be colon equals

or ... we call it SKYRIZI!

(sorry, the 14 yr old still lives inside)

@lorentz I also don't see why either is bad form

Think of this.. it's not uncommon to see C programmers do this...

if( ptr ) {/* */}

- technically exercises the knowledge that 0 is the definition of "false" at the machine code level & any other value is "true". It translates to "if the pointer is not nil then".

But it relies on a side effect of the C language at the time. There is no guarantee that in the future version of C won't define 1 as true and 0 as false and the such code could then have an "undefined" in the conditional.

In reality, it should be:

if( ptr != NULL ) {/* */}

- which is self documenting ;-)

This parallels Swift which **assumes** that "nil" is false in the

if( let x = y ) {/* */}

as the let x = y executes and leaves behind the x as in:

let x = y

if( x != nil ) {/* */}

and this discretely performs a legit boolean check, is truly self documenting, and is easily debuggable.

@lorentz Booleans are exactly as real as optionals too

I have not run the Swift construct down machine code or assembly yet, but the thrust is that optionals don't exist at the CPU level... the computer's machine code. It takes extra multiple lines of machine code to implement such a concept. A boolean in C is nothing more than a compare to 0 or not zero when it hits assembly. Exceptionally efficient down to the CPU cycle per machine code instruction level.

I have not investigated booleans in Swift at the assembly level yet, but what you said about booleans in Swift makes me apprehensive at an OCD efficiency level. 😱

@atheist fun fact, ALGOL is where ":=" started and it was popularized by Pascal circa 1970.

While I think it is kinda cool it is called the walrus operator, it is pronounced "set equal" where the colon is where the hands of the sprinter are on the track, the = is where the sprinter's feet are. Ready "set" go.. hence ":" is the "set".

Goo goo g' joob?

@kiki Re I only like common swift

Have to agree, lovely.

@iiii Re: What's wrong with C and C++ to be using Swift of all things?

My C conventions have carried through C++ and ObjectiveC. If I am going to convert them over to Swift, I would rather not try to maintain them in two very different languages, especially one that does not generally allow you to use pointers / hardware addresses

@Lensflare actually it technically (with plenty of thorns) does embedded. I'm adopting it to bare metal coding for a hardware project. It is no easy task and definitely shows the insanely buggy nature of Xcode... but it is in theory a generic IDE that executes against external tool chains.

(what?! Xcodesucks sticking up for Xcode? Sign of the apocalypse; what's next? dogs and cats living together?)

I feel your pain...

Swift is... inconsistent at best

lets just say that I did not have to put "func" in front of a method or function since Pascal and then it was either "procedure" or "function". Why on earth would a "modern" language revert to such primitive style?

But to add insult to injury, the inconsistency is that you only put 'func' in front of some methods in a Class but not all.. e.g. not in front of init(), deinit().

"func"? We don't need no stinkin' "func"!

@Lensflare Session: "Meet Liquid Glass" would have had a standing ovation if it were I person. 😉

@Lensflare In my experience command-click or option-command-click does not always work. Nothing happens for instance when command-clicking on "padding". Xcode Does suck you know... 🤣

@Lensflare Digging through AI interaction on why that line causes the obscure error output, it very clearly pointed out that the reason the assignment could only be performed during declaration is because Swift functionally converts the "var" to a "let".

Here is some fun.. figuring out what owns what...

put self in front of ".padding" like this:

self.padding( .horizontal, 20 )

It builds easily and runs and then shits its pants 💩👖 with

Thread 1: EXC_BAD_ACCESS (code=2, address=0x16f17ffd0)

In some thread that I did not create.

"safe" seems to mean "no pointers" and I guess nothing else. I guess any car without a stick shift could be called "safe" by that sort of logic. (Swift == Hype)

@Lensflare Re: give me an example? ... not enough space available?

small memory models in any firmware force disciplined use of resources. Firmware in your TV, in your refrigerator, in your smart lightbulb, your ring doorbell, your AirTag, your USB-C or Thunderbolt cable.

Most of the computers out there have tiny memory models. (just count your cables, subtract your laptops, desktops, phones and iPads, there's your minimal "most")

Apple just advertised Swift Embedded last year for the ESP32C6 system: https://developer.apple.com/videos/... and then doubled down this year telling us they are using it in Secure Enclave Processor found in their devices (this could be a major fuckup). Be aware that the ESP32C6 is fairly bloated for an "embedded" system; try to fit that into the lightening cable head! (LMAO)

@lorentz

Re: By that definition there aren't any safe languages

Yep, nailed it. No such thing as a "safe car" either. Safety is always the responsibility of the driver. Discipline is key.

Re: so safety as a concept can only apply to end-user software.

Nope, not at all. My shit has been running for over a decade, no crashes.

RE: Software that can't crash can be written in Swift relatively easily like any other by-value language, by avoiding the heap

Beg to differ. Avoiding the heap has nothing to do with no-crash software or firmware. You can blow out a stack easy enough. There is no such thing as "infinite memory". Managing your memory like a BOSS has everything to do with no-crash software.

@Lensflare Kudos to you for going literal and noticing the 'int'. I suspect my cranky side put 'int"' into the malloc().

I just listened to another WWDC25 session, the one on Improve Memory Usage and Performance with Swift. It feels like the problems I pointed out are known to the team but they may be in denial.

@12bitfloat @12bitfloat, I firmly believe that crashing a program is never acceptable or safe.

Imagine your steering column is drive-by-wire, a common feature in many cars today, and it’s written in Swift within the car’s firmware. Now, imagine if the software crashes.

Consider the scenario where your mother is on a ventilator, and its firmware is written in Swift.

What if the code for the predator drone was written in Swift?

I'm not sure when it became "ok" for an app to crash but I'm not likely to ever be "ok" with it. Crashing app means shit-code, just that simple.

@Lensflare

Ok, show me how to do this in Swift:

int *ptr =NULL;

ptr = ( int * ) malloc( sizeof( int ) );

if ( ptr != NULL ) {

// Allocation succeeded, use ptr

}

else {

// Allocation failed, handle error

printf( "Memory allocation failed.\n" );

}

Because god knows that memory is tight in a Thunderbolt connector head...

@Lensflare how about the basics. When Swift fails to allocate memory, there is nothing to check, not like a null pointer to check or even a 1984 (OSError) MemError(void) function to call… things just go sideways; software crashes.

Accordingly it doesn’t sound like a good idea to use Swift in things like automobile software, medical ventilators, X-ray machines, CT scanners, aircraft software, navy ship software, nuclear missile software, drones, SpaceX rockets, and so on.

@lorentz Seems like every board requires a ton of library support that you need to hunt and peck around to find. Hours of just getting "hello world" to compile and link in many cases.

@BlazeStorm91 as hypocritical as it sounds, I'm trying to create a system of using Xcode with this and get rid of the Arduino IDE. If I can't step through debugging code, I want to ditch it with a vengeance.

the lesson learned here is make sure you copy the content before accessing the mouse in any web-edit. Web editing is always risky compared to editing in a real app. 😉

Developing political software? No? Maybe does not belong on DevRant.

@Grumm It used to be that there was a data fork and a resource fork, or just one of the forks. It really worked well, especially the resource fork which was a binary precursor to .plist files. Elegant actually. But when storing such on Windows servers, in Windows you saw both file forks. Nothing was "invisible" on either side. Invisible files were a rarity. Now it's like the file system has STDs everywhere in the form of invisible crap.