I said, "Given two candidates with all things equal except ..."
I mean if there are two candidates who are equally motivated and are more or less equal in all things except that one is strong at CS fundamentals and another isn't, is there a good reason to reject the candidate who is good at CS fundamentals.
In many hiring decisions, I am faced with a similar choice, and I go for the person who is good at CS fundamentals. If two candidates are good in all other ways, then the understanding of CS fundamentals becomes a tie breaker. I see no rationale for selecting the guy who does not demonstrate his strength in CS fundamentals.
> though in this case the easy and correct thing for the interviewer to do is to say "OK, how is Collections.shuffle implemented?"
And very likely that's what really happened. I have been in such interviews and it is sometimes hard to guess whether the interviewer wants the practical answer (calling a library function) from engineering standpoint or the conceptual answer (demonstrating that I can implement the inner workings of the function) from CS standpoint. Often I would just ask a follow up question to clarify exactly at which level of abstraction does the interviewer want my solution to be in?
In situations where I offer a solution that does not match the interviewer's expectation, they clarify the expectations.
I think it's stupid to assume that a decision regarding time complexity would never come up at their job. Where I work right now, and especially in Google (not where I work right now), it is important that one understands time and space complexity issues well. The data sizes are huge and optimization skills are highly valued.
Sure I can teach constant vs. linear time. But what incentive or reason do I have to spend time teaching these fundamental concepts when I can just hire an engineer who demonstrates the understanding of basic CS at the interview time itself?
Given two candidates with all things equal except that one demonstrates the understanding of CS fundamentals and other does not, why would I want to hire the second person and spend our time teaching him those concepts?
I come across candidate A who shows up on time, with a good attitude, takes heat and shares credit, builds people up, isn't afraid to speak their mind and offers a smart-ass answer to a problem designed to evaluate whether the candidate understands the underlying concepts.
Then I come across candidate B who shosw up on time, with a good attitude, takes heat and shares credit, builds people up, isn't afraid to speak their mind and offers a genuine and insightful answer to a problem designed to evaluate whether the candidate understands the underlying concepts.
Ah! That makes a lot of sense. If Python 3 is the default, it does make sense 'pip' to be the Python 3 pip. That way 'pip' always refers to the default version.
Unfortunately in the Ubuntu and Mac world 'python' is still Python 2.7 and 'pip' refers to the Python 2 pip. Python 3 is available as 'python3' along with 'pip3'.
I am aware of that. So has been many other distributions like Debian, Ubuntu, etc.
My point was: Which command do you normally use to install packages in Python 3? pip3 or pip?
I thought it was pip3 but the article seems to imply that using the pip command to install packages in Python 3 is common too. If this is true, which distribution ships Python 3 with pip instead of pip3 for installing packages in Python 3? Does it not conflict with pip of Python 2?
> On some Python 3 distributions, you may need to replace pip with pip3 in the command above.
Are there any distributions where the command pip just works with Python 3?
In every Python 3 installation I have used, I had to invoke it as pip3. So it seems to me that pip3 is the commonly used command and one may need to replace pip3 with pip only on some distributions.
> ability to read code and locally easily reason about types only gets more critical as the application gets more architecture or performance dependent
Exactly! And using auto for variables with very limited scope where the type is obvious effortlessly does not negatively affect the ability to read code and in my opinion improves the ability to read code.
> Absence of explicit type info is an inherently bad thing.
Let me reiterate: It is your opinion which many people here do not agree with in the context of types obvious from context. Your opinion is definitely not a popular coding standard and definitely not a fact. Most of the coding standards are in favor of using auto for simple code where the type is immediately obvious from the context.
The auto keyword is available to help people who do not share your opinion. The auto keyword is present for teams which agree that absence of explicit type info is a good thing for simple code with obvious types (obvious from the context).
Teams that believe that absence of explicit type info is an inherently bad thing don't have to use the auto keyword. But that belief does not become a fact no matter how many times you reiterate that belief.
> paying the penalty of giving up valuable explicit info
That's your opinion. My opinion which many coding standards agree with: There is no penalty in giving up explicit type info in a local loop variable. The typo info is not valuable in that case.
> There’s absolutely no sense in which less explicit information is somehow better for code readers.
This is patently false. It has been demonstrated more than once in this thread that there clearly are cases where the types can be deduced effortlessly and avoiding explicit information leads to cleaner code.
Your claim is only your subjective opinion/belief and definitely not a fact.
We might just have to agree to disagree, but I would disagree with your claim here in the strongest possible terms. Constantly pretending as if your subjective beliefs comes off as obtuse and is in poor taste. There is one size fits all standard for coding. You are free to follow your coding standards and so is everyone else. What looks like an obvious argument to you may appear absurd to another. Like I said, the world of software development is far more heterogenous that you seem to believe it is.
> this kind of system that relies on the whole codebase having no localized type annotations (so you can’t reason locally about code when you go to refactor or change types, etc.), is so egregiously bad.
Nobody said that either. The parent comment specifically said that they have alternate types to provide different performance characteristics and behavior. Such code bases do exist contrary to what you believe.
Don't think of it as an Apple type suddenly replaced with an Orange type on one fine day and your head begins to spin when you try to understand what the code does.
Think of it more like int32_t being replaced with int_fast32_t because you realize you want to port the code to a new architecture due to which int_fast32_t makes more sense now. Now the argument should not appear as "egregiously bad" as you make it look like.
The world of software development is far more heterogeneous than what your experience might have led you to believe.
> In most cases it won’t be anywhere near this easy anyway
Then don't use auto in such cases -- is the point of the discussion here.
Use auto anywhere it is indeed nearly this easy.
When the situation is simple, auto clearly provides an advantage of automatically deducing types that are very obvious to humans and the compiler. The argument here is that not having explicit types here is better.
Your cannot use the word "strictly" here in the mathematical sense at all since you have not mathematically established that explicit types for simple cases are better. It is only your subjective opinion that explicit types are better even in simple cases and such an opinion is far from the exactness and axiomatic nature of mathematics.
You pretend as if the proposition that "explicit types are better" is an axiom. It is not. To many of us such proposition is neither self-evident nor obvious because many of us believe removing explicit types for simple cases is better. As such, the usage of "strictly" here is merely a weasel word.
> In that case, it sounds like very bad general software design that is not well-crafted to the problems you are solving.
That does not sound like bad software to me at all. It is quite a stretch to say that types changing during the course of software development implies the software is badly designed. This sound very backwards.
On the other hand, I believe a software that is malleable enough to handle changing types easily during the course of software development is good software.
The usage of the word "strictly" here is strictly sloppy.
Why is a typedef/typename better than using auto in this case? You can literally look up the actual type the auto keyword is deducing by looking at the function parameters two lines above.
How many new typedefs do you want to create for code like this? You are suggesting creating two typedefs for this tiny 4-line code only. Imagine how many typedefs you might need to create in a real and complex project. How is the mess of typedefs going to be any more maintainable than this?
There are places where the auto keyword would make it hard to understand the type and there are places where it won't. This is a place where the auto keyword does not make it hard to understand the type.
Don't use the auto keyword if you don't want to but pretending that there is no value in using the auto keyword by using weasel words such as "strictly" is disingenuous.
> let's just keep crapping on a company no longer under the same ownership
I have no intention of crapping on SourceForge. I am merely making an observation. I think many would agree that users have lost trust in Sourceforge regardless of the history or current state of ownership.
In fact, I used to appreciate loganabbott's (the new president of Sourceforge) attempt to amend SourceForge until today when I see the same person posting insinuating and insulting comments towards potential users.
I have no intention of crapping on SourceForge because SourceForge is largely irrelevant to me. I host my projects on GitHub these days. If GitHub becomes untenable for any reason, I might move to Gitea. But I am definitely not coming back to Sourceforge after seeing these juvenile comments coming off from the president of Sourceforge in this thread. Don't know about others but he has definitely managed to piss me off as a user.
Regarding why Sourceforge gets the kind of flak other companies don't, I have commented about it here: https://news.ycombinator.com/item?id=17281519 (again this is merely a conversation, not a passing of judgement).
You are insinuating both Websense and me that we are not informed about the current state of Sourceforge. Insinuating your potential users like this is in poor taste considering you are the president of Sourceforge.
I am very much aware and I followed the HN thread [1] when you acquired Sourceforge and when you commented extensively trying to reassure us that you will turn Sourceforge around. Sure you have made efforts but I think it is quite clear that the good measures you took came a little too late.
Frankly, your comments in that acquisition thread [1] were more balanced and matured. The comments you are posting in this thread are coming off as immature.
You also seem to be misinformed about Websense. Websense and other web application firewalls and content gateways are very much in use in many corporate networks including mine. Looks like I am not the only one with this issue.[2]
We also need to think a little about how the times were. Sourceforge rose to popularity in the early 2000s. Free and open source software (FOSS) was not just a matter of pragmatism or convenience. It was an ideology, a philosophy, and a movement strongly pushed forward by FSF, Open Source Initiative, various LUGs, and various special interest groups. Open source enthusiasts used to have very active and influential LUGs all throughout the world. There used to be free and open source software conferences all over the world with the sole agenda of increasing open source awareness among the general public.
In those years, most of the developers who chose to host their projects on Sourceforge strongly believed in this ideology. GPLv2 was the most popular open source license then. Given all this, it makes sense that those early users who held freedom of software to be sacred were very pissed when Sourceforge decided to bundle closed source adware into the binaries of these open source projects without the explicit permission of these open source developers.
Times have changed a lot since then. GPLv2/v3 license is now considered too restrictive and the MIT license is more popular. Most of the tech community understands the concept of open source more or less. The movement in favor of software freedom has begun to lose momentum. Open source software makes a lot of business sense, so we don't need the push for open source software anymore like we used to in the early 2000s.
Even some people like me who once would run nothing but completely free operating system with free tools have now begun to use proprietary drivers because as we have grown older, got busy, with kids and family, the time spent tinkering with open source drivers is not worth it, we would rather use something that just works. When we use Microsoft and Facebook we know what we are getting into and most of us are more or less okay with it. It's different times and different kinds of users. That explains why Microsoft and Facebook do not get penalized as heavily as Sourceforge did. Sourceforge violated something that was held sacred during those times. Microsoft and Facebook have no notion of sacred-anything.
Websense blacklisted Sourceforge after the 2013 DevShare debacle. It has remained blacklisted since. It is blacklisted in many other web application firewalls and content gateways too. Sourceforge is inaccessible from many corporate networks due to this. It will remain inaccessible for many more years to come.
It's unfortunate how Sourceforge, once a leader in the open source community, lost the trust and reputation it built over 14 years in a matter of a few weeks. It may take another 14 years to regain this lost trust and even that may not be enough.
Congratulations on making a successful release. Kudos to you!
I am going to post a concern regarding the increasing layers of abstraction which is not at all directed at your project but at this domain of managing containers, in general, and the never-ending increase in complexity.
So first we find it difficult to manage so many virtual machines, we got Docker which was a good concept.
Then we found it difficult to manage so many Docker-based services so we got Docker Swarm and Kubernetes.
Now it is difficult to manage Kubernetes, so we have got a new project to manage Kubernetes.
I mean if there are two candidates who are equally motivated and are more or less equal in all things except that one is strong at CS fundamentals and another isn't, is there a good reason to reject the candidate who is good at CS fundamentals.
In many hiring decisions, I am faced with a similar choice, and I go for the person who is good at CS fundamentals. If two candidates are good in all other ways, then the understanding of CS fundamentals becomes a tie breaker. I see no rationale for selecting the guy who does not demonstrate his strength in CS fundamentals.