Oberon space
General Category => Общий раздел => Тема начата: Freeman от Январь 24, 2013, 09:39:30 am
-
Хотел создать тему, но не находил нужных слов. Поэтому дам просто ссылку (http://tunilab.org/Ono).
В идеале хотелось бы услышать конструктивную критику по языку и всему остальному. Не покидает ощущение, что пока не удалось донести свои мысли должным образом.
-
Спецификации языка не нашёл также как не нашёл и компилятора, только общие слова. Критиковать пока нечего.
-
Девиз языка:
Функциональное программирование в привычном синтаксисе.
Уже интересно, надо будет почитать что там и как. Вот только многовато букв...
-
А можно пример какой-нибудь не слишком тривиальный? Ну хоть сортировку какую-нибудь (пузырьком), или там решение какой-нибудь задачки отсюда: http://benchmarksgame.alioth.debian.org/
Ну или вот этой задачки решение: http://oberspace.dyndns.org/index.php/topic,392.0.html
(последнее предпочтительно, ибо эту задачку вроде бы все уже знают и не придется заново вникать).
-
Спецификации языка не нашёл также как не нашёл и компилятора, только общие слова. Критиковать пока нечего.
Насколько я помню там интерпретатор в svn.
-
Насколько я помню там интерпретатор в svn.
К сожалению, нет. Сам язык пока в стадии разработки (синтаксис), поэтому о реализации еще говорить рано.
После первых отзывов могу сказать несколько слов. Язык Оно изначально задумывался с синтаксисом, управляемым библиотекой (RTL). Позже эта идея трансформировалась в двухуровневый подход:
- Есть некие базовые неперекрываемые понятия, реализуемые магией компилятора и условно соответствующие абстрактной высокоуровневой машине, примитивы которой -- и есть обратимый байт-код. Получается, что ассемблером этой машины является (http://tunilab.org/Ono/Concepts/TuniAsm) сам Оно.
- Есть некоторый набор операций, реализуемых в RTL, -- так называемый (http://tunilab.org/Ono/Concepts/NoOperatorOverloading) "Лисп-скобка-скобка". Как оказалось, похожий подход используется в языке Эйфель.
Сейчас стоит задача завершения работы над синтаксисом, что даст основу для байт-кода, после чего писать RTL -- уже на Оно. И только потом можно будет браться за компилятор.
Зачем все это делается, я попытался объяснить в статье "Фрактальная ОС (http://tunilab.org/UniEnv/FractalOS)", перед прочтением которой стоит также прочесть "ОС как платформа (http://tunilab.org/OSDev/Platform)". Получилось довольно эмоционально, но уж как есть.
Вот такой мега-проект. У меня сомнения не столько в технической реализуемости, сколько в востребованности и соответствию вызовам времени. Как говорят в определенных кругах? Проект "нинужен", у нас "..." есть.
-
http://tunilab.org/Ono/Syntax/Algorithms/Loops
Операторы цикла представлены в Оно циклом Дейстры, циклом типа «паук» и циклом for, который рассматривается как итератор, совмещенный с алгоритмической реализацией агрегатной функции.
Для чего нужен цикл Дейкстры, если будет цикл "паук", частным случаем которого является цикл Дейкстры?
-
Да хватит умничать уже.
Т. н. цикл-'паук' придумал какой-то мудак, который не смыслит в циклах ни уха, ни рыла.
Достаточно посмотреть на ссылку в конце статьи в википедии:
Работа с циклами for и foreach в PHP
-
http://tunilab.org/Ono/Philosophy/WYTIWYG (http://tunilab.org/Ono/Philosophy/WYTIWYG):
Язык Оно создается на замену С/С++ ...
Вот такой мега-проект. У меня сомнения не столько в технической реализуемости, сколько в востребованности и соответствию вызовам времени. Как говорят в определенных кругах? Проект "нинужен", у нас "..." есть.
Как там в поговорке говорится?.. "Чужую беду руками разведу" :)
Когда я вижу перед собой столь широкомасштабный проект, первое, что я делаю, - это пытаюсь найти ответы на главные вопросы. Один из таких вопросов: "Вы разрабатываете новый язык, потому что ЛИЧНО испытываете в нём потребность? Или для того чтобы осчастливить "бедных" пользователей C/C++?" Я понимаю, что одно другое не исключает. И всё-таки, что для Вас главное? Если второе, то не тратьте понапрасну силы и время.
-
В идеале хотелось бы услышать конструктивную критику по языку и всему остальному. Не покидает ощущение, что пока не удалось донести свои мысли должным образом.
Мысли местами интересные, местами вообще непонятные и сильно разбросаны. Может все же со стороны примеров зайти?
-
Насколько я помню там интерпретатор в svn.
К сожалению, нет. Сам язык пока в стадии разработки (синтаксис), поэтому о реализации еще говорить рано.
Неверный подход.
Синтаксис - дело вторичное. Главное - семантика:
Представление программы в виде семантического дерева позволяет реализовать идею Б.Страуструпа о том, что синтаксис языка программирования является только интерфейсом [3], который, вообще говоря, можно менять, выбирая наиболее удобный. В Semantic IDE помимо синтаксиса Semantic Language реализованы С-подобный и Pascal-подобный синтаксисы. Кроме того, каждое из представлений может быть показано как в русской лексике, так и в английской.
-
Вы разрабатываете новый язык, потому что ЛИЧНО испытываете в нём потребность? Или для того чтобы осчастливить "бедных" пользователей C/C++?
Поскольку первоначальной идеей была разработка ОС, вместе с языком это нужно рассматривать как попытку создать отдельную экосистему, основанную на оригинальном подходе к решению задач -- борьбе с рутиной -- в том смысле, как она понимается автором проекта. ОС и язык -- инструменты для реализации выбранного подхода.
C/C++ рассматривается как некий ориентир, пример успешной экосистемы или даже нескольких экосистем. Глядя на него, сразу видны и задачи, и требования, и глубина проработки, и усилия для этого. Воспроизвести результат, не копируя подходы и решения -- вот чего хочется. С этой точки зрения Оно "спасает" программистов на C/C++ так же, как их "спасает" Objective-C, например.
Может все же со стороны примеров зайти?
Пробовал, но пока не получается или получается совсем мало, как в new (http://tunilab.org/Ono/Syntax/Classes/New#html). Думаю, что со временем появится раздел с аналогами решений, принятых в других языках. Надеюсь, что помогут ваши наводящие вопросы. :)
Синтаксис - дело вторичное. Главное - семантика:
Не знаю, как это правильно объяснить. Поиск семантики через синтаксис? Гм. Ведь вместе с синтаксисом вырабатывается некая модель, которая станет основой байт-кода.
Представление программы в виде семантического дерева позволяет реализовать идею Б.Страуструпа о том, что синтаксис языка программирования является только интерфейсом [3]
Это не из "Странника" цитата? Нагуглил, вроде нет. Похожая идея была также в SymADE Максима Кизуба... А ваша разработка как-то мимо меня прошла. :)
Идея Единой среды в том, что одновременно с разработкой языка ведется поиск некой минимальной высокоуровневой машины, оперирующей понятиями "объект", "список", "условие", "функция" и некоторыми другими. Скажем, объект рассматривается как "объектный регистр"... Простота тут не в синтаксисе, как в Обероне, а в машине -- в байт-коде. Именно поэтому в Оно сразу два синтаксиса -- командный и декларативный.
В разработке все проявляется как-то одновременно, и мне кажется, что набор понятий машины возникнет в тот день, когда будет завершена работа над синтаксисом. Есть какие-то внутренние критерии, позволяющие отделить хорошее от плохого, но пока затрудняюсь сформулировать их словами.
-
Синтаксис - дело вторичное. Главное - семантика:
Не знаю, как это правильно объяснить. Поиск семантики через синтаксис? Гм. Ведь вместе с синтаксисом вырабатывается некая модель, которая станет основой байт-кода.
...
Именно поэтому в Оно сразу два синтаксиса -- командный и декларативный.
В разработке все проявляется как-то одновременно, и мне кажется, что набор понятий машины возникнет в тот день, когда будет завершена работа над синтаксисом. Есть какие-то внутренние критерии, позволяющие отделить хорошее от плохого, но пока затрудняюсь сформулировать их словами.
Для одной и той же семантики, для одного и того же байткода можно придумать множество совершенно непохожих друг на друга синтаксисов -- лисповый, сишный, паскалевский, питоновский и тд.
По-моему Вы смешиваете эти два понятия -- синтаксис и семантику...
-
Просмотрел статьи по Вашему языку, слишком уж много там воды и мало конкретики.
Ещё раз убедился в правильности виртовского подхода -- сначала сделай, а потом напиши-расскажи публике...
-
Вы разрабатываете новый язык, потому что ЛИЧНО испытываете в нём потребность? Или для того чтобы осчастливить "бедных" пользователей C/C++?
Поскольку первоначальной идеей была разработка ОС, вместе с языком это нужно рассматривать как попытку создать отдельную экосистему, основанную на оригинальном подходе к решению задач -- борьбе с рутиной -- в том смысле, как она понимается автором проекта. ОС и язык -- инструменты для реализации выбранного подхода.
C/C++ рассматривается как некий ориентир, пример успешной экосистемы или даже нескольких экосистем. Глядя на него, сразу видны и задачи, и требования, и глубина проработки, и усилия для этого. Воспроизвести результат, не копируя подходы и решения -- вот чего хочется.
1. Проект Оберон - наше все... :)
Уже сделана - ОС вместе с языком реализации и он же язык программирования в этой ос.
2. Проект оберон делался без оглядки на мир С++.
3. Вот книжка: http://www.ozon.ru/context/detail/id/8218517/
-
2. Проект оберон делался без оглядки на мир С++.
Справедливости ради, полно ОСей писались без оглядки на мир С++, например Юникс :-) Да и языков тоже полно (старых, собственно Оберон делался без оглядки на плюсы просто потому, что плюсов тогда особо и не было).
Сейчас проектируя новый язык глупо игнорировать опыт С++ и других языков.
-
1. Разница существенная.
Проект Оберон СРАЗУ разрабатывался как ос на языке высокого уровня. А unix - переписана на языке высокого уровня.
2. учет опыта С++ приводит к разработкам типа Java и C#.
Лучше от этого отрешиться и просто сформулировать - чего надо-то?
-
1. Разница существенная.
Проект Оберон СРАЗУ разрабатывался как ос на языке высокого уровня. А unix - переписана на языке высокого уровня.
Ну, ок. Не юникс. Пусть будет BeOS.
2. учет опыта С++ приводит к разработкам типа Java и C#.
Лучше от этого отрешиться и просто сформулировать - чего надо-то?
Нет. Учет опыта С++ приводит к разработкам типа Rust и Go.
PS. А чем java не нравится?
-
http://tunilab.org/Ono/Philosophy/WYTIWYG
Проблема читабельности и понятности
Недостатки языков Си-семейства хорошо известны: плохая читабельность, «ребусы», небезопасная и чреватая трудноуловимыми ошибками концепция препроцессора, и многое другое. Но когда я начал изучать функциональное программирование, оказалось, что все, за что ругаем C/C++ — функционалка. Точнее, это кривая-косая попытка всунуть часть подходов ФП в явно императивный язык. Кстати, именно поэтому Си так лаконичен, за что и любим программистами. Но цель все же не оправдывает средства.
Взяв полноценные функциональные языки, вроде Haskell или Erlang, мы… увидим то же самое: плохую читабельность, «ребусы» и, разве что, вывод типов и сопоставление с образцом вместо препроцессора. Видя программу на ФП-языке, программист, не знакомый с парадигмой, пытается «зацепиться глазом» за привычные вещи: переменные, типы, стандартные операторы, вроде if, и пр. Но ничего этого в программе на ФП-языке, как правило, нет. Другая парадигма, и всё тут. Пока получается, что функционалку знают параноики самые въедливые, кому интересно разбираться в новом виде тайнописи.
Ого, какой феерический бред ))) Даже понравилось )))
Видя программу на ФП-языке, программист, не знакомый с парадигмой, пытается «зацепиться глазом» за привычные вещи: переменные, типы, стандартные операторы, вроде if, и пр. Но ничего этого в программе на ФП-языке, как правило, нет. Другая парадигма, и всё тут.
Да есть всё это, есть. Хаскелл так вообще является лабораторией типов...
-
Тот же пример на Оно:
add(int x, y) = x + y;
inc(int x) = add(x, 1);
Ужасный пример! Либо уж полностью специфицируйте тип функции, либо вообще опустите спецификацию. А вот такая частичная, с недоговорками и необоснованными предположениями, что программист, читающий этот код, сам догадается (common sense, понимаешь ли!) -- не годится!
int add(int x, int y) = x + y;
int inc(int x) = add(x, 1);Так ещё куда ни шло.
Однако хаскельный оригинал имхо лучше, только правильнее всё же делать так:
add :: (Num a) => a -> a -> a
add x y = x + y
inc :: (Num a) => a -> a
inc x = add x 1Что же касается наглядности и понятности описаний, то тут во многом дело привычки. Кому-то нагляднее так, например:
function add(x: in Integer; y: in Integer) return Integer is
begin
return x + y;
end add;
function inc(x: in Integer) return Integer is
begin
return add(x, 1);
end inc;и я их вполне понимаю...
-
2. учет опыта С++ приводит к разработкам типа Java и C#.
Под учетом опыта подразумевается ответ на вопрос "Зачем они это сделали?":
- Анализ результатов. Типа, шаблоны -- это обобщенное программирование, полиморфизм времени компиляции.
- Поиск исходных задач и воспроизведение среды, в которых они решались. Типа, на PDP-11 (?) поиск нулевого байта в строке делался одной командой.
Такая "обратная разработка" применяется ко всему, не только к C/C++. Например, окна нужны были в свое время для отображения информации большей, чем может вместить экран. Так в 2007-м году была предсказана (http://tunilab.org/UniEnv/Interface/LargeDiagonalShallKillWIMP) Retina и модные нынче адаптивные интерфейсы. Просто были правильно воспроизведены условия, и логически мыслящие люди по разные стороны океана пришли к одинаковым выводам.
С этой точки зрения вторичные по отношению к C++ решения тоже могут быть источником опыта. Например, в модных версиях Delphi были бездумно добавлены "дурацкие угловые скобки" -- решение с шаблонами было скопировано в лоб. Зачем, спрашивается?
Зато в Delphi полностью своя, чуть ли не единственная "расово верная" реализация строк с хорошо продуманной поддержкой кодировок. С поправкой на окружение Delphi она может служить примером.
Ого, какой феерический бред ))) Даже понравилось )))
Мы старались. :)
-
Насчет читабельности.
Передо мной книжка Окулова: Информатика. Развитие интеллекта школьника.
Он упоминает об эффекте Струпа: http://ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%A1%D1%82%D1%80%D1%83%D0%BF%D0%B0
Дык в программировании этот эффект, как я теперь понимаю, проявляется сплошь и рядом!
Особенно когда имена не соответствуют содержанию. Отсюда и ошибки - от несоответствия.
-
Хотел создать тему, но не находил нужных слов. Поэтому дам просто ссылку (http://tunilab.org/Ono).
В идеале хотелось бы услышать конструктивную критику по языку и всему остальному. Не покидает ощущение, что пока не удалось донести свои мысли должным образом.
После чтения - ощущение такое..что автор.. после того как прочитал несколько популярных статей из ВИКИ понял пчто просто так информация содержащаяся в них у него не устаканится.. Поэтому он залил ее 10 литрами пива (процесс пошел), для его ускорения он начал прыгать на одной ноге.. но упал ударившись головой о пол... после этого его посетило ОТКРОВЕНИЕ.. в основе которого появились эти материалы...Поскольку эффект этого ритуала быстро сошел на нет, то автор не в состоянии даже себе обьяснить суть написанного и просит разобраться других...
-
Слушайте господа, а может Freeman - это новый ник. Влада Жаринова? (типа ссылается на труды своей молодости) :)
-
Маловероятно, если заочно давать оценку. Объяснить не могу, но различие ощущается чётко.
-
Слушайте господа, а может Freeman - это новый ник. Влада Жаринова? (типа ссылается на труды своей молодости) :)
(http://tunilab.org/About/Freeman.png) (http://tunilab.org/About)
Владислав, но не Жаринов, а какой-то Джавадов.
И да, всё же стиль словоблудия Freeman'а заметно отличается от стиля словоблудия Драконографа...
-
http://tunilab.org/Ono/Syntax/Containers/SCA
’строка’ — (’ст’, ’ка’) = ’ро’;
Вычитание набора строк (контейнера) из строки: входящие в контейнер строки вычитаются из исходной строки, как в первом варианте.
Бесполезное и неоправданное усложнение. Проще сделать так:
’строка’ — ’ст’ — ’ка’ = ’ро’;
Насчёт операций деления и умножения строк, вероятно стоит рассматривать здесь строки как множества символов и использовать соответствующие операции.
http://tunilab.org/Ono/Syntax/Containers/TreesGraphs
Деревья и графы вводить в язык не стоит, лучше сделать их просто частью стандартной библиотеки.
http://tunilab.org/Ono/Syntax/Exceptions
Вопросы по исключениям — только по ключевым словам:
Для возбуждения исключений использовать throw или raise? Или оба ключевых слова одновременно?
Для отлова исключений голосую за catch, находя except неоднозначным. Но если кто-то хочет except, можно добавить равноценным словом, как и с возбуждением.
Язык надо делать как можно более компактным, поэтому разведение кучи ключевых слов для одной и той же сущности -- плохо. То же и с операциями.
Так же синтаксис кортежей с круглыми и квадратными скобками тоже слишком избыточен, лучше оставить один вариант. Haskell-way: кортежы в круглых скобках, списки в квадратных.
Вообще в описании Оно постоянно упоминаются SQL и СУБД. С чем это связано?
http://tunilab.org/Ono/Syntax
Поскольку синтаксис языка Оно создавался во многом путем комбинирования синтаксиса паскалеподобного языка и SQL, при изучении Оно достаточно запомнить простое правило:
Синтаксис SQL имеет приоритет.
Интересно будет посмотреть на реальную работающую более-менее большую программу на этом Оно -- тот ещё птичий язык получится )))
-
После чтения - ощущение такое..что автор.. после того как прочитал несколько популярных статей из ВИКИ понял что просто так информация содержащаяся в них у него не устаканится.. Поэтому он залил ее 10 литрами пива (процесс пошел), для его ускорения он начал прыгать на одной ноге.. но упал ударившись головой о пол... после этого его посетило ОТКРОВЕНИЕ.. в основе которого появились эти материалы...Поскольку эффект этого ритуала быстро сошел на нет, то автор не в состоянии даже себе обьяснить суть написанного и просит разобраться других...
У меня ощущение, что автор раньше работал с СУБД и SQL, со всякими дельфями, интересовался ФП, всякими хаскелями и лиспами, и вдруг решил сделать свой язык, не имея при этом достаточно серьёзной теоретической и практической подготовки в информатике и программировании.
И вот мы и увидели шедевр по названием Оно (Ono is Not Oberon).
Вот только сомневаюсь я, что автор Freeman со своим помощником Proger'ом (а их там двое) осилят создание транслятора с Оно.
А если вдруг и осилят, результирующий язык будет сильно отличаться...
-
что автор Freeman со своим помощником Proger'ом (а их там двое) осилят создание транслятора с Оно.
А если вдруг и осилят, результирующий язык будет сильно отличаться...
В плане трансляторов, я бы авторам (Freeman & Co) советовал, в качестве легкого упражнения, реализовать компилятор/транслятор Оберона-07/11 четко по описанию языка от Вирта.
По моему, это первое что должен сделать автор будущего языка - простое упражнение которое позволит прокачать основные навыки. Эдакий компиляторный и языковый Hello World (кроме навыков реализации компилятора прокачаются также навыки досконального разбора языка по спекам, без оглядки на существующие реализаци).
-
Сначала надеялся, что с созданием языка всё не очень серьёзно, потому не хотел говорить об одной маркетинговой неувязочке. Но теперь, думаю, всё-таки стоит сказать: настоятельно советую сменить название.
-
Удивляет поощрение множественного наследования реализации как центральная идея.
Если учесть, что наиболее гибкие, надёжные и расширяемые архитектуры получаются при отказе от наследования реализации вообще (скрытые реализации, создание через фабрики, композиция). Не надо считать это узко-обероновским загоном. Это и Гамма со товарищи, а теперь и многие к этому приходят (недавно наткнулся на книжку Стояна Стефанова "JavaScript. Шаблоны". O-Relly. Так там вообще ООП-архитектуры с наследованием называются устаревшими, а без него - современными).
В советской книжке «128 советов начинающему программисту» рассказывалось, что все управляющие операторы можно заменить циклом while. Неудивительно, что этот вид цикла развивается больше всего, поскольку является «настоящим» циклом, так сказать.
Интересно, а кроме Очкова-Пухначёва автор читал что-то по теме циклов?? :)
Ну, а я, соответственно, хочу поставить вопрос, стоит ли учить школьников императивному программированию, когда у них уже даже в мобилах не сегодня-завтра многоядерные процы будут? Императивное программирование должно было умереть еще лет 6 назад, с появлением этих самых многоядерных процессоров. Ан нет, — индустрия, то-сё, — так до сих пор на Си всё и пишут.
Всегда прошу так вещающих привести мне пример таких компонентов ПО, которым не хватает производительности одного процессора. А затем оценить в удельном соотношении по строкам кода. Если в 20% всех задач программирования в 20% их кода нужно задействовать много ядер, потому что одно не справляется, то это ещё не повод в оставшемся коде переходить к чему-то другому от наиболее практичного, по интегралу, стиля (императивного объектно-ориентированного).
Из-за того, что отдельные части систем потребовали оптимизации, Вы собираетесь запутывать стиль разработки остальных частей? :)
-
Если учесть, что наиболее гибкие, надёжные и расширяемые архитектуры получаются при отказе от наследования реализации вообще (скрытые реализации, создание через фабрики, композиция).
А ещё можно пугать приведениями, лешими и другой нечистью... :)
Если немного задуматься (и перестать бояться и, как следствие, пугать других собственными страхами)... то наследование интерфейсов - это нонсенс... Поскольку интерфейсы - это просто спецификации/требования, точно такие же (по сути), как спецификации/требования, прилагаемые к чертежам узлов и деталей. И любые узлы/детали, соответствующие данной спецификации, могут быть использованы... В программировании интерфейсы "приклеили" к сущностям, как некие "видимые извне" свойства... получили массу проблем... И теперь их пытаются преодолеть... окончательно, утратив/исказив смысл. Отсюда и фобии...
Всегда прошу так вещающих привести мне пример таких компонентов ПО, которым не хватает производительности одного процессора. А затем оценить в удельном соотношении по строкам кода. Если в 20% всех задач программирования в 20% их кода нужно задействовать много ядер, потому что одно не справляется, то это ещё не повод в оставшемся коде переходить к чему-то другому от наиболее практичного, по интегралу, стиля (императивного объектно-ориентированного).
Из-за того, что отдельные части систем потребовали оптимизации, Вы собираетесь запутывать стиль разработки остальных частей? :)
Когда-то человеку хватало собственных рук... И попытки объединить/скоординировать усилия нескольких людей, наверно, вызывали подобные... отповеди. Тем не менее... время шло... и усилий одних рук не хватало всё чаще... В окружающем нас мире, всё живёт, развивается и даже умирает... параллельно... не дожидаясь своей очереди у "исполнителя команд".
С другой стороны... какой может быть причина не использовать доступные вычислительные мощности?.. Дело даже не в том, что отдельной мощности может не хватить, а в том, что совместно можно сделать быстрее (при правильном проектировании системы и планировании работ, соответственно). Почему кто-то из пользователей должен расплачиваться за нашу безграмотность?..
И кто с-казал/до-казал/по-казал, что параллельный код запутаннее, чем последовательный?.. Что труднее/затратнее: выдать инструкции сразу всем исполнителям или много раз выдавать последовательные инструкции одному исполнителю?.. Может быть дело в нас самих... привыкших к последовательной выдаче?.. Может быть это нам труднее перестроиться?.. И рассуждения о запутанности и трудностях... только фобии, которых боимся мы и пугаем других?..
-
Код в виде параллельно работающих агентов, написанных в императивном стиле может быть и не запутанней, и вообще, наборот - помочь сделать более ясную программу.
Я имею в виду именно переход к ФП ради автоматического распараллеливания потока вычислений.
По поводу прогресса - иногда появление новых возможностей не отменяет предыдущие. Например, с появлением самолётов не исчез наземный транспорт. Просто разное назначение.
Методы программирования для сверхмногоядерных спецвычислителей (GPU и проч.) не обязаны становится основными методами.
-
Я имею в виду именно переход к ФП ради автоматического распараллеливания потока вычислений.
Что любопытно, конкретно в той цитате, что Вы привели, нет ни слова про ФП:
Ну, а я, соответственно, хочу поставить вопрос, стоит ли учить школьников императивному программированию, когда у них уже даже в мобилах не сегодня-завтра многоядерные процы будут? Императивное программирование должно было умереть еще лет 6 назад, с появлением этих самых многоядерных процессоров. Ан нет, — индустрия, то-сё, — так до сих пор на Си всё и пишут.
Однако в удовольствии укусить ФП Вы себе не отказали ))) Всё же какая-то нерациональная нелюбовь к ФП у Вас наблюдается, имхо...
В описании этого Оно постоянно упоминается SQL, являющийся самым распространённым декларативным языком.
При всех проблемах планирования SQL-запросов они, тем не менее, являются ярким примером возможности распараллеливания вычислений...
И ещё, каким именно образом ФП, по Вашему, приводит к "запутыванию стиля разработки остальных частей"?
-
Код в виде параллельно работающих агентов, написанных в императивном стиле может быть и не запутанней, и вообще, наборот - помочь сделать более ясную программу.
Именно.
По поводу прогресса - иногда появление новых возможностей не отменяет предыдущие. Например, с появлением самолётов не исчез наземный транспорт. Просто разное назначение.
Кто же с этим спорит?.. Появляется много разных видов транспорта, и у нас появляется возможность... выбрать то, что удобно для данной конкретной ситуации... О чём я и говорил.
Методы программирования для сверхмногоядерных спецвычислителей (GPU и проч.) не обязаны становится основными методами.
Да, этим методам... как-то безразлично... Собственно, и программисту должно быть безразлично... Он [программист] указывает связи между сущностями, а анализ связей показывает, что может работать параллельно, а что должно работать последовательно. Простой случай - зависимость по данным.
-
Хотел создать тему, но не находил нужных слов. Поэтому дам просто ссылку (http://tunilab.org/Ono).
В идеале хотелось бы услышать конструктивную критику по языку и всему остальному. Не покидает ощущение, что пока не удалось донести свои мысли должным образом.
После чтения - ощущение такое..что автор.. после того как прочитал несколько популярных статей из ВИКИ понял пчто просто так информация содержащаяся в них у него не устаканится.. Поэтому он залил ее 10 литрами пива (процесс пошел), для его ускорения он начал прыгать на одной ноге.. но упал ударившись головой о пол... после этого его посетило ОТКРОВЕНИЕ.. в основе которого появились эти материалы...Поскольку эффект этого ритуала быстро сошел на нет, то автор не в состоянии даже себе обьяснить суть написанного и просит разобраться других...
А еще подобный эффект бывает без столь сложных ритуалов, достаточно просто употребить кокаин:
...у поциента под коксом полностью отключается самокритика. Он может, например, поставить в сушку жирные тарелки, слегка обмыв их холодной водой, считая, что вымыл посуду идеально. Грязные тарелки он с удивлением обнаружит только на следующий день.
Интересная вещь происходит с памятью. То, что происходит под коксом, в трезвом состоянии бывает почти невозможно вспомнить, пока не примешь следующую дозу. У человека могут образоваться как бы две почти не связанные друг с другом реальности. Например, Стивен Кинг рассказывал, что он написал пару книг под кокаином и вообще не может этого вспомнить.
...
Главная подлянка кокаина, что аффтар не чувствует своего аффтарства. Эти произведения написаны как бы и не им. Как это хорошо выражено у Tequilajazzz, если ты употребляешь кокаин, то «в твоем плюгавом теле вторая сука живет». Именно эта «вторая сука» и творит за аффтара, а сам он об этом может даже и не помнить, как Стивен Кинг не помнил написанных под сабжем двух книг.