OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Март, 2024 08:35

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




Начать новую тему Ответить на тему  [ Сообщений: 95 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
СообщениеДобавлено: Вторник, 21 Январь, 2014 19:03 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Madzi писал(а):
Код:
FOR aelem IN arr DO
    FOR aelem IN brr DO
       someVal := aelem * belem;
    END;
END;


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

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 575
Откуда: Россия, Санкт-Петербург
Пётр Кушнир писал(а):
Madzi писал(а):
Код:
FOR aelem IN arr DO
    FOR aelem IN brr DO
       someVal := aelem * belem;
    END;
END;

В исходном сообщении
Код:
FOR aelem IN arr DO
    FOR belem IN brr DO
       someVal := aelem * belem;
    END;
END;


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


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

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 575
Откуда: Россия, Санкт-Петербург
Тролинг оценил.

Считаю что машина должна работать на человека, а не человек на машину.
Другими словами компилятор должен облегчать жизнь разработчику, а не разработчик подстраиваться под компилятор.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 21 Январь, 2014 22:03 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
Madzi писал(а):
Считаю что машина должна работать на человека, а не человек на машину.
Другими словами компилятор должен облегчать жизнь разработчику, а не разработчик подстраиваться под компилятор.


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

Согласен на все 100%, программист, должен задачу решать, а не компилятор ублажать. Сейчас компьютеры стали в десятки раз мощнее, чем 20 лет назад. Простота компилятора и однопроходность для скорости компиляции, не нужна. Лучше усложнить компилятор предоставив определённые возможности, чем упростить компилятор и повесить это на программиста.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Январь, 2014 08:42 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Илья Ермаков писал(а):
Про число строк:
когда уменьшение числа строк достигается ценой гипер-абстракции, то цена поиска каждой ошибки тоже часто вырастает.

Для аудита хаскелевого кода, очевидно, нужно больше времени на строку и аудиторы более высокой квалификации.

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

Я как - то еще в социализме читал признание одного гуру. Он написал, что однажды ему для разбора программы из 4 (четырех) строк на APL потребовалось около 4(четырех) часов!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Январь, 2014 13:32 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
Всё зависит, от требуемой функциональности программы. Если программа, по оценке, допустим занимает >1000 строк, ошибки неминуемы. Но у оберона, есть серьёзное преимущество, отточенное ядро языка, которое не даст, сделать глупые ошибки, которые остались в С совместимых языках. К примеру глючный for в фортране. Отсутствуют наслоения. Но самое главное это не предел.

Madzi писал(а):
В исходном сообщении
Код:
FOR aelem IN arr DO
    FOR belem IN brr DO
       someVal := aelem * belem;
    END;
END;


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


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Январь, 2014 13:48 
Модератор
Аватара пользователя

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

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

Это же не прогресс материального производства (и то там есть масса примеров, когда некоторые оптимальные принципы уже не меняются десятилетиями - никто не отказывается от колёс для основной массы транспорта).
Допустим, в математике создаются новые уровни абстракций - очень "высокоуровневые" теории типа общей топологии и т.п.
Но для массы применений ничего в уровне абстракции не меняется уже век-полтора. И не может поменяться, потому что основные закономерности деятельности на этом уровне были зафиксированы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Январь, 2014 13:52 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
К примеру ББ, отлавливает такие ошибки, на уровне компиляции. Усложняет ли это компилятор, думаю да. Есть ли смысл, отказываться от таких проверок, в угоду простоты компилятора. Уверен, что нет.

VAR
M: ARRAY 10 OF INTEGER;
I : INTEGER;

BEGIN
I := 500;
M[500] := 5; ошибка
M[I] := 5; ошибка

Но такое уже компилит.

J := 500;
StdLog.String("Hello World");
StdLog.Ln;

M[J] := 5;

Всего лишь поменял, имя переменной. Усложним.

J := 500;
I := J + 3;
StdLog.String("Hello World");
StdLog.Ln;

M[I] := 5;

Опять компилит. Работы не початый край.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Январь, 2014 13:57 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
Илья Ермаков писал(а):
Это же не прогресс материального производства (и то там есть масса примеров, когда некоторые оптимальные принципы уже не меняются десятилетиями - никто не отказывается от колёс для основной массы транспорта).


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

Конструкция та же, но реализация разная. Это и размер, колёс, вес, устойчивость, изнашиваемость и т.д


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Январь, 2014 14:04 
Модератор
Аватара пользователя

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

А абстракция одна: колесо :)

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

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

А мы ведём речь про аппарат абстракции, способ описания систем.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Январь, 2014 14:17 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
Илья Ермаков

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Январь, 2014 14:47 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
Jordan писал(а):
VAR
M: ARRAY 10 OF INTEGER;
I : INTEGER;

BEGIN
I := 500;
M[500] := 5; ошибка
M[I] := 5; ошибка

Но такое уже компилит.

J := 500;
StdLog.String("Hello World");
StdLog.Ln;

M[J] := 5;

Всего лишь поменял, имя переменной. Усложним.

J := 500;
I := J + 3;
StdLog.String("Hello World");
StdLog.Ln;

M[I] := 5;

Опять компилит. Работы не початый край.


Данные проверки, не вносят в язык дополнительных возможностей. Так как если цикл не один, или вложенный в другой, такое только при тестировании можно выявить. Или в неком верификационном режиме компилятора. На стадии компиляции, такое выявить сложно.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Jordan писал(а):
Согласен. Взять тот же указатель, базовые свойства, читать и писать. А сколько указатель, позволяет выразить структур данных и алгоритмов... Всё программирование на них держится.
Насчёт роста абстракций, нужно подумать. Сразу отсекать как ненужно, не стоит.


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

По моему мнению, примерно на том же уровне языковых абстракциий и на том же наборе элементов и схем их соединения, который сейчас устоялся, допустим, в добротном Java Enterpris-е (Гамма, Эванс, Фаулер) будут создавать системы и через 15-20 лет.
Может поменяться и язык, и много шероховатостей, наконец, обтесаться, надстроится мета-уровень проектирования (когда общая архитектура будет более строго описываться, то, на что претендует UML, но будет что-то более простое и удобоваримое), может быть, наконец, будет семантическое, а не текстовое редактирование, но какого-то массового прыжка отрасли к уровням абстракции Haskell-ей, Скал и прочего - не будет. Поиграются, это займёт свои ниши - но и только.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Январь, 2014 15:55 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
Ещё о встроенных возможностях.

Если взять пример встроенных строк.

1. Компилятор сам может, оптимизировать строки. Когда нужно, передавать указатель, а когда
копировать строку. Бесплатная оптимизация.

2. Конструкция вида S := S + Char;
Сулит большим расходом процессорного времени. Но если подкрутить компилятор, для того, что бы в строке был буфер. Тогда, если строка не может вместить, компилятор удваивает размер строки.

3. Не нужен нуль символ для конца строки. Получение размера строки одна машинная инструкция.

4. Приведение к нуль строке, запись символа в конец. Создания не происходит. Изначально в строке есть место для данного символа.

Работать с такими строками, одна радость.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Январь, 2014 16:02 
Модератор
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Январь, 2014 16:28 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
Всё нормально размещается.

VAR
A: STRING; дин строка, по умолчанию размер 32
B: STRING[64]; дин строка, размер буфера равен 64
C: ARRAY 16 OF CHAR; статическая строка
D: POINTER TO ARRAY OF CHAR; указатель на строку.

Возможность для работы со статическим массивом символов остаётся. В язык требуется ввести только одно ключевое слово. Язык не стал сложнее. Принцип минимализма, сохранён.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 23 Январь, 2014 00:38 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Валерий Лаптев писал(а):
Илья Ермаков писал(а):
Про число строк:
когда уменьшение числа строк достигается ценой гипер-абстракции, то цена поиска каждой ошибки тоже часто вырастает.

Для аудита хаскелевого кода, очевидно, нужно больше времени на строку и аудиторы более высокой квалификации.

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

Я как - то еще в социализме читал признание одного гуру. Он написал, что однажды ему для разбора программы из 4 (четырех) строк на APL потребовалось около 4(четырех) часов!

Не такой уж это сложный язык - APL. Вот J, с его композициями глаголов и Tacit-ом, - это будет посложнее.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 23 Январь, 2014 07:56 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 710
Откуда: Псков
Рыжий писал(а):
Вот J, с его композициями глаголов и Tacit-ом, - это будет посложнее.

Знакомство с Tacit-ом на сайте 'jsoftware' началось и закончилось последней строкой на странице 'Tacit definition' :
"Tacit programming is very powerful, but there is no need to leap into it."
:)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 13 Февраль, 2014 20:53 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
Ещё пример упрощения, через усложнение инструмента.

Вложение:
725c80a78d617f8469fdf17874f318e4.png
725c80a78d617f8469fdf17874f318e4.png [ 172.06 КБ | Просмотров: 9197 ]


И главное, без данных возможностей, нужно писать и ещё раз писать код.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Февраль, 2014 10:25 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
Если нужна статика. Легко можно написать статические контейнеры, по примеру std::array.

Вроде, static_string<type>, static_stack<type>, static_queue<type> и т.д Возможность конструирования присутствует.

Конечно, это серьёзное усложнение компилятора. Не думаю, что среда ББ легче в написании и понимании. Среда ББ уже усложняет язык, как минимум нужно прочитать мануалы, как в ней работать. Очень важный момент, ББ тесно связан с КП, это нужно учитывать, оверхед всё же есть.

Конечно, можно закрыть глаза, и писать пасквили в стиле Info21.(Да я о последней статье, даже Влада с онлайн компилятором не упомянули.) Я не имею ввиду заслуги Вирта, они бесспорны, но аргументы вроде, минимальной программы на ББ в 512 байт смешны. Считаем windows + ББ = ?
Linux + wine + ББ = ???

Всё это сравнение было об обобщённом программировании, если сравнивать си и оберон, оберон абсолютный победитель, остаётся только вопрос, нужен ли сейчас просто безопасный си? Или, что то более гибкое, обобщаемое, перенсимое(есть проблемы с манипуляциями c system)


Последний раз редактировалось Jordan Пятница, 14 Февраль, 2014 10:40, всего редактировалось 1 раз.

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

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


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

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


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

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