Pretty much every social network ever has a feature to “block” abusive users. So yes, usually you have access to your own personal hellban, if you want to think of it that way.

My sentiments exactly.

I dare say, perhaps this would be another good fit for a browser addon? Something that may compromise the site’s goal, but could still be useful for some users. (Obviously, the result would be greyed-out or striked-out entries, rather than big blank gaps)

It’s absolutely not censorship in any case. It’d be pretty silly to say that I’m censoring someone by ignoring them.

The user controls who they wouldn’t like to see, not an organisation.

I’m always reticent of the possibility of censoring people.

A user is still submitting content to the site which is displaying it by default to everyone. For those that want to opt out, i.e. filter a user, it’s no different than filtering a tag. If it’s censorship, then so too is tag filtering. I don’t see it as any worse in that regard. And it’s potentially much more effective, without forcing me to filter tags I don’t want to filter. (I will do this if I have to or possibly just cull my reading of lobsters, whichever is easiest.)

For example, I find Haskell (and functional languages in general) to be less readable than their imperative counterparts.

It’s interesting because my non-technical friends find imperative languages to be equally less readable as compared to functional languages. This may sound like hyperbole. But bear with me, because I truly believe there’s something important that’s revealed about our assumptions here.

So what exactly do I mean? You learned one way of formulating logic and now it feels natural to you. But I argue there’s nothing inherently natural about it. At least not in a way that isn’t inherently true of functional programming or logic programming or…

Learned patterns do feel natural, but you probably could have just as easily learned some other paradigm and then have argued that imperative languages were difficult to read.

Does poor readability cause errors when code reviewing or when translating requirements to code?

The salient point here is that this whole “functional programming just isn’t as readable” argument is specious: once you learn the idioms, it isn’t true. Also keep in mind, you had to do the same with the imperative paradigm as well.

So no, it doesn’t, because people who have learned functional paradigms don’t suffer from this mythical poor readability ailment. Granted, if you aren’t familiar with a given paradigm, then it’s legitimate to state that for you there is potentially an issue of readability.

My advice? Learn functional programming! :) It really isn’t as hard as it might seem.

For example, I find Haskell (and functional languages in general) to be less readable than their imperative counterparts.

You really need to qualify readability before talking about it. The only sensible definition of readability that I’ve found is “to what extent does this code preserve equational reasoning” - a definition which is not only simple but also measurable.

Which is exactly why I find Haskell to be readable.

Does abstracting the underlying hardware to high level abstractions cause performance issues down the road?

Haskell is extremely fast precisely because it’s high-level. A compiler has deep introspection into your code. For example, it can inline code, automatically specialise, fuse equations and decide when things should be evaluated.

It seems like it’s possible to write solid code (or shit code) in any language.

I don’t think this is true. Would you be so diplomatic to Malbolge, INTERCAL or Whitespace?

I agree that programming is not the end goal. You use the tool that is best for the job. Go happens to be a very good tool for distributed systems.

Having said that, strict functional languages like Haskell sometimes are the best tool for the job. In my compilers class in university, we developed a compiler in OCaml. Things like algebraic datatypes and pattern matching come in really handy when you’re processing a complex AST. I wouldn’t say functional programming languages are less readable. If you get familiar with the language and do things in an idiomatic way, the code can be very clear and concise. Also, you tend not to run into bugs because the compiler detects a lot of them as type errors (although the compiler error messages can sometimes be really cryptic).

One more point to the readability of code. The longest part of the software development lifecycle (open source or otherwise) is maintenance. If the code you wrote truly has no side effects then it should be really obvious what’s going on when you go to track down a bug 5 months after you wrote the code. Of course this may or may not have anything to do with the language (though perl is fairly frequently a write once language) but there are languages that take longer, and are generally coded in a fashion that’s harder to troubleshoot and read later on. For instance, concurrency in java can be done and is more easy to read than in assembler. There are languages that just about any developer can jump in and read and figure out what’s going on… now being that I’m not smart enough to learn Haskell I have no idea what it looks like.

It solves many large-scale production problems extremely well, and its concurrency model is neat as well. (I’d prefer to use Clojure and core.async, but that’s just me.)

One thing to note here, I believe it was Rich Hickey or perhaps Timothy Baldridge who pointed this out at Clojure/conj 2013: “I wouldn’t want to use any language that only had a single concurrency model”, to paraphrase. This came up during a core.async discussion and I think it’s a really good point to make.

Consider that while CSP-style concurrency is clearly suited to many problems, you still need to be wary of deadlocking the parent thread. This implies that certain tasks should not happen on the logical threads provided by Goroutines or inside go blocks in core.async, e.g. blocking IO.

A related problem is that when you’re given a lens with which to see the world through, you start to see all your problems in terms of that framework; if given a hammer, suddenly you see nails everywhere. So in the case of CSP and Go, the danger, I think, is that then you start to shoehorn all your problems into what Go is capable of. Whereas a language like Clojure gives you the same capabilities in terms of concurrency model, but also allows you to do what you want by way of providing additional models for concurrency and being flexible enough for you to do essentially whatever you want.

If you’re just playing, now is a great time to start. But don’t put any stakes on it. You can make OSS projects, but keep in mind there’s still a bit of work version to version to keep them up to date.

Compile-time typing definitely has its uses, but most of the time, what people care about is interface integrity– which ought to be a high-ranking consideration no matter how dynamic the language is.

Very recently I found myself lamenting the fact that Python by-and-large completely eschews this, primarily in terms of culture. The argument is always “well it’s duck-typing, so get over it”. But while this may sound fine on the surface, I challenge people who advocate duck-typing to come up with sane ways of managing consistency and understanding in large code bases and teams. I work with a fairly small team and even here we have plenty of issues with team members simply grappling with and understanding the code. This is what was so eye-opening about Schema for me and frankly I think languages like Python could really benefit from something similar.

I don’t know if there is a big group of users that will want to filter out clojure but not lisp.

Conversely, I find that tags are useful for filtering positively, rather than negatively. In other words, I can see all “compsci” news as a separate view. This is exactly why it makes sense to have an Erlang or Haskell tag, and not simply a “functional” tag. While Clojure is debatably a Lisp, it would be nice to have a Clojure view, given its idiosyncrasies juxtaposed the broader Lisp world via the “lisp” tag. I certainly enjoy reading about Scheme and Common Lisp, but sometimes I prefer to read about Clojure specifically, as opposed to other Lisps.

FWIW, I am definitely one user who’d be interested in news about Clojure but not the wider world of lisps - the communities seem different enough that I’d expect this to be relatively common, but that’s really just a gut feel.

I worry a bit about this advice – asking tons of questions is working well for me right now, but it also depends on the market and how much privilege/power you have as an interviewee.

My advice to people interviewing is, don’t worry about fucking it up.

I think I understand the intended mindset this is meant to advocate, but I wonder if this works when I know I’m interviewing for my dream job? How do I not worry about the interview, when I, as the interviewee, already know the job is precisely what I want? This seems like a special case where my primary objective has to be to impress and possibly show I’m amenable (we’re talking about a dream job after all).

Further, what if I give the interviewer the wrong impression by asking questions that could either be interpreted as pedantic or intrusive? What if I give the interviewer the impression I don’t trust the company to get even the basics right? Leading with the impression that I’m concerned at once with small details most decent places are bound to get right or showing mistrust doesn’t seem like something an employer is likely to respond positively to. Conversely I do see how some of these questions might be interpreted positively, as showing an interest in the particulars of the job and how they relate to you as a potential employee–certainly that should be a positive signal to the interviewer.

However, if I know I’m interviewing for my dream job, I’m probably not wondering if they use version control, for instance. And asking a question like that seems like it could be a bit of a red flag or at best noise that could be avoided in favor of more relevant discussion. So maybe this list is potentially less applicable to an interview you know you can’t fuck up. In which case, I’m not sure I can walk into an interview without worrying if I’m going to make a misstep.