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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

R>Это вообще к чему? Какой посыл от этой фразы в контексте беседы?

Посыл в том, что в словаре (и в lingvo и в multitran) Yellow/подлость помечено не как сленговое, а как разговорное. И что между этими понятиями есть разница.

R>Вы специально это делаете? Начинаете извращать смысл фраз или находить в них особый смысл?

Вы написали "Английский лишён ..., поэтому в качестве языка программирования он намного более предпочтительнее чем русский".

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

Вам настолько нравится английский, что вместо "в именах" Вы пишете "в нейминге"

(при этом букв на целых две больше!)

На счет наименования полей и методов — в том же 1С как Вы думаете, почему используется русский язык? Или вместо русских слов разработчики (очень часто английского вообще не знающие — такая у них там специфика) должны искать в словарях (полных амонимов!) переводы для, например, ПросроченныеСчетаПоставщиков т.п.? А если выполняется автоматизация, скажем, строительства — нужно учить новые английские слова. Поэтому все нормальные разработчики решений для РФ на 1С будут использовать русские названия полей (во многих фирмах — это стандарт). При этом, если ключевые слова продолжать писать по английски, а имена — по русски, возникает проблема постоянного переключения раскладки клавиатуры RUS/ENG. Между прочем, в языке 1С можно использовать и англиские ключевые слова, но что то никто этого не делает.

R>У меня есть подозрение, что не только вы не сможете определить значение омонима если его написать как отдельное слово. Отсюда получается, что вы со мной согласны. Слова на английском короче, а семантический смысл явен.

Короче — да. На счет смысла — для ключевых слов C# он "явен" только в программе на C#. Если в программе на 1С использовать русские ключевые слова, то их смысл будет не менее явен в этой программе.

R>Ну да, как и трусы через голову.

Т.е. если вместо IF писать ЕСЛИ, это трусы через голову? Не кажется Вам, что это слишком?

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

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

R>Всего доброго.

Пока. Учи английский.

YZ>Java и C# предполагает использование фигурных скобок {...} в коде в большом количестве. В русской раскладке клавиатуры такие скобки отсутствуют, придется постоянно переключаться.

Новый язык и названия операторов русскими буквами смущают. Область применения резко сужается т.к. 1.Этот язык ограничен и экзотичен. 2."IDE" становится применима лишь для проектов внутрироссийского использования.
Судя по видео, полученные сборки нужно будет потом использовать в проекте в Visual Studio.
И, получается, что разработчику все равно нужно знать один из стандартных языков программирования .Net.
А если разработчик уже знает один язык, то зачем ему дополнительные заморочки с новым языком в Вашей "IDE"?
И раскладку все равно придется переключать при вызове сгенерированных "IDE" классов из, например, C# проекта (хорошо еще, что Windows можно переключаться одной клавишей).
Рациональнее использовать стандартный язык программирования, а кириллицей, при желании, писать только названия классов, функций, переменных и таблиц в БД.
Но это только критика внешней стороны дела. Оправданность реализованного Вами подхода в целом под большим сомнением. Допускаю его оправданность лишь для написания каким-то образом клиентских расширений, но про это нигде не увидел.

Лирическое отступление.
Сразу вспомнились русифицированные версии языков программирования, возникшие на заре советской компьютеризации — язык для ПЭВМ "Искра-1256" (типа "Бейсик") и язык РАПИРА для БЭСМ-6, Агата, Ямахи и ЕСки.

P.S.

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

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

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

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

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

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

? Знакомо

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

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

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

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

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

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

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

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

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

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

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

R>Здравствуйте, aloch, Вы писали:
R>Про yellow уже ничего не слышно. Осталось только это.

Про Yellow я все уже сказан ранее. Но Вы уверены что "разговорное слово" (о чем лингвисты указали в двух словарях) = сленг, на основании чего сказали что "подлость" — это редкое значение слова yeloow, известное крайне малому количеству носителей языка. Свои выводы вы подтвердили тем, что сами этого никогда не слышали. При этом вы написали, что в английском нет суффиксов (не их меньше, чем в русском, а просто — нет), чем подтвердили глубокое знание предмета.

R>Тот самый первый тезис следует читать так: "В русском языке по сравнению с английским намного более богатое словообразование со многими нюансами, что порождает избыточную нагрузку". Более богатое словообразование выливается в большую длинну слов и, на мой взгляд, в программировании это избыточно.

Английские слова в большинстве случаев короче, но словообразование там очень богатое, со многими нюансами (называемыми граматикорй), Вы просто этого не знаете.

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

A>Про Yellow я все уже сказан ранее. Но Вы уверены что "разговорное слово" (о чем лингвисты указали в двух словарях) = сленг, на основании чего сказали что "подлость" — это редкое значение слова yeloow, известное крайне малому количеству носителей языка. Свои выводы вы подтвердили тем, что сами этого никогда не слышали. При этом вы написали, что в английском нет суффиксов (не их меньше, чем в русском, а просто — нет), чем подтвердили глубокое знание предмета.

Составители словарей ошибаются. Они обычные люди. Там ещё и не такое можно встретить. Вас не смутил тот факт, что в других словарях такого нет или значения для yellow в разг. совсем другие? Для того, чтобы сказать, что идёт дождь не нужно быть метеорологом.
A>чем подтвердили глубокое знание предмета.
Про суффиксы я вам уже объяснил, поэтому не занимайтесь троллингом — сливаете сами себя и всю беседу.

A>Английские слова в большинстве случаев короче, но словообразование там очень богатое, со многими нюансами (называемыми граматикорй), Вы просто этого не знаете.

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

Ваша аргументация как всегда поразительна:
A>Еще скажи, что в английском (кроме фак) мата нет.
A>Так что не так все просто там, как кажется.
A>Вы просто этого не знаете.

Осталось только ещё по третьему разу написать про суффиксы, иероглифы и COBOL.

Зря я даже начинал.
Всего доброго.

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

? Знакомо

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

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

Здравствуйте, 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 запросам нет места в обработчиках событий так же как и бизнес логике.
А>Как мы это сделаем в вашей тулзе..? давай те ка по проектируем немного более или менее сложное приложение...

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

Здравствуйте, 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, Вы писали:

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

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

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

lightswitch видел?

YZ>Ну почему, если русский синтаксис, то сразу 1С? Писать на русском – это просто хорошая идея для разработки отечественного ПО, особенно в прикладной среде, такой как бухгалтерия, учет и прочее.
Бредовая идея. Некий финский студент писал ядро ОС, не зная при этом английского языка, но писал при этом на английском, а не транслите.
Студента кстати Линус Торвальдс звали.

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

А если мультиязычное приложение?

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

YZ>>Ну почему, если русский синтаксис, то сразу 1С? Писать на русском – это просто хорошая идея для разработки отечественного ПО, особенно в прикладной среде, такой как бухгалтерия, учет и прочее.
G>Бредовая идея. Некий финский студент писал ядро ОС, не зная при этом английского языка, но писал при этом на английском, а не транслите.
G>Студента кстати Линус Торвальдс звали.

Он не знал английский? Откуда дровишки?

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

L>Он не знал английский? Откуда дровишки?

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

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

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

так вот кто затягивает все проекты!!11

Здравствуйте, Ночной Смотрящий, Вы писали:

L>>Он не знал английский? Откуда дровишки?

НС>Особенно в свете того, что, по признанию самого Торвальдса, на написание линуха его вдохновила книжка Таненбаума, которая, между прочим, была на английском.

он в английском варианте читал или таки перевод на финский?

Оффтоп: у данного Прометея можно выклевать печень? И если да, то как часто это можно делать?

Чувак старался, а вы... вы все злобные и жестокие

http://www.rsdn.ru/forum/flame.comp/4070578.1.aspx

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

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

Блин. Вы умудрились взять самое худшее из 1С(русскоязычный код и кошмарный синтаксис). ORM это хорошо, но само по себе это не киллер-фича.
Ну и да, средств работы с кодом никаких(неудивительно, для одного человека написать это сложно) — после современных средств разработки вызывает такие же рвотные позывы, как и 1С в силу своей совершенной деревянности и беспомошности.

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

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

Ценный вклад в борьбу с легендарным синтаксическим оверхедом

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

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

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

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

Вот как раз примочка для студии могла бы иметь хотя-бы какой-то смысл.
А так — ваша IDE ничего не умеет, кроме как создавать объекты и связывать их с БД. В таком виде оно нахрен никому не упало.

Что-то никто не поддержал вашей идеи. К слову, еще не разу не видел, чтобы кто-то здесь засветил свой проект для оценки и получил бы кучу отзывов типа "Ух ты!". Но критика зачастую вполне адекватная.
Вы обращаете больше внимания на то что сделано и как это реализовано. А ведь главный вопрос для здешних читателей- зачем это надо и не изобретение ли это велосипеда. А если это велосипед, то чем он лучше других?

Вот например,
YZ>Мне нужно, чтобы структура БД и бизнес-логика описывались в одном месте. Только так можно автоматически сгенерировать классы-обвертки ORM.
Я поддерживаю эту мысль. Но, наверное, тут можно посмотреть существующие ORM.
Моя любимая — DataObjects. И она реализует то, что нужно и даже больше.
В частности, там очень симпатично реализован подход, называемый "Code-First"- cущности описываются в виде классов, а ORM сама обновляет структуру БД разными способами, если что-то изменилось в коде. В большинстве случаев описывать сущности с их логикой удобнее всего в .Net классах (ведь именно для этого они и приспособлены как нельзя лучше), а не в БД или XML.

По поводу русского языка в коде.
Если уж это очень надо, то никто не запрещает называть классы, методы и переменные русскими буквами.
И таблицы в БД тоже.

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

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

До тех пор пока ты не занимаешься бухучетом или банковской автоматизацией. Переведи, на английский следующие термины:

субконто

плоскость учета

красное сальдо

книга учета доходов-расходов

приведенный остаток в фактической плоскости учета

Затем закрой перевод бумажкой и попроси своего тестера перевести. Закрой перевод бумажкой и попроси своего бухгалтера перевести. Убери бумажку и сравни переводы.

Здравствуйте, Денис, Вы писали:
Д>Чувак старался, а вы... вы все злобные и жестокие

http://www.rsdn.ru/forum/flame.comp/4070578.1.aspx

Это всё начинается с того момента когда нам сообщают что Деда Мороза нет и что на эту машинку в витрине не хватит денег. Дальше в жизни идёт сплошная жесткость!

Кочетков по ссылке всё правильно написал, но тут совсем другое. Конечно, в плане личных заслуг, разработка своей собственной среды разработки это замечательно. Вообще, похвально стремление делать свои велосипеды, одноко только как образовательный процесс, но не более. Также как и желание решать кроссворды, а не пить пиво. Другое дело, когда ты свою картину хочешь кому-нибудь всучить, чтобы он повесил себе это на стену.

Надо разделять критерии оценки для похвалы. Одно дело ждать похвалы за то, что вы просто что-то такое умеете делать. Это дело друзей и родных. Другое дело получать похвалу за то, что действительно представляет собой нечто особенное, не обладает особыми недостатками и чему нет массы альтернатив.

В данном случае критика довольна очевидна и конструктивна. Можно представить, что бы было, если бы на форумах была ярко выраженная позитивная среда. Каждый месяц врывался бы человек и произносил что-то типа: "Здравствуйте, я сделал свой язык на основе КОБОЛ, только на монгольском, для более удобного использования в отчётности Бурятского автономного округа" и его заваливали бы криками "Вау!", "Класс!", "Круто!", "Ответь в личку! Хочу от тебя детей". Можно было бы похвалить такое? Конечно. Можно было бы. Человек ведь вложил свой труд! Но не обладает ли такой продукт заметными недостатками? Есть ли альтернативы? Перевешивают ли имеющиеся плюсы эти недостатки? Может лучше жестокая критика, чем позитивное сюсюкание. Особенно когда критика конструктивна. Ведь ругают всех: Эпл, Майкрософт, википедию, провайдера и т.д. И там ведь тоже не дураки сидят, и ошибаются бывает частенько.

Возможно, куда разумнее было бы, скажем, помочь проекту Nemerle, сделав этот язык на его основе. Заодно им можно было бы помочь с интеграцией и остальным. Главное помнить, что неверный вектор реализации пассионарности может убить энтузиазм. Как в принципе и негативные отклики... Бугага

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

M>До тех пор пока ты не занимаешься бухучетом или банковской автоматизацией. Переведи, на английский следующие термины:
M> субконто
M> плоскость учета
M> красное сальдо
M> книга учета доходов-расходов
M> приведенный остаток в фактической плоскости учета

M>Затем закрой перевод бумажкой и попроси своего тестера перевести. Закрой перевод бумажкой и попроси своего бухгалтера перевести. Убери бумажку и сравни переводы.

Да, при этом светить им в лицо фонариком и натравливать бойцовских собак.

А что насчёт xml комментариев? Неужели нельзя вынести все сложные термины в единую памятку?
Только ради группы терминов нужно перейти на русский? Бухгалтерия какая-то особенная область? А в других областях все термины всегда совпадают? Мне казалось трудности перевода есть везде.

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

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

M>>До тех пор пока ты не занимаешься бухучетом или банковской автоматизацией. Переведи, на английский следующие термины:
M>> субконто
M>> плоскость учета
M>> красное сальдо
M>> книга учета доходов-расходов
M>> приведенный остаток в фактической плоскости учета

M>>Затем закрой перевод бумажкой и попроси своего тестера перевести. Закрой перевод бумажкой и попроси своего бухгалтера перевести. Убери бумажку и сравни переводы.

R>Да, при этом светить им в лицо фонариком и натравливать бойцовских собак.

R>А что насчёт xml комментариев? Неужели нельзя вынести все сложные термины в единую памятку?
R>Только ради группы терминов нужно перейти на русский? Бухгалтерия какая-то особенная область? А в других областях все термины всегда совпадают? Мне казалось трудности перевода есть везде.
Мне лично очень удобно писать на русском в 1С, так и на C# применяю русские символы. Правда приходится чаше клавиатуру переключсать. И не болит голова о транслите или преводе. Писать приходится оочень много.
А вот идея прикрутить компилятор к аля 1С очень радует Это одно из узких мест 1С при обработке больших объемов где не везде и SQL применим. Так что идея перспективна, правда тягаться с существующими решениями 1С сложно.

написанные в вашей среде? Или это очередной немерл?

Здравствуйте, yurik-z!

Разработка интересная! Я надеюсь, Вам хватит сил довести её до хорошего законченного продукта.
Будущее за высокоуровневыми средствами разработки бизнес-приложений.

Рекомендую обратить внимание на отклики касательно кода.
Если уж Вы придерживаетесь линии русскоязычного кода попробуйте реализовать не VB-стиль, а Java/C#-стиль — он лаконичнее.

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

F>он в английском варианте читал или таки перевод на финский?

Вроде бы на английском. Да и последовавший известный срач с автором точно на английском был.

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

V>Что-то никто не поддержал вашей идеи. К слову, еще не разу не видел, чтобы кто-то здесь засветил свой проект для оценки и получил бы кучу отзывов типа "Ух ты!".

Ну так тут весьма высокий уровень тусовки, чтобы заслужить похвалу, надо, чтобы проект обладал чем то полезным и уникальным. А таких проектов вообще очень немного. Из примеров вспоминается BLT.

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

А можно поподробнее про "свой компилятор"? Он целиком свой?

А то у меня есть подозрение, что это какая-то нашлепка над компилятором VB.

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

С>Если уж Вы придерживаетесь линии русскоязычного кода попробуйте реализовать не VB-стиль, а Java/C#-стиль — он лаконичнее.

Java и C# предполагает использование фигурных скобок {...} в коде в большом количестве. В русской раскладке клавиатуры такие скобки отсутствуют, придется постоянно переключаться.

K>А можно поподробнее про "свой компилятор"? Он целиком свой?
K>А то у меня есть подозрение, что это какая-то нашлепка над компилятором VB.

Компилятор VB не позволяет делать "нашлепки". Мой компилятор не использует никакие сторонние исходные коды. Для работы требуется только функционал .NET 2.0, таким образом прекрасно работает даже в MONO.

Еще одно лирическое отступление.
Нам повезло, что мы программируем НЕ русскими словами.
У нас есть отдельно английские слова и термины для техники, и отдельно русские слова для живого общения.
Английский язык более формален и лучше подходит для технических предметов (пример: попробуйте родными короткими словами перевести interface и render, перевести разными словами compile и collect?).
Русский более образен и многооттеночен. Например, слово "жёлтенький" сразу сколько информации несет — один, маленький, мужского рода, жёлтого цвета. Английский перевод- просто "yellow" — кроме цвета больше ничего.

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

V>Еще одно лирическое отступление.
V>Нам повезло, что мы программируем НЕ русскими словами.
V>У нас есть отдельно английские слова и термины для техники, и отдельно русские слова для живого общения.
V>Английский язык более формален и лучше подходит для технических предметов (пример: попробуйте родными короткими словами перевести interface и render, перевести разными словами compile и collect?).
V>Русский более образен и многооттеночен. Например, слово "жёлтенький" сразу сколько информации несет — один, маленький, мужского рода, жёлтого цвета. Английский перевод- просто "yellow" — кроме цвета больше ничего.
Не совсем. Когда читаешь текст программ, то на русском одним взглядом больше текста воспринимаешь более понятны методы, поля, свойства. Все же легче читать и писать на чем думаешь, а многословность не есть плохо мы же не воюем, а более информативные поля дают больше понимания. Уже давно прошли времена когда переменный были из одной буквы. А когда есть инлеллисенс печатать становится не так много.

Здравствуйте, 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, Вы писали:

> Английский перевод- просто "yellow" — кроме цвета больше ничего.

ну да...

В multitran.ru:

общ. жёлтый цвет; желтизна; желток; человек с жёлтой кожей; жёлтая, бульварная газета; жёлтая лихорадка; карантинный флаг; подлость
амер., сл. мулатка; квартеронка; негритянка со светлой кожей
биол. краситель жёлтого цвета
дип. бульварная газета; жёлтая газета
Макаров желтая, бульваhная газета
разг. трусость
редк. мулат
сл. золотые наручные часы; масло; светлокожий негр (чаще негритянка)
тех. жёлтая краска; жёлтый пигмент
фитопатол. желтуха
энт. желтушка; желтушка (Colias)

Еще скажи, что в английском (кроме фак) мата нет.

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

Ф>Я категорически против такого подхода. Нужно наоборот.

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. Единственное, что более менее серьезно анноит — недоформализованное образование множественного числа от единственного (много исключений, мутноватые правила при наличии нескольких слов). Впрочем, в русском с этим все намного печальнее.

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

В общ. у yellow, "желтый цвет" и "подлость". А ты писал — "yellow — только цвет".

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

Посмотри значения слов switch (хлыст, переключатель (понятно, и то и другое — щелкает)), case (случай, чемодан), throw (бросок, шарф), out (недостаток, выход), lock (локон, замок) и т.д.

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

A>В общ. у yellow, "желтый цвет" и "подлость". А ты писал — "yellow — только цвет".

В топку такой словарь. Какой-то "умник" решил выпендриться.
Взгляните сюда:
http://lingvo.abbyyonline.com/en/ru-en/yellow
Все эти "продажный" и "боязливый" это разг. т.е. слэнг.

Попробуйте найти ещё обратный перевод слова подлость, чтобы там было "yellow".

Ошибка понятна? Хотя вина тут не ваша, словарь дурацкий.

A>Английский яхык известен тем, что одно слово может иметь множество значаний, зачастую понятных толко из контекста. В русском такие слова тоже есть (коса и т.д.), но в английском их гораздо больше.
Сударь, ну что вы в самом деле. "yellow" и подлость — это слэнг. Вы понимаете различие между слэнгом и омонимами? Я ни разу не встречал такого употребления этого слова. Это как "духовка" — попа. Вы хоть примерно понимаете какое количество значений можно логически связать с другими? Между прочим, знаете значение фразы "do russian"?

>В русском такие слова тоже есть (коса и т.д.), но в английском их гораздо больше.
Неужели есть? А знаете почему? Догадываетесь? Ладно упустим. Знаете какой вывод? По очевидными причинам омонимы редко пересекаются в областях применения. Английский лишён артиклей, мало словоформ, поэтому в качестве языка программирования он намного более предпочтительнее чем русский.

A>Посмотри значения слов switch (хлыст, переключатель (понятно, и то и другое — щелкает)), case (случай, чемодан), throw (бросок, шарф), out (недостаток, выход), lock (локон, замок) и т.д.
Теперь подумайте над семантическим значением. Сильно отличное не так ли? Теперь посчитайте количество букв в английских словах и русских. Задайте себе вопрос, как часто вы за "case" будете принимать чемодан.

Короткие корни+отсутствие артиклей+семантическая ясность = хорошо для описания алгоритмов.

Ошибки понятны?

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

R>В топку такой словарь. Какой-то "умник" решил выпендриться.

Конечно, в том что даже у "yellow" оказалось много значений виноват словарь. Между прочим словарь очень полезный (его используют многие професиональные переводчики). Слово "умником" не добавлено — иначе там бы рядом в скобках ссылка бы была ну "умника". И обратный перевод там есть.

При этом в lingvo оно помечено как разг. — т.е. разговорное, но ведь это не сленг? Т.е. слово yellow в качестве "трусливый" можно услышать не только от бандита или панка, но и в принципе от любого обычного человека на улице в простом разговоре.

см.

http://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B7%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%D0%BD%D1%8B%D0%B9_%D1%81%D1%82%D0%B8%D0%BB%D1%8C

например, в том же лингво — http://lingvo.abbyyonline.com/ru/en-ru/%D1%8D%D0%BB%D0%B5%D0%BA%D1%82%D1%80%D0%B8%D1%87%D0%BA%D0%B0

Электричка — это сленг? Или есть человек, говоряший по русски и не понимающий, что это значит?

> Английский лишён артиклей,

Артикли — The, A. Это конечно не Der, Die, Das, Ein, но вот в литературном русском артиклей нет.

> мало словоформ, поэтому в качестве языка программирования он намного более предпочтительнее чем русский.

Английский в качестве языка программирования используется только в COBOL. Во всех остальных языках программирования (известных мне) используются ключевые слова, правда в основном взятые из английского языка, в том числе и по историческим причинам ("кибернетика — продажная девка имериализма", после этого она обиделась и долго не говорила по русски

). При этом эти слова могут иметь разные значения, но в языке программирования их суть всегда одна.

> Задайте себе вопрос, как часто вы за "case" будете принимать чемодан.

Если написано просто "case" — я (и никто, кроме написавшего) не буду знать что это значит. В связанном тексте — по контексту. В программе на C# я это не буду воспринамать ни как чемодан, ни как случай, а как ключевое слово, означающее метку в операторе switch.

R>Короткие корни+отсутствие артиклей+семантическая ясность = хорошо для описания алгоритмов.

Это просто дело привычки.

R>Ошибки понятны?

Нет

Зачем все это, если уже есть Превед

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

A>Конечно, в том что даже у "yellow" оказалось много значений виноват словарь. Между прочим словарь очень полезный (его используют многие професиональные переводчики). Слово "умником" не добавлено — иначе там бы рядом в скобках ссылка бы была ну "умника". И обратный перевод там есть.

A>При этом в lingvo оно помечено как разг. — т.е. разговорное, но ведь это не сленг?

Сленг (от англ. slang) — терминологическое поле, набор особых слов или новых значений уже существующих слов, употребляемых в различных человеческих объединениях (профессиональных, социальных, возрастных групп).

Заметим, сленг — это терминологическое поле, а разговорная речь — это разновидность устной литературной речи.
Шестерёнка, это не автомобиль, но что-то близко, да. Тоже механизмус.

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

Подчёркиваю, повседневное, т.е. то что по крайней мере понятно всем.

A> Т.е. слово yellow в качестве "трусливый" можно услышать не только от бандита или панка, но и в принципе от любого обычного человека на улице в простом разговоре.

Ага, попоробуйте поприменять. По своему опыту ни разу не слышал такого, во всяком случае не чаще чем сказать, человеку что он gray, pink, red или dark. В цвет можно заложить соответсвующий смысл от ситуации. Одно дело сказать кому-то что он gay, другое дело что yellow. Может значить всё что угодно. Это семантические аллюзии завязанные на цвет.

Если вы скажете кому-то что он yellow, он может вас и поймёт, но употребление крайне ограничено. Yellow man — это явно жёлтый человек, а не подлый.

A>см.
A>http://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B7%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%D0%BD%D1%8B%D0%B9_%D1%81%D1%82%D0%B8%D0%BB%D1%8C
A>например, в том же лингво — http://lingvo.abbyyonline.com/ru/en-ru/%D1%8D%D0%BB%D0%B5%D0%BA%D1%82%D1%80%D0%B8%D1%87%D0%BA%D0%B0
A>Электричка — это сленг? Или есть человек, говоряший по русски и не понимающий, что это значит?

Это вообще к чему? Какой посыл от этой фразы в контексте беседы?

>> Английский лишён артиклей,
A>Артикли — The, A. Это конечно не Der, Die, Das, Ein, но вот в литературном русском артиклей нет.

Ой, ошибся, миль пардон, я про суффиксы. Они избыточны в программировании. Ну не суть.

>> мало словоформ, поэтому в качестве языка программирования он намного более предпочтительнее чем русский.
A>Английский в качестве языка программирования используется только в COBOL. Во всех остальных языках программирования (известных мне) используются ключевые слова, правда в основном взятые из английского языка, в том числе и по историческим причинам ("кибернетика — продажная девка имериализма", после этого она обиделась и долго не говорила по русски

). При этом эти слова могут иметь разные значения, но в языке программирования их суть всегда одна.

Вы специально это делаете? Начинаете извращать смысл фраз или находить в них особый смысл? Неужели вы думали что под английским в программировании я ратую за письменный английский или стиль COBOL? Это как вообще, к чему это?
Неужели не ясно, что речь шла о плюсах именно текущего варианта английского в С-подобных языках и использовании английских терминов в нэйминге методов и полей.

A>Если написано просто "case" — я (и никто, кроме написавшего) не буду знать что это значит. В связанном тексте — по контексту. В программе на C# я это не буду воспринамать ни как чемодан, ни как случай, а как ключевое слово, означающее метку в операторе switch.

У меня есть подозрение, что не только вы не сможете определить значение омонима если его написать как отдельное слово. Отсюда получается, что вы со мной согласны. Слова на английском короче, а семантический смысл явен.

R>>Короткие корни+отсутствие артиклей+семантическая ясность = хорошо для описания алгоритмов.
A>Это просто дело привычки.

Ну да, как и трусы через голову.

R>>Ошибки понятны?
A>Нет

Поняли, просто вредничаете.

Ну или значит у вас свой особый путь.

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

A>Посыл в том, что в словаре (и в lingvo и в multitran) Yellow/подлость помечено не как сленговое, а как разговорное. И что между этими понятиями есть разница.

Словари пишут люди. Дискуссии о таких понятиях как сленг и разговорная речь у лингвистов идут до сих пор. Смотрите по факту о yellow. Как уже сказано, это аллюзивное связывание с бульварностью, желчностью, трусостью и подлостью. Однако ко многим цветам можно подобрать подобное. В данном случае скорее всего хотели показать подобное употребление слова, но ещё раз повторяю, это как напротив слова "духовка" писать "разг. попа".

A>Вы написали "Английский лишён ..., поэтому в качестве языка программирования он намного более предпочтительнее чем русский".

Ну да, я написал то, что пишут лингвисты, неужто я сам придумал? Или вы не согласны?

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

A>Вам настолько нравится английский, что вместо "в именах" Вы пишете "в нейминге"

(при этом букв на целых две больше!)

Ничуть, русский обожаю много больше, на полном серьёзе и во много раз. Я вообще сторонник гипотезы Сепира—Уорфа. Ничего нет плохого чтобы расширить русский язык словом "нэйминг", никто не забудет слово "наименование" или "именование". Сделаем английский сабсетом русского!

A>На счет наименования полей и методов — в том же 1С как Вы думаете, почему используется русский язык? Или вместо русских слов разработчики (очень часто английского вообще не знающие — такая у них там специфика) должны искать в словарях (полных амонимов!) переводы для, например, ПросроченныеСчетаПоставщиков т.п.?

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

A>А если выполняется автоматизация, скажем, строительства — нужно учить новые английские слова.

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

A>Поэтому все нормальные разработчики решений для РФ на 1С будут использовать русские названия полей (во многих фирмах — это стандарт). При этом, если ключевые слова продолжать писать по английски, а имена — по русски, возникает проблема постоянного переключения раскладки клавиатуры RUS/ENG. Между прочем, в языке 1С можно использовать и англиские ключевые слова, но что то никто этого не делает.

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

A>Короче — да. На счет смысла — для ключевых слов C# он "явен" только в программе на C#. Если в программе на 1С использовать русские ключевые слова, то их смысл будет не менее явен в этой программе.

И общая длинна будет больше, а значит и лишняя наргузка на глаза.

A>Т.е. если вместо IF писать ЕСЛИ, это трусы через голову? Не кажется Вам, что это слишком?

Нет, не кажется. Два символа вместо четырёх воспринимаются намного легче, тут уж хоть режьте. В мозгах тоже есть свой парсер и ему тоже также может быть плохо. Там нет никакой магии. Я, конечно, не могу привести вам железных АИ, но делаю вывод чисто логически по тому, что знаю. Абсолютно незачем нагружать его избыточной информацией.

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

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

R>Нет, не кажется. Два символа вместо четырёх воспринимаются намного легче, тут уж хоть режьте. В мозгах тоже есть свой парсер и

По-китайски все ключевые слова будут представляться одним иероглифом — от этого проще не станет

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

В английском есть суффиксы — http://www.studynow.ru/grammar/suffix. И они важны при программировании (при "наминге" полей/методов), например, суффикс -able (Serializable,Writable и т.п.).

PS и приставки в английском есть, нпример, inactive, invalid — используются в "наминге". И окончания (-ed, -ing). Так что не так все просто там, как кажется.

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

A>По-китайски все ключевые слова будут представляться одним иероглифом — от этого проще не станет

Ай, ну опять. Разница между иероглифом и буквой ясна?

A>Я забыл в прошлом письме ответить на замечание про суффиксы. Так вот, в начале Вы написали, что в английском нет артиклей, потом поправились, что имели в виду суффиксы, которых или нет в английском, или они просто не нужны при программировании (я не доконца понял). (Все таки наверное нет в английском, т.к. изначально было сказано, что нет артиклей).

A>В английском есть суффиксы — http://www.studynow.ru/grammar/suffix. И они важны при программировании (при "наминге" полей/методов), например, суффикс -able (Serializable,Writable и т.п.).

Про yellow уже ничего не слышно. Осталось только это.

Вы меня совсем не понимаете и уже начали уже лезть в бутылку. Не стоит мне с вами говорить такими однозначными фразами. Похоже вы каждую фразу воспринимаете как подопытного и пытаетесь заглянуть ему во все места. Хотя я сам, пожалуй, был недостаточно ясен. К своему стыду, я срезаю углы и не являюсь википедией, поэтому не шлифую фразы. От этого появляются ошибки скорости. Когда я говорил, что там "нет суффиксов" я имел в виду, что их ГОРАЗДО меньше, а их использование как бы "незаметно", всё сидит в своих слотах. Если у меня 1000 рублей, а у вас 100 я могу сказать, что денег у вас нет. В контексте разговора такое утверждение нормально. Мы ведь не сами языки сравниваем, а их уместность в программировании

Тот самый первый тезис следует читать так: "В русском языке по сравнению с английским намного более богатое словообразование со многими нюансами, что порождает избыточную нагрузку". Более богатое словообразование выливается в большую длинну слов и, на мой взгляд, в программировании это избыточно.

Прошу вас, не лезьте в бутылку. Разочаровывает, что когда были приведены стандартные аргументы о пользе английского, вы начинаете говорить про настоящий английский и COBOL. Ну и опять, в том же духе, вы привели в пример иероглифы. Неужели непонятно, что иероглиф читать много тяжелее чем букву?(да-да, есть простые)

A>PS и приставки в английском есть, нпример, inactive, invalid — используются в "наминге". И окончания (-ed, -ing). Так что не так все просто там, как кажется.

Вы серьёзно думаете, что мне кажется это так просто, что я не знаю про приставки и окончания? Ну пишите уж тогда про времена и герундий.

— Кузнечики зелёного цвета. Это связано с тем что трава зелёная.
— Неправда! Лол! Она бывает красной, а не только зелёной! Не всё так просто как кажется!
— [фейспалм] Ну да, и девушки бывают с бородами. Но речь шла о конкретной лужайке и о конкретных кузнечиках.

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

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

	От:	Lloyd
	Дата:	15.01.11 23:35
	Оценка:	1 (1)

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

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

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

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	16.01.11 19:58
Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	17.01.11 16:19
Оценка:

От:	Wissenschaftler	http://rsdn_user.livejournal.com
Дата:	17.01.11 17:20
Оценка:

	От:	Светлояр
	Дата:	17.01.11 22:53
	Оценка:

От:	Фанатик	http://vk.com/id10256428
Дата:	19.01.11 13:10
Оценка:

	От:	aloch
	Дата:	24.01.11 15:37
	Оценка:	+1 -1

	От:	aloch
	Дата:	25.01.11 13:11
	Оценка:	-2

	От:	aloch
	Дата:	25.01.11 05:00
	Оценка:	-1