141–150 of 192 posts
Earlier quoted context omitted.
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.
No, the claim was that metaprogramming made the grammar of C++ Turing complete.
Earlier quoted context omitted.
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.
No, the claim was that metaprogramming made the grammar of C++ Turing complete.
Earlier quoted context omitted.
> In 2020, not sure we should care that much about how hard compilers have to work to achieve this. That's not right. Long compile times are a real issue for some programming languages even today (Rust and C++). > Computers and software are here to support us--we're not here to support them. A false dichotomy, and not a perspective that offers any insight. Sometimes a low-level language is appropriate, and sometimes…
C++ is stuck in this trap where because it's slow to compile, the compiler maintainers increase the amount of optimizations the compiler does to make it faster. Which of course makes the compiler even slower. Which motivates them to increase the amount of optimizations. Which makes the compiler yet slower. I feel part of the problem with rust is it doesn't have quick and dirty mode thats fast and a production ready m…
Most editors did this on save before LSP came along. For logic, this is fast enough because the type system catches enough mistakes and I don't need to run tests all the time. For UI though, a faster iteration cycle would be nice...
val x: String = "hello"
String x = "hello"
The second line reads: "String x contains hello"
val and : are fluff and add nothing. Arguments about it being tougher to parse would have some merit if this wasn't all figured out almost 50 years ago.
This feels a little nitpicky/idealistic, I don't think the post does a good job of conveying why it's more beneficial. > This means that the vertical offset of names stays consistent, regardless of whether a type annotation is present (and how long it is) or not. Why is this necessarily desirable? Strong typing systems have very expressive types, to the point where if something is typed correctly, most of the time my…
Because rythm makes text easier to parse for the human eye
>most of the time my property names are just an alternative casing of the type
String or int are very rarely appropriate variable names
If consistency if so important, why do we have: function, func, fun, fn, def, etc... depending the author? For clarity, use "function", for simplicity use "fn", other forms are just fancy.
"This is the standard we should all adopt!" https://xkcd.com/927/
Earlier quoted context omitted.
> 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…
> As you yourself noted, personal anecdotes are really not an argument. 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 c…
Evidence. Maybe a study showing programmers have a natural preference? Or scientific evidence? Anything more convincing than "Rust evangelist" anecdotes.
> 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.
Difficulty parsing? If it didn't parse and found an error, then it means it didn't have any difficulty parsing. That has more to do with the complexity of the language itself than parsing. Parsing is a very simple matter. Or maybe the compiler for one language is better? Also, I thought we were comparing Rust to Java?
> I would think that more-useful error messages pass your test of "make it easier for programmers to program".
It does, but once again all you've done is provide anecdotes without any examples or evidence.
> Regardless, I'm in agreement: I find "name: Type = blah" much easier to read.
I don't. The most important part of "name: Type = blah" is the Type. So it's nice to have it first. But then again, there are people who love dynamic programming languages. So once again personal preferences and personal anecdotes aren't convincing arguments.
> As someone who cut his teeth on C and later Java, much later learning Scala and Rust
Yeah, I too fanboy over new languages I learn. But then I get over it and move on with my life. My guess is you just wrote toy programs in scala and rust and nothing substantive.
> 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.
So then use Rust? Why are you using Java?
> 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.
I don't have to argue it. All you've provided is personal preference. "I find "name: Type = blah" much easier to read. " is personal preference. It's no more a convincing argument of anything than you prefering chocolate over vanilla shows that chocolate is better than vanilla.
Earlier quoted context omitted.
In Dylan all types were delimited with . Personally I always found that very aesthetically pleasing.
Same in Powershell except they use square brackets [string] $foo = "foo"