I think it’s the ease of doing common operations and writing common programs. Maybe it’s easier to classify what isn’t a scripting language.
I like Go, but to me it isn’t a scripting language like Python and Ruby because it has less ergonomic APIs for common operations (especially for strings and slices). Rather, Go prefers a literal representation of what’s going on in memory. For instance, there’s no “str1[1:5] + str2[1]” api, or you append to a slice with “s2 = append(s1, newElement)”. You can’t just “s1 + newElement”. I think Go’s reasoning is that it likes to avoid less literal features like operator overloading, and append() hints that a heap allocation might occur. But in a scripting language, you shouldn’t care that a heap allocation occurs and instead should choose a more concise and ergonomic api.
Java isn’t a scripting language because it’s so wordy.
Rust isn’t a scripting language because its type system and borrow checker are a bit too much.
Haskell isn’t a scripting language because monads and lazy execution are a bit much.
When I think of scripting languages like Python and Ruby, they focus on making common scripting type tasks easy, which often involves giving the programming less control over the machine. But at the same time, they don’t introduce any opinionated language abstractions like monads, a borrow checker, and actor threading model, etc. It also just shouldn’t be that wordy or type-heavy in a way that would slow down prototyping.
Traditional scripting languages have been dynamically types. But I think they can still be statically typed (like this language is trying to do). There isn’t a hard boundary, but once you are “too far into the weeds”, you notice that you are too far into weeds and not in scripting language territory anymore.
I like Go, but to me it isn’t a scripting language like Python and Ruby because it has less ergonomic APIs for common operations (especially for strings and slices). Rather, Go prefers a literal representation of what’s going on in memory. For instance, there’s no “str1[1:5] + str2[1]” api, or you append to a slice with “s2 = append(s1, newElement)”. You can’t just “s1 + newElement”. I think Go’s reasoning is that it likes to avoid less literal features like operator overloading, and append() hints that a heap allocation might occur. But in a scripting language, you shouldn’t care that a heap allocation occurs and instead should choose a more concise and ergonomic api.
Java isn’t a scripting language because it’s so wordy.
Rust isn’t a scripting language because its type system and borrow checker are a bit too much.
Haskell isn’t a scripting language because monads and lazy execution are a bit much.
When I think of scripting languages like Python and Ruby, they focus on making common scripting type tasks easy, which often involves giving the programming less control over the machine. But at the same time, they don’t introduce any opinionated language abstractions like monads, a borrow checker, and actor threading model, etc. It also just shouldn’t be that wordy or type-heavy in a way that would slow down prototyping.
Traditional scripting languages have been dynamically types. But I think they can still be statically typed (like this language is trying to do). There isn’t a hard boundary, but once you are “too far into the weeds”, you notice that you are too far into weeds and not in scripting language territory anymore.