Re: Будущее программирования - обсудим?
От: IT Россия linq2db.com
Дата: 08.02.12 16:39
Оценка: 37 (7) +3
Здравствуйте, LaptevVV, Вы писали:

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


Отпишусь ещё раз по существу.

Я не верю в будущее без настоящего. То, что будет завтра, вовсю проявляет себя, так или иначе, уже сейчас. То, что будет через 10-20 лет, уже маячит где-то на горизонте, вызывает определённый интерес у энтузиастов и уже удивляет нас своими пусть пока наивными, но вполне осязаемыми возможностями.

Никаких предпосылок для появления визуального программирования на сегодняшний день не наблюдается вообще. Всё как раз совсем наоборот. От визуальных редакторов сегодня нередко отказываются. Взять тот же ASP.NET MVC, на мой взгляд, лучшая на сегодня среда для разработки веб приложений. Визуальный редактор в ней отсутствует совсем, хотя до этого на протяжении 10 лет ASP.NET навязчиво предлагал писать html не руками, а размазывать его по экрану мышкой.

Так что же с будущим? Неужели его нет? Есть. И мы можем наблюдать его проявления уже сейчас.

В первую очередь это DSL. В качестве примера возьмём Linq. Типичный встроенный в C# специализированный язык. В умелых руках в разы повышает производительность разработки приложений, работающих с БД. Эта вещь уже в мэйнстриме и очень неплохо себя зарекомендовала. Следующий пример тот же ASP.NET MVC со своим Razor. Результат при смешивании C# и html обычно выглядит крайне печально, а здесь всё получается очень аккуратно и читабельно. Не думал что такое вообще возможно. А если учесть, что связующим языком в данном случае является C#, а в нём есть Linq, то вот вам и привет из будущего — три языка в одном коде, удачно дополняющих друг друга.

Пока в этом направлении есть только одна проблема – относительная сложность разработки своих собственных DSL, т.к. сегодня недостаточно просто придумать язык и написать к нему компилятор. Нужна ещё поддержка средств разработки, таких как Visual Studio, Idea и т.п.

Вторым направлением является, конечно же, функциональное программирование. Здесь автор статьи прав. Рано или поздно оно будет в мэйнстриме. О нём много говорят, им интересуются, элементы ФП проникают в мэйнстрим языки и довольно неплохо там приживаются. О причинах этого я уже писал здесь
Автор: IT
Дата: 24.10.08
. Всё теоретическое в программировании уже придумано лет 20-ть назад, если не больше. Теперь дело лишь за переосмыслением всего этого массами и реализацией в мэйнстриме.

Третья вещь – это метапрограммирование. Мы уже сейчас вовсю его используем, хотя можем этого и не замечать. В студии море скрытых генераторов кода. От визардов, до редакторов всяческих схем. Есть и более доступные вещи, вроде T4. Но мы пока не научились этим толком пользоваться. В результате одни пишут целые фреймворки для поддержки, например, баиндинга в WPF, тормознутые по своей сути, а другие берут T4 и за пол дня на коленке делают шаблон, который генерирует для их задачи всё, что может понадобиться, получая при этом гораздо более гибкий и производительный код.

Вообще возможности метапрограммирования пока плохо изучены. То, что мы имеем сейчас – это генерация кода либо до, либо после компиляции. А что если нам дадут в руки расширяемый компилятор? Microsoft что-то ковыряет в этом направлении, но похоже уже умудрилась сбиться с правильного пути. Но есть и другие альтернативы. И их можно попробовать и оценить уже сейчас.

Они уже есть и значит у них есть будущее. А то, о чём говорит автор статьи существует лишь в его собственном воображении.
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Будущее программирования - обсудим?
От: IT Россия linq2db.com
Дата: 08.02.12 16:41
Оценка: :)))
Здравствуйте, IT, Вы писали:

IT>Они уже есть и значит у них есть будущее. А то, о чём говорит автор статьи существует лишь в его собственном воображении.


Кстати, забыл добавить сакраментальное "Казалось бы, причём тут Немерле?".
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Будущее программирования - обсудим?
От: Hobot Bobot США  
Дата: 08.02.12 18:00
Оценка: :)
Здравствуйте, LaptevVV, Вы писали:

LVV>Имена, константы, выражения — это требует редактирования ручного. А сама структура конструкции оператора редактирования не требует.

LVV>Он добавляется в модель одной клавишей. Одной же и удаляется.

Здравствуй, ZX Spectrum?
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Re: Будущее программирования - обсудим?
От: minorlogic Украина  
Дата: 08.02.12 18:45
Оценка: +1
Кстати забыл добавить, что в визуальное програмирование я не сильно верю. Скорее очень постепенное , эволюционное развитие IDE средств для поддержки языковых.

Например даже в очень user frendly приложениях со своими DSL слишко часто используют текст (макросы excel текстовые) и т.д.

Так же могу предположить эволюцию различных анализаторов кода и генераторов типа UML -> code , code -> UML, DSL ->code и т.п.
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[5]: Будущее программирования - обсудим?
От: blackhearted Украина  
Дата: 08.02.12 19:04
Оценка: 1 (1)
Здравствуйте, Don Reba, Вы писали:

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


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


DR>Пиком человеческого прогресса на данный момент ялвляется Vim + Nemerle.



Re[2]: Будущее программирования - обсудим?
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 08.02.12 19:58
Оценка: +1
Здравствуйте, IT, Вы писали:

IT>А что если нам дадут в руки расширяемый компилятор?


Тогда вместо решения насущных задач программисты начнут расширять компилятор.
Re[3]: Будущее программирования - обсудим?
От: IT Россия linq2db.com
Дата: 08.02.12 20:35
Оценка: +1 :)
Здравствуйте, velkin, Вы писали:

V>Тогда вместо решения насущных задач программисты начнут расширять компилятор.


Это стандартное заблуждение. Программисты и сейчас занимаются всякой фигнёй только дай волю. Строительство завода для производства гвоздя (одного!) является обычным развлечением большинства 'зи архитектов'.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Будущее программирования - обсудим?
От: quwy  
Дата: 08.02.12 23:47
Оценка:
LVV>Мы у себя делаем семантический редактор, который с текстами не работает.
LVV>Первая часть компилятора физически отсутствует — фактически требуют анализа только выражения.
LVV>Но на экране — текст, который читает человек.
ZX Spectrum изобретаете заново?
Re[4]: Будущее программирования - обсудим?
От: dimgel Россия http://dimgel.ru/
Дата: 09.02.12 05:54
Оценка:
Здравствуйте, licedey, Вы писали:

L>Я вот глобальных попыток не видел. Пример приведете? Чтобы например как тот же Делфи в свое время ахнул. Так что все впереди.


Я вот летающих крокодилов не видел. Так что всё впереди.
А примеры в той ветке приводились.
Re: Будущее программирования - обсудим?
От: vladimir_i СССР  
Дата: 09.02.12 08:03
Оценка: :)
Здравствуйте, LaptevVV, Вы писали:

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

LVV>

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

LVV>Как будет выглядеть программирование через 10-20 лет? В канун нового года самое время пофилософствовать о будущем нашей индустрии. Мы находимся на пороге значительных изменений в деле написания программ, по сравнению с которыми нынешние, 2011 года, техники и идеи будут выглядеть примитивными. Изменения будут происходить в нескольких важных областях: инструментария и инфраструктуры, языков и систем типов, систем времени исполнения.
LVV>...


А зачем в принципе что-то кардинально улучшать? Неужели существующих средств не достаточно для решения всех мыслимых задач?

Запрос на изменения должен исходить извне — от производителей новых устройств (смартфоны, например), новых процессоров (квантовых в будущем), новых прикладных сервисов и технологий (web, социальные сети, облака и.т.д.).
Re[2]: Будущее программирования - обсудим?
От: GlebZ Россия  
Дата: 09.02.12 08:13
Оценка: +1
Здравствуйте, IT, Вы писали:

IT>Отпишусь ещё раз по существу.

Фи, мужчина, вы какой-то приземленный. Нешогласная я!(с)ни я ни разу.

IT>Я не верю в будущее без настоящего. То, что будет завтра, вовсю проявляет себя, так или иначе, уже сейчас. То, что будет через 10-20 лет, уже маячит где-то на горизонте, вызывает определённый интерес у энтузиастов и уже удивляет нас своими пусть пока наивными, но вполне осязаемыми возможностями.


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

Ишь ты. Ты знаешь какие бабки крутятся в ERP, CRM???? А знаешь сколько сайтов сделано с помощью CMS??? Пекут как пирожки без всякого MVC. Сидят, рисуют и думают о чем то теплом. Например, о бабах.

IT>ASP.NET навязчиво предлагал писать html не руками, а размазывать его по экрану мышкой.

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

IT>В первую очередь это DSL. В качестве примера возьмём Linq.

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

IT>Вторым направлением является, конечно же, функциональное программирование.

Рок&ролл — мёртв. ФП — мёртв. Мы — зловещие мертвецы. 30 лет назад, это тоже было перспективным направлением. Если на основе различных ФП мозгляки придумывали различные непотребные вещи, которые потом ввели в мейнстрим, это не значит что сам ФП станет мейнстримом. Некоторые средства — да. Само ФП — нет. И это следует считать доказанным, опытным путем, фактом.

IT>Третья вещь – это метапрограммирование.

Метапрограммирование вещь сама в себе. Метапрограммирование — может дать декларативность. Но в то же время, может и не дать. И тогда она чрезвычайно опасная штука, вводящая зависимости какие в ООП не снились, и сложность на уровне — перед тем как подойти к клавиатуре, давайте выучим Войну и Мир наизусть. Суперкомпиляция, IMHO, выглядит более перспективным. Однако его развитие с 60-ых было нулевым. В общем полное ХЗ в моем ИМХО.
Re[3]: Будущее программирования - обсудим?
От: dimgel Россия http://dimgel.ru/
Дата: 09.02.12 11:48
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Через 10-20 лет я вообще не хочу видеть html. Это язык для несложных презентаций времен телефонных модемов.


Через 10-20 лет я вообще не хочу видеть txt. Это язык для несложных документов времен до телефонных модемов.
Сложные веб-приложения — обсуждаемо (но не потому что html, а потому что js), а простой rich-formatted text по-любому нужен и будет нужен. Из мне известных, html — самый простой.
Re[3]: Будущее программирования - обсудим?
От: IT Россия linq2db.com
Дата: 09.02.12 16:11
Оценка:
Здравствуйте, GlebZ, Вы писали:

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

GZ>Ишь ты. Ты знаешь какие бабки крутятся в ERP, CRM???? А знаешь сколько сайтов сделано с помощью CMS??? Пекут как пирожки без всякого MVC. Сидят, рисуют и думают о чем то теплом. Например, о бабах.

Мы тут говорим о программировании, а не о рисовании. Разве нет?

IT>>ASP.NET навязчиво предлагал писать html не руками, а размазывать его по экрану мышкой.

GZ>Через 10-20 лет я вообще не хочу видеть html.

А придётся.

IT>>В первую очередь это DSL. В качестве примера возьмём Linq.

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

Ты о чём?

IT>>Вторым направлением является, конечно же, функциональное программирование.

GZ>Рок&ролл — мёртв. ФП — мёртв. Мы — зловещие мертвецы. 30 лет назад, это тоже было перспективным направлением. Если на основе различных ФП мозгляки придумывали различные непотребные вещи, которые потом ввели в мейнстрим, это не значит что сам ФП станет мейнстримом. Некоторые средства — да. Само ФП — нет. И это следует считать доказанным, опытным путем, фактом.

Можно подробнее про опыты?

IT>>Третья вещь – это метапрограммирование.

GZ>Метапрограммирование вещь сама в себе. Метапрограммирование — может дать декларативность. Но в то же время, может и не дать. И тогда она чрезвычайно опасная штука, вводящая зависимости какие в ООП не снились, и сложность на уровне — перед тем как подойти к клавиатуре, давайте выучим Войну и Мир наизусть.

Я выше приводил пример про баиндинг. Написать шаблон на T4, который решает проблемы, которые решают некоторые навороченные фреймворки, у меня заняло пол дня.

Ну а хрен себе при желании отстрелить можно чем угодно. Не обязательно для этого использовать сложный, изощрённый механизм. Можно просто засунуть его в электрическую мясорубку. Нажимаем кнопку 'Вкл' до характерного звука 'счёлк' и вот тебе к столу фарш их хрена.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Будущее программирования - обсудим?
От: m e  
Дата: 09.02.12 17:21
Оценка:
IT>Это стандартное заблуждение. Программисты и сейчас занимаются всякой фигнёй только дай волю. Строительство завода для производства гвоздя (одного!) является обычным развлечением большинства 'зи архитектов'.

в связи с этим надо помочь им это делать намного быстрее -- это сэкономит время, теряемое впустую, и значит принесет прибыль работодателю
Re: Будущее программирования - обсудим?
От: PSV100  
Дата: 09.02.12 22:28
Оценка:
Предлагаю глянуть на ДРАКОН — один из редчайших графических языков программирования, который доказал себя на промышленной (!!!!!!) практике. Это визуальный алгоритмический язык, напоминающий блок-схемы, на устремлённых графах. Разрабатывался для проекта Буран и сейчас задействован в космической промышленности. С его помощью удалось решить реально огромную проблему: программисты знают как писать программы, но не понимают сложной предметной области, инженеры — не понимают программы, и, тем более, как программировать. Теперь инженеры сами создают управляющие приложения для оборудования — через описания и схемы.

Одна ремарка по этому поводу. Я реально не представляю как рисовать такие огромные схемы. Инженерам, имхо, проще начертить на A1 и пускать под сканер и т.д. Программерам проще лабать в каком-нибудь эмаксе в виде текстовых псевдо-схем:

...
|
|- блок 1
|- блок 2
...
и т.п.

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

Дракон дал хороший вывод: программистам — программилово, инженерам — естественные для них схемы. Поэтому текстовое представление программ никуда не денется. И в ближайшую эпоху кардинально ничего не перевернётся: бизнес будет давить net-ом с жабой (или что там будет), кто по-практичнее и менее политично угнетён — кложура, эрланг, какой-нибудь Go, в системном уровне вряд ли потеснится С/С++, кому нужно, тот будет дружить с ФЯ, матязыками, языками для рисования нот и т.д. и т.п. Безусловно всё потихоньку будет развиваться в своём русле.

Кардинальный перелом будет тогда, когда наконец-то разрешат вылезти кванто/био/нано/и пр. -процессорам, сверх-быстрым с одновременным многовариантным состоянием в единицах памяти вместо 0 и 1. И когда наконец-то родят для них доказательную математическую модель вместо ныне действующей двоичной алгебры. Тогда начнутся настоящие параллельные вычисления, и что там будет — пока никому не снилось...
Re[2]: Это, скорее, от недостатка погромистов...
От: os24ever
Дата: 10.02.12 00:15
Оценка:
PSV>Это визуальный алгоритмический язык, напоминающий блок-схемы, на устремлённых графах.

Этто ффсё от недостатка погромистов и их руководителей в подобных проектах.

Зачем погромисту переться в г. Королёв, когда он может поднять столько же денег в Нерезиновске, быстро-быстро высирая сайты-визитки или медленно-медленно автоматизируя бизнес-процессы под лампами дневного света.

PSV>Я реально не представляю как рисовать такие огромные схемы.


До тех пор, пока на них линии не пересекаются. Плавали, знаем. Вызовы функций в Си потребовали уже трёхмерных схем (а не блок-схем). Так-то.
дракон язык космонавтика
Re[3]: Это, скорее, от недостатка погромистов...
От: PSV100  
Дата: 10.02.12 10:35
Оценка:
Здравствуйте, os24ever, Вы писали:

PSV>>Это визуальный алгоритмический язык, напоминающий блок-схемы, на устремлённых графах.


O>Этто ффсё от недостатка погромистов и их руководителей в подобных проектах.


O>Зачем погромисту переться в г. Королёв, когда он может поднять столько же денег в Нерезиновске, быстро-быстро высирая сайты-визитки или медленно-медленно автоматизируя бизнес-процессы под лампами дневного света.


PSV>>Я реально не представляю как рисовать такие огромные схемы.


O>До тех пор, пока на них линии не пересекаются. Плавали, знаем. Вызовы функций в Си потребовали уже трёхмерных схем (а не блок-схем). Так-то.


Конечно криворукие программисты и такие же руководители там есть, да и везде они. Я давненько изучал материалы по этому дракону, но, насколько я помню, основная проблема всё-таки была иного плана, и квалифицированных нормальных прогеров они привлекали не мало. В их космолетах настолько специфичное оборудование, что компьютеры они напоминают ну очень отдаленно: по своему устройству они крайне просты, минимум потребление энергии и главное — сверхнадежность, потом всё остальное. Управляются эти компы очень замысловатыми командами и по специфичным принципам, ни на какой ассемблер и близко не похоже. Писать программы для прямого транслятора в машкод — так и не смогли осилить. Попытались реализовать конверторы через С — не всё гладко. Основная картина при разработке была такая: сидит пятидесятилетний дядька рядом с программером, у него в голове разрез двигателя со всеми схемами и напрочь не понимает про какие циклы с указателями ему говорит программист, а пацану в голову этот разрез двигателя не впихнешь. Как-то так. Покумекали они, и решили — пусть инженеры сами рисуют себе алгоритмы, а те только рады были, для них это родное и тёплое. Так и выкрутились.

А схемы эти реально полезные. Основная идея — чтобы как раз не было пересекающихся линий, и здорово выручает. В своей практике использовались: просто рисовались на бумаге схемы в таком стиле вместо ранее не пойми какого велосипеда со стрелками туда-сюда. Показывалось людям, далёким от программирования, все въезжали мгновенно без лишних слов, и можно было обсуждать проблему на одной языке.
Так что, если есть потребность, рекомендую присмотреться.
Re: Будущее программирования - обсудим?
От: PSV100  
Дата: 10.02.12 15:17
Оценка:
Сорри, что я с небольшим офтопом тут. У меня вопросик к ТС. Из этой темы форума я косвенно узрел, что Вы работаете (или студенты под вашем началом как научного руководителя) над проектом, связанным с каким-то семантическим редактором. Судя по характеру приведенной статьи, Вас интересует эта проблематика. В свое время мне на глаза попадались некие подобные системы, и я не понял, какие практичные задачи они решают. Я могу для себя выделить академический интерес (исследования в IT — вещь необходимая), также могут понять и некоторое коммерческое продвижение подобных проектов вплоть до откатов в госструктурах. Но чем они реально могут эффективно помочь в жизни — не понимаю. Попробую обосновать свою "приставалку".

Я не понимаю, зачем программисту видеть и особенно редактировать некую AST-модель кода для написания алгоритмов. Очень часто такие системы реализуют через какие-то графические редакторы, или полу-графические + текстовое описание. Здесь банально нет никакой продуктивности в работе: обычные операции над текстом в редакторах + утилиты — на порядок всё проще, удобнее и быстрее. Я не знаю всех деталей вашего проекта, и возможно в этом конкретном случае как-то не так, и как бы просто имеются умненькие вставлялки/удалялки текста. Но имхо никакой семантический редактор не даст продуктивности как у хорошего текстового редактора, и тот же эмакс, например, частенько умненько редактирует код.
Можно глянуть на проект MetaLua, это некий Немерле для Lua. Вот там есть возможность работать с AST-моделью напрямую. Во-первых, специфика проекта такова, что AST там — вещь необходимая (и то для случаев проектирования своего "языка" — конкретный востребованный случай AST-программирования). Во-вторых, там опять же есть текстовое представление AST, и вроде удобное, насколько возможно.

Имхо, очень плохая идея не хранить программисткие шедевры в не текстовых файлах. Всего в семантический/текстовый редактор/IDE никогда не впихнешь, и с текстом часто приходится работать и за их рамками.
Очень хорошая идея иметь какую-то структурированную модель кода и выполнять реляционные операции в нём. Об этом неоднократно мечтал и автор в указанной статье. Действительно приятно клацнуть клавишу в эмакс/вим/сублиме и открыть консоль, быстро набрать "select что-то from оттуда where чего-то into такой-то буфер", и получить все нужные зависимости от какого-то элемента, например. Но это — вспомогательный помощник в вашем редакторе. И нельзя не иметь текстового представления всей кодобазы.
Приведу пример из личной жизни. В свое время была необходимость реализовать возможность конфигурирования достаточно сложной системы. Требовалось указывать ряд параметров и задавать некоторые алгоритмические действия (самое сложное). Было принято решение: все данные хранить в базе и реализовать интерфейс для работы с этим делом для тех, кто не связан с программированием (а таким людям и приходилось этим заниматься, в основном). Но было уйма технических проблем и сложностей, для всех — и для настройщиков, и для "обработчиков" данных. Попробовали сделать наколенный простой DSL, и кто имел хотя бы представление о том, что такое bat-файл — смогли "программировать". Нас, как разработчиков, люди чуть ли не целовали, ибо им тоже гораздо проще оказалось работать с текстовыми файлами, чем мучаться с навороченным (вынужденно) GUI.
Майкрософт вроде грозилась когда-то, что ее файловые системы будут SQL-подобные. Но что-то тихо сейчас, и явные файлы пока не отменили.

Важный момент: лучше, чем возня с текстовыми файлами, для программистов, простых смертных, пока не придумали, и навряд ли что-то изменится. Уже было графическое представление — перфокарты, и после того, как их скинули, пока текстовые файлы никуда не подвинулись.
В качестве успешного графического языка программирования я уже приводил здесь ДРАКОН. Но в его случае явно видна практичность решаемых задач. К тому же, технически — он помощник для генерации текстового представления программы. А вот неуспешных визуальных систем в жизни хоть отбавляй. Например, можно программиста заставить нарисовать UML, но он ее сделает только для козла-начальника, как правило, оторванную от жизни, и никому она на самом деле не нужна: ни козлу-начальнику, ни всем его начальникам, окромя для имитации активной деятельности начальства. Гараздо практичнее для себя на бумаге набросать те же дракон-схемки, сразу делая "рефакторинг" с помощью резинки. Меня всегда настораживают "интерпрайз-внедренцы-консультанты", которые схемы баз данных рисуют в каких-то ErWin — сразу видно, что люди в жизни пороха не нюхали. Иногда полезно набросать какую-то "Mind Map" для презентации, но если нужны какие-то структурированные схемы для постоянной работы, то удобнее, чем org-mode в эмаксе что-то не вспоминается ничего (опять же — текстовое представление).

Не совсем понятно, зачем создавать семантические редакторы и получать текстовое представление одного и того же, но для разных языков. Например, платформа Net позволяет работать из разных языков. Но кому нужен бейсик обычно C# не использует, как и наоборот. Обычно в жизни стараются уменьшать количество языков в проектах, и от того, что их часто не мало получается на практике — никто не танцует.
Гараздо важнее иметь эффективное текстовое представление, более эффективный язык, и в идеале — один. Многие, кто пришёл к лиспу, имеют долгий и тяжёлый путь: С, C++, Java, Net и пр.

Иными словами, в жизни как-то стремишься к эффективному текстовому языку и простоте (!) — это залог для создания сложных объёмных систем, иначе полный каюк.

Я был бы очень признателен, если бы меня "просветили" в рамках пары слов по поводу того, на решение каких практичных проблем направлены подобные семантические редакторы, кроме научного, образовательного и спортивного интереса. Мне действительно это нужно для себя понять. Спасибо.
Re: Будущее программирования - обсудим?
От: Pavel Dvorkin Россия  
Дата: 10.02.12 16:45
Оценка: 9 (1) :))
Здравствуйте, LaptevVV, Вы писали:

Да обсуждали уже... Год назад.


http://rsdn.ru/forum/life/4277911.1.aspx
Автор: Pavel Dvorkin
Дата: 19.05.11
With best regards
Pavel Dvorkin
Re[2]: Будущее программирования - обсудим?
От: LaptevVV Россия  
Дата: 10.02.12 16:56
Оценка:
Здравствуйте, PSV100, Вы писали:

PSV>Предлагаю глянуть на ДРАКОН — один из редчайших графических языков программирования, который доказал себя на промышленной (!!!!!!) практике. Это визуальный алгоритмический язык, напоминающий блок-схемы, на устремлённых графах. Разрабатывался для проекта Буран и сейчас задействован в космической промышленности. С его помощью удалось решить реально огромную проблему: программисты знают как писать программы, но не понимают сложной предметной области, инженеры — не понимают программы, и, тем более, как программировать. Теперь инженеры сами создают управляющие приложения для оборудования — через описания и схемы.

О драконе мне известно очень хорошо.
На сайте оберонщиков много тем по нему, разрабатываются редакторы...
Книжки Паронджанова имею, читаю. Более того, одному студенту задание дал — включить дракон в его курсовую — редактор графических языков проектирования.
Если он не слиняет с этой темы — будем через год на драконе обучать алгоритмизации первокурсников и второкурсников.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.