Dude, I have no issues calling a spade a spade, or recognizing that the kid in a wheelchair is never going to be an astronaut. But if you actually look at the speed of the TTS some blind programmers use, it's basically at the same speed most programmers read code at. You've still got the disadvantage of needing more short term memory, but that's about it, and it's partially mitigated by the speed of the TTS.

Now, you take a random programmer, make them blind, they're going to be pretty slow. But that's where the selection bias kicks in - anyone who persists with programming despite the difficulty of being unable to see is going to be pretty passionate about it, and as a result of this I'd expect the average blind programmer to be faster and expend more effort improving their ability than the average programmer.

There's a pretty good video here which should give you some idea of how blind programmers actually write code.

You would be wrong. Selection bias means that the few blind programmers are crazy fast.

There are plugins for all of those:

• code completion - YouCompleteMe
• code navigation - ctags
• debugging - vebugger

That said, I do agree with you about using the right tool for the job. What I usually end up doing is using Vim for all the actual text editing, and then switching to the IDE for more complex/specialised tasks like debugging or refactoring. The main reason for this is that while I don't consider myself a 'Vim wizard', I'm proficient enough with it that typing in a conventional editor feels painfully slow by comparison (especially since I often type Ctrl-W by mistake).

Protection from discrimination includes protection from a ‘hostile working environment’, which again applies in the UK and US. Any company which says it is ok to harass some people can potentially be sued by all of those people regardless of whether they have actually been affected by the policy.

...

Furthermore, not only employees but customers ... would be entitled to sue (see, for example, s29 Equality Act 2010). Furthermore their customers could be sued if they required any employee to work on the openly racist project. Worse for Ms Palamountain, UK law allows individual Defendants. Every single claimant could sue any individual responsible for discrimination.

No wonder they're back-pedalling - if it became more well-known that Github's paid users could be sued over this policy, the resulting exodus would annihilate their revenue.

Ok, so I was certain that there was a feature where you could group together related repos as a single project, but I can't seem to find any indication that such a thing ever existed. It looks like they'll be adding that feature soon though, so I wasn't completely wrong.

I'm sorry, but why hasn't anyone boycotted GitHub yet?

Network effects. Bitbucket actually has quite a few features Github lacks (e.g. ability to group together multiple related repos) and is, IMO, generally better, but it still has a much lower market share because the value of the site is directly dependent on the number of projects using it, since you need to use it for PRs and non-hostile forks.

grep -o "Hello world!" /dev/urandom

I'd say there's definitely a distinction to be made between programming and proper CS. There's already an (abandoned?) compsci board though - perhaps it would have made more sense to revive it instead?

I have a question for you tho, would you say it's more difficult for a woman to get a decent job as a programmer? Or is it about the same, or even easier? You may not even know, I just thought I'd ask.

Probably easier. Of female programmers I know, the distribution of their skills was basically the same as that of the male programmers I knew, so most of them could easily compete for the same jobs. Diversity is a buzzword now though, so there are lots of gender-specific opportunities out there for scholarships, internships, etc. They aren't jobs per se, but they definitely help you to get a foot in the door.

Can I have your bank account number?

12345 ;)

I'm not sure where people even got the idea that volatile was useful for multi-threading - the only place I've ever seen it used was with memory-mapped hardware (described in the article as "memory modified by an external agent").

NAT does not provide any additional security for IPv6, given that the address used publicly is generated randomly and changed regularly. Firewalling works the same as before, except the absence of NAT reduces the computational overhead.

The main holy wars seem to be around the lack of generics and some people missing exceptions

The lack of exceptions makes sense - I know some people avoid them in C++ because they're so expensive, and checking return values is more explicit anyway (especially if you force it by using something like Maybe) - but I'm curious about the reason for the lack of generics.

I wasn't aware it was out of beta, but does it have the sheer number of libraries of Java?

Of course not - Rust is barely a year old, and Java has been around for decades. Rust won't have the same no. of libraries until Java is well and truly dead.

The better question is whether it has libraries for whatever you need to build, and that's improving steadily. (Not to mention that you can always use C libraries, same as in D.)

That said, I haven't done much with it because I find the pointer system to be too constrictive. I wish they hadn't removed the GC pointer type from the language - it made it possible to use Rust as a high level language without worrying about ownership semantics. You can still do it with a template (similar to C++), but the syntax is much uglier.

Seconded - the type system really is something else. It also taught me the value of higher order functions and functional purity, which changed how I write code in other languages.

Interesting. I'm (pleasantly) surprised D ranked so highly - IMO it doesn't get nearly enough attention for what it offers.

The main issue with Java (when it comes to security) tends to be that it's usually used with massively overengineered frameworks that make it difficult to fully understand the implications of changes.

Java is popular because it's popular - students learn Java because that's what industry uses, and vice versa. It remains in use because it's just good enough to get the job done, but has enough problems (e.g. type erasure) that plenty of people despise it.

First language was C# - it's a nice mix of power and expressiveness, but the Linux support is pretty poor atm (should hopefully change in the future), so when I switched I had to find a replacement.

My current favourite language is D - it's very much like C#, but has great cross-platform support, Python-like meta-programming, and can link against C libraries. (It's overall aim is "C++ done right"). The only weakness is the fairly small community and set of libraries available for it.

Python is quite nice, but the lack of type checking means I don't trust it for anything other than small programs. I hear Nim is much better in this regard, but I haven't tried it out yet.

I think simply tagging posts could work - maybe have a tag for basic questions, and tags for language specific questions as well?

Wouldn't it be kind of hard to get advanced programming questions answered? What if one has an advanced question about the Go compiler, but most people hanging there are Java seniors? Questions would definitely be more visible here...

Most people would belong in both subs as well - someone could easily be a senior Java dev with a beginner's knowledge of Go.

That said, perhaps the programming sub should focus on questions which are general, and leave language-specific questions to their corresponding subs where possible? So a question about the differences between two languages might belong here, but a question about the best way to do X in Y language would belong in the Y sub (if it existed).

Pretty much this. There are a bunch of encodings that are theoretically possible, but in practice you can't beat an array of ints for performance on a COTS CPU. (Involve GPUs or FPGAs and it's a completely different story.)

Oh the irony... I actually did some work on (a fork of) that repo about a year back, before real life got in the way. There were basically two problems with it:

• the author decided to write their own version of associative arrays to fix some issues with the native implementation. Only problem was, it was buggy. I got the library to work by simply ripping out their implementation and using the standard one, but that meant it was a no-go as an upstream merge.

• signals & slots didn't work, and without them it was basically a proof of concept. I did some work on implementing dynamic signals/slots using C++, but I can't seem to find it at the moment.

I'm not sure if I'll resume work on it any time soon, since I'm going to be busy moving interstate in the next few months, but hopefully I'll get around to it eventually. Part of the issue is that I haven't done any GUI programming lately, so I need to get up-to-date with Qt5 and figure out if there's even any point in re-using the existing Qt4-only code. (w0rp made a bunch of design decisions that I don't entirely agree with, so starting from scratch is quite tempting, though it does increase the risk of not getting the project of the ground)

I suspect that if I don't get around to it soon, I'll keep getting reminded of it each time DConf rolls around (since it's the main thing preventing me from using D more), so I'm bound to start working on it eventually...

Yep, that pretty much confirms it's irreducible complexity.

That link actually makes a really good point about focusing on the concrete before the abstract. One approach using that would be as follows: most programmers have learnt a C-family language before Haskell, and are therefore familiar with NaN and how it propagates through FP computations. That's basically equivalent to the Maybe monad, so from there it's easy to generalize about applying that to arbitrary data types. (Or at least, that's how I made sense of it.)

There's a lot of good advice in the other posts, but here's one thing that most of them have glossed over: when interviewing for a programming position, 99% of the time they ask you questions about first year CS content - stuff like "implement a sorting algorithm". Read an introductory CS book (this was the one we used in my course) and you'll be fine. You might also want to consider learning C/C++ as well, just to round out your skill set a bit more.

People already use minifiers to compress (and obfustcate) Javascript. The reality is that those who care about open source will stick their code on github, and those who don't will put their code up in some reverse engineering unfriendly format, and life will go on.

This was how I learnt Haskell, a few years ago. It's definitely one of the more accessible approaches, though the language does get a bit more complex once you reach monads (that might be due to the irreducible complexity though).

And who needs a program to fit two megs of code anymore anyway?

Embedded systems developers. This becomes more important with the IoT, not less. Not to mention that even if you have GBs of RAM, you only have a few MB of L3 cache (to say nothing of the 64 KB of per-core L1 cache in Haswell...)

Whoops, looks like I missed it cause of the different name.

What idiot thought running javascript on a server was a good idea?

I think that could be said of most weakly typed languages. Type checking is one of the greatest advances in programming language design in the last century, and so many people insist on discarding it simply because they dislike compiler errors. Except, those bugs end up being run-time errors instead, which are even worse...

YAML isn't too bad actually (makes a lot of sense if you're doing Python work), but JSON is particularly amusing in that it was created around the ability to parse it using eval(), but people had to implement parsers because of the security implications of that...

There is no LispLisp. I am disappoint.

I LOVE C# as a language.

If you're feeling impatient, take a look at D. It's virtually identical to C#, except it has some more powerful features like compile-time function evaluation (CTFE) and templates, and has significantly better cross-platform support. The only issue is that library support is a bit weak, due to its lack of popularity (and vice versa).

Most of those reasons apply equally to C++, or to a lesser extent, D. (D is very C#-like and much more powerful, but isn't quite as polished.)

I tried picking using Mono when I first switched to Linux, but I gave up after I ran into some weird issue where programs wouldn't run as an unprivileged user. I don't think C# will be a real option for Linux until they get it working for LLVM and can generate native code with it.

Came here to post exactly this - D is an amazingly powerful language that really should be more well known. I've been meaning to create some Qt bindings for it to make it more viable for GUI projects - really should get around to that soon...

So what you're saying is that kids won't enjoy coding because you never enjoyed coding. You might be extrapolating a tad there...

Not all kids will enjoy coding, but then not all kids enjoy sport or art either. Those that do enjoy coding are likely to do so for the same reasons that adults enjoy coding. I got into it when I was 12 myself, and it was mostly for the enjoyment and challenge of being able to create interesting things. Give them robots and they'll have a blast with those, since they make it easy to see the practical consequences of their code.

You should learn C. C++ is a massively complex language, and the most recent revisions (e.g. C++11) avoid manual memory management in favour of automatic mechanisms such as shared_ptr. And trust me when I say that if you don't understand how to do manual memory management, Rust's system probably isn't going to make a lot of sense to you. Learn C, then look at learning C++ if you want to take on something more complex.

Is there an analogus web dev concept (that is not literally memory addresses)? Thanks.

The following analogy will probably suck cause I'm not a webdev, but here goes nothing...

Think about how you can look-up different elements by their id tags. You can call getElementById() multiple times, and it'll always return the same object for the same id. That's basically the same idea as with pointers, except instead of a string you have a number, and instead of getElementById() you have an operator, *. And instead of using .id to get the id of an element, you use the & operator.

Congrats on your first sub! (Would vote you up, but already used up my quota.)

I think my favourite tech book is The D Programming Language. It probably won't be of interest to you unless you want to learn D, but the thing that sets it apart is the style - it's extremely easy to read with a fair bit of humour, compared to books like The C/C++ Programming Language which are incredibly dry.

Practical Vim probably has the best ROI though - I can't think of anything else that has improved my productivity as much.