Oberon space
General Category => Общий раздел => Тема начата: valexey от Сентябрь 20, 2011, 11:09:29 am
-
Вот. Предлагаю собрать некую статистику по участникам форума.
Пояснение к пунктам:
Крайне важна - от скорости компиляции зависит цикл разработки продекта.
Важна но не очень - хорошо если компиляция быстра, но цикл разработки от этого не зависит (бОльшую часть времени все равно занимает что-то другое, например юниттесты).
Не важна - скорость компиляции вообще никак не влияет на процесс разработки.
-
Для интерпретируемых языков программирования скорость компиляции не имеет значения. Так что зависит ещё от того с каким инструментом приходится работать.
А для компилируемых языков программирования скорость компиляции "важна, но не очень".
-
Важна не столько скорость компиляции, сколько скорость проверки программы на правильность. И тут уже важно, какой язык.
В хаскелле, например, для изготовления правильной программы нужно не так уж и много запусков, так что скорость компиляции некритична, а тайп-чеккинг и прочие проверки компиляторы и интерпретаторы хаскелла делают практически мгновенно.
А вот для низкоуровневых языков -- там да, чем быстрее получится екзешник, тем быстрее его запустишь и тем быстрее найдёшь и исправишь новые баги...
ЗЫ. Вообще, я в последнее время только у двух языков видел медленную компиляцию -- у С++ и у Eiffel (когда чуть-чуть возился с ним).
-
Для интерпретируемых языков программирования скорость компиляции не имеет значения. Так что зависит ещё от того с каким инструментом приходится работать.
А для компилируемых языков программирования скорость компиляции "важна, но не очень".
Это не так. Например Оберон и Си - вполне интерпретируемые языки. В то время как питон - вполне себе компилируемый. :-)
Я бы сказал, что для языков с динамической типизацией, у которых на этапе компиляции проверяется только корректность синтаксиса (например ассемблер) время компиляции... Критично! Но только при условии что запустить приложение можно только произведя компиляцию (трансляцию исходных текстов с этого языка в какой-либо другой язык, например в машкоды, или в байткод), потому что проверить корректность программы можно только посредством запуска самого кода (например юниттестами).
Другое дело, что поскольку на этапе компиляции там только проводится проверка синтаксиса и трансляция, скорость таких компиляторова обычно весьма хорошая. Поэтому люди автоматом ставят галку на против пункта "не важно".
-
ЗЫ. Вообще, я в последнее время только у двух языков видел медленную компиляцию -- у С++ и у Eiffel (когда чуть-чуть возился с ним).
А я видел. Например у Haskell'я весьма медленная компиляция. А поскольку бОльшая часть программы на хаскеле проверяется именно во время компиляции а не юниттестов, скорость компиляции становится критичной.
Но это конечно зависит от объемов которые приходится компилировать. Если hello world писать, то можно вполе и 5 секунд на 500 строк вытерпить.
-
А я видел. Например у Haskell'я весьма медленная компиляция. А поскольку бОльшая часть программы на хаскеле проверяется именно во время компиляции а не юниттестов, скорость компиляции становится критичной.
Но это конечно зависит от объемов которые приходится компилировать. Если hello world писать, то можно вполе и 5 секунд на 500 строк вытерпить.
Медленная компиляция только если программа правильная -- тогда она там оптимизируется, всё такое )))
А проверки у неправльной проги там быстро делаются ))
-
Важна не столько скорость компиляции, сколько скорость проверки программы на правильность. И тут уже важно, какой язык.
или даже инструментарий которым пользуешься(точнее организация, труда) востребованных "раскрученных" IDE, есть примочки делающие эти проверки on-fly
..Но на достаточно крупных и распределенных в пространстве проектах- эта штука может влиять как на распределение ресурсов (человеческих , денежных), так и на распорядок трудового дня. Помню в начале 2000 был проект со временем сборки в час с небольшим. Хотя у американов была пара человек, которая занималась только тем, что лопатила make- файл. В связи с этим определенный порядок работы был у менеджера (final check+ сборка), разрабов и тестеров по обе стороны океана...т.е. важна но не очень (считаю что практически всегда можно построить процесс разработки минимизирующий потери вследствии медленной компиляции)
-
Важна не столько скорость компиляции, сколько скорость проверки программы на правильность. И тут уже важно, какой язык.
или даже инструментарий которым пользуешься(точнее организация, труда) востребованных "раскрученных" IDE, есть примочки делающие эти проверки on-fly
Это самое on-fly тоже зависит от скорости компиляции :-) Там же инкрементально компилятор запускается, либо проверки делаются не полностью (если скорость не позволяет). Во втором случае оно нинужно.
..Но на достаточно крупных и распределенных в пространстве проектах- эта штука может влиять как на распределение ресурсов (человеческих , денежных), так и на распорядок трудового дня. Помню в начале 2000 был проект со временем сборки в час с небольшим. Хотя у американов была пара человек, которая занималась только тем, что лопатила make- файл. В связи с этим определенный порядок работы был у менеджера (final check+ сборка), разрабов и тестеров по обе стороны океана...
О! Час с небольшим это еще мало! Оно иногда всю ночь собирается. Под полную сборку проекта выделяется билд-сервер (или даже небольшой кластер, для распределенной сборки).
К чему далеко ходить? Пересборка squid'a на моей машинке четыре года назад занимала где-то минут 20 (машинка впрочем была для того времени довольно слабой).
-
Есть некий критический барьер после которого общая скорость разработки начинает тормозиться. Лично для меня это несколько секунд на комипиляцию текущего модуля. Если компиляция занимает дольше - это раздражает и отвлекает внимание. Общая сборка + линковка + запуск - уже не так важна, но чем быстрее - тем лучше. И тут уже сильно зависит от конкретной ситуации. Если надо поэкспериментировать с каким-то параметром и после минимального изменения вся сборка занимает больше 5 секунд - тоже раздражает. Ну а если весь день писался код, а под вечер запускается - то можно и 10 минут спокойно подождать (попивая чаек).
-
Если проект большой и правильный, то на написание кода вообще мало времени потребуется.
А скорость компиляции начинает иметь критическое значение, когда осваиваешь новый язык, чужой код или новую библиотеку. Словом, всё то, о чём нет в голове чётко сложившегося представления. Чем быстрее можно будет посмотреть результат - тем лучше. Но и здесь не только компиляция может тормозить процесс. Во-первых, может долго расчухиваться IDE, а во-вторых, после компиляции может потребоваться загрузить программу на устройство, эмулятор, сервер.
-
Если проект большой и правильный, то на написание кода вообще мало времени потребуется.
У меня такое ощущение складывается, что большой проект правильным быть не может (в том смысле в котором оная правильность тут подразумевается).
В большом проекте почти весь код тебе не знаком и написан не тобой (либо написан тобой но 10 лет назад и тогда же ты последний раз этот код видел). То есть всесь код чужой.
А скорость компиляции начинает иметь критическое значение, когда осваиваешь новый язык, чужой код или новую библиотеку.
Таким образом скорость компиляции имеет критическое значение в любом большом проекте? (особенно если учесть что в большом проекте много людей и они постоянно меняются (кто-то увольняется, кто-то просто умирает, а на их место нанимают новых. постоянно))
Во-первых, может долго расчухиваться IDE
Ну, если у нас такая IDE которой нужно расчухиваться, то и компиляция как таковая может не понадобиться, чтобы понять что с чем связано и как это все работает. Ну, то есть понадобится конечно, но не часто.