Здравствуйте, Quintanar, Вы писали:
Q>С чего она увяла? Наоборот, изменяемость языка одна из очень мощных и интересных фич. И трудности синтаксического анализа не сильно мешают. Ну в самом деле, какие могут быть трудности с анализом в Лиспе?
Имхо, в основном, под трудностями Вирт подразумевал трудности воспрятия подобных вещей программистом, а не транслятором. Учитывая, что на Лиспе программируют гораздо меньше, чем на C/C++/Java/C# с этим сложно не согласиться.
Q>Ну-ну. Только лучший язык со встроенным параллелизмом в данное время функциональный Erlang, а объектно-ориентированных языков что-то не видно.
А почему параллелизм должен быть встроенным в язык? Думаю, что программ, использующих распараллеливание работы, и написанных на C++/Java гораздо больше, чем на Erlange-е. Вот, один пример
).
Д>просто их время пришло только сейчас. Раньше технологии были недостаточно зрелы, чтобы обеспечить достаточное удобство в их применении.
Имхо, здесь будет классический пример развития истории по спирали. В очередной раз попробуют DSL (на новом уровне развития технологии), поймут, что ничего хорошего не вышло. Забудут лет на ...надцать. Затем опять поробуют на новом уровне развития техники и т.д.
Д>как всё-таки удивительно узнать, что возможность переложить часть работы по распараллеливанию программ на компилятор — это "минимальное преимущество", а вот возможность делать всё самому и вручную — это "более эффективный способ хорошего использования параллелизма"
Самому и вручную -- это на самом деле может быть эффективно (например, с точки зрения скорости работы и ресурсоемкости). Не эффективной может быть скорость разработки, если все самому и вручную. Но если взять в помощь какой-нибудь специализированный инструмент
Здравствуйте, VladD2, Вы писали:
VD>Во, блин. Хорошо что многие не были так гениальны как Вирт и мир все же увидел, выпендрежи Александреску, макросы Лисап и в итоге Nemerel.
Наверное, в обратной последовательности: макросы Лиспа, выпендрежи Александреску и, в итоге, Nemerle.
Слушай, Влад, ты в последнее время так часто поминаешь Scala и Nemerle, что я не понимаю: C# -- он что, уже отстойный язык? Будущее за Nemerle?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
MS>Общеизвестным плохим примером является выбор знака равенства для обозначения присваивания, восходящий к языку Fortran в 1957 г. и слепо повторяемый до сих пор массой разработчиков языков. Эта плохая идея низвергает вековую традицию использования знака "=" для обозначения сравнения на равенство, предиката, принимающего значения true или false.
MS>Я не понял выделенного, что значит вековая традиция в его понимании? Сколько лет coputer science (ну или хотя бы слову предикат)? MS>На мой взгляд знак "=" как раз понятен. MS>Например: MS>E=mc^2 MS>F=ma
Формула E=mc^2 (как и любая другая) читается как "Энергия равна произведению массы на квадрат скорости света". Но ни в коем слуае не "Энергии следует присвоить произведение..." То есть это равенство уже существует, а формула лишь описывает его.
В С++ же выражение
x = y;
означает действие по приведению значения х в состояние, когда оно будет равным у.
Второе. В любой мат. формуле, если справедливо E=mc^2, то верно будет и mc^2=E. А в С++ x=y; это не то же самое, что y=x;
Присваивание — это не выражение равенства, а приведение в нему, то есть активная и несимметричная операция.
Здравствуйте, VladD2, Вы писали:
VD>Грамматика регекспов не LL(1). Это нерекурсивная грамматика. Так что она куда проще.
Ну как же не рекурсивная? Ведь операторы РВ применяют к самим РВ. Напрмиер, постфиксный оператор Клини "*" имеет в качестве аргумента именно регулярное выражение. Т.о. имея атомарное выражение a мы затем конструируем последовательность вложенных выражений (((a*)*)*)*... Это рекурсия в чистом виде. Доказать, что язык РВ сам не является регулярным языком очень просто, достаточно воспользоваться леммой о накачке. Являетс ли язык РВ LL(1)-языком? Уверен что да. Пару месяцев назад построил как раз такую грамматику и написал распознаватель, работающий методом рекурсивного спуска и выбирающий альтернативу на основе просмотра следующего символа. А значит, это именно LL(1)-грамматика.
Здравствуйте, eao197, Вы писали:
E>Имхо, здесь будет классический пример развития истории по спирали. В очередной раз попробуют DSL (на новом уровне развития технологии), поймут, что ничего хорошего не вышло. Забудут лет на ...надцать. Затем опять поробуют на новом уровне развития техники и т.д.
ну если по спирали, значит то же самое можно сказать про любую другую технологию
E>Не эффективной может быть скорость разработки, если все самому и вручную. Но если взять в помощь какой-нибудь специализированный инструмент
любой инструмент, который помогает распараллелить задачи, должен уметь определять наличие или отсутствие побочных эффектов у функции. Иначе грош ему цена. А это будет шаг к тем самым функциональным языкам, пусть даже сама технология называется по другому.
Здравствуйте, Дарней, Вы писали:
Д>ну если по спирали, значит то же самое можно сказать про любую другую технологию
Любую другую, про которую переодически вспоминают. От процедурного, структурного и объектно-ориентированного программирования, почему-то так просто не отказываются. А, например, про кодогенерацию то вспоминают, то забывают.
Д>любой инструмент, который помогает распараллелить задачи, должен уметь определять наличие или отсутствие побочных эффектов у функции.
Смотря что мы понимаем под распараллеливанием. Если я пишу for(...) и какой-то умный инструмент понимает, как запустить этот for в параллель на нескольких процессорах -- это одно. А если я делаю, например, текстовый редактор и хочу, чтобы автосохранение выполнялось в фоне, параллельно редактированию, то здесь совсем другое. И я не уверен, что для текстового редактора нужен инструмент на основе функционального языка.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
K_O>Формула E=mc^2 (как и любая другая) читается как "Энергия равна произведению массы на квадрат скорости света". Но ни в коем слуае не "Энергии следует присвоить произведение..." То есть это равенство уже существует, а формула лишь описывает его.
K_O>В С++ же выражение K_O>x = y; K_O>означает действие по приведению значения х в состояние, когда оно будет равным у.
K_O>Второе. В любой мат. формуле, если справедливо E=mc^2, то верно будет и mc^2=E. А в С++ x=y; это не то же самое, что y=x; K_O>Присваивание — это не выражение равенства, а приведение в нему, то есть активная и несимметричная операция.
Со всем вышесказанным согласен.
Однако стоит отметить, что в тех-же мат. формулах операции присваивания также обозначаются "=".
"Пусть D=sqrt(b^2-4ac), тогда ..."
По поводу симметиричности:
как часто вы говорите что "3.1415192 равно пи", вместо "пи равно 3.141592"
Я по-прежнему считаю, что использование = вместо := более логично (к тому-же меньше синтаксического оверхеда
Здравствуйте, MShura, Вы писали:
MS>По поводу симметиричности: MS>как часто вы говорите что "3.1415192 равно пи", вместо "пи равно 3.141592"
На самом деле ни то, ни другое не верно, т.к. 3.141592 -- это результат округления числа пи.
MS>Я по-прежнему считаю, что использование = вместо := более логично (к тому-же меньше синтаксического оверхеда
Да что к ':=' прицепились? Вирт, вероятно, был в большей степени математиком вначале, чем программистом. Поэтому для него '=' -- это равенство, а не присваивание. Он так был воспитан. А я, например, изучать программирование начал раньше, чем высшую математику. Поэтому я совершенно спокойно принимаю в качестве присваивания как '=', так и ':='. Меня больше беспокоило, что неравенство в программировании -- это '<>' или '!=' (или что там еще бывает), а в математике -- перечеркнутое равно. Здесь дело привычки, кто к чему привык в детстве.
Ну есть и дедушки такой пунктик по поводу ':='. Ну и ладно, вполне безобидная придурь.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
Q>>С чего она увяла? Наоборот, изменяемость языка одна из очень мощных и интересных фич. И трудности синтаксического анализа не сильно мешают. Ну в самом деле, какие могут быть трудности с анализом в Лиспе?
E>Имхо, в основном, под трудностями Вирт подразумевал трудности воспрятия подобных вещей программистом, а не транслятором.
Скорее всего. Например, в ST-74 язык потока сообщений можно было менять для каждого отдельного класса(!), но после накопления некоего опыта, от этого отказались, из-за сложности поддержания и сопряжения "разноязыковых" классов.
Здравствуйте, eao197, Вы писали:
E>Любую другую, про которую переодически вспоминают. От процедурного, структурного и объектно-ориентированного программирования, почему-то так просто не отказываются. А, например, про кодогенерацию то вспоминают, то забывают.
Ну во первых, никто не забывал. Просто применялось это не очень широко.
А во вторых, в последнее время наблюдается явная тенденция к использованию декларативного программирования вместо императивного. Просто это пока не очень заметно.
E>А если я делаю, например, текстовый редактор и хочу, чтобы автосохранение выполнялось в фоне, параллельно редактированию, то здесь совсем другое. И я не уверен, что для текстового редактора нужен инструмент на основе функционального языка.
А я не уверен, что для распараллеливания такой задачи вообще нужны какие-то особые инструменты
Здравствуйте, Дарней, Вы писали:
E>>А если я делаю, например, текстовый редактор и хочу, чтобы автосохранение выполнялось в фоне, параллельно редактированию, то здесь совсем другое. И я не уверен, что для текстового редактора нужен инструмент на основе функционального языка.
Д>А я не уверен, что для распараллеливания такой задачи вообще нужны какие-то особые инструменты
Здравствуйте, eao197, Вы писали:
E>Меня больше беспокоило, что неравенство в программировании -- это '<>' или '!=' (или что там еще бывает), а в математике -- перечеркнутое равно.
Ещё бывает (в оберонах) дважды перечеркнутое равно #
WHILE (list # NIL) & (list.head # obj) DO list := list.tail END
E>>Меня больше беспокоило, что неравенство в программировании -- это '<>' или '!=' (или что там еще бывает), а в математике -- перечеркнутое равно.
СГ>Ещё бывает (в оберонах) дважды перечеркнутое равно #
СГ>WHILE (list # NIL) & (list.head # obj) DO list := list.tail END
В целом, и "#" и "!=" — попытки изобразить все тот же знак
Правда, у решетки есть минус — в английском (американском?) — это устоявшийся символ слова "номер"
F>Остроумна критика операторов ++/-- (Вирт считает, что это уродство). В общем — стоит, наверное, обратить внимание
Ему просто обидно. Как же так — он академик всея академий проиграл каким-то двоешникам — Кернигану Томпсоновичу Ричи. Причем с треском — с языка C делают синтаксические реинкарнации, а Паскаль пытается реанимировать только сам Вирт с апостолами. Если бы Вселенная была бы устроена на принципах милосердия, то Java и аналог C# имели бы синтаксис Паскаля — как дань проделанному титаническому труду. Но наша Вселенная не устроена на принципах милосердия.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, eao197, Вы писали:
>А почему параллелизм должен быть встроенным в язык? Думаю, что программ, использующих распараллеливание работы, и написанных на C++/Java гораздо больше, чем на Erlange-е.
E>Смотря что мы понимаем под распараллеливанием. Если я пишу for(...) и какой-то умный инструмент понимает, как запустить этот for в параллель на нескольких процессорах -- это одно. А если я делаю, например, текстовый редактор и хочу, чтобы автосохранение выполнялось в фоне, параллельно редактированию, то здесь совсем другое. И я не уверен, что для текстового редактора нужен инструмент на основе функционального языка.
Такое ощущение, что вы не в курсе, что представляет собой язык со встроенной поддержкой многозадачности. Это тоже самое, что язык с GC на фоне языка с ручным управлением памятью. Когда такая поддержка есть на уровне языка, то многие вещи становятся значительно проще, многие проблемы исчезают, а многие дополнительные возможности появляются.
Здравствуйте, Quintanar, Вы писали:
Q>Такое ощущение, что вы не в курсе, что представляет собой язык со встроенной поддержкой многозадачности. Это тоже самое, что язык с GC на фоне языка с ручным управлением памятью. Когда такая поддержка есть на уровне языка, то многие вещи становятся значительно проще, многие проблемы исчезают, а многие дополнительные возможности появляются.
Очень может быть. А на какие языки со встроенной многозадачностью, кроме Erlang, еще можно посмотреть?
Тем не менее, у меня есть мнение, что далеко не все представляют, как легко многозадачность может выглядеть в том же C++. Я не про распараллеливание вычислений, а об организации многопоточности (да и многопроцессовости тоже).
И, кроме того, я не считаю, что GC -- это абсолютное добро, достижение и бла-бла-бла. И на некоторых задачах GC будет давать только лишний геморрой по сравнению с ручным управлением памятью.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
M>>попытки изобразить все тот же знак
СГ>Система программирования Mathematica отличилась тем, что неравенство обозначается именно так как в математике:
СГ>
Ндяяя... Вводится или дополнительным кликом по тулбару или комбинацией клавиш, я так понимаю.
Это мне напоминает мою первую книжку по Турбо Паскалю. Десять глав, по-моему было. Из них девяь — все нормально. В десятой объяснялись указатели... Указатели обозначались знаком "вертикальная стрелочка вверх" То есть не "^", а натурально
Здравствуйте, MShura, Вы писали:
MS>Однако стоит отметить, что в тех-же мат. формулах операции присваивания также обозначаются "=". MS>"Пусть D=sqrt(b^2-4ac), тогда ..."
Это не присваивание. Указанную запись можно рассматривать как введение в констекст нового уравнения D = sqrt(b^2-4ac). Ничто не мешает мне записать "пусть справедливо равенство a+b=b+c", или что-то в этом роде. Вообще в математике отсутствует понятие присваивания, оно там избыточно и является частным случаем уравнения.
