и каков разумный предел?
Собственно, испытывало ли ещё кто трудности/неприятие/разочарование и т.п. из-за длинного расплывчатого кода/алгоритма?
были ли какие нибудь более-менее успешные попытки увеличить плотность? в разумных пределах конечно, не в ущерб читабельности(разве что минимальный).
Буду программировать и переводить с японского за еду. Предложения принимаются.
Здравствуйте, anokata, Вы писали:
A>и каков разумный предел? A>Собственно, испытывало ли ещё кто трудности/неприятие/разочарование и т.п. из-за длинного расплывчатого кода/алгоритма? A>были ли какие нибудь более-менее успешные попытки увеличить плотность? в разумных пределах конечно, не в ущерб читабельности(разве что минимальный).
Довольно поучительно анализировать решения одних и тех же задач на разных языках. К примеру, очень неплохо для этого подходит турнир Google Code Jam — народ наклепал даже специальный сайт статистики, где можно искать присланные решения задач: http://www.go-hero.net/jam/10/solutions
Про увеличение плотности — к примеру, практически все турнирные решения на C++ начинаются с тучи заранее заготовленных макросов, резко упрощающих и ускоряющих написание кода.
Здравствуйте, Artifact, Вы писали:
A>Этот вопрос был решён ещё задолго до появления языков программирования. Поэтому вместо "двадцать три прибавить тридцать три" мы пишем "23 + 33".
А в Коболе именно так и пишем: ДОБАВИТЬ 23 К 33 ПОЛОЖИТЬ РЕЗУЛЬТАТ В СУММА
Здравствуйте, Artifact, Вы писали:
A>Здравствуйте, anokata, Вы писали:
A>Этот вопрос был решён ещё задолго до появления языков программирования. Поэтому вместо "двадцать три прибавить тридцать три" мы пишем "23 + 33".
Пример появления понятия дифференциал более поучителен.. вместо "отношение приращения функции к приращению аргумента"
Здравствуйте, anokata, Вы писали:
A>и каков разумный предел? A>Собственно, испытывало ли ещё кто трудности/неприятие/разочарование и т.п. из-за длинного расплывчатого кода/алгоритма? A>были ли какие нибудь более-менее успешные попытки увеличить плотность? в разумных пределах конечно, не в ущерб читабельности(разве что минимальный).
Тут вариантов два.. либо насыщать обозначениями либо текст.. Так что вопрос стандартизации и пользовательское определение знаков это единственный выход
Re: Стремитесь минимизировать сущности, а не буковки
Здравствуйте, anokata, Вы писали:
A>и каков разумный предел? A>Собственно, испытывало ли ещё кто трудности/неприятие/разочарование и т.п. из-за длинного расплывчатого кода/алгоритма? A>были ли какие нибудь более-менее успешные попытки увеличить плотность? в разумных пределах конечно, не в ущерб читабельности(разве что минимальный).
Большая лаконичность плохо, большая многобуковость тоже плохо, нужен определенный баланс. При этом естественные языки показывают, что баланс должен быть несколько смещен в сторону многобуковости.
Вообще вопросу лаконичности уделяется слишком большое внимание, стремиться нужно к языку, который позволяет решать задачи используя минимум сущностей, а не минимум буковок.
Здравствуйте, anokata, Вы писали:
A>Собственно, испытывало ли ещё кто трудности/неприятие/разочарование и т.п. из-за длинного расплывчатого кода/алгоритма?
Я наоборот, испытываю трудности с чтением, когда все слишком уплотнено. Люблю, когда написано пусть и немного длинно, но зато понятно.
Computer science is no more about computers than astronomy is about telescopes (c) Edsger Dijkstra
Re[2]: Стремитесь минимизировать сущности, а не буковки
Здравствуйте, Undying, Вы писали:
U>Большая лаконичность плохо, большая многобуковость тоже плохо, нужен определенный баланс. При этом естественные языки показывают, что баланс должен быть несколько смещен в сторону многобуковости.
U>Вообще вопросу лаконичности уделяется слишком большое внимание, стремиться нужно к языку, который позволяет решать задачи используя минимум сущностей, а не минимум буковок.
вот и покажите языки которые обходятся минимумом сущностей
Буду программировать и переводить с японского за еду. Предложения принимаются.
Re[3]: Стремитесь минимизировать сущности, а не буковки
Здравствуйте, anokata, Вы писали:
A>Здравствуйте, Undying, Вы писали:
U>>Большая лаконичность плохо, большая многобуковость тоже плохо, нужен определенный баланс. При этом естественные языки показывают, что баланс должен быть несколько смещен в сторону многобуковости.
U>>Вообще вопросу лаконичности уделяется слишком большое внимание, стремиться нужно к языку, который позволяет решать задачи используя минимум сущностей, а не минимум буковок.
A>вот и покажите языки которые обходятся минимумом сущностей
Имхо сущности они в первую очередь в голове автора, а не в языке...
Здравствуйте, Курилка, Вы писали:
К>Имхо сущности они в первую очередь в голове автора, а не в языке...
Не подрывай основы!
Этак ты докатишься до того, что язык не важен.
Хотя, почти все программисты "за сорок" так думают.
Даже Шеридан (фанатик из фанатиков) что-то подобное когда-то говорил
Здравствуйте, batu, Вы писали:
B>Здравствуйте, Artifact, Вы писали:
A>>Здравствуйте, anokata, Вы писали:
A>>Этот вопрос был решён ещё задолго до появления языков программирования. Поэтому вместо "двадцать три прибавить тридцать три" мы пишем "23 + 33". B>Пример появления понятия дифференциал более поучителен.. вместо "отношение приращения функции к приращению аргумента"
Математик-наци mode on:
"отношение приращения функции к приращению аргумента" — это производная. Если дописать перед фразой слово "предел" и после "при приращении аргумента, стремящемся к нулю".
Re[4]: Стремитесь минимизировать сущности, а не буковки
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, anokata, Вы писали:
A>>Здравствуйте, Undying, Вы писали:
U>>>Большая лаконичность плохо, большая многобуковость тоже плохо, нужен определенный баланс. При этом естественные языки показывают, что баланс должен быть несколько смещен в сторону многобуковости.
U>>>Вообще вопросу лаконичности уделяется слишком большое внимание, стремиться нужно к языку, который позволяет решать задачи используя минимум сущностей, а не минимум буковок.
A>>вот и покажите языки которые обходятся минимумом сущностей
К>Имхо сущности они в первую очередь в голове автора, а не в языке...
Именно.
От себя добавлю, что краткости языка не существует. Поэтому нельзя говорить о том достоинство это или недостаток. Всё потому что краткость это когда программист говорит с языком программирования как на своём естественном языке. Хотя если вас интересует количество буковок, то упарываться тут можно до бесконечности сводя всё к абсурду и превращая язык в эзотерический.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Re[5]: Стремитесь минимизировать сущности, а не буковки
Здравствуйте, Sorc17, Вы писали:
S>От себя добавлю, что краткости языка не существует. Поэтому нельзя говорить о том достоинство это или недостаток. Всё потому что краткость это когда программист говорит с языком программирования как на своём естественном языке. Хотя если вас интересует количество буковок, то упарываться тут можно до бесконечности сводя всё к абсурду и превращая язык в эзотерический.
Ах да, и ещё забыл. Например для меня С++ стал эзотерическим со временем. Я просто перестал понимать эту бешеную кашу из перегруженных операторов и сахара. ОХ УЖ ЭТОТ САХАР. Знаете как мыслят эти остолопы? Я делаю одну и ту же рутинную работу каждый день, пишу одни и те же слова. А почему бы мне не заменить их каким-нибудь одним символом? А что, круто! И после этого мы получаем:
myclass():a(0),strcpy(b,"")
C++ и особенно С# мои самые ненавистные языки в этом смысле. Там постоянно вводят какой-то не нужный бред:
var a = new A();
О да, конечно у них очень веские причины чтобы изменить синтаксис языка. Знаете дети, отныне мы не будем писать "дуп" вместо "дуб", так короче и всё равно любой человек поймёт что имеется ввиду "дуб", так зачем утруждать себя и писать "дуб"? Ведь всё же делается чтобы людям было удобнее и проще! Новая улучшенная версия русского языка! Спешите видеть! (студентам скидки)
Как люди пишут на языках, разработчики которых им каждые код вставляют палки в колёса я не знаю. Предпочитаю Java и чистый C. Спасибо за внимание
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Re[5]: Стремитесь минимизировать сущности, а не буковки
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, Курилка, Вы писали:
К>>Имхо сущности они в первую очередь в голове автора, а не в языке...
A>Не подрывай основы! A>Этак ты докатишься до того, что язык не важен.
Ну яб сказал, что для язык может быть (не)удобен для решения задач, на которые он заточен, но при условии наличия головы у автора, который бы выражал на нём необходимые сущности.
