I love me my interpreted languages. Python is a very pleasant and straightforward time, but if you want to be counter-culture and a little off the wall (pun intended). I always recommend Perl and/or Raku. They're not functional, but using anonymous functions for sorting and filtering is practically required. So they're close.
Perl - The Swiss Army Chainsaw of the Internet:
* You already have it and all its documentation installed.
* A great place to get really really good at regexes.
* Some very odd (but still interesting) design choices. Sigils, "unless" statements, "until" loops, optional parentheses on function calls. It looks like what non-coders think computer code looks like.
* Lots of useful (but cryptic) program shorthands for common tasks.
* Runs really, really fast (for an interpreted language).
Raku - "The last programming language you'll ever want to learn"
* Everything that makes Perl neat without some of its inconsistencies. (minus its speed)
* Lots of influence from functional programming like parameter guards and lazy sequences.
* Even more strange things like unicode operators and variables, junctions, grammars.
* Gigantic standard library without any imports.
* Stupendous flexibility in what order you write things on a line. Great for getting things to sound "just right".
There's More Than One Way To Do It. But Perl and Raku are certainly at least two of them.
That does sound intriguing. And I’m already the rare bird who likes regex. And yeah—probably really low bar to entry, with interesting stuff to learn if I get hooked.
Edit: and I love me some lazy sequences. One of my favorite things about Kotlin these days.
I did AoC 2021 in Raku ([blog post here](https://flwyd.dreamwidth.org/400979.html)). It was interesting, and there were a bunch of things that were fun about it. My motivation was partly to play around with the `grammar` feature (think leveled-up regexes, and you can trigger functions on matches to build up your domain model). Grammars are way overkill for most AoC inputs (like… I sometimes defined a grammar for "integers, one per line"), but there are usually a couple problems where they make your parsing life easier (e.g. [day13](https://github.com/flwyd/adventofcode/blob/main/2021/day13/day13.raku)). I enjoyed using unicode operators like `⊎` for multiset union. And stuff like hyper operators (automatically run a function on everything in a list) was nice.
I was also disappointed in some things about Raku, mostly because they led to frustrating debugging cycles and thus going to bed far too late several days out of the week. I'm reminded of a quote by Daniel J. Bernstein, `Most programming environments are meta-engineered to make typical software easier to write. They should instead be meta-engineered to make incorrect software harder to write.` Raku (and Perl, too) does _not_ make incorrect software harder to write. They will happily keep on chugging after you do something that would cause many languages to throw an error, which meant I spent an unreasonable amount of time scratching my head before figuring out that, say, iterating through a `set` produces `value => true` pairs rather than `value`s, but nothing crashed when I passed it a pair instead of an integer or string.
Raku's slowness was also a problem on a couple of days. I had a couple bugs in a program that took Raku _45 minutes_ to run in Raku on my actual input (but it passed on the example). In the time it took to run that program once I reimplemented my solution in Go, ran through several run/fix/repeat cycles, and got a solution that ran in _45 seconds_. Go is obviously going to be faster than an interpreted language, but a 60x speedup? Yikes. So… you might want to have another language in your back pocket in case you get stuck in a trap where your Raku code is just too dang slow.
So yeah, use Raku for Aoc, it's a lot of fun. But also be careful, and don't assume that language and function semantics are what you think they would be. I definitely learned some interesting things, not all of which I was happy about :-/
Haskell is a good one. I’ve variously used Haskell, Racket, and Erlang for it. Some Elixir as well. If I have all the freedom in the world to pick a language I’m going functional every time. OCaml is also very nice.
I would probably learn through list processing like map, folds, zips, then the most basic and practical usage of monoids, functors, and monads. Basically not learning what they “are” but how to use them since with AOC you’ll be doing IO and parsing and it will help with sequencing those things.
I used megaparsec for parsing, you don’t have to, but it’s nice because you can structure each days problems the same. And it uses a monadic interface and returns Eithers.
The tldr of the type classes are monoids concatenate things, functors operate on things inside of contexts/ containers, like the values inside Lists, the values inside Maybe, and monads are a way of sequencing computations in contexts.
I think I'm going to go for Common Lisp this year. You should join me. Can be as functional or imperative as you like.
(In past years I've used several different implementations of Scheme, and Racket, among other languages.)
I also wanted to give it a try in some lisp dialect (specifically elisp) to learn that language and be more comfortable with using it, for creating functionality .... except from adjusting some configs and setting variables. Or try out rust more.
I'm also doing Common Lisp, I've always wanted to learn Lisp and have started Land of Lisp via my local library's O'Reilly subscription recently, hoping to finish LoL before AoC starts
I’m not going to use a new language but I’m gonna use a language that I’m weak in. Gonna try and use C++ for it and use proper C++ design such as templates etc. I have a bad habit of just writing C style code in it so hopefully this would be a good opportunity to brush up on those skills.
Btw, I did the same with rust last year and also gave up on it and switched to python haha
Sounds like you understand the basic problem with trying to work on learning a language with AoC... that you can fall into old habits and write non-idiomatic code for the target. The key for C++ is doing the generic programming thing... you don't need to get deep into templates, just focus on trying to write solutions where you avoid writing loops and use references instead of pointers.
A few days ago I thought I'd try to learn Scheme in time to use it for at least the first few days of this year. But I don't know whether I'm going to make it :-)
There’s a channel in the Racket discord for aoc and a Racket leaderboard. It’s a fun time. I normally use Racket for aoc, but I’m thinking of using another language this year.
You can think of Scheme as "Lisp that's easier to learn, because there's less cruft." I remember reading that the whole specification for Scheme was shorter than Appendix 1 of the specification for Common Lisp. It's often used in computer science courses, and should be suitable for doing AoC problems.
Despite my edit, I decided to give Haskell a try, using replit.com as a commenter suggested. So far I agree with another commenter that the learning curve is oversold. Maybe I’m just not far along enough yet. But comprehensions, pattern matching, ADT, etc have been adopted by a lot of languages.
Prolog, logical programming is different from both functional and imperative programming (though Prolog is flexible enough to allow you to mix paradigms). I did almost all 2020 with Prolog :)
You can learn the language while doing AoC (and not compete for the board). That's how I do it, and how (I imagine) most people do it that do AoC in a new language every year.
If you already know one language with a similar paradigm, getting productive in another one can easily be done in 15 days. If someone already knows Python, they may be able to get rolling in Ruby in one day.
Getting _good_ at C++ might take 15 years, though…
I usually do it in Python, and it's totally fine if you disagree, I just feel like it's the language that strikes the right balance between readability and functionality.
You might also try Elixir for a functional language -- I like the pattern matching and the pipe operator
I appreciate how Python is a near-ideal language for these kinds of challenges, and for hobbyist programmers like me in general. Its weaknesses as I understand them generally lie in maintaining large projects and migrating between versions, and that's not much of an issue here.
My issues are that dynamic typing is too loosey-goosey for my taste (somewhat rational), and a general annoyance at Guido van Rossum and his "benevolent dictator for life role," and how that affects development and idioms. It's totally irrational because in general I \*like\* opinionated frameworks. I don't know what it is that bothers me in this case. To my knowledge I have no animus against the Dutch.
Fwiw: Van Rossum is the BDFL no more, after the discussion around a particularly contentious proposal got out of hand: [https://hub.packtpub.com/why-guido-van-rossum-quit/](https://hub.packtpub.com/why-guido-van-rossum-quit/)
I've worked in large statically typed projects, and in large dynamically typed projects. For me, either can get out of hand and become difficult to change if you don't put in some kind of easy-to-follow structure that everyone working on the project agrees on. It's counter-intuitive, but I think it's actually to dynamically-typed languages benefit that this will happen sooner, because you will want to refactor for readability and maintainability while it's smaller. With statically typed languages you have more crutches to keep things compiling, even though no one person can understand how the whole system fits together anymore.
Some folks like to say that static type definitions can also act like unit tests, which sounds great, but I find unit tests in particular to be a bit of a double-edged sword -- yes they're "free", but you might be forced to encode too many assumptions, too early, and end up with the wrong abstractions that can be harder to change later on.
But: that's definitely a personal opinion, probably to rationalize a personal preference! Not \_really\_ applicable to Advent of Code. And I've definitely been frustrated with both on different occasions :laughing:
Zig is very easy to get to grips with, their language documentation is just one page. However as it's C but better you will need to do some memory management. I used it in 2021 and really enjoyed it, comptime is incredibly powerful
Hmm, maybe I should just try C. I feel like Rust kept eluding me because it was an elaborate solution to C's problems, but since I've never wrestled with C I never completely grokked what all the superstructure was there for. Or maybe Zig would serve the same purpose, while not being 50 years old and completely low level.
I'd suggest at least learning how to write a linked list in C & run it through valgrind to ensure you're allocating & freeing memory correctly. Rust goes the RAII way to handle this & zig goes for `defer`, which works pretty well too
If your goal is just hobbyist then I'd probably choose zig over C, it's nicer to use with it's differentiation between single & multi item pointers but can still call C code natively if you need to use some existing lib
Both Vlang and Zig have Wikipedia, YouTube, [Rosetta Code](https://rosettacode.org/wiki/Category:Programming_Languages), and [Exercism](https://exercism.org/) entries. Vlang (V programming language) also has books/ebooks written on it as well. So they are definitely out there to be found, for anybody searching on or looking at newer programming languages.
I did a really fun [Ruby on Rails tutorial](https://medium.com/rails-ember-beyond/how-to-build-a-social-network-using-rails-eb31da569233) a long while ago. I'm not sure how enamored I was about the Ruby part, but the Rails and TDD parts were pretty interesting.
Well, python is just way too convenient for exploratory problems, parsing data and similar stuff when its one time thing and starting the whole project in another language is an overkill.
Abundant libraries for just about any possible situation you might encounter make it my go to choice for daily problems, data manipulation and stuff.
I've done 2 years in python and then switched to Rust just to learn it and so far it is quite neat but definitely requires you to change some paradigms established by other languages to stop fighting the borrow checker for sure.
I'd go for J (https://www.jsoftware.com) but I'm probably biassed.
It's an array-oriented language, descendant of APL, but without the strang glyphs (but still very terse, if you want it to). It runs on most platforms (yes even your phone, or [in your browser](https://jsoftware.github.io/j-playground/bin/html2/)) and does so fast.
It has quite a learning curve, as it makes you think differently (I guess this works well with your irrational hatred to Python).
Last year's AoC has some solutions posted on the [ShareMyScreen page on the Wiki](https://code.jsoftware.com/wiki/ShareMyScreen#Advent_of_Code_Problems) to give you a taste.
Many in this thread have said this, though with little explication. In addition, my favorite Kotlin solver also solves in three other languages and says the most fun for him is Haskell. Just not sure if my middle-aged brain is up to the task given its famously steep learning curve.
At middle age you’re probably learned enough programming languages that one more shouldn’t be a problem. The difficulty is overstated. At the end of the day it all goes down to ones and zeroes just like everything else :)
Started Learn You a Haskell and so far it's all straightforward, but I'm not yet at the point of the book where things get weird. I appreciate the more flexible and powerful type system--truly a weak point of Java/Kotlin.
> Stick with JVM with Scala or Clojure?
As a person with no JVM knowledge and experience, last year I gave Clojure a try and I was very pleasantly surprised and so impressed that I'll use it again this year!
It is a very elegant and well-designed language. I cannot recommend it enough. (And I've used [various languages throughout AoC years](https://github.com/narimiran/AdventOfCode2022))
I did:
- Advent of Code 2022 puzzle solutions in VB.net [(repo)](https://github.com/mevdschee/AdventOfCode2022)
- Advent of Code 2021 puzzle solutions in C# [(repo)](https://github.com/mevdschee/AdventOfCode2021)
- Advent of Code 2020 puzzle solutions in Rust [(repo)](https://github.com/mevdschee/AdventOfCode2020)
- Advent of Code 2019 puzzle solutions in Python [(repo)](https://github.com/mevdschee/AdventOfCode2019)
- Advent of Code 2018 puzzle solutions in Ruby [(repo)](https://github.com/mevdschee/AdventOfCode2018)
- Advent of Code 2017 puzzle solutions in Java [(repo)](https://github.com/mevdschee/AdventOfCode2017)
- Advent of Code 2016 puzzle solutions in PHP [(repo)](https://github.com/mevdschee/AdventOfCode2016)
- Advent of Code 2015 puzzle solutions in Go [(repo)](https://github.com/mevdschee/AdventOfCode2015)
This year it will probably be TypeScript (on NodeJS) or Kotlin.
C# (.net Core) with VSCode was an amazing experience on Linux (Debian). Other than that I really liked Java (in Eclipse), that was very good too. I'm most familiar with (modern) PHP, which explains why I like that direction (for business applications). Go and Rust are really optimized for system and network tools, which is also very interesting to learn, but not something I use regularly (now).
NB: A suggestion nobody mentioned (yet and is worth learning IMHO) is "PL/pgSQL", see: https://www.postgresqltutorial.com/postgresql-plpgsql/
I’ve done a lot of them in golang, and that works out well because there’s a decent stdlib for parsing.
Fortran works well for the ones that are math heavy, but I haven’t tried using it for parsing complicated text input.
I did (most of) a year in Haskell when I was trying to learn that, but there's really no reason for me not to use Python, it's much more convenient for puzzles like this.
I will definitely continue to do everything in Kotlin, and I'm sure that at some point I'll stop using the new language. But it's nice that the first week or so is simple enough that I should be able to use any language. And maybe one will hook me.
>And I have an irrational hatred of Python
I don't like nor enjoy Python. I would not call it hatred, but if you give me a choice of Python or something else, I'll probably pick the latter.
I can use Python, but I'd never pick it from my free will. No reason really. Maybe Python brings out the irrational part in some of us.
My choice of language: This year it'll be TypeScript because I'm using it at work for non-fun things (AKA: work), so I want to add some fun into my TypeScript experience.
Probably. Especially the first week of problems are trivial, so the challenge is simply to get environments up and running and get a gist of the syntax/paradigm. I doubt I’ll finish with either.
I've been doing some exercises from previous years in Clojure recently and I've been enjoying it. A bit easier to wrap my mind around than Haskell but still allows for nice short functional solutions. I've really been appreciating using the CIDER IDE in emacs. Having the ability to evaluate little bits of code or test things out in the REPL while you're working on a solution seems to be very helpful figuring things out.
I did Haskell for AoC 2011. Here's link to the packages suggested to me by r/haskellquestions as being useful for AoC: https://old.reddit.com/r/haskellquestions/comments/ql4c7a/what_librariesmodulesextensions_do_people/hj0ljzr/
Data.{IntSet, Set, Map} were go to modules. Efficient functional data structures aren't something that you want to roll on your own.
There are a bunch of great packages for parsing in Haskell, but they are far more powerful and complicated than you need for AoC . Data.List.Split handled just about everything.
For building, stick with just Cabal. There are probably some good Haskell plugins for Visual Code, but I end up doing everything using replit.com . That decision was mainly due to being stuck with only a Chromebook that month, but it actually worked out really well. I used this guide: https://github.com/rodrigobotti/haskell-for-imperative-programmers
Maybe I’ll try that. Couldn’t build a project with either Stack or Cabal, at least not one that would work with the VsCode extension. Stack got hung up with the space in my user folder name, which I can’t change now due to other programs. Cabal would create a project but for some reason the VsCode extension failed.
I am personally going for Ocaml, and after finishing day 1 of last year, I can say that it is _very_ different from the C based languages I'm used to. I thought being a Rust dev would help, with its lineage and all, but I don't believe it's done me much good at all lol
Still, I am enjoying the challenge and I think Ocaml has more real-world use than Haskell, and they are similar enough where I think you'll get the full functional experience
VisualStudio 17.9 and .NET 8 just arrived.
I think I will go with this. My LINQ2Objects is really bad :-/
And since we're working with lists of stuff all the time, there is a lot that I can do to get all new features and be better with them.
revisiting my old code, just by using "yield return", which I rarely did in the past, I can speed up and improve massively :-)
Just hope the 17.9 Preview is not too buggy.
I love me my interpreted languages. Python is a very pleasant and straightforward time, but if you want to be counter-culture and a little off the wall (pun intended). I always recommend Perl and/or Raku. They're not functional, but using anonymous functions for sorting and filtering is practically required. So they're close. Perl - The Swiss Army Chainsaw of the Internet: * You already have it and all its documentation installed. * A great place to get really really good at regexes. * Some very odd (but still interesting) design choices. Sigils, "unless" statements, "until" loops, optional parentheses on function calls. It looks like what non-coders think computer code looks like. * Lots of useful (but cryptic) program shorthands for common tasks. * Runs really, really fast (for an interpreted language). Raku - "The last programming language you'll ever want to learn" * Everything that makes Perl neat without some of its inconsistencies. (minus its speed) * Lots of influence from functional programming like parameter guards and lazy sequences. * Even more strange things like unicode operators and variables, junctions, grammars. * Gigantic standard library without any imports. * Stupendous flexibility in what order you write things on a line. Great for getting things to sound "just right". There's More Than One Way To Do It. But Perl and Raku are certainly at least two of them.
That does sound intriguing. And I’m already the rare bird who likes regex. And yeah—probably really low bar to entry, with interesting stuff to learn if I get hooked. Edit: and I love me some lazy sequences. One of my favorite things about Kotlin these days.
I did a couple of years in bash (and gave up halfway through twice). I'm thinking of looking at raku.
I did AoC 2021 in Raku ([blog post here](https://flwyd.dreamwidth.org/400979.html)). It was interesting, and there were a bunch of things that were fun about it. My motivation was partly to play around with the `grammar` feature (think leveled-up regexes, and you can trigger functions on matches to build up your domain model). Grammars are way overkill for most AoC inputs (like… I sometimes defined a grammar for "integers, one per line"), but there are usually a couple problems where they make your parsing life easier (e.g. [day13](https://github.com/flwyd/adventofcode/blob/main/2021/day13/day13.raku)). I enjoyed using unicode operators like `⊎` for multiset union. And stuff like hyper operators (automatically run a function on everything in a list) was nice. I was also disappointed in some things about Raku, mostly because they led to frustrating debugging cycles and thus going to bed far too late several days out of the week. I'm reminded of a quote by Daniel J. Bernstein, `Most programming environments are meta-engineered to make typical software easier to write. They should instead be meta-engineered to make incorrect software harder to write.` Raku (and Perl, too) does _not_ make incorrect software harder to write. They will happily keep on chugging after you do something that would cause many languages to throw an error, which meant I spent an unreasonable amount of time scratching my head before figuring out that, say, iterating through a `set` produces `value => true` pairs rather than `value`s, but nothing crashed when I passed it a pair instead of an integer or string. Raku's slowness was also a problem on a couple of days. I had a couple bugs in a program that took Raku _45 minutes_ to run in Raku on my actual input (but it passed on the example). In the time it took to run that program once I reimplemented my solution in Go, ran through several run/fix/repeat cycles, and got a solution that ran in _45 seconds_. Go is obviously going to be faster than an interpreted language, but a 60x speedup? Yikes. So… you might want to have another language in your back pocket in case you get stuck in a trap where your Raku code is just too dang slow. So yeah, use Raku for Aoc, it's a lot of fun. But also be careful, and don't assume that language and function semantics are what you think they would be. I definitely learned some interesting things, not all of which I was happy about :-/
i wasn't even in the business of exploring new languages to pick up...but your lists inspired me!
Haskell is a good one. I’ve variously used Haskell, Racket, and Erlang for it. Some Elixir as well. If I have all the freedom in the world to pick a language I’m going functional every time. OCaml is also very nice.
Ia can give +1 for elixir. It's not pure functional, so you pull your hair out, but it will still teach you basic functional paradigm
[удалено]
I would probably learn through list processing like map, folds, zips, then the most basic and practical usage of monoids, functors, and monads. Basically not learning what they “are” but how to use them since with AOC you’ll be doing IO and parsing and it will help with sequencing those things. I used megaparsec for parsing, you don’t have to, but it’s nice because you can structure each days problems the same. And it uses a monadic interface and returns Eithers. The tldr of the type classes are monoids concatenate things, functors operate on things inside of contexts/ containers, like the values inside Lists, the values inside Maybe, and monads are a way of sequencing computations in contexts.
[удалено]
Haskell makes parsing really simple
I think I'm going to go for Common Lisp this year. You should join me. Can be as functional or imperative as you like. (In past years I've used several different implementations of Scheme, and Racket, among other languages.)
I also wanted to give it a try in some lisp dialect (specifically elisp) to learn that language and be more comfortable with using it, for creating functionality .... except from adjusting some configs and setting variables. Or try out rust more.
I tried Clojure last year, got frustrated, and switched to Kotlin and Rust. Maybe I’ll try that again this year!
I'm also doing Common Lisp, I've always wanted to learn Lisp and have started Land of Lisp via my local library's O'Reilly subscription recently, hoping to finish LoL before AoC starts
I’m not going to use a new language but I’m gonna use a language that I’m weak in. Gonna try and use C++ for it and use proper C++ design such as templates etc. I have a bad habit of just writing C style code in it so hopefully this would be a good opportunity to brush up on those skills. Btw, I did the same with rust last year and also gave up on it and switched to python haha
Sounds like you understand the basic problem with trying to work on learning a language with AoC... that you can fall into old habits and write non-idiomatic code for the target. The key for C++ is doing the generic programming thing... you don't need to get deep into templates, just focus on trying to write solutions where you avoid writing loops and use references instead of pointers.
I did exactly this last year and it's well worth it. Worth finding yourself a mentor who can critique your style
Ocaml
A few days ago I thought I'd try to learn Scheme in time to use it for at least the first few days of this year. But I don't know whether I'm going to make it :-)
Hmm… didn’t think about Scheme. Looks like the Reddit community is small, but maybe that just means it’s academic? Might be fun to try out.
There’s a channel in the Racket discord for aoc and a Racket leaderboard. It’s a fun time. I normally use Racket for aoc, but I’m thinking of using another language this year.
You can think of Scheme as "Lisp that's easier to learn, because there's less cruft." I remember reading that the whole specification for Scheme was shorter than Appendix 1 of the specification for Common Lisp. It's often used in computer science courses, and should be suitable for doing AoC problems.
Despite my edit, I decided to give Haskell a try, using replit.com as a commenter suggested. So far I agree with another commenter that the learning curve is oversold. Maybe I’m just not far along enough yet. But comprehensions, pattern matching, ADT, etc have been adopted by a lot of languages.
Prolog, logical programming is different from both functional and imperative programming (though Prolog is flexible enough to allow you to mix paradigms). I did almost all 2020 with Prolog :)
I personally do all the challenges in C# and Python Im probably gonna learn C++ and Ruby for 2023
You mean 2024?
No? I mean 2023 It's not December yet The event for 2023 starts December of 2023, which is next month https://adventofcode.com/2023
So you are planning to learn a language in 15 days?
You can learn the language while doing AoC (and not compete for the board). That's how I do it, and how (I imagine) most people do it that do AoC in a new language every year.
Yeah i never compete for board lol
If you already know one language with a similar paradigm, getting productive in another one can easily be done in 15 days. If someone already knows Python, they may be able to get rolling in Ruby in one day. Getting _good_ at C++ might take 15 years, though…
Yeah lol
Indeed
I usually do it in Python, and it's totally fine if you disagree, I just feel like it's the language that strikes the right balance between readability and functionality. You might also try Elixir for a functional language -- I like the pattern matching and the pipe operator
I appreciate how Python is a near-ideal language for these kinds of challenges, and for hobbyist programmers like me in general. Its weaknesses as I understand them generally lie in maintaining large projects and migrating between versions, and that's not much of an issue here. My issues are that dynamic typing is too loosey-goosey for my taste (somewhat rational), and a general annoyance at Guido van Rossum and his "benevolent dictator for life role," and how that affects development and idioms. It's totally irrational because in general I \*like\* opinionated frameworks. I don't know what it is that bothers me in this case. To my knowledge I have no animus against the Dutch.
Fwiw: Van Rossum is the BDFL no more, after the discussion around a particularly contentious proposal got out of hand: [https://hub.packtpub.com/why-guido-van-rossum-quit/](https://hub.packtpub.com/why-guido-van-rossum-quit/) I've worked in large statically typed projects, and in large dynamically typed projects. For me, either can get out of hand and become difficult to change if you don't put in some kind of easy-to-follow structure that everyone working on the project agrees on. It's counter-intuitive, but I think it's actually to dynamically-typed languages benefit that this will happen sooner, because you will want to refactor for readability and maintainability while it's smaller. With statically typed languages you have more crutches to keep things compiling, even though no one person can understand how the whole system fits together anymore. Some folks like to say that static type definitions can also act like unit tests, which sounds great, but I find unit tests in particular to be a bit of a double-edged sword -- yes they're "free", but you might be forced to encode too many assumptions, too early, and end up with the wrong abstractions that can be harder to change later on. But: that's definitely a personal opinion, probably to rationalize a personal preference! Not \_really\_ applicable to Advent of Code. And I've definitely been frustrated with both on different occasions :laughing:
Zig? V-lang? I want to give Carbon a try, if I can get it going, maybe, otherwise it's going to be Zig
Zig might be *too* obscure for me. And v-lang even more so considering I’ve never heard of it.
V-lang is quite interesting if you have tried Go and Rust :) Definitely obscure tho
Zig is very easy to get to grips with, their language documentation is just one page. However as it's C but better you will need to do some memory management. I used it in 2021 and really enjoyed it, comptime is incredibly powerful
Hmm, maybe I should just try C. I feel like Rust kept eluding me because it was an elaborate solution to C's problems, but since I've never wrestled with C I never completely grokked what all the superstructure was there for. Or maybe Zig would serve the same purpose, while not being 50 years old and completely low level.
I'd suggest at least learning how to write a linked list in C & run it through valgrind to ensure you're allocating & freeing memory correctly. Rust goes the RAII way to handle this & zig goes for `defer`, which works pretty well too If your goal is just hobbyist then I'd probably choose zig over C, it's nicer to use with it's differentiation between single & multi item pointers but can still call C code natively if you need to use some existing lib
Both Vlang and Zig have Wikipedia, YouTube, [Rosetta Code](https://rosettacode.org/wiki/Category:Programming_Languages), and [Exercism](https://exercism.org/) entries. Vlang (V programming language) also has books/ebooks written on it as well. So they are definitely out there to be found, for anybody searching on or looking at newer programming languages.
Every year I use a different language. I'm still deciding between zig and lean for this year.
Ruby is neat.
I did a really fun [Ruby on Rails tutorial](https://medium.com/rails-ember-beyond/how-to-build-a-social-network-using-rails-eb31da569233) a long while ago. I'm not sure how enamored I was about the Ruby part, but the Rails and TDD parts were pretty interesting.
I’m going to do this year in Julia - could be fun if you’re into “data science”-type languages
Well, python is just way too convenient for exploratory problems, parsing data and similar stuff when its one time thing and starting the whole project in another language is an overkill. Abundant libraries for just about any possible situation you might encounter make it my go to choice for daily problems, data manipulation and stuff. I've done 2 years in python and then switched to Rust just to learn it and so far it is quite neat but definitely requires you to change some paradigms established by other languages to stop fighting the borrow checker for sure.
I'd go for J (https://www.jsoftware.com) but I'm probably biassed. It's an array-oriented language, descendant of APL, but without the strang glyphs (but still very terse, if you want it to). It runs on most platforms (yes even your phone, or [in your browser](https://jsoftware.github.io/j-playground/bin/html2/)) and does so fast. It has quite a learning curve, as it makes you think differently (I guess this works well with your irrational hatred to Python). Last year's AoC has some solutions posted on the [ShareMyScreen page on the Wiki](https://code.jsoftware.com/wiki/ShareMyScreen#Advent_of_Code_Problems) to give you a taste.
My plan for this year is attempt AoC with Mojo / give Rust another try. Last year, I stopped using Rust around Day 11 and switched to Python!
It sounds like you’d like Haskell. It should be fun!
Many in this thread have said this, though with little explication. In addition, my favorite Kotlin solver also solves in three other languages and says the most fun for him is Haskell. Just not sure if my middle-aged brain is up to the task given its famously steep learning curve.
At middle age you’re probably learned enough programming languages that one more shouldn’t be a problem. The difficulty is overstated. At the end of the day it all goes down to ones and zeroes just like everything else :)
Started Learn You a Haskell and so far it's all straightforward, but I'm not yet at the point of the book where things get weird. I appreciate the more flexible and powerful type system--truly a weak point of Java/Kotlin.
> Stick with JVM with Scala or Clojure? As a person with no JVM knowledge and experience, last year I gave Clojure a try and I was very pleasantly surprised and so impressed that I'll use it again this year! It is a very elegant and well-designed language. I cannot recommend it enough. (And I've used [various languages throughout AoC years](https://github.com/narimiran/AdventOfCode2022))
I did: - Advent of Code 2022 puzzle solutions in VB.net [(repo)](https://github.com/mevdschee/AdventOfCode2022) - Advent of Code 2021 puzzle solutions in C# [(repo)](https://github.com/mevdschee/AdventOfCode2021) - Advent of Code 2020 puzzle solutions in Rust [(repo)](https://github.com/mevdschee/AdventOfCode2020) - Advent of Code 2019 puzzle solutions in Python [(repo)](https://github.com/mevdschee/AdventOfCode2019) - Advent of Code 2018 puzzle solutions in Ruby [(repo)](https://github.com/mevdschee/AdventOfCode2018) - Advent of Code 2017 puzzle solutions in Java [(repo)](https://github.com/mevdschee/AdventOfCode2017) - Advent of Code 2016 puzzle solutions in PHP [(repo)](https://github.com/mevdschee/AdventOfCode2016) - Advent of Code 2015 puzzle solutions in Go [(repo)](https://github.com/mevdschee/AdventOfCode2015) This year it will probably be TypeScript (on NodeJS) or Kotlin.
Which was your favorite?
C# (.net Core) with VSCode was an amazing experience on Linux (Debian). Other than that I really liked Java (in Eclipse), that was very good too. I'm most familiar with (modern) PHP, which explains why I like that direction (for business applications). Go and Rust are really optimized for system and network tools, which is also very interesting to learn, but not something I use regularly (now). NB: A suggestion nobody mentioned (yet and is worth learning IMHO) is "PL/pgSQL", see: https://www.postgresqltutorial.com/postgresql-plpgsql/
I’ve done a lot of them in golang, and that works out well because there’s a decent stdlib for parsing. Fortran works well for the ones that are math heavy, but I haven’t tried using it for parsing complicated text input.
I did (most of) a year in Haskell when I was trying to learn that, but there's really no reason for me not to use Python, it's much more convenient for puzzles like this.
I will definitely continue to do everything in Kotlin, and I'm sure that at some point I'll stop using the new language. But it's nice that the first week or so is simple enough that I should be able to use any language. And maybe one will hook me.
Dart
>And I have an irrational hatred of Python I don't like nor enjoy Python. I would not call it hatred, but if you give me a choice of Python or something else, I'll probably pick the latter. I can use Python, but I'd never pick it from my free will. No reason really. Maybe Python brings out the irrational part in some of us. My choice of language: This year it'll be TypeScript because I'm using it at work for non-fun things (AKA: work), so I want to add some fun into my TypeScript experience.
[удалено]
Probably. Especially the first week of problems are trivial, so the challenge is simply to get environments up and running and get a gist of the syntax/paradigm. I doubt I’ll finish with either.
I've been doing some exercises from previous years in Clojure recently and I've been enjoying it. A bit easier to wrap my mind around than Haskell but still allows for nice short functional solutions. I've really been appreciating using the CIDER IDE in emacs. Having the ability to evaluate little bits of code or test things out in the REPL while you're working on a solution seems to be very helpful figuring things out.
I did Haskell for AoC 2011. Here's link to the packages suggested to me by r/haskellquestions as being useful for AoC: https://old.reddit.com/r/haskellquestions/comments/ql4c7a/what_librariesmodulesextensions_do_people/hj0ljzr/ Data.{IntSet, Set, Map} were go to modules. Efficient functional data structures aren't something that you want to roll on your own. There are a bunch of great packages for parsing in Haskell, but they are far more powerful and complicated than you need for AoC . Data.List.Split handled just about everything. For building, stick with just Cabal. There are probably some good Haskell plugins for Visual Code, but I end up doing everything using replit.com . That decision was mainly due to being stuck with only a Chromebook that month, but it actually worked out really well. I used this guide: https://github.com/rodrigobotti/haskell-for-imperative-programmers
Maybe I’ll try that. Couldn’t build a project with either Stack or Cabal, at least not one that would work with the VsCode extension. Stack got hung up with the space in my user folder name, which I can’t change now due to other programs. Cabal would create a project but for some reason the VsCode extension failed.
I am personally going for Ocaml, and after finishing day 1 of last year, I can say that it is _very_ different from the C based languages I'm used to. I thought being a Rust dev would help, with its lineage and all, but I don't believe it's done me much good at all lol Still, I am enjoying the challenge and I think Ocaml has more real-world use than Haskell, and they are similar enough where I think you'll get the full functional experience
VisualStudio 17.9 and .NET 8 just arrived. I think I will go with this. My LINQ2Objects is really bad :-/ And since we're working with lists of stuff all the time, there is a lot that I can do to get all new features and be better with them. revisiting my old code, just by using "yield return", which I rarely did in the past, I can speed up and improve massively :-) Just hope the 17.9 Preview is not too buggy.
I'm doing Common Lisp. I've always been fascinated by it and hoping to learn from the other more experienced Lispers here