marxama

No joke, I'm 31, only 2-3 years ago the companies were all over me, I would get offers right and left. Now, not so much, I've noticed a pretty huge difference.

I love Smallworld, and yeah, I never get tired of it. Another one whose rules are pretty straightforward is Power Grid, been playing it for years and it hasn't gotten old yet (except for the sometimes pretty sudden and ruthless endgame).

One thing is that a lot of testers are still working in a very rigid way. First, design and write down the test cases (based on a specification that is most likely flawed and incomplete). Then, perform the tests. Then, document the results. There is very little room for creativity and exploration in such a process.

This is basically what you do when you write automated tests, except the execution (and reporting) steps will be done automatically and repeatedly. Which is super valuable, but when a skilled tester goes at it, there will be ideas and crazy connections flying around everywhere. Even if many of these tests were to be automated (which in many cases really isn't feasible, considering implementation time/execution time/maintainability costs), you'd need someone to even think up the tests, and typically developers don't have the time or breadth of knowledge of their system to do it.

I used to work in a team with 5 developers and me as the tester. Besides finding tons of bugs - many of them very subtle - I became the one person who understood the product best since I was the only one touching all parts of it, so I was the one people came to for questions. Now, working as a developer, I do write automated tests, but I refuse to release anything our tester haven't had the time to test yet.

I don't understand why people seem to think that testers could or should be replaced by automated tests. I've worked a lot with test automation, and I find it super important to have automated tests for any long-living project, but one of their main purposes are to off-load the manual testers from doing repetitive regression testing, and focus on more creative exploratory testing - things that humans (well, some) are good at, but computers are not.

In addition, testers should play a central role when it comes to validating requirements - they typically catch issues and inconsistencies that would otherwise go unnoticed until $x has already been spent on going down the wrong path.

Great read, thanks! The same effect was used brilliantly in Monaco.

I think it's also interesting to note that sometimes when choosing immutability as the default, which gives a slight performance penalty for basic operations compared to doing normal mutation, you end up being able to save lots of performance on a larger level. React wrappers in ClojureScript, such as Om, are a good example of this - since data is immutable, shouldComponentUpdate is automatically and trivially implemented for you, leading to oftentimes better performance than straight React. I reckon this would also be the case with the lock-free code you write in Clojure, etc.

That's good to know, thanks for pointing it out!

IRL, I've actually met two people who've watched and enjoyed talks by Hickey, but I haven't met a single one who's actually tried Clojure...

I disagree, I've come across several cases where front-end-only state need to be shared by components not naturally sharing some common parent component in which the state should reside.

This post is enough for me to decide to get this NOW.

Every so often, I use strings in my code. F# gives me no compile time checks against null references when I'm dealing with strings, nor any other reference type. I did mention that the constructs F# provide are not nullable, which is nice, but that doesn't mean that F# is NRE free. As I said, F# is a nice language, but the "no null reference exceptions" claim, if anything, is misleading.

(I'm not very experienced with F# and would be thrilled to be shown that I'm incorrect!)

> no null reference => no null reference exception

This is only true in the same sense that there are no NRE in C# as long as you don't use reference types. F# seems to be a fine language, and its non-nullable types are certainly a good thing, but you have to handle null references in F# just like in C#.

> 6. Nulls are NOT allowed, in general.

I really want to like F#, but that's a really big "in general". I love the idea of option types, but I often hear with regards to F#, "forget about NullReferenceExceptions!". Yeah, that's nice, except I sometimes use strings in my code...

What I would've liked is to have F# strictly forbid nullable references, and treat all reference types in interop situations as (implicitly) options. Not sure if that would be possible, haven't given it too much thought and I'm sure there are tons of tricky cases that haven't occurred to me, but I haven't really seen this discussed anywhere.

That's really nice. Is it possible to do the destructuring directly in the argument list?

ClojureScript, along with Reagent (or some other React.js wrapper like Om or Quiescent - I currently prefer Reagent, which has been gaining lots of traction recently), Figwheel and a browser REPL, has really had a lot of impact on how I view GUI development.

I do Winforms development in my day job and I hate it. The feedback loop I have from changing something in the code to viewing it in the application can be a matter of 1-2 minutes (need to compile, start up, login, setup everything to the correct state, etc). Going from that to being able to grow the application in real-time, without ever having to restart/refresh, is amazing, and makes me feel infinitely more productive. Combining it with Cordova to make mobile web apps, where I can deploy once to my phone and then have changes be applied over wifi as I type them into my text editor, is super sweet.

Getting everything set up can be a bit tricky, but https://github.com/plexus/chestnut makes it a whole lot easier.

I got to use it a bit in a Real-Time Systems course I took recently. I wasn't too excited about it starting out, it didn't initially feel like much more than a different C. As I've been spending some time with Clojure's core.async, I was really pleasantly surprised when I came to realize that it offered a really nice CSP implementation! Didn't go much further than that, but seems like a nice language that I wouldn't mind using more.

Another thing is that the F# example has equality semantics built in, whereas in the C# example, you'd have to override Equals (and GetHashCode), adding more lines still (for some tedious work that you shouldn't have to do).