Основное назначение языка – донести информацию с минимальными искажением и потерями.
Смысл использования языка (назовем это общением) обусловлен субъектами общения, т.е. теми, кто “говорит” и “слушает”. Нет смысла передавать информацию, которую не способен понять говорящий или слушающий. Традиционные языки программирования ограничивают языковые средства до уровня понимания слушателя (компилятора) и говорящего (программиста). И это неплохо работает пока слушатель и говорящий неизменны.
Но если мы хотим использовать код каким-то другим образом, например, передать для доработки другому программисту или использовать совместно с другим кодом, то начинаются “проблемы перевода”. Всем “неожиданным” читателям и писателям была бы очень полезна та информация, которая отсечена при урезании до уровня понимания компилятора. Все то, что оказалось непонятым и ненужным компилятору “выдавливается” на бумагу в виде документации. И обрабатывается эта документация исключительно “вручную”.
Одним из проявлений этого является пресловутый закон Брукса, по которому добавление разработчика в команду замедляет процесс разработки. Это происходит в основном потому, что все то, что “отрезано” компилятором и осталось в документации и головах разработчиков, нужно “загрузить” в голову нового члена команды.
В идеале Программа – это не способ управления машиной. Это формализация знаний программиста о задаче и способах ее решения. Основное назначение современного языка программирования – позволить ему и _провоцировать_ его сделать это с минимальными искажениями и потерями. И язык должен позволять работать с собой на произвольном уровне понимания программиста. Поэтому он должен по крайней мере в основе своей быть независимым от “говорящего» и “слушающего”. Только тогда он сможет адаптироваться под каждого конкретного “пользователя”. Я сейчас пытаюсь изобразить что-то подобное на основе логики предикатов...
Кстати, предлагаю тест на “годность” языка. Дается задача. Берется некоторое кол-во программистов примерно одного уровня. Они пишут ее по очереди каждый один день, причем до “своего” дня он не знает о программе ничего. Параллельно один программист решает ту же задачу. Отношение времени решения вторым и первым способом потраченного в обоих вариантов и будет коэффициентом эффективности языка
О, спасибо Literate Programming — хорошая идеология, вот только изменение одного словав Literature части может соответствовать перелопачиванию половины Programming. И что-то при этом обязательно забывают перелопатить. И чем больше изменений, тем больше различия между тем, что программа делает и тем, что она делает на самом деле Классика...
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Кстати, предлагаю тест на “годность” языка. Дается задача. Берется некоторое кол-во программистов примерно одного уровня. Они пишут ее по очереди каждый один день, причем до “своего” дня он не знает о программе ничего. Параллельно один программист решает ту же задачу. Отношение времени решения вторым и первым способом потраченного в обоих вариантов и будет коэффициентом эффективности языка
Интересная идея. Я бы поучаствовал.
Прежде чем придумывать новый язык программирования подумайте над тем
— как писать парсер для него
— как писать run-time и кодогенератор для него
— как интегрировать программы на этом языке с библиотеками написанными на других языках
— какова будет поддержка компонентной разработки на этом языке
— можно ли импортировать код написанный на других языках в данный язык.
— будет ли язык иметь возможности для параллельного программирования.
— какова сложность создания IDE и библиотек для этого языка.
— насколько язык будет способен уживаться с системами контроля версий (Diff/Merge текстов и т.п)
— кто будет писать стандартные библиотеки
Здравствуйте, _Obelisk_, Вы писали:
_O_>Прежде чем придумывать новый язык программирования подумайте над тем
О, спасибо за списочек... Щас подумаем...
_O_>- как писать парсер для него
Текстовый язык хорошим быть не может Стандарт надо описывать без оглядки на текстовое представление.
Вообще у меня получается что-то похожее на MDA, но с исчислением предикатов вместо UML как базовой знаковой системой. И с понятиями вместо имен.
_O_>- как писать run-time и кодогенератор для него
Ну, сначала паразитировать на готовых рантаймах, а там-как получиться...
_O_>- как интегрировать программы на этом языке с библиотеками написанными на других языках
Примерно так же, как ассемблерные вставки с C или C с C++ или C++ с макросаим или шаблонами
Т.е. не навязывать свои правила, а приходить на помощь, когда исчерпаны средства основного языка программиста.
_O_>- можно ли импортировать код написанный на других языках в данный язык.
Нужно. И импортировать, и агрегировать. И вообще, каждый язык представляет какой-то образ мыслей и способы их представления.
_O_>- какова будет поддержка компонентной разработки на этом языке
Как основной модели разработки Т.е. любой кусок кода будет всеми силами пытать стать компонентом
_O_>- будет ли язык иметь возможности для параллельного программирования.
А как без этого?
_O_>- какова сложность создания IDE и библиотек для этого языка.
Порядка const*(сложность формулировки того, что они должны делать)
_O_>- насколько язык будет способен уживаться с системами контроля версий (Diff/Merge текстов и т.п)
Я как раз хочу избавиться от артефактов текстового представления... Соответственно, "родное" представление не должно быть текстовым...
Кстати, как с этим обстоит дело в MDA?
_O_>- кто будет писать стандартные библиотеки
Ну, разумеется, нужно уметь использовать библиотеки, написанные на других языках...
Раз какой-то интерес есть попытаюсь завтра более внятно описать что же у меня собственно получается...
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Текстовый язык хорошим быть не может Стандарт надо описывать без оглядки на текстовое представление. INT>Вообще у меня получается что-то похожее на MDA, но с исчислением предикатов вместо UML как базовой знаковой системой. И с понятиями вместо имен.
Как раз ошибаетесь. UML-ю недоставало текстового представления, мы (Telelogic) его придумали. Customer-ам нравится.
Скажем гораздо проще написать
Integer Sum (Integer A, Integer B) { return A+B; }
чем рисовать диаграмму.
Текстовое представление тут же парсится во внутреннее представление, являющееся обычной UML 2.0 моделью.
_O_>>- как писать run-time и кодогенератор для него INT>Ну, сначала паразитировать на готовых рантаймах, а там-как получиться...
Для того что вы хотите это не совсем хороший путь. Могут быть проблемы с трансформациями. Скажем станет их сложность порядка O(N^2) где N — число конструкций в программе на вашем языке.
_O_>>- как интегрировать программы на этом языке с библиотеками написанными на других языках INT>Примерно так же, как ассемблерные вставки с C или C с C++ или C++ с макросаим или шаблонами INT>Т.е. не навязывать свои правила, а приходить на помощь, когда исчерпаны средства основного языка программиста.
Не, не как С с С++, а скорее как Java с С++ или С# с ассемблером БЭСМ-6 . А интеграция жизненно необходима потому как у customer-ов будут куча библиотек с сотнями тысяч функций которые они захотят зареюзить.
_O_>>- можно ли импортировать код написанный на других языках в данный язык. INT>Нужно. И импортировать, и агрегировать. И вообще, каждый язык представляет какой-то образ мыслей и способы их представления.
Тоже множество проблем. Скажем попытайтесь создать модель одинаково подходящею для С++ и Java.
_O_>>- будет ли язык иметь возможности для параллельного программирования. INT>А как без этого?
А как с ними ? Вариантов ведь множество.
_O_>>- насколько язык будет способен уживаться с системами контроля версий (Diff/Merge текстов и т.п) INT>Я как раз хочу избавиться от артефактов текстового представления... Соответственно, "родное" представление не должно быть текстовым... INT>Кстати, как с этим обстоит дело в MDA?
Проблематично, пытаемся найти приемлимое решение. В общем случае Diff/Merge деревьев имеет сложность O(N^2).
Здравствуйте, _Obelisk_, Вы писали:
_O_>Как раз ошибаетесь. UML-ю недоставало текстового представления, мы (Telelogic) его придумали. Customer-ам нравится.
_O_>Не, не как С с С++, а скорее как Java с С++ или С# с ассемблером БЭСМ-6 . А интеграция жизненно необходима потому как у customer-ов будут куча библиотек с сотнями тысяч функций которые они захотят зареюзить.
У тебя только богатые американские клиенты? Или ты пессимист по жизни?
Одно дело, язык с научной стороны, а другое дело — с коммерческой.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, _Obelisk_, Вы писали:
_O_>>Как раз ошибаетесь. UML-ю недоставало текстового представления, мы (Telelogic) его придумали. Customer-ам нравится.
ВВ>А можно ссылочку? Не нашел на сайте
Здравствуйте, BUran, Вы писали:
_O_>>Не, не как С с С++, а скорее как Java с С++ или С# с ассемблером БЭСМ-6 . А интеграция жизненно необходима потому как у customer-ов будут куча библиотек с сотнями тысяч функций которые они захотят зареюзить. BU>У тебя только богатые американские клиенты? Или ты пессимист по жизни?
1. Богатые клиенты не у меня, а у компании, на которую мы работаем.
2. Да, я пессемист и иногда (очень редко) реалист . Данные о куче библиотек с сотнями тысяч функций и типов взяты из опыта. Более того, переучить гигантские корпорации на использование нового языка или методологии черезвычайно трудно. Обычно на все попытки приучения к хорошему стилю моделирования/программирования они заявляют, что они делают так как делали и будут так делать впредь.
BU>Одно дело, язык с научной стороны, а другое дело — с коммерческой.
Язык программирования призван все же решать практические задачи бизнеса и производства.
Здравствуйте, _Obelisk_, Вы писали:
_O_>>>Как раз ошибаетесь. UML-ю недоставало текстового представления, мы (Telelogic) его придумали. Customer-ам нравится.
Здравствуйте, Miem, Вы писали:
M>Здравствуйте, _Obelisk_, Вы писали:
_O_>>>>Как раз ошибаетесь. UML-ю недоставало текстового представления, мы (Telelogic) его придумали. Customer-ам нравится.
M>Когда .NET поддерживать будете?
Тогда, когда .Net станет работать под Linux-ом и Solaris-ом.
Здравствуйте, King Oleg, Вы писали:
INT>>Кстати, предлагаю тест на “годность” языка. Дается задача. Берется некоторое кол-во программистов примерно одного уровня. Они пишут ее по очереди каждый один день, причем до “своего” дня он не знает о программе ничего. Параллельно один программист решает ту же задачу. Отношение времени решения вторым и первым способом потраченного в обоих вариантов и будет коэффициентом эффективности языка KO>Интересная идея. Я бы поучаствовал.
Это надо еще придумать как организовать Например, как обеспечить честность "играющих".
Можно попробовать "блиц" — одна задача, пять часов, пять програмистов по очереди. Плюс добавление требований функционалу при каждой смене программистов IMHO было бы тренировкой Tean Work покруче стандартных правил ACM
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Можно попробовать "блиц" — одна задача, пять часов, пять програмистов по очереди. Плюс добавление требований функционалу при каждой смене программистов
при таких условиях каждый будет заново начинать переписывать
INT>>Кстати, предлагаю тест на “годность” языка. Дается задача. Берется некоторое кол-во программистов примерно одного уровня. Они пишут ее по очереди каждый один день
KO>Интересная идея. Я бы поучаствовал.
Ага. Пишем объявление "Требуется программист" и высылаем это дело как тестовое задание. Дёшево и сердито — социологическое исследование
Здравствуйте, mihailik, Вы писали:
INT>>Основное назначение языка – донести информацию с минимальными искажением и потерями. M>Во первых не вообще информацию, а алгоритм.
А вот нетушки, иногда не только алгоритм, а иногда не столько алгоритм.