3 ms·

Can we have a REPL-driven language that's statically typed? My hope is yes, in that it's just that the work hasn't been put in yet to create to create the equi

Can we have a REPL-driven language that's statically typed? My hope is yes, in that it's just that the work hasn't been put in yet to create to create the equivalent of Typescript for Clojure or Lua that compiles down to the actual, extensible language. I always wish that it would become unnecessary to have to choose between stability and extensibility when selecting a programming language. Having a Clojure with static types or a typed Lua (Teal) would put us so much closer to that goal.

jeofken 5y ago
You certainly can, OCaml and Haskell do. They were sadly not designed with S-expressions though.
cnasc 5y ago
There’s always https://shen-language.github.io/ https://shen-language.github.io/
Blikkentrekker 5y ago
Typed Racket actually has a rather marvelous type system. The following is fine therein and statically type checks: (let ([x (if (condition) "string" (list "a list"))]) (if (string? x) (string-length? x) (length? x))) By process of elimination, because the type of the variable is `(U string? (List-of string?))`, the type checker can prove that if `(string? x)~ be false, the type of `x` must be `list?`, and that `(length x)` succeeds.
Jach 5y ago
There's always Common Lisp using the popular SBCL implementation. It's not statically typed but you still get compiler warnings about types at compile time -- even cooler is that SBCL uses the types for assembly code optimization, so it can also guide you to write faster code with type warnings, e.g. about places where it couldn't infer the type and is forced to use a generic addition. https://news.ycombinator.com/item?id=14780381 https://news.ycombinator.com/item?id=14780381 shows a few errors that provide typo protection, no type declaring needed https://news.ycombinator.com/item?id=13389287 https://news.ycombinator.com/item?id=13389287 shows the optimization warnings https://news.ycombinator.com/item?id=12222404 https://news.ycombinator.com/item?id=12222404 shows it can even delete unused code thanks to type inference There's also a handful of attempts to bring stricter type checking guarantees on top as a library, but I haven't experimented with those. I'm very much in the crowd that doesn't find static types very valuable (apart from aiding performance) even for multi-million-line projects, but if I can get a few non-strict warnings like SBCL gives, that's a nice bonus, much like running a concurrent linter for extra warnings in <any lang>. I liked Clojure a lot, but fell out of love once I realized how much it's still missing from the Common Lisp it was inspired from (non-bonkers OOP, condition system, and reader macros being the biggest to me), and also how its pervasive laziness is something I'd rather opt in to than vice versa. Some people feel the same about its immutability-by-default structures, I don't mind either way. (e.g. I can opt in to them in CL, that's fine, and Clojure's ways of opting out of them aren't bad either.)
valenterry 5y ago
Scala for example is statically typed and had a REPL from day 1. However, when using a language with a great typesystem, the need for a REPL is just much less. You mostly don't need to try things out because the types guide you. Therefore these languages might have a REPL and it might be useful, but REPL-driven is not really necessary. > I always wish that it would become unnecessary to have to choose between stability and extensibility Stability, extensibility, low language-complexity. Pick 2.
- jim90 5y ago
  I'd argue Clojure has all 3 Stability - one of Clojure's core tenets. Low language complexity - not much more than EDN and everything is an expression, plus a few extras like destructuring. Certainly simpler than any other language I have used. Extensibility - again, one of Clojure's strong points with macros. As for "Type systems removing the value of a repl" again, I disagree. Repl driven development is as much about exploring the problem than it is writing code.
  - valenterry 5y ago
    Stability in this context means "can make changes with confidence in the absence of tests". The more confident you can be, the more stable. Maybe not the right word though. > Repl driven development is as much about exploring the problem than it is writing code. Which is exactly what types give you. This even coined the term "type driven development" (same as "test driven development" on purpose").
    - tome 5y ago
      > Stability in this context means "can make changes with confidence in the absence of tests". The more confident you can be, the more stable. Maybe not the right word though. I'd call it "robustness".
mark_l_watson 5y ago
As I said elsewhere in this thread, Haskell has a good REPL dev experience. Personally, I am a much better Lisp programmer (used Lisp languages since around 1978) than Haskell. My journey learning Haskell is almost a decade long, and still I am no where near as productive as using Common Lisp. I find that Clojure is usually a high productivity language, but I get stuck sometimes on platform details and that gets me out of a flow programming experience. If you want to try Haskell, work though a few tutorials and if it looks good, you can grab a free copy of my Haskell book https://markwatson.com/opencontent/haskell-cookbook.pdf https://markwatson.com/opencontent/haskell-cookbook.pdf There are much better Haskell books than mine though, my book just reflects my own learning process.
mikelevins 5y ago
Depends on what you mean by "repl-driven". If you mean a statically-typed language with a decent repl, then yes, you can have that--for example there are Haskell and ML implementations that give it to you. If you mean "repl-driven" in a stronger sense, in the sense of a livecoding repl-driven environment that supports building programs by interactively modifying them as they run, then about the only place you find full-featured support for that style of programming is in old-fashioned Lisp and Smalltalk systems. Maybe also in Factor, and arguably in FORTH (though with fewer conveniences). There's no reason in principle that you can't have a full-featured repl-driven environment for a statically-typed language; I just don't know of any. That's not a big surprise, though. There aren't all that many of them for dynamically-typed languages, either. It takes a lot of work to build one, and the builders pretty much need to know up front what it is they're trying to build, which means they probably need to have seen one before. Most programmers haven't. Static types aren't particularly an obstacle, but strong immutability is. A full-featured repl-driven livecoding environment wants the programmer to be able to inspect and change anything and everything in the live environment as it runs. Soft immutability is fine; it's okay if you have to say "Mother, may I?" before changing something. Hard immutability is a problem, though. If it's actually _impossible_ to change something, that's incompatible with the nature of a repl-driven livecoding environment. A programmer accustomed to livecoding environments will experience that impossibility as a bug in the environment.
dudul 5y ago
Can you define REPL-driven here? because just to name 2, Scala and Haskell have a very good REPL.
- nonbirithm 5y ago
  Maybe what I should have said was something along the lines of an "iterative language." Essentially I was thinking of a language where you can reload the functions/types in a single module and see the results instantly without restarting. The shortening of the feedback loop is the important part. And also important is being able to take some code and put it in a REPL to find out what it does or modify it until it's just right. One language which is explicitly designed to have first-class hotloading support and static types is Mun. It's not production ready, but it was born out of frustration over the dynamically typed nature of Lua while appreciating the benefits it brought to extensibility and rapid prototyping. https://mun-lang.org/ https://mun-lang.org/ For me Lua has the iterative part, but no types. The iterative part makes LÖVE an attractive target for gamejam developers, who don't want to be constrained by compile-restart cycles when they don't yet understand what every aspect of the finished game will look like.

jeofken 5y ago

You certainly can, OCaml and Haskell do. They were sadly not designed with S-expressions though.

cnasc 5y ago

There’s always https://shen-language.github.io/ https://shen-language.github.io/

Blikkentrekker 5y ago

Typed Racket actually has a rather marvelous type system. The following is fine therein and statically type checks: (let ([x (if (condition) "string" (list "a list"))]) (if (string? x) (string-length? x) (length? x))) By process of elimination, because the type of the variable is `(U string? (List-of string?))`, the type checker can prove that if `(string? x)~ be false, the type of `x` must be `list?`, and that `(length x)` succeeds.

Jach 5y ago

There's always Common Lisp using the popular SBCL implementation. It's not statically typed but you still get compiler warnings about types at compile time -- even cooler is that SBCL uses the types for assembly code optimization, so it can also guide you to write faster code with type warnings, e.g. about places where it couldn't infer the type and is forced to use a generic addition. https://news.ycombinator.com/item?id=14780381 https://news.ycombinator.com/item?id=14780381 shows a few errors that provide typo protection, no type declaring needed https://news.ycombinator.com/item?id=13389287 https://news.ycombinator.com/item?id=13389287 shows the optimization warnings https://news.ycombinator.com/item?id=12222404 https://news.ycombinator.com/item?id=12222404 shows it can even delete unused code thanks to type inference There's also a handful of attempts to bring stricter type checking guarantees on top as a library, but I haven't experimented with those. I'm very much in the crowd that doesn't find static types very valuable (apart from aiding performance) even for multi-million-line projects, but if I can get a few non-strict warnings like SBCL gives, that's a nice bonus, much like running a concurrent linter for extra warnings in <any lang>. I liked Clojure a lot, but fell out of love once I realized how much it's still missing from the Common Lisp it was inspired from (non-bonkers OOP, condition system, and reader macros being the biggest to me), and also how its pervasive laziness is something I'd rather opt in to than vice versa. Some people feel the same about its immutability-by-default structures, I don't mind either way. (e.g. I can opt in to them in CL, that's fine, and Clojure's ways of opting out of them aren't bad either.)

valenterry 5y ago

Scala for example is statically typed and had a REPL from day 1. However, when using a language with a great typesystem, the need for a REPL is just much less. You mostly don't need to try things out because the types guide you. Therefore these languages might have a REPL and it might be useful, but REPL-driven is not really necessary. > I always wish that it would become unnecessary to have to choose between stability and extensibility Stability, extensibility, low language-complexity. Pick 2.

jim90 5y ago
I'd argue Clojure has all 3 Stability - one of Clojure's core tenets. Low language complexity - not much more than EDN and everything is an expression, plus a few extras like destructuring. Certainly simpler than any other language I have used. Extensibility - again, one of Clojure's strong points with macros. As for "Type systems removing the value of a repl" again, I disagree. Repl driven development is as much about exploring the problem than it is writing code.
- valenterry 5y ago
  Stability in this context means "can make changes with confidence in the absence of tests". The more confident you can be, the more stable. Maybe not the right word though. > Repl driven development is as much about exploring the problem than it is writing code. Which is exactly what types give you. This even coined the term "type driven development" (same as "test driven development" on purpose").
  - tome 5y ago
    > Stability in this context means "can make changes with confidence in the absence of tests". The more confident you can be, the more stable. Maybe not the right word though. I'd call it "robustness".

mark_l_watson 5y ago

As I said elsewhere in this thread, Haskell has a good REPL dev experience. Personally, I am a much better Lisp programmer (used Lisp languages since around 1978) than Haskell. My journey learning Haskell is almost a decade long, and still I am no where near as productive as using Common Lisp. I find that Clojure is usually a high productivity language, but I get stuck sometimes on platform details and that gets me out of a flow programming experience. If you want to try Haskell, work though a few tutorials and if it looks good, you can grab a free copy of my Haskell book https://markwatson.com/opencontent/haskell-cookbook.pdf https://markwatson.com/opencontent/haskell-cookbook.pdf There are much better Haskell books than mine though, my book just reflects my own learning process.

mikelevins 5y ago

Depends on what you mean by "repl-driven". If you mean a statically-typed language with a decent repl, then yes, you can have that--for example there are Haskell and ML implementations that give it to you. If you mean "repl-driven" in a stronger sense, in the sense of a livecoding repl-driven environment that supports building programs by interactively modifying them as they run, then about the only place you find full-featured support for that style of programming is in old-fashioned Lisp and Smalltalk systems. Maybe also in Factor, and arguably in FORTH (though with fewer conveniences). There's no reason in principle that you can't have a full-featured repl-driven environment for a statically-typed language; I just don't know of any. That's not a big surprise, though. There aren't all that many of them for dynamically-typed languages, either. It takes a lot of work to build one, and the builders pretty much need to know up front what it is they're trying to build, which means they probably need to have seen one before. Most programmers haven't. Static types aren't particularly an obstacle, but strong immutability is. A full-featured repl-driven livecoding environment wants the programmer to be able to inspect and change anything and everything in the live environment as it runs. Soft immutability is fine; it's okay if you have to say "Mother, may I?" before changing something. Hard immutability is a problem, though. If it's actually _impossible_ to change something, that's incompatible with the nature of a repl-driven livecoding environment. A programmer accustomed to livecoding environments will experience that impossibility as a bug in the environment.

dudul 5y ago

Can you define REPL-driven here? because just to name 2, Scala and Haskell have a very good REPL.

nonbirithm 5y ago
Maybe what I should have said was something along the lines of an "iterative language." Essentially I was thinking of a language where you can reload the functions/types in a single module and see the results instantly without restarting. The shortening of the feedback loop is the important part. And also important is being able to take some code and put it in a REPL to find out what it does or modify it until it's just right. One language which is explicitly designed to have first-class hotloading support and static types is Mun. It's not production ready, but it was born out of frustration over the dynamically typed nature of Lua while appreciating the benefits it brought to extensibility and rapid prototyping. https://mun-lang.org/ https://mun-lang.org/ For me Lua has the iterative part, but no types. The iterative part makes LÖVE an attractive target for gamejam developers, who don't want to be constrained by compile-restart cycles when they don't yet understand what every aspect of the finished game will look like.