?

Log in

записи соседство календарь хуэмай журнал ...Ранее ...Ранее Далее... Далее...
emacs, доведённый до enterprise-качества - Why is the rum gone?
That's not good enough
akater
akater
emacs, доведённый до enterprise-качества
Иллюстрация: твой любимый модный
язык программирования через 7 лет.


Это разбухший ответ на один из комментов к прошлой записи, где речь шла про среды разработки. Наверное, мне не нужно было называть их так. Лучше было говорить про какие-нибудь IIE, Interactive Improvisation Environments.

IDE — это опасно, чувак


— А вообще, твоя мечта это smalltalk))

Мою мечту я давно нашёл, это Mathematica (во всяком случае, она воплощает мечту до тех пор, пока речь не идёт о программах, которые обязаны работать настолько быстро, насколько это позволяет железо — это к дискуссии не имеет отношения). В последнее время я пытаюсь писать о тех идеях, которые там давно реализованы (и успешно продаются) но которые я почему-то не встречаю в open-source сообществе и вообще в мэйнстриме — при этом стараюсь не всегда упоминать явно, чтобы это не выглядело как навязывание конкретного closed-source продукта.

— Вместо того чтобы писать код и вникать в документацию языка и stdlibы — тебе IDE генерит пачку кода

Это да, плохо. Впрочем, рано или поздно даже в этом коде надо будет разбираться, если потребуется писать что-то кроме одной формы с фиксированным количеством кнопок на ней. Но я даже не предлагаю пихать в поставку языка те DE, которые сделаны для создания полномасштабных проектов с документацией, интерязыковым взаимодействием и Unit Tests. Я про те, которые позволяют просто экспериментировать с языком, писать на нём что-то короткое и повседневное, и делают жизнь неискушённого (и даже очень неискушённого) пользователя намного легче. Короче говоря, средства импровизации. Мне по нраву слово «импровизация», потому что я разделяю мнение Graham'а о том, что у хакеров много общего с художниками — намного больше, чем с академическими создателями теорий или «методов» и, возможно, больше, чем с традиционными инженерами.

Головная боль им. фон Ноймана


Для искушённых программеров экспериментировать с языком вообще просто. Они с детства, видимо, понимают, что такое build, compile и link. Люди, которые активно пользуются интерпретируемыми языками, могут этого легко не понимать. Я, например, не понимаю, что такое build и link — и поэтому, по всей видимости, плохо понимаю, что такое compile, раз уж эти вещи всё время упоминаются вместе; в результате этого всего я понимаю разные синтаксисы, но ничего реально работающего из большинства из них не могу произвести. Со временем таких как я будет больше, потому что языки программирования как системы упрощаться не будут, а будут только жирнеть, медленно, но верно поднимая барьеры для входа в них.

Эта особенность (равно как и существование процедур build, compile и link) — не случайность, а непреодолимое следствие господства архитектуры фон Ноймана; функционально эта особенность никак не связана с наиболее хорошими (= наиболее реюзабельными) алгоритмами и синтаксисом конкретных языков. Поэтому она функционально не связана с написанием общественно полезного open-source кода. Искушённые программеры полностью понимают устройство языка как системы отдельных взаимодействующих (пусть и простых самих по себе) частей. Но, по-моему, требовать от потенциально нового юзера языка понимания этих деталей — это анахронизм, а также вредно для экосистемы open-source в целом. Лично я разберусь с билдами, компайлами и линками, потому что сильно припёрло, но это не меняет того факта, что они — не более чем головная боль им. фон Ноймана, вредное влияние которой можно уменьшить.

Впрочем, Б-г с ней, с архитектурой. Даже если речь идёт об интерпретируемом языке — когда текстовый редактор (не всегда осведомлённый о синтаксических единицах языка) находится в одном месте, executable-интерпретатор в другом, терминал в третьем, а хелп ещё где-то, это выглядит довольно странно и даже неестественно для меня как давнего пользователя среды, где всё это собрано вместе. По-моему, это как если бы у GNU/Linux не было дистрибутивов. Даже такая, казалось бы, мелочь, как наличие качественной и однородной документации, мгновенно доступной оффлайн в процессе собственно написания кода, многого стоит. Конечно, систему можно собрать из отдельных компонентов, и модульность приветствуется, потому что у каждого свои вкусы. Но дистрибутив — это благо: на то компоненты и существуют, чтобы из них собирать готовые вещи. Например, такие вещи как средства импровизации.

Это успешно получилось у Wolfram Research, и вот, я не понимаю, почему только они пытались.

Общеприменимость


Раньше я думал, это от того, что Mathematica — это какая-то слишком специфичная система, но сейчас вижу, что там нет ничего принципиально отличного от какого-нибудь emacs — интерпретатор-ядро, набор компилированных библиотек и (закрытых)* исходников, DE для импровизаций, хелп. Но — всё вместе, работает out of the box и одинаково полезное как человеку вообще без опыта, так и человеку с многолетним опытом (хотя и выглядит так, будто это предназначено только для людей первого типа).

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

Забавно, что когда некоторые люди видят этот DE, они иногда говорят: «эта система не может решить, она GUI или CLI». Система всё решила, она продукт естественной эволюции и того, и другого. Это emacs, доведённый до enterprise-качества, с некоторыми модификациями подлежащего языка.

Эта модель общения с юзером очень дружелюбна и применима абсолютно везде. Если её не имплементировать, программирование может стать слишком сложным занятием, чтобы такое явление как open-source могло существовать и не терять в продуктивности. Надеюсь ещё увидеть в сфере разработчиков open-source языков не только хакеров, серьёзно относящихся к дизайну языков, но и агрессивных пиарщиков, авторов красивых картинок и неискушённых тестеров.

_______________
* Это важно, но технология в этом обсуждении всё же важнее, чем бизнес-модель.
Комментариев: 40 >< выразиться
Comments
kouzdra From: kouzdra Date: le 30 juillet 2013 04:26 (UTC) (Ссылка)
Со временем таких как я будет больше, потому что языки программирования как системы упрощаться не будут, а будут только жирнеть, медленно, но верно поднимая барьеры для входа в них.

Почему же - там идет циклический процесс - первый на моей памяти пик сложности - OS/360/PL/I/A-68, потом резкий спад - RT-11/VM-370/C/Pascal, Дальше нарастание сложности - Wndow/Unix/.../C++ (и IDE-бум)

Потом снова спад - Java/ML, попытка локально нарастить сложность С#/Haskell, щас вот Go и Rust - которые например наконец выбросили объектность редуцировав ее к существенно более простым понятиям. Ну и с билд-системами также. Сложность удерживается на определенном уровне и действительно замкнутые системы типа Smalltalk/Lisp себя не оправдали

На сам деле Emacs - это довольно кривая система именно из-за того, что он пытается быть вещью в себе - например встраивание интерпретатора lisp было ошибкой (хоть было и естественным шагом) - более правилен в этом смысле XEdit, у которого просто не было встроенного языка, а был интерфейс к внешним интерпретаторам.

Но например куда более user-friendly Eclipse (который и есть Emacs, только "по уму сделанный" - там тоже концепция "все есть плагин") становится моментально не то, что не user-friendly, а даже developer-не-friendly, как только речь заходит о необходимости в нем что-то подправить. Там и опытный программер не сразу разберется что к чему внутри.

Что до compile-link-run - это просто технологическая необходимость. Процесс сборки более или менее сложной программы сам по себе обычно непрост. А главное - не стандартен. Равно как и процесс взаимодействия с системами версионирования etc. И тут и начинаются траблы - то что было достоинством IDE моментально превращается в ее недостаток.
akater From: akater Date: le 30 juillet 2013 05:34 (UTC) (Ссылка)
> Почему же - там идет циклический процесс

Тогда не было open-source в таком виде, как сейчас. Сейчас спад в сложности прежде всего означает (условное, но всё же) выбрасывание в ведро огромного количества условных единиц труда.

> Сложность удерживается на определенном уровне и действительно
> замкнутые системы типа Smalltalk/Lisp себя не оправдали

Про Smalltalk не знаю, увы. Но Лисп же ещё далеко не закончился. Раз в n лет появляется новый популярный диалект, с завидной регулярностью. Проблема только в том, что Лисп-сообщество не умеет быть популярным, а в эпоху open source умение быть популярным критично. Как только научатся быть популярными, Лисп себя «оправдает». А написать современное средство для обретения популярности — не проблема. Clojure, если не ошибаюсь, один человек создал? :-)
kouzdra From: kouzdra Date: le 30 juillet 2013 06:27 (UTC) (Ссылка)
Тогда не было open-source в таком виде, как сейчас.

Было в очень похожем - тот же DECUS - несколько сот мегабайт сорцов, а это причем специфически PDP11 сообщество

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

Так не в первый раз.

Но Лисп же ещё далеко не закончился. Раз в n лет появляется новый популярный диалект, с завидной регулярностью.

Это давно уже жизнь после смерти - бешеный успех Лиспа в свое время основывался на объективных факторах:

1) язык крайне прост в реализации и реализация эта компактна и может влезть в комп начала 60-х без заталкивания его туда кувалдой

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

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

Сейчас у него особых достоинств нет - существует скорее по инерции
akater From: akater Date: le 30 juillet 2013 05:43 (UTC) (Ссылка)
И потом, Вы говорите про системы, которые создают «проекты». Это сложная тема, я не могу ничего сказать. Я говорю, что http://ipython.org/ — совершенно правильная идея и недоумеваю, почему таких мало. Она не создаёт замкнутую группу пользователей языка. Или Вы считаете, что для компилируемых языков такие вещи делать невозможно?
kouzdra From: kouzdra Date: le 30 juillet 2013 06:30 (UTC) (Ссылка)
А в чем там специфика? Кроме yet another IDE собственно?

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

Ну и потому что у этой проблемы нашлись более удобные решения.
akater From: akater Date: le 30 juillet 2013 07:00 (UTC) (Ссылка)
Специфика в большой интерактивности, наглядном контроле за кодом, нежёсткой его вёрстке. Если они постараются, там можно будет интерактивно отображать не только банальные графики, но и, скажем, элементы интерфейса (WRI это сделали). В основе дерево JSON, его легко парсить, что открывает перспективы для автоматического выписывания полезного кода (например, отмеченного) в отдельный source-файл, коллекционирования unit test-ов, даже с комментами, и т.д.

Ничего подобного в 90-е не было, Вы троллите, как это часто бывает. :-) Как, впрочем, и с DECUS. Сколько там было народу в тех временах, о которых идёт речь? Они общались друг с другом настолько же молниеносно, как люди общаются сегодня, и вне лаборатории в том числе? Это была разнородная среда людей с разными навыками, коллективная работа над программами была для них неосновной работой? Впрочем, это неинтересно обсуждать, как и то, что Си — это «наконец появившаяся» альтернатива Лиспу.

Edited at 2013-07-30 07:03 (UTC)
kouzdra From: kouzdra Date: le 30 juillet 2013 07:22 (UTC) (Ссылка)
Специфика в большой интерактивности, наглядном контроле за кодом, нежёсткой его вёрстке. Если они постараются, там можно будет интерактивно отображать не только банальные графики, но и, скажем, элементы интерфейса (WRI это сделали). В основе дерево JSON, его легко парсить, что открывает перспективы для автоматического выписывания полезного кода (например, отмеченного) в отдельный source-файл, коллекционирования unit test-ов, даже с комментами, и т.д.

Этого в 90-е не было, но вообще-то кажется, если я правильно понял, все это и много чего еще давно уже умеет и Eclipse и IDEA (которая собственно это и придумали). Ну то есть например добавить (или поменять местами) параметр в виртуальном методе, поправить все его реализации и вызовы. Даже если в проекте несколько сот тысяч строк.

Или там выделить кусок кода в отдельный метод (аккуратно передав все необходимое через параметры и вернув обратно результат). etc etc.

PS: Что до доступа к коду - в Caml доступ к дереву кода был еще в середине 90-х - и что с того?

Некоторые DSL на этом сделали и только.

В Go вообще синтаксическое дерево, парсер, принтер и форматтер входят в стандартные либы - это полезно, потому что позволяет писать тулы, работающие с текстом, но революции это не произведет.

Си — это «наконец появившаяся» альтернатива Лиспу.

А это действительно так.
rdia From: rdia Date: le 30 juillet 2013 20:30 (UTC) (Ссылка)
У Математики, а подозреваю, что и у iPython есть косяки:

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

б) Крайне неудобная разметка кода и синтаксис. Скажем, "операторы" IF или FOR.

в) Привязанность к IDE - приходится пользоваться той же сетевой прозрачностью X-ов, к которой ещё нужно привязать Xpar, для запуска на удалённой машине с firewall'ом (пользователь не root, админских прав не имеет).
akater From: akater Date: le 31 juillet 2013 08:29 (UTC) (Ссылка)
Косяки, если они и есть, к теме псто, то есть, к improvisation environment не имеют прямого отношения. :-]

Не знаю почти ничего про синтаксис iPython, но подозреваю, что он очень похож на синтаксис Python. У меня не сложилось с Python, пробовал два раза, и не пошло. Ничего про него не могу сказать.

а) Не знаю, что такое контроль типов, и согласен с тем, что в Mma нет типов, так что, подозреваю, пенять ей на отсутствие контроля типов не стоит, так как она создана не для работы с типами. Описанную ситуацию представить не могу, сорри. Программист, который делает возможными такие вещи, сам в них виноват.

б) Удобство / неудобство синтаксиса — вопрос вкуса. :-) Мне, например, тяжело читать программы, где много квазипустых строк или begin'ов с end'ами. Разметка кода — это личное дело юзера; мне очень нравится форматирование Input-ячеек во FrontEnd, но если не нравится, его можно отключить, а для попадающихся иногда сложных выражений я использую custom-вывод. Человеческие наименования функций в Mma — это тоже приятно: почти всегда, когда я не помню функцию, я легко могу догадаться, что мне нужно, или найти через хелп по синонимам. If и For — это выражения, потому что всё должно быть выражением. (Кстати, нет ни одной причины использовать For в Mma, кроме личной привычки к конструкции For: процедурные аналоги работают быстрее, функциональные — ещё быстрее.)

в) Не понял ничего про “X”, извините. :-( Но если правильно понял про остальное, то — никто не обязывает пользоваться front-end'ом, можно использовать свой любимый текстовый редактор и вычислять всё голым ядром.
rdia From: rdia Date: le 31 juillet 2013 11:21 (UTC) (Ссылка)
> а) Не знаю, что такое контроль типов, и согласен с тем, что в Mma нет типов, так что, подозреваю, пенять ей на отсутствие контроля типов не стоит, так как она создана не для работы с типами. Описанную ситуацию представить не могу, сорри. Программист, который делает возможными такие вещи, сам в них виноват.

Контроль типов - это проверка на этапе компиляции, что вы не складываете строку с числом, не берёте индекс от числа.

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

> в) Не понял ничего про “X”, извините. :-( Но если правильно понял про остальное, то — никто не обязывает пользоваться front-end'ом, можно использовать свой любимый текстовый редактор и вычислять всё голым ядром.

Нельзя, поскольку языки "голого ядра" и "front-end'а" отличаются.
akater From: akater Date: le 31 juillet 2013 12:31 (UTC) (Ссылка)
Ну, сложение строки с числом в Mma — это попросту не ошибка, так уж устроен язык. Результат такого вычисления запросто может быть не менее полезен, чем результат сложения символа с числом. Поэтому естественно это не проверять.

Mma не компилируемый, а интерпретируемый язык, так что проверки на этапе комиляции нет за отсутствием этапа компиляции. :-) С механизмом работы выражения Compile я не знаком, но факт в том, что его совершенно необязательно использовать, чтобы решать задачи с помощью Mma, и во многих случаях его даже нельзя использовать, так как не всякое выражение компилируется. Но обращу внимание, что типов в Mma вообще-то тоже нет; можно обращаться с заголовками выражений как с типами, и это очень распространённая практика, но также вовсе не универсальная.

> языки "голого ядра" и "front-end'а" отличаются

Наверное, я чего-то не понимаю.

Содержание файла “c:\simpleScript.m”:

Write[OpenWrite[FileNameJoin[{$UserBaseDirectory, "testfile"}]], "I'm generated by script!"]

Далее, команда в терминале:

math -script c:\simpleScript.m

В рабочей директории юзера появился файл testfile, с каким надо содержанием. Вы что-то другое имели в виду?
rdia From: rdia Date: le 31 juillet 2013 15:30 (UTC) (Ссылка)
> Ну, сложение строки с числом в Mma — это попросту не ошибка, так уж устроен язык.

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

> Но обращу внимание, что типов в Mma вообще-то тоже нет

Есть, конечно. Она отличает список от числа. И некоторая функциональщина там тоже есть - т.е. тип "функция" отличается от типа "число".

> Mma не компилируемый, а интерпретируемый язык, так что проверки на этапе комиляции нет за отсутствием этапа компиляции.

Никто не мешает встроить проверку без компиляции.

> В рабочей директории юзера появился файл testfile, с каким надо содержанием. Вы что-то другое имели в виду?

Можно так запустить .nb? Чтобы он за пару дней всё просчитал, все графики внутри себя построил, а потом открыть его в Frontend'е?
akater From: akater Date: le 31 juillet 2013 17:09 (UTC) (Ссылка)
> всё просчитал, все графики внутри себя построил

Ядро способно без всяких ограничений вычислять графику само по себе. Оно вычислит объект, который без визуализации отображается как - Graphics -, или что-нибудь в этом роде. Этот объект можно импортировать в файл, или в несколько файлов, или записать внутрь nb-файла. Да собственно, так же как графику, ядро может генерировать и те же Notebooks (nb-файлы), например, и сохранять их. Но вслепую кажется, что это оверкилл и лишняя работа. Автоматической генерацией nb-файлов я ещё почти не занимался, так что готовое решение не посоветую. [Уже посоветовал, двумя комментами ниже; думаю, это будет работать со всеми ноутбуками, в которых нужно вычислять только Input-ячейки, и в том порядке, в каком они выписаны в ноутбуке.]

Но про это наверняка много писали. Например, вот: Running Mathematica Without Kernel. Но это старый текст, и я вижу, что там написан несколько сомнительный код. Я просто хотел сказать, что эта задача наверняка волновала кучу людей. Решение, которое Вы хотите, существует; лучшее место для поиска ответов — mathematica.stackexchange.com

> Ошибка - доступ по 3-м индексам к матрице.

Если у Вас доступ к чему-то по 3-м индексам (т.е., буквально f[[a]][[b]][[c]]), Вы, скорее всего, просто неидиоматически программируете. :-( Это как в Си неаккуратно обращаться с указателями — звучит почти как явное изъявление желания получить ошибку. Mma обладает мощными средствами, чтобы не надо было делать вещей, за которыми тяжело следить — как любой высокоуровневый язык, она существует как раз для того, следить за сложными структурами было легко. Если не использовать этих методов, зачем вообще брать Mma? Есть какие-нибудь языки со static type checking, которые, грубо говоря, ничего кроме многомерных массивов не умеют, зато их умеют хорошо. Математически обращение к избранному компоненту матрицы — как правило, абсолютно бессмысленная операция; я бы серьёзно задумался о том, правильную программу ли я пишу, если начинаю делать такие вещи. Обращение к элементу массива по его номеру — это в Mma нехорошая практика, к которой стоит прибегать только в моменты отчаяния.

> Никто не мешает встроить проверку без компиляции.

Наверное, я не понимаю, о чём речь. Но 1) если что-то такое будет проверяться, это, скорее всего, будет прежде всего ограничение возможностей языка, а потом уже полезный инструмент; 2) выше Вы определили это как проверку на этапе компиляции. Может оказаться, что это несложно написать самому, если понимать, что это (я просто ваще не представляю).

> Она отличает список от числа.

Ок, покажите какой-нибудь пример. иллюстрирующий «типизацию». Такие выражения как TagSet и UpSetDelayed (плюс Unprotect, если сильно надо) позволяют обращаться почти с чем угодно как с почти чем угодно. (С числами и со списками как с функциями — это и без таких хаков элементарно. :-)

Edited at 2013-08-01 04:08 (UTC)
akater From: akater Date: le 31 juillet 2013 17:27 (UTC) (Ссылка)
…или, может, я вообще не понял, что Вы хотите, сорри, — но вот тут люди описывают похожие пожелания, и предлагают несколько решений.

Edited at 2013-07-31 17:45 (UTC)
akater From: akater Date: le 01 août 2013 03:38 (UTC) (Ссылка)
Вот скрипт, который работает у меня для простого nb-файла; думаю, будет работать и для довольно сложного:

run.test.nb.m

Begin["EvalContext`"]

nbFileName = FileNameJoin[{"C:", "test.nb"}];

outputCellPattern = Cell[_, "Output", ___];

cellEval[Cell[b_BoxData, "Input", rest___]] :=
 Cell[
  CellGroupData[{
    Cell[b, "Input", rest],
    Cell[BoxData@ToBoxes@(ToExpression @@ b), "Output"]},
   Open]]

cellEval[x_CellGroupData | x_Cell | x_Notebook] := cellEval /@ x

cellEval[l_List] := cellEval /@ Cases[l, Except@outputCellPattern, {1}]

cellEval[smthElse_] := smthElse

evaluateNotebook = Export[#1, cellEval@Get@#1] &;

End[]

EvalContext`evaluateNotebook@EvalContext`nbFileName

Далее, math -script run.test.nb.m делает всю работу. Исходный nb-файл переписывается с графиками и всем прочим.

К сожалению, путь к nb-файлу указывается в самом скрипте. Но это несложно править, а если бы я лучше знал возможности ядра, то, наверное, можно было бы ещё лучше сделать, передаавая в скрипт адрес как аргумент.
rdia From: rdia Date: le 01 août 2013 05:02 (UTC) (Ссылка)
Огромное вам спасибо! (Одно непонятно - почему-то у меня в вашем журнале все служебные надписи по-французски, ну, типа Mot de pass и т.д.)
akater From: akater Date: le 01 août 2013 05:41 (UTC) (Ссылка)
Гм, мне казалось, язык интерфейса у каждого юзера отображается свой. (Я поставил французский, чтобы привыкнуть к незнакомой лексике через знакомый layout.)
rdia From: rdia Date: le 01 août 2013 05:04 (UTC) (Ссылка)
Да, переподстановка делается простым .shником. Всё равно ведь ваш скрипт нужно на вход math запихивать.
akater From: akater Date: le 01 août 2013 05:39 (UTC) (Ссылка)
Только Вы резервные копии nb-файлов делайте поначалу. :-)

1. Уже существующие в ноутбуке Output-ячейки скрипт выкидывает.

2. Я писал его менее чем за час, и структуру nb-файлов детально не знаю, так что мало ли что он выкинет ещё. Рубрикация и комменты лично у меня сохраняются. Он также не вычисляет Code-ячейки, только Input, как видно в первой строчке определения cellEval. Для последовательности Input-ячеек и комментов с несложной рубрикацией всё будет работать.
akater From: akater Date: le 04 août 2013 10:06 (UTC) (Ссылка)
Этот скрипт выглядит как полезная фича, которую никто не реализовывал. Если у Вас будут пожелания, собственные улучшения или просто жалобы, — пишите, я буду рад допилить.
From: tristes_tigres Date: le 31 juillet 2013 19:05 (UTC) (Ссылка)
Точно. Математика - результат вбухивания больших денег в устаревшую технологию (нетипизированное лямбда-исчисление). В результате содержит тяжёлые глюки, которые не фиксятся годами.
akater From: akater Date: le 01 août 2013 02:16 (UTC) (Ссылка)
Там же в основе Pattern matching, это вроде как уже больше чем λ-исчисление?
From: tristes_tigres Date: le 01 août 2013 17:37 (UTC) (Ссылка)
Pattern matching - syntactic sugar

Ничего особо не меняет
From: nivanych Date: le 30 juillet 2013 06:15 (UTC) (Ссылка)
> тебе IDE генерит пачку кода

Мне, например, очень нравится, как Agda генерит пачечки кода ;-)
И не понимать там не получится.
andybil From: andybil Date: le 30 juillet 2013 15:28 (UTC) (Ссылка)

Дело не только в фон Неймане

Там архитектура для последовательного исполнения, и только бухгалтерских чисел (64 разряда). Потому для графики, распознавания образов и т.д., ваш фон Нейман и ВСЕ евонные языки "як мертвому припарки".
Человек с временем реакции 20 мс распознаёт и реагирует на изменения окружающей среды. От глаза до коры около 10 нейронов, столько же от коры до мышцы. Так прикиньте, что даёт параллелизмь!
А ваши фоннейманы с 3 ГГцами текст толком не распознают, а речь только в онлайне. Тфу, мракобесы.
Я спросил математиков, сколько теория даёт времени для расчёта максимума в массиве, мне сказали что о(n), что безусловно говорит о небесном происхождении жизни, после чего чего меня забанили, как чела, который считает математику не наукой.
Может вы спасёте престиж математики?

Edited at 2013-07-30 15:29 (UTC)
kouzdra From: kouzdra Date: le 30 juillet 2013 20:10 (UTC) (Ссылка)

Re: Дело не только в фон Неймане

В графике вообще 32 разряда достаточно - в Open GL именно так, причем увеличивать никто не жаждет - потому как медленнее будет. А 32 хватает.
andybil From: andybil Date: le 31 juillet 2013 03:24 (UTC) (Ссылка)

Re: Дело не только в фон Неймане

"В графике вообще 32 разряда достаточно" Речь идёт о типах, которые параллельно обрабатываются. Если у вас файл на 10 мегапикслелей, то вы можете обрабатывать 10 мегапикслелей ПАРАЛЛЕЛЬНО, что бы найти букву Ё.
Так что 32 бита маловато будет. и да, 10 мегапикселей = 320 Мбайт параллельно. Так же и в зыуке, у вас не один 10 разрядный сампл, а поболе, что бы последовательно обработать вы запустите цикл, а параллельно боработать можно в один такт найти максимум, или нет? Вот где зарыта собака.
kouzdra From: kouzdra Date: le 31 juillet 2013 05:33 (UTC) (Ссылка)

Re: Дело не только в фон Неймане

Дык не очень нужно, хотя GPU довольно в этом смысле хороши. А так - если очень надо - берешь FPGA и лепишь там ту схемотехнику, которая нужна. Многие так и делают.
andybil From: andybil Date: le 31 juillet 2013 05:44 (UTC) (Ссылка)

Re: Дело не только в фон Неймане

В том-то и дело, что НЕ ЛЕПЯТ.
Во первых, ежли это частый случай, должон быть стандартный проц.
Во вторых, там не нужно много процев, как в GPU, а нужен один FullHD разрядный.
Небось в ДАРПе уже всё есть, но до поры всем про это не рассказывают. От себя замечу, что это можно спокойно сделать на 100 нм, что есть в Зелгороде.
kouzdra From: kouzdra Date: le 31 juillet 2013 07:08 (UTC) (Ссылка)

Re: Дело не только в фон Неймане

Лепят сколько угодно - железки с ARM в качестве контроллера и FPGA для того, что действительно надо просто серийно делаются как платформы.

Во первых, ежли это частый случай, должон быть стандартный проц.

Чего нестандартного в тех же ксайлингсах или амтеле? Серийное изделие. Что программируется несколько иначе - ну так вы вроде этого и просите.

PS: На сам деле то, чего вам хочется должно выглядеть совсем не так - это должно быть что-то вроде компилятора для этого - только эффективно реализующего подобные проги (это как раз параллельная сортировка Батчера, которая в идеале работает за O((log N)2)

PPS: Ну или доведение до ума чего-то типа Handel C - который как раз и придуман для "прграммирования схемотехники на человеческом языке"

PPPS: Собственно и Go и Handel C юзают один и тот же фреймворк - хоаровский CSP - только первый заточен под реализацию на классической многопроцессорной архитектуре, а второй - под полностью "железную" реализацию. В принципе если скрестить оба подхода, чтобы что-то спихивалось на хардварь, а что-то на софтварь (с учетом количества доступной хардвари) - получится примерно то, что вы и хотите.

Edited at 2013-07-31 07:22 (UTC)
andybil From: andybil Date: le 31 juillet 2013 07:23 (UTC) (Ссылка)

Re: Дело не только в фон Неймане

O((log N)2), ага, то есть наши мозги могут распознать точку в темноте за очень большое время, однако мы справляемся гораздо быстрее.
kouzdra From: kouzdra Date: le 31 juillet 2013 07:26 (UTC) (Ссылка)

Re: Дело не только в фон Неймане

Не справляются. Там на сам деле полно эвристик всяких и приближенных и вероятностно верных решений. Так если вас устроят приближенные и "более или менее работающие" решения - все и на классической архитектуре все сильно ускорится.
andybil From: andybil Date: le 31 juillet 2013 07:28 (UTC) (Ссылка)

Re: Дело не только в фон Неймане

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

Edited at 2013-07-31 07:28 (UTC)
kouzdra From: kouzdra Date: le 31 juillet 2013 07:31 (UTC) (Ссылка)

Re: Дело не только в фон Неймане

В самолетах давно уже кстати. Там исключение человека из цепей управления основное направление.
andybil From: andybil Date: le 31 juillet 2013 07:30 (UTC) (Ссылка)

Re: Дело не только в фон Неймане

И да, приближенные любые вычисления, и любые вычисления эвристические, ибо процессор имеет ограниченное количество разрядов.
Это не ответ.

Edited at 2013-07-31 07:30 (UTC)
kouzdra From: kouzdra Date: le 31 juillet 2013 07:33 (UTC) (Ссылка)

Re: Дело не только в фон Неймане

Ну чтобы было вам понятнее - чтобы реализовать задачу быстрой проверки наличия элемента в массиве достаточно поставить n компараторов и завести их выходы на элемент или. Тот же гендель с вам разводку для этого сгенерит с лету - только если n велико - у вас получится и сложность по числу элементов соответствующая. А работать будет вообще за один такт.
andybil From: andybil Date: le 31 juillet 2013 07:36 (UTC) (Ссылка)

Re: Дело не только в фон Неймане

Это не та задача. Нужны координаты, что бы закрыть рукой огонёк за 200 мс.
kouzdra From: kouzdra Date: le 31 juillet 2013 07:44 (UTC) (Ссылка)

Re: Дело не только в фон Неймане

Так протащите за компанию индекс - будет посложнее схема и только.

Мозги примерно так и решают проблему - за счет чудовищно сложной, хоть и очень медленной схемотехники. Компам щас в основном проще гигагерцами тут брать.
rdia From: rdia Date: le 31 juillet 2013 15:31 (UTC) (Ссылка)

Re: Дело не только в фон Неймане

А прикольно будет сделать мозги, работающие на гигагерцовой частоте.
From: karpion Date: le 31 juillet 2013 18:35 (UTC) (Ссылка)

Re: мозги, работающие на гигагерцовой частоте.

Вы радиатор для этой системы представляете? Это не считая того, что будет проблемно вывести тепло из глубины мозга к его поверхности; а растягивать мозг или делать его плоским - удлиняются пути передачи сигнала.
Комментариев: 40 >< выразиться