@EliahKagan yes definitely

@EliahKagan I do know a little Bash and sed but I wouldn't claim to know bc

@Zanna You found you liked Ruby -- what did you like about it?

well, it was only a toe-dip, but I liked it aesthetically. It was easy and satisfying to understand

There are other languages that are easy to understand, but I do not know of any other language that is particularly similar to Ruby aesthetically. It sounds like you should pursue Ruby further!

haha you may well be right

I had been thinking that you might be interested to learn a programming language that is very different from Bash. But every programming language that isn't a shell scripting language is extremely different from Bash, so that's almost trivially satisfied.

haha :)

when I show some code to my brother (who writes in various non-shell languages) he is like "this is so bizarre!"

That's his reaction to Bash code?

yes

I mean, I agree with him, Bash really is bizarre... but does he not ever use a shell?

no doubt he does, but I don't know what for

I think all different kinds of shells are weird compared to other programming languages.

I like how Stéphane Chazelas stated the contrast between shells and most other programming languages in this answer.

There is at least one general-purpose programming language that is shell-like, though: Tcl

I had been planning to suggest that you might want to learn a compiled language with a strong, static type system. That would be even more different from Bash. You should learn Ruby, though, if Ruby is what interests you. (Ruby is an interpreted language with a strong, dynamic type system. Bash is an interpreted language with a weak, dynamic type system.)

"Strong"/"weak" and "static"/"dynamic" typing are used to mean different things by different authors. I think I am using them in the currently most popular way, which I believe are the meanings the terms have stabilized into.

As I use the terms, static typing means that expressions have types, while dynamic typing means values have types. As a totally separate thing, strong typing means type conversions do not take place implicitly--you have to write actual code when you want one--and weak typing means they do take place implicitly. All four combinations are possible and exist in programming languages people actually use.

Yes I would like to learn things that are different from what I know already

@EliahKagan yes :D I have read before that description of taking the tool out of the drawer, using it and washing it and putting it back every time you invoke it. That is a good thing to keep in mind

Also, I've said it like it's either one way or another (static or dynamic, weak or strong) but that's not really the case. It's immediately obvious how this is so for weak vs. strong typing, because you could have type conversions happen in more or fewer situations. But static vs. dynamic typing is also a continuum rather than one or the other.

For example, people usually say Perl is dynamically typed, but of the dynamically typed languages I can think of, it is the most statically typed of them: it is clear, when a Perl program is compiled into Perl bytecode, whether any given expression is a scalar, list, typeglob, etc. What is not clear until runtime is whether any given scalar expression is a number, string, reference (and if so, reference to what kind of thing), and so forth.

...On the other hand, this is only really true given a sufficiently attenuated sense of "it is clear," since even the compilation stage in Perl involves running Perl code (BEGIN blocks, and some other constructs that are syntactic sugar for them, run during compilation). As the saying goes, it's impossible to parse Perl, even the Perl interpreter can only run it.

hahaha

(Btw, by "Perl" above, I mean Perl 5. I don't know much about Perl 6. And back in the days of Perl 4, I believe matters were somewhat simpler, because if I recall correctly, Perl 4 did not have references.)

> What is not clear until runtime is whether any given scalar expression is a number, string, reference (and if so, reference to what kind of thing), and so forth.

that offers a kind of excitement I guess

Well, in most dynamically typed languages (or, given a sufficiently restrictive notion of what it means to be dynamically typed, all dynamically typed languages), nothing about the type of an expression is clear until runtime.

I mean obviously you can sometimes figure it out by thinking about what happens when the program is run.

However, since values rather than expressions are what have types in a dynamically typed language, an expression can evaluate to different values with different types.

So, for example, consider this Python program:

#!/usr/bin/env python3

def add(x, y, z):
    return x + y + z

print(add(10, 5, 2))
print(add('foo', 'bar', 'baz'))

And this Ruby program, which does the same thing:

#!/usr/bin/env ruby

def add(x, y, z)
  x + y + z
end

puts add(10, 5, 2)
puts add('foo', 'bar', 'baz')

Both Python and Ruby are strongly typed and dynamically typed. (Ruby is a bit more strongly typed, but that doesn't factor in here.) They also are duck typed, based on the aphorism, "If it looks like a duck, and quacks like a duck, ..., it's probably a duck." No type conversions happen in either of those programs. No runtime errors occur when they are run.

In each case, add is able to operate on the actual arguments passed as values of the formal parameters x, y, and z because both integers and strings support +. They give in a different meaning; it is addition, for integers, but it is concatenation, for strings.

Dynamic typing facilitates this, but not all dynamically typed languages are duck typed. For example, in Perl the symbol for addition is + and the symbol for concatenation is ., so nothing like this will work. In Python and Ruby, + is defined, separately, for multiple types, but you cannot use it between different types where the meaning is different.

'foo' + 7 and 7 + 'foo' are both syntactically correct expressions in both Python and Ruby, but in both languages both expression produce errors at runtime when they are actually evaluated, because + is not defined between strings and numbers.

In contrast, in Perl, + does work between foo and 7 (though, in this example, it will generate a warning if warnings are enabled), because the meaning of + is ambiguous, and because Perl is weakly typed: foo is simply interpreted as a number in 'foo' + 7 or 7 + 'foo' in Perl. Similarly, in Perl you can write 'foo' . 7 and that will perform concatenation, treating 7 as a string even though it is supplied as a number.

So, one benefit of dynamic typing is that it can--in some languages--allow a function to be implemented once and work on different types for which the same expressions denote different operations. However, there are statically typed languages where you can do that, too, through genericity.

For example, F# is like strongly typed (like Python and Ruby, though F# is actually even more strongly typed than they are), but unlike Python and Ruby it is statically typed. In F# I can write this program:

let inline add x y z =
    x + y + z

add 10 5 2 |> printfn "%O"
add "foo" "bar" "baz" |> printfn "%O"

That produces the same output as the Python program and Ruby program shown above. This is to say that they all show:

17
foobarbaz

In some statically typed languages, you must declare what type things are. In F#, you can do so--you can add type annotations--but usually this is unnecessary, because the compiler infers the types. Furthermore, functions in F# are generic automatically. (There are situations where that cannot be achieved, and type annotations can prevent it, too.)

In the Python and Ruby versions of the adding/concatenation program, there is really only one function defined, and its behavior differs depending on its arguments (specifically, it calls the objects' functions that implement the behavior of +, which belong to their types, and their types are different, so the implementations are different).

But in the F# program, there are two functions called add. It was just not necessary to write them separately. The F# compiler knows the types of 10, 5, and 2 (it could usually infer them if they were more complex expressions, too), so it infers that the add function whose type is int -> int -> int -> int is intended. Likewise, "foo", "bar", and "baz" are strings so the add function that takes them as arguments must have type string -> string -> string -> string.

I have hand-wavily glossed over some things. In this case, I made it inline, so the two functions are generated fully at compile-time. I have to do that here because of technical limitations in F#. But it is often possible, in F#, to write generic functions that are instantiated into type-specific functions at runtime, but where they are really still separate functions, and where the typing is still fully static. (Which version gets called is still established at compile-time.)

Also, while the behavior signified by the add's expressions was determined entirely via parametric polymorphism (i.e., genericity), both parametric polymorphism and objected-oriented runtime polymorphism are involved in using printfn "%O" to print both results. (Relatedly, in the Python and Ruby programs, duck typing was used not just to do the right thing for + each time, but also to do the right thing for the conversion to string that occurred to facilitate printing, each time.)

Oh, you two are back from radio silence? :)

hope youre doing well

@Videonauth likewise! I am doing fine

:) good to hear

having a lots of real life troubles, but fine so far, just a lot of paperwork and so on, on the brink of getting new medication, which sadly needs a confirmation of cost coverage from my health insurance

when this is through i will be far better in the future

actually loosing my mind over a program i want to write

@EliahKagan is that behaviour (where the function's behaviour differs depending on its arguments) what the Wikipedia article you linked to calls "ad hoc polymorphism" as opposed to parametric polymorphism, or am I wandering?

@Videonauth ugh. sorry for that

as long i only import into the main module all is fine, but as soon i try to import a variable from the main module into a sub module something does not want to play nice

@Videonauth :)

@Videonauth uh oh...

not sure what im doing wrong

but i will find a way, still my little sources tool as python program

with a few more options, like recording installs

and so on

ah nice

so if you apt install something this tool will when called record that operation so you can replay those on a new system, managing your sources.list files etc

so you do no backup of your install, you simply record and replay it

@Videonauth most likely it will be incredibly obvious when you do know what you were formerly doing wrong :)

for sure, i think its the problem that i import the file into main where i import main into a variable

@Videonauth nice! what about configuration?

the file i have that trouble with is called blueprints.py, where i store all variables which are blueprints for files

main dir and sub dir have init.py files

but i will find that rpoblem

found a nice way to write my programs properly

oh?

yes im writing down text to start with (comment text) what it shall do then i insert the logic

example:

        # Getting and parsing system information in to a dictionary called i_lsb_release which is meant to be private.
        # We only 'read' here, since we clean the input, writing it back could be fatal! If the file not exists,
        # we have a very dire dependency fail and exit out with error.
        i_lsb_release = dict()
        if file_exists(f'/etc/lsb-release'):
            i_lsb_release.update(strip_quotes_from_dict(file_to_dict(f'/etc/lsb-release')))
        else:
            print(f'File \"/etc/lsb-release\" missing, aborting action.')

i_ variables are treated imutable

_ variables as private

of the containing script

then i have one module called core which imports nothing but has all the basis functions and so on

what i found for myself is, if you use comments to descript a function, it becomes particularly easy to write the function

and if the logic part below the comment gets to big, simple rule: divide and conquer

ah that makes a lot of sense

# Style Guide
## Preamble:
I want to keep this as short as possible as to many strict rules hinder creativity.
## Rules:
Comments:
  * Do not comment every line, write descriptive code instead!
  * If you write logic like `if`, `while` and so on write a comment what it does in general.
  * Comment lines can be 120 characters long but not longer.

Code:
  * No CamelCase!
  * `_variables` are meant to be treated privately, means they only exist within their respective script, function or class.
  * `i_variables` are meant to be treated immutable, if you write to such a variable you do somethi…

my style guide :P

not big or so

No CamelCase!

:D

why is camel case called camel case? Something to do with humps?

yeah see a camel has humps and a variable in CamelCase is somehow similar

i hate camel case

VariableWhichDoesSomething

shudder

I like it for naming my files because I don't have to create files with spaces in their names

alone for typing i prefer _ as seperator and descritive names

for example for finding if i am root i made a function which returns true if i am root

the function is called i_am_root so in my programm i later can write if i_am_root:

so i get a logical sentence out of it

@Videonauth I guess it looks like it has an inflated sense of its own importance

yep, i still because of the german keyboard try to avoid pressing shift while typing :)

on the other hand i as well try to cut variable names down to the absolute minimum

soo instead of _program_parameter only using _parameter for example

that it is a program i already know and it only adds for confusion later having such names

still having a few places where i have bad word constructs but fighting them as much as possible (example: parser.parse_args())

two times parse

@EliahKagan I am now not really sure what the difference is between a value and an expression!

for me (with my limited understanding) a value is a value which does not change anymore due to the operation, and an expression are more than one value which result in a different value through the operation

very basic

so 1 is a value 1+1 is an expression

it ought to be basic since it's very fundamental :)

yes, but im not sure if that in this case applies, not have read the whole conversation above

@Videonauth Hi Videonauth!

:) how are you?

I'm pretty good.

I'm sorry to hear you're having to deal with large amounts of bureaucracy and paperwork. I hope it all goes smoothly!

I hope too, but as it looks right now i might have to go to court for getting my medication paid from health insurance

Damn.

That's the opposite of going smoothly. I hope it all works out okay!

yeah sadly, my doc want to put me on medical marijuana, but after that law act passsed here our government made the mistake to give the health insurances free reign if they cover the cost for this or not

its actually in decision from the side of the health insurance but i not have much hope, that they simply will cover it

on the other hand its not possible for me to cover those costs alone

the amount i'm supposed to take each day (multiple times a day) goes into about 30-40 gramms per month

and 5 gramms cost when i get it via the official channels will cost 120 euros per 5 gramm

and has to be imported from canada lol

well i will for sure go to court if they decline the covering of th costs

im financially not able to stem those sums per month, and taking valium and rohypnol regularly like I'm doing right now poses a serious health risks over time

Yeah, it sounds like you should definitely go to court if that's what's necessary to get the medication you need! It ought not to be necessary, in the first place, for patients to go to court to force their insurance to cover their medical costs. This sounds like the sort of thing that would happen (and that I am familiar with a number of instances happening) here in the US.

well the legislative is to blame for this

they put up a law which allows marijuana to be prescribed if a doctor sees a sense in it, but they left it totally open to the health insurances if they over costs and we have a set ov hardline health insurances here in germany and about only 50% of them have no problem with covering the costs of such a medication

im sadly insured with the other half

but there are precedence cases already where people got special allowance before the law was passed

and those alowances cover insomnia, depression, panic attacks, PTSD, agoraphobia, back pain etc

and i have all of the just counted up problems

so the regulatory body already gave for each of those a special allowance to people, i have all of them together, i see no reason why i should not go to court if the decline cost coverage

I think I'm in a very good position for a court case if needed

but it is a lot of paperwork

even if i not have medication right now i have to document it every day etc, my doc has to document it every 2 weeks etc etc

and the health insurance already took 4 weeks and has no conclusive answer if they cover the costs

:(

yeah, sadly valium and rohypnol is far cheaper as marijuana

and now tell me there is no lobby working against it ;)

but im actually totally against taking barbiturates and or opioides

@Videonauth hah, yeah

I'm normally not into conspiracy theories, but this smells foul somehow

Many years ago, my dad told me you can make anything you can make from crude oil from hemp...

going to sleep

yeah even more you can do, all those furniture you have at home could be made from hemp too

biofuel too, food oils, etc etc

the firts levis jeans where made from hemp too

very sturdy

going to watch a movie now and prepare for bed :)

@Zanna I mean that, in a statically typed language, types exist in the code. Occurrences of text like x + y have type. In contrast, in a dynamically typed language, the data that are produced when x + y is evaluated--that is, when an operation it denotes gets performed as part of running the programming--are what have type.

* as part of running the program

This article explains the notion of an expression in computer science. I am using "expression" in that way, but I would like to distinguish more sharply between (a) things being named and (b) the text that is used to name them. That article says "2+3 is an arithmetic and programming expression which evaluates to 5." I do write things like that, sometimes.

But it is more precise--and, in the context of distinguishing between static and dynamic typing, conceptually important--to recognize that "2+3" denotes the actual text 2+3 as it would appear in source code, while "5" denotes something more abstract (or abstract in a different way, if you consider text to be abstract, which really it is, too). It would be more accurate to say that "2+3 is an arithmetic and programming expression that evaluates to 5."

The difference is subtle, but SE chat's CSS makes it seems subtler than it is: unlike in that Wikipedia article, I have formatted "2+3" as code, but I have not formatted "5" as code. The Wikipedia article could just have well said, "5 is an arithmetic and programming expression that evaluates to 5." That is, the text "5" is the expression; the abstract thing we mean when we say "5", i.e., 5, is the value. (Strongly related.)