Эта идея совершенно понятна и звучит разумно, но слабо верится, что язык, слепленный по такому принципу, может получить широкое распространение. Как тот же Страуструп писал, все языки делятся на два вида: те, которые все ругают и те, на которых никто не пишет.
В процессе развития языка всегда возникает дилемма: порвать с прошлым и переписать заново, либо сохранять всё в языке. Конечно, в первом случае мы получаем красоту, но никто с таким языком не захочет иметь дела. Даже весьма скромные обновления Python в третьей версии вызвали раскол, до сих пор не преодолённый.
А С++ да, сохраняет все те окаменелости, которые давно пора бы выбросить, но нельзя. Я вот не знаю, если бы на месте Страуструпа решил, что перегрузка операторов нужна, чтобы я делал? Наверно, тоже ввёл бы ссылки. Макроподстановки взяты ещё из C, стало быть, в С++ надо было не делать const вообще или переписать механизм макросов.
Да уж. По поводу шаблонов — не зря Страуструп сокрушался, что в стандарт так и не вошли концепты. Если дождёмся, полегчает. Хотя язык станет ещё монстроуознее.
А «написанный с нуля С++» уже есть — язык D. Вон какой популярный, все на нём только и пишут :)
Да, в этом смысле проблема C++ показательна, потому что Страуструп в «Дизайн и эволюция С++» пишет, что ссылки были введены ради перегрузки операторов. Тут было два пути — либо отказаться перегружать операции, либо отказаться от ссылок. Проблема в том, что «по Вирту» надо было вообще отказаться от нужной фичи из-за того, что она частично пересекается с существующей. Ну или переписать весь язык с нуля, да. В этом смысле С++ похож на человеческие языки: в нём сосуществуют самые разные «пласты» лексики. Некоторые явно архаичны, но с этим ничего не сделаешь.
По поводу молотка — я вот думаю, что дело обстоит как раз наоборот, обобщённое программирование и итерация по коллекции значительно снижают вероятность ошибок. Потому что без обобщённого программирования я должен заново реализовывать библиотечные алгоритмы, а без итерации по коллекции могу перепутать индексы.
А по поводу «набора фич» — в общем-то С++ тоже консервативен. Апдейт стандарта раз 13 лет — разве это часто? А на выходе такая разница с Обероном. А вот С#, конечно, бешеная собака. Я не успеваю версии отслеживать.
Да, конечно, тут можно многое обсудить. Для меня «язык общего назначения» — это, скажем так, второй язык программирования. Если в качестве первого языка я бы предложил изучить что-то простое и полуигрушечное (вроде SmallBasic), то в качестве второго языка это был бы тот самый наш «общеназначенец». И это был бы явно и не SQL, и не MATLAB, и не PHP.
Ну давайте согласимся, что играть в слова незачем: любой полный по Тьюрингу язык годится для чего угодно. Так что и C может «широко применяться», естественно.
А значит, разница состоит исключительно в «удобстве» (в любом понимании этого термина) для программиста. Соответственно, вам кажется, что инструменты, разработанные за последние 40 лет, не особенно ценны. Ну что я могу на это сказать?.. Видимо, в вашей сфере деятельности действительно это не нужно.
Я исхожу из того, что любой инструмент, придуманный за последние 40 лет, призван решать какую-то задачу. А чем больше задач может решать язык, тем шире он применим в реальной жизни, вот и всё.
Оставим пока наследование, потому что второе — это проблема.
Как алгоритмический модуль может импортировать ADT-модуль, если ADT-модуля ещё нет? То есть я вот хочу написать библиотеку алгоритмов, которой могут воспользоваться неизвестные мне люди. Классическое разделение труда.
Да чего уж там, давайте сразу назовём ассемблер.
Понятно, что любой язык программирования полон по Тьюрингу, но наши представления о прекрасном всё-таки прошли некоторую эволюцию с 1973 года.
Вот если бы я увидел код, вопросы бы отпали сами собой.
В частности (опять же, мы теряем время, потому что я вынужден формулировать все вопросы, которые и так бы прояснились при виде кода):
1) Можно ли получить тип на основе нескольких базовых? Это необходимо в моей задаче.
2) Как имея только базовый тип, написать код присваивания объектов производных типов?
3) Как конкретно можно разрешить автору производного типа передать алгоритму сортировки (который ничего не знает о производном типе) функцию сравнения?..
Да, пишут. Но разве я сильно ошибусь, если предположу, что ниша C постепено отходит к задачам, где основная работа как раз и производится с такими массивами?.. Рискну сделать и более сильное утверждение: в 2014 году язык С уже не может считаться языком общего назначения.
Вот в этом и проблема, потому что сначала нам рассказывают про инструменты, «простые как скальпель», которые благодаря своей простоте «предохраняют от ошибок», но потом на практике оказывается, что всё это на самом деле болтовня. Потому что да, чем меньше инструментов, тем меньше способов ошибиться. Но чем проще инструмент, тем хуже он подходит для решения любой отдельно взятой задачи, и в итоге провоцирует совершать идиотские ошибки, просто по невнимательности, да и плодит сущности там, где это не надо. Например, в Паскале если мне надо просто выполнить действие для каждого элемента коллекции, у меня возникает абсолютно избыточная сущность «индексатор i», хотя в моей задаче его нигде не было.
Ну то есть по сути предлагается альтернатива: либо вафельница + тостер, либо сковородка. Да, в первом случае сущности две, но неправильно их применить трудно. А во втором случае сущность одна, но ошибиться можно миллионом способов.
Вот смотрите, я просил десять строк кода, а в результате снова получаю несколько абзацев текста. Давайте код. Я не собираюсь свои критерии трактовать с религиозным рвением. Под сжатостью я понимаю, например, то, что сортировка пузырьком не будет занимать 200 строк. А 10 строк или 20 — не так принципиально. Но если 200 — увольте, у меня нет времени столько печатать сортировку.
Разделение работы меня интересует в контексте «одни пишут алгоритмы, а другие структуры». Вот как это реализуется (поэтому и просил обобщённую сортировку)? Применение в новых проектах — это идеально формализуемый критерий, которому удовлетворяет любая библиотека, такая как стандартные классы .NET или библиотека C++ STL.
Книга Вирта меня в данном случае не устраивает (я её читал), потому что там рассматриваются алгоритмы на примерах базовых типов данных. Например, если вы пойдёте в главу 2.2, то увидите, что сортировка описывается на примере сортировки целых чисел.
Как раз пример книги AD — это, в общем-то фейл уважаемого мэтра доказать свою теорию. Потому что со времён первого издания (1985) в ней по факту очень мало изменились листинги. Как-то вот на месте топчемся. Те же примеры практически в тех же декорациях.
А есть ли в Обероне операция по типу foreach для обхода коллекции?
Из моего опыта вероятность того, что оператор ">" будет означать запись в сокет минимальна, в то время как ошибка в границах коллекции в циклах вроде for i = 1 to N — это просто классика жанра.
Ну вот почему вы всё время ударяетесь в общие рассуждения? Ведь мы же все здесь программировать умеем. Покажите на примере, как простой инструмент решает сложную задачу, и мы сразу же поймём. По крайней мере, я.
Кстати, Бейсик тоже простой инструмент, и на нём я тоже с удовольствием программировал когда-то. Можно просто вернуться к Бейсику и радоваться.
Ну почему же, это решение необязательно намекает на C++. Это можно совершенно без напряжений сделать на Python и на массе других языков. По поводу «зачем это надо» я отвечу очень просто: старая идея «повторного использования кода» никем не отменена.
Вот смотрите. Есть огромное количество классических алгоритмов, описанных у Кормена или у Кнута. Это ведь полезные алгоритмы, так? Иначе они бы не вошли в учебники.
Далее, каждый раз, когда мне требуется такой алгоритм, что я могу сделать? Могу реализовать сам, а могу обратиться к библиотеке. Неужели Оберон потребует от меня тысячной реализации сортировки или алгоритма Дейкстры? Это же полностью противоречит идеям любой школы программирования. Классические алгоритмы заслуживают эталонных реализаций.
Теперь, предположим, некто готов построить карьеру на реализации таких классических алгоритмов. Он пишет библиотеку алгоритмов, рассчитанную на самый широкий круг пользователей. Как он может написать такую библиотеку на Обероне?..
Даже если вы предложите алгоритм только для массива (ОК), всё равно остаются сложности со сравнением и копированием элементов неизвестной природы. А заставлять пользователя наследоваться от вашего базового класса — это уже перебор (ну, если там нет множественного наследования, конечно).
Вы говорите, что «в мире есть иные взгляды на программирование». Вот я и хочу посмотреть, как такая задача решается на Обероне.
А критерии очень простые, многократно описаны в работах классиков и годятся для любого языка:
— По возможности сжатость (иначе можно писать на ассемблере).
— По возможности понятность.
— Возможность разделить работу между исполнителями.
— Возможность применить написанное в новых проектах.
Давайте лучше код, а там уже и критерии будут очевидны. Может, у меня откроются глаза и я действительно увижу новый взгляд, не лишайте меня удовольствия.
В процессе развития языка всегда возникает дилемма: порвать с прошлым и переписать заново, либо сохранять всё в языке. Конечно, в первом случае мы получаем красоту, но никто с таким языком не захочет иметь дела. Даже весьма скромные обновления Python в третьей версии вызвали раскол, до сих пор не преодолённый.
А С++ да, сохраняет все те окаменелости, которые давно пора бы выбросить, но нельзя. Я вот не знаю, если бы на месте Страуструпа решил, что перегрузка операторов нужна, чтобы я делал? Наверно, тоже ввёл бы ссылки. Макроподстановки взяты ещё из C, стало быть, в С++ надо было не делать const вообще или переписать механизм макросов.
В общем, всё плохо :)
А «написанный с нуля С++» уже есть — язык D. Вон какой популярный, все на нём только и пишут :)
По поводу молотка — я вот думаю, что дело обстоит как раз наоборот, обобщённое программирование и итерация по коллекции значительно снижают вероятность ошибок. Потому что без обобщённого программирования я должен заново реализовывать библиотечные алгоритмы, а без итерации по коллекции могу перепутать индексы.
А по поводу «набора фич» — в общем-то С++ тоже консервативен. Апдейт стандарта раз 13 лет — разве это часто? А на выходе такая разница с Обероном. А вот С#, конечно, бешеная собака. Я не успеваю версии отслеживать.
А значит, разница состоит исключительно в «удобстве» (в любом понимании этого термина) для программиста. Соответственно, вам кажется, что инструменты, разработанные за последние 40 лет, не особенно ценны. Ну что я могу на это сказать?.. Видимо, в вашей сфере деятельности действительно это не нужно.
Я исхожу из того, что любой инструмент, придуманный за последние 40 лет, призван решать какую-то задачу. А чем больше задач может решать язык, тем шире он применим в реальной жизни, вот и всё.
Как алгоритмический модуль может импортировать ADT-модуль, если ADT-модуля ещё нет? То есть я вот хочу написать библиотеку алгоритмов, которой могут воспользоваться неизвестные мне люди. Классическое разделение труда.
Понятно, что любой язык программирования полон по Тьюрингу, но наши представления о прекрасном всё-таки прошли некоторую эволюцию с 1973 года.
В частности (опять же, мы теряем время, потому что я вынужден формулировать все вопросы, которые и так бы прояснились при виде кода):
1) Можно ли получить тип на основе нескольких базовых? Это необходимо в моей задаче.
2) Как имея только базовый тип, написать код присваивания объектов производных типов?
3) Как конкретно можно разрешить автору производного типа передать алгоритму сортировки (который ничего не знает о производном типе) функцию сравнения?..
Ну то есть по сути предлагается альтернатива: либо вафельница + тостер, либо сковородка. Да, в первом случае сущности две, но неправильно их применить трудно. А во втором случае сущность одна, но ошибиться можно миллионом способов.
И да, в Бейсике есть абстрактные типы данных. И из книги Вирта AD я не увидел особой разницы. Многие листинги оттуда прекрасно переносятся на Бейсик.
Разделение работы меня интересует в контексте «одни пишут алгоритмы, а другие структуры». Вот как это реализуется (поэтому и просил обобщённую сортировку)? Применение в новых проектах — это идеально формализуемый критерий, которому удовлетворяет любая библиотека, такая как стандартные классы .NET или библиотека C++ STL.
Книга Вирта меня в данном случае не устраивает (я её читал), потому что там рассматриваются алгоритмы на примерах базовых типов данных. Например, если вы пойдёте в главу 2.2, то увидите, что сортировка описывается на примере сортировки целых чисел.
Как раз пример книги AD — это, в общем-то фейл уважаемого мэтра доказать свою теорию. Потому что со времён первого издания (1985) в ней по факту очень мало изменились листинги. Как-то вот на месте топчемся. Те же примеры практически в тех же декорациях.
Из моего опыта вероятность того, что оператор ">" будет означать запись в сокет минимальна, в то время как ошибка в границах коллекции в циклах вроде for i = 1 to N — это просто классика жанра.
Кстати, Бейсик тоже простой инструмент, и на нём я тоже с удовольствием программировал когда-то. Можно просто вернуться к Бейсику и радоваться.
Вот смотрите. Есть огромное количество классических алгоритмов, описанных у Кормена или у Кнута. Это ведь полезные алгоритмы, так? Иначе они бы не вошли в учебники.
Далее, каждый раз, когда мне требуется такой алгоритм, что я могу сделать? Могу реализовать сам, а могу обратиться к библиотеке. Неужели Оберон потребует от меня тысячной реализации сортировки или алгоритма Дейкстры? Это же полностью противоречит идеям любой школы программирования. Классические алгоритмы заслуживают эталонных реализаций.
Теперь, предположим, некто готов построить карьеру на реализации таких классических алгоритмов. Он пишет библиотеку алгоритмов, рассчитанную на самый широкий круг пользователей. Как он может написать такую библиотеку на Обероне?..
Даже если вы предложите алгоритм только для массива (ОК), всё равно остаются сложности со сравнением и копированием элементов неизвестной природы. А заставлять пользователя наследоваться от вашего базового класса — это уже перебор (ну, если там нет множественного наследования, конечно).
А критерии очень простые, многократно описаны в работах классиков и годятся для любого языка:
— По возможности сжатость (иначе можно писать на ассемблере).
— По возможности понятность.
— Возможность разделить работу между исполнителями.
— Возможность применить написанное в новых проектах.
Давайте лучше код, а там уже и критерии будут очевидны. Может, у меня откроются глаза и я действительно увижу новый взгляд, не лишайте меня удовольствия.