Re[6]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.07.09 14:33
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, thesz, Вы писали:


J>>>Для решения этой проблемы существуют юнит-тесты.

T>>А если их изначально не было? Как они решат эту проблему?
J>Изначально там тестов не было вообще.
J>А если в общем говорить, то тестов было недостаточно, и не было теста, который покрывал бы требуемые граничные случаи.
J>Стало быть, на этот фикс пишется соответствующий юнит-тест, который этот граничный случай будет проверять.

Но он не будет проверять другие граничные условия, для других вариантов использования.

T>>>>Что самое интересное, вероятность правильной работы кода после исправлений растёт со временем. Компиляторы, дебаггеры, всякие валгринды с параллельными студиями интела... Вчера везде было проще использовать чёрный ящик, сегодня уже не в столь многих местах, а завтра вообще чёрных ящиков останется раз, два и обчёлся.

J>>>Юнит-тесты все же надежнее и проще.
J>>>Хотя бы потому, что тебе не нужно запускать все тот список программ, что ты привел.

T>>Правильный компилятор
Автор: dotneter
Дата: 01.07.09
выявляет больше ошибок
Автор: thesz
Дата: 05.02.09
, чем любой юнит тест (и любое их количество).

J>Ты передергиваешь. "Компиляторы, дебаггеры, всякие валгринды", удобство и функциональность которых улучшаются со временем, не предполагают смены языка, как в случае перехода на зависимые типы, когда старый компонент по-любому не может быть использован, просто потому что язык другой.

Как автор, я не вижу здесь передергивания.

Если я вношу в язык зависимые типы и начинаю их применять, то мне придётся распространять доказательства соответствия спецификации по всей программе.

Например, если раньше я использовал FILE* read_filename_from_first_string(FILE*f), а теперь начал использовать FILE<content> read_filename_from_first_string(FILE<text_file>* f), то я не отверчусь. Надо будет сделать кучу телодвижений, которые окупятся потом.

J>Понятно, что на бейсике писать удобнее, чем на ассемблере, на С++ — удобнее, чем на бейсике, и т.д, с этим никто не спорит.


T>>Мои текущие нападки на юнит-тесты должны рассматриваться в струе "средства программирования делают изменения более дешёвыми".

J>Кстати, интересно было бы посмотреть, как на зависимых типах будет выглядеть оформление десятка граничных случаев.

Нормально.

Из моего опыта использования ассоциированных типов в Хаскеле они действительно сокращают код.

J>Боюсь, что с ростом сложности требований к типам потребуется настолько сложое описание этого типа, что потребуется дебаггер для того, чтоб убедиться, что ты правильно все записал.

J>В то время как при помощи юнит-тестов подобные вещи выражаются очень просто, хотя, естественно, они не являются строгим доказательством корректности, как в случае использования зависимых типов.

J>Просто, имхо, баланс должен быть.

J>Что просто выразить через систему типов — должно быть выражено там, а что проще через простейшие юнит-тесты в противовес килобайту зависимых типов — должно быть в тестах.

Насчёт килобайта зависимых типов это ты повторяешь чужие глупые мысли.

Спецификация не может быть длинней кода. Тем более она не может быть длинней тестов этого кода.

PS
Почему-то любая дискуссия со мной выливается в "юинт-тесты супротив статической типизации".

Круто!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[4]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.07.09 14:35
Оценка:
Здравствуйте, VGn, Вы писали:

T>>Если мы зафиксируем некоторый срок, то вероятность дописать компонент до нужного уровня становится всё выше и выше с течением времени. Грубо говоря, вчера было труднее написать, чем найти, сегодня проще написать.


VGn>А объем этого кода в геометрической прогрессии больше.


В арифметической, если мы берём одного разработчика. В геометрической, если мы берем рост разработчиков.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[5]: Кнут о компонентном программировании.
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 10.07.09 15:07
Оценка:
T>>>Если мы зафиксируем некоторый срок, то вероятность дописать компонент до нужного уровня становится всё выше и выше с течением времени. Грубо говоря, вчера было труднее написать, чем найти, сегодня проще написать.

VGn>>А объем этого кода в геометрической прогрессии больше.


T>В арифметической, если мы берём одного разработчика. В геометрической, если мы берем рост разработчиков.


Вот именно, что нет. Пять лет назад у того же грида было в десять раз меньше свойств. И свойства стали сложнее. При этом он как гридом был, так им и остался. А поскольку средства стали лучше, мы сейчас можем использовать этот грид намного быстрее. И что теперь при наличии исходников проще стало доработать контрол?
Кстати это обычно не проблема. Все ведущие производители контролов поставляют исходники за отдельную плату. Но разработчики заглядывают в них всё реже и реже. И это правильно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[7]: Кнут о компонентном программировании.
От: jazzer Россия Skype: enerjazzer
Дата: 10.07.09 17:33
Оценка:
Здравствуйте, thesz, Вы писали:

J>>Стало быть, на этот фикс пишется соответствующий юнит-тест, который этот граничный случай будет проверять.


T>Но он не будет проверять другие граничные условия, для других вариантов использования.

Да.
Может, их и нету, других граничных случаев.
Это называется "решать проблемы по мере их появления".
Ты, кстати, точно так же можешь забыть выразить граничные случаи в зависимых типах.

T>Если я вношу в язык зависимые типы и начинаю их применять, то мне придётся распространять доказательства соответствия спецификации по всей программе.


Если ты внес в язык зависимые типы, которых там раньше не было, то это уже другой язык.

T>Например, если раньше я использовал FILE* read_filename_from_first_string(FILE*f), а теперь начал использовать FILE<content> read_filename_from_first_string(FILE<text_file>* f), то я не отверчусь. Надо будет сделать кучу телодвижений, которые окупятся потом.


Вот-вот: эдесь ты только что из С сделал С++.

T>>>Мои текущие нападки на юнит-тесты должны рассматриваться в струе "средства программирования делают изменения более дешёвыми".

J>>Кстати, интересно было бы посмотреть, как на зависимых типах будет выглядеть оформление десятка граничных случаев.

T>Нормально.


T>Из моего опыта использования ассоциированных типов в Хаскеле они действительно сокращают код.

Сокращают какой код?
Код определения типа — могут только усложнить.
В противовес этому, возможно, помрут какие-то юнит-тесты.
Я говорю "возможно", потому что то, как ты запрограммировал свои зависимые типы, тоже неплохо бы проверить, а то вдруг ты где-то минус с плюсом перепутал, как указывали в соседней дискуссии.
Такие вещи только юнит-тестами можно отловить, ну или любым другим альтернативным проверяющим движком — просто потому, что одну и ту же ошибку в двух совсем разных местах совершить затруднительно.

J>>Просто, имхо, баланс должен быть.

J>>Что просто выразить через систему типов — должно быть выражено там, а что проще через простейшие юнит-тесты в противовес килобайту зависимых типов — должно быть в тестах.

T>Насчёт килобайта зависимых типов это ты повторяешь чужие глупые мысли.

Вот еще! Это мои личные глупые мысли!

T>Спецификация не может быть длинней кода. Тем более она не может быть длинней тестов этого кода.

Спецификация на человеческом языке вполне может быть короче кода, выражающего эту спецификацию на машинном языке.
Просто потому что спецификация на человеческом языке опирается на весь контекст, доступный человеку, а для машины тебе придется весь этот контекст воспроизвести руками.

T>Почему-то любая дискуссия со мной выливается в "юинт-тесты супротив статической типизации".

Ну потому что ты ратуешь за то, чтоб вообще все загнать в статику.
На что тебе указывают, что даже твою статику надо чем-то проверять, не говоря уже о том, что нужно проверять и то, что нельзя (или трудно) загнать в систему типов.
Я сам большой поклонник статики и все, что можно, стараюсь сделать ошибкой времени компиляции.
Только вот потом тебе нужно все равно написать тест, который скомпилирует то, что правильно, и не скомпилирует то, что неправильно — иначе как ты узнаешь, что ты реализовал статику без ошибок?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[8]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.07.09 19:09
Оценка:
T>>Но он не будет проверять другие граничные условия, для других вариантов использования.
J>Да.
J>Может, их и нету, других граничных случаев.
J>Это называется "решать проблемы по мере их появления".
J>Ты, кстати, точно так же можешь забыть выразить граничные случаи в зависимых типах.

Не получится. По рукам дадут.

T>>Если я вношу в язык зависимые типы и начинаю их применять, то мне придётся распространять доказательства соответствия спецификации по всей программе.

J>Если ты внес в язык зависимые типы, которых там раньше не было, то это уже другой язык.

Расширение предыдущего.

См. лямбда-куб.

T>>Например, если раньше я использовал FILE* read_filename_from_first_string(FILE*f), а теперь начал использовать FILE<content> read_filename_from_first_string(FILE<text_file>* f), то я не отверчусь. Надо будет сделать кучу телодвижений, которые окупятся потом.

J>Вот-вот: эдесь ты только что из С сделал С++.

Или просто использовал шаблоны.

T>>>>Мои текущие нападки на юнит-тесты должны рассматриваться в струе "средства программирования делают изменения более дешёвыми".

J>>>Кстати, интересно было бы посмотреть, как на зависимых типах будет выглядеть оформление десятка граничных случаев.
T>>Нормально.
T>>Из моего опыта использования ассоциированных типов в Хаскеле они действительно сокращают код.
J>Сокращают какой код?
J>Код определения типа — могут только усложнить.

И насколько, как ты думаешь?

J>В противовес этому, возможно, помрут какие-то юнит-тесты.

J>Я говорю "возможно", потому что то, как ты запрограммировал свои зависимые типы, тоже неплохо бы проверить, а то вдруг ты где-то минус с плюсом перепутал, как указывали в соседней дискуссии.

Минус-плюс я могу в параметр внести, видно будет.

J>Такие вещи только юнит-тестами можно отловить, ну или любым другим альтернативным проверяющим движком — просто потому, что одну и ту же ошибку в двух совсем разных местах совершить затруднительно.


Правильно, функциональным тестом. Не юнит-тестом, в последнем смысла нет.

T>>Спецификация не может быть длинней кода. Тем более она не может быть длинней тестов этого кода.

J>Спецификация на человеческом языке вполне может быть короче кода, выражающего эту спецификацию на машинном языке.
J>Просто потому что спецификация на человеческом языке опирается на весь контекст, доступный человеку, а для машины тебе придется весь этот контекст воспроизвести руками.

Спецификация на машинном языке — на той же Агде или на ACL2, — опирается на всю мощь библиотеки машинного языка, которую не надо воспроизводить руками.

T>>Почему-то любая дискуссия со мной выливается в "юинт-тесты супротив статической типизации".

J>Ну потому что ты ратуешь за то, чтоб вообще все загнать в статику.

Потому, что когда человек пишет программу, он рассуждает о программе статически, и никак иначе.

J>На что тебе указывают, что даже твою статику надо чем-то проверять, не говоря уже о том, что нужно проверять и то, что нельзя (или трудно) загнать в систему типов.


Видишь ли, в типы нельзя загнать, я думаю, только красоту души девушки. Всё остальное типизируется.

J>Я сам большой поклонник статики и все, что можно, стараюсь сделать ошибкой времени компиляции.

J>Только вот потом тебе нужно все равно написать тест, который скомпилирует то, что правильно, и не скомпилирует то, что неправильно — иначе как ты узнаешь, что ты реализовал статику без ошибок?

Нет, мне не надо писать такой тест. Если я правильно написал основные типы, то мои операции будут ими правильно ограничены, я не смогу сделать лишнего и смогу сделать нужное.

А больше мне не надо.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: Кнут о компонентном программировании.
От: jazzer Россия Skype: enerjazzer
Дата: 11.07.09 00:28
Оценка: 1 (1) +1
Здравствуйте, thesz, Вы писали:

T>>>Но он не будет проверять другие граничные условия, для других вариантов использования.

J>>Да.
J>>Может, их и нету, других граничных случаев.
J>>Это называется "решать проблемы по мере их появления".
J>>Ты, кстати, точно так же можешь забыть выразить граничные случаи в зависимых типах.

T>Не получится. По рукам дадут.


Ну что значит — не получится, если в момент написания они тебе попросту неизвестны?
И только то, что ты придумаешь, то там и будет.
И потом уже в продакшене выяснится, что еще вот такой случай надо специально обработать, и другой — своим особым образом...
А ты о них, когда писал первую версию, ни сном, ни духом.

T>>>Если я вношу в язык зависимые типы и начинаю их применять, то мне придётся распространять доказательства соответствия спецификации по всей программе.

J>>Если ты внес в язык зависимые типы, которых там раньше не было, то это уже другой язык.

T>Расширение предыдущего.

Это обычно и означает — новый язык.

J>>Вот-вот: эдесь ты только что из С сделал С++.


T>Или просто использовал шаблоны.


В С нет шаблонов.
Так что это таки С -> С++.



T>>>>>Мои текущие нападки на юнит-тесты должны рассматриваться в струе "средства программирования делают изменения более дешёвыми".

J>>>>Кстати, интересно было бы посмотреть, как на зависимых типах будет выглядеть оформление десятка граничных случаев.
T>>>Нормально.
T>>>Из моего опыта использования ассоциированных типов в Хаскеле они действительно сокращают код.
J>>Сокращают какой код?
J>>Код определения типа — могут только усложнить.

T>И насколько, как ты думаешь?

Что значит — насколько? В чем мерять?
Думаю, это от языка зависит. В том, который под зависимые типы заточен — в том мало будет дополнительной писанины, а в том, который не заточен — это либо очень многословно, либо вообще нереализуемо.

J>>В противовес этому, возможно, помрут какие-то юнит-тесты.

J>>Я говорю "возможно", потому что то, как ты запрограммировал свои зависимые типы, тоже неплохо бы проверить, а то вдруг ты где-то минус с плюсом перепутал, как указывали в соседней дискуссии.

T>Минус-плюс я могу в параметр внести, видно будет.

Ну вот о чем и речь, что придется весь текст функции засунуть в тип.
После чего у тебя сложность типа будет сравнима со сложностью кода функции, и если код сильно кучерявый, то и тип будет такой же.
И этот тип придется тестировать так же, как ты тестировал бы функцию без этого типа.

J>>Такие вещи только юнит-тестами можно отловить, ну или любым другим альтернативным проверяющим движком — просто потому, что одну и ту же ошибку в двух совсем разных местах совершить затруднительно.


T>Правильно, функциональным тестом. Не юнит-тестом, в последнем смысла нет.

И каждый раз функциональный тест руками проделывать? А ты точно не забудешь проверить все граничные случаи, что ты их правильно запрограммировал? Их же все, по-хорошему, надо проверить. Это и есть юнит-тесты.

T>>>Спецификация не может быть длинней кода. Тем более она не может быть длинней тестов этого кода.

J>>Спецификация на человеческом языке вполне может быть короче кода, выражающего эту спецификацию на машинном языке.
J>>Просто потому что спецификация на человеческом языке опирается на весь контекст, доступный человеку, а для машины тебе придется весь этот контекст воспроизвести руками.

T>Спецификация на машинном языке — на той же Агде или на ACL2, — опирается на всю мощь библиотеки машинного языка, которую не надо воспроизводить руками.


Можешь развернуть этот тезис?

T>>>Почему-то любая дискуссия со мной выливается в "юинт-тесты супротив статической типизации".

J>>Ну потому что ты ратуешь за то, чтоб вообще все загнать в статику.

T>Потому, что когда человек пишет программу, он рассуждает о программе статически, и никак иначе.


Можешь развернуть и этот тезис?

J>>На что тебе указывают, что даже твою статику надо чем-то проверять, не говоря уже о том, что нужно проверять и то, что нельзя (или трудно) загнать в систему типов.


T>Видишь ли, в типы нельзя загнать, я думаю, только красоту души девушки. Всё остальное типизируется.

Ну, вопрос только какой ценой.
Плюс в языках со статической типизацией (типа С++) тебе нужно будет предусмотреть переход из динамики в статику — тоже вещь не самая простая.
Ну и оттестировать этот переход, само собой.

J>>Я сам большой поклонник статики и все, что можно, стараюсь сделать ошибкой времени компиляции.

J>>Только вот потом тебе нужно все равно написать тест, который скомпилирует то, что правильно, и не скомпилирует то, что неправильно — иначе как ты узнаешь, что ты реализовал статику без ошибок?

T>Нет, мне не надо писать такой тест. Если я правильно написал основные типы, то мои операции будут ими правильно ограничены, я не смогу сделать лишнего и смогу сделать нужное.


Вот для проверки утверждения "Если я правильно написал" тесты и нужны, и никуда ты не денешься от них.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[10]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.07.09 13:52
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, thesz, Вы писали:


T>>>>Но он не будет проверять другие граничные условия, для других вариантов использования.

J>>>Да.
J>>>Может, их и нету, других граничных случаев.
J>>>Это называется "решать проблемы по мере их появления".
J>>>Ты, кстати, точно так же можешь забыть выразить граничные случаи в зависимых типах.
T>>Не получится. По рукам дадут.
J>Ну что значит — не получится, если в момент написания они тебе попросту неизвестны?
J>И только то, что ты придумаешь, то там и будет.
J>И потом уже в продакшене выяснится, что еще вот такой случай надо специально обработать, и другой — своим особым образом...
J>А ты о них, когда писал первую версию, ни сном, ни духом.

Это такой сферический конь в вакууме, да?

Типа, если мы чего не знаем, то мы всегда ничего не знаем.

Да ну, глупость.

T>>>>Если я вношу в язык зависимые типы и начинаю их применять, то мне придётся распространять доказательства соответствия спецификации по всей программе.

J>>>Если ты внес в язык зависимые типы, которых там раньше не было, то это уже другой язык.
T>>Расширение предыдущего.
J>Это обычно и означает — новый язык.

Вот, в Хаскеле появились ассоциированные типы. Стал ли Хаскель новым языком?

J>>>Вот-вот: эдесь ты только что из С сделал С++.

T>>Или просто использовал шаблоны.
J>В С нет шаблонов.
J>Так что это таки С -> С++.

Приведённый мной код и Си, и Си++.

T>>>>>>Мои текущие нападки на юнит-тесты должны рассматриваться в струе "средства программирования делают изменения более дешёвыми".

J>>>>>Кстати, интересно было бы посмотреть, как на зависимых типах будет выглядеть оформление десятка граничных случаев.
T>>>>Нормально.
T>>>>Из моего опыта использования ассоциированных типов в Хаскеле они действительно сокращают код.
J>>>Сокращают какой код?
J>>>Код определения типа — могут только усложнить.
T>>И насколько, как ты думаешь?
J>Что значит — насколько? В чем мерять?
J>Думаю, это от языка зависит. В том, который под зависимые типы заточен — в том мало будет дополнительной писанины, а в том, который не заточен — это либо очень многословно, либо вообще нереализуемо.

Ура. По-моему, есть подвижка/

J>>>В противовес этому, возможно, помрут какие-то юнит-тесты.

J>>>Я говорю "возможно", потому что то, как ты запрограммировал свои зависимые типы, тоже неплохо бы проверить, а то вдруг ты где-то минус с плюсом перепутал, как указывали в соседней дискуссии.
T>>Минус-плюс я могу в параметр внести, видно будет.
J>Ну вот о чем и речь, что придется весь текст функции засунуть в тип.

Внутренние связи между ограничениями не будут видны в типе. Поэтому я отвечаю резким "нет".

J>После чего у тебя сложность типа будет сравнима со сложностью кода функции, и если код сильно кучерявый, то и тип будет такой же.


Опять же, нет.

J>И этот тип придется тестировать так же, как ты тестировал бы функцию без этого типа.


И снова нет.

J>>>Такие вещи только юнит-тестами можно отловить, ну или любым другим альтернативным проверяющим движком — просто потому, что одну и ту же ошибку в двух совсем разных местах совершить затруднительно.

T>>Правильно, функциональным тестом. Не юнит-тестом, в последнем смысла нет.
J>И каждый раз функциональный тест руками проделывать? А ты точно не забудешь проверить все граничные случаи, что ты их правильно запрограммировал? Их же все, по-хорошему, надо проверить. Это и есть юнит-тесты.

Граничные условия отдельных функций проверяются типами функций.

T>>Спецификация на машинном языке — на той же Агде или на ACL2, — опирается на всю мощь библиотеки машинного языка, которую не надо воспроизводить руками.

J>Можешь развернуть этот тезис?

Да чего разворачивать. Вот стандартная библиотека Agda2: http://www.cs.nott.ac.uk/~nad/repos/lib/src/

В ней присутствуют: Алгебры, Категории, Операции по индукции, Коиндукция (для всякого рода бесконечных вещей), Отношения (например, типы, индексированные отношениями) и прочее.

Берешь и используешь.

T>>Потому, что когда человек пишет программу, он рассуждает о программе статически, и никак иначе.

J>Можешь развернуть и этот тезис?

У человека, рассуждающего о программе, есть только её текст. Иногда логи, которые показывают события, происходившие в отдельных частях программы, но в основном только текст.

Человек выписывает статические связи между участками программы, поскольку текст статичен. Даже если в динамике код программы будет изменяться, то все его изменения должны быть предсказуемы статически.

Больше мне сказать нечего.

J>>>Я сам большой поклонник статики и все, что можно, стараюсь сделать ошибкой времени компиляции.

J>>>Только вот потом тебе нужно все равно написать тест, который скомпилирует то, что правильно, и не скомпилирует то, что неправильно — иначе как ты узнаешь, что ты реализовал статику без ошибок?
T>>Нет, мне не надо писать такой тест. Если я правильно написал основные типы, то мои операции будут ими правильно ограничены, я не смогу сделать лишнего и смогу сделать нужное.
J>Вот для проверки утверждения "Если я правильно написал" тесты и нужны, и никуда ты не денешься от них.

Если я неправильно написал типы, то у меня будут затруднения с выражением своих мыслей в других частях программы. Программа просто не будет написана.

Она На Хаскеле пишется с трудом, если типы плохие, что уж говорить про зависимые типы.

Тесты калибра меньше функциональных не нужны.

Функциональные тесты нужны для проверки высокоуровневой логики, Типа, "подходит ли это заказчику".
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: Кнут о компонентном программировании.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.07.09 19:40
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Ну вот о чем и речь, что придется весь текст функции засунуть в тип.

J>После чего у тебя сложность типа будет сравнима со сложностью кода функции, и если код сильно кучерявый, то и тип будет такой же.
J>И этот тип придется тестировать так же, как ты тестировал бы функцию без этого типа.

см. ниже.

J>И каждый раз функциональный тест руками проделывать? А ты точно не забудешь проверить все граничные случаи, что ты их правильно запрограммировал? Их же все, по-хорошему, надо проверить. Это и есть юнит-тесты.


Смотри. Если ты написал тип правильно, то, согласно Curry-Howard isomorphism, если функции, использующие этот тип, компилируются, то это будет доказательством того, что тип написан верно. Написать тип неправильно, конечно, можно тоже, но тогда у тебя это выловится в дальнейшем, когда ты попытаешься с этим типом работать (ожидая от типа, что он описывает определённый граничный случай).
Re[2]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 10:22
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Просто лично ты никогда не создавал объемного ПО (которое не создать в одиночку) и не можешь понять зачем это нужно. Кнут вообще теоретик-алгоритмист из прошлого века. К его мнению нужно относиться очень осторожно.


И это еще слабо сказано !
Re[3]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.07.09 10:25
Оценка: +3 :))) :))
Здравствуйте, Ikemefula, Вы писали:

VD>>Просто лично ты никогда не создавал объемного ПО (которое не создать в одиночку) и не можешь понять зачем это нужно. Кнут вообще теоретик-алгоритмист из прошлого века. К его мнению нужно относиться очень осторожно.


I>И это еще слабо сказано !


Авторитетно заявил офигенный программист-практик XXI века.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 11:04
Оценка:
Здравствуйте, eao197, Вы писали:

VD>>>Просто лично ты никогда не создавал объемного ПО (которое не создать в одиночку) и не можешь понять зачем это нужно. Кнут вообще теоретик-алгоритмист из прошлого века. К его мнению нужно относиться очень осторожно.


I>>И это еще слабо сказано !


E>Авторитетно заявил офигенный программист-практик XXI века.


Я просто программист-практик. Офигенный это про тебя.
Re[3]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 12.07.09 12:18
Оценка: +1 -2
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, VladD2, Вы писали:



VD>>Просто лично ты никогда не создавал объемного ПО (которое не создать в одиночку) и не можешь понять зачем это нужно. Кнут вообще теоретик-алгоритмист из прошлого века. К его мнению нужно относиться очень осторожно.


I>И это еще слабо сказано !


Про тебя с Владом отлично написал в девятнадцатом веке Крылов: "Ай, моська..."
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[4]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 13:18
Оценка:
Здравствуйте, thesz, Вы писали:

VD>>>Просто лично ты никогда не создавал объемного ПО (которое не создать в одиночку) и не можешь понять зачем это нужно. Кнут вообще теоретик-алгоритмист из прошлого века. К его мнению нужно относиться очень осторожно.


I>>И это еще слабо сказано !


T>Про тебя с Владом отлично написал в девятнадцатом веке Крылов: "Ай, моська..."


Покажи мне работы Кнута на тему "Искусство объектно ориентированого дизайна", "Искусство построения компонентов" и тд.

Валяй.
Re[4]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.07.09 13:23
Оценка:
Здравствуйте, thesz, Вы писали:

I>>И это еще слабо сказано !


T>Про тебя с Владом отлично написал в девятнадцатом веке Крылов: "Ай, моська..."


Это вряд ли. Тогда не было программистов-прагматиков.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 12.07.09 17:54
Оценка: +1 -1 :))
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, thesz, Вы писали:


VD>>>>Просто лично ты никогда не создавал объемного ПО (которое не создать в одиночку) и не можешь понять зачем это нужно. Кнут вообще теоретик-алгоритмист из прошлого века. К его мнению нужно относиться очень осторожно.


I>>>И это еще слабо сказано !


T>>Про тебя с Владом отлично написал в девятнадцатом веке Крылов: "Ай, моська..."


I>Покажи мне работы Кнута на тему "Искусство объектно ориентированого дизайна", "Искусство построения компонентов" и тд.


I>Валяй.


Комментарий вполне в стиле моськи, кстати. "Он не слон, поскольку не может так звонко тявкать, как это делаю я и моя стая."

Тьфу.

Он написал труд, сравнимый с, а то и превосходящий вышеуказанные. И не один. Практически каждый его труд лежит в основе "объектно-ориентированного дизайна" и в "построении компонент".

Я так думаю, что количество шаблонов проектирования не сильно превышает количество алгоритмов, названных его именем.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[6]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 19:48
Оценка: :)
Здравствуйте, thesz, Вы писали:

T>Он написал труд, сравнимый с, а то и превосходящий вышеуказанные. И не один. Практически каждый его труд лежит в основе "объектно-ориентированного дизайна" и в "построении компонент".


Он написал труд который никоим образом не относится к ООД и компонентам и многому, что есть в индустрии ПО.
Re[7]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.07.09 20:29
Оценка: +1 -1
Здравствуйте, Ikemefula, Вы писали:

T>>Он написал труд, сравнимый с, а то и превосходящий вышеуказанные. И не один. Практически каждый его труд лежит в основе "объектно-ориентированного дизайна" и в "построении компонент".


I>Он написал труд который никоим образом не относится к ООД и компонентам и многому, что есть в индустрии ПО.


А Вы? Написали?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 20:34
Оценка:
Здравствуйте, eao197, Вы писали:

T>>>Он написал труд, сравнимый с, а то и превосходящий вышеуказанные. И не один. Практически каждый его труд лежит в основе "объектно-ориентированного дизайна" и в "построении компонент".


I>>Он написал труд который никоим образом не относится к ООД и компонентам и многому, что есть в индустрии ПО.


E>А Вы? Написали?


А ты ?
Re[7]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 12.07.09 21:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, thesz, Вы писали:


T>>Он написал труд, сравнимый с, а то и превосходящий вышеуказанные. И не один. Практически каждый его труд лежит в основе "объектно-ориентированного дизайна" и в "построении компонент".


I>Он написал труд который никоим образом не относится к ООД и компонентам и многому, что есть в индустрии ПО.


"Врага надо знать в лицо".

Published his groundbreaking paper "An empirical study of FORTRAN programs." ( Software---Practice and Experience, vol 1, pages 105-133, 1971) which laid the cornerstone of an empirical study of programming languages.

ОО языки программирования всё равно остаются языками программирования.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: Кнут о компонентном программировании.
От: Erop Россия  
Дата: 12.07.09 21:56
Оценка:
Здравствуйте, thesz, Вы писали:

T>Видишь ли, в типы нельзя загнать, я думаю, только красоту души девушки. Всё остальное типизируется.


IMHO, это не правда.
Скажем представь себе, что ты игрока в шахматы пишешь. Типизируй, например, требование "играет не хуже первого взрослого разряда".
Или, ещё хитрее: "скорее всего выиграет у последней доступной версии программы-конкурента"...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.