Visual Basic vs bash
When comparing Visual Basic vs bash, the Slant community recommends bash for most people. In the question“What is the best programming language to learn first?” bash is ranked 37th while Visual Basic is ranked 64th. The most important reason people chose bash is:
Bash is the default shell on virtually every UNIX system. Making it very portable across different systems and once you get used to it, you can use it everywhere.
Ranked in these QuestionsQuestion Ranking
Pros
Pro Capable language
Compiling to the same intermediate language as C# and compiling against the same .NET libraries, the differences between C# and VB are largely syntactic. Most VB features even have a 1:1 correspondence with C#.
Pro Huge community
Being Microsoft's introductory language, visual basic has a strong and large community.
Pro English-like syntax
Pro Flexible, won't get in the way of a beginner
A beginner developer can worry about the code logic first, and then learn the language. Visual Basic lets you do basically anything if you really want, while still having the power to be a fully statically-typed and object oriented.
Pro Sibling to C#
If you don't want to start with C# because of its high learning floor, you can start with VB. It is dead easy to switch between the two.
Pro Very simple and efficient language (in terms of number of lines of code)
Pro Easy to deal with Win32API
Using platform invoke, it's very easy to use the win32 api in vb.net. Neat and clean syntax. Not a mess like c# (meaning those "{}"s).
Pro Default shell on most systems
Bash is the default shell on virtually every UNIX system. Making it very portable across different systems and once you get used to it, you can use it everywhere.
Pro Plenty of examples and tutorials
Since this is very mature shell there is a lot of great examples and other resources describing how to do almost everything.
Pro POSIX compatible
Pro Emacs-like keyboard control
By default, BASH uses shortcuts and concepts very similar to Emacs, so learning one often results in familiarity with the other.
Pro Rich scripting capabilities on a single line
Want to run something 5 times? Write a throw-away loop: for i in 1 2 3 4 5; do date; done
If you need it 100 times? Not a problem: for i in {1..100}; do date; done
or: for ((i=0; i<100; ++i)); do date; done
How about emailing yourself when remote server is back online? Sure thing: while ! ping -c1 example.com &>/dev/null; do date; sleep 5; done && mailx -s 'server is back!' me@myself.com
Pro Recursive globbing
ls **/*.log
for example is supported by Bash if you set shopt -s globstar
.
Pro Built-in 'help'... helps a lot
Builtin 'help' provides quick and efficient help on builtins and keywords.
Pro Rich scripting capabilities
BASH scripting is a rich and robust language.
Pro Variables and aliases are listed the way they are built
alias
and set
will list aliases and variables in a format that can be run directly with no modifications. Even if the values contain \n.
This is handy if you want to modify a value.
Pro Rich built-in features
By default, there are many built-in features. They make really complex and reliable programs possible. In comparison to dash, for example, you can do the same tasks in less time and fewer lines of code.
Pro vi mode is more comprehensive than on other shells
Vi editing mode works without a glitch. "_" will print you the last argument of the latest command (zsh won't). VI mode is fast off the bat - You don't have to reset any variable (like "KEYTIMEOUT" in zsh) for that.
Cons
Con Bad reputation
Being a visual basic programmer, you're unlikely to be taken seriously by other programmers. According to the 2015 Stack Overflow survey, it was voted the second most dreaded language among developers.
Con Almost as bad as Python, but less used.
Con Tends to get clunky due to prebuilt assets
Con Lags behind on features compared to ZSH and Fish
People who wants power features or to customize their shell experience use zsh or fish.
Con Extremely complicated and inconsistent rules
In Bash, exceptions are the rule, not even all being described by the main page.
There are a grand total of 5 different ways of quoting, sometimes even when one does not want to, for instance in command substitutions. These are all based around preserving the literal meaning of every character, with an exception list. There is even an exception list to the exception list in 4 of the 5, regarding how the backslash behaves! The behavior of the backslash is also one of the quoting rules, so naturally, it also has an exception in how it works when it stands before a newline as compared to other characters.
Bash has several layers of interpretations, all to be kept in mind:
The ~ expands to the home of the current user. So if you store it in a variable, can you use it that way? Nope: tilde expansion comes before variable expansion.
Aha, so that's how it works! Then, since applying quotation happens after redirections are set up, it must mean that redirecting within quotes works, right? Nope: there is an exception! If a redirection symbol is not quoted, quotation around the symbol is observed, but is not removed. So, since variable expansion also comes after setting up redirections, and no exceptions are described here in the man page, getting the name of a file from a variable and using it as a target should not work, right? No: redirection does not actually take place when the symbols are being read, the symbols are merely removed and are noted for later, right before when the actual command runs.
Apart from 5 types of quotation, there are basically 2 quoting phases, 2 word splitting phases (with only one being controllable), and a tokenization phase on top of that.
If you have a command, it could be an alias, a special built in, a non-special built in, a symbolic link to a file, a regular file, a function, with different rules regarding how they can be overridden, if redirection happens before or after arguments have been passed (what does "time my_command 2>&1 >log_file" do?), etc.
This list is admittedly long, but it doesn't even scratch the surface of the bloat, complexity and inconsistencies of Bash.
Con No out-of-the-box command autocompletion
To have command autocompletion in bash you need to install third-party plug-ins.
Con Filename expansion is not consistent
filename expansion is not consistent. "echo *" will print the names of the files in your current dir, if there are any... and will print "*" if there are none.
Con Non-intuitive shell expansion in for loops
If there are no .sh files, this will print mask itself:
for filename in *.sh; do
echo $filename
done
Con One of the most dangerous languages around
What it is mostly used for are file system operations. Guess what it is bad at? Operating on files. It automatically splits and carries out filename expansion on every single string resulting from variable expansion and command substitution unless quoted, by default on whitespace, whilst spaces are very common in filenames.
Before that, it even does pathname expansion, so woe to anywone who does not want to actually operate on files, but has a globbing metacharacter stored anywhere in a variable.
This means what you store in a variable is not going to be what will ACTUALLY be accessed.
If an empty variable is unquoted, it disappears completely due to word splitting, sometimes leading to applications signalling a missing parameter at a wrong position.
If quoted however, said variables cannot be iterated over in a loop, no matter what character one uses for word splitting.
If you use any globbing pattern with a command, be sure to use -- after the option arguments or if none are present, before starting the pattern with a mandatory ./
Otherwise, another Bash script run gone wrong or a hacker can create files named like an option ("-f", for instance) and your program will happily accept it as such, if it results from globbing.
For interactive use, it is convenient. For programming, it is a no-go.
Built By the Slant team
Lustre recommends the best products at their lowest prices – right on Amazon.