Kotlin посягнули на святое — сделали ";" не обязательной и даже не рекомендуемой, кода и так понятно что там должна стоять ; Якобы для чистоты кода.

Т.е. можно так:

val a = 5;
val b = 10;
println(a + b);

А можно и так:

val a = 5
val b = 10
println(a + b)

— компилятор не будет ругаться.

А вот тут уже обязательно:

val a = 5; val b = 10; println(a + b)

Т.е. по идее то же самое можно сделать для большинства других языков без особых доработок компилятора. Но стало ли чище?

Как вам идея?

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

А как начет такой детской ошибки/опечатки?

if (i < 10);
   print(i)

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

H>

H>if (i < 10);
H>   print(i)
H>

Тут не понял — такую же опечатку можно сделать и в православном C++ или Java.

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

S>Здравствуйте, Hоmunculus, Вы писали:

H>>

H>>if (i < 10);
H>>   print(i)
H>>

S>Тут не понял — такую же опечатку можно сделать и в православном C++ или Java.

Так я поэтому и спросил
Разрулит что лажа?

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

H>Так я поэтому и спросил
H>Разрулит что лажа?

Просто варнинг:

'if' has empty body

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


S>Т.е. по идее то же самое можно сделать для большинства других языков без особых доработок компилятора. Но стало ли чище?

S>Как вам идея?

Ну, если это единственная оставшаяся нерешенная проблема, то почему бы и нет

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

M>Ну, если это единственная оставшаяся нерешенная проблема, то почему бы и нет

Но нет порядка. Как же перфекционизм?

Кто-то будет писать ; а кто-то скажет что это лишнее. Начнется новый холивар, еще похлеще пробелы vs табы, возможно дойдет до кровопролития в отдельных случаях.

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

M>>Ну, если это единственная оставшаяся нерешенная проблема, то почему бы и нет

S>Но нет порядка. Как же перфекционизм?

S>Кто-то будет писать ; а кто-то скажет что это лишнее. Начнется новый холивар, еще похлеще пробелы vs табы, возможно дойдет до кровопролития в отдельных случаях.

Насрать

S> сделали ";" не обязательной

Во всём виноват python

Здравствуйте, Эйнсток Файр, Вы писали:

S>> сделали ";" не обязательной
ЭФ>Во всём виноват python

Но в JS так же ; не обязательна. Пишут и так и эдак. В бейсике тоже не требовалась ;

Это чисто фишка C — строго ; и строгость в больших/маленьких буквах.

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

S>Кто-то будет писать ;
Не будет. И холиваров нет.

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

H>

H>if (i < 10);
H>   print(i)
H>

В Go эта конструкция выглядит так:

if i < 10 {
    print(i)
}

Фигурные скобки обязательны. Тут уж одной точкой с запятой незаметно для себя логику не сломаешь.

На Go есть смысл ссылаться потому, что это не какой-то там еще один язык программирования, а, в определенном смысле, работа над ошибками в языке Си.

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

S>Как вам идея?

Это они у Go позаимствовали

S>Kotlin посягнули на святое — сделали ";" не обязательной и даже не рекомендуемой, кода и так понятно что там должна стоять ; Якобы для чистоты кода.
Все правильно сделали.
В Go так же и даже лучше.

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

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

S>>Как вам идея?

Pzz>Это они у Go позаимствовали

Ну, да! Конечно, из Go, откуда же еще? Scala тут совсем не причем.

А так, избавление от точки с запятой — одна из тенденций современного программирования. То, что в мейнстриме используется много где, — это еще по инерции

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

S>Kotlin посягнули на святое — сделали ";" не обязательной и даже не рекомендуемой, кода и так понятно что там должна стоять ; Якобы для чистоты кода.

Офигеть, какая актуальная проблема.

Едут в купе ветеринар и два программиста. Программисты трещат всю дорогу о чём-то о своём. Наконец, ветеринар робко решается прервать их:
— Я извиняюсь... А вы когда-нибудь пробовали быка в ноздрю?
— ????????
— Ну, я просто, чтоб в разговор встрять...

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

Pzz>На Go есть смысл ссылаться потому, что это не какой-то там еще один язык программирования, а, в определенном смысле, работа над ошибками в языке Си.

Точно? А мне казалось, что какая-то херота типа питона

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

D>А так, избавление от точки с запятой — одна из тенденций современного программирования. То, что в мейнстриме используется много где, — это еще по инерции

Не понимаю, а что, так сложно завершить выражение точкой с запятой? Или лучше оставить неоднозначности?

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

S>Kotlin посягнули на святое — сделали ";" не обязательной и даже не рекомендуемой, кода и так понятно что там должна стоять ; Якобы для чистоты кода.

S>Т.е. по идее то же самое можно сделать для большинства других языков без особых доработок компилятора. Но стало ли чище?

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

S>Как вам идея?

Рефакторинг усложняется, т.к. можно нарваться на неприятности при удалении, объединении или переносе конструкций.

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

Pzz>>На Go есть смысл ссылаться потому, что это не какой-то там еще один язык программирования, а, в определенном смысле, работа над ошибками в языке Си.

M>Точно? А мне казалось, что какая-то херота типа питона

Ты ошибался. Go сделали те же люди, что сделали UNIX, C, Plan9, ...

И видно, что он сделан в том же комплексе идей.

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

F3V>Для чистоты нужно заменить точку с запятой на точку, точку на запятую, запятую на точку с запятой и разрешить пробелы в идентификаторах.

И восклицательные знаки там, где надо выругаться.

H>>

H>>if (i < 10);
H>>   print(i)
H>>

Pzz>В Go эта конструкция выглядит так:

Pzz>

Pzz>if i < 10 {
Pzz>    print(i)
Pzz>}
Pzz>

Pzz>Фигурные скобки обязательны. Тут уж одной точкой с запятой незаметно для себя логику не сломаешь.

Скобки ломают всю идею Scala, из которой Kotlin черпает вдохновение.
А там можно сделать вот так:

    var mf = 2;
    var i = if (mf == 1) 111 else 222

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

Pzz>>>На Go есть смысл ссылаться потому, что это не какой-то там еще один язык программирования, а, в определенном смысле, работа над ошибками в языке Си.

M>>Точно? А мне казалось, что какая-то херота типа питона

Pzz>Ты ошибался. Go сделали те же люди, что сделали UNIX, C, Plan9, ...

И что? Что мешает гошке быть херотой типа питона, кроме громких имён основателей?


Pzz>И видно, что он сделан в том же комплексе идей.

идеи, кк говорится, ничто, реализация — всё

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

Pzz>И восклицательные знаки там, где надо выругаться.

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

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

F3V>Для чистоты нужно заменить точку с запятой на точку, точку на запятую, запятую на точку с запятой и разрешить пробелы в идентификаторах.

Также однозначно необходима полная поддержка юникода, особенно в части пробельных символов

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

F3V>>Для чистоты нужно заменить точку с запятой на точку, точку на запятую, запятую на точку с запятой и разрешить пробелы в идентификаторах.

Pzz>И восклицательные знаки там, где надо выругаться.

Ну, "!!!" для ошибки времени канпеляции нормас вполне

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

F3V>>Для чистоты нужно заменить точку с запятой на точку, точку на запятую, запятую на точку с запятой и разрешить пробелы в идентификаторах.

M>Также однозначно необходима полная поддержка юникода, особенно в части пробельных символов

Конечно. Потом понадобятся ещё и полиморфные слова в идентификаторах.

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

F3V>>>Для чистоты нужно заменить точку с запятой на точку, точку на запятую, запятую на точку с запятой и разрешить пробелы в идентификаторах.

M>>Также однозначно необходима полная поддержка юникода, особенно в части пробельных символов

F3V>Конечно. Потом понадобятся ещё и полиморфные слова в идентификаторах.

composed/precomposed символы, без них никак

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

M>composed/precomposed символы, без них никак

что-то типа такого? язык Swift

let 💩 = "Что угодно!"
print(💩)

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

M>>composed/precomposed символы, без них никак

wl.>что-то типа такого? язык Swift
wl.>

wl.>let 💩 = "Что угодно!"
wl.>print(💩)
wl.>

Да, отличная идея. Раскладывать 💩 шки по коду

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

M>>>Также однозначно необходима полная поддержка юникода, особенно в части пробельных символов

F3V>>Конечно. Потом понадобятся ещё и полиморфные слова в идентификаторах.

M>composed/precomposed символы, без них никак

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

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

F3V>>>Конечно. Потом понадобятся ещё и полиморфные слова в идентификаторах.

M>>composed/precomposed символы, без них никак

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

Нет проблем. Ой, есть. Я хочу написать вызов my_cool_💩_func_с_пробелами. Я не знаю, какую говняшку вставить, говняшек же очень много сортов

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

F3V>>>>Конечно. Потом понадобятся ещё и полиморфные слова в идентификаторах.

M>>>composed/precomposed символы, без них никак

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

M>Нет проблем. Ой, есть. ... очень много сортов

Это не проблема, это всего лишь задача.

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

Pzz>>Ты ошибался. Go сделали те же люди, что сделали UNIX, C, Plan9, ...

M>И что? Что мешает гошке быть херотой типа питона, кроме громких имён основателей?

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

Например, в Go очень популярная штука — слайс. Они там почти всегда используются вместо массивов. Слайс — это срез с массива, их можно субслайсить, дописывать им в хвост (что может привести или не привести к реаллокации, в зависимости от наличия места в конце) и т.п. По природе своей они reference (в Go, как и в C, параметры всегда передаются по значению, но само значение может иметь семантику указателя на объект).

Так вот, субслайсы с одного массива, у них память-то общая. Но если дописывать в хвост, может случиться realloc, и тогда память разделится.

Или, например, из слайса легко сделать очередь. Push — дописываем в хвост, Pop — берём первый элемент и субслайсим остаток без первого элемента. Но только если так делать, занимаемая такой очередью память будет расти до бесконечности. Pop не освобождает первый элемент.

Как сишнику, мне это понятно и комфортно. Но вот питонист, боюсь, на этом свихнётся, если наткнётся.

Кстати, говорят, про это любят спрашивать на собеседованиях. Вероятно, народ массово на этом расшибает себе нос.

Pzz>>И видно, что он сделан в том же комплексе идей.

M>идеи, кк говорится, ничто, реализация — всё

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

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

Pzz>>И восклицательные знаки там, где надо выругаться.

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

Такой язык называется COBOL

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

M>>И что? Что мешает гошке быть херотой типа питона, кроме громких имён основателей?

Pzz>Ну, гошка не очень похожа на питон. Некоторые вещи там, совершенно очевидные сишнику, я не уверен, что питонист их вообще поймёт.

Что видел — питон один в один


Pzz>Например, в Go очень популярная штука — слайс. Они там почти всегда используются вместо массивов. Слайс — это срез с массива, их можно субслайсить, дописывать им в хвост (что может привести или не привести к реаллокации, в зависимости от наличия места в конце) и т.п. По природе своей они reference (в Go, как и в C, параметры всегда передаются по значению, но само значение может иметь семантику указателя на объект).

Не очень понятно, в питоне слайсы норм вроде


Pzz>Так вот, субслайсы с одного массива, у них память-то общая. Но если дописывать в хвост, может случиться realloc, и тогда память разделится.

Бывает, и чо?


Pzz>Или, например, из слайса легко сделать очередь. Push — дописываем в хвост, Pop — берём первый элемент и субслайсим остаток без первого элемента. Но только если так делать, занимаемая такой очередью память будет расти до бесконечности. Pop не освобождает первый элемент.

Андерлай контейнер меняется или нет? Если не меняется, то что меняется от синт сахара? Если меняется, то сколько это стоит?


Pzz>Как сишнику, мне это понятно и комфортно. Но вот питонист, боюсь, на этом свихнётся, если наткнётся.

Синтаксис, приятный и удобный, но делающй что-то другое — зло


Pzz>Кстати, говорят, про это любят спрашивать на собеседованиях. Вероятно, народ массово на этом расшибает себе нос.

Pzz>>>И видно, что он сделан в том же комплексе идей.

M>>идеи, кк говорится, ничто, реализация — всё

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


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

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

F3V>>нужно чтобы документация не расходилась с кодом,
F3V>>а потому код должен быть на языке документации.

Pzz>Такой язык называется COBOL

А должен быть великий и могучий.

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

Pzz>>Такой язык называется COBOL

F3V>А должен быть великий и могучий.

КОБОЛ был и на великом и могучем. Но читать его было не так удобно, как оригинал. Из-за падежных окончаний. Деталей не помню, мне больше с оригинальным дело иметь пришлось.

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

S>Kotlin посягнули на святое — сделали ";" не обязательной и даже не рекомендуемой, кода и так понятно что там должна стоять ; Якобы для чистоты кода.

S>Т.е. можно так:

S>

S>val a = 5;
S>val b = 10;
S>println(a + b);
S>

S>А можно и так:

S>

S>val a = 5
S>val b = 10
S>println(a + b)
S>

S>- компилятор не будет ругаться.

S>А вот тут уже обязательно:

S>

S>val a = 5; val b = 10; println(a + b)
S>

S>Т.е. по идее то же самое можно сделать для большинства других языков без особых доработок компилятора. Но стало ли чище?

S>Как вам идея?

Как без запяточки написать пустой оператор?

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

Q>Как без запяточки написать пустой оператор?

Так ее же не отменили — а просто там где компилятор и так может ее добавить — не нужно писать вручную. Там где компилятор не может достоверно определить — ; остается.

Здравствуйте, 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, а потом снова точку с запятой? Внешне выглядит совсем плохо. Без точки с запятой будет много изящнее и красивее.

Впрочем, никто от существующей кодовой базы на сегодняшних мейнстримных языках, конечно, не откажется в обозримом будущем. Более того, не все программисты могут воспринимать идеи из функционального программирования просто в силу своего типа характера (спросите Алису почему?). Поэтому точке с запятой еще многие лета!

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

S>Как вам идея?

Мне на практике Kotlin не зашёл (я работаю в области Enterprise), Java как была, так и остаётся идеальным языком для корпоративной разработки. Урезание синтаксиса имхо на пользу EE не идёт.

S>Kotlin посягнули на святое — сделали ";" не обязательной и даже не рекомендуемой, кода и так понятно что там должна стоять ; Якобы для чистоты кода.
Ну в Бейсике (даже не вижуал а Q и GW и прочих наверное тоже) так и было, но только не ; а :
Так что все уже придумано до этих ваших котлина и го

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

D>... Более того, не все программисты могут воспринимать идеи из функционального программирования просто в силу своего типа характера (спросите Алису почему?)

Функциональный стиль контр-интуитивен, а императивный стиль наоборот — интуитивен. Империтив — это порядок шагов (порядок шагов, чтобы достать банан), это максимально понятный прямолинейный способ.
Именно виду контр-интуитивности не все программисты и могут, и это нормально. А функциональщина — это ненормально, это искривление естественного мышления.

Наличие разделителя снижает когнитивную нагрузку, а его отсутствие — увеличивает, т.к. челвоек вынужден на каждой строке анализировать, является ли это окончанием всего выражения или нет.

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

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

D>>... Более того, не все программисты могут воспринимать идеи из функционального программирования просто в силу своего типа характера (спросите Алису почему?)

G>Функциональный стиль контр-интуитивен, а императивный стиль наоборот — интуитивен. Империтив — это порядок шагов (порядок шагов, чтобы достать банан), это максимально понятный прямолинейный способ.
G>Именно виду контр-интуитивности не все программисты и могут, и это нормально. А функциональщина — это ненормально, это искривление естественного мышления.

G>Наличие разделителя снижает когнитивную нагрузку, а его отсутствие — увеличивает, т.к. челвоек вынужден на каждой строке анализировать, является ли это окончанием всего выражения или нет.

А я и не буду спорить с тобой, потому что для тебя это может быть чистой правдой.

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

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

Значит, я ценю в этом предсказуемость и надежность. А есть еще люди, которым нравится просто сама (математическая) концепция — они просто тащатся от нее.

Мы все разные. Кому-то действительно императивный стиль ближе, где расписано все по шагам, по правилам — как они сами и думают в обычной жизни. Кому-то ближе функциональный стиль. И это абсолютно нормально и естественно

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

D>Значит, я ценю в этом предсказуемость и надежность. А есть еще люди, которым нравится просто сама (математическая) концепция — они просто тащатся от нее.

D>Мы все разные. Кому-то действительно императивный стиль ближе, где расписано все по шагам, по правилам — как они сами и думают в обычной жизни. Кому-то ближе функциональный стиль. И это абсолютно нормально и естественно

Кстати говоря, все это чистой воды словестная эквилибристика до тех пор пока стороны не договорятся о каких именно задачах в каких областях идет речь. Потому что один может считать проценты по деривативам в рамках ETL, а другой -- чтением/записи портов ввода-вывода в драйверах ОС.

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

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

Оно, конечно, так. Но великий и могучий у каждого свой. Мне в эпоху перфокарт и IEBUPDTE пришлось разбираться с грузинским

Автор: Privalov
Дата: 08.09.05

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-ад), максимально скрыв сам пошаговый императивный способ получения результата. В идеале в функциональной программе вообще не должно быть ни слова про шаги получения результата.

Ты хотел сказать "функциональный стиль мышления"? За всех говорить не будем. Функциональное программирование нравится очень разным людям.

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

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

Без функционального программирования у меня бы не получилось такого результата

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

S>Kotlin

не нужен

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

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

P>Оно, конечно, так. Но великий и могучий у каждого свой. Мне в эпоху перфокарт и IEBUPDTE пришлось разбираться с грузинским

Автор: Privalov
Дата: 08.09.05

PL/1.
P>Да, а в эпоху глобализации мне пришлось однажды объяснять индусу, что такое stroka.

Но позвольте, если великий и могучий у каждого свой, то зачем нужна глобализация?
Разве на по этой причине великий и могучий отменяется глобализацией так или иначе?

P>В эпоху продвинутых IDE имена типа s1, s2, s2a, d1 везде, а также суровый матан на Фортране перестали напрягать. Как и Бейсик на Искре-226 с его двухсимвольными идентификаторами.

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

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

F3V>>На мой взгляд, лучше работать в модели языка и терминах великого и могучего.

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

G>Функциональный стиль контр-интуитивен, а императивный стиль наоборот — интуитивен. Империтив — это порядок шагов (порядок шагов, чтобы достать банан), это максимально понятный прямолинейный способ.
G>Именно виду контр-интуитивности не все программисты и могут, и это нормально. А функциональщина — это ненормально, это искривление естественного мышления.

Это синдром утёнка. Если бы вас учили в универе на Haskell, а не С++, вы бы сказали иначе.
Вот так думает компьютер.

void sign(const auto& docs) {
    for(int i = 0; i < docs.size(); ++i) {
        const auto& doc = docs[i];
        sign(doc);
    }
}

А так думает человек:

signDocuments :: [String] -> [String]
signDocuments [] = []
signDocuments (doc:rest) = sign doc : signDocuments rest

У ФП хватает минусов, но не надо притягивать за уши несуществующие.

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

F3V>Но позвольте, если великий и могучий у каждого свой, то зачем нужна глобализация?

Зачем нужна — скажем, не знаю. Но у того же Microsoft офисы по всему шарику разбросаны.

F3V>Разве на по этой причине великий и могучий отменяется глобализацией так или иначе?

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

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

Явно вы никогда не пробовали разбирать текст программы по километровой распечатке. Для той эпохи 2500 строк на PL/1 — это до фига.

F3V>>>На мой взгляд, лучше работать в модели языка и терминах великого и могучего.

Который устраивает всех разработчиков, находящихся и в Рейкьявике, и в Льеже, и в Антананариву, и в Абакане.

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

SP>А так думает человек:
SP>

SP>signDocuments :: [String] -> [String]
SP>signDocuments [] = []
SP>signDocuments (doc:rest) = sign doc : signDocuments rest
SP>

SP>У ФП хватает минусов, но не надо притягивать за уши несуществующие.

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

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

F3V>>Разве на по этой причине великий и могучий отменяется глобализацией так или иначе?

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

И было очевидно, ведь вы в противоположном окопе:
язык — это форма (слова) и содержание (смыслы, способ описания реальности).
Тут при одинаковой форме есть конфликт содержаний.

Т.е. исходное утверждение верно, но уточню его, хотя это тоже очевидно:

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

ПС: Для правильного разбора тут понадобится парсер КЗ грамматики или выше

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

S_S>Я бы предпочел, чтобы в файлах ";" была, но чтобы текстовый редактор ее не показывал, где не надо. Чтобы задавалось в персональных настройках редактора.
S_S>Тоже самое с блоками "{}", автоматически скрывать, если и по отступам видно. Редактор VS все равно рисует линию перед блоком, поэтому сами "{}" уже не нужны.

Я вот потому фаром до сих пор и пользуюсь для всего, потому что умники IDE-пейсатели понапридумывают улучшений для меня, причем в каждой IDE свои, а я пехайся потом с этим

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

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

Pzz>>>На Go есть смысл ссылаться потому, что это не какой-то там еще один язык программирования, а, в определенном смысле, работа над ошибками в языке Си.

M>>Точно? А мне казалось, что какая-то херота типа питона

Pzz>Ты ошибался. Go сделали те же люди, что сделали UNIX, C, Plan9, ...

Pzz>И видно, что он сделан в том же комплексе идей.

Только сборщик мусора не в тему.

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

Pzz>Так вот, субслайсы с одного массива, у них память-то общая. Но если дописывать в хвост, может случиться realloc, и тогда память разделится.

Разве не п...ц?

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

Pzz>>И видно, что он сделан в том же комплексе идей.

D>Только сборщик мусора не в тему.

А Пайк считает, что ошибкой было не сделать сборщика мусора в Си.

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

D>>Только сборщик мусора не в тему.

Pzz>А Пайк считает, что ошибкой было не сделать сборщика мусора в Си.

А можно цитату из Пайка с этим мнением?

Так-то, конечно, было бы любопытно узнать чем бы закончилась попытка переписать ядро Unix-а на этот гипотетический "Си со сборщиком мусора" на 16-битовом PDP-11. Но есть подозрение, что ничем.

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

Pzz>Ну не знаю. Я так не думаю. Скорее, я думаю, как в первом примере. Если мне надо заколотить дцать гвоздей, я возьму молоток и заколочу их по очереди, а не заколочу один и передам остаток работы себе, рекурсивно вызванному.

наверное вы

• запоминаете номер текущего гвоздя
• проверяете, что этот номер не больше -дцати
• отсчитываете нужный гвоздь (причём считаете и уже забитые гвозди!)
• после приколачивания прибавляете к номеру гвоздя единицу

Думаю, всё таки нет. Вы берёте пачку гвоздей. Если пачка пуста, процесс завершаете. Иначе берёте первый гвоздь, приколачиваете и с оставшимися возвращаетесь в начало (рекурсия!).
Всё дело в привычке. Вы уже подсознательно воспринимаете for(int i = 0...) за прохождение по всем элементам. И не обращаете внимания сколько фигни с точки зрения человека происходит.

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

SP>Думаю, всё таки нет. Вы берёте пачку гвоздей. Если пачка пуста, процесс завершаете. Иначе берёте первый гвоздь, приколачиваете и с оставшимися возвращаетесь в начало (рекурсия!).

Рискну предположить, что для обычного человека все-таки был бы более привычен алгоритм, описанный вот в такой императивной форме:

пока (есть гвозди) и (не все еще прибито):
  взять очередной гвоздь;
  забить взятый гвоздь;

Без рекурсии.

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

SP>>У ФП хватает минусов, но не надо притягивать за уши несуществующие.
Pzz>Ну не знаю. Я так не думаю. Скорее, я думаю, как в первом примере. Если мне надо заколотить дцать гвоздей, я возьму молоток и заколочу их по очереди, а не заколочу один и передам остаток работы себе, рекурсивно вызванному.

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

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

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

Pzz>>А Пайк считает, что ошибкой было не сделать сборщика мусора в Си.

S>А можно цитату из Пайка с этим мнением?

Можно.

http://herpolhode.com/rob/ugly.pdf

14-я страница (на самом слайде написано 13).

Languages

C is well understood and has aged surprisingly gracefully. (Good)
Still it’s not very modern: (Bad)
— No garbage collection
— No string handling!

And it has some horrible mistakes: (Ugly)
— The preprocessor
— Conditional compilation

S>Так-то, конечно, было бы любопытно узнать чем бы закончилась попытка переписать ядро Unix-а на этот гипотетический "Си со сборщиком мусора" на 16-битовом PDP-11. Но есть подозрение, что ничем.

Мне бы тоже было бы это любопытно узнать.

С одной стороны, был LISP и он был garbage-collected и работал и на машинках послабее той PDP-ки.

С другой стороны, сама по себе идея написать ядро ОС на языке высокого уровня, а не на ассемблере, как Богом заведено, вызывала насмешки.

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

SP>Думаю, всё таки нет. Вы берёте пачку гвоздей. Если пачка пуста, процесс завершаете. Иначе берёте первый гвоздь, приколачиваете и с оставшимися возвращаетесь в начало (рекурсия!).

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

Кстати, обычно задача по вбиванию гвоздей имеет целью не потратить все гвозди из пачки, а вбить гвозди во все места, в которых они нужны. И да, я эти места размечаю и иду по порядку. Это скорее for ... range, чем for i = 0; i < N; i ++.

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

Pzz>>>А Пайк считает, что ошибкой было не сделать сборщика мусора в Си.

S>>А можно цитату из Пайка с этим мнением?

Pzz>Можно.

Pzz>http://herpolhode.com/rob/ugly.pdf

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

Pzz>

Pzz>Still it’s not very modern: (Bad)
Pzz>- No garbage collection

Это сейчас плохо то, что Си без сборщика мусора (следовательно не шибко современный).
Из этого, что есть сейчас, не следует, что "не сделать сборщик мусора в Си" было ошибкой.

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

Pzz>>

Pzz>>Still it’s not very modern: (Bad)
Pzz>>- No garbage collection

S>Это сейчас плохо то, что Си без сборщика мусора (следовательно не шибко современный).
S>Из этого, что есть сейчас, не следует, что "не сделать сборщик мусора в Си" было ошибкой.

Хорошо, принимаю эту поправку.

Кабы то ни было, по мнению Пайка сборщик мусора в Си не был бы лишним.

P.S. В гошечке я бы хотел иметь функции unsafe.Malloc/unsafe.Free для тех редких случаев, когда сборщик мусора скорее мешает, чем наоборот. И чтобы на выделяемую ими память сборщик мусора не зарился (в идеале, чтобы указатели на эту память его не тормозили).

Я понимаю, что можно сделать самодельный из C.malloc/C.free, но сразу появится CGo overhead...

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

Pzz>Кабы то ни было, по мнению Пайка сборщик мусора в Си не был бы лишним.

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

По моему мнению, например, в современном мире лишним является сам Си. И чем меньше софта будет писаться на Си (с переходом на C++ и/или Rust), тем лучше. Но это мое личное заблуждение мнение.

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

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

G>Если уж пошла такая пьянка, то сознание работает вообще не так. Сознание — это квантовый компьютер (см. недавние подтверждения микротрубочек у достаточно старой маргинальной гипотезы Пенроуза/Хомского о квантовой природе сознания). Таким образом, квантовый компьютер в нашей голове строит реальные параллельные ветки вселенной, в каждой из которых проигрываются разные варианты событий. Затем мозг через механизм связи параллельных вселенных (например, интерференция одиночной частицы со своими версиями из параллельных вселенных — пример такой меж-вселенской связи), способом, аналогичным методу бесконтактных измерений Элицура-Вайдмана (метод определения рабочих взрывателей бомбы путём её подрыва в параллельной вселенной) собирает результаты таких прогонов и тем самым позволяет предсказать последствия действий. После чего мозг выбирает оптимальный с его точки зрения "маршрут" в самой привлекательной версии порождённых вселенных, остальные порожденные вселенные живут далее (или погибают, если проверка гипотезы была злодейская, например, злодей продумывает варианты уничтожения вселенной).
G>Из всего этого следует, что квантовое программирование — самый точный способ передать способ мысли человека.

Это называется "многовариантностью мышления". Это только у творческих людей так (к ним относится большинство программистов). У других людей совсем не так

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

Аналогия с квантовым компьютером мне очень понравилась. Не задумывался ранее

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

D>Аналогия с квантовым компьютером мне очень понравилась. Не задумывался ранее

Да. Парадоксально, но дешевле всего для решения задачи именно сгенерировать параллельные вселенные, чем обеспечить симуляцию вариантов на архитектуре фон неймана в одной вселенной. Генерация мульти-вселенных — это самый дешёвый и даже "обыденный" процесс. Каждая мини-радуга на стене от солнечного окна — это на самом деле ансамбль мульти-вселенных, взаимодействующих друг с другом через механизм интерференции, и это всё истинно параллельно. А для построения симуляции фон неймана нужно описать императив, прогнать его последовательно (или параллельно, но с издержками синхронизации).
Вопрос лишь за тем, чтобы дождаться удешевления квантового компьютинга и развития соотв. методик и языков.

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

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

D>>Аналогия с квантовым компьютером мне очень понравилась. Не задумывался ранее

G>Да. Парадоксально, но дешевле всего для решения задачи именно сгенерировать параллельные вселенные, чем обеспечить симуляцию вариантов на архитектуре фон неймана в одной вселенной. Генерация мульти-вселенных — это самый дешёвый и даже "обыденный" процесс. Каждая мини-радуга на стене от солнечного окна — это на самом деле ансамбль мульти-вселенных, взаимодействующих друг с другом через механизм интерференции, и это всё истинно параллельно. А для построения симуляции фон неймана нужно описать императив, прогнать его последовательно (или параллельно, но с издержками синхронизации).
G>Вопрос лишь за тем, чтобы дождаться удешевления квантового компьютинга и развития соотв. методик и языков.

У тебя получилась очень точная метафора, но я могу судить об этом только умозрительно на основании прочитанных мною книг и статей, потому что у меня самого с мновариантностью туговато многовариантность несколько ограничена

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

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

D>>>Аналогия с квантовым компьютером мне очень понравилась. Не задумывался ранее

G>>Да. Парадоксально, но дешевле всего для решения задачи именно сгенерировать параллельные вселенные, чем обеспечить симуляцию вариантов на архитектуре фон неймана в одной вселенной. Генерация мульти-вселенных — это самый дешёвый и даже "обыденный" процесс. Каждая мини-радуга на стене от солнечного окна — это на самом деле ансамбль мульти-вселенных, взаимодействующих друг с другом через механизм интерференции, и это всё истинно параллельно. А для построения симуляции фон неймана нужно описать императив, прогнать его последовательно (или параллельно, но с издержками синхронизации).
G>>Вопрос лишь за тем, чтобы дождаться удешевления квантового компьютинга и развития соотв. методик и языков.

D>У тебя получилась очень точная метафора, но я могу судить об этом только умозрительно на основании прочитанных мною книг и статей, потому что у меня самого с мновариантностью туговато

Я сам пришёл в эту тему с изучения проблематики синхронности в типовой архитектуре фон неймана (книги по java concurrency), и потом по книге "квантовые вычисления для айтишников" и по книге "структура реальности" дойча (одного из отцов квантового компьютинга), которую мне подсказали на этом форуме несколько лет назад.

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

Я не имею ничего против функциональщины как очередного около-академического загона, тем более на нём построен реактивный стэк, но только к месту (например, как higload/gateway микросервис). На мой взгляд, основная проблема как раз в том, что типовые корпоративные приложения, где я в основном работаю, нет смысла делать на таком сложном стэке, т.к. этот стэк контринтуитивен (по опыту, вижу как разрабы, даже опытные, пытаются его освоить и применять), и если одна успешная команда "академиков" напишет тебе истинно функциональный код, но потом на поддержку придут джуны/мидлы, которые не сильно шарят в этой теме, то они начнут дописывать такой код уже в "псевдо-функциональном" стиле и сидеть над элементарным багфиксом месяцами, тупо из-за того, что функциональный код "не понятен".
Чтобы функциональщина стала полезной, нужно, чтобы типовой разработчик с рынка этими методами владел, а это пока далеко не так.
А писать в функциональном стиле сложную бизнес-логику типового enterprise-приложения, при том, что разрабы сменяют друг друга каждые полгода — это антиутопия.
Функциональщина больше годится в сфере научного труда, как и прочие методики, типа DSL (например, IntelliJ MPS, которые прекрасны в теории, но ужасны на практике). Ну может немного на фронте, т.к. фронт по своей природе реактивен.

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

G>Я не имею ничего против функциональщины как очередного около-академического загона, тем более на нём построен реактивный стэк, но только к месту (например, как higload/gateway микросервис). На мой взгляд, основная проблема как раз в том, что типовые корпоративные приложения, где я в основном работаю, нет смысла делать на таком сложном стэке, т.к. этот стэк контринтуитивен (по опыту, вижу как разрабы, даже опытные, пытаются его освоить и применять), и если одна успешная команда "академиков" напишет тебе истинно функциональный код, но потом на поддержку придут джуны/мидлы, которые не сильно шарят в этой теме, то они начнут дописывать такой код уже в "псевдо-функциональном" стиле и сидеть над элементарным багфиксом месяцами, тупо из-за того, что функциональный код "не понятен".
G>Чтобы функциональщина стала полезной, нужно, чтобы типовой разработчик с рынка этими методами владел, а это пока далеко не так.
G>А писать в функциональном стиле сложную бизнес-логику типового enterprise-приложения, при том, что разрабы сменяют друг друга каждые полгода — это антиутопия.
G>Функциональщина больше годится в сфере научного труда, как и прочие методики, типа DSL (например, IntelliJ MPS, которые прекрасны в теории, но ужасны на практике). Ну может немного на фронте, т.к. фронт по своей природе реактивен.

Если ты джавист, то функциональщиной можно назвать Stream API. Я перестал использовать джаву до того, как там появилось это API. Но поиск в яндексе показывает, что это оно.

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

Еще похожие идеи часто внедряются в языки под видом асинхронных вычислений. Иногда в стиле близком к ФП, иногда — нет.

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

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

S>По моему мнению, например, в современном мире лишним является сам Си. И чем меньше софта будет писаться на Си (с переходом на C++ и/или Rust), тем лучше. Но это мое личное заблуждение мнение.

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

Rust выглядит прикольным, но на мой взгяд, слишком уж переусложнён. И от восклицательных знаков в глазах рябит. Напоминает чем-то конфиг sendmail-а.

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

S>Кто-то будет писать ; а кто-то скажет что это лишнее. Начнется новый холивар, еще похлеще пробелы vs табы, возможно дойдет до кровопролития в отдельных случаях.

Пайка на вас нет. Он бы вам показал фашистский концлагерь. Как велел бы расставлять знаки препинания, так бы и расставляли, и никаких гражданских свобод и свободы самовыражения.

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

D>И заметь одну важную вещь. Почти нигде в документации в подобных случаях не указывают на прямую связь ФП. Если тебе напишут, что Java Stream — это моноид, то тебе такое понравится?

А как ответить на такой вопрос: если из этого моноида вызвать транзакционный jpa-код, к какому треду и связанному с каким тредом и tx-менеджером его соотнесет EE-фреймворк, от этого ведь будет зависеть логика коммита/отката? И вообще, этот моноид исполняется на треде реквеста или на вторичном треде из некоего пула? А этот пул какой вместимости? Не станет ли он узким местом? А с секьюрностью что будет, если секьюрити контекст с авторизацией привязан к треду реквеста, он што, потеряется и тред моноида будет выполняться анонимно? Значит, код моноида подвержен атакам? Секьюрность контекста у моноида вообще можно обеспечить гарантией java sdk, как у классического threadlocal, или это обеспечивается лишь псевдо-гарантией на уровне самописных реактивных библиотек? А шо там у моноидов с OneToMany/ManyToMany? Не поддерживается, и нужно вручную реализовывать? Надо же, какая досада, но зато функционально! А шо там у них с пробросом эксепшнов? А стектрейс человеческий (кто это когда и с чем по цепочке вызвал) можно посмотреть без установки в ide спец-приблуд? Нельзя, но зато функционально!
Столько вопросов, столько рисков, это же не просто голые computation, может надёжнее не открывать эту кротовую нору и писать enterprise-код в общепринятом процедурном стиле с анемичной моделью?

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

S>Это чисто фишка C — строго ; и строгость в больших/маленьких буквах.

А почему везде ; надо, а после закрывающей фигурной скобки не надо?

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

D>Кстати, таким людям обычно нравится функциональное программирование. Их вдохновляет сама красота математических абстракций, а в абстракциях они разбираются просто превосходно. Это так, к слову. Ты попробуй! Может быть, и тебе тоже понравится?

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

Когда я вижу слишком абстрактную абстракцию, меня всё время не покидает чувство, что где-то на каком-то уровне меня обязательно на@&ут, и из красивой математической абстракции вылезет какая-нибудь неучтённая деталь реализации, которую я знать вроде как не должен, но которая обязательно подкрадётся и укусит исподтишка, когда не ждёшь.

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

S>>По моему мнению, например, в современном мире лишним является сам Си. И чем меньше софта будет писаться на Си (с переходом на C++ и/или Rust), тем лучше. Но это мое личное заблуждение мнение.

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

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

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

Pzz>Мне очень неуютно и трудно программировать, если я не могу разобрать красоту математической абстракции до самых её корней

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

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

Pzz>Когда я вижу слишком абстрактную абстракцию, меня всё время не покидает чувство, что где-то на каком-то уровне меня обязательно на@&ут, и из красивой математической абстракции вылезет какая-нибудь неучтённая деталь реализации, которую я знать вроде как не должен, но которая обязательно подкрадётся и укусит исподтишка, когда не ждёшь.

То ли дело чистая императивщина на теплой ламповой Сишечке:

    if (finding->name != NULL) {
        device->mdns_name = str_dup(finding->name);
    }

Вот прямо очевидно, что str_dup, если повезет, приведет к логированию и вызову abort.

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

SP>наверное вы
SP>

SP>• запоминаете номер текущего гвоздя
SP>• проверяете, что этот номер не больше -дцати
SP>• отсчитываете нужный гвоздь (причём считаете и уже забитые гвозди!)
SP>• после приколачивания прибавляете к номеру гвоздя единицу
SP>

SP>Думаю, всё таки нет. Вы берёте пачку гвоздей. Если пачка пуста, процесс завершаете. Иначе берёте первый гвоздь, приколачиваете и с оставшимися возвращаетесь в начало (рекурсия!).
SP>Всё дело в привычке. Вы уже подсознательно воспринимаете for(int i = 0...) за прохождение по всем элементам. И не обращаете внимания сколько фигни с точки зрения человека происходит.

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

void sign(const auto& docs) {
    for(const auto& doc : docs) {
        sign(doc);
    }
}

Тогда приведённый выше список упрощается:

• Забить каждый гвоздь

И это всё ещё императивный стиль!

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

S>То ли дело чистая императивщина на теплой ламповой Сишечке:
S>

S>    if (finding->name != NULL) {
S>        device->mdns_name = str_dup(finding->name);
S>    }
S>

Ну это, вообще-то, идеоматично для сишных программ для современного UNIX: паниковать при невозможности выделить память.

А что еще можно сделать? Собственно, даже и этого можно не делать по большому счёту. malloc не вернёт NULL. Он выделит какое-то место в адресном пространстве и вернёт его адрес, а при первом обращении система не найдёт свободной странички и пришлёт SIGSEGV или SIGBUS (если OOM Killer не пришлёт раньше SIGKILL).

Ну уж я и не говорю о том, что соответствующее поведение документированно в комментарии к mem_resize.

P.S. Этот код, кстати, внимательно просматривали специально обученные люди из RedHat, Canonical и Google. Все возникающие вопросы мы с ними обсудили и пришли к консенсусу. Не говоря уж о нескольких десятках контрибьютеров.

Так что неудачный заход, увы.

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

Pzz>Ну это, вообще-то, идеоматично для сишных программ для современного UNIX: паниковать при невозможности выделить память.

Pzz>Так что неудачный заход, увы.

Я давно подозревал, что ваша критика C++ она не от большого ума, а совершенно наоборот. И это "наоборот" подтверждается тем, что вы как-то странно воспринимаете информацию. То вы в словах Пайка увидели то, что он назвал ошибкой отсутствие сборщика мусора в GC. Теперь вот в том, что я написал, обнаружили что-то свое.

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

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

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

D>>И заметь одну важную вещь. Почти нигде в документации в подобных случаях не указывают на прямую связь ФП. Если тебе напишут, что Java Stream — это моноид, то тебе такое понравится?

G>А как ответить на такой вопрос: если из этого моноида вызвать транзакционный jpa-код, к какому треду и связанному с каким тредом и tx-менеджером его соотнесет EE-фреймворк, от этого ведь будет зависеть логика коммита/отката? И вообще, этот моноид исполняется на треде реквеста или на вторичном треде из некоего пула? А этот пул какой вместимости? Не станет ли он узким местом? А с секьюрностью что будет, если секьюрити контекст с авторизацией привязан к треду реквеста, он што, потеряется и тред моноида будет выполняться анонимно? Значит, код моноида подвержен атакам? Секьюрность контекста у моноида вообще можно обеспечить гарантией java sdk, как у классического threadlocal, или это обеспечивается лишь псевдо-гарантией на уровне самописных реактивных библиотек? А шо там у моноидов с OneToMany/ManyToMany? Не поддерживается, и нужно вручную реализовывать? Надо же, какая досада, но зато функционально! А шо там у них с пробросом эксепшнов? А стектрейс человеческий (кто это когда и с чем по цепочке вызвал) можно посмотреть без установки в ide спец-приблуд? Нельзя, но зато функционально!
G>Столько вопросов, столько рисков, это же не просто голые computation, может надёжнее не открывать эту кротовую нору и писать enterprise-код в общепринятом процедурном стиле с анемичной моделью?

Если честно, то я немногие слова разобрал. Но скажу так, что транзакции, пул потоков и исключения (даже бывают асинхронные исключения) в полном достатке присутствуют и в функциональных языках, например, в Haskell. Они же сбоку. Идее о композиции вычислений не противоречат.

В программировании часто нет такого водораздела, что здесь, мол, функциональное программирование, а вот здесь идет уже императивное.

Ты летал на самолете на высоте 10 километров при смене дня и ночи? Там будет такое явление, как "терминатор", когда день и ночь поделили ровно словно масло ножом. Но на самой земле свет рассеивается, и такой жесткой границы нет. Так и нет жесткой границы между функциональным стилем и императивным. Более того, их по-моему даже часто неправильно противопоставлять друг другу. Это как есть профиль и анфас лица человека. Лицо человека — это как задача программирования, а смотрим мы на нее сбоку или прямо — саму задачу не особо-то и меняет. Просто могут быть разные пути решения для достижения одной цели. Так, и функциональное программирование и императивное — это иногда разные пути достижения одной цели. Часто они даже работают в тандеме.

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

Ты так не дели мир на черное и белое! Все куда сложнее и проще одновременно

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

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

Есть-то есть, но через одно место. Например, в реактивном стэке Spring Reactor/Webflux стримы выполняются на небольшом кол-ве системных тредов, т.е. сами реактивные стримы не многопоточны, поэтому если разработчик выполняет любую блокирующую операцию на стриме неправильно ("неправильно" — это обычным вызовом блокируюшей операции), то он блочит весь стрим, т.е. блочит все сотни других и превращает высоконагруженный скоростной стрим в узкое место.
А блокирующие операции — это чуть ли не 90% всех БД и интеграционных операций — вызовы REST API, вызовы к файловой системе, работа с БД, даже просто поставить паузу через Thread.sleep. И поэтому реактивщина тянет за собой целый ворох специфики — чтобы работать с БД в неблокирующем стиле, нужен реактивный jdbc-драйвер, чтобы работать в неблокирующем стиле с REST API, нужен особый неблокирующий REST API-клиент, чтобы работать в неблокирующем стиле с входящими веб-запросами, нужен особый неблокирующей веб-сервер. В общем, это полностью новый мир со своими правилами, и многие из этих библиотек ещё сырые (например, в реактивном JPA, насколько знаю, до сих пор не реализованы OneToMany/ManyToMany), реактивный сервер netty имеет баги и утечки (сам лично находил), т.е. я бы сказал, что для корпоративной разработки функциональщина и реактивщина ещё не "дозрели" и остаются либо вотчиной "академиков", либо хайлоада, где имеет смысл жертвовать в угоду хайлоаду (типа простейших микросервисов гейтвеев), но желательно, чтобы бизнес-логики на функциональщине было написано минимум, потому что попытка писать на ней сложную бизнес логику приводит к миллиону не-императивных функциональных конструкций, в которых потом никто, даже сам автор, разобраться не в силах, и случайно посадить в этом нагромождении баг проще простого, например вставив куда-нибудь блокирующую операцию, что превращает всё это великолепное нагромождение функциональных операторов в тыкву.

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

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

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

G>Есть-то есть, но через одно место. Например, в реактивном стэке Spring Reactor/Webflux стримы выполняются на небольшом кол-ве системных тредов, т.е. сами реактивные стримы не многопоточны, поэтому если разработчик выполняет любую блокирующую операцию на стриме неправильно ("неправильно" — это обычным вызовом блокируюшей операции), то он блочит весь стрим, т.е. блочит все сотни других и превращает высоконагруженный скоростной стрим в узкое место.
G>А блокирующие операции — это чуть ли не 90% всех БД и интеграционных операций — вызовы REST API, вызовы к файловой системе, работа с БД, даже просто поставить паузу через Thread.sleep. И поэтому реактивщина тянет за собой целый ворох специфики — чтобы работать с БД в неблокирующем стиле, нужен реактивный jdbc-драйвер, чтобы работать в неблокирующем стиле с REST API, нужен особый неблокирующий REST API-клиент, чтобы работать в неблокирующем стиле с входящими веб-запросами, нужен особый неблокирующей веб-сервер. В общем, это полностью новый мир со своими правилами, и многие из этих библиотек ещё сырые (например, в реактивном JPA, насколько знаю, до сих пор не реализованы OneToMany/ManyToMany), реактивный сервер netty имеет баги и утечки (сам лично находил), т.е. я бы сказал, что для корпоративной разработки функциональщина и реактивщина ещё не "дозрели" и остаются либо вотчиной "академиков", либо хайлоада, где имеет смысл жертвовать в угоду хайлоаду (типа простейших микросервисов гейтвеев), но желательно, чтобы бизнес-логики на функциональщине было написано минимум, потому что попытка писать на ней сложную бизнес логику приводит к миллиону не-императивных функциональных конструкций, в которых потом никто, даже сам автор, разобраться не в силах, и случайно посадить в этом нагромождении баг проще простого, например вставив куда-нибудь блокирующую операцию, что превращает всё это великолепное нагромождение функциональных операторов в тыкву.

Если ты про async-await, то в языках типа C# и F# весь IO должен быть явно определен в терминах асинхронных вычислений. Это ограничение метода реализации.

С другой стороны, в том же Haskell все стандартные операции IO внутри рантайма являются неблокирующими (асинхронными) через select/poll/epoll. И это делается прозрачно для пользователя за счет зеленых потоков. Код пишется как обычно, то есть, якобы как синхронный, но на деле он — асинхронный. Я так понимаю, что в тех же Go и Erlang ситуация похожая (вот, не смог себя заставить до конца прочитать учебник по Go этим летом)

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

Pzz>Например, в Go очень популярная штука — слайс. Они там почти всегда используются вместо массивов. Как сишнику, мне это понятно и комфортно. Но вот питонист, боюсь, на этом свихнётся, если наткнётся.

Слайсы — совершенно очевидная вещь: https://habr.com/ru/articles/89456/

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

S>>Кто-то будет писать ;
GIV>Не будет. И холиваров нет.

Да помню споры с разработчиками на Scala:
— Это можно писать вот так.
— Одерски так не пишет!!!

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

S>Но в JS так же ; не обязательна. Пишут и так и эдак. В бейсике тоже не требовалась ;

Из за этого там есть грабли типа:

console.log((function () {
    return
        "Oops!";
})());

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

S>>Это чисто фишка C — строго ; и строгость в больших/маленьких буквах.
Pzz>А почему везде ; надо, а после закрывающей фигурной скобки не надо?

Символ } служит окончанием блока инструкций, это аналог символа ; в конце одной инструкции.

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

Pzz>>Например, в Go очень популярная штука — слайс. Они там почти всегда используются вместо массивов. Как сишнику, мне это понятно и комфортно. Но вот питонист, боюсь, на этом свихнётся, если наткнётся.

A>Слайсы — совершенно очевидная вещь: https://habr.com/ru/articles/89456/

В Питоне:

s=[1,2,3,4,5]
a=s[2:4]
b=s[2:4]
a[0]=888
print(a)
print(b)

Напечатает:

[888, 4]
[3, 4]

А в Go оба раза напечатает [888, 4]

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

Q>>Как без запяточки написать пустой оператор?
S>Так ее же не отменили — а просто там где компилятор и так может ее добавить — не нужно писать вручную. Там где компилятор не может достоверно определить — ; остается.

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

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

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

D>>Кстати, таким людям обычно нравится функциональное программирование. Их вдохновляет сама красота математических абстракций, а в абстракциях они разбираются просто превосходно. Это так, к слову. Ты попробуй! Может быть, и тебе тоже понравится?

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

Pzz>Когда я вижу слишком абстрактную абстракцию, меня всё время не покидает чувство, что где-то на каком-то уровне меня обязательно на@&ут, и из красивой математической абстракции вылезет какая-нибудь неучтённая деталь реализации, которую я знать вроде как не должен, но которая обязательно подкрадётся и укусит исподтишка, когда не ждёшь.

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

И потом, мы не во всем сильны. Так просто не бывает. Обычно те, кто углубляется в детали, — те обычно не видят общей картины. И наоборот, кто может видеть общую картину, — те обычно второстепенные детали упускают. Вместе обе штуки не работают одновременно. Наверное, нет на свете таких людей, кто мог бы одновременно и видеть целое, видеть всю систему, и при этом вникать до мелочей в каждую деталь... Это фантастика.

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

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

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

M>Ну, "!!!" для ошибки времени канпеляции нормас вполне
Нет, это ругательства за женским авторством. Там где мальчикам достаточно одного, девочки используют не менее трёх.