From my vantage point, Zig's syntax perfectly matches the language: it is ad-hoc, whimsical and serendipitous. It is lacking in grace, elegance and compassion.
Zig's Lovely Syntax
151–160 of 246 posts
Re: Zig's Lovely Syntax
#152Earlier quoted context omitted.
We can just use a crate for that and don't have to have this horrible comment like style that brings its own category of problems. https://docs.rs/indoc/latest/indoc/
And what if you do want to include two spaces at the beginning of the block (but not any of the rest of the indentation)? Choice of specific line-start marker aside, I think this is the best solution to the indented-string problem I've seen so far.
I think Java's solution is much cleaner.
Re: Zig's Lovely Syntax
#153Earlier quoted context omitted.
If the lambda captures some value, and also outlives the current scope, then that captured value has to necessarily be heap allocated.
No, (in C++) the lambda can capture the the variable by value, and the lambda itself can be passed around by value. If you capture a variable by reference or pointer that your lambda outlives, your code got a serious bug.
And in Rust, it will enforce correct usage via the borrow checker - the outlive case simply will not compile.
If you do want it, you have the option to, say, heap allocate.
Re: Zig's Lovely Syntax
#154Re: Zig's Lovely Syntax
#155Everyone agrees that "syntax doesn't matter", but implicit in that is "syntax doesn't matter, so let's do what I prefer". So really, syntax does matter. Personally I prefer the Rust/Zig/Go syntax of vaguely C inspired with some nice fixes, as detailed in the post. Judging by the general success of that style, I do wonder if more functional languages should consider an alternative syntax in that style. The Haskell/OCa…
That saying never made any sense to me either. After all syntax is your main interface to a language. Anything you do has to go through the syntax. Some people say the syntax just kind of disappears for them after some time. That never seems to happen with me. When I am reading any code the syntax gets even more highlighted.
One of the reasons why I use Lisp is because the syntax helps me keep my mind organised. C-style syntax is just too chaotic for me to handle.
Re: Zig's Lovely Syntax
#156Earlier quoted context omitted.
I personally find Go's bare syntax harder to parse when reading, and I spend more time reading code than typing it (even while writing). An excessively terse syntax becomes very unforgiving, when a typo is not noticed by the compiler / language server, but results in another syntactically correct but unexpected program, or registers as a cryptic error much farther downstream. Cases in point: CoffeeScript, J.
That is why syntax debates are so difficult. There is no objectively best syntax. So we are all stuck with subjective experience. For me I find Python (non-typed) and Golang syntax easiest to read. Too many symbols like ., :, @, ; etc just mess with my brain.
Yes it's sigils that are the culprits more often than not.
They are often semantically irrelevant and just make things easier to parse for the machines.
Happy Go doesn't indulge too much in them.
Re: Zig's Lovely Syntax
#157Earlier quoted context omitted.
I worked with browsers since before most people knew what a browser was and it will never cease to amaze me how often people confuse slash and backslash, / and \ It’s some sort of mental glitch that a number of people fall into and I have absolutely no idea why.
I wonder if it's dyslexia-adjacent. Dyslexic people famously have particular difficulty distinguishing rotated and reflected letterforms.
Could be. The frequency is such that it could be dyslexics. It's not all the time, but it's a steady rate of incidence.
Re: Zig's Lovely Syntax
#158I wish Zig had lovely vector, quaternion, matrix etx syntax. The team's refusal to add operator overloading will prevent this.
Agreed, their reason for not allowing it is weird. No hidden overloading?
OK make it explicit then: #+, #/ would be fine.
Re: Zig's Lovely Syntax
#159I much prefer C# 11's raw string literals. It takes the indentation of the first line and assumes the subsequent ones have the same indentation. string json = $""" {title} Welcome to {sitename}. """; And it even allows for using embedded curly braces as real characters: string json = $$""" {{title}} Welcome to {{sitename}}, which uses the {sitename} syntax. """; The $ (meaning to interpolate curly braces) appears twi…
Just a minor correction (as I'm the author of c#'s raw string literal feature). The indentation of the final ` """` line is what is removed from all other lines. Not the indentation of the first line. This allows the first line to be indented as well. Cheers, and I'm glad you like it. I thought we did a really good job with that feature :-)
That's a fantastic design idea, and it seems to require all the other lines to have the same indentation "prefix".
Haven't used much C#, but I love Scala's `.stripPrefix` and `StringContext`.
Re: Zig's Lovely Syntax
#160Earlier quoted context omitted.
Maybe if you've never tried formatting a traditional multiline string (e.g. in Python, C++ or Rust) before. If it isn't obvious, the problem is that you can't indent them properly because the indentation becomes part of the string itself. Some languages have magical "removed the indent" modes for strings (e.g. YAML) but they generally suck and just add confusion. This syntax is quite clear (at least with respect to i…
Significant whitespace is not difficult to add to a language and, for me, is vastly superior than what zig does both for strings and the unnecessary semicolon that zig imposes by _not_ using significant whitespace. I would so much rather read and write: let x = """ a multiline string example """ than let x = //a //multiline string //example ; In this particular example, zig doesn't look that bad, but for longer strin…
Does `scalafmt` really slow down builds "considerably"? I find that difficult to believe, relative to compile time.