131–140 of 192 posts
If this were true, we'd have to conclude that speakers of name-then-honorific languages like Japanese ("Graham-san") are better at remembering and focusing on people's names than speakers of honorific-then-name languages like English ("Mr. Graham.")
But there's no evidence of that, is there?
Earlier quoted context omitted.
I've been using Rust a lot recently, which puts names before types and inputs before outputs, and I will absolutely attest to how much mental work is saved by ordering things this way. Skimming or reading Rust comes twice as easy as reading Java, and I do a lot of both. Sure it's an anecdotal report, but I have a real sense here that I feel compelled to report. As other posters have stated, this order makes parsing e…
> and I will absolutely attest to how much mental work is saved by ordering things this way. As you yourself noted, personal anecdotes are really not an argument. Someone could say they find Java easier to skim than Rust and we'd be nowhere. Like arguing which end of a boiled egg to crack first. > As other posters have stated, this order makes parsing easier. Programming languages don't exist to make itself easier to…
Then what is? If you're looking for a randomized sampling of programmers with sufficient sample size, you're not going to find it here.
> Programming languages don't exist to make itself easier to parse.
No, but a fine example is that of C++: the difficulty in parsing means that if you make a typo, the error message you get might be bizarre and confusing. A compiler for a language that's easier to parse will have a much better idea of the programmer's intent and can provide a much better error message. I find it astounding how often rustc can figure out exactly what I wanted to do and suggest it as a note after the error message.
I would think that more-useful error messages pass your test of "make it easier for programmers to program".
While we're talking about making it easier to program, "name: Type" make it possible to avoid typing out "Type" at all, and letting the compiler infer it (no, this isn't good and readable to do in all situations, but often it's fine). If you have "Type name" style, and try to add the ability to infer types, you end up with Java's "var" abomination.
Regardless, I'm in agreement: I find "name: Type = blah" much easier to read. I read it as "name is a Type that is equal to blah". This also is an improvement in parameter lists, when they're lined up vertically:
def foo(bar: String,
baz: Int,
quux: Foo)
void foo(String bar,
int baz,
Foo quux)
As someone who cut his teeth on C and later Java, much later learning Scala and Rust, I immediately liked the style of the latter two much better. Lately I've been doing a lot of Java and get constantly annoyed at the "backwards" order.
> This is the problem with tech evangelism. It has the same problems as religions, lots of claims, no evidence.
I suppose you could argue that what I've written above is just personal preference, but I see it as a bit stronger than that.
Earlier quoted context omitted.
I was just thinking about pointer syntax today, and if you ask me, there are a lot of problems that could be avoided if language designers took a page out of Guido van Rossum's book and extend his idea of forced spacing. Take the first example you've given, and let's just talk about variable declaration: int* a; int * a; int *a; That's all the same. That's wrong. Obviously, you can write a lexer and parser that doesn…
There's a perspective that doesn't seem to be noted yet, which is that int *f is declaring that *f will be an int. This perspective addresses why the star belongs with the name, why it's star instead of ampersand, why you need to repeat the star for multiple variables, why the brackets goes after the name for arrays, and it will sort of get you where you need to go with function pointers (although there's an automati…
A more practical reason as a language designer is that C and C++-style type-before-name syntax is a nightmare to lex and parse, as you can't tell whether A * B; is a multiplication or a variable declaration, or whether A D; is a two comparisons with a comma operator or a templated variable declaration, without first knowing the names of all declared types. This means in practice that you have to declare types before…
I missed your mention of the 'most vexing parse' before writing this up, but for those not in the know, here's another fun quirk of C++ syntax: Declare a local named neko of type Kitten , passing a value to its constructor: Kitten neko(42); Declare a local named neko of type Kitten , without passing a value to its constructor: Kitten neko; Declare a function named neko with zero parameters and with return type Kitten…
Kitten neko(Felis::catus);
There's probably some way to say:
Kitten neko(Felis::value_of>::catus);Earlier quoted context omitted.
Checking if a Brainfuck program is well formed (i.e. can be run) is a linear time operation. In C++ this can take forever. They have different complexities.
The original comment was about Turing completeness, and it was defined incorrectly. I was giving an example of a dead-simple language that was Turing complete, because the claim was that metaprogramming made C++ Turing complete.
Earlier quoted context omitted.
More generally this falls into a discussion of context-specific vs context-free grammars. Of which C++ falls into the former, Java falls into the latter.
The grammar of C++ is not a context-sensitive grammar. It's Turing-complete, on account of its template metaprogramming capabilities. I'd be very surprised if Java's grammar were context-free. Do you have a source for this? I wasn't able to find one with a quick search.
Well-formedness includes type checking. But even without full type checking that can be done later, it also includes things like being aware, in C, of whether a given identifier is declared as a typedef in the current scope. So while C has a nice context-free "rough syntax" formally specified in the standard, its actual input language is context sensitive.
As for Java, the first example that comes to mind is that constructors must have the same name as the class they belong to. This "choose whatever identifier you like, but at some later point repeat that exact same identifier" is a very typical example of something that is not context-free.
You might disagree whether this constraint is part of what you consider Java's "grammar". So the answer to your question depends on what language level you are thinking of. But whichever level you apply to Java, you should apply the same to C++. C++ also has a context-free "rough syntax" in its standard.
A more practical reason as a language designer is that C and C++-style type-before-name syntax is a nightmare to lex and parse, as you can't tell whether A * B; is a multiplication or a variable declaration, or whether A D; is a two comparisons with a comma operator or a templated variable declaration, without first knowing the names of all declared types. This means in practice that you have to declare types before…
1 - (sorry, formatting is messing this up) mandate the declaration:
'A*' or '*B'
2 - add some keyword like "type"
Though the compilers are able to deal with it, so it's not a big issue
I think the author misses the single biggest advantage of `identifier: Type`. The moment `Type identifier` syntax encounters higher order functions and types, you end up with messes of parenthesis. Figuring out what a type means then involves bouncing back and forth across the type definition. With `identifier: Type` complex higher order types still parse linearly left to right. It's enough of a UI issue that people…
Earlier quoted context omitted.
If you have local type inference, an alternative would be "x = 5: int".
In Rust, you can write: let x = 5i32; Sadly it's nowhere near as elegant for string literals.
What do you mean? For string literals you just do
let foo= "bar";
and that's it.
BTW, in Rust you can omit most variable type annotations since the compiler is able to infer them. You have to give type annotations to functions though.
Earlier quoted context omitted.
I also know many languages (which is hardly some grand accomplishment) and it’s my firm opinion that syntax MATTERS LEAST. You spend some time getting used to it and it never really bothers you again. Semantics matter most - syntax is just an interface to the important stuff. The difference between Python, C++, Haskell, Common Lisp, Prolog, and SQL isn’t syntax. If it was, everyone would pick their favorite syntax an…
> The difference between Python, C++, Haskell, Common Lisp, Prolog, and SQL isn’t syntax Ok, let's try: Do SQL without the SQL syntax. P.D: I don't think we are that in disagreement ("The syntax just needs to be a decent enough interface to the semantics"), is that the claim of "syntax don't matter" make it look is just an irrelevant aspect of the language. Can be argued how much relevant, but after years on this tra…
Select(`my_table`, [`column_A`, `column_B`])
.Filter(`column_C` > 53 && `column_D` == $varA)
.Sort_by(`column_C`)
> Syntax is 100% tied to paradigms, idioms, and such. Is intrinsic to the language we use.
I think then we don't have the same definition of syntax. The way i understand it is that the syntax is just the way to represent these idioms and paradigms visually. What the parent is saying is that these paradigms and idiom as what is important, but the exact way they are written, not as much (as long as it is within reason)