Re[2]: Будущее программирования - обсудим?
От: Hobot Bobot США  
Дата: 10.02.12 17:05
Оценка:
Здравствуйте, 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!
Re[2]: Будущее программирования - обсудим?
От: LaptevVV Россия  
Дата: 10.02.12 17:32
Оценка:
Здравствуйте, PSV100, Вы писали:

PSV>Сорри, что я с небольшим офтопом тут. У меня вопросик к ТС. Из этой темы форума я косвенно узрел, что Вы работаете (или студенты под вашем началом как научного руководителя) над проектом, связанным с каким-то семантическим редактором. Судя по характеру приведенной статьи, Вас интересует эта проблематика. В свое время мне на глаза попадались некие подобные системы, и я не понял, какие практичные задачи они решают. Я могу для себя выделить академический интерес (исследования в IT — вещь необходимая), также могут понять и некоторое коммерческое продвижение подобных проектов вплоть до откатов в госструктурах. Но чем они реально могут эффективно помочь в жизни — не понимаю. Попробую обосновать свою "приставалку".


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


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

1. В первую очередь меня интересует проблема обучения программированию.
Что есть обучение профи? Это не только сумма знаний и умений, но и навык автоматического применения правильных вещей на всех уровнях.
Тут я полностью согласен с Федором Ткачевым, что технику программирования нужно ставить, как голос ставят певцу, или удар ставят боксеру.
К сожалению, при групповом обучении "поставить удар" большинству группы — проблематично. Никакие слова не помогают — только жесткое требование переписать РАБОТАЮЩУЮ программу в соответствии с требованиями задания. Хорошо, если студень молча перепишет. Но частенько находятся субъекты, которые начинают спорить и доказывать, что все работает, а остальное — пофигу. От этого со временем СИЛЬНО устаешь.
2. Кроме того, не все преподы знают, как правильно. Сейчас такое время, что квалифицированных преподов — мало. Вот и у нас с кафедры свалили наши выпускники — деньги зарабатывать. Поэтому речь идет о том, чтобы даже в условиях дефицита квалифицированных кадров все же давать качественное обучение программированию. Это можно сделать только автоматизацией.
Система просто не должна позволять новичкам писать неправильно! В ней естественно заложить паттерны правильного написания, которые будут у студня перед глазами все время обучения.
Даже разработчик семантического редактора, пописАв в семантическом редакторе, заметил, что приобрел достаточно устойчивую привычку писать структурно.
И это 4 курс, когда все плохие привычки уже сформировались! А если так делать с самого начала?
3. Семантический редактор — это только часть большой системы. Основная идея — автоматизировать оценивание работы студента. Тут большой простор для исследований. И оценивание с точки зрения качества работы, и оценивание с точки зрения наличия "плохих" кодов, и оценивание с точки зрения последующих рекомендаций по рефакторингу ... И т.п. Большое поле для исследований.
Мы уже пытались к студии прикрутить оценивание сделанной работы для программ на Додиезе — это получился целый диплом. Основное время у пацана заняло разобраться в структуре сборки и вытащить необходимую для оценивания информацию. И не не всегда этой информации хватало.
Или писать свой парсер для языка — не менее рутинная и не очень интересная работа.
ИМХО проще реализовать свою систему, в которой вся информация сохраняется. Но сделать ее совместимой в некотором смысле с существующими языками.
Таким образом, получаем систему ОДИНАКОВО оценивающую работу студентов.
Независимо от настроения и квалификации преподов, от вчерашнего праздника или критических дней...
4. И одновременно это система для препода — в ней он и задания положит, и примеры напишет. Среда должна обладать свойством генерации заданий на основе некоторого вида шаблонов. Тогда каждому студенту будет выдаваться индивидуальный вариант, равноценный с другими по данной теме. Ведь подобрать много равноценных вариантов — это проблема для препода. И в этом направлении работа тоже ведется. Образец есть — школьная сборка Ткачева. ИМХО — отличная работа!
Кроме того, в среде реализуем два режима: обучающий и контрольный. В обучающем режиме — подсказки, помощь и все такое. Вплоть до выполнения очередного шага сценария вместо студента.
А в контрольном — оценивание умений и навыков.

Если работа покажет себя на практике (первую версию вместо Кумира собираемся внедрить уже в сентябре), то будем развивать и в среду для программирования, а не для обучения.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Будущее программирования - обсудим?
От: PSV100  
Дата: 10.02.12 17:56
Оценка:
Здравствуйте, Hobot Bobot, Вы писали:

HB>

HB>гибридный язык Дракон-Ада


HB>Хороший каламбур.


Ага, есть ещё Язык РАЯ — Русский алгоритмический язык. Не удивляюсь, что после этого появляются ПохмельФС — POHMELFS
Re[3]: Будущее программирования - обсудим?
От: PSV100  
Дата: 10.02.12 18:52
Оценка:
Здравствуйте, 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 (здесь — опыт на питоне). В этом случае можно убить двух зайцев — и обществу будет реальная польза (а также и некое признание с его стороны — какой-то плюс для портфолио будущего специалиста, и часто более важный, чем "раскрытая тема в дипломе"), и студент получит реальный опыт, если нюхнёт реальной жизни. Но здесь возня будет не малая, есть нюанс: для курсовой может быть излишне, для диплома — вроде не солидно. Так что, здесь — больше "интузазизма".

В общем, как-то так. Спасибо.
Re[4]: Будущее программирования - обсудим?
От: LaptevVV Россия  
Дата: 10.02.12 19:23
Оценка:
Здравствуйте, PSV100, Вы писали:

PSV>Спасибо за оказанное внимание. Мои подозрения подтвердились, к сожалению, обучение — это не моя сфера, что-то конкретно дать полезного от себя не могу. Искренне лишь желаю удачи, ибо задумка ой как не легка.


PSV>Возможно, смогу дать пару намёков. Я заметил в этой теме форума, что у Вас не было тесных контактов с MPS от jetbrains. Также рекомендую глянуть, на всякий случай, если Вы не в курсе, на проект Xtext от eclipse. Обе системы направлены на создание своего DSL. Рациональные зёрна в них есть. Я их давненько смотрел, мне они показались, прежде всего, неудобными, опять же из-за проблем с GUI — непрактично это. На основе Xtext вроде сварганили какой-то xtend — язычок для жабы. Возможно, что-то полезное всплывёт из них.

Спасибо. На MPS мне уже указали — я уже студентам сообщил.
Про Eclips мы знаем — программисты нашей команды тренировались в ней. Спасибо за дополнительную инфу.
PSV>Ещё одна мысль, так, к слову... Раз тут затронуты эти драконы, и вроде студенты у Вас ваяют свои редакторы под него, то попробую дать практичный совет. Не нужно повторять те попытки, которые встречаются в интернете — графические редакторы для лепки этих схем. Кроме какого-то обучения они больше ни для чего не пригодны. Может есть смысл попробывать сделать какой-нибудь mode для эмакса, по подобию org-mode. Эмакс с вимом, конечно, штуки не простые. Как альтернатива, можно глянуть в сторону JEdit (здесь будет практика на джаве), или на Sublime Text 2 (здесь — опыт на питоне). В этом случае можно убить двух зайцев — и обществу будет реальная польза (а также и некое признание с его стороны — какой-то плюс для портфолио будущего специалиста, и часто более важный, чем "раскрытая тема в дипломе"), и студент получит реальный опыт, если нюхнёт реальной жизни. Но здесь возня будет не малая, есть нюанс: для курсовой может быть излишне, для диплома — вроде не солидно. Так что, здесь — больше "интузазизма".
Спасибо за наводку — можно доприлепить к студии соответствующий движок. Студия 10 это сейчас позволяет.
И это на диплом вполне потянет, если делать всерьез, а не просто для отмазки.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[5]: Будущее программирования - обсудим?
От: PSV100  
Дата: 10.02.12 23:17
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Спасибо за наводку — можно доприлепить к студии соответствующий движок. Студия 10 это сейчас позволяет.

LVV>И это на диплом вполне потянет, если делать всерьез, а не просто для отмазки.

Приятно, что "драконья" тема не оставлена в стороне. Позволю себе ещё ремарку по этому поводу, ибо задето "за живое" — у меня у самого когда-то чесались руки что-то сбацать эдакое, но работа как всегда заваливает тебя по самые помидоры, а самим схемам далее, чем рисование на бумаге, и то редко, применение не нашлось.

Прежде всего, хотелось бы отметить о правильном их применении. Преобразования вида Дракон -> C -- не более, чем начальная обучалка в стиле "так вот ты какой северный олень". Какой-нибудь функциональный язык дает на выхлопе код С — это реальная практичная задача, и подобных проектов не мало. Изначально, где дракона родили, в этих схемах манипулировали реальными аппаратными командами, и транслировали данные как бы всё в оригинале — это природное практичное использование.
Иными словами, форсировать тему Дракон -> унив. язык общего применения — не стоит. Имхо, уверен, что у Вас такое же осознание реальности.

Интересен и неоднозначен способ как схемы создавать. Ковыряние мышкой — это для какого-нибудь Visio, а не для программистов. Нужен удобный текстовый синтаксис, причём увлекаться псевдографикой, т.е. полноценными прямоугольниками и т.п., не стоит. Лучше вложиться в рамки символов "| — + -> * #" и пр. Затем, уже когда нужно, рисовать полные весёлые картинки, на экране, печать, экспорт и т.д. К сожалению, сейчас в голову ничего конкретного не лезет, чётко сказать не могу.

Сомнительна польза от наличия таких схем в монстрах-IDE в виде Vis. studio. Понимаете, большая часть народа (но не все), кто работает в студии, эклипсе и пр., вынуждены будут рисовать какой-нибудь UML или какие-то диаграммы в той же Visio. А вот те, кто не чурается (часто совместно с монстрами) работать в эмакс/вим/сублиме/jedit и им подобным — очень запросто могут подраконить. К тому же, у меня в голове была косвенная мысль, что не плохо было бы, если студентов пораньше познакомить с программисткими редакторами, и чем раньше у них придёт понимание того, зачем они нужны — им легче будет жить (естественно, кто сам себе с детства всё выхватывает и "в теме" — того и учить не надо, не мне Вам рассказывать).

Скорее всего, весь ваш комплекс ваяется на студии, и очень вероятен, что C#. В этом случае, если подойти к этому по-серьёзнее, лучше реализовать эти схемы обособлено от общего проекта. Возможно, это как-то не вписывается в какие-то сложившиеся рамки, но лучше подойти к этому дело по-человечнее. Поясню.

В идеале необходимо реализовать ядро на С++, желательно сразу кроссплатформенное, не зависимое ни от какой студии. Затем уже к ней прикрутить. А дальше уже есть потенциал прикручивания к чему угодно, и отдельное приложение — само собой. Более того, если получится родить удачный движок, вполне возможно расширить применение, и подключить другие схемы. Например, такие диаграммы последовательностей как здесь, иногда приходится что-то такое колхозить на бумажках. Или для Mind map так и нет толкового инструментария. В общем, полёт фантазий не ограничен.
Взяться за такое смогут реально толковые пацаны (но и девчонки ). Кроме опыта, они особо не потеряют время зря: у них появится задел на будущее, вплоть до создания Donate-софта или шаровары, а то и для Visio конкуренцию составят

Как-то так видится эта проблема. Спасибо.
Re[9]: Будущее программирования - обсудим?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.02.12 01:12
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Мы с Вольфхаундом уже пообщались. Поизучаем, посторонние решения посмотреть всегда полезно.


Более точно было бы сказать "по игнорировали".

А эта ваша блэкбоксовщена — это полное мракобесие. Никакими учебными интересами ее не оправдать. Учите людей позавчерашнему дню.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Будущее программирования - обсудим?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.02.12 01:41
Оценка:
Здравствуйте, Don Reba, Вы писали:

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


Значит я новичек-непрограммист, так как мне порой рефакторинга выноса кода в локальную функцию или метода, очень не хватает в Nemerle.
Комплит и навигация тоже делает мою работу существенно быстрее.

Так что каждому свое. Есть аскеты, но большинству людей подавай удобство.

Проблема только в том, что Лаптев говоря о визуальном программировании на самом деле имеет ввиду ровно обратное. Его любимый Блэкбокс только файлы пишет бинарные. А в удобстве редактирования кода он не уступает разве что нотпэду.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Будущее программирования - обсудим?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.02.12 01:47
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Кроме того, выделили процедурное ядро Додиеза и Оберона — оно одинаковое с семантической точки зрения.

LVV>Взяли грамматики этих языков и сравнили.
LVV>И теперь у нас одной кнопочкой на экране хочешь — Додиез, а хочешь — Оберон. В процедурной части, естественно.

А что вы понимаете под процедурной частью?

И как насчет таких вещей как: разрешение перегрузок, неявное приведение типов, лифтинг операторов в Nulable?

LVV>Тут еще работать и работать. Но к сентябрю хотим первую версию запустить. Прямо в классах.


Версию чего? Если вы решили сделать поддержку C# 4 по спецификации, и вас двое человек, то первого сентября у вас может что-то и заработает, но только не в этом году, а годка эдак через 2 (а то и через 5).
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Будущее программирования - обсудим?
От: uncommon СССР  
Дата: 11.02.12 02:43
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Проблема только в том, что Лаптев говоря о визуальном программировании на самом деле имеет ввиду ровно обратное. Его любимый Блэкбокс только файлы пишет бинарные. А в удобстве редактирования кода он не уступает разве что нотпэду.


А как же ручная раскраска программы в разные цвета? В ноутпаде такого нееету!
Re[5]: Будущее программирования - обсудим?
От: uncommon СССР  
Дата: 11.02.12 03:10
Оценка:
Здравствуйте, LaptevVV, Вы писали:

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


ПТУ?
Re[4]: Будущее программирования - обсудим?
От: uncommon СССР  
Дата: 11.02.12 03:49
Оценка:
Здравствуйте, IT, Вы писали:

IT>Где-то в середине 90-х был подобный редактор для модулы, если не ошибаюсь. Всё проверял, всё контролировал, не давал делать ошибок и везде старался как мог. Смотрелось очень круто. Выкинули его через неделю и не потому что он плохо делал свою работу, а как раз наоборот слишком хорошо. Смотреть на него, конечно, было прикольно, но работать в нём было невозможно по одной простой причине. Некомпилируемый, разваленный и разрезанный на куски код — это перманентное состояние программы над которой в данный момент трудится программис. И каким образом он перейдёт из одного рабочего состояния программы в другое известно только ему одному.


Программа на лиспе при редактировании в emacs'е в любой момент представляет из себя некое законченное AST. Она может не компилироваться, но там все будет разбито на атомы и s-выражения.
Re[3]: Будущее программирования - обсудим?
От: Michael7 Россия  
Дата: 11.02.12 04:11
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>2. Отец БлэкБокса Клеменс Шиперски работает в Microsoft Research: http://research.microsoft.com/en-us/um/people/cszypers/

LVV>А представление модулей в БлэкБоксе — не текстовое. Это было еще в 95-м году.
LVV>3. Программа — это мультиграф, вершинами которого являются модули.
LVV>В системе этот мультиграф может хранится в каком угодно виде.
LVV>И только для человека его нужно представить в текстовом виде. Но это не значит, что в текстовом же виде программу надо и обрабатывать.
LVV>И даже вводить можно не в текстовом виде.

Это все жутко интересно, пока речь идет об относительно небольших программах.
Но проект эквивалентный хотя бы паре сотен тысяч строк в мультиграфе и не в текстовом виде — это не для людей точно
Re[5]: Будущее программирования - обсудим?
От: IT Россия linq2db.com
Дата: 11.02.12 05:56
Оценка:
Здравствуйте, uncommon, Вы писали:

U>Программа на лиспе при редактировании в emacs'е в любой момент представляет из себя некое законченное AST. Она может не компилироваться, но там все будет разбито на атомы и s-выражения.


Лисп не то. Там AST пишется прямо в текстовом виде. Там и нет ничего кроме AST. Лучше может быть только написание программы прямо в машинных кодах. Наши древние предки так умели. Выщёлкивали команды процессора тумблерами на коммандном пункте уплавления ЭВМ
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Будущее программирования - обсудим?
От: uncommon СССР  
Дата: 11.02.12 06:25
Оценка:
Здравствуйте, IT, Вы писали:

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


U>>Программа на лиспе при редактировании в emacs'е в любой момент представляет из себя некое законченное AST. Она может не компилироваться, но там все будет разбито на атомы и s-выражения.


IT>Лисп не то. Там AST пишется прямо в текстовом виде. Там и нет ничего кроме AST. Лучше может быть только написание программы прямо в машинных кодах. Наши древние предки так умели. Выщёлкивали команды процессора тумблерами на коммандном пункте уплавления ЭВМ


Не понял, при чем здесь сравнение Лиспа с машинными кодами. Лисп — язык высокого уровня, не уступающий по мощности, а в большинстве случаев превосходящий другие широко используемые языки программирования.
Re[6]: Будущее программирования - обсудим?
От: LaptevVV Россия  
Дата: 11.02.12 06:27
Оценка:
Здравствуйте, 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
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[10]: Будущее программирования - обсудим?
От: LaptevVV Россия  
Дата: 11.02.12 06:29
Оценка: -1 :)
Здравствуйте, VladD2, Вы писали:

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


LVV>>Мы с Вольфхаундом уже пообщались. Поизучаем, посторонние решения посмотреть всегда полезно.


VD>Более точно было бы сказать "по игнорировали".


VD>А эта ваша блэкбоксовщена — это полное мракобесие. Никакими учебными интересами ее не оправдать. Учите людей позавчерашнему дню.

Влад, ты не прав!
Мы учим программированию, а не технологиям. Для современных технологий у них дофига отдельных курсов.
А программмеру — полезно с разными подходами знакомиться.
Тем более, что БлэкБокс обладает некоторыми чертами, которые даже профи оценить не способны...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[6]: Будущее программирования - обсудим?
От: LaptevVV Россия  
Дата: 11.02.12 06:33
Оценка:
Здравствуйте, VladD2, Вы писали:

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


LVV>>Кроме того, выделили процедурное ядро Додиеза и Оберона — оно одинаковое с семантической точки зрения.

LVV>>Взяли грамматики этих языков и сравнили.
LVV>>И теперь у нас одной кнопочкой на экране хочешь — Додиез, а хочешь — Оберон. В процедурной части, естественно.

VD>А что вы понимаете под процедурной частью?

Нет наследования. Остальное — все есть.
VD>И как насчет таких вещей как: разрешение перегрузок, неявное приведение типов, лифтинг операторов в Nulable?
Никаких неявных преобразований. Перегрузку операторов для начинающих — нафиг!
Нуллабле — пока нафиг.
LVV>>Тут еще работать и работать. Но к сентябрю хотим первую версию запустить. Прямо в классах.
VD>Версию чего? Если вы решили сделать поддержку C# 4 по спецификации, и вас двое человек, то первого сентября у вас может что-то и заработает, но только не в этом году, а годка эдак через 2 (а то и через 5).
Нас 4 человека.
Среда уже работает.
Идет не разработка а рефакторинг. В первую очередь рефакторинг общей архитектуры.
Уточнение семантики конструкций, исследование операций рефакторинга для включения в систему.
Анализ действий программиста в среде.
Так что к сентябрю, думаю, успеем.
Проблема пока в разработке хорошего хелпа — один пацан как-то не справляется пока...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[6]: Будущее программирования - обсудим?
От: LaptevVV Россия  
Дата: 11.02.12 06:35
Оценка:
Здравствуйте, uncommon, Вы писали:

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

U>ПТУ?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Будущее программирования - обсудим?
От: LaptevVV Россия  
Дата: 11.02.12 06:36
Оценка:
Здравствуйте, 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>Но проект эквивалентный хотя бы паре сотен тысяч строк в мультиграфе и не в текстовом виде — это не для людей точно
Пока речь идет в первую очередь о лабах, курсовых и дипломах. Нужен инструмент для разбора и оценки.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.