Отличный код! Давно на Rails пишиет? Для себя «открыл» content_for <...> во вьюшках, с последующей вставкой в layout в виде yield(<...>) if yield(<...>), а так же ActiveRecord::BaseWithoutTable, вообще бы не подумал что так можно:) skip_before_filter в котнроллере тоже забавно. По какой литературе учились?

Да, участвовал в двух RoR проектах. Сейчас дали покапать чужой «быдлокод» на PHP (без фреймворка, без разделения данных и представления, все кучей в одном файле). И знаете что? Этот код мне кажется более понятным и поддерживаемым, чем наш собственый на руби. Это не проблема РоР, это наша проблема. Но в проекте участвовали другие очень компетентные люди. И получилось такое г… Кому нужна такая технология, что что-то сложнее блога за 15 минут которым одурманивают новичков выливается просто в непосильную задачу?

Хм интересно, но имхо wxRuby поинтереснее будет (полегче, рисует родными для ос средствами, лицензия LGPL)

А как вам примерно вот такой концепт?

Hashtable opts = OptParser.Get({{"-f", "--foo", OptOptions::REQUIRED},… });
string val = opts[«f»];

Не похож он на старые MVC фреймворки типа Spring, потому как там не только MVC просматривается но и соглашения по конфигурации, хелперы и прочие присущие RoR аттрибуты.

Хм… Мне кажеться или это очередной клон Ruby On Rails? :)

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

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

>ListSomeList = new List(); — Не вижу смысла.

А это +1.

Если уберут var, то достаточно будет просто SomeList = new List();
Было еще неплохо, что-то типа SomeList = [string];

Да, я вижу вы мыслите очень прагматично, и наверное это во многом правильный подход. C#, да это помойка, но я никак не могу назвать Java "аскетичной и минималистичной". Аскетичные и минималистичные языки в моем представлении - Lisp, Forth. Дизайн Java идеально подходит для студентов, которые получили диплом программиста, но недопоняли C/C++ и их можно быстро переучить до нужной кондиции, не ломая их представления о синтаксисе и подходе вообще. Java завязана на библиотеках, а они отнюдь и не минималистичны и не аскетичны.

Исследователи языков программирования уже не одно десятилетия пророчат лидерство декларативного подхода. Конечно у них есть свои аргументы "за". Ответом вопрос "на какой черт" наверное будет то что будет требоваться меньше строк кода для выражения мыслей. Меньше кода, меньше ошибок и тд... А еще имеет место уменьшение количества сущностей, что так же способствует пониманию. Хочу еще уточнить, что структурный подход это не антипод к динамическому:) Насчет валидности XML я что-то не понял. Так же как мы валидируем XML, мы можем и валидировать, скажем JSON, коль речь о JS зашла, кстати предмет нашего обсуждения имеет очень благородные корни - язык Self.

ассемблер - фортран - алгол - паскаль - си - си++ - java/c#

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

Что же дальше? Однозначно языки с динамической типизацией и переход к декларативности (C# 3.0 тому подтверждение, хоть и мейнстрим-язык, но тем не менее...). Все проблемы динамических языков, которые вы привели не столь важны, они легко решаются. Да проблемы есть, но они несколько в другом, они решаются и динамика потихоньку просачиваются в software factory. Скриптовые языки здесь ни причем:)

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

О недостатках JavaScript не видел статей уже последние несколько лет. Единственный весомый недостаток - различная (причем кривая) реализация в разных браузерах, что для серверных решений не имеет значения. Ограничение на язык серверной части есть - это предоставление хостинга и распространённость языка, второй критерий это как раз лакомый кусочек.

Предложите лучше:) Прелесть его в том что, если что-то не нравиться, то можно поправить, а вот всякие Java/PHP как были "глобальными и надежными" так ими и остануться.

JavaScript - отличнейший язык! Я сам поклонник Ruby, однако видел в том же prototype, что с помощью нехитрых вещей можно реализовать те же map, each etc для массивов. Система метапрограммирования позволяет слепить все что нужно

Именно как delphi-модуля нету. Конечно есть реализации для .NET и еще куча разных реализаций:
- YAML C Libraries:
- libyaml # New Fast YAML (1.1)
- Syck # Old Fast YAML (1.0)
- PyYaml # YAML 1.1 Implementation
- JsYaml # JavaScript PyYaml port
- RbYaml # Ruby port of PyYaml
- JvYaml # Java port of PyYaml
- ocaml-syck # Syck bindings for OCaml
- Perl Modules:
- YAML # Pure Perl YAML Module
- YAML::XS # Binding to libyaml
- YAML::Syck # Binding to libsyck
- YAML::Tiny # A small YAML subset module
- PlYaml # Perl port of PyYaml
- YamlReference # Haskell 1.2 reference parser
- YPaste # Play with the Haskell 1.2 parser

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

3. >Зачем они выбирают "плохое" решение? Не смешите меня
Это вы не смешите, интрепрайз на то он и интерпрайз - все должно быть стандартно и понятно любому идиоту, они никогда не ставили цели использовать что-то более менее современное. Их решения хороши с маркетинговой точки зрение, с технической они просто отвратительны.

"Изучив его вы сможете применять его во множестве областей программирования"
Ну я же не говорил, что "XML - не нужен", я его постоянно использую, однако хранить в нем конфиги это сверх избыточное решение, YAML штука специализированная и в общем-то примитивная по сравнению с XML, более того интуитивно понятная.

1. Для YAML уже написано куча библиотек под разные платформы. Если для вас скачать архив, распаковать и подключить компонент к проекту это препятствие перед тем что бы использовать лучшие решения.. чтож, пользуйтесь стандартными компонентами и бодрите себя мыслью, что они самые-самые....
3. А кто сказал что XML - плох? Плохим являеться решение использовать его для конфигурации каждого чиха в интрепрайз приложениях.

Про сравнение YAML и XML. Сравнивать их в общем смысле не корректно, ибо
"YAML — человекочитаемый формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования."

Т.е. XML язык разметки, а YAML нет, поэтому сравнивать их корректно только в нашем примере.

Ознакомиться с преимуществами YAML над XML в написании конфигурационных файлов можно на вики.

1. YAML как раз создавался для таких целей. В общем здесь все написано - http://ru.wikipedia.org/wiki/YAML
2. -
3. Использование XML-х конфигов свойственно для java приложений, которые в большинстве своем громоздки и не блещут свежими идеями.

Реляционная БД это реляционная БД, а этот hierarchyid смахивает на велосипед с квадратными колесами. Конечно возможно я ошибаюсь, но что-то у меня большие сомнения по производительности такого решения, ведь для реляционных бд есть математика и их можно оптимизировать, а вот для смешанных? Может все таки для иерархических структур использовать XML? Как вариант хранить XML-ки в реляционной бд, делать их выборки, а потом уже делать нужные выборки. Для XML бд вроде как разрабатываеться математика, следовательно есть вероятность что их скоро буду хорошо оптимизировать.

1) Конфиги лучше хранить в YAML формате
2) Конфиги зло, хотя в некоторых случаях действительно без них никак
3) Гибкие идеи не стоит искать среди интерпрайз решений

Это мое мнение, интересно будет послушать ваши возражения:)

Пост полезный, но полезный для тех кто любит лепить кастыли. Он лишний раз показывает кривость ASP.NET в чистом виде. Костылей можно сразу избежать, если использовать, скажем MVC. Там как раз можно принять, что все методы контроллеров (точнее сказать методы в данном случая имеет значение "actions") вызываються пользователем, и не морочить себе голову. Тем более что уже есть такая вещь как ASP.NET MVC.