Все зависит от цели.
Одна команда написала систему анализа движения воздуха методом конечных объемов.
Как в большинстве вычислительных задач, алгоритм и тип данных оптимизирован под скорость работы.
Встал вопрос о точности результатов. Я предложил использовать вместо double новый тип «физическая величина» из двух double — «значение» и «погрешность». И заменить стандартную арифметику на принятую в физике: при сложении и вычитании погрешности складываются, при умножении и делении подсчитываются соответствующим образом.
Работать будет гораздо медленнее, но для исследования применимости расчетов к различным задачам очень удобно.
Вроде бы, задача не много сложнее рефакторинга. Но программисты дружно отвергли идею — слишком сложно в реализации и отладке.
Интересно, в каком языке такое изменение не вызовет сложностей?
Пока программист не осознАет, что пишет не только ( и не столько) для компилятора, но и для других программистов, которым придется изучать и модифицировать его текст, его нельзя брать в серьезную разработку.
Конструкторов «с детства» учат соблюдать ЕСКД. Проектировщиков-строителей ЕСПД. Зачем? Чтобы ЛЮДИ легко друг друга понимали.
Программы типа «Hello, World!» плохи тем, что скрывают эту сторону вопроса. Написал, запустил, работает. Просто и понятно. Буду программистом.
Разумеется, очень плохо, когда блок не помещается на экран. Хотя, у кого какой экран.
Речь идет о том, что запретить это нельзя. Случаются ситуации, когда приходится писать длинные строки и длинные тексты.
Поэтому любой стандарт форматирования имеет смысл, пока способствует удобочитаемости. Но необходимо иметь возможность от него отказаться в тех местах, где его соблюдение ухудшает читаемость кода.
Мне очень не хватает в большинстве языков возможности именования блоков. Просто ради того, чтобы осознать назначение некоторых закрывающихся скобок. Делаю это с помощью комментариев, но хотелось бы, чтобы компилятор мог убедиться в правильности вложений.,
Это совсем другое дело.
Давным давно, я пытался доказывать, что язык, это не только синтаксис, но и словарь. И среди языков выиграет тот, в стандарт которого будет включена обширная библиотека.
Собственно, это и случилось. При сложном и, я бы сказал, неопрятном синтаксисе, С++ стал популярен, благодаря стандартизации библиотек. Это, действительно, требует сотен страниц описаний.
По моему, никто и не пытался составить формальное описание С++. Дело в том, что С++ создавался без формализованных требований. В первых изданиях своей книги Страуструп подробно описывал, что пытался (и не сумел) сделать. Ему требовался инструмент имитационного моделирования. Описание Симулы-67 он нашел, а работающую реализацию нет. Он стал дописывать С, постепенно добавляя необходимые механизмы. Работа осталась незавершенной. Но появились пользователи и первоначальная цель была отставлена.
ЗЫ: Борланд делал компилятор С++, там в документации, что-то похожее на формальное описание было. На полсотни страниц.
Ада — одно из величайших разочарований в моей жизни :)
Хорошо составленные требования были реализованы без какого-либо анализа. Есть требование — вводится соответствующая конструкция.
В результате, описание синтаксиса Паскаля укладывается в 30 определений, а Ада потребовала 180. Держать в голове такой компилятор не удается, а без этого производительность программиста резко падает.
Так что, «хорошо обоснован» еще не означает «хорошо сделан».
Одна команда написала систему анализа движения воздуха методом конечных объемов.
Как в большинстве вычислительных задач, алгоритм и тип данных оптимизирован под скорость работы.
Встал вопрос о точности результатов. Я предложил использовать вместо double новый тип «физическая величина» из двух double — «значение» и «погрешность». И заменить стандартную арифметику на принятую в физике: при сложении и вычитании погрешности складываются, при умножении и делении подсчитываются соответствующим образом.
Работать будет гораздо медленнее, но для исследования применимости расчетов к различным задачам очень удобно.
Вроде бы, задача не много сложнее рефакторинга. Но программисты дружно отвергли идею — слишком сложно в реализации и отладке.
Интересно, в каком языке такое изменение не вызовет сложностей?
Конструкторов «с детства» учат соблюдать ЕСКД. Проектировщиков-строителей ЕСПД. Зачем? Чтобы ЛЮДИ легко друг друга понимали.
Программы типа «Hello, World!» плохи тем, что скрывают эту сторону вопроса. Написал, запустил, работает. Просто и понятно. Буду программистом.
Пока будешь семь раз мерить, все уже изрежут.
Речь идет о том, что запретить это нельзя. Случаются ситуации, когда приходится писать длинные строки и длинные тексты.
Поэтому любой стандарт форматирования имеет смысл, пока способствует удобочитаемости. Но необходимо иметь возможность от него отказаться в тех местах, где его соблюдение ухудшает читаемость кода.
Мне очень не хватает в большинстве языков возможности именования блоков. Просто ради того, чтобы осознать назначение некоторых закрывающихся скобок. Делаю это с помощью комментариев, но хотелось бы, чтобы компилятор мог убедиться в правильности вложений.,
Давным давно, я пытался доказывать, что язык, это не только синтаксис, но и словарь. И среди языков выиграет тот, в стандарт которого будет включена обширная библиотека.
Собственно, это и случилось. При сложном и, я бы сказал, неопрятном синтаксисе, С++ стал популярен, благодаря стандартизации библиотек. Это, действительно, требует сотен страниц описаний.
ЗЫ: Борланд делал компилятор С++, там в документации, что-то похожее на формальное описание было. На полсотни страниц.
Хорошо составленные требования были реализованы без какого-либо анализа. Есть требование — вводится соответствующая конструкция.
В результате, описание синтаксиса Паскаля укладывается в 30 определений, а Ада потребовала 180. Держать в голове такой компилятор не удается, а без этого производительность программиста резко падает.
Так что, «хорошо обоснован» еще не означает «хорошо сделан».