Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Failing to Learn Zig via Advent of Code

forrestthewoods.com

Post reply on HN
Print view View original

21–30 of 338 posts

Re: Failing to Learn Zig via Advent of Code

#21

Post by alexvoda »

brabel wrote: post #14

Nice to see a "brain dump" as someone who learned many languages and can easily relate with most of the issues the author faced. But I take issue with this: // Obviously good and easy to read return a*(1.0-t) + b*t; // Obviously bad and hard to read return add(mul(a, 1.0 - t), mul(b, t)); Sorry, but the first one is not obviously good, it's just what you're used to (the second one is indeed bad). Here's what I would…

The notation the author complains about looks like a broken polish (prefix) notation with added parens.

Your notation looks like a very bizare mix of infix arrangement postfix (RPN) behaviour plus added parens for good measure.

RPN has plenty of benefits, once you get used to its initial awkwardness, that I feel your notation fails to capitalise on.

Re: Failing to Learn Zig via Advent of Code

#22

Post by NeutralForest »

I don't understand people recommending reading the source code to learn. Source codes can be really daunting because there are so many things going on. There can also be "tricks" using advanced language features, which defeats the purpose if you're trying to learn as a first timer. Also, "read the source" is, at least to me, an admission that there is no valid documentation 90% of the time. Reading the source of a tool or a small to medium library is fine, it's not fine for large projects or projects you know nothing about.

Incremental examples is where it's at. You should document a fonction/type/feature/whatever with a short example with basic operations and then a more involved example with good practices and potential caveats. I know this is a lot of work, I understand it can't be like that everywhere.

This is not a dig at anyone's project or language, but "read the source code" comments always strike me as unhelpful.

Re: Failing to Learn Zig via Advent of Code

#23

Post by thom »

brabel wrote: post #14

Nice to see a "brain dump" as someone who learned many languages and can easily relate with most of the issues the author faced. But I take issue with this: // Obviously good and easy to read return a*(1.0-t) + b*t; // Obviously bad and hard to read return add(mul(a, 1.0 - t), mul(b, t)); Sorry, but the first one is not obviously good, it's just what you're used to (the second one is indeed bad). Here's what I would…

The LISP version can be more readable with (e.g. Clojure’s) threading macros:

    (-> 1
        (- t)
        (* a)
        (+ (* t b)))
Obviously use more or less whitespace to taste.

Re: Failing to Learn Zig via Advent of Code

#24

Post by messe »

I like zig, but agree with many of the points here. A couple of thoughts below,

> Zig reference documentation badly needs examples. Can't figure out how to use std.fmt.parseInt.

While yes, Zig documentation badly needs examples, I'm not sure this particular criticism is justified. I would have thought that the usage of parseInt, was fairly obvious from the type-signature:

    parseInt(comptime T: type, buf: []const u8, radix: u8) ParseIntError!T
Or, translated to C++ (and assuming the use of exceptions to return the error):

    template T parseInt(const char buf[], uint8_t radix)
> Need to access myArray.items[idx] instead of myArray[idx]. I get it. But very unintuitive and requires knowledge of implementation details.

I'm 50:50 on this one. While it might be nice to hide the implementation here and have a .item(n: usize) member function, ArrayList explicitly manages a contiguous region of memory, so I don't see the problem with exposing it as a slice as part of the interface.

> Should I pass the allocator to every function? Doesn't seem great. Maybe I'm supposed to create a global? Globals are evil and feel bad.

As a rule of thumb, libraries should take allocators as arguments to their functions, while applications can either do that or create a global allocator. There is absolutely nothing wrong with using a global allocator in an application; after all it's what almost every other language does. Zig just makes that global explicit.

Globals aren't always evil.

> Zig's inability to infer type is annoying. If I create var count and return it and the function return type is usize then var count is obviously a usize.

It's not. It could be any unsigned type of smaller size than usize.

Re: Failing to Learn Zig via Advent of Code

#25

Post by ReleaseCandidat »

> No one in the history of the world has ever been confused or upset by a + b calling a function.

That depends on `a`, `b` and the function - I have seen way too many `+` that weren't commutative and/or associative. Languages which do not allow to use _other_ symbols like `⊕` too almost always lead to confusing behavior of 'usual' operators.

And what does `a * b` do for vectors `a` and `b`? Is it the 'usual' 'dot product', is it component wise multiplication (`[.., ai * bi, ..]`) is it 'matrix multiplication' (`a * b^t`), is it the cross product (because the language doesn't allow to define `×` as operator), is it ...

Actually, in C and C++ the implicit conversion and promotion rules are footguns enough.

Re: Failing to Learn Zig via Advent of Code

#26

Post by iTokio »

NeutralForest wrote: post #22

I don't understand people recommending reading the source code to learn. Source codes can be really daunting because there are so many things going on. There can also be "tricks" using advanced language features, which defeats the purpose if you're trying to learn as a first timer. Also, "read the source" is, at least to me, an admission that there is no valid documentation 90% of the time. Reading the source of a to…

Reading the source code is very helpful if you are an experimented programmer that already grasped the basics of the language.

It helps you to see what are the idioms, what does optimized production code look like.

Compare C++ and Go std lib and it’s easy to constate the difference in language goals that they have.

Re: Failing to Learn Zig via Advent of Code

#27

Post by ralphb »

NeutralForest wrote: post #22

I don't understand people recommending reading the source code to learn. Source codes can be really daunting because there are so many things going on. There can also be "tricks" using advanced language features, which defeats the purpose if you're trying to learn as a first timer. Also, "read the source" is, at least to me, an admission that there is no valid documentation 90% of the time. Reading the source of a to…

In general I would agree, but (as multiple people pointed out) the zig standard library source code is very accessible.

Re: Failing to Learn Zig via Advent of Code

#28

Post by kristoff_it »

coldtea wrote: post #11
bollu wrote: post #5

Earlier quoted context omitted.

Zig documentation isn't crap; the documentation *does not exist* yet. There's an important difference between the two which seems to be ignored. Zig is young. They're spending their time maturing the core ecosystem --- the compiler, the standard library, and so forth. It's perfectly reasonable to expect early adopters to "RTFS/read the fucking source". *When* they start writing documentation, I'd be perfectly happy t…

> Zig documentation isn't crap; the documentation does not exist* yet. There's an important difference between the two which seems to be ignored.* Well, crap as an offering (what you get atm), not necessarily as in the quality of what little it is. It does though have a reference and documentation page: https://ziglang.org/learn/

The autogenerated docs immediately greet you with a red banner that states

    These docs are experimental. Progress depends on the self-hosted compiler, consider reading the stdlib source in the meantime.
It also links to a page that explains how the standard library is structured: https://github.com/ziglang/zig/wiki/How-to-read-the-standard...

Re: Failing to Learn Zig via Advent of Code

#29

Post by SiVal »

AnIdiotOnTheNet wrote: post #19

As a seasoned Zig programmer, this is good information, though painful to read. A lot of the problems seem to be from a fundamental misunderstanding of Zig's philosophy and very basic things about how the language works. Possibly Zig needs more emphasis on those things in its documentation. I also have to wonder about a fundamental misalignment of thinking when someone says downloading and replacing a single .exe is…

If there are fundamental philosophies in a programming language (and there usually are), tutorials ought to begin with lots of tiny example programs that exemplify those fundamentals. They should continue with examples of gradually increasing complexity, but ALWAYS using those same fundamentals in various combinations to show how those fundamentals are intended to work together in all sorts of ways.

If the tutorials aren't deliberately built up from the language's own defining philosophical fundamentals introduced singly and then in combination, then someone like me will just re-use the fundamentals I learned in whatever other languages I know that feel most similar to the new one. Most languages can be used in roughly parallel ways with just a change in syntax, even if that's not how they are supposed to be used, and if I (like most of us) have to get up and running ASAP in some new tool and don't have a quick on-ramp to establish the preferred patterns right from the start, I'll just have to re-use as much as I already know and just get on with it.

Re: Failing to Learn Zig via Advent of Code

#30

Post by ReleaseCandidat »

littlestymaar wrote: post #20
brabel wrote: post #14

Nice to see a "brain dump" as someone who learned many languages and can easily relate with most of the issues the author faced. But I take issue with this: // Obviously good and easy to read return a*(1.0-t) + b*t; // Obviously bad and hard to read return add(mul(a, 1.0 - t), mul(b, t)); Sorry, but the first one is not obviously good, it's just what you're used to (the second one is indeed bad). Here's what I would…

> Sorry, but the first one is not obviously good, it's just what you're used to. That's also what everybody who as been in primary school is used to. Infix notation have its quirks but at least its ubiquitous.

> That's also what everybody who as been in primary school is used to.

That would (hopefully ;) have been

   (1 - t)a + tb
Post reply on HN