Новая среда разработки для .NET - Прометей - Компьютерные священные войны

Всем привет. Хочу рассказать о новой среде разработки бизнес-приложений. Называется "Прометей". Если сказать коротко, то это среда разработки для .NET, имеющая собственный язык программирования на основе синтаксиса Visual Basic.NET, расширенного русскоязычными ключевыми словами, собственный компилятор для CLR. Обладает функционалом ORM, а также способна автоматически поддерживать структуру базы данных в соответствии с логической моделью сущностей.
Особенно хочу отметить встроенный язык запросов, для которого автоматически производится типизация.
Здесь статья, где я попытался рассказать, для чего я её создал. Там же есть видео, где можно посмотреть "Прометей" в действии. "Прометей" можно скачать в моём блоге. Комментарии, обсуждения, советы и критика приветствуются. Заранее всем спасибо.

16.01.11 13:55: Перенесено модератором из '.NET' — TK

16.01.11 22:29: Перенесено модератором из 'Священные войны' — AndrewVK

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

YZ>Всем привет. Хочу рассказать о новой среде разработки бизнес-приложений. Называется "Прометей". Если сказать коротко, то это среда разработки для .NET, имеющая собственный язык программирования на основе синтаксиса Visual Basic.NET, расширенного русскоязычными ключевыми словами, собственный компилятор для CLR. Обладает функционалом ORM, а также способна автоматически поддерживать структуру базы данных в соответствии с логической моделью сущностей.
YZ>Особенно хочу отметить встроенный язык запросов, для которого автоматически производится типизация.
YZ>Здесь статья, где я попытался рассказать, для чего я её создал. Там же есть видео, где можно посмотреть "Прометей" в действии. "Прометей" можно скачать в моём блоге. Комментарии, обсуждения, советы и критика приветствуются. Заранее всем спасибо.

Посмотрел видео...
Вопрос возник только один... зачем она нужна?
Чем она лучше VS? никаких спец задач не решает...
Так же заметно влияние 1С на создателя

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

YZ>Всем привет. Хочу рассказать о новой среде разработки бизнес-приложений.

Это вам не сюда надо. Обратитесь в органы власти — Российская система разработки и все такое... Есть шанс припасть к титьке матери Родины.
Для разработчика, имхо неинтересно. От мысли писать VB-подобный код да еще по-русски аж передергивает.

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

? Знакомо

Здравствуйте, Аноним, Вы писали:

А>Посмотрел видео...
А>Вопрос возник только один... зачем она нужна?

Основная цель — это упростить процесс разработки бизнес-приложений. Существующий инструментарий для платформы .NET не очень хорошо справляется с этой задачей. Например, мы хотим добавить поле к таблице. Обычно это происходит так: сначала мы пишем соответствующий SQL DDL скрипт (или генерируем его при помощи таких средств, как Management Studio), потом мы этот скрипт передаем другим членам команды, чтобы они актуализировали свои структуры БД. Потом мы переписываем Insert-ы и Update-ы в коде своего приложения. Прометей берет всю эту работу на себя. Он автоматически актуализирует структуру БД согласно новой схеме. Никаких alter table. Также классы ORM генерируются автоматически согласно логической схеме базы данных.

А>Чем она лучше VS? никаких спец задач не решает...

VS – среда универсальная, а Прометей специализируется на разработке бизнес-логики приложений. Например, в VS нет встроенного языка SQL запросов. LINQ не в счет. Прометей генерирует класс-обвертку для SQL запроса со всем необходимым базовым функционалом. Просто пишем SQL, Прометей сделает остальное сам.

А>Так же заметно влияние 1С на создателя

Ну почему, если русский синтаксис, то сразу 1С? Писать на русском – это просто хорошая идея для разработки отечественного ПО, особенно в прикладной среде, такой как бухгалтерия, учет и прочее. Если у приложения весь UI русский, комментарии в коде тоже на русском написаны, то зачем мы пишем названия таблиц Order, Customer и Invoice? Чтобы запутать тех, кто после нас будет поддерживать наше приложение? Отсюда и начинается квест: а для чего эта таблица, я не могу найти описание в ТЗ. Задача среды Прометей – реализация этой идеи на современной среде .NET.

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

E>Очередная попытка делать мегасистемы силами бухгалтеров

? Знакомо

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

Бухгалтер – это не программист. Задача бухгалтера – вводить циферки в компьютер, задача программиста – писать программный коды. Давайте не будем путать понятия. Задача такая, чтобы в коде приложения использовались те же названия и термины, что и в техническом задании. Ясность кода и что он делает – вот цель, которая приведет к экономии времени на объяснение, что какая сущность значит. Профит: программисты быстрее напишут программу => получат больше зарплаты.

YZ>Основная цель — это упростить процесс разработки бизнес-приложений. Существующий инструментарий для платформы .NET не очень хорошо справляется с этой задачей. Например, мы хотим добавить поле к таблице. Обычно это происходит так: сначала мы пишем соответствующий SQL DDL скрипт (или генерируем его при помощи таких средств, как Management Studio), потом мы этот скрипт передаем другим членам команды, чтобы они актуализировали свои структуры БД. Потом мы переписываем Insert-ы и Update-ы в коде своего приложения. Прометей берет всю эту работу на себя. Он автоматически актуализирует структуру БД согласно новой схеме. Никаких alter table. Также классы ORM генерируются автоматически согласно логической схеме базы данных.

Entity Framework не подходит для этой задачи?

Помоему вы изобрели велосипед....

А>>Чем она лучше VS? никаких спец задач не решает...

YZ>VS – среда универсальная, а Прометей специализируется на разработке бизнес-логики приложений. Например, в VS нет встроенного языка SQL запросов. LINQ не в счет. Прометей генерирует класс-обвертку для SQL запроса со всем необходимым базовым функционалом. Просто пишем SQL, Прометей сделает остальное сам.
Почему LINQ не в счет?
Он как раз делат то что вы представляете как инновацию...

А>>Так же заметно влияние 1С на создателя

YZ>Ну почему, если русский синтаксис, то сразу 1С? Писать на русском – это просто хорошая идея для разработки отечественного ПО, особенно в прикладной среде, такой как бухгалтерия, учет и прочее. Если у приложения весь UI русский, комментарии в коде тоже на русском написаны, то зачем мы пишем названия таблиц Order, Customer и Invoice? Чтобы запутать тех, кто после нас будет поддерживать наше приложение? Отсюда и начинается квест: а для чего эта таблица, я не могу найти описание в ТЗ. Задача среды Прометей – реализация этой идеи на современной среде .NET.

Таким запутать можно только необразованных программистов которые не знают английского языка. NUST have skill.

YZ>Профит: программисты быстрее напишут программу
=> их быстрее уволят

на самом деле, если это диплом — то может и неплохо, многие этим болеют

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

Автору — это действительно скучно и неэффективно, советую быстрей переболеть и найти другую работу.

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

YZ>Всем привет. Хочу рассказать о новой среде разработки бизнес-приложений. Называется "Прометей". Если сказать коротко, то это

... тот самый Прометей, которому ежедневно печень выклевывали?

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

L>... тот самый Прометей, которому ежедневно печень выклевывали?

В данном случае скорее глаза, особенно при виде "русского языка программирования"

(мысли вслух)
Посмотрил видео, в который раз вздохнул глядя на "Функция", "КонецФункции", "Перем з = новый..." и уже решил закрыть, но тут вспомнил кое-что. Думаю многим известно такое:

При анализе второй мировой войны, американские военные историки обнаружили очень интересный факт. А именно: при внезапном столкновении с силами японцев американцы, как правило, гораздо быстрее принимали решения и, как следствие, побеждали даже превосходящие силы противника.
Исследовав данную закономерность, ученые пришли к выводу, что средняя длина слова у американцев составляет 5,2 символа, тогда как у японцев 10,8 и, следовательно, на отдачу приказов уходит на 56% меньше времени, что в коротком бою играет немаловажную роль.
Ради интереса они проанализировали русскую речь, и оказалось, что длина слова в русском языке составляет 7,2 символа на слово (в среднем), однако при критических ситуациях русско-язычный командный состав переходит на ненормативную лексику и длина слова сокращается до: 3,2 символов в слове.

Догадались? Так вот. Наверное подобное уже предлагал кто-то. Но всё же.
Как насчёт "Бухгалтерского обсценного языка программирования" на основе Visual Basic? Который будет с длинной слов короче чем в английском, более удобным и НАШИМ!
Абсолютно понятно, что такая нарочито бранная лексика оттолкнёт многих интеллектуалов. Однако, при всей неоднозначности такого предложения, этот язык являлся бы лишь разумным плодом логики.
Например (внимание, возможное нарушение правил форума, прошу понять):

ёп ПолучитьВсеНомера
  хня х = ля ВсеТелефоныйQuery
  нах
х*й

сравним с оригиналом

функция ПолучитьВсеНомера
 Перем з = Новый ВсеТелефоныйQuery
 Возврат
КонецФункции

Пояснение:
ёп — (function) начало тела функции, эмоциональная окраска как бы говорит нам о том, что это восклицание, при понимании того, что предстоит некая работа.
ля — (new) вызов конструктора.
хня — (var) опеределение переменной, тип которой выводит компилятор. Значение фразы можно перевести как "какая-то штука, сам знаешь какая".
нах — (return) возврат.
х*й — конец тела (простите за явную и мнимую многозначность) функции.

Как видите, уже даже на этапе прототипирования такой язык выигрывает у английского варианта, не говоря уже о русском.
В окопах, пожалуй, будет самое то программировать на нём.

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

YZ>Бухгалтер – это не программист. Задача бухгалтера – вводить циферки в компьютер, задача программиста – писать программный коды. Давайте не будем путать понятия. Задача такая, чтобы в коде приложения использовались те же названия и термины, что и в техническом задании. Ясность кода и что он делает – вот цель, которая приведет к экономии времени на объяснение, что какая сущность значит. Профит: программисты быстрее напишут программу => получат больше зарплаты.
Уж если очень надо, то можно все методы, переменные, классы, писать русскими буквами. И все — то, что будет в техзадании, автоматом будет 1 в 1 ложиться на код, все проблемы решены. Вот только смысла в этом нет никакого, так как практически любой программист владеет английским в достаточной степени, чтоб англоязычные названия терминов не были проблемой, более того, он с большим удовольствием будет использовать англоязычную терминологию за счет того, что он нахаляву без усилий выучит новые английские слова, даже если изначально не знает.
А программисты да, получат большие зарплаты

. Так как на свой мегаязык нужно будет привлекать ну совсем уж зеленых новичков, которые даже английского начального не знают, и платить им как нормальным разработчиков, либо брать нормальных, и платить им гораздо выше рынка, чтоб они согласились на работу, которая им не нравится (да, работать они будут медленнее, чем могли бы, так как те штатные средства, к которым они привыкли, не работают в новой среде). Вот возьмем мегаязык ABAP/4, как пример, там как раз такая ситуация — народ страшно матерится, делается все медленнее, но соглашается работать, так как платят больше.

Здравствуйте, Аноним, Вы писали:

А>Entity Framework не подходит для этой задачи?

Помоему вы изобрели велосипед....

Нет, не подходит. В EF4 появилась возможность сгенерировать скрипт создания таблиц, однако она работает очень тупо: сначала все таблицы DROP, потом все таблицы CREATE. В результате полная очистка базы данных. Entity Framework не умеет генерировать скрипт Alter Table.

А>Почему LINQ не в счет?
А>Он как раз делат то что вы представляете как инновацию...

Я вообще-то про встроенный SQL. LINQ не является языком SQL. LINQ предназначен для запросов к объектам в памяти. То, что его заточили в LINQ2SQL и EF для генерации SQL запросов — идея крайне неудачная. Программист, когда на нём пишет, никогда не знает, какой SQL будет сгенерирован. Отсюда проблемы с производительностью и прочее.

А>Таким запутать можно только необразованных программистов которые не знают английского языка. NUST have skill.

Вот после таких NUST в коде и возникают проблемы с пониманием этого кода.

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

YZ>Здравствуйте, Аноним, Вы писали:

А>>Entity Framework не подходит для этой задачи?

Помоему вы изобрели велосипед....

YZ>Нет, не подходит. В EF4 появилась возможность сгенерировать скрипт создания таблиц, однако она работает очень тупо: сначала все таблицы DROP, потом все таблицы CREATE. В результате полная очистка базы данных. Entity Framework не умеет генерировать скрипт Alter Table.

Это не повод придумывать среду разработки ведь так?

А>>Почему LINQ не в счет?
А>>Он как раз делат то что вы представляете как инновацию...

YZ>Я вообще-то про встроенный SQL. LINQ не является языком SQL. LINQ предназначен для запросов к объектам в памяти. То, что его заточили в LINQ2SQL и EF для генерации SQL запросов — идея крайне неудачная. Программист, когда на нём пишет, никогда не знает, какой SQL будет сгенерирован. Отсюда проблемы с производительностью и прочее.

Спорное утверждение... очень даже...
всегда есть возможность

var products = context.CreateQuery<Product>("SELECT VALUE p FROM Products AS p WHERE p.ProductID < 2");

это не T SQL, но...
кроме того можно опять сделать композицию...

var products2 = from p in products 
                        where p.ProductID > 5
                        select p;

В общем то что вы называете неудачной идеей радует глаз очень многим

А>>Таким запутать можно только необразованных программистов которые не знают английского языка. NUST have skill.

YZ>Вот после таких NUST в коде и возникают проблемы с пониманием этого кода.
ой ну конечно

а если я напишу безнес вместо бизнес... это русско говорящего не вгонит в ступор?

вы забываете очень важную вещь...
приложения проектируются. И когда они проектируются то SQL запросам нет места в обработчиках событий так же как и бизнес логике.
Как мы это сделаем в вашей тулзе..? давай те ка по проектируем немного более или менее сложное приложение...

Здравствуйте, Аноним, Вы писали:

А>Это не повод придумывать среду разработки ведь так?

А почему бы и нет? Что в этом плохого? На самом деле это вынужденная мера. Мне нужно, чтобы структура БД и бизнес-логика описывались в одном месте. Только так можно автоматически сгенерировать классы-обвертки ORM. У меня был ещё вариант — встроить этот функционал в VS, однако раз уж у меня есть свой компилятор, зачем мне заморская оболочка? Короче, в WinForms накидать небольшое приложение оказалось проще, чем изучать VS API.

А>всегда есть возможность

А>

А>var products = context.CreateQuery<Product>("SELECT VALUE p FROM Products AS p WHERE p.ProductID < 2");
А>

В этом случае теряется возможность проверки синтаксиса запроса на этапе компиляции.

А>это не T SQL, но...
А>кроме того можно опять сделать композицию...

А>

А>var products2 = from p in products 
А>                        where p.ProductID > 5
А>                        select p;
А>

А>В общем то что вы называете неудачной идеей радует глаз очень многим

Решите задачку: Вызовите функцию YEAR() при помощи LINQ. Например, чтобы получилось так: SELECT * FROM events e WHERE YEAR(e.TimeStart) <> YEAR(e.TimeEnd)
Насчет радует глаз: Что более радует глаз:
SELECT t.f1, t.f2 FROM table t
или
from t in table select new { f1 = t.f1, f2 = t.f2 };

А>ой ну конечно

а если я напишу безнес вместо бизнес... это русско говорящего не вгонит в ступор?

Знаю случай, когда название таблицы для справочника услуг была названа FAVORS. Почему именно так, понятия не имею. Просто слово SERVICES уже использовалось в другой части проекта для справочника служб. Вот вы бы догадались, что FAVORS — это услуги?

А>вы забываете очень важную вещь...
А>приложения проектируются. И когда они проектируются то SQL запросам нет места в обработчиках событий так же как и бизнес логике.
А>Как мы это сделаем в вашей тулзе..? давай те ка по проектируем немного более или менее сложное приложение...

Давайте по-проектируем. В процессе проектирования при обсуждении мы будем называть сущности на русском, так как они названы в ТЗ, или же сражу будем их называть по-английски?

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

YZ>Особенно хочу отметить встроенный язык запросов, для которого автоматически производится типизация.
YZ>Здесь статья, где я попытался рассказать, для чего я её создал. Там же есть видео, где можно посмотреть "Прометей" в действии. "Прометей" можно скачать в моём блоге. Комментарии, обсуждения, советы и критика приветствуются. Заранее всем спасибо.
не касаясь темы актуальности, хотел бы сказать что нет смысла писать свою IDE для нового языка. Вроде 21й век на дворе и можно просто написать плагин к студии. Как сделано например в Немерле

Если же есть новые идеи для IDE, но нет денег на пару миллионов человеко-часов, то лучше писать плагины к студии и-или эклипсу

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

Хочу обратитть Ваше внимание на то, что название Прометей применительно к компютерной программе уже используется (и даже широко известно в узких кругах) — http://www.prometeus.ru/.

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

N>не касаясь темы актуальности, хотел бы сказать что нет смысла писать свою IDE для нового языка. Вроде 21й век на дворе и можно просто написать плагин к студии. Как сделано например в Немерле

Да, Nemerle со своими возможностями по созданию DSL как раз подошёл бы тут.

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

YZ>У меня был ещё вариант — встроить этот функционал в VS, однако раз уж у меня есть свой компилятор, зачем мне заморская оболочка? Короче, в WinForms накидать небольшое приложение оказалось проще, чем изучать VS API.

Когда то, уже сравнительно давно (лет 6 назад) я тоже так думал. Накидал свое приложение буквально за пару месяцев. Но потом система развивалась, требования росли, и стало понятно, что в итоге следует все переписать в виде пакета к VS. Ты вот подумал о поддержке CI? Отладке? Поддержке VCS? Кучи вспомогательного функционала типа редактора XML? И т.д. Объем работ для реализации даже на среднем уровне тех вещей, которые сейчас ожидаемы от IDE очень велик.

YZ>В этом случае теряется возможность проверки синтаксиса запроса на этапе компиляции.

Можешь контроллировать его отдельным проходом в процессе компиляции. Как, к примеру, это делает Code Contracts.

YZ>Решите задачку: Вызовите функцию YEAR() при помощи LINQ. Например, чтобы получилось так: SELECT * FROM events e WHERE YEAR(e.TimeStart) <> YEAR(e.TimeEnd)
В предположении, что DateTime.Year отрабатывает некорректно (я просто не в курсе, как на самом деле обстоит):

[SqlFunction]
public static int Year(this DateTime date) {...}
...
var q =
  from evt in db.Events()
  where evt.TimeStart.Year != evt.TimeEnd.Year()
  select evt;

YZ>Насчет радует глаз: Что более радует глаз:
YZ>SELECT t.f1, t.f2 FROM table t
YZ>или
YZ>from t in table select new { f1 = t.f1, f2 = t.f2 };

Одинаково. А теперь приведи свой эквивалент такого:

var q = from x in xs select x;
if (!name.IsNullOrEmpty())
  q = q.Where(x => x.Name = name);
if (ordered)
{
  q =
    descending
      ? q.OrderBy(x => x.Created)
      : q.OrderBy(x => x.Created);
  if (byVal)
        q = q.ThenBy(x => x.Value);
}
return q.ToList();

	От:	yurik-z
	Дата:	15.01.11 17:22
	Оценка:

	От:	Аноним
	Дата:	15.01.11 18:18
	Оценка:

	От:	1stein
	Дата:	15.01.11 18:26
	Оценка:	1 (1) +12 -2

	От:	elmal
	Дата:	15.01.11 18:43
	Оценка:

	От:	yurik-z
	Дата:	15.01.11 18:55
	Оценка:	-3

От:	Rival	https://twitter.com/#!/red_rival
Дата:	16.01.11 05:24
Оценка:	18 (8) +2

	От:	Niemand
	Дата:	16.01.11 11:45
	Оценка:	1 (1) +1

	От:	Ночной Смотрящий
	Дата:	16.01.11 19:57
	Оценка: