Здравствуйте, VladD2, Вы писали:

VD>Дело не только в мусоре.
VD>Дело еще и в голове. Блаб не понимающий что написано в коде оценит самый выразительный и лаконичный код как совершенно запутанный и непонятный.

Кто угодно (даже VladD2!!!), не понимающий в коде, оценит самый выразительный и лаконичный код как совершенно запутанный и непонятный.

Здравствуйте, VladD2, Вы писали:

VD>А пользовался им?
VD>Если ответ — да, то еще один вопрос. А пробовал ли ты преобразовывать XML без XSLT (или аналогичного инструмента)? Ну, скажем через DOM?
VD>Любой кто это делал знает, что использовать XSLT на порядок продуктивнее.
VD>Точно так же на порядок продуктивнее использовать и другие инструменты. Вот для развития того же компилятора продуктивнее использовать квази-цитирование и подсистему вроде макросов. Но в МС это пока что просто не понимают. И это не смотря на то, что у них есть F# в котором квази-цитирование присутствует.

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

VD>Точно так же возможность создания встроенных (в основной универсальный язык) микро-DSL-ей способно поднять производительность прикладника. Ведь код будет получаться более высокоуровневый. В нем можно допускать меньше ошибок. Ведь отладка ДСЛ-я намного проще чем отладка гор кода написанного без его использования.

С одной стороны, да, ты говоришь резонно. Обоснованная потребность в отдельных встроенных DSL'ях возникает очень редко и круг задач весьма ограничен. МС предпочитает делать специализированное решения, которые имеют важное преимущество: они стандартны и well-known. Соответственно, для проекта just-for-fun я бы выбрал lisp-подход, когда по сути мы сначала для себя делаем некий уникальный и идеально подходящий нам DSL, а потом на этом DSL'e воротим горы. Но вот для промышленного проекта, который разрабатывается кучей народа и который должен пережить несколько поколений разрабатывающих/поддерживающих его команд, я выберу подход МС. Это надежнее.

VD>Ага. И по этому ты ни разу так и не создал ни одного инструмента который бы тебе помог. Вместо этого ты долбишь землю каменной мотыгой и споришь с теми кто тебе предлагает использовать трактор и плуг.

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

Здравствуйте, prVovik, Вы писали:

G>>Легко. Сравни STL со всеми предыдущими контейнерными библиотеками. А ведь STL задействует и полагается на всего лишь пару фич языка — шаблонные функции, и "функторы", которые позволяют выражать замыкания и функции высшего порядка. Применение последних _концепций_ и делает библиотеку настолько выразительной и простой.

V>Согласен, но я не то имел ввиду, просто недостаточно четко выразился. Я имел ввиду, что конкретно Майкрософт скорее вводит в язык фичи, которые полезны для фреймворка/средств разработки чем придумывает некую абстрактную фичу языка, а потом постепенно начинает эту фичу использовать во фреймворке. Пример последнего — дженерики, пример первого — всё остальное. Хотя, может я чего и упустил (например анонимные делегаты).

Не то чтобы я спорил бы. Но мне кажется, Шарп в принципе и не должен развиваться по другому. Сила .NET как раз в том, что он изначально многоязычный by design, что позволяет выполнить "диверсификацию", удовлетворяя разными языками потребности разных групп пользователей. Ориентацией на многоязычность МС сильно развязал себе руки. Хотите более радикальный и инновационный подход — берите F#. C# — ориентирован на более консервативную аудиторию, он позиционируется как самый мэйнстримовый язык MS-а, нет? Однако, удивительное рядом. Я не силен в третьем шарпе, но судя по тем отголоскам и слухам, что до меня доходят — в его развитии Майкрософт зашел несколько дальше, активно заимствуя новые концепции, чем добавление простых клуджей-одноходовок под нужды библиотек.

Здравствуйте, Gaperton, Вы писали:

G>Я вообще-то тебе не "справку о крутости" даю и не аргументы, а провожу ликвидацию безграмотности, рассказав, что такое Гартнер и заодно — IDC. Теперь ты это знаешь, не так ли? Облажался ты действительно до крайности смешно — в первой же фразе, ну что ж, это урок всем нам .

Я знаю ЧТО? Что это крутой мужик, с извесной фирмой? Это хоть как-то отменяет тот факт, что его hype методика базируется на последствиях, а не причинах? Чем отличаются последствия от причин я тебе уже писал.

M>>Никто не оспаривает крутости Аристотеля, но как по мне, то лучше пользоваться моделью движения планет от Коперника.

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

Чем лучше пользоваться ДЛЯ ЧЕГО? Чтоб заработать денег? Если по быстрому — то конечно нужен маркетинг.
А если пользоваться общими законами развития — то маркетинг будет следовать этим законам, а не наборот.
Только у них более длительный срок действия, это сила которая двигает, медленно, но неуклонно. А маркетинг — это броуновское
движение на фоне общих законов развития. С моей точки зрения. А ты, видимо, считаешь маркетинг в этом месте главным,
раз без него мы не можем поискать причин медленности прогресса.

G>Итак, ты в довольно экзотической форме, одной фразой, сразу дал мне понять, что до маркетинга от твоей работы как до Аристотеля, и никакой практики ты в этом деле никогда не имел. Хорошо, не вопрос. Не знаешь, не понятно — спроси по человечески. Я одного не пойму — зачем ты с такой бездонной глубиной знаний спорить-то лезешь, а? Ты ведь, на минуточку, не зная что такое Гартнер, самоутвердится только что пытался за его счет крупнейшего профессионального хайтечного аналитического агенства. Самому не смешно? Тебе еще аргументы какие-нибудь нужны? Осень наступила чтоли, не пойму?

Ты мне хоть один аргумент приведи, кроме крутизны и бездонности знаний тов.Гартнера.
Возьми его методику на вооружение и выведи из неё — куда будет идти прогресс, какие идеи так и останутся без надобности, а какие будут востребованы. Скажи когда нужна будет та или иная технология (ведь нужно прийти с ней "вовремя", не так-ли?).
Главное — что hype методика может ПРЕДСКАЗАТЬ, а не "объяснить" ПОСТФАКТУМ.
Вот прям по пунктам, которые ты описал —
а) эволюционность и революционность технологии, как их разделить, как определить сроки требуемые для революционных технологий, почему одни выстрелили (вроде C/Unix), а другие нет (вроде Lisp/FP), и если выстреля — то когда.
б) методику разделения технологий на меняющие жизнь и нет, почему ты решил, что Nemerle не меняет жизнь, какие из IT технологий поменяют нашу жизнь и т.п.
в) как пресказать — вовремя вошла технология или нет, почему пришедшая раньше срока технология умирает (вместо чтоб возродиться когда прийдёт ей время) и т.п.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, prVovik, Вы писали:

VD>>>Разница есть, но небольшая — ты отдельно отлаживать кодопостроитель, и отдельно прикладную программу.
VD>>>Но макросы редко занимаются динамикой и в большинстве случаев заменить их динамикой или нельзя или это приводит к серьезным жертвам (производительности, стабильности и надежности)

V>>В данном случае я писал конкретно про макрос late, а не про макросы вообще.

VD>Тогда не ты должен понимать, что как аргумент в общем споре это не канает.

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, prVovik, Вы писали:

V>>Все верно, только термины целевой платформы совпадают с терминами бизнес-домена

AVK>Только частично. Полного совпадения в прироже не бывает.

V>>, и эти "программисты" не знают ни сишарп, ни тем более немерле.

AVK>Ну и что? Программисты на 1С тоже ничего этого не знают, вот только результатом снижение гибкости, производительности, качества.
Ну зачем же так обидно то. Не только знаем, но и используем, правда в основном в связке с 1С, увеличивая ее гибкость, производительность и разумеется качество

Здравствуйте, nikov, Вы писали:

N>Некоторые объяснения и возражения здесь

Автор: nikov
Дата: 08.09.08

.

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

Здравствуйте, VladD2, Вы писали:

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

Можешь привести пример таких задач? Я имею ввиду, чтобы на макросах задача решалась хорошо, а без — сильно хуже. Я уже просил Sinclair'a, он привел в качестве примера динамический доступ к свойствам.

VD>Факт. Но он доступен только тем кто не отрицает все что выходит за рамки того к чему его приучили.
Ага.

VD>Вот только вряд ли она тебе поможет в решении твоих задач. В отличии от...
Вопрос в объемах помощи.

VD>Невнятная гора кода — это не лучше или хуже. Это — пипец. Это заваленные сроки, глючная программа, море нервов...

Зато на обычном коде хорошо работают автоматические средства рефакторинга. В отличии от ручных DSL'eй, о которых тулзы ничего не знают.

VD>При этом других средств попросту нет.

Есть — голова на плечах и руки, растущие откуда надо. Это универсальное средство

Здравствуйте, Gaperton, Вы писали:

G>Не то чтобы я спорил бы. Но мне кажется, Шарп в принципе и не должен развиваться по другому. Сила .NET как раз в том, что он изначально многоязычный by design, что позволяет выполнить "диверсификацию", удовлетворяя разными языками потребности разных групп пользователей. Ориентацией на многоязычность МС сильно развязал себе руки. Хотите более радикальный и инновационный подход — берите F#. C# — ориентирован на более консервативную аудиторию, он позиционируется как самый мэйнстримовый язык MS-а, нет? Однако, удивительное рядом. Я не силен в третьем шарпе, но судя по тем отголоскам и слухам, что до меня доходят — в его развитии Майкрософт зашел несколько дальше, активно заимствуя новые концепции, чем добавление простых клуджей-одноходовок под нужды библиотек.

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

Здравствуйте, mkizub, Вы писали:

G>>Я вообще-то тебе не "справку о крутости" даю и не аргументы, а провожу ликвидацию безграмотности, рассказав, что такое Гартнер и заодно — IDC. Теперь ты это знаешь, не так ли? Облажался ты действительно до крайности смешно — в первой же фразе, ну что ж, это урок всем нам .

M>Я знаю ЧТО? Что это крутой мужик, с извесной фирмой? Это хоть как-то отменяет тот факт, что его hype методика базируется на последствиях, а не причинах? Чем отличаются последствия от причин я тебе уже писал.

Ну хорошо, давай поговорим. Опустим то, что ты мне писал об отличиях причин отследствий (я, как человек с высшим математическим образованием, в курсе этой тонкой разницы), и остановимся для начала на том, в чем ты делаешь ошибку с самого начала. Ты не прав в том, что она базируется на последствиях. Хайп — является не только следствием, но и причиной, это необходимый и важный элемент процесса внедрения инноваций. Допустим, я придумал крутую штуку. Если я о ней не пишу, и она не вызывает бурного обсуждения в публикациях, как ты (а главное — широкая общественность, и инвесторы) о ней узнают? С другой стороны — если я пишу, а хайпа нет — это означает ровно одно. Людям это не интересно, и это не затрагивает никаких значимых потребностей.

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

Выглядит это примерно так:


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

Хотя, учет этой закономерности может сильно помогать в ряде случаев. Например:
http://www.gartner.com/DisplayDocument?id=507779
Подписки на Gartner у тебя разумеется нет, и поэтому посмотреть ты можешь только оглавление.

M>Ты мне хоть один аргумент приведи, кроме крутизны и бездонности знаний тов.Гартнера.
M>Возьми его методику на вооружение и выведи из неё — куда будет идти прогресс, какие идеи так и останутся без надобности, а какие будут востребованы. Скажи когда нужна будет та или иная технология (ведь нужно прийти с ней "вовремя", не так-ли?).
M>Главное — что hype методика может ПРЕДСКАЗАТЬ, а не "объяснить" ПОСТФАКТУМ.

Вот, теперь ты знаешь, что такое "методика hype". Вторая твоя ошибка, на которой ты основываешь свои претензии, состояла в том, что это никакая не "методика", которой надо следовать, и будет тебе счастье, а всего лишь одна из наблюдаемых закономерностей, которую надо учитывать и на нее полагаться. Более подробно разницу между "методикой" и "закономерностью" объяснять не надо?

Здравствуйте, AndrewVK, Вы писали:


AVK>Т.е. гнобить на основании того, что человек якобы религиозный фанатик, можно?
нет конечно, но он являлся гражданином своей страны, и если закон этой страны требует от него платить налоги и не иметь дел со странами на которое оно (государство) наложили свое эмбарго,а Фишер осознанно это сделал, то стоит ли удивляться, что его стали гнобить?

Здравствуйте, prVovik, Вы писали:

V>Можешь привести пример таких задач? Я имею ввиду, чтобы на макросах задача решалась хорошо, а без — сильно хуже. Я уже просил Sinclair'a, он привел в качестве примера динамический доступ к свойствам.

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

V>Зато на обычном коде хорошо работают автоматические средства рефакторинга. В отличии от ручных DSL'eй, о которых тулзы ничего не знают.

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

class Foo {
  Foo(int i) {
    super(i);
  }
}

тебе надо заменить i на некоторый код, который требует временной переменной. А ты эту временную
переменную никуда вписать не сможешь, потому как super() вызов конструктора должен быть _первым_,
никакие декларации переменных и вообще ничего до него быть не может.
Никакой рефакторинг тебе не поможет. И кодо-генерация исходников не поможет — нельзя написать
валидный код. А в языке программирования манипулирующим непосредственно с AST деревом — никаких
проблем.

Здравствуйте, mkizub, Вы писали:

M>Толку тебе приводить пример из собственного опыта, если ты не представляешь всей сложности проблемы, решённой макросом.
M>Любой достаточно сложный проект можно привести в пример. Ты со сложными проектами работал? С какими, приведи пример, и получишь понятный тебе ответ.

CRM, Sales front-office, "Молотилки данных", системы, автоматизирующие всевозможные бизнес-процессы, интеграция чего угодно с чем угодно.

M>Так мета-программирование одним nemerle не исчерпывается.

Под метопрограммированием в данном случае я понимал прежде всего макросы. Согласен, это слишком узко.

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

M>

M>class Foo {
M>  Foo(int i) {
M>    super(i);
M>  }
M>}
M>

M>тебе надо заменить i на некоторый код, который требует временной переменной. А ты эту временную
M>переменную никуда вписать не сможешь, потому как super() вызов конструктора должен быть _первым_,
M>никакие декларации переменных и вообще ничего до него быть не может.
M>Никакой рефакторинг тебе не поможет. И кодо-генерация исходников не поможет — нельзя написать
M>валидный код.

Я уже плохо помню яву, но разве так нельзя:

class Foo {
  Foo(int i) {
    super(Initialize(i));
  }
  int Initialize(int i)
  {
    ...
  }
}
M>

Здравствуйте, prVovik, Вы писали:

V>Здравствуйте, Gaperton, Вы писали:

G>>Не то чтобы я спорил бы. Но мне кажется, Шарп в принципе и не должен развиваться по другому. Сила .NET как раз в том, что он изначально многоязычный by design, что позволяет выполнить "диверсификацию", удовлетворяя разными языками потребности разных групп пользователей. Ориентацией на многоязычность МС сильно развязал себе руки. Хотите более радикальный и инновационный подход — берите F#. C# — ориентирован на более консервативную аудиторию, он позиционируется как самый мэйнстримовый язык MS-а, нет? Однако, удивительное рядом. Я не силен в третьем шарпе, но судя по тем отголоскам и слухам, что до меня доходят — в его развитии Майкрософт зашел несколько дальше, активно заимствуя новые концепции, чем добавление простых клуджей-одноходовок под нужды библиотек.

V>В третьем шарпе все изменения делятся на две группы: те, что вводились для поддержки Linq, и те, что вводились для упрощения автоматической кодогенерации. Пусть меня поправят, если я что-то упустил.

http://en.wikipedia.org/wiki/C_Sharp_(programming_language)#Features_of_C.23_3.0

Features of C# 3.0

C# 3.0 is the current version, and was released on 19 November 2007 as part of .NET Framework 3.5. It includes new features inspired by functional programming languages such as Haskell and ML, and is driven largely by the introduction of the Language Integrated Query (LINQ) pattern to the Common Language Runtime.[10]

Linq
Language Integrated Query:[11] "from, where, select" context-sensitive keywords allowing queries across SQL, XML, collections, and more. These are treated as keywords in the LINQ context, but their addition won't break existing variables named from, where, or select.

Object initializers
Customer c = new Customer(); c.Name = "James";
can be written
Customer c = new Customer { Name="James" };

Collection initializers
MyList list = new MyList(); list.Add(1); list.Add(2); can be written as MyList list = new MyList { 1, 2 }; (assuming that MyList implements System.Collections.IEnumerable and has a public Add method[12])

Anonymous types
var x = new { Name = "James" }

Local variable type inference
Local variable type inference: var x = "hello"; is interchangeable with string x = "hello";. More than just syntactic sugar, this feature is required for the declaration of anonymous typed variables.

Lambda expressions
Lambda expressions: listOfFoo.Where(delegate(Foo x) { return x.Size > 10; }) can be written listOfFoo.Where(x => x.Size > 10);
Compiler-inferred translation of Lambda expressions to either strongly-typed function delegates or strongly-typed expression trees.

Automatic properties
The compiler will automatically generate a private instance variable and the appropriate getter and setter given code such as: public string Name { get; private set; }

Extension methods
Extension methods (adding methods to classes by including the this keyword in the first parameter of a method on another static class)

Partial methods
Allow codegenerators to generate method declarations as extension points that are only included in the source code compilation if someone actually implements it in another portion of a partial class.[13]

Здравствуйте, Sinclair, Вы писали:

VD>>Синклер, тебе ведь где-то 30 лет?! Ты что с СУБД с 10 лет работаешь? Или с СУБД год за два идет?
S>Если быть точным, то с 12.

У каждого в детстве были свои soft toys

Здравствуйте, Gaperton, Вы писали:

G>Ну хорошо, давай поговорим. Опустим то, что ты мне писал об отличиях причин отследствий (я, как человек с высшим математическим образованием, в курсе этой тонкой разницы), и остановимся для начала на том, в чем ты делаешь ошибку с самого начала. Ты не прав в том, что она базируется на последствиях. Хайп — является не только следствием, но и причиной, это необходимый и важный элемент процесса внедрения инноваций. Допустим, я придумал крутую штуку. Если я о ней не пишу, и она не вызывает бурного обсуждения в публикациях, как ты (а главное — широкая общественность, и инвесторы) о ней узнают? С другой стороны — если я пишу, а хайпа нет — это означает ровно одно. Людям это не интересно, и это не затрагивает никаких значимых потребностей.

Так я же сразу сказал — hype это элемент социодинамики вокруг технологии. Конечно, какая-то социодинамика вокруг технологии всегда будет, и её можно померять, тем-же количеством публикаций и пр. Но она вторична, это величина измеряемая, а не причинная. Да, известность технологии, hype, buzzword — определяет количество вкладываемых денег на определённом этапе развития технологии. Но не она определяет — будет технология развиваться или помрёт, и если будет развиваться — то куда и как.
Ты хочешь вложить деньги в новую технологию и получить прибыль. На каком этапе ты это должен делать? Ясно, что не на вершине hype-а. В это время все вкладывают деньги, и через некоторое время теряют их. Банальный эффект толпы — все ломанулись, и попередавили друг друга.
Вкладывать можно когда технология прошла минимум и опять начала развиваться — но там уже ты получишь стандартную норму прибыли, и тебе надо вложить очень много если ты хочешь войти как новый игрок на рынок. И не факт, что ты получишь даже эту стандартную норму прибыли — технология может не пойти вверх достаточно быстро и сильно. Так и помрёт.

Простой пример с dynamic языками (Perl, Python, PHP, Ruby). Мы имели кучу хайпа в недавнее время (по видимости, они как раз прошли первый пик). Что с ними будет дальше? Как высоко они пойдут в подъём после прохождения минимума, и пойдут ли вообще, и если пойдут — то в каком направлении будет развиваться технология (от этого зависит — во что именно вкладывать средства)? Почему они выстрелили именно сейчас, а не раньше или позже — ведь они давно существуют!
Если рассматривать явление dynamic языков с эволюционной точки зрения — то ответы ясно видны. Я уже писал об этом выше. Вкратце — модель их выхода в mainstream аналогична модели вытеснения лесов степью. Как трава на самом первом этапе роста лучше деревьев, так и динамические языки лучше строгих на этапе начала проекта. Они позволяют быстрее и удобней написать работающий код. Вот только они не могут соревноваться со строгими языками при дальнейшем росте размера программы. Слишком неэффективны (в смысле ресурсов — скорости и памяти), слишком тяжело отладить (компилятор не может контролировать ошибки) и пр.
В среде программ-однодневок динамические языки чуствуют себя прекрасно. Вот PHP и Ruby поднялись на волне массового спроса на сайты-однодневки.
Если дальнейшее развитие IT предоставит среду для динамических языков (программы-однодневки) — они будут развиваться и после минимума на кривой hype-а будет опять рост. А если не будет этой среды — не будет подъёма после минимума. Просто не будет.
Если вкладывать в них деньги — очевидно, надо их вкладывать в ту технологию, которая позволит переход от динамики к строгому языку при росте проекта, сохранив простоту на начальном этапе создания программы. Такая технология в конце концов вытеснит старые строгие языки программирования, за счёт того, что начинать проекты будут на ней, и главное — продолжать их будут тоже на ней, а не переписывать всё с нуля.
И это никакого отношения к маркетингу и хайпу не имеет. Независимо от количества вложенных средств и рекламы — развитие будет идти по этим законам, а не по желанию маркетологов.

G>Кривая хайпа всегда примерно одинакова, это закономерность, которая соблюдается в большинстве случаев, и предсказывать ее форму каждый раз не надо. Надо делать две вещи.
G>1) Определять место технологии на кривой в данный момент, что сделать вполне можно.
G>2) Прогнозировать скорость ее движения по кривой.

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

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

Хорошо, в качестве иллюстративной методики у меня к ней претензий нет.
Но почему ты тогда советуешь Владу ориентироваться на эту кривую, которая просто иллюстрирует, а не объясняет (в том числе, и "почему развитие идёт именно так")?

Здравствуйте, Gaperton, Вы писали:

G>Linq
G>Language Integrated Query:[11] "from, where, select" context-sensitive keywords allowing queries across SQL, XML, collections, and more. These are treated as keywords in the LINQ context, but their addition won't break existing variables named from, where, or select.

Ну с этим все ясно. Далее:

G>Object initializers
G>Customer c = new Customer(); c.Name = "James";
G>can be written
G>Customer c = new Customer { Name="James" };

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

G>Collection initializers
G>MyList list = new MyList(); list.Add(1); list.Add(2); can be written as MyList list = new MyList { 1, 2 }; (assuming that MyList implements System.Collections.IEnumerable and has a public Add method[12])

Вопрос, конечно спорный, но без этой фичи не напишешь код, типа: from i in new List<int>(){1, 2, 3, 4} where i % 2 == 0 select i;

G>Anonymous types
G>var x = new { Name = "James" }

Нужны, чтобы из Ling возвращать результат.

G>Local variable type inference
G>Local variable type inference: var x = "hello"; is interchangeable with string x = "hello";. More than just syntactic sugar, this feature is required for the declaration of anonymous typed variables.

Без этой фичи невозможно использовать Linq.

G>Lambda expressions
G>Lambda expressions: listOfFoo.Where(delegate(Foo x) { return x.Size > 10; }) can be written listOfFoo.Where(x => x.Size > 10);
G>Compiler-inferred translation of Lambda expressions to either strongly-typed function delegates or strongly-typed expression trees.

Без этой фичи невозможно использовать Linq.

G>Automatic properties
G>The compiler will automatically generate a private instance variable and the appropriate getter and setter given code such as: public string Name { get; private set; }

Кодогенерация.

G>Extension methods
G>Extension methods (adding methods to classes by including the this keyword in the first parameter of a method on another static class)

Без этого было бы невозможно создавать пользовательские операции в Linq

G>Partial methods
G>Allow codegenerators to generate method declarations as extension points that are only included in the source code compilation if someone actually implements it in another portion of a partial class.[13]

Кодогенерация.

P.S.: ох, чувствую сейчас флейм начнется

Здравствуйте, cadet354, Вы писали:

AVK>>Т.е. гнобить на основании того, что человек якобы религиозный фанатик, можно?
C>нет конечно

Т.е. ты сознательно привел не относящуюся к делу информацию в качестве аргумента.

C>, но он являлся гражданином своей страны, и если закон этой страны требует от него платить налоги и не иметь дел со странами на которое оно (государство) наложили свое эмбарго,а Фишер осознанно это сделал, то стоит ли удивляться, что его стали гнобить?

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

Здравствуйте, Serginio1, Вы писали:

V>>>, и эти "программисты" не знают ни сишарп, ни тем более немерле.

AVK>>Ну и что? Программисты на 1С тоже ничего этого не знают, вот только результатом снижение гибкости, производительности, качества.
S>Ну зачем же так обидно то. Не только знаем, но и используем, правда в основном в связке с 1С, увеличивая ее гибкость, производительность и разумеется качество

Читать надо внимательнее. Все это относится к "эти "программисты" не знают ни сишарп, ни тем более немерле.
".

Здравствуйте, prVovik, Вы писали:

M>>Толку тебе приводить пример из собственного опыта, если ты не представляешь всей сложности проблемы, решённой макросом.
M>>Любой достаточно сложный проект можно привести в пример. Ты со сложными проектами работал? С какими, приведи пример, и получишь понятный тебе ответ.

V>CRM, Sales front-office, "Молотилки данных", системы, автоматизирующие всевозможные бизнес-процессы, интеграция чего угодно с чем угодно.

Хм. Фатальное несовпадение областей работы. Ни с чем из вышеприведённого не работал, конкретно привести пример не могу.

V>Я уже плохо помню яву, но разве так нельзя:
V>

V>class Foo {
V>  Foo(int i) {
V>    super(Initialize(i));
V>  }
V>  int Initialize(int i)
V>  {
V>    ...
V>  }
V>}
M>>

Тут ты меня поймал. Можно, конечно, если Initialize будет static.
Так кодогенераторы и мучаются. Нельзя же заводить отдельный метод на каждую переписываемую операцию (а если заводить — то за лесом деревья не увидишь). Вот они в одно месте делают так, в другом эдак. В результате сложность генератора текста возрастает на порядок. Потом хрен разберёшся, чего они нагенерировали, а не разобравшись — хрен отладишь. Это я по опыту работы с генераторами парсеров говорю.