Наткнулся на интересное поведение в D2010

← →
Kerk © (2011-01-05 16:03) [80]

Удалено модератором

← →
Kerk © (2011-01-05 16:05) [81]

> Дмитрий Тимохов (05.01.11 15:57) [79]
>
> Я ушел от for in в сторону обычного for.
> Не вижу большого смысла в них.

Синтаксический сахар, не более.

← →
DiamondShark © (2011-01-05 17:50) [82]

> Дмитрий Тимохов (05.01.11 15:57) [79]
> Я ушел от for in в сторону обычного for. Не вижу большого
> смысла в них.

LINQ, например.
Результат запроса -- инумератор анонимного типа, у которого ни индексера ни свойства Count.

Вообще-то, коллекция последовательного доступа -- такая же фундаментальная структура, как и индесная коллекция.

← →
Kerk © (2011-01-05 18:11) [83]

> DiamondShark © (05.01.11 17:50) [82]
>
> > Дмитрий Тимохов (05.01.11 15:57) [79]
> > Я ушел от for in в сторону обычного for. Не вижу большого
> > смысла в них.
>
> LINQ, например.
> Результат запроса -- инумератор анонимного типа, у которого
> ни индексера ни свойства Count.

В Delphi ничего подобного нет. Если я не прозевал, конечно.

← →
DiamondShark © (2011-01-05 18:15) [84]

> В Delphi ничего подобного нет.

Да? Даже в дотнетовской инкарнации?
Пичаль...

← →
Игорь Шевченко © (2011-01-05 18:19) [85]

> В Delphi ничего подобного нет. Если я не прозевал, конечно.

for..in - это как раз оно и есть: "инумератор анонимного типа, у которого ни индексера ни свойства Count"

http://17slon.com/blogs/gabr/2007/03/fun-with-enumerators.html

← →
Kerk © (2011-01-05 18:22) [86]

Не, я про LINQ

← →
DiamondShark © (2011-01-05 18:23) [87]

> Kerk © (05.01.11 18:11) [83]
> DiamondShark © (05.01.11 18:15) [84]

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

LINQ просто как пример.

← →
Alkid © (2011-01-05 19:07) [88]

Сказать по правде, идея enumerator`ов в том виде, как она реализована в .net мне не нравится. В первую очередь тем, что сам enumerator там изменяемый. Зря они в Дельфи сделали так же.

← →
DiamondShark © (2011-01-05 19:32) [89]

> сам enumerator там изменяемый

Какэто?

← →
Alkid © (2011-01-05 20:08) [90]

> DiamondShark © (05.01.11 19:32) [89]
> > сам enumerator там изменяемый
> Какэто?

Он является stateful объектом. MoveNext изменяет его состояние.

← →
DiamondShark © (2011-01-05 20:36) [91]

> Alkid © (05.01.11 20:08) [90]

Очень интересно было бы взлянуть на инумератор без состояния.

← →
Alkid © (2011-01-05 20:54) [92]

> DiamondShark © (05.01.11 20:36) [91]
> Очень интересно было бы взлянуть на инумератор без состояния.

Ленивый односвязный список.

← →
vuk © (2011-01-05 21:10) [93]

Кстати, вспомнил тут, что у того же Буча рассматриваются активные и пассивные итераторы. То, что обычно подразумевается под итератором(инумератором) - это активный итератор. Пассивный - это вообще не объект, а метод, которому передается ссылка на функцию, которую он применяет к каждому элементу набора.
Вот, помнится, еще у коллекций в TurboVision бали методы-итераторы - ForEach, FirstThat, LastThat. Как раз пассивные итераторы.

← →
Дмитрий Тимохов (2011-01-05 22:10) [94]

я все равно стою на том, что чем меньше примитивов, тем лучше )))

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

вообще, сила любого языка, я думаю, не в языке как таковом, а в библиотеках.

← →
vuk © (2011-01-05 22:16) [95]

to Дмитрий Тимохов (05.01.11 22:10) [94]:

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

Вот скажи мне, ты лично дофига прикладных задач решил на классическом паскале? Я вот - ни одной.

← →
Alkid © (2011-01-05 22:20) [96]

> Дмитрий Тимохов (05.01.11 22:10) [94]
> вообще, сила любого языка, я думаю, не в языке как таковом,
> а в библиотеках.

Не соглашусь. Сам язык очень важен. Иначе бы мы до сих пор писали на Фортране :)

← →
Юрий Зотов © (2011-01-05 22:20) [97]

_Юрий (05.01.11 12:32) [75]
> Слепое следование традициям только потому, что это традиции - одна из
> наиболее тупых вещей, свойственных человеку.

Смысла в этой фразе ровно столько же, сколько и вот в этой: "Слепое следование новшествам только потому, что это новшества - одна из наиболее тупых вещей, свойственных человеку".

Развивать мысль я не буду - она или понятна, или объяснение бесполезно.
© _Юрий

← →
Юрий Зотов © (2011-01-05 22:28) [98]

> vuk © (05.01.11 22:16) [95]
> Вот скажи мне, ты лично дофига прикладных задач решил на
> классическом паскале? Я вот - ни одной.

Я - наверное, парочку, вряд ли больше (на TP, конечно, до фига, но это уже не классический, так что не считается). Но это же не значит, что классический Паскаль недостаточен?

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

← →
Игорь Шевченко © (2011-01-05 22:37) [99]

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

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

← →
Дмитрий Тимохов (2011-01-05 22:38) [100]

>
> Вот скажи мне, ты лично дофига прикладных задач решил на
> классическом паскале? Я вот - ни одной.

Леш, ты же знаешь - я не использую DFM и все с этим связанное.
Т.е. в этом смысле RAD как таковой я не пользуюсь.

Классы, конечно, использую, куда без них. Но все это и на паскале можно делать. Эвона, в WinAPI нет классов, а жить можно.

Я утрирую, конечно, но либы штука важная.

> Alkid © (05.01.11 22:20) [96]

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

Юра Зотов когда-то приводил пример про сложность либы по каким тот там ынтыгралам в частичных проиходных (деталей не помню). что-то типа, что такую либу писать человекогода.

← →
Юрий Зотов © (2011-01-05 22:41) [101]

> Игорь Шевченко © (05.01.11 22:37) [99]

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

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

← →
vuk © (2011-01-05 22:42) [102]

to Юрий Зотов © (05.01.11 22:28) [98]:

> Но это же не значит, что классический Паскаль недостаточен?

Достаточен. Вопрос только в том, для чего достаточен.

В какой-то мере и брэйнфак, например, достаточен. Но это же не повод? :)

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

Вот, например, в классическом паскале не было модульности. И как её туда добавить без усложнения языка? И да, это уже не классический паскаль.

← →
vuk © (2011-01-05 22:50) [103]

to Дмитрий Тимохов (05.01.11 22:38) [100]:

> Леш, ты же знаешь - я не использую DFM и все с этим связанное.

Ну а я использую. Но тут уж каждый сам себе буратино. :)

> Классы, конечно, использую, куда без них. Но все это и на
> паскале можно делать. Эвона, в WinAPI нет классов, а жить
> можно.

На классическом паскале - низзя. Кстати. Ты много пробовал писать оконные приложения на чистом WinAPI? У меня, вот, в какой-то момент (где-то еще на уровне BP for Windows) желание такое пропало начисто. Даже OWL, которая была совсем не RAD-библиотекой дело упрощала на порядок.

← →
Alkid © (2011-01-05 23:07) [104]

> Дмитрий Тимохов (05.01.11 22:38) [100]
> на нем и пишут до сих пор очень-очень много.
> просто фортран использовался для расчетов.
> как раз он там либы - штука архи важная.
>
> Юра Зотов когда-то приводил пример про сложность либы по
> каким тот там ынтыгралам в частичных проиходных (деталей
> не помню). что-то типа, что такую либу писать человекогода.

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

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

← →
Дмитрий Тимохов (2011-01-05 23:57) [105]

>
> Тем не менее, мы пишем не на Фортране и это уже доказывает,
> что не все решается библиотеками. Сам язык и те абстракции,
> которые он дает, важны.

наука пишет на фортране )))

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

---

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

обобщение таково - человеческий мозк - это капитошка, в которую подливают воду образование, жизненный опыт, а выливают - старение, вредные привычки, и т.д.

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

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

как-то так ))

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

если не ошибаюсь, Игорь Шевченко про овощ в нужном месте в нужное время говорит. возможно я тоже научусь применять правильные овощи в правильное время.

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

было время, я увлекался функциональным программированием. именно в Хаскелле я понял, что такое быстрая сортировка ))) и насколько это просто.

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

← →
Kerk © (2011-01-06 00:07) [106]

> Игорь Шевченко © (05.01.11 22:37) [99]
>
> а вот люди провели исследование и выяснили, что на определенное
> количество строк кода в среднем приходится определенное
> количество ошибок. Вне зависимости от языка. Отсюда вывод
> - чем меньшим количеством строк кода может быть решена конкретная
> задача, тем меньше ошибок будет при ее решении.

Молодцы люди. Я тоже всем говорю, что на перле нужно только так и писать: "(1 x $_) !~ /^(11+)\1+$/ && print while ++ $_", ошибок меньше будет.

← →
Kerk © (2011-01-06 00:10) [107]

Удалено модератором

← →
vuk © (2011-01-06 00:19) [108]

to Дмитрий Тимохов (05.01.11 23:57) [105]:

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

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

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

"потому что во многой мудрости много печали; и кто умножает познания, умножает скорбь" (Еккл. 1, 18)

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

← →
имя (2011-01-06 01:03) [110]

Удалено модератором

> Дмитрий Тимохов (05.01.11 23:57) [105]
>
> и вот, если ты будешь тратить часть своего мозка (памяти)
> на то, чтобы помнить неочевидные моменты твоего языка программирования,
> то у тебя останется меньше жидкости на другие стороны твоей
> профессиональной деятельности.

"Неочевидные моменты языка программирования" - это, скорее, про С++ и про такие кунштюки в Дельфи, как этот с областями видимости. Это называется "accidental complexity". В этом смысле C#проще Дельфи, поскольку там правила областей видимости более регулярны.

Кстати, вопрос с достаточностью языка - это тоже вопрос не очень очевидный. В смысле тьюринг-полноты достаточен и ассемблер :) Тот продукт, который мы недавно выпустили на C#, раньше писался на С++. То есть С++ был *достаточен*, но C# оказался лучше.

← →
_Юрий (2011-01-06 11:30) [112]

> Юрий Зотов © (05.01.11 22:20) [97]
>
>

Абсолютно верно.
Ключевое слово - "слепое".
Но таких вот "безголовых новаторов" не особо много, я лично ни одного не знаю, а "безголовых консерваторов" дофига

> _Юрий (06.01.11 11:30) [112]
> Но таких вот "безголовых новаторов" не особо много, я лично
> ни одного не знаю, а "безголовых консерваторов" дофига

Исходя из закона больших чисел, их количество примерно одинаково. И если Вам встречаются только одни "консерваторы", то это означает, что либо Вам просто не везет (что менее вероятно), либо Вы даете людям ошибочные оценки (что более вероятно).

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

А если это так, то кто же тогда "безголовый новатор"?
:o)

> _Юрий (06.01.11 11:30) [112]
> Но таких вот "безголовых новаторов" не особо много, я лично
> ни одного не знаю, а "безголовых консерваторов" дофига

Мой опыт говорит ровно об обратном ;)

> Alkid © (06.01.11 13:10) [114]

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

Назвать эту взвешенную осторожность "безголовостью" небезголовому человеку довольно сложно. Обычно ее называют опытом, а иногда даже и мудростью.
:o)

> Юрий Зотов © (06.01.11 13:34) [115]
> Поскольку консерваторами становятся не просто так, а после
> набития немалого числа шишек (которые новаторы еще набить
> не успели, иначе они стали бы консерваторами) - что приводит
> к взвешенной осторожности в решениях.

Это тоже не всегда так. Бывают и люди, которые в принципе боятся нововведений и предпочитают старые, проверенные способы даже тогда, когда они уже не адекватны ситуации.

Простых ответов нет. Надо быть мудрее и искать гармонию :)

> Alkid © (06.01.11 13:45) [116]
> Простых ответов нет. Надо быть мудрее и искать гармонию :)

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

Удалено модератором
Примечание: Не на базаре

> DiamondShark © (06.01.11 14:47) [118]

Ты хоть сам понял, чего выдал? Цитирую:

> то вторым прямая дорога в биореактор.

Это я так понял ты про "старых перечниц", верно? Хорошо. Далее:

> так и будет горлодранской шантропой (пока не повзрослеет,
> конечно)

Т.е., надо понимать, что как повзрослеет, туды же, в биореактор? Ибо, тоже превратится в "старых перечниц"? Так?

Получается или ты "горлодранская шантропа" или в биореактор?
Т.е. "горлодранская шантропа" - наше все?

> Получается или ты "горлодранская шантропа" или в биореактор?

Ну вот смотри: ты утром просыпаешься, а вечером засыпаешь.
Получается или ты просыпаешься, или ты засыпаешь.
Т.е. ты всё время спишь.

Наткнулся на интересное поведение в D2010 Найти похожие ветки