Здравствуйте, Shmj, Вы писали:
S>>> сделали ";" не обязательной ЭФ>>Во всём виноват python S>Но в JS так же ; не обязательна. Пишут и так и эдак. В бейсике тоже не требовалась ;
не обязательна, но если используешь линтер, то становится обязательной
не оценили
Здравствуйте, F3V, Вы писали:
F3V>>>нужно чтобы документация не расходилась с кодом, F3V>>>а потому код должен быть на языке документации.
F3V>А должен быть великий и могучий.
Ну это как бы очевидно.
Я уже давно пишу программы с русскими идентификаторами.
Но для полного щщастья мне хочется чего-то более радикального.
Типа возможности вставить картинку... Ну хотя бы в комментарий.
Здравствуйте, alpha21264, Вы писали:
F3V>>>>а потому код должен быть на языке документации.
F3V>>А должен быть великий и могучий.
A>Ну это как бы очевидно.
Это очевидно тому, кто думает на великом и могучем.
Остальные могут только знать об этом.
A>Я уже давно пишу программы с русскими идентификаторами.
Да, помню и не сомневался в комментарии.
A>Но для полного щщастья мне хочется чего-то более радикального. A>Типа возможности вставить картинку... Ну хотя бы в комментарий.
A>И гиперссылки.
Безопасно можно комментарии использовать и их парсить и отображать в среде разработки.
Картинки можно хранить там в ссылках на "data:image/.." , но это раздует исходники.
Лучше уж комментарий в виде html или что-то подобное с svg использовать.
Среда разработки-то не проблема, а всего лишь задача
Здравствуйте, Privalov, Вы писали:
P>КОБОЛ был и на великом и могучем. Но читать его было не так удобно, как оригинал. Из-за падежных окончаний. Деталей не помню, мне больше с оригинальным дело иметь пришлось.
Если язык определяет мышление, то понимание великого и могучего будет разное на английском и на русском языках.
На мой взгляд, лучше работать в модели языка и терминах великого и могучего.
Здравствуйте, Shmj, Вы писали:
S>Kotlin посягнули на святое — сделали ";" не обязательной S>Как вам идея?
Я бы предпочел, чтобы в файлах ";" была, но чтобы текстовый редактор ее не показывал, где не надо. Чтобы задавалось в персональных настройках редактора.
Тоже самое с блоками "{}", автоматически скрывать, если и по отступам видно. Редактор VS все равно рисует линию перед блоком, поэтому сами "{}" уже не нужны.
Чтобы это сделать, придется разрешить множество мелких проблем, проработать множество сценариев редактирования. Но эти проблемы разрешимы.
Здравствуйте, Enomay, Вы писали:
E>Скобки ломают всю идею Scala, из которой Kotlin черпает вдохновение. E>А там можно сделать вот так:
E>
E> var mf = 2;
E> var i = if (mf == 1) 111 else 222
E>
какую идею оно ломает? В Rust н-р скобки обязательны. Вышеприведённый код выглядит так
let mf = 2;
let i = if mf == 1 { 111 } else { 222 };
Наоборот, в Kotlin уже сломали всю идею Scala с обязательным return. Так что можно уже спокойно выдохнуть, отбросить все моральные преграды и ломать дальше.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, dsorokin, Вы писали:
D>>А так, избавление от точки с запятой — одна из тенденций современного программирования. То, что в мейнстриме используется много где, — это еще по инерции
M>Не понимаю, а что, так сложно завершить выражение точкой с запятой? Или лучше оставить неоднозначности?
Я так понимаю, что это уменьшает когнитивную нагрузку на читателя. Еще эта мода пошла из статически-типизированных языков функционального программирования (и некоторых скриптовых), а создатели языков обычно хорошо подкованы в том, какие существуют языки на свете. Часто программисты ничего не знают и не хотят знать о том, что существует за пределами уютного и ограниченного для них мейнстрима (по моим собственным наблюдениям). А вот создатели языков программирования, как правило, блестяще эрудированы.
А чтобы не было неоднозначностей, усложняют парсеры и лексеры. Создается видимость простоты для программиста, а вот тем, кто пишет компиляторы, становится сложнее.
В той же scala есть нюансы в том, когда заканчивается выражение. Я никогда строгих правил не помнил. Достаточно было интуитивного понимания, когда в сложных случаях подсказывал сам компилятор.
И еще касательно точки с запятой. Этот атавизм уходит в прошлое еще и потому, что в мейнстрим все больше проникает другая идея из мира функционального программирования о том, что проще писать и понимать код, когда язык является ориентированным на выражения (expressions), а не на утверждения (statements). А писать обе ветви в выражении if или тело лямбды с точкой запятой — ну, такое себе. И ставить в конце return, а потом снова точку с запятой? Внешне выглядит совсем плохо. Без точки с запятой будет много изящнее и красивее.
Впрочем, никто от существующей кодовой базы на сегодняшних мейнстримных языках, конечно, не откажется в обозримом будущем. Более того, не все программисты могут воспринимать идеи из функционального программирования просто в силу своего типа характера (спросите Алису почему?). Поэтому точке с запятой еще многие лета!
Мне на практике Kotlin не зашёл (я работаю в области Enterprise), Java как была, так и остаётся идеальным языком для корпоративной разработки. Урезание синтаксиса имхо на пользу EE не идёт.
S>Kotlin посягнули на святое — сделали ";" не обязательной и даже не рекомендуемой, кода и так понятно что там должна стоять ; Якобы для чистоты кода.
Ну в Бейсике (даже не вижуал а Q и GW и прочих наверное тоже) так и было, но только не ; а :
Так что все уже придумано до этих ваших котлина и го
Как много веселых ребят, и все делают велосипед...
Здравствуйте, dsorokin, Вы писали:
D>... Более того, не все программисты могут воспринимать идеи из функционального программирования просто в силу своего типа характера (спросите Алису почему?)
Функциональный стиль контр-интуитивен, а императивный стиль наоборот — интуитивен. Империтив — это порядок шагов (порядок шагов, чтобы достать банан), это максимально понятный прямолинейный способ.
Именно виду контр-интуитивности не все программисты и могут, и это нормально. А функциональщина — это ненормально, это искривление естественного мышления.
Наличие разделителя снижает когнитивную нагрузку, а его отсутствие — увеличивает, т.к. челвоек вынужден на каждой строке анализировать, является ли это окончанием всего выражения или нет.
Здравствуйте, gyraboo, Вы писали:
G>Здравствуйте, dsorokin, Вы писали:
D>>... Более того, не все программисты могут воспринимать идеи из функционального программирования просто в силу своего типа характера (спросите Алису почему?)
G>Функциональный стиль контр-интуитивен, а императивный стиль наоборот — интуитивен. Империтив — это порядок шагов (порядок шагов, чтобы достать банан), это максимально понятный прямолинейный способ. G>Именно виду контр-интуитивности не все программисты и могут, и это нормально. А функциональщина — это ненормально, это искривление естественного мышления.
G>Наличие разделителя снижает когнитивную нагрузку, а его отсутствие — увеличивает, т.к. челвоек вынужден на каждой строке анализировать, является ли это окончанием всего выражения или нет.
А я и не буду спорить с тобой, потому что для тебя это может быть чистой правдой.
С другой стороны, основная идея функционального программирования — это композиционность. Это когда программа, целое, строится из частей. Малые блоки соединяются в композицию — так получается в итоге программа. Это преимущественно восходящий метод проектирования.
Смысл в том, что есть люди, которым заходит такой восходящий стиль программирования. Мне же, например, он, скорее всего, заходит из-за большей предсказуемости и надежности. Как бы там ни было, здесь меньше возникает непредсказуемых и неясных ошибок просто по той причине, что для успешного применения функционального стиля необходимо ограничивать работу с изменяемым состоянием, иначе толком не получится никакой композиции. А чем меньше побочных эффектов с изменяемым состоянием, то тем проще использовать код как строительные блоки, как кирпичики, из которых потом строится большой дом, создается программа.
Значит, я ценю в этом предсказуемость и надежность. А есть еще люди, которым нравится просто сама (математическая) концепция — они просто тащатся от нее.
Мы все разные. Кому-то действительно императивный стиль ближе, где расписано все по шагам, по правилам — как они сами и думают в обычной жизни. Кому-то ближе функциональный стиль. И это абсолютно нормально и естественно
Здравствуйте, dsorokin, Вы писали:
D>Значит, я ценю в этом предсказуемость и надежность. А есть еще люди, которым нравится просто сама (математическая) концепция — они просто тащатся от нее.
D>Мы все разные. Кому-то действительно императивный стиль ближе, где расписано все по шагам, по правилам — как они сами и думают в обычной жизни. Кому-то ближе функциональный стиль. И это абсолютно нормально и естественно
Кстати говоря, все это чистой воды словестная эквилибристика до тех пор пока стороны не договорятся о каких именно задачах в каких областях идет речь. Потому что один может считать проценты по деривативам в рамках ETL, а другой -- чтением/записи портов ввода-вывода в драйверах ОС.
PL/1. В эпоху продвинутых IDE имена типа s1, s2, s2a, d1 везде, а также суровый матан на Фортране перестали напрягать. Как и Бейсик на Искре-226 с его двухсимвольными идентификаторами.
F3V>На мой взгляд, лучше работать в модели языка и терминах великого и могучего.
Да, а в эпоху глобализации мне пришлось однажды объяснять индусу, что такое stroka.
Здравствуйте, dsorokin, Вы писали:
D>С другой стороны, основная идея функционального программирования — это композиционность. Это когда программа, целое, строится из частей. Малые блоки соединяются в композицию — так получается в итоге программа. Это преимущественно восходящий метод проектирования.
Модульность издревле есть и в императивной разработке (модули Паскаля, Оберона, модули и библиотеки Джавы, и т.д.).
Мне кажется, основная идея функциональности — это декларативность ("математическая функциональная запись", "не как сделать, а что сделать"). А лямбда и композиционность — это уже вторичные особенности, которые есть и в других парадигмах.
D>Смысл в том, что есть люди, которым заходит такой восходящий стиль программирования. Мне же, например, он, скорее всего, заходит из-за большей предсказуемости и надежности. Как бы там ни было, здесь меньше возникает непредсказуемых и неясных ошибок просто по той причине, что для успешного применения функционального стиля необходимо ограничивать работу с изменяемым состоянием, иначе толком не получится никакой композиции. А чем меньше побочных эффектов с изменяемым состоянием, то тем проще использовать код как строительные блоки, как кирпичики, из которых потом строится большой дом, создается программа.
Точно так же можно ограничивать работу с изменяемым состоянием и в императивной парадигме (final-переменные, арх. паттерны типа CQRS (Command Query Responsibility Segregation)).
D>Значит, я ценю в этом предсказуемость и надежность.
Предсказуемость и надежность как раз таки у императива выше))
D>А есть еще люди, которым нравится просто сама (математическая) концепция — они просто тащатся от нее.
Вот это уже ближе к истине))
D>Мы все разные. Кому-то действительно императивный стиль ближе, где расписано все по шагам, по правилам — как они сами и думают в обычной жизни. Кому-то ближе функциональный стиль. И это абсолютно нормально и естественно
АИ как думают функциональщики в обычной жизни? Не по шагам?
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Hоmunculus, Вы писали:
H>>
H>>if (i < 10);
H>> print(i)
H>>
Pzz>В Go эта конструкция выглядит так:
Pzz>
Pzz>if i < 10 {
Pzz> print(i)
Pzz>}
Pzz>
Pzz>Фигурные скобки обязательны. Тут уж одной точкой с запятой незаметно для себя логику не сломаешь.
Pzz>На Go есть смысл ссылаться потому, что это не какой-то там еще один язык программирования, а, в определенном смысле, работа над ошибками в языке Си.
В swift аналогично, кстати. А в упоминании про массивы чуть далее я только понял, что есть что-то с интервалами, и что там ссылочные типы данных, остальное изложено на непонятной мен трасянке. Но как раз зазличие типов данных для диапазонов, частей массивов в диапазонах и номеров элементов по мне вполне удобно. Только в swift массивы от чего-то решили сделать передаваемыми по значению с хи copy-on-write, ну и коллекций там вообще крайне мало, даже stack и queue нет в стандартном наборе. Точки с запятой в swift, кстати, необаательны, но именно это похоже на источник проблем, ибо полноценный compiler под такое сделать не могут в итоге.
Здравствуйте, gyraboo, Вы писали:
G>Здравствуйте, dsorokin, Вы писали:
G>Модульность издревле есть и в императивной разработке (модули Паскаля, Оберона, модули и библиотеки Джавы, и т.д.). G>Мне кажется, основная идея функциональности — это декларативность ("математическая функциональная запись", "не как сделать, а что сделать"). А лямбда и композиционность — это уже вторичные особенности, которые есть и в других парадигмах.
Функциональные языки могут выглядеть декларативно. Это бесспорно. Но если быть въедливым до терминологии, то декларативность означает большее. К декларативным, например, относят и Пролог, но он функциональным не является.
Что касается других парадигм, просто происходит взаимопроникновения идей, хотя основа императивного языка С++ все равно остается императивной, как ты ни старайся на нем писать в функциональном стиле (я пробовал: один раз было очень удачно, а в других случаях был "ужас, летящий на крыльях ночи").
G>Точно так же можно ограничивать работу с изменяемым состоянием и в императивной парадигме (final-переменные, арх. паттерны типа CQRS (Command Query Responsibility Segregation)).
А можно через инкапсуляцию. Проблема-то общая. Собственно, вопрос стиля программирования — это не жесткое какое-то правило. Это просто предпочитаемый и наиболее удобный в рамках конкретного языка стиль решения задач программирования. Как-то так. А так, можно ООП увидеть и в Эрланге, и в Хаскеле при желании. SICP не даст соврать.
G>Предсказуемость и надежность как раз таки у императива выше))
Это субъективно.
D>>А есть еще люди, которым нравится просто сама (математическая) концепция — они просто тащатся от нее.
G>Вот это уже ближе к истине))
Не хочу спорить.
D>>Мы все разные. Кому-то действительно императивный стиль ближе, где расписано все по шагам, по правилам — как они сами и думают в обычной жизни. Кому-то ближе функциональный стиль. И это абсолютно нормально и естественно
G>АИ как думают функциональщики в обычной жизни? Не по шагам?
Если ты лично про меня, то, вероятнее всего, что у меня "интуитивно-эмоциональное" мышление, где действительно "не по шагам". Заметь, что я никоим образом не пытался наехать на тебя. Просто еще раз хочу заметить, что люди порою очень сильно отличаются друг от друга. Кому-то императивное программирование ближе, кому-то — функциональное, а кто-то знать не хочет ни о каком программировании, да и компьютер кому, вообще, на фиг не сдался
Здравствуйте, dsorokin, Вы писали:
G>>И как думают функциональщики в обычной жизни? Не по шагам?
D>Если ты лично про меня, то, вероятнее всего, что у меня "интуитивно-эмоциональное" мышление, где действительно "не по шагам". Заметь, что я никоим образом не пытался наехать на тебя. Просто еще раз хочу заметить, что люди порою очень сильно отличаются друг от друга. Кому-то императивное программирование ближе, кому-то — функциональное, а кто-то знать не хочет ни о каком программировании, да и компьютер кому, вообще, на фиг не сдался
То-бишь императивный стиль мышления более близок гуманитариям? Это имеет смысл. Гуманитарии часто не любят/не могут вникать в щепетильный пошаговый процесс, им важен результат, и декларативный стиль как раз об этом — объявить результат, работать с результатом, результат на результате сидит и результатом погоняет (promise-ад), максимально скрыв сам пошаговый императивный способ получения результата. В идеале в функциональной программе вообще не должно быть ни слова про шаги получения результата.
Здравствуйте, gyraboo, Вы писали:
G>То-бишь императивный стиль мышления более близок гуманитариям? Это имеет смысл. Гуманитарии часто не любят/не могут вникать в щепетильный пошаговый процесс, им важен результат, и декларативный стиль как раз об этом — объявить результат, работать с результатом, результат на результате сидит и результатом погоняет (promise-ад), максимально скрыв сам пошаговый императивный способ получения результата. В идеале в функциональной программе вообще не должно быть ни слова про шаги получения результата.
Ты хотел сказать "функциональный стиль мышления"? За всех говорить не будем. Функциональное программирование нравится очень разным людям.
Ты близко описал то, как в одном моем методе задаются имитационные модели для систем массового обслуживания. Там действительно просто описываешь декларативно, как ведет себя система. Ну, а то, что изменяемое состояние скрыто внутри вычислений (продолжений под видом монад), — это уже деталь реализации. Не вижу в этом ничего плохого.
Кстати, эта штука работает даже в случае распределенной имитации (на кластере, или на многоядерном компьютере) с откатами вычислений. Именно такая декларативность, скрывающая работу с изменяемым состоянием, и позволяет гарантировать воспроизводимость вычислений (с точностью до нестабильной сортировки событий) даже независимо от того, какой будет порядок двоичных пакетов данных между разными логическими процессами (узлами имитационной модели).
Без функционального программирования у меня бы не получилось такого результата
Здравствуйте, Privalov, Вы писали:
F3V>>Если язык определяет мышление, то понимание великого и могучего будет разное на английском и на русском языках.
P>Оно, конечно, так. Но великий и могучий у каждого свой. Мне в эпоху перфокарт и IEBUPDTE пришлось разбираться с грузинским
PL/1. P>Да, а в эпоху глобализации мне пришлось однажды объяснять индусу, что такое stroka.
Но позвольте, если великий и могучий у каждого свой, то зачем нужна глобализация?
Разве на по этой причине великий и могучий отменяется глобализацией так или иначе?
P>В эпоху продвинутых IDE имена типа s1, s2, s2a, d1 везде, а также суровый матан на Фортране перестали напрягать. Как и Бейсик на Искре-226 с его двухсимвольными идентификаторами.
Когда знаешь содержание, то форма не очень важна, но понять содержание по плохой форме тяжелее.
Компьютерная латиница — работает, но не всегда оптимальна и её тяжелее понимать, чем родной язык.
Нехорошо и заменить слова (форму) в модели языка на родные, т.к. содержание (смысл) останется.
Потребуется изменение всей модели языка, а тут глобализаторы точно не помогут.
F3V>>На мой взгляд, лучше работать в модели языка и терминах великого и могучего.
