Comments 8
Мой учитель, как-то сказал мне: «Ты предложил, ты и делай. А если не хочешь сам делать, то перестань предлагать».
Предложи реализацию решения, я думаю, его рассмотрят, и если оно будет качественным, то его примут…
Предложи реализацию решения, я думаю, его рассмотрят, и если оно будет качественным, то его примут…
Проблема тут не столько в парсере, сколько в пользователях.
Пользователи, которые не хотят знать грамматику, которую понимает парсер, не хотят также слышать о своих ошибках. Представьте себе, что вы пишете текст, а когда жмыкаете submit, получаете тонну сообщений о том, что тут не то, а там не так.
После этого вы рвете волосы и все такое.
Это та же самая проблема, что и с валидацией HTML. Сколько процентов веб-разработчиков знают грамматику HTML на 100%? Почему браузеры проглатывают любой суп тегов?
Пользователи, которые не хотят знать грамматику, которую понимает парсер, не хотят также слышать о своих ошибках. Представьте себе, что вы пишете текст, а когда жмыкаете submit, получаете тонну сообщений о том, что тут не то, а там не так.
После этого вы рвете волосы и все такое.
Это та же самая проблема, что и с валидацией HTML. Сколько процентов веб-разработчиков знают грамматику HTML на 100%? Почему браузеры проглатывают любой суп тегов?
Правильно, правильно! Когда я переводил вон тот текст, около двух третей всего времени ушло на возню с оформлением и подсветкою CSS-кода. Несколько часов кряду. Если бы я тогда знал то, что знаю теперь, то сочинил бы пару-тройку-другую регулярных выражений — чтобы ускорить дело. Но понятно же, что уж лучше пущай у Хабрахабра явится собственная подсветка кода, нежели каждый пользователь станет самостоятельно сочинять регулярные выражения.
Поддерживаю. Дико бесит, когда парсер вырезает куски блоков кода. Например, директивы конфигурационных файлов или [x] отметки.
Sign up to leave a comment.
парсер для кода