11 ms·

I wonder if Blow has ever looked at Nim. Sometimes I hallucinate that game devs will have an Awakening and realize it's the way forward.

aerique 11y ago
I've got the same dream but about Lispy languages, preferably Common Lisp. I'm sure more people around here have the same dream about their favorite language :-)
- whitegrape 11y ago
  Every now and again when I'm really figuratively toked up I go reread the history of Crash Bandicoot and also dream for more Lisp in the games industry (and every other industry). :) But I think Nim is slightly more realistic.
- davexunit 11y ago
  I look at all these new languages with horrificly complicated syntax and wish for s-expressions. Lisp is perfectly well suited for game development, too, and not just for scripting. There are many implementations around with fast optimizing compilers, JIT compilers, and other modern features that make things run fast. When I see languages like what Jonathan Blow made, I think that most of the features can be implemented as extensions to your Lisp of choice.
  - basketcasing 11y ago
    The one thing that keeps me away from Lisp/Scheme is the lack of built-in syntax for hashmaps and sets (I like Clojure's syntax, but don't want the JVM). I've never gotten the hang of car/cdr and dotted pairs.
    - davexunit 11y ago
      I don't think this is a particularly large problem. Traditional hash tables are imperative data structures, and Lisp code (or Scheme code, at least) typically does not use them because of this. Association lists, which can be represented as literals, are persistent and provider faster lookup, despite being O(n), for the cases in which hash literals are typically used (small number of pairs). The Clojure language has built-in persistent hash tables and sets, so it makes sense for them to have a reader that can process them. I really don't think this is a deal breaker though, when you can just do stuff like this: (alist->hash-table '((foo . 1) (bar . 2)))
      - basketcasing 11y ago
        > Traditional hash tables are imperative data structures, and Lisp code (or Scheme code, at least) typically does not use them because of this. I don't understand that. > Association lists, which can be represented as literals, are persistent and provider faster lookup, despite being {snip} Those look like like they could be useful, but I don't see how they can replace hashmaps --- for one thing, they allow duplicate "keys" (the first element of each pair). I'd use a lisp, and don't mind the lisp/parens syntax, but to be useful for me it must provide easy access to and use of hashmaps and sets.
        davexunit 11y ago
        >I don't understand that. Introducing state into programs makes them harder to reason about, thus Scheme programmers generally discourage the use of mutable data structures when a persistent data structure would have worked. >Those look like like they could be useful, but I don't see how they can replace hashmaps --- for one thing, they allow duplicate "keys" (the first element of each pair). The way alists are used, only the first pair to contain the desired key is considered. Thus, you can "overwrite" a key/value pair by consing a new pair onto the head of the list. >I'd use a lisp, and don't mind the lisp/parens syntax, but to be useful for me it must provide easy access to and use of hashmaps and sets. I had the same initial complaints about the lack of reader syntax for hash table. It's a common complaint, actually. However, I found that as I learned more about how to write Scheme, I stopped using hash tables in any place where I used to want literal syntax for them. I learned that people reach for mutable hash tables far too frequently when there are better options available. What languages even have literal syntax for sets? I can't think of any, but I'd like to know. Reader syntax varies in each language, but I hope you can see that this really isn't a big problem at all.
        whitegrape 11y ago
        Clojure has syntax for sets. I really like Clojure's data literals. I even think there's a Common Lisp package (or two) out there implementing reader macros to allow Clojure's syntax, but I don't think it's popular among Lispers.
  - hacker_9 11y ago
    When we look at Lisp we see archaic user interfaces, legacy keywords such as car, cdr and cons which bear no meaning to us mere mortals. Also no clear consensus on what extensions to use. Why are there so many dialects? Can you not agree on something that works? Where is your IDE with error underlining and autocomplete list that comes up with each keystroke? And finally s-expressions, which make you twist your mind in order to write and don't give clear structure of the code meaning to the reader, and not even considering macros... Not trying to start an argument, but that's my view from a C#'er who tried Lisp a while ago. I often see Lisp talked about on HN as though it's the solution to all our problems, but it's really not. Syntax is a big deal in programming languages, with lots of trade offs between human readability and unambiguous parsing by the computer, and s-exps aren't some magic bullet for this.
    - lispm 11y ago
      > Why are there so many dialects? That's a really funny question in a thread about another new programming language.
    - davexunit 11y ago
      >When we look at Lisp we see archaic user interfaces, legacy keywords such as car, cdr and cons which bear no meaning to us mere mortals. Also no clear consensus on what extensions to use. Car, cdr, and cons take very little time to understand, but yes their meaning is steeped in history. "car" returns the first element of a pair, "cdr" (pronounced like "could-er") returns the second element of a pair, and "cons" creates pairs. Not that bad. However, today's Lisps put more emphasis on using pattern matchers than manually car/cdring down lists. >Why are there so many dialects? That's like asking "Why are there so many ALGOL derivatives?" Lisp classifies a family of languages, not a single language. It's like saying something has C-like syntax. >Can you not agree on something that works? Given the above misunderstanding, this question is no longer relevant. >Where is your IDE with error underlining and autocomplete list that comes up with each keystroke? A lot of Lisp hackers use Emacs with a few extensions. I am a Guile Scheme user, so I can only speak for my setup: Emacs, Paredit, and Geiser. Paredit provides efficient, and powerful structured editing support for s-expressions. Geiser provides REPL integration. Geiser can autocomplete symbols, jump to the definition points of variables, display documentation for a procedure or macro, show the values of variables under the cursor in the modeline, show function signatures in the modeline, and allow instant evaluation of arbitrary expressions with a simple keystroke (including jumping to the debugger when things go wrong), and probably some other things that I'm forgetting. It is the nicest development environment I have ever used. Common Lisp users also like Emacs and Paredit, but they typically use SLIME for REPL integration. > And finally s-expressions, which make you twist your mind in order to write and don't give clear structure of the code meaning to the reader, and not even considering macros... We'll have to disagree here. S-expressions are very nice, once you get used to them, which can be a bit difficult if your background is using C-like languages with infix notation. They remove complexity, make the language more regular (the operator is always the first element of a list, things that are operators in some languages like +, -, etc. are normal procedures that can be used as values), and allow for syntactic abstraction. Not only can you quote arbitrary expressions like '(+ 1 1) and manipulate symbols directly, the macro systems available in various Lisps allow for the creation of new syntax which is one of the most useful features a programming language could have. One of Paul Graham's essays talks about "top down, bottom up" design where the "bottom up" part involves defining new syntax when patterns emerge in your problem domain that you'd like to express in a more readable and less redundant way. Lisp allows you to build the language suitable for your problem. You seem to imply that macros are bad, but I think that languages that do not offer a macro system are fundamentally limited in the problems they are suited for solving. I by no means claim that s-expressions are a magic bullet, but I think you are biased in saying that they are inherently less readable than more complex syntaxes. There's a lot of mystique and misunderstanding around Lisp, and I hope I have cleared up a thing or two.
  - CyberDildonics 11y ago
    garbage collection and a language that doesn't run as fast as performance minded C++ are not going to be used in hardcore game programming. You don't have control over the memory allocation or layout. For non native game programming there are many many choices.
    - davexunit 11y ago
      This shows a bias that high-level languages do not have native code compilers that can generate faster code than what someone writes in C/C++. This is not true. Some of these compilers can produce better native code because the language lets you write better code in the first place.
      - CyberDildonics 11y ago
        I wasn't talking about all high level languages, just LISP. My experience is that people who like a particular language try to rationalize and convince others that there is no downside. I would love to see and example of LISP being as fast as C++ with multi-threading and cache coherency taken into account, using the same amount of memory, with no pauses from the gc that would affect interactivity. If it hasn't happened in the last half century though, I don't think it's going to happen at all.
        davexunit 11y ago
        > My experience is that people who like a particular language try to rationalize and convince others that there is no downside. There are always trade-offs. GC is a win because manual memory management is terrible and error prone, but a lose because you have to learn how to tune it to behave the way you need. But no matter the language some things stay the same: learn to anticipate what code your compiler is going to generate, check what the optimizer is doing, check the disassembly, use the profiler. Good GCs and compilers play all the same games with cache locality and such, and some are better than others. I think you are underestimating the advances in compiler design. Maybe you think C/C++ are fine languages, and that's OK, but personally they are the absolute last resort for when I reach limitations of my language's compiler and runtime.
- weavie 11y ago
  Yes, how much fun folks could have if you could connect a Repl into your game and arbitrarily change the rules on the fly!
  - davexunit 11y ago
    (shameless plug alert) This is how my WIP (verrrry WIP) game engine written in Guile Scheme works. It is built explicitly to enable iterative, live development. 2 year old video of a precursor to the current project: https://dthompson.us/functional-reactive-programming-in-scheme-with-guile-2d.html https://dthompson.us/functional-reactive-programming-in-sche... Simple example program: https://git.dthompson.us/sly.git/blob/HEAD:/examples/simple.scm https://git.dthompson.us/sly.git/blob/HEAD:/examples/simple.... More complicated minesweeper example: https://git.dthompson.us/sly.git/blob/HEAD:/examples/mines/mines.scm https://git.dthompson.us/sly.git/blob/HEAD:/examples/mines/m... Home page: https://dthompson.us/pages/software/sly.html https://dthompson.us/pages/software/sly.html Hoping to get a 0.2 release out the door in time for the Lisp Game Jam coming up in April.
  - CyberDildonics 11y ago
    You can do that right now with Love2D and a stub game loop that sources the actual implementations every second or two.
    - davexunit 11y ago
      That is a far cry from a REPL.
      - CyberDildonics 11y ago
        It's better than a REPL, that allows you to write a game completely live. I'm not sure what you think is lost since you didn't back up what you are saying with anything.
        davexunit 11y ago
        It is strictly less powerful than a REPL. Claiming that you can't live code a game at a REPL is false, because I do it on a regular basis. When I write games in Scheme, I use a REPL to write the game live, doing all of my editing within Emacs. I do not have to save files for the code to be evaluated, I just press a keystroke to evaluate the specific form I'm interested in. I can evaluate more fine-grained sections of code, not only entire files.
CyberDildonics 11y ago
Doesn't Nim use garbage collection? Also the compiler isn't even stable, it is an interesting language but can't be take seriously for professional development yet.
- whitegrape 11y ago
  Use of GC in Nim is up to you -- you can malloc/free as you please if you want and avoid it altogether. I'm not sure to what extent you can/can't make use of the standard library if you avoid GC, but even if you lessen your restrictions and use it a little bit, it's a highly tuneable/controllable and understandable GC including support for swapping out entirely different GC algorithms. Professional game development as in AAA studios? Yeah, probably not, but more for the tooling alone than whatever language any particular studio happens to use. Professional indie game development? It's ready, even though it's not at 1.0 yet. Indie devs deal with big breaking upgrades to their frameworks (Unity, Corona, etc.) all the time, it's annoying but not a deal-breaker if the language gets those sometimes too.

aerique 11y ago

I've got the same dream but about Lispy languages, preferably Common Lisp. I'm sure more people around here have the same dream about their favorite language :-)

whitegrape 11y ago
Every now and again when I'm really figuratively toked up I go reread the history of Crash Bandicoot and also dream for more Lisp in the games industry (and every other industry). :) But I think Nim is slightly more realistic.
davexunit 11y ago
I look at all these new languages with horrificly complicated syntax and wish for s-expressions. Lisp is perfectly well suited for game development, too, and not just for scripting. There are many implementations around with fast optimizing compilers, JIT compilers, and other modern features that make things run fast. When I see languages like what Jonathan Blow made, I think that most of the features can be implemented as extensions to your Lisp of choice.
- basketcasing 11y ago
  The one thing that keeps me away from Lisp/Scheme is the lack of built-in syntax for hashmaps and sets (I like Clojure's syntax, but don't want the JVM). I've never gotten the hang of car/cdr and dotted pairs.
  - davexunit 11y ago
    I don't think this is a particularly large problem. Traditional hash tables are imperative data structures, and Lisp code (or Scheme code, at least) typically does not use them because of this. Association lists, which can be represented as literals, are persistent and provider faster lookup, despite being O(n), for the cases in which hash literals are typically used (small number of pairs). The Clojure language has built-in persistent hash tables and sets, so it makes sense for them to have a reader that can process them. I really don't think this is a deal breaker though, when you can just do stuff like this: (alist->hash-table '((foo . 1) (bar . 2)))
    - basketcasing 11y ago
      > Traditional hash tables are imperative data structures, and Lisp code (or Scheme code, at least) typically does not use them because of this. I don't understand that. > Association lists, which can be represented as literals, are persistent and provider faster lookup, despite being {snip} Those look like like they could be useful, but I don't see how they can replace hashmaps --- for one thing, they allow duplicate "keys" (the first element of each pair). I'd use a lisp, and don't mind the lisp/parens syntax, but to be useful for me it must provide easy access to and use of hashmaps and sets.
      - davexunit 11y ago
        >I don't understand that. Introducing state into programs makes them harder to reason about, thus Scheme programmers generally discourage the use of mutable data structures when a persistent data structure would have worked. >Those look like like they could be useful, but I don't see how they can replace hashmaps --- for one thing, they allow duplicate "keys" (the first element of each pair). The way alists are used, only the first pair to contain the desired key is considered. Thus, you can "overwrite" a key/value pair by consing a new pair onto the head of the list. >I'd use a lisp, and don't mind the lisp/parens syntax, but to be useful for me it must provide easy access to and use of hashmaps and sets. I had the same initial complaints about the lack of reader syntax for hash table. It's a common complaint, actually. However, I found that as I learned more about how to write Scheme, I stopped using hash tables in any place where I used to want literal syntax for them. I learned that people reach for mutable hash tables far too frequently when there are better options available. What languages even have literal syntax for sets? I can't think of any, but I'd like to know. Reader syntax varies in each language, but I hope you can see that this really isn't a big problem at all.
        whitegrape 11y ago
        Clojure has syntax for sets. I really like Clojure's data literals. I even think there's a Common Lisp package (or two) out there implementing reader macros to allow Clojure's syntax, but I don't think it's popular among Lispers.
- hacker_9 11y ago
  When we look at Lisp we see archaic user interfaces, legacy keywords such as car, cdr and cons which bear no meaning to us mere mortals. Also no clear consensus on what extensions to use. Why are there so many dialects? Can you not agree on something that works? Where is your IDE with error underlining and autocomplete list that comes up with each keystroke? And finally s-expressions, which make you twist your mind in order to write and don't give clear structure of the code meaning to the reader, and not even considering macros... Not trying to start an argument, but that's my view from a C#'er who tried Lisp a while ago. I often see Lisp talked about on HN as though it's the solution to all our problems, but it's really not. Syntax is a big deal in programming languages, with lots of trade offs between human readability and unambiguous parsing by the computer, and s-exps aren't some magic bullet for this.
  - lispm 11y ago
    > Why are there so many dialects? That's a really funny question in a thread about another new programming language.
  - davexunit 11y ago
    >When we look at Lisp we see archaic user interfaces, legacy keywords such as car, cdr and cons which bear no meaning to us mere mortals. Also no clear consensus on what extensions to use. Car, cdr, and cons take very little time to understand, but yes their meaning is steeped in history. "car" returns the first element of a pair, "cdr" (pronounced like "could-er") returns the second element of a pair, and "cons" creates pairs. Not that bad. However, today's Lisps put more emphasis on using pattern matchers than manually car/cdring down lists. >Why are there so many dialects? That's like asking "Why are there so many ALGOL derivatives?" Lisp classifies a family of languages, not a single language. It's like saying something has C-like syntax. >Can you not agree on something that works? Given the above misunderstanding, this question is no longer relevant. >Where is your IDE with error underlining and autocomplete list that comes up with each keystroke? A lot of Lisp hackers use Emacs with a few extensions. I am a Guile Scheme user, so I can only speak for my setup: Emacs, Paredit, and Geiser. Paredit provides efficient, and powerful structured editing support for s-expressions. Geiser provides REPL integration. Geiser can autocomplete symbols, jump to the definition points of variables, display documentation for a procedure or macro, show the values of variables under the cursor in the modeline, show function signatures in the modeline, and allow instant evaluation of arbitrary expressions with a simple keystroke (including jumping to the debugger when things go wrong), and probably some other things that I'm forgetting. It is the nicest development environment I have ever used. Common Lisp users also like Emacs and Paredit, but they typically use SLIME for REPL integration. > And finally s-expressions, which make you twist your mind in order to write and don't give clear structure of the code meaning to the reader, and not even considering macros... We'll have to disagree here. S-expressions are very nice, once you get used to them, which can be a bit difficult if your background is using C-like languages with infix notation. They remove complexity, make the language more regular (the operator is always the first element of a list, things that are operators in some languages like +, -, etc. are normal procedures that can be used as values), and allow for syntactic abstraction. Not only can you quote arbitrary expressions like '(+ 1 1) and manipulate symbols directly, the macro systems available in various Lisps allow for the creation of new syntax which is one of the most useful features a programming language could have. One of Paul Graham's essays talks about "top down, bottom up" design where the "bottom up" part involves defining new syntax when patterns emerge in your problem domain that you'd like to express in a more readable and less redundant way. Lisp allows you to build the language suitable for your problem. You seem to imply that macros are bad, but I think that languages that do not offer a macro system are fundamentally limited in the problems they are suited for solving. I by no means claim that s-expressions are a magic bullet, but I think you are biased in saying that they are inherently less readable than more complex syntaxes. There's a lot of mystique and misunderstanding around Lisp, and I hope I have cleared up a thing or two.
- CyberDildonics 11y ago
  garbage collection and a language that doesn't run as fast as performance minded C++ are not going to be used in hardcore game programming. You don't have control over the memory allocation or layout. For non native game programming there are many many choices.
  - davexunit 11y ago
    This shows a bias that high-level languages do not have native code compilers that can generate faster code than what someone writes in C/C++. This is not true. Some of these compilers can produce better native code because the language lets you write better code in the first place.
    - CyberDildonics 11y ago
      I wasn't talking about all high level languages, just LISP. My experience is that people who like a particular language try to rationalize and convince others that there is no downside. I would love to see and example of LISP being as fast as C++ with multi-threading and cache coherency taken into account, using the same amount of memory, with no pauses from the gc that would affect interactivity. If it hasn't happened in the last half century though, I don't think it's going to happen at all.
      - davexunit 11y ago
        > My experience is that people who like a particular language try to rationalize and convince others that there is no downside. There are always trade-offs. GC is a win because manual memory management is terrible and error prone, but a lose because you have to learn how to tune it to behave the way you need. But no matter the language some things stay the same: learn to anticipate what code your compiler is going to generate, check what the optimizer is doing, check the disassembly, use the profiler. Good GCs and compilers play all the same games with cache locality and such, and some are better than others. I think you are underestimating the advances in compiler design. Maybe you think C/C++ are fine languages, and that's OK, but personally they are the absolute last resort for when I reach limitations of my language's compiler and runtime.
weavie 11y ago
Yes, how much fun folks could have if you could connect a Repl into your game and arbitrarily change the rules on the fly!
- davexunit 11y ago
  (shameless plug alert) This is how my WIP (verrrry WIP) game engine written in Guile Scheme works. It is built explicitly to enable iterative, live development. 2 year old video of a precursor to the current project: https://dthompson.us/functional-reactive-programming-in-scheme-with-guile-2d.html https://dthompson.us/functional-reactive-programming-in-sche... Simple example program: https://git.dthompson.us/sly.git/blob/HEAD:/examples/simple.scm https://git.dthompson.us/sly.git/blob/HEAD:/examples/simple.... More complicated minesweeper example: https://git.dthompson.us/sly.git/blob/HEAD:/examples/mines/mines.scm https://git.dthompson.us/sly.git/blob/HEAD:/examples/mines/m... Home page: https://dthompson.us/pages/software/sly.html https://dthompson.us/pages/software/sly.html Hoping to get a 0.2 release out the door in time for the Lisp Game Jam coming up in April.
- CyberDildonics 11y ago
  You can do that right now with Love2D and a stub game loop that sources the actual implementations every second or two.
  - davexunit 11y ago
    That is a far cry from a REPL.
    - CyberDildonics 11y ago
      It's better than a REPL, that allows you to write a game completely live. I'm not sure what you think is lost since you didn't back up what you are saying with anything.
      - davexunit 11y ago
        It is strictly less powerful than a REPL. Claiming that you can't live code a game at a REPL is false, because I do it on a regular basis. When I write games in Scheme, I use a REPL to write the game live, doing all of my editing within Emacs. I do not have to save files for the code to be evaluated, I just press a keystroke to evaluate the specific form I'm interested in. I can evaluate more fine-grained sections of code, not only entire files.

CyberDildonics 11y ago

Doesn't Nim use garbage collection? Also the compiler isn't even stable, it is an interesting language but can't be take seriously for professional development yet.

whitegrape 11y ago
Use of GC in Nim is up to you -- you can malloc/free as you please if you want and avoid it altogether. I'm not sure to what extent you can/can't make use of the standard library if you avoid GC, but even if you lessen your restrictions and use it a little bit, it's a highly tuneable/controllable and understandable GC including support for swapping out entirely different GC algorithms. Professional game development as in AAA studios? Yeah, probably not, but more for the tooling alone than whatever language any particular studio happens to use. Professional indie game development? It's ready, even though it's not at 1.0 yet. Indie devs deal with big breaking upgrades to their frameworks (Unity, Corona, etc.) all the time, it's annoying but not a deal-breaker if the language gets those sometimes too.