Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Новости и прочее

Анализ и критика

История создания и использования языков программирования полна как научных озарений и торжества интелекта человека, так добросовестных заблуждений, чрезмерных надежд и решений, которые впоследствии были признаны ошибочными. Тот же «goto» казался на заре компьютерной эры вполне естественным. Ну куда же без «goto»? Некоторые нетрадиционные подходы казались порою надуманными и необоснованно сложными. Например, объектно-ориентированное и функциональное программирование.

         Было бы любопытно рассмотреть «под лупой» интересные свойства и особенности существующих языков программирования. Этот анализ позволит отобрать хорошие идеи и обойти проблемы, которые имеются в тех или иных языках.

         Давайте постараемся рассмотреть всё, что покажется достойным внимания. Это как широко распространённые языки, так и не очень. Любые языки, имеющие свою «изюминку».
анализ языков программирования


         Особое внимание хотелось бы уделить всякого рода «фокусам» и «трюкам». Необходимо выяснить, насколько они полезны, понятны и как часто употребительны. Не упускаем из виду не только правила, но и исключения из них, выясняем причины, по которым они появились на свет.

         В правилах, по которым построен язык программирования, бывают многочисленные исключения. Эти исключения часто являются результатом компромиссов. Например, в C++ классы могут наследоваться от других классов (которые, в общем, можно считать новыми типами), но вот от фундаментальных типов — нет. Нельзя, к примеру, унаследовать класс от типа «int». Автор C++ вынужден был пойти на такие компромиссы, чтобы язык обладал обратной совместимостью с C. Исключения раздувают грамматику языка со всеми вытекающими отсюда последствиями. Чем меньше исключений, тем логически стройнее язык.
Вот перечень языков, которые будут упомянуты здесь хотя бы единожды:
  • Ada
  • Algol-68
  • Basic
  • C, C++
  • C#
  • Clean
  • Cobol
  • D
  • Euphoria
  • Forth
  • J
  • Java
  • Haskell
  • Lisp
  • ML
  • Nemerle
  • PHP
  • Phyton
  • PL/I
  • Ruby
  • Rust
  • Visual Basic
  • Валентина
  • Кумир
  • Пифагор

Опубликовано: 2012.09.25, последняя правка: 2018.08.31    20:24

ОценитеОценки посетителей
   █████████████████████████████████████ 7 (87.5%)
   ██████ 1 (12.5%)
   ▌ 0
   ▌ 0

Отзывы

     2014/01/31 11:35, Pensulo          # 

Предлагаю пополнить список упоминаний языком C#, на самом деле, весьма активно набирающим обороты. Да и в дальнейшем анализе с цель выработки наиболее грамотного решения опираться прежде всего на C#, а не на таких "динозавров" программостроения как C или даже C++.

     2014/01/31 16:21, Автор сайта          # 

Пополнил. Хотя он будет «один из».

     2014/11/03 11:23, Аноним          # 

Нельзя, к примеру, унаследовать класс от типа «int». Автор C++ вынужден был пойти на такие компромиссы, чтобы язык обладал обратной совместимостью с C.

ИМХО здесь дело не в совместимости. Базовые типы умеет эффективно обрабатывать процессор, а дополнительный слой абстракции в виде класса привёл бы к большим накладным расходам (виртуальная таблица методов и т. д.) в обработке; а поскольку выполнение программы преимущественно состоит из операций над значениями базовых типов, то получили бы замедление. Вроде как на этом погорел в своё время Smalltalk. Поэтому в C++ базовые типы представлены в виде отдельных от классов сущностей, в Java -- тоже, но есть объектные обёртки над ними, в .NET структуры (в число которых попадают и базовые типы) неявно наследуются от класса System.ValueType, предполагаю, что проблемы производительности решаются на уровне генерации байт-кода.

     2014/11/03 14:46, Автор сайта          # 

Да, обратная совместимость — не единственная причина. Накладные расходы, естественно, тоже надо учитывать. Но представьте себе, что виртуальная таблица методов не вызывает замедления. Проблема была бы решена? Отнюдь! Каждый объект должен иметь, помимо собственно значения, ещё указатель на эту таблицу. Т.е. каждый объект увеличивается, становится длиннее на размер указателя. А это — потеря обратной совместимости. Прогресс в увеличении в скорости процессоров легко компенсирует потерю эффективности, вызванною накладными расходами. А вот потерю обратной совместимости не компенсируешь ничем.

     2015/04/07 03:26, misha_shar53          # 

Предлагаю включить язык MUMPS. Это очень интересный язык. К тому же он рабочий и эффективный. Проверенный временем.

     2016/07/14 00:31, rst256          # 

в .NET структуры (в число которых попадают и базовые типы) неявно наследуются от класса System.ValueType, предполагаю, что проблемы производительности решаются на уровне генерации байт-кода.

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

Но представьте себе, что виртуальная таблица методов не вызывает замедления. Проблема была бы решена? Отнюдь! Каждый объект должен иметь, помимо собственно значения, ещё указатель на эту таблицу.

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

     2016/07/14 12:14, rst256          # 

Предлагаю взглянуть на возможности аспектно-ориентированного программирования, например ACC аоп для языка си:
https://sites.google.com/a/gapp.msrg.utoronto.ca/aspectc/home
А здесь пара статей на русском об общим принципах данного подхода:
http://www.javable.com/columns/aop/

Добавить свой отзыв

Написать автору можно на электронную почту mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Содержание

Каким должен быть язык программирования?

Анализ и критика

●  Устарел ли текст как форма представления программы

●  Русский язык и программирование

●  Многоязыковое программирование

Синтаксис языков программирования

Синтаксический сахар

●  Некоторые «вкусности» Алгол-68

●  «Двухмерный» синтаксис Python

●  Почему языки с синтаксисом Си популярнее языков с синтаксисом Паскаля?

●  Должна ли программа быть удобочитаемой?

●  Стиль языка программирования

●  Тексто-графическое представление программы

●●  Разделители

●●  Строки программы

●●  Слева направо или справа налево?

●  Комментарии

●●  Длинные комментарии

●●  Короткие комментарии

●●  Комментарии автоматической генерации документации

●●  Нерабочий код

●●  Помеченные комментарии

●  Нужны ли беззнаковые целые?

●  Шестнадцатиричные и двоичные константы

●  Условные операторы

●  Переключатель

●  Циклы

●●  Продолжение цикла и выход из него

●  Некошерный «goto»

●  Изменение приоритетов операций

●  Операции присвоения и проверки на равенство. Возможно ли одинаковое обозначение?

●  Так ли нужны операции «&&», «||» и «^^»?

●  Постфиксные инкремент и декремент

●  Почему в PHP для конкатенации строк используется «.»?

●  Указатели и ссылки в C++

●●  Обработка ошибок

Использование памяти

●  Почему динамическое распределение памяти — это плохо

●  Как обеспечить возврат функциями объектов переменной длины?

●●  Типы переменного размера (dynamically sized types, DST) в языке Rust

●●  Массивы переменной длины в C/C++

●●  Размещение объектов в стеке, традиционный подход

●●  Размещение объектов переменной длины с использованием множества стеков

●●  Размещение объектов переменной длины с использованием двух стеков

●●  Реализация двухстековой модели размещения данных

●●  Двухстековая модель: тесты на скорость

●●  Изменение длины объекта в стеке во время исполнения

●●  Размещение объектов переменной длины с использованием одного стека

●  Можно ли забыть о «куче», если объекты переменной длины хранить в стеке

●  Безопасность и размещение объектов переменной длины в стеке

●  Массивы, структуры, типы, классы переменной длины

●  О хранении данных в стеке, вместо заключения

●  Реализация параметрического полиморфизма

Описание языка

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

Компьютерный юмор

Новости и прочее




Последние отзывы

2019/12/08 17:48 ••• Noname
Почему обречён язык Форт

2019/12/05 23:29 ••• Автор сайта
Слоны в комнате

2019/12/03 22:45 ••• Автор сайта
Следующие 7000 языков программирования: заключение

2019/12/03 22:36 ••• Автор сайта
Наблюдаемая эволюция языка программирования

2019/11/30 20:55 ••• Сергей
Каким должен быть язык программирования?

2019/11/09 21:27 ••• kt
Программирование без программистов — это медицина без врачей

2019/11/07 10:58 ••• kt
Признаки устаревшего языка

2019/10/28 23:55 ••• Автор сайта
Типы в инженерных задачах

2019/10/15 16:32 ••• kt
Модификация исполняемого кода как способ реализации массивов с изменяемыми границами

2019/10/07 14:15 ••• Автор сайта
О наименовании проекта и языка программирования

2019/09/19 15:23 ••• kt
Некошерный «goto»

2019/09/13 16:38 ••• Автор сайта
Программирование исчезнет. Будет дрессировка нейронных сетей