Live data from Hacker News

My Swift Dilemma

owensd.io

91–100 of 129 posts

Re: My Swift Dilemma

#91
post #83

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.

"It’s the syntactic sugar that makes the syntax modern, not the feature set within Swift itself. A cleaner ObjC could have done the same thing."

I think this statement is false—a cleaner Objective-C could be nowhere near as clean as Swift!

Re: My Swift Dilemma

#92
post #81

Earlier quoted context omitted.

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 en…

You're putting words in my mouth. I did not say "it is hard to make programming languages". It is a skill like any other that can be improved with sustained practice. My point is most of these conversations about the merits/demerits of languages are less than useless. Here's a programming language checklist http://colinm.org/language_checklist.html and another one about the history of programming languages http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m.... This post was just a variation of the checklist which indicates to me the author is not really interested in any kind of deep analysis of the language and is just publicly bitching and moaning. That to me is an indicator of the blub disease.

Re: My Swift Dilemma

#93
post #61

Earlier quoted context omitted.

Golang is an evolutionary dead end. It missed out on the last 25 years of language research. I'm following Rust more closely because it has new ideas for systems programming. Go has no new ideas.

Rust is interesting one. The only part I dislike is the pointer ownership. Can they work out a better model/analogy after 15 years of Boost?

Pointer ownership prevents memory bugs and concurrency bugs. When you have the combination of aliasing, mutability and concurrency is when you have all of these Heisenbugs. Rust attacks it from the angle of not having aliasing. You can have mutability and concurrency, but only one thread should have ownership of the thing being modified.

Re: My Swift Dilemma

#94
post #89
post #82

Earlier quoted context omitted.

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.

You should get around more.

Objective-C object-orientation via dynamic messaging is much more advanced/powerful than the Abstract Data Types available in C++ and Java. It enables such features as target/action, NSUndoManager, Higher Order Messaging, distributed objects...and their concise implementation.

If you don't understand dynamic messaging and see Objective-C as just a way of doing things that you would do in Java or C++, then I'd agree that it is less advanced at doing those things.

Blub.

Re: My Swift Dilemma

#95
post #83

Earlier quoted context omitted.

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.

"It’s the syntactic sugar that makes the syntax modern, not the feature set within Swift itself. A cleaner ObjC could have done the same thing." I think this statement is false—a cleaner Objective-C could be nowhere near as clean as Swift!

You have heard of Smalltalk? Remove the square brackets, remove the C. Squeaky clean syntax. http://squeak.org/

And now you have room in your language to provide actual innovation. See http:/objective.st/ for a start of what that might look like.

Re: My Swift Dilemma

#96
post #83

Earlier quoted context omitted.

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.

"It’s the syntactic sugar that makes the syntax modern, not the feature set within Swift itself. A cleaner ObjC could have done the same thing." I think this statement is false—a cleaner Objective-C could be nowhere near as clean as Swift!

Look at Eero for to how a simple updated syntax could look. On top of that, many of Swift's features could run on an updated ObjC as well. The problem is that the features that required a whole new runtime and compiler model are very few.

In other words, we could have gotten almost-Swift by building squarely on ObjC and would have avoided most of the runtime and performance issues that still plague the language. Plus it would have been a simpler language than Swift is.

Re: My Swift Dilemma

#97
post #53

Earlier quoted context omitted.

But tests test for specific values. Example: testThatAddWorks result = add( 3, 4 ) EXPECT( result , 7)

I know that's just an example and that you probably don't actually write tests like that in your day job, but it's a terrible unit test. For example, it fails to tell apart addition from the constant function 7. Even if you add more data points, you're still not testing addition. In a way, "testing for specific values" is very misleading. Consider that it'd be the wrong if you were actually trying to prove something.…

> it fails to tell apart addition from the constant function 7

It's not supposed to do that.

Have you heard of TDD? In a TDD/XP setting, the constant function 7 would be the appropriate implementation for making that test pass, because it is the simplest thing that could possibly work. Then you add another test, let's say add(40,2) EXPECT(42).

Now you could extend your add() function to do case analysis, and maybe in a first step you even do that. But then you refactor towards better code, and you replace the case analysis with actual addition.

For addition the steps are, of course, a bit contrived, because it is "obvious" what is supposed to happen. For production code the technique works really well in keeping the solution as simple as possible but no simpler. You probably wouldn't believe all the "obviously needed" code I haven't written because of it.

Another interesting benefit is that it splits coding into two distinct activities: (1) making the test pass as stupidly as you can and only then (2) making the code good by refactoring an existing solution.

Doing a good job of (2) is much, much easier when you are transforming a solution known to work and safeguarded by tests.

Also having just two test to induce addition may seem a bit sparse, and it is(!), but in my practical experience with TDD, I have been utterly surprised by how few concrete examples have been sufficient to safely cover potentially large spaces. Much fewer than I would have suspected or believed possible.

Re: My Swift Dilemma

#98
post #88

Earlier quoted context omitted.

> 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.

There are degrees of static typing. Swift tries to get close to Haskell, but without the full set of tools to do so without losing things along the way. This is sort of the worst of both worlds.

In the meantime Strongtalk already demonstrated that you can write a fairly rich optional type system to reap the compile time benefits of static typing while retaining the runtime power of message passing. I think that would have been more fruitful.

Re: My Swift Dilemma

#99
post #61

Earlier quoted context omitted.

Golang is an evolutionary dead end. It missed out on the last 25 years of language research. I'm following Rust more closely because it has new ideas for systems programming. Go has no new ideas.

Rust is interesting one. The only part I dislike is the pointer ownership. Can they work out a better model/analogy after 15 years of Boost?

Pointer ownership is the most important feature of Rust, and everything is built around it. The management of memory, auto-freeing of resources (a mutex unlocks simply when it goes out of scope). It also ensures that no piece of memory has more than one pointer which is mutable at any one time, allowing many optimisations that const in C++ does, but without actually having to annotate all your variables. You can also guarantee that a new thread shares no memory with another thread, preventing many types of race conditions. Goodbye to memory leaks, goodbye to buffer overflows, goodbye to use-after-free, goodbye to null pointer crashes.

Re: My Swift Dilemma

#100
post #89

Earlier quoted context omitted.

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.

You should get around more. Objective-C object-orientation via dynamic messaging is much more advanced/powerful than the Abstract Data Types available in C++ and Java. It enables such features as target/action, NSUndoManager, Higher Order Messaging, distributed objects...and their concise implementation. If you don't understand dynamic messaging and see Objective-C as just a way of doing things that you would do in J…

Where is a good place to learn about this style of OO?
Post reply on HN