V: Rename functions like `mkdir` and `rm`

[r00ster91]

I think these and other similar functions should be renamed to something more general that isn't so Linux-specific because V is a language for all operating systems, not just Linux. I think we should be equally welcoming to all operating systems. Naming the functions after a specific platform's terminology isn't very friendly for other platforms and might also be confusing for non-Linux users.

[dhonx]

I don't think those names are taken because is Linux specific names, but because of those names is a suitable name. It's short and clear.

I think even though people who don't work on Linux os also know what the function names mean.

But if you have a suggestion for a good new function name. please ... let us know. 🙂

[spytheman]

rm and mkdir are not Linux specific at all. They are present on every Unix-y platform except may be Windows, and even there you can use for example msys2 or https://docs.microsoft.com/en-us/windows/wsl/install-win10 and you will have them available.

[spytheman]

See for example https://www.unix.com/man-page/posix/1p/mkdir/ and https://www.unix.com/man-page/posix/1p/rm/ .

[vitalyster]

Agreed, vlib functions should follow standard V naming conventions (make_directory, remove, etc.)

[Delta456]

@vitalyster label for functions are fine imo and just as @spytheman says that they are present on every Unix Platform expect Windows and also can be easily understood.

If we even used this style then os.ls would be named os.list or os.list_struct and what not.

[vitalyster]

Sure, os.list_directory will match vlib naming conventions.
The issue is not only in os module but in other modules like pg and mysql where names just match their C counterparts. For example, that is the one of most criticized part of PHP standard library, V standard library should be better :)

[spytheman]

There should be a balance between shortness, clear naming, and familiarity.

I also think that os.ls, os.mkdir and os.ls achieve that balance.
Others may not think so. Such is life ¯_(ツ)_/¯ .

Claiming that they are biased towards Linux is wrong.
The correct bias that is at play here is from Windows users, that are not accustomed to short names (probably because CLI interfaces are not very welcomed on that platform) in my opinion, is it not?

(See https://docs.microsoft.com/en-us/windows/win32/api/sddl/nf-sddl-convertsecuritydescriptortostringsecuritydescriptora and http://ashutoshmehra.net/blog/2010/02/long-function-names/ for examples...)

Should os.ls be renamed to os.list_directory, and os.rm to os.remove?

I do not know. I personally do not like it.
It would affect vsh's ability to be short and terse like a shell script is.

At this point, why even bother with vsh?

For example, that is the one of most criticized part of PHP standard library, V standard library should be better :)

The criticism was mostly about inconsistent parameter position/naming, and not about the function names themselves, no? The vast builtin php standart library, has certainly played a huge part in PHP's success... The easy ability to upload scripts to practically any host, and the VERY easy to read and understand high quality documentation of the said standart library, have also played a very big role. I hope that v can have the positive parts (the high quality documentation and easy to remember short names of functions), while reducing the negatives (v has modules, PHP did not have => the huge crowded standard function namespace).

Keep in mind also this aphorism:
"There are only two kinds of languages: the ones people complain about and the ones nobody uses."
I would like v to be a language that is used, and that people complain about. They already complain, so I hope v is on the right track ;-) .

@medvednikov what do you think?

[runeimp]

I could be wrong but I doubt V can even compile to any operating system that doesn't follow the POSIX standard, with the sole exception being Windows. That should make the current os method names the more inclusive standard. Windows isn't even command line compatible with itself as Command Prompt and PowerShell have different command sets from each other. But all of the UNIX subsystems for Windows all followed the POSIX standard. Now I'm not entirely against neutral method names. But that's yet another thing to learn for anyone who is not a Windows only developer.

[spytheman]

@runeimp it had (still has?) support for haiku, which I think is not POSIX, but I may be wrong.

[medvednikov]

These names are pretty much a standard now:

https://golang.org/pkg/os/#Mkdir
https://golang.org/pkg/os/#File.Chdir
https://golang.org/pkg/os/#File.Chmod

I'd rather use that than come up with something new. make_dir? make_directory?

Then VSH becomes pointless, since its goal is to be a simple alternative to bash.

[medvednikov]

And many Windows developers use Linux on the servers, I think a vast majority of developers knows what mkdir or ls do :)

[vitalyster]

@medvednikov golang standard library have consistent naming, the problem not in short names but in the fact - partially V os module have "long names" (is_executable) and another part is "familiar"

[medvednikov]

It's os.mkdir in Python as well.

[spytheman]

what is a suitable short name for os.is_executable ?

[spytheman]

os.is_x?
os.x?

[vitalyster]

@spytheman if we will follow your "familiar" way then there should not be "high level" is_executable function, and every V developer should play with access bits just like in C.

[spytheman]

why?
os.ls for example does not have libc equivalent, but is short and easy to use ...

Anyway, bikeshedding function names is fun, but working on actual code is more so.
Have a nice and productive day.

[vitalyster]

it is "short in easy" only for "linux biased" people, os.is_x short and easy too then

[spytheman]

There is no linux bias, that was my point, which I already made 2 times... It comes from unix/posix.

[runeimp]

@spytheman BeOS and Haiku both are POSIX compatible. Haiku more so than BeOS even, I believe.

[spytheman]

Like it or not, Windows is the special one about naming C functions. I do not like it, but I agree that we have to support it 100%. Following its idiotic decisions however about long function names is not something that we should do in my opinion.

[spytheman]

@runeimp thanks, I did not know that.

[medvednikov]

It's os.mkdir() in Python and Go, some of the most popular languages. I don't see any point in coming up with a new name.