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.
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 :)
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...
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.
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.
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.
> Overuse of them led to LISP code being hard to read like you said
I don't think that's the case.
That poster your comment goes to claimed that there are types of macros which make debugging harder - not code reading.
Debugging code which makes use of macros is more complicated than code without. There is no doubt about it. One part of it is that debugging happens in a different place -> code transformations with side-effects are running in a compiler or with interpreters at runtime.
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.
>First, it's Lisp not LISP. Using "LISP" immediately flags you as someone with a superficial (if at all there) understanding of the language.
Actually both versions are valid.
You seem to not know historical information about Lisp/LISP. While Common Lisp is spelled "Lisp" and more modern use is Lisp, historically LISP has been prevalent (and tons of Lisp dialects prefer the capitalized version, e.g. like "fooLISP" or "barLISP").
Second, you are concerned with superficial details people don't and should not care about. We're programmers, we care about the code and what you can do with it, not about whether some language is "properly" spelled in caps of mixed case.
Third, you are rude, which is worse than both of the above.
I learned about it from old books, often on AI, I could scrounge up when I didn't have the Internet or a computer. LISP as in LISt Processor. An acronym. Due to broken memory, I sometimes forget which term to use on stuff that's faded away. I end up about randomly using LISP or Lisp unless its Common Lisp where I usually see "Lisp" in write-ups.
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.
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.
> 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).
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.
> 100% overlapping with what I'm trying to do with Zig.
I don't see any mention of meta-programming for V, which seems to be a big emphasis for Zig? This seems like a massive feature that at least I'd care about. I haven't personally had the opportunity to try Zig, but I'm routing for you, so I hope you keep going with the project.
I'm pretty sure none of V will deliver on its promises. Wouldn't be surprised if nothing came out of the announcement at all. Author seems to have a history of big claims and vanishing shortly after. Also details on implementation specifics here in the comments don't make him sound like someone who has an idea of the internals of a compiler or programming languages.
That's what I referred to. His comment history looks like he is advertising his chat apps all the time. One comment pointed out, that eul.im was 4MB in size but loaded a browser runtime upon initial start, also he never opened the source. I'm not saying that he is a scam or anything but that product page makes some very huge claims and has little to no proof for V's existence. So I think it is too soon to celebrate the new GOAT in the programming language game.
The claim that the language is guaranteed thread safe without data races is also unsubstantiated. Avoiding data races, and more importantly, dead and live-lock, are incredibly difficult problems to solve.
V looks interesting, but I'll wait and see before I jump onboard.
Very interesting. What I'm curious about is how this language is compiled, the implication seems to be that it gets translated to C/C++ which seems to overlap a lot with what we are doing with Nim :)
It seems to be an option to compile to C for platform support, but the page also says:
> V is compiled directly to x86_64 machine code (ARM support is coming later) with no overhead, so the performance is on par with C.
Which is interesting. There is a lot more information required still but direct may also imply that it's doing the actual instruction scheduling too rather than relying on LLVM. I'm looking forward to hearing more.
I think /lang may be out of date from the home page. Here's what's on the index:
> Is Volt open-source?
> Not at the moment. Due to several reasons, right now the development model is similar to that of Sublime Text. The app is going to be open-sourced in 2021, so you don't have to worry about it being abandoned.
Edit: Just in case people miss the responses, my apologies, this quote may be referring to Volt the app, not the language (V).
That refers to the Volt app, not the V language. According to the website, the V language will be open sourced in 2019, and Volt (the app) will be open sourced in 2021.
It's at least plausible they could open source the language without open sourcing the app at the same time. So they're not necessarily in contradiction.
Is this language going to be open-source? It seems incredibly impressive, and 100% overlapping with what I'm trying to do with Zig.