-
I decided to just write what I felt and fuck whatever programmers think. I wrote it, put in a couple of jokes and trolls, and then posted it. Fuck it, I have a cold and don’t give a fuck.
And there would be absolutely nothing wrong with this, if the post in question wasn’t targeted at beginners as a learning resource. Learning resources for beginners should be held to a much higher standard than rants intended for your personal blog, and they definitely shouldn’t include subtle technical “jokes and trolls” which beginners are by definition poorly equipped to understand.
This is just plain irresponsible and the guy ought to know better.
-
There’s another argument that this article doesn’t really address: people struggle with monads because they’re introduced to monads (the solution) before they’re introduced to the scenarios in which monads are useful (the problem).
For me, as for many others, there was a particular monad tutorial that finally made it all click. The tutorial in question succeeded where others had failed because it separated the explanation into several deliberately ordered steps:
- Introduce a few example problems, along with a preliminary solution (no monads involved!) to each problem.
- Point out the repetitive structural similarities between the given solutions.
- Show how the structurally similar bits of each solution can be factored out into a single class.
By introducing the problems first, and then presenting the author’s thought process as they work through the solutions to these problems “in real time”, the tutorial in question helps clarify the why behind monads: why did we start using monads in the first place? The vast majority of monad tutorials make no attempt to answer this question.
Of course monad tutorials about the
Monadclass are written in Haskell, because it uses two language features not present in other popular languages. JavaScript, Ruby, Python don’t have a type system. C# and Java have generics, and Common Lisp has generic functions, but none of them have value polymorphism. The whole reason that Haskell is used to teach this concept is because it’s only a satisfying class in Haskell.The monad tutorial that worked for me was written in Ruby. I don’t think that a monad tutorial has to be written in Haskell to be successful. It certainly helps that Haskell’s type system forces you to use either monads or hand-rolled “monad-like” solutions to certain kinds of problems, but I think it’s possible to write an effective tutorial in practically any language, as long as the why behind monads is made clear.
-
I more or less agree with you here, but I do think that just how crufty the syntax gets in a particular language can really impact whether monads end up being compelling as a solution to the problem. If you introduce the problem, and then introduce a solution that seems just about as verbose and tedious as the one it’s replacing, then it ends up not seeming so great. See, for example, “Why monads have not taken the Common Lisp world by storm”.
-
-
As much as I want to like stateless password managers, I don’t think they will ever work in the wild. Inevitably you will come across a site with stupid password restrictions that will reject your generated password.
-
I don’t want to let the perfect get in the way of the good. We can get 95% of the way there if the generated passwords have one lowercase, one uppercase, one symbol and are 16 characters or less. A crowdsourced spreadsheet of the password ‘rules’ for popular sites would let us do an even better job.
One change I’ve been contemplating is to always append a ‘bang’ at the end of the password to accommodate the ‘one symbol’ rule.
-
-
-
“Embed the rules” strikes me as the game design equivalent of the programming maxim “make illegal states unrepresentable” (at around 18:06). There’s a lot of interesting parallels to be drawn between game design and programming; both disciplines spend a lot of time pursuing ways to represent and communicate systems of rules, often really complicated ones, in ways that make sense to human beings.
-
journeysquid
3 years ago
|
link
| on:
Pennsylvania to Become First State to Use “Precrime” Statistics in Criminal Sentencing
Isn’t this just likelihood to reoffend? Seems like a lot of buzzwords for something that’s still based on past behavior.
-
Same. One of the factors is criminal record, which sound more like post-crime than pre-crime. Then they mention sex, but there’s zero info provided about how such factors are weighted or interact.
This would be a much better article if it focused on what’s actually different. It sounds like parole boards are already making these decisions. Codifying it upfront seems much preferable than rolling the dice with them.
-
The original FiveThirtyEight article is much better than the Infowars post, both at explaining what’s actually different and at discussing the different factors that Pennsylvania’s proposed sentencing tool takes into account. It also addresses arguments in favor of the proposed changes, and even attempts to anticipate potential questions from the reader rather than taking the reader’s position on the issue for granted.
-
Nice. I’m much happier I read the whole thing now instead of just the quoted sections.
The example of the drunk driver is interesting. He says he’s never breaking the law again after a year in prison. One wonders why he’s decided that now, as opposed to after his first two arrests. Is identifying him as high risk the wrong decision? (In order to get four points, that requires over 7 priors. So actually he hasn’t had two prior arrests, it was two DUIs, plus five other crimes.)
To answer my earlier question, the scale is available in the sidebar. https://espnfivethirtyeight.files.wordpress.com/2015/08/lb_sentencing_chart.png?w=607&h=650
It’s interesting to see the age ranges vary. Also, Allegheny County is apparently bad news.
-
-
-
-
I think a thing missing from Stack Overflow’s worldview is that, as you move along in you career, your questions either:
Start being super super super specific to your situation (“On WhateverBSD 4.2, using Erlang HPE compiled with Clang 3.0, I’m getting E_OBSCUREST_OF_ERRORS…what can I mount to /proc to work around this?”) and so you may well receive no answer whatsoever before you grind through it.
Are high-level opinion questions, which are totally valid (“Which of these two approaches is currently the industry standard? Have you ever been bitten by this?”) but appear to be silly subjective slapfights to mods.
There probably could stand to be a place (C2 wiki, maybe?) for at least questions of the second type.
-
I think Programmers Stack Exchange, which claims to focus on “conceptual questions about software development”, was created specifically to handle questions of the second type.
-
-
It amuses me that we’ve got this paragraph:
I get the sense that Python-first programmers are missing out on a lot of the fun of programming
immediately followed by this one:
At times, you will want to punch the monitor and weep on your keyboard.
The absolute worst way to encourage people to learn to program is to start them off with a language that is known for frustrating learners to this degree.
In education there’s this concept of the zone of proximal development (ZPD for short). Essentially, knowledge of a field can be divided into three distinct zones for any given learner. There’s stuff that the learner already knows or is capable of doing on their own; stuff that the learner is capable of doing with guidance but not alone; and stuff that the learner simply can’t do yet at all. The second of these zones – stuff the learner can only do with guidance – is the ZPD, and it’s here that the learner is outside of their comfort zone but not so far outside as to be incapable of making useful progress.
Of all the people I know who’ve tried learning to program in any language, I’ve never once heard any of them complain that it wasn’t sufficiently challenging to hold their interest. On the contrary: learning to program involves learning a completely unfamiliar paradigm of interaction with the computer. Suddenly, instead of pointing and clicking on things, you’re writing code in files and struggling with the command line. Experienced programmers consistently underestimate the amount of culture shock this transition causes in and of itself.
When you pile onto this necessary culture shock the profound inaccessibility of a language like C, you’ve got a recipe for turning smart people off of programming forever. To give a beginner C is to plant in their head the idea that Real Programming involves wrestling with pointers and buffer overflows, completely disregarding the fact that a great many Real Programmers never even have to touch C in the course of their work. The beginner rushes headlong into C, discovers that writing even a totally unimpressive program (e.g. a number-guessing game on the command line) involves a huge amount of cognitive exertion, contrasts their own meager successes with the enormous scope of their favorite website or iPhone app, and concludes that they’re simply not cut out to do Real Programming.
If you want to encourage smart people to learn to program, then give them the tools and guidance they need to write something meaningful. Everyone wants to make video games and apps; hardly anyone starts out with a burning desire to learn how to hand-write the fundamental datastructures that eventually enable you to write useful programs a couple levels up the stack.
No one can possibly become a good programmer without first becoming a programmer. Leading with C is an excellent way to lose beginners before they even get that far.
-
[Comment removed by author]
-
It seems like there’s a false dichotomy being drawn here between the “extreme minority” driven by “personal agendas” and “activists who care about the actual cause”. There’s room in activist movements for a variety of approaches, and pitting individual activists with differing views against one another as if activism is zero-sum is a classic derailing tactic.
Some of the concerns you have with the Open Letter are echoed and addressed by Jenn Schiffer in this blog post, which also addresses some of what I’ve touched on about zero-sum rhetoric. I’d recommend it to anyone who’s looking for a counterpoint to the Open Letter from a slightly differing (albeit still feminist) perspective.
-
-
In case anyone’s interested in playing around with tools.analyzer but wants to have some documentation on hand before diving in, I wrote a quickref to the AST node structures a little while ago.
I’m currently working on a project that leans on the analyzer pretty heavily, and I’m convinced that the AST-as-data model is going to revolutionize Clojure tooling in terms of quality and ease-of-use. You can use it to write code that understands other code – making good on the promise of Lisp on a higher level than even macros allow.
I think the author misses the point. Enemy AI isn’t intended to be realistic or human-level challenging. The author even unwittingly provides evidence when he mentions the guards yelled “flush him out” before throwing a grenade. That dialogue isn’t there for the AI, it’s there for player to hear, deal with, and learn from. They only yell at each other for the player’s benefit. Hearing “flush him out” and having a couple seconds to do something is much more fun than being pinned down, spraying some fire, trying to figure out what you’re going to do, and then cutting to a game over screen because the enemy tossed a short-fuse grenade you didn’t hear hit the ground over the gunfire, shot you through a window instead of crashing through it, flanked you by coordinating with hand signals instead of yelling, etc.
FPS enemies are fodder. It’s really obvious in stealth games, where the lone enemy always goes to investigate that odd sound/movement directly instead of taking backup. They’re person-shaped challenges, not persons. The “realistic” approach would look like real-world police/guard response protocol, which is something like: find cover, call for backup, keep your damn head down, just stay alive until an effectively infinite amount of heavily armed-and-armored experts arrive. Not fun for the player when a single misstep means the mission is over.
Speaking of not fun, I remember reading an article on Gamasutra 10-15 years ago talking about a AI in a stealth game (maybe Splinter Cell?). In an early build, if a military guard spotted the player and wasn’t spotted themselves, they’d take the correct action: silently shoulder their rifle and plug them in the back. It turned out that players weren’t too happy about gameplay that went “sneak, sneak, peek, sneak, btw you’re dead” with no idea what happened. They changed it so guards spotting would always yell in alarm or call for backup, then run for cover. This was all timed slow enough the player could turn around and see who’d spotted them to learn from the experience. I couldn’t find it again, but Gamasutra and other industry sources have no shortage of info on how to develop fun AI, and most explicitly mentions that the goal is not complexity or realism.
+1. There are a couple of games that are interesting in relation to this topic. The first is ArmA, which is not renowned for having fantastic AI (if scripted badly, they can just be stationary mannequins standing in a field). However, the AI reacts fairly competently and realistically to contact: they spread out, seek cover, and return fire. It’s extremely easy to screw up only slightly, get noticed, and then hear “chunk” as a bullet kills you, without ever noticing the AI squad that spotted you (or knowing why).The second is Invisible Inc, which went through several iterations of adding more and more information to the player’s knowledge, until it’s basically a puzzle game rather than a traditional “try try again” stealth game. The result is one of the best “stealth games” around, to the point that I have no urge to ever play a traditional stealth game again.
One of the funny things about Arma is that, iirc, they only use one thread for AI.
They eventually added a way of adding dedicated headless (read: AI-only) servers.
So, one of the main clans (Shacktac) tried this out.
This did not end well for them.
First half of that was useless as I have no idea what was going on. Might have been better to show first team’s perspective. Although seeing their bodies everywhere later knowing enemies must be somewhere had a nice, survival-horror flare to it. The second part was fun. Also, interesting in that it gave me ideas for AI patterns that could’ve given the humans hell. Especially a combo of scouts to spot positions of soldiers all clumped together followed by combo of nade spamming that area to flush those that survive w/ MG’s or rifles waiting at likely exits. Is there a write-up on the AI that was used, though, as it seemed OK?
The gameplay trailer for Invisible Inc did look neat. Funny quip that the executive’s computer was “the larger one with the simplified controls.” Haha. One thing I didn’t get was what effects came with the security level going up every turn. They had that happening and were setting off alarms. So, it wasn’t clear what reactions each were producing outside guards showing up. Also, can you move bodies so they don’t see them or that becomes immaterial to its style of gameplay?
The security level is the clock that drives players through the level. It ticks up every turn or based on certain player actions (getting spotted, knocking out/killing advanced guards, triggering particular hacking defenses). Every 5 ticks fills the circle, the number goes up in the middle, and something bad for the player happens. Effects include changed patrols, additional guards, increased firewalls, elite guards who can scan areas to find agents in cover, and instant locating of one or two agents (which alarms every guard). The functional gameplay effect is that the player wants to move as fast as possible through the level, balancing speed and risk of detection.
You can hide bodies out of sight, whether they’re unconscious and will wake up in a few turns or dead. Unconscious guards wake up alerted.
Thanks. That sounds really neat. I like the diversity of it instead of “alarm followed by all guards coming after you” as only thing that happens in many games. I can already see how that might interact with the basic gameplay, esp if level design is good.
For anyone who wants to read more about these design considerations in the context of stealth games, I’d strongly recommend this article, the first half of which discusses the idea of the “partial failure margin”. Essentially, in a stealth game, interesting gameplay mostly takes place in the relatively narrow margin between total failure (i.e. getting caught and failing the level) and total success (i.e. sneaking through the level perfectly, with the guards oblivious to your presence).
Because this partial failure margin is where all of the fun takes place, it’s arguably the role of the designer to expand this margin as much as possible. Thus you get guards with deliberately “unintelligent” AI designed to draw out engagements with the player, rather than to shut them down as quickly as possible once detected (as would usually be “realistic” in the situations these games portray).
[Quick edit: just noticed one of the sibling comments here mentions Invisible Inc, which has also been discussed in greater detail by the author of the post I just linked. I’m also partial to this analysis, which talks about some of the same concepts under the label of the “failure spectrum”.]
The original Killzone AI was quite good at analyzing the battlespace.
As I recall, they had an issue where the AI got a bit too good at flushing enemies out of cover using indirect-fire weapons (rockets and grenades):
Exception to that good writeup being MGS 2 or 3 when enemies are alerted but you’re brinb stealthy. They do bring backup. They’ve occasionally put pressure on me if I landed a spot with little cover or escape opportunities.
I can’t find the link, but I remember watching a GDC talk about ‘smart’ AI, and this was one of the main issues that the presenter mentioned. You can spend hours designing and implementing complex and intelligent AI, but if that means that the player gets killed quickly then the game will seem unfair.
At the end of the day games are designed to be fun, and designing with that in mind is what will make a game memorable.
Agreed. Bots tend to behave predictably and stupidly so that one of the more fun and frustrating things to do is play with actual humans online. More when on a team match but sometimes in a pub game you get surprising use of cover and clever tactics. If you’re not playing enough to fully explore and memorize the maps you’re done. The Call of Duty franchise has realized that the stealth and snipe aspect annoys casual players so they’ve nerfed the long- and medium-range weapons except in hardcore mode, designed maps with short lanes and limited sight lines, bumped up health and healing rate, and fiddled with the mechanics of movement. It makes for a frenetic game that you can pick up and put down but takes away a lot of the reward.