Curly braces

Why would anyone seriously want to use curly braces to denote scope? Surely significant indentation, or implicit scope based on the surrounding keywords, is far superior.

Also consider this: every time you wish to enter { or }, you must hold down the shift key. That is one extra wasted keypress per scopening and sclosing.

And it just looks messy, like a spastic has been scribbling nonsense all over your screen.

>>37
faggot :: String
faggot = "Oh, and semicolons are also fail, when we can\                                                                                                      
         \ do multiline statements with PROPER STRING ESCAPE CHARACTERS!"

PINNACLE OF OPTIMISATION

() replaces {}[];,.-> etc etc etc.  Keep it simple.

>>41
Whoops. Copying and pasting from gnome-terminal added an extra line.

>>40
foo

Function call or variable? YOU'LL NEVER KNOW.

>>39
The extra keywords have a superfluous meaning. Brace languages just compound the fail by having both keywords and braces.

It makes no more sense in JavaScript, since it's getting compressed before it hits the wire anyway.

>>45
Python and Haskell are superior in this regard. If you're going to indent your code anyway, it's a good idea for that indentation to have meaning. And where you don't want to indent your code, you can use braces and semi-colons.

Some of you are just showing how bad at programming you really are. Those long explicit strings in code is just an incredibly bad and faggy practice.

>>40

The symbol for testing equality and assignment is different in some languages because it was easier to write their parser, not because there is some intrinsic value to doing so.

>>47

The ability to do an assignment in the conditional of the if statement, like so

if (ptr = new Whatever())
    // handle any possible NULL pointer, such as from insufficient memory

Alternatively,
if ((ptr = new Whatever()) == NULL)

>>48
Whoops, meant to have a negative !(...) around the first part.

>>48
Before the detractors come, that is actually a useful C idiom, though your second way is slightly more "accepted" (and the compiler won't bitch, either.)

>>48

Thats just not good practice. The if statement is actually responsible for assignment, its resposible for chacking the result. Thats 2 different things and should be convey as such in your code. Especially since it makes more sense to assign a value to something at its declaration for many reasons, and because you aren't going to be declaring something in the statement of an if statement.

1. Perform assignment
2. Check the assignment

Grouping it together doesn't produce a more performant execyltable or more readable and maintainable code.

>>51

Fuck, that should read:
The if statement is NOT actually responsible for assignment, its resposible for chEcking the result.

ONE WORD, FORCED INDENTATION OF THE CODE, THREAD OVER

CHACK CHACK CHACK CHACK CHACKING

CHACK CHACK CHACK CHACK CHACKING

Type Chacking

cout << massively << fails << at << life.

>>47
The symbol for testing equality and assignment is different in some languages because it was easier to write their parser, not because there is some intrinsic value to doing so.
Not because it's easier for programmers to read and because assignment and tests for equality are unrelated concepts?

>>58

It isn't easier to read.

>because assignment and tests for equality are unrelated concepts?

As much as using the + sign is for numerical addition and string concatenation.

>>59
No, in the latter case you're still putting two things together. The result is different but the high level concept is the same.

For the record I prefer a separate operator for concatenation, but your statement is still incorrect.

aardvarks

>>60
It's not incorrect, it's a statement about subjective experience; the easiness of reading. I'm not >>59, btw. I don't like that + with odd polymorphism of taking different types for each argument. String + Number, okay, fine. But statements like foo = String + Number + Number + String confuse me at first glance. I prefer Perl's and PHP's . operator and VB's & operator.

This is also why Scheme is superior. SET! is much better than =

>>63
set! is just to enable multiple paradigms, it's not meant to be used excessively in Scheme. You know, it's an academic language (like Haskell lol), so it should support more than FP.

hax my anus

>>62
By "incorrect" I was referring to the statement that concatenation and addition are unrelated.

>>66
ambiguity wins again

Have native lists and   dictionaries AKA hash   tables are like   bringing a catapult   and chariots to   a battlefield filled   with heavy artillery   and tanks all   while being totally   unaware of how   it can be   done in C   What I mean   maybe there already   exist things that   work differently The!

All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy

/prog/ will be spammed continuously until further notice. we apologize for any inconvenience this may cause.