Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Closing this as we are no longer pursuing Swift adoption

github.com

Post reply on HN
Print view View original

271–280 of 332 posts

Re: Closing this as we are no longer pursuing Swift adoption

#271

Post by alwaysbeconsing »

PaulDavisThe1st wrote: post #167
bunderbunder wrote: post #156

Earlier quoted context omitted.

It is, and that’s part of what I loved about it. But it’s also the kind of trick that can quickly become a source of chaos on a project with many contributors and a lot of contributor churn, like we tend to get nowadays. Because - and this was the real point of Dijkstra’s famous paper; GOTO was just the most salient concrete example at the time - control flow mechanisms tend to be inscrutable in proportion to their p…

I don't really want to defend method swizzling (it's grotesque from some entirely reasonable perspectives). However, it does work on external/3rd party code (e.g. audio plugins) even when you don't have control over their source code. I'm not sure you can pull that off with "better" approaches ...

Problem come when a third-party code do that swizzling, looking at you every iOS analytics framework to this day.

Re: Closing this as we are no longer pursuing Swift adoption

#272

Post by ifwinterco »

nottorp wrote: post #244
ifwinterco wrote: post #223

Earlier quoted context omitted.

There's already a stereotype that Rust people will just carpet bomb any discussion with aggressively promoting Rust, people expect it to happen at this point and it just annoys people. So I think it probably meets the threshold of "toxic", but more importantly - it's not effective. Everyone and their dog has already heard of Rust, aggressive proselytising is not going to help drive Rust adoption, it's just pissing pe…

It's probably the same people who were proselitysing blockchain and now are proselytising "AI"?

I think that's more of a financial grift in a lot of cases (how many pie-eyed AI evangelists turn out to be running some "AI startup" or otherwise have skin in the game).

The rust thing is more like actual religious evangelism, like having Jehovah's Witnesses knocking on the door. They have seen the light and you haven't

Re: Closing this as we are no longer pursuing Swift adoption

#273

Post by librasteve »

zephen wrote: post #268
librasteve wrote: post #257

Earlier quoted context omitted.

Well sure - being in a rut is good. But the language is the medium in which you cast your idiom, right? Here's a Python rut: n = 20 # how many numbers to generate a, b = 0, 1 for _ in range(n): print(a, end=" ") a, b = b, a + b print() Here's that rut in Raku: (0,1,*+*...*)[^20] I am claiming that this is a nicer rut.

seq = [0,1] while len(seq) > I am claiming that (0,1, + ...*)[^20] is a nicer rut. If it's so fantastic, then why on earth do you go out of your way to add extra lines and complexity to the Python?

err - I cut and pasted the Python directly from ChatGPT ;-)

Re: Closing this as we are no longer pursuing Swift adoption

#274

Post by anonymars »

9rx wrote: post #263
anonymars wrote: post #189

Earlier quoted context omitted.

I think you are both unknowingly talking past each other: my understanding is that Smalltalk-style "object-oriented programming" ("everything is a message!") is quite distinct from C++/C#/Java/Rust "object-oriented programming" ("my structs have methods!")

Right, the former is what OOP is. The latter, encapsulating data in "objects", is functional programming.

They are both OOP, just as a "football" can be either spherical or oblong.

Functional programming is not "encapsulating data in 'objects'". Such a model would naturally feature methods like "void Die.roll()", "void list.Add(element)" which are definitely not functional programming (which emphasizes immutability, pure functions, composition, etc.)

Re: Closing this as we are no longer pursuing Swift adoption

#275

Post by 9rx »

anonymars wrote: post #274
9rx wrote: post #263

Earlier quoted context omitted.

Right, the former is what OOP is. The latter, encapsulating data in "objects", is functional programming.

They are both OOP, just as a "football" can be either spherical or oblong. Functional programming is not "encapsulating data in 'objects'". Such a model would naturally feature methods like "void Die.roll()", "void list.Add(element)" which are definitely not functional programming (which emphasizes immutability, pure functions, composition, etc.)

> They are both OOP, just as a "football" can be either spherical or oblong.

They are both OOP like a football can be something that you use in a sport and something that flies you to the moon. Except it is not clear what flies you to the moon goes by "football".

> Such a model would naturally feature methods like "void Die.roll()", "void list.Add(element)" which are definitely not functional programming

Exactly, functional programming. `Die` and `list` encapsulate data and use higher order functions to operate on it, which is what defines functional programming.

> which emphasizes [...] pure functions

Functions without encapsulation is imperative programming. If you introduce encapsulation then, yes, you have functional programming, just like your examples above.

Immutability is a disjoined property that can optionally apply to all of these programming paradigms. OOP, functional, and imperative programs can all be immutable, or not.

Composition and encapsulation go hand in hand, so that one is also functional programming, yes. And certainly composition is core to languages like C++/Java/Rust/etc. Naturally, them being functional languages.

To reiterate:

- Imperative programming: Data and functions are separate.

- Functional programming: Data is grouped with functions.

- Object-oriented programming: Data is grouped with message responders.

Re: Closing this as we are no longer pursuing Swift adoption

#276

Post by anonymars »

9rx wrote: post #275
anonymars wrote: post #274

Earlier quoted context omitted.

They are both OOP, just as a "football" can be either spherical or oblong. Functional programming is not "encapsulating data in 'objects'". Such a model would naturally feature methods like "void Die.roll()", "void list.Add(element)" which are definitely not functional programming (which emphasizes immutability, pure functions, composition, etc.)

> They are both OOP, just as a "football" can be either spherical or oblong. They are both OOP like a football can be something that you use in a sport and something that flies you to the moon. Except it is not clear what flies you to the moon goes by "football". > Such a model would naturally feature methods like "void Die.roll()", "void list.Add(element)" which are definitely not functional programming Exactly, fun…

You're welcome to insist that your definitions are canonical ("the objective in football is to kick the ball into the net"), but they are at odds with the rest of the thread

Re: Closing this as we are no longer pursuing Swift adoption

#277

Post by bunderbunder »

PaulDavisThe1st wrote: post #167
bunderbunder wrote: post #156

Earlier quoted context omitted.

It is, and that’s part of what I loved about it. But it’s also the kind of trick that can quickly become a source of chaos on a project with many contributors and a lot of contributor churn, like we tend to get nowadays. Because - and this was the real point of Dijkstra’s famous paper; GOTO was just the most salient concrete example at the time - control flow mechanisms tend to be inscrutable in proportion to their p…

I don't really want to defend method swizzling (it's grotesque from some entirely reasonable perspectives). However, it does work on external/3rd party code (e.g. audio plugins) even when you don't have control over their source code. I'm not sure you can pull that off with "better" approaches ...

That’s the main use case I can think of. It’s possible with other languages but may require more hacking.

I like monkey patching for testing legacy code. I like it less as a thing in production code because it can become a security and reliability problem.

Re: Closing this as we are no longer pursuing Swift adoption

#278

Post by zadikian »

jason_oster wrote: post #246
zadikian wrote: post #159

Earlier quoted context omitted.

It doesn't seem uncommon for someone to generally like Rust but still want to use something OO for UI. I'm in that boat. Never liked OOP much, but it makes sense sometimes.

Every "OO for UI" approach I've seen breaks most of the rules of object-oriented design. GTK, Qt, DOM, WinUI 3, Swing, Jetpack Compose, and GWT (to name a few) all provide getters and setters or public properties for GUI state, violating the encapsulation principle [1]. The TextBox/EditBox/Entry control is the perfect example. The impedance mismatch is that a GUI control is not an object [2]. And yet, all of the obje…

Right, in this context people are not taking such a strict definition of OO.

Re: Closing this as we are no longer pursuing Swift adoption

#279

Post by 9rx »

anonymars wrote: post #276
9rx wrote: post #275

Earlier quoted context omitted.

> They are both OOP, just as a "football" can be either spherical or oblong. They are both OOP like a football can be something that you use in a sport and something that flies you to the moon. Except it is not clear what flies you to the moon goes by "football". > Such a model would naturally feature methods like "void Die.roll()", "void list.Add(element)" which are definitely not functional programming Exactly, fun…

You're welcome to insist that your definitions are canonical ("the objective in football is to kick the ball into the net"), but they are at odds with the rest of the thread

Just as you are welcome to come up with other definitions. Although last time you tried they ended up being quite inconsistent, so one does need to be careful if you want them to be useful.

These definitions are not at odds with the discussion at hand at all. It was clearly stated that Swift has better OO support. Which is obviously true because it tries to be compatible with Objective-C, and therefore needs to have some level of OO support. That is something that Rust has no interest in doing, and rightfully so.

Your redefinition violates the claim, and therefore we can logically determine that it is not what was being used in the rest of the thread. That is, aside from the confused Rust guy that set this tangent in motion, but the remainder of this thread was merely clarifying to him what was originally intended. "He has a different definition for OOP" doesn't really help his understanding. That is what this thread branch has always been about, so it is not clear where you are trying to go with that.

Re: Closing this as we are no longer pursuing Swift adoption

#280

Post by gethly »

weedhopper wrote: post #266
ifwinterco wrote: post #222

Earlier quoted context omitted.

It is a genuinely strange social phenomenon. What is it about Rust specifically that attracts these people?

I think they are mostly just idealists. Found a perfect programming language that allows them to claim that everything else is wrong, and rust can solve every problem under the sun.

Just wait until they discover assembly!
Post reply on HN