#Gamelab2018 - Jon Blow's Design decisions on creating Jai a new language for game programmers
Gamelab Conference3 HN recommenders · recommended in 3 months, 2018–2023
talk · advanced · evergreen · 2018–2023 on HN
Jonathan Blow talks at Gamelab 2018 about the design decisions behind Jai, the programming language he is building for game programmers. He covers low-friction development, quality of life and the effects of compile times.
Recommended for a substantive look at language design priorities and a critique of why modern programming feels broken.
Up next
16 mo on HNHow Python was Shaped by leaky Internals, Armin Ronacher, Flask framework
Видео с мероприятий {speach!
15 HN recommender · 2017–2025
12 mo on HNWhy Isn't Functional Programming the Norm? – Richard Feldman
Metosin
12 HN recommender · 2019–2025
11 mo on HNMaybe Not - Rich Hickey
ClojureTV
14 HN recommender · 2018–2025
10 mo on HNConway's Game Of Life in APL
Dyalog
11 HN recommender · 2010–2024
9 mo on HNLecture 1A | MIT 6.001 Structure and Interpretation, 1986
MIT OpenCourseWare
11 HN recommender · 2012–2024
10 mo on HNCrockford on JavaScript - Volume 1: The Early Years
YUI Library
10 HN recommender · 2013–2022
10 mo on HNGrowing a Language, by Guy Steele
Bill Pugh
11 HN recommender · 2014–2026
10 mo on HNEffective Programs - 10 Years of Clojure - Rich Hickey
ClojureTV
10 HN recommender · 2017–2026
9 mo on HNBrian Goetz - Stewardship: the Sobering Parts
ClojureTV
10 HN recommender · 2014–2025
10 mo on HNJavaScript: The Good Parts
Google TechTalks
11 HN recommender · 2009–2020
9 mo on HNIdeas about a new programming language for games.
Jonathan Blow
7 HN recommender · 2014–2025
8 mo on HN"Propositions as Types" by Philip Wadler
Strange Loop Conference
9 HN recommender · 2015–2026
4 comments from Hacker News
This video does a great job of explaining why modern programming in general has failed: ▶ this video I think OOP specifically derailed programming because of how big it was, how fast it took over and how long it was considered to be the one true programming paradigm. When OOP hit, it hit hard and fast. It wasn't long before colleges were teaching OOP as The One True Way To Program. Every employer required knowledge of OOP before they would interview you. And I mean every employer, from startups to corporate enterprise. And once it took hold, it took people (and me!) 10-20 years to realize the OOP emperor had no clothes on. I still don't understand why or how it got so big so quickly. All I can figure is that the software industry as a whole pays attention to the wrong people.
Hubris. "Look at us, we have these LANGUAGE EXPERTS working for us". As a result the only presentations these people do are about how great their new Yet Another Language toy is. Compare this to, say, Jonathan Blow talking about design decisions for his language: ▶ this video
They become really frustrating as the project grows in size. Personally, it becomes really difficult to maintain productivity. As compile times tick up, I start bouncing over to other tabs rather than just twiddling my thumbs starring at a terminal. Then I realize I've been on Reddit for a half-hour. I recently watched this talk by Johnathan Blow[0] where he talks about quality of life in programming languages and spends a fair amount of time talking about compile times and their effects. I think we collectively need to re-align on being performance focused. Tools are simultaneously amazing but crummy at the same time. [0] ▶ this video
I happened to have read many of VPRI’s papers and some domain expertise in a few of their topics, or know close friends with such domain expertise. Btw, my collection of their links are at link The goal is a noble one; though it's unclear to me if their research is the right way to go. Alan Kay's gang's research's end result are often great, but their implementations are usually more geared toward prototyping rather than production. For example, the GUI innovation is great, whereas its implementation using Smalltalk is clearly geared toward faster iteration and not meant to be as competitive as a production language (let's not enter into this debate as this is another rabbit hole. Plenty of other HN threads on this). But I think so far these implementations have gotten a pass because the end result is futuristic enough for someone else to come along and implement e.g. the GUI in more production-oriented languages. In the context of VPRI, however, the goal wasn't to create more futuristic end results, but to recreate existing result using hopefully drastically more concise paradigms and DSLs. In this case, the implementation itself is the thing we should examine, and imo they kinda fall short. For example: - Yes, it's very appealing that Nile can reduce the antialiasing logic by so much. Is it resilient to real world requirement changes though? Unclear (and the Nile paper still isn't out as the author seems busy with some startup). - The OMeta parser tool is cool until you e