Здравствуйте, licedey, Вы писали:

LVV>>Нет. Мы — программисты. И должны сами сделать такой инструмент, который НАМ удобен.
LVV>>Как в свое время сделали юникс — систему, которая удобна именно программистам.

L>НАМ удобен=нам привили=мы привыкли. Вспоминается Форд: "если бы я слушал что говорят люди, то они до сих пор бы ездили на повозках"
L>Однако...вопрос этого извечного "фии" на новые фиичи у коллег — это да.
Нет.
Так можно и Страуструпа послать. Он же фии сказал на Симулу. И решил, что надо в С нечто подобное вставить.
А еще Ричи раньше сказал фии на тогдашние языки программирования и сказал А В С.

LVV>Встраивать подобный инструмент в существующие — слишком геморно и не интересно.

там не надо встраивать -- все уже готово

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

думаю, тем чувакам вашу функциональность 100% повторить заняло бы меньше 1 человеко-дня, а я бы даже предположил где-то полчаса

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

LVV>К тому же — опыт проектирования, разработки и рефакторинга такого большого продукта гораздо более полезен, чем ковыряние в чужой работе.

NIH? а еще полезно первоначальный сбор инфы проводить

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, LaptevVV, Вы писали:

LVV>>http://ajc.su/koding/budushhee-programmirovaniya/
LVV>>

LVV>>[Автор оригинального текста — Paul Chiusano, программист, работает в Capital IQ, пишет преимущественно на Scala. Один из разработчиков библиотеки scalaz — прим. пер.]

GZ>Исчо один!!!
GZ>Невозможен универсальный DSL для всех программ. Теорема Геделя уже давно вещь сколько не математическая, а филосовская и доказанная на практике. Для подобных программ нужно просто отменить конкуренцию, и заставить пользователей покупать не то что они хотят, а то что им зают. А пока приходится менять уровни абстракции от уровня "Нарисуем форму", вплоть до хака переопределения функций в системных dll.
GZ>Автор утверждает, что мы уменьшим повторяемость. О каком уменьшении можно говорить, если: разработчик обычно пишет велосипеды не только на чужие модули, но и даже на уровне апи. То что надо знать еще до начала разработки. Автор выступает за увеличение сложности и неуправляемости типов. Флаг ему в руки... Точнее в культяпки, поскольку такие руки надо рубить. С чем нужно бороться? Может все таки бороться со сложностью?
GZ>Как сидели над вопросами 60-ых, как уменьшить нам сложность набора процедур. Так и сидят. Что касается уменьшения сложности, многомодульности, принципа разделяй и властвую — ноль.

Вы конечно загнули, насчет 60-ых. Давайте вспомним эволюцию ЯП. Давайте вспомним 90-ые. Что? С, паскаль, WinApi.
10 лет назад. Что? С++ MFC. 3-5 лет? .NET во всю, Java во всю, RAD разработка. Сегодня? Чувствуется C# уж не столь кардинально меняется, java конструкции, плюсы превратились воплотило все больные идеи с 70-ых годов и тащит этот ворох старья. Не холивара ради. Назревает необходимость в a) Кросс-аппаратности/платформенности/браузерности б) упрощении манипулирования абстракциями, не отвлекаясь на мелочи, мыслить по задаче в) от роста уровня абстрагирования от задачи, менять и ее представление. Еще довольно много "Хотелось бы", чего нет в силу зависимости от прошлого с одной стороны, и необъятных ресурсов для прорыва в будущее с другой. Но кто-то должен начать.

ME>>у них емнип уже че-то вроде импорта было, типа вставки из clipboard
LVV>Ну, это и у нас есть... Прямо уже сейчас...

т.е. оно все же умеет парсить, если из кармана вставляется хотя бы (А+В)*С-17 ?

Здравствуйте, licedey, Вы писали:

L>Я вот глобальных попыток не видел. Пример приведете? Чтобы например как тот же Делфи в свое время ахнул. Так что все впереди. Как автор написал — визуальных инструмент должен быть значительно лучше текстового аналога. Для кого-то в vim'e на Сях — лучше всего до сих пор.

Пиком человеческого прогресса на данный момент ялвляется Vim + Nemerle. С хорошим языком, из IDE бывает нужен только интеллисенс, при интенсивной работе с незнакомыми API. Существующие визуальные редакторы в лучшем случае подспорья для новичков или непрограммистов.

LVV>К тому же — опыт проектирования, разработки и рефакторинга такого большого продукта гораздо более полезен, чем ковыряние в чужой работе.

кстати, что меня удивляет -- что многие думают "программист пишет код", а ведь он в основном его читает

Последние десятилентия мы видим сдвиг в сторону использования готовых библиотек или готовых DSL и т.п. если лет 25 назад програмируя игру писалась и операционная ситстема . то сейчас используются готовые игровые движки.
Эта тенденция будет только увеличиваться.


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

Здравствуйте, m e, Вы писали:

ME>>>у них емнип уже че-то вроде импорта было, типа вставки из clipboard
LVV>>Ну, это и у нас есть... Прямо уже сейчас...

ME>т.е. оно все же умеет парсить, если из кармана вставляется хотя бы (А+В)*С-17 ?
Да, конечно.

Здравствуйте, m e, Вы писали:

LVV>>К тому же — опыт проектирования, разработки и рефакторинга такого большого продукта гораздо более полезен, чем ковыряние в чужой работе.

ME>кстати, что меня удивляет -- что многие думают "программист пишет код", а ведь он в основном его читает
Читаем, читаем. Много.

Здравствуйте, m e, Вы писали:

LVV>>Встраивать подобный инструмент в существующие — слишком геморно и не интересно.
ME>там не надо встраивать -- все уже готово
ME>там надо определить конструкции (ну или как их там... из которых состоит модель) и их внешнее представление, да еще и отнаследовать от существующих языков можно, дабы сократить время
ME>думаю, тем чувакам вашу функциональность 100% повторить заняло бы меньше 1 человеко-дня, а я бы даже предположил где-то полчаса
Возможно. Но мы лучше СВОИХ кадров рОстить будем...
ME>впрочем, у них там разница -- переменные вводятся тоже целиком, а не по буковкам, причем емнип с учетом области видимости
Ага. Мы тоже...
LVV>>К тому же — опыт проектирования, разработки и рефакторинга такого большого продукта гораздо более полезен, чем ковыряние в чужой работе.
ME>NIH? а еще полезно первоначальный сбор инфы проводить
Сбор инфы полезно на любой стадии проводить...
Мы с Вольфхаундом уже пообщались. Поизучаем, посторонние решения посмотреть всегда полезно.

Здравствуйте, minorlogic, Вы писали:

M>Последние десятилентия мы видим сдвиг в сторону использования готовых библиотек или готовых DSL и т.п. если лет 25 назад програмируя игру писалась и операционная ситстема . то сейчас используются готовые игровые движки.
M>Эта тенденция будет только увеличиваться.


M>Языки програмирования , никакой революции не происходит. Сдвиг будет когда JIT компиляторы смогут ложить на лопатки статические или например декларативные смогут избавляться от лишних накладных расходов.

SQL, вроде как, уже давно успешно занимается и тем, и другим
да и регэкспы недалеко.
Оба декларативные и обы выигрывают у _средней_ рукопашной реализации.

You will always get what you always got
  If you always do  what you always did

LVV> Поизучаем, посторонние решения посмотреть всегда полезно.

потом мне (или всем) расскажите, к каким выводам пришли, какие недостатки у MPS заметили и т.п.

интересно

Здравствуйте, m e, Вы писали:

LVV>> Поизучаем, посторонние решения посмотреть всегда полезно.
ME>потом мне (или всем) расскажите, к каким выводам пришли, какие недостатки у MPS заметили и т.п.
ME>интересно
Ок.

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, minorlogic, Вы писали:

M>>Языки програмирования , никакой революции не происходит. Сдвиг будет когда JIT компиляторы смогут ложить на лопатки статические или например декларативные смогут избавляться от лишних накладных расходов.

J>SQL, вроде как, уже давно успешно занимается и тем, и другим
J>да и регэкспы недалеко.
J>Оба декларативные и обы выигрывают у _средней_ рукопашной реализации.

Хорошие примеры но довольно специфичные. Может скоро доберемся до языков общего назначения.

Забыл еще упомянуть про LLVM и т.п., которая на мой взгляд дозрела до солидного возраста. Может хороший сдвиг дать, как в технологиях програмирования , так и взаимодействия с железом и создание инструментальных средств.

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

В интересно время же живем

Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, jazzer, Вы писали:

J>>Здравствуйте, minorlogic, Вы писали:

M>>>Языки програмирования , никакой революции не происходит. Сдвиг будет когда JIT компиляторы смогут ложить на лопатки статические или например декларативные смогут избавляться от лишних накладных расходов.

J>>SQL, вроде как, уже давно успешно занимается и тем, и другим
J>>да и регэкспы недалеко.
J>>Оба декларативные и обы выигрывают у _средней_ рукопашной реализации.

M>Хорошие примеры но довольно специфичные. Может скоро доберемся до языков общего назначения.

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

M>Забыл еще упомянуть про LLVM и т.п., которая на мой взгляд дозрела до солидного возраста. Может хороший сдвиг дать, как в технологиях програмирования , так и взаимодействия с железом и создание инструментальных средств.

Да, LLVM много кем юзается на очень низком уровне.

M>Так же революция может прити со стороны суперкомпиляции, тогда языки срочно подтянутся за требованиями оптимизаторов.

M>В интересно время же живем
+100

You will always get what you always got
  If you always do  what you always did

Здравствуйте, minorlogic, Вы писали:

M>Последние десятилентия мы видим сдвиг в сторону использования готовых библиотек или готовых DSL и т.п. если лет 25 назад програмируя игру писалась и операционная ситстема . то сейчас используются готовые игровые движки.
M>Эта тенденция будет только увеличиваться.
Плюс тыщапитцот. Отдельновзятый коммунизм наступит тогда, когда я буду сидеть у плевательного монитора. Плюнул влево- бухгалтерия поднялась, плюнул влево — делопроизводство синтегрировалось, плюнул вниз — тетрис синтегрировался. И тут еще и начальника пришла, денюшки принесла, и высказала свою строгую, но верную оценку моей гениальности. И никакого тестирования.
На данный момент, вопрос интегрирования DSL как стоял, так и в стоячем состоянии стоит. Начиная с времен корбы. От библиотек мы далеко не ушли. Нам приходится выбирать различные интерфейсы, а иногда и переписывать велосипеды, поскольку понять и осязать готовые уже не в состоянии. Приходится думать о форматах сохранения, способах доступа к данным, вместо того чтобы решить, нужно сохранять или нет.
Попытки совметить несовметимое пока ничтожны. Занимаемся синтаксисом вместо семантики. Счастливого будущего — нет. Пули есть, но не серебрянные, и все в мозг.

M>Языки програмирования , никакой революции не происходит. Сдвиг будет когда JIT компиляторы смогут ложить на лопатки статические или например декларативные смогут избавляться от лишних накладных расходов.
Разделение языков по уровню было, есть и будет. Многим и сейчас приходится помнить что такое ассемблер.

Здравствуйте, licedey, Вы писали:

GZ>>Как сидели над вопросами 60-ых, как уменьшить нам сложность набора процедур. Так и сидят. Что касается уменьшения сложности, многомодульности, принципа разделяй и властвую — ноль.

L>Вы конечно загнули, насчет 60-ых. Давайте вспомним эволюцию ЯП. Давайте вспомним 90-ые. Что? С, паскаль, WinApi.
L>10 лет назад. Что? С++ MFC. 3-5 лет? .NET во всю, Java во всю, RAD разработка. Сегодня? Чувствуется C# уж не столь кардинально меняется, java конструкции, плюсы превратились воплотило все больные идеи с 70-ых годов и тащит этот ворох старья.
В остальном согласен кроме датировки. В 90-ые VB,Java, Delpha и еще PowerBuilder. То есть RAD уже был. Я свидетель. Вышеупомянутые С, паскаль — 70-ые, и то с сильным влиянием Алгола(особенно такого монстра как Алгол-68). Ничего кардинально нового с 60-ых годов не придумано. Разве что различные VM(кажется 70-ые) и связанных с http технологий.

Здравствуйте, LaptevVV, Вы писали:

LVV>Интересный фактец. Пацан, которые пишет сам семантический редактор, признался.

Ключевое слово выделено.

Здравствуйте, LaptevVV, Вы писали:

LVV>

LVV>Как будет выглядеть программирование через 10-20 лет?

Первую свою программу я написал более двадцати лет назад.
Далее только тезисные заявления. Доказательства — через 20 лет

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

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

Редактирование кода будет производиться в структурных редакторах, которые будут совсем не похожи на современные IDE

IDE несомненно сильно разовьются, но останутся узнаваемыми и похожими на сегодняшние средства.

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

Это вряд ли. По психологическим причинам.

Распространение кода и будущее web.

Этот вопрос крайне сложен. Глядя в свой магический жидкий кристалл Я вижу две разнонаправленные тенденции: 1) разделение web'a на слабовзаимодействующие домены 2) усилия по созданию p2p сетей и облаков на их основе.

Предвижу будущее, в котором Javascript постепенно отходит на второй план, как уходят и специализированные плагины для браузеров вроде Flash, уступая место коду, написанному на произвольных, компилируемых языках, использующих для работы что-нибудь вроде NaCl. Это будет совмещено с кешированием подписанного кода и механизма отслеживания зависимостей, так что, например, станет возможным предоставить приложение, которое подгружает виртуальную машину Java и другие зависимости, если они еще не закешированы на вашем компьютере и подписи совпадают. Это изменяет способ мышления о программном обеспечении. ПО не всегда будет чем-то из категории «скачай это себе на компьютер и запусти». Напротив, ПО существует «само по себе», а вы его запускаете. Как деталь реализации процесса запуска вы можете позволить подгрузить дополнительный код, который нужен ему для работы.

С этим я согласен. Тут интересно рассмотреть маркетинговую составляющую.

Я уже намекал на это: функциональное программирование бесспорно победит

Нет. Это спорно. Функциональное программирование может победить исключительно за счёт автоматической параллелизации исполнения. В любом случае о полной победе речь идти не может.

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

ЗЫ Всё это при условии, что ИИ не будет создан.

Здравствуйте, LaptevVV, Вы писали:

LVV>Он для проверки интерпретатора пишет в нем тестовые проги — довольно много.

Пусть он для проверки работоспособности идеи напишет не много мелких прог, а одну большую, без чёткихх требований, а потом хорошенько её порефакторит.

LVV>И пацан заметил за собой, что в студии на шарпе он стал писать структурный текст.
LVV>И что смешно. По его собственному признанию проги стали получаться проще, понятней и с меньшим количеством ошибок.

Кто же спорит. Возможно это навело у него порядок в голове и он научился лучше писать "довольно много тестовых прог".