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

Swift Regrets

belkadan.com

Post reply on HN
Print view View original

171–180 of 207 posts

Re: Swift Regrets

#171

Post by bsaul »

selcuka wrote: post #127
bsaul wrote: post #76

Earlier quoted context omitted.

My impression following swift forums is that original core team members were very concerned about relying a lot on first principles, whereas the new generation is more about building powerful constructs, in a fast paced way.

The new generation doesn't seem to have a need for extracting substrings from strings then. The existing Swift syntax for slicing strings [1] is horrible. [1] https://www.cocoaphile.com/posts/string-slicing-in-swift

You can find a few extensions on stackoverflow that makes subscripting work with integers on strings. I'm still unsure why this isn't part of the stdlib..

Re: Swift Regrets

#172

Post by pjmlp »

gurkendoktor wrote: post #165
pjmlp wrote: post #160

Earlier quoted context omitted.

What can I say, lucky you. Now try the same with a couple of offshored projects from some famous consulting companies.

Fair enough, but I also don't see why we should judge languages based on the absolute worst projects written in them. For example, the offshore Swift programmers I've encountered will add "?? 0", "?? []" etc. into expressions involving optionals until they compile. That doesn't mean that Swift's nullability is pointless, it's still a great tool for diligent programmers.

I agree in principle, but that doesn't change the fact that such kind of code might land on an application I depend on for some reason.

Hence why I always advocate for better industry regulation, as I get to see how the sausage is made, and would like everyone gets more healthier.

Most managements don't care about diligent programmers, only delivery.

Re: Swift Regrets

#173

Post by mpweiher »

pjmlp wrote: post #152
mpweiher wrote: post #144

Earlier quoted context omitted.

It was really solved by reference counting, way back when Foundation was introduced. The ARC increment was tiny.

For Cocoa like classes, it did not solve anything else for the rest.

My stack-allocated integers don't need it.

Re: Swift Regrets

#174

Post by pjmlp »

mpweiher wrote: post #173
pjmlp wrote: post #152

Earlier quoted context omitted.

For Cocoa like classes, it did not solve anything else for the rest.

My stack-allocated integers don't need it.

Yeah, but those heap allocated structs surely do.

And although there is now partial ARC support for that scenario, partial is the keyword here, as it needs to obey specific access patterns to actually work.

Re: Swift Regrets

#175

Post by iainmerrick »

gavinray wrote: post #75
iainmerrick wrote: post #70

Earlier quoted context omitted.

I think it helps that C and C++ just work on iOS, so you can easily use or wrap existing code in those languages. Unless things have changed a lot recently, C/C++ sort-of-works on Android but it’s a pain to use and the tooling support is very weak.

There's a tool called "scapix" that's popped up recently that fixes this and is really impressive. It's zero-boilerplate (IE, don't need to manually write bindings like most tools) bindings from C++ code for both Swift/ObjC and Java. The idea being you can write C++ code and then consume it on both mobile platforms, making your life easier. https://github.com/scapix-com/scapix It also is really useful if you want to…

Sounds great, I’ll check it out!

I’ve always wondered why Google didn’t make something like this themselves. I assume the answer is that they just don’t care about native code, or at least native/Java interoperability.

Re: Swift Regrets

#176

Post by andrekandre »

novok wrote: post #44
jshier wrote: post #35

Earlier quoted context omitted.

It would be impossible to evolve Obj-C to add most of Swift's capabilities unless you drop binary and source back compatibility. At that point it's just another new language and you've lost the things you say made Obj-C simpler. I have a hard time believing any engineer is productivity bound by Swift's build times and especially indexing times, since indexing doesn't affect your ability actually write code. Typically…

I see you haven't worked in a swift code base that is more than a few engineers. Work in a project that is 20-80+ engineers and you slam into these issues very quickly. Last time I checked the inflection point starts around 100k lines of code. Also 'thinking' of solutions often involves writing something and then trying it out in a build-edit-run cycle, and then integrating your thing into a larger app context, which…

  > Last time I checked the inflection point starts around 100k lines of code.
if your using swiftui + generics for your view models, depending on what your doing, be prepared to hit that limit at around 2000 lines, and then your app wont even compile...

Re: Swift Regrets

#177

Post by mpweiher »

pjmlp wrote: post #174
mpweiher wrote: post #173

Earlier quoted context omitted.

My stack-allocated integers don't need it.

Yeah, but those heap allocated structs surely do. And although there is now partial ARC support for that scenario, partial is the keyword here, as it needs to obey specific access patterns to actually work.

But why on earth would I heap-allocate structs in Objective-C? That's what I have objects for. If I am going to dumb things down to structs, the reason is that I don't want heap allocation.

Unless I have no clue whatsoever as to what I am doing.

As in, I just wrote pure C (no Objective- at all) and for some reason changed the extension of the file to .m

Anyway, not using the solution that is there is not the same as the solution not existing, it certainly doesn't qualify as "the rest".

Re: Swift Regrets

#178

Post by andrekandre »

whiddershins wrote: post #111

So is Objective-C kinda going away after all? If I did a greenfield iOS or OSX app would it be malpractice to do it in Objective-C? Because I actually adore that language. Haven’t used it lately, but I do love it.

  > So is Objective-C kinda going away after all?
did c and c++ go away when obj-c landed?

(my guess is, obj-c will be the same: not the main one, but still around for where its appropriate)

Re: Swift Regrets

#179

Post by pjmlp »

mpweiher wrote: post #177
pjmlp wrote: post #174

Earlier quoted context omitted.

Yeah, but those heap allocated structs surely do. And although there is now partial ARC support for that scenario, partial is the keyword here, as it needs to obey specific access patterns to actually work.

But why on earth would I heap-allocate structs in Objective-C? That's what I have objects for. If I am going to dumb things down to structs, the reason is that I don't want heap allocation. Unless I have no clue whatsoever as to what I am doing. As in, I just wrote pure C (no Objective- at all) and for some reason changed the extension of the file to .m Anyway, not using the solution that is there is not the same as…

You "mpweiher" might not do it, but I assure you plenty of enterprise programming cogs do.

They code mostly in a C like way, and only use Objective-C at the level it is required to call into Apple specific APIs.

When using C++, then their code looks like what I call C+.

The same set of people that are to blame for Objective-C conservative GC never working in practice, when mixing Frameworks compiled with different modes.

Re: Swift Regrets

#180

Post by [deleted] »

iainmerrick wrote: post #70
dhritzkiv wrote: post #42

Earlier quoted context omitted.

Totally. To add to this: when looking for third party libraries (Swift/Objective-C or Kotlin/Android Java), aside from those from large organizations (Square, Airbnb, etc.), I've found the selection and quality of those available for iOS to be better, on average.

I think it helps that C and C++ just work on iOS, so you can easily use or wrap existing code in those languages. Unless things have changed a lot recently, C/C++ sort-of-works on Android but it’s a pain to use and the tooling support is very weak.

[deleted]
Post reply on HN