Before I do anything "risky" with forms I copy the text AND paste it somewhere else to confirm I really copied it. Only then do I take the next action, and still I get burned all the time by crap like this one way or another.
I usually just start from typing it up in emacs, then copy paste it to the fussy little form. Anything over six words, it probably saves me time, even if nothing was going to go wrong. And then… Just as you said.
I recently had a complaint form refuse my complaint because it was too rude!
There wasn’t any bad language in it at all. I removed the sentence "It’s now more than two months since the accident and I would have expected the repairs to have been completed by now” and that let it through - sensitive or what?
I once had the opposite experience. Calmly and amiably complained about an employee misbehaving, but got asked aside by the manager to talk. She asked me to put the complaint in writing through their system and, looking directly at my eyes, added “Please feel free to be as explicit and emotionally expressive as you want. Don’t refrain from expletives, rudeness and bad words. We would really, really want to understand the extent of your upset over this situation, you know what I mean?” That’s when I realized that she wanted to fire this employee guilt free and was asking me to give her the ammo for the firing squad in front of HR.
Using “self documenting” as a blanket excuse to not document things that need it is inexcusable, yes, but I’d rather work on code written by somebody who seriously thinks about how to make it clean and self documenting, and then documents whatever still needs it as well, than on code written by somebody who doesn’t make that effort, but documents heavily. And as for people who claim they’re documenting everything, when the documentation is function fooTheBar() // foos the bar, they can eat a bag of docs.
100% agree. Sometimes I start a comment and realize I’ve either explained exactly what it’s doing and delete it or just update my variables to be more concise.
My job doesn’t like when I document the parameters and return type/value of methods. I think that that is really important in a dynamic language like Ruby and sets expectations that the method should ONLY return that type.
I mean, you aren’t wrong in your joke. Godot’s pattern is slightly but not much better. Unreal is far more structured and realistic but still lacking in a lot of ways.
Unreal is what I have the most experience in. It’s very strict and structured. Everything in Unreal is a UObject. There are Actors and Actor Components. Every feature has a requirement, such as, some of the AI features require you to have your AI as Pawns which are Actors that can have a Controller (an actor that manages the connection to a player) which then there is a PlayerController and an AI Controller which can hold a behavior tree to tell the AI how to control their pawn.
In Godot, things are far less structured. Godot has everything based on Nodes like Unreal but it expects you to build out whatever you want. So it doesn’t come with Behavior Trees or the concept of a player. It expects you to build these things. Mainly because it’s a budding engine that hasn’t had the maturity or time put into it like Unreal.
Unity is a mix of both. Unity has a huge freeform nature to it. Again Unity starts with a class, everything in Unity is an Object. It has the concepts of Components that attach to a GameObject (which GameObject and Object are different). There is no Actor class, and no defined way to move an actor across a floor, a controller object in Unity is seen as the place where all the logic to control the actor is. So Unity has its own structure but it’s also less built out like Godot. As such the AssetStore in Unity has taken the task of providing whatever the developer needs. So a Behavior Tree system on Unity differs from project to project from whatever they made or bought off of the store. Unreal allows you to, of course, use something else for behavior trees but no one does because their base implementation works and works well. It’s standardized.
So overall, Unreal is standardized, strict, and gives you a ton of features. Unity is less strict, provides less standardized features, and forces developers to make their own things. Godot furthermore is less strict, has very little built-out, and the standardization it’s attempted to create gets changed in the next major update because it’s very new.
They never tried to push the language and make it mainstream, but this is somewhat changing since the Haskell Foundation started a couple years ago.
Also, if you only know C or Java, then it looks a bit alien.
I’ve been using it exclusively at work for about 4 years and it makes writing correct code and maintaining it much easier than anything else I’ve tried so far.
haskell is one of the mathematically founded functional languages, which is a whole family of loosely related languages that have seen lower uptake over the years. Other examples include ML and variants, and F#.
There are a few reasons why adoption has been slow:
poor outreach by language founders
less focus on commercial use
novel syntax
core abstractions that differ from mainstream
Many of these are seeing some change. Haskell is getting better at outreach and comercial focus, and Rescript (ml for the web) has a lot of syntactical similarity to ja|ascript.
Yeah, I wish F# was used more often. I actually learned it for fun, and it would be great to work with it. Unfortunately I haven’t heard of any F# job in my country yet.
(I wonder if the F# people have tried doing outreach via F# memes, should work IMO, good names that also fit slang abbreviations are a very contested and already expended word space)
Functional programming requires quite a shift in how you think about designing and debugging code. If you’ve spent your whole programming life thinking procedurally and approaching debugging by stepping through, it’s not an easy mental reset to make. And many languages these days can give you a taste of the functional style without taking away so much that is familiar, giving you some of the advantages of functional programming, such as clean code that’s thread safe and free of side effects. People under time pressure are likely to stop there.
It’s a cool language. Main problem is that it’s difficult to recruit for. Not many developers know Haskell well enough.
Haskell also makes many huge sacrifices for purity. Accessing the file system is quite wonky. Basic stuff like maps aren’t easy to implement either. In the end, it’s a language great for toy examples, but turns into a massive hassle once you want to do real practical stuff.
I think everybody should at least learn it. You’ll learn some cool stuff that will be of use in other languages.
Basic stuff like maps aren’t easy to implement either.
This is mostly due to a preference for immutable data structures. That said, the standard library has a balanced tree-based map that’s not too complex.
If you want a good immutable data structure with O(1) find and update, you’re unfortunately looking at something like a hash array mapped trie, but that’s the same in e.g. clojure or Scala.
The problem Haskell was trying to solve was that in the late 80s, there was a bunch of interest in lazy functional programming but all the research groups had to write their own lazy language before writing a paper on whatever new feature they were interested in. So they banded together to create Haskell as a common research program that they could collectively use.
It’s been remarkably successful for a research language, and has become more practical over the years in many ways. But it’s always had the motto “avoid (success at all costs)”.
IIRC, the majority of Haskell enthusiasts’ day jobs are coding in Java, and things like monad transformer stacks and applicatives are things they daydream about as a coping mechanism against the tedium. Which is probably why Scala exists.
programmer_humor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.