Re[5]: Какой язык выбрать для erp системы?
От: Gaperton http://gaperton.livejournal.com
Дата: 12.01.05 12:21
Оценка:
Здравствуйте, stalcer, Вы писали:

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


G>>Второе (менее очевидное) — динамически типизированный язык в качестве языка бизнес логики дает больше свободы при разработке объектной модели.

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

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

При этом, разрабатывая объектную модель для строго типизированного языка вы думаете не только о прикладном смысле классов, но также вынуждены думать о том, как организовать полиморфизм. В случае динамически типизированных языков вы об этом не думаете.
Re[6]: Какой язык выбрать для erp системы?
От: Cyberax Марс  
Дата: 12.01.05 12:28
Оценка:
Gaperton пишет:

> G>>Второе (менее очевидное) — динамически типизированный язык в

> качестве языка бизнес логики дает больше свободы при разработке
> объектной модели.
> S>Какие-же преимущества он дает? Возможность использование системы
> менее квалифицированными программистами?
> Динамическая типизация заметно упрощает дизайн, что, с одной стороны,
> снижает требования к квалификации программиста, с другой, освобождает
> квалифицированного от размышлений, не связанных на прямую с прикладной
> областью.

И является замечательным источником ошибок на больших проектах, особенно
тех, которые пишут неквалифицированные программисты....

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
О динамически типизированных языках
От: Gaperton http://gaperton.livejournal.com
Дата: 12.01.05 18:31
Оценка: 310 (32)
#Имя: FAQ.design.typification
Здравствуйте, Cyberax, Вы писали:

C>И является замечательным источником ошибок на больших проектах, особенно

C>тех, которые пишут неквалифицированные программисты....

Программирование это вообще источник ошибок. В форумах, мэйллистах и news группах подобные дискуссии обычно оканчиваются тем, что люди соглашаются на следующем:
1) Статическая проверка типов увеличивает количество ошибок, пойманное до тестирования.
2) Статическая типизация позволяет генерировать более эффективный код.
3) Последствия отсутствия статической проверки типов а ассемблере, FORTH, и С гораздо хуже, чем в языках Smalltalk, JScript и Python. Ошибки типизации в С обыкновенно ведут к повреждению памяти, что невозможно в перечисленных языках — они проверяют типы в рантайме.
4) Часть людей считает, что явная аннотация типов является неотемлемой и критичной частью их подхода к программированию, и что время, потраченное на это, окупается сокращением времени отладки, тестирования, и сопровождения.
5) При этом, другие люди уверены в том, что аннотации типов замусоривают код и делают программы менее гибкими, что удлинняет фазу прототипирования и затруднят экcперименты.

Также, неплохо иметь в виду, что:
1) Определение типов возможно без аннотации типов (пример — система типов Хиндли-Милнера, которая гарантирует определение типа из контекста). Такая техника называется type inference, и применяется во многих, как статически, так и динамически типизированных языках, в частности, в JScript.NET.

2) Также, многие динамически типизированные языки разрешают явную аннотацию типов. Как например JScript.NET.

3) Вышеперечисленное позволяет динамически типизированным языкам, вопреки распространенному мнению, достигать высокой производительности сравнимой с С# и Java а также выявлять ошибки типизации до тестирования (но не обязательно во время компиляции — часто это делается отдельными тулзами).

4) Динамическая типизация не более опасна, чем явное использование динамического приведения типов в языках Java и C#. Техника программирования, подразумевающая использование QueryInterface (в COM) и вообще динамических запросов интерфейсов (в Java и C#) не имеет такой "убийственной" репутации, как динамическая типизация, хотя совершенно ей эквивалентна. На самом деле тот же С# позволяет писать динамически типизированный код, только он будет выглядеть более громоздко. У вас используется тип Object? Вы запрашиваете у объекта интерфейс? Поздравляю, ваш код динамически типизирован.

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

Цена исправления дефекта в среднем тем больше, чем больше прошло времени с его внесения до его обнаружения (по данным Carnegi-Mellon SEI). Таким образом, у нас ошибки типизации находятся позже, и возрастает цена их исправления. Однако, благодаря большей ориентированности цикла разработки на прототипирование, раньше находятся алгоритмические дефекты и дефекты дизайна (которые всегда стоят дороже ошибок типизации), и их исправление будет стоить дешевле. На деле эти два фактора нивелируют друг друга, что подтверждает...

6) ...практика написания больших систем на динамически типизированных языках без применения статических проверок типов. Она показывает, что наличие динамической типизации не влияет заметным образом на количество ошибок в конечной системе, и такие ошибки не являются критическим фактором при разработке. В частности, метрики Ericsson по закрытым проектам (среди которых есть проекты размером до 2.5 миллионов строк) показывают, что средняя плотность дефектов на тысячу строк кода в динамически типизированных языках (Erlang) практически не отличается от таковой для статически типизированных языков (Java, C++, PLEX).

Хао. Я все сказал. ИМХО, повода для флейма нет. Мне, например, все понятно .
Re[5]: Какой язык выбрать для erp системы?
От: Gaperton http://gaperton.livejournal.com
Дата: 12.01.05 18:34
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Gaperton пишет:


>> Кстати, удивительное рядом. В статьях о GC также иногда пишут как о

>> чем-то само-собой разумеющемся, что сборка мусора на основе подсчета
>> ссылок *менее *эффективна, чем анализ графа зависимостей
>> (mark-and-sweep и stop-and-copy). Несколько раз встречал.

C>Так и есть, в подавляющем большинстве случаев. Так как в многотредных

C>приложениях каждое присваивание refconted-ссылки будет требовать
C>блокировки ДВУХ мьютексов.

А я верю . Даже в однопоточном случае необходимо постоянно дергать счетчик при каждом присваивании. GC же в среднем будет пробегаться по каждому из объектов реже.
Re[3]: Какой язык выбрать для erp системы?
От: Максим Зелински Россия  
Дата: 12.01.05 19:00
Оценка:
Здравствуйте, GlebZ, Вы писали:

G>>Поэтому не парься, пиши все на шарпах, а в качастве языка программируемой бизнес-логики возьми JScript.NET — это динамически типизированный язык с аннотацией типов — то, что доктор прописал.

GZ>Я тут подумал, а что мешает организовать программируемую бизнес-логику на С#. Вроде особых проблем не вижу (только плюсы).
Кстати, мы так и делаем . На первых порах, во всяком случае, потом, наверное, прикрутим интерпретаторы для языков предметной области.

GZ>С уважением, Gleb.
Re[4]: Какой язык выбрать для erp системы?
От: Максим Зелински Россия  
Дата: 12.01.05 22:12
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>При грамоном использовании дотнета и наличии достаточного количества памяти, и естественно, при условии что в одном из случаев вы не сделаете каких-нибудь глупостей... можно ожидать потерю в скорости до 1.1-1.5 раз. Если высвободившееся время пустить на оптимизацию алгоритмов и поиск более грамотных проектных решений, то... ну, думаю ты понял.

Я всё же выбрал дотНет, и вот почему:
да, наши замеры показали, что просев скорости от 1.1 до 1.6 (замеряли фреймворк 1.1), когда пересели на фреймворк 2.0 просев был от 1.1 до 1.4. Это всё не очень страшно, главное что наша производительность увеличилась. Особенно мои программисты балдеют от IL, настоящей компонентности (нет больше всяких IDL для Кома, геморроя со статическими переменными в разных модулях, загроможденности кода), атрибутов. Я даже более детально стал поучивать C#, чтоб не отстать Честно сознаюсь, я "фанат" C++, до того как я вплотную познакомился с C# я его считал "языком для дурачков", теперь я так не считаю. Во всяком случаи в моей области (создание ПО управления предприятием (erp, scm, crm)) — это правильный выбор, так как в C# есть всё, что может "облегчить" жизнь (сначала я планировал делать систему на С++, в планах стояло написать свою компонентную модель, поддержку атрибутов и т.д.).

VD>Ну, и главное! От С++ как средства оптимизации отказыватьс совершенно не нужно. Если вы обнаружите узкие места которые, по вашему мнению, могут быть устранены реализацией узких мест на С++, то спокойно переисывайте их на нем и смотрите что получилось.

Хех, надеюсь, что таких мест будет крайне мало. Очень приятно, что у C# есть нормальная система интеропа, в отличии от Java.

VD>Скорсоть MC++ практически идентична анменеджед VC той же версии.

MC++ — уродец
Re[2]: Какой язык выбрать для erp системы?
От: Максим Зелински Россия  
Дата: 12.01.05 22:16
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Максим Зелински, Вы писали:


МЗ>>Надо написать такую, есть выбор между C++ (производительность) и C# (простота разработки).

G>C++ — даже не думай об этом.
Уже не думаю...

G>Забей. Во первых, языки дотнета довольно шустры, посмотри тесты. На численных расчетах они на равных с С++.

Хотя просев есть Но я уверен, что MS это исправит.

G>В случае трехзвенки — утечки памяти и крэши на серваке (где цена ошибки гораздо выше) — неприятная штука. Совсем небольшой минус от сборщика мусора (не более 5% от времени полезной работы сервака) того стоит, чтобы на него плюнуть, не говоря о том, что ты просто его не заметишь. К тому же, аллокатор дотнета работает в целом лучше, чем стандартный плюсовый . Бояться надо другого. Большие boxed массивы маленьких объектов — в этом проблема (решаемая), а не в сборщике мусора.

Перешли на фреймворк 2.0. Боксинга вроде больше нет и хорошо.

G>Поэтому не парься, пиши все на шарпах, а в качастве языка программируемой бизнес-логики возьми JScript.NET — это динамически типизированный язык с аннотацией типов — то, что доктор прописал.

Для БО на первых порах будем использовать сам C#, потом прикрутим интерпретатор языка предметной области.

G>А это как раз не проблема. Ты с компонентной моделью и скриптингом гораздо больше натрахаешься.

Да, скриптинг прикрутить к объектам (при чем не изменяя их!) как два пальца об асфальт
Re[3]: Какой язык выбрать для erp системы?
От: Gaperton http://gaperton.livejournal.com
Дата: 12.01.05 22:37
Оценка:
Здравствуйте, Максим Зелински, Вы писали:

G>>А это как раз не проблема. Ты с компонентной моделью и скриптингом гораздо больше натрахаешься.

МЗ>Да, скриптинг прикрутить к объектам (при чем не изменяя их!) как два пальца об асфальт
Ну, не все так радужно . Ты уже в курсе, что нельзя выгружать отдельные сборки? Что выружать можно только домен целиком? Если вы собираетесь разрешить замену кода на работающей системе, это может стать проблемой — налетите на междоменную передачу данных, а это небыстро.

Причем, при выгрузке домена происходит memory leak, что в ряде случаев тоже может стать проблемой. Не знаю, поправили ли это во второй версии фреймворка.

Далее, в версиях фреймворка <2.0 приложение-отладчик должен быть unmanaged (это вообще пипец). Правда, в 2.0 это обещали поправить.
Re[4]: В догонку
От: Gaperton http://gaperton.livejournal.com
Дата: 13.01.05 00:43
Оценка:
G>Причем, при выгрузке домена происходит memory leak, что в ряде случаев тоже может стать проблемой. Не знаю, поправили ли это во второй версии фреймворка.
Memory leak возникает, если загружать каждый раз разные сборки (!). Случай довольно специфический, но иногда это чудовищные грабли. Это значит, в частности, что пользуясь платформой .NET не так просто написать Web-browser с поддержкой JavaScript.

Далее, приятная новость осени прошлого года. Microsoft прекратил разработку продукта Visual Studio for Applications .NET. Продукта не будет. Всем сожалеющим об этом рекомендуется кастомизировать "взрослую" Visual Studio .NET. Надеялись использовать VSA? Хренушки.

Короче, если нужен полноценный скриптинг во всех позах, Java — лучший выбор, чем .NET. Почему так:
1) Единица загрузки — класс (не сборка).
2) Неиспользуемые классы удаляются GC (в дот нет вы можете выгрузить только домен целиком, обязаны делать это вручную, и это в некоторых случаях дает memory leak)
3) Плюс к этому, написав свой ClassLoader, вы полностью контроллируете политику загрузки и выгрузки классов.
4) Для JVM есть большое количество готовых скриптовых языков и решений.
Re: Какой язык выбрать для erp системы?
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 13.01.05 07:08
Оценка:
Здравствуйте, Максим Зелински, Вы писали:

МЗ>Нюанс в том, что эта erp — по сути "конструктор" (наподобии 1С или Axapta).


Интересно.
Пишите на своё/определенное предприятие?
Почему отказались от существующих решений?
... << RSDN@Home 1.1.4 beta 3 rev. 241>>
Вселенная бесконечна как вширь, так и вглубь.
Re[2]: Какой язык выбрать для erp системы?
От: Максим Зелински Россия  
Дата: 13.01.05 08:46
Оценка:
Здравствуйте, Real 3L0, Вы писали:

МЗ>>Нюанс в том, что эта erp — по сути "конструктор" (наподобии 1С или Axapta).


R3>Интересно.

R3>Пишите на своё/определенное предприятие?
R3>Почему отказались от существующих решений?
Если бы писали под своё предприятие, то не заторачивались с "конструктором" (а именно, писать свой бизнес фреймворк дело не из простых). Это коробочный софт.
Re[4]: Какой язык выбрать для erp системы?
От: Максим Зелински Россия  
Дата: 13.01.05 08:51
Оценка:
Здравствуйте, Gaperton, Вы писали:

МЗ>>Да, скриптинг прикрутить к объектам (при чем не изменяя их!) как два пальца об асфальт

G>Ну, не все так радужно . Ты уже в курсе, что нельзя выгружать отдельные сборки? Что выружать можно только домен целиком? Если вы собираетесь разрешить замену кода на работающей системе, это может стать проблемой — налетите на междоменную передачу данных, а это небыстро.
Ну это детали, можно сделать полу интерпретированную надстройку (компилиться в свой байт код и потом интерпретируется), конечно Reflection.Emit использовать с существующими ограничениями (на выгрузку сборок) пока не будем. Но когда продукт выйдет на финальную стадию (а языки предметных областей будут разрабатываться после выхода финальной версии), подоспеет и второй фреймворк, где это вроде обещали исправить.
Re[5]: В догонку
От: Максим Зелински Россия  
Дата: 13.01.05 08:54
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Далее, приятная новость осени прошлого года. Microsoft прекратил разработку продукта Visual Studio for Applications .NET. Продукта не будет. Всем сожалеющим об этом рекомендуется кастомизировать "взрослую" Visual Studio .NET. Надеялись использовать VSA? Хренушки.

Да, обидно, но жить можно.

G>Короче, если нужен полноценный скриптинг во всех позах, Java — лучший выбор, чем .NET. Почему так:

Мы к Java приценивались, но пришлось отказаться, так как там нет "атрибутов", которые очень нам нужны.
Re[3]: Какой язык выбрать для erp системы?
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 13.01.05 09:24
Оценка:
Здравствуйте, Максим Зелински, Вы писали:

МЗ>Если бы писали под своё предприятие, то не заторачивались с "конструктором" (а именно, писать свой бизнес фреймворк дело не из простых). Это коробочный софт.


Тогда, в чем необходимость существования вашего продукта?
... << RSDN@Home 1.1.4 beta 3 rev. 241>>
Вселенная бесконечна как вширь, так и вглубь.
Re[4]: Какой язык выбрать для erp системы?
От: Максим Зелински Россия  
Дата: 13.01.05 09:30
Оценка: :)
Здравствуйте, Real 3L0, Вы писали:

R3>Тогда, в чем необходимость существования вашего продукта?

Странный вопрос . Наверное деньги хотим заработать А что вас смущает?
Re[5]: Какой язык выбрать для erp системы?
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 13.01.05 09:38
Оценка:
Здравствуйте, Максим Зелински, Вы писали:

МЗ>Странный вопрос . Наверное деньги хотим заработать А что вас смущает?


Т.е. в продажах не сомневаетесь?
... << RSDN@Home 1.1.4 beta 3 rev. 241>>
Вселенная бесконечна как вширь, так и вглубь.
Re[6]: Какой язык выбрать для erp системы?
От: Максим Зелински Россия  
Дата: 13.01.05 09:47
Оценка:
Здравствуйте, Real 3L0, Вы писали:

R3>Т.е. в продажах не сомневаетесь?

Конечно сомневаемся, это наш "первенец" в области бизнес софта. Во всяком случаи наш софт будет выделяться на фоне остальных конструкторов, таких как 1С, Axapta, Sap R/3, своими "уникальными" возможностями. К сожалению, я не вправе (пока во всяком случае) их раскрывать, могу только сказать, что у нас трёх звённая архитектура, мы очень много времени уделили разработке подходов к "проверке" данных, поступающих от клиентов, наша система объединяет лучшие свойства онлайн (безопасность данных на уровне логики) и оффлайн подхода (возможность работы в автономном режиме), так что нам вроде как есть что предложить рынку.
Re[7]: Какой язык выбрать для erp системы?
От: stalcer Россия  
Дата: 13.01.05 12:11
Оценка: 9 (1) +2
Здравствуйте, Максим Зелински, Вы писали:

Если это коммерческий проект, то я бы посоветовал разработать свой язык (для бизнес логики разумеется, а не для написания ядра ). Тем более для системы-конструктора. Я тоже пишу подобную систему, и считаю что практически невозможно реализовать качественный конструктор, наподобие 1С без своего встроенного языка.
... << RSDN@Home 1.1.3 stable >>
Re[8]: Какой язык выбрать для erp системы?
От: Максим Зелински Россия  
Дата: 13.01.05 13:46
Оценка:
Здравствуйте, stalcer, Вы писали:

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

Я же вроде писал , что пока будем использовать C# для логики, а потом прикрутим язык предметной области.

S>Тем более для системы-конструктора. Я тоже пишу подобную систему, и считаю что практически невозможно реализовать качественный конструктор, наподобие 1С без своего встроенного языка.

Ну вот тут я бы поспорил. C# можно использовать для написания бизнес логики, и мы планируем, что типовые решения из-за скорости будут написаны именно на нём. Встроенный язык мы не будет делать не в коем случае, мы не хотим, чтобы пользователь потом страдал, если ему язык не нравиться. Вместо этого мы предоставим разработчикам фреймворк для подключения любого языка. Тем самым мы можем добавить хоть эмулятор языка 1C, хоть басика
Re[9]: Какой язык выбрать для erp системы?
От: Gaperton http://gaperton.livejournal.com
Дата: 13.01.05 14:15
Оценка: 1 (1)
Здравствуйте, Максим Зелински, Вы писали:

S>>Тем более для системы-конструктора. Я тоже пишу подобную систему, и считаю что практически невозможно реализовать качественный конструктор, наподобие 1С без своего встроенного языка.

МЗ>Ну вот тут я бы поспорил. C# можно использовать для написания бизнес логики, и мы планируем, что типовые решения из-за скорости будут написаны именно на нём.
В базу вы упретесь, в базу и компоненты фреймворка. Как сделаете что-нибудь работающее, померяйте профайлером, сами увидите, если не верите.

Теперь о том, что ИМХО важно на самом деле. Скорость языка для написания типовых решений не важна, важнее другое — нужна легкость поддержки (низкая цена внесения изменений), концептуальная простота языка (только необходимый минимум изобразительных возможностей), а также максимальная заточка языка с фреймворком под предметную область. Последнее самое важное — концептуальная пропасть между средствами языка/фреймворка и предметной областью должна по возможности отсутствовать.

Напишете типовые решения на С# — тем самым не добьетесь ничего, кроме того, что существенно поднимете порог квалификации специалиста по внедрению и цену внедрения. Ведь предполагается, что в типовые решения могут вносится изменения, так?

МЗ>Встроенный язык мы не будет делать не в коем случае, мы не хотим, чтобы пользователь потом страдал, если ему язык не нравиться. Вместо этого мы предоставим разработчикам фреймворк для подключения любого языка. Тем самым мы можем добавить хоть эмулятор языка 1C, хоть басика


Это разумно. Но заметным образом на ваши продажи не повлияет, ИМХО — воспользуются этой возможностью единицы. Впрочем, я не знаю предполагаемую среднюю цену внедрения для вашей системы и описания предполагаемого клиента (с оценкой объема рынка). Это бы все прояснило.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.