Являются ли сегодняшние языки общего назначения на правильном уровне абстракции?

Сегодня Дядя Боб Мартин , настоящий герой, показал этот видео

В этом видео Bob Martin утверждает, что наши языки программирования находятся на правильном уровне для наших проблем в это время. Одна из причин, которые я получаю от этого видео, так как Боб Мартин видит нас в качестве менеджеров деталей, и наши проблемы находятся на уровне детализации.

Это первый раз, когда я должен не согласиться с Бобом Мартином и задавался вопросом, что думают об этом люди у программистов.

Сначала существует разница между MDA и MDE MDA сама по себе не сработала, и я обвиняю в значительной степени формализации на уровне, который вы не можете формализовать в этих проблемах. MDE и MDD все еще пытаются проявить себя и, на мой взгляд, показывают большие перспективы. например посмотрите MetaEdit

Детали по-прежнему должны быть в моем управлении, но вы делаете это в одном месте (каркас или генераторы), а не в нескольких местах.

Право на наши проблемы? Я думаю, зависит от того, на какие проблемы вы смотрите. Поддерживают ли текущие языки программирования текущие требования во времени на рынок? Являются ли они хорошими для преодоления разрыва в сфере информационных технологий в бизнесе?

И что вы думаете?

6 голосов | спросил KeesDijk 6 Jam1000000amThu, 06 Jan 2011 11:56:27 +030011 2011, 11:56:27

6 ответов


13

Будучи исследователем и ученым, я узнал некоторые простые правила, и самое главное - не позволять моему воображению устанавливать границы. Я имею в виду тот факт, что я не могу представить, что лучший способ абстрагировать сегодняшние проблемы не означает, что его не существует. Это не означает, что другой подход не полностью изменит способ мышления о программировании и, следовательно, мое понимание абстракции.

В рыночном смысле это действительно о конкуренции. Если у кого-то нет überlang, то , конечно, текущие языки, похоже, решают проблемы на соответствующем рынке уровне. Ожидания разумного развития с технологией.

Если вы прочтете некоторые из рассказов Пола Грэма о Лиспе, вы увидите, что он считает, что его конкурентное преимущество было überlang, Lisp. Вы также увидите некоторые довольно сильные заявления об уровне абстракции, предоставляемой Lisp, и о том, как он отличается от, скажем, Python. Я смущаюсь утверждать, что такие претензии заслуживают ... но он составил 48 миллионов долларов, написав код Lisp, и я этого не сделал. Это добавляет к его уличному кредиту, на мой взгляд.

Если предположить, что Грэхем прав, то мы можем только заключить, что семейство деревьев Fortran языков медленно доходит до уровня абстракции, доступного в 1957 году пользователям семейных языков Lisp. Это смелое утверждение, но если это правда, чем сегодняшние языки (потомки Fortran, я имею в виду), не вполне адекватны сегодняшним вызовам.

Но Грэм не должен быть прав, чтобы дядя Боб ошибся. Дядя Боб ошибается, если дядя Боб не имеет полного знания того, что возможно. Нам нужно в значительной степени использовать языки, которые мы используем, и парадигму, в которой мы работаем, а не наоборот.

ответил philosodad 6 Jpm1000000pmThu, 06 Jan 2011 14:57:39 +030011 2011, 14:57:39
11

У меня нет проблем с «уровнем» существующих языков, и я был основательным учеником Lisp-ism, но весь этот разговор действительно беспокоит меня.

Меня это беспокоит, потому что мы используем really , который мы и другие создали поверх , что предоставляет компилятор или интерпретатор. Существительные, глаголы, синтаксис и семантика состоят не только из того, что появилось «из коробки», но и из каких библиотек мы включили, какие классы и методы мы определили, какие макросы мы написали, какие у нас есть переводчики закодированные, какие парсеры и генераторы кода мы написали.

Не существует четкой разделительной линии между , использующей язык, и создание языка. Это больше похоже на ракеты, взлетающие в космос. В каждом пункте он использует то, что он создал ранее. Подобно тому, как ракета ускоряется в определенном направлении, исключая других, наша программа /язык все больше и больше строится по конкретной проблеме, которую мы решаем. Он становится все более и более специфичным для домена языком (DSL).

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

Я знаю, что люди собираются сказать: «Ну, разве это не то, что должен был делать UML?» Ответ в том, что он не мог, именно потому, что он был предопределен. Язык, специфичный для домена, является именно этим. Общий язык домена полезен, если он может быть эффективно преобразован в язык, специфичный для домена.

ответил Mike Dunlavey 6 Jpm1000000pmThu, 06 Jan 2011 17:14:29 +030011 2011, 17:14:29
3

Я думаю, что одна из вещей, которую он говорит, прав.

  

Языки программирования сегодня находятся на правильном уровне абстракции.

Но я думаю, что, хотя в будущем мы можем использовать те же языки, что и сегодня, потому что компиляторы становятся лучше, а процессоры быстрее getter (так как в них можно делать больше вычислений в секунду), мы можем работать на более высоком уровне, где нам не нужно беспокоиться о деталях производительности.

Это уже произошло с большинством задач и ростом и ростом динамических языков, таких как python и ruby, но по мере того как компиляторы улучшатся, мы сможем начать писать такие вещи, как базы данных и, возможно, в конечном итоге модули ядра и операционные системы в этом стиле.

ответил dan_waterworth 6 Jpm1000000pmThu, 06 Jan 2011 12:15:37 +030011 2011, 12:15:37
2

Мне приходит в голову эпиграмма «Алан Перлис»: «Язык программирования низкий, когда его программы требуют внимания к нерелевантности».

Кроме того, я предпочитаю программировать как управление сложностью, а не управление деталями.

Во многих словах, если мы сможем уйти от знания о микрокодах и еще не писать много программных средств (даже уйти даже из-за особенностей оборудования), с чем еще мы сможем справиться? Возможный ответ: любые вычислительные явления мы можем создать модель для (подумайте о операционных системах, грамматиках соответствия шаблонов, управлении памятью, потоке данных, транзакциях с программной памятью и т. Д.) И сделайте ее достаточно общей и достаточно гибкой, чтобы мы могли чувствовать себя комфортно с выполнением умственная магия, называемая «абстрагированием» множества нежелательных деталей сложных явлений, с которыми мы имеем дело.

Итак, я не думаю, что сегодняшние общепринятые языки никоим образом не приближаются к моим личным ожиданиям.

ответил Thiago Silva 6 Jpm1000000pmThu, 06 Jan 2011 14:37:04 +030011 2011, 14:37:04
1
  

Боб Мартин видит нас в качестве менеджеров деталей, и наши проблемы находятся на уровне детализации.

Наши проблемы находятся на уровне детализации, потому что мы являемся менеджерами деталей. Если бы мы работали на более высоком уровне абстракции, детали позаботились о себе, и нам больше не пришлось бы управлять ими.

ответил stonemetal 6 Jpm1000000pmThu, 06 Jan 2011 18:10:09 +030011 2011, 18:10:09
1

Я согласен с дядей Бобом, что нам не нужно MDA на вершине языка программирования. Я разработчик java и почему для моего кода генерируется автоматически, если модель не может обрабатывать подробную информацию управления. Говоря о том, что я не согласен с тем, что UML не является подходящим уровнем абстракции, который нам нужен для нашего проекта, если мы не ожидаем, что UML приведет наше поколение кода. Я имею в виду, что для меня UML - это фантастический язык, который должен использоваться во всех проектах, но MDA, MDD и т. Д. Не должны ...

Многие проекты используют только доски, тогда как легкий UML был бы намного более подходящим. Вам не обязательно быть экспертом, а просто использовать свой мозг и иметь возможность говорить об объекте на уровне Java и модели. Если вы не знаете UML, просто создайте диаграммы классов, чтобы создать скелет вашего приложения.

Я использую расширенный UML, который генерирует только мой код, когда мне это нужно, и какая модель обновляется, когда я просто код. Просто чудесная технология, которая позволяет мне создать мою архитектуру, а затем начать код, вернуться к моей модели и снова вернуться к коду, не теряя при этом никакой информации и имея очень хорошо написанный код. Механизм, который я использую, - это инкрементное слияние модели, разработанное Omondo. Нет MDD или MDA с Omondo, но слияние между Java и UML-идентификаторами.

Вы когда-нибудь замечали, что UML 2.3 имеет ту же архитектуру, что и C # и Java? У этого есть пакеты, классы, атрибуты, методы, а также может обрабатывать ограничения на методы, которые являются данными управления Говорит дядя Боб. Проблема в том, что задание спецификации OMG, которое является абсолютно фантастическим, имеет дело с метамодели, в то время как обсуждаются только диаграммы UML. Я имею в виду, что UML не должен быть просто графическим или MDA, MDD. UML должен быть всей моделью проекта с диаграммами UML просто зрителем модели, а не самой моделью! Проблема в том, что инструменты используют слои преобразования для создания кода и моделей, а не официальной спецификации, которая является метамодели UML 2.3!

ответил UML_GURU 11 Jpm1000000pmTue, 11 Jan 2011 12:40:01 +030011 2011, 12:40:01

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132