384 karma · joined April 24, 2009
That idea of showing the top 10 trending bugs is a good one. I also like the StackOverflow approach of suggesting dupes immediately as you type stuff in, so it would be rad to have a tracker that does that.
Actually if we compare the Stack Exchange hatred list against the TIOBE index, then we can correct for the amount of 'expected' hatred (the kind that is proportional with usage)
VBScript: Hated much more than expected
PHP: Hated more than expected
Java: Hated less than expected
Visual Basic: Hated slightly more than expected
ColdFusion: Hated much more than expected
C++: Hated much less than expected
Disclaimer, those are a bunch of vague guesses based on two sources of questionable data.
I hosted the files in a Github project so that other people could find it in a nice convenient way. As far as I can tell, this is allowed by their license terms.
http://github.com/paulhodge/EASTL
Keyframe, Let me know if you want a shoutout, I can add your name to the README.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227...
and these things seem to be missing:
priority_queue, rand, deque, numeric, stack
But most of the fundamentals seem to be there, so it looks like it's still a useful chunk of code. My guess is that they deleted anything that EAWekKit didn't need.
Worst. List. Ever.
But, if you write one of those, at least try to be realistic. Too often I find comments saying "XXX THIS MUST BE FIXED IMMEDIATELY!!" in code that hasn't changed for years.
There was a good discussion on the list: http://groups.google.com/group/emerginglangs/browse_thread/t...
Basically if your language uses floats by default then it will get that challenge wrong, and if it uses fractions or arbitrary-precision decimals, then it'll get it right.
First, the post presents itself as a harmless and useful source of information. There's nothing to lose, and you might be informed or at least entertained if you keep reading.
The story spans several different aspects of human behavior. At some point, it might touch on something that you've personally experienced, which makes you more interested in the post.
As the post goes on, it begins to accumulate reasons why the topic is important, and how it can potentially affect you and your life. Before you know it, you begin to feel like you can't afford to ignore the provided advice.
Then finally, the trap is set! An affiliate link is posted, and all you have to do to feel better about the situation is whip out your credit card.
Here's how you can avoid buying a book that you don't really want:
1) Recognize the signs
2) Use a web site that allows comments to publicly mock the blog post. Not only does this give you the enjoyment of being a jackass, you can transform your reticence into a noble cause.
I hope this advice has been helpful!
If HTML could reliably do everything Flash does that would certainly save us a lot of effort, but that does not appear to be coming to pass.
which is probably referring to how HTML5 does not have: efficient vector-based animation, support for audio mixing, strong tool support and ecosystem for creating interactive content, a pathway to run C code (Alchemy), etc.
2) If you have a design but are just trying to figure out how to implement it, then TDD can help a lot. Write a test that checks if your thing does what it is supposed to. Then run the test, it should say you have X failures. There, now you have a concrete problem to solve: you need to fix those failures.
3) If you are intimidated by a large coding problem, try instead to just make the simplest possible prototype version that just barely works. Even if this exercise causes you to write throwaway code, it's worthwhile. Once you have something working at all, it's easier to think about the features that you need to add to make it finished.
In general I think people get blocked when they try to solve too many open-ended questions at once. So try to break apart your problems into bite-sized pieces, and find ways to turn your open-ended questions into specific, measurable problems.
These days, git-svn is much smarter about recognizing a SVN branch, so it doesn't have to re-checkout the whole world.
"Boot Camp now includes HFS+ read support that enables you to access the files on your Mac OS X partition from Windows. It’s read-only to prevent PC viruses from affecting Mac OS X,"
1) Being forced to click "Trust" just to watch a video is pretty bad, and would turn away many of your users.
2) Having an alert box "Are you sure you want to leave this page?" is also pretty bad, and unnecessary.
Overall, I can see the value that this technology gives to you (less bandwidth). But what value do you give to the consumer? Why would I want to endure the various hassles of this site, and give up some my scarce upstream bandwidth, when I could just go to Youtube or Vimeo instead?
I think the most common reason for me to cancel a comment is just knowing how internet people are. People on the internet, especially software people, are really really critical. I think there's a certain group of people that browse forums with the sole intention of pointing out how other people are wrong.
So sometimes if I have a slightly controversial opinion, I will just not bother commenting, because I don't feel like dealing with the nitpickers.
Search Flickr by color: http://labs.ideeinc.com/multicolr . This one lets you pick a palette of several colors, and the UI looks better.
Various other crazy ways to search Flickr: http://mashable.com/2007/07/11/browse-flickr-photos/
One thing is automatically preserving state across a reload. This is really hard if I allow the programmer to store state any way that they want- I can't tell which things I should preserve. So the language forces the programmer to declare their stateful things in a special way.
Another thing is introspecting on code. I want to be able to click an image and then see all of the calculations that went in to that image's position (maybe so that I can change them). But this is pretty hard in most languages. Aliasing makes it hard. So this language discourages operations which are hard to introspect.
So I could theoretically support Ruby or something, but it would turn out to be "not really Ruby", because there would be a lot of stuff you wouldn't be allowed to do.