Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Темы - vlad

Страницы: 1 2 [3]
31
Общий раздел / автомобили-роботы
« : Февраль 20, 2012, 06:18:50 pm »

32
Общий раздел / обучение управлению памятью
« : Февраль 10, 2012, 04:18:48 pm »
Поскольку сам info21 цитирует нас на своем ресурсе, то нельзя не прокомментировать :) Вот альтернативная ссылка: http://forum.oberoncore.ru/viewtopic.php?p=70577#p70577
(конечно ссылку на оригинал info21 не дал, ну так что ж с него возьмешь...)

Цитата: Info21
Сформулирую главную мысль покороче, повторившись в 100000-й раз:

В отличие от всевозможных интерпретируемых языков (ФЯ и проч.)

ФЯ не обязан быть интерпретируемым. Еще более странно это слышать от info21, который в свое время утверждал, что оберон хорошо покрывает функциональную парадигму.

Цитата: Info21
автоматическое управление памятью в Обероне позволяет разделить (DIVIDE ET IMPERA) две важные и разные вещи:

фазу проектирования структур данных -- когда нужные структуры данных еще не известны -- и

фазу их оптимизации -- когда структуры данных в случае нужды (sic) отображаются на статическую память.

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

33
Общий раздел / Новый раздел
« : Февраль 04, 2012, 03:15:37 am »
Есть предложение отделить от "общего" раздела новый, имеющий непосредственное отношение к разработке ПО.

34
Общий раздел / Рукописи не горят
« : Январь 27, 2012, 03:32:04 pm »
Предлагю фиксировать здесь избранное с оборонкоре, пока его не отмодерировали :)

оригинал: http://forum.oberoncore.ru/viewtopic.php?p=70134#p70134
Цитата: Сергей Губанов
Цитата: Илья Ермаков
Нормальный же цикл - обсудили, породили "сырьё", структурировали, выделили зёрна. Ну кто будет через месяц перечитывать целиком 10 страниц трёпа, даже из самих обсуждающих?
Зёрна можно выделять методом копирования интересного, а вовсе не уничтожения неинтересного.

---------------------------------------------------------------------------------------------------------------------

Если нет гарантии неприкосновенности авторского текста (включая контекст, в котором он написан), то желание писать что-то серьёзное вкладывая душу совершенно пропадает.

Давайте представим следующую ситуацию. Допустим некий Чокнутый Доктор 21 угробил кучу ресурсов и написал сочинение на 22 страницы под названием "Теория двух типов ума". А в один прекрасный день модератор эту ветку раздраконил. Часть выкинул вообще, часть поместил в отвлечённые темы. Мотивировал тем, что "по своему усмотрению" Администрация всегда может сделать что угодно. Отвлечённые темы не индексируются поисковиками, видны только зарегистрированным пользователям, таким образом все труды Чокнутого Доктора 21 оказались слиты в унитаз.

Короче, жизненно необходимо иметь гарантии:
1) Неприкосновенность авторского текста.
2) Неприкосновенность области его видимости (если автор решил, что его текст должен быть виден всему Интернету, а не зарегистрированным пользователям, то так и должно быть).

Если бы Чокнутому Доктору 21 этого не гарантировали, то он ни за что на свете не опубликовал бы здесь свою теорию.

35
Общий раздел / Часто замечаю за собой
« : Январь 27, 2012, 05:12:40 am »
Предлагаю обсудить здесь тему отсюда: http://forum.oberoncore.ru/viewtopic.php?p=70068#p70068

По поводу нулевых указателей. Проблема частично языковая (нет в языке средств статического контроля). Но чаще всего это следствие дизайна. Компонент допускает "непроиниченность".  Или  задает протокол типа "get/set", делегируя на пользователя ответственность за то, что и когда туда выставляется и берется. Ошибиться становится легко.

По поводу второго пункта. Не уверен, что правильно понял в чем проблема. Как я понял, речь идет о том, что есть красивый общий интерфейс, который подразумевает функциональность, которая на деле реализована лишь частично. Мой подход такой, что красивый интерфейс приносится в жертву суровой реальности. Либо неподдерживаемая функциональность ассертится сразу на входе.

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

36
Общий раздел / Почему не взлетел Juice
« : Ноябрь 03, 2011, 03:28:32 pm »
В продолжении темы http://oberspace.dyndns.org/index.php/topic,149.0.html.  Посмотрел чуть ближе на Juice (спасибо Илье Ермакову за архив).
Итак:
- Требование специальной и специфической среды (Windows Oberon System 3). Т.е. это не просто рантайм, а именно среда. "Вещь в себе" - про что я и говорил.
- Упор сделан на далеко не самое главное свойство "ЯП для Web" - размер скомпилированного бинаря. Это все очень хорошо, но после того как можно просто взять страницу с жабаскриптом и посмотреть как оно будет выглядеть будучи переписанной на другом ЯП (оберон). Компиляция чего-то куда-то здесь совсем не в тему.
- Проблемы жабаскрипта, которые теоретически мог бы решить "оберон для Web"  никак не обозначены и не решены. Т.е. все знают, что на обероне можно делать расширяемые модульные контроллируемые системы, но куда и сколько еще надо точить конкретно представленнуюу штуку - непонятно.

37
По мотивам http://forum.oberoncore.ru/viewtopic.php?p=63851#p63851
Итак, имеем:
  • Единое адресное пространство и много потоков в терминах ОС.
  • Допиленный ББ (или другой ЯП) в котором каждый поток может иметь доступ только к своим объектам - объекатм, которые он сам создал и который он сам освободит.
  • Взаимодействие между потоками осуществляется только через сообщения (сериализуемые объекты).
Очевидные достоинства такого подхода:
  • Отсутствие race conditions для разделяемых данных (потому что их нет, хе-хе).
  • Сильно упрощается сборка мусора.
  • Больше поводов правильно инкапсулировать компоненты :)
  • А вот дедлоки все равно остаются :)

Как я понимаю, такая схема хорошо работает для случаев а-ля "один поток попросил что-то сделать, другой поток сделал". Хотелось бы комментариев от людей, которые щупали это на практике, применительно к другим случаям:
1. Насколько эффективно такой подход работает для случаев, когда один поток что-то делает и имеет обновляемый статус/данные, а куча других потоков читает этот статус/данные. По сравннию с классическими локами на запись/чтение.
2. Как передавать большие объемы данных между потоками. Вопрос прежде всего к Илье и его ББ, потому как в других языках (эрланг - пусть Алексей Веселовский подтвердит) такая проблема нивелируется иммутабельностью данных.

38
Общий раздел / Steve Jobs On MS
« : Апрель 04, 2011, 03:15:56 pm »
Цитировать
Steve jobs: Apple had a monopoly on the graphical user interface for almost 10 years. That's a long time. And how are monopolies lost? Think about it. Some very good product people invent some very good products, and the company achieves a monopoly. But after that, the product people aren't the ones that drive the company forward anymore. It's the marketing guys or the ones who expand the business into Latin America or whatever. Because what's the point of focusing on making the product even better when the only company you can take business from is yourself? So a different group of people start to move up. And who usually ends up running the show? The sales guy... Then one day, the monopoly expires for whatever reason. But by then the best product people have left, or they're no longer listened to. And so the company goes through this tumultuous time, and it either survives or it doesn't.

BusinessWeek: Is this common in the industry?
Steve Jobs: Look at Microsoft -- who's running Microsoft?

BusinessWeek: Steve Ballmer.
Steve Jobs: Right, the sales guy. Case closed."

Read more: http://www.electronista.com/articles/11/04/03/microsoft.mobile.failure.pinned.on.windows.pride/#ixzz1ITeA7Y73

39
оригинальная ветка: http://forum.oberoncore.ru/viewtopic.php?p=61461#p61461

Цитата: igor
Суть проблемы, вроде как, состоит в том, что три дискретных числовых оси не совпадают. Эти дискретные числовые оси соответствуют десятичному представлению и двум двоичным (SHORTREAL и REAL).

Суть проблемы не только в различии представления, но и вообще в потере точности при вычислениях. Те же самые грабли вы получите с одним и тем же вещественным типом, сравнив на равенство результаты 2/3 и 4/6. Так что идея запретить в языке сравнение вещественных типов не такая уж и плохая, учитывая что многие руководства по граблям так и пишут "не сравнивайте на равенство вещественные типы".

40
Сейчас, вроде, сделано так, что все функции всегда возвращают результат в регистрах проца. Если разрешить функциям возвращать записи, то этой эффективной реализации придёт кирдык.  :)

Неправда :) Сейчас функции "возвращают" записи как VAR-параметр. Так что вопрос сугубо синтаксический. Никто не мешает компилятору по-прежнему использовать VAR-параметр, просто но будет скрытый. А с точки зрения синтаксиса - все будет единообразно.

41
Общий раздел / Допилить оберон под себя
« : Март 09, 2011, 02:41:10 pm »
Про идеальный ЯП поговорили. Давайте про реальный: чего нужно допилить в КП (как наиболее "реальном" обероне) лично для вас, чтобы можно было его использовать вместо вашего текущего ЯП для текущих задач (если бы все пришлось писать заново). Оставим за скобками инфраструктуру (библиотеки, IDE и т.д.) - только сам язык. Вот мой список (в порядке уменьшения значимости):

1.Параллельные вычисления. Не знаю в каком виде, но нечто более высокоуровневое, нежели "вот вам стандартный мьютекс - а дальше вы сами разбирайтесь". ActiveOberon - тоже слишком низкоуровнево. Как минимум, на уровне языка должны быть полностью решены проблемы конкурентной модификации данных.
2. Обработка ошибок. Что-нибудь более продвинутое, чем явное таскание кода ошибки.
3. Обобщенное программирование. Хотя бы на уровне контейнеров и алгоритмов. Чтобы не изобретать в 10 раз за день список и не писать WHILE там, где на самом деле foreach.
4. Замыкания. Принципиально упрощают код, по сравнению с закатами солнца вручную.
5. Что-то для работы с ресурсами в scope (хотя бы аналог шарпового using).
6. Объявление переменных по месту. Писать с допотопным VAR'ом я уже не смогу :)
7. Синтаксис. Ну да, можно скрипеть зубами, писать КАПСОМ и расставлять все эти точки с запятой. Но после питона от нового языка хочется чего-нибудь человеческого.

P.S. Кстати, питон удовлетворяет этому списку, за исключением пункта 1. Ну и динамической типизации :) Есть еще хаскель... :) Но хотелось бы пойти от базового, понятного и простого.

42
Общий раздел / Функции против процедур
« : Февраль 27, 2011, 03:19:08 am »
Обсуждение как-то затерялось в общем потоке, поэтому решил выделить в отдельную тему.
Итак, из того, что было сказано, я понял, что смысл разделения процедура функция сводится к (поправьте):
1. Функция не имеет побочных эффектов.
2. Процедура не возвращает значения (или косвенно возвращает через OUT-аргументы).

По поводу пункта 1 у меня никаких возражений нет - да, хочется контролировать побочные эффекты. И такое разделение иметь полезно, пока мы имеем некий компромиссный ЯП (не хаскель ;)
По поводу пункта 2 - вообще непонятно зачем такое ограничение. Пусть возвращает нормальный результат. Зачем кому-то нужны OUT-параметры?

Далее по реализации. Если брать за базу оберон, то какие изменения нужны в языке, чтобы обеспечить пункт 1? Если ничего нельзя сделать - тогда извините, но такое разделение совсем не нужно и плодит лишние сущности.
Конкретно хочется услышать ответ на вопрос: если мы запрещаем из функции обращение ко всем "внешним" сущностям и ограничиваем аргументы простыми типами (даже не процедурными) - то что полезного можно получить из таких функций.

43
Общий раздел / ASSERT
« : Февраль 19, 2011, 04:59:22 am »
Навеяно недавним просмотром ББ'ых исходников... А в чем глубокий смысл второго параметра ББ'ого ASSERT'а? Нигде таких ассертов нет :) В смысле все полезное в стэке и в номере строки, нет? :) Зачем эта лишняя сущность в языке, славящимся отсутствием всего лишнего?

44
Цитата: Сергей Прохоренко
Уже полгода на моем рабочем столе лежит презентация The Next Mainstream Programming Language: A Game Developer’s Perspective - крик души разработчика игр. Лежит как напоминание о том, что хороший структурный редактор должен соответствовать этим ясно выраженным потребностям. Должен признать, что предложенные автором решения мне понравились. А компьютерные игры - это передовой край Computer Science, эталон пригодности инструментального программного обеспечения к решению сложных задач.

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

По поводу нулевых указателей и неинициализированных переменных. Я уже выступал на оригинальном форуме (http://forum.oberoncore.ru) и наверняка есть ЯП в которых эта проблема в каком то виде решена, но если подытожить применительно к оберону и структурному редактору, то основные тезисы такие:
- Неинициализированных переменных нет, потому что объявление переменной совмещено с ее инициализацией синтаксически. A-ля VAR i: INTEGER := 3.
- Указатели по умолчанию ненулевые (обязаны быть проинициализированы реальным объектом или другим ненулевым указателем).
- Можно объявить нулевой указатель. Это другой тип, совместимый с ненулевым указателем в одну сторону: ненулевой указатель может быть приведен к нулевому, но не наоборот. Нулевой указатель не может быть разыменован.
- Для получения ненулевого указателя из нулевого есть специальная синтаксическая конструкция вроде обероновской проверки/приведения типа с помощью WITH. Если проверка сработала, то выполняется ветка кода, где "виден" ненулевой указатель.

Страницы: 1 2 [3]