emelski

If you disagree with any part of the proposition, or if you feel it is poorly constructed, then you should vote against it. It's easier, ultimately, to reject a poorly written law and try again with a new law than it is to accept a poorly written law and later try to repeal it.

Too many people fall into the trap of believing "we must do something; this is something; therefore we must do this."

There are literally dozens of "make your own t-shirt" offerings online, most with a wider array of shirt colors and the ability to include your own graphics in addition to text, at a price comparable or cheaper than you are offering (cafepress.com, inktastic.com, etc). I've used these services myself and found them easy, not at all "cumbersome" as you state on helvetitee.com.

What value does your offering have in comparison to your competition?

I'm skeptical because I don't see how visual programming models are even possible for the type of development I routinely perform (my day job is writing a high-performance distributed, parallel implementation of the well-known 'make' tool). Even if it is theoretically possible, for some parts of my project, I imagine it would take nearly as long to create the visual programming environment, and I'm not sure it would be particularly reusable.

I loved Bret Victor's talk. And this recursive drawing thing is neat too. But both of those are dealing with programs that are primarily visual in their own output. I can't help but think, "That's neat, but not broadly applicable." Honestly, how many people are there out there dying to write programs to make fractal-like pictures?

Perhaps I'm just not visionary enough to see the potential, but I don't believe these techniques will really "democratize programming." Whether or not doing so is desirable in the first place is another debate altogether.

Wow, I did notice that when I first looked. I guess I've gotten too accustomed to the Web 2.0 presentation style, where the pricing is prominently displayed and there's an unavoidable call-to-action button.

I think my college-bound daughter would enjoy this if I gifted her a subscription. Unfortunately I can't tell how much it costs without creating an account (giving away my email), nor can I tell if it's possible to give an anonymous gift (because I find the idea of my daughter getting random socks anonymously hilarious).

I wonder why they chose to use compressed helium to fill the bag. I don't know much about these things, but helium is not cheap, and surely you don't need its lighter-than-air properties in this application. Couldn't you use compressed carbon dioxide, or even just compressed air? For comparison, apparently automotive airbags are inflated with nitrogen gas.

Here's the rationale from that document:

* C++ is a standardized, well known, popular language.

* C++ is nearly a superset of C90 used in GCC.

* The C subset of C++ is just as efficient as C.

* C++ supports cleaner code in several significant cases.

* C++ makes it easier to write and enforce cleaner interfaces.

* C++ never requires uglier code.

* C++ is not a panacea but it is an improvement.

It's interesting to me how defensive many of those justifications are. "It's just as efficient!" or "It's just a superset anyway!" Not until halfway through the list do we get any real description of expected benefits: C++ makes it easier to write and enforce interfaces, and C++ supports cleaner code in several significant cases. The last item is the most telling though: it's clear that these developers feel they've hit a point of crisis, and they are willing to take risks like this in order to lift themselves out of the problem.

Interesting perspective as the remote user, but I wonder how your employees felt about that setup. It was easier for you to feel you had a cohesive team, but did they feel more cohesive for having a robotic you floating around?

Sounds great in theory, but that assumes that every engineer is spending time every day monitoring all of the accomplishments by every other engineer just to make sure everything gets valued appropriately. I suppose the answer to that is, "Well, you (or somebody) could tell everybody that you did this wonderful thing," but then you're right back in the position of having to do self-promotion to get recognition for your work.

It's not about putting in the minimum effort. It's about getting something usable out quickly and gathering feedback from actual users not only to validate the idea, but to ensure that the next steps we take are in the right direction. There's nothing to be gained by building in a vacuum, or polishing a product or feature for months or years, only to find out at last that you built the wrong thing, or that somebody else beat you to the market with something that was "good enough" while you finished your magnum opus.

You can use the MVP concept, even on a very mature product. You just have to adjust the scope of the idea. For example, my product has been in development for more than 10 years and has had 24 major releases. Yet when we are considering adding a new feature, we still scope the work in terms of the minimum usable version of the feature, as well as the "100% version", hopefully with a few reasonable steps in between. This enables us to focus on getting something useful out quickly, in order to validate the feature, while avoiding gold plating until we have that validation.

That's a valid concern. One of our design goals has been 100% compatibility with GNU make, specifically to reduce that friction, so you don't have to fiddle with your makefiles to switch from gmake to ElectricMake (emake). The converse is also true -- you can switch back to gmake if you like. You lose the benefits of emake, but the makefiles still work with gmake.

What surprises me is that nobody seems to take the approach of fixing make, as if it is somehow beyond redemption. With a little effort you could address some of the things that people most dislike about make (tabs-vs-spaces, multiple outputs per target). With a little more effort you can have up-to-date checks that don't rely solely on timestamps.

That's the direction we've taken with ElectricAccelerator ( http://www.electric-cloud.com/products/electricaccelerator-d...) -- fix make, rather than cooking up Y.A.M.R. It hasn't (yet) fixed all of the issues with make, but it's hit some of the biggest.

(disclaimer: I'm the architect of ElectricAccelerator)

Of course he's not under any obligation to provide any more info than he has. But given that he already has the test harness setup, and that only he has access to the hardware on which his benchmarks ran, it seems that he could easily enable more people to help him by providing additional data points.

There's no need to spill internal processes and configurations. The fellow said he had a synthetic repo that he used to benchmark various operations. Surely whatever generated that test repo can scale it up or down to whatever size they like, so you can benchmark at various points and collect the data that would tell us if there is some horrible non-linear scaling going on under the covers.

> For some people, 250GB/month is unreasonable.

If 250GB/month is unreasonable, then those people should not be signing up for a 250GB/month service plan. There's nothing stopping him from getting a business plan, for example, with a larger cap or no cap at all. It's not reasonable for this user to expect to dictate both the bandwidth limits _and_ the low price point. Even if we stipulate that internet access is a human right, I don't think it's reasonable to assert that everybody is entitled to unlimited bandwidth to the internet, at somebody else's expense.

> How do my internet habits interfere with your internet habits?

As far as I know, at some point this guy's connection is going through a shared resource, whether that is a switch or router or hub or whatever. Those gadgets only have so much bandwidth available, which is shared amongst all the connections going through it. Sure, most of the time the limit of that hardware vastly exceeds the demands of those connections, but there _is_ a limit, and it is possible (albeit, perhaps, unlikely) that one guy, uploading _terabytes_ of data, could impede his neighbor's ability to enjoy the internet.

How is it reasonable for somebody to expect to be able to upload "terabytes of RAW images, musics tracks ripped in lossless format, etc."? That seems to be substantially outside the scope of what both Comcast's home user internet service is designed for, and, I would guess, Carbonite as well -- although I note that Carbonite does offer "unlimited" backups for home users. I agree with other commenters -- this sounds like a serious case of entitlement. I don't know whether Internet access should be considered a right or not; but even if it is, I would say it only really works if people are reasonable and responsible in their usage of it. Just like it's a right for me to speak my mind, but people will still shun me if I insist on doing so at full volume in all venues at all times, in a way that impedes others from enjoying _their_ access to that right.

> I don't have a way to do it with paper flashcards ...

Most people separate paper flashcards into two piles as they go, one for those they got right and one for those they got wrong.

Many of those criticisms are completely irrelevant now. The post is from 1994, which means RMS is probably talking about Tcl 7.3, which is worlds apart from Tcl 8.5, the latest official release. People certainly can and have developed large applications in Tcl; Tcl has long since introduced an internal representation to efficiently handle numbers; etc. Posting links like this that are so old and out of date borders on irresponsible, because not everybody will take the time to realize that the criticisms are no longer valid.

For all the talk of the difficulties of playing Jeopardy! due to the "nuances of natural language" and "puns and double meanings in the clues", that did not really seem to be a factor in the second round -- most of the questions were quite plainly worded with answers easily discoverable just by searching. Accordingly, Watson performed dramatically better today than yesterday, when a larger portion of the questions did have nuance and plays-on-words in the phrasing. Note too how spectacularly badly Watson performed on the Final Jeopardy! question, where nuance _did_ play a much bigger role.

So today, we learned that machines can push buttons faster than people, and search is a great way to find answers for trivia questions. I doubt the former is a surprise to anybody alive in the past 50 years; the latter shouldn't surprise anybody who's ever used Google.

Neither did I, so I looked it up:

http://en.wikipedia.org/wiki/Radiation_symbol#Radioactive_si...

In fact, the symbol is so completely unintuitive that ISO came up with a new version:

http://upload.wikimedia.org/wikipedia/en/1/10/New_radiation_...

... which to me certainly does connote "these rocks shoot death rays!" as well as the sage advice "RUN!"

There were about a dozen issues uncovered using this technique. I would say the majority of them were what I would call "real" bugs, as opposed to "sure, that doesn't work but nobody cares". One example is that gmake allows $$ in variable names, as in "FOO$$BAR=abc"; at the time our parser did not handle this correctly. I did not have to create special cases to fix these bugs, at least not any more so than any other parser feature.

The problem with relying solely on "real world makefiles" is that there is not a lot of variation amongst those that are publicly accessible. The vast majority of open source projects that use make are autoconf based, which means the makefiles are all more-or-less the same, except that the list of source files and the project name change. Once you can successfully build one of these, you can probably build all of them.

There are a handful projects that don't follow this pattern, such as Mozilla, but once you've built those they cease to be useful for flushing out new bugs.

So, what do you do once you've built all the open source projects you can find, and you are still finding incompatibilities in your parser when you go to customers? Markov chain-based makefiles are a reasonable way to extend the breadth of our testing. Obviously it's not the only thing we do, but it is another valuable tool to add to the toolbox.