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

Remove the ++ and –- operators

github.com

Post reply on HN
Print view View original

161–170 of 249 posts

Re: Remove the ++ and –- operators

#161

Post by dstanko »

cballard wrote: post #58
ra1n85 wrote: post #42

Earlier quoted context omitted.

"These operators increase the burden to learn Swift as a first programming language" It looks like they may be trying to make it easier for current tweens that would have otherwise learned PHP. Don't see the value in this. These operators are terse, well known, and are implemented in a wide array of languages.

Apple has a long history of readability over terseness. "plus plus" doesn't mean anything. It might even be confusing that it doesn't add 2 .

From Swift documentation:

for i in 0..This ..< operator is so much more logical, of course! Not to mention == and ===. Logically, the first one compares twice and the second compares three times (for luck), just in case first two comparisons didn't go through...

Re: Remove the ++ and –- operators

#162

Post by jakejake »

If there's some technical or performance reason for getting rid of this as far as the swift compiler goes, then I guess whatever just tell me how to increment a number and that's what I'll do.

But to try to say that x++ is complicated to understand? It's no more complicated than a lot of operations. I don't think anyone would intuit what x%2 means either. There are things that you can get just by looking at it, and others that you just have to learn once, then you go "oh, that's what it does" and move on.

Re: Remove the ++ and –- operators

#163

Post by mikeash »

mei0Iesh wrote: post #141
mikeash wrote: post #108

Note that if anyone truly misses these operators, you can add them back with a few lines of code. Swift has extensive support for custom operators, and if ++ and -- disappear as built-in operators, you can just implement them as custom operators. I see a lot of people complaining that they like ++ and -- who may not realize that they can still have it if they want it. I get that there are legitimate questions over wh…

That's good. Can you make anything? Like x+ is x+=1, x++ is x+=2, x+++ is x+=3? x+++++++++++++++++++++++++++++

Yep:

http://swiftstub.com/43404468

Obviously you should be careful not to commit such atrocities in any code that might ever see production.

Re: Remove the ++ and –- operators

#164

Post by TazeTSchnitzel »

springogeek wrote: post #127
filthydumbidiot wrote: post #45

Earlier quoted context omitted.

Judging by your capitalization, you must be of the BASIC school of aesthetics...?

It could be FORTH.

Or PHP, if they're one of those very few people who still writes it like that.

Re: Remove the ++ and –- operators

#165

Post by ScottBurson »

ridiculous_fish wrote: post #153
JoeAltmaier wrote: post #46

Removing ++ et al: ok, they have their problems. But retaining x += 1? That one has always annoyed me. Why does '+' (and friends) get this special form, but not my functions? Just because they're built-in. They are useful; no argument there. Largely because 'x' can be a complex reference, and you don't have to type it twice (and the compiler doesn't have to figure out that its the same expression twice). E.g. x=x+1 i…

In Swift, += is a separate operator from +, and is defined within the confines of the language. It's not privileged in any particular way: func +=(inout lhs: Int, rhs: Int) and you can just implement this. You might object that special forms are still privileged, e.g. foo[idx]+=1. But in fact these are not special: one of the surprising features of Swift is that inouts work on computed properties. For example, say we…

> Swift is the first language I've encountered that works this way; are there others?

Lisp, of course :-) Common Lisp's SETF and related macros work this way. E.g.,

  (incf (ldb (byte 3 5) x))
would increment the "byte" (CL's term for an arbitrary bit field) of width 3 at offset 5 of X.

INCF is defined in terms of SETF. Of course, the set of macros that can update a place is user-extensible. So if you wanted one that multiplies the value in the place by two, you could just write something like this (the trailing "f" in the name, as you might guess, is the convention for such a macro):

  (define-modify-macro doublef () (lambda (x) (* x 2)))
then you could call it like this:

  (doublef (ldb (byte 3 5) x))
to double the value in the bit field.

(EDIT: used lambda expression instead of helper function.)

Re: Remove the ++ and –- operators

#166

Post by throwaway999888 »

spc476 wrote: post #123
cballard wrote: post #23

Earlier quoted context omitted.

Yes. Anointing "+ 1" as a thing that needs special syntax is weird .

Not necessarily so if you come from a strong Assembly language background. Most processors have a special instruction for incrementing a register that's shorter (and faster) than the more generic ADD instruction. For instance, on a 64-bit x86 machine, ADD RAX,1 is nine bytes long, while INC RAX is one byte. Maybe not as much a win these days, but back when memory was smaller and more expensive, it was worth it.

Any optimising compiler for a mainstream language that can't do this optimisation reliably in this day and age is crap.

Re: Remove the ++ and –- operators

#167

Post by cballard »

Alupis wrote: post #157
cballard wrote: post #134

Earlier quoted context omitted.

This operator was popularized by C, so comparisons with C make sense. Of course you wouldn't remove pointers from C, the language would barely work if you did. Confusing C-isms like pointers are what Swift is trying to get away from. This is another case of that. "We're making a new language, it isn't C, but will share some characteristics. Which should those be?" is the question being asked here.

It seems to me, we're trying to make Swift "beginner-proof". The problem, Swift is unlikely to be a "beginner's language"... since it's predominantly (at least for now) an Apple language; used almost exclusively for making iOS apps. To make an iOS app, you have to have an Apple Developer license, be paid up on fees, own a very expensive Mac, and pay Apple to put your app in the store. None of which is something a beg…

It's less beginner-proof, and more "doing bad things proof". The purpose of releasing Swift as open source is that they don't want it to be an Apple language. I can't wait for it to replace Python for scripting - I dread every time I'm writing code without a competent type system.

> be paid up on fees

This isn't true anymore, FWIW. Also, OS X apps exist.

Re: Remove the ++ and –- operators

#168

Post by Nadya »

kuschku wrote: post #131
Nadya wrote: post #83

Earlier quoted context omitted.

Which type of keyboard do you use? I know English-International has a similar issue with `'`, `"`, and `'`. I think QWERTZ or a German keyboard do as well? Can try changing it to English - US to get around that if you run Windows. Not sure about Mac/Linux. I swapped the US out for international because it was important to me to type Pokémon properly. It is an annoyance to have to type ` followed by a space because it…

I use a bastardized DE1 layout, as provided by linux. So I have æ, but not å. Actually, I’m gonna switch to DE3. Still doesn’t solve these special characters.

I guessed the German QWERTZ properly at least...unfortunately I don't know a way of solving that without having an EN keyboard, using a keybind to swap between T1/EN as needed. Though depending how much German shows up in your programming... swapping every few characters probably isn't desirable either. :(

Re: Remove the ++ and –- operators

#169

Post by akira2501 »

isomorphic wrote: post #10
manaskarekar wrote: post #2

> Their expressive advantage is minimal - x++ is not much shorter than x += 1 Personal opinion, but I definitely miss '++' every time I'm doing '+=' in Python.

I think forcing me to use "+=" in Ruby reminds me that it's really a method call (which can be overridden), rather than an increment operation on primitive types.

And yet, ruby still provides 4 unary operators that can be redefined.
Post reply on HN