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

PC_>Здравствуйте, kochetkov.vladimir, Вы писали:

PC_>Замечательно.
PC_>Тоесть чтобы выпрямить код Немерла, пришлось почти полностью откатиться к Шарпу на этом примере ?

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

Кстати, не смутило, что мой код (однострочный) генерирует один случайный пароль по алфавиту и длине, а ваш шарпный — все сочетания с повторениями заданной длины? Вот аналогичный код на немерле:

def p(l, n)
{
        l.Fold([], (e, a) => if (n==1) [e]::a else p(l, n-1).Fold(a, (s, b) => (e::s)::b))
}

Он более чем понятен, по крайней мере для меня...

PC_>Когда я показываю свой код сортировки на руби и на РС, я показываю:
PC_>Вот смотрите, у меня код в 5 раз короче. Поэтому он может быть для когото не понятным без мануала,
PC_>но обьективно он короче.

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

PC_>Тоесть есть смысл разбираться с синтаксисом, чтобы писать короче и лучше.

Безусловно есть. Ключевое слово выделил.

PC_>С Немерлом же этого нет, код длинее и непонятней

Непонятнее для кого?

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

AV>Лучше уж нули, чем индексы.
Чем лучше?
IMHO, лучше всего то, что реализации не надо будет хранить...

AV>Можно и вообще заранее не инициализировать.
Зачем? Это же небезопасно?

E>>Намного прямее научиться описывать переборщики, и потом инициализировать массив сразу нужными значениями из какого-нибудь переборщика...
AV>Вариант. Но не уверен, что это должен быть единственный вариант.
А зачем нужен какой-то другой?

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

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

AV>Спасибо за труды. Но и это тоже читал. А вот вопрос к ТС насчет GC в Питоне так и остался.

Я вот не пойму. Ты хочешь узнать что-то новое про питон или про ТС или про что?

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

AV>>Лучше уж нули, чем индексы.
E>Чем лучше?

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

AV>>Можно и вообще заранее не инициализировать.
E>Зачем? Это же небезопасно?

А зачем инициализировать чем-то, если эти значения потом не будут использоваться?

E>>>Намного прямее научиться описывать переборщики, и потом инициализировать массив сразу нужными значениями из какого-нибудь переборщика...
AV>>Вариант. Но не уверен, что это должен быть единственный вариант.
E>А зачем нужен какой-то другой?

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

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

AV>>Спасибо за труды. Но и это тоже читал. А вот вопрос к ТС насчет GC в Питоне так и остался.

E>Я вот не пойму. Ты хочешь узнать что-то новое про питон или про ТС или про что?

Думаю от ТС что-то новое я вряд ли узнаю. Просто мне интересно на чем базируются утверждения ТС.

AV>>>Спасибо за труды. Но и это тоже читал. А вот вопрос к ТС насчет GC в Питоне так и остался.

E>>Я вот не пойму. Ты хочешь узнать что-то новое про питон или про ТС или про что?

AV>Думаю от ТС что-то новое я вряд ли узнаю. Просто мне интересно на чем базируются утверждения ТС.

Не TC, а PC_2

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

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

PC_>>Предложи нормальную синт. конструкцию. Добавлю

E>Я так думаю, что если сделать эффективную, или хотя бы приемлемую реализацию переборщиков, то можно переделать так, что 1..10 будет переборщиком от 1 до 10. А ещё какая-то конструкция, например, 0**10 даст переборщик из 10 нулей. Если же ещё и какие-то операции над переборщиками научиться записывать, то можно будет описывать довольно хитрый переборщик, а потом только инициализировать им массив.
Уже умеют это записывать. Что осталось сделать — сэкономить на буковках:
F#

[|for i in 1..10 -> i*i|]

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

[|for i in 1..10 -> i*i|]    (** массив квадратов **)
[for i in 1..10 -> i*i]      (** список квадратов **)
seq{for i in 1..10 -> i*i}   (** последовательность квадратов **)
[for i in 1..10 -> [1..i*i]] (** генератор генераторов **)

Примечательно то, что при едином синтаксисе и механизме генераторов в итоге получается тот контейнер, который указан в обрамлении генератора. [] — список, [||] — массив, seq{} — последовательность. Причем можно создавать свои типы контейнеров my_container_type{}. И не только контейнеров, а вообще связанные вычисления.

Концепции генераторов больше 30 лет. Их умеют готовить в OCaml, F#, Nemerle, Common Lisp, Erlang, Haskell, Javascript, Python, Scala, Scheme, Visual Prolog, в многих других языках, и даже C# не исключение, правда там немного через зад.

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

AV>>>>Спасибо за труды. Но и это тоже читал. А вот вопрос к ТС насчет GC в Питоне так и остался.

E>>>Я вот не пойму. Ты хочешь узнать что-то новое про питон или про ТС или про что?

AV>>Думаю от ТС что-то новое я вряд ли узнаю. Просто мне интересно на чем базируются утверждения ТС.

M>Не TC, а PC_2

Сорри, я думал, что он и есть ТС. Приношу извинения реальному ТС.

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

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

AV>>>Думаю от ТС что-то новое я вряд ли узнаю. Просто мне интересно на чем базируются утверждения ТС.

M>>Не TC, а PC_2

AV>Сорри, я думал, что он и есть ТС. Приношу извинения реальному ТС.
он и есть ТС

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

E>>Зачем? Это же небезопасно?
AV>А зачем инициализировать чем-то, если эти значения потом не будут использоваться?
Ну, как вариант, можно поддержать специальное состояние "нет значения", но не факт, что это надо.
Просто неинициализированная переменная -- это однозначно плохо.

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

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

S>Концепции генераторов больше 30 лет. Их умеют готовить в OCaml, F#, Nemerle, Common Lisp, Erlang, Haskell, Javascript, Python, Scala, Scheme, Visual Prolog, в многих других языках, и даже C# не исключение, правда там немного через зад.

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

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

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

S>>Концепции генераторов больше 30 лет. Их умеют готовить в OCaml, F#, Nemerle, Common Lisp, Erlang, Haskell, Javascript, Python, Scala, Scheme, Visual Prolog, в многих других языках, и даже C# не исключение, правда там немного через зад.

E>Это, всего лишь, способ инициализировать коллекцию. А хочется другого. Например, чтобы можно было передать генератор в функцию, там что-то с ним сделать, потом вернуть копию, а потом только, например, породить коллекцию...
Какие проблемы?
Linq только этим и занимается, что передает генераторы в функции, и по-разному их комбинирует.

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

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

Я, конечно, извиняюсь... Но одно дело реинвентнуть вещи, 30 лет назад изобретенные и успешно забытые. Но вы изобретаете то, что уже в мэйнстриме не первый год.
Да, много буков в c# это занимает. Но это именно то, о чем ты говоришь — передача переборщика в функцию, возвращение комбинированного переборщика и потом порождение коллекции.

Enumerable.Range(1, 10).Select(i=>i*i).ToArray(); // ToList(), ToDictionary()...

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

PC_>после Евал Немерлисты меня больше не тревожат лямдами, да и вообще не тревожат

А до евал немерлисты вас тревожили? Хотите об этом поговорить?

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

Вы палитесь на каждом шагу, демонстрируя крайне поверхностную теоретическую подготовку в вопросах конструирования языков программирования и отсутствие сколь-нибудь значимого опыта в этой области: вы берете из исходника на немерле понятие "мутабл" и, не разобравшись, что он означает начинаете употреблять его совершенно не к месту; вы демонстрируете отсутствие каких-либо знаний на тему сборки мусора в CLR и питоне (вообще ); вы следуете довольно широко распространенному заблуждению о примитивности javascript, что говорит о том, что вы никогда на нем не писали ничего серьезного; вы смеетесь над понятием "дизайн" языка, но если бы у вас был опыт в области языкостроения, то вы бы знали, что это — устоявшийся термин; вы по-тихому опускаете в своих цитатах любые неудобные для вас аргументы, на которые вы не в состоянии что-либо ответить и упорно игнорируете просьбы дать на них ответ и т.п. и т.д.

Это нормально и понятно, никто не может объять необъятное. Но даже если списать вашу хамскую манеру общения на особенности вашего психотипа, то тут вырисовывается еще один любопытный момент. Даже из этой темы (а уж тем более из темы на SQL.ru) отчетливо следует, что вы не особо представляете себе, что именно вы разрабатываете, как и с какой целью. Вас даже за последний день бросало из сторону в сторону относительно тех решений, которые вы вообще-то должны были принять еще до начала работы на языком. И это тоже понятно, если бы не одно "но": при этом, вы безапелляционно заявляете о превосходстве вашего языка над любыми существующими и о своем превосходстве над любыми участниками этого обсуждения, вздумавшими вам перечить. Но при этом, четкого представления о том, что должен из себя представлять "язык будущего" у вас как бы и нет. И, в свете этого, причины вашей самоуверенности вкупе с хамской манерой общения и нежеланием вести конструктивный разговор, предстают в совершенно ином свете.

Я исчерпывающе ответил на ваш вопрос о причинах того, почему здесь нет немерлистов?

Я же нахожусь в этой теме с одной лишь целью: у меня есть основания считать, что рано или поздно атмосфера общения в ней достигнет примерно того же культурного уровня, что и тема на SQL.ru. Как только это случится, судьба этой темы повторит судьбу той, а судьба виновного в этом участника (участников) здесь, повторит вашу судьбу там.

Надеюсь, я выразился предельно ясно.

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

E>>>Зачем? Это же небезопасно?
AV>>А зачем инициализировать чем-то, если эти значения потом не будут использоваться?
E>Ну, как вариант, можно поддержать специальное состояние "нет значения", но не факт, что это надо.

И это гораздо лучше чем инициализировать индексами.

E>Просто неинициализированная переменная -- это однозначно плохо.

Не все так однозначно. Идея "плачу только за то, что запросил" далеко не всегда плоха.

AV>>А затем, что в момент создания массива не всегда может быть доступен твой переборщик.
E>А зачем тогда создавать массив?

Массив может заполняться в нескольких местах. Это первое что приходит в голову

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

AV>>>>Думаю от ТС что-то новое я вряд ли узнаю. Просто мне интересно на чем базируются утверждения ТС.

M>>>Не TC, а PC_2

AV>>Сорри, я думал, что он и есть ТС. Приношу извинения реальному ТС.
S>он и есть ТС

Мужики, вы меня в конец запутали. То, вроде, ТС и PC_2 два разных человека, то один. Как бы не вышло как со Славой КПСС.

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

S>Да, много буков в c# это занимает. Но это именно то, о чем ты говоришь — передача переборщика в функцию, возвращение комбинированного переборщика и потом порождение коллекции.
S>

S>Enumerable.Range(1, 10).Select(i=>i*i).ToArray(); // ToList(), ToDictionary()...
S>

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

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

AV>Не все так однозначно. Идея "плачу только за то, что запросил" далеко не всегда плоха.
Это хорошая идея для С... А PC-2 всё время хочет уйти от императивной стороны вопроса...

E>>А зачем тогда создавать массив?
AV>Массив может заполняться в нескольких местах. Это первое что приходит в голову

Можно создавать переборщики, и только потом дампить их в массив, если надо...

Массив -- это просто функция, отображающая начало натурального ряда на свои элементы. Ты же не создаёшь обычные функции "про запас"? Зачем так создавать массивы?

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

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

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

def p(l, n)
{
        l.Fold([], (e, a) => if (n==1) [e]::a else p(l, n-1).Fold(a, (s, b) => (e::s)::b))
}

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

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

!x='a'..'z'
!m=0..5
y+='+x'+m
^y

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

Так что гаспадин Кочетков, вместо переноса тем в треши "О жизни" и
веселого прятанья головы в песок, как в песне "А нам всеравно" лучше бы
занялись делом, да может подстругали Немерлу.

Конкуренцыя итит ийо налево

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

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

S>>Да, много буков в c# это занимает. Но это именно то, о чем ты говоришь — передача переборщика в функцию, возвращение комбинированного переборщика и потом порождение коллекции.
S>>

S>>Enumerable.Range(1, 10).Select(i=>i*i).ToArray(); // ToList(), ToDictionary()...
S>>

E>Ну там всё-таки это больше на базы данных ориентированно. Хотя похоже, конечно.
Базы данных — это лишь частный случай подхода. С той лишь разницей, что комбинируются не генераторы, а части SQL AST.
E>Но букв много. И это правда.
Это не такая большая проблема. В других языках оно компактнее, но к первенству по размерам в байтах никто из разработчиков не стремится.