[cjdell]

Yes! We're finally challenging the notion that scripting languages must inheritly be dynamically typed.

Some say that types are too much of an overhead for small programs but I find it impossible to reason about the design of software without types. I even opt for TS over JS for throwaways...

[junon]

There have been statically types scripting languages for ages. Embeddable ones, too. That's not new.

[cjdell]

Any in particular that you're a fan of? (Genuinely curious)

[jlokier]

NimScript comes to my mind. You get most of the Nim language, which is statically typed and versatile. But NimScript is interpreted immediately, like running a Python script, instead of compiled to an optimised binary like regular Nim.

[mr_ms]

I'm a fan or Umka. It is inspired by Go and can be embedded into C programs.

https://github.com/vtereshkov/umka-lang

[otteromkram]

If you don't want to run awkward searches through your main Google account, DuckDuckGo provides decent results.

[cjdell]

I didn't know DuckDuckGo could find me results about a particular person's preferences.

Yes you can Google pretty much anything that you can have a conversation about and never speak to anyone. What is your point?

[replwoacause]

Not really sure he has one. I was confused too.

[crabbone]

There are no such things as "scripting language" -- any language is a scripting language if you write a script (i.e. a program that automates another program) in it.

All languages are both statically typed and dynamically typed. Or, if you want to be precise: statically checked and dynamically checked. Static vs dynamic refers to whether a check is performed before the program is run or when the program is run.

It's upsetting that even people who write languages use this nonsense taxonomy to describe what they do.

----

As a consequence, your enthusiasm... sort of comes from the place of not understanding something. My guess is that you are happy to see that there are type annotations in the language and they seem to be mandatory (? -- I haven't explored the language in detail enough to tell, but usually if the type annotation precedes an identifier in the grammar is not possible to make it optional).

What I think you (or the language's author) might be happy about is that there aren't built-in mechanisms in the language to convert between different types (or interpret the data stored in a variable in different ways). Such mechanisms exist to various degree in languages programmers don't normally call "dynamically typed" (even though, like I wrote before, this taxonomy is nonsense). For example, in C, everything is and integer in the end of the day, which makes a lot of implicit conversions possible. Or, for example, it's possible in Haskell to overload string literals making them something other than strings (eg. SQL prepared statements) making the meaning of the program depend on an annotation / compiler argument.

There are instances where it's genuinely convenient to have the language guess the type of data and there are instances where it leads to frustrating and difficult to discover bugs. Since a language has to make a decision for all such cases it's difficult to find a good middle ground. Below are some examples of when implicit type conversion is convenient:

* When everything in the language can be "printed" and operations involving strings implicitly convert everything to string. Alternatives involve complicated mechanisms of defining printing methods for various objects, while still not being able to write generic code that prints any inputted objects. Or creating automatic methods that print "something" about the object that usually ends up being useless (eg. the memory address of the chunk of memory occupied by the object). And so on.

* Reading user's input, especially interactively. If I had to spell out the types of arguments I pass down to Unix "find" command every time I use it, I'd have invented a language that would allow me not to do that and would've guessed the types from a more concise input.

* Arithmetic involving different flavors of numbers. Imagine there are languages where it's a tradition to define a special sub-type of some integral type for indexing of every array type the program uses. Imagine now that these types usually cannot be converted between each other. You probably haven't worked with a language like that, but if you want to see how you might like it, you could try Ada.

[seanhunter]

There are no such things as “serving spoons” — any spoon is a serving spoon if you serve something with it.

There are no such things as “desert spoons” — any spoon is a desert spoon if you eat desert with it.

Don’t get me started on whether or not teaspoons exist.

This is such a pointless observation given the world has really come down heavily on the side of sanity, which is to say yes clearly any language can be used for scripting but “scripting languages” are those languages for which writing scripts is the primary purpose. Just like, while you can serve food with any spoon in a pinch, if you really want a spoon that is specialised for serving, a serving spoon is what you are crying out for.

If everyone understands exactly what they mean when they say “scripting language” or “statically typed” and these terms are frequently used to bootstrap understanding of other languages, are they really wrong to use those terms? This isn’t “nonsense taxonomy”, it’s using language in the normal way for the purposes of communicating with human beings, which is something most people try to do.

[rickydroll]

It seems like the term "scripting language" has become a pejorative; denigrating a programming language as somehow less worthy for "serious" programs than non-scripting languages. To me, when I hear someone describe a language as a scripting language, it says more about how they think about programming than the functionality and applicability of a language for solving different classes of problems.

I'm coming to think different programing languages are more like a patois or creole. an expression of ideas shaped by the speaker's thoughts and experience in the world. Sometimes the patois de jour taps into a common experience (e.g. python) or not (e.g. forth).

[seanhunter]

100% agree. And just like you don’t talk to a new-born child in quantifier logic and you don’t attempt to write a PhD thesis in babytalk, there are places where more or less rigorous and exacting language is appropriate.

It used to be the general consensus was that “scripting” comprised quick and temporary automation of tasks and therefore the emphasis in a language was on something convenient and expressive that could get a bunch of stuff done quickly even if the semantics were a bit janky (I’m looking at you bourne shell). Then perl really opened a lot of people’s eyes to what could be done with “scripting languages” (both in terms of power and in terms of the horror that could unleash in the wrong hands) and there has since been a gradual shift towards simplicity and understandability given that there are few things more permanent than a temporary script.

[crabbone]

> There are no such things as “serving spoons” — any spoon is a serving spoon if you serve something with it.

> There are no such things as “desert spoons” — any spoon is a desert spoon if you eat desert with it.

That's not how that works. Eating a dessert is not what makes a dessert spoon what it is. There are multiple criteria which all go into deciding whether a spoon is a desert spoon. For example, dessert spoon cannot be bigger than a table spoon if they are sold as a set.

This isn't true for languages. There's nothing to warrant a title of "scripting" to a language. Nothing that would allow you to discern a "scripting language" from a non-scripting one. This terminology lack internal consistency. You could try to define what that means for you, and that could make the definition valid, but there isn't a shared coherent explanation for how to tell a scripting language from a non-scripting.

> If everyone understands exactly what they mean when they say “scripting language”

Well, here's where you are confused: no, nobody understands what exactly they mean when they say "scripting language". Far from it. It's similar to the situation with fruits and vegetables. Unless you know about the controversy, you might be convinced that you know very well what is a fruit or what is a vegetable, but you will find that not only there isn't a consensus on individual plants, but that there isn't even a consensus on the definition.

So, similarly, if you want to be precise, and you want to use the word "fruit", you need to consider the context in which you are using it and make sure that whoever you are talking to knows what sort of a definition you are using.

But, it's even worse with "scripting languages" because any of the definitions I know are without merit. They don't describe any useful property of a programming language. Knowing that some language is a scripting language doesn't help you understand what can it be used for or what to expect from it etc.

The unfortunate reality is that beyond various aspects of extensions of context-free language group we don't have any useful means for creating of language taxonomy. All we have is a bunch ob b/s often inspired by marketing departments of companies pushing those languages. But we crave taxonomy. It's just the one that we have is worthless...