[Автор оригинального текста — Paul Chiusano, программист, работает в Capital IQ, пишет преимущественно на Scala. Один из разработчиков библиотеки scalaz — прим. пер.]
Как будет выглядеть программирование через 10-20 лет? В канун нового года самое время пофилософствовать о будущем нашей индустрии. Мы находимся на пороге значительных изменений в деле написания программ, по сравнению с которыми нынешние, 2011 года, техники и идеи будут выглядеть примитивными. Изменения будут происходить в нескольких важных областях: инструментария и инфраструктуры, языков и систем типов, систем времени исполнения.
...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Да что там обсуждать, кто ж его знает как оно будет на самом деле. Мир слишком многогранен, что бы зоопарк ушел в лес.
По сравнению с меинстримными языками, такими как Java, C# или Python язык Javascript не так и плох; в некоторых отношениях он даже лучше. Но Javascript не выдерживает сравнения с языками, имеющими хорошую систему типов и настоящую поддержку ФП, вроде Haskell, Scala и тех языков будущего, которые придут им на смену.
Яваскрипт перед всеми остальными имеет ровно одно преимущество — он действительно исполняется в реальных браузерах.
По всем остальным пунктам он сольёт. Тем не менее я лично считаю, что JS — язык действительно интересный, хороший язык — но — на нём дороговато разрабатывать. Лучшие средства разработки с трудом справляются с ним даже с обильно усеянными хинтами. Эффективность исполнения? Тоже сольёт и Java и C# и Python.
А про ФП — так это вообще судя по всему словечки ради дани моде.
Нет, конечно, если на каждый чих генерить страницы с сервера — то зачем и JS то нужен?! А для более-менее современной обвязки нужно как минимум около 300Kb JS кода, — фреймворка. Посмотреть на фреймворки поболее — так там счет на мегабайты. Может не в языке дело?
Предвижу будущее, в котором Javascript постепенно отходит на второй план, как уходят и специализированные плагины для браузеров вроде Flash, уступая место коду, написанному на произвольных, компилируемых языках, использующих для работы что-нибудь вроде NaCl.
NaCl как и Chromium платформа просто умрёт под собственным грузом. Да ну как и остальные html движки — кода много — ресурсов хавает дай бог каждому, а толку то реально мало. Продвигать насквозь однопоточные layouting engine с кучей ограничений лишь под флагом секурности и скорости и изоляции — это просто бред, при этом решая просто насущные проблемы однопоточного дизайна, и (опционально для разных движков) невозможность достоверно уничтожить js context без перезапуска процесса. Самое смешное, что исключительно все выходцы былых времен и страдают одними и теми же проблемами — а новых выходцев — нет, потому что потянуть всю эту ахинею осилит далеко не каждый, труд слишком велик. Тем не менее вся это богодельня мне кажется очень даже будет жить.
Да уже лет 30 ничего в программировании толком ничего не меняется. Что будет еще через 10? Да ничего! То же самое подадут еще раз под несколькими соусами. Ну может и возникнет какая-нибудь мода, и станет популярным какой-нибудь PJMLScript&& для новой разработки, но суть останется той же да и большинство продолжит поддерживать кучу написанного кода и верно напоминать, что PJMLScript&& оно конечно да, но ни разу не панацея и мозг включать по любому придется.
Здравствуйте, LaptevVV, Вы писали:
LVV>[Автор оригинального текста — Paul Chiusano, программист, работает в Capital IQ, пишет преимущественно на Scala. Один из разработчиков библиотеки scalaz — прим. пер.]
Первым существенным изменением будет уход от представления программ в виде текста, разделенного на файлы.
Первый посыл и сразу весьма сомнительный. Сомнительный практически до нереального. Короче, фантазёрство. Советские фантасты так представляли планету через 50 лет (как раз наше время). Везьде коммунизм, в небе кругом летательные аппараты, космические карабли бороздят просторы, а мониторы у компьютеров всё такие же зелёные и информация хранится в сейфе предварительно сброшенная на перфоленту. А на деле получилось интернет, карманные телефоны со встроенными видео камерами, навигаторами и музыкальными центрами, трёхмерное телевидение и терабайты семейных картинок и видео. Правда вот с коммунизмом и космосом как-то не всё получилось.
Если нам не помогут, то мы тоже никого не пощадим.
LVV>[Автор оригинального текста — Paul Chiusano, программист, работает в Capital IQ, пишет преимущественно на Scala. Один из разработчиков библиотеки scalaz — прим. пер.]
LVV>Как будет выглядеть программирование через 10-20 лет?
LVV>...
Изменения в программировании происходят,когда назревает необходимость. Так было с С++ и Java. На данный момент, контроль над мейнстримными языками осуществляют те же компании, что и создают веяния в мире софта и железа. Так получается замкнутный круг — девайс->технология<->язык.
Лично я За — изменения самого образа программирования в сторону визуальности. Автор прав в том, что потеря продуктивности из-за кода в тексте, остается за пределами радаров программиста.
1. автор -- человек с завышенным чсв, рассказывает про то, что
> Эта проблема пользуется популярностью среди людей, которые предпочитают находить своему нежеланию учить Haskell и ФП рациональные объяснения
*людям* и права нет смысла учить хаскель, его имеет смысл учить *только* для того, чтобы понимать о чем там говорят ученые и псевдо-ученые
> А тем, кто предпочитает критиковать ФП, я считаю, не помешает заиметь немного скромности.
помешает
очень даже помешает критическому восприятию их понтов -- как ввели *недавно* в хаскеле (или его расширении) семейства типов (практически аналог плюсовых шаблонных типов, существующих х.з. сколько времени), уж столько помпы в вики -- это же почти зависимые типы!!1111
3.
> Так, будут почти универсальные стандарты (вроде getAllLinks)
так мы и поверили -- гуглу будет выдаваться одно, а человеку показываться другое, спамеры однако
я думаю тут решение будет простое -- настоящим аппликухам нет смысла держать у себя шибко интересные гуглу урл-ки, урл-ки это атрибут документации (т.е. именно страницы с (гипер)текстом), а не аттрибут аппликухи
это язык для создания запросов к исходному коду и для трансформации исходного кода
что касается нетекстового и нефайлового хранения -- идея 50% на 50%; хотя мне честно говоря не хватает текстового представления языка, нетекстовое потребует затрат по адаптации к нему vcs
Здравствуйте, licedey, Вы писали:
L>Лично я За — изменения самого образа программирования в сторону визуальности. Автор прав в том, что потеря продуктивности из-за кода в тексте, остается за пределами радаров программиста.
Попыток уйти от этого было дохрена и больше. И обсуждений причин гиблости затеи здесь тоже было дохрена и больше. Вот из последнего, где я участвовал.
LVV>[Автор оригинального текста — Paul Chiusano, программист, работает в Capital IQ, пишет преимущественно на Scala. Один из разработчиков библиотеки scalaz — прим. пер.]
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, LaptevVV, Вы писали: IT>
IT>Первым существенным изменением будет уход от представления программ в виде текста, разделенного на файлы.
IT>Первый посыл и сразу весьма сомнительный. Сомнительный практически до нереального. Короче, фантазёрство. Советские фантасты так представляли планету через 50 лет (как раз наше время). Везьде коммунизм, в небе кругом летательные аппараты, космические карабли бороздят просторы, а мониторы у компьютеров всё такие же зелёные и информация хранится в сейфе предварительно сброшенная на перфоленту. А на деле получилось интернет, карманные телефоны со встроенными видео камерами, навигаторами и музыкальными центрами, трёхмерное телевидение и терабайты семейных картинок и видео. Правда вот с коммунизмом и космосом как-то не всё получилось.
1. А вы читали вот эту книгу: http://www.ozon.ru/context/detail/id/2896278/
Там есть очень интересная глава про исследовательские работы в Микрософте.
2. Отец БлэкБокса Клеменс Шиперски работает в Microsoft Research: http://research.microsoft.com/en-us/um/people/cszypers/
А представление модулей в БлэкБоксе — не текстовое. Это было еще в 95-м году.
3. Программа — это мультиграф, вершинами которого являются модули.
В системе этот мультиграф может хранится в каком угодно виде.
И только для человека его нужно представить в текстовом виде. Но это не значит, что в текстовом же виде программу надо и обрабатывать.
И даже вводить можно не в текстовом виде.
Мы у себя делаем семантический редактор, который с текстами не работает.
Первая часть компилятора физически отсутствует — фактически требуют анализа только выражения.
Но на экране — текст, который читает человек.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, licedey, Вы писали:
L>Изменения в программировании происходят,когда назревает необходимость. Так было с С++ и Java. На данный момент, контроль над мейнстримными языками осуществляют те же компании, что и создают веяния в мире софта и железа. Так получается замкнутный круг — девайс->технология<->язык.
Вот у нас (лично у нас в Астрахани) и назрела необходимость. L>Лично я За — изменения самого образа программирования в сторону визуальности. Автор прав в том, что потеря продуктивности из-за кода в тексте, остается за пределами радаров программиста.
Нет. Мы — программисты. И должны сами сделать такой инструмент, который НАМ удобен.
Как в свое время сделали юникс — систему, которая удобна именно программистам.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>3. Программа — это мультиграф, вершинами которого являются модули. LVV>В системе этот мультиграф может хранится в каком угодно виде. LVV>И только для человека его нужно представить в текстовом виде. Но это не значит, что в текстовом же виде программу надо и обрабатывать.
Ну как бы что у Влада интеграция немерла для VS, что у Одерски интеграция скалы для Eclipse тоже всё перекомилирует на каждый чих программиста. Причём как минимум у одного из них — не полностью, а только необходимое поддерево. Небось, как раз и держит в памяти AST — тот самый нетекстовый вид. А вот фраза "для человека его нужно представить в текстовом виде" содержит ошибочку: надо не только "представить" (r/o), но и обеспечить возможность редактирования человеком в текстовом виде (r/w).
LVV>Мы у себя делаем семантический редактор, который с текстами не работает. LVV>Первая часть компилятора физически отсутствует — фактически требуют анализа только выражения. LVV>Но на экране — текст, который читает человек.
читает, но не редактирует? а редактирует уже дерево/граф?
а парсить текстовые файлы ваша система умеет? или для переноса в нее кода требуется забивать его руками?
если так уж прям хочется окунуться в такую систему, рекомендую JetBrains MPS
а вот еще че забыл спросить -- грамматика для перевода дерева/графа в текстовое представление проверяется на однозначность? т.е. может возникнуть такая ситуация, что два *разных* графа выливаются в один и тот же текст?
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, LaptevVV, Вы писали:
LVV>>3. Программа — это мультиграф, вершинами которого являются модули. LVV>>В системе этот мультиграф может хранится в каком угодно виде. LVV>>И только для человека его нужно представить в текстовом виде. Но это не значит, что в текстовом же виде программу надо и обрабатывать.
D>Ну как бы что у Влада интеграция немерла для VS, что у Одерски интеграция скалы для Eclipse тоже всё перекомилирует на каждый чих программиста. Причём как минимум у одного из них — не полностью, а только необходимое поддерево. Небось, как раз и держит в памяти AST — тот самый нетекстовый вид. А вот фраза "для человека его нужно представить в текстовом виде" содержит ошибочку: надо не только "представить" (r/o), но и обеспечить возможность редактирования человеком в текстовом виде (r/w).
Редактировать надо не весь текст. Например, ключевые слова нафиг не надо редактировать.
Фактически создание модуля состоит из операций вставки-удаления конструкций + текстовое редактирование отдельных лексем — идентификаторов, констант и т.п.
Плюс операции рефакторинга вроде — преобразовать выделенную последовательность операторов в функцию. И наоборот — "раздеть" функцию.
Операции рефакторинга требуют исследования. Это вам не вставить — удалить символ.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, m e, Вы писали:
LVV>>Мы у себя делаем семантический редактор, который с текстами не работает. LVV>>Первая часть компилятора физически отсутствует — фактически требуют анализа только выражения. LVV>>Но на экране — текст, который читает человек. ME>читает, но не редактирует? а редактирует уже дерево/граф?
Редактирует. Но не весь. Ключевые слова нафиг редактировать.
Имена, константы, выражения — это требует редактирования ручного. А сама структура конструкции оператора редактирования не требует.
Он добавляется в модель одной клавишей. Одной же и удаляется. ME>а парсить текстовые файлы ваша система умеет? или для переноса в нее кода требуется забивать его руками? ME>если так уж прям хочется окунуться в такую систему, рекомендую JetBrains MPS ME>она уже сделана
В смысле IntelliJ ?
Импорт — это естественно будет. Но задача не первоочередная.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Фактически создание модуля состоит из операций вставки-удаления конструкций + текстовое редактирование отдельных лексем — идентификаторов, констант и т.п.
Для меня создание модуля в доброй половине случаев начинается с копипаста другого.
Здравствуйте, LaptevVV, Вы писали:
LVV>А сама структура конструкции оператора редактирования не требует. LVV>Он добавляется в модель одной клавишей.
Дык это и щас есть. Code snippets называется, что ли... Один хрен не пользуюсь — лениво запоминать горячую клавишу и настраивать удобные мне шаблоны с удобным мне форматированием.
LVV>Одной же и удаляется.
Гы. Я так понимаю, не дай бог нажать delete под словом "class".
Мне так кажется, что надо не обсуждать что сделают другие, а что мы сделаем в том момент когда все зашло в тупик, самый момент предложить что-то новое.
Но для начала надо понять что плохо.
А плохо то что так и не создан язык, подобный математическому языку. Языку без ифов, языку без двоичной логики. Ну если хотите, для затравки/обьяснения — языку у которого иф как бы срабатывает на 0.5 То есть если уловие уже близко к истине он уже начинает выполняться.
Здравствуйте, m e, Вы писали:
LVV>> которая удобна именно программистам.
ME>а вот еще че забыл спросить -- грамматика для перевода дерева/графа в текстовое представление проверяется на однозначность? т.е. может возникнуть такая ситуация, что два *разных* графа выливаются в один и тот же текст?
Проверяли, но поскольку нет пока обратной операции текст->модель, то еще будем проверять.
Кроме того, выделили процедурное ядро Додиеза и Оберона — оно одинаковое с семантической точки зрения.
Взяли грамматики этих языков и сравнили.
И теперь у нас одной кнопочкой на экране хочешь — Додиез, а хочешь — Оберон. В процедурной части, естественно.
Тут еще работать и работать. Но к сентябрю хотим первую версию запустить. Прямо в классах.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, LaptevVV, Вы писали:
LVV>>А сама структура конструкции оператора редактирования не требует. LVV>>Он добавляется в модель одной клавишей.
D>Дык это и щас есть. Code snippets называется, что ли... Один хрен не пользуюсь — лениво запоминать горячую клавишу и настраивать удобные мне шаблоны с удобным мне форматированием.
Ну, мы тоже на сниппетах остановились. LVV>>Одной же и удаляется. D>Гы. Я так понимаю, не дай бог нажать delete под словом "class".
Ну вы батенька совсем уж нас за лохов принимаете...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, worobоw, Вы писали:
W>Мне так кажется, что надо не обсуждать что сделают другие, а что мы сделаем в том момент когда все зашло в тупик, самый момент предложить что-то новое.
Мы и делаем. Сами. Для себя. W>Но для начала надо понять что плохо.
Что плохо для преподов — это я могу МНОГО написать. Что плохо для студентов — тут индивидуально очень. Один пон7имает влет. Другому надо 100500 раз повторить. W>А плохо то что так и не создан язык, подобный математическому языку. Языку без ифов, языку без двоичной логики. Ну если хотите, для затравки/обьяснения — языку у которого иф как бы срабатывает на 0.5 То есть если уловие уже близко к истине он уже начинает выполняться. W> Кстати кто будет участвовать в разработке?
В Вашей команде? Мы не будем, у нас свои разработки.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, worobоw, Вы писали:
W>Здравствуйте, LaptevVV, Вы писали:
W>Мне так кажется, что надо не обсуждать что сделают другие, а что мы сделаем в том момент когда все зашло в тупик, самый момент предложить что-то новое.
W>Но для начала надо понять что плохо.
W>А плохо то что так и не создан язык, подобный математическому языку. Языку без ифов, языку без двоичной логики. Ну если хотите, для затравки/обьяснения — языку у которого иф как бы срабатывает на 0.5 То есть если уловие уже близко к истине он уже начинает выполняться.
Это, по-вашему, не математика, да?
Да и двоичная логика с чего вдруг из математики пропала?
Здравствуйте, worobоw, Вы писали:
W> Кстати кто будет участвовать в разработке?
Да, вот еще, что — природа создала свой язык программирования, точнее архитектуру, мне кажется, сейчас самое время использовать ее наработки. Я об ДНК/РНК.
И кстати повторю, чтобы не показалось что это стеб — наберется человек 20 настоящих профессионалов? Причем именно супер-профессионалов, с амбициями на прорыв?
Здравствуйте, LaptevVV, Вы писали:
LVV>Первая часть компилятора физически отсутствует — фактически требуют анализа только выражения. LVV>Но на экране — текст, который читает человек.
Где-то в середине 90-х был подобный редактор для модулы, если не ошибаюсь. Всё проверял, всё контролировал, не давал делать ошибок и везде старался как мог. Смотрелось очень круто. Выкинули его через неделю и не потому что он плохо делал свою работу, а как раз наоборот слишком хорошо. Смотреть на него, конечно, было прикольно, но работать в нём было невозможно по одной простой причине. Некомпилируемый, разваленный и разрезанный на куски код — это перманентное состояние программы над которой в данный момент трудится программис. И каким образом он перейдёт из одного рабочего состояния программы в другое известно только ему одному.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, worobоw, Вы писали:
W>А плохо то что так и не создан язык, подобный математическому языку. Языку без ифов, языку без двоичной логики.
И не будет создан. имеется ввиду широко применяемый, чтобы в 20ку TIOBE попасть.
Потому что символьная запись в математике применяется для ИЗВЕСТНЫХ закономерностей.
А компьютерные программы обрабатывают НЕИЗВЕСТНЫЕ задачи. Например — мы не знаем заранее в каком порядке и в каком месте экрана пользователь княпнет.
Имеем — противоположные условия.
Второе принципиальное отличие.
Компьютерные программы вобщем-то занимаются преобразованием информации, из одного вида в другой. Язык программирования позволяет записать правила этого преобразования. И правила эти в общем случае — произвольны. Нет на них никакого "закона".
Математическая же запись предназначена для записи логических соответствий между сущностями. Причем мы вначале однозначно должны определить эти сущности.
И эти две задачи ИМХО ортогональны. Но за счет специализации на ЯП легче решать первые задачи, а языком математики вторые.
Так что ничего случайного, что такой язык не был создан ранее. Он не годится для практического программирования.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, LaptevVV, Вы писали:
LVV>>Первая часть компилятора физически отсутствует — фактически требуют анализа только выражения. LVV>>Но на экране — текст, который читает человек.
IT>Где-то в середине 90-х был подобный редактор для модулы, если не ошибаюсь. Всё проверял, всё контролировал, не давал делать ошибок и везде старался как мог. Смотрелось очень круто. Выкинули его через неделю и не потому что он плохо делал свою работу, а как раз наоборот слишком хорошо. Смотреть на него, конечно, было прикольно, но работать в нём было невозможно по одной простой причине. Некомпилируемый, разваленный и разрезанный на куски код — это перманентное состояние программы над которой в данный момент трудится программис. И каким образом он перейдёт из одного рабочего состояния программы в другое известно только ему одному.
Вот это и пора сломать в 21-м веке...
Хватит кустарничать! Пора переходить к промышленному программированию.
Интересный фактец. Пацан, которые пишет сам семантический редактор, признался.
Он для проверки интерпретатора пишет в нем тестовые проги — довольно много.
А редактор делает исключительно структурный текст.
И пацан заметил за собой, что в студии на шарпе он стал писать структурный текст.
И что смешно. По его собственному признанию проги стали получаться проще, понятней и с меньшим количеством ошибок.
И это 4 курс, вроде все дурные привычки уже в крови.
А вот получил правильный инструмент — и привычки стали меняться...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, m e, Вы писали:
ME>теперь часть Б -- с чем я согласен
ME>это язык для создания запросов к исходному коду и для трансформации исходного кода
ME>что касается нетекстового и нефайлового хранения -- идея 50% на 50%; хотя мне честно говоря не хватает текстового представления языка, нетекстовое потребует затрат по адаптации к нему vcs
Универсально удобного для всех случаев представления и быть не может. Потому логичнее иметь несколько представлений. У меня их несколько.. Тектовый, теговый, типа конструктора (графический), в табличном виде (базы данных), да еще и связи (типа UML) И классы объекты оттуда же. Такое стало возможным именно из-за единства формата всего. И файлов тоже. Расширения просто перестали существовать. Это свойство документа как загружаемой (передаваемой) единицы..
Я бы заметил, что файловая древовидная модель — это анахронизм, хотя и очень удачный. В целом операционки уже давно пытаются прятать тот факт, что есть какие-то файлы. "Установленные программы", "Медиабиблиотека", "Плэйлист" — шаг в правильном направлении. Я не знаю, что будет в будущем, мб что-то ближе к БД или тэгам.
Здравствуйте, LaptevVV, Вы писали:
LVV>Редактирует. Но не весь. Ключевые слова нафиг редактировать. LVV>Имена, константы, выражения — это требует редактирования ручного. А сама структура конструкции оператора редактирования не требует.
Да, правда, что-ли?
Возьмем немеле. И посмотрим на конструкцию foreach
Самый простой вариант
выберем из коллекции только то, что является SomeItem
foreach (item is SomeItem in collection)
{
}
А теперь представь, сколько конструкций получится, если учесть, что это все можно комбинировать.
И сами паттерны могут быть весьма кучерявыми.
Возьмём другой пример.
Это не окончательный вариант синтаксиса для парсера над которым я работаю.
По этому описанию будет построен динамически расширяемый парсер. Пример динамической расширяемости. Ага. Прямо во время разбора текста, встретив определенную конструкцию парсер загружает из внешней длл новые правила.
Вот пример попроще.
using IncParser;
using NumParser;
any = ['\u0000'..'\uFFFF'];
s : void = ' '*;
[StartRule]
start : ExprAst = s expr !any;
[StartRule]
expr : ExprAst;
[Ast(l, expr, r)] rounds is expr = '('s expr ')'s;
[Ast(l, expr, r)] seq is expr = '{'s expr* '}'s;
[Ast(num)] num is expr = number s;
[Ast(op, expr)] neg is expr = '-'s expr : 100;
[Ast(op, expr)] prefixDec is expr = "--"s expr : 200;
[Ast(expr, op)] postfixDec is expr = expr : 200 "--"s;
[Ast(l, op, r)] add is expr = expr : 10 '+'s expr : 10;
[Ast(l, op, r)] sub is expr = expr : 10 '-'s expr : 10;
[Ast(l, op, r)] mul is expr = expr : 20 '*'s expr : 20;
[Ast(l, op, r)] div is expr = expr : 20 '/'s expr : 20;
[Ast(l, op, r)] mod is expr = expr : 20 '%'s expr : 20;
[Ast(l, op, r)] pow is expr = expr : 31 '^'s expr : 30;
Как видишь так называемые "конструкции" отсутствуют чуть менее чем полностью.
LVV>Он добавляется в модель одной клавишей. Одной же и удаляется.
Автокомплит для языковых конструкций сделать не проблема.
LVV>В смысле IntelliJ ?
В смысле: http://www.jetbrains.com/mps/
Поставь и посмотри. И своему орлу покажи. Пусть поймет, что велосипед делает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
LVV>[Автор оригинального текста — Paul Chiusano, программист, работает в Capital IQ, пишет преимущественно на Scala. Один из разработчиков библиотеки scalaz — прим. пер.]
Исчо один!!!
Невозможен универсальный DSL для всех программ. Теорема Геделя уже давно вещь сколько не математическая, а филосовская и доказанная на практике. Для подобных программ нужно просто отменить конкуренцию, и заставить пользователей покупать не то что они хотят, а то что им зают. А пока приходится менять уровни абстракции от уровня "Нарисуем форму", вплоть до хака переопределения функций в системных dll.
Автор утверждает, что мы уменьшим повторяемость. О каком уменьшении можно говорить, если: разработчик обычно пишет велосипеды не только на чужие модули, но и даже на уровне апи. То что надо знать еще до начала разработки. Автор выступает за увеличение сложности и неуправляемости типов. Флаг ему в руки... Точнее в культяпки, поскольку такие руки надо рубить. С чем нужно бороться? Может все таки бороться со сложностью?
Как сидели над вопросами 60-ых, как уменьшить нам сложность набора процедур. Так и сидят. Что касается уменьшения сложности, многомодульности, принципа разделяй и властвую — ноль.
Здравствуйте, WolfHound, Вы писали:
LVV>>В смысле IntelliJ ? WH>В смысле: http://www.jetbrains.com/mps/ WH>Поставь и посмотри. И своему орлу покажи. Пусть поймет, что велосипед делает.
1. Спасибо за информацию. Состыкую пацана — поговорите поглубже. Он информацию собирает отовсюду.
2. Мы делаем в первую очередь обучающую среду.
В ней должен быть инструмент для препода по оценке действий студента.
Основная идея именно в этом, а не в обеспечении возможности писание мегабайтных программ.
Встраивать подобный инструмент в существующие — слишком геморно и не интересно.
К тому же — опыт проектирования, разработки и рефакторинга такого большого продукта гораздо более полезен, чем ковыряние в чужой работе.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>В смысле IntelliJ ?
ME>у нас все точно (с) робот в ответ громозеке
ME>именно MPS
LVV>>Импорт — это естественно будет. Но задача не первоочередная.
ME>у них емнип уже че-то вроде импорта было, типа вставки из clipboard
Ну, это и у нас есть... Прямо уже сейчас...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, licedey, Вы писали:
L>>Изменения в программировании происходят,когда назревает необходимость. Так было с С++ и Java. На данный момент, контроль над мейнстримными языками осуществляют те же компании, что и создают веяния в мире софта и железа. Так получается замкнутный круг — девайс->технология<->язык. LVV>Вот у нас (лично у нас в Астрахани) и назрела необходимость.
Речь шла о глобальных веяниях, вроде GUI, кросс-платформенности, вэб-приложений, фреймворков. За каждым стоит свой язык. А у вас в Астрахани что намечается, если не секрет?
L>>Лично я За — изменения самого образа программирования в сторону визуальности. Автор прав в том, что потеря продуктивности из-за кода в тексте, остается за пределами радаров программиста. LVV>Нет. Мы — программисты. И должны сами сделать такой инструмент, который НАМ удобен. LVV>Как в свое время сделали юникс — систему, которая удобна именно программистам.
НАМ удобен=нам привили=мы привыкли. Вспоминается Форд: "если бы я слушал что говорят люди, то они до сих пор бы ездили на повозках"
Однако...вопрос этого извечного "фии" на новые фиичи у коллег — это да.
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, licedey, Вы писали:
L>>Лично я За — изменения самого образа программирования в сторону визуальности. Автор прав в том, что потеря продуктивности из-за кода в тексте, остается за пределами радаров программиста.
D>Попыток уйти от этого было дохрена и больше. И обсуждений причин гиблости затеи здесь тоже было дохрена и больше. Вот из последнего, где я участвовал.
Я вот глобальных попыток не видел. Пример приведете? Чтобы например как тот же Делфи в свое время ахнул. Так что все впереди. Как автор написал — визуальных инструмент должен быть значительно лучше текстового аналога. Для кого-то в vim'e на Сях — лучше всего до сих пор.
S>Компьютерные программы вобщем-то занимаются преобразованием информации, из одного вида в другой. Язык программирования позволяет записать правила этого преобразования. И правила эти в общем случае — произвольны. Нет на них никакого "закона". S>Математическая же запись предназначена для записи логических соответствий между сущностями. Причем мы вначале однозначно должны определить эти сущности. S>И эти две задачи ИМХО ортогональны. Но за счет специализации на ЯП легче решать первые задачи, а языком математики вторые.
С другой строны, информация A — это одни мат правила, информация B — это друние мат. правила, а программа между ними — это некое B = (g o f)(A)
Здравствуйте, licedey, Вы писали:
LVV>>Нет. Мы — программисты. И должны сами сделать такой инструмент, который НАМ удобен. LVV>>Как в свое время сделали юникс — систему, которая удобна именно программистам.
L>НАМ удобен=нам привили=мы привыкли. Вспоминается Форд: "если бы я слушал что говорят люди, то они до сих пор бы ездили на повозках" L>Однако...вопрос этого извечного "фии" на новые фиичи у коллег — это да.
Нет.
Так можно и Страуструпа послать. Он же фии сказал на Симулу. И решил, что надо в С нечто подобное вставить.
А еще Ричи раньше сказал фии на тогдашние языки программирования и сказал А В С.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>Встраивать подобный инструмент в существующие — слишком геморно и не интересно.
там не надо встраивать -- все уже готово
там надо определить конструкции (ну или как их там... из которых состоит модель) и их внешнее представление, да еще и отнаследовать от существующих языков можно, дабы сократить время
думаю, тем чувакам вашу функциональность 100% повторить заняло бы меньше 1 человеко-дня, а я бы даже предположил где-то полчаса
впрочем, у них там разница -- переменные вводятся тоже целиком, а не по буковкам, причем емнип с учетом области видимости
LVV>К тому же — опыт проектирования, разработки и рефакторинга такого большого продукта гораздо более полезен, чем ковыряние в чужой работе.
NIH? а еще полезно первоначальный сбор инфы проводить
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) Кросс-аппаратности/платформенности/браузерности б) упрощении манипулирования абстракциями, не отвлекаясь на мелочи, мыслить по задаче в) от роста уровня абстрагирования от задачи, менять и ее представление. Еще довольно много "Хотелось бы", чего нет в силу зависимости от прошлого с одной стороны, и необъятных ресурсов для прорыва в будущее с другой. Но кто-то должен начать.
Здравствуйте, licedey, Вы писали:
L>Я вот глобальных попыток не видел. Пример приведете? Чтобы например как тот же Делфи в свое время ахнул. Так что все впереди. Как автор написал — визуальных инструмент должен быть значительно лучше текстового аналога. Для кого-то в vim'e на Сях — лучше всего до сих пор.
Пиком человеческого прогресса на данный момент ялвляется Vim + Nemerle. С хорошим языком, из IDE бывает нужен только интеллисенс, при интенсивной работе с незнакомыми API. Существующие визуальные редакторы в лучшем случае подспорья для новичков или непрограммистов.
Последние десятилентия мы видим сдвиг в сторону использования готовых библиотек или готовых 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, вроде как, уже давно успешно занимается и тем, и другим
да и регэкспы недалеко.
Оба декларативные и обы выигрывают у _средней_ рукопашной реализации.
Здравствуйте, 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
Здравствуйте, 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>Интересный фактец. Пацан, которые пишет сам семантический редактор, признался.
Ключевое слово выделено.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
LVV>Как будет выглядеть программирование через 10-20 лет?
Первую свою программу я написал более двадцати лет назад.
Далее только тезисные заявления. Доказательства — через 20 лет
Первым существенным изменением будет уход от представления программ в виде текста, разделенного на файлы.
Нет, но файловые системы очень будут похожи на базы данных. В частности, с файлом можно будет работать, как с хранилищем структурированных единиц.
Редактирование кода будет производиться в структурных редакторах, которые будут совсем не похожи на современные IDE
IDE несомненно сильно разовьются, но останутся узнаваемыми и похожими на сегодняшние средства.
Языки с нестрогой семантикой будут доминировать в новом мире благодаря увеличению повторно используемого кода и модульности, которая характерна для «нестрогости по умолчанию».
Это вряд ли. По психологическим причинам.
Распространение кода и будущее web.
Этот вопрос крайне сложен. Глядя в свой магический жидкий кристалл Я вижу две разнонаправленные тенденции: 1) разделение web'a на слабовзаимодействующие домены 2) усилия по созданию p2p сетей и облаков на их основе.
Предвижу будущее, в котором Javascript постепенно отходит на второй план, как уходят и специализированные плагины для браузеров вроде Flash, уступая место коду, написанному на произвольных, компилируемых языках, использующих для работы что-нибудь вроде NaCl. Это будет совмещено с кешированием подписанного кода и механизма отслеживания зависимостей, так что, например, станет возможным предоставить приложение, которое подгружает виртуальную машину Java и другие зависимости, если они еще не закешированы на вашем компьютере и подписи совпадают. Это изменяет способ мышления о программном обеспечении. ПО не всегда будет чем-то из категории «скачай это себе на компьютер и запусти». Напротив, ПО существует «само по себе», а вы его запускаете. Как деталь реализации процесса запуска вы можете позволить подгрузить дополнительный код, который нужен ему для работы.
С этим я согласен. Тут интересно рассмотреть маркетинговую составляющую.
Я уже намекал на это: функциональное программирование бесспорно победит
Нет. Это спорно. Функциональное программирование может победить исключительно за счёт автоматической параллелизации исполнения. В любом случае о полной победе речь идти не может.
К тому же в статье не упомянуты два больших направления: метапрограммирование и усилия по созданию языков для удобного программирования параллельно исполняющегося кода. Например, успехи метапрограммирования могут привести к исчезновению языков как отдельных сущностей (т.е. использование языка в проекте будет равносильно действию, которое сейчас делается по добавлению в проект новой библиотеки). А усилия в области распараллеливания кода могут привести к новым парадигмам в программировании.
Здравствуйте, LaptevVV, Вы писали:
LVV>Он для проверки интерпретатора пишет в нем тестовые проги — довольно много.
Пусть он для проверки работоспособности идеи напишет не много мелких прог, а одну большую, без чёткихх требований, а потом хорошенько её порефакторит.
LVV>И пацан заметил за собой, что в студии на шарпе он стал писать структурный текст. LVV>И что смешно. По его собственному признанию проги стали получаться проще, понятней и с меньшим количеством ошибок.
Кто же спорит. Возможно это навело у него порядок в голове и он научился лучше писать "довольно много тестовых прог".
Если нам не помогут, то мы тоже никого не пощадим.
Я не верю в будущее без настоящего. То, что будет завтра, вовсю проявляет себя, так или иначе, уже сейчас. То, что будет через 10-20 лет, уже маячит где-то на горизонте, вызывает определённый интерес у энтузиастов и уже удивляет нас своими пусть пока наивными, но вполне осязаемыми возможностями.
Никаких предпосылок для появления визуального программирования на сегодняшний день не наблюдается вообще. Всё как раз совсем наоборот. От визуальных редакторов сегодня нередко отказываются. Взять тот же ASP.NET MVC, на мой взгляд, лучшая на сегодня среда для разработки веб приложений. Визуальный редактор в ней отсутствует совсем, хотя до этого на протяжении 10 лет ASP.NET навязчиво предлагал писать html не руками, а размазывать его по экрану мышкой.
Так что же с будущим? Неужели его нет? Есть. И мы можем наблюдать его проявления уже сейчас.
В первую очередь это DSL. В качестве примера возьмём Linq. Типичный встроенный в C# специализированный язык. В умелых руках в разы повышает производительность разработки приложений, работающих с БД. Эта вещь уже в мэйнстриме и очень неплохо себя зарекомендовала. Следующий пример тот же ASP.NET MVC со своим Razor. Результат при смешивании C# и html обычно выглядит крайне печально, а здесь всё получается очень аккуратно и читабельно. Не думал что такое вообще возможно. А если учесть, что связующим языком в данном случае является C#, а в нём есть Linq, то вот вам и привет из будущего — три языка в одном коде, удачно дополняющих друг друга.
Пока в этом направлении есть только одна проблема – относительная сложность разработки своих собственных DSL, т.к. сегодня недостаточно просто придумать язык и написать к нему компилятор. Нужна ещё поддержка средств разработки, таких как Visual Studio, Idea и т.п.
Вторым направлением является, конечно же, функциональное программирование. Здесь автор статьи прав. Рано или поздно оно будет в мэйнстриме. О нём много говорят, им интересуются, элементы ФП проникают в мэйнстрим языки и довольно неплохо там приживаются. О причинах этого я уже писал здесь
. Всё теоретическое в программировании уже придумано лет 20-ть назад, если не больше. Теперь дело лишь за переосмыслением всего этого массами и реализацией в мэйнстриме.
Третья вещь – это метапрограммирование. Мы уже сейчас вовсю его используем, хотя можем этого и не замечать. В студии море скрытых генераторов кода. От визардов, до редакторов всяческих схем. Есть и более доступные вещи, вроде T4. Но мы пока не научились этим толком пользоваться. В результате одни пишут целые фреймворки для поддержки, например, баиндинга в WPF, тормознутые по своей сути, а другие берут T4 и за пол дня на коленке делают шаблон, который генерирует для их задачи всё, что может понадобиться, получая при этом гораздо более гибкий и производительный код.
Вообще возможности метапрограммирования пока плохо изучены. То, что мы имеем сейчас – это генерация кода либо до, либо после компиляции. А что если нам дадут в руки расширяемый компилятор? Microsoft что-то ковыряет в этом направлении, но похоже уже умудрилась сбиться с правильного пути. Но есть и другие альтернативы. И их можно попробовать и оценить уже сейчас.
Они уже есть и значит у них есть будущее. А то, о чём говорит автор статьи существует лишь в его собственном воображении.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Они уже есть и значит у них есть будущее. А то, о чём говорит автор статьи существует лишь в его собственном воображении.
Кстати, забыл добавить сакраментальное "Казалось бы, причём тут Немерле?".
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, 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!
Кстати забыл добавить, что в визуальное програмирование я не сильно верю. Скорее очень постепенное , эволюционное развитие IDE средств для поддержки языковых.
Например даже в очень user frendly приложениях со своими DSL слишко часто используют текст (макросы excel текстовые) и т.д.
Так же могу предположить эволюцию различных анализаторов кода и генераторов типа UML -> code , code -> UML, DSL ->code и т.п.
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, licedey, Вы писали:
L>>Я вот глобальных попыток не видел. Пример приведете? Чтобы например как тот же Делфи в свое время ахнул. Так что все впереди. Как автор написал — визуальных инструмент должен быть значительно лучше текстового аналога. Для кого-то в vim'e на Сях — лучше всего до сих пор.
DR>Пиком человеческого прогресса на данный момент ялвляется Vim + Nemerle.
Здравствуйте, velkin, Вы писали:
V>Тогда вместо решения насущных задач программисты начнут расширять компилятор.
Это стандартное заблуждение. Программисты и сейчас занимаются всякой фигнёй только дай волю. Строительство завода для производства гвоздя (одного!) является обычным развлечением большинства 'зи архитектов'.
Если нам не помогут, то мы тоже никого не пощадим.
LVV>Мы у себя делаем семантический редактор, который с текстами не работает. LVV>Первая часть компилятора физически отсутствует — фактически требуют анализа только выражения. LVV>Но на экране — текст, который читает человек.
ZX Spectrum изобретаете заново?
Здравствуйте, licedey, Вы писали:
L>Я вот глобальных попыток не видел. Пример приведете? Чтобы например как тот же Делфи в свое время ахнул. Так что все впереди.
Я вот летающих крокодилов не видел. Так что всё впереди.
А примеры в той ветке приводились.
LVV>[Автор оригинального текста — Paul Chiusano, программист, работает в Capital IQ, пишет преимущественно на Scala. Один из разработчиков библиотеки scalaz — прим. пер.]
LVV>Как будет выглядеть программирование через 10-20 лет? В канун нового года самое время пофилософствовать о будущем нашей индустрии. Мы находимся на пороге значительных изменений в деле написания программ, по сравнению с которыми нынешние, 2011 года, техники и идеи будут выглядеть примитивными. Изменения будут происходить в нескольких важных областях: инструментария и инфраструктуры, языков и систем типов, систем времени исполнения.
LVV>...
А зачем в принципе что-то кардинально улучшать? Неужели существующих средств не достаточно для решения всех мыслимых задач?
Запрос на изменения должен исходить извне — от производителей новых устройств (смартфоны, например), новых процессоров (квантовых в будущем), новых прикладных сервисов и технологий (web, социальные сети, облака и.т.д.).
Здравствуйте, 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-ых было нулевым. В общем полное ХЗ в моем ИМХО.
Здравствуйте, GlebZ, Вы писали:
GZ>Через 10-20 лет я вообще не хочу видеть html. Это язык для несложных презентаций времен телефонных модемов.
Через 10-20 лет я вообще не хочу видеть txt. Это язык для несложных документов времен до телефонных модемов.
Сложные веб-приложения — обсуждаемо (но не потому что html, а потому что js), а простой rich-formatted text по-любому нужен и будет нужен. Из мне известных, html — самый простой.
Здравствуйте, 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, который решает проблемы, которые решают некоторые навороченные фреймворки, у меня заняло пол дня.
Ну а хрен себе при желании отстрелить можно чем угодно. Не обязательно для этого использовать сложный, изощрённый механизм. Можно просто засунуть его в электрическую мясорубку. Нажимаем кнопку 'Вкл' до характерного звука 'счёлк' и вот тебе к столу фарш их хрена.
Если нам не помогут, то мы тоже никого не пощадим.
IT>Это стандартное заблуждение. Программисты и сейчас занимаются всякой фигнёй только дай волю. Строительство завода для производства гвоздя (одного!) является обычным развлечением большинства 'зи архитектов'.
в связи с этим надо помочь им это делать намного быстрее -- это сэкономит время, теряемое впустую, и значит принесет прибыль работодателю
Предлагаю глянуть на ДРАКОН — один из редчайших графических языков программирования, который доказал себя на промышленной (!!!!!!) практике. Это визуальный алгоритмический язык, напоминающий блок-схемы, на устремлённых графах. Разрабатывался для проекта Буран и сейчас задействован в космической промышленности. С его помощью удалось решить реально огромную проблему: программисты знают как писать программы, но не понимают сложной предметной области, инженеры — не понимают программы, и, тем более, как программировать. Теперь инженеры сами создают управляющие приложения для оборудования — через описания и схемы.
Одна ремарка по этому поводу. Я реально не представляю как рисовать такие огромные схемы. Инженерам, имхо, проще начертить на A1 и пускать под сканер и т.д. Программерам проще лабать в каком-нибудь эмаксе в виде текстовых псевдо-схем:
...
|
|- блок 1
|- блок 2
...
и т.п.
Ибо во всяких визуальных редакторах для подобных рисовалок работать далее, чем поиграться, фактически невозможно.
Дракон дал хороший вывод: программистам — программилово, инженерам — естественные для них схемы. Поэтому текстовое представление программ никуда не денется. И в ближайшую эпоху кардинально ничего не перевернётся: бизнес будет давить net-ом с жабой (или что там будет), кто по-практичнее и менее политично угнетён — кложура, эрланг, какой-нибудь Go, в системном уровне вряд ли потеснится С/С++, кому нужно, тот будет дружить с ФЯ, матязыками, языками для рисования нот и т.д. и т.п. Безусловно всё потихоньку будет развиваться в своём русле.
Кардинальный перелом будет тогда, когда наконец-то разрешат вылезти кванто/био/нано/и пр. -процессорам, сверх-быстрым с одновременным многовариантным состоянием в единицах памяти вместо 0 и 1. И когда наконец-то родят для них доказательную математическую модель вместо ныне действующей двоичной алгебры. Тогда начнутся настоящие параллельные вычисления, и что там будет — пока никому не снилось...
PSV>Это визуальный алгоритмический язык, напоминающий блок-схемы, на устремлённых графах.
Этто ффсё от недостатка погромистов и их руководителей в подобных проектах.
Зачем погромисту переться в г. Королёв, когда он может поднять столько же денег в Нерезиновске, быстро-быстро высирая сайты-визитки или медленно-медленно автоматизируя бизнес-процессы под лампами дневного света.
PSV>Я реально не представляю как рисовать такие огромные схемы.
До тех пор, пока на них линии не пересекаются. Плавали, знаем. Вызовы функций в Си потребовали уже трёхмерных схем (а не блок-схем). Так-то.
Здравствуйте, os24ever, Вы писали:
PSV>>Это визуальный алгоритмический язык, напоминающий блок-схемы, на устремлённых графах.
O>Этто ффсё от недостатка погромистов и их руководителей в подобных проектах.
O>Зачем погромисту переться в г. Королёв, когда он может поднять столько же денег в Нерезиновске, быстро-быстро высирая сайты-визитки или медленно-медленно автоматизируя бизнес-процессы под лампами дневного света.
PSV>>Я реально не представляю как рисовать такие огромные схемы.
O>До тех пор, пока на них линии не пересекаются. Плавали, знаем. Вызовы функций в Си потребовали уже трёхмерных схем (а не блок-схем). Так-то.
Конечно криворукие программисты и такие же руководители там есть, да и везде они. Я давненько изучал материалы по этому дракону, но, насколько я помню, основная проблема всё-таки была иного плана, и квалифицированных нормальных прогеров они привлекали не мало. В их космолетах настолько специфичное оборудование, что компьютеры они напоминают ну очень отдаленно: по своему устройству они крайне просты, минимум потребление энергии и главное — сверхнадежность, потом всё остальное. Управляются эти компы очень замысловатыми командами и по специфичным принципам, ни на какой ассемблер и близко не похоже. Писать программы для прямого транслятора в машкод — так и не смогли осилить. Попытались реализовать конверторы через С — не всё гладко. Основная картина при разработке была такая: сидит пятидесятилетний дядька рядом с программером, у него в голове разрез двигателя со всеми схемами и напрочь не понимает про какие циклы с указателями ему говорит программист, а пацану в голову этот разрез двигателя не впихнешь. Как-то так. Покумекали они, и решили — пусть инженеры сами рисуют себе алгоритмы, а те только рады были, для них это родное и тёплое. Так и выкрутились.
А схемы эти реально полезные. Основная идея — чтобы как раз не было пересекающихся линий, и здорово выручает. В своей практике использовались: просто рисовались на бумаге схемы в таком стиле вместо ранее не пойми какого велосипеда со стрелками туда-сюда. Показывалось людям, далёким от программирования, все въезжали мгновенно без лишних слов, и можно было обсуждать проблему на одной языке.
Так что, если есть потребность, рекомендую присмотреться.
Сорри, что я с небольшим офтопом тут. У меня вопросик к ТС. Из этой темы форума я косвенно узрел, что Вы работаете (или студенты под вашем началом как научного руководителя) над проектом, связанным с каким-то семантическим редактором. Судя по характеру приведенной статьи, Вас интересует эта проблематика. В свое время мне на глаза попадались некие подобные системы, и я не понял, какие практичные задачи они решают. Я могу для себя выделить академический интерес (исследования в 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 и пр.
Иными словами, в жизни как-то стремишься к эффективному текстовому языку и простоте (!) — это залог для создания сложных объёмных систем, иначе полный каюк.
Я был бы очень признателен, если бы меня "просветили" в рамках пары слов по поводу того, на решение каких практичных проблем направлены подобные семантические редакторы, кроме научного, образовательного и спортивного интереса. Мне действительно это нужно для себя понять. Спасибо.
Здравствуйте, PSV100, Вы писали:
PSV>Предлагаю глянуть на ДРАКОН — один из редчайших графических языков программирования, который доказал себя на промышленной (!!!!!!) практике. Это визуальный алгоритмический язык, напоминающий блок-схемы, на устремлённых графах. Разрабатывался для проекта Буран и сейчас задействован в космической промышленности. С его помощью удалось решить реально огромную проблему: программисты знают как писать программы, но не понимают сложной предметной области, инженеры — не понимают программы, и, тем более, как программировать. Теперь инженеры сами создают управляющие приложения для оборудования — через описания и схемы.
О драконе мне известно очень хорошо.
На сайте оберонщиков много тем по нему, разрабатываются редакторы...
Книжки Паронджанова имею, читаю. Более того, одному студенту задание дал — включить дракон в его курсовую — редактор графических языков проектирования.
Если он не слиняет с этой темы — будем через год на драконе обучать алгоритмизации первокурсников и второкурсников.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, PSV100, Вы писали:
PSV>Предлагаю глянуть на ДРАКОН
гибридный язык Дракон-Ада
Хороший каламбур.
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!
Здравствуйте, PSV100, Вы писали:
PSV>Сорри, что я с небольшим офтопом тут. У меня вопросик к ТС. Из этой темы форума я косвенно узрел, что Вы работаете (или студенты под вашем началом как научного руководителя) над проектом, связанным с каким-то семантическим редактором. Судя по характеру приведенной статьи, Вас интересует эта проблематика. В свое время мне на глаза попадались некие подобные системы, и я не понял, какие практичные задачи они решают. Я могу для себя выделить академический интерес (исследования в IT — вещь необходимая), также могут понять и некоторое коммерческое продвижение подобных проектов вплоть до откатов в госструктурах. Но чем они реально могут эффективно помочь в жизни — не понимаю. Попробую обосновать свою "приставалку".
PSV>Иными словами, в жизни как-то стремишься к эффективному текстовому языку и простоте (!) — это залог для создания сложных объёмных систем, иначе полный каюк.
PSV>Я был бы очень признателен, если бы меня "просветили" в рамках пары слов по поводу того, на решение каких практичных проблем направлены подобные семантические редакторы, кроме научного, образовательного и спортивного интереса. Мне действительно это нужно для себя понять. Спасибо.
1. В первую очередь меня интересует проблема обучения программированию.
Что есть обучение профи? Это не только сумма знаний и умений, но и навык автоматического применения правильных вещей на всех уровнях.
Тут я полностью согласен с Федором Ткачевым, что технику программирования нужно ставить, как голос ставят певцу, или удар ставят боксеру.
К сожалению, при групповом обучении "поставить удар" большинству группы — проблематично. Никакие слова не помогают — только жесткое требование переписать РАБОТАЮЩУЮ программу в соответствии с требованиями задания. Хорошо, если студень молча перепишет. Но частенько находятся субъекты, которые начинают спорить и доказывать, что все работает, а остальное — пофигу. От этого со временем СИЛЬНО устаешь.
2. Кроме того, не все преподы знают, как правильно. Сейчас такое время, что квалифицированных преподов — мало. Вот и у нас с кафедры свалили наши выпускники — деньги зарабатывать. Поэтому речь идет о том, чтобы даже в условиях дефицита квалифицированных кадров все же давать качественное обучение программированию. Это можно сделать только автоматизацией.
Система просто не должна позволять новичкам писать неправильно! В ней естественно заложить паттерны правильного написания, которые будут у студня перед глазами все время обучения.
Даже разработчик семантического редактора, пописАв в семантическом редакторе, заметил, что приобрел достаточно устойчивую привычку писать структурно.
И это 4 курс, когда все плохие привычки уже сформировались! А если так делать с самого начала?
3. Семантический редактор — это только часть большой системы. Основная идея — автоматизировать оценивание работы студента. Тут большой простор для исследований. И оценивание с точки зрения качества работы, и оценивание с точки зрения наличия "плохих" кодов, и оценивание с точки зрения последующих рекомендаций по рефакторингу ... И т.п. Большое поле для исследований.
Мы уже пытались к студии прикрутить оценивание сделанной работы для программ на Додиезе — это получился целый диплом. Основное время у пацана заняло разобраться в структуре сборки и вытащить необходимую для оценивания информацию. И не не всегда этой информации хватало.
Или писать свой парсер для языка — не менее рутинная и не очень интересная работа.
ИМХО проще реализовать свою систему, в которой вся информация сохраняется. Но сделать ее совместимой в некотором смысле с существующими языками.
Таким образом, получаем систему ОДИНАКОВО оценивающую работу студентов.
Независимо от настроения и квалификации преподов, от вчерашнего праздника или критических дней...
4. И одновременно это система для препода — в ней он и задания положит, и примеры напишет. Среда должна обладать свойством генерации заданий на основе некоторого вида шаблонов. Тогда каждому студенту будет выдаваться индивидуальный вариант, равноценный с другими по данной теме. Ведь подобрать много равноценных вариантов — это проблема для препода. И в этом направлении работа тоже ведется. Образец есть — школьная сборка Ткачева. ИМХО — отличная работа!
Кроме того, в среде реализуем два режима: обучающий и контрольный. В обучающем режиме — подсказки, помощь и все такое. Вплоть до выполнения очередного шага сценария вместо студента.
А в контрольном — оценивание умений и навыков.
Если работа покажет себя на практике (первую версию вместо Кумира собираемся внедрить уже в сентябре), то будем развивать и в среду для программирования, а не для обучения.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>1. В первую очередь меня интересует проблема обучения программированию. LVV>Что есть обучение профи? Это не только сумма знаний и умений, но и навык автоматического применения правильных вещей на всех уровнях. LVV>Тут я полностью согласен с Федором Ткачевым, что технику программирования нужно ставить, как голос ставят певцу, или удар ставят боксеру. LVV>К сожалению, при групповом обучении "поставить удар" большинству группы — проблематично. Никакие слова не помогают — только жесткое требование переписать РАБОТАЮЩУЮ программу в соответствии с требованиями задания. Хорошо, если студень молча перепишет. Но частенько находятся субъекты, которые начинают спорить и доказывать, что все работает, а остальное — пофигу. От этого со временем СИЛЬНО устаешь. LVV>2. Кроме того, не все преподы знают, как правильно. Сейчас такое время, что квалифицированных преподов — мало. Вот и у нас с кафедры свалили наши выпускники — деньги зарабатывать. Поэтому речь идет о том, чтобы даже в условиях дефицита квалифицированных кадров все же давать качественное обучение программированию. Это можно сделать только автоматизацией. LVV>Система просто не должна позволять новичкам писать неправильно! В ней естественно заложить паттерны правильного написания, которые будут у студня перед глазами все время обучения. LVV>Даже разработчик семантического редактора, пописАв в семантическом редакторе, заметил, что приобрел достаточно устойчивую привычку писать структурно. LVV>И это 4 курс, когда все плохие привычки уже сформировались! А если так делать с самого начала? LVV>3. Семантический редактор — это только часть большой системы. Основная идея — автоматизировать оценивание работы студента. Тут большой простор для исследований. И оценивание с точки зрения качества работы, и оценивание с точки зрения наличия "плохих" кодов, и оценивание с точки зрения последующих рекомендаций по рефакторингу ... И т.п. Большое поле для исследований. LVV>Мы уже пытались к студии прикрутить оценивание сделанной работы для программ на Додиезе — это получился целый диплом. Основное время у пацана заняло разобраться в структуре сборки и вытащить необходимую для оценивания информацию. И не не всегда этой информации хватало. LVV>Или писать свой парсер для языка — не менее рутинная и не очень интересная работа. LVV>ИМХО проще реализовать свою систему, в которой вся информация сохраняется. Но сделать ее совместимой в некотором смысле с существующими языками. LVV>Таким образом, получаем систему ОДИНАКОВО оценивающую работу студентов. LVV>Независимо от настроения и квалификации преподов, от вчерашнего праздника или критических дней... LVV>4. И одновременно это система для препода — в ней он и задания положит, и примеры напишет. Среда должна обладать свойством генерации заданий на основе некоторого вида шаблонов. Тогда каждому студенту будет выдаваться индивидуальный вариант, равноценный с другими по данной теме. Ведь подобрать много равноценных вариантов — это проблема для препода. И в этом направлении работа тоже ведется. Образец есть — школьная сборка Ткачева. ИМХО — отличная работа! LVV>Кроме того, в среде реализуем два режима: обучающий и контрольный. В обучающем режиме — подсказки, помощь и все такое. Вплоть до выполнения очередного шага сценария вместо студента. LVV>А в контрольном — оценивание умений и навыков.
LVV>Если работа покажет себя на практике (первую версию вместо Кумира собираемся внедрить уже в сентябре), то будем развивать и в среду для программирования, а не для обучения.
Спасибо за оказанное внимание. Мои подозрения подтвердились, к сожалению, обучение — это не моя сфера, что-то конкретно дать полезного от себя не могу. Искренне лишь желаю удачи, ибо задумка ой как не легка.
Возможно, смогу дать пару намёков. Я заметил в этой теме форума, что у Вас не было тесных контактов с MPS от jetbrains. Также рекомендую глянуть, на всякий случай, если Вы не в курсе, на проект Xtext от eclipse. Обе системы направлены на создание своего DSL. Рациональные зёрна в них есть. Я их давненько смотрел, мне они показались, прежде всего, неудобными, опять же из-за проблем с GUI — непрактично это. На основе Xtext вроде сварганили какой-то xtend — язычок для жабы. Возможно, что-то полезное всплывёт из них.
Ещё одна мысль, так, к слову... Раз тут затронуты эти драконы, и вроде студенты у Вас ваяют свои редакторы под него, то попробую дать практичный совет. Не нужно повторять те попытки, которые встречаются в интернете — графические редакторы для лепки этих схем. Кроме какого-то обучения они больше ни для чего не пригодны. Может есть смысл попробывать сделать какой-нибудь mode для эмакса, по подобию org-mode. Эмакс с вимом, конечно, штуки не простые. Как альтернатива, можно глянуть в сторону JEdit (здесь будет практика на джаве), или на Sublime Text 2 (здесь — опыт на питоне). В этом случае можно убить двух зайцев — и обществу будет реальная польза (а также и некое признание с его стороны — какой-то плюс для портфолио будущего специалиста, и часто более важный, чем "раскрытая тема в дипломе"), и студент получит реальный опыт, если нюхнёт реальной жизни. Но здесь возня будет не малая, есть нюанс: для курсовой может быть излишне, для диплома — вроде не солидно. Так что, здесь — больше "интузазизма".
Здравствуйте, PSV100, Вы писали:
PSV>Спасибо за оказанное внимание. Мои подозрения подтвердились, к сожалению, обучение — это не моя сфера, что-то конкретно дать полезного от себя не могу. Искренне лишь желаю удачи, ибо задумка ой как не легка.
PSV>Возможно, смогу дать пару намёков. Я заметил в этой теме форума, что у Вас не было тесных контактов с MPS от jetbrains. Также рекомендую глянуть, на всякий случай, если Вы не в курсе, на проект Xtext от eclipse. Обе системы направлены на создание своего DSL. Рациональные зёрна в них есть. Я их давненько смотрел, мне они показались, прежде всего, неудобными, опять же из-за проблем с GUI — непрактично это. На основе Xtext вроде сварганили какой-то xtend — язычок для жабы. Возможно, что-то полезное всплывёт из них.
Спасибо. На MPS мне уже указали — я уже студентам сообщил.
Про Eclips мы знаем — программисты нашей команды тренировались в ней. Спасибо за дополнительную инфу. PSV>Ещё одна мысль, так, к слову... Раз тут затронуты эти драконы, и вроде студенты у Вас ваяют свои редакторы под него, то попробую дать практичный совет. Не нужно повторять те попытки, которые встречаются в интернете — графические редакторы для лепки этих схем. Кроме какого-то обучения они больше ни для чего не пригодны. Может есть смысл попробывать сделать какой-нибудь mode для эмакса, по подобию org-mode. Эмакс с вимом, конечно, штуки не простые. Как альтернатива, можно глянуть в сторону JEdit (здесь будет практика на джаве), или на Sublime Text 2 (здесь — опыт на питоне). В этом случае можно убить двух зайцев — и обществу будет реальная польза (а также и некое признание с его стороны — какой-то плюс для портфолио будущего специалиста, и часто более важный, чем "раскрытая тема в дипломе"), и студент получит реальный опыт, если нюхнёт реальной жизни. Но здесь возня будет не малая, есть нюанс: для курсовой может быть излишне, для диплома — вроде не солидно. Так что, здесь — больше "интузазизма".
Спасибо за наводку — можно доприлепить к студии соответствующий движок. Студия 10 это сейчас позволяет.
И это на диплом вполне потянет, если делать всерьез, а не просто для отмазки.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Спасибо за наводку — можно доприлепить к студии соответствующий движок. Студия 10 это сейчас позволяет. LVV>И это на диплом вполне потянет, если делать всерьез, а не просто для отмазки.
Приятно, что "драконья" тема не оставлена в стороне. Позволю себе ещё ремарку по этому поводу, ибо задето "за живое" — у меня у самого когда-то чесались руки что-то сбацать эдакое, но работа как всегда заваливает тебя по самые помидоры, а самим схемам далее, чем рисование на бумаге, и то редко, применение не нашлось.
Прежде всего, хотелось бы отметить о правильном их применении. Преобразования вида Дракон -> C -- не более, чем начальная обучалка в стиле "так вот ты какой северный олень". Какой-нибудь функциональный язык дает на выхлопе код С — это реальная практичная задача, и подобных проектов не мало. Изначально, где дракона родили, в этих схемах манипулировали реальными аппаратными командами, и транслировали данные как бы всё в оригинале — это природное практичное использование.
Иными словами, форсировать тему Дракон -> унив. язык общего применения — не стоит. Имхо, уверен, что у Вас такое же осознание реальности.
Интересен и неоднозначен способ как схемы создавать. Ковыряние мышкой — это для какого-нибудь Visio, а не для программистов. Нужен удобный текстовый синтаксис, причём увлекаться псевдографикой, т.е. полноценными прямоугольниками и т.п., не стоит. Лучше вложиться в рамки символов "| — + -> * #" и пр. Затем, уже когда нужно, рисовать полные весёлые картинки, на экране, печать, экспорт и т.д. К сожалению, сейчас в голову ничего конкретного не лезет, чётко сказать не могу.
Сомнительна польза от наличия таких схем в монстрах-IDE в виде Vis. studio. Понимаете, большая часть народа (но не все), кто работает в студии, эклипсе и пр., вынуждены будут рисовать какой-нибудь UML или какие-то диаграммы в той же Visio. А вот те, кто не чурается (часто совместно с монстрами) работать в эмакс/вим/сублиме/jedit и им подобным — очень запросто могут подраконить. К тому же, у меня в голове была косвенная мысль, что не плохо было бы, если студентов пораньше познакомить с программисткими редакторами, и чем раньше у них придёт понимание того, зачем они нужны — им легче будет жить (естественно, кто сам себе с детства всё выхватывает и "в теме" — того и учить не надо, не мне Вам рассказывать).
Скорее всего, весь ваш комплекс ваяется на студии, и очень вероятен, что C#. В этом случае, если подойти к этому по-серьёзнее, лучше реализовать эти схемы обособлено от общего проекта. Возможно, это как-то не вписывается в какие-то сложившиеся рамки, но лучше подойти к этому дело по-человечнее. Поясню.
В идеале необходимо реализовать ядро на С++, желательно сразу кроссплатформенное, не зависимое ни от какой студии. Затем уже к ней прикрутить. А дальше уже есть потенциал прикручивания к чему угодно, и отдельное приложение — само собой. Более того, если получится родить удачный движок, вполне возможно расширить применение, и подключить другие схемы. Например, такие диаграммы последовательностей как здесь, иногда приходится что-то такое колхозить на бумажках. Или для Mind map так и нет толкового инструментария. В общем, полёт фантазий не ограничен.
Взяться за такое смогут реально толковые пацаны (но и девчонки ). Кроме опыта, они особо не потеряют время зря: у них появится задел на будущее, вплоть до создания Donate-софта или шаровары, а то и для Visio конкуренцию составят
Здравствуйте, Don Reba, Вы писали:
DR>Пиком человеческого прогресса на данный момент ялвляется Vim + Nemerle. С хорошим языком, из IDE бывает нужен только интеллисенс, при интенсивной работе с незнакомыми API. Существующие визуальные редакторы в лучшем случае подспорья для новичков или непрограммистов.
Значит я новичек-непрограммист, так как мне порой рефакторинга выноса кода в локальную функцию или метода, очень не хватает в Nemerle.
Комплит и навигация тоже делает мою работу существенно быстрее.
Так что каждому свое. Есть аскеты, но большинству людей подавай удобство.
Проблема только в том, что Лаптев говоря о визуальном программировании на самом деле имеет ввиду ровно обратное. Его любимый Блэкбокс только файлы пишет бинарные. А в удобстве редактирования кода он не уступает разве что нотпэду.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, LaptevVV, Вы писали:
LVV>Кроме того, выделили процедурное ядро Додиеза и Оберона — оно одинаковое с семантической точки зрения. LVV>Взяли грамматики этих языков и сравнили. LVV>И теперь у нас одной кнопочкой на экране хочешь — Додиез, а хочешь — Оберон. В процедурной части, естественно.
А что вы понимаете под процедурной частью?
И как насчет таких вещей как: разрешение перегрузок, неявное приведение типов, лифтинг операторов в Nulable?
LVV>Тут еще работать и работать. Но к сентябрю хотим первую версию запустить. Прямо в классах.
Версию чего? Если вы решили сделать поддержку C# 4 по спецификации, и вас двое человек, то первого сентября у вас может что-то и заработает, но только не в этом году, а годка эдак через 2 (а то и через 5).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Проблема только в том, что Лаптев говоря о визуальном программировании на самом деле имеет ввиду ровно обратное. Его любимый Блэкбокс только файлы пишет бинарные. А в удобстве редактирования кода он не уступает разве что нотпэду.
А как же ручная раскраска программы в разные цвета? В ноутпаде такого нееету!
Здравствуйте, IT, Вы писали:
IT>Где-то в середине 90-х был подобный редактор для модулы, если не ошибаюсь. Всё проверял, всё контролировал, не давал делать ошибок и везде старался как мог. Смотрелось очень круто. Выкинули его через неделю и не потому что он плохо делал свою работу, а как раз наоборот слишком хорошо. Смотреть на него, конечно, было прикольно, но работать в нём было невозможно по одной простой причине. Некомпилируемый, разваленный и разрезанный на куски код — это перманентное состояние программы над которой в данный момент трудится программис. И каким образом он перейдёт из одного рабочего состояния программы в другое известно только ему одному.
Программа на лиспе при редактировании в emacs'е в любой момент представляет из себя некое законченное AST. Она может не компилироваться, но там все будет разбито на атомы и s-выражения.
Здравствуйте, LaptevVV, Вы писали:
LVV>2. Отец БлэкБокса Клеменс Шиперски работает в Microsoft Research: http://research.microsoft.com/en-us/um/people/cszypers/ LVV>А представление модулей в БлэкБоксе — не текстовое. Это было еще в 95-м году. LVV>3. Программа — это мультиграф, вершинами которого являются модули. LVV>В системе этот мультиграф может хранится в каком угодно виде. LVV>И только для человека его нужно представить в текстовом виде. Но это не значит, что в текстовом же виде программу надо и обрабатывать. LVV>И даже вводить можно не в текстовом виде.
Это все жутко интересно, пока речь идет об относительно небольших программах.
Но проект эквивалентный хотя бы паре сотен тысяч строк в мультиграфе и не в текстовом виде — это не для людей точно
Здравствуйте, uncommon, Вы писали:
U>Программа на лиспе при редактировании в emacs'е в любой момент представляет из себя некое законченное AST. Она может не компилироваться, но там все будет разбито на атомы и s-выражения.
Лисп не то. Там AST пишется прямо в текстовом виде. Там и нет ничего кроме AST. Лучше может быть только написание программы прямо в машинных кодах. Наши древние предки так умели. Выщёлкивали команды процессора тумблерами на коммандном пункте уплавления ЭВМ
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, uncommon, Вы писали:
U>>Программа на лиспе при редактировании в emacs'е в любой момент представляет из себя некое законченное AST. Она может не компилироваться, но там все будет разбито на атомы и s-выражения.
IT>Лисп не то. Там AST пишется прямо в текстовом виде. Там и нет ничего кроме AST. Лучше может быть только написание программы прямо в машинных кодах. Наши древние предки так умели. Выщёлкивали команды процессора тумблерами на коммандном пункте уплавления ЭВМ
Не понял, при чем здесь сравнение Лиспа с машинными кодами. Лисп — язык высокого уровня, не уступающий по мощности, а в большинстве случаев превосходящий другие широко используемые языки программирования.
Здравствуйте, PSV100, Вы писали:
PSV>Иными словами, форсировать тему Дракон -> унив. язык общего применения — не стоит. Имхо, уверен, что у Вас такое же осознание реальности.
C этим согласен. PSV>Интересен и неоднозначен способ как схемы создавать. Ковыряние мышкой — это для какого-нибудь Visio, а не для программистов. Нужен удобный текстовый синтаксис, причём увлекаться псевдографикой, т.е. полноценными прямоугольниками и т.п., не стоит. Лучше вложиться в рамки символов "| — + -> * #" и пр. Затем, уже когда нужно, рисовать полные весёлые картинки, на экране, печать, экспорт и т.д. К сожалению, сейчас в голову ничего конкретного не лезет, чётко сказать не могу.
Язык представления — это правильно. И то, что он должен быть доступен руками набрать — это тоже правильно. PSV>Сомнительна польза от наличия таких схем в монстрах-IDE в виде Vis. studio. Понимаете, большая часть народа (но не все), кто работает в студии, эклипсе и пр., вынуждены будут рисовать какой-нибудь UML или какие-то диаграммы в той же Visio. А вот те, кто не чурается (часто совместно с монстрами) работать в эмакс/вим/сублиме/jedit и им подобным — очень запросто могут подраконить. К тому же, у меня в голове была косвенная мысль, что не плохо было бы, если студентов пораньше познакомить с программисткими редакторами, и чем раньше у них придёт понимание того, зачем они нужны — им легче будет жить (естественно, кто сам себе с детства всё выхватывает и "в теме" — того и учить не надо, не мне Вам рассказывать).
Спасибо за мысль — я попробую что-нить подобное внедрить на 3 курсе в дисциплине по системному ПО. PSV>Скорее всего, весь ваш комплекс ваяется на студии, и очень вероятен, что C#. В этом случае, если подойти к этому по-серьёзнее, лучше реализовать эти схемы обособлено от общего проекта. Возможно, это как-то не вписывается в какие-то сложившиеся рамки, но лучше подойти к этому дело по-человечнее. Поясню.
Вы совершенно правы. Но это — пилотный проект для отработки архитектуры и выявления тонких мест. PSV>В идеале необходимо реализовать ядро на С++, желательно сразу кроссплатформенное, не зависимое ни от какой студии. Затем уже к ней прикрутить. А дальше уже есть потенциал прикручивания к чему угодно, и отдельное приложение — само собой. Более того, если получится родить удачный движок, вполне возможно расширить применение, и подключить другие схемы. Например, такие диаграммы последовательностей как здесь, иногда приходится что-то такое колхозить на бумажках. Или для Mind map так и нет толкового инструментария. В общем, полёт фантазий не ограничен. PSV>Взяться за такое смогут реально толковые пацаны (но и девчонки ). Кроме опыта, они особо не потеряют время зря: у них появится задел на будущее, вплоть до создания Donate-софта или шаровары, а то и для Visio конкуренцию составят
В планах — переписывание пилотного проекта на Qt — уже пути намечаем, Qt практически позволяет все, что доступно в студии.
Пацан, который делал курсовую по диаграмма — делал сразу на Qt (2 курс)...
Если с темы не слиняет — это ему и задел на диплом, и поучаствовать в конкурсах Умника и Старта.
Мы, кстати, с пилотным проектом семантического редактора Умник выиграли.
Еще мысль есть, но попозже, сделать то же самое и в БлэкБоксе.
И тогда сравнить трудности и особенности реализации: Студия- QtCreator-BlackBox
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, LaptevVV, Вы писали:
LVV>>Мы с Вольфхаундом уже пообщались. Поизучаем, посторонние решения посмотреть всегда полезно.
VD>Более точно было бы сказать "по игнорировали".
VD>А эта ваша блэкбоксовщена — это полное мракобесие. Никакими учебными интересами ее не оправдать. Учите людей позавчерашнему дню.
Влад, ты не прав!
Мы учим программированию, а не технологиям. Для современных технологий у них дофига отдельных курсов.
А программмеру — полезно с разными подходами знакомиться.
Тем более, что БлэкБокс обладает некоторыми чертами, которые даже профи оценить не способны...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, LaptevVV, Вы писали:
LVV>>Кроме того, выделили процедурное ядро Додиеза и Оберона — оно одинаковое с семантической точки зрения. LVV>>Взяли грамматики этих языков и сравнили. LVV>>И теперь у нас одной кнопочкой на экране хочешь — Додиез, а хочешь — Оберон. В процедурной части, естественно.
VD>А что вы понимаете под процедурной частью?
Нет наследования. Остальное — все есть. VD>И как насчет таких вещей как: разрешение перегрузок, неявное приведение типов, лифтинг операторов в Nulable?
Никаких неявных преобразований. Перегрузку операторов для начинающих — нафиг!
Нуллабле — пока нафиг. LVV>>Тут еще работать и работать. Но к сентябрю хотим первую версию запустить. Прямо в классах. VD>Версию чего? Если вы решили сделать поддержку C# 4 по спецификации, и вас двое человек, то первого сентября у вас может что-то и заработает, но только не в этом году, а годка эдак через 2 (а то и через 5).
Нас 4 человека.
Среда уже работает.
Идет не разработка а рефакторинг. В первую очередь рефакторинг общей архитектуры.
Уточнение семантики конструкций, исследование операций рефакторинга для включения в систему.
Анализ действий программиста в среде.
Так что к сентябрю, думаю, успеем.
Проблема пока в разработке хорошего хелпа — один пацан как-то не справляется пока...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Michael7, Вы писали:
M>Здравствуйте, LaptevVV, Вы писали:
LVV>>2. Отец БлэкБокса Клеменс Шиперски работает в Microsoft Research: http://research.microsoft.com/en-us/um/people/cszypers/ LVV>>А представление модулей в БлэкБоксе — не текстовое. Это было еще в 95-м году. LVV>>3. Программа — это мультиграф, вершинами которого являются модули. LVV>>В системе этот мультиграф может хранится в каком угодно виде. LVV>>И только для человека его нужно представить в текстовом виде. Но это не значит, что в текстовом же виде программу надо и обрабатывать. LVV>>И даже вводить можно не в текстовом виде.
M>Это все жутко интересно, пока речь идет об относительно небольших программах. M>Но проект эквивалентный хотя бы паре сотен тысяч строк в мультиграфе и не в текстовом виде — это не для людей точно
Пока речь идет в первую очередь о лабах, курсовых и дипломах. Нужен инструмент для разбора и оценки.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, VladD2, Вы писали:
VD>Значит я новичек-непрограммист, так как мне порой рефакторинга выноса кода в локальную функцию или метода, очень не хватает в Nemerle. VD>Комплит и навигация тоже делает мою работу существенно быстрее.
Я имел в виду не-текстовые редакторы — формы, диаграммы, итп. По моему опыту, даже WinForms быстрее создаётся в коде.
Здравствуйте, LaptevVV, Вы писали:
PSV>>Интересен и неоднозначен способ как схемы создавать. Ковыряние мышкой — это для какого-нибудь Visio, а не для программистов. Нужен удобный текстовый синтаксис, причём увлекаться псевдографикой, т.е. полноценными прямоугольниками и т.п., не стоит. Лучше вложиться в рамки символов "| — + -> * #" и пр. Затем, уже когда нужно, рисовать полные весёлые картинки, на экране, печать, экспорт и т.д. К сожалению, сейчас в голову ничего конкретного не лезет, чётко сказать не могу.
LVV>Язык представления — это правильно. И то, что он должен быть доступен руками набрать — это тоже правильно.
Именно так. Для программистов текстовые файлы — как калькуляторы для бухгалтеров . Для них в программах в различных элементах для редактирования данных часто делают кнопочки, что-то вроде комбобокса, где по кнопке выпадает калькулятор. Кроме того, часто где-то вверху есть большие кнопки для вызова калькулятора, календаря, да и в винде есть свой калькулятор. Но я толком и не видел, что ими кто-то пользуется: под рукой всегда есть калькулятор с большими кнопками. Поэтому, когда скинули "перфокарты" — счёты — пока лучше для них ничего не придумали
PSV>>Сомнительна польза от наличия таких схем в монстрах-IDE в виде Vis. studio. Понимаете, большая часть народа (но не все), кто работает в студии, эклипсе и пр., вынуждены будут рисовать какой-нибудь UML или какие-то диаграммы в той же Visio. А вот те, кто не чурается (часто совместно с монстрами) работать в эмакс/вим/сублиме/jedit и им подобным — очень запросто могут подраконить. К тому же, у меня в голове была косвенная мысль, что не плохо было бы, если студентов пораньше познакомить с программисткими редакторами, и чем раньше у них придёт понимание того, зачем они нужны — им легче будет жить (естественно, кто сам себе с детства всё выхватывает и "в теме" — того и учить не надо, не мне Вам рассказывать).
LVV>Спасибо за мысль — я попробую что-нить подобное внедрить на 3 курсе в дисциплине по системному ПО.
Имхо, если речь идет про С/С++, то это не очень удачная сфера для какого-то знакомства с вимом/эмаксом. Здесь как раз лучше, если для освоения тяжелого С/С++ будут помогать иде, та же студия, или если и кроссплатформа осваивается — какой-нибудь QtCreator, CodeBlocks и пр. Те интузиасты (и их не мало), кто ваяет на С в виме/эмаксе, как правило, уже опытные в С, и собак наелись в разных монстрах-иде. Здесь и язык тяжелый, и инструмент потребует не малого вникания.
По своему опыту. Я сначала пытался ринутся на вим/эмакс, уже имея представление, какие профиты они могут дать. Но не было практичной задачи, которая бы нагнула, и я так их осилить и не смог. Затем я нашёл способ как себя заставить. Я попробовал Vimperator/Pentadactyl — плагины для FireFox, эмулирующие управление броузером в стиле вима. Понравилось, наваял себе пару расширений, и до сих пор так и "подсёрфываю" — дошло, чем может быть вим. Попробовал KeySnail — похожий плагин, но эмулирующий эмакс (местами приятнее вимператора) — ага, вот ты какой эмакс. И честно, когда запускаешь супер-монстра студию или эклипс и пр. — очень становится печально при месеве всяких кнопок с панелями.
Также в виме/эмаксе есть и другая сторона. Сейчас я вынужден редко ими пользоваться. Одновременно приходится работать и в монстрах, и во всяких системах для работы с СУБД, и прочий спец. софт. И когда одновременно переключаешься с одного распространенного принципа управления на другой (и в виме и эмаксе — они тоже разные) — в голове не успеваешь переключиться, путаешься, и это реально мешает. К тому же, у нас в команде есть свои всякие наколенные язычки, DSL и пр. и для них есть и наколенная иде на базе JEdit — оказалось проще и быстрее приспособить, чем тот же эклипс, да и работать в нем приятнее. Поэтому сейчас JEdit у меня основной редактор (именно как программисткий редактор).
По сему, лучше смотреть на вим/эмакс при изучении какого нибудь питона/руби. Здесь и монстры-иде не сильны в плане развитого автокомплита, код-броузера, рефакторинга и т.д. в силу динамичной природы таких языков. Как раз, хороший момент, когда можно попробывать другой стиль разработки. Например, далеко не всегда автокомплит — супер киллер-фича, часто он и тормозной, и не всегда верный в этих монстрах. В простых языках частенько достаточно быстрого (!) автокомплита из уже введенных слов или из соседних буферов + предопределенный список элементов. При этом никаких тормозов и раздражений, плюс удобные всякие коде-сниппеты, умная расстановка отступов, всякие приятненькие автоставлялочки/удалялочки, множественное выделение и пр. — красота. Плюс удобное управление средой, огромный потенциал для реализации нужных именно тебе операций над текстом и т.д.
Имхо, есть смысл начать с Sublime Text 2. Он "не безгрешен", но думаю, что его авторы в душе не сильно против, что их триал будут юзать в образовании их будущие клиенты (каюсь, сам его не приобретал, ибо использую крайне редко). Редактор простой и имхо "расово-верный". Если его "прокачать" — станет понятно, зачем смотреть на вим с эмаксом.
И ещё. По поводу системного программирования. У меня как раз появилась потребность после долгого перерыва снова дёрнуться к C/C++. Есть мысль, что в этих рамках неплохо глянуть также на Go. Я недавно о нём вспоминал, вот здесь
мой пост в соседнем форуме и от него по ветке ещё пару сообщений, где можно узреть кое-какие взгляды, почему на Go не мешало бы обратить внимание. Сейчас Go промышленно малопригодный, и особо с ним ненужно увлекаться, но обратить внимание на то, что он может быть альтернативой — стоит. Язык концептуально — очень неплох. К тому же, напр., если понять, почему там нет классов, и чем интерфейсы их лучше — гараздо легче потом понимаешь классы типов в хаскеле, а типы с протоколами в кложуре — ценить начинаешь, и т.д.
LVV>В планах — переписывание пилотного проекта на Qt — уже пути намечаем, Qt практически позволяет все, что доступно в студии. LVV>Пацан, который делал курсовую по диаграмма — делал сразу на Qt (2 курс)... LVV>Если с темы не слиняет — это ему и задел на диплом, и поучаствовать в конкурсах Умника и Старта. LVV>Мы, кстати, с пилотным проектом семантического редактора Умник выиграли.
LVV>Еще мысль есть, но попозже, сделать то же самое и в БлэкБоксе. LVV>И тогда сравнить трудности и особенности реализации: Студия- QtCreator-BlackBox
Не совсем понятно, что именно планируется переписывать на разные языки: весь учебный комплекс или систему по поводу схем. Имхо, в любом случае, затея не практична. Понимаете, нас умные дядьки учат, что вы через всякие супер-пупер ORM в своих системах сможете менять любую СУБД как перчатки. На практике в сложных и огромных системах смена СУБД — это как секс среди подростков: о нём больше говорят, чем есть на самом деле. Если Вы зададите цель — сравнить разработку в "Студия- QtCreator-BlackBox" — это косвенно станет главным, и функционал комплекса будет не в ту сторону, и соответствующего масштаба/уровня.
Кстати, имхо, не стоит углубляться в рамках BlackBox. Академически — вещь интересная, крайне полезно знать его концепции, но система — промышленно не применима. Достаточно человека познакомить с ней, когда ему потребуется, напр., какие-то инженерные расчёты — он вспомнит о нём и успешно решит свою задачу (если другого варианта не будет).
А сравнить принципы разработки в разных языках — вещь обязательная. Но, имхо, это лучше делать в рамках уч. процесса, реализуя какие-то спец. задания, например, где конкретно видно различие в подходах, скажем, где-то RAII, а где-то try-finally, и в таком духе.
И ещё, по поводу этих драконов. Имхо, есть смысл подойти к этому делу по аналогии с системами для создания всяких Wiki-страниц, или документации, как это делает AsciiDoc например. Т.е. нужно:
— сформировать "стандарт" языка — простое (!) текстовое представление дракон-схем;
— реализовать движок, который будет текст конвертить в HTML-представление схемы, с возможностью интерактивного взаимодействия — переходы между схемами, напр., из какого-то блока-прямоугольника раскрываем его схему-детализацию и далее в таком духе. Если это оправдает себя, то возможны и другие форматы: pdf, свои бинарные и т.д. Реализовать нужно на чистом C++, без Qt — STL, Boost, минимум зависимостей, кроссплатформа, куда хошь прикручивай и делай отдельные утилиты и т.д.
— нужны плагины для всяких редакторов: раскраска синтаксиса, форматирование, "тексто-помогалки" и т.д. Такое соседство рядом с эмаксовым org-mode — самое то.
— нужны инструменты и для графических редакторов, напр., какое-то расширение для Visio. Я не спец по диаграммам, включая и эту Visio, возможно есть и другие общепризнанные вещи.
Это то, что востребовано в реальной жизни. Для диплома, имхо, главное — движок. Если в уч. комплексе есть и свои текстовые редакторы, и какие-то графические — интеграция движка, имхо, будет гармоничной.
Надеюсь, что общая идея понятна (блин, вот мысли летят и руки прям чешутся конкуренцию составить )
Хочу обратить внимание , что среда разрабокти + язык, просто обязаны выполнять функцию иерархической декомпозицию .
Другими словами разбивать сложную программу на небольшие куски по 3 — 5 сущностей. В этом плане представленные визуальные решения не выдерживают никакой критики.
Здравствуйте, AndrewVK, Вы писали:
LVV>>Пока речь идет в первую очередь о лабах, курсовых и дипломах. Нужен инструмент для разбора и оценки. AVK>И чем текстовый вид не прокатил для "разбора и оценки"? Тяжело парсер было написать?
Парсер — анахронизм 50-60 годов. Пора уже без парсеров обходится, если есть возможность.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, PSV100, Вы писали:
PSV>Имхо, если речь идет про С/С++, то это не очень удачная сфера для какого-то знакомства с вимом/эмаксом. Здесь как раз лучше, если для освоения тяжелого С/С++ будут помогать иде, та же студия, или если и кроссплатформа осваивается — какой-нибудь QtCreator, CodeBlocks и пр. Те интузиасты (и их не мало), кто ваяет на С в виме/эмаксе, как правило, уже опытные в С, и собак наелись в разных монстрах-иде. Здесь и язык тяжелый, и инструмент потребует не малого вникания.
QtCreator мои студиозы и так осваивают — в процессе писания курсовой по ООП. Я не запрещаю — пишут и в CodeBlocks. Все это 2 курс. PSV>[...]
Спасибо за массу информации! Весьма полезная инфа от практиков — то что нужно.
Я постепенно буду это все пробовать в том или ином виде.
К сожалению, наши молодые сплошь погрязли в микрософт. Задачи позволяют не слезать с этого монстра.
Да и свалили с кафедры — слишком мало платят. А они — хорошие программеры и в нашей Астрахани запросто зарабатывают 40-50 штук.
Для Астрахани это серьезные деньги. А в универе — платили 10 — кандидатам -доцентам.
Но еще есть я — и я обязательно буду пробовать. LVV>>Еще мысль есть, но попозже, сделать то же самое и в БлэкБоксе. LVV>>И тогда сравнить трудности и особенности реализации: Студия- QtCreator-BlackBox
PSV>Не совсем понятно, что именно планируется переписывать на разные языки: весь учебный комплекс или систему по поводу схем. Имхо, в любом случае, затея не практична. Понимаете, нас умные дядьки учат, что вы через всякие супер-пупер ORM в своих системах сможете менять любую СУБД как перчатки. На практике в сложных и огромных системах смена СУБД — это как секс среди подростков: о нём больше говорят, чем есть на самом деле. Если Вы зададите цель — сравнить разработку в "Студия- QtCreator-BlackBox" — это косвенно станет главным, и функционал комплекса будет не в ту сторону, и соответствующего масштаба/уровня.
Не. Мы сначала делаем законченную версию в рамках студии на Додиезе — не отвлекаясь на переписывание. Когда система будет в работе — попробуем переписать — именно с целью получить опыт переписывания и переноса на другие платформы. PSV>Кстати, имхо, не стоит углубляться в рамках BlackBox. Академически — вещь интересная, крайне полезно знать его концепции, но система — промышленно не применима. Достаточно человека познакомить с ней, когда ему потребуется, напр., какие-то инженерные расчёты — он вспомнит о нём и успешно решит свою задачу (если другого варианта не будет).
А я так и делаю. Я именно с концепциями и знакомлю.
Поскольку многие школьники паскаль в школе учили — им без проблем в БлэкБоксе наваять программу. PSV>[...] PSV>Это то, что востребовано в реальной жизни. Для диплома, имхо, главное — движок. Если в уч. комплексе есть и свои текстовые редакторы, и какие-то графические — интеграция движка, имхо, будет гармоничной.
Опять же — спасибо за практическую информацию!
PSV>Надеюсь, что общая идея понятна (блин, вот мысли летят и руки прям чешутся конкуренцию составить )
НУ, так конкурируйте!...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, minorlogic, Вы писали:
M>Хочу обратить внимание , что среда разрабокти + язык, просто обязаны выполнять функцию иерархической декомпозицию .
M>Другими словами разбивать сложную программу на небольшие куски по 3 — 5 сущностей. В этом плане представленные визуальные решения не выдерживают никакой критики.
1. Единица трансляции — модуль. Модуль пишет программист. Он выделяет сущности и собирает их в модули.
2. Модули — загружаемая и исполняемая единица системы.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, minorlogic, Вы писали:
M>>Хочу обратить внимание , что среда разрабокти + язык, просто обязаны выполнять функцию иерархической декомпозицию .
M>>Другими словами разбивать сложную программу на небольшие куски по 3 — 5 сущностей. В этом плане представленные визуальные решения не выдерживают никакой критики. LVV>1. Единица трансляции — модуль. Модуль пишет программист. Он выделяет сущности и собирает их в модули. LVV>2. Модули — загружаемая и исполняемая единица системы.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, LaptevVV, Вы писали:
LVV>>Здравствуйте, minorlogic, Вы писали:
M>>>Хочу обратить внимание , что среда разрабокти + язык, просто обязаны выполнять функцию иерархической декомпозицию .
M>>>Другими словами разбивать сложную программу на небольшие куски по 3 — 5 сущностей. В этом плане представленные визуальные решения не выдерживают никакой критики. LVV>>1. Единица трансляции — модуль. Модуль пишет программист. Он выделяет сущности и собирает их в модули. LVV>>2. Модули — загружаемая и исполняемая единица системы.
G>Модули 1. и 2. могут не совпадать.
Каждый написанный и отлаженный модуль может быть загружен и выполнен.
Или вы имеете ввиду представление модулей — исходных и исполняемых?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
AVK>>И чем текстовый вид не прокатил для "разбора и оценки"? Тяжело парсер было написать? LVV>Парсер — анахронизм 50-60 годов.
О как. А есть хоть один современный промышленный язык без парсера?
LVV> Пора уже без парсеров обходится, если есть возможность.
Зачем?
... << RSDN@Home 1.2.0 alpha 5 rev. 21 on Windows 7 6.1.7601.65536>>
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, LaptevVV, Вы писали:
LVV>>>Здравствуйте, minorlogic, Вы писали:
M>>>>Хочу обратить внимание , что среда разрабокти + язык, просто обязаны выполнять функцию иерархической декомпозицию .
M>>>>Другими словами разбивать сложную программу на небольшие куски по 3 — 5 сущностей. В этом плане представленные визуальные решения не выдерживают никакой критики. LVV>>>1. Единица трансляции — модуль. Модуль пишет программист. Он выделяет сущности и собирает их в модули. LVV>>>2. Модули — загружаемая и исполняемая единица системы.
G>>Модули 1. и 2. могут не совпадать. LVV> LVV>Каждый написанный и отлаженный модуль может быть загружен и выполнен. LVV>Или вы имеете ввиду представление модулей — исходных и исполняемых?
Нет, я имею ввиду фразу "единица трансляции", например файл в C++, но он не может быть отдельно загружен и выполнен.
Здравствуйте, LaptevVV, Вы писали:
VD>>И как насчет таких вещей как: разрешение перегрузок, неявное приведение типов, лифтинг операторов в Nulable? LVV>Никаких неявных преобразований. Перегрузку операторов для начинающих — нафиг!
Тогда не надо называть "это" C#-ом. Называйте это честно — C-подобный синтаксис.
LVV>Нуллабле — пока нафиг.
Настоящий компилятор тем и отличается от игрушечного, что содержит миллионы тонкостей. Сделать игрушечный компилятор может почти любой программист. А вот настоящий единицы в этом мире. В прочем, надеюсь, что с появлением Н2 это изменится.
LVV>>>Тут еще работать и работать. Но к сентябрю хотим первую версию запустить. Прямо в классах. VD>>Версию чего? Если вы решили сделать поддержку C# 4 по спецификации, и вас двое человек, то первого сентября у вас может что-то и заработает, но только не в этом году, а годка эдак через 2 (а то и через 5). LVV>Нас 4 человека.
Это мало что меняет. МС убил на упрвляемую версию своего компилятора шарпа уже где-то лет пять. И они еще не закончили. Но они делают настоящий продукт, а не игрушку. Так как вы себе таких задач не ставите, то может и выйдет чуть быстрее.
Но, в любом случае, твои планы — это прожектерство. Все что у вас будет осенью — это прототип игрушечного компилятора в котором не будет тучи деталей. А, как я уже сказал, компилятор определяют именно детали.
LVV>Среда уже работает.
Это что-то вроде того что есть в Блэкбоксе? Тогда не надо это средой называть. Тебя просто не поймут. Под средой в наше время понимают IDE класса VS, Idea или Eclips, но никак не Вордпэл с функций запуска кода.
LVV>Идет не разработка а рефакторинг. В первую очередь рефакторинг общей архитектуры.
Рефакторинг чего? Блэкбокса, что ли?
LVV>Уточнение семантики конструкций, исследование операций рефакторинга для включения в систему. LVV>Анализ действий программиста в среде. LVV>Так что к сентябрю, думаю, успеем. LVV>Проблема пока в разработке хорошего хелпа — один пацан как-то не справляется пока...
Хелпом сыт не буедешь.
В общем, похоже, что ты в очередной раз прочел статью и сделал из нее совершенно неверные выводы. Ваша игрушка ничего не имеет общего с тем о чем говорилось в статье. Соответственно она будет иметь примерно такой же интерес для программистов как и Блэкбокс, т.е. чуть менее чем никакой.
Не знаю, что ваше новое творение может дать с точки зрения обучения, но у меня стойкое впечатление, что вы готовите учеников к "прошлой войне".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, LaptevVV, Вы писали:
LVV>Мы учим программированию, а не технологиям. Для современных технологий у них дофига отдельных курсов. LVV>А программмеру — полезно с разными подходами знакомиться.
Вот именно — разным, а не одному Блэкбоксу.
LVV>Тем более, что БлэкБокс обладает некоторыми чертами, которые даже профи оценить не способны...
Ничем он для профи не интересен. В прочем, они ученикам ничем не интересен. Им в начале как нельзя нужна помощь. Современные IDE ее оказывают. А Блэкбокс застрял в прошлом. Никакой помощи от него нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В прочем, они ученикам ничем не интересен.
Я представляю реакцию студентов, которые имели возможность программировать в любой современной IDE, при виде этого блэкбокса: "Бл*! Что это за ***ня?! И мне с этим работать???"
Более того блэкбокс уже не интересен даже самому Вирту. Он на него давно забил. Команда под руководством Вирта даже не смогла доделать версию 1.6, которую они забросили на релизе rc5 в 2007 году. И только суровые русские программисты-преподы уверовшие в православность Вирта пытаются допилить этот гребанный блэкбокс. У них мало что выходит. Но своих студентов помучить блэкбоксом они более чем рады.
Здравствуйте, LaptevVV, Вы писали:
LVV>http://ajc.su/koding/budushhee-programmirovaniya/ LVV>[q] LVV>[Автор оригинального текста — Paul Chiusano, программист, работает в Capital IQ, пишет преимущественно на Scala. Один из разработчиков библиотеки scalaz — прим. пер.]
Лаптев, ты меня просто разочаровываешь. В кои то веки запостил хорошую ссылку
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, LaptevVV, Вы писали:
LVV>>Мы учим программированию, а не технологиям. Для современных технологий у них дофига отдельных курсов. LVV>>А программмеру — полезно с разными подходами знакомиться.
VD>Вот именно — разным, а не одному Блэкбоксу.
Влакд, Студия 10, QtCreator, BlackBox — для второго курса достаточно. LVV>>Тем более, что БлэкБокс обладает некоторыми чертами, которые даже профи оценить не способны... VD>Ничем он для профи не интересен. В прочем, они ученикам ничем не интересен. Им в начале как нельзя нужна помощь. Современные IDE ее оказывают. А Блэкбокс застрял в прошлом. Никакой помощи от него нет.
"А баб яга — против" (с).
Оставим этот спор о ББ.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, gandjustas, Вы писали:
LVV>>>>1. Единица трансляции — модуль. Модуль пишет программист. Он выделяет сущности и собирает их в модули. LVV>>>>2. Модули — загружаемая и исполняемая единица системы. G>>>Модули 1. и 2. могут не совпадать. LVV>> LVV>>Каждый написанный и отлаженный модуль может быть загружен и выполнен. LVV>>Или вы имеете ввиду представление модулей — исходных и исполняемых? G>Нет, я имею ввиду фразу "единица трансляции", например файл в C++, но он не может быть отдельно загружен и выполнен.
В том-то и дело, что С++ в этом месте остался в 70 году...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, minorlogic, Вы писали:
M>Я говорил про декомпозицию на всех уровнях
Ну, вы же понимаете, что граф связей — это только представление, для программиста?
В явном виде он же не хранится.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, minorlogic, Вы писали:
M>>Я говорил про декомпозицию на всех уровнях LVV>Ну, вы же понимаете, что граф связей — это только представление, для программиста? LVV>В явном виде он же не хранится.
Не понимаю. Приведенный тут как пример , ДРАКОН как справляется с задачей декомпозиции ?
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, LaptevVV, Вы писали:
LVV>>Здравствуйте, minorlogic, Вы писали:
M>>>Я говорил про декомпозицию на всех уровнях LVV>>Ну, вы же понимаете, что граф связей — это только представление, для программиста? LVV>>В явном виде он же не хранится.
M>Не понимаю. Приведенный тут как пример , ДРАКОН как справляется с задачей декомпозиции ?
Дракон — никак.
Декомпозиция задачи — это творческий акт. Язык может поддерживать этот творческий акт или не поддерживать.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
IT>Мы тут говорим о программировании, а не о рисовании. Разве нет?
Программированние — это построение программ. Программа — это преобразование данных в другие данные сообразно некоторому алгоритму. Определения, только что выдуманные, но академические определения, думаю, подобны. Заметь, ни про перфоленту, клавиатуру или мышь нигде не сказано.
IT>>>ASP.NET навязчиво предлагал писать html не руками, а размазывать его по экрану мышкой. GZ>>Через 10-20 лет я вообще не хочу видеть html. IT>А придётся.
Думаешь он вечен как бэйсик?
IT>>>В первую очередь это DSL. В качестве примера возьмём Linq. GZ>>Пример интересный. Однако следует напомнить о сложности интеграции. Нужно быть мазохистом в самой извращенной форме, чтобы добровольно реализовывать визитеров.
IT>Ты о чём?
О провайдерах LINQ. Делать их сложно. Даже на немерле
IT>>>Вторым направлением является, конечно же, функциональное программирование. GZ>>Рок&ролл — мёртв. ФП — мёртв. Мы — зловещие мертвецы. 30 лет назад, это тоже было перспективным направлением. Если на основе различных ФП мозгляки придумывали различные непотребные вещи, которые потом ввели в мейнстрим, это не значит что сам ФП станет мейнстримом. Некоторые средства — да. Само ФП — нет. И это следует считать доказанным, опытным путем, фактом. IT>Можно подробнее про опыты?
В каком году появился лисп? Практически полностью фп оформилось в 70-ых.
IT>>>Третья вещь – это метапрограммирование. GZ>>Метапрограммирование вещь сама в себе. Метапрограммирование — может дать декларативность. Но в то же время, может и не дать. И тогда она чрезвычайно опасная штука, вводящая зависимости какие в ООП не снились, и сложность на уровне — перед тем как подойти к клавиатуре, давайте выучим Войну и Мир наизусть.
IT>Я выше приводил пример про баиндинг. Написать шаблон на T4, который решает проблемы, которые решают некоторые навороченные фреймворки, у меня заняло пол дня.
Т4 — система метапрограммирования? Ну можно и так сказать. С некоторым Ы. Только опять вопрос, сколько людей, хотя бы думают, что знают С#, а сколько Т4. Новым инструментом мы ввели излишнюю сложность. Но вопрос не об этом. Это низменное решение. Высокое решение состоит в том, чтобы человек ни разу не думал как у него проходит биндинг. Ему нужно знать что данные связаны по некоторым, управляемым законам, которые он может свободно менять. Желательно с рисованием, чтобы не сделать ошибку в тексте. И с проверкой семантики.
IT>Ну а хрен себе при желании отстрелить можно чем угодно. Не обязательно для этого использовать сложный, изощрённый механизм. Можно просто засунуть его в электрическую мясорубку. Нажимаем кнопку 'Вкл' до характерного звука 'счёлк' и вот тебе к столу фарш их хрена.
А вот в светлом будущем, все будут плеваться от нашей с тобой недоразвитости. Не нам одним плеваться на goto.
Здравствуйте, uncommon, Вы писали:
U>Не понял, при чем здесь сравнение Лиспа с машинными кодами. Лисп — язык высокого уровня, не уступающий по мощности, а в большинстве случаев превосходящий другие широко используемые языки программирования.
Может по мощности он и не уступает. Но вот по бесчеловечности точно не уступает.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, uncommon, Вы писали:
U>>Программа на лиспе при редактировании в emacs'е в любой момент представляет из себя некое законченное AST.
IT>Т.е. если из работающего кода я просто тупо удалю все открывающие скобки, то в этот момент оно будет представлять из себя некое законченное AST?
Удаление открывающей скобки удаляет и закрывающюю. Я же говорю, emacs редактирует код на лиспе таким образом, что все скобки всегда сбалансированны.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, uncommon, Вы писали:
U>>Не понял, при чем здесь сравнение Лиспа с машинными кодами. Лисп — язык высокого уровня, не уступающий по мощности, а в большинстве случаев превосходящий другие широко используемые языки программирования.
IT>Может по мощности он и не уступает. Но вот по бесчеловечности точно не уступает.
Почему? Я буквально полторы книги по лиспу прочитал и несколько программ написал. И в какой-то момент код на лиспе стал читаться и писаться без особых затруднений.
[...] Спасибо. У меня ещё пару мыслей по этой опере. Я затрону соседнюю тему рядом со всякими схемами — отчёты для печати. Я не в курсе о специфике вашего ВУЗа/кафедры и применима ли эта тема, но отчеты требуются во многих местах, и далеко за пределами коммерции. Так вот, я предлагаю глянуть на проектик "Script Reporter", архив можно взять здесь. С проектом возиться не нужно, достаточно глянуть хелп и примеры (там такого совсем чуть-чуть). Это старый проект 90-х годов для Delphi, уже умерший (но, имхо, только в интернете !). Представляет из себя простой скриптовый язык программирования для создания отчетов + небольшая инфрастуктура для него.
Поясню причины своей "приставалки".
Во-первых, это пример эффективного текстового представления, которого часто не хватает в реальной жизни простым смертным людям.
Например, отчёты часто вынужденны ваять поверх HTML-я, особенно в рамках веб-а/интранета, через всякие около-вебные фреймворки. Частенько вручную ваяют PDF. Но это всё — ещё та морока. Есть не мало готовых отчётных систем. MS Reporting Services, Crystal Reports, JasperReport и BIRT для джавы — это основной "ынтерпрайз". Плюс есть много чего для Delphi, Net-a, вот для джавы — совсем их мало, а также полно встроенных отчётов во всяких около-тыпрайзнутых системах. Часто они состоят из XML-программирования (то ещё удовольствие) + всякие дизайнеры и пр.
Часто визуальные хорошие системы очень нужны. Напр., до меня иногда доносятся стоны от тех людей, кто вынужден разрабатывать для всяких Акцапт, Ораклов, Sap R3 и т.п. (где стоимость систем с немалыми нулями), и они знают, как ваяются отчеты в 1С. Вот в 1С — удачная графическая система. 1С повлиял на популярный проект FastReport — отчёты для Delphi и Net-а — одна из лучших штучек в этой области (жаль, что нет для жабы и решений для серверов приложений, хотя что-то там сетевое есть). В своё время для дельфи был проектик PReport (уже давненько умер, но на просторах инета найти можно) — имхо, среди подобных систем в нём был самый гибкий алгоритм формирования отчётов, есть чему поучиться многим "ынтепрайзам".
Кстати, 1С, FastReport, PReport и указанный проект — наваяли их наши люди — нюх к практичности по сравнению с индусами имеется. Как минимум, наши люди не забывают о матричных принтерах и всяких печатных машинах — они ещё очень долго будут нужны, и ни чем их пока не заменят.
Но, выше приведенные системы не дают такого профита, как этот указанный древний проект. Именно подобные системы позволяют небольшой команде или одному человеку ваять сотни, если не тысячи, отчётов, которые постоянно нужно подгонять под новые требования. В проекте небольшой текстовый язык, чем-то напоминающий SQL и полу-паскаль, там нечего осваивать. Ключевой момент — простота (!), при этом эффективная.
У себя имеются разработки в таком стиле, так что, всё проверено на своей шкуре.
И это именно тот проект, который мне когда-то раскрыл глаза, как можно решать практично сложные проблемы (почему, собственно, я о нем и вспомнил).
Во-вторых. На проект полезно глянуть для разработки тех же дракон-схем и им подобным. Сам по себе DSL в этом проекте не пригоден "в лоб" для драконов. Здесь декларативное описание, а драконы требуют явного императивного указания алгоритма (это их цель). Но, если о драконах говорить далее, чем рисование на бумажках, то обычно эти схемы от фонаря не создают. Необходимо иметь те же декларативные элементы для задания предметной области, какие-то базовые функциональные вещи (те же встроенные функции, для которых дробить алгоритм в рамках схем не имеет смысла) и т.п. Затем в таком стиле можно что-то нафантазировать и для задания прямых алгоритмов-схем. Как-то так.
Ну и последнее. Сам по себе такой язык программирования для отчётов — это, имхо, вполне хорошая тема для какой-то научной/дипломной работы. И главное — это востребовано в реальной жизни. Лично я ничего подобного не видел ни для жабы, ни для net-а. Сомнительна массовая потребность таких вещей в рамках C++, напр., того же Qt, но уверен, что многим людям и здесь чего-то такого не хватает.
Имхо, можно копать в такую сторону:
— обосновать, зачем нужен ещё один язык, пусть даже только для отчётов. Здесь можно напридумывать немало научных слов, но это не моя стихия. Я скажу прямо: в современном мэнстриме — C++, Java, C#, даже питон с руби и т.д. — не очень удобно ваять прикладную логику, если не сказать более "теплых" слов. Кстати, здесь
у меня недавно вырвался плевок в сторону ООП, там вроде и тема была несерьезная, но почему-то "зацепила".
И ещё, к слову. Имхо, уже упомянутый здесь Go — вполне хороший пример, где можно понять, как решаются те же проблемы, но без классовой иерархии, каких-то глобальных зависимостей. К тому же, имхо, Go — хорошая стартовая точка для освоения функциональных языков, при этом он проще, чем тоже около-системный D, или Rust, который сейчас мазиловцы ваяют. В Go сейчас не хватает пары вещей, напр., дженериков, не всё гладко с платформой. Может есть смысл для пилотного учебного комплекса "C#- Qt-BlackBox" попробывать и Go, даже вместо BlackBox — пользы будет больше. Правда могут быть проблемы, как минимум с GUI, но может быть это как раз повод сделать web-версию
— далее, набросать сам язык, плюс небольшая инфраструктура, хотя бы раскраска синтаксиса;
— нужен базовый движок для генерации отчётов. Лучше сначала ориентироваться на ынтерпрайз. Реализовать ядро на джаве, которое будет генерировать HTML по вкусу (с рядом ограничений, сам этот html — штука не фонтан для отчётов). Адаптировать ядро под возможность работы с серверами приложений. Если есть потребность интеграции в учебный комплекс — через HTML будет вполне добротно, и не чего страшного, если где-то рядом нужно будет жабку запустить, ее даже встроенной можно сделать.
Как-то так. Если тема будет "прокачена" — это не вылетит в трубу, а отличный задел на будущее: расширение форматов (PDF, свои бинарники, plain-text и т.д), какие-то JS-либы для расширенной работы в броузере, интеграция для десктопа (Swing, JavaFX, SWT), портирование на Net и конца этому не будет, если коммерчески себя оправдает
P.S. Пару слов в оправдание моего тутошнего офтопа. Я после студенчества быстро осознал, какой фигней приходилось заниматься в ВУЗ-е, и сколько времени было потрачено неэффективно. Тут так сложилась тема на форуме, что "задела былые раны".
Буду рад, если удалось выложить реально полезную инфу.
Здравствуйте, minorlogic, Вы писали:
M>Не понимаю. Приведенный тут как пример , ДРАКОН как справляется с задачей декомпозиции ?
Сорри, но я, например, тоже не понимаю, о каком отсутствии декомпозиции в драконе идёт речь ?
Я давно смотрел на "стандарт" дракона (да собственно, от дракона, кроме как идеи направленного графа — больше ничего ненужно, это и весь "стандарт"), я не помню, чтобы он запрещал в блоках (каких-то прямоугольниках) указывать какие-то свои команды перехода на другие схемы, т.е. можно указать какой-то процесс, а "раскрыть" его — отдельной схемой (что и делалось на практике — вполне себе какая-то декомпозиция).
Возможно и огромные схемы, с большим количеством всяких сущностей, весьма востребованы. Какому-то инженеру, м.б., удобно разбирать схему на A1, где всё сразу перед глазами, он к этому привык.
Здравствуйте, PSV100, Вы писали:
PSV>т.е. можно указать какой-то процесс, а "раскрыть" его — отдельной схемой (что и делалось на практике — вполне себе какая-то декомпозиция).
Это и есть один из механизмов поддержки иерархической декомпозиции.
Здравствуйте, uncommon, Вы писали:
IT>>Может по мощности он и не уступает. Но вот по бесчеловечности точно не уступает. U>Почему? Я буквально полторы книги по лиспу прочитал и несколько программ написал. И в какой-то момент код на лиспе стал читаться и писаться без особых затруднений.
Бывает. Я не отрицаю мазохизм как явление.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, uncommon, Вы писали:
U>Удаление открывающей скобки удаляет и закрывающюю. Я же говорю, emacs редактирует код на лиспе таким образом, что все скобки всегда сбалансированны.
При чём тут emacs? Мы разве его обсуждаем?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, PSV100, Вы писали:
PSV>>т.е. можно указать какой-то процесс, а "раскрыть" его — отдельной схемой (что и делалось на практике — вполне себе какая-то декомпозиция).
M>Это и есть один из механизмов поддержки иерархической декомпозиции.
Понятно, я так и думал. Скорее всего, Вы смотрели или только примеры, или плюс какие-то визуальные среды для этих драконов, где на глаза попалось то, что во всяких прямоугольниках обычно внедряются какие-то конечные действия. Так, кстати, и делают ряд редакторов, которыми я когда-то баловался. Какая есть система в тех местах, где этот дракон родили — сие есть "тайна", но где-то какая-то инфа проскакивала, и вроде там что-то стоящее. А так, если нужны схемки — бумага, карандаш, линейка и "рефакторинг"-резинка — это лучшее, что пока есть.
Моя основная мысль , что для конкуренции с текстовыми языками, визуальные должны предоставлять средства декомпозиции не хуже а лучше существующих. Пока с этим очень большое отставание.
В тесте исторически используются много гетерегонных средств , начиная от разбивки по файлам и сборкам заканчивая пустой строкой для групировки выражений по смыслу.
PSV>По сему, лучше смотреть на вим/эмакс при изучении какого нибудь питона/руби. Здесь и монстры-иде не сильны в плане развитого автокомплита, код-броузера, рефакторинга и т.д. в силу динамичной природы таких языков.
1. в виме есть автокомплит и прочее (хотя никогда не пользовался)
2. kdevelop позволяет в качестве компонента-редактора использовать вим, не теряя автокомплита и прочего (опять сам никогда не пользовался)
я что-то не понял -- в blackbox реализовано что-то типа структурного редактора? ссылка на этот редактор есть? (а лучше на описание его предполагаемых киллер-фич)
Здравствуйте, m e, Вы писали:
PSV>>По сему, лучше смотреть на вим/эмакс при изучении какого нибудь питона/руби. Здесь и монстры-иде не сильны в плане развитого автокомплита, код-броузера, рефакторинга и т.д. в силу динамичной природы таких языков.
ME>1. в виме есть автокомплит и прочее (хотя никогда не пользовался)
ME>2. kdevelop позволяет в качестве компонента-редактора использовать вим, не теряя автокомплита и прочего (опять сам никогда не пользовался)
Здесь можно ещё добавить и Eclim для эклипса, но я им не пользовался. Я лишь хотел сказать о том, что пробовать освоить С/С++ и одновременно вим/эмакс — сугубо моё личное имхо, будет как-то тяжеловато. С тем же комплитом и пр. хорошие IDE справляются по-приятнее, чем какой-нибудь ctags или cscope и им подобные, да и перезапускать всякий ctags на каждый чих — тоже не фонтан. Для тех, кого устраивает ctags, он не такой уж и частый помощник. В виме/эмаксе есть тоже отличные "иде", например, не мало лисперов свой SLIME ни на что не променяют. Да и к тому же, как минимум клавиатурное управление в этих редакторах быстро с наскока не возьмёшь, особенно, если вим/эмакс — не основная сфера деятельности (теоретически есть возможность раскладки попеределовать по-своему, но, к примеру, тогда это уже будет не совсем вим).
Здравствуйте, m e, Вы писали:
ME>я что-то не понял -- в blackbox реализовано что-то типа структурного редактора? ссылка на этот редактор есть? (а лучше на описание его предполагаемых киллер-фич)
Нет, не структурный.
Фишка ББ в том, что любой модуль, написанный на компонентном паскале становится частью среды.
И его можно запускать и использовать совершенно так же, как и любой стандартный.
То есть компонентный паскаль — это не только язык программирования, но и внутренний язык развития системы.
Микрософт подобную штуку сделала только 10-й студии, когда на Додиезе стало возможно саму среду.
До того в среде был механизм макросов, реализованный на VB.
Окно редактора ББ представляет собой документ, в котором можно писать как в ворде.
Причем можно смешивать обычный текст и программу.
Более того, тут же в документа можно написать и входные данные (если их немного).
И тут же из окна запустить программу.
Меню бб — это такой же документ, который можно редактировать в том же редакторе. Поэтому из ББ можно сделать такую систему, которая требуется.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
ME>>я что-то не понял -- в blackbox реализовано что-то типа структурного редактора? ссылка на этот редактор есть? (а лучше на описание его предполагаемых киллер-фич) LVV>Нет, не структурный. LVV>Фишка ББ в том, что любой модуль, написанный на компонентном паскале становится частью среды.
Это не фишка.
Это идеологическая бага.
Причем она делает компонентный паскаль просто неработоспособным в реальном мире.
Ибо один злобный или глючный модуль, который начнет создавать объекты из других модулей и складировать их у себя съест всю память.
И его даже срубить нельзя будет. Ибо в этом случае будет нарушена целостность графа объектов.
Я уже не говорю о том, что переменная модуля это фактически глобальная переменная. То, что она скрыта за интерфейсом модуля, ничего не меняет. Все основные проблемы глобальных переменных остаются.
Что делать если нужно запустить несколько копий модуля?
А если разным модулям нужны разные версии модуля одного?
Это же dllhell на стеройдах.
И об этом уже не раз сказано. Но каждый раз игнорируется.
И через некоторое время опять начинается песнь про то что это мегафича.
LVV>Микрософт подобную штуку сделала только 10-й студии, когда на Додиезе стало возможно саму среду.
Это лож. Если мне не изменяет склероз то для студии с самого начала можно расширения на .НЕТ писать. Для 2008 точно можно.
LVV>Окно редактора ББ представляет собой документ, в котором можно писать как в ворде.
Только так и не ясно нахрена оно нужно.
Вот подсветка синтаксиса, подсветка ошибок, автокомплит, навигация, рефакторинг,... нужны.
Помнишь голосование: http://www.rsdn.ru/poll/3001.aspx
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, LaptevVV, Вы писали:
ME>>>я что-то не понял -- в blackbox реализовано что-то типа структурного редактора? ссылка на этот редактор есть? (а лучше на описание его предполагаемых киллер-фич) LVV>>Нет, не структурный. LVV>>Фишка ББ в том, что любой модуль, написанный на компонентном паскале становится частью среды. LVV>>Микрософт подобную штуку сделала только 10-й студии, когда на Додиезе стало возможно саму среду. WH>Это ложь. Если мне не изменяет склероз то для студии с самого начала можно расширения на .НЕТ писать. Для 2008 точно можно.
Фигню глаголешь, отрок! Вот передо мной книжка по среде Visual Studio 2008. Авторы Ларс Пауэрс, Майкл Снелл.
Глава 12. Пишем макросы. Страница 418.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
WH>>Это ложь. Если мне не изменяет склероз то для студии с самого начала можно расширения на .НЕТ писать. Для 2008 точно можно.
LVV>Фигню глаголешь, отрок! Вот передо мной книжка по среде Visual Studio 2008. Авторы Ларс Пауэрс, Майкл Снелл. LVV>Глава 12. Пишем макросы. Страница 418.
Если мне не изменяет память, там можно было писать макросы на VB и extensions на .net
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!
Здравствуйте, LaptevVV, Вы писали:
WH>>Это ложь. Если мне не изменяет склероз то для студии с самого начала можно расширения на .НЕТ писать. Для 2008 точно можно. LVV>Фигню глаголешь, отрок! Вот передо мной книжка по среде Visual Studio 2008. Авторы Ларс Пауэрс, Майкл Снелл. LVV>Глава 12. Пишем макросы. Страница 418.
Это макросы внутри самой среды. API студии всегда доступен был через COM/.NET, так что расширения можно было хоть на ActivePerl писать (у меня парочка таких была).
Здравствуйте, Hobot Bobot, Вы писали:
HB>Здравствуйте, LaptevVV, Вы писали:
WH>>>Это ложь. Если мне не изменяет склероз то для студии с самого начала можно расширения на .НЕТ писать. Для 2008 точно можно.
LVV>>Фигню глаголешь, отрок! Вот передо мной книжка по среде Visual Studio 2008. Авторы Ларс Пауэрс, Майкл Снелл. LVV>>Глава 12. Пишем макросы. Страница 418.
HB>Если мне не изменяет память, там можно было писать макросы на VB и extensions на .net
Да, вы правы. Макросы и надстройки различаются. У них два разных механизма и два разных языка.
И вот что интересно: с механизмом расширения разбирается практически сразу любой. Ибо — ПРОСТО. И единообразно.
А с механизмами расширения Студии — без специального изучения не обойтись.
Например, надо знать структуру надстройки...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Фигню глаголешь, отрок! Вот передо мной книжка по среде Visual Studio 2008. Авторы Ларс Пауэрс, Майкл Снелл. LVV>Глава 12. Пишем макросы. Страница 418.
А интеграция немерла написанная на немерле мне приснилась. https://github.com/rsdn/nemerle/downloads
Я тебя правильно понял?
Плюс если мне не изменяет склероз я когда в Парусе работал под 2003 расширения на .НЕТ писал. Под 2005 точно писал.
К остальному как я понимаю вопросов нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
LVV>>Фигню глаголешь, отрок! Вот передо мной книжка по среде Visual Studio 2008. Авторы Ларс Пауэрс, Майкл Снелл. LVV>>Глава 12. Пишем макросы. Страница 418. WH>А интеграция немерла написанная на немерле мне приснилась. WH>https://github.com/rsdn/nemerle/downloads WH>Я тебя правильно понял? WH>Плюс если мне не изменяет склероз я когда в Парусе работал под 2003 расширения на .НЕТ писал. Под 2005 точно писал.
Я в соседнем ответе написал уже, что два механизма. WH>К остальному как я понимаю вопросов нет.
Вопросов нет, ибо Блэкбоксовики перечисленных тобой траблов — НЕ ИМЕЮТ.
Не веришь — сходи на оберонский форум и поинтересуйся, как это они без всех тобой перечисленных проблем обходятся?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
WH>>К остальному как я понимаю вопросов нет. LVV>Вопросов нет, ибо Блэкбоксовики перечисленных тобой траблов — НЕ ИМЕЮТ.
Имеют.
LVV>Не веришь — сходи на оберонский форум и поинтересуйся, как это они без всех тобой перечисленных проблем обходятся? \
Да очень просто — не пишут чего-либо серьёзного.
Здравствуйте, LaptevVV, Вы писали:
LVV>Вопросов нет, ибо Блэкбоксовики перечисленных тобой траблов — НЕ ИМЕЮТ. LVV>Не веришь — сходи на оберонский форум и поинтересуйся, как это они без всех тобой перечисленных проблем обходятся?
Это по тому, что в их блекбоксах крутятся только стандартные и их модули.
А если блекбокс довести до полноценной ОС и загрузить туда десятки программ от разных производителей начнется, то, что я написал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, uncommon, Вы писали:
U>Удаление открывающей скобки удаляет и закрывающюю. Я же говорю, emacs редактирует код на лиспе таким образом, что все скобки всегда сбалансированны.
Задам глупый вопрос. Как там выглядит перенос скобки с места на место?
(1 2 3 (4 5))
хочется превратить в
(1 2 (3 4 5))
оставляя скобки всегда сбалансированными. Перенос тройки не предлагать.
Здравствуйте, LaptevVV, Вы писали:
LVV>Фишка ББ в том, что любой модуль, написанный на компонентном паскале становится частью среды. LVV>И его можно запускать и использовать совершенно так же, как и любой стандартный. LVV>То есть компонентный паскаль — это не только язык программирования, но и внутренний язык развития системы.
Для построения динамической системы используется язык с полным отсутствием динамических возможностей. (Component Pascal, грубо говоря, по возможностям мало чем отличается от C.) Результат, как не трудно догадаться, получился плачевный. Мало того, что этот блэкбокс очень неудобно использовать как таковой, его возможности расширения не позволяют ему сделать тривиальных вещей, как например, автоматическая подсветка кода (epic fail оберонщиков, которые смогли написать для блэкбокса только полу-автоматическую подсветку, т.е. написал код, нажал на hotkey, код подсветился). Об более серьезных расширениях речи вообще идти не может.
Для сравнения, Emacs: написан по большой части на лиспе (elisp), расширяется через тот же лисп. Динамический язык и более грамотная архитектура emacs-а позволяет легко изменять любую часть этого редактора. Количество всяких расширений написанных для emacs-а поражает воображение. От простейших, до таких монстров, как cedet. ББ здесь и рядом не стоял. Более того в ББ нет ничего нового, что уже не было в emacs-е десятилетия назад.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, uncommon, Вы писали:
U>>Удаление открывающей скобки удаляет и закрывающюю. Я же говорю, emacs редактирует код на лиспе таким образом, что все скобки всегда сбалансированны.
Z>Задам глупый вопрос. Как там выглядит перенос скобки с места на место?
Z>
Z>(1 2 3 (4 5))
Z>
Z>хочется превратить в Z>
Z>(1 2 (3 4 5))
Z>
Z>оставляя скобки всегда сбалансированными. Перенос тройки не предлагать.
Ну то, что программа — это многомерная штука, и программируя в текстовых файлах, мы работаем с проекциями этой многомерной структуры на текст — это очевидно. Всякое АОП это как раз добавление размерностей к программному коду. Очевидно и то, что в будущем появятся более удобные способы манипулирования кодом. Но насчет языков вообще сложно что-то прогнозировать. Может взлететь какая-то совершенно темная лошадка, если её использование будет сильно удешевлять разработку. А может и сишарп еще 40 лет будем использовать как одно из самых выразительных средств (при условии что Хейлсберг продолжит его развивать, а майкрософт выложат в открытый доступ).
Имхо появится несколько программерских топовых инструментов, каждый из которых будет наиболее удобен для своей области применения (что-то для многопоточной обработки данных, что-то для client-side, что-то для алгоритмизации, что-то для метапрограммирования), которые будут между собой легко соединяться и без проблем взаимодействовать. А программистам останется лишь придумать архитектуру и на каждом уровне применить то, что больше подходит. Сейчас мы этот процесс уже наблюдаем, но в топы инструменты еще не вышли, и из-за этого взаимодействовать между собой не так просто. Когда останутся буквально 10-20 общепризнанных лучших инструментов, тогда и будет счастье: то, как спроектировать "несложную" систему типа ютьюба,- будут проходить на 2 курсе университета.
Ну а потом человечество упрется рогом в ограниченные возможности интеллекта. Жонглировать абстракциями станет слишком сложно для человеческого мозга. Сначала мы попробуем генетические импрувменты, потом рано или поздно сделаем искуственный интеллект, который и будет двигать прогресс дальше.
Здравствуйте, LaptevVV, Вы писали:
LVV>Я в соседнем ответе написал уже, что два механизма.
Механизм один, просто способы регистрации и стартапа разные. Причем не 2, а 3 — макросы, расширения и пакеты (и еще MEF-расширения в 2010). Но API самой студии там единое.
... << RSDN@Home 1.2.0 alpha 5 rev. 21 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, LaptevVV, Вы писали:
LVV>>Я в соседнем ответе написал уже, что два механизма.
AVK>Механизм один, просто способы регистрации и стартапа разные. Причем не 2, а 3 — макросы, расширения и пакеты (и еще MEF-расширения в 2010). Но API самой студии там единое.
Вот и я о том же...
Один простой-простой и ВСЕМИ понятый механизм или три, из которых как минимум два — не очень простых.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Если нам не помогут, то мы тоже никого не пощадим.
Автор(ы): К. Чарнецки, У. Айзенекер
