LINUX.ORG.RU

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

 , , , ,


0

0

Комитет разработчиков языка программирования Scheme принял решение о разделении спецификации языка на две составляющих: описание «малого языка», ориентированного на обучение; и «большого языка», ориентированного на промышленную разработку.

Спецификация «малого Scheme» будет основываться на R5RS, и полностью соответствовать заложенным в RnRS принципам: «языки программирования должны проектироваться не путём последовательного нагромождения возможностей». В целях повторного использования существующей образовательной базы, предполагается сохранять как можно большую обратную совместимость с существующими стандартами Scheme.

Спецификация «большого Scheme» будет основываться на R6RS, и включать максимальное количество возможностей, признанных полезными в промышленной разработке: сетевое программирование, потоки, интернационализация, FFI, и т.д.

Предполагаются публичные отчёты через 6 и 12 месяцев с начала работы групп; публичный драфт стандарта через 18 месяцев; финальный драфт через 24 месяца.

Обсуждение на LtU: http://lambda-the-ultimate.org/node/3582

Описание «малого Scheme»: http://scheme-reports.org/2009/working-group-1-charter.html

Описание «большого Scheme»: http://scheme-reports.org/2009/working-group-2-charter.html

>>> Подробности

★★★★★

Проверено: maxcom ()
Ответ на: комментарий от Kuka

Прикладной софт должен быть написан на языке прикладной области. Что это за универсальный такой "объектный мир" мне непонятно.

Расскажите еще об этом.

Про костыль смешно :) Этак в 80е тру индустриал программеры все такие объектные из себя объектные. Особенно на фоне всяких лиспов да смолталков.

Кобол это судьба индустриального программера, в том числе и на "объектах" можно писать на коболе.

Но вообще какая эволюция, от бредней о "повторном использовании кода", до "объектов на которых можно писать про мир". Напоминает эволюцию "7ми уровневой модели". :)

psv1967 ★★★★★
()
Ответ на: комментарий от psv1967

Лучше так:
http://www.google.ru/insights/search/#q=common%20lisp%2CFreeBSD%2CICQ&cmpt=q

Сразу видно, что культ вокруг LISP - такая же типично постсовковая зараза, как и FreeBSD, и ICQ.

Цивилизованный Запад всем этим уже давно не интересуется.

Kuka ★★
()
Ответ на: комментарий от psv1967

> Прикладной софт должен быть написан на языке прикладной области.

У прикладной области (подмножества окружающего мира) не может быть языка.

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

> бредней о "повторном использовании кода"


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

Kuka ★★
()
Ответ на: комментарий от Kuka

А что будет, если посмотреть на Java. Он вообще нужен только индусам.

mdraven
()
Ответ на: комментарий от psv1967

Простейший случай code reuse - это процедуры и функции, лежащие, кстати, в основе LISP и Scheme.

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

Kuka ★★
()
Ответ на: комментарий от mv

> про троицу Lisp-ML-Erlang ещё много чего услышите.

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

Скорее, услышим о гибридах типа Scala против "чистых" вроде F#/ML и Haskell.

tailgunner ★★★★★
()
Ответ на: комментарий от Kuka

> Чистый функциональный язык

Ну кто вам сказал, что он функциональный?

> не подходит для моделирования нашего до мозга костей объектного мира

ООП - набор баззвордов.

> даже у Common Lisp там больше шансов, благодаря своему костылю CLOS

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

> А если речь идет об industrial - то там рулят микроконтроллеры, Си и ассемблеры

Про Форт мсье не слышал?

grusha
()
Ответ на: комментарий от resurtm

>>какие ERP, билинги, ОС на нем существуют?

>Не суетись


у него не суета, а банальный неумный троллинг

black7
()
Ответ на: комментарий от smh

>Ага. И бесспорные лидеры - Идия и Пакистан.

ты расист?

black7
()

Да глупости это все конечно. Весь мир де объекты. Так-то оно так, да стрелочки не забудьте поставить между объектами. Одним словом в данных конкретных обстоятельствах происходит шифт в сторону стрелочек. А полнее говоря. Теория категорий рулиз как метаязык. А отсюда следует что Хаскелл оправдан и не так уж и плох . Я тут еще разок взглянул.Терпимо вобщем. Можно использовать. И для железяк (LAVA, Atom) и для метапрограммирования и как функциональный язык с поддеркой параллелизма. А реюзабельность обеспечивается строгой типизацией.

kristall ★★
()
Ответ на: комментарий от Zenom

>Напоминает ситуацию с OCaml и Caml light. И кому этот Caml light нужен?

Может, академической среде? Будет что-то вроде латыни для медиков - не видоизменяется каждые полгода, не надо менять учебные планы, методички и т.п.

Turbo_Mascal
()
Ответ на: комментарий от tailgunner

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

Это тупо - судить по второстепенным признакам не анализируя то почему он динамически типированный. Видишь ли, дело в том что эрланг перестанет быть эрлангом если из него убрать возможность гонять сериализованные формы через инстантсами эрланга по TCP/IP. А чтобы гонять сериализованные формы нужен MOP. И собственно этот MOP исключает возможность сделать язык статически типированным. Если же вносить отдельную сущность с интерфейсами a-la CORBA которые статически компилируются в эрланговый код то получится гиморой на пустом месте ради статической религии с нулевым профитом. Привет.

Absurd ★★★
()
Ответ на: комментарий от Turbo_Mascal

>*sheme*...
>>Диаграмма приняла совершенно иной вид. :)


Стоит ещё учесть, что слова lisp и emacs значат именно язык программирования и емакс. А scheme - это всё же менее однозначное слово. Из тех запросов, что гугель мне показал:

>Scrap scheme boosts new car sales

>Krion 'a Ponzi-type scheme'

>`No voluntary disclosure scheme'


Итд. Так что я бы не стал по этим графикам утверждать, что scheme захватывает мир.

Laz ★★★★★
()
Ответ на: комментарий от Laz

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

Я и не против. Мне достаточно того, что он есть.

А кто и что там захватывает мне фиолетово.

Turbo_Mascal
()
Ответ на: комментарий от Absurd

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

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

Динамическая типизация - это второстепенный признак? Узнаю Абсурда.

> чтобы гонять сериализованные формы нужен MOP.

Да.

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

Нет.

tailgunner ★★★★★
()
Ответ на: Проектирование непутём. от Camel

>Эта фраза и в оригинале так звучит, или у неё есть продолжение

продолжения нет. в оригинале "programming languages should be designed not by piling feature on top of feature"

jtootf ★★★★★
() автор топика
Ответ на: комментарий от volh

>может тогда уж назвать большую схему как-нибудь по-другому?

"the names of the languages to be developed by working groups 1 and 2 have not yet been determined". т.е. вполне возможно, что ни один ни другой не будут носить названия Scheme

jtootf ★★★★★
() автор топика
Ответ на: комментарий от Turbo_Mascal

>Я и не против. Мне достаточно того, что он есть. А кто и что там захватывает мне фиолетово.

Поддерживаю :)

Laz ★★★★★
()
Ответ на: комментарий от tailgunner

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

>Динамическая типизация - это второстепенный признак? Узнаю Абсурда.

Статическая типизация это некий дополнительный кариес с которым можно жить, то есть второстепенный признак.

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

>Нет.

Без удвоения сущностей и костылей в виде биндингов статика<->динамика, манифестов каких-нибудь долбаных с интерфейсами - да, исключает. А язык и так непривычный для большинства, не стоит его усложнять.

Absurd ★★★
()
Ответ на: комментарий от jtootf

>>Статическая типизация это некий дополнительный кариес

>ого

Ну да, это некий дополнительный фактор который надо вычитать из продуктивности. Потребность делать интерфейс или специализированную структуру на каждый чих, итп в том же роде.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> Статическая типизация это некий дополнительный кариес с которым можно жить, то есть второстепенный признак.

Бгг. Тогда вообще все признаки второстепенны - со всеми можно жить. С отсуствием MOP - тоже.

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

>>Нет.

> Без удвоения сущностей и костылей в виде биндингов статика<->динамика, манифестов каких-нибудь долбаных с интерфейсами - да, исключает.

Нет. Я могу написать сериализатор для Си, который будет сериализовывать и десериализовывать любые Си-структуры, без изменений в языке. А в Си даже MOP нет.

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

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

Динамическая типизация - это quick'n'dirty hack разработчиков языка. Упрощает жизнь им, но не прогерам долгоживущих программ.

tailgunner ★★★★★
()
Ответ на: комментарий от Absurd

> Потребность делать интерфейс или специализированную структуру на каждый чих, итп в том же роде

к структуре надо приучать.

Rastafarra ★★★★
()
Ответ на: комментарий от tailgunner

>> Статическая типизация это некий дополнительный кариес с которым можно жить, то есть второстепенный признак.

>Бгг. Тогда вообще все признаки второстепенны - со всеми можно жить. С отсуствием MOP - тоже.

Статическая типизация отличается тем что она усложняет работу и создателям языка и программистам.

>> Без удвоения сущностей и костылей в виде биндингов статика<->динамика, манифестов каких-нибудь долбаных с интерфейсами - да, исключает.

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

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

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

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

Да, давай сравним тупой как пробка вызов функции через указатель с чем-то типа Loki::Functor<>.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> Без удвоения сущностей и костылей в виде биндингов статика<->динамика, манифестов каких-нибудь долбаных с интерфейсами - да, исключает.

это просто соглашение. сериализатор запросто релизуется и без биндингов, просто метапрограммированием. типы естественно надо описать с двух сторон.

Rastafarra ★★★★
()
Ответ на: комментарий от Rastafarra

>> Потребность делать интерфейс или специализированную структуру на каждый чих, итп в том же роде

>к структуре надо приучать.

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

Absurd ★★★
()
Ответ на: комментарий от Absurd

> Статическая типизация отличается тем что она усложняет работу и создателям языка и программистам.

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

Rastafarra ★★★★
()
Ответ на: комментарий от Absurd

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

да, народ (и я, кстати поначалу тоже) с системой типов склонен бороться.

но. если научиться (а это неизбежно) ей пользоваться... все ставновится намного проще. и в плане поддержки кода тоже.

Rastafarra ★★★★
()
Ответ на: комментарий от Rastafarra

>типы естественно надо описать с двух сторон.

Вот тут и есть слабое место которое будет постоянно ломаться, т.к в реальном мире эти типы никогда не будут согласованы.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> эти типы никогда не будут согласованы.

тогда client<--->server ломается.

Rastafarra ★★★★
()
Ответ на: комментарий от Absurd

ха, я видимо вместо К.О. седня )

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

Rastafarra ★★★★
()
Ответ на: комментарий от Kuka

ну конечно выбор запада (США и Японии) r[56]rs :)

psv1967 ★★★★★
()
Ответ на: комментарий от Absurd

> Статическая типизация отличается тем что она усложняет работу и создателям языка

Плевать мне на их сложности.

> и программистам.

А мне не усложняет, прикинь. Вот динамическая - усложняет.

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

Айлол. А на Эрланге сериализатор - не костыль между тупым сетевым форматом и родным Эрланг-объектом? Да ровно то же - на входе описание объекта и сам объект, на выходе - массив байтов.

> давай сравним тупой как пробка вызов функции через указатель с чем-то типа Loki::Functor<>.

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

tailgunner ★★★★★
()
Ответ на: комментарий от Kuka

>> Прикладной софт должен быть написан на языке прикладной области.

>У прикладной области (подмножества окружающего мира) не может быть языка.

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

Угу и именно поэтому куча банков тянут свои собственные APL системы поддержки бизнеса. Там все очень так объектно, объектно.

>> бредней о "повторном использовании кода"

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

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

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

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

psv1967 ★★★★★
()
Ответ на: комментарий от Unknown

> Индия и Россия любят LISP, а еще популярность лиспа неуклонно падает

Первое да, а второе нет. Скорее всего находит свое подтверждение теория о равенстве суммарного кол-ва интеллекта на планете константе.

> Числа на графике показывают долю поисков по заданному запросу в общем числе поисков, выполненных в Google за определенное время. Эти числа не представляют абсолютные значения объема поиска, поскольку данные приводятся в нормализованном виде и отображаются на шкале от 0 до 100. Каждая точка на графике соотносится с максимальным значением, т. е. 100. При отсутствии достаточного количества данных отображается значение 0. Числа, указываемые рядом с поисковыми запросами над графиком, представляют собой суммарные значения.

psv1967 ★★★★★
()
Ответ на: комментарий от Absurd

>Статическая типизация отличается тем что она усложняет работу и создателям языка и программистам.

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

Zenom ★★★
()
Ответ на: комментарий от tailgunner

>этот Loki и книга Александреску

А ты почитай. Феерическая книга. Может ушибнуть. template meta-programming это же о-го-го. Моск выносит.

Может уже кто-то скажет ребятам что есть Ocaml, например. Где есть отличная система модулей, вроде как целиком и полностью перекочевавшая туда из Ады (правда могу ошибаться).

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

Macil ★★★★★
()
Ответ на: комментарий от Macil

>>этот Loki и книга Александреску

>А ты почитай.

Ты правда думаешь, что я ее не читал? :)

> template meta-programming это же о-го-го. Моск выносит.

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

> Может уже кто-то скажет ребятам что есть Ocaml, например. Где есть отличная система модулей, вроде как целиком и полностью перекочевавшая туда из Ады (правда могу ошибаться).

И ошибаешься.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Ты правда думаешь, что я ее не читал? :)

Ну так если чтал - какие проблемы :) Людям, которые пытаются применить положения на практике нужно сочувствовать, а не прикалываться.

Macil ★★★★★
()
Ответ на: комментарий от tailgunner

>> и программистам.

>А мне не усложняет, прикинь.

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

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

>А на Эрланге сериализатор - не костыль между тупым сетевым форматом и родным Эрланг-объектом?

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

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

Эта библиотека хороша чистотой концепта. В бусте много динамических компромиссов, #ifdef-ов c компиляторо-специфическими цацками и прочим.

Absurd ★★★
()
Ответ на: комментарий от Rastafarra

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

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

Absurd ★★★
()
Ответ на: комментарий от psv1967

ну дык в рашке карго культы же. Вот теперь лиспу поклоняются

krasnoglazeg
()
Ответ на: комментарий от Kuka

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

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

sv75 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.