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

My Swift Dilemma

owensd.io

Post reply on HN
Print view View original

81–90 of 129 posts

Re: My Swift Dilemma

#81

Post by lerno »

dkarapetyan wrote: post #71
lerno wrote: post #26

Earlier quoted context omitted.

If you had followed what Owens has written and done in Swift, you know that he has worked and pondered the language quite a bit. Dismissing it as due to "blub" is disingenuous. Aside from brushing away the value of his opinions, such a statement also implies that Swift is in some way sufficiently removed from mainstream languages as to feel "foreign". That is not true. Swift is a pragmatic amalgam of features from ma…

When it comes to programming language reviews I don't think there is any value in them regardless of who is doing the review. Steve Yegge in one of his epic posts explains why everyone should design a language from scratch to see what the process is like. Once you do that the magic and wonder disappears and you realize both how hard and easy it can be depending on what constraints you have. Here's a nice starting poi…

You're the one who evoked "blub", essentially insinuating that the reason for his inability to appreciate the language was due to him not being used to it.

I addressed that, and your counter with that it's "hard to make a programming language"?

Of course it's hard. And the problem with Swift is that it tried to do so many things at once, even with the hard constraints it had. And this is precisely why the language ends up short of its goal.

Speaking of ObjC 3.0, the point of the author is simply that an incremental improvement on ObjC which simply removes redundant syntax from ObjC would have been just as useful but much easier to get up and running.

The features that Swift tries to incorporate are admirable and interesting for the most part, but the implementation falls short because it's quite simply too ambitious to even reach "usable" until 3.0 or something.

Re: My Swift Dilemma

#82

Post by lerno »

the_af wrote: post #75
mpweiher wrote: post #66

Earlier quoted context omitted.

Post https://news.ycombinator.com/item?id=8367012 suggests that it is actually Swift that is the Blub language...

That doesn't suggest Swift is a Blub-like language to me. Though not explicitly stated in the Blub paradox, I'd say it implies that a fresh programmer, unfamiliar with both Blub and the more advanced language, would pick the more advanced language. The Blub paradox doesn't automatically apply to every language whose syntax you find bizarre. It also has to be a more advanced language, and the reason that you don't lik…

No? You've never ever heard Java/C++ programmers complain about ObjC's syntax? I find that... unlikely. http://bit.ly/1CqrYY4

Re: My Swift Dilemma

#83

Post by lerno »

aclissold wrote: post #58

The author fails to realize one critical thing—that the imaginary "Objective-C 3" language he wants requires intentionally breaking the fact that Objective-C is a strict superset of C… exactly what Swift has done.

I think you misunderstand then. I think he's all for a new language, the problem with Swift is that it's not quite the language he hoped for.

Re: My Swift Dilemma

#84

Post by lerno »

bsaul wrote: post #21

My take on swift : use it once apple release a real product made with it.

I got a request to share my project (15k LOC) with the compiler team because they had no larger projects to test on. This was less than a month ago. Draw your own conclusions on how much Swift has been used internally at Apple. Oh, and compile times for any change in that project was 50-60 seconds. That's a minute for changing a single character in one of the Swift files.

Since they don't seem to be scrambling to fix that problem, I can only assume that there's no urgency internally at Apple to fix it.

Re: My Swift Dilemma

#86

Post by lerno »

bsaul wrote: post #31
antimagic wrote: post #23

Earlier quoted context omitted.

Which is fair enough, but if you look at the amount of effort they are putting in to bring Swift's documentation / tooling up to speed, it seems pretty obvious that Apple themselves have high ambitions for the language. Also, it's going to be hard to tell how much Swift code is being shipped by Apple - the interfacing with existing Obj-C code is sufficiently clean that it's relatively simple to have parts of a produc…

I recently learned that core data wasn't used internally at apple. That freaked me out, because it made me feel that choosing that technology for a serious project was a mistake, despite the numerous documentation and support apple provides for it.

I don't understand why people use Core Data. The sweet spot for Core Data is really tiny, yet everyone seems to be using it (and regretting it).

Re: My Swift Dilemma

#87

Post by the_af »

the_af wrote: post #72
zvrba wrote: post #69

Earlier quoted context omitted.

> For example, it fails to tell apart addition from the constant function 7. Right. But how would you test for the addition function without exhaustive O(N^2) search over the whole input space? (You need to test for commutativity; if you're going to test for associativity, it grows to O(N^3)).

My comment was in the context of the "unit tests vs type systems" debate. It was meant to illustrate my opinion that "more general" is better than "specific values" when testing, as much as is practically possible. I'm aware that addition is a toy example, but suppose we want to test our implementation: Except for very simple verification, to exclude obviously broken implementations, I'd rule out testing specific val…

Downvoter: out of curiosity, which part of my post did you disagree with?

Re: My Swift Dilemma

#88

Post by the_af »

dragonwriter wrote: post #73
the_af wrote: post #72

Earlier quoted context omitted.

My comment was in the context of the "unit tests vs type systems" debate. It was meant to illustrate my opinion that "more general" is better than "specific values" when testing, as much as is practically possible. I'm aware that addition is a toy example, but suppose we want to test our implementation: Except for very simple verification, to exclude obviously broken implementations, I'd rule out testing specific val…

> The tools that I'm aware of that can do this (such as QuickCheck or ScalaCheck) come from statically typed languages, though I don't see why they couldn't be used with dynamically typed languages. The tools use type information to determine the universe to draw test values from and the mechanism used to do it. You can actually do something very similar for dynamically typed languages, but if you don't have queryabl…

You are right, without additional information property testing would be less useful. Which is yet another reason to favor static typing in my opinion.

Re: My Swift Dilemma

#89

Post by the_af »

lerno wrote: post #82
the_af wrote: post #75

Earlier quoted context omitted.

That doesn't suggest Swift is a Blub-like language to me. Though not explicitly stated in the Blub paradox, I'd say it implies that a fresh programmer, unfamiliar with both Blub and the more advanced language, would pick the more advanced language. The Blub paradox doesn't automatically apply to every language whose syntax you find bizarre. It also has to be a more advanced language, and the reason that you don't lik…

No? You've never ever heard Java/C++ programmers complain about ObjC's syntax? I find that... unlikely. http://bit.ly/1CqrYY4

Yes, I've heard it many times.

How is that a counterexample? Bizarre syntax alone is not enough for the Blub paradox. I don't know anyone who seriously argues that Obj-C is a more advanced language than Java/C++, so Blub doesn't apply.

Re: My Swift Dilemma

#90

Post by yen223 »

the_af wrote: post #78
yen223 wrote: post #18

Earlier quoted context omitted.

My favourite part was the whole "Optionals suck because Obj-C have nil, therefore Obj-C is superior" bit.

Except for the "therefore Obj-C is superior" part, I agree that Option types in languages such as Swift and Scala are unfortunately marred by those languages' need to be compatible with Obj-C and Java, respectively. I understand idiomatic Scala won't use null , just as I assume idiomatic Swift won't use nil , but nevertheless the fact that they allow nulls weakens their type systems.

That's one of the benefits of Rust imho - no legacy baggage. One of its downsides as well - no ecosystem to draw from. Oh well, take the good with the bad I guess.
Post reply on HN