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

K>Здравствуйте, Pyro Sun, Вы писали:

PS>>Из своих наблюдений пришел к выводу что класс должен быть меньше 1000 строчек.
PS>>Да и 1000 это пожалуй великовато.

K> Класс вовсе не обязан быть функциональной единицей, требующей единовременного полного понимания.

М-да. И вообще, понимать что и как работает — это роскошь

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

K>> Класс вовсе не обязан быть функциональной единицей, требующей единовременного полного понимания.

FDS>М-да.

Не согласны с моим утверждением? Обоснуйте развёрнуто!

FDS> И вообще, понимать что и как работает — это роскошь

У человечишки в ущербненьком и убогоньком мозгу помещается одновременно около 7 сущностей. Больше — с трудом, а трудиться зря — не стоит, головка будет бо-бо.

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

И, кстати: функциональная единица должна помещаться на один экран. Читаться сразу и целиком. Это основное требование. А эти ваши 1000 строк — чушь, ничем не обоснованная.

Как вы добьётесь этого — не важно, если язык не позволяет — меняйте язык, используйте умные и правильные системы форматирования кода (такие, как noweb).

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

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

K>>> Класс вовсе не обязан быть функциональной единицей, требующей единовременного полного понимания.

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

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

Если речь идёт об изменении класса — то нет, если речь идёт об использовании хорошо написанного класса — то да, да и ещё раз да!

FDS>> И вообще, понимать что и как работает — это роскошь

K> У человечишки в ущербненьком и убогоньком мозгу помещается одновременно около 7 сущностей. Больше — с трудом, а трудиться зря — не стоит, головка будет бо-бо.

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

K> И, кстати: функциональная единица должна помещаться на один экран. Читаться сразу и целиком. Это основное требование. А эти ваши 1000 строк — чушь, ничем не обоснованная.

1. Это не мои 1000 строк. У меня — 700
2. Они обоснованы:
2.1. Чем меньше код, тем меньше сущностей.
2.2. По маленькому файлу легче перемещаться и находить в нём нужные методы
2.3. Т.е. прокруткой при чтении пользоватся не рекомендуется: вдруг глюки будут
Вообще, то, что метод должен помещатся на экран — это полная и ничем не обоснованная чушь. Видел большие, но очень простые для понимания и написания методы и маленькие, понятьь которые можно только после подробного изучения пары тыс. строк кода

K> Как вы добьётесь этого — не важно, если язык не позволяет — меняйте язык, используйте умные и правильные системы форматирования кода (такие, как noweb).

Не понял — что значит "умные и правильные системы форматирование кода"?

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

K>>>> Класс вовсе не обязан быть функциональной единицей, требующей единовременного полного понимания.

FDS>Если класс не есть цельная функциональная единица, то его, скорее всего, можно разбить на несколько других классов или подклассов — тем самым облегчить понимание программы.

Методы OOD очень сильно далеки собственно от деталей реализации. А раз уж OOD повелел делать эту сущность одним классом — будет она одним классом. Состоящим из нескольких функциональных единиц, не выделяемых в рамках ОО-таксономии.

FDS>Я считаю, что ООП предоставляет класс именно как единицу, которая упрощает понимание логики и должна быть понятна без особых проблем.

Такого свойства ООП не имеет by design.

FDS> Проще говоря — класс, элемент, декомпозирующий систему, и если он не понятен, то его нужно декомпозировать до тех пор, пока он станет понятным целиком.

Понятность реализации никоим образом не прописывается в методиках объектной декомпозиции.

FDS>1. Это не мои 1000 строк. У меня — 700

Тоже много.

FDS>2. Они обоснованы:
FDS>2.1. Чем меньше код, тем меньше сущностей.

Это не так.

FDS>2.2. По маленькому файлу легче перемещаться и находить в нём нужные методы

Кто бы спорил. Только зачем привязывать файл к классу?

FDS>2.3. Т.е. прокруткой при чтении пользоватся не рекомендуется: вдруг глюки будут

Так я и говорю — одна функциональная единица = одна страница.

FDS>Вообще, то, что метод должен помещатся на экран — это полная и ничем не обоснованная чушь.

А метод, к вашему сведению, это тоже не обязательно функциональная единица.

FDS> Видел большие, но очень простые для понимания и написания методы и маленькие, понятьь которые можно только после подробного изучения пары тыс. строк кода

И что? Это нерелевантно обсуждаемой теме.

K>> Как вы добьётесь этого — не важно, если язык не позволяет — меняйте язык, используйте умные и правильные системы форматирования кода (такие, как noweb).

FDS>Не понял — что значит "умные и правильные системы форматирование кода"?

Я же название дал. Сходите гуглём за ним. Вот ещё: web, fweb, cweb, literate haskell, ...

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>5. Наконец, писать/читать программки на J это интересно, и кроме того очень полезно — совершенствуются навыки, которые востребованы сплошь и рядом, не только в программировании.

LCR>Определённо не для мэйнстрима, но есть люди, применяющие J для коммерческой разработки.

Хотелось бы ссылок на эти интерпретаторы, интересно посмотреть.
И еще сколько времени надо чтобы научится сносно читать — писать на них?

Здравствуйте, Eugene Beschastnov, Вы писали:

WM>>Ну а если функциональность класса действительно большая, из-за сложности объекта который он описывает? Что тогда, делать что-то вроде: MyClass_volume1, MyClass_volume2...

EB>Есть такое слово — декомпозиция...

Там, где это слово заканчивается, детали реализации логики ещё даже не начинаются.

FR wrote:
> LCR>5. Наконец, писать/читать программки на J это интересно, и кроме
> того очень полезно — совершенствуются навыки, которые востребованы
> сплошь и рядом, не только в программировании.
>
> LCR>Определённо не для мэйнстрима, но есть люди, применяющие J для
> коммерческой разработки.
>
> Хотелось бы ссылок на эти интерпретаторы, интересно посмотреть.
> И еще сколько времени надо чтобы научится сносно читать — писать на них?
http://www.jsoftware.com — J. Время — насколько хотеть, словарик,
конечно, запоминается не сразу. Хотя самое используемое запомнится быстро.

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

R>http://www.jsoftware.com — J. Время — насколько хотеть, словарик,
R>конечно, запоминается не сразу. Хотя самое используемое запомнится быстро.

Я на сайте не нашел по какой лицензии распрастраняется, не знаешь?

FR wrote:
> R>http://www.jsoftware.com — J. Время — насколько хотеть, словарик,
> R>конечно, запоминается не сразу. Хотя самое используемое запомнится быстро.
>
> Я на сайте не нашел по какой лицензии распрастраняется, не знаешь?
Проприетарный проект, дают скачать бесплатно для
ознакомления/образовательного использования. Коммерческое использование
стоит денег, чем фирма и живёт. OpenJ (openj.sf.net) надеется выпросить
Dictionary под лицензией, позволяющей создать open-source реализацию.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Короче, "не лезть в чужой монастырь со своим уставом" — это сугубо моё внутреннее ограничение, которое тем не менее многие окружающие меня люди считают разумным поведением.

Похвально, но вот только данное ограничение к этой ситуации никакого отношения не имеет. Никто не лезет в чужой монастырь со своим уставом. Ведь никто не говорит это надо передаелать так-то и так-то, а сдесь нужно поступать так-то и так-то. Данная пословица вообще не про критику. Нет никаких причин воздерживаться от суждений о чем бы то ни было на основании тех сведений, которыми Вы располагаете. Ведь это суждения — и только.

LCR>Да, это действительно нечто новое. Анализу подвергались мельчайшие детали математической нотации с целью максимальной унификации и упрощения последней. ASCII — исключительно ограничение, возникшее из-за соприкосновения с реальными операционными системами. Только в последнее время стало возможным безболезненно писать программы в Юникоде.

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

K>>Этот код напоминает страшнейшие write-only регекспы (которые зачастую даже их автор не может прочитать уже через 2 минуты после написания) с редкими вкраплениями чисел и сокращенных названий математических функций.

LCR>Слишком много эмоций, причём совершенно не по делу. Есть функции, данные, и то и другое могут иметь имена. Те куски, которые вам напомнили "write-only регекспы, которые даже их автор..." содержат на 90% идиоматические конструкции.

Насчет эмоций согласен.

LCR>Ну что ещё могу добавить? Ну вот месяцок-другой назад пост

Автор: Mikl Kurkov
Дата: 08.02.06

был про волка, козу и капусту. Никто не умер.

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

K>>Какие это дает преимущества, кроме автоматической обфускации, лично мне (по всей видимости, очень ограниченному человеку) совершенно непонятно.

LCR>1. K и J содержит большое количество действительно новых идей, а не старья в 984234-й инстанции заимствованного из других языков.

Тут эмоции тоже через край. Лучше бы упомянули хоть одно умопомрачительное новшество.

LCR>2. K и J являются самыми быстрыми интерпретируемыми языками благодаря их уникальным способностям к операциям с массивами. J особенно силён в математическом, статистическом анализ данных, K — в базах данных. Следствием интерпретируемости является большая гибкость.

Ну что тут скажешь? Лидерство среди безнадежных тормозов — это пять.

LCR>3. Помимо синтаксиса эти языки несут определённую точку зрения на проблему, взгляд с которой помогает находить решения лучше для задач, где чего-то уже было, или хоть что нибудь, если ничего не было.

Вот именно, что помимо. К синтаксису это никакого отношения не имеет, и к преимуществам синтаксиса о которых я и спрашивал не относится.

LCR>4. K и J очень компактны, соответственно и скорость создания программы тоже очень высока. В комментариях к "выпуклой оболочке на J" проскальзывала информация, что на ежегодной выставке в Нью-Йорке товарищ из KX в реальном времени (за 0.5...1 часа) пишет довольно-таки фукнциональную ERP, заказчиком выступают зрители в зале. Очень впечатляет.

Компактность синтаксиса очень слабо связана со скоростью разработки и даже написания кода, даже если это написание кода в блокноте.
А как дела со скоростью чтения?

LCR>5. Наконец, писать/читать программки на J это интересно, и кроме того очень полезно — совершенствуются навыки, которые востребованы сплошь и рядом, не только в программировании.

То, что эти языки отличная головоломка-загадка у меня сомнений не вызывает.

LCR>Определённо не для мэйнстрима, но есть люди, применяющие J для коммерческой разработки.

Кто эти люди?

klapaucius,

LCR>>Да, это действительно нечто новое. Анализу подвергались мельчайшие детали математической нотации с целью максимальной унификации и упрощения последней. ASCII — исключительно ограничение, возникшее из-за соприкосновения с реальными операционными системами. Только в последнее время стало возможным безболезненно писать программы в Юникоде.

K>Боюсь, что на практике только совершенно фантастические удобства могут компенсировать отказ от привычной математической нотации.

Зачем отказываться от того, что и так хорошо. Но стандартная математическая нотация имеет ряд ограничений и несуразностей, которые обошли, оставшееся унифицировали и обобщили. Получилось замечательно.


LCR>>1. K и J содержит большое количество действительно новых идей, а не старья в 984234-й инстанции заимствованного из других языков.

K>Тут эмоции тоже через край. Лучше бы упомянули хоть одно умопомрачительное новшество.

Verb trains, tacit form, loop-free programming. А из известных "code is data is code", функции высшего порядка и т.п.


LCR>>2. K и J являются самыми быстрыми интерпретируемыми языками благодаря их уникальным способностям к операциям с массивами. J особенно силён в математическом, статистическом анализ данных, K — в базах данных. Следствием интерпретируемости является большая гибкость.

K>Ну что тут скажешь? Лидерство среди безнадежных тормозов — это пять.

Ага, правильный (ТМ) путь — это тормоз с надеждой на ускорение. Скорость на уровне компилируемых языков. В гугле можно поискать ссылки на бенчмарки (если они вообще что-нибудь да значат).

Да и обычные рассуждения головным мозгом подсказывают, что скорость интерпретации пропорциональна размеру программы при условии отсутствия циклов. А поскольку в типичной программе на J/K циклов очень мало, то получаем, что поток управления большую часть времени будет проводить в реализации, а там оптимизированный C и ассемблер.

K>К синтаксису это никакого отношения не имеет, и к преимуществам синтаксиса о которых я и спрашивал не относится.

Имеет, и самое прямое.

"Notation as a tool of thought" by Кен Иверсон;

When the human mind is engaged in thought of an explicit nature, the speech center of the brain is involved. This means that we are verbalizing our thoughts even though we may not actually be speaking. When we are thinking we are necessarily using language or a notation of some sort to accomplish this verbalization. Hence it follows that notation, particularly the scientific notation of the field of science is a critical tool for creative thinking.

Упомянутая выше статья "Succinctness is Power" by Paul Graham;

Математика не достигла бы таких высот, если бы до сих пор использовалась как в средних веках:
"D будет квадратный корень от b умноженного на самое себя за вычетом четвёрки помноженной на a и сразу же на c".

Какой системой счисления вы пользуетесь? Позиционной вероятно, поскольку она эффективнее.

LCR>>4. K и J очень компактны, соответственно и скорость создания программы тоже очень высока. В комментариях к "выпуклой оболочке на J" проскальзывала информация, что на ежегодной выставке в Нью-Йорке товарищ из KX в реальном времени (за 0.5...1 часа) пишет довольно-таки фукнциональную ERP, заказчиком выступают зрители в зале. Очень впечатляет.

K>Компактность синтаксиса очень слабо связана со скоростью разработки и даже написания кода, даже если это написание кода в блокноте.

Неверно. Или мягче выражусь: не в случае J/K. Подтверждено независимыми испытаниями.

K>А как дела со скоростью чтения?

Конечно же любому человеку потребуется бесконечное время (Hint: кто читатель?).

А если серьёзно, то я буду говорить о человеке, который использовал J хотя бы полгода. Так вот, я утверждаю, что скорость понимания этим человеком программы на J и программы на Java, примерно равных по функционалу, быстрее в случае J.

То есть четыре строки на J читаются быстрее трёх экранов на Java.


LCR>>Определённо не для мэйнстрима, но есть люди, применяющие J/K для коммерческой разработки.

K>Кто эти люди?

Юрий Бургер, искать в форуме "Декларативное программирование". Они в конторе используют связку с J + C++, J даёт гибкость, которой нет у C++ без всяких компромиссов по отношению к скорости.

http://kxsystems.com — маленькая компания, разработчик самой быстрой СУБД kdb. kdb — лучшая на данный момент СУБД для финансовых приложений. kdb используют ряд (более 20-ти) крупных финансовых компаний и бирж. kdb дорогая, вероятно самая дорогая из расчёта доллар/строка. kdb написана на K. Такой язык был выбран не потому, что это прикольно или необычно, а потому что это выгодно. Да, вот так банально. Использование K позволило существенно (то есть как минимум на порядок) удешевить разработку системы.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:


K>>Тут эмоции тоже через край. Лучше бы упомянули хоть одно умопомрачительное новшество.

LCR>Verb trains, tacit form, loop-free programming. А из известных "code is data is code", функции высшего порядка и т.п.

А можно чуть подробнее первое предложение разъяснить?

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

FDS>>Я считаю, что ООП предоставляет класс именно как единицу, которая упрощает понимание логики и должна быть понятна без особых проблем.

K> Такого свойства ООП не имеет by design.

Сочутствую вам и тем, кто будет читать ваш код

FDS>> Проще говоря — класс, элемент, декомпозирующий систему, и если он не понятен, то его нужно декомпозировать до тех пор, пока он станет понятным целиком.

K> Понятность реализации никоим образом не прописывается в методиках объектной декомпозиции.

Но это не значит, что класс не должен быть понятен

FDS>>1. Это не мои 1000 строк. У меня — 700

K> Тоже много.

Кому как. Я высказал своё личное мнение, основанное на моём личном опыте

FDS>>2. Они обоснованы:
FDS>>2.1. Чем меньше код, тем меньше сущностей.

K> Это не так.

Точнее: это не всегда так.

FDS>>2.2. По маленькому файлу легче перемещаться и находить в нём нужные методы

K> Кто бы спорил. Только зачем привязывать файл к классу?

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

FDS>>2.3. Т.е. прокруткой при чтении пользоватся не рекомендуется: вдруг глюки будут

K> Так я и говорю — одна функциональная единица = одна страница.

Так я и говорю — откуда это взялось? Что, программист прокуртить текст не может?

FDS>>Вообще, то, что метод должен помещатся на экран — это полная и ничем не обоснованная чушь.

K> А метод, к вашему сведению, это тоже не обязательно функциональная единица.

Что-то? И что же тогда такое — эта ваша загадочная функциональная единица?

FDS>> Видел большие, но очень простые для понимания и написания методы и маленькие, понятьь которые можно только после подробного изучения пары тыс. строк кода

K> И что? Это нерелевантно обсуждаемой теме.

Релевантно. Тут много слов из обсуждаемой темы
Это относится к методу, который занимает места больше чем одна страница.

K>>> Как вы добьётесь этого — не важно, если язык не позволяет — меняйте язык, используйте умные и правильные системы форматирования кода (такие, как noweb).

FDS>>Не понял — что значит "умные и правильные системы форматирование кода"?

K> Я же название дал. Сходите гуглём за ним. Вот ещё: web, fweb, cweb, literate haskell, ...

Хм, вы имеете ввиду текстовые редакторы, или я что-то сильно не понял?

FR wrote:
> K>>Тут эмоции тоже через край. Лучше бы упомянули хоть одно
> умопомрачительное новшество.
>
> LCR>Verb trains, tacit form, loop-free programming. А из известных "code
> is data is code", функции высшего порядка и т.п.
>
> А можно чуть подробнее первое предложение разъяснить?

Первые два — это отличные, в чём-то новаторские реализации того, что
есть в идеализированном ФП. Правильная константа, как иногда оказывается
— это константная функция (она кстати, возвращает себя), поэтому
применение функции к функции даст композицию. Они формализовали это
чуть-чуть по-другому, чтобы это было удобнее. "* + -" — это функция,
складывающая произведение и разность.
tacit form — оно же fixed-point, оно же программирование без явного
указания аргумента за счёт функций высшего порядка. Опять-таки, язык под
это заточен, иногда (если привыкнуть) результат бывает приятнее, чем
обычные виды записи. См. также Haskell.
loop-free — это просто идея того, что при сложении массивов цикл на
интерпретаторе писать не стоит, пусть его сделает оптимизированное ядро,
а парсер воспримет как одно действие. Опять же хорошо продумано и описано.

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

www.jsoftware.com — если хотите деталей.

raskin,

Verb trains были изобретены Иверсоном и впервые появились именно в APL. Фактически это способ представления дерева композиций в виде бесскобочного выражения. Особенно здорово оно работает в сочетании с adverbs и conjunctions:

Можно сравнить:

    truth_table1 =: #&2 #: [: i. 2&^
    truth_table2 =: (] # 2:) #: [: i. 2: ^ ]
    truth_table3 =: monad : '((] y.) # (2: y.)) #: (i. (2: y.) ^ (] y.))'
    truth_table4 =: monad : '(y. # 2) #: (i. 2 ^ y.)'
    truth_table1 3
0 0 0
0 0 1
0 1 0
0 1 1
1 0 0
1 0 1
1 1 0
1 1 1

Во втором случае verb train прерывается. В третьем случае — традиционный вариант через композицию и скобки над теми же функциями. В четвёртом случае — традиционный вариант над теми же функциями за исключением ] и 2:, поскольку в данном случае (] y.) может быть упрощено до просто y., а функция 2: возвращает 2 для любых аргументов.

Приведу эквивалентный совсем традиционный вариант (комментарии вставил чтобы не заставлять других читателей лезть в словарь, в тебе не сомневаюсь):

gen_elem  = (#);  // сгенерировать вектор y y .. y с кол-вом элементов x
gen_vect  = (i.); // сгенерировать вектор 0..(y-1)
antibase  = (#:); // конвертировать y в вектор используя базу из x
right     =  (]);  // взять правый аргумент
two       = (2:); // возвращает двойку для любого аргумента
power     = (^);  // возведение в степень

// тип type - потому что может быть n-мерный массив, необязательно число
type truth_table(type args)
{
    return antibase(gen_elem(right(args), 2), gen_vect(power(2, right(args)));
}

// выкинул функцию right, потому что в Java принято 
type truth_table_simplified(type x, type y)
{
    return antibase(gen_elem(y, 2), gen_vect(power(2, y)));
}

На мой взгляд verb trains очень даже новшество.


Tacit — да, есть аналогия с комбинаторами, но есть отличие: инфиксная запись и коньюнкции. Подозреваю, что как-то можно в хаскеле это эмулировать, но сомневаюсь, что 1-в-1. Если что — готов убедиться в обратном.


Loopless code — возможно хотелка была у многих и возможно давно, но внятной реализации охватывающей сколь нибудь сложный перебор не было. Даже Sisal — ФЯ который проектировался как киллер Фортрана, делает это весьма банально:

b := for initial       i := 0;
       bvalue := a[0];
     while (i < n - 1) repeat
       i := old i + 1;
       bvalue := old bvalue + a[i];
     returns
       array of bvalue
     end for;

Как видно for в д.с. — не цикл, а while — это функция которая который выдаёт массив — результат работы цикла, и этот цикл сформулирован явно.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

K>>Лучше бы упомянули хоть одно умопомрачительное новшество.

LCR>Verb trains, tacit form, loop-free programming...

По моему, весьма забавно, что первая ссылка, которую выдает google по зпросу loop-free programming — это ссылка на Konrad Zuse's Plankalkul. Вобщем, кто понимает — тот понимает.

А вообще, для обстоятельного ответа мне нужно кое что почитать.

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

K>> Такого свойства ООП не имеет by design.

FDS>Сочутствую вам и тем, кто будет читать ваш код

У вас квалификации достаточно чтобы такие заявления делать?

K>> Понятность реализации никоим образом не прописывается в методиках объектной декомпозиции.

FDS>Но это не значит, что класс не должен быть понятен

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

K>> Тоже много.

FDS>Кому как. Я высказал своё личное мнение, основанное на моём личном опыте

Надо бы ещё определиться, что под "понятностью" подразумеваем. Для меня это — возможность врубиться в смысл за 2-5 секунд прочтения. Дольше — уже не годится.

FDS>>>2.1. Чем меньше код, тем меньше сущностей.

K>> Это не так.

FDS>Точнее: это не всегда так.

Без разницы. Обоснование то всё равно снимается.

K>> Кто бы спорил. Только зачем привязывать файл к классу?

FDS>Во многих языках один класс не может быть описан в разных файлах.

А препроцессоры на что? Посмотрите на *WEB, они очень хорошо помогают разбросать код по разным файлам.

FDS>Класс, описанный в разных файлах — то же не очень здорово — нужно искать сразу по нескольким файлам.

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

K>> Так я и говорю — одна функциональная единица = одна страница.

FDS>Так я и говорю — откуда это взялось? Что, программист прокуртить текст не может?

Это будет уже больше 5 секунд. Надо чтобы можно было с первого взгляда прочитать всё.

K>> А метод, к вашему сведению, это тоже не обязательно функциональная единица.

FDS>Что-то? И что же тогда такое — эта ваша загадочная функциональная единица?

Любая семантически выделенная сущность.

FDS>Релевантно. Тут много слов из обсуждаемой темы
FDS>Это относится к методу, который занимает места больше чем одна страница.

Ну так кого волнуют методы?

FDS>>>Не понял — что значит "умные и правильные системы форматирование кода"?

K>> Я же название дал. Сходите гуглём за ним. Вот ещё: web, fweb, cweb, literate haskell, ...

FDS>Хм, вы имеете ввиду текстовые редакторы, или я что-то сильно не понял?

Учу пользоваться google. Недорого. $350 за лекцию. Дидактические материалы высылаю наложенным платежом, $500 за комплект.

Lazy Cjow Rhrr wrote:
> raskin,
>
> Verb trains были изобретены Иверсоном и впервые появились именно в APL.
> Фактически это способ представления дерева композиций в виде
> /бесскобочного/ выражения. Особенно здорово оно работает в сочетании с
> adverbs и conjunctions:
Я не отрицаю новторства verb trains как реализации. Но при этом всё же
это очень удачные синтаксис и уточнённая семантика для идеи, что любая
функция действует на функциях как композиция со своим действием на
константах.
>
> Можно сравнить:
>
> truth_table1 =: #&2 #: [: i. 2&^
> truth_table2 =: (] # 2 #: [: i. 2: ^ ]
> truth_table3 =: monad : '((] y.) # (2: y.)) #: (i. (2: y.) ^ (] y.))'
> truth_table4 =: monad : '(y. # 2) #: (i. 2 ^ y.)'
> truth_table1 3
> Приведу эквивалентный совсем традиционный вариант (комментарии вставил
> чтобы не заставлять других читателей лезть в словарь, в тебе не сомневаюсь):
Зря, кстати, я его ещё не выучил до конца.
Вот antibase не помню наизусть
>

> antibase = (#; // конвертировать y в вектор используя базу из x
-- имеется в виду превратить число в вектор цифр записи c переменным
основанием системы исчисления в соответствии с элементами x.

[: Вы не описали — это явно чтобы заставить людей прочитать про trains.
>
> На мой взгляд verb trains очень даже новшество.
Новшество — как отличная реализация того, что реализовано до конца на
компьютере до этого не было, да.
>
>
> Tacit — да, есть аналогия с комбинаторами, но есть отличие: инфиксная
> запись и коньюнкции. Подозреваю, что как-то можно в хаскеле это
> эмулировать, но сомневаюсь, что 1-в-1. Если что — готов убедиться в
> обратном.
Комбинаторы, функции высшего порядка — разные записи. Я не отрицаю
великолепной синтаксической реализации, но как идеи это можно найти в
ранних Лиспах... (функция выраженная как результат выражения высшего
порядка).
>
>
> Loopless code — возможно хотелка была у многих и возможно давно, но
> внятной реализации охватывающей сколь нибудь сложный перебор не было.
> Даже Sisal — ФЯ который проектировался как киллер Фортрана, делает это
> весьма банально:
Ну правильно, в язык, закладывая то, что нужно, его обобщали. Например,
надо было добавить сложение векторов без циклов.. Реализация очень хорошая.

В общем, в математике все эти идеи были. Неожиданными, я думаю, они ни
для кого не были. Но то, как их обобщили и включили в синтаксис (и
реализовали как действующий язык) — это было новое, и хорошее.

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

K>>> Такого свойства ООП не имеет by design.
FDS>>Сочутствую вам и тем, кто будет читать ваш код
K> У вас квалификации достаточно чтобы такие заявления делать?
Да. Её и не так много надо, что бы посочувтсвовать


K>>> Тоже много.

FDS>>Кому как. Я высказал своё личное мнение, основанное на моём личном опыте

K> Надо бы ещё определиться, что под "понятностью" подразумеваем. Для меня это — возможность врубиться в смысл за 2-5 секунд прочтения. Дольше — уже не годится.

А-а-а-а. Хм. Я под понятность подразумеваю, что нужно не более 2-х проходов по тексту, что бы его понять и применять с минимумом ошибок

FDS>>>>2.1. Чем меньше код, тем меньше сущностей.
K>>> Это не так.
FDS>>Точнее: это не всегда так.
K> Без разницы. Обоснование то всё равно снимается.

Нет. Я привёл распространённый частный случай, и это только один из пунктов.


FDS>>Класс, описанный в разных файлах — то же не очень здорово — нужно искать сразу по нескольким файлам.
K> У вас, кажется, со средствами разработки напряжёнка, если даже такая простая вещь вызывает затруднения. Попробуйте их поменять, что ли...

Хм. Наверное я слишком привередлив и ленив Но всё же поиск в редакторе VisualStudio 2005 и Delphi 7 меня напрягает.

K>>> Так я и говорю — одна функциональная единица = одна страница.
FDS>>Так я и говорю — откуда это взялось? Что, программист прокуртить текст не может?
K> Это будет уже больше 5 секунд. Надо чтобы можно было с первого взгляда прочитать всё.

Понял.

K>>> А метод, к вашему сведению, это тоже не обязательно функциональная единица.
FDS>>Что-то? И что же тогда такое — эта ваша загадочная функциональная единица?
K> Любая семантически выделенная сущность.

Тогда класс — это функциональная единица


FDS>>>>Не понял — что значит "умные и правильные системы форматирование кода"?

K>>> Я же название дал. Сходите гуглём за ним. Вот ещё: web, fweb, cweb, literate haskell, ...

FDS>>Хм, вы имеете ввиду текстовые редакторы, или я что-то сильно не понял?

K> Учу пользоваться google. Недорого. $350 за лекцию. Дидактические материалы высылаю наложенным платежом, $500 за комплект.

Спасибо. Я то же учу пользоваться google, не помню вот только сколько за пару, но думаю раз в 100 меньше
Вы лучше мне английский выучить помогите, часа за два...

raskin,

>> antibase = (#; // конвертировать y в вектор используя базу из x
R>-- имеется в виду превратить число в вектор цифр записи c переменным
R>основанием системы исчисления в соответствии с элементами x.

Точно.

  2 2 2 2 #: 13
1 1 0 1      NB. бинарное представление

  5 4 3 2 #: 13
0 2 0 1      NB. 13 - это 201 в (5,4,3,2)-ичной системе счисления

  24 60 60 #: 1300
0 21 40      NB. 1300 секунд - это 0 часов, 21 минута и 40 секунд

R>В общем, в математике все эти идеи были. Неожиданными, я думаю, они ни
R>для кого не были. Но то, как их обобщили и включили в синтаксис (и
R>реализовали как действующий язык) — это было новое, и хорошее.

Как-то и хочется поспорить, но времени — увы. Хотя я уже большую часть доводов высказал, можно детально по косточкам разобрать ранги, коньюнкции, причастия (adverbs) и остальные элементы, как это завязывается в гармоничный клубок и посмотреть аналогичные решения на других языках. А потом долго дискутировать, принципиальные они или косметические...

Резюмирую.
Уникальность и первенство в реализации сочетания идей выше вроде сомнений не вызывает, и это хорошо.
С другой стороны я готов согласиться, что в некотором виде эти идеи витали в воздухе до APL (тем более до J/K).

Вот. Я предлагаю