Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jai Language Primer

github.com

Post reply on HN
Print view View original

71–80 of 102 posts

Re: Jai Language Primer

#71

Post by basketcasing »

davexunit wrote: post #31
basketcasing wrote: post #20

Earlier quoted context omitted.

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.

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…

> 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.

Re: Jai Language Primer

#72

Post by pandaman »

gregstula wrote: post #70
pandaman wrote: post #68

Earlier quoted context omitted.

>std::array is better than int arr[ARR_SIZE] I don't know how you could disagree with that... What is the alignment of your std::array? What is the memory type (e.g. can the GPU read from it at all? Can it write? What are cache policies?). The alternative though is not a C array, it's an explicit memory mapping. >Can you be clear about why this is bad? Useless code at best (if your game runs properly it will never be…

> What is the alignment of your std::array? What is the memory type (e.g. can the GPU read from it at all? Can it write? What are cache policies?). The alternative though is not a C array, it's an explicit memory mapping. Guaranteed to be contiguous, and semantically equivalent to a C array in all cases. If you don't trust your vendor's STL implementation take a look at the intrusive containers in EA's STL implementa…

As I said, the alternative is not a C array. Neither is C style malloc and free are used in games. If you want a discussion - argue over what I've said or ask questions if you don't understand something. Otherwise have fun with your own mental image of game programming yourself.

Re: Jai Language Primer

#73

Post by lispm »

tomp wrote: post #49
davexunit wrote: post #28

Earlier quoted context omitted.

>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" cre…

> S-expressions [...] allow for syntactic abstraction I never bought this argument, based on my intuition, but now Julia has proved this argument to be invalid. Insisting only S-expressions allow macros is simply intelectually dishonest. Go check how Julia does metaprogramming; all the power of Lisp with none of the wierdness.

Macros were available in S-Expression free languages long before Julia.

Re: Jai Language Primer

#74

Post by gregstula »

pandaman wrote: post #72
gregstula wrote: post #70

Earlier quoted context omitted.

> What is the alignment of your std::array? What is the memory type (e.g. can the GPU read from it at all? Can it write? What are cache policies?). The alternative though is not a C array, it's an explicit memory mapping. Guaranteed to be contiguous, and semantically equivalent to a C array in all cases. If you don't trust your vendor's STL implementation take a look at the intrusive containers in EA's STL implementa…

As I said, the alternative is not a C array. Neither is C style malloc and free are used in games. If you want a discussion - argue over what I've said or ask questions if you don't understand something. Otherwise have fun with your own mental image of game programming yourself.

You asked a question about the array and I answered it.

Yeah I missed the part where you said mmap. There's libraries that make that safer, but clearly there's a preference for working with the raw tools here.

> Otherwise have fun with your own mental image of game programming yourself.

Ignorance is bliss. Have fun ignoring the progress systems programming has made in the last 30 years. Why bother even looking into it right? If what works for you works... that's all that matters.

Re: Jai Language Primer

#75

Post by lispm »

urs2102 wrote: post #57
hacker_9 wrote: post #22

Earlier quoted context omitted.

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 i…

Well I think Lisp's biggest strength is also its biggest weakness: macros. By being able to bend a Lisp to your will, you trade your ability to standardize the language and build a community of libraries and tools around it. That being said, there's nothing like having a language which eventually becomes the best tool for solving the problem you're facing for at hand (as your Lisp will tend to evolve appropriately).

People 'standardize' macros all the time.

1) Invent a new useful macro.

2) Package it as a library

3) Document it.

4) advertize it

Since macros are written in a standard language and many cab be written in a portable way, it just another way of meta programming.

Stuff like DEFCLASS, DEFMETHOD, ITERATE, WITH-GENSYMS, etc. started as portable libraries.

What one has to learn: the language does not have a fixed amount of syntax. That's the price to pay: learning a new level of programming: linguistic meta programming.

Re: Jai Language Primer

#76

Post by lispm »

hacker_9 wrote: post #22
davexunit wrote: post #11

Earlier quoted context omitted.

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 implemen…

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 i…

> Why are there so many dialects?

That's a really funny question in a thread about another new programming language.

Re: Jai Language Primer

#77

Post by davexunit »

basketcasing wrote: post #71
davexunit wrote: post #31

Earlier quoted context omitted.

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…

> 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…

>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.

Re: Jai Language Primer

#78

Post by lispm »

CyberDildonics wrote: post #42
davexunit wrote: post #32

Earlier quoted context omitted.

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.

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 happen…

There is a price to pay for a better programming language. C++ is fast and crashes fast. Its data structures are at the same time complex and inflexible. Many Lisp dialects are tuned for flexibility and some add a bit of performance to it. C++ comes from a different angle. It provides more performance, but it is fully inflexible.

Still people can do interesting stuff. For example the Crash Bandicoot games for the early Playstation were written in a low-level Lisp dialect with an external compiler implemented in Common Lisp. It ran on a tiny Playstation with cute graphics and sold very well.

https://en.wikipedia.org/wiki/Crash_Bandicoot

Re: Jai Language Primer

#79

Post by lispm »

davexunit wrote: post #31
basketcasing wrote: post #20

Earlier quoted context omitted.

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.

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…

Boah, I don't even know how long hash tables are in Lisp now. Hash tables became popular when the implementations used them for their symbol tables.

The MIT Lisp Machine from the late 70s implemented hash tables and used them widely:

http://lispm.de/source/lispm-system-78-48/lispm2/hash.lisp

Post reply on HN