4 ms·

To Andy: I thought it was a new name for Zig seeing your name and the description in the link. ;) It actually looks about too good to be true, especially that

To Andy: I thought it was a new name for Zig seeing your name and the description in the link. ;) It actually looks about too good to be true, especially that it can handle any C++ to V conversion. I was pushing people to check out languages like ZL exactly to rid us of C++ without throwing away legacy code. If it can do that and fast compiles, I can't wait to read the full write-up later on. Btw, I encourage you to keep at Zig for diversity in systems, language space. Plus, macros. I tell people to avoid them by default for more maintainable code. However, there's times where it's better to have them than not have them. I was happy to see D, Rust, and Julia do macros. Zig and V should have them, too, for max productivity. To amedvednikov: 1. The name. Although Kesterel had a V language, that was long time ago. You're not stepping on anything. I just encourage you to do one people can spell and pronounce easily that isn't already taken. That will make both search results and adoption a little better. 2. Macros. Like I said above. I saw you mention Go which intentionally tries to keep a standardized language for maintainability and easy compilation. I get that. You could add a warning to the main page that macros are available but discouraged for most situations for those reasons. "Use them only when the cost is worth it." Can just do two passes: one for macros, one for regular code. Your incremental compilation should knock out most of what little slowdown there is.

DubiousPusher 8y ago
Max productivity to the library implementor not to the integrator or maintainer. The number of hours I've spent inlining gross macros so I can debug them has poisoned me against all but the simplest application of them.
- nickpsecurity 8y ago
  I said the same thing in my comment. You get max productivity with selective use. Nine times out of 10 you don't need them. Overuse of them led to LISP code being hard to read like you said. We don't need to repeat mistakes of history. So, I said add them with a warning to minimize them for maintainability if language is trying to be like Go. On the other hand, they should be most of the code if taking a DSL- or MOP-like approach. The people using those will be very familiar with the higher-level language. There's a solid, lower-level language underneath for when the VHLL's don't work out. The macros help there.
  - insertcredit 8y ago
    First, it's Lisp not LISP. Using "LISP" immediately flags you as someone with a superficial (if at all there) understanding of the language. Second, unsubstantiated proclamations like "Overuse of them led to LISP code being hard to read" reinforce the previous point. Could you provide a clear reference where Lisp macros are considered "mistakes of history"? Clear references where overuse of Lisp macros turned out to be a problem? I'm curious if you've ever used a Lisp development environment with facilities such as interactive macroexpanders or if you're just assuming things based on your (incomplete, suspect) understanding of the domain.
    - greghendershott 8y ago
      This seems unnecessarily harsh. Capitalization isn't a deep signal. There are lIsPs like Clojure that argue (> data functions macros). Although I mostly disagree (for example I love Racket macros), I understand and appreciate the sentiment. I have heard it from other people who have worked with a variety of LiSp code bases over the years. TL;DR: Any form of non-trivial DSL needs supporting materials like documentation and a simple, clear design. Although it is nice to be able to expand macros, fully-expanded macro-generating macros are clear in approximately the same way as assembly language. It is impressive if you can navigate that, but even more impressive if can manage not to need to do so.
      - dkersten 8y ago
        Clojure argues that (> data functions macros), but it still has macros and accepts that they are not only useful, but sometimes necessary. Clojure's core.async would have had to be built into the compiler, if it wasn't for macros. Just because it prefers data to functions and functions to macros, doesn't mean that it doesn't recognise the importance or usefulness of all three.
      - lispm 8y ago
        > lIsPs like Clojure that argue (> data functions macros). That's not really Lisp related. It's more like how the community likes to see code being written. For example I would regularly make use of macros to provide more declarative syntax various programming concepts. There are Lisp dialects which are light on macros and some which are using macros a lot more. For example the base language of Common Lisp already makes use of many macros by providing them to the user as part of the language (from DEFUN, DEFCLASS, ... INCF, upto LOOP).
AndyKelley 8y ago
> Zig and V should have them, too, for max productivity. Have you read my articles about macros and what Zig does instead? https://andrewkelley.me/post/zig-programming-language-blurs-line-compile-time-run-time.html https://andrewkelley.me/post/zig-programming-language-blurs-... I would be curious to hear your thoughts with this context.
- SomethingOrNot 8y ago
  Seems like you are going for a two-staged language with homogeneous metaprogramming. As opposed to heterogeneous metaprogramming (macros). I like it, I must say.
amedvednikov 8y ago
I'm against macros. I've done a lot of research on this topic. One of the main goals is simplicity and maintainability. I want people to be able to jump into any code base (including stdlib and compiler) and understand what's going on. Macros don't help with that. I went through like 10 names and ALL of them were taken. There are a lot of programming languages out there :)
- deleted 8y ago
  [deleted]
- skocznymroczny 8y ago
  I don't know of any language with macros that have proper IDEs that do more than syntax highlighting. One of the reasons languages like Dart, Java or C# have such amazing IDE capabilities w.r.t. refactoring is that they don't generate half of their code during runtime...
- rafaelvasco 8y ago
  I agree. Macros only help the programmer. They significantly decrease code readability imo. Code readability is more about how easy it is to understand what is going on than about how much stuff there is to read.
eggy 8y ago
It's hard to avoid naming conflict, but there is: V programming language https://www.vcode.org/ https://www.vcode.org/
SomethingOrNot 8y ago
> Btw, I encourage you to keep at Zig for diversity in systems, language space. I don’t think that “Basically like C but a tiny bit better” deserves to be associated with the word “diversity”.

DubiousPusher 8y ago

Max productivity to the library implementor not to the integrator or maintainer. The number of hours I've spent inlining gross macros so I can debug them has poisoned me against all but the simplest application of them.

nickpsecurity 8y ago
I said the same thing in my comment. You get max productivity with selective use. Nine times out of 10 you don't need them. Overuse of them led to LISP code being hard to read like you said. We don't need to repeat mistakes of history. So, I said add them with a warning to minimize them for maintainability if language is trying to be like Go. On the other hand, they should be most of the code if taking a DSL- or MOP-like approach. The people using those will be very familiar with the higher-level language. There's a solid, lower-level language underneath for when the VHLL's don't work out. The macros help there.
- insertcredit 8y ago
  First, it's Lisp not LISP. Using "LISP" immediately flags you as someone with a superficial (if at all there) understanding of the language. Second, unsubstantiated proclamations like "Overuse of them led to LISP code being hard to read" reinforce the previous point. Could you provide a clear reference where Lisp macros are considered "mistakes of history"? Clear references where overuse of Lisp macros turned out to be a problem? I'm curious if you've ever used a Lisp development environment with facilities such as interactive macroexpanders or if you're just assuming things based on your (incomplete, suspect) understanding of the domain.
  - greghendershott 8y ago
    This seems unnecessarily harsh. Capitalization isn't a deep signal. There are lIsPs like Clojure that argue (> data functions macros). Although I mostly disagree (for example I love Racket macros), I understand and appreciate the sentiment. I have heard it from other people who have worked with a variety of LiSp code bases over the years. TL;DR: Any form of non-trivial DSL needs supporting materials like documentation and a simple, clear design. Although it is nice to be able to expand macros, fully-expanded macro-generating macros are clear in approximately the same way as assembly language. It is impressive if you can navigate that, but even more impressive if can manage not to need to do so.
    - dkersten 8y ago
      Clojure argues that (> data functions macros), but it still has macros and accepts that they are not only useful, but sometimes necessary. Clojure's core.async would have had to be built into the compiler, if it wasn't for macros. Just because it prefers data to functions and functions to macros, doesn't mean that it doesn't recognise the importance or usefulness of all three.
    - lispm 8y ago
      > lIsPs like Clojure that argue (> data functions macros). That's not really Lisp related. It's more like how the community likes to see code being written. For example I would regularly make use of macros to provide more declarative syntax various programming concepts. There are Lisp dialects which are light on macros and some which are using macros a lot more. For example the base language of Common Lisp already makes use of many macros by providing them to the user as part of the language (from DEFUN, DEFCLASS, ... INCF, upto LOOP).

AndyKelley 8y ago

> Zig and V should have them, too, for max productivity. Have you read my articles about macros and what Zig does instead? https://andrewkelley.me/post/zig-programming-language-blurs-line-compile-time-run-time.html https://andrewkelley.me/post/zig-programming-language-blurs-... I would be curious to hear your thoughts with this context.

SomethingOrNot 8y ago
Seems like you are going for a two-staged language with homogeneous metaprogramming. As opposed to heterogeneous metaprogramming (macros). I like it, I must say.

amedvednikov 8y ago

I'm against macros. I've done a lot of research on this topic. One of the main goals is simplicity and maintainability. I want people to be able to jump into any code base (including stdlib and compiler) and understand what's going on. Macros don't help with that. I went through like 10 names and ALL of them were taken. There are a lot of programming languages out there :)

deleted 8y ago
[deleted]
skocznymroczny 8y ago
I don't know of any language with macros that have proper IDEs that do more than syntax highlighting. One of the reasons languages like Dart, Java or C# have such amazing IDE capabilities w.r.t. refactoring is that they don't generate half of their code during runtime...
rafaelvasco 8y ago
I agree. Macros only help the programmer. They significantly decrease code readability imo. Code readability is more about how easy it is to understand what is going on than about how much stuff there is to read.

eggy 8y ago

It's hard to avoid naming conflict, but there is: V programming language https://www.vcode.org/ https://www.vcode.org/

SomethingOrNot 8y ago

> Btw, I encourage you to keep at Zig for diversity in systems, language space. I don’t think that “Basically like C but a tiny bit better” deserves to be associated with the word “diversity”.