Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 150
Хорошая идея!
жду продолжения
З.Ы.
сам давно думал об чем то в таком духе, но пока «руки не дошли»…
З.Ы.Ы.
чем обусловлен выбор плотформы?(дотНЕТ)
жду продолжения
З.Ы.
сам давно думал об чем то в таком духе, но пока «руки не дошли»…
З.Ы.Ы.
чем обусловлен выбор плотформы?(дотНЕТ)
Тут несколько причин:
1. Я хорошо знаю C#
2. .net имеет высокую скорость
3. .net обладает кроссплатформенностью (благодаря mono, который мне уже давно больше нравится чем сам .net)
4. .net отвечает всем требованиям проекта
1. Я хорошо знаю C#
2. .net имеет высокую скорость
3. .net обладает кроссплатформенностью (благодаря mono, который мне уже давно больше нравится чем сам .net)
4. .net отвечает всем требованиям проекта
Я уже наверно стар. Вот раньше говорили, что С имеет высокую скорость… (:
Странное высказывание. Да, С имеет более высокую скорость чем C#. Все познается в сравнении. Я сравнивал с другими знакомыми мне языками (PHP, Python).
И неправильно сделали — PHP и Python — языки интерпретируемые, так что C# безусловно будет быстрее
Разумнее было бы сравнить с Java
Разумнее было бы сравнить с Java
.net сборку еще можно прекомпилировать, как это сделано для стандартных сборок FCL в .net, как в mono — не знаю. Есть еще какие-то проекты по написанию AOT компиляторов, так что примерно сравнимого с C быстродействия достичь можно при желании.
да, действительно. хорошая идея!
Нам нужна еще одна успешная IDE!
Нам нужна еще одна успешная IDE!
Стоит заметить, что всякая там мульти платформенность и т.д. вещи второстепенные… На первом месте — это построение семантического дерева, на которое уже будет навешиваться и расцветка, и нормальные рефакторинги, и все остальное. Потом нужно создать свою виртуальную фаловую систему, чтобы как-то синхронизироваться с внешним миром… Все остальные части IDE будут переписываться по тысячи раз пока разработчики не поймут чего они хотят. А то, что я перечислил, скорее всего, останется навсегда как незыблемый фундамент (ну разве что дописываться будет в случае изменения языка)
Пока не интересно. Жду «высокоуровневого проекта»
o_0 «Пишем свой SharpDevelop за 24 часа»
вашу бы энергию, да в мирных целях :)
напрмер напильником тот же SharpDevelop попилять, или к Эклипсу чего дописать… а можно на Add-in'ах к Студии поразмяться и чего полезного обществу родить… а очередной мертворожденный проект это печально.
почитать, конечно, будет любопытно, но в тоге ничего большего чем пара статей на хабре и левелап нескольких скиллов к программинге у автора ожидать бессмысленно. а так хотелось увидеть как напишется «IDE твоей мечты, %username%» вместо грустной картины «мечты vs суровая реальность»
вашу бы энергию, да в мирных целях :)
напрмер напильником тот же SharpDevelop попилять, или к Эклипсу чего дописать… а можно на Add-in'ах к Студии поразмяться и чего полезного обществу родить… а очередной мертворожденный проект это печально.
почитать, конечно, будет любопытно, но в тоге ничего большего чем пара статей на хабре и левелап нескольких скиллов к программинге у автора ожидать бессмысленно. а так хотелось увидеть как напишется «IDE твоей мечты, %username%» вместо грустной картины «мечты vs суровая реальность»
Прочитайте цель проекта. Основная цель — обучение.
да я это понял. непонятно только обучение кого?
если себя, то непонятно зачем выносить это на публику — наблюдать за неудачниками не так уж и забавно, а если и для других то оптимальнеебыл бы проект с шансами а долгую и успешную жизнь. я, конечно, и вашему проекту желаю процветания, но IDE это такая штука, трудоемкость которой измеряется человеко-годами (точне и человеко-веками)…
при попытке учить других на примерах важно балансировать между сложностью (иначе интереса не будет) и выполнимостью (иначе интерес быстро угаснет).
З.Ы.: я все равно с интересом понаблюдаю если будете публиковать материал и дальше, всегда интересно посмотреть как работают дугие ;)
если себя, то непонятно зачем выносить это на публику — наблюдать за неудачниками не так уж и забавно, а если и для других то оптимальнеебыл бы проект с шансами а долгую и успешную жизнь. я, конечно, и вашему проекту желаю процветания, но IDE это такая штука, трудоемкость которой измеряется человеко-годами (точне и человеко-веками)…
при попытке учить других на примерах важно балансировать между сложностью (иначе интереса не будет) и выполнимостью (иначе интерес быстро угаснет).
З.Ы.: я все равно с интересом понаблюдаю если будете публиковать материал и дальше, всегда интересно посмотреть как работают дугие ;)
В одной из моих статей меня попросили рассказать о том как разрабатывать приложения от проектирования до выпуска. Мне стала интересна эта тема и я занимался подготовкой материала, часть из которого вы сейчас наблюдаете. Более того, мне очень интересно применить несколько особо любимых паттернов в совокупности на практике.
Я свой проект пилю уже 5 лет, ну как 5, год пилил потом бросил, а через год заново начал, и до сих пор пилю) Сразу скажу, что вначале была полная лажа, обычный чат-бот. Зато теперь довольно мощная штука. И интерес не угасает, а нарастает. На пред последней сборке выглядел так:
Сейчас разрабатываю модуль логического мышления, через 2-3 месяца сделаю новую сборку.
И если сложный проект, это круто, и чем сложнее тем лучше, это мотивирует изучать новые области.
SharpDevelop развивается довольно медленно.
Как насчет того что б взять исходники MonoDevelop?
Как насчет того что б взять исходники MonoDevelop?
А ваша среда «вэб-разработки» будет обходиться без серверного языка? Какая-то странная «вэб-разработка».
То, что вы описываете, похоже на notepad виндуса с расширенными возможностями.
IDE подразумевает под собой не только редактор с подсказками, сниплетами, доками и автокомплитом, это еще и сборка, тестирование, отладка и много-много чего еще.
Откройте тот же Эклипс, РАД, НетБинз и т.д.
По-моему мнению, написание продвинутого блокнота вам скиллов особых не добавит.
Покопайтесь в Paint.net, напишите для него расширение, изучите. что там уже написано.
Ковыряние чужого кода, его разбор и написание своего — вот это реальный-мега-скилл.
Всеравно желаю удачи! Ученье — свет!
То, что вы описываете, похоже на notepad виндуса с расширенными возможностями.
IDE подразумевает под собой не только редактор с подсказками, сниплетами, доками и автокомплитом, это еще и сборка, тестирование, отладка и много-много чего еще.
Откройте тот же Эклипс, РАД, НетБинз и т.д.
По-моему мнению, написание продвинутого блокнота вам скиллов особых не добавит.
Покопайтесь в Paint.net, напишите для него расширение, изучите. что там уже написано.
Ковыряние чужого кода, его разбор и написание своего — вот это реальный-мега-скилл.
Всеравно желаю удачи! Ученье — свет!
Я работаю JavaScript-разработчиком, пишу на JS, верстаю с использованием HTML/CSS. Для меня актуальна такая среда. Кстати, Aptana (на базе Eclipse) как раз является подобной средой.
А насчет Paint.NET — зачем мне заниматься тем, что мне не интересно? Мне интересны сложные проекты на данный момент. Опыта хватает, знаний тоже.
А насчет Paint.NET — зачем мне заниматься тем, что мне не интересно? Мне интересны сложные проекты на данный момент. Опыта хватает, знаний тоже.
Paint.NET на .NET написан, к тому же он совсем непростой.
Если вам кажется, что вам хватает опыта и знаний, значит вы слишком мало знаете. В контексте данного топика это особенно заметно.
Поясните. Я люблю учиться на ошибках.
Это следствие «Я знаю только то, что ничего не знаю» Сократа.
Поэтому если человек говорит «Опыта хватает, знаний тоже.», то можно с вероятностью 0.99 можно сделать предположение о его уровне.
P.S. Я сам как-то сказал такие слова вслух и при людях. После этого прошло достаточно много времени: я очень много узнал и получил очень много опыта. Сейчас понимаю, что я знаю очень мало, а мой опыт — тьфу.
Поэтому если человек говорит «Опыта хватает, знаний тоже.», то можно с вероятностью 0.99 можно сделать предположение о его уровне.
P.S. Я сам как-то сказал такие слова вслух и при людях. После этого прошло достаточно много времени: я очень много узнал и получил очень много опыта. Сейчас понимаю, что я знаю очень мало, а мой опыт — тьфу.
скажите, «сниплеты» — это опечатка или где-то есть такой термин?
просто мне знаком только термин snippets, который есть в VS
просто мне знаком только термин snippets, который есть в VS
Я не встречал, а сниппеты есть не только в VS это общее понятие :)
Есть разные веб-сервисы которые их сортируют и иногда дают API или плагины к IDE :)
gotcodesnippets.com/
www.codekeep.net/addins.aspx
Есть разные веб-сервисы которые их сортируют и иногда дают API или плагины к IDE :)
gotcodesnippets.com/
www.codekeep.net/addins.aspx
Я встречаю то сниппеты, то сниплеты постоянно. Не знаю как правильно. Но исправлю на сниппеты, спасибо.
Мне кажется еще стоит интегрировать рендер и w3c validator :)
Язык для использования контролов как я понимаю ASP.Net?
Сам C# будет поддерживаться?
Intellisence?
Язык для использования контролов как я понимаю ASP.Net?
Сам C# будет поддерживаться?
Intellisence?
Интересно, автор читал Фаулера?
Читал Мартина Фаулера и Стива Макконнелла. А почему вы спрашиваете?
К вопросу о подходе. Сказать «давайте сделаем IDE» это тоже самое что сказать «давайте сделаем OS». Можно написать 100 заданий, нарисовать массу красивых диаграмм, потратить массу времени на дизайн, написание кода, переработку, довести проект до рабочего состояния… и ничего не сделать.
Высокоуровневое проектирование это конечно хорошо. В том случае, когда есть аналитики которые знают, каков должен быть результат, которые отлично разбираются в предметной области, которые могут правильно поставить задачи. В вашем посте ничего этого нет. Есть абстрактные рассуждения… давайте сделаем то-то и то-то, пусть конечный продукт будет запускаться под win, linux, mac…
Начните с другой стороны, изучите предметную область, определитесь с тем, что вам _не_хватает_, или _не_нравится_ в существующих средах разработки… Исходя из этой информации гораздо проще придумать и конкретизировать модель будущего приложения. Как-то так.
Высокоуровневое проектирование это конечно хорошо. В том случае, когда есть аналитики которые знают, каков должен быть результат, которые отлично разбираются в предметной области, которые могут правильно поставить задачи. В вашем посте ничего этого нет. Есть абстрактные рассуждения… давайте сделаем то-то и то-то, пусть конечный продукт будет запускаться под win, linux, mac…
Начните с другой стороны, изучите предметную область, определитесь с тем, что вам _не_хватает_, или _не_нравится_ в существующих средах разработки… Исходя из этой информации гораздо проще придумать и конкретизировать модель будущего приложения. Как-то так.
Еще добавлю, что с GTK и Mono автор явно поторопился…
Поясните.
А тут пояснять нечего. .NET и Mono это две разные вещи. Пока MS не выкупит Mono и официально не объявет о поддержке своей платформы на отличных от Windows операционных системах, вообще нет смысла ориентироваться на C#, как на язык кроссплатформенной разработки.
По поводу GTK практически тоже самое. Эти ребята похоже, сами пока не знают, чего хотят.
По поводу GTK практически тоже самое. Эти ребята похоже, сами пока не знают, чего хотят.
А тут пояснять нечего. .NET и Mono это две разные вещи. Пока MS не выкупит Mono и официально не объявет о поддержке своей платформы на отличных от Windows операционных системах, вообще нет смысла ориентироваться на C#, как на язык кроссплатформенной разработки.
По поводу GTK практически тоже самое. Эти ребята похоже, сами пока не знают, чего хотят.
По поводу GTK практически тоже самое. Эти ребята похоже, сами пока не знают, чего хотят.
Не совсем с вами согласен, тк с вашей точки зрения, mono — живой труп пока его не купят MS, факты о рабочих приложениях на Mono/Gtk# и даже Mono/ASP.NET говорят же об обратном.
Какие? Что-то серьезное сделано? Учебный F-Spot? Понятное дело, что разработчики Gnome будут его тянуть, пытаясь вдохнуть жизнь в свой продукт… Только наврядли что-то у них получится.
Команда Mono работает, результаты налицо, понятное дело, что разработка идет медленней и они стараются реализовать спецификации .net. Если для вас выглядят недостаточно убедительно список проектов использующих Mono, то я даже не знаю что может быть очевиднее фактов.
Проекты в целях обучения это всегда хорошо.
Но имхо уж больно большую цель Вы выбрали для одного человека.
Но имхо уж больно большую цель Вы выбрали для одного человека.
>Интерфейс
>Реализации
>>WinForms (Windows)
>>Gtk# (*nix)
>>Cocoa# (Mac OS X)
может стоит выбрать что нить одно кроссплатформенное?
>Реализации
>>WinForms (Windows)
>>Gtk# (*nix)
>>Cocoa# (Mac OS X)
может стоит выбрать что нить одно кроссплатформенное?
В том то и дело — хочется учитывать особенности интерфейса каждой ОС для максимального удобства. Например, приложения на Java очень неудобны в Mac OS X.
>Например, приложения на Java очень неудобны в Mac OS X.
ого! а вы видели, например, cyberduck? Ну или хотя бы IJ Idea…
ого! а вы видели, например, cyberduck? Ну или хотя бы IJ Idea…
Это как раз приложения, которые используют разные GUI для разных операционных систем. Это хороший тон.
У идеи один и тот же гуй под все ОС, есть конечно под каждую хаки — но в целом одно и тоже.
идея-то? Не очень понятно что вы имеете в виду под «разным GUI», но код там практически весь pure java и GUI в разных системах _практически_ не отличается, это вам не SWT'шный эклипс. Ну а UI cyberduck'а (оп-па!) вообще на cocoa.
SWT'шники, кстати, тоже от карбона к cocoa переходят
SWT'шники, кстати, тоже от карбона к cocoa переходят
О, я ни разу не видел Джава-приложения на Маке! А чем они неудобны?
Имеют не нативный интерфейс. Меню не сверху и т.п.
ой, уж меню-то исправляется одной строчкой…
Автор, предлагаю заменить WinForms на WPF, не пожалеете. Совсем другой подход к программированию (все элементы форм и их параметры задаются в XML), соответственно минимизация хардкода, отсутствие автосгенерированного кода, и т.д. — оно того стоит. Да и вообще самого кода придется писать меньше, так как это намного более мощное решение.
Я полностью перешел на WPF полгода назад, теперь разработка — одно сплошное удовольствие, просыпаюсь каждое утро, сразу мысль, вот, после завтрака продолжу проект… сразу настроение улучшается, позитив.
Я полностью перешел на WPF полгода назад, теперь разработка — одно сплошное удовольствие, просыпаюсь каждое утро, сразу мысль, вот, после завтрака продолжу проект… сразу настроение улучшается, позитив.
Проект OpenSource?
То, что Вы описали на самом деле — это еще не проектирование, а техзадание.
Это этап, предшествующий проектированию.
Это этап, предшествующий проектированию.
Если верить Стиву Макконнелу, то постановка цели, выработка требований и написание архитектуры — неотъемлимые этапы процесса проектирования. В любом случае спасибо, что выразили свое мнение.
Давненько Макконнелла не перечитывал, подзабыл уже немного.
Мой пойнт в том, что обычно программист или команда не занимается постановкой цели и выработкой требований — это задача заказчика. В идеале от заказчика т.з. приходит именно в том виде, что вы написали.
Но если вы — сам себе заказчик, то тогда этот этап техзадания можно включить в проектирование.
Мой пойнт в том, что обычно программист или команда не занимается постановкой цели и выработкой требований — это задача заказчика. В идеале от заказчика т.з. приходит именно в том виде, что вы написали.
Но если вы — сам себе заказчик, то тогда этот этап техзадания можно включить в проектирование.
К сожалению (или к счастью) я учился на опыте зарубежных разработчиков, а они проектируют это все до архитектуры включительно вместе с заказчиком.
Правильный подход.
Немного как у нас: у нас есть специальная команда Product Owner-ов и представителей команд-разработчиков. Они придумывают фичи, расставляют приоритеты и описывают их в удобном для команды виде. Получается грамотное т.з., которое поступает команде — а по такому т.з. уже и работать приятно.
Прямые контакты команды с заказчиками запрещены, чтобы девелоперов не нервировать — только через product owner-ов
Немного как у нас: у нас есть специальная команда Product Owner-ов и представителей команд-разработчиков. Они придумывают фичи, расставляют приоритеты и описывают их в удобном для команды виде. Получается грамотное т.з., которое поступает команде — а по такому т.з. уже и работать приятно.
Прямые контакты команды с заказчиками запрещены, чтобы девелоперов не нервировать — только через product owner-ов
Гм, я так думаю, что IDE для веб разработки — слишком сложный для учебный проект, тем более уже есть open source «аналоги» MS VS — Sharp/MonoDevelop и пишут они их достаточно долго и сравнивать их со студией сложно, разные весовые категории. Это, так сказать, от себя, мысли.
Статья — очень хорошо, но основное — это требования, которые каким-либо образом стоит изложить, желательно подробно, чтобы было возможно приступать к дизайну программного обеспечения.
PS
Насчет расширяемости, почему JS и стоит ли понимать под полноценными библиотеками плагины?
Статья — очень хорошо, но основное — это требования, которые каким-либо образом стоит изложить, желательно подробно, чтобы было возможно приступать к дизайну программного обеспечения.
PS
Насчет расширяемости, почему JS и стоит ли понимать под полноценными библиотеками плагины?
Полноценная библиотека — что-то вроде dll. Для масштабных дополнений. А JS — для мелких.
Почему JS? Потому что это стандарт дэ-факто для расширения приложений.
Почему JS? Потому что это стандарт дэ-факто для расширения приложений.
Ясно, интересно будет посмотреть связку .net — js, тк движков js для .net я не встречал, хотя и не исключаю их существование) лично бы я остановился бы для начала на .dll плагинах. В рамках Mono есть Addin framework, советую посмотреть в эту сторону.
интересно.
Имхо, интерфейс лучше делать на QT изначально, чем писать 3 версии под 3 ос :)
Но вот не знаю, есть ли биндинги QT под .NET/Mono
Имхо, интерфейс лучше делать на QT изначально, чем писать 3 версии под 3 ос :)
Но вот не знаю, есть ли биндинги QT под .NET/Mono
Есть, как ни странно QT# =)
Проект уже сейчас подает большие надежды ид колышет широчайшие народные массы!
Правда, остается два вопроса — можно ли будет грабить корованы (ну хотя бы посредством плагина на де-факто стандартном js) и планируется ли версия под ОС нового поколения dino-web?
Правда, остается два вопроса — можно ли будет грабить корованы (ну хотя бы посредством плагина на де-факто стандартном js) и планируется ли версия под ОС нового поколения dino-web?
Имхо гораздо интереснее учиться на проектах, которые до тебя еще никому не приходил в голову. Ну или по крайней мере в программе должны быть такие фитчи, штуки или функции. Иначе велик соблазн просто слямзить готовое.
А вообще начало мне нравится, ждемс продолжния и интересных и новых идей в проектном решении.
А вообще начало мне нравится, ждемс продолжния и интересных и новых идей в проектном решении.
Надеюсь, может хоть вы напишете про UML тогда? А то проектирование проектированием, оно тоже бывает качественным и некачественным. Подняли бы мне карму, чтобы я писать смог, я бы тогда написал :)
Посмотрите на Aptana. Может имеет смысл сделать модуль для Eclipse? Заодно и Java изучите, оно того стоит, уж поверьте.
Автор упоминает что главная цель — это обучение. Ничего против этого не имею, но все-таки на всякий случай скажу. Автор указывает Мак, как целивую платформу номер один и в тоже самое время выбирает C# так как он его хорошо знает… В общем, советую хорошо подумать на этапе выбора технологий, прежде чем приступать к следующим пунктам составления плана :) А вообще, если уж изучать что-либо самостоятельно и работать над своим проектом, то я бы смотрел в сторону Опен Соурс технологий, но никак не Microsoft.
Советую вам разработать плагин для Eclipse и узнать побольше про OSGi. Я бы и сам этим занялся, интерес есть во всяком случае. Заодно Java подучите, всё же с кроссплатформенностью у неё должно быть получше :).
Свою IDE, я уверен, что не потянете. Вы хоть знаете ВСЕ функции настоящей IDE? Я вот нет… нахожу новые фишечки и удобства постоянно.
p.s.: открывая для себя Eclipse, я понял какой должна быть настоящая IDE. :) удачи ;)
Свою IDE, я уверен, что не потянете. Вы хоть знаете ВСЕ функции настоящей IDE? Я вот нет… нахожу новые фишечки и удобства постоянно.
p.s.: открывая для себя Eclipse, я понял какой должна быть настоящая IDE. :) удачи ;)
Eclipse очень медленная, а в плане кода — очень интересная.
Но опять же — прочитайте цель проекта.
Но опять же — прочитайте цель проекта.
А насчет функций IDE — нет фиксированного списка функций с которым редактор становится IDE.
На Open Komodo смотрели?
В «примерах успешных IDE» следовало бы и Воrland Delphi добавить… опять дискриминация ;)
Знаете, все таки цели нужно несколько пересмотреть, имхо одно дело учиться — другое дело разрабатывать конечный продукт… Ну и потом, если Вы все же ставите целью написать IDE не для себя, а для других, то необходимо исследовать потребности потенциальных пользователей вашего продукта, ну и в конце концов ответить на один вопрос: а готовы ли Вы посвятить ему часть своей жизни? (мертвых проектов и без того хватает)
На мой взгляд рынок IDE перенасыщен, чтобы пытаться сделать что-либо новое и конкурентноспособное в этой области. Топик — фантазия. Я буду серьезно удивлен если из этого что-либо стоящее получится! Но может конечно я и ошибаюсь.
Выбор технологий конечно выглядит немного странно. Хотя понятно почему, автор объяснял. И что за версия Mac OS 1.5.0? Может 10.5.0?
Какое то время я сам думал над идеальной (для меня) IDE. И вот некоторые мои мысли:
1. Не стоит ориентироваться на существующие IDE, которые похожи как капли воды (IDEA, Orcas, Eclipse), иначе это будет подражанием, и превзойти их можно будет только качеством. Но это с ограниченными ресурсами нереально, нужно выделяться подходом.
2. Все вышеупомянутые IDE хранят файлы проектов в виде коллекции файлов исходников и файлов проекта. Это сделано по исторической причине: компиляторы работают с файлами, системы контроля версий работают с файлами, редакторы текста (от куда произошли IDE) работают с файлами. Но я как программист думаю классами, объектами и методами, где файлы? Таким образом я пришел к идеи, что от файлов нужно отказаться — пусть будет один файл проекта, в нем храниться AST, с которым IDE напрямую и работает, через промежуточное представление в виде текста исключительно для редактирования. Компиляция происходит через экспорт в текстовое представление всего проекта и компилированием через nant, например.
Из пункта два сразу можно сделать нескольков выводов, например, эта IDE не для больших проектов, но большинство ведь являются такими, а потом на производительность можно забить, так первым делом нужно разработать концепт, а его совершенствование это следующий шаг.
Другой вывод это то, что отказавшись от текстового представления, можно использовать в качестве комментариев картинки, аудио, видео, TeX и другие данные.
Другой минус, но так же плюс это то, что нельзя использовать существующие системы контроля версий, но если создать свою, то она побьет все существующие, так как будет сравнивать AST, а не текстовые файлы и выдовать сответствущие сообщения: в классе Foo добавился новый метод MakeFoo(); а не то, что в каком-то файле изменился какая то строка.
Единицой редактинрования будет метод, то есть нельзя редактировать сразу весь класс, окно редактирования будет показывать только текущий метод, а для просмотра всего класса будет использоваться другое представление, желательно графическое, например UML.
Как вам такой подход, может в вашей IDE он будет реализован. Если вы настроены всерьез, то я готов присоединиться к вам и тратить пару часов в неделю на этот проект.
1. Не стоит ориентироваться на существующие IDE, которые похожи как капли воды (IDEA, Orcas, Eclipse), иначе это будет подражанием, и превзойти их можно будет только качеством. Но это с ограниченными ресурсами нереально, нужно выделяться подходом.
2. Все вышеупомянутые IDE хранят файлы проектов в виде коллекции файлов исходников и файлов проекта. Это сделано по исторической причине: компиляторы работают с файлами, системы контроля версий работают с файлами, редакторы текста (от куда произошли IDE) работают с файлами. Но я как программист думаю классами, объектами и методами, где файлы? Таким образом я пришел к идеи, что от файлов нужно отказаться — пусть будет один файл проекта, в нем храниться AST, с которым IDE напрямую и работает, через промежуточное представление в виде текста исключительно для редактирования. Компиляция происходит через экспорт в текстовое представление всего проекта и компилированием через nant, например.
Из пункта два сразу можно сделать нескольков выводов, например, эта IDE не для больших проектов, но большинство ведь являются такими, а потом на производительность можно забить, так первым делом нужно разработать концепт, а его совершенствование это следующий шаг.
Другой вывод это то, что отказавшись от текстового представления, можно использовать в качестве комментариев картинки, аудио, видео, TeX и другие данные.
Другой минус, но так же плюс это то, что нельзя использовать существующие системы контроля версий, но если создать свою, то она побьет все существующие, так как будет сравнивать AST, а не текстовые файлы и выдовать сответствущие сообщения: в классе Foo добавился новый метод MakeFoo(); а не то, что в каком-то файле изменился какая то строка.
Единицой редактинрования будет метод, то есть нельзя редактировать сразу весь класс, окно редактирования будет показывать только текущий метод, а для просмотра всего класса будет использоваться другое представление, желательно графическое, например UML.
Как вам такой подход, может в вашей IDE он будет реализован. Если вы настроены всерьез, то я готов присоединиться к вам и тратить пару часов в неделю на этот проект.
Блядь. Плохо прочитал топик. Все мои мысли выше касались по большей части языков типа C#, Java.
Насчет C# — проект подразумевает простое расширение. То есть, добавить другие языки не должно составлять проблем. Главное — основа. Присоединяйтесь, через неделю будет SVN и Trac.
Если ограничиваться умным блокнотом, то поддержа разных языков не проблема на уровне плагинов. Но если копать дальше, то начнуться проблемы: структура шарпа это монолит, а javascript'a — пластилин с кучей проволок натыканных в него.
Я имею ввиду, что работать с JS намного сложнее — неограниченная вложенность функций, замыкания, лексический контекст, eval функции, прототипы и намешанные поверх этого классы. Писать код, который статически анализирует код я бы стал только с зарплатой в несколько тысяч евро за это. Статический анализ кода на шарпе просто сказка по сравнению с JS.
Касательно JS имеет смысл только реализовать свою виртуальную машины, скрестить её с IDE и работать с кодом, который в данный момент выполняется, но это на голом энтузиазме невозможно.
Другой косяк: с проектом программы на шарпе все понятно — это исходник, манифест, ресурсы. Выполняет это все ВМ, библиотеки которой известы на момент компиляции. В случае с JS рантайм это html, dom и css, по сути что бы статически работать с кодом на нужно знать спеки всего этого на зубок и реализовать поддержку этого. По моим оценкам это очень сложно.
Я не призываю вас ни к чему, кроме того, что бы подумать прежде, чем писать код.
Я имею ввиду, что работать с JS намного сложнее — неограниченная вложенность функций, замыкания, лексический контекст, eval функции, прототипы и намешанные поверх этого классы. Писать код, который статически анализирует код я бы стал только с зарплатой в несколько тысяч евро за это. Статический анализ кода на шарпе просто сказка по сравнению с JS.
Касательно JS имеет смысл только реализовать свою виртуальную машины, скрестить её с IDE и работать с кодом, который в данный момент выполняется, но это на голом энтузиазме невозможно.
Другой косяк: с проектом программы на шарпе все понятно — это исходник, манифест, ресурсы. Выполняет это все ВМ, библиотеки которой известы на момент компиляции. В случае с JS рантайм это html, dom и css, по сути что бы статически работать с кодом на нужно знать спеки всего этого на зубок и реализовать поддержку этого. По моим оценкам это очень сложно.
Я не призываю вас ни к чему, кроме того, что бы подумать прежде, чем писать код.
Ваш второй пункт меня очень приятно удивил) Даже обрадовался что есть думающие люди.
А чего тут думать? Это достаточно очевидно :).
Только… Это ведь всё уже было. И было не так уж гладко, как кажется. Изучите историю продуктов VisualAge. Если там и не AST дерево хранилось, то что-то очень похожее. У VA-сред было много плюсов. Но и минусов тоже. Ну, а результат мы все видим.
А уж хранить таким образом уеб-проекты… :)
Только… Это ведь всё уже было. И было не так уж гладко, как кажется. Изучите историю продуктов VisualAge. Если там и не AST дерево хранилось, то что-то очень похожее. У VA-сред было много плюсов. Но и минусов тоже. Ну, а результат мы все видим.
А уж хранить таким образом уеб-проекты… :)
>Но я как программист думаю классами, объектами и методами, где файлы?
а какая, собственно, разница, как оно хранится в файловой системе? В той же идее есть представление в виде классов-методов-объектов.
>в классе Foo добавился новый метод MakeFoo();
вы не поверите, но как минимум при переименовывании та же идея сама напишет в изменения
«Renaming method MakeFoo() of class MyApp to MakeBoo()»
а какая, собственно, разница, как оно хранится в файловой системе? В той же идее есть представление в виде классов-методов-объектов.
>в классе Foo добавился новый метод MakeFoo();
вы не поверите, но как минимум при переименовывании та же идея сама напишет в изменения
«Renaming method MakeFoo() of class MyApp to MakeBoo()»
Почему редактируя метод класса я редактирую не метод класса, а файл в котором описан сам класс?
Я имел ввиду такое сообщение выведет дифф при сравнении двух версий проекта, не обладая никакой метаинформацией о изменениях.
Я имел ввиду такое сообщение выведет дифф при сравнении двух версий проекта, не обладая никакой метаинформацией о изменениях.
для этого и пишутся комментарии при коммитах…
а вообще — посмотрите ещё вот это демо:
www.jetbrains.com/idea/training/demos/local_history.html
а вообще — посмотрите ещё вот это демо:
www.jetbrains.com/idea/training/demos/local_history.html
кстати я тут выяснил, что идея вполне себе может показывать что метод какой-то и переменная такая-то — новые.
Мысль свежая, интересная. Было бы приятно, если бы вместо здоровенного репозитория исходников проекта все постоянно лежало в одном компактном архивчике.
Но, с другой стороны, какая разница где хранится исходник, в файлах ли, или в архиве, или в базе данных, или как-то еще? Современные IDE (та же IDEA), как раз именно как Вы и пишите, могут работать в режиме пакет-класс-метод, то есть, можно писать код, даже не задумываясь что есть какие-то там файлы.
Аналогично с UML, ряд IDE (например Visual Studio) уже давно это используют для представления классов. Удобно работать с AST? Пожалуйста, к распространенным IDE можно пробовать поискать соответствующие плагины (для Eclipse я такой видел точно).
Хотя мое мнение — работать с методом класса как с отдельной единицей кода, не удерживая в поле зрения его контекст, очень неудобно, особенно это касается мелких приватных методов, но, возможно, это лишь дело привычки.
Но, с другой стороны, какая разница где хранится исходник, в файлах ли, или в архиве, или в базе данных, или как-то еще? Современные IDE (та же IDEA), как раз именно как Вы и пишите, могут работать в режиме пакет-класс-метод, то есть, можно писать код, даже не задумываясь что есть какие-то там файлы.
Аналогично с UML, ряд IDE (например Visual Studio) уже давно это используют для представления классов. Удобно работать с AST? Пожалуйста, к распространенным IDE можно пробовать поискать соответствующие плагины (для Eclipse я такой видел точно).
Хотя мое мнение — работать с методом класса как с отдельной единицей кода, не удерживая в поле зрения его контекст, очень неудобно, особенно это касается мелких приватных методов, но, возможно, это лишь дело привычки.
Далее, продолжу. Исходники, написанные на каком-либо языке программирования — это далеко не единственные артефакты проекта. Еще есть конфиги, темплейты, разного рода графика, таблицы стилей и многое другое, в зависимости от проекта.
То есть, проект состоит не только из компилируемых единиц, а еще и из других ресурсов, но которые тоже являются составляющей частью исходников. И не всегда эти ресурсы могут быть настолько абстрагированы, чтобы можно было забыть о файлах. Особенно это касается Web проектов.
Так что, наверное, эта идея слишком нова, чтобы сходу бросаться ее внедрять, но в любом случае интересна, стоит того, чтобы ее можно было посмотреть.
То есть, проект состоит не только из компилируемых единиц, а еще и из других ресурсов, но которые тоже являются составляющей частью исходников. И не всегда эти ресурсы могут быть настолько абстрагированы, чтобы можно было забыть о файлах. Особенно это касается Web проектов.
Так что, наверное, эта идея слишком нова, чтобы сходу бросаться ее внедрять, но в любом случае интересна, стоит того, чтобы ее можно было посмотреть.
1. Чем, позвольте поинтересоваться IDEA похожа на Eclipse, например? Вобщем-то, рассуждая подобным образом, можно сказать, что все IDE похожы, как две капли воды.
2. Отказ от использования файлов проекта и исходников — откровенный бред.
3. «Использование в качестве комментариев картинки» ЛОЛ))))))
4. По поводу системы контроля версий — советую для начала написать такую штуку как diff. Уверяю, задача нетривиальная.
Вобщем, можно посоветовать учить матчасть.
2. Отказ от использования файлов проекта и исходников — откровенный бред.
3. «Использование в качестве комментариев картинки» ЛОЛ))))))
4. По поводу системы контроля версий — советую для начала написать такую штуку как diff. Уверяю, задача нетривиальная.
Вобщем, можно посоветовать учить матчасть.
1. Да я и утверждаю, что все IDE (популярные) похожи как две капли воды. Кроме, наверное, xotclide и других, которые не на слуху.
2. Ваш комментарий — откровенный бред.
3. Не только картинки, но и маркеры, что бы можно было обвести кусок кода красным, вставить гиперссылку на описание алгоритма. Да и вообще код здорово оформлять в виде mind map. Или как это можно делать в OneNote. Если писать код на бумаге, то он у меня выглядит как раз так и не факт, что классическое представление лучше.
4. Тривиальная задача, Как я писал код хранится в виде AST, поэтому diff сводиться к сравнению деревьев.
Матчасть? Гомоморфный образ группы изоморфен фактор группе по ядру гомоморфизма.
2. Ваш комментарий — откровенный бред.
3. Не только картинки, но и маркеры, что бы можно было обвести кусок кода красным, вставить гиперссылку на описание алгоритма. Да и вообще код здорово оформлять в виде mind map. Или как это можно делать в OneNote. Если писать код на бумаге, то он у меня выглядит как раз так и не факт, что классическое представление лучше.
4. Тривиальная задача, Как я писал код хранится в виде AST, поэтому diff сводиться к сравнению деревьев.
Матчасть? Гомоморфный образ группы изоморфен фактор группе по ядру гомоморфизма.
То есть желания задуматься не появилось, я правильно понимаю?)
По поводу гиперссылок — разве кто-то отменил, например какой-нибудь doxygen? Оформлять код в виде майндмэпов — зачем? Рисуйте майндмэпы на бумаге, код должен быть формализован. На-то он и код.
По поводу дифа — напишите дифф, который будет сравнивать два xml-документа, например. Те же деревья, с которыми несложно работать, тогда и поговорим. Только дифф, понятое дело это не просто ответ — одинаковые, или разные.
А вобще нескромный вопрос — вы участвовали когда-нибудь в разработке крупных проектов? Где много людей, много мнений, много кода, много ошибок?
По поводу гиперссылок — разве кто-то отменил, например какой-нибудь doxygen? Оформлять код в виде майндмэпов — зачем? Рисуйте майндмэпы на бумаге, код должен быть формализован. На-то он и код.
По поводу дифа — напишите дифф, который будет сравнивать два xml-документа, например. Те же деревья, с которыми несложно работать, тогда и поговорим. Только дифф, понятое дело это не просто ответ — одинаковые, или разные.
А вобще нескромный вопрос — вы участвовали когда-нибудь в разработке крупных проектов? Где много людей, много мнений, много кода, много ошибок?
1. Чем, позвольте поинтересоваться IDEA похожа на Eclipse, например? Вобщем-то, рассуждая подобным образом, можно сказать, что все IDE похожы, как две капли воды.
2. Отказ от использования файлов проекта и исходников — откровенный бред.
3. «Использование в качестве комментариев картинки» ЛОЛ))))))
4. По поводу системы контроля версий — советую для начала написать такую штуку как diff. Уверяю, задача нетривиальная.
Вобщем, можно посоветовать учить матчасть.
2. Отказ от использования файлов проекта и исходников — откровенный бред.
3. «Использование в качестве комментариев картинки» ЛОЛ))))))
4. По поводу системы контроля версий — советую для начала написать такую штуку как diff. Уверяю, задача нетривиальная.
Вобщем, можно посоветовать учить матчасть.
Не только вам такие мысли приходили в голову:)
Мы в JetBrains пишем проект MPS предназначенный для разработки домен-специфичных языков и программировании на них. В нашем проекте не используется текст для представления кода, а как раз AST. Редактируется оно не путём преобразованием в текст, а непосредственно, что означает отсутствие необходимости написания парсера для языка. Для компиляции проекта из него генерируется текст.
Если интересно, то можете посмотреть на EAP версию www.jetbrains.net/confluence/display/MPS/JetBrains+MPS+Download+Page.
Мы в JetBrains пишем проект MPS предназначенный для разработки домен-специфичных языков и программировании на них. В нашем проекте не используется текст для представления кода, а как раз AST. Редактируется оно не путём преобразованием в текст, а непосредственно, что означает отсутствие необходимости написания парсера для языка. Для компиляции проекта из него генерируется текст.
Если интересно, то можете посмотреть на EAP версию www.jetbrains.net/confluence/display/MPS/JetBrains+MPS+Download+Page.
Извиняюсь, правильная ссылка MPS Download Page.
А есть где-то более подробные статьи по MPS? Я глянул два скринкаста: webr & создание простейшего языка от Сергея Дмитриева и мысли следующие:
1) В чём (принципиальные) преимущества перед Internal DSLs(например Groovy & Grails)?
2) Создание языка выглядит наиболее мутным: это не просто; используется кодогенерация; не ясен вопрос interoperability с другими библиотеками.
3) Насколько это применимо на практике? Слышал, что в JB на ней пишется новая PM/Bug-tracking система.
Вообщем нужен опенсорсный проект, где можно посмотреть, как это всё внутри устроенно и работает. На данный момент складывается ощущение, что с Groovy/Scala можно быть более продуктивным.
1) В чём (принципиальные) преимущества перед Internal DSLs(например Groovy & Grails)?
2) Создание языка выглядит наиболее мутным: это не просто; используется кодогенерация; не ясен вопрос interoperability с другими библиотеками.
3) Насколько это применимо на практике? Слышал, что в JB на ней пишется новая PM/Bug-tracking система.
Вообщем нужен опенсорсный проект, где можно посмотреть, как это всё внутри устроенно и работает. На данный момент складывается ощущение, что с Groovy/Scala можно быть более продуктивным.
Преимущества MPS такие:
1. Язык автоматически получает IDE, которая «знает» про его конструкции, т. е., например, комплишн и подсветка автоматически работают.
2. Возможно создание собственной системы типов.
3. Поддержка data flow анализа для языка.
5. Расширяемость IDE через плагины.
6. Возможность расширения языков. Например, хотите добавить новый тип statement-a в java (она у нас baseLanguage называется) — пожалуйста.
Да, к сожалению, обучиться MPS-у не очень просто, и материалов в сети не много. Мы пишем руководство по MPS. Также могу дать ссылки на пару скринкастов, некоторые из них, правда, достаточно старые:
1. Расширение baseLanguage новой конструкцией www.sergeydmitriev.com/mps/blext/BaseLanguageExtension.html
2. Пример из книжки Мартина Фаулера www.sergeydmitriev.com/mps/dslbook_example/dslbook_example.html
Также в дистрибутиве MPS есть несколько небольших примеров языков.
Багтрекер не только пишется, но используется у нас, в частности для MPS.
А что вы имеете в виду под «interoperability с другими библиотеками»?
1. Язык автоматически получает IDE, которая «знает» про его конструкции, т. е., например, комплишн и подсветка автоматически работают.
2. Возможно создание собственной системы типов.
3. Поддержка data flow анализа для языка.
5. Расширяемость IDE через плагины.
6. Возможность расширения языков. Например, хотите добавить новый тип statement-a в java (она у нас baseLanguage называется) — пожалуйста.
Да, к сожалению, обучиться MPS-у не очень просто, и материалов в сети не много. Мы пишем руководство по MPS. Также могу дать ссылки на пару скринкастов, некоторые из них, правда, достаточно старые:
1. Расширение baseLanguage новой конструкцией www.sergeydmitriev.com/mps/blext/BaseLanguageExtension.html
2. Пример из книжки Мартина Фаулера www.sergeydmitriev.com/mps/dslbook_example/dslbook_example.html
Также в дистрибутиве MPS есть несколько небольших примеров языков.
Багтрекер не только пишется, но используется у нас, в частности для MPS.
А что вы имеете в виду под «interoperability с другими библиотеками»?
Ну багтрекер я уже глянул — teamsys.intellij.net/teamsys/workspace я правда не знаю, должен ли он вот так пускать пользователя или нет)
Просто мне кажется, что Language Workbench — это какой-то over-engineering по сравнению с internal DSLs. Комплишн и подсветка работают и с Groovy, а у Scala есть ещё большие переспективы в этом плане, type system у неё тоже довольно богатая.
Если можно — ряд конкретных вопросов:
1) Code re-use. DSL наверное являются самыми сложными с точки зрения проектирования, абстрактно мыслить задачами куда сложнее, чем декомпозировать их на объекты. И если с Java мы можем без осложнений подключить любую старую бизнес-логику, то возникает вопрос — насколько совместимы различные DSL? Насколько развиты средства для их автоматического рефакторинга в случае изменения?
2) Чёрный ящик. Те примеры MPS, что я видел — не интуитивны и язык не кажется целым(в отличие от internal DSL). Действительно будет проще разобраться в 5 DSL, чем в 5 API? Как оптимизировать такие программы(транслятора порой мало и нужен умный компилятор)?
Просто мне кажется, что Language Workbench — это какой-то over-engineering по сравнению с internal DSLs. Комплишн и подсветка работают и с Groovy, а у Scala есть ещё большие переспективы в этом плане, type system у неё тоже довольно богатая.
Если можно — ряд конкретных вопросов:
1) Code re-use. DSL наверное являются самыми сложными с точки зрения проектирования, абстрактно мыслить задачами куда сложнее, чем декомпозировать их на объекты. И если с Java мы можем без осложнений подключить любую старую бизнес-логику, то возникает вопрос — насколько совместимы различные DSL? Насколько развиты средства для их автоматического рефакторинга в случае изменения?
2) Чёрный ящик. Те примеры MPS, что я видел — не интуитивны и язык не кажется целым(в отличие от internal DSL). Действительно будет проще разобраться в 5 DSL, чем в 5 API? Как оптимизировать такие программы(транслятора порой мало и нужен умный компилятор)?
0. Language Workbench вещь более сложная, чем internal dsl, зато она и свободы даёт больше. В частности, из наших dsl-ей можно генерировать в принципе что угодно.
1. А что вы понимаете под совместимостью? Можно ли встраивать один dsl в другой? Можно. Только то, как они вместе будут работать зависит от того, насколько хорошо эти dsl-и спроектированы.
При изменении языка в MPS необходимо написать скрипт, который конвертирует программы на нём в новую версию (преобразованием AST).
2. Мы пытаемся создать универсальную систему для построения языков, поэтому, к сожалению, продукт получается не простым для освоения. Что же касается изучения dsl-ей при изученном MPS — не думаю, что это будет сложнее, чем изучение каких-нибудь API. Насколько сложно изучить, например, какую-нибудь библиотеку? Если она хорошо спроектирована — то сравнительно просто, если плохо — то сравнительно сложно (при одном и том же уровне сложности реализуемой функциональности). Так же и с новым языком.
Автоматической оптимизации сгенерированного кода у нас нет.
1. А что вы понимаете под совместимостью? Можно ли встраивать один dsl в другой? Можно. Только то, как они вместе будут работать зависит от того, насколько хорошо эти dsl-и спроектированы.
При изменении языка в MPS необходимо написать скрипт, который конвертирует программы на нём в новую версию (преобразованием AST).
2. Мы пытаемся создать универсальную систему для построения языков, поэтому, к сожалению, продукт получается не простым для освоения. Что же касается изучения dsl-ей при изученном MPS — не думаю, что это будет сложнее, чем изучение каких-нибудь API. Насколько сложно изучить, например, какую-нибудь библиотеку? Если она хорошо спроектирована — то сравнительно просто, если плохо — то сравнительно сложно (при одном и том же уровне сложности реализуемой функциональности). Так же и с новым языком.
Автоматической оптимизации сгенерированного кода у нас нет.
Можите написать немного подробние про создание собственной системы типов?
Вообще, система типов в MPS штука сложная, подробно про неё лучше читать в главе руководства.
Попробую кратко описать основное.
Для задания системы типов для языка необходимо написать свои правила, по которым производятся проверки типов для вершин AST. Эти правила могут быть записаны в виде уравнений с неизвестными (типами), которые при проверке будут найдены алгоритмом вывода типов в MPS. В уравнениях можно проверять не только равенства, но и то, что один тип является подтипом другого (для этого в MPS можно задавать иерархии типов). Кроме этого, есть ещё много advanced возможностей, но я вряд ли могу рассказать о них, т.к. сама системой типов на таком уровне не пользуюсь.
Попробую кратко описать основное.
Для задания системы типов для языка необходимо написать свои правила, по которым производятся проверки типов для вершин AST. Эти правила могут быть записаны в виде уравнений с неизвестными (типами), которые при проверке будут найдены алгоритмом вывода типов в MPS. В уравнениях можно проверять не только равенства, но и то, что один тип является подтипом другого (для этого в MPS можно задавать иерархии типов). Кроме этого, есть ещё много advanced возможностей, но я вряд ли могу рассказать о них, т.к. сама системой типов на таком уровне не пользуюсь.
Я слышал про MPS, но толкового руковадства не встеречал. Раз вы его разрабатываете, то надеюсь вас можно спросить о ней. Каково разнообразие языков, которое можно в ней создать. Молжно но ли описать в ней, например, TCL, smalltalk или nemerle?
Руководство у нас на стадии разработки:)
Грубо говоря, определяя язык в MPS вы определяете как минимум три вещи.
1. Абстрактный синтаксис, то есть типы вершин AST и то, как они могут быть взаимосвязаны. Например, в языке Java некоторые вершины AST соответствуют конструкции while, а значит должны иметь детей, соответствующих условию и телу цикла. Или вершины соответствующие переменным имеют ссылки на объявления этих переменных.
2. Конкретный синтаксис, то есть то, как программа записывается. Например, в конструкции while сначала стоит ключевое слово, потом условие, потом тело в скобках.
3. Генератор. То как программа на языке преобразуется в текст или в другой язык, который в конце-концов тоже будет преобразован в текст.
Кроме этого, есть ещё много всего, что можно сказать про язык, например, как в нём устроена система типов, но перечисленные три пункта самые главные.
Мне кажется, что используемый способ задания языков достаточно абстрактен и покрывает достаточно много языков, в частности, думаю, и tcl и smalltalk. Про nemerle не могу сказать, т.к. очень плохо представляю себе этот язык. Вообще основная задача была не покрыть множество существующих языков, а сделать удобным создание и использование dsl-ей.
Не знаю, стало ли понятней что-нибудь про MPS или нет, спрашивайте, если что.
Грубо говоря, определяя язык в MPS вы определяете как минимум три вещи.
1. Абстрактный синтаксис, то есть типы вершин AST и то, как они могут быть взаимосвязаны. Например, в языке Java некоторые вершины AST соответствуют конструкции while, а значит должны иметь детей, соответствующих условию и телу цикла. Или вершины соответствующие переменным имеют ссылки на объявления этих переменных.
2. Конкретный синтаксис, то есть то, как программа записывается. Например, в конструкции while сначала стоит ключевое слово, потом условие, потом тело в скобках.
3. Генератор. То как программа на языке преобразуется в текст или в другой язык, который в конце-концов тоже будет преобразован в текст.
Кроме этого, есть ещё много всего, что можно сказать про язык, например, как в нём устроена система типов, но перечисленные три пункта самые главные.
Мне кажется, что используемый способ задания языков достаточно абстрактен и покрывает достаточно много языков, в частности, думаю, и tcl и smalltalk. Про nemerle не могу сказать, т.к. очень плохо представляю себе этот язык. Вообще основная задача была не покрыть множество существующих языков, а сделать удобным создание и использование dsl-ей.
Не знаю, стало ли понятней что-нибудь про MPS или нет, спрашивайте, если что.
Любопытно, а вы не пробовали SmallTalk? ) Мне кажется вам понравится )
Чем больше я читаю комменты, тем больше мне хочется сделать среду разработки для того же C#.
Прочитав эти фразы:
>Если мы хотим довести проект до конца — его необходимо спроектировать. Зачем?
>Этапы проектирования:
> 1. Определение цели
> 2. Выработка требований
> 3. Определение архитектуры
> 4. Написание высокоуровневого проекта
становиться понятно что вы не читали ни один стандарт разработки программного обеспечения, не знакомы с понятием «жизненный цикл ПО» и не читали практически ни какую соответствующую литературу, прежде чем начинать проект так как вы хотите советую познакомиться со следующими стандартами:
Стандарт ГОСТ Р ИСО/МЭК 12207
Стандарт IEEE 1074 (особенно с этим)
Для примера, приведу основные этапы:
-системный анализ;
-анализ требований;
-проектирование;
-кодирование;
-тестирование;
-сопровождение.
У вас к проектированию относятся только 3 и 4, хотя как можно проектировать если цели и требования ещё не определены неясно.
Я ни в коем случае не хочу сказать что у вас получится плохое ПО, или что у вас ничего не получиться, я просто хочу обратить внимание что область разработки ПО совсем не нова и есть достаточное количество информации, прочтя которое специалист из вас получиться намного профессиональнее, а тут прямое влияние на качество продукта.
>Если мы хотим довести проект до конца — его необходимо спроектировать. Зачем?
>Этапы проектирования:
> 1. Определение цели
> 2. Выработка требований
> 3. Определение архитектуры
> 4. Написание высокоуровневого проекта
становиться понятно что вы не читали ни один стандарт разработки программного обеспечения, не знакомы с понятием «жизненный цикл ПО» и не читали практически ни какую соответствующую литературу, прежде чем начинать проект так как вы хотите советую познакомиться со следующими стандартами:
Стандарт ГОСТ Р ИСО/МЭК 12207
Стандарт IEEE 1074 (особенно с этим)
Для примера, приведу основные этапы:
-системный анализ;
-анализ требований;
-проектирование;
-кодирование;
-тестирование;
-сопровождение.
У вас к проектированию относятся только 3 и 4, хотя как можно проектировать если цели и требования ещё не определены неясно.
Я ни в коем случае не хочу сказать что у вас получится плохое ПО, или что у вас ничего не получиться, я просто хочу обратить внимание что область разработки ПО совсем не нова и есть достаточное количество информации, прочтя которое специалист из вас получиться намного профессиональнее, а тут прямое влияние на качество продукта.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
IDE своими руками: проектирование