accatyyc

Agreed. This is just like when I tried to grok monads. So many articles trying to tell me how simple they are... yet still so many articles needed to explain it (and I'm none the wiser)

One "creative" use is project setup. Sometimes, less technical colleagues need to run our application, and explaining git and recursive submodules takes a lot of time, so I usually create a Makefile with a "setup" target that checks out submodules and generates some required files to run the project.

You can still do that. Just last week I hacked together a quite useable web page using simple HTML and a few <?php-snippets to make it useable :) Don't need JS for everything.

To expand on my other answer in regards to this - I wouldn't say we have a glut of qualified applicants. It's pretty hard to find the great developers, and the reason we bin the generic ones is that we have never found a fit through one of those. Also it simply takes too much time to move further with those applications. I'd rather be programming :)

That's some good feedback! I will try to think about making sure that our job ads contain enough information about the role. Hadn't thought about that. Thanks!

Depends on your point of view. In terms of amount of applications, no. Loads of people apply, but in terms of finding the right person, yes I think it's very hard. It takes a huge amount of time, and all the generic/automatic applications certainly don't speed up the process.

Regarding job applications: when hiring people the first applications we send to the bin are generic ones. I really despise them because we get so many of them. We spend so much of time reading applications that if an applicant can't have the courtesy of writing a personal email it really leaves a sour taste.

So to actually answer your question - when applying, write why you are interested in the job. Make it at least sound like you know what the company you're applying to does. Ask questions about the job. If it's just some generic "I'm good at this and that" we'll just throw it in the bin even if you seem to have the skills.

I code in C so can't speak for C++, but I imagine it works well for that too: irony-mode as a backend and company-mode as frontend. It pretty much gives the Xcode auto-complete experience, and I think it works great!

What's worse... the refactor functionality for renaming used to be great, but when swift came along it stopped working for Objective-C as well...

I'm in the "never use fixed size integers unless needed"-camp. For example, if you write code that's supposed to run on an 8-bit computer (something embedded) as well as your 64-bit desktop, it makes no sense to limit yourself. For example, say that you know that your number will be between 1-200, you could use uint8_t. But why not use int? It will be the native width of the platform, and likely to be faster. Calculations on an 8-bit int can be slower than 64-bit ints on your 64-bit CPU, because the CPU might have to mask out the relevant part of the register to only operate on your 8 bits. And you don't gain anything by writing uint8_t, you still need to occupy a register on your CPU (which will be 64-bit). The behavior of your program will be the same on both platforms.

I really disagree that this is madness. It may be madness to someone not used to coding in C. But if you code a lot of C you _will_ know when to use which one of these, and you will know that they're immensely useful.

For example, iterating and adding stuff to arrays:

array[index++] = object;

instead of

array[index] = object; index += 1;

and the other way around:

array[++index] = object;

instead of:

index += 1; array[index] = object;

There is no way you will miss incrementing your index here, or do it in the wrong place. This is so common, that as a C-programmer you WILL recognize this pattern.

It's even better when iterating pointers instead of integers. May I ask what the following means to you?

float *float_ptr; float_ptr += 1;

I think writing ++float_ptr here is just much more clear. Incrementing pointers by integers just feels wrong when what you really are doing is incrementing it with sizeof(float_ptr).

... and put all their keys and values in Redis. And use curl for testing their revolutionary REST-API!

But what if your IDE simply adds the debugger buttons to the touch strip instead? They could even have the correct icons and update state as you debug. Seems even better to me.

It says in the linked article that it will only be available in the phone apps for the moment.

One example is that if you don't need a specific size, using the loosely defined types may be faster. For example, if you specify int32_t, but your program compiles for a 16-bit platform, then instructions operating on this variable may need to run twice, since the registers can only fit 16 bits of data.

And the other way around: If you specify int8_t, but your program runs on a 64-bit platform which only can address memory in 64 bit chunks, then you might waste 32-bits of memory for this variable, and addressing it can be slower since the program has to find the 8 interesting bits in a 64-bit register, and discard the rest of the bits so they don't affect calculations.

The only reason to use specific sizes IMO is if you work with loads of data and need to pack it efficiently, or work with bit-specified protocols like TCP packets or files. If you need _at least_ 16 bit of data for example, then you can use the int_least_16_t, which may be 64-bit or 16-bit depending on the architecture.

It is the title of the blog post though, which is a Microsoft blog. I don't think clickbaiting was the intention of the poster.

Not really. He suggests that if a function is called from multiple places, one should try to make it pure to avoid subtle bugs. If called from a single place it may be better to inline it.

Citation: "I don’t think that purely functional programming writ large is a pragmatic development plan, because it makes for very obscure code and spectacular inefficiencies, but if a function only references a piece or two of global state, it is probably wise to consider passing it in as a variable."

This would maybe be possible in C if the "functional" keyword was added (as suggested in the letter), and the compiler can be sure that the function doesn't use anything apart from its (const) arguments to generate a return value.

Then it also would need to make sure that those parameters can't change between different calls within the same function.

This wouldn't be feasible in the example above, since that function explicitly depends on outside variables. If you were to supply both `health` and `alive` as arguments, you could pretty much write the check yourself from the beginning.

Of course, there are many bigger checks that could benefit from this, but still, you (or the compiler) have to make sure that all functions are pure, that no arguments can change etc etc. I imagine that this could make compile times quite slow (and also complicated to write the compiler itself).

I'm not really sure I agree with communicating over the network in your GUI anyway. A git frontend shouldn't handle the connections, this is what libgit is for. Which would probably use curl or similar internally. Both of those are written in C, and are also reasonably secure as far as I know.

I stand by my point. Simply "not using C" isn't magically going to make your application so much more secure.

C is simply the Correct Tool For the Job when writing cross-platform (native) UI's. It's simple, it's callable from almost any other language, and all OS GUI API's are already in C.

There has been a lot of negativity/arguments against C here lately, which in my opinion has been very exaggerated.

Seriously, how often do you guys write GUI apps that _also need to be secure_? An application isn't secure just because you write it in another language, there's a lot more work to it. If there is even such a thing as secure.

How so? The likely reason is that a C lib is usable from many other environments. Look at ncurses for example. Heavily used from many languages, and written in C.

Another reason is that the underlying tools used by this library are likely in C as well, so it's probably the easiest language to use for the task.

Yes, but he means that "end users" of CocoaPods are actually developers. It's a package manager for libraries.

Very cool idea! I could add a simpler variant of what you're suggesting by not allowing cursor movement past opened tiles. Thanks for the input :)

Yeah, I think it could work. I at least got some "vim-flow" by playing nethack!

I felt that I could maybe get better at Minesweeper with a keyboard interface, so I made this game with ncurses. The controls are inspired by nethack/vim (but arrow keys work as well).

When developing it, I made the game logic into a library, which was also used by a friend to create a GameBoy version! Check it out: https://github.com/rotmoset/gb-mines

But why does it matter? With your solution they'll have two "task files" to manage instead of one.

Why should they switch over?

Check out this article! http://www.senocular.com/flash/tutorials/transformmatrix/

It helped me understand them quickly, with easy to understand, practical examples.

Don't mind the "Flash 8" context, there really isn't anything flash-specific in there.

That sound pretty crazy. The reason to use RVM is to be able to run Ruby programs with different Ruby versions... How would you run it in the first time if you have the wrong versions?

I guess bash is a good choice since it can be run pretty much everywhere.

Quite a few. Especially our designers/people that doesn't commit/use git very much but still have to use it, have a hard time grasping the difference. The git client they're using being called "GitHub" doesn't make it any easier!