Вот смотрите, я просил десять строк кода, а в результате снова получаю несколько абзацев текста. Давайте код. Я не собираюсь свои критерии трактовать с религиозным рвением. Под сжатостью я понимаю, например, то, что сортировка пузырьком не будет занимать 200 строк. А 10 строк или 20 — не так принципиально. Но если 200 — увольте, у меня нет времени столько печатать сортировку.
Разделение работы меня интересует в контексте «одни пишут алгоритмы, а другие структуры». Вот как это реализуется (поэтому и просил обобщённую сортировку)? Применение в новых проектах — это идеально формализуемый критерий, которому удовлетворяет любая библиотека, такая как стандартные классы .NET или библиотека C++ STL.
Книга Вирта меня в данном случае не устраивает (я её читал), потому что там рассматриваются алгоритмы на примерах базовых типов данных. Например, если вы пойдёте в главу 2.2, то увидите, что сортировка описывается на примере сортировки целых чисел.
Как раз пример книги AD — это, в общем-то фейл уважаемого мэтра доказать свою теорию. Потому что со времён первого издания (1985) в ней по факту очень мало изменились листинги. Как-то вот на месте топчемся. Те же примеры практически в тех же декорациях.
А есть ли в Обероне операция по типу foreach для обхода коллекции?
Из моего опыта вероятность того, что оператор ">" будет означать запись в сокет минимальна, в то время как ошибка в границах коллекции в циклах вроде for i = 1 to N — это просто классика жанра.
Ну вот почему вы всё время ударяетесь в общие рассуждения? Ведь мы же все здесь программировать умеем. Покажите на примере, как простой инструмент решает сложную задачу, и мы сразу же поймём. По крайней мере, я.
Кстати, Бейсик тоже простой инструмент, и на нём я тоже с удовольствием программировал когда-то. Можно просто вернуться к Бейсику и радоваться.
Ну почему же, это решение необязательно намекает на C++. Это можно совершенно без напряжений сделать на Python и на массе других языков. По поводу «зачем это надо» я отвечу очень просто: старая идея «повторного использования кода» никем не отменена.
Вот смотрите. Есть огромное количество классических алгоритмов, описанных у Кормена или у Кнута. Это ведь полезные алгоритмы, так? Иначе они бы не вошли в учебники.
Далее, каждый раз, когда мне требуется такой алгоритм, что я могу сделать? Могу реализовать сам, а могу обратиться к библиотеке. Неужели Оберон потребует от меня тысячной реализации сортировки или алгоритма Дейкстры? Это же полностью противоречит идеям любой школы программирования. Классические алгоритмы заслуживают эталонных реализаций.
Теперь, предположим, некто готов построить карьеру на реализации таких классических алгоритмов. Он пишет библиотеку алгоритмов, рассчитанную на самый широкий круг пользователей. Как он может написать такую библиотеку на Обероне?..
Даже если вы предложите алгоритм только для массива (ОК), всё равно остаются сложности со сравнением и копированием элементов неизвестной природы. А заставлять пользователя наследоваться от вашего базового класса — это уже перебор (ну, если там нет множественного наследования, конечно).
Вы говорите, что «в мире есть иные взгляды на программирование». Вот я и хочу посмотреть, как такая задача решается на Обероне.
А критерии очень простые, многократно описаны в работах классиков и годятся для любого языка:
— По возможности сжатость (иначе можно писать на ассемблере).
— По возможности понятность.
— Возможность разделить работу между исполнителями.
— Возможность применить написанное в новых проектах.
Давайте лучше код, а там уже и критерии будут очевидны. Может, у меня откроются глаза и я действительно увижу новый взгляд, не лишайте меня удовольствия.
Я это читал, но согласитесь, между чтением мануала и умением писать хороший код на данном языке лежит пропасть. Поэтому я и прошу вас привести тот кусок, который был бы образцом «оберонного» стиля решения данной задачи. Подставляться я не боюсь, подумаешь, тоже мне проблема.
Если просто кидаться текстами, я не «пойму, что есть другие взгляды». Давайте конкретнее.
Согласитесь, моя задача не относится ни к какой узкой области. Речь идёт о банальной сортировке. Если один член команды разрабатывает алгоритм сортировки, а другой работает над структурами данных, то разделение труда таким образом выглядит очевидным. Кроме того, хороший алгоритм сортировки можно применить и в следующем проекте (короче говоря, это библиотечный код).
Ну, я, конечно, в этом языке малокомпетентен, так что могу сильно промазать.
Но вот взять хотя бы простую задачу: «разработать алгоритм сортировки произвольной линейной структуры данных, в которой хранятся объекты пользовательского типа, для которой определены операции доступа по индексу, а объекты сравнимы операцией „меньше“».
Согласитесь, базовее задачу трудно придумать. Как это выглядит на Обероне? Ну то есть предположим, требуется разработать библиотечное средство.
Это не аксиоматика, это теорема, которую я попытался вкратце обосновать.
Но вы с ней даже не спорите, потому что предлагаете «выбирать язык в соответствии с задачей».
Ну так укажите язык ОБЩЕГО назначения, который Вам нравится, а я попробую его раскритиковать. Это будет конструктивно.
Мне тоже нравятся языки из Вашего списка. Но только для написания каких-то мелких кусков или для самостоятельных упражнений. А вот в качестве инструмента для широкого класса задач у меня с ними плохо срастается.
Давайте я для простоты картины сведу мысль к двум тезисам:
1) Вирт проповедует минимализм и выражает свою философию в языках вроде Паскаля, Модулы и Оберона.
2) Вирт позиционирует упомянутые языки как языки общего назначения с самой широкой сферой деятельности.
Я считаю, что минимализм и широкая сфера несовместимы, вот и всё.
Соответственно, можно опровергать (1), (2) или мой вывод. А разговоры о «школах» и т.п. нерелевантны.
Нет, не надо приписывать меня к какому-либо лагерю. Я работаю с несколькими языками и вижу их сильные и слабые стороны.
Вы снова и снова уходите от темы.
Это всё общие слова про разность школ и прочие высокие философии. Не причисляю себя ни к какой «школе».
Я выше объяснил своё видение ситуации с языками общего назначения. Если вы видите альтернативу (тезис — антитезис), разговор можно продолжить. А иначе получается игра в одни ворота — вместо опровержения своих мыслей я просто получаю какие-то абстрактные размышлизмы о специализации языков и школах.
Кстати, довольно странно записывать Страуструпа и авторов Simula 67 в американцы.
Не складывается. Фортран всего на год старше Лиспа, а C на пятнадцать лет моложе.
А вот про подготовку поверить могу. Но это уже к вопросу о «ломании через колено».
Нет, я поклонник C++.
По предыдущим замечаниям — понятно, но это всё довольно очевидные соображения, которые в наши дни всё сильнее размываются реальностью. А реальность такова, что предметных областей становится всё больше, а возможности человеческие ограничены. Всё равно очень хорошо выучить можно пять-семь языков и обходиться ими в любой задаче.
Но мы, на самом деле уходим в сторону, потому что в текущем контексте речь идёт о языках общего назначения, как я это себе представляю. Или профессор Вирт и вправду придумал несколько узко специализированных языков, а я чего-то недопонял?
Ну вот это проблема курицы и яйца: Бейсик появился позже Лиспа, так в чём же проблема освоения преподавателями, которые на тот момент были tabula rasa?
Дело не в моём вкусе, а в моей предметной области. Она не имеет никакого отношения ко вкусу.
Вот ориентация на определённый класс задач — это совсем другое дело. Поэтому у нас есть SQL, например. Или Perl. Но в контексте данной статьи, я думаю, речь в большей степени идёт о Паскале и Обероне, которые позиционируются как языки общего назначения.
А необходимое — опять же, для кого. Для математика, например, арифметические операции с векторами и матрицами абсолютно необходимы. А я с ними редко сталкиваюсь.
Я думаю, если такими широкими мазками перечислять базовые понятия C++, окажется примерно столько же :)
Интерпретация и типизация, я бы сказал, очень важное свойство языка. Именно благодаря этим штукам в Python так изящно работает duck typing и гораздо меньше головной боли с частично пересекающимися в целях механизмами шаблонов и наследования в C++. Ведь если подумать, сколько всего в C++ наворочено лишь ради того, чтобы код можно было откомпилировать…
Это так, но из этого не следует, что в параллельной вселенной, где всё наоборот, LISP бы оказался впереди.
Вообще в известном смысле мир становится всё более мультипарадигменным, и тот же C++ в последние годы сделал немало шагов навстречу функциональному программированию, так что скоро все в одной лодке будем.
Когда ещё не было никакого C, LISP мог конкурировать с Бейсиком, однако вот как-то воспринимался Бейсик попроще.
В том и дело, что (повторю свой тезис) автор языка не может знать заранее, что конкретно мне нужно. Так что с тезисом (2) я в корне не согласен: язык должен удовлетворять мои объективные потребности. А если не удовлетворяет, то для меня он не годится.
Тут, конечно, надо пройти по тонкому льду между «естественными / правильными» абстракциями и «вредными костылями». Скажем, Чак Мур вообще всё на свете объявляет вредными костылями.
Я рассуждаю так. Вот я сижу и абстрактно решаю задачу. Например: нужно найти решение уравнения с заданной точностью. Точность — это разность между решениями, полученными на последовательных шагах численного метода. Таким образом, моя задача естественным образом разбивается на две: программирование многошагового метода и определение разности между двумя членами.
Языки вроде Haskell или Python позволяют описать мои мысли с наименьшими искажениями, то есть лениво сгенерировать бесконечный список, а потом пройтись по его элементам и найти требуемый шаг.
Если же язык заставляет меня формулировать мысли иначе, это не очень хороший язык, потому что я здесь хозяин, в конце концов, а он мне должен служить.
Вряд ли соглашусь. Языки вроде LISP или FORTH живучи и мощны, но я думаю, что они обладают слишком ограниченными средствами для описания моей проблемы на моём языке, скажем так. Это языки, которые «ломают программиста через колено». Если на всё смотреть сквозь призму FORTH или LISP, то да, на них можно сделать что угодно.
Если бы всё было так просто, на LISP писали бы всё подряд, и у языка вроде Java не было бы никакого шанса выжить.
Python я бы не назвал слишком простым языком. В него легко войти, но встроенных средств в него заложено очень немало. К тому же предположу, что рано или поздно и там начнутся добавления, потому что будет «почему Вася может написать на своём языке Х, а я не могу?»
Да и у Питона свои недостатки (которые являются продолжениями его достоинств) — интерпретация, динамические типы. Не всегда я им рад.
Разделение работы меня интересует в контексте «одни пишут алгоритмы, а другие структуры». Вот как это реализуется (поэтому и просил обобщённую сортировку)? Применение в новых проектах — это идеально формализуемый критерий, которому удовлетворяет любая библиотека, такая как стандартные классы .NET или библиотека C++ STL.
Книга Вирта меня в данном случае не устраивает (я её читал), потому что там рассматриваются алгоритмы на примерах базовых типов данных. Например, если вы пойдёте в главу 2.2, то увидите, что сортировка описывается на примере сортировки целых чисел.
Как раз пример книги AD — это, в общем-то фейл уважаемого мэтра доказать свою теорию. Потому что со времён первого издания (1985) в ней по факту очень мало изменились листинги. Как-то вот на месте топчемся. Те же примеры практически в тех же декорациях.
Из моего опыта вероятность того, что оператор ">" будет означать запись в сокет минимальна, в то время как ошибка в границах коллекции в циклах вроде for i = 1 to N — это просто классика жанра.
Кстати, Бейсик тоже простой инструмент, и на нём я тоже с удовольствием программировал когда-то. Можно просто вернуться к Бейсику и радоваться.
Вот смотрите. Есть огромное количество классических алгоритмов, описанных у Кормена или у Кнута. Это ведь полезные алгоритмы, так? Иначе они бы не вошли в учебники.
Далее, каждый раз, когда мне требуется такой алгоритм, что я могу сделать? Могу реализовать сам, а могу обратиться к библиотеке. Неужели Оберон потребует от меня тысячной реализации сортировки или алгоритма Дейкстры? Это же полностью противоречит идеям любой школы программирования. Классические алгоритмы заслуживают эталонных реализаций.
Теперь, предположим, некто готов построить карьеру на реализации таких классических алгоритмов. Он пишет библиотеку алгоритмов, рассчитанную на самый широкий круг пользователей. Как он может написать такую библиотеку на Обероне?..
Даже если вы предложите алгоритм только для массива (ОК), всё равно остаются сложности со сравнением и копированием элементов неизвестной природы. А заставлять пользователя наследоваться от вашего базового класса — это уже перебор (ну, если там нет множественного наследования, конечно).
А критерии очень простые, многократно описаны в работах классиков и годятся для любого языка:
— По возможности сжатость (иначе можно писать на ассемблере).
— По возможности понятность.
— Возможность разделить работу между исполнителями.
— Возможность применить написанное в новых проектах.
Давайте лучше код, а там уже и критерии будут очевидны. Может, у меня откроются глаза и я действительно увижу новый взгляд, не лишайте меня удовольствия.
Если просто кидаться текстами, я не «пойму, что есть другие взгляды». Давайте конкретнее.
Согласитесь, моя задача не относится ни к какой узкой области. Речь идёт о банальной сортировке. Если один член команды разрабатывает алгоритм сортировки, а другой работает над структурами данных, то разделение труда таким образом выглядит очевидным. Кроме того, хороший алгоритм сортировки можно применить и в следующем проекте (короче говоря, это библиотечный код).
Но вот взять хотя бы простую задачу: «разработать алгоритм сортировки произвольной линейной структуры данных, в которой хранятся объекты пользовательского типа, для которой определены операции доступа по индексу, а объекты сравнимы операцией „меньше“».
Согласитесь, базовее задачу трудно придумать. Как это выглядит на Обероне? Ну то есть предположим, требуется разработать библиотечное средство.
Но вы с ней даже не спорите, потому что предлагаете «выбирать язык в соответствии с задачей».
Ну так укажите язык ОБЩЕГО назначения, который Вам нравится, а я попробую его раскритиковать. Это будет конструктивно.
Мне тоже нравятся языки из Вашего списка. Но только для написания каких-то мелких кусков или для самостоятельных упражнений. А вот в качестве инструмента для широкого класса задач у меня с ними плохо срастается.
1) Вирт проповедует минимализм и выражает свою философию в языках вроде Паскаля, Модулы и Оберона.
2) Вирт позиционирует упомянутые языки как языки общего назначения с самой широкой сферой деятельности.
Я считаю, что минимализм и широкая сфера несовместимы, вот и всё.
Соответственно, можно опровергать (1), (2) или мой вывод. А разговоры о «школах» и т.п. нерелевантны.
Вы снова и снова уходите от темы.
Это всё общие слова про разность школ и прочие высокие философии. Не причисляю себя ни к какой «школе».
Я выше объяснил своё видение ситуации с языками общего назначения. Если вы видите альтернативу (тезис — антитезис), разговор можно продолжить. А иначе получается игра в одни ворота — вместо опровержения своих мыслей я просто получаю какие-то абстрактные размышлизмы о специализации языков и школах.
Кстати, довольно странно записывать Страуструпа и авторов Simula 67 в американцы.
А вот про подготовку поверить могу. Но это уже к вопросу о «ломании через колено».
По предыдущим замечаниям — понятно, но это всё довольно очевидные соображения, которые в наши дни всё сильнее размываются реальностью. А реальность такова, что предметных областей становится всё больше, а возможности человеческие ограничены. Всё равно очень хорошо выучить можно пять-семь языков и обходиться ими в любой задаче.
Но мы, на самом деле уходим в сторону, потому что в текущем контексте речь идёт о языках общего назначения, как я это себе представляю. Или профессор Вирт и вправду придумал несколько узко специализированных языков, а я чего-то недопонял?
Вот ориентация на определённый класс задач — это совсем другое дело. Поэтому у нас есть SQL, например. Или Perl. Но в контексте данной статьи, я думаю, речь в большей степени идёт о Паскале и Обероне, которые позиционируются как языки общего назначения.
А необходимое — опять же, для кого. Для математика, например, арифметические операции с векторами и матрицами абсолютно необходимы. А я с ними редко сталкиваюсь.
Интерпретация и типизация, я бы сказал, очень важное свойство языка. Именно благодаря этим штукам в Python так изящно работает duck typing и гораздо меньше головной боли с частично пересекающимися в целях механизмами шаблонов и наследования в C++. Ведь если подумать, сколько всего в C++ наворочено лишь ради того, чтобы код можно было откомпилировать…
Вообще в известном смысле мир становится всё более мультипарадигменным, и тот же C++ в последние годы сделал немало шагов навстречу функциональному программированию, так что скоро все в одной лодке будем.
Когда ещё не было никакого C, LISP мог конкурировать с Бейсиком, однако вот как-то воспринимался Бейсик попроще.
Тут, конечно, надо пройти по тонкому льду между «естественными / правильными» абстракциями и «вредными костылями». Скажем, Чак Мур вообще всё на свете объявляет вредными костылями.
Я рассуждаю так. Вот я сижу и абстрактно решаю задачу. Например: нужно найти решение уравнения с заданной точностью. Точность — это разность между решениями, полученными на последовательных шагах численного метода. Таким образом, моя задача естественным образом разбивается на две: программирование многошагового метода и определение разности между двумя членами.
Языки вроде Haskell или Python позволяют описать мои мысли с наименьшими искажениями, то есть лениво сгенерировать бесконечный список, а потом пройтись по его элементам и найти требуемый шаг.
Если же язык заставляет меня формулировать мысли иначе, это не очень хороший язык, потому что я здесь хозяин, в конце концов, а он мне должен служить.
Если бы всё было так просто, на LISP писали бы всё подряд, и у языка вроде Java не было бы никакого шанса выжить.
Python я бы не назвал слишком простым языком. В него легко войти, но встроенных средств в него заложено очень немало. К тому же предположу, что рано или поздно и там начнутся добавления, потому что будет «почему Вася может написать на своём языке Х, а я не могу?»
Да и у Питона свои недостатки (которые являются продолжениями его достоинств) — интерпретация, динамические типы. Не всегда я им рад.