171–180 of 307 posts
I'm surprised that the reason I'm mostly interested in Zig is not mentioned. This is C interop. I work with C quite a bit and I enjoy it, however writing a large project in C can be tiresome. Having an option like Zig which can import C headers and call C functions without bindings is pretty attractive, especially when you want to write something a big larger but still stay in C world.
What about c++ interop?
Earlier quoted context omitted.
I haven't tried Zig, but "all the things you like about C plus better versions of most/all of the awkward bits" seems like a reasonable value proposition. Especially since the compiler can apparently let you use C painlessly alongside your Zig -- enabling incremental rewriting.
Can you use Zig painlessly alongside C? Does `zig cc` or an equivalent provide for writing Zig libraries that then can be called by a main C function?
Earlier quoted context omitted.
Writing greek symbols is sufficiently annoying that I always kind of resent code that does this. It’s not just about the first time you are writing code, but also when you are reviewing it, or trying to share a snippet with a coworker, or lots more scenarios. Maybe it’s just me, but writing ‘z = x ∇ d’ is really tedious.
∇ is near-worst-case since it's not even Greek. I think domain-specific keyboard layouts are as much of a good idea as language-specific layouts, but they're a nuisance to install on *nix (trivial on OS X). Using .XCompose is the most practical *nix approach, in the absence of program-specific methods like Julia's tab-completable backslash names.
The main take away is: > Something that makes Zig harder to learn up front, but easier in the long run is lack of undefined behavior. Reminds me of the old discussions of Fortran Vs C, and specifically in the early times before C had a standard library. What we call "undefined behaviour" was just an idiom of the language where the "behaviour" was sometimes on purpose, but recognised might not be portable. And so the…
C89's ‘undefined behavior’ was a failed attempt to say “you get what the hardware gives you”.
Earlier quoted context omitted.
> Referentially transparent means that you can replace an expression with its value without changing the meaning of the program. Not quite. A referentially transparent expression (E) is one where you can replace any of its subexpressions (A) with another (B) that has the same meaning (not value!!!!) as (A) without changing the meaning (not value!!!) of E. However, in purely functional languages, the meaning of any ex…
Do you have sources for your definition? The original definition that I'm finding from Quine seems to broadly support the interpretation that an expression is referentially transparent if it can be replaced by its value without altering program semantics, as others have stated. Regardless, it isn't clear to me how macros are any more or less referentially transparent than function calls in an impure language.
In most programming languages the reference or meaning of a term is not a value; in pure functional languages the meaning is a value and that's what makes them special, not their referential transparency which they share with imperative languages.
Here's an example from C:
int global_x = 0;
void f() { x++; }
void g() { x++; }
#define m(x) #x
Earlier quoted context omitted.
I haven't tried Zig, but "all the things you like about C plus better versions of most/all of the awkward bits" seems like a reasonable value proposition. Especially since the compiler can apparently let you use C painlessly alongside your Zig -- enabling incremental rewriting.
Can you use Zig painlessly alongside C? Does `zig cc` or an equivalent provide for writing Zig libraries that then can be called by a main C function?
https://ziglearn.org/chapter-4/ See here
Earlier quoted context omitted.
Maybe an operator-overloading region ? #{ m3 = m1 * m2 + m3; m3 += m4; } Basically, pure syntactic sugar to help the author express intent without having to add a bunch of line-chatter. Speaking of operator-overloading, I really wish C++ (anyone!) had a `.` prefix for operator-overloading which basically says "this is more arguments for the highest-precedence operator in the current expression: a := b * c .+ d; Which…
Huh I've never seen this approach. Very interesting solution, could be adapted to the JavaScript matrix libraries I bet.
Earlier quoted context omitted.
Do you have sources for your definition? The original definition that I'm finding from Quine seems to broadly support the interpretation that an expression is referentially transparent if it can be replaced by its value without altering program semantics, as others have stated. Regardless, it isn't clear to me how macros are any more or less referentially transparent than function calls in an impure language.
I'm very sure the commenter is being a little pedantic But even pedantry can't argue that Java is a fundamentally more referentially transparent language than Haskell lol. That threw me for a loop.
> [...] easy things seem easy primarily because they are familiar. Easy is subjective. But simple things are simple because they do not complicate; they have fewer concepts. Simple is objective. This should be printed out as a large poster in every office.
In a lot of ways, Zig is to the systems programming space what Clojure is to the information processing space.
If you have 5+ years experience, you want simple, not easy. Both languages deliver real advances on that promise in their respective domains.
----
Back to the article, perhaps not coincidentally, the product my startup is developing is written primarily in Zig (language runtime), Clojure, and an in-house Forth/Factor/Joy derivative for user-level scripting. I guess I really do care about simplicity…
[0] Simple Made Easy: https://www.youtube.com/watch?v=SxdOUGdseq4