4 ms·

I agree. But the name problem is only one small piece of the text problem. Text is a great deal better than punch cards and that is even a greater deal better t

by collint 17y ago

I agree. But the name problem is only one small piece of the text problem. Text is a great deal better than punch cards and that is even a greater deal better than writing things on paper and physically setting the switches. There exists a grotesque obsession with text and the tools to edit text among programmers. My editor of choice can give me a great deal of help when writing HTML markup. It's actually quite amazing how good an editor can be. But I can still jump off the track and remove a "<" where there really should be one. No, that's not really useful to me at all. I'd be much better off in a world where the angular brackes, quote marks wrapping strings, and other arbitrary delimiters of the ENCODING didn't really exist at all. I'd much rather edit a DOM directly than through the looking glass of text. An film editor would never open up his final cut project files and tweak them by hand. He has far better tools that more appropriately fit his domain. Why not me?

aaronblohowiak 17y ago
You'd probably like Codekana and Ngedit. http://www.ngedit.com/ http://www.ngedit.com/
- collint 17y ago
  I'm solidly anti-text. And as a hobby work on non-text programming tools. It's entirely unproven. But I hope one day I can say it's a better way to do things.
krakensden 17y ago
Have you ever used final cut? I really don't want to live in a world where I can fix my logic by re-aligning things to a pixel grid. The reason programmers use text is that you can input text much faster than you can drag and drop things together, it's easy to massage with simple scripts, and if the vendor-du-jour's IDE is broken, incomplete, or unsatisfactory we can go outside of it without having to deal with some arbitrary binary file format. Seriously, you need to make a better case that a visual language would be an improvement instead of another reason to become a park ranger.
regularfry 17y ago
The stock response to this is that "abstractions are leaky." For the DOM, it's conceptually nice to be able to just operate on the tree, but as soon as you start dealing with browser bugs (or even just browser-specific functionality) the chances are that it'll just break, and the system will end up more complex than if you'd just stuck with text. Also, presumably you'd want a non-textual Javascript layer to go with your non-textual DOM layer. I think the jury's still out on general non-textual programming. I think the reason programmers get hung up on text and its editors is that it's like C: it's the lingua franca. Every system uses it at some level, so if you've got a good tool for using it, it's applicable to any domain you care to look at. Without it, you'd be reduced to domain-specific abstractions which might not have any wider applicability at all.

by collint 17y ago

aaronblohowiak 17y ago

You'd probably like Codekana and Ngedit. http://www.ngedit.com/ http://www.ngedit.com/

collint 17y ago
I'm solidly anti-text. And as a hobby work on non-text programming tools. It's entirely unproven. But I hope one day I can say it's a better way to do things.

krakensden 17y ago

Have you ever used final cut? I really don't want to live in a world where I can fix my logic by re-aligning things to a pixel grid. The reason programmers use text is that you can input text much faster than you can drag and drop things together, it's easy to massage with simple scripts, and if the vendor-du-jour's IDE is broken, incomplete, or unsatisfactory we can go outside of it without having to deal with some arbitrary binary file format. Seriously, you need to make a better case that a visual language would be an improvement instead of another reason to become a park ranger.

regularfry 17y ago

The stock response to this is that "abstractions are leaky." For the DOM, it's conceptually nice to be able to just operate on the tree, but as soon as you start dealing with browser bugs (or even just browser-specific functionality) the chances are that it'll just break, and the system will end up more complex than if you'd just stuck with text. Also, presumably you'd want a non-textual Javascript layer to go with your non-textual DOM layer. I think the jury's still out on general non-textual programming. I think the reason programmers get hung up on text and its editors is that it's like C: it's the lingua franca. Every system uses it at some level, so if you've got a good tool for using it, it's applicable to any domain you care to look at. Without it, you'd be reduced to domain-specific abstractions which might not have any wider applicability at all.