Анализ и критикаИстория создания и использования языков программирования полна как научных озарений и торжества интелекта человека, так добросовестных заблуждений, чрезмерных надежд и решений, которые впоследствии были признаны ошибочными. Тот же «goto» казался на заре компьютерной эры вполне естественным. Ну куда же без «goto»? Некоторые нетрадиционные подходы казались порою надуманными и необоснованно сложными. Например, объектно-ориентированное и функциональное программирование. Было бы любопытно рассмотреть «под лупой» интересные свойства и особенности существующих языков программирования. Этот анализ позволит отобрать хорошие идеи и обойти проблемы, которые имеются в тех или иных языках.Давайте постараемся рассмотреть всё, что покажется достойным внимания. Это как широко распространённые языки, так и не очень. Любые языки, имеющие свою «изюминку».
Особое внимание хотелось бы уделить всякого рода «фокусам» и «трюкам». Необходимо выяснить, насколько они полезны, понятны и как часто употребительны. Не упускаем из виду не только правила, но и исключения из них, выясняем причины, по которым они появились на свет. В правилах, по которым построен язык программирования, бывают многочисленные исключения. Эти исключения часто являются результатом компромиссов. Например, в C++ классы могут наследоваться от других классов (которые, в общем, можно считать новыми типами), но вот от фундаментальных типов — нет. Нельзя, к примеру, унаследовать класс от типа «int». Автор C++ вынужден был пойти на такие компромиссы, чтобы язык обладал обратной совместимостью с C. Исключения раздувают грамматику языка со всеми вытекающими отсюда последствиями. Чем меньше исключений, тем логически стройнее язык. Вот перечень языков, которые будут упомянуты здесь хотя бы единожды:
Опубликовано: 2012.09.25, последняя правка: 2018.08.31 20:24
Отзывы✅ 2014/01/31 11:35, Pensulo #0 Предлагаю пополнить список упоминаний языком C#, на самом деле, весьма активно набирающим обороты. Да и в дальнейшем анализе с цель выработки наиболее грамотного решения опираться прежде всего на C#, а не на таких "динозавров" программостроения как C или даже C++.✅ 2014/01/31 16:21, Автор сайта #1 Пополнил. Хотя он будет «один из».✅ 2014/11/03 11:23, Аноним #2 Нельзя, к примеру, унаследовать класс от типа «int». Автор C++ вынужден был пойти на такие компромиссы, чтобы язык обладал обратной совместимостью с C. ИМХО здесь дело не в совместимости. Базовые типы умеет эффективно обрабатывать процессор, а дополнительный слой абстракции в виде класса привёл бы к большим накладным расходам (виртуальная таблица методов и т. д.) в обработке; а поскольку выполнение программы преимущественно состоит из операций над значениями базовых типов, то получили бы замедление. Вроде как на этом погорел в своё время Smalltalk. Поэтому в C++ базовые типы представлены в виде отдельных от классов сущностей, в Java -- тоже, но есть объектные обёртки над ними, в .NET структуры (в число которых попадают и базовые типы) неявно наследуются от класса System.ValueType, предполагаю, что проблемы производительности решаются на уровне генерации байт-кода.✅ 2014/11/03 14:46, Автор сайта #3 Да, обратная совместимость — не единственная причина. Накладные расходы, естественно, тоже надо учитывать. Но представьте себе, что виртуальная таблица методов не вызывает замедления. Проблема была бы решена? Отнюдь! Каждый объект должен иметь, помимо собственно значения, ещё указатель на эту таблицу. Т.е. каждый объект увеличивается, становится длиннее на размер указателя. А это — потеря обратной совместимости. Прогресс в увеличении в скорости процессоров легко компенсирует потерю эффективности, вызванною накладными расходами. А вот потерю обратной совместимости не компенсируешь ничем.✅ 2015/04/07 03:26, misha_shar53 #4 Предлагаю включить язык MUMPS. Это очень интересный язык. К тому же он рабочий и эффективный. Проверенный временем.✅ 2016/07/14 00:31, rst256 #5 в .NET структуры (в число которых попадают и базовые типы) неявно наследуются от класса System.ValueType, предполагаю, что проблемы производительности решаются на уровне генерации байт-кода. Увы все проще .net не производит нативный код, соответственно и базовых типов в чистом виде там уже изначально нет.Но представьте себе, что виртуальная таблица методов не вызывает замедления. Проблема была бы решена? Отнюдь! Каждый объект должен иметь, помимо собственно значения, ещё указатель на эту таблицу. ООП слишком примитивен и ограничен. Объектам, чьи методы известны на этапе компиляции, не нужна никакая таблица...✅ 2016/07/14 12:14, rst256 #6 Предлагаю взглянуть на возможности аспектно-ориентированного программирования, например ACC аоп для языка си:https://sites.google.com/a/gapp.msrg.utoronto.ca/aspectc/home А здесь пара статей на русском об общим принципах данного подхода: http://www.javable.com/columns/aop/ Написать автору можно на электронную почту |
Русский язык и программирование