adios spittin' hot fire lately about all our terrible teachers

obvious solution appears to be that he should take an online teaching position so we can all learn from non-insane teachers imo

I Tell him to have his wife watch 50 Shades of Grey and that as his co-worker you would appreciate a bit more than 2 hours a day.

This is exceedingly common in almost all teachers. This is why profs at Stanford/Harvard/MIT who have real world experience are as expensive as they are.

I checked this thread on my phone for the first time in forever today. I read the problem itself but not the followup discussion until I got home several hours later, having worked it out mere minutes before walking in the door, only to find you guys already figured it out. Probably the worst I've been nerd sniped in awhile!

Depends on what you want to make constant.

Your example (const int* a) does not allow you to point a to another address, but you still can change the value.

int * const a : would make the integer itself not changeable, but allow you to change the address of the pointer.

const int * const a : now all is locked down. (Well, sorta. 'til someone comes along with const_cast.)

I'm considering starting a thread on a deeper dive into C++ and C. One post I'm considering at deeper look into how the compiler will actually put data into read only sections using const. Also suzzers nicknamed "sudoku" solution that he posted. It shows the candidate learned well in his undergrad work but it definitely can be improved upon greatly. It is a simple problem but an illustrative one and a thank you to suzzer for posting.

For you, I'm positive that contrasting the solution in C++ with a solution in Python will be an eye opener.

adios, do you work with C++11/14 or mostly older versions? How's the industry's doing in terms of migrating to the newer standard and taking advantage of newer features?

I've decided I'd like to try my hand at making iPhone apps, so I'm learning Swift. One of the language features is named parameters in function calls. I can see how this would make code more readable so I'm on board with it, especially since code completion within Xcode means I'm not really slowed down by the extra typing this would involve otherwise. But Swift's rules for when named parameters should and shouldn't be used seem very strange to me. This stack overflow page gives an example:
http://stackoverflow.com/questions/2...-name-in-swift

It turns out that if the function is declared outside of a class, you call it without named parameters, like this:
But if its a class method, the first parameter can't be named and the second parameter (and all subsequent parameters) must be named:
Which makes sense to precisely nobody who hasn't seen it before. There's a way to force named parameters to be used in the call by including # before the parameter name in the declaration, like this:
Really wish function calls would either always use named parameters, or not use them at all. The default behavior is a confusing middleground. I might just start including # in front of every parameter name in every function I write.

Oh yeah, there's also such a thing as external parameter names and internal parameter names, which can be different.

Can't imagine ever wanting to do that.

Obviously that's from Objective-C but I wonder if they had to do that for compatibility reasons or they were so used to it from years of abuse that they started thinking it was a good idea.

Yeah having separate external/internal parameter names makes sense within the context of Objective-C naming conventions (something I'm vaguely familiar with). Apple appears to still be promoting those same naming conventions, as in this example from the Swift Programming Language book:

So if you've got parameter names prefixed with prepositions in the function call (it reads like a sentence!), you maybe don't want to use variables with names like "toString" and "withJoiner" inside the function. What is a withJoiner supposed to be anyway? No idea whether it's for compatibility reasons as well, but even if it isn't, that naming convention kind of demands multiple parameter names to not look stupid. Meanwhile I don't need my function calls to read like sentences. I'll take one name per parameter, please.

Isn't it the other way around? From what I remembered, you are suppose to read it from right to left.
so
I read this as, variable number is a pointer to a integer that is constant.

I read this as, variable number is a constant pointer to an integer.

Good stack overflow explanation

Yep Barrin, I got that the wrong way around. Thanks for pointing that out.

"Read right to left" is a great way to memorize it. Surprised I haven't heard that before.

Ok well I submitted my framework on HN. Feel free to upvote or leave disparaging comments: https://news.ycombinator.com/item?id=9261423

Aw man someone at ycombinator renamed my catchy title.

Upvoted, but looks like it's too late...

What was the original title?

"nodules:node::JSPs:Servlets "

I figured it might get some attention at least. I don't really know the hacker news community that well though.

6 upvotes. I'm rocketing up the charts!

Hey, big favor, I have a test in about 2 hours and Big O notation is probably gonna be represented pretty heavily on it.

I got the concept of O(log n) algorithms pretty well, but I am struggling to find or come up with an example of an O(n log n) algorithm.

Many sorting algorithms are n log n.

Take a look at the diagram in the top right of http://en.wikipedia.org/wiki/Merge_sort, it's a pretty good visualization of an n log n algorithm.

Thanks!

I'm to #134. Rocketing up the charts. I created an entry on r/node as well http://www.reddit.com/r/node/

I gave you an upvote in both places, you may have released this at non-optimal time

The time of brandnewframework.js being on the HN front page is pretty long gone really, no matter what it is.

i feel like i see them fairly often still....

Yeah, definitely this.