Interactive programming Flappy Bird in ClojureScript

I don't disagree with the article, but I also don't know that pushing the boundaries of interactivity and "fun" are relegated to academia. Iterating on what makes things fun is (probably) highly unscientific and might be better left to people more focused on it directly, such as game programmers. As far as interactive development of games goes, I still marvel at Bruce Hauman's demo[1] of "Interactive programming Flappy Bird in ClojureScript". I think the best hope of achieving what the author is suggesting is in the development of something similar, either direct REPL access to the game environment or DSLs embedded in the game engines (which already exist I'm sure). Outside of the big name engines, I'm curious about what existing options are (leaving out anything browser based because JavaScript is an obvious example), I know of LÖVE[2] but I'm not familiar with how "fun" games made in it are. [1]: ▶ this video [2]: link

I'm not sure if the parent did, but I followed what you were looking for and the answer is still "try clojure", perhaps more specifically it is "Try the Clojure libraries figwheel and devcards to do web stuff" but the push for immediate feedback and "interactive programming" is central for everyone. It's a community that took Bret Victor's Inventing on Principle talk to heart, already agreeing due to the REPL centric workflows that most people used. Bruce Hauman has some good talks about his tools, which are GUI application-centric and a joy to use [1][2][3] If you aren't doing web or native mobile GUI stuff then the default tools have immediate unit test/linting/spec compliance feedback triggered every time you save a file. Unless you mean you want a very simplified language, in which case you should look elsewhere. Clojure has definitely chosen the high power side of that trade-off, but this also allows some truly first class tools to be developed. [1] link [2] ▶ this video [3] link <- this one in particular is original and outstanding in my opinion

From my standpoint as a one man show, it's invaluable to be able to write the web client and backend in the same language, to share code between them... and have that one language NOT be JS. Clojurescript with Rum/Citrus or Reagent/Reframe deliver on the promise of React/Redux with much less fuss and overhead. Editing JSX is a pain in comparison to the Hiccup syntax used more often in CLJS, e.g. [:div {:class shiny} "some stuff" [:button "OK"]] - with the structural editing in any good Clojure editor you can cut, paste, entire blocks of tags, or slurp a tag from outside your div into it, or spit one out, all with a few keystrokes, never stopping to find some closing </div> tag.. I guess some JSX IDEs might do this, but it's really nice that the HTML is represented as just another piece of data, not some weird chimerical syntax bolt on. With Figwheel or ShadowCLJS hot reloading is instantaneous and doesn't even interrupt your webapp. If they're written properly, functions and the app state are not conflated at all, so you can modify any function in your app's rendering or behavior and as long as they aren't incompatible with the runtime state, it will just pop right into your browser. Illustrated well in this video where the author is interactively re-implementing Flappy Bird: ▶ this video I feel particularly strongly about this having started out doing front end work primarily in cljs but recently being falling into using React/Redux for a contract and being REALLY strung out by the tedium of working with them.

Does TypeScript let you build a program interactively as a living thing? Example of what dynamic languages for the browser (ClojureScript) have been doing for 5 years now: ▶ this video Given that frontend work is so often an endless series of tweaks I don't know how people stand doing anything big for a long duration the classic way of edit -> compile (refresh) -> rebuild runtime state to look at what changed/play around/test -> repeat.

Well, the CLJS->JS side of story is very polished, Figwheel [1] makes things work smoothly (in-browser errors and warnings, sourcemaps, hot reload all work from the box). You can check out [2] if you are interested. There are two areas that still can be improved in my opinion: * the asset story. Right now I use a gulp task that prepares my assets and outputs CSS into a folder known to Figwheel, which makes hotreloading work automagically. However, if you need a complicated interaction between JS, HTML and CSS (i.e. you use CSS Modules), it can be a bit more involved. * the NPM deps story. AFAIK it's gonna be solved in CLJS core soon, but right now your best bet is to pack all NPM deps using native JS tool (webpack, rollup or w/e) into one file and include it before CLJS-generated JS code. Ah, and in some cases you will need externs, too. It's actually way less complicated then it sounds, and if you need any help, feel free to reach me through mail (my nickname here at gmail.com). I would be happy to help. [1]: link [2]: ▶ this video