На поднятие вопроса меня подтолкнула статья Тима Брея — в ней он очень сомневается в реальности а, может быть, и в нужности сего.
Собственно вопрос:
Как вы думаете, необходимо ли иметь встроенную в язык поддержку XML и операций с ним?
В голову по этому поводу приходит скала, да дотнетные вещи аля Comega и другие (конкретно уже не помню точно, где оно было реализовано в языке).
Насколько востребованы такие средства или всёже было бы лучше не "загрязнять" язык и оставить XML на уровне библиотек?
Здравствуйте, Курилка, Вы писали:
К>Насколько востребованы такие средства или всёже было бы лучше не "загрязнять" язык и оставить XML на уровне библиотек?
Нужно А также нужно макросное, метопрограммирование, декларативное, функциональное, поддержка регекспов, поддержка unittest, generetic, и т.д. Каждая группа программистов должна писать так как ей захочется. Независимо от политической, расовой и сексуальной принадлежности .
Курилка,
К>Как вы думаете, необходимо ли иметь встроенную в язык поддержку XML и операций с ним?
ХМЛ — это формат данных.
Иметь встроенную поддержку XML — это вводить оверхед, который для нишевых языков оправдан, а для универсальных — нет.
К>В голову по этому поводу приходит скала, да дотнетные вещи аля Comega и другие (конкретно уже не помню точно, где оно было реализовано в языке).
Scala:
val b = <book>
<title>The Scala Language Specification</title>
<version>{scalaBook.version}</version>
<authors>{scalaBook.authors.mkList("", ", ", "")}</authors>
</book>
Симпатично, но то же самое можно написать и в Java, и в C++, просто чуть более многословно, и парсить это выражение будет не встроенный парсер, а xerces.
К>Насколько востребованы такие средства или всёже было бы лучше не "загрязнять" язык и оставить XML на уровне библиотек?
Имхо, лучше ориентироваться на целостность, полноту и непротиворечивость, чем на сахар.
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>Здравствуйте, Курилка, Вы писали:
К>>Насколько востребованы такие средства или всёже было бы лучше не "загрязнять" язык и оставить XML на уровне библиотек?
AAV>Нужно А также нужно макросное, метопрограммирование, декларативное, функциональное, поддержка регекспов, поддержка unittest, generetic, и т.д. Каждая группа программистов должна писать так как ей захочется. Независимо от политической, расовой и сексуальной принадлежности .
Это ты верно подметил, определённо нужен язык со встроенной поддержкой геев, наверняка он найдёт свою нишу.
Здравствуйте, Курилка, Вы писали:
К>На поднятие вопроса меня подтолкнула статья Тима Брея — в ней он очень сомневается в реальности а, может быть, и в нужности сего. К>Собственно вопрос: К>Как вы думаете, необходимо ли иметь встроенную в язык поддержку XML и операций с ним? К>В голову по этому поводу приходит скала, да дотнетные вещи аля Comega и другие (конкретно уже не помню точно, где оно было реализовано в языке). К>Насколько востребованы такие средства или всёже было бы лучше не "загрязнять" язык и оставить XML на уровне библиотек?
Не...Мало ли чего еще напридумывают?! И для всего — вставлять ЯЗЫКОВУЮ поддержку? Не...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
К>>Насколько востребованы такие средства или всёже было бы лучше не "загрязнять" язык и оставить XML на уровне библиотек? LVV>Не...Мало ли чего еще напридумывают?! И для всего — вставлять ЯЗЫКОВУЮ поддержку? Не...
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>А также нужно макросное,
Если макросы ala С — то нам с ними не по пути,
Если макросы Немерле — это в п.2.
AAV> метапрограммирование,
Да, хорошо бы, чтобы меньше copy-paste.
AAV> декларативное,
Куда ж без SQL то родимого?
Вот LINQ нам грозятся сделать.
AAV> функциональное,
мысли зачем это надо здесь
.
AAV> поддержка регекспов,
тоже клево,
правда не стоит увлекаться, а то получится Perl .
AAV> поддержка unittest,
очень полезно
AAV> generic
удобно, но можно также делать через метапрограммирование.
AAV>Каждая группа программистов должна писать так как ей захочется. Независимо от политической, расовой и сексуальной принадлежности .
Точно.
Но есть три подхода:
1) Зачем нам много возможностей. Пусть язык будет попроще, остальное в библиотеках.
Это скорее С и Java.
2) Встроим как можно больше фич прямо в стандарт языка.
С#?
3) Включить в стандарт языка необходимое, снабдив его возможностями к расширению.
Наиболее чисто последнюю концепцию выражает Lisp.
Хорошо ее выражает Nemerle
и в некоторой степени к этому пришел С++ с его шаблонами
(хотя со всеми фичами его стандарт достаточно тяжеловесен).
D находится где-то между 2 и 3, поскольку хотя и близок к С++ в него еще встроенных средств напихали.
Здравствуйте, Mamut, Вы писали:
К>>>Насколько востребованы такие средства или всёже было бы лучше не "загрязнять" язык и оставить XML на уровне библиотек? LVV>>Не...Мало ли чего еще напридумывают?! И для всего — вставлять ЯЗЫКОВУЮ поддержку? Не...
M>Уже напридумывали
M>YAML, JSON, ASN.1, PostScript, TeX, SGML...
Ладно JSON, на то он и JS, это понятно, что он интегрируется, а вот остальное? Особенно SGML меня интересует...
LVV>>>Не...Мало ли чего еще напридумывают?! И для всего — вставлять ЯЗЫКОВУЮ поддержку? Не...
M>>Уже напридумывали
M>>YAML, JSON, ASN.1, PostScript, TeX, SGML...
К>Ладно JSON, на то он и JS, это понятно, что он интегрируется, а вот остальное? Особенно SGML меня интересует...
JSON in ActionScript:
JSON in C.
JSON in C++.
JSON in C#.
JSON in Cold Fusion.
JSON in Delphi.
JSON in E.
JSON in Erlang.
JSON in Java.
JSON in JavaScript.
JSON in Lisp.
JSON in Lua.
JSON in ML and Ruby.
JSON in Objective C.
JSON in Objective CAML.
JSON in OpenLaszlo.
JSON in Perl.
JSON in PHP.
JSON in Python.
JSON in Rebol.
JSON in Ruby.
JSON in Squeak.
YAML 1.1 for Python, written by Kirill Simonov.
YAML 1.1 for Ruby, written by Ola Bini (port of Kirill's work).
Toby Ho's Java binding is Jyaml.
WhyTheLuckyStiff's multi-language (Ruby, Python, PHP, OCaml) implementation is here
Kirill Simonov's Python binding for Syck is here.
Brian Ingerson's Perl binding for Syck is here.
Slaven Rezic's Javascript implementation is at http://sourceforge.net/projects/yaml-javascript.
Здравствуйте, VladGalkin, Вы писали:
AAV>>> поддержка unittest, АХ>>очень полезно VG>Хм, это интересно. А если это сделать в Nermerle?
На макросах это можно сделать довольно легко. Можешь заняться если есть жилание.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Андрей Хропов, Вы писали:
АХ>2) Встроим как можно больше фич прямо в стандарт языка. АХ> С#?
Я бы сказал, что C# выбрал золотую середину.. Между пунктом 1 и 2....
АХ>Что вам больше по душе? АХ>Мне последнее.
Ну не правильно это! Не должен программист для того что бы самому написать аля Hello world писать вначале свой язык программирования. Да, я сторонник DSL и макропрограммирования, но внутренний разработчик должен иметь максимально богатые возможности самого языка, он не должен задумываться как ему это правильно написать, он должен задумываться как это будет работать, как это будет взаимодействовать с другими частями программы, как это потом вольется в общий проект. Сам язык, сама технология программирования на этом языке, должна быть настолько гибка, что любой программист сел и начал писать в свойственной ему манере. При этом делал это настолько быстро и эффективно, насколько можно себе это позволить. И здесь не помогут макросредства. Внутренний язык должен быть настолько сильным и функциональным, что бы мог обеспечить комфортабельную работу любого программиста не зависимо от его .... А то последнее время с подачи сильных мира сего макропрограммирование стало чуть ли не Чашей Грааля от любых бед и для любого решения. Ну не правильно это!
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>Ну не правильно это! Не должен программист для того что бы самому написать аля Hello world писать вначале свой язык программирования. Да, я сторонник DSL и макропрограммирования, но внутренний разработчик должен иметь максимально богатые возможности самого языка, он не должен задумываться как ему это правильно написать, он должен задумываться как это будет работать, как это будет взаимодействовать с другими частями программы, как это потом вольется в общий проект. Сам язык, сама технология программирования на этом языке, должна быть настолько гибка, что любой программист сел и начал писать в свойственной ему манере. При этом делал это настолько быстро и эффективно, насколько можно себе это позволить. И здесь не помогут макросредства. Внутренний язык должен быть настолько сильным и функциональным, что бы мог обеспечить комфортабельную работу любого программиста не зависимо от его .... А то последнее время с подачи сильных мира сего макропрограммирование стало чуть ли не Чашей Грааля от любых бед и для любого решения. Ну не правильно это!
Дык, колега, Вам прямой путь к Немерле. Он как раз удовлетворяет всем перечисленным критериям.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Дык, колега, Вам прямой путь к Немерле. Он как раз удовлетворяет всем перечисленным критериям.
Неа... Лет 6-7 назад мне часто приходилось гонять по областным центрам, филиалам заказчика, поддерживая и дорабатывая систему на ходу, все время подлатывая систему под определенный тип/формат входных/выходных данных, конфигурируя логику и вырабатывая ряд рекомендательных решений (утилит) не отходя от серверной стойки. Чем мне в данном случае помогут макроопределения и др. прелести Немирлы, когда у меня в наборе промышленная СУБД, Far, компилятор и полное отсутствие возможности пронести какие либо диски, флешки и т.д? В данном случае, чем богаче язык, тем меньше кода (с нуля) мне придется написать для того, чтобы родить утилиту аля "для экспорта данных нужно вначале запустить эту утилиту, а только потом выполнить экспорт", тем меньше времени я проведу занимаясь "сексом стоя", и тем быстрее я приеду в свою любимую кроватку.
PS Тока не надо посылать меня в раздел управления, сам знаю
Здравствуйте, ArhAngelVezel, Вы писали:
AAV> Неа... Лет 6-7 назад мне часто приходилось гонять по областным центрам, филиалам заказчика, поддерживая и дорабатывая систему на ходу, все время подлатывая систему под определенный тип/формат входных/выходных данных, конфигурируя логику и вырабатывая ряд рекомендательных решений (утилит) не отходя от серверной стойки. Чем мне в данном случае помогут макроопределения и др. прелести Немирлы, когда у меня в наборе промышленная СУБД, Far, компилятор и полное отсутствие возможности пронести какие либо диски, флешки и т.д? В данном случае, чем богаче язык, тем меньше кода (с нуля) мне придется написать для того, чтобы родить утилиту аля "для экспорта данных нужно вначале запустить эту утилиту, а только потом выполнить экспорт", тем меньше времени я проведу занимаясь "сексом стоя", и тем быстрее я приеду в свою любимую кроватку.
Дыу Nemerle — это самый богатый язык на сегодняшний день. И достигнуто это не в последнюю очередь (это если быть оооОочень скромным) за счет тех самых макросов.
Вот какой язык ты сам считашь богатым (т.е. подходящим для написания твоих утилит)?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
. 
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Об этом-то и речь 
