v-lang (programming language) - Page 1
Forum section: electronics / general

author: DiTBho
author_rank: Super Contributor
timestamp: May 02, 2023, 01:09:59 pm
content: Yesterday Ania reached me out on Whatsapp with big news - here it isvlang: can you really miss it and not add it to your personal language collection? -language+=v-langso she wrote with so much enthusiasm that .... can you really miss it? ... well I forgot to remind her that at 2:05 am local time ... my synapses are with nothing but algorithms to count as many imaginary sheeps as you can herd inside the circle in the plane of complex numbers.(is it an algorithm that terminates?)so, sorry guys, but I haven't yet given a detailed look at the manual, looks *very* interesting btw

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 02, 2023, 10:46:03 pm
content: Ah, so almost all new prog languages, you find pointless, but not this one? I'd be curious to know the rationale - apart from the fact Ania seems to be dear to your heart?

author: DiTBho
author_rank: Super Contributor
timestamp: May 03, 2023, 06:28:52 am
content: Quote from: SiliconWizard on May 02, 2023, 10:46:03 pmI wouldn't put it that way ... when she reached me on WhatsUp she was all excited saying "See we're not the only ones thinking about certain features? So much for those who tell us we're going in the wrong direction"I had asked her, as I have asked here on this forum, to find a language to replace Bash for writing UNIX deployment scripts, building scripts, etc. for ourGNU/linux&Cprojects. Because with Bash ... I really can't take it anymore, which is how she probably foundv-lang.shell scripts in v-lang as V can be used as an alternative to Bash to write deployment scripts, build scripts, etc. The advantage of using V for this is the simplicity and predictability of the languagebonus, there are already CoreUtils in V, Programs equivalent to GNU coreutils, written 100% in V.Ania is one of the sustainers, as well as a contributor, of my-c --level3, and it happens that for the first time, we see implemented in an external project some of the features for which "others" are perplexed about my-c.Things in common, scratching at the surfacebuilt-in code-style formatterVariables always have an initial value and are immutable by defaultFunctions are private and not exported by defaultImmutable function args by defaultinitialization and assignment operators"is" operator to type check"in" operator to check whether an array contains an elementfor in loopis similar towhen 'range(when in range)Similarsafe/unsafeclassification of code sectionsCompile time code IF-condition, to replace C #ifdefSome of the spiciest differences, strictly prohibited in my-clabelslabel with gotobreakcontinueThe two mechanisms that made Ania jump out of her chairSo, v-lang allows unconditionally jumping to a label with goto, even if the label name must be contained within the same function as thegoto statement, andbreakandcontinuecontrol the innermost for loop by default, with labels ...()but ...defer statementmethods on types, functions with a special receiver argument... but, then you also have a "defer statement" that actually "defers" the execution of a block of statements until the surrounding function returns, and this is very similar to what my-c offers, as a side effect, with the use of monads.And although it doesn't have classes, you can definemethods on types. A method is a function with a special receiver argument. Again this is very similar to what my-c offers, as a side effect, with the use of monads.WOW, now we are talking

author: DiTBho
author_rank: Super Contributor
timestamp: May 03, 2023, 06:29:35 am
content: (v-lang is much more than this,too much for us,so it will be likely used in a very close subset)

author: DiTBho
author_rank: Super Contributor
timestamp: May 03, 2023, 11:22:10 am
content: Code:v # makecd ./vc && git clean -xf && git pull --quietremote: Enumerating objects: 2, done.remote: Counting objects: 100% (2/2), done.remote: Compressing objects: 100% (2/2), done.remote: Total 2 (delta 1), reused 0 (delta 0), pack-reused 0Receiving objects: 100% (2/2), 901.81 KiB | 1.40 MiB/s, done.Resolving deltas: 100% (1/1), done.Updating files: 100% (2/2), done.cd ./thirdparty/tcc && git clean -xf && git pull --quietThe executable './thirdparty/tcc/tcc.exe' does not work.cc -std=gnu99 -w -o v1.exe ./vc/v.c -lm -lpthread./v1.exe -no-parallel -o v2.exe cmd/v./v2.exe -nocache -o ./v cmd/vrm -rf v1.exe v2.exe==================cc: error: thirdparty/tcc/lib/libgc.a: No such file or directory...==================(Use `v -cg` to print the entire error message)builder error:==================C error. This should never happen.This is a compiler bug, please report it using `v bug file.v`.https://github.com/vlang/v/issues/new/chooseYou can also use #help on Discord: https://discord.gg/vlangmake: *** [GNUmakefile:117: all] Error 1so, here we have the same problem we have with GNAT: no bootstrapperCode:cat thirdparty/tcc/README.md# thirdparty-unknown-unknownThis branch is reserved for platforms for which we currentlyhave not yet precompiled a binary tcc executable.no one for GNU/Linux-x86/32bit

author: DiTBho
author_rank: Super Contributor
timestamp: May 08, 2023, 07:59:59 am
content: any comment?

author: abeyer
author_rank: Frequent Contributor
timestamp: May 08, 2023, 09:50:02 am
content: Kind of hard to be too optimistic given their long history of repeatedly claiming to have built something, then backpeddaling when they get called out on it not actually being what they claimed, then promising it's coming "real soon now."

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 08, 2023, 07:07:06 pm
content: Well, does it actually work?Otherwise, I don't particulary care for the syntax.The list of "features" is kind of an aggregated buffet of what can be found in myriads of other languages.But this list is rather long, looking at the documentation. Yet the compiler looks very small and fast.So yeah, does it even work?

author: abeyer
author_rank: Frequent Contributor
timestamp: May 08, 2023, 11:45:55 pm
content: This was the last somewhat comprehensive independent status report I'd seen of it:https://mawfig.github.io/2022/06/18/v-lang-in-2022.htmlThe tl;dr was that (as of about a year ago) less than 25% of the claimed features could actually be verified working as advertised.

author: DiTBho
author_rank: Super Contributor
timestamp: May 09, 2023, 08:34:53 am
content: Quote from: abeyer on May 08, 2023, 09:50:02 amso it's vaporware or something to "test" the interest

author: DiTBho
author_rank: Super Contributor
timestamp: May 09, 2023, 08:55:14 am
content: Quote from: abeyer on May 08, 2023, 11:45:55 pmeveryone has their own strategies, but that's why the features my-c has beenprogressively implementedby levels.The thing I don't understand is either you do a private project and every now and then you tell us what you do asjust talking, or you do a public project with Sources, Examples, and Documentation ...... which has likely also a financial aspect, kind of donations? investment? crowdfunding?but then people expect to find the things you promote that actually work

author: DiTBho
author_rank: Super Contributor
timestamp: May 09, 2023, 08:58:05 am
content: Oh, Ania's uncle says - "it's better to learn how to cook reindeerthan waste time doing science scientists on computer languages"pearls of wisdom, who knows

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 09, 2023, 09:56:06 pm
content: Quote from: DiTBho on May 09, 2023, 08:34:53 amMost of these projects are vaporware.Heck, I would even venture that most software projects overall just turn into vaporware in the sense that they never get completed to even a reasonably usable state.Starting a project is easy. Completing it is hard, hard, hard.And just because it gets a fancy-looking website and some hype on social networks doesn't mean anything more.Every idiot can get a a fancy-looking website these days.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 10, 2023, 12:46:46 am
content: Other than that, I'm for one not convinced about an imperative programming language having "immutable variables" by default.Maybe trending towards that (which seems popular these days) is a circonvoluted way of not admitting you should use functional programming instead.One point is that it comes down to what we call a "variable" to begin with. Can be taken in the literal sense - something that varies - in which case, an "immutable variable" is an oxymoron - or in the math sense, which is a bit more abstract and doesn't necessarily mean that the variable is going to change. Still, I have a problem with this term that really sounds like an oxymoron.It's usually a fancy way of saying that your variables are actually constants by default. Said like this, it would sound a lot less appealing though, while it would be basically the same thing.Sure the idea of making this default is to force the programmer to explicitely think - and express - the quantities that are going to change and those that aren't, making it harder to define ones that can change, considering that changing states is dangerous, so you must be protected against it."Immutable" functions args, OTOH, I agree with. Unless you mean something else by that, I take it as the inability to use function args as just any local variable - which a number of prog languages allow - and thus modify them within a function's body. That can lead to spectacular bugs, makes code less readable (unless it's a trivial one- or two-liner).Regarding variables, I kinda like the following concept. I would define 3 classes of "variables" (not sure this would be the right term to use, but that's another topic):- Constants (have a type and initial value, can never change)- Regular variables (have a type, an initial value, and can change)- Definitions (identifiers bound to an expression that can involve any object in scope)I would be against the possibility of changing a given variable's class at any point.For "definitions", here's a very simple example to illustrate them (in some kind of pseudo C-like code):Code:double Foo(double x1, double y1, double x2, double y2, double r){double x2p = x1 + x2, y2p = y1 + y2;def double xdiff = x2p - x1, ydiff = y2p - y1, distance = sqrt(xdiff*xdiff + ydiff*ydiff);while (distance > r){x2p = 0.5*(x1 + x2p);y2p = 0.5*(y1 + y2p);}return distance;}(Good luck trying to figure out what it computes though)

author: Fredderic
author_rank: Regular Contributor
timestamp: May 10, 2023, 03:01:30 am
content: Quote from: SiliconWizard on May 10, 2023, 12:46:46 amYour definitions are more commonly known as lambda's.The issue here, seems to be conflating the variable with it's value. Though intrinsically linked, they are separate concepts, and have separate lifetimes, mutability, and so forth. C has immutability too, it calls it "const", in which the variables are the immutable part — the value is still free to vary. This is mostly an abomination. Immutability in most cases I've seen, is an attempt to fix that; a variable may or may not be able to vary, but the nature of the value it presently holds, can not. If you take a "view" into that value, your view will remain valid, even if the variable holding it changes.Further, fundamental value types like a number, are immutable by default, and always have been; 5 will always be 5. I don't believe we have any concept of it ever changing. (Kinda — if you forget that numbers larger than 1 are themselves represented by a collection of other numbers, and sometimes, by collections of collections of basic numbers, and then there are floats…) It's just the more complex types where mutability is optional — arrays, and other collections of fundamental value types.The problem with C's idea of constant-ness, is that even if you can't change the value, the value can usually still change itself, and worse, other things can "forget" that it was meant to be constant. This means that if you try to reuse part of the value for another purpose, that view into the larger value can now mysteriously (and potentially incorrectly) change without you knowing it. That's bad. And doesn't even consider why you made that view in the first place, and thus whether it's new state, while being valid in and of itself, is valid for the purpose for which you made it.Sharing is an awesome thing. I don't know how this V-lang uses Immutability, but D-lang, which is based around manipulating "views into data" (they call it "ranges"), has an XML parser that manages to process an entire loaded XML file (loaded as in, the text bytes are by some means readable through a stable range of memory addresses), while only allocating a hundred or so bytes per the "depth" of the deepest node in the entire file. So if you have a 100MB XML file with a maximum depth of only 3 levels, the parser will feed you every node in that file one by one, while only itself allocating 300-ish additional bytes. It does that by handing you strings that are a "view" into the source data, rather than making copies of it — which also makes it significantly faster. This is only possible, because we know the source data will not be changing or disappearing — it's Immutable.So, Immutability is great for speed and safety! The downside, is that it tends to eat memory because if you have a three byte view into a 100MB XML file still hanging around, that entire 100MB XML file also has to hang around to provide them — unless you have some whacky memory manager which is able to release part of an allocation (certainly possible, but probably not efficient, and not yet natively supported)… D-lang as a result, is amazing awesomeness rivalled by none (IMHO) — if you have buckets of memory to spare. That said, D-lang also doesn't force you to use the GC, and you can easily enough use mutable equivalent types (most of them are provided, and can be used in either mode — in fact, one of it's problems is that it typically offers three versions of everything, so you can chose your memory model), or explicitly copy values which know are going to out-live the source data, thus allowing it to be collected. Immutability enables a lot of good things, but it rather encourages tying up memory, and requiring some stuff that might have lived on the stack, to instead occupy the heap. (D-lang is kinda dual-natured in that regard, favouring value-passed references to shared immutable heap memory — so, more stack as well as more heap, unfortunately. Plus it barely knows what 8- or 16- bit are. It's like, a millennial of the programming language world, or something.)As an aside, D-lang has UFCS (which it had a good decade before Rust even existed) which makes any function that takes no arguments look like a property. So your "definitions", are indeed simple lambda's in D. In other languages, you would simply need to us the commonly accepted "definition indicator syntax", which is, a pair of empty parenthesis after the value. ie. xdiff(), instead of merely xdiff. (Not at all a function call… it's clearly a "definition", honest!)This is of course, all to say, Immutable is arguably what C's const should have been, rather than the abomination it is. Still… It's not actually for everything.