Здравствуйте, Светлояр, Вы писали:
С>Если уж Вы придерживаетесь линии русскоязычного кода попробуйте реализовать не VB-стиль, а Java/C#-стиль — он лаконичнее.
Java и C# предполагает использование фигурных скобок {...} в коде в большом количестве. В русской раскладке клавиатуры такие скобки отсутствуют, придется постоянно переключаться.
K>А можно поподробнее про "свой компилятор"? Он целиком свой? K>А то у меня есть подозрение, что это какая-то нашлепка над компилятором VB.
Компилятор VB не позволяет делать "нашлепки". Мой компилятор не использует никакие сторонние исходные коды. Для работы требуется только функционал .NET 2.0, таким образом прекрасно работает даже в MONO.
YZ>Java и C# предполагает использование фигурных скобок {...} в коде в большом количестве. В русской раскладке клавиатуры такие скобки отсутствуют, придется постоянно переключаться.
Новый язык и названия операторов русскими буквами смущают. Область применения резко сужается т.к. 1.Этот язык ограничен и экзотичен. 2."IDE" становится применима лишь для проектов внутрироссийского использования.
Судя по видео, полученные сборки нужно будет потом использовать в проекте в Visual Studio.
И, получается, что разработчику все равно нужно знать один из стандартных языков программирования .Net.
А если разработчик уже знает один язык, то зачем ему дополнительные заморочки с новым языком в Вашей "IDE"?
И раскладку все равно придется переключать при вызове сгенерированных "IDE" классов из, например, C# проекта (хорошо еще, что Windows можно переключаться одной клавишей).
Рациональнее использовать стандартный язык программирования, а кириллицей, при желании, писать только названия классов, функций, переменных и таблиц в БД.
Но это только критика внешней стороны дела. Оправданность реализованного Вами подхода в целом под большим сомнением. Допускаю его оправданность лишь для написания каким-то образом клиентских расширений, но про это нигде не увидел.
Лирическое отступление.
Сразу вспомнились русифицированные версии языков программирования, возникшие на заре советской компьютеризации — язык для ПЭВМ "Искра-1256" (типа "Бейсик") и язык РАПИРА для БЭСМ-6, Агата, Ямахи и ЕСки.
P.S.
Вообще, работа у Вас проделана немаленькая. Один лишь только самописный компилятор чего стоит. Очень полезный опыт. И спасибо Вам за повод подпитать темы для обсуждений и даже маленьких "холиваров".
Еще одно лирическое отступление.
Нам повезло, что мы программируем НЕ русскими словами.
У нас есть отдельно английские слова и термины для техники, и отдельно русские слова для живого общения.
Английский язык более формален и лучше подходит для технических предметов (пример: попробуйте родными короткими словами перевести interface и render, перевести разными словами compile и collect?).
Русский более образен и многооттеночен. Например, слово "жёлтенький" сразу сколько информации несет — один, маленький, мужского рода, жёлтого цвета. Английский перевод- просто "yellow" — кроме цвета больше ничего.
Здравствуйте, vecs, Вы писали:
V>Еще одно лирическое отступление. V>Нам повезло, что мы программируем НЕ русскими словами. V>У нас есть отдельно английские слова и термины для техники, и отдельно русские слова для живого общения. V>Английский язык более формален и лучше подходит для технических предметов (пример: попробуйте родными короткими словами перевести interface и render, перевести разными словами compile и collect?). V>Русский более образен и многооттеночен. Например, слово "жёлтенький" сразу сколько информации несет — один, маленький, мужского рода, жёлтого цвета. Английский перевод- просто "yellow" — кроме цвета больше ничего.
Не совсем. Когда читаешь текст программ, то на русском одним взглядом больше текста воспринимаешь более понятны методы, поля, свойства. Все же легче читать и писать на чем думаешь, а многословность не есть плохо мы же не воюем, а более информативные поля дают больше понимания. Уже давно прошли времена когда переменный были из одной буквы. А когда есть инлеллисенс печатать становится не так много.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, yurik-z, Вы писали:
YZ>Всем привет. Хочу рассказать о новой среде разработки бизнес-приложений. Называется "Прометей". Если сказать коротко, то это среда разработки для .NET, имеющая собственный язык программирования на основе синтаксиса Visual Basic.NET, расширенного русскоязычными ключевыми словами, собственный компилятор для CLR. Обладает функционалом ORM, а также способна автоматически поддерживать структуру базы данных в соответствии с логической моделью сущностей. YZ>Особенно хочу отметить встроенный язык запросов, для которого автоматически производится типизация. YZ>Здесь статья, где я попытался рассказать, для чего я её создал. Там же есть видео, где можно посмотреть "Прометей" в действии. "Прометей" можно скачать в моём блоге. Комментарии, обсуждения, советы и критика приветствуются. Заранее всем спасибо.
Здравствуйте, vecs, Вы писали:
V>В частности, там очень симпатично реализован подход, называемый "Code-First"- cущности описываются в виде классов, а ORM сама обновляет структуру БД
Я категорически против такого подхода. Нужно наоборот.
------------
В знакомых мне предметных областях приходится долго и нудно пректировать БД и обмен данными, на это уходит до четверти, или даже трети времени. После чего (или паралельно с этим) надо проектировать UI, и в процессе уточнять задачу и корректировать БД. Потом браться за проектирование софтины.
При этом БД проектируется очтасти с помощью бумажки и ручки, отчасти в Visio (или чём-то подобном).
При сопровождении чаще всего в первую очередь нужно ответить на вопросы типа: где взять данные, как их изменить, при том так, чтобы ничего не разрушить.
(кстати, перестройка индексов в живой БД может занять гораздо более 8-ми часов)
Всё сказанное выше — личное мнение, если не указано обратное.
V>>В частности, там очень симпатично реализован подход, называемый "Code-First"- cущности описываются в виде классов, а ORM сама обновляет структуру БД
Ф>Я категорически против такого подхода. Нужно наоборот.
Ну а я и не категорически "За".
Согласен, что этот подход не всегда оптимален для системы в целом.
Например, "Code-First" хорош в системах, где логика первична, а данные вторичны. Это когда я хочу описывать сущности, их отношения и наследование, описывать их методы и не задумываться о том, как они сохраняются в БД и достаются оттуда (да еще и БД-независимо). Простейший путь — описывать классы в коде.
Если потребуется визуальное представление модели (для документирования системы), то можно воспользоваться утилитами, которые генерируют его на основе кода или конечной структуры БД.
Очень удобно то, что вся модель описывается в одном единственном месте и сопровождать ее чрезвычайно просто (там же в коде для особых случаев можно поставить атрибуты-подсказки для ORM, чтобы тот генерировал дополнительные индексы в БД и дооптимизировал запросы). И с обновлением структуры БД при выходе новой версии нет заморочек (не надо пакет скриптов готовить).
Другое дело, когда первичны данные. Это когда есть БД с которой работает куча разного софта, в т.ч. чужого и при этом в БД требуется наличие всякой дополнительной общедоступной логики (хранимые процедуры, представления и т.д.). И пускай открытость системы на уровне БД уже не комильфо, однако от систем с историей никуда не деться.
Разрабатывать программу "Database First" неудобнее, т.к. сущность описывается последовательно нескольких местах: 1)Таблицы и индексы в БД 2)Атрибуты в ORM 3)Класс-расширение (partial) для сгенерированного ORM класса. А иногда перед (1) еще и какое-нибудь UML-проектирование. Плюс надо сгенерировать SQL-скрипт изменений. Это ж сколько шагов надо пройти, чтобы добавить всего одно поле? А при подходе "Code-First" я просто добавлю в свой класс строчку:
..
[Field(Length = 100)]
public string Text { get; set; }
..
В общем, для разных случаев оптимальны разные подходы. И хорошо, когда ORM красиво поддерживает разные варианты работы.
Тут главное не использовать лишь один подход — бездумный.
И не желательно делать так, как рассказано про IDE Прометей: "Недолго думая, я засучил рукава и начал писать программный код". Предпочтительнее начинать дело рассудив, помолясь и перекрестясь.
Здравствуйте, vecs, Вы писали:
V>Другое дело, когда первичны данные. Это когда есть БД с которой работает куча разного софта, в т.ч. чужого и при этом в БД требуется наличие всякой дополнительной общедоступной логики (хранимые процедуры, представления и т.д.). И пускай открытость системы на уровне БД уже не комильфо, однако от систем с историей никуда не деться.
Куча разного софта чатстенько образуется потом, т.е. спустя некоторое время. И необходимость оптимизировать структуру БД и индексы частенько людям приходит в голову тогда, когда это уже оказывается очень дорого.
хотя... платит ведь всё равно заказчик — его проблемы
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, vecs, Вы писали:
V>В частности, там очень симпатично реализован подход, называемый "Code-First"- cущности описываются в виде классов, а ORM сама обновляет структуру БД разными способами
Здравствуйте, Фанатик, Вы писали:
Ф>Я категорически против такого подхода. Нужно наоборот.
EF Code First это не подход, это просто способ описать структуру БД при помощи метаданных нетовских классов (при этом экземпляры этих классов могут никогда не создаваться вовсе). Ради того чтобы не писать одно и то же два раза — в DDL-скриптах и в POCO-классах. А уж как это использовать — дело программиста.
Так что сама идея здравая. Реализация вот при этом весьма посредственная.
В связи с вопросами не могу не удержаться от апологии DO.
V>При "Code First" ORM сама обновляет структуру БД разными способами НС>Она не обновляет. Она только с нуля создает.
X-tensive DataObjects структуру обновляет, причем в разных режимах (может и с нуля пересоздать, если захотите).
НС>EF Code First это не подход, это просто способ описать структуру БД...Реализация вот при этом весьма посредственная.
Про EF ничего не могу сказать- говорил про DO. В EF только-только начали "Code First" воплощать, только-только созрели. В то время, как в DO уже зрелая реализация.
Кажись, мы ушли от предмета. По ORM-мам надо другой разговор затевать.
Если автор темы критикой IDE удовлетворен, то надо закругляться.
Здравствуйте, aloch, Вы писали:
A>В multitran.ru:
A> общ. жёлтый цвет; желтизна; желток; человек с жёлтой кожей; жёлтая, бульварная газета; жёлтая лихорадка; карантинный флаг; подлость A> амер., сл. мулатка; квартеронка; негритянка со светлой кожей A> биол. краситель жёлтого цвета A> дип. бульварная газета; жёлтая газета A> Макаров желтая, бульваhная газета A> разг. трусость A> редк. мулат A> сл. золотые наручные часы; масло; светлокожий негр (чаще негритянка) A> тех. жёлтая краска; жёлтый пигмент A> фитопатол. желтуха A> энт. желтушка; желтушка (Colias)
Он прав, копипастом ты только доказал его правоту.
Посмотри, можно отбросить всё, кроме "общ." Всё остальное это арго или бред. Под словом "жёлтый" мы тоже китайца можем иметь в виду, семантика может быть какой угодно, но вот только сленг имеет мало общего с реальным миром. Словоформа же "жёлтенький" определяет сразу пол и имеет суффикс "еньк" с ласкательным значением. В английском варианте ничего этого нет. Программирование — это язык команд, для команд нежелательна многозначность и громоздкость. Поэтому английский больше подходит из-за краткости слов и меньшей однозначности.
A>Еще скажи, что в английском (кроме фак) мата нет.
Смотря с чем сравнивать и что считать матом. Прямого аналога русского мата в английском нет.
Фраза эта Гоблина. И смысл её несколько иной.
Самый точный аналог "жёлтенького" это "yellowish thing" или "yellow thingy". Только опять-таки значение русского точнее ибо обратный перевод на русский может быть "жёлтенькая", "жёлтенький", "жёлтенькое" или вообще "жёлтенькая штука".
«История жизни – это, по существу, развитие сознания, которое завуалировано морфологией.» Пьер Тейяр де Шарден
Здравствуйте, Rival, Вы писали:
R>Программирование — это язык команд, для команд нежелательна многозначность и громоздкость. Поэтому английский больше подходит из-за краткости слов и меньшей однозначности.
+1. Единственное, что более менее серьезно анноит — недоформализованное образование множественного числа от единственного (много исключений, мутноватые правила при наличии нескольких слов). Впрочем, в русском с этим все намного печальнее.
В общ. у yellow, "желтый цвет" и "подлость". А ты писал — "yellow — только цвет".
Английский яхык известен тем, что одно слово может иметь множество значаний, зачастую понятных толко из контекста. В русском такие слова тоже есть (коса и т.д.), но в английском их гораздо больше.
Посмотри значения слов switch (хлыст, переключатель (понятно, и то и другое — щелкает)), case (случай, чемодан), throw (бросок, шарф), out (недостаток, выход), lock (локон, замок) и т.д.
Попробуйте найти ещё обратный перевод слова подлость, чтобы там было "yellow".
Ошибка понятна? Хотя вина тут не ваша, словарь дурацкий.
A>Английский яхык известен тем, что одно слово может иметь множество значаний, зачастую понятных толко из контекста. В русском такие слова тоже есть (коса и т.д.), но в английском их гораздо больше.
Сударь, ну что вы в самом деле. "yellow" и подлость — это слэнг. Вы понимаете различие между слэнгом и омонимами? Я ни разу не встречал такого употребления этого слова. Это как "духовка" — попа. Вы хоть примерно понимаете какое количество значений можно логически связать с другими? Между прочим, знаете значение фразы "do russian"?
>В русском такие слова тоже есть (коса и т.д.), но в английском их гораздо больше.
Неужели есть? А знаете почему? Догадываетесь? Ладно упустим. Знаете какой вывод? По очевидными причинам омонимы редко пересекаются в областях применения. Английский лишён артиклей, мало словоформ, поэтому в качестве языка программирования он намного более предпочтительнее чем русский.
A>Посмотри значения слов switch (хлыст, переключатель (понятно, и то и другое — щелкает)), case (случай, чемодан), throw (бросок, шарф), out (недостаток, выход), lock (локон, замок) и т.д.
Теперь подумайте над семантическим значением. Сильно отличное не так ли? Теперь посчитайте количество букв в английских словах и русских. Задайте себе вопрос, как часто вы за "case" будете принимать чемодан.
Короткие корни+отсутствие артиклей+семантическая ясность = хорошо для описания алгоритмов.
Ошибки понятны?
«История жизни – это, по существу, развитие сознания, которое завуалировано морфологией.» Пьер Тейяр де Шарден
Здравствуйте, Rival, Вы писали:
R>В топку такой словарь. Какой-то "умник" решил выпендриться.
Конечно, в том что даже у "yellow" оказалось много значений виноват словарь. Между прочим словарь очень полезный (его используют многие професиональные переводчики). Слово "умником" не добавлено — иначе там бы рядом в скобках ссылка бы была ну "умника". И обратный перевод там есть.
При этом в lingvo оно помечено как разг. — т.е. разговорное, но ведь это не сленг? Т.е. слово yellow в качестве "трусливый" можно услышать не только от бандита или панка, но и в принципе от любого обычного человека на улице в простом разговоре.
Электричка — это сленг? Или есть человек, говоряший по русски и не понимающий, что это значит?
> Английский лишён артиклей,
Артикли — The, A. Это конечно не Der, Die, Das, Ein, но вот в литературном русском артиклей нет.
> мало словоформ, поэтому в качестве языка программирования он намного более предпочтительнее чем русский.
Английский в качестве языка программирования используется только в COBOL. Во всех остальных языках программирования (известных мне) используются ключевые слова, правда в основном взятые из английского языка, в том числе и по историческим причинам ("кибернетика — продажная девка имериализма", после этого она обиделась и долго не говорила по русски ). При этом эти слова могут иметь разные значения, но в языке программирования их суть всегда одна.
> Задайте себе вопрос, как часто вы за "case" будете принимать чемодан.
Если написано просто "case" — я (и никто, кроме написавшего) не буду знать что это значит. В связанном тексте — по контексту. В программе на C# я это не буду воспринамать ни как чемодан, ни как случай, а как ключевое слово, означающее метку в операторе switch.
R>Короткие корни+отсутствие артиклей+семантическая ясность = хорошо для описания алгоритмов.
Здравствуйте, yurik-z, Вы писали:
YZ>Особенно хочу отметить встроенный язык запросов, для которого автоматически производится типизация. YZ>Здесь статья, где я попытался рассказать, для чего я её создал. Там же есть видео, где можно посмотреть "Прометей" в действии. "Прометей" можно скачать в моём блоге. Комментарии, обсуждения, советы и критика приветствуются. Заранее всем спасибо.
НачалоФункции, КонецФункции...
Зачем все это, если уже есть Превед
.jpg)
