Автор Тема: Допилить оберон под себя  (Прочитано 24319 раз)

vlad

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

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

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

DIzer

  • Гость
Re:Допилить оберон под себя
« Ответ #1 : Март 09, 2011, 02:52:45 pm »
Мой список (в предположении что популярности КП быстро не достигнуть, а реальные ресурсы на проработку ограничены):
1. Возможность возвращение функцией записи (а не указателя). не фиг плодить сущности где это не требуется...
2. Массивы  индексируемые с 1...(untagged с 0) - язык должен быть дружественным к начинающим...
3. Либо убрать repeat until, либо заменить его на do while (без инверсии условия продолжения).

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Допилить оберон под себя
« Ответ #2 : Март 09, 2011, 03:07:24 pm »
Мой список (в предположении что популярности КП быстро не достигнуть, а реальные ресурсы на проработку ограничены):
1. Возможность возвращение функцией записи (а не указателя). не фиг плодить сущности где это не требуется...
2. Массивы  индексируемые с 1...(untagged с 0) - язык должен быть дружественным к начинающим...
3. Либо убрать repeat until, либо заменить его на do while (без инверсии условия продолжения).

ИМХО массивы не с 0 - однозначное зло :) Или это уже не массив, а что-то более конкретное с конкретным индексом. Сколько с таким сталкивался... даже в С++ где можно обложить все это типами, чтобы не выстрелить в ногу - только головная боль. Или массив и 0 или не массив и итератор/ключ.

DIzer

  • Гость
Re:Допилить оберон под себя
« Ответ #3 : Март 09, 2011, 03:11:22 pm »

ИМХО массивы не с 0 - однозначное зло :) Или это уже не массив, а что-то более конкретное с конкретным индексом. Сколько с таким сталкивался... даже в С++ где можно обложить все это типами, чтобы не выстрелить в ногу - только головная боль. Или массив и 0 или не массив и итератор/ключ.
Интересно.... Пояснить свою точку зрения сможете ? Я свою - могу...

igor

  • Sr. Member
  • ****
  • Сообщений: 438
    • Просмотр профиля
Re:Допилить оберон под себя
« Ответ #4 : Март 09, 2011, 03:12:07 pm »
1. Возможность возвращение функцией записи (а не указателя). не фиг плодить сущности где это не требуется...
Сейчас, вроде, сделано так, что все функции всегда возвращают результат в регистрах проца. Если разрешить функциям возвращать записи, то этой эффективной реализации придёт кирдык.  :)

2. Массивы  индексируемые с 1...(untagged с 0) - язык должен быть дружественным к начинающим...
Не по-программерски это как-то  :) Начинающие пусть привыкают.

DIzer

  • Гость
Re:Допилить оберон под себя
« Ответ #5 : Март 09, 2011, 03:15:40 pm »
Господа, у меня есть предложение... в эту ветку кидать только предложения , о каламбур, однако,  - для обсуждения их заведем отдельную(ые) ветки. Пусть те кто предлагает и отвечают за свой "базар"  ;) так будет веселе да и полезнее...
« Последнее редактирование: Март 09, 2011, 03:17:40 pm от DIzer »

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Допилить оберон под себя
« Ответ #6 : Март 09, 2011, 03:22:00 pm »

ИМХО массивы не с 0 - однозначное зло :) Или это уже не массив, а что-то более конкретное с конкретным индексом. Сколько с таким сталкивался... даже в С++ где можно обложить все это типами, чтобы не выстрелить в ногу - только головная боль. Или массив и 0 или не массив и итератор/ключ.
Интересно.... Пояснить свою точку зрения сможете ? Я свою - могу...

Эти единицы будут везде лезть - где-то с плюсом, где-то с минусом.

offset = index2 - index1;
array[offset]; // вот здесь будет артефактная 1

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Допилить оберон под себя
« Ответ #7 : Март 09, 2011, 03:25:16 pm »
Господа, у меня есть предложение... в эту ветку кидать только предложения , о каламбур, однако,  - для обсуждения их заведем отдельную(ые) ветки. Пусть те кто предлагает и отвечают за свой "базар"  ;) так будет веселе да и полезнее...
Принимается.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Допилить оберон под себя
« Ответ #8 : Март 09, 2011, 03:48:52 pm »
Фичи… Хм… Ну попробую перечислить просто фичи:

1. обобщенное программирование (хотя бы на уровне дженериков).
2. человеческий bit syntax для разбора бинарей (правильный bit syntax можно посмотреть в erlang'e).
3. возможность анотирования метаинформацией как минимум всего того, что может экспортировать модуль.
4. явное наличие в языке интерфейсов (спецификаций) модулей. чтобы можно было явно сказать, что вот этот модуль удовлетворяет вот такой-то спецификации. Сейчас по сути типизация модулей утиная.
5. максимум дополнительных сложностей для создания глобальных переменных в модулях (инструмент должен провоцировать не ошибки, а правильные решения).
6. многопоточность
7. явно прописанное поведение при возникновение таких например ситуаций как деление на ноль, выход за границу массива, целочисленное переполнение.
8. foreach
9. вообще синтаксис причесать. капс убрать, многие точкизапятые тоже явно лишние.

Пункты 1 и 2 (а также горстка других, здесь не упомянутых, например возможность проверки на корректность построения того же конечного автомата на этапе компиляции) легко решаются, если сделать возможность написания модулей расширения для компилятора с явным синтаксисом. Я пока не готов сформулировать как конкретно это должно смотреться синтаксически.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Допилить оберон под себя
« Ответ #9 : Март 09, 2011, 04:24:45 pm »
А кстати, что допиливаем – Оберон, Оберон-2, КП, Оберон-07, Active Oberon, Zonnon, MiniComponent Pascal? :-)
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Допилить оберон под себя
« Ответ #10 : Март 09, 2011, 04:41:50 pm »
А кстати, что допиливаем – Оберон, Оберон-2, КП, Оберон-07, Active Oberon, Zonnon, MiniComponent Pascal? :-)

Давайте КП. Потому что в нем лишнего вроде как нет. Остальные менее популярны.

igor

  • Sr. Member
  • ****
  • Сообщений: 438
    • Просмотр профиля
Re:Допилить оберон под себя
« Ответ #11 : Март 09, 2011, 04:53:07 pm »
Я ещё предложил бы совместить внешние границы областей видимости с границами соответствующих блоков. И заодно уж убрать опережающие объявления процедур.

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Допилить оберон под себя
« Ответ #12 : Март 09, 2011, 05:13:45 pm »
Мой список (в предположении что популярности КП быстро не достигнуть, а реальные ресурсы на проработку ограничены):
1. Возможность возвращение функцией записи (а не указателя). не фиг плодить сущности где это не требуется...
2. Массивы  индексируемые с 1...(untagged с 0) - язык должен быть дружественным к начинающим...
3. Либо убрать repeat until, либо заменить его на do while (без инверсии условия продолжения).

1 - возможно, да.
3 - убрать.
2 - vlad пояснил, почему нельзя. Совершенно невменяемой арифметика смещений становится, все нормальные "взрослые" рефлексы летят нафиг. Мягкость для начинающих - это одно, но нельзя вырабатывать неправильные рефлексы.
Пример невменяемости арифметики смещений: представьте себе кольцевой буфер и "закольцовку" смещения операцией MOD. MOD ведёт себя как раз по схеме "нумерации с нуля".

Валерий Лаптев

  • Jr. Member
  • **
  • Сообщений: 58
    • Просмотр профиля
Re:Допилить оберон под себя
« Ответ #13 : Март 10, 2011, 09:50:37 am »
Мой список (в предположении что популярности КП быстро не достигнуть, а реальные ресурсы на проработку ограничены):
1. Возможность возвращение функцией записи (а не указателя). не фиг плодить сущности где это не требуется...
2. Массивы  индексируемые с 1...(untagged с 0) - язык должен быть дружественным к начинающим...
3. Либо убрать repeat until, либо заменить его на do while (без инверсии условия продолжения).

1. IMHO - нормально. Получаем запись по значению, и возвращаем запись по значению.
Правда надо думать про передачу и возврат по ссылке или по указателю.
Ибо если передаем var, то var нужно уметь и возвращать.
Если же передаем указатель, то и возвращаем указатель (привет Си... :) )
2. Не... Я - против. Это дело привычки. В конце-концов, программирование - это специфическая деятельность. Запоминают же водители, что вперед нажимать: газ или сцепление. Так и тут. Тем более, что сейчас практически повсеместно уже массивы индексируются с нуля. Это - смещение, а не номер. Так и объяснять с самого начала.
3. А вот это - очень правильно. Вычисление условий во всех циклах должно быть единообразным.

Валерий Лаптев

  • Jr. Member
  • **
  • Сообщений: 58
    • Просмотр профиля
Re:Допилить оберон под себя
« Ответ #14 : Март 10, 2011, 09:59:35 am »
Фичи… Хм… Ну попробую перечислить просто фичи:

1. обобщенное программирование (хотя бы на уровне дженериков).
2. человеческий bit syntax для разбора бинарей (правильный bit syntax можно посмотреть в erlang'e).
3. возможность анотирования метаинформацией как минимум всего того, что может экспортировать модуль.
4. явное наличие в языке интерфейсов (спецификаций) модулей. чтобы можно было явно сказать, что вот этот модуль удовлетворяет вот такой-то спецификации. Сейчас по сути типизация модулей утиная.
5. максимум дополнительных сложностей для создания глобальных переменных в модулях (инструмент должен провоцировать не ошибки, а правильные решения).
6. многопоточность
7. явно прописанное поведение при возникновение таких например ситуаций как деление на ноль, выход за границу массива, целочисленное переполнение.
8. foreach
9. вообще синтаксис причесать. капс убрать, многие точкизапятые тоже явно лишние.

Пункты 1 и 2 (а также горстка других, здесь не упомянутых, например возможность проверки на корректность построения того же конечного автомата на этапе компиляции) легко решаются, если сделать возможность написания модулей расширения для компилятора с явным синтаксисом. Я пока не готов сформулировать как конкретно это должно смотреться синтаксически.
1. Шаблон модуля с параметром типов - минимально необходимая конструкция.
2. Короче, нормальный битовый тип со всеми битовыми операциями. И возможностью преобразования целые и обратно. Да?
3-4. Пока не знаю.
5. Видимость на уровне модуля. Или отдельный модуль с глобальными переменными. То есть  объявление модуля типа специальным только для глобальных объектов
6. Модуль = процесс, процедура модуля - тред.
7. То есть обработка исключительных ситуаций.
8. Шаблон функции?