6 ms·

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 sma

by cjdell 3y ago

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 3y ago
There have been statically types scripting languages for ages. Embeddable ones, too. That's not new.
- cjdell 3y ago
  Any in particular that you're a fan of? (Genuinely curious)
  - jlokier 3y ago
    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.
  - otteromkram 3y ago
    If you don't want to run awkward searches through your main Google account, DuckDuckGo provides decent results.
    - cjdell 3y ago
      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 3y ago
        Not really sure he has one. I was confused too.
  - mr_ms 3y ago
    I'm a fan or Umka. It is inspired by Go and can be embedded into C programs. https://github.com/vtereshkov/umka-lang https://github.com/vtereshkov/umka-lang
crabbone 3y ago
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.

by cjdell 3y ago

junon 3y ago

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

cjdell 3y ago
Any in particular that you're a fan of? (Genuinely curious)
- jlokier 3y ago
  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.
- otteromkram 3y ago
  If you don't want to run awkward searches through your main Google account, DuckDuckGo provides decent results.
  - cjdell 3y ago
    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 3y ago
      Not really sure he has one. I was confused too.
- mr_ms 3y ago
  I'm a fan or Umka. It is inspired by Go and can be embedded into C programs. https://github.com/vtereshkov/umka-lang https://github.com/vtereshkov/umka-lang

crabbone 3y ago

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.