Hacker News Reader

Comment by twelvechairs | Hacker News Reader

Of course the original video was not perfect. It is a concept, not a fully fleshed out product.

It piqued peoples interest for good reason, because of a combination of many ideas working together in a clean interface. To criticise it for details ('this takes up half the screen', 'some of these things have been done before', 'this particular feature might not work for the kinds of work I do') is to entirely miss the point of a 'concept'. It needs constructive input (eg. 'this is a good idea, but would work better if done like that'). The kind of criticism provided here doesn't help anyone much at all.

View on HN

I wonder if this is one of the reasons we are stuck with crappy development tools in era of slick iPads. Not only do we balk at the amount being raised (also happened with ruby.app), we also tend to criticize any thing that looks new and trying to change status quo. At the worst this will be a half baked IDE while still offering some creative features paving way for (hopefully) better future IDEs. You don't see many people haring off to criticize other creative projects the same way outside programming world.

Yes, but most, if not all, of the concept has been done before. Given that, I think the question why things would work better this time is one that the backers of this project should think about before starting development.

My input would be that I think the cute displays in the video will not work on real-scale projects. One reason is that I do not see how the most interesting part, the live display of a call graph, will work as nicely as displayed in the video with:

  - functions that manipulate disk or network state
  - large functions
  - deeply nested functions, in particular recursive ones

I can envision each of them, but all in a somewhat ugly way. The first would require programmers to write set-up and tear-down code; the second and third would eat screen real estate and/or would involve scrolling and/or collapsing.

If you have to write that setup and teardown code, I do not see how this interactive way of testing code is that much better than writing unit tests.

Translating that into constructive feedback: I would aim for building a good tool for education first; then, work on the scaling problem. But, be prepared: you should be happy if you get the education part only; you may not find a way to scale this up to real-world projects. And you should also realize beforehand that, if this does not scale, the educational program may be seen as a toy, only useful in the first half-year or so, only because 'real programmers' do not use it. It may take time to overcome that, just like it took (or even: is taking) time to overcome the notion that real programmers do not use IDEs.

[Going on a tangent: I would love to have a system that allowed me to split unit tests into API examples and all the other tests (timing tests, integration tests specific to certain bugs, etc.) That way, the documentation system could grab the first kind of tests and show them in the documentation.

I also would like to see a system that forbid me to write code that is not covered by a unit test yet. For example, in C, it would force programmers to write the header file first, the unit tests exercising part of the code second, and the actual code last. It should allow me to write the whole header file, then implement and test that header in parts, though. I also might hate it the moment I see it, but I need to see it to discover that.]

Yeah, I think thats a very reasonable viewpoint to take. To me there was a lot more depth in what you just said that the OP.

What I will say though is that to me when you 'envison.. in a somewhat ugly way' its basically a guess that they won't find a nice way to solve the UI difficulties of things that weren't in the video. You might be proved right, but to really know (rather than guess) this, you need to spend probably some days thinking about and prototyping it, which assumedly they will do (and we have not).

I think they should be encouraged to do so, and my main problem with the OP was its basically discouraging tone of 'its never going to work because you haven't shown me a perfect final version that covers all bases'.

"you need to spend probably some days thinking about and prototyping it"

I would _guess_ that "thinking about it and researching it" will be time better spent. Inventing the wheel often is a lot of fun, but it also can be a waste of time. I do not know the literature, but it would not really surprise me to learn that there is some cheap knowledge to mine from it.

I also would like to see a system that forbid me to write code that is not covered by a unit test yet.

I suspect that would lead to the people who are currently not writing unit tests writing useless tests just to circumvent the requirement. It would also make exploratory programming, where you haven't completely figured out what you want it to do much more difficult.

See, THAT is why you think before you leap. Iteration #1: make it 'forbid to commit code' instead of 'forbid to write code'.

And I agree that that might only work fine in safety-critical code.

And writing useless tests won't help if this would be as strict as I envision. Imagine a project where you cannot commit

   if flag:
     doA
   else:
     doB

unless you have a test that hits the doA part and a test that hits the doB part. Complete code coverage, enforced by the system. I am thinking more and more that I do want to see such a tool, but not really will want to use it. Maybe iteration #2 is "hm, that is not the best of ideas". Although, if somebody would want to pay for such enforced code coverage, it could be fun to search for with design patterns that help it make easier to write such code...

Are you reinventing design by contract using tests?

Now you mention it: yes, probably.

Reply on news.ycombinator.com