Мое личное мнение, что оценка языка должна отталкиваться от предметной области. Поверь я обеими руками за С#. Но есть много факторов, что бы я поднимал руки и за 1С и за Питона итд.
1. Позднее связывание, и работа с объетами неопределенного типа. Здесь рулят аналоги IDispatch. И никакая статическая типизация не спасет.
2. Читабельность кода. Она заключается не только в ручках, но и возможностях языка, чем сложнее тем больше наворотов, где без поллитры не разберешься, даже в собственном коде (когда он писался в момент озарения
Чем проще язык, тем меньше возможности обусфактить код.
Я лично изучал бухгалтерию исключительно по исходникам. И есть опыт написания на типизированном языке с автокомплитом итд, разница по скорости и читабельности всеже существует, не в пользу компиляторов.
Чем проще язык, тем больше можно найти (обучить) специалистов которые бы понимали как предметную область, так и умели это программировать, не влезая во всякие языковые дебри и фичи, в том числе и на родном для них лингвистическом языке. Насчет ошибок итд, то вырабатывается некий стиль, снижающий этот риск (опять же смотрим 1 где статическая типизация не спасает, а наступить на теже грабли легко и со статической типизацией).
И поверь мной на 1С написано многие мегабайты кода и ничего страшного.
По поводу скорости, то во многих случаях лимитирующей стадие является отнюдь не среда исполнения. Смотрим на янус, поверь та же задача на 1С просто летала бы (ах этот долбанный Аксесс).
Для каждой задачи свой язык
S> По поводу скорости, то во многих случаях лимитирующей стадие является отнюдь не среда исполнения. Смотрим на янус, поверь та же задача на 1С просто летала бы (ах этот долбанный Аксесс).
LCR>Янус не летает, потому что он активно использует высокоуровневые средства. Впрочем производительности для многих достаточно.
Бедный янус был приведен любителям скорости компиляторов. А многим хватает скорости хватает и интерпитирующих сред.
Все должно применяться по месту, учитывая огромное количество факторов.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> По поводу скорости, то во многих случаях лимитирующей стадие является отнюдь не среда исполнения. Смотрим на янус, поверь та же задача на 1С просто летала бы (ах этот долбанный Аксесс).
RSDN-клиент на 1С... Ммм... Свежо, свежо... А почему бы и нет, собственно, если на восьмерке... Должно получиться довольно халявно, не так ли, как думаешь?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Serginio1, Вы писали:
S>> По поводу скорости, то во многих случаях лимитирующей стадие является отнюдь не среда исполнения. Смотрим на янус, поверь та же задача на 1С просто летала бы (ах этот долбанный Аксесс).
G>RSDN-клиент на 1С... Ммм... Свежо, свежо... А почему бы и нет, собственно, если на восьмерке... Должно получиться довольно халявно, не так ли, как думаешь?
Ну движок аля 1С делается за неделю
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, Serginio1, Вы писали:
S>>> По поводу скорости, то во многих случаях лимитирующей стадие является отнюдь не среда исполнения. Смотрим на янус, поверь та же задача на 1С просто летала бы (ах этот долбанный Аксесс).
G>>RSDN-клиент на 1С... Ммм... Свежо, свежо... А почему бы и нет, собственно, если на восьмерке... Должно получиться довольно халявно, не так ли, как думаешь? S> Ну движок аля 1С делается за неделю
Мы пробовали. Оказалось, что не все так просто, как кажется. Пришли к выводу, что проще и дешевле купить настоящий движок 1С вместе со всеми прелестями, которые дает среда разработки и типовыми решениями в исходниках. За такие деньги — это просто подарок. Особенно, если имеешь 50% скидку .
Кстати, в самом 1С они очень многие вещи для себя, не относящиеся к учету, пишут на "Предприятии". В частности, прога-редактор контента их дисков с "информационным сопровождением" (что-то типа журнала) написана на 1С. Я был в шоке — выяснилось, что так проще.
Я к чему . Шутки шутками, а вполне может оказаться, что на 1Сv8, с его встроенной поддержкой XML, прозрачной работой с БД (объекты персистентные сами по себе — с точки зрения программера 1С очень похожа на объектную БД), полноценным гуем, и полной поддержкой ActiveX написать RSDN-клиента окажется проще, чем на С# . Я в этом почти уверен .
S>> Ну движок аля 1С делается за неделю G>Мы пробовали. Оказалось, что не все так просто, как кажется. Пришли к выводу, что проще и дешевле купить настоящий движок 1С вместе со всеми прелестями, которые дает среда разработки и типовыми решениями в исходниках. За такие деньги — это просто подарок. Особенно, если имеешь 50% скидку .
За такие деньги можно каждый год покупать по новой конфигурации . Что зачастую я и наблюдал.
G>Кстати, в самом 1С они очень многие вещи для себя, не относящиеся к учету, пишут на "Предприятии". В частности, прога-редактор контента их дисков с "информационным сопровождением" (что-то типа журнала) написана на 1С. Я был в шоке — выяснилось, что так проще.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Так динамически типизируемый язык рулит.
В случае 1С дело не только и не столько в динамической типизации. Это один из кирпичиков в их решении. Выигрыш получается в первую очередь за счет следующих вещей:
1) Автоматическая персистентность бизнес-объектов. Все "существенные" объекты хранятся в БД, кэшируются прозрачным образом, сохраняются и восстанавливаются сами, по мере необходимости. Об этом просто не надо думать. Есть язык запросов, правда, довольно странный. Имеем в результате нечто, очень похожее на объектную БД.
2) ГУЙ привязывается к бизнес-объектам простым и прозрачным образом — там эффективно реализованные "живые" контролы. Система сохраняет состояние визуальной формы автоматически, и в большинстве случаев об этом тоже думать не надо.
3) Наследоваться бизнес-объекты друг от друга не могут, это, в общем, плохо. Поэтому язык динамически типизирован — это позволяет писать полиморфный код не прибегая к наследованию. В результате все получается reasonably well. Использование динамически типизированного языка позволяет заметно упростить систему и язык, и совсем немного проиграть при этом в удобстве. В целом — удачный инженерный компромис.
4) Великолепный редактор печатных форм — а-ля Excel. Вне конкуренции. Использование динамически типизированного языка и позднего связнывания позволяет внедрять фрагменты кода непосредственно в ячейки таблицы. Этот код потом выполняется в контексте вызывающего. Круто и мега-удобно.
5) Нет клиентской и серверной части — с точки зрения программера решение выглядит как монолитное приложение. Платформа сама нагружает серверную часть. Подобный подход применялся в Borland IntraBuilder, если кто помнит такой продукт. Удобно.
Короче, при правильном применении этой ботвы выходит, что 90% кода, который ты пишешь — это чистая бизнес-логика. Все остальное, не относящееся к предметной области, делается за тебя системой. В этом выигрыш, в этом и грабли — система, в целом, заточена под одну идеологию организации ГУЯ (Справочник-Документ-Отчет), и под достаточно узкий класс задач.
Здравствуйте, Gaperton, Вы писали:
G>Я к чему . Шутки шутками, а вполне может оказаться, что на 1Сv8, с его встроенной поддержкой XML, прозрачной работой с БД (объекты персистентные сами по себе — с точки зрения программера 1С очень похожа на объектную БД), полноценным гуем, и полной поддержкой ActiveX написать RSDN-клиента окажется проще, чем на С# . Я в этом почти уверен .
Гы-гы. Ты сначала в wsdl RSDN-а посмотри.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Gaperton, Вы писали:
G>1) Автоматическая персистентность бизнес-объектов. Все "существенные" объекты хранятся в БД, кэшируются прозрачным образом, сохраняются и восстанавливаются сами, по мере необходимости. Об этом просто не надо думать. Есть язык запросов, правда, довольно странный. Имеем в результате нечто, очень похожее на объектную БД.
В 1С бизнес объекты скорее похожи на DTO, так как там нет ничего похожего на IdentiyMap, и соответственно можно иметь несколько копий объекта в памяти. Что в свою очередь приводит к тому, что измененный объект (копию) необходимо вручную save'ить.
Какая же это автоматическая персистентность? Это классический подход: считал, изменил, записал.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Гы-гы. Ты сначала в wsdl RSDN-а посмотри.
Не, ну почему, если модуль синхронизатора написать на шарпе и подцепить его через СОМ ... Впрочем слухи о том, что на 1C реализовать янус проще сильно преувеличены. Даже для примитивнейшей реализации придется поковыряться, дабы реализовать необходимые алгоритмы. Дальше хуже — GUI в 1С примитиный и не расширяемый. Чем к примеру заменить TreeGrid или PropertyGrid я даже не представляю. Ну и наконец сложность януса не столько в БД, она в нем примитивная, сколько в большом количестве прикладного функционала, а его 1С реализовать ничем не поможет, а скорее наоборот, усложнит.
AVK>Не, ну почему, если модуль синхронизатора написать на шарпе и подцепить его через СОМ ... Впрочем слухи о том, что на 1C реализовать янус проще сильно преувеличены. Даже для примитивнейшей реализации придется поковыряться, дабы реализовать необходимые алгоритмы. Дальше хуже — GUI в 1С примитиный и не расширяемый. Чем к примеру заменить TreeGrid или PropertyGrid я даже не представляю. Ну и наконец сложность януса не столько в БД, она в нем примитивная, сколько в большом количестве прикладного функционала, а его 1С реализовать ничем не поможет, а скорее наоборот, усложнит.
Можно этот самый прикладной функционал, хотя бы бегло, описать. Потому как я ничего особого, кроме списка оценок для поста, не заметил.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Можно этот самый прикладной функционал, хотя бы бегло, описать.
Бегло содержимое почти 3 мег кода? Боюсь не получится. Открывай исходники и смотри сам что и сколько занимает. Вот к примеру 300К занимает подсистема конфигурирования. Вряд ли на 1С получится меньше, если только не скатится до их плоского списка констант или справочника.
ANS> Потому как я ничего особого, кроме списка оценок для поста, не заметил.
Признак того что этот функционал грамотно раскидан и не мозолит глаза, если не нужен .
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Гы-гы. Ты сначала в wsdl RSDN-а посмотри. AVK>Не, ну почему, если модуль синхронизатора написать на шарпе и подцепить его через СОМ ...
Ну вот в том-то и дело. Тогда проще весь Янус переписать на шарпе ещё раз. Вот ежли вы вместо нетипизированных датасетов будете типизованные кидать... Тогда будет попроще.
AVK>Впрочем слухи о том, что на 1C реализовать янус проще сильно преувеличены. Даже для примитивнейшей реализации придется поковыряться, дабы реализовать необходимые алгоритмы. Дальше хуже — GUI в 1С примитиный и не расширяемый. Чем к примеру заменить TreeGrid или PropertyGrid я даже не представляю. Ну и наконец сложность януса не столько в БД, она в нем примитивная, сколько в большом количестве прикладного функционала, а его 1С реализовать ничем не поможет, а скорее наоборот, усложнит.
+1
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ну вот в том-то и дело. Тогда проще весь Янус переписать на шарпе ещё раз. Вот ежли вы вместо нетипизированных датасетов будете типизованные кидать... Тогда будет попроще.
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Ну вот в том-то и дело. Тогда проще весь Янус переписать на шарпе ещё раз. Вот ежли вы вместо нетипизированных датасетов будете типизованные кидать... Тогда будет попроще.
AVK>Возможно, но, ИМХО, не особо.
Попроще будет в том смысле, что можно будет цеплять не .Net-овские клиенты Web-сервисов. В принципе, их можно и сейчас подцепить, но уж больно геморройно и рискованно.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Попроще будет в том смысле, что можно будет цеплять не .Net-овские клиенты Web-сервисов.
И чем в этом отношении типизированные датасеты лучше? И там и там они на примитивные типы не отображаются и скорее всего xml придется парсить руками. Ну разве что схема у типизированных поподробнее будет, но это мелочи.
Здравствуйте, stalcer, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>1) Автоматическая персистентность бизнес-объектов. Все "существенные" объекты хранятся в БД, кэшируются прозрачным образом, сохраняются и восстанавливаются сами, по мере необходимости. Об этом просто не надо думать. Есть язык запросов, правда, довольно странный. Имеем в результате нечто, очень похожее на объектную БД.
S>В 1С бизнес объекты скорее похожи на DTO, так как там нет ничего похожего на IdentiyMap, и соответственно можно иметь несколько копий объекта в памяти.
Приведите пожалуйста пример для элементов справичников и документов.
S>Что в свою очередь приводит к тому, что измененный объект (копию) необходимо вручную save'ить.
Вызвать к нему "Сохранить"? В чем проблема — считайте, что изменения элементов выполняются в рамках транзакции, а "Сохранить" эту транзакцию коммитит. И это очень, очень хорошо. Кстати, на самом деле так оно и есть — вы можете обозначать границы транзакции и руками, например.
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Попроще будет в том смысле, что можно будет цеплять не .Net-овские клиенты Web-сервисов.
AVK>И чем в этом отношении типизированные датасеты лучше? И там и там они на примитивные типы не отображаются и скорее всего xml придется парсить руками. Ну разве что схема у типизированных поподробнее будет, но это мелочи.
Тем, что можно будет gSOAP натравить, например. А то он <s:any/> не переваривает (и правильно делает). А схему вместе с датасетом передавть не надо, поскольку если она известна, то что с ней делать — понятно, а если изначально неизвстна, то и что с ней делать, когда получишь — тоже не догадаешься. Пусть уж лучше всё в WSDL будет, с optional-колонками. Ну, или, на худой конец — отдельные xsd. Главное, чтобы они были изначально известны.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
AVK>>И чем в этом отношении типизированные датасеты лучше? И там и там они на примитивные типы не отображаются и скорее всего xml придется парсить руками. Ну разве что схема у типизированных поподробнее будет, но это мелочи.
ГВ>Тем, что можно будет gSOAP натравить, например. А то он <s:any/> не переваривает (и правильно делает).
А кто их переваривает, эти <s:any/>?
Я вообще плохо представляю себе логику MS в этом вопросе. WS изначально платформенно-независимая штуковина. Плюнули в <s:any/> датасетом, и вот мы уже .Net-зависимы.
Здравствуйте, vdimas, Вы писали:
ГВ>>Тем, что можно будет gSOAP натравить, например. А то он <s:any/> не переваривает (и правильно делает). V>А кто их переваривает, эти <s:any/>? V>Я вообще плохо представляю себе логику MS в этом вопросе. WS изначально платформенно-независимая штуковина. Плюнули в <s:any/> датасетом, и вот мы уже .Net-зависимы.
Дык! Скорее всего, это и есть одна из причин отсутствия alter-Janus. Не самая могучая, естественно, но...
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Дык! Скорее всего, это и есть одна из причин отсутствия alter-Janus. Не самая могучая, естественно, но...
Да не, эта проблема достаточно просто решается. При генерации просто склеиваем захардкоженные собственно и данные, при разборе — пробегаемся по элементам. Хотя если бы там были стандартные типы, задаваемые схемой, было бы гораздо удобнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Гы-гы. Ты сначала в wsdl RSDN-а посмотри.
AVK>Не, ну почему, если модуль синхронизатора написать на шарпе и подцепить его через СОМ ... Впрочем слухи о том, что на 1C реализовать янус проще сильно преувеличены. Даже для примитивнейшей реализации придется поковыряться, дабы реализовать необходимые алгоритмы.
Возможно. Алгоритмы, безусловно, никуда не денутся.
AVK>Дальше хуже — GUI в 1С примитиный и не расширяемый. Чем к примеру заменить TreeGrid или PropertyGrid я даже не представляю.
Я ведь сказал — 1Сv8. И это не случайно — там можно активиксы в гуе использовать. Так что расширяемый. Во вторых, если бы какой смельчак и отважился писать янус на 1С , то гуй бы он полностью переработал, если себе не враг, так, что вопрос "чем заменить" не стоял бы.
AVK>Ну и наконец сложность януса не столько в БД, она в нем примитивная, сколько в большом количестве прикладного функционала, а его 1С реализовать ничем не поможет, а скорее наоборот, усложнит.
Усложнит — это вряд ли. Во-вторых, я все-таки не понимаю, какой такой в читалке форума сложный прикладной функционал. Примеры самых функционалистых модулей Януса можешь привести, если не сложно, с указанием размера (в LOC было бы идеально)? Интересна была бы доля прикладного функционала в процентах ко всему остальному, и буквально в двух словах, что именно он делает.
Здравствуйте, WFrag, Вы писали:
ГВ>>Дык! Скорее всего, это и есть одна из причин отсутствия alter-Janus. Не самая могучая, естественно, но... WF>Да не, эта проблема достаточно просто решается. При генерации просто склеиваем захардкоженные собственно и данные, при разборе — пробегаемся по элементам. Хотя если бы там были стандартные типы, задаваемые схемой, было бы гораздо удобнее.
Да понятно, что проблема решабельна. Неприятно, что шаг в сторону от .Net...
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Gaperton, Вы писали:
AVK>>Ну и наконец сложность януса не столько в БД, она в нем примитивная, сколько в большом количестве прикладного функционала, а его 1С реализовать ничем не поможет, а скорее наоборот, усложнит. G>Усложнит — это вряд ли. Во-вторых, я все-таки не понимаю, какой такой в читалке форума сложный прикладной функционал.
Не сложный, а объемный. Про сложность я ничего не писал.
G> Примеры самых функционалистых модулей Януса можешь привести, если не сложно, с указанием размера (в LOC было бы идеально)? Интересна была бы доля прикладного функционала в процентах ко всему остальному, и буквально в двух словах, что именно он делает.
Это большой объем работы, который я ради пофлеймить делать не буду. Интересно — скачивай исходники и смотри.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, WFrag, Вы писали:
ГВ>>>Дык! Скорее всего, это и есть одна из причин отсутствия alter-Janus. Не самая могучая, естественно, но... WF>>Да не, эта проблема достаточно просто решается. При генерации просто склеиваем захардкоженные собственно и данные, при разборе — пробегаемся по элементам. Хотя если бы там были стандартные типы, задаваемые схемой, было бы гораздо удобнее.
ГВ>Да понятно, что проблема решабельна. Неприятно, что шаг в сторону от .Net...
Не в пользу .NET скажу, а просто в тему. Если делать что-то сильно абстрактное, то внешний интерфейс может сильно усложниться. Например, как бы ты передал данный в SOAP, специфичные для платформы? Через поток байтов в специальном параметре? А вот через s:any это намного проще решается. По крайней, мере для .NET
Здравствуйте, AndrewVK, Вы писали:
G>> Примеры самых функционалистых модулей Януса можешь привести, если не сложно, с указанием размера (в LOC было бы идеально)? Интересна была бы доля прикладного функционала в процентах ко всему остальному, и буквально в двух словах, что именно он делает.
AVK>Это большой объем работы, который я ради пофлеймить делать не буду. Интересно — скачивай исходники и смотри.
Интересно, но не настолько, чтобы разбираться в 3х метрах сомнительного кода, не имея даже краткого обзора по центральным модулям.
Желаю дальнейших успехов в популяризации платформы посредством януса . Для себя я решил, что смотреть его сорцы не буду ни в коем случае. Раз для тебя, насколько я понимаю, одного из авторов, проблема сделать то, что обычно делается людьми по памяти за 5 минут — то у меня нет вообще никаких шансов .
Здравствуйте, Mika Soukhov, Вы писали:
ГВ>>>>Дык! Скорее всего, это и есть одна из причин отсутствия alter-Janus. Не самая могучая, естественно, но... WF>>>Да не, эта проблема достаточно просто решается. При генерации просто склеиваем захардкоженные собственно и данные, при разборе — пробегаемся по элементам. Хотя если бы там были стандартные типы, задаваемые схемой, было бы гораздо удобнее.
ГВ>>Да понятно, что проблема решабельна. Неприятно, что шаг в сторону от .Net...
MS>Не в пользу .NET скажу, а просто в тему. Если делать что-то сильно абстрактное, то внешний интерфейс может сильно усложниться.
Причём тут что-то сильно абстрактное? Речь идёт только о типизированных датасетах.
MS> Например, как бы ты передал данный в SOAP, специфичные для платформы? Через поток байтов в специальном параметре? А вот через s:any это намного проще решается. По крайней, мере для .NET (Вот в том-то и дело — ГВ.)
И вот нельзя так делать. Потому что, если я пихаю что-то через <s:any/>, то я могу это делать только имея неколебимую уверенность, что на другой стороне раположено нечто, способное переварить то, что заряжено через <s:any/>. В данном случае предполагаю, что приёмник тоже сделан на .Net. А такие предположения противоречат самой идее веб-сервисов.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Gaperton, Вы писали:
G>>> Примеры самых функционалистых модулей Януса можешь привести, если не сложно, с указанием размера (в LOC было бы идеально)? Интересна была бы доля прикладного функционала в процентах ко всему остальному, и буквально в двух словах, что именно он делает.
AVK>>Это большой объем работы, который я ради пофлеймить делать не буду. Интересно — скачивай исходники и смотри. G>Интересно, но не настолько, чтобы разбираться в 3х метрах сомнительного кода, не имея даже краткого обзора по центральным модулям.
G>Желаю дальнейших успехов в популяризации платформы посредством януса . Для себя я решил, что смотреть его сорцы не буду ни в коем случае. Раз для тебя, насколько я понимаю, одного из авторов, проблема сделать то, что обычно делается людьми по памяти за 5 минут — то у меня нет вообще никаких шансов .
Справедливости ради, в Янусе не сложный код. Объёмный просто и слегка путаный. С точки зрения же прикладного функционала (на мой взгляд, естественно) ничего особенного нет, просто каждая фича вынесена в отдельный модуль — отсюда и "объёмный функционал". Так что, с AVK в каком-то смысле можно согласиться — сложновато "перечислять" функциональность, структурированную таким образом.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Справедливости ради, в Янусе не сложный код. Объёмный просто и слегка путаный. С точки зрения же прикладного функционала (на мой взгляд, естественно) ничего особенного нет, просто каждая фича вынесена в отдельный модуль - отсюда и "объёмный функционал". Так что, с AVK в каком-то смысле можно согласиться — сложновато "перечислять" функциональность, структурированную таким образом.
Каждая фича вынесена в отдельный модуль. Отлично. Сколько у вас всего модулей? Есть ли у вас список этих самых фич?
Я всего-навсего попросил список самых важных модулей, относящихся не к ГУЮ и не к базе данных, а к функционалу, каждый с коротким комментарием в пару-тройку предложений о том, что он делает, и размером. Это правда так сложно сделать? Тогда извините ребята, но это, как любит говорить AVK, "приговор" .
Вы (ну, может быть не вы лично) постоянно говорите о прелестях компонентности, которая обеспечивается дотнетом, и тут вдруг — проблема со структурированием (sic!), настолько, что объяснить ничего нельзя? Не понимаю. Документация-то у вас есть по проекту хоть какая-нибудь? Хотя-бы overview архитектуры?
Здравствуйте, Gaperton, Вы писали:
G>Я всего-навсего попросил список самых важных модулей, относящихся не к ГУЮ и не к базе данных, а к функционалу, каждый с коротким комментарием в пару-тройку предложений о том, что он делает, и размером. Это правда так сложно сделать? Тогда извините ребята, но это, как любит говорить AVK, "приговор" .
Судя по форуму RSDN@Home, с жизненными силами у проекта всё в порядке: AFAIK, у Януса больше 20 разработчиков, так что, переадресуй вопрос в RSDN@Home, может быть — ответят. А я просто поигрался с кодом Януса некоторое время, да и бросил это занятие.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Gaperton, Вы писали:
G>Вы (ну, может быть не вы лично) (Ага, точно не я) постоянно говорите о прелестях компонентности, которая обеспечивается дотнетом, и тут вдруг — проблема со структурированием (sic!), настолько, что объяснить ничего нельзя?
Ну, пока что я только предполагаю. А вообще, поддержание подобной документации в актуальном виде — довольно нудная работа. Метрики снимать — вообще занудсво редкостное.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Gaperton, Вы писали:
G>Я всего-навсего попросил список самых важных модулей, относящихся не к ГУЮ и не к базе данных,
Здорово, только догадаться об этом было сложно. Ну тогда ответ простой — такой список скорее всего пустой.
G> а к функционалу, каждый с коротким комментарием в пару-тройку предложений о том, что он делает, и размером.
Извини, но на это требуется пара часов работы. Более того — сейчас у меня под рукой исходников януса нет и сделать это тебе самому будет даже проще.
G> Это правда так сложно сделать? Тогда извините ребята, но это, как любит говорить AVK, "приговор" .
Чему?
G>Вы (ну, может быть не вы лично) постоянно говорите о прелестях компонентности, которая обеспечивается дотнетом, и тут вдруг — проблема со структурированием (sic!), настолько, что объяснить ничего нельзя?
Объяснить можно, но это не то, чем у меня есть желание заниматься исключительно ради того чтобы пофлеймить.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ну, пока что я только предполагаю. А вообще, поддержание подобной документации в актуальном виде — довольно нудная работа. Метрики снимать — вообще занудсво редкостное.
Особенно забесплатно, особенно в процессе отпуска.
Здравствуйте, Mika Soukhov, Вы писали:
ГВ>>Да понятно, что проблема решабельна. Неприятно, что шаг в сторону от .Net...
MS>Не в пользу .NET скажу, а просто в тему. Если делать что-то сильно абстрактное, то внешний интерфейс может сильно усложниться. Например, как бы ты передал данный в SOAP, специфичные для платформы? Через поток байтов в специальном параметре? А вот через s:any это намного проще решается. По крайней, мере для .NET
Эдак мы всю науку... тьфу, все интерфейсы к одному методу сведём:
И делать невинные глаза по поводу того, что "платформа и так всё знает".
Так что... Либо полная платформонезависимая спецификация интерфейса, либо это у нас "не совсем" веб-сервис, а так... частный случай приватной коммуникации на базе одной из реализаций SOAP.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Ну, пока что я только предполагаю. А вообще, поддержание подобной документации в актуальном виде — довольно нудная работа. Метрики снимать — вообще занудсво редкостное.
AVK>Особенно забесплатно, особенно в процессе отпуска.
В корень зришь!
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>И делать невинные глаза по поводу того, что "платформа и так всё знает".
ГВ>Так что... Либо полная платформонезависимая спецификация интерфейса, либо это у нас "не совсем" веб-сервис, а так... частный случай приватной коммуникации на базе одной из реализаций SOAP.
А в .NET не особо сильно выбор стоит между коммуникацией. Если использовать Remoting, то для него нужно писать свой хост (или использовать IIS, от которого потом приложение перерастет в обычний веб сервис). Так что для внешней коммуникации намного проще написать веб сервис и не заботиться о платформонезависимости. Для януса ведь кроме .NET клиента ничего не существует. Так зачем делать лишнюю работу, которая может и не окупиться?
Здравствуйте, Gaperton, Вы писали:
G>Интересно, но не настолько, чтобы разбираться в 3х метрах сомнительного кода, не имея даже краткого обзора по центральным модулям.
Забавно. Разбираться не хочешь, но ярлычок "сомнительный код" уже прикрутил.
G>Желаю дальнейших успехов в популяризации платформы посредством януса . Для себя я решил, что смотреть его сорцы не буду ни в коем случае. Раз для тебя, насколько я понимаю, одного из авторов, проблема сделать то, что обычно делается людьми по памяти за 5 минут — то у меня нет вообще никаких шансов .
Вообще классный прием... Толкнуть откровенно провакационное предложение. Сделать пару заявлений, что мол на 1С это будет быстро и просто. А потом начать требовать планов, цифр, метрик. А можно узнать на каком основании не имея всего этого делались заявления о простоте?
В общем, не нужно заявлений. Если все так просто, то потрать пару дней и сделай Хоум на 1С. А если понимашь, что это не так просто, то не нужно брасаться заявлениями и темболее что-то ребовать.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
. Что зачастую я и наблюдал.
Ну, или, на худой конец — отдельные xsd. Главное, чтобы они были изначально известны.
.
Не понимаю. Документация-то у вас есть по проекту хоть какая-нибудь? Хотя-бы overview архитектуры?
