1. 2

    Just thought it would be interesting to share it, as I am planning to go through it properly myself :)

    1. 2

      it’s a great resource, and I recommend it highly!

      1. 1

        I’d really appreciate it if you took notes on what made sense and what was unclear as you go through the tutorial. That kind of feedback is super helpful for us! Thanks :)

      1. 5

        wow, have never wanted to design a font until playing this this demo!

        (I’ve never used “kcurves” though)

        1. 2

          Agreed, that was fun to play around with. (As a small suggestion to the author, it would have been great to have a way to play around with that demo letter ‘A’.)

          1. 3

            If, as is likely, I keep pushing that codebase forward, load/save (and export to SVG) functionality is high on the list. Thanks for the kind words, I’m glad you like it!

        1. 2

          Very nifty game. Performance is excellent. Did you have to play performance games to actually make it performant, or was that just out of the box?

          1. 6

            good question- for the “engine” aspect of the code, I was keeping performance characteristics in mind through my choice of languages, and there were a few false starts along the way. (i built this entire game once in JS and once in lua in the past)

            for the “logic” code in species.rs that defines how elements behave, i felt able to do whatever I wanted, including lots of branching, some higher order functions, abstractions, casting type of numbers, etc. (but, definitely very little heap allocation). This is notable because language expressiveness here indirectly impacts how fun the game is, but this code is also super hot and runs thousands of times per frame.

            an interesting anecdote here is that I unwittingly wrote most of the game with my rustc optimization strategy on “z”, optimize for binary size. once the project was already quite developed I realized this and switched it to o3 which things like inlining and gave me a big performance boost, where i had been being frugal!

          1. 2

            Awesome! Just curious, what changed between your comment on the previous “Rust and WASM” story and now?

            1. 6

              the biggest things were mobile browser GPU support (this was hard), the upload/browse/restore backend, and a few new elements + tweaking to many of their behaviors

              1. 2

                what were the issues with mobile browser gpu support?

                1. 5

                  The two main issues were:

                  The texture types they support (the fluid sim is in floats, but on phone browsers I could only take data in or out of the shaders via unsigned byte textures, required some munging)

                  There’s also a maximum # of bound texture units of 8, and I had to plug a lot of gaps in my knowledge of how OpenGL works in order to correctly bind textures for each program and stay under that limit.

                  all of this was made more complicated by the fact my only phone is an iphone and I don’t own a macbook. Apple only allows you to connect to the safari devtools from a mac >:’( So i was debugging somewhat blind.

                  1. 1

                    Apple requires developers to both own a mac to build and also pay them a yearly fee to be able to offer even free apps on their app store. This kinda sucks, but on the other hand the hardware + macOS is okay.

            1. 1

              Why is there always wind to the left? Any way to adjust that?

              1. 1

                do you mean that particles are blowing to the left and there’s no fire or anything generating that wind? if so, that sounds like a bug in the webgl code, what browser + device are you on?

                1. 1

                  I’m using firefox 63 on arch linux. Here’s a screenshot of what I’m observing. Actually, from experimenting with chrome, it seems like almost everything is going in the wrong direction. Fire floats downward, “gases” float up, and ice falls instead of staying put.

                  1. 3

                    I’m sorry that it doesn’t work, you may have better luck on a smartphone. WebGL has a huge surface area of browser and platform specific implementation details, and I don’t think I could hunt down the issue unless I could reproduce your issue locally. (FWIW, firefox 60 on ubuntu works for me)

              1. 2

                This is so fun, thanks for making it!

                1. 1

                  : )

                1. 3

                  Cool game :-) I’ve managed to grow some plants in lava, it’s fun :-)

                  1. 8

                    If you use a mix of the clone dots, seeds, and oil you can get a neat cycle of fire burning up plants and regrowth https://imgur.com/a/Qxmt6x9

                    1. 1

                      how did you accomplish that? :0 upload an example?

                      1. 4

                        The trick was to constantly water the surviving plant matter on the lava until it stabilized. Here’s an example: https://sandspiel.club/#uuL30AiL3VoU9roKgbwo

                        1. 1

                          I think i had a similar effect of growing plants on lava if it the lava had died down enough. second time around i just put a small area of sand on top of the lava.

                          One more: https://imgur.com/4WnEg4F

                      1. 20

                        Impressive! I particularly like the smoke effects that come from fire. Are you doing some fluid dynamics to get that behaviour?

                        1. 21

                          yep, the fluid simulation also runs completely on the GPU, which is one reason it’s so smooth. I adapted this excellent implementation for my needs: https://github.com/PavelDoGreat/WebGL-Fluid-Simulation

                        1. 19

                          I followed this tutorial to get started on my falling sand game project*. It’s a concise introduction to some really useful tools - using this ecosystem has been a total joy and has enabled me to build things in the browser with incredible performance, without sacrificing the web niceties I’m used to like quick feedback cycles and performance tracing via devtools. The browser support is also really strong, my game (mostly, WIP!) works on mobile and most browsers (I think) Highly recommend this book!

                          * https://maxbittker.github.io/sandtable/

                          https://github.com/MaxBittker/sandtable

                          1. 7

                            This is so so so awesome <3

                            1. 4

                              Holy crap. That game is awesome. The way the different elements interact so intuitively is just incredible. I was playing around with destroying things with acid, but then I realized half my screen was acid and it was fun trying to get rid of it. I love how gas and lava interact, and also how ice will cause surrounding water to freeze. And also, putting a bit of lava under some wood and then using wind on the wood actually scatters the embers of the wood. Wow.

                              That’s a really incredible project!

                              1. 3

                                thank you so much! falling sand games were a part of my childhood, I love their mode of play through experiment-building.

                                My eventual goal is to allow the user to program, fork, and share new elements of their own design, and mix them. Defining an element right now has an intentionally simple cellular automata api surface, and I hope to eventually figure out how to compile and link wasm modules in the browser to allow hundreds of elements, so you can try out usernameFoo’s “Alien Plant v4” against usernameBar’s “pink super acid”

                                I’ll need to understand the wasm toolchain a lot better to make that happen though

                              2. 3

                                This game is amazing. thank you. Also, I want the last two hours of my life back 😅

                                1. 8

                                  Thank you! This is a bit silly considering that I posted this on a public forum, but my one request is to please not share the game more broadly yet, I have a lot of things I still want to implement before I show it to people outside the context of it being a tech demo. Posted it here because I appreciate this learning resource so much!

                                2. 2

                                  I love the smoke effect!

                                  As I sit here posting my girlfriend is whispering in my ear, “what is clone?”

                                  1. 2

                                    Thanks! I adapted most of the fluid simulation code from here, learned a lot about webgl doing so! https://github.com/PavelDoGreat/WebGL-Fluid-Simulation

                                  2. 1

                                    holy shit the plant actually catches on fire when it touches lava this is awesome

                                    1. 1

                                      the dust can explode…..

                                  1. 5

                                    People who’re participating, what languages are you using? I’m starting to learn Typescript, so I’m thinking of using that for practical reasons, though I’d probably rather do OCaml or something a bit more esoteric.

                                    1. 8

                                      Last year I used 6 languages, and this year my goal is to use 12! Carp, Fennel, and Reason are some new-to-me languages I hope to touch on. I will likely do most of the problems in clojure because I enjoy manipulating data-structures in it so much, but rarely feel like it’s the practical choice for my projects.

                                      1. 2

                                        So, the 12 languages of Christmas?

                                      2. 6

                                        If it is fine with you to not be able to complete a task in 24h than AoC is a great way to learn new language.

                                        1. 6

                                          I’m learning Clojure and liking it so far, so my AoC has a perfect timing this year to be full of parenthesis

                                          1. 2

                                            Let’s compare solutions!

                                          2. 3

                                            Planning on giving ReasonML and Elm a shot.

                                            1. 3

                                              I did 2015 and 2017 in Racket, and had a pretty good time. I tried 2016 in Erlang, and really struggled.

                                              This year, I’m going to try it with Pony.

                                              1. 2

                                                As much as I am tempted to try ReasonML, I wrote a modest amount of Elixir back in 1.2 (three years ago, and stable is now 1.7), and have an upcoming need for it again. Will probably do that to brush up on any changes.

                                                In an attempt to make it challenging is I am going to try and pick up Emacs while doing so. I have heard that the lineage inherited from Erlang provides a decent ecosystem in Emacs for other BEAM languages. Does anyone know if that perception is correct?

                                                1. 1

                                                  Cannot edit my post anymore, but it looks like not only is that the case, there are multiple Elixir-specific packages as well (elixir-mode and alchemist).

                                                2. 2

                                                  I’ll probably take a shot with Haskell again, or possibly F#.

                                                  1. 2

                                                    Crystal. Figured I should brush up on making actual programs instead of one-off scripts and thus style and “architecture” will be my focus.

                                                    1. 2

                                                      Pretty ballsy that a project will try to reclaim that name from the horror that is Crystal Reports. Kudos!

                                                    2. 2

                                                      I use Perl 5. Life + day job doesn’t give much time for actual programming so I’m really happy to just try to solve problems in a language I know well.

                                                      Plus Perl makes parsing the problem input a breeze.

                                                      1. 1

                                                        I’ve been looking into D a bit recently so going to give that a try.

                                                        1. 1

                                                          I think this year I’ll forego going for leaderboard, and use the opportunity to brush up on my Elixir skills. I haven’t had a good chance to touch it for quite a while, so it should be a good refresher. I really enjoy thinking in and solving problems with the toolset available in Elixir.

                                                          1. 2

                                                            Jose Valim is going to stream his own solutions to each challenge one day afterward (in Elixir of course):

                                                            http://blog.plataformatec.com.br/2018/11/lets-learn-elixir-together-with-advent-of-code/

                                                            1. 1

                                                              Fantastic! Thanks for the heads up!

                                                        1. 3

                                                          This can be interesting as I’m learning I started to use Clojure not so long ago. But the beginning of December can be hard as I’m moving from Canada to Brazil :(

                                                          1. 9

                                                            what’s the rush, took me 6 months to do 2017’s aoc! i really enjoyed doing it mostly in clojure

                                                            1. 3

                                                              Interesting, I’ll try them. But I imagine that after some time the chat around it start to cool down.

                                                              1. 3

                                                                Sometimes that’s better; you don’t want to be spoiled! I did it last year as a way to learn Ruby.

                                                                1. 2

                                                                  Plus the subreddit is always there if you get stuck

                                                            2. 7

                                                              If you don’t get caught up in the “must be done before the next one drops”, it’s perfectly fine to do them at ones own pace!

                                                            1. 3

                                                              I’ve had good experiences using clojurescript and figwheel to do hot reloading on file change. Quil is compatible with clojurescript

                                                              1. 2

                                                                I’d second this. Maybe also devcards. But this setup makes it really easy to write some code, save and see the changes right away as it re-renders. Even if your desired target isn’t the web, the same Quil code should then work in eg. OpenGL as well.

                                                              1. 3

                                                                Are you compiling your code in release mode? There’s a significant performance difference. I found that rust’s speed made certain brute force approaches to PE problems more viable.

                                                                1. 1

                                                                  That is an excellent point, I’ll make sure to try that, although the perceptual differences are fairly tiny even in debug 😬

                                                                1. 3

                                                                  if you enjoyed this, I highly recommend the fantastic technical/process log here: https://www.youtube.com/watch?v=hTlNVUmBA28

                                                                  1. 1

                                                                    I found myself in this position a lot at work, and wrote a post about to be useful when you’re in the junior developer tasked with reviewing code from people who know the system better than you do - because it can be intimidating and difficult!!

                                                                    https://maxbittker.github.io/code-review/

                                                                    1. 3

                                                                      map and filter capture common operations in a really solid way that is almost always an advantage over a loop.

                                                                      In my experience, the bar is a lot higher when considering rewriting loops into reduces. A reduce isn’t necessarily much more opinionated or explicit than a loop, and so you need to be careful to ensure that you’re choosing it over a loop for the right reasons.

                                                                      If your reducer body is longer than a single statement, or your output data structure is more complicated than a single literal, you might not be gaining much by using reduce.

                                                                      1. 3

                                                                        https://redash.io/ Redash is a very similar feature set (if I understand correctly) and is open source, if anyone wants something hostable / ownable.

                                                                        1. 1

                                                                          (disclaimer: Redash author)

                                                                          Thank you for mentioning Redash. Actually Redash’s features extend beyond QueryClips, as it allows to visualize the data, create dashboards, alerts and more.

                                                                          @dpaola2 on the website you mentioned that you created QueryClips after being frustrated with the lack of simple, easy-to-use tools. I created Redash for the same reasons ;-) I just wonder, did you have the chance to evaluate Redash before creating QueryClips? :-)

                                                                        1. 5

                                                                          Working on a game in webgl, and packaging some tiny quality of life tools for my workflow in the meantime. main takeaways are that regl and glslify are really delightful!

                                                                          A mystery for the reader: What is this weird rendering artifact i’m getting on mobile? image

                                                                          At work this morning, fixing a small crop of bugs that popped up over weekend <3

                                                                          1. 25

                                                                            I used to do the things listed in this article, but very recently I’ve changed my mind.

                                                                            The answer to reviewing code you don’t understand is you say “I don’t understand this” and you send it back until the author makes you understand in the code.

                                                                            I’ve experienced too much pain from essentially rubber-stamping with a “I don’t understand this. I guess you know what you’re doing.” And then again. And again. And then I have to go and maintain that code and, guess what, I don’t understand it. I can’t fix it. I either have to have the original author help me, or I have to throw it out. This is not how a software engineering team can work in the long-term.

                                                                            More succinctly: any software engineering team is upper-bound architecturally by the single strongest team member (you only need one person to get the design right) and upper-bound code-wise by the single weakest/least experience team member. If you can’t understand the code now, you can bet dollars to donuts that any new team member or new hire isn’t going to either (the whole team must be able to read the code because you don’t know what the team churn is going to be). And that’s poison to your development velocity. The big mistake people make in code review is to think the team is bound by the strongest team member code-wise too and defer to their experience, rather than digging in their heels and say “I don’t understand this.”

                                                                            The solution to “I don’t understand this” is plain old code health. More functions with better names. More tests. Smaller diffs to review. Comments about the edge cases and gotchas that are being worked around but you wouldn’t know about. Not thinking that the code review is the place to convince the reviewer to accept the commit because no-one will ever go back to the review if they don’t understand the code as an artifact that stands by itself. If you don’t understand it as a reviewer in less than 5 minutes, you punt it back and say “You gotta do this better.” And that’s hard. It’s a hard thing to say. I’m beginning to come into conflict about it with other team members who are used to getting their ungrokkable code rubber stamped.

                                                                            But code that isn’t understandable is a failure of the author, not the reviewer.

                                                                            1. 7

                                                                              More succinctly: any software engineering team is upper-bound architecturally by the single strongest team member (you only need one person to get the design right) and upper-bound code-wise by the single weakest/least experience team member.

                                                                              Well put – hearing you type that out loud makes it incredibly apparent.

                                                                              Anywhoo, I think your conclusion isn’t unreasonable (sometimes you gotta be the jerk) but the real problem is upstream. It’s a huge waste when bad code makes it all the way to review and then and then needs to be written again; much better would be to head it off at the pass. Pairing up the weaker / more junior software engineers with the more experienced works well, but is easier said than done.

                                                                              1. 4

                                                                                hmm, you make a good point and I don’t disagree. Do you think the mandate on the author to write understandable code becomes weaker when the confusing part is the domain, and not the code itself? (Although I do acknowledge that expressive, well-structured and well-commented code should strive to bring complicated aspects of the problem domain into the picture, and not leave it up to assumed understanding.)

                                                                                1. 3

                                                                                  I think your point is very much applicable. Sometimes it takes a very long time to fully understand the domain, and until you do, the code will suffer. But you have competing interests. For example, at some point, you need to ship something.

                                                                                  1. 2

                                                                                    Do you think the mandate on the author to write understandable code becomes weaker when the confusing part is the domain, and not the code itself?

                                                                                    That’s a good question.

                                                                                    In the very day-to-day, I don’t personally find that code reviews have a problem from the domain level. Usually I would expect/hope that there’s a design doc, or package doc, or something, that explains things. I don’t think we should expect software engineers to know how a carburetor works in order to create models for a car company, the onus is on the car company to provide the means to find out how the carburetor works.

                                                                                    I think it gets much tricker when the domain is actually computer science based, as we kind of just all resolved that there are people that know how networks work and they write networking code, and there’s people who know how kernels work and they write kernel code etc etc. We don’t take the time to do the training and assume if someone wants to know about it, they’ll learn themselves. But in that instance, I would hope the reviewer is also a domain expert, but on small teams that probably isn’t viable.

                                                                                    And like @burntsushi said, you gotta ship sometimes and trust people. But I think the pressure eases as the company grows.

                                                                                    1. 1

                                                                                      That makes sense. I think you’ve surfaced an assumption baked into the article which I wasn’t aware of, having only worked at small companies with lots of surface area. But I see how it comes across as particularly troublesome advice outside of that context

                                                                                  2. 4

                                                                                    I’m beginning to come into conflict about it with other team members

                                                                                    How do you resolve those conflicts? In my experience, everyone who opens a PR review finds their code to be obvious and self-documenting. It’s not uncommon to meet developers lacking the self-awareness required to improve their code along the lines of your objections. For those developers, I usually focus on quantifiable metrics like “it doesn’t break anything”, “it’s performant”, and “it does what it’s meant to do”. Submitting feedback about code quality often seems to regress to a debate over first principles. The result is that you burn social capital with the entire team, especially when working on teams without a junior-senior hierarchy, where no one is a clear authority.

                                                                                    1. 2

                                                                                      Not well. I don’t have a good answer for you. If someone knows, tell me how. If I knew how to simply resolve the conflicts I would. My hope is that after a while the entire team begins to internalize writing for the lowest common denominator, and it just happens and/or the team backs up the reviewer when there is further conflict.

                                                                                      But that’s a hope.

                                                                                      1. 2

                                                                                        t’s not uncommon to meet developers lacking the self-awareness required to improve their code along the lines of your objections. For those developers, I usually focus on quantifiable metrics like “it doesn’t break anything”, “it’s performant”, and “it does what it’s meant to do”. Submitting feedback about code quality often seems to regress to a debate over first principles.

                                                                                        Require sign-off from at least one other developer before they can merge, and don’t budge on it – readability and understandability are the most important issues. In 5 years people will give precisely no shits that it ran fast 5 years ago, and 100% care that the code can be read and modified by usually completely different authors to meet changing business needs. It requires a culture shift. You may well need to remove intransigent developers to establish a healthier culture.

                                                                                        The result is that you burn social capital with the entire team, especially when working on teams without a junior-senior hierarchy, where no one is a clear authority.

                                                                                        This is a bit beyond the topic at hand, but I’ve never had a good experience in that kind of environment. If the buck doesn’t stop somewhere, you end up burning a lot of time arguing and the end result is often very muddled code. Even if it’s completely arbitrary, for a given project somebody should have a final say.

                                                                                        1. 1

                                                                                          The result is that you burn social capital with the entire team, especially when working on teams without a junior-senior hierarchy, where no one is a clear authority.

                                                                                          This is a bit beyond the topic at hand, but I’ve never had a good experience in that kind of environment. If the buck doesn’t stop somewhere, you end up burning a lot of time arguing and the end result is often very muddled code. Even if it’s completely arbitrary, for a given project somebody should have a final say.

                                                                                          I’m not sure.

                                                                                          At very least, when no agreement is found, the authorities should document very carefully and clearly why they did take a certain decision. When this happens everything goes smooth.

                                                                                          In a few cases, I saw a really seasoned authority to change his mind while writing down this kind of document, and finally to choose the most junior dev proposal. And I’ve also seen a younger authority faking a LARGE project just because he took any objection as a personal attack. When the doom came (with literally hundreds of thousands euros wasted) he kindly left the company.

                                                                                          Also I’ve seen a team of 5 people working very well for a few years together despite daily debates. All the debates were respectful and technically rooted. I was junior back then, but my opinions were treated on pars with more senior colleagues. And we were always looking for syntheses, not compromises.

                                                                                      2. 2

                                                                                        I agree with the sentiment to an extent, but there’s something to be said for learning a language or domain’s idioms, and honestly some things just aren’t obvious at first sight.

                                                                                        There’s “ungrokkable” code as you put it (god knows i’ve written my share of that) but there’s also code you don’t understand because you have had less exposure to certain idioms, so at first glance it is ungrokkable, until it no longer is.

                                                                                        If the reviewer doesn’t know how to map over an array, no amount of them telling me they doesn’t understand will make me push to a new array inside a for-loop. I would rather spend the time sitting down with people and trying to level everyone up.

                                                                                        To give a concrete personal example, there are still plenty of usages of spreading and de-structuring in JavaScript that trip me up when i read them quickly. But i’ll build up a tolerance to it, and soon they won’t.

                                                                                      1. 10

                                                                                        I ended up writing a ClojureScript micro-framework for Node called Macchiato. I primarily work with Clojure, and I found a few cases where the JVM is not the best fit. The two main limitations being relatively high memory requirements and startup time. This makes the JVM a poor fit for things like AWS Lambda. I had a use case for making some lightweight services at work, and wanted to learn a bit about the Node ecosystem, so this was the result.

                                                                                        1. 2

                                                                                          Very excited about new developments like shadow-cljs and macchiato in the clojurescript world! thanks Yogthos :)

                                                                                          1. 1

                                                                                            Thanks, 2018 should be a pretty exciting year for ClojureScript. :)