OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 14:24

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 123 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7  След.
Автор Сообщение
СообщениеДобавлено: Вторник, 14 Август, 2007 00:04 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Ну, не знаю. Может, Москва действительно другая страна? У меня совершенно другие ощущения. Везде вкладываются огромные деньги в легализацию Windows. Всё бизнес-ПО только под Windows! Например, лучшие программные продукты в области Business Intelligence (а это самая быстроразвивающаяся область, где крутятся колоссальные деньги) - виндусовые (я это хорошо знаю). Исключение составляют СУБД. Это в основном Oracle под всякими юниксами (и Lunix тут не первый!). Получается что-то вроде Windows + качественные приложения - для богатых, а Lunix + кустарные поделки - для бедных. Незаметно, чтобы производители дорогого и качественного ПО переделывали его под Lunix. Это и накладно, и никому не нужно. Я не говорю, что Lunix хуже, чем Windows (мне кажется, что "оба хуже"). Я просто описываю картину, которую вижу. И весьма возможно, что помыкавшись с казалось бы бесплатным софтом, регионы, которые побагаче, тоже мигрируют в сторону Windows. Я не в восторге от этой ОС, но Lunix оказался не способен её вытеснить в секторе дорогого и качественного бизнес-ПО, за исключением серверов. И MS Office тоже ставят себе все начальники и специалисты, оставляя Open Office секретаршам.

Я думаю, что (оставив за скобками хищнические монополистские приемы Microsoft, за что её давно пора лишить охраны авторских прав) причина непотопляемости Windows в умении интегрировать и стандартизировать ПО и форматы данных недоступными для конкурентов способами. Другие явно проигрывают. Скажем, если бы BlackBox позволял использовать библиотеки функций других языков программирования, ЛЕГКО манипулировать WinAPI, не особенно в нём разбираясь, и ЛЕГКО интегрировать программные модули на С++ и Java с модулями на Компонентном Паскале, ему бы цены не было. Я понимаю, что на практике это невозможно. Нет даже интеграции с ближайшим родственником - Delphi.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 14 Август, 2007 00:32 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Кстати, Дельфи, что интересно, оказывается не ближайшим родственником - из-за языка.
Object Pascal и Component Pascal, несмотря на общую часть названия, очень сильно отличаются по средствам, поддерживаемым архитектурным приёмам - и как следствие, по целевым секторам.
Причём Object Pascal в этом смысле оказывается полностью идентичным Яве, но за счёт более последовательной идеологии языка она его таки бьёт...
Подробнее анализ см. viewtopic.php?f=26&t=592


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 14 Август, 2007 21:59 

Зарегистрирован: Четверг, 01 Июнь, 2006 11:14
Сообщения: 240
Сергей Прохоренко писал(а):
Скажем, если бы BlackBox позволял использовать библиотеки функций других языков программирования, ЛЕГКО манипулировать WinAPI, не особенно в нём разбираясь, и ЛЕГКО интегрировать программные модули на С++ и Java с модулями на Компонентном Паскале, ему бы цены не было. Я понимаю, что на практике это невозможно. Нет даже интеграции с ближайшим родственником - Delphi.

зачем привязываться к винапи?
наоборот здорово, что потом модули перенес в линуховую версию ББ и менять ничего не нужно (если я правильно понимаю)
винда и линь будут просто средами для запуска ББ)
да и вообще
вроде КП является не легким, а не является избыточно сложным?
почему ББ должен быть инструментом для работы с винАпи, явой, делфёй и цпп?
тащить чужой груз, чужие проблемы...зачем?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 15 Август, 2007 00:16 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
___ писал(а):
Сергей Прохоренко писал(а):
Скажем, если бы BlackBox позволял использовать библиотеки функций других языков программирования, ЛЕГКО манипулировать WinAPI, не особенно в нём разбираясь, и ЛЕГКО интегрировать программные модули на С++ и Java с модулями на Компонентном Паскале, ему бы цены не было. Я понимаю, что на практике это невозможно. Нет даже интеграции с ближайшим родственником - Delphi.

зачем привязываться к винапи?
наоборот здорово, что потом модули перенес в линуховую версию ББ и менять ничего не нужно (если я правильно понимаю)
винда и линь будут просто средами для запуска ББ)
да и вообще
вроде КП является не легким, а не является избыточно сложным?
почему ББ должен быть инструментом для работы с винАпи, явой, делфёй и цпп?
тащить чужой груз, чужие проблемы...зачем?


Чтобы те 99% программистов, кто вынужденно работает на всем этом безобразии, и те 99% будущих программистов, которые весь этот кошмар изучают, могли с легким сердцем мигрировать на БлэкБокс и развить (в т.ч. своим платежеспособным спросом) его до такой степени, чтобы отпала потребность во всем перечисленном. Опыт Микрософт и ее менее удачливых конкурентов показывает, что если хорошо интегрировать (но не в пользу конкурентов!) даже не шибко хорошие продукты, то успех гарантирован, а если делать идеальный изолированный продукт, то он обречен. Интеграция дает программисту гораздо более широкие возможности, чем многоплатформенность. Если же инструмент не будет решать "чужие", как Вы выразились, но реальные проблемы программистов, то он и не будет нужен, и всей его замечательной многоплатформенностью будет пользоваться лишь узкая группа людей для решения столь же узких задач.

Я, кстати, не верю в 100%-ую автоматическую переносимость одного и того же кода, кроме самого примитивного или далекого от средств ОС. Что-то да придется подлаживать под конкретную ОС. Можно сразу выделить ОС-зависимые модули и сделать их в двух вариантах. Да и многоплатформенность можно обеспечить "кружным" путем - их уже понапридумывали много (кросс-компиляторы, промежуточные языки, рантайм, эмуляторы ОС и т.д. и т.п.). Осталось лишь выстроить их в технологическую цепочку и оформить в виде "мастера" (wizard) переноса на другую платформу. При этом нет ничего зазорного в том, что исходный код некоторых модулей при переносе под другую ОС придется немного подправить.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 15 Август, 2007 00:33 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Я, кстати, не верю в 100%-ую автоматическую переносимость одного и того же кода, кроме самого примитивного или далекого от средств ОС. Что-то да придется подлаживать под конкретную ОС. Можно сразу выделить ОС-зависимые модули и сделать их в двух вариантах. Да и многоплатформенность можно обеспечить "кружным" путем - их уже понапридумывали много (кросс-компиляторы, промежуточные языки, рантайм, эмуляторы ОС и т.д. и т.п.). Осталось лишь выстроить их в технологическую цепочку и оформить в виде "мастера" (wizard) переноса на другую платформу. При этом нет ничего зазорного в том, что исходный код некоторых модулей при переносе под другую ОС придется немного подправить.

По поводу первой части (не-изоляционизма) - я вполне с Вами согласен.

По поводу "100% переносимости" - спец. ОО-паттерны помогают легко разрезать платформозависимую и платформонезависимую часть. Вы можете сначала не поверить, но это факт: в подсистемах System, Text, Forms (~35 тыс. строк) нет НИ ОДНОЙ СТРОЧКИ кода, зависимого от операционной системы! (кроме модуля Kernel, половина нутра которого, кстати, тоже не привязана к ОС). Всё, что привязано к ОС, находится в подсистеме Host, и коммутируется через динамические разъёмы.
Т.е. независимость радикальная: платформонезависимые модули не только не обращаются к ОС напрямую, но и НЕ ИМПОРТИРУЮТ ни одного модуля, который это делает (т.е. не имеют никаких неявных предположений о реализации, "подкручивать" просто нечего). Напротив, модули реализации подлаживаются под общие модули, чтобы "воткнуться" в них должным образом.

Несколько сложнее с зависимостью от разрядности процессора - предположения о 32-бит указателях поразмазаны кое-где по коду, тут требуется поработать...
А вот зависимость от порядка байт (остроконечники-тупоконечники) как раз учтена (ещё бы - на старых Маках был обратный Интелям порядок) и строится по константе Kernel.littleEndian.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 15 Август, 2007 10:37 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
:?: Илья, Вы наверняка знаете, в какой степени уже сейчас код на языке MSIL переноси'м на другие ОС? Я имею в виду FreeBSD, Linux и Mac OS X в рамках проектов Mono и DotGNU. В перспективе мне интересна переносимость на ОС жесткого реального времени для встроенных систем. Где-то я краем глаза видел что-то про MSIL и Pocket PC.

:idea: Если код на языке MSIL переноси'м, то тогда выстраивается хорошая цепочка:

Component Pascal IDE :arrow: код на языке MSIL :arrow: Какой-то компилятор :arrow: исполнимый файл для целевой ОС (+ рантайм .NET)

и можно будет пользоваться богатыми библиотечными возможностями .NET :D в программе на Компонентном Паскале :D , а рантайм .NET обеспечит сборку мусора :D и проконтролирует выход индексов массивов за границы :D .


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 15 Август, 2007 10:50 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Component Pascal IDE

Ну я бы лучше сказал, GPCP - компилятор...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 15 Август, 2007 11:20 

Зарегистрирован: Среда, 28 Февраль, 2007 00:08
Сообщения: 142
Откуда: Нижний Новгород
Сергей Прохоренко писал(а):
Я думаю, что (оставив за скобками хищнические монополистские приемы Microsoft, за что её давно пора лишить охраны авторских прав) причина непотопляемости Windows в умении интегрировать и стандартизировать ПО и форматы данных недоступными для конкурентов способами.

Недавно Sun'овцы сделали плагин для Ворд-2007 сохраняющий OpenXML в ODF и обнаружилось, что OpenXML предложенный для стандартизации несовпадает с реализованным в Ворде. Такие вот "способы стандартизации недоступные конкурентам" :roll:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 15 Август, 2007 11:55 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Аргументы за .NET ясны. Этот вариант нами рассматривался - и рассматривался всерьёз, затем был отложен, только как запасной/второстепенный.
Во-первых, у .NET-машины есть некоторые особенности, которые не позволяют так просто взять - и перейти на неё. Если идти "в лоб" по пути "модуль = сборка .NET", то первый же тупик - это отсутсвие динамической выгрузки сборки в .NET. Это тут же ставит крест на компонентности и на идее интегрированной среды. Единственный путь решения этой проблемы - оставлять свой формат модуля (уже с MSIL-кодом, конечно) и формировать сборку в памяти динамически, через метапрограммирование .NET. Путь не такой простой, и сразу не очевидно, сколько проблем на нём встретится. А есть и другие проблемы - в частности, обработка исключений. Известно, что в Win64 эта проблема есть даже в режиме Native - MS по каким-то причинам отказались от формирования фреймов исключений динамически на стеке, а перешли к режиму прошития спец. данных в исполняемый файл. А если исполняемый файл - это только пускач, а всё остальное грузится динамически? Такое ощущение, что всем системным разработчикам кроме себя самих намеренно ставятся палки в колеса... Чтобы шли на .NET и только на .NET.
Про россыпи подводных камней (плохо или фрагментарно документированных) в изделиях от Microsoft я знаю не по наслышке, когда вводится куча средств для одних и тех же задач, при этом половина вскоре объявляется устаревшей, а другая половина работает совсем не так, как ожидается.

С портами .NET тоже не всё ясно - говорится, что Mono так и не обеспечивает 100%-совместимости.
Порт на не-mainstream ОСи не предвидится и в проекте, ибо это очень трудоёмко. Кто будет портировать на Бутылку, на системы реального времени вроде QNX?
Поэтому путь привязки к .NET после изрядных размышлений кажется не то чтобы тупиковым... но игра не стоит свеч. Напротив, мы сейчас поставили целью получить как самостоятельное изделие портируемый компонентный рантайм для ББ, который мог бы легко и быстро переноситься на любую платформу, вплоть до голого железа. И, как частное решение, потом можно уже и на .NET попробовать.

Спорный вопрос с использованием .NET Framework - ведь все эти классы от МС являются ИХ продуктом, и поставить рантайм Mono недостаточно, а какова ситуация с использованием Framework и на каких условиях?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 15 Август, 2007 12:03 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
А если нужен конкретно и только Компонентный Паскаль под .NET - так ведь уже есть GPCP... Так что проблема с этим остро не стоит.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 15 Август, 2007 17:36 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Илья, спасибо за обстоятельный ответ. В общем, я понял, что компилятор и среду разработки на Компонентном Паскале следует подбирать "динамически" - в зависимости от особенностей конкретной задачи и даже этапа решения задачи. Если нужны обширные библиотеки .NET, совместимость с другими языками и легкость создания исполнимого файла, то Component Pascal IDE и GPCP - компилятор. Если нужна динамическая загрузка/выгрузка модулей и в будущем переносимость программ на Linux (а для системных программистов - также возможность модернизировать под себя среду разработки) - то BlackBox. Если нужна скорость работы программы - то компилятор XDS. Если нужна встроенная система - надо делать компилятор или покупать тот урезанный вариант, который был сделан для вертолета. Не очень просто всё выглядит, особенно если еще добавить лицензирование.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 15 Август, 2007 20:50 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Увы... Лёгкого пути к универсализации пока нет.

Забыл добавить - как раз к вопросу о фрагментарности... Кроме названных качеств разрабатываемой подсистемы времени выполнения, мы пробуем понемногу двигаться в сторону возможности мультиязыкового рантайма. Т.е. хотелось бы, что бы общий рантайм мог использоваться для нескольких языков, хотя бы Оберон-семейства. К примеру, Component Pascal и Active Oberon...
Потому что несовместимость и взаимоисключительность всех Оберонов - штука малоприятная.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 15 Август, 2007 21:53 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Илья Ермаков писал(а):
Увы... Лёгкого пути к универсализации пока нет.

Забыл добавить - как раз к вопросу о фрагментарности... Кроме названных качеств разрабатываемой подсистемы времени выполнения, мы пробуем понемногу двигаться в сторону возможности мультиязыкового рантайма. Т.е. хотелось бы, что бы общий рантайм мог использоваться для нескольких языков, хотя бы Оберон-семейства. К примеру, Component Pascal и Active Oberon...
Потому что несовместимость и взаимоисключительность всех Оберонов - штука малоприятная.


Я не думаю, что при почти нулевой популярности и скудных библиотеках совместимость Оберонов крайне необходима. Чем им делиться друг с другом? Они все нищие, голые и босые. :? Может, проще сделать трансляторы с разных Оберонов в Component Pascal (языки то очень похожи, многое можно оставлять без изменений), а сложные для трансляторов места оставлять программисту? Правда мой опыт автоматической трансляции с Турбо-Паскаля на Компонентный Паскаль был неудачным: синтаксис языка перевелся с небольшими ошибками, вроде увеличения длины массивов на единицу, зато процедуры ввода-вывода вставились из несуществующего модуля. Я не нашел такого модуля ни в поставке БлэкБокса, ни даже в интернете. Видимо, на качестве этого транслятора сказалось отсутствие эталонной (стандартной) библиотеки для Компонентного Паскаля. :(

:idea: Зато для далеких от Компонентного Паскаля, но популярных языков с богатыми библиотеками мультиязыковый рантайм был бы очень полезен для популяризации самого Компонентного Паскаля. Как насчет мультиязыкового рантайма Компонентный Паскаль + MSIL? В смысле, что оригинальный .NET-рантайм вместе с библиотекой сажается в виртуальную "клетку" и лишь обеспечивает выполнение библиотечных функций .NET в Windows-зависимых модулях. Аналогично, не помешал бы мультиязыковый рантайм для Java.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 15 Август, 2007 22:19 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
У OberonMicrosystems есть версии среды (и ОС), позволяющие выполнять в общем адресном пространстве модули КП и классы Явы. Вообще говоря, даже элементарные типы в КП намеренно приводились к совместимости с Явой.
Увы, в Open-Source ничего от Ява-версии не досталось... Видать, это их хлеб, точно так же, как для Excelsior теперь хлеб не XDS, а JET...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 15 Август, 2007 22:21 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
А по поводу "нищи, босы и голы" - это не совсем так. ETH Oberon много лет была рабочей системой цюрихских учёных, под неё реализовано приличное количество софта самого разного назначения. В совокупности с Oberon V4, Бутылкой - те же архиваторы, сетевые протоколы, поддержка файловых систем... Хотелось бы это дело попользовать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 30 Август, 2007 15:29 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Хочу высказать свои мысли по поводу вопросов, поднятых Сергеем Прохоренко. Если какие-то мысли Сергея сформулировал не точно, прошу поправить, поскольку сразу читал страницы 2-5, в голове отложилось общее впечатление - в деталях могу ошибиться.

- Задачи на массивы, - мало готовят для реальных творческих задач и т. п. Простой инструмент (без всяких полезных средств, облегчающих ввод и т. п.) - для начинающего сложность, для обучения - минус.
Сергей, мне кажется, что преподаванием программирования Вы профессионально не занимались. Прошу меня заранее извинить, если я ошибся, и Ваши высказывания основаны на конкретном опыте - в этом случае было бы интересно, чтобы Вы более подробно пояснили свое мнение и поделились конкретным опытом. Иначе это равносильно тому, что, например, Вы никогда не работали в Access, а нам рассказываете как там работать.
Я тоже самоучка, осваивал "программирование" либо методом тыка, либо по убогим книгам. Ко всяким паскалям и учебным задачкам у меня было пренебрежительное отношение. Многие вещи стал переосмысливать после 3 лет преподавания, и теперь я жалею, что не было учителя, который мне давал бы такие задачки и учил правильно программировать (а точнее - составлять алгоритмы). Это сэкономило бы для меня уйму времени. Что такое инвариант цикла узнал в прошлом году (хотя слово это мне попадалось лет 8 назад). :) Вот мое мнение сейчас:
Когда речь идет об обучении программированию - она идет прежде всего об обучению составлению алгоритмов. Все внимание должно быть сфокусировано именно на алгоритме, как последовательности действий, которую учащийся должен составить от начала до конца и при этом понимать и осмысливать каждый шаг. Лишь после этого он может приступить к записи алгоритма - и тут не важно как его писать - полностью от руками, при помощи кнопок или шаблонов. Это уже детали. Можно даже вообще работать без компьютера - с ручкой и бумагой - а исполнять записанный алгоритм будет сам учащийся.
Однако, сейчас, поскольку компьютеры есть везде и работают обычно сразу с ними - получается параллельное освоение учащимся и навыка "составления алгоритмов" и навыка "использования какого-либо инструмента". Поскольку первый навык является целью обучения, сложность освоения второго должна стремиться к минимуму (чтобы акцентировать внимание на первом, не сбивать с него внимание, не создавать дополнительных трудностей и т. д.) - что достигается при наиболее простом инструменте.
Если дать учащемуся тот инструмент, который предлагаете Вы, - да он его по-любому освоит, с ним он будет записывать алгоритм быстрее, - но 100% внимание сместится на освоение инструмента - и драгоценное время будет потеряно - тем больше, чем сложнее-удобнее наш инструмент.

- Построитель в Access удобен.
Это субъективное мнение. Кому то он удобен, кому то нет.
Про себя скажу: первое мое впечатление при изучении Access - я был просто в шоке от количества элементов управления, обилия кнопок и проч. Считаю также, что лучше бы меня в университете обучили основам теории баз данных и основам SQL, нежели обучали тыканью кнопок в вызыванию визардов в Access - при этом про базы данных я не получил никакого представления. Сейчас, когда я знаком с SQL, в Access для меня удобнее писать SQL запрос, нежели ковырять кнопки в построителе.

Построители и всякие кнопки полезны при изучении самого инструмента.
Тут я считаю не стоит забывать психологию. При обучении надо учитывать тип мышления обучаемого. Насколько я помню курс возрастной психологии (точность не гарантирую), с подросткового возраста 11-13 лет начинает формироваться абстрактно-логическое мышление, когда человек мыслит словами, фразами языка. До этого мышление основано на образах предметов и т. п.
Если мы будем обучать малого ребенка работе в Access - вопрос только зачем ему это, то кнопочки и всякие построители тут на руку - он видит с чем работает. Чтобы получить то то и то то - он должен нажать кнопку с той или иной картинкой...
Если же речь идет о взрослых людях, студентах (котрых надо научить учиться, мыслить) - обучение их тыканью кнопок - сведение их до уровня малых детей, которое ничего хорошего в развитии не даст, мыслить не научит и будет вести к отупению. На примере того же Access - основы теории БД, основы языка SQL - человек может решать свои задачи и мыслить при помощи языка. После уже можно показать, как запись на языке (для тех кто медленно набирает) можно ускорить при помощи всяких кнопок и диалогов.
Несомненно, что последний подход труднее в освоении. Однако, вспомним - "Математику уже затем учить надо, что она ум в порядок приводит." А математика тоже наука абстрактная и не простая в изучении. А надо ее учить или не надо - да просто сравним средний уровень образованности наших людей и, скажем, американцев. Надо учить математике всех или не надо - когда взрослый человек не может сложить "половину с третью" и не знает, "сколько будет стоить 1 метр чего-то, если 100 стоит 7 долларов"? Надо учить физике или не надо - когда засудили бедную компанию по производству фенов, которая не написала в руководстве, что нельзя использовать фен под душем; или другую компанию, которая не написала, что кошек в микроволновке сушить нельзя? Если америкосы в своем большинстве такие дэбилы и им это нравится, так это их дело, и очень прискорбно, что люди, особенно чиновники от образования, начинаю перенимать методы и программы обучения. Уже сейчас все ВУЗы жалуются, что уровень поступающих сильно упал. Будем идти дальше в этом направлении - и нам ничего не останется, как стать тем сырьевым придатком запада, который они из нас усиленно пытаются сделать.

Надо идти по пути максимальной интеграции
Насчет максимальной интеграции - особенно с MS и их стандартами - тут лучше почитать статью бывшего работника MS. Ссылку на нее приводили или на этом форуме или на форуме http://forum.phys-math.ru - возможно подскажет Борис Рюмшин. Смысл статьи такой - MS плодит всякие технологии - которые играют роль заградительного огня по конкурентам. И те, кто пытается все это поддерживать, просто изнемогают, тратя кучу времени на изучение новинок от MS и прикручивания их поддержки к своим продуктам, в то время как MS идет своим путем дальше.

Резюме:
- Всякие рюшечки и прочие вспомогательности - это маркетинговый шаг. На него разумно идти специально, если только есть свободные ресурсы, которые не задейстованы в более важных местах.
- Никакой интеграции нам не надо. Нужен независимый качественный передовой продукт, который будет удовлетворять наши потребности. Если интеграция и понадобиться - то это опять же маркетинговый шаг, и делаться она должна поверх независимой основы - насколько получится.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 30 Август, 2007 21:20 

Зарегистрирован: Понедельник, 29 Январь, 2007 19:00
Сообщения: 370
Откуда: Украина, Запорожье
Евгений Темиргалеев писал(а):
Насчет максимальной интеграции - особенно с MS и их стандартами - тут лучше почитать статью бывшего работника MS. Ссылку на нее приводили или на этом форуме или на форуме http://forum.phys-math.ru - возможно подскажет Борис Рюмшин.


http://russian.joelonsoftware.com/Articles/FireAndMotion.html


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 30 Август, 2007 23:01 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Евгений Темиргалеев писал(а):
Хочу высказать свои мысли...


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 31 Август, 2007 09:50 

Зарегистрирован: Пятница, 29 Июнь, 2007 12:16
Сообщения: 98
Вводят они в заблуждение или нет в данном случае не важно. В принципе, не очень понятно, во что превратился вопрос. Насколько я понимаю, прикручивать к ББ какую-нибудь фиговину или нет - личное дело каждого разработчика или учителя(хотя конечно хотелось бы немного автоматизировать процесс прикручивания - откручивания). Так в чем же дело? Большинство местных обитателей говорят, что им этот инструмент не нужен, это означает всего навсего то, что они его не будут разробатывать и в случае чего использовать. Но никто не мешает таки разработать этот инструмент и предоставить его на общественное рассмотрение, не так ли?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 31 Август, 2007 10:26 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток
Цитата:
Большинство местных обитателей говорят, что им этот инструмент не нужен, это означает всего навсего то, что они его не будут разробатывать и в случае чего использовать.

Это да. Я как-то делал приблуду, которая автоматически при вводе переводит ключевые слова в верхний регистр и немного раскрашивает структуру программы. Так вот даже сам не пользуюсь. При переустановке ББ ставить было лень :)


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 123 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 14


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB