people who code for fun (and profit?)

[Darus Grey]

nice game, keep it up!


I use libgdx for graphics but I think Unity is a lot easier. libgdx doesn't have a GUI at all; it's just you and the code. although there are probably GUIs out there by now, at least for some of the features


learning Clojure for my current class. I either love it or hate it... not sure which. functional languages are weird as fuck.

If you wanna cross domains a bit there's a great libGDX wrapper in clojure called playclj, can maybe use some of your existing knowledge and apply it to learning the other.

If you have any specific questions regarding clojure feel free to hit me up, been using it professionally last 6yrs; which is almost as long as it's existed.

Hope you love it!

[Yuri-G]

oh man. programming a game in Clojure? that sounds... insane. but it might be a project worth working on if for no other reason than to hone my skills. either way I appreciate the tip. I would never have guessed such a thing existed. how did you know about that - have you used libgdx before? I really like it; it's much more oriented toward coders than things like Unity imo.


mostly I am liking Clojure, except for the formatting. it takes a lot of getting used to. my biggest problem right now is trying to remember where to put the parentheses and brackets. for example, using letfn within a function and then using let within the letfn to assign some variables... that creates some real funky syntax. I'm getting the hang of it though.

on another note, currently reworking my roguelike. this is the fun part of programming... you write shit the wrong way because you didn't know any better, you learn, you redo all that fucking shit. I was previously using a matrix to represent the game grid and multiplying the x/y values by 32 to get the proper pixel values to display the object. I'm going to redo that by leaving the game grid as is, but adding x & y pixel values to every single object. why? because there's no reason to perform 2 multiplication operations on every single object, every single time the screen is rendered (once for the object's x value on the grid, once for the y value). track them separately and you risk decoupling them if you write some bad code (I can already see fireballs originating out of nowhere because the player's graphical x/y got decoupled from the grid x/y), but it makes way more sense from a computational standpoint. given the power of today's computers that's not really an issue, but I still feel like it's the proper way to do things. until I find a better way and have to start all over again :D

[Teorem]

mostly I am liking Clojure, except for the formatting. it takes a lot of getting used to. my biggest problem right now is trying to remember where to put the parentheses and brackets. for example, using letfn within a function and then using let within the letfn to assign some variables... that creates some real funky syntax. I'm getting the hang of it though.

You should look into Lisp proper. It'll be fun!

[Yuri-G]

(def fun
(fn [x]
(if
(= x "too many goddamn parentheses!!!"
"lisp!"
"not lisp..."))))

[Darus Grey]

(def fun
(fn [x]
(if
(= x "too many goddamn parentheses!!!"
"lisp!"
"not lisp..."))))

Java/C/C# has significantly more parentheses/scope blocks. This complaint has always infuriated me because it's provably untrue. If you're comparing like for like(same functionality), Java for instance has 4-5x more, but you don't notice it because you're acclimated to it.

Same thing happens with Lisps, after enough experience you acclimate to it, then suddenly Java seems ridiculously verbose and complicated for less functionality when you go back and forth(like I do daily).

[Yuri-G]

I have to disagree on the parentheses though. C/Java/etc. tend to handle their phrasing with semicolons, which I find more user-friendly (though you may be right that I'm just more acclimated to it). I'm more comfortable with


{
stuff;
stuff;
stuff;
stuff;
}


than I am with


(stuff
(stuff
(stuff
(stuff
(stuff
(stuff))))))


Although I can agree that nested loops and similar constructs can be really awkward in either language. Thank god for IDEs, right?


And then there's Python, where indents actually matter, and that's a whole other realm. In any case, you are far more experienced than I am, so you probably have a better idea of what you're talking about - to be fair There is definitely a learning curve when it comes to something like (def fn [variable] body), though I can see how it is a bit cleaner in a sense.

[Darus Grey]

Except that's not a realistic example.

It's more:

{
stuff.stuff()
stuff()
stuff.stuf(stuff.stuff())
stuff()
}

It's also not "like for like", (stuff(stuff stuff(stuff(stuff)))) in Clojure probably encompass 5-10x more functionality than the equivalent java block being compared. Even if we assume that's not true, *at worst* they're roughly the same in practice. It's a stereotype from the 80s that simply won't die and was never true, the placement of the scoping blocks is different, there's not more of them.

I've been using both Algol derivative(C family) syntax, and Lisp syntax for most my life, well there is a mild clutter aspect of the parenthesis in lisp, they come with major benefits(macro systems that can unambiguously parse the AST tree, something trivial in a lisp and monumental in an algol), and as you point out, IDEs take almost all the pain points away, and IDE's because of the first benefit are significantly more useful in Lisps because they can parse programs with near certainty where algol derivatives are a lot of guess work.

Just as a general rule I recommend most new learners purposefully learn a language from each paradigm/syntax family for more or less the perspective it gives. Programming at many levels has a lot of cultural attached to it, and you really only discover this going outside the "business world" comfort zone.

If you work with a Lisp extensively, then move on to a prolog family(Prolog, Erlang, etc), then maybe a visual scripter, a pure language(haskell), a reactive language(elm), and then like basic assembly, you get a really good view of the entire field, and the pros and cons of each set of tools.

[Yuri-G]

yeah, my view of the field is pretty skewed right now lol


spent forever trying to figure out why some Clojure wasn't working, only to realize I was using my object-oriented brain to assign a value to a hash-map table and then return said table. except I should have returned the assignment itself, because that table is immutable >_>

[Darus Grey]

yeah, my view of the field is pretty skewed right now lol


spent forever trying to figure out why some Clojure wasn't working, only to realize I was using my object-oriented brain to assign a value to a hash-map table and then return said table. except I should have returned the assignment itself, because that table is immutable >_>

Yeah, that's pretty much the biggest barrier for a lot of people coming from an OO background, the realization that variables themselves don't exist, and more importantly that they don't need to exist, and finally how to solve problems without them(and why for the majority of cases it's preferable to remove mutation). You're technically appending the value at each stage of the process(which you can easily see because a (for) can return EVERY version of say a hashmap generated inside a function, and can (reverse (first x)) to get the "last" update), so you're just adding new data to it with each operation, thus the very last operation is the one you want, not the reference to the original(as you found out the hard way).

Biggest "mistake" I usually see from lisp beginners is using tons of LET statements and treating them like local variables. In Clojure at least, anytime you'd want a variable, you actually want an Atom, and even then, Atoms are the last resort if a particular problem doesn't match functional composition really well(like doing transactions on very stateful external service APIs).

[Corrderio]

So Yuri, did you use any sites for hame dev or was it something you dabbled with using previous experience?

[Yuri-G]

mostly google and previous experience. I have just enough OOP in my background to be able to pull off a moderately complicated game, as long as I have an engine to work with (I only know a tiny amount about coding graphics directly). it also helps that libgdx has a huge following on the internet and there is a ton of info out there; pretty much any question I've had I can just google it and find the answer


a lot of it is also "discover as you go" kinda stuff. so much trial and error. so much!

[Yuri-G]

Yeah, that's pretty much the biggest barrier for a lot of people coming from an OO background, the realization that variables themselves don't exist, and more importantly that they don't need to exist, and finally how to solve problems without them(and why for the majority of cases it's preferable to remove mutation). You're technically appending the value at each stage of the process(which you can easily see because a (for) can return EVERY version of say a hashmap generated inside a function, and can (reverse (first x)) to get the "last" update), so you're just adding new data to it with each operation, thus the very last operation is the one you want, not the reference to the original(as you found out the hard way).

Biggest "mistake" I usually see from lisp beginners is using tons of LET statements and treating them like local variables. In Clojure at least, anytime you'd want a variable, you actually want an Atom, and even then, Atoms are the last resort if a particular problem doesn't match functional composition really well(like doing transactions on very stateful external service APIs).

it's a different way of thinking for sure. my professor pointed out the other day that in Clojure, recursion is basically the only real way to repeatedly run code - and recursion just happens to be something that most OOP people I know avoid unless it's a really obvious fit for the problem. it's hard to think recursively. our last problem was to run through two lists and figure out if the elements matched up or not; that required nested recursion and I just about shat myself lol. sat there for a good five minutes asking myself "how do you recur twice in one funtion...?" I figured it out in the end though

[Corrderio]

mostly google and previous experience. I have just enough OOP in my background to be able to pull off a moderately complicated game, as long as I have an engine to work with (I only know a tiny amount about coding graphics directly). it also helps that libgdx has a huge following on the internet and there is a ton of info out there; pretty much any question I've had I can just google it and find the answer


a lot of it is also "discover as you go" kinda stuff. so much trial and error. so much!

Got it. I suppose I need to dig a bit deeper since the issue I have with a lot of "tutorials" is they go on a "This is how you do it" route and don't explain jack.

[Yuri-G]

yeah, a lot of the tutorials expect you to understand the underlying concepts fairly well. sometimes they don't explain much of anything and you just kinda have to use intuition and prior knowledge to grasp what they're talking about. for example, the drop game tutorial I used to create my first game taught me to place graphics on the screen, move them around using user input, and detect collision. it never really tells you that's what you're learning, so you kind of have to intuit "oh, I put the bucket graphic on using this line of code, I bet I can do that again with a different image if I wanted" and then you take that and make a new game with it.


if I didn't have a decent background in OOP - not a lot, just a couple years of college and some random practice - I would be absolutely lost. I'm not sure where your coding skills are at but that might be something to work on?


also other computer science classes have helped a lot - discrete structures being a huge one for me. definitely useful.

[Yuri-G]

implementing merge sort in Clojure and my brain is like "HAHAHAHAHAHAAHAHAHAHAHAH no."


edit: n/m, that was easy. it only looked hard because the professor used the wrong function name in two places in his notes. which makes a big fucking difference, if you ask me. but once I realized his mistake, ez pz


welp, my homework for the week is done lol

[Yuri-G]

ok, I have a general Clojure question if Darus is around. if not, I'll email my prof tomorrow


nevermind. AS I WAS POSTING THIS, I figured it out. if you're interested, read below.

Spoiler: show

let's say I create the following hash-map:
(def keyRing (hash-map - '(sub) + '(add) * '(mul) / '(div)))


why does THIS call work:
(get keyRing -) -> returns (sub)


but THIS call does not:
(get keyRing (first '(-))) -> returns nil


answer: because first '(-) returns '- as a literal, and not - as a Clojure operator. I redid the keyRing:
(def keyRing (hash-map '- '(sub) '+ '(add) '* '(mul) '/ '(div)))


and now it works.

[Darus Grey]

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

[Yuri-G]

yep


and... ok, what the fuck?


> (def b '(1 2 3))
#'sandbox18451/b
> (list? b)
true
> (def c '(1 2 3))
#'sandbox18451/c
> (list? c)
false


??? what just happened there?


edit: ok, seriously. wtf. is it just the website I'm using? because it also does this:


> (def c (list 1 2 3))
#'sandbox18451/c
> c
(1 2 3)
> (list? c)
false


on http://www.tryclj.com/


I think the website is just doing something funky; I try that in an actual compiler and it correctly outputs "true" for those tests. weird.

[Darus Grey]

yep


and... ok, what the fuck?


> (def b '(1 2 3))
#'sandbox18451/b
> (list? b)
true
> (def c '(1 2 3))
#'sandbox18451/c
> (list? c)
false


??? what just happened there?


edit: ok, seriously. wtf. is it just the website I'm using? because it also does this:


> (def c (list 1 2 3))
#'sandbox18451/c
> c
(1 2 3)
> (list? c)
false


on http://www.tryclj.com/


I think the website is just doing something funky; I try that in an actual compiler and it correctly outputs "true" for those tests. weird.

Yeah, it's problem something to do with how those websites bound the code for safety is my best guess, if it was happening with an actual JVM runtime I'd recommend rebooting the runtime, because all VM languages are prone to dangling objects with code changes(where different versions of an object haven't been properly GC'd and you get weird behavior where references are hitting old targets even if you updated them).

[Corrderio]

Question time.

At some point we need to pull production data down into our testing environment at work. And to comply with our cyber security team make sure there is no sensitive information. After some looking it's just the SSN that's a flag so once we push the data into testing we need to scramble the SSN. The question is does anyone have any good advice on how to scramble a SSN? We don't really have anything set in stone but my boss would like them to look somewhat like actual numbers instead of being something like ###-99-9999.

I'm not really sure if it's overkill, but one method I was thinking of was creating an int array and having the index match the current digit and index's value be the new digit ([0] = 7, [1] = 3, etc.) then just go through each card's digit and update it.