OberonCore

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

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




Начать новую тему Ответить на тему  [ Сообщений: 17 ] 
Автор Сообщение
СообщениеДобавлено: Суббота, 17 Апрель, 2010 18:35 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
А вот как надо управлять разработкой на платформе Apple:

Цитата:
в правила внесли пункт, запрещающий использовать для разработки программ какие-либо инструменты и языки программирования, отличающиеся от того, что входит в фирменный IDE Xcode. Под угрозой в одночасье оказались не только создатели альтернативных инструментов, но и авторы многих (от сотен до нескольких тысяч) приложений, созданных с их применением.


Цитата:
Стоит вспомнить, к примеру, случай с использованием закрытых API. Компания долго злила разработчиков тем, что не давала пользоваться теми же инструментами, которые применяла в своих приложениях. В итоге оказалось, что в Apple планировали радикально изменить закрытые программные интерфейсы. После изменения большая часть из них стала публичной. Действуй Apple мягче и разреши доступ к закрытым API раньше времени, переделывать их было бы труднее. Компании пришлось бы встать перед выбором: портить чужие приложения или не обновлять платформу.


http://www.computerra.ru/terralab/softerra/524364/


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 17 Апрель, 2010 20:51 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
В обероне как раз нет ни жесткости не неизменности, каждый лепит те расширения языка и трактует сообщение о языке так, как хочет :-)

Благо язык маленький, карманный можно сказать. Модифицировать его одно удовольствие.

Относительная неизменность BB скорее из за того, что просто мало народу им занимается. Т.е. банально мало ресурсов привлечено. Да и то, даже несмотря на малость ресурсов имеем уже сколько версий BB? Две? Три? Четыре? 1.5 официальная, 1.6 какая-то там бета. юникодная версия. русифицированная верси. версия под линух (две штуки). Вот ещё хотят видоизменить язык ( :!: ) чтобы портировать его на 64 бита. :-)

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


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

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

В том и штука, что для простых систем он гораздо менее болезнен, чем для громоздких.

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

"Всякие питоны" в плане адаптируемости тоже непосильны, потому что рантайм любого такого языка - здоровенный ящик запаянный, написанный всё на том же С, ну и т.п.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 17 Апрель, 2010 21:06 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Идёт процесс эволюции..

В том и штука, что для простых систем он гораздо менее болезнен, чем для громоздких.

Ясное дело.

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

Угу. И вне зависимости от размеров языка это черевато как минимум не совместимостью с адаптированными инструментариями других контор. Это называется -- зоопарк языков. И это вроде как уже проходили :-)

Цитата:
"Всякие питоны" в плане адаптируемости тоже непосильны, потому что рантайм любого такого языка - здоровенный ящик запаянный, написанный всё на том же С, ну и т.п.

Рантайм всяких питонов написан на всяком питоне. См. PyPy.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Alexey Veselovsky писал(а):
Угу. И вне зависимости от размеров языка это черевато как минимум не совместимостью с адаптированными инструментариями других контор. Это называется -- зоопарк языков. И это вроде как уже проходили :-)


Ну, язык менять в ста вариациях никто и не станет... Но деталировка какая-нибудь, модификации среды и проч. - почему нет?

Ещё раз: для маленьких систем ничего тут страшного нет. Стандарты де-факто прекрасно работают.

(По поводу "контор"... Я исхожу из того, что по возможности серьёзная контора стремится строить "натуральное хозяйство". И это разумно.)


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Alexey Veselovsky писал(а):
Рантайм всяких питонов написан на всяком питоне. См. PyPy.
Страшную картину воображение рисует... или это после Звонаревой мозг так?


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

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Alexey Veselovsky писал(а):
Угу. И вне зависимости от размеров языка это черевато как минимум не совместимостью с адаптированными инструментариями других контор. Это называется -- зоопарк языков. И это вроде как уже проходили :-)


Ну, язык менять в ста вариациях никто и не станет... Но деталировка какая-нибудь, модификации среды и проч. - почему нет?

Хм. А например? Дотачивание работы с памятью? Дык во всяких адах и плюсах это делается средствами языка. Если язык не предоставляет абстракций пригодных для прозрачной подмены менеджмента памяти, то да, нужно слегка дотачивать рантайм-окружение. Т.е. среду. Что тут будет проще -- дотачивать ли окружение простого языка, или языковыми средствами менять менеджмент памяти в сложном языке -- фиг знает. Мне кажется что примерно то на то и выходит.

Когда сложный язык не предоставляет годного инструмента для абстрагирования от менеджмента памяти (например ява, или c#), то остается только менять среду, или городить вообще бог весть что. Тут да, я тремя руками за обероны. Ибо это ж застрелиться проще. чем лезть в рантайм какого-нибудь .net'a. Одно неверное движение при правке тамошнего GC (который нифига не простой), и всё.

Илья Ермаков писал(а):
Ещё раз: для маленьких систем ничего тут страшного нет. Стандарты де-факто прекрасно работают.

Ну ведь не получится взять скажем из второго оберона (скажем из набора либ oo2c) какой-то модуль и спокойно себе использовать в BB. Придется всяко ручками править. Как минимум синтаксис. Также я вот ну совсем не уверен что оно же корректно заработает (если на это не тестировалось) в XDS. Или в класических оберонах.

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

Илья Ермаков писал(а):
(По поводу "контор"... Я исхожу из того, что по возможности серьёзная контора стремится строить "натуральное хозяйство". И это разумно.)

Зависит от рода деятельности оной серьезной конторы :-)

PS. Нет, я не против оберона. Если мне вдруг захочется/потребуется реализовать язык для некой специфической области (скажем для некой железяки новой, или в качестве эдакого императивного DSL для хаскеля, что, кстати, актуально), то я за основу скорее всего возьму именно Оберон (скорее всего либо Оберон-1 либо Оберон-07) и модифицирую его под данную задачу (синтаксис, возможно систему типов, быть может что-то будет выкинуто, вроде расширяемых записей, если они не нужны в данном случае будут и т.п.), может что-то добавлено (например вывод типов). Но за основу имеративного языка в любом случае стоит брать именно оберон. Ибо сухая выжимка императивщины. Реализовывать даже огрызок скажем ады... Ну вы поняли. Для того чтобы сделать огрызок нужно вначале понять всю аду и понять что там нам нужно а что нет. Про С++ я таки умолчу. Си -- имеет жуткий неоднозначный синтаксис и такую же типизацию. Всякие паскали брать не имеет смысла, ибо оберон по всем статьям лучше. Про всякие Lua/Python и проч. динамически типизированную фигню даже думать не хочу. Вот. как-то так.

Каждому инструменту своя задача ;-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 17 Апрель, 2010 23:58 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Да, а питон.. Питон суть отрыжка мейнстрима.


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

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Alexey Veselovsky писал(а):
В обероне как раз нет ни жесткости не неизменности
Не считаю. Принципиальных изменений мало.

Alexey Veselovsky писал(а):
Да и то, даже несмотря на малость ресурсов имеем уже сколько версий BB? Две? Три? Четыре? 1.5 официальная, 1.6 какая-то там бета. юникодная версия. русифицированная верси. версия под линух (две штуки).
Те же яйца, только сбоку. Views, Controllers, Files, Documents и пр. как были, так и есть.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 18 Апрель, 2010 00:21 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Иван Кузьмицкий писал(а):
Alexey Veselovsky писал(а):
В обероне как раз нет ни жесткости не неизменности
Не считаю. Принципиальных изменений мало.

Достаточно чтобы сделать их несовместимыми :-)

Иван Кузьмицкий писал(а):
Alexey Veselovsky писал(а):
Да и то, даже несмотря на малость ресурсов имеем уже сколько версий BB? Две? Три? Четыре? 1.5 официальная, 1.6 какая-то там бета. юникодная версия. русифицированная верси. версия под линух (две штуки).
Те же яйца, только сбоку. Views, Controllers, Files, Documents и пр. как были, так и есть.

Да, про многопоточную версию забыл ещё.
Ну, с этой т.з. С++ также жесткий и не изменный. Ведь в MFC ничего принципиально не меняется :-) Более того, там даже есть обратная совместимость! (ну, или почти есть ;-) )
Это если следовать той же логике.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 18 Апрель, 2010 00:39 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Даже если очень бегло глянуть на зоопарк реализаций питона, то обероны с блэкбоксами здесь просто отдыхают :) Так что с "Изменяемость похлеще чем даже у питона какого" Вы не угадали :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 18 Апрель, 2010 01:02 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Иван Кузьмицкий писал(а):
Даже если очень бегло глянуть на зоопарк реализаций питона, то обероны с блэкбоксами здесь просто отдыхают :) Так что с "Изменяемость похлеще чем даже у питона какого" Вы не угадали :)

А где там зоопарк? Есть референсная (и единственно реально используемая) реализация -- CPython. Остальные либо пытаются мимикрировать под него (и часто частично на нем базируются), соответствовать ему (в плане языка и базовых либ, естественно), либо создают свой собственный диалект который собственно никто за питон не считает. :-) ). Более того, развитие CPython специально притормозили (конкретно -- заморозили ветку 3.х в плане развития языка), чтобы те кто следует за лидером, могли подтянуться и реализовать всё что не реализовано.

Разброда и шатаний как бы особо и нет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 18 Апрель, 2010 09:09 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Alexey Veselovsky писал(а):
Да, а питон.. Питон суть отрыжка мейнстрима.
Суть--sunt--sont--sind = множественное число третьего лица. Они/оне суть.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 18 Апрель, 2010 09:11 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Иван Кузьмицкий писал(а):
Alexey Veselovsky писал(а):
В обероне как раз нет ни жесткости не неизменности
Не считаю. Принципиальных изменений мало.
Может смутить расширяемость Оберонов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 18 Апрель, 2010 10:14 

Зарегистрирован: Воскресенье, 03 Февраль, 2008 12:50
Сообщения: 249
Alexey Veselovsky писал(а):
Рантайм всяких питонов написан на всяком питоне. См. PyPy.

Не вводите людей в заблуждение. :)
Во-первых, (потом Вы таки написали об этом) PyPy - это не reference implementation.
Во-вторых, PyPy does not support the CPython C API, which means that third party libraries for python, written in C, will not work. А это знаете ли очень много нужных библиотек. Работа с БД (кроме sqlite, по-моему нет ни одной реализации не на С), NumPy, ...
В-третьих, (пожалуй самое главное) PyPy написан не на Python, а на Restricted Python (RPython). А он статически типизированный, не поддерживает генераторы + ограничения на кортежи, списки + methods and other class attributes do not change after startup. Короче, и не Python это совсем. Так слегка расширенная Modula-3 с питоновским синтаксисом и питоновской стандартной библиотекой.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 18 Апрель, 2010 10:41 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Alexey Veselovsky писал(а):
А где там зоопарк? Есть референсная (и единственно реально используемая) реализация -- CPython.


Набросаю в Вашем же стиле (упомянуть разные версии ББ, из которых на самом деле только 1.5 стандарт, а 1.6 - юникодный, причём лично я пробовал программы, написанные в 1.5, успешно запускать в 1.6 и наоборот):

Цитата:
CPython является основной, но не единственной реализацией языка программирования Python. Существуют также следующие реализации:

Jython — реализация Python, использующая JVM в качестве среды исполнения. Позволяет прозрачно использовать Java библиотеки.[60]

PyS60[43] — реализация Питона для (некоторых) смартфонов фирмы Nokia.

IronPython — Python для Microsoft .NET и Mono. Компилирует Python программы в MSIL, таким образом предоставляя полную интеграцию с .NET системой.[61]

Stackless[62] — также написанная на С реализация Python. Это не полноценная реализация, а патчи к CPython. Предоставляет расширенные возможности многопоточного программирования и значительно большую глубину рекурсии.

Python for .NET[63] — ещё одна реализация Python для .NET. В отличие от IronPython эта реализация не компилирует Python код в MSIL, а только предоставляет интерпретатор, написанный на C#. Позволяет использовать .NET сборки из Python кода.

PyPy[64] — реализация Python, написанная на Python. Позволяет легко проверять новые возможности. В PyPy кроме стандартного CPython включены возможности Stackless (англ.), Psyco (англ.), модификация АСТ «на лету» и многое другое. В проект интегрированы возможности анализа Python кода и трансляция в другие языки и байтокоды виртуальных машин (C, LLVM, Javascript, .NET с версии 0.9.9). Начиная с 0.9.0, возможна полностью автоматическая трансляция интерпретатора на C, в результате чего достигается скорость, приемлемая для использования (в 2—3 раза медленнее чем CPython при отключённом JIT для версии 0.9.9). JIT находится в активной доработке.

python-safethread[54] — версия CPython без GIL, что позволяет одновременно исполнять Python потоки на всех доступных процессорах. Внесены также некоторые другие изменения.

Unladen Swallow[42] — начатый Google проект по разработке высокоэффективного, максимально совместимого с CPython JIT-компилятора на базе LLVM.

tinypy[65] — минималистическая версия Python. Часть возможностей CPython не реализована.


Цитата:
Специализированные подмножества/расширения Python

На основе Python было создано несколько специализированных подмножеств языка, в основном предназначенных для статической компиляции в машинный код. Некоторые из них:

RPython[68] — созданная в рамках проекта PyPy сильно ограниченная реализация Python без динамизма времени исполнения и некоторых других возможностей. RPython код можно компилировать во множество других языков/платформ — C, JavaScript, Lisp, .NET[69], LLVM. На RPython написан интерпретатор PyPy.

Pyrex[28] — ограниченная реализация Python, но несколько меньше, чем RPython. PyReX расширен возможностями статической типизации типами из языка С и позволяет свободно смешивать типизированный и не типизированный код. Предназначен для написания модулей расширений, компилируется в код на языке С.

Cython[70] — расширенная версия Pyrex.

pyastra[71] — компилятор Python кода в ассемблер для PIC архитектуры.

Проект shed-skin[30] — предназначен для компиляции неявно статически типизированного Python кода в оптимизированный код на языке С++, проект далёк от завершения.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 18 Апрель, 2010 11:40 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
kemiisto писал(а):
Alexey Veselovsky писал(а):
Рантайм всяких питонов написан на всяком питоне. См. PyPy.

Не вводите людей в заблуждение. :)
... Короче, и не Python это совсем. Так слегка расширенная Modula-3 с питоновским синтаксисом и питоновской стандартной библиотекой.
Спасибо, ценно :)

(Еще пример комбинаторных игрищ приматического ума...)


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 17 ] 

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


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

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


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

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