Errr... how much income do you think makes you 1%? Hint: it's $150k/yr. That's not "upper middle class". I understand that there are a lot of people here that might make that, close to it, or more because software is very lucrative, but don't let that skew your perception of the world.
Where's your $150k coming from? The figure I usually hear cited is $350k, though that's for "household income". Adding to your main point though, it's also worth pointing out that $150k in, say, downtown New York is pretty different from $150k in, say, Cheyenne, Wyoming. But I'd still call both "upper-middle class." Maybe it's near the lower-fuzzy-boundary of "upper middle class", but I don't see how you think it's a classic "middle class" salary. It's certainly not an "upper class" salary.
$190K is the number for that I've always heard thrown around for individuals, which, if both parties in the household are earning that much, easily adds up to $350K and more.
The hardest part about this entire project took me about an hour to figure out. No, it wasn't sorting. No, it wasn't trying to organize or query search results. It was God damn JavaScript Closures. Believe it or not, out of everything, this took me the longest to figure out. I was close to just saying "Fuck it" and not allowing people to click on links.
Sounds like underscore.js would have cut your development time by more than 25%. You should check it out - it's a great library.
It doesn't matter how hard switching is for the browser, what matters is how hard switching was for the OS - that's where Microsoft had a monopoly. In that, switching was very hard. They were trying to leverage that monopoly in a new market (browsers).
The key point. SW online does not have the charachteristics of natural monopoly. I have 8x choices in my integrated search bar (the default ones on Firefox). There are some network effects, or returns to scale from usage analytics that impact quality, but that is a different animal. MS Dos / Intel x86 technical architecture was actually exclusive.
Also, with MSFT was clearly a case of prediatory pricing funded by cross-subsidy from the monoply business. They set out to 'kill' netscape in its infacy as a business stratgy. Google is arguably just doing its job, and doing it better. Advertisers fell like there is "no choice" (because of scale), but they are sock-puppets. The consumer is the searcher. Advertisers have plenty of other places to advertsise online, so there is no monopoly.
It's very easy to give someone a list of concrete things they need to do about communication: 1) respond to emails within one business day, 2) update your manager and coworker 4 days before a deadline if it looks like you'll miss it, etc.
On the other hand, it's very hard to give someone a list of concrete things that will make them a better programmer. I suspect if you tried, you'd end up with very subjective things like 'strive for readable code' etc.
Yes, it's easy to give someone a list to do, but if you want him to do exactly what you want him to do, there's one certain condition: the man must be good at communication.
I got some colleagues who are like the guy in this post, it's very hard to let them see the importance of communication, they are very stubborn. Mostly, they see what they are doing matters.
I'm not saying teaching someone coding is easy, but at least you can see some progress on this, which make both side much easier.
I'm not a big user of Python, but it seems to me that any language that requires you to embed a different language for performance is inherently broken.
To regular pythonistas: Is this a common issue with Python, or only in the author's contrived scenario of summing a ridiculous amount of numbers?
I'd actually call it a feature, and not a bug or flaw, in Python.
You can prototype something in Python (or another language with native hooks) very, very quickly. If that thing works, you can roll in ctypes or cython and get your code running as quickly as C. Thus, you get quick development + numerous paths to native-level performance.
That's much better than taking longer to develop a library or model in C/C++, only to find they don't satisfy your needs.
By your definition all dynamic scripting style languages (lua, ruby, perl, etc.) are inherently broken. Very few languages out there can reasonably expect to get C like speed for numerical work without dropping down to C. All this shows is how relatively easy it is to do when you need it.
One of pythons really big and popular uses is as a powerful language for tying together high performance low level C/C++/Fortran libraries for serious numerical work (see libraries like numpy, numexpr, scipy and so on), so as such calling C libraries from python is about as standard a scenario as you can get.
It's a contrived scenario. I've used Python a ton and never needed to break out to C, certainly not for summing numbers. Granted, I use Python mostly for web development, but I do care about performance.
In case of number crunching, I've heard numpy is very good and fast at number crunching using arrays, and the crunchy parts of numpy are written in C.
All that said, why is a language "inherently broken" if it requires you to use another language for tight-loop performance such as this? Game and graphics developer writing in C break out to assembly for things like this -- is C also "inherently broken"?
Wow, I don't think I've ever had such a visceral reaction to anything I've posted on HN before. By people who clearly didn't take the time out of their day to even read what I posted!
Basically, I don't use python very much and wanted to know if python had performance issues that required you to drop down to C code often, or if that was just for a scenario such as this.
I think that any language that REQUIRES you to drop down to a lower level for performance (not one that SUPPORTS it, but one where it's REQUIRED) is inherently broken. I would think that would be a pretty noncontroversial statement - if every python script you wrote had to have embedded C code because otherwise it was too slow, that would be pretty broken. That's why I wanted to know how common this was.
I think the reaction was because you put Python in a broadly negative camp by infering ctype extensions are required for any sort of performant code. Its actually relatively uncommon to use ctypes and most developers who use Python know this.
Python is a great general purpose language and is used as such. No one would be silly enough to solely rely on it in highly performance sensitive environments (IE: 3d renderers or high frequency trading). Just like no one would be silly enough to write an entire CRUD web app in C.
The point is, Python isn't broken and claiming that it may be because you read a short article on a Python feature got you the negative reaction.
I never inferred that ctypes were required - in fact, I explicitly did the opposite. I asked if it was required for performant code. See the part of my post where I said "To regular pythonistas: Is this a common issue with Python, or only in the author's contrived scenario of summing a ridiculous amount of numbers?"
> I'm not a big user of Python, but it seems to me that any language that requires you to embed a different language for performance is inherently broken.
It seems like you imply both of those things, though perhaps not as explicit as "Python is broken because ctypes are required", which you did not say.
Words like "Slow" and "Performance" are very relative. Yes python (well at least cPython) is a very slow language (on par with the likes of ruby, lua, perl, php etc.) and yes if you really need performance you really need C (again, not that different from the above mentioned language) and yes most non-trivial python code relies on C/C++ in at least some point.
However very few python coders find themselves actually writing C code when working in Python. Most rely on existing libraries that put a nice python wrapper around highly tuned C code, and in many cases most python programmers are only vaguely aware of which libraries are pure python and which are wrappers.
I think that any language that REQUIRES you to drop down to a lower level for performance.
Again without defining "performance" this statement means nothing. All languages (even C) have cases where you are required to drop down to a lower level to get the fastest possible performance.
That's why I wanted to know how common this was.
Depends very much on what you're doing. If you're doing web development, it's very uncommon. If you're doing fairly performance critical numerical work over very large data sets, then it's much more common (but even in that case the kind folks over at numpy and friends have done 98% of the hard work for you).
Whether calling c is "required" depends on a few things. The relative importance of run-time vs programming-time, the nature of the problem, etc.
I've been doing scientific programming in Python for 4 years, and I've never felt I needed to drop to C (though I was aware of the option.)
The hard computing for most problems is done in calls to a few libraries that wrap highly optimized code from lower level languages. So matrix inversion, arithmetic on arrays, etc are just as fast in python as in C or Fortran.
If your work can't be done using library calls, pure python is going to be much slower.
As dagw mentions - treat it as a feature. I taught High Performance Python at PyCon, I've published all the src and a 55 page PDF covering a range of techniques to optimise a Mandelbrot example (including cython, shedskin, numpy, multiprocessing, pycuda): http://ianozsvald.com/2012/03/18/high-performance-python-1-f...
With some languages this is painful, with Python you can easily profile (cProfile, line_profiler) and then work on easy or complex optimisations (both within Python and using external tools) - great flexibility for when you really need it.
Obviously broken, because all possible uses of a programming language require the absolute utmost speed. Every other consideration of language design, usability, and ridiculous fluff such as "productivity" must kowtow before the god of performance.
So C/C++ are also inherently broken because game engines break out to raw ASM at their mist critical points? Or Java because it exposes native code via JNI?
This is actually totally standard behavior in pretty much every language.
Hi there, I'm the author of the post (my username matches the domain of the post =D )
The purpose is just to show an example of how to drop to C.
I chose a contrived example so the reader could expend the minimum possible number of brain cycles (so to speak) trying to understand that part of the code.
It seems like the author is taking a specific subset of ed-tech ("online learning companies that rely on the student's intrinsic motivation") and trying to generalize it to all ed-tech.
There are TONS of different companies doing some really interested stuff in ed-tech. Not only are there lots of ed-tech companies that aren't online learning companies, there are a lot of online learning companies that DON'T rely on a student's intrinsic motivation: e.g. anything in the K12 space - there are a lot of K12 schools that are beginning to incorporate online learning into their curriculum, and then there's plenty of extrinsic (e.g. grade-based) motivation to do well and perform.
I think my #1 takeaway from this is that the author isn't the target market for most of these ed-tech companies. They're not trying to get people to take these classes for fun, no more than colleges want people to take classes for fun.
I'm definitely aware that there are tons of companies doing amazing things. But I think that people are confusing tools for communication with tools for education, and that the distinction is unfortunately larger than the landscape suggests.
Great point about incorporating behavior though - technology that molds and aids existent behavior is always needed!
The biggest argument for not validating email addresses shouldn't be that "it's hard". It should be that email providers don't always follow RFC guidelines. At my old job, we had this really weird bug that, after a lot of work, we tracked down to users who legitimately had greek letters in their email addresses.
If there are legitimate emails that don't follow RFC, you should absolutely allow users to enter non-RFC-compliant email addresses.
It's not hard, though. Anybody can go online and search for an email validating regex, but as some have pointed out, many are too strict and don't allow for, say, tagged email addresses ([email protected]). There's email validation, and there's overkill. That's what I was trying to get at.
The difficulty of writing regexes for email validation wasn't the main point - the main point was that emails don't follow spec so any regex based on that is inherently wrong. However, it seems like saying "most email validation regexes are broken" is equivalent to saying "email validation regex is hard"
This post really spoke to me - all my life, I'd lived in the Midwest - first in Minnesota (coincidentally enough) then in Illinois for college. In October last year (the beginning of my senior year in college) I received a nice, safe offer as a Software Engineer at Google and that was my plan: do the 'Google thing' and see how I felt two, three, or four years down the road.
Fast forward to May of this year, I saw a job posting here on HN for a YCS12 company that was looking for a summer intern. I sent them a short email, not knowing really what was going to happen - one thing led to another, and before I know it I'm flying out to San Francisco the day after I graduate to begin my internship!
I can honestly say that this summer has been the best summer of my life - I've learned more than I thought possible, worked more than I thought possible, and had more fun than I thought possible.
And that safe job offer from Google? Well, I'm not doing that anymore - I'm the first hire at a very promising YC startup that I'm in love with.
Errr... how much income do you think makes you 1%? Hint: it's $150k/yr. That's not "upper middle class". I understand that there are a lot of people here that might make that, close to it, or more because software is very lucrative, but don't let that skew your perception of the world.