5 ms·

Damn it - another unique Racket feature stops being unique. I hoped that in 2020 Racket will be around 5th position in "the most popular language" rankings wit

Damn it - another unique Racket feature stops being unique. I hoped that in 2020 Racket will be around 5th position in "the most popular language" rankings with Clojure in the first ten too. Now it looks like Clojure is taking the lead - maybe Racket2 will change this again. But hey, either way that's a popular, mainstream Lisp! That's unprecedented!

coldtea 13y ago
>I hoped that in 2020 Racket will be around 5th position in "the most popular language" rankings with Clojure in the first ten too. Now it looks like Clojure is taking the lead - maybe Racket2 will change this again. I don't think will ever see a Lisp in the top 5 most popular rankings (assuming we can measure actual use, which, somewhat roughly, we can). In 2020 we'll probably see imperative and functional imperative hybrids topping the charts.
- adambard 13y ago
  The top languages today all existed by 2000 -- many well before that. C: 1972 C++: 1983 Objective-C: 1983 Python: 1992 PHP: 1995 JavaScript: 1995 Ruby: 1995 Java: 1995 C#: 2000 Of course, these rankings are skewed by existing codebases, but they're still topping the charts. In 2020, the languages at the top of the charts will surely have existed in 2010 -- what imperative-functional hybrid that is presently in use did you have in mind?
  - klibertp 13y ago
    I don't know what specific language GP had in mind, but I would guess it's probably one of OCaml, F# or Scala. Or Rust - did Rust development start before 2010? Or one of the Lisps, where Clojure has a bit "worse" (or better, depending on who you ask:)) imperative story than Racket (the latter has mutable lists and hashes, although they are discouraged and not the default), but both are on the way to popularity (I still believe in this) and have mixed, imperative, generic, OO (Racket) and functional features. Of course Common Lisp, which is similarly a mix of paradigms, has a chance to make a great comeback too. There's also JavaScript, especially with improvements it's going to get in the future, but this damned thing already is 9th according to TIOBE[1]. Honestly, I wouldn't be very disappointed if it proved to be like this. All these languages are interesting and in 7 years time could become true "languages of the future". However, despite hoping so, I don't believe it will come true. Most probably some languages will just move slightly higher with others moving a bit lower. Java will remain in the first 3, at the very least. Maybe Objective-C will swap places with C++ and Python or Ruby (or both) will come close to PHP. That's all I think will change, although it would be nice to see Rust instead of C++ for example or Clojure in place of (Visual) Basic. Also, all the currently most popular languages are this young because there was a major paradigm shift from imperative to OO in the '80. Without similar shift happening sometime soon we will be stuck with Java not just to 2020, but to 2040 at least :) [1] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
  - coldtea 13y ago
    Well, by "imperative-functional hybrid" I wasn't going for maximul functional-ness, e.g something like Ocaml or F#. I was referering to stuff in the current trend of imperative languages with added functional capabilities (from first class functions to closures to macros) and used with a dash (or several) of functional idioms. So stuff like C#, Scala, etc would qualify. Javascript and Ruby too. And Rust, if it hits off. And I also had in mind how those and their libs would evolve more "functionaly" going forward to 2020.
kenko 13y ago
You can take solace in the fact that Typed Racket actually does optimizations based on the types. Typed Clojure is more like a linter, AFAICT.
- swannodette 13y ago
  Typed Racket does some optimization based on types and the feature is completely orthogonal to type checking. If Typed Clojure is a linter then so is the type checking phase of every typed programming language.
  - kenko 13y ago
    Ambrose explicitly likened Typed Clojure to Erlang's Dialyzer on the Clojure mailing list. The description of Dialyzer on erlang.org, "a static analysis tool that identifies software discrepancies such as type errors, unreachable code, unnecessary tests, etc.", strikes me as lint-like. It may be true that the type-checking phase of every typed programming language is, in this respect, lint-like. A typed language's implementation is obviously not required to stop with ensuring that the types check out. It can use the information so derived to do further things, including introduce optimizations. Insofar as Typed Racket does optimizations based on types it's hard to see how it can be completely orthogonal to type checking, on pain of the optimizations being potentially incorrect; insofar as the optimizations are based on types, it's a use of a type system beyond what Typed Clojure currently offers.
    - kenko 13y ago
      MY MISTAKE: it wasn't Ambrose but someone else (Michael Klishin) who compared Typed Clojure to Dialyzer.
6cxs2hd6 13y ago
Racket remains special at a deeper level, AFAICT. At first glance, it's a wonderful, modern, practical Lisp with many batteries included. Which it is. You can use it as just that. But also, it is a remarkable language for making languages that can interoperate. For example you can freely mix `#lang racket` with `#lang typed/racket` modules, as well as with `#lang my-little-dsl`. The combination of `#lang`s and macros is seriously wicked good. My own hope is that Clojure will open many more eyes to Lispy ways (including reducing paren-phobia) --- and then many of those people will go on to discover and love Racket, too. Indeed already I see people who seem to appreciate and use both Clojure and Racket. I expect that will increase.
- klibertp 13y ago
  I hope for this too. I really appreciate a "language builder toolkit" part of Racket, although I didn't use it very much yet, I only mixed typed/racket, racket and lazy, which was - as you say - seamless and very impressive. Clojure obviously lacks many features in this area and probably always will be lacking them, because it's not it's focus. As you say, if Clojure's success helps Racket adoption, then I have no complaints at all. It would be great if people used both Racket and Clojure, one for (almost) seamless interop with C and custom DSLs, the other for interop with Java and concurrency - for example. I still have hope and believe that Racket will become a successful language. I love Racket and prefer it to Clojure, that's true, but I really hope for Clojure's success too. As I said, they're both Lisps, and having even only one of them "succeed" (in terms of mainstream adoption, they're greatly successful as it is already in their niches) will make me happy. I will be a bit more happy if the one to succeed will be Racket, but I will be overcome with joy when they succeed both. :)
graue 13y ago
The presence in Clojure of persistent vectors and hashmaps, which are very, very fast, and are used pervasively throughout the core libraries and Clojure code at large, makes it way more interesting to me than other Lisps I've seen. Does modern Racket have anything comparable to Clojure's collection primitives? My introduction to Lisp, some years ago, was reading The Little Schemer, which I loved. Afterwards, I was very disillusioned when I needed an array and learned the canonical solution was to use mutable arrays and set! (as if adding a bang after its name made it less of a sin). I understand why it's like that: persistent data structures are tricky to implement efficiently, and Scheme emphasizes simplicity of implementation. But it still bums me out.
- 6cxs2hd6 13y ago
  Standard datatypes and generics (including hash tables, dictionaries, vectors, sets, sequences, streams, etc.): http://docs.racket-lang.org/reference/data.html http://docs.racket-lang.org/reference/data.html Additional datatypes (including imperative queues, growable vectors, orders and ordered dictionaries, splay trees, skip lists, interval maps, binary heaps, integer sets, bit vectors, etc.): http://docs.racket-lang.org/data/index.html http://docs.racket-lang.org/data/index.html
  - chongli 13y ago
    Are all of those standard datatypes thread-safe? If not, they are not what the parent was asking for. Clojure's maps, sets and vectors are all thread-safe due to being immutable. They're all built-in to the standard library and have extremely slick syntactic sugar. Sure, you could implement all of this in Racket, I'm not saying you couldn't; the advantage with Clojure is that these things are standard and that everybody else's libraries make use of this stuff. This is probably the biggest advantage with starting any new programming language: you get a chance to redo the standard library (and tie it into some syntactic sugar) without worrying about compatibility.
    - klibertp 13y ago
      > Are all of those standard datatypes thread-safe? Some of them have both mutable and immutable versions (lists, hashes) where immutability is the default, some are purely functional (Okasaki's data structures implementation https://pkg.racket-lang.org/info/pfds https://pkg.racket-lang.org/info/pfds), and some are mutable by default (the "data" package). Most of the stdlib is immutable by default or plain immutable. There is no "slick" syntactic sugar for these by default, but Racket being as good in "language creation" department as it is, there are 3rd party implementations (https://github.com/greghendershott/rackjure https://github.com/greghendershott/rackjure). > the advantage with Clojure is that these things are standard and that everybody else's libraries make use of this stuff For the most part it is true for Racket, too. Where it differs is syntactic sugar and more complex data structures; I think some of this will change in racket2 (which is being planned if I understand correctly). > you get a chance to redo the standard library (and tie it into some syntactic sugar) without worrying about compatibility. That's why every "racket" program starts with a #lang specifier. Racket, in reality, is many different languages at once; because of this design and matching implementation, there is absolutely no problem with redoing stdlib and syntax completely - you can write Racket that is lazy, that is FRP, that is Algol(try it, it's fun!) that is typed or is logic oriented (http://en.wikipedia.org/wiki/Datalog http://en.wikipedia.org/wiki/Datalog) already. And you can mix modules written in them freely and conveniently (provide in one and require form in the other module are all it takes in practice). This alone makes Racket so much more flexible than any other language. What Racket lacks now to implement everything Clojure (and other languages) offers as one of the Racket languages are only man-hours of development team. Other, less complicated features from other languages are being ported all the time, for example generator function in a Python style (with yield) implementation is in a stdlib since a long time, so I believe assimilating proven concepts from other languages is both possible and a "Racket way".

coldtea 13y ago

>I hoped that in 2020 Racket will be around 5th position in "the most popular language" rankings with Clojure in the first ten too. Now it looks like Clojure is taking the lead - maybe Racket2 will change this again. I don't think will ever see a Lisp in the top 5 most popular rankings (assuming we can measure actual use, which, somewhat roughly, we can). In 2020 we'll probably see imperative and functional imperative hybrids topping the charts.

adambard 13y ago
The top languages today all existed by 2000 -- many well before that. C: 1972 C++: 1983 Objective-C: 1983 Python: 1992 PHP: 1995 JavaScript: 1995 Ruby: 1995 Java: 1995 C#: 2000 Of course, these rankings are skewed by existing codebases, but they're still topping the charts. In 2020, the languages at the top of the charts will surely have existed in 2010 -- what imperative-functional hybrid that is presently in use did you have in mind?
- klibertp 13y ago
  I don't know what specific language GP had in mind, but I would guess it's probably one of OCaml, F# or Scala. Or Rust - did Rust development start before 2010? Or one of the Lisps, where Clojure has a bit "worse" (or better, depending on who you ask:)) imperative story than Racket (the latter has mutable lists and hashes, although they are discouraged and not the default), but both are on the way to popularity (I still believe in this) and have mixed, imperative, generic, OO (Racket) and functional features. Of course Common Lisp, which is similarly a mix of paradigms, has a chance to make a great comeback too. There's also JavaScript, especially with improvements it's going to get in the future, but this damned thing already is 9th according to TIOBE[1]. Honestly, I wouldn't be very disappointed if it proved to be like this. All these languages are interesting and in 7 years time could become true "languages of the future". However, despite hoping so, I don't believe it will come true. Most probably some languages will just move slightly higher with others moving a bit lower. Java will remain in the first 3, at the very least. Maybe Objective-C will swap places with C++ and Python or Ruby (or both) will come close to PHP. That's all I think will change, although it would be nice to see Rust instead of C++ for example or Clojure in place of (Visual) Basic. Also, all the currently most popular languages are this young because there was a major paradigm shift from imperative to OO in the '80. Without similar shift happening sometime soon we will be stuck with Java not just to 2020, but to 2040 at least :) [1] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
- coldtea 13y ago
  Well, by "imperative-functional hybrid" I wasn't going for maximul functional-ness, e.g something like Ocaml or F#. I was referering to stuff in the current trend of imperative languages with added functional capabilities (from first class functions to closures to macros) and used with a dash (or several) of functional idioms. So stuff like C#, Scala, etc would qualify. Javascript and Ruby too. And Rust, if it hits off. And I also had in mind how those and their libs would evolve more "functionaly" going forward to 2020.

kenko 13y ago

You can take solace in the fact that Typed Racket actually does optimizations based on the types. Typed Clojure is more like a linter, AFAICT.

swannodette 13y ago
Typed Racket does some optimization based on types and the feature is completely orthogonal to type checking. If Typed Clojure is a linter then so is the type checking phase of every typed programming language.
- kenko 13y ago
  Ambrose explicitly likened Typed Clojure to Erlang's Dialyzer on the Clojure mailing list. The description of Dialyzer on erlang.org, "a static analysis tool that identifies software discrepancies such as type errors, unreachable code, unnecessary tests, etc.", strikes me as lint-like. It may be true that the type-checking phase of every typed programming language is, in this respect, lint-like. A typed language's implementation is obviously not required to stop with ensuring that the types check out. It can use the information so derived to do further things, including introduce optimizations. Insofar as Typed Racket does optimizations based on types it's hard to see how it can be completely orthogonal to type checking, on pain of the optimizations being potentially incorrect; insofar as the optimizations are based on types, it's a use of a type system beyond what Typed Clojure currently offers.
  - kenko 13y ago
    MY MISTAKE: it wasn't Ambrose but someone else (Michael Klishin) who compared Typed Clojure to Dialyzer.

6cxs2hd6 13y ago

Racket remains special at a deeper level, AFAICT. At first glance, it's a wonderful, modern, practical Lisp with many batteries included. Which it is. You can use it as just that. But also, it is a remarkable language for making languages that can interoperate. For example you can freely mix `#lang racket` with `#lang typed/racket` modules, as well as with `#lang my-little-dsl`. The combination of `#lang`s and macros is seriously wicked good. My own hope is that Clojure will open many more eyes to Lispy ways (including reducing paren-phobia) --- and then many of those people will go on to discover and love Racket, too. Indeed already I see people who seem to appreciate and use both Clojure and Racket. I expect that will increase.

klibertp 13y ago
I hope for this too. I really appreciate a "language builder toolkit" part of Racket, although I didn't use it very much yet, I only mixed typed/racket, racket and lazy, which was - as you say - seamless and very impressive. Clojure obviously lacks many features in this area and probably always will be lacking them, because it's not it's focus. As you say, if Clojure's success helps Racket adoption, then I have no complaints at all. It would be great if people used both Racket and Clojure, one for (almost) seamless interop with C and custom DSLs, the other for interop with Java and concurrency - for example. I still have hope and believe that Racket will become a successful language. I love Racket and prefer it to Clojure, that's true, but I really hope for Clojure's success too. As I said, they're both Lisps, and having even only one of them "succeed" (in terms of mainstream adoption, they're greatly successful as it is already in their niches) will make me happy. I will be a bit more happy if the one to succeed will be Racket, but I will be overcome with joy when they succeed both. :)

graue 13y ago

The presence in Clojure of persistent vectors and hashmaps, which are very, very fast, and are used pervasively throughout the core libraries and Clojure code at large, makes it way more interesting to me than other Lisps I've seen. Does modern Racket have anything comparable to Clojure's collection primitives? My introduction to Lisp, some years ago, was reading The Little Schemer, which I loved. Afterwards, I was very disillusioned when I needed an array and learned the canonical solution was to use mutable arrays and set! (as if adding a bang after its name made it less of a sin). I understand why it's like that: persistent data structures are tricky to implement efficiently, and Scheme emphasizes simplicity of implementation. But it still bums me out.

6cxs2hd6 13y ago
Standard datatypes and generics (including hash tables, dictionaries, vectors, sets, sequences, streams, etc.): http://docs.racket-lang.org/reference/data.html http://docs.racket-lang.org/reference/data.html Additional datatypes (including imperative queues, growable vectors, orders and ordered dictionaries, splay trees, skip lists, interval maps, binary heaps, integer sets, bit vectors, etc.): http://docs.racket-lang.org/data/index.html http://docs.racket-lang.org/data/index.html
- chongli 13y ago
  Are all of those standard datatypes thread-safe? If not, they are not what the parent was asking for. Clojure's maps, sets and vectors are all thread-safe due to being immutable. They're all built-in to the standard library and have extremely slick syntactic sugar. Sure, you could implement all of this in Racket, I'm not saying you couldn't; the advantage with Clojure is that these things are standard and that everybody else's libraries make use of this stuff. This is probably the biggest advantage with starting any new programming language: you get a chance to redo the standard library (and tie it into some syntactic sugar) without worrying about compatibility.
  - klibertp 13y ago
    > Are all of those standard datatypes thread-safe? Some of them have both mutable and immutable versions (lists, hashes) where immutability is the default, some are purely functional (Okasaki's data structures implementation https://pkg.racket-lang.org/info/pfds https://pkg.racket-lang.org/info/pfds), and some are mutable by default (the "data" package). Most of the stdlib is immutable by default or plain immutable. There is no "slick" syntactic sugar for these by default, but Racket being as good in "language creation" department as it is, there are 3rd party implementations (https://github.com/greghendershott/rackjure https://github.com/greghendershott/rackjure). > the advantage with Clojure is that these things are standard and that everybody else's libraries make use of this stuff For the most part it is true for Racket, too. Where it differs is syntactic sugar and more complex data structures; I think some of this will change in racket2 (which is being planned if I understand correctly). > you get a chance to redo the standard library (and tie it into some syntactic sugar) without worrying about compatibility. That's why every "racket" program starts with a #lang specifier. Racket, in reality, is many different languages at once; because of this design and matching implementation, there is absolutely no problem with redoing stdlib and syntax completely - you can write Racket that is lazy, that is FRP, that is Algol(try it, it's fun!) that is typed or is logic oriented (http://en.wikipedia.org/wiki/Datalog http://en.wikipedia.org/wiki/Datalog) already. And you can mix modules written in them freely and conveniently (provide in one and require form in the other module are all it takes in practice). This alone makes Racket so much more flexible than any other language. What Racket lacks now to implement everything Clojure (and other languages) offers as one of the Racket languages are only man-hours of development team. Other, less complicated features from other languages are being ported all the time, for example generator function in a Python style (with yield) implementation is in a stdlib since a long time, so I believe assimilating proven concepts from other languages is both possible and a "Racket way".