Здравствуйте, Сергей Губанов, Вы писали:
СГ>А на каком языке?
на самом деле язык не важен, если он высокоуровневый...
СГ>Вот одна строка на одном языке: IF a THEN b ELSIF c THEN d ELSE e END СГ>а вот пятнадцать строк на другом: СГ>
Здравствуйте, Pyro Sun, Вы писали:
PS>Кто как считает? Какой размер класса в строках оптимален для понимания того что там происходит?
PS>Из своих наблюдений пришел к выводу что класс должен быть меньше 1000 строчек. PS>Да и 1000 это пожалуй великовато.
Размер в строках — это плохой критерий в этом случае.
Надо смотреть на функциональность.
Размер в строках для класса для меня лично никогда не было большой проблемой.
А вот неудачные названия для методов, дублирование функциональности (copy/paste)
и прочие проблемы плохого дизайна класса — это то, что реально мешает пониманию.
Здравствуйте, Pyro Sun, Вы писали:
PS>Кто как считает? Какой размер класса в строках оптимален для понимания того что там происходит?
PS>Из своих наблюдений пришел к выводу что класс должен быть меньше 1000 строчек. PS>Да и 1000 это пожалуй великовато.
Как говорят классики, класс-отражение некоторой сущности действительности (хотя действительность вообще говоря сама может быть некоторой абстракцией в другой более "реальной" действительности). Тогда получается (если взять нормаьный, непатологический код), что в среднем одна строка должна описывать одно свойство этой сущности или какое-то ее (сущности) поведение. Даже если какой-то объект имеет столько свойств, то это означает только, что такой объект-некая сложная система, и представить его нужно в виде агрегации его подсистем (подобъектов), например, аэродром, взлетные полосы.
Такие вещи прекрасно описаны в книге Г. Буча (название сейчас точно не помню, по-моему "Объекто-ориентированный анализ...").
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Pyro Sun, Вы писали:
PS>>Из своих наблюдений пришел к выводу что класс должен быть меньше 1000 строчек.
СГ>А на каком языке?
СГ>Вот одна строка на одном языке: IF a THEN b ELSIF c THEN d ELSE e END
Зачот
Здравствуйте, Pyro Sun, Вы писали:
PS>Кто как считает? Какой размер класса в строках оптимален для понимания того что там происходит?
PS>Из своих наблюдений пришел к выводу что класс должен быть меньше 1000 строчек. PS>Да и 1000 это пожалуй великовато.
Я думаю, что важнее не общий размер класса, а размер его методов и количество этих методов. Так, класс из одного метода на 500 строчек воспринимается хуже, чем класс из 20 методов по 25 строчек в каждом. Ну и, конечно, количество единиц функциональности на строчку кода таки зависит от языка, как бы ни пинали Сергея Губанова
(филосовское отступление) Вообще, наверное, нужно различать "оптимальное количество строчек кода" и "оптимальное количество функциональности". Первый параметр имеет значение на маленьких объёмах кода — когда можно охватить весь код одним взглядом. Второй же параметр важен при понимании функциональности класса в целом, т.е. при бОльших объёмах кода. На близкую тему была довольно интересная дискуссия — http://sobaker.livejournal.com/231436.html .
Здравствуйте, FoolS.Top, Вы писали:
FT>Как говорят классики, класс-отражение некоторой сущности действительности (хотя действительность вообще говоря сама может быть некоторой абстракцией в другой более "реальной" действительности). Тогда получается (если взять нормаьный, непатологический код), что в среднем одна строка должна описывать одно свойство этой сущности или какое-то ее (сущности) поведение. Даже если какой-то объект имеет столько свойств, то это означает только, что такой объект-некая сложная система, и представить его нужно в виде агрегации его подсистем (подобъектов), например, аэродром, взлетные полосы. FT>Такие вещи прекрасно описаны в книге Г. Буча (название сейчас точно не помню, по-моему "Объекто-ориентированный анализ...").
Интересно отражением какой "реальной сущьности"? являеться класс шаблона Facade, который представляет собой надстройку над интерфейсом 5 или более классов... А что класс отражает некоторую сушьность действительности это фигня, зачастую это не так, как в выше привеленном примере.
Здравствуйте, Eugene Beschastnov, Вы писали:
EB>(филосовское отступление) Вообще, наверное, нужно различать "оптимальное количество строчек кода" и "оптимальное количество функциональности". Первый параметр имеет значение на маленьких объёмах кода — когда можно охватить весь код одним взглядом. Второй же параметр важен при понимании функциональности класса в целом, т.е. при бОльших объёмах кода. На близкую тему была довольно интересная дискуссия — http://sobaker.livejournal.com/231436.html.
Спасибо за ссылку почитал... Как видно собрались там любители смолтолка... Я тоже себя к ним отношу...
но чтобы на нем какие то проекты писать... бр....
Я же иммел ввиду более традиционные языки C++, С#, ObjectPascal.
Теперь насчет оптимального количества строчек кода...
Понятно что если в классе реализован сложный алгоритм, к примеру дискретное преобразование Фурье,
или в классе реализвано простое 'линейное' действие, вроде сериализации обьекта в базу данных.
То это две большие разницы с точки зрения понимания функционирования данного кода.
Я же иммел ввиду код одинаковой сложности...
Здравствуйте, bkat, Вы писали:
B>Размер в строках для класса для меня лично никогда не было большой проблемой.
А если класс являеться Facade для 5 и более классов... И так может получится что этот Facade
все растет и растет и вырастает дето до 3000-5000 строчек. Обозревать это все нехватает никакой возможности.
Вот такие классы нада резать на более мелкие. Отсюда и делаю вывод что классы больше 1000 строк это зло...
B>А вот неудачные названия для методов, дублирование функциональности (copy/paste)
за копи/паст сразу руки обычно отрывают разработчикам, либо не сразу а када проект валиться начинает B>и прочие проблемы плохого дизайна класса — это то, что реально мешает пониманию.
вот я и хочу сказать что класс за 1000 строчек это пример плохого дизайна архитектуры, либо отсутствие постоянного рефакторинга кода...
Здравствуйте, Pyro Sun, Вы писали:
PS>Спасибо за ссылку почитал... Как видно собрались там любители смолтолка... Я тоже себя к ним отношу... PS>но чтобы на нем какие то проекты писать... бр....
Оффтопик — а что мешает проекты писать?
Здравствуйте, Pyro Sun, Вы писали:
PS>вот я и хочу сказать что класс за 1000 строчек это пример плохого дизайна архитектуры, либо отсутствие постоянного рефакторинга кода...
Либо генератор кода.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Сергей Губанов, Вы писали:
PS>>Из своих наблюдений пришел к выводу что класс должен быть меньше 1000 строчек.
СГ>А на каком языке? СГ>Вот одна строка на одном языке: IF a THEN b ELSIF c THEN d ELSE e END
Здравствуйте, Pyro Sun, Вы писали:
PS>вот я и хочу сказать что класс за 1000 строчек это пример плохого дизайна архитектуры, либо отсутствие постоянного рефакторинга кода...
Либо отсутствие в языке таких средств как #region.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, klapaucius, Вы писали:
K>Здравствуйте, pagid, Вы писали:
P>>А в обероне есть классы?
K>Конечно же нет! Там есть так называемые "пастухи умозрительных протоколов": K>
K>pointer of abstract record
K>
pointer of — это Вы мощно придумали!
Типы данных языка Component Pascal имеющие отношение к "class":
Object = RECORD ... END;
Нерасширяемый value-тип — аналог struct в C# или в C.
Варианты с указателями:
PtrObject = POINTER TO Object;
RefObject = POINTER TO RECORD ... END;
ExtensibleObject = EXTENSIBLE RECORD ... END;
Расширяемый value-тип — аналог class/struct в C++.
Варианты с указателями:
PtrExtensibleObject = POINTER TO ExtensibleObject;
RefExtensibleObject = POINTER TO EXTENSIBLE RECORD ... END;
AbstractObject = ABSTRACT RECORD ... END;
Расширяемый абстрактный value-тип. Тоже что EXTENSIBLE, но размещать переменные этого типа нельзя.
Варианты с указателями:
PtrAbstractObject = POINTER TO AbstractObject;
RefAbstractObject = POINTER TO ABSTRACT RECORD ... END;
LimitedObject = LIMITED RECORD ... END;
Переменные этого value-типа можно (расширять и) размещать только в его собственном модуле, в других модулях размещать переменные этого типа нельзя.
Варианты с указателями:
PtrLimitedObject = POINTER TO LimitedObject;
RefLimitedObject = POINTER TO LIMITED RECORD ... END;
Здравствуйте, Pyro Sun, Вы писали:
PS>Кто как считает? Какой размер класса в строках оптимален для понимания того что там происходит?
PS>Из своих наблюдений пришел к выводу что класс должен быть меньше 1000 строчек. PS>Да и 1000 это пожалуй великовато.
Для меня больше 500 строк уже много, размер метода не должен вообще не должен быть больше одного экрана в идеале.
Не совсем по теме, но можно найти некоторые ответы по оценке качества кода и сложности проекта
Здравствуйте, Pyro Sun, Вы писали:
PS>Кто как считает? Какой размер класса в строках оптимален для понимания того что там происходит?
PS>Из своих наблюдений пришел к выводу что класс должен быть меньше 1000 строчек. PS>Да и 1000 это пожалуй великовато.
Ну а если функциональность класса действительно большая, из-за сложности объекта который он описывает? Что тогда, делать что-то вроде: MyClass_volume1, MyClass_volume2...
Здравствуйте, WinterMute, Вы писали:
WM>Ну а если функциональность класса действительно большая, из-за сложности объекта который он описывает? Что тогда, делать что-то вроде: MyClass_volume1, MyClass_volume2...
Здравствуйте, WinterMute, Вы писали:
WM>Здравствуйте, Pyro Sun, Вы писали:
PS>>Кто как считает? Какой размер класса в строках оптимален для понимания того что там происходит?
PS>>Из своих наблюдений пришел к выводу что класс должен быть меньше 1000 строчек. PS>>Да и 1000 это пожалуй великовато.
WM>Ну а если функциональность класса действительно большая, из-за сложности объекта который он описывает? Что тогда, делать что-то вроде: MyClass_volume1, MyClass_volume2...
Имхо, следует поступать согласно здравому смыслу, не обращая внимания на догмы: класс должен... бла-бла-бла подставить нужное по вкусу.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Kluev, Вы писали:
K>>З.Ы. Авторитетов для программиста быть не должно.
VD>А как же Страуструп?
А Страуструп, кстати в авторитеты и не лезет. Просто и неневязчиво излагает свои мысли: "тут сделали так, тут наступили на грабли — переделали, это хотели сделать красиво получилось как всегда, а вот эта вещь действительно удалась". При этом он не страдает навязчивой идеей по продвижению тараканов в головы программистов. В отличии от некоторых деятелей типа Вирта-состоварищи и министерства пропаганды из m$
Здравствуйте, Kluev, Вы писали:
K>>>З.Ы. Авторитетов для программиста быть не должно.
VD>>А как же Страуструп?
K>А Страуструп, кстати в авторитеты и не лезет.
А что можно влезть в аторитеты?
K> Просто и неневязчиво излагает свои мысли: "тут сделали так, тут наступили на грабли — переделали, это хотели сделать красиво получилось как всегда, а вот эта вещь действительно удалась". При этом он не страдает навязчивой идеей по продвижению тараканов в головы программистов. В отличии от некоторых деятелей типа Вирта-состоварищи и министерства пропаганды из m$
У него у самого тараканов море и другим он их распространяет. Хотя надо признать, что он намного более разумен нежели многие фанаты С++.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Kluev, Вы писали:
K>>>>З.Ы. Авторитетов для программиста быть не должно.
VD>>>А как же Страуструп?
K>>А Страуструп, кстати в авторитеты и не лезет.
VD>А что можно влезть в аторитеты?
K>> Просто и неневязчиво излагает свои мысли: "тут сделали так, тут наступили на грабли — переделали, это хотели сделать красиво получилось как всегда, а вот эта вещь действительно удалась". При этом он не страдает навязчивой идеей по продвижению тараканов в головы программистов. В отличии от некоторых деятелей типа Вирта-состоварищи и министерства пропаганды из m$
VD>У него у самого тараканов море и другим он их распространяет. Хотя надо признать, что он намного более разумен нежели многие фанаты С++.
Насчет тараканов, все в мире относительно. Верх знамени (cockroach free)
Здравствуйте, Pyro Sun, Вы писали:
PS>Я иммел ввиду один и тот же по функциональной сложности код, написаный в одном и томже стиле одним и тем же программистом...
Э... it depends on
1) каков уровень этого программиста
2) каковы его предпочтения
3) чем он замотивирован
— если, скажем, ему платят за объём — то с радостью напедалит полторы тыщщи там, где можно обойтись одной строкой
— ручная оптимизация с развёртыванием циклов (там, где компилятор не осилил) тоже не способствует краткости
Здравствуйте, VladD2, Вы писали:
K>>>>З.Ы. Авторитетов для программиста быть не должно. VD>>>А как же Страуструп? K>>А Страуструп, кстати в авторитеты и не лезет. VD>А что можно влезть в аторитеты?
У Страуструпа припоминается только одно "надо", которое формулируется примерно так: если вы программируете на C++, то надо извлекать преимущества из C++, а не пытаться превратить его в SmallTalk, например. Те, кто этому совету последовали — научились программировать на C++. Кстати, сам SmallTalk он при этом вовсе не ругает за то, что SamllTal — это не C++.
В отличие от массы проповедников лучшего стиля, лучшего языка, лучшей модели разработки и им подобных. Что, в общем-то, и понятно, если посмотреть, кто чем на жизнь зарабатывает.
K>> Просто и неневязчиво излагает свои мысли: "тут сделали так, тут наступили на грабли — переделали, это хотели сделать красиво получилось как всегда, а вот эта вещь действительно удалась". При этом он не страдает навязчивой идеей по продвижению тараканов в головы программистов. В отличии от некоторых деятелей типа Вирта-состоварищи и министерства пропаганды из m$
VD>У него у самого тараканов море и другим он их распространяет. Хотя надо признать, что он намного более разумен нежели многие фанаты С++.
Ну само собой — то "здравомыслие" сравниваем, то "разумность", то ещё какие-нибудь абстрактные сферические органы.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Pyro Sun, Вы писали:
PS>Кто как считает? Какой размер класса в строках оптимален для понимания того что там происходит?
PS>Из своих наблюдений пришел к выводу что класс должен быть меньше 1000 строчек. PS>Да и 1000 это пожалуй великовато.
В общем, это субъективная величина — иной раз бывают понятны и классы по 5 тысяч строк, а иной раз и в 10 строчках не разберёшься.
Здесь более надёжным критерием чем количество строк могут быть только оценки сложности графа связей класса и сложность методов. Но даже эти оценки сразу упираются в выбор допустимых пределов.
Поищи инфу по ключевым словам: "ОО-метрики" и "метрики ПО". Там где-то попадаются усреднённые оценки "по индустрии".
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, FR, Вы писали:
_>>Все еще будете продолжать меряться у кого что короче? FR>Нет будем мерятся у кого самые птичьи мозги, чтобы понять приведеные отрывки кода
Думаю для того легендарного-полумифического человека "мыслящего регекспами" которого кто-то приводил пример, понять это задачка элементарная. Но по-моему, назрела уже необходимость ввести термин противоположный синтаксическому оверхеду.
Синтаксическая недостаточность.
В данном случае мой диагноз — острая синтаксическая недостаточность (также известная как миосинтаксия или синтаксимия)
Прогрессирующая или нет — сказать не могу. С историей болезни языков J и K я не знаком.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, klapaucius, Вы писали:
K>В данном случае мой диагноз — острая синтаксическая недостаточность (также известная как миосинтаксия или синтаксимия)
Да, "острая синтаксическая недостаточность" это сильно. Пора цитатник заводить.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>klapaucius,
K>>В данном случае мой диагноз — острая синтаксическая недостаточность (также известная как миосинтаксия или синтаксимия)
LCR>Во-первых, комментариев в коде достаточно для понимания людьми, разбирающимися в языке. То есть нормальный стиль никто не отменял.
А где там комментарии?
При желании на многих языках можно писать криптокод, например первая задачка про простые числа на питоне:
print [a for a in range(2,1e6) if 0 not in [a%b for b in range(2,1+pow(a,0.5))]][10001]
только выдавать это за достоинство языка по моему не правильно.
FR,
LCR>>Во-первых, комментариев в коде достаточно для понимания людьми, разбирающимися в языке. То есть нормальный стиль никто не отменял.
FR>А где там комментарии?
Предложение перед строкой с кодом, которая объясняет то, что он (код) делает. Эти слова имело бы смысл сделать комментарием в самом коде.
Кстати, мне — всё понятно.
FR>При желании на многих языках можно писать криптокод, например первая задачка про простые числа на питоне: FR>
FR>print [a for a in range(2,1e6) if 0 not in [a%b for b in range(2,1+pow(a,0.5))]][10001]
FR>
FR>только выдавать это за достоинство языка по моему не правильно.
Потому что это неестественный для этого языка (Питона в д.с.) код, он не следует принятым традициям и не использует сложившиеся идиоматические конструкции.
А вообще-то Краткость =/= Маленький_объём_в_символах (и уж тем более =/= Криптообразности, Обфусцированности или ещё чему-нибудь в этом роде).
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>FR,
LCR>>>Во-первых, комментариев в коде достаточно для понимания людьми, разбирающимися в языке. То есть нормальный стиль никто не отменял.
FR>>А где там комментарии? LCR>Предложение перед строкой с кодом, которая объясняет то, что он (код) делает. Эти слова имело бы смысл сделать комментарием в самом коде.
аа
LCR>Кстати, мне — всё понятно.
Я смутно догадываюсь
LCR>Потому что это неестественный для этого языка (Питона в д.с.) код, он не следует принятым традициям и не использует сложившиеся идиоматические конструкции.
Почему неестественный, я могу довольно шустро такой код выдавать, вот например последняя задача:
FR,
LCR>>А вообще-то Краткость =/= Маленький_объём_в_символах (и уж тем более =/= Криптообразности, Обфусцированности или ещё чему-нибудь в этом роде).
FR>А что тогда?
Улыбнуло Навеяло этим:
-- Поздравляю, ваша жена только-что родила.
— Малчика?
— Нет.
— А кого?
) есть кой-какие мысли по этому поводу. Строгого определения не получилось (если строгое определение вообще возможно в данной области), но на текущий момент мне к тем мыслям прибавить нечего.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Во-первых, комментариев в коде достаточно для понимания людьми, разбирающимися в языке. То есть нормальный стиль никто не отменял.
Когда без коментариев даже человек разбирающийся в языке не может понять что делает код — это фича?
LCR>Во вторых, LCR> LCR>Совершеннно ничего не значащий набор символов для ученика начальных классов. Но этот факт говорит лишь о немощи этого ученика.
Во-первых, это не говорит о немощи ученика, как не говорит о Вашей немощи (предположительное) незнание валлийского языка.
Вот если бывший школьник не будет понимать этот набор символов после, допустим, n-го курса ВУЗа это будет говорить о его немощи.
Во-вторых, синтаксис математических выражений оттачивался столетиями, и он не ограничен набором аски-закорючек, что очень хорошо приведенная Вами формула демонстрирует. Кроме того синтаксис математических выражений общепринят и изучается всеми начиная со школы. Если бы код выглядел именно как метематические выражения я бы про синтаксическую недостаточность не говорил. Математика, в принципе, тоже когда-то была чем-то эзотерическим, вот только такой большой отрезок времени (чтобы изотерика стала мейнстримом) никакой язык программирования просто не проживет.
Легко видеть, что код этот не похож ни на декларативную математическую запись — ни на общепринятый способ записи алгоритмов.
А требования изучить ни на что не похожий синтаксис от языка-наколеночной поделки это смешнее даже чем сравнение этой поделки с математикой в качестве оправдания. Не то чтобы очень много людей придумывает вечерком на кухне новый синтаксис математических выражений, видимо потому что они понимают, как обрадуются коллеги, вынужденные эти записи читать. А новый язык выпекают чуть ли не каждую неделю. правда разнообразие синтаксисов языков программирования — куда меньше.
Этот код напоминает страшнейшие write-only регекспы (которые зачастую даже их автор не может прочитать уже через 2 минуты после написания) с редкими вкраплениями чисел и сокращенных названий математических функций.
Какие это дает преимущества, кроме автоматической обфускации, лично мне (по всей видимости, очень ограниченному человеку) совершенно непонятно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
K>Прогрессирующая или нет — сказать не могу. С историей болезни языков J и K я не знаком.
насколько я понимаю болезнь передается через гены, так что тут все серьезно
а вот по поводу синтаксической недостаточности — это все верно. я свой пример приводил именно с целью того, чтобы показать, что меньше не значит лучше.
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, Pyro Sun, Вы писали:
PS>Кто как считает? Какой размер класса в строках оптимален для понимания того что там происходит?
PS>Из своих наблюдений пришел к выводу что класс должен быть меньше 1000 строчек. PS>Да и 1000 это пожалуй великовато.
Смотря какой класс.
1. Если класс состоит из относительно простых методов, практически не связанных друг с другом (например, один метод public не связан с другими public и в помощь ему идут 2-3 private метода), то можно до 2000 строк
2, Если класс строго делится по группам методов слабо между собой связанных и есть возможность реализовать их в разных файлах — до 3-4 тыс. строк
3. Если методы довольно сильно между собой связаны, то
3.1 Не более 10 публичных методов
3.2. Не более 700 строк
Здравствуйте, Pyro Sun, Вы писали:
PS>Из своих наблюдений пришел к выводу что класс должен быть меньше 1000 строчек. PS>Да и 1000 это пожалуй великовато.
Класс вовсе не обязан быть функциональной единицей, требующей единовременного полного понимания.
klapaucius,
K>Когда без коментариев даже человек разбирающийся в языке не может понять что делает код — это фича?
Кто сказал, что не может? Я говорил, что какой бы вы язык не взяли, всегда требуется выработать стиль и следовать этому стилю. Наличие внятных комментариев — важная составляющая хорошего стиля. И APL/K/J не исключение.
LCR>>Во вторых, LCR>> LCR>>Совершеннно ничего не значащий набор символов для ученика начальных классов. Но этот факт говорит лишь о немощи этого ученика.
K>Во-первых, это не говорит о немощи ученика, как не говорит о Вашей немощи (предположительное) незнание валлийского языка.
Именно моё невладение валлийским языком и говорит обо мне как о пустом месте, когда требуется прочитать поэму на валлийском языке. Я могу теоретически это исправить изучив язык до уровня, на котором я смогу прочитать типичный текст. И до этого момента у меня просто не хватит наглости сказать: "Валлийский — плохой язык, его невозможно читать."
Короче, "не лезть в чужой монастырь со своим уставом" — это сугубо моё внутреннее ограничение, которое тем не менее многие окружающие меня люди считают разумным поведением.
K>Во-вторых, синтаксис математических выражений оттачивался столетиями, и он не ограничен набором аски-закорючек, что очень хорошо приведенная Вами формула демонстрирует. Кроме того синтаксис математических выражений общепринят и изучается всеми начиная со школы. Если бы код выглядел именно как метематические выражения я бы про синтаксическую недостаточность не говорил. Математика, в принципе, тоже когда-то была чем-то эзотерическим, вот только такой большой отрезок времени (чтобы изотерика стала мейнстримом) никакой язык программирования просто не проживет. K>Легко видеть, что код этот не похож ни на декларативную математическую запись — ни на общепринятый способ записи алгоритмов.
Да, это действительно нечто новое. Анализу подвергались мельчайшие детали математической нотации с целью максимальной унификации и упрощения последней. ASCII — исключительно ограничение, возникшее из-за соприкосновения с реальными операционными системами. Только в последнее время стало возможным безболезненно писать программы в Юникоде.
K>Этот код напоминает страшнейшие write-only регекспы (которые зачастую даже их автор не может прочитать уже через 2 минуты после написания) с редкими вкраплениями чисел и сокращенных названий математических функций.
Слишком много эмоций, причём совершенно не по делу. Есть функции, данные, и то и другое могут иметь имена. Те куски, которые вам напомнили "write-only регекспы, которые даже их автор..." содержат на 90% идиоматические конструкции.
Ну что ещё могу добавить? Ну вот месяцок-другой назад пост
был про волка, козу и капусту. Никто не умер.
K>Какие это дает преимущества, кроме автоматической обфускации, лично мне (по всей видимости, очень ограниченному человеку) совершенно непонятно.
1. K и J содержит большое количество действительно новых идей, а не старья в 984234-й инстанции заимствованного из других языков.
2. K и J являются самыми быстрыми интерпретируемыми языками благодаря их уникальным способностям к операциям с массивами. J особенно силён в математическом, статистическом анализ данных, K — в базах данных. Следствием интерпретируемости является большая гибкость.
3. Помимо синтаксиса эти языки несут определённую точку зрения на проблему, взгляд с которой помогает находить решения лучше для задач, где чего-то уже было, или хоть что нибудь, если ничего не было.
4. K и J очень компактны, соответственно и скорость создания программы тоже очень высока. В комментариях к "выпуклой оболочке на J" проскальзывала информация, что на ежегодной выставке в Нью-Йорке товарищ из KX в реальном времени (за 0.5...1 часа) пишет довольно-таки фукнциональную ERP, заказчиком выступают зрители в зале. Очень впечатляет.
5. Наконец, писать/читать программки на J это интересно, и кроме того очень полезно — совершенствуются навыки, которые востребованы сплошь и рядом, не только в программировании.
Определённо не для мэйнстрима, но есть люди, применяющие J для коммерческой разработки.
Здравствуйте, 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>Ну что ещё могу добавить? Ну вот месяцок-другой назад пост
Нда. С комментариями там напряженно. И, на мой вкус, код на Хаскеле выглядит симпатичнее, хоть он и длиннее.
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 для коммерческой разработки.
Кто эти люди?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
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 позволило существенно (то есть как минимум на порядок) удешевить разработку системы.
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 — это просто идея того, что при сложении массивов цикл на
интерпретаторе писать не стоит, пусть его сделает оптимизированное ядро,
а парсер воспримет как одно действие. Опять же хорошо продумано и описано.
Я не отрицаю, что реализации содержат семантические улучшения, которых
нигде более я не видел, кроме как в одном семействе языков. Но, всё же
идеи использовались и раньше и позже. Часто — использовались хуже.
Verb trains были изобретены Иверсоном и впервые появились именно в APL. Фактически это способ представления дерева композиций в виде бесскобочного выражения. Особенно здорово оно работает в сочетании с adverbs и conjunctions:
Во втором случае 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. Вобщем, кто понимает — тот понимает.
А вообще, для обстоятельного ответа мне нужно кое что почитать.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, 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).
Lazy Cjow Rhrr wrote: > Как-то и хочется поспорить, но времени — увы. Хотя я уже большую часть > доводов высказал, можно детально по косточкам разобрать ранги, > коньюнкции, причастия (adverbs) и остальные элементы, как это
Причастия, коньюнкции, и т.д. — варианты записи функций высшего порядка. > завязывается в гармоничный клубок и посмотреть аналогичные решения на > других языках. А потом долго дискутировать, принципиальные они или > косметические... > > Резюмирую. > Уникальность и первенство в реализации сочетания идей выше вроде > сомнений не вызывает, и это хорошо.
Более того, я согласен, что многие из идей по отдельности дают иногда
преимущество в удобстве, уникальны (считая APL/J/K родственными) и,
соответственно являются первыми, при этом очень хорошо продуманы и
реализованы. > С другой стороны я готов согласиться, что в некотором виде эти идеи > витали в воздухе до APL (тем более до J/K).
При этом я это говорю только про семантические идеи.
Синтаксические идеи — действительно уникальны. > > Вот. Я предлагаю
Согласен.
Но! Это неофициальные результаты. Такая ситуация связана с тем, как администрируются бенчмарки TPC. Поскольку стандартной имплементации бенчмарков нет, то членам TPC (членство стоит ессно нехилых денег) выдаются правила, которым должны следовать при создании своей имплементации. Если вдруг кто-то побивает рекорд, то он потом долго и нудно доказывает что он не верблюд до тех пор, пока результаты не будут официально подтверждены.
Поэтому у больших контор типа IBM, Oracle и т.п. за имплементацию и защиту TPC бенчмарков отвечают целые департаменты, чего маленькая контора KX себе позволить не может.
Можно загрузить, погонять и удостовериться самомоу.
В readme к tpcd:
[we expect kdb to be 10-100 times faster and scale better than other DBMS's.]
PS>>вот я и хочу сказать что класс за 1000 строчек это пример плохого дизайна архитектуры, либо отсутствие постоянного рефакторинга кода...
IT>Либо отсутствие в языке таких средств как #region.
Это фича языка или среды разработки?
От чего, от чего, от чего тах хорошо?
Потому что кто-то любит программиста
<< RSDN@Home 1.2.0 alpha rev. 647>>
Здравствуйте, Mamut, Вы писали:
PS>>>вот я и хочу сказать что класс за 1000 строчек это пример плохого дизайна архитектуры, либо отсутствие постоянного рефакторинга кода...
IT>>Либо отсутствие в языке таких средств как #region.
M>Это фича языка или среды разработки?
Думаю и того и другого. Сегодня эти вещи уже вполне осязаемого начинают зависеть друг от друга.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Такие рузультаты идут в топку. А выводы делаемые на них выглядят не честно.
Слова же про то что люди создали минимум в 10 раз более быстрый сервер и при этом не могут найти денег на публикацию тестов выглядят не слишком серьезно. Ведь отрыв в тестах в 10 раз гарантирует невероятные прибыли в течении будквально года, а то и месяцев. Любой банк даест денег столько сколько нужно.
У Оракла тоже как-то раз результат был в 10 или даже в 100 (сейчас не помню) раз быстрее остальных. Потом выяснилось, что они смашейничали. Использовали кэширование результатов вметсо вычисления. С тех пор TPC изменили и теперь TPC-C больше такое машейничество не позволяет.
Если их слова не откровенная лож, то скорее всего какой нибудь машейничество.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Lazy Cjow Rhrr wrote: > Можно загрузить, погонять и удостовериться самомоу. > В readme к tpcd: > [we expect kdb to be 10-100 times faster and scale better than other > DBMS's.]
Нереально. В разы — еще возможно, но не на порядки.
Насколько я понимаю, у них там заточка на in-memory DB, то есть большая
часть нужных для запросов данных держится резидентно в памяти. Особенно
учитывая, что столбцы таблиц они хранят по-отдельности. Это может в
некоторых ситуациях дать ооооочень неплохой прирост производительности,
но в общем случае все равно будет быстрее какой-нибудь Oracle.
Здравствуйте, Pyro Sun, Вы писали:
PS>Кто как считает? Какой размер класса в строках оптимален для понимания того что там происходит?
PS>Из своих наблюдений пришел к выводу что класс должен быть меньше 1000 строчек. PS>Да и 1000 это пожалуй великовато.
Ну, это не всегда верно. Например, при разработке контролов под .NET. Взять хотя бы события. Допустим, у нас есть 5-6 событий. К ним нужно добавить события вида PropertyChanged, причём ещё и свойств 8-9. Т.е получается около 15 событий. Для каждого из них нужно создать статический объект, написать add/remove код, OnEvent, комментарии к событиям и к On'ам. Получается, что до 500 строчек кода уходит только на события. Причём код весьма тривиальный и однообразный, его можно делать из сниппетов, а можно генерировать. Хорошо что в .NET есть #region, а начиная со второй версии — partial классы.
Думаю вопрос надо ставить не так. Скорее, на читабельность кода влияет количество строк в файле, не считая типовой код. С тем, что не следует делать файлы из более чем 1000 строк согласен. А вообще, производительность работы зависит не только от количества строк в файле, но и от количества публичных неунаследованных методов/свойств в классе, от количества классов в пространстве имён (пакете), от количества файлов в папке и т.д.
Нужно носить в себе еще хаос, чтобы быть в состоянии родить танцующую звезду.
Здравствуйте, Lazy Cjow Rhrr, Вы писали: LCR>Но! Это неофициальные результаты. Такая ситуация связана с тем, как администрируются бенчмарки TPC. Поскольку стандартной имплементации бенчмарков нет, то членам TPC (членство стоит ессно нехилых денег) выдаются правила, которым должны следовать при создании своей имплементации. LCR> Если вдруг кто-то побивает рекорд, то он потом долго и нудно доказывает что он не верблюд до тех пор, пока результаты не будут официально подтверждены.
Трендеж беззастенчивый.
1. Спецификации TPC доступны всем и совершенно бесплатно.
2. Если есть сомнения или проблемы с пониманием, то можно взять full disclosure report по любому из тестов, проведенных Большими Пацанами, и посмотреть, как они интерпретировали спецификации.
3. Никто ничего нудно не доказывает. Результаты публикуются сразу после тестирования, но имеют соответствующий статус, пока их не рассмотрят педанты из комитета. Вот, к примеру, результат IBM уже полтора года In Review, и ничего. LCR>Поэтому у больших контор типа IBM, Oracle и т.п. за имплементацию и защиту TPC бенчмарков отвечают целые департаменты, чего маленькая контора KX себе позволить не может.
Конечно целые департаменты. Достаточно посмотреть в цены top50 решений TPC, чтобы понять, что миллион TPC-C ни одна мелкая контора не потянет. Потому как для этого нужно только оборудования баксов эдак на миллион. С другой стороны, есть low-end тесты, в которых стоимость решения ~ $30000 с учетом софта и цен на серверное железо. Аналог приведенного результата можно собрать в современной России, ограничившись ~ $3000.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Конечно целые департаменты. Достаточно посмотреть в цены top50 решений TPC, чтобы понять, что миллион TPC-C ни одна мелкая контора не потянет. Потому как для этого нужно только оборудования баксов эдак на миллион. С другой стороны, есть low-end тесты, в которых стоимость решения ~ $30000 с учетом софта и цен на серверное железо. Аналог приведенного результата можно собрать в современной России, ограничившись ~ $3000.
Не, не, Синклер, ты не прав! Если наша КулСубд действительно в 100 раз круче топового паравоза, то ей не составит труда побить всех на железе продающеся в соседнем магазине офисных товаров. 100 раз это ну очень много .
А то что это трындеж беззастенчивый я склонен с тобой согласиться.
ЗЫ
А вообще очень интересно послушать логическое обоснование того как же можно на одном железе быть в 100 раз быстрее конкурентов при этом не мухлюя. Никак применяются торсионные поля.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Sinclair,
LCR>>Но! Это неофициальные результаты. Такая ситуация связана с тем, как администрируются бенчмарки TPC. Поскольку стандартной имплементации бенчмарков нет, то членам TPC (членство стоит ессно нехилых денег) выдаются правила, которым должны следовать при создании своей имплементации. LCR>> Если вдруг кто-то побивает рекорд, то он потом долго и нудно доказывает что он не верблюд до тех пор, пока результаты не будут официально подтверждены.
S>1. Спецификации TPC доступны всем и совершенно бесплатно.
+1. Моя ошибка, неверный источник.
S>2. Если есть сомнения или проблемы с пониманием, то можно взять full disclosure report по любому из тестов, проведенных Большими Пацанами, и посмотреть, как они интерпретировали спецификации. S>3. Никто ничего нудно не доказывает. Результаты публикуются сразу после тестирования, но имеют соответствующий статус, пока их не рассмотрят педанты из комитета. Вот, к примеру, результат IBM уже полтора года In Review, и ничего.
Вот именно, что ничего. Эти 2 "типа опровержения" и означают, что ты должен "долго и нудно доказывать что ты не верблюд", если представишь соответствующее решение. Здесь я прав.
В мэйл-листе kxsystems в последнее время стали часто всплывать апелляции к TPC, так что возможно результаты появятся в будущем.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>В мэйл-листе kxsystems в последнее время стали часто всплывать апелляции к TPC, так что возможно результаты появятся в будущем.
Сомневаюсь. Принципы, проложенные в основу дизайна kdb, несколько отличаются от традиционных.
Вот выдержки из обсуждения пятилетней давности.
I'm curious how KDB would stack up against these numbers and whether Kx has any plans to post TPC scores.
IBM's new world record is 2733 queries per hour (QphH), with a system cost of $347/QphH.
— Microsoft's old world record was 1699 QphH at $161/QphH.
— Microsoft achieved its score by using eight PIII 700MHz Intel processors on a single server; IBM used 16 PIII 700MHz processors spread across a four-node cluster.
-----
kdb would do about 14000 QphH with 16 p3 700MHZ
>and whether Kx has any plans to post TPC scores.
it would be fun but tpc-h says vertical partitioning is not allowed.
-----
(Why not send it in with a question about why arbitrary rules should be allowed to hinder progress...?)
-----
They freely acknowledge this problem, and "address" it by stating categorically that any changes would result a different benchmark (not "tpc-h").
[The implicit assumption is that vertical partitioning requires a lot of work and that they're not really excluding any meaningful database implementations with this rule. But implicit assumptions are hard to address in explicit conversation.]
An important part of TPC is how fast you can back out of incomplete failed transactions.
KDB is designed to eliminate all work on failed transactions -- that's one of the reasons it's fast.
So far, no one has exhibited much interest in building a superstructure around KDB to benchmark doing pointless work then undoing it.
Until that's done, KDB would not be suitable for TPC.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>>>Но! Это неофициальные результаты. Такая ситуация связана с тем, как администрируются бенчмарки TPC. Поскольку стандартной имплементации бенчмарков нет, то членам TPC (членство стоит ессно нехилых денег) выдаются правила, которым должны следовать при создании своей имплементации. LCR>>> Если вдруг кто-то побивает рекорд, то он потом долго и нудно доказывает что он не верблюд до тех пор, пока результаты не будут официально подтверждены.
S>>1. Спецификации TPC доступны всем и совершенно бесплатно. LCR>+1. Моя ошибка, неверный источник.
Кстати, никакой ошибки нет. Спецификации доступны всем, но стандартной реализации ("имплементации") нет. Каждый реализует в меру своей интерпретации спецификаций а потом сдает это дело на аудит.
Трурль,
LCR>>В мэйл-листе kxsystems в последнее время стали часто всплывать апелляции к TPC, так что возможно результаты появятся в будущем.
Т>Сомневаюсь. Принципы, проложенные в основу дизайна kdb, несколько отличаются от традиционных. Т>Вот выдержки из обсуждения пятилетней давности. Т>
tecnical discussion about KDB guts
Т>Как видно — сплошной мухлеж.
Всё понятно, спасибо. Короче итог:
1. TPC — это прежде всего "пеар", который неизвестно окупится или нет. Наличие официальных тестов позволяет привлечь лишь внимание потенциальных клиентов (тем, кто давно и плотно подсел на M$, Oracle etc. это пустой звук). Но этого "пеара" не будет по причине номер два.
2. Архитектурные различия таковы, что представить эффективную реализацию бенчмарков TPC, устраивающую остальные стороны невозможно.
Следовательно, единственно 100% работающий способ привлечь новых клиентов — это конкретно и обстоятельно, в тесном контакте с клиентами, продемонстрировать альтернативный более быстрый способ решения задач клиента. Чем как я полагаю ребята из KX и занимаются.
Здравствуйте, VladD2, Вы писали:
VD>Слова же про то что люди создали минимум в 10 раз более быстрый сервер и при этом не могут найти денег на публикацию тестов выглядят не слишком серьезно. Ведь отрыв в тестах в 10 раз гарантирует невероятные прибыли в течении будквально года, а то и месяцев. Любой банк даест денег столько сколько нужно.
Скорость никого не интересует. Будь они в 1000 раз быстрее Ms-Sql, всё равно они его не переплюнут. Вкладываться нужно не в скорость, а в рекламу.