`
>always write one statement per line as a matter of convention
>still need to put a semicolon at the end of the line
>it's 2012 and everyone has baby duck syndrome about a shitty hack meant to help parsers from the 1960s
>>4
Ah, sorry, I was expressing two points and it got jumbled as one. Everything after the "but" was addressing line and statement spacing, not the semicolon.
Name:
Anonymous2012-07-28 1:51
source code isn't anything like dense text paragraphs sub parse_sexp(;$)
{ @_ = $_ unless @_; my @ret = (); if (shift =~ /^(\(((?:(?>[^()]*)|(?1))*)\))$/) { my $inner = $2; push @ret, $1 ? split ' ', $1 : parse_sexp $2 while $inner =~ /([^()]+)|(\((?:(?>[^()]*)|(?2))*\))/g } return \@ret }
Name:
Anonymous2012-07-28 2:01
always write one statement per line as a matter of convention
Well if that is the case then you can write your own preprocessor to add semi-colons before compilation.
Name:
Anonymous2012-07-28 2:40
OP, why don't you marry Python if you love it so much?
Name:
Anonymous2012-07-28 2:43
source code isn't anything like dense text paragraphs
It's more like dense operator chaining.
Name:
Anonymous2012-07-28 5:05
>>1, it's your fault for not using Go. Though its parser does use semicolons internally, it can also insert them by itself, making Go a language without terminating semicolons as far the user is concerned.
>>13
the only part that's even close to "unreadable" is the two regular expressions, but they're not any worse than typical lisp code (and even resemble it!)
Name:
Anonymous2012-07-28 12:13
>>15
I'd suggest that languages like Lisp (maybe Perl) can get away with breaking a individual statement per line convention because it already looks that way normally and doesn't lose anything if the developer chains it. Additionally, it does a good job at mitigating the obvious parentheses that others mock.
It would make a language like C look like a mess through. And I've never seen it done with Assembly either.
>>14 New C style: for (i=0; s[i] != '\n'; ++i)
s[i] = ' ';
Everyone should write liek this.
Name:
Anonymous2012-07-28 13:14
>>14
JavaShit has ``semicolon insertion'', whereby semicolons are inserted into one's anus code. for (i=0; s[i] != '\n'; ++i);
s[i] = ' ';
The ``logical'' thing for that code to do is this, which replaces the first newline with a space, if you ask any JavaShit programmer. for (i=0; i < len; ++i)
a[i] = 0
This code is even more ``logical'' to a JavaShit programmer because it does exactly what they would expect: it wastes time with a loop, and then sets the value of the last element of the array to 0. i = len > 0 ? len - 1 : 0
a[i] = 0
This is the OPTIMIZED version of the above code.
Name:
Anonymous2012-07-28 13:19
>>6 Still not dense text, punctuation doesn't help a bit.
So?
>>18
But what if I wanted to replace the first line with spaces, like >>17 did?
The point is that you either need forced semicolons (like they are), forced braces (Go has that) or (the ugliest way) force every loop/if to be on one line.
Personally, I prefer Go's way, since it forces an uniform code style that makes all these C code styles irrelevant and thus all code readable.
Name:
Anonymous2012-07-28 15:08
there are a couple of problems with not using semicolons:
1) the newline character is not the same between operating systems, so you cant count on it to delimit a line statement
2) the semicolon can be useful for breaking up points of execution on a single line so that you have more control of order of evaluation
points of execution ... control of order of evaluation
Sequence points? Just a sign of a confusing design.
Read the Go docs.
Name:
Anonymous2012-07-28 18:42
>>28 Sequence points? Just a sign of a confusing design. Read the Go docs.
no its not, changing C's syntax to Pascal/Python syntax is a major fuck up, and I say that with deep respect for Bob Pike's work on programming languages and text editors (I use sam). Go will fail as a systems programming language if they dont go back to C syntax.
>>30
Syntax shouldn't interfere with the process of programming because it is pointless. That's why significant indentation is a major fuckup.
Ideally, block syntax should be simplified to the extreme with consistent and æsthetic indentation automatically added by the text editor.
>>33
Go doesn't have significant indentation and the standard compiler includes a tool called ``gofmt'', which automatically formats and indents Go source.
Name:
Anonymous2012-07-28 20:52
>>30 Care to elaborate why would the syntax, of all things, be so important?
because....it is....I dont know how else to say it. The syntax should convey the style of programming youre doing, C syntax has been adopted by most popular programming languages for its conciseness and clarity. Pascal syntax still has its place, its used in Ada. Using := assignment instead of = is clutter, assignment is the most common thing done in imperative programming. Putting the type after the identifier is clutter, the type should come first. It really suprises me that Ken Thompson would choose Pascal syntax over C syntax, he is making a big mistake here.
>>35
You're wrong. Because you are. I don't know how else to say it.
Name:
Anonymous2012-07-28 20:56
(set! x y)
pig disgusting
Name:
Anonymous2012-07-28 21:53
>>33 significant indentation is a major fuckup ... æsthetic
Q: Can you guess what is easier to read and to parse?
A: Smart tabs. Even better, proportional sans-serif fonts with auto indent.
Q: Why no one uses them?
A: Baby ducks, i.e., they prefer tty-alike terminals or notepads with fixed bitmap fonts (VS,gtksrcview,eclipse,textmate...) and blatant discussion about tabs x spaces and blurry x sharp text. EXPERT PROGRAMMERS MY TAILLOL!
>>35 additional ":" per assignment is clutter, ";" after each statement is not syntax should convey the “style” of programming C syntax, for conciseness and clarity Ken choose Pascal syntax (for Go), big mistake
IHBT, after all.
The only reason why it's not a full stop is the latter easily confused with the decimal point.
Statement terminators are there for a reason: to let you know when the end is. People naturally ignore newlines because it is normal to simply continue reading onto the next line once reaching the end of the previous line. Having something visible to delimit individual statements makes things clearer.
☞ def main ☾ ☽
★ if lol
☆ ★ puts "Hello World"
☝ end
Name:
Anonymous2012-07-29 5:47
>>43
Douglas Crockford commented in his Javascript videos about how the option of leaving semicolons out of Javascript was a mistake. I disagree with him only because Javascript is such a lax language meant to do simple tasks, but I would agree with him in a complex systems language.
Name:
Anonymous2012-07-29 14:40
>>41
I said the opposite: it's trivial to put terminators / blocks on FIOC code.
>>42
Unfortunately, Emacs indentation is also based on fixed width chars.
It isn't impossible, but you know how people are avert to changes.
>>43
Newlines are visible, but you know, most people work on a 80x25 tty with 8 spaces/tab, 5 indentation levels and lots of long argument lists / ?: per line... So of course you need line-wrap safe visual clues.
Name:
Anonymous2012-07-29 16:53
I agree, OP. It's funny how a compiler error might say "missing semicolon at line 145," instead of just modifying the source for you.
Name:
Anonymous2012-07-29 18:12
>>48
See >>14. You don't want the compiler to fix your errors unless you're a hardcore INTERCAL programmer.