Scheme будет разделён на два языка программирования

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

> Писать код на любом зрелом языке общего назначения - плевое по сути дело если голова есть, предметная матчасть усвоена и скилл имеется.

А... так ты суперпрограммист. Ну тогда ой.

> Дело тут в том что надо писать кучу левого кода который не делает ничего и кучу мейтенанса этого кода который не делает ничего.

О чем ты вообще?

>>У тебя, как у прогера, этот Loki и книга Александреску - родовая травма походу, ты их постоянно упоминаешь зачем-то.

> Эта библиотека хороша чистотой концепта

Ахренеть. А сериализация тут причем?

>Внезапно оказалось, что шаблоны - это такой интерпретируемый язык.

Ну делание идиотских классов вроде Array<T> это вообще вредная задача для метапрограммирования. Метапрограммирование это вообще слишком специфическая вещь и в нормальном языке должно быть возможным обойтись без него, особенно когда нужен просто динамический массивчег чтобы вернуть пачку каких-то виджетов/гаджетов/айтемов из простой процедуры.

> эти "))))" явно сделаны для роботов, а не для людей.

дану? эти "</xml></xml></xml>" несомненно гораздо лучше.

> Код который не делает ничего это код описывающий типы конечно.

ммм... мисье ниасили кодогенерацию...?

> Из-за динамической типизации не возникает потребности думать о том что там есть какой-то сериализатор в котором надо следить за декларациями интерфейсов.

пришел пакет, который ты не можешь распарсить. дальше что?

> явно сделаны для роботов, а не для людей.
> дану? эти "</xml></xml></xml>" несомненно гораздо лучше.

ничем не лучше, xml тоже не для людей

> В эрланге насколько я понимаю возникнет исключение

т.е. сервер вернет код ошибки? прелесть какая :)

дык в чем различие?

> ничем не лучше, xml тоже не для людей

json таки спасет мир?

> json таки спасет мир?

вы перескочили от языков программирования к описанию данных

> вы перескочили от языков программирования к описанию данных

да? ээээ... это я выше упомянул слово «сереализация»?

>> Писать код на любом зрелом языке общего назначения - плевое по сути дело если голова есть, предметная матчасть усвоена и скилл имеется.

>А... так ты суперпрограммист.

Что сложного в том чтобы написать код если знаешь язык и есть представление о том как он должен работать?

>> Дело тут в том что надо писать кучу левого кода который не делает ничего и кучу мейтенанса этого кода который не делает ничего.

>О чем ты вообще?

О коде который не несет полезной нагрузки, то есть о декларациях интерфейсов и структур характерных для языков со строгой типизацией. Например, в java есть ключевое слово "interface". Все то что написано после него не выполняет никаких действий до закрывающей фигурной скобки.

>> Эта библиотека хороша чистотой концепта

>Ахренеть. А сериализация тут причем?

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

>> В эрланге насколько я понимаю возникнет исключение

>т.е. сервер вернет код ошибки? прелесть какая :)

Эрланг хорош тем что он написан людьми разбирающимися в программировании. Они понимают что сервера постоянно будут дохнуть, т.к

a) Их будут писать через жопу. б) Версия протокола у клиента и сервера никогда не будет одинаковой.

Поэтому эрланг сделан так что там смерть сервера это нормальное ожидаемое событие.

> Например, в java есть ключевое слово "interface"

в java мы может посылать байткод без реализации на сервере. имхо не плохо.

в окамле мы можем передавать sexp-ы очень зачетно без всяктх inteface.

вопрос реализации?

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

> смерть сервера это нормальное ожидаемое событие

поток на клиент... в рамках одного процесса с псевдопотоками -- может быть. многопроцесорность просасывает?

> Что сложного в том чтобы написать код если знаешь язык и есть представление о том как он должен работать?

Это мне еще напоминает ответ на вопрос "как сделать тройное сальто?"

> в java есть ключевое слово "interface". Все то что написано после него не выполняет никаких действий до закрывающей фигурной скобки.

В рамочку и на стену.

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

Выбирай, какие проблемы...

>Версия протокола у клиента и сервера никогда не будет одинаковой.
Сервер от этого не должен дохнуть.

> дану? эти "</xml></xml></xml>" несомненно гораздо лучше.

То, что XML -- для роботов, практически и не отрицалось

> многопроцесорность просасывает?

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

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

хосты -- да. но процы? эрланг -- вм и все потоки у него псевдо. как он заграбастает многопроцовость?

Почитай про Эрланг.

hint: на каждый проц свои runqueue и шедуллер.

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

Ну глупость же. Ничто не мешает использовать message passing хоть в Си. А вот асинхронность эрлангового message passing - это принципиальная проблема.

> Ну глупость же. Ничто не мешает использовать message passing хоть в Си.

Да можно хоть компостером на перфокартах напробивать MP, но в Эрланге это всё равно в стотыщраз проще.

> Если для вас принцип code reuse - "бредни", то мне, пожалуй, нечего добавить.

Почитайте отчет о расследовании причин падения ракетоносителя Ariane 5.

> Может уже кто-то скажет ребятам что есть Ocaml, например. Где есть отличная система модулей

А что у Ocaml с поддержкой Unicode? Можно исходные тексты программ хранить в UTF-8?

>А что у Ocaml с поддержкой Unicode? Можно исходные тексты программ хранить в UTF-8?

А на С++ значит можно?

Работа с UTF8 есть в библиотеке batteries (правда пока еще бета). Насчет utf8 идентификаторов - не в курсе.

>>А что у Ocaml с поддержкой Unicode? Можно исходные тексты программ хранить в UTF-8?

>А на С++ значит можно?

>Работа с UTF8 есть в библиотеке batteries (правда пока еще бета). Насчет utf8 идентификаторов - не в курсе.

Использовать для переменных русские буквы и иероглифы меня почему-то не тянет. А вот использовать все строки и ресурсы в кодировке utf-8 очень удобно, что с легкостью можно делать в языках C, Java.

Должна остаться только одна кодировка - UTF-8 без BOM.

Хорошо хотя бы, что прогу для управления Ariane 5 писали не на Ruby

Конечно можно и на С MPI использовать и многопоточность, но я насмотрелся таких решений. Получалось так себе: race conditions, deadlocks это наше все. Конечно можно сказать, что де "писать надо лучше". Конечно надо, но где взять столько грамотных специалистов с богатым multithread бэкграундом, чтобы хорошо писалось. В Erlang есть итересные фичи, которые можно и в С поиметь, но это большая работа! Тысячи LOC'ов. А сколько багов там будет... А получится все равно что-то а ля Erlang :).

> А вот асинхронность эрлангового message passing - это принципиальная проблема.

Не вижу в этом большой проблемы. Хочешь синхронно да пожалуйста, на Erlang'e это сделать просто как мычание. Вот если бы все было синхронно это была бы большая проблема.

P.S. Да и вообще какая разница Erlang не Erlang, если это кому-то помогает зарабатывать деньги то весь этот thread > /dev/null

В общем нет, эти "))))" явно сделаны для роботов, а не для людей

Зато парсеры просто писать :)

Что-то менять уже поздно. Если "второй древнейший язык" еще не умер, то стоит оставить все как есть. Хотя бы из уважения к этому факту :)

>> Чистый функциональный язык не подходит для моделирования нашего до мозга костей объектного мира

> Вы видимо прогуляли все лекции, где говорили, например, про IDEF0.

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

даешь черепашку лого !

Python же не дохнет, и даже вам вполне себе ничего.. нет?

F#/ML поближе к Scala будут, чем к Haskell, который из преведенных единственный является "чистым". И с поддержкой Майкрософта F# думается популярнее будет, чем Scala.

> Писать код на любом зрелом языке общего назначения - плевое по сути дело если голова есть, предметная матчасть усвоена и скилл имеется.

Извините, но это не правда. Писать _качественный_ код решения любой более-менее нетривиальной задачи на любом языке дело сложное.

> статистика утверждает, что проекты использующие IDEF0 имеют существенно меньшие шансы быть завершенными, чем программы поекты которых разрабатывались на объектной основе.

Это феерично, давайте ссылку. Особенно если учитывать, для чего предназначен IDEF0.

>Чистый функциональный язык не подходит для моделирования нашего до мозга костей объектного мира, поэтому Scheme в пролете для enterprise (даже у Common Lisp там больше шансов, благодаря своему костылю CLOS).

еще один с ООП головного мозга. А хочешь простейший Ынтырпрайз пример, где оно ну совсем ни в красную армию?

>> статистика утверждает, что проекты использующие IDEF0 имеют существенно меньшие шансы быть завершенными, чем программы поекты которых разрабатывались на объектной основе.

> Это феерично, давайте ссылку. Особенно если учитывать, для чего предназначен IDEF0.

Ссылку уже не найду. Для чего предназначен IDEF0 - не важно. Важно то, что он хорошо верифицируется и для некоторых задач более подходящего не найти. Изучал эту проблему перед началом одного из проектов. Пришлось его использовать, Для объектных проектов разработана методология проектирования, шаблоны, методология рефакторинга, шаблоны рефакторинга, методология тестирования, шаблоны тестирования. Не хватает только верефицируемости. По многим параметрам объектные методологие проектирования существено лучше, чем IDEF0. К сожалению, верификационность для некоторых задач - это обязательное требование.

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

>> Ну глупость же. Ничто не мешает использовать message passing хоть в Си.

> Да можно хоть компостером на перфокартах напробивать MP,

М прикинь, масштабироваться это будет не хуже Эрланга :D

> но в Эрланге это всё равно в стотыщраз проще.

Речь вроде о масштабируемости шла.

>> А вот асинхронность эрлангового message passing - это принципиальная проблема.

> Не вижу в этом большой проблемы. Хочешь синхронно да пожалуйста, на Erlang'e это сделать просто как мычание.

И как?

> Вот если бы все было синхронно это была бы большая проблема.

Скажи это Хоару.

> Да и вообще какая разница Erlang не Erlang, если это кому-то помогает зарабатывать деньги то весь этот thread > /dev/null

Если бы ты и правда так считал, не ответил бы.

> Python же не дохнет

И слава ТНБ.

> и даже вам вполне себе ничего.. нет?

Динамически типизированное дерьмо :( Но по сочетанию качеств лучше ничего нет. Хотя писать на Питоне что-то большое мне лично очень стремно.

> с поддержкой Майкрософта F# думается популярнее будет, чем Scala.

Вероятно. И это плохо, потому что F# несвободный.

>> но в Эрланге это всё равно в стотыщраз проще.

>Речь вроде о масштабируемости шла.

Типичная стрелковская демагогия на тему "все можно сделать правильно если заранее все предусмотреть и сделать правильную инфраструктуру проекта". Реальность однако состоит в том что такой подход вреден, т.к инфраструктура может быть написана только постфактум. Но покольку постфактум она уже никому не нужна, то она вообще не может быть создана.

> Типичная стрелковская демагогия

Ты за MOP ответь %)

> инфраструктура может быть написана только постфактум

Ы. А чем тебе тот же Эрланг не инфраструктура? %) "Телекоммуникационный фреймворк со встроенным языком программирования" (с) anonymous@LOR

>> Типичная стрелковская демагогия

>Ты за MOP ответь %)

А что с MOP не так? Там все упирается в то что для статической типизации в распределенной среде весь зависимый код должен рекурсивно перекомпилироваться на всех узлах при появлении нового типа на одном из узлов. Это я уже писал раньше в каком-то динамическом сраче.

>> инфраструктура может быть написана только постфактум

>А чем тебе тот же Эрланг не инфраструктура

Наверно надо все же мыслить реалистично и стремиться к соотношению вида 80-20 или даже 90-10 между тем что обеспечивает сам язык и его библиотеки и тем чего в языке нет и должно быть написано.

> А что с MOP не так?

С MOP всё так. Ты объясни вот это:

> А чтобы гонять сериализованные формы нужен MOP. И собственно этот MOP исключает возможность сделать язык статически типированным.

...причем оба тезиса.

> для статической типизации в распределенной среде весь зависимый код должен рекурсивно перекомпилироваться на всех узлах при появлении нового типа на одном из узлов

Бред. Для любого типа, имеющегося в протоколе - да. И что? Это всегда так (за исключением откровенно бредовых и редких случаев, когда по сети передается исполняемый код для обработки новых типов пакетов).

>>А чем тебе тот же Эрланг не инфраструктура

>Наверно надо все же мыслить реалистично и стремиться к соотношению вида 80-20 или даже 90-10 между тем что обеспечивает сам язык и его библиотеки и тем чего в языке нет и должно быть написано.

Ичо? Где четкая разница между языком и библиотекой, и в чем она с точки зрения прикладника?

>> для статической типизации в распределенной среде весь зависимый код должен рекурсивно перекомпилироваться на всех узлах при появлении нового типа на одном из узлов

>Бред. Для любого типа, имеющегося в протоколе - да.

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

>Это всегда так

Это почти всегда не так. Я бы даже усилил это утверждение в стиле законов Мерфи: версия протокола у клиента и сервера вообще *не может* быть одинаковой. Допустим, синхронизации протоколов мешает Дъявол или энтропия Вселенной.

>Где четкая разница между языком и библиотекой, и в чем она с точки зрения прикладника?

Хорошие библиотеки обычно пишутся в наиболее естественным для языка стиле. Те которые пытаются переделать язык плохо стыкуются с имеющимся массивом кода и отсеиваются.

> вообще все типы должны являться частью протокола.

> версия протокола у клиента и сервера вообще *не может* быть одинаковой.

По этой части вопросов больше нет %)

Так что насчет MOP?

>Так что насчет MOP?

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

> Если система типов у языка статическая то при наличии параметризованных типов надо компилировать код в рантайме чтобы создать инстанс какого-то типа полученного из MOP.

Ты средствами MOP собираешься новые типы создавать? Если да, то зачем? И в чем проблема запустить компилятор в рантайме? Ява постоянно это делает :)

> А при отсутствии параметризованных типов интерфейсная часть будет экспоненциально раздуваться, оттягивая кучу сил на мейтенанс.

Слова вроде все понятны, а смысл - нифига.

>> Если система типов у языка статическая то при наличии параметризованных типов надо компилировать код в рантайме чтобы создать инстанс какого-то типа полученного из MOP.

>Ты средствами MOP собираешься новые типы создавать? Если да, то зачем?

Да потому что любая попытка выделить и поддерживать какую-то общую библиотеку типов для всех узлов в распределенной системе обречена на провал. Классический Dependency Hell.

>> А при отсутствии параметризованных типов интерфейсная часть будет экспоненциально раздуваться, оттягивая кучу сил на мейтенанс.

>Слова вроде все понятны, а смысл - нифига.

Характерно для состыковки кода написанного разными программистами. Полный комплект типов вида "Account", "Address" на каждый бакэнд, и каждый надо поддерживать.

>>> Если система типов у языка статическая то при наличии параметризованных типов надо компилировать код в рантайме чтобы создать инстанс какого-то типа полученного из MOP.

>> Ты средствами MOP собираешься новые типы создавать? Если да, то зачем?

> Да потому что любая попытка выделить и поддерживать какую-то общую библиотеку типов для всех узлов в распределенной системе обречена на провал.

_Этот_ вопрос уже закрыли. Если ты хочешь использовать все типы программы в сетевых пакетах, то я тебе не доктор.

>>> А при отсутствии параметризованных типов интерфейсная часть будет экспоненциально раздуваться, оттягивая кучу сил на мейтенанс.

>>Слова вроде все понятны, а смысл - нифига.

>Характерно для состыковки кода написанного разными программистами. Полный комплект типов вида "Account", "Address" на каждый бакэнд, и каждый надо поддерживать.

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

>Если ты хочешь использовать все типы программы в сетевых пакетах, то я тебе не доктор.

А это и есть фича эрланга - любой кусок можно отколоть и повесить на отдельный хост в любой момент. Либо на несколько хостов через балансировщик нагрузки.

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

Как раз правильный подход это когда можно вызвать метод которого не существует и получить перехватываемую ошибку. Это позволяет добавлять новые фичи с одной стороны не ломая рабочий код с другой стороны. Компилятор тут конечно бессилен.