Здравствуйте, Timur I., Вы писали:
TI>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
Если ты уже делишь языки на "основные" и "альтернативные" — это уже ошибочная постановка вопроса. Посему предложу тебе другую методику. В начале, пожалуй, математика в объёме первых 3-х курсов любого вуза. Это — минимум. Дальше в некотором роде смесь: системное программирование, формальные языки и построение компиляторов, дискретная математика, основы электроники, вопросы связанные с искусственным интеллектом. Присоединюсь к тем, кто советовал SICP и добавлю сюда ещё дядьку Кнута. Потом — применение тех или иных языков для определённых задач. Ну и в процессе уже определишься, что к чему и почему, и откуда и куда у чего ноги растут.
А так... Ну скажут тебе, что, к примеру, Lisp полезно знать. А почему? Его же относительно редко применяют. Потому что Пол Грэхем о нём балладу спел? Так баллады много о чём пели! Что ж теперь?
Так что, копай, а там вопросы подобные онтопику сами собой отпадут.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Константин Л., Вы писали:
КЛ>>PS: тот, кто часто использует кортежи в качестве возвращаемых значений явно что-то не то делает. Или у него слишком специфичная задача. Отсутствие кортежей — не смертельно.
FR>Конечно не смертельно. Но такая вроде с виду фигня реально сокращает объем кода. Но дело даже не в сокращении объема, а в удобстве, уже привыкаешь что не нужно заводить бестолковые временные структуры, не нужно задумыватся о том как вернуть результат.
поинт в том, что если ты возвращаешь "бестолковые временные структуры", то значит у тебя метод делает "все сразу и еще кучу вещей", что часто говорит о его избыточности или неправильности. Если же так нужно и это осмысленная операция, то эти "бестолковые временные структуры" должны стать нормальными логическими сущностями и уж тут кортежи нафиг не нужны. Кароче моё мнение, что кортежи — это затычки для костылей, которые мы сами и сажаем.
Здравствуйте, Timur I., Вы писали:
TI>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
Здравствуйте, Timur I., Вы писали:
TI>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
Мой список языков котрый может расширить кругозор:
1. C# — классика ООП, компонентность, статическая типизация, обобщенное программирование.
2. Руби — классика скриптов, динамика, гибкость.
3. Хаскель — функциональный подход, вывод типов, красивая идея классов типов (похожая на интерфейсы в C#, но которые можно подключать к уже имеющися типам), ленивое исполнение.
4. XQuary/XSLT — как пример языков трансформации данных.
5. Схема — как пример языка без синтаксиса и мощи макросов.
6. Рад, что даждались ожидаемого. Правильно немерле как квинтесенция свсего перечисленного выше.
7. Пролог, как демонстрация красивой идеии логического программирования практичски бесполеной на прктие.
8. SQL — пример декларативного языка обраобтки данных.
9. Регулярные выражения и Перл, как пример того что и на системах фирования можно писать программы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
КЛ>PS: тот, кто часто использует кортежи в качестве возвращаемых значений явно что-то не то делает. Или у него слишком специфичная задача. Отсутствие кортежей — не смертельно.
Конечно не смертельно. Но такая вроде с виду фигня реально сокращает объем кода. Но дело даже не в сокращении объема, а в удобстве, уже привыкаешь что не нужно заводить бестолковые временные структуры, не нужно задумыватся о том как вернуть результат.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, Timur I., Вы писали:
TI>>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
ЗХ>Однозначно последнее.
Присоединяюсь. Ибо если такой вопрос к публике (а не к себе самому) возникает в принципе то не надо.
Вообще языки *изучать* не надо. Желание на посмотреть чего-то придет само (если придет).
VD>>>А чем по-твоему иявляются параметры функций?
E>>Ага, фрейм стека в C/C++ в перемешку со значениями регистров уже стал кортежем.
BZ>а причём тут процессор? речь идёт о языке. и тут Влад прав — с теоретичсекой точки зрения это кортёж и есть, пока ты не используешь переменнное число аргументов
Какая-то оторванная от практики теория, укуренная, я бы сказал.
Нет в C++ штатных средств получения аргументов метода в виде одного объекта (т.е. никакого экземпляра кортежа получить нельзя). Да, если компилятор не засовывает аргументы в регистры, то хаками на ассемблере можно получить копию стекового фрейма, но к языку это не имеет отношения.
В Ruby можно аргументы метода получать в виде одного объекта штатными средствами языка, там хоть как-то можно кортежи за уши притягивать. А вот в C/C++ -- только, если трава забористая попалась.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Да, уместно. Но о нем еще надо знать. А rsn81 явно не из тех кто обсуждает то, что знает.
Еще можно было бы упоминуть дизайн делегатов и пару других вещей.
Все это достадные ошибки дизайна. Но их все же не много. И их наличие никак не умоляет того факта, что ошибки дизайна Явы были проанализированы и в оснвном устранены.
D>Лично я не разделяю крайне пуристские взгляды на ref-out параметры. И считаю, что они в некоторых случаях бывают весьма полезны. Тем более, что в C#'е они реализованы, на мой взгляд, лучше, чем в C++ (например, есть разделение на ref и out (а не просто ссылка); и необходимость явно помечать ref out аргументы при вызове).
В С++ их вообще нет. За то есть указатели позволяющие эмулировать их, но эта эмуляция черевата ошибками, и опасными. Плюс явное указание этих модификаторов четко описывает намерение, а значит делает код более понятным и предсказуемым.
Но самое, что смешное, лично я соглассен, что без них можно было бы обойтись. Только не так убого как в Яве, где они просто отсуствуют, что приводит к эмуляции их совершенно уродливыми методами, а как это сделано в большинстве ФЯ — введением кортежех.
Программируя на том же Nemerle у меня даже не возникает потребности в out/ref-параметрах. Намного красивее просто возрварить кортеж с нужными данными.
D>Однако, если говорить о Java, то ref-out в ней до сих пор не реализовано не только по "историческим причинам" и еще и потому, что ref-out параметры могут "добавить" граблей в программу.
Это явное преувеличение. Скорее из-за нежелания усложнять рантайм. Вот там действительно создаются проблемы. Но опять же запрет при явной потребности фичи — это плохое решение.
D>Например, ... если попытаться ею обменять значения полей некоторого объекта (в одном потоке), то другой поток может "увидеть" частично измененный объект .... D>Т.е. для того, чтобы пользоваться таким Swap'ом необходимо понимать, что происходит внутри (т.е. невозможно воспринимать Swap как черный ящик) и предпринимать некотороые действия для того, чтобы избежать негативных последствий. Скажем, поместить вызовы Swap в lock блок.
Языки типа Явы и C# ВООБЩЕ не рассчитаны на работу в многопоточном окружении. В них проблема гонок и неатомарности функций может возникнуть где угодно и когда угодно.
И ref/out-параметры тут вообще не причем. Любой метод изменяющий более одного поля может привести к проблемам в многопоточном окружении.
Замени ref-параметр на параметр меняющий значение в ячейке массива и ты получишь полную аналогию. Собственно так в Ява и поступают. Так что можно сказать, что в Ява ref параметры реализуются паттернами.
D> Кроме того, функции с ref параметрами могут возбуждать исключения, а это добавляет сложностей, поскольку в случае возникновения исключения в общем случае может потребоваться привести ref параметры в некое "разумное" значение.
Это так же заблуждение. Ведь исключение на то и исключение, чтобы считать все вычисления неудачными. После исключения рассчитывать на корректность данных вообще нельзя. Задача обработчиков исключений как раз и заключается в приведении данных в корректное состояние.
На самом деле ref/out-параметры довольно естественны для императивных языков. Они ничего в них не нарушают. И ни к каким проблемам не приводят.
Но у них есть одна проблема — они неудобны. Или скажем, так в большинстве случаев вместо них удобнее использовать озврат множетсва значений (котреж, напимер). Такой подход решает и проблему многопточности (при условии что весь многопоточный код написан в фукнциональном стиле) решает, и просто удобен.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>>Нет в C++ штатных средств получения аргументов метода в виде одного объекта (т.е. никакого экземпляра кортежа получить нельзя). Да, если компилятор не засовывает аргументы в регистры, то хаками на ассемблере можно получить копию стекового фрейма, но к языку это не имеет отношения.
E>У меня вопрос к господам, поставившим минусы на мое сообщение. Как известно, практика -- критерий проверки теории. Итак, хотелось бы увидеть практический пример интерпритации параметров функции в C++ в качестве объекта-кортежа (будь то передача параметров при вызове или получения всех параметров внутри функции в качестве объекта-кортежа). Стандартными средствами языка.
Минус не поставил, но могу Потому как не согласный я тоже.
Ты говорил о синтаксисе и деталях реализации. А сентенция "параметры функции суть кортеж" — говорит о _семантике_.
То есть, вот эту запись:
foo(1, "a", &c)
Вполне можно, с определенной точки зрения, рассматривать как "функцию foo, которая принимает на вход кортеж параметров и статически контролирует количество и тип элементов кортежа". Да, с точки зрения языка с полноценным кортежами — это весьма ограниченные возможности, но ведь и, к примеру, "функторы" в плюсах тоже странноватые, а ничего, пользуемся.
Ну и, возвращаясь к тому, с чего была поднята эта тема, метафора кортежа была употреблена вполне корректно, в диалоге "зачем возвращать из функции кортеж (список разнотипных значений)? — затем же, зачем мы передаем в функцию кортеж (список разнотипных значений)?"
Здравствуйте, Alexander_S_U, Вы писали:
A_S>Какие языки из "альтернативных" для общего развития посоветуете?
SQL, правда это не альтернатива
Схему/Лисп, Хаскелл, пролог(для общего развитя кругозора), эрланг(сам не видел, но так сильно и упорно советуют что не могу не включить в список), ну и асм какой нить. Для того что бы убедиться что программировать можно "с улыбкой в душе и на устах": питон — очень улыбчивый язычок с батарейками в комплекте.
И САМОЕ ГЛАВНОЕ, В ОБЯЗАТЕЛЬНОМ ПОРЯДКЕ — !!! nemerle !!!
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>То есть, вот эту запись: ЗХ>
ЗХ>foo(1, "a", &c)
ЗХ>
ЗХ>Вполне можно, с определенной точки зрения, рассматривать как "функцию foo, которая принимает на вход кортеж параметров и статически контролирует количество и тип элементов кортежа".
С другой точки зрения это же можно рассматривать как "функцию foo, которая принимает на вход целое и возвращает функцию foo(1), которая принимает на вход строку и возвращает функцию foo(1, "a"), которая принимает на вход указатель...". Да, с точки зрения языка с полноценным ФВП — это весьма ограниченные возможности, но ведь и, к примеру, "функторы" в плюсах тоже странноватые, а ничего, пользуемся.
Здравствуйте, Дм.Григорьев, Вы писали:
AVK>>Обжегшись на молоке (DTD) стали дуть на воду (XSD, XSLT)
ДГ>Эммм... Можно вот здесь поподробнее, для чайников?
Можно. В составе стандарта SGML (помним, что именно от него произрости и HTML и XML) была часть для описания ряда синтаксических правил документа, выходящих за рамки стандартных ограничений. Т.е. набор допустимых тегов, атрибутов, их взаимоотношения и т.п. Описывалось это все специальным языком Document Type Definition. Засада была в том, что для этого языка нужен был свой отдельный парсер. В результате далеко не все реализации XML этот самый DTD контроллировали. Поэтому, во-первых начали делать DTD, но с синтаксисом XML, т.е. XML Schema, а во-вторых при разработке XSLT побоялись повторения аналогичной ситуации и отбросили варианты с не-XML синтаксисом (а они были).
1. Разговор в стиле меряний длины органов у нас явно не получится: возможно, вам такой вариант нравится, но мне нет. Мы или говорим четко по теме, или вы скатываетесь в обсуждение своего величия и ущербности ваших собеседников? Второй вариант клоунады неинтересен.
2. Про знание языков все же отвечу. Да, опыта на Java больше: около 3 лет, на .NET же разработки веду уже второй год, при этом продолжаю "свободные" проекты писать на Java. Разумеется, и это не все ЯП, с которыми приходилось иметь дело. Про уровень своего профессионализма говорить считаю неуместным и смешным делом (хватит и того, что вы написали), тем, чем настоящий профессионал, как мне кажется, никогда заниматься не станет.
3. Подробно комментировать глупые нападки не имею желания. Одно только, статью, ссылку на которую дал dshe (As vs Cast), читал, и достаточно давно, честно говоря, воспринял ее тогда с долей юмора: история о том, как вначале C# предоставляет свободу действий, расчитывая на то, что имеет дело с профессионалом, а потом... когда приходит понимание, что программисты — тоже люди, которым свойствено ошибаться, пишутся разгромные научные труды, как же побороть ошибки от необдуманного своеволия в C#.
4. Если правильно расставить акценты, то разговор начался с того, что C# был объявлен классикой ООП, а Java послали в лес. У меня вовсе не было желания все сделать наоборот: C# послать в лес, а Java восхвалить — эти священные войны все же детство, а работать все равно приходится с обоими платформами. Речь же "зачиналась" о конкретных недостатках каждого из языков — вот это было бы интересно обсудить.
VD>Мой не трогай.
Забавно.
Здравствуйте, lomeo, Вы писали:
L>Ты же не добавлял, когда говорил, что С# классический ОО,
Для особо невнимательных цитирую себя любимого: [b]Мой список языков котрый может расширить кругозор:[/b]
L> а я всего лишь говорю об идее "всё есть объект, объекты общаются сообщениями". В смолтолке эта идея выражена чище. Ой, прости, это моё мнение.
Еще раз. Создай отдельно свой список и хоть Перл туда запиши. Мой списко трогать не надо.
На мой взгляд за чистоту Смолтака по рукам надо бить. Если возникнет вопрос "почему", то воспользуйся поиском.
VD>>Я считаю Смолток языком с прототипной орканизации.
L>Твоё изобретательство в области новых определений старых терминов не знает границ, поясни. что ты понимаешь под прототипной организацией?
За самобразованием обращайся к Википедии. Ключевое слово для поиска Prototype-based.
VD>>И она мне категорически не нравится. Так что мое мнение — смолток для начального обучения лучше не применять. Он даст отрицальный эффект.
L>"Мне не нравится, так что лучше не применять". Железная логика!
А мне по барабуну ты лично и то что ты думаешь о моей логие в частности. Повторяю последний раз. Это мой список. Создай свой и те кто считает твое мнение интересным воспользуются им. А от меня отстань. Я высказал свое мнение. Считаю свой список вполне достаточным. Причем еще и полезным, так как человек не только изучит языки отражающие основные тенденции в развитии языков программирования, но и изучит живые языки которые могут пригодиться ему в будущей работе. Изучение же Смолтоков и другой древности, на мой взгляд, практического смысла не имеет. Ничего нового уникального из них не почерпнуть, и на практике их тоже использовать вряд ли получится. Те же кто интересуется ЯП с научно-позновательной точки зрения и так изучат все что захотят.
Мой ответ исчерпывающий? Если, да, то просба отвязаться от меня. Мня утамляет навязчивость.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>При чем тут твой список? Где ты сказал, что то, что С# классический ОО, это твоё мнение?
При том, что это мое мнение. Твои проблемы соглашаться с ним или нет. Не согласен, можешь попробовать доказать обратное. Но я не обязан каждому встречному давать исчерпывающие обоснования. Тут море фанатов. Находятся фанаты любой экзотики. И если каждому объяснять почему не упомянули его любимую игршку, то жинь пройдет.
L>Указывать другим на то, что им делать — это запросто.
Указывай. Только отдельной веткой. Я, если не соглашусь поставлю тебе минус.
L> Наплести логически несвязанного винегрета — пожалуйста!
Плети. Кто же против то?
L> Но как только ты слышишь мнение отличное от своего, то сразу поднимается оскорбленный вопль о списках, находящихся в частной собственности. Очень по детски.
Ты явно что-то не понимаешь. Мне плевать на твое мнение. Я просто не хочу провести неделю в оправданиях. Я шел 15 лет к тому чтобы сформировать это мнение и не хочу от него отказываться. По крайней мере без весомых на то причин. Вокруг много крикунов неспособных сказать ничего интересного, но каждый из них с радостью докопается до любых слов и начент развивать почему его любимую игрушку не включили в список.
Ответ простой — не считаю нужным.
VD>>Еще раз. Создай отдельно свой список и хоть Перл туда запиши. Мой списко трогать не надо.
L>Правила форума это запрещают?
Нет. А тебя сдерживают от глупых поступков только правила форума?
L>Термин я знаю. Ок, обратимся к Википедии.
Значит я его не выдумал? ОК, так и запишем — ты погорячился.
L>
L>Prototype-based programming is a style of object-oriented programming in which classes are not present, and behaviour reuse (known as inheritance in class-based languages) is accomplished through a process of cloning existing objects which serve as prototypes.
L>Я, наверное, что то путаю, но в Смолтолке есть и классы и переиспользование там достигается совсем другими механизмами.
Смолток позволяет вмешиваться в структуру объектов в рантайме. Это свойства тех самых прототипных языков. Смолтон не чистный прототипный язык. Но он был преттече Сэлфа. Идеи Сэлфа почерпнуты именно из природы Смолтока.
В общем-то Руби развивает эту идеяю в полной мере и, на мой взгляд, более красиво. Хотя сама идея менять объекты в рантайме мне категорически не нравится.
L>Так что ты опять что то изобрел. Я и спрашиваю — что?
Ты это утверждаешь, тебе и доказывать. Не буду же я доказываь или опровергать каждую твою фантазию?
VD>>А мне по барабуну ты лично и то что ты думаешь о моей логие в частности.
L>Зачем тогда ты это пишешь?
Ты серьезно считашь, что я это делал специально для тебя?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
L>А откуда берутся сомнения? Изучать новый язык просто так? Даже несмотря на то что сейчас он не нужен? Из логики "Может быть пригодиться"? (с). Это и есть пустая трата времени. Это самое время можно потратить более продуктивно. Имхо, конечно.
видишь ли, в чём прикол — мы все используем наши языки не совсем по назначению, вносим в них те концепции (паттерны программирования), которые изначально в языке отсутствуют. используем продцедурное программирование с ассемблером, ООП — с Си, функциональное — с С++. и для того, чтобы знать, как можно улучшить свои паттерны программирования, и полезно знать другие языки. кроме того, некоторые сами выбирают, на чём им писать
Здравствуйте, VladD2, Вы писали:
VD>А чем по-твоему иявляются параметры функций?
VD>Это ни что иноге как список фиксированной длинны разнонипных значений передающихся как единая сущность.
Ну ты понял, да?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, lomeo, Вы писали:
L>Да ладно, это же трюк. Приходится заводить на каждое имя фунции по классу, и на каждую сигнатуру по инстансу. L>В "чистом" виде перегрузки на самом деле нет L>.... L>Надеюсь, что я что то пропустил.
Я предлагаю отделить ветку и перенести в rsdn.decl. Многим будет интересно, а здесь тема затеряется в бессмысленном флейме.
а этот на нее ссылается. Я понимаю, когда защищают сильные стороны любимого дитяти, понимая, что для этого приходится жертвовать чем-то еще. Но наезжать на Хаскелл с точки зрения type machinery, приводя в пример немерле, (и упоминая, что "Немерловый алгоритм вывода типов не выводит полиморфные типы") — это за гранью.
За чьей? За гранью фанатов хаскеля? Ой, не смешите мои лямбды
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Timur I., Вы писали:
TI>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
Здравствуйте, VladD2, Вы писали:
VD>Ява перенела довольно много граблей из С++. Например, отсуствие явного указания переопределения методов (ключевое слово override)
В чем собственно недостаток? Если уж грабельный разговор... заодно расскажите, используете ли вы модификатор new в C#?
VD> или отсуствие возможности явно описать, что функция возращает множество результатов (в виде кортежей или ref/out-параметров).
Возвращение примитива по ссылке противоречит объектно-ориентированному методу. Это уже множество раз обсуждалось: передача параметра "по ссылке"
— в C# это оставили, потому на нем удобно писать в том числе и "процедурно" (к примеру, вычислители), а Java более "чистый" в этом отношении ООЯ.
VD> И таких проблем в ней много.
Да?
VD> C# можно считать наследником Явы в котором вычещено большинство проблем этого языка.
Извините, но вы пока не убедили.
VD> Еще более чистым решением является Немерле, но так что в принципе им можно заменить C#, но им можно заменить и многое другое. Если же говорить о чистых представителях, то я их перечислил и расширять список не намерен. Если у гого-то свои взгляды на такой список, то высказывайте их отдельно, а не прытайтесь подправить мой список. Если я решу его изменить, то скажу об этом сам.
Да как вам угодно: на ваш список никто не посягает — просто вы сказали достаточно резкое утверждение без аргументации, вот и заинтересовало.
Ява идет в лес за грязный дизай языка.
VD>>4. XQuary/XSLT — как пример языков трансформации данных. R>+более частные спецификации: XSL-FO, SVG, X-Path и т.п.
X-Path часть XQuary/XSLT, а остальные в лес за ненадобностью.
VD>>8. SQL — пример декларативного языка обраобтки данных. R>+объектные подходы в БД
В лес по тем же сообрежениям.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, rsn81, Вы писали:
VD>>Ява идет в лес за грязный дизай языка. R>Разжуйте, пожалуйста.
Ява перенела довольно много граблей из С++. Например, отсуствие явного указания переопределения методов (ключевое слово override) или отсуствие возможности явно описать, что функция возращает множество результатов (в виде кортежей или ref/out-параметров). И таких проблем в ней много. C# можно считать наследником Явы в котором вычещено большинство проблем этого языка. Еще более чистым решением является Немерле, но так что в принципе им можно заменить C#, но им можно заменить и многое другое. Если же говорить о чистых представителях, то я их перечислил и расширять список не намерен. Если у гого-то свои взгляды на такой список, то высказывайте их отдельно, а не прытайтесь подправить мой список. Если я решу его изменить, то скажу об этом сам.
А вообще, есть много языков с различными особенностями. Например ОКамл. Но они не дают представления о чем-то радикально новом и имеют ряд недостатков. Именно по этому я не называю эти зяыки. А то можно было бы просто перечислить все языки начиная с С и заканчивая J с K.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Да, собственно, забыл сказать. Я не зря упоминул Руби. Это как раз язык из серии продолжателей идей Смолтока только с "человеческим лицом". Так что еще раз поторюсь, смысла включать в свой список такой архики как Смолток не вижу.
VD>>Языки типа Явы и C# ВООБЩЕ не рассчитаны на работу в многопоточном окружении.
C>synchronized? lock? Это не расчет на многопоточность???
это как раз костыли вокруг mutable values, чтобы затащить их в brave new world эрланг, созданный для программирования АТСок, таких затычек не имеет, а ведь там тысячи процессов — это не подвиг, а норма
Здравствуйте, BulatZiganshin, Вы писали:
BZ>если бы вторым был пролог — это бы сказалось я к тому, что сейчас вузы т у нас, и за рубежом учат людей шравным образом императивным языкам
В моем вузе Пролог был. А то что императивным языкам учат не на программистских специальностях, так это нормально. Ненормально то, что большая часть современных программистов не имеет профильного образования.
BZ>, и потому-то они и считают это естественным. имхо, функциональный подход даже более естественен, особенно если идти от чистой математики
Нет, функциональный подход не естественен, потому что идея неизменяемого мира не может быть естественной. Понимаешь, лет несколько назад я наверное думал так же. А сейчас понимаю — не попадись мне тогда бейски, я скорее всего так и не стал бы программистом. Понять тогда ФП мне было просто без шансов, для меня ООП тогда был крайне сложной штукой.
BZ>а когда человек изучит десяток императивных языков, ему в функциональные врубиться уже совсем тяжело
Это тоже заблуждение. Функциональность вобще слабо коррелирует с императивным программированием, но при этом неплохо комбинируется с ним. Более того, мне вобще не нравится рассматривать ФП как некий монолит. На самом деле в ФП есть несколько идей, и многие из них (immutable структуры, лямбды, pattern matching etc) вполне применимы и в императивном программировании. Я тебе даже больше скажу — огромное количество современных мейнстрим-программистов знает минимум один функциональный язык — SQL. Да, он конечно весьма ограничен, но тем не менее. А есть еще XSLT, который не любят, но продолжают жрать кактус. Беда ФП не в страшном и ужасном образовании, которое навязывает императивщину, а в том, что многие функциональщики упорно тащат свою тележку в сторону элитарности.
Вот для чего действительно требуется ломка сознания, так это для языков вроде Пролог. И для ООП (если начинать со структурного программирования) кстати тоже.
BZ>, и возникает у него ощущение "а они почему строем не ходят?"
Правильное, между прочим, ощущение. Бо действительно не все хорошо в функциональном королевстве. Вот, к примеру, LInQ большинством программистов воспринимается на ура. Так может проблема не во внешнем мире, а внутри? Промышленный язык должен разрабатываться именно как промышленный язык, и никак иначе, вне зависимости от того, какую парадигму он проповедует.
... << RSDN@Home 1.2.0 alpha rev. 673 on Windows Vista 6.0.6000.0>>
Здравствуйте, VladD2, Вы писали:
VD>Ребят, чеснослово задолбали!
На обиженных... ну ты сам знаеш
VD>Поймите, просто перечислить все языки которые знаешь или о которых слышал — это задача для дауна. Я попытался создать минимально достаточный список. В него ничего не надо вставлять!
"Я тут сказал мысль, а вы не сметь критиковать!"
VD>Я понимаю, что у разных людей разные предпочтения, но и вы меня поймите. Это мои предпочтения. Не надо в них добавлять ничего! Создайте свой и хоть всю вселенную в него впихните.
Ну и ты нас пойми, нас очень интересует не сам список, а _почему_ он именно такой!
Или так сильно влом вежливо и без наездов объяснить, почему именно этот язык не включён в список?
Или с тебя шапка упадёт/нимб свалится, если ты признаешся, что не знаешь какой-то язык?
Здравствуйте, Yuri Khomich, Вы писали:
YK>Ничего такого отсюда не следует. С таким же успехом ты можешь получить дедлок в случае использования в качестве локов внутренних объектов, если локи берутся в неверном порядке. Ну так думать же надо.
Ну, наверное, имеется в виду, что в случае синхронайзед методов — шанс получить дедлок выше.
И вообще, имхо, это странно — иметь возможность использовать любой объект в системе в качестве монитора.
Здравствуйте, konsoletyper, Вы писали:
K>А то многие начинают выпендриваться и говорить "прочитай Кнута и научишься программировать". Совершенно согласен, что Кнута нужно изучать далеко не в первую очередь.
это как раз основы программирования. только читать надо в адаптированном варианте, типа "алгоритмы и структуры данных" Вирта; таких книг до фига и ещё больше
VD>>А чем по-твоему иявляются параметры функций?
E>Ага, фрейм стека в C/C++ в перемешку со значениями регистров уже стал кортежем.
а причём тут процессор? речь идёт о языке. и тут Влад прав — с теоретичсекой точки зрения это кортёж и есть, пока ты не используешь переменнное число аргументов
BZ>>все возможности *яызка* Смоллток в руби есть.
VD>+1 Даже больше. Но действитльно языки одного направления, хотя Руби вроде дрался с Перла.
семантика — смолток, синтаксис — эйфель, фичи — перл. вообще, руби — это просто фантастическая коллекция наиболее удачных решений из разнообразных языков. например, в книге "жемчужины прогшраммирвания" описан гипотетический язык с очень удобным операторм case. нигда в реальных яхзыках такого так и не сделали. кроме руби!
BZ>> правда, изменилась терминоллогия, и главное — нет той замечательной среды. ведь это же была первая IDE в мире! и до сих пор, как я понимаю, нет ни одной среды, где было бы так легко работать со структурой классов и проверять, что возвратят те или иные методы
VD>Сполток конечно обладал первой IDE, но на сегодня IDE Явы и Шрпа намного мощьнее.
не видел ни ту, ни другую, ни третью, так что могу ошибаться. но фишка в том, что смолток динамчисекий язык и в его среде во-первых ты работал непосредтсвеенно с классами, а не исходными файлами, во-вторых, мог проверить работу любой функции непосредственно запустив её
>Тут ты не прав. И причина тут в том, что для этих языков доступна полная информация о типах. Кстати, для Хаскеля хорошую IDE сделать можно, хотя язык имеет плохие особенности вроде уникальных идентификаторов (из-за выбранной системы типов и уращения клгоритма вывода типов), что весма странно будет выглядить в современном мире. А у Руби и Смолтока их динамическая типизация приводитк к серьезным ограничениям.
что означает "уникальные идентификаторы"? я вообще лучше знаю английскую терминологию
BZ>>C# же, как и Delphi — язык чисто практический, я лично в нём ничего концептуального не вижу.
VD>В них выражены все концепции ООП. Причем используется система типов основанная на классах, то есть так что родилась в Симуле. Смоток и Риби пошли своим путем. Лично мне он не нравится. Но в любом случае достаточно одного представителя этого направления — Руби. Теболее что Руби на мой взгляд более интересный язык.
вместо C# и Delphi с теоретической точки зрения лучше изучать Eiffel, это дейсвтивительно красивый и мощный язык с чистой ООП идеологией. руби отличается от него динамической титпизацией, это отдельная парадигма со своими преимуществами и недостатками
BZ>> и вообще, на мой взгляд, изучать ФП надо с...
VD>А причем тут ФП? У тебя случае мунктика на нем нет? В списке били и Хаскель, и Схема. Вот на них пусть ФП и изучается.
есть. я вроде и говорил про эти два языка, ты не заметил?
BZ>> наиболее теоретичсеких, удобных в программировании, но неэффективных (пролог, хаскел),
VD>С каких пор Пролог стал ФЯ?
логичнсеколе программирование — тоже мощная, хотя и медлительная парадигма
BZ>> и далее спускать к более практичным, но сложным в использовании языкам. и заканчивать на C#, яве или чём-то ещё, что будет реально использоваться. языки более низкого уровня, типа C++, изучать необязательно — разве что чтобы понять, как функционирует процессор, да и это начинающему ни к чему
VD>А я так не считаю. Как раз я бы сначала познакомил людей с выражениями, потом с основами процедурного программировнаи, а потом бы уже давал бы ФП и ООП как его расширения (заужение). На мой взгляд так будет проще донести до людей эти идеии. Возможно даже вначале показывать сам подход в виде паттернов, а потом показывать соотвествующие языковые конструкции.
имхо после выражений нужно переходить к более сложным выражениям
VD>Что касается языка, то я бы как раз выделил на роль первого языка Немерле или Руби. Руби я бы посоветовал тем учетилям которые считают, что вначале людям не надо морочить голову с типизацией, а Немерле тем кто считает, что типизация важнеший аспект. Ну, и по той причине, что на немерле можно показать практически все приемы кроме разве что ЛП.
вот именно, и ничего хорошего я тут не вижу. мимхо, надо изучать разные параддигмы по их чистым представителям, а не язык, где они как-то сбиты вместе. что касается руби... он очень хорош для некадровых программистов. профессионалы должны думать более систематчисеким путём, они должны жить со сторгой типизщацией в уме, и для них руби будет полезен ближе к концу курса как красивый практический язык
BZ>>такой подход научит человека мыслить на наиболее высоком возможном уровне — ведь здесь важно, с чего ты начнёшь.
VD>Твой подход привьет человеку конкретный образ мышления и осложнит восприятие других парадигм. Точно так же плохо давать в начале ООП, а потом пытаться обучить ФП.
а ты собираешься их смешанно давать, типа одно предложение их одной парадигмы, второе из другой? имхо надо изучить каждую из них — ООП, ФП, ЛП в чистом виде, на чистых языках, и затем уже идти к тому, как они могут сочетаться. иначе вчедловек, привыкший к ФП-поверх-ООП в Немерле будет *очень* обескуражен ООП-поверх-ФП в окамле, и скорей всего до него долго не дойдёт в чём тут приницпиальная разница
VD>В обоих случаях будет отторжение второй парадигмы и ломка. Особенно это актуально для ФП, так как литература по нему полное дерьмо. Вообще удивительно как казалось бы стольк умные люди придумавшие все это так бездарны в писательстве! Ну, да это отдельная тема.
а ты читал книгу Вадлера или Худака или судишь по Хал-Ван Даму?
VD>В общем, я виду к тому, что ООП и ФП надо давать параллельно и обязательно как развите стурктурного программирования.
почему? потому, что ты сам начинал с него? в хаскеле неструктурное программирование вообще трудно поредставить, оно лежит в самой идеологии языка. то же самое в прологе
BZ>> если первым яхзыком будет бейсик, то он для человека станет "родным", и дальше все новые концепции будут перекладываться на его "архитектуру"
VD>Забавно, что ты заметил, что первый язык привязывает к образу мышления. Стало быть твое предложение сделать ФП первым в изучении ни что иное как попытка привязать программирование к нему. На мой взгляд это ошибка.
я вообще-то предлагал начать с Пролога, поскольку считаю ЛП наиболее высокоуровневой парадигмой. и дальше идти по остальным парадигмам, чтобы человек с самого начала усвоидл каждую из них. но по отдельности, а не в виде nuj бутерброда, которы они приняли в том или ином конкретном языке. иначе он не научится видеть, что здесь принадлежит к ФП, что к ООП, и как их можно соединить иначе или вообще одну из них выкинуть
VD>Бэйсик же бывает разным. Бывает 70-ых годов с жудчащими goto вместо функций. А бывает VB.NET почти не отличающийся от C#. В прочем VB.NET — это ООЯ, что опять же привяжет к ООП. Что плохо.
VD> А вот как средство изучения структурного программирования Васик довольно хорош. Так чта... а пуркуа бы собственно не па?
с.п. на данный момент уже можно считать частью ООП. я не вижу смысла изучать его отдельно, благо что при других парадигмах нестурктурно программировать всё равно не получится
VD>Я вот первым языком учил С. И особых проблем не вознкло. ФП крышу рвал по началу, но только от того что писатели пытающиеся его объснить были бездарностями.
имхо, ты м сейчас мыслишь в императивном стиле, используя ФП только локально. на что несомненно откладывает отпечаток используемый тобой язык
VD>Кстати, ООП я освоил на раз. И уверен, что это произошло так легко потому, что я сначала испытал в нем потребность, а затем прочел о нем. Я в 93-ем писал программу выводящую окна на экран и после первого лобового опыта стал задумываться как бы это дело реализовать. Патом я стал читать книжку про Виндвс и восхищался идеями сообщений и окон. Далее я изобразил что-то подобное на структурах и указателях на фукнции. Ну, а потом я уже читалш про С++ и мне все казалось логичным и стройным.
VD>Уверен, что именно так надо преподносить знания в учебных заведениях. То есть: VD>1. Базовые знания. VD>2. Постановка задачи хорошо решающеся с помощью некого подхода. VD>3. Решение в лоб. VD>4. Анализ проблем. VD>5. Теоритический рассказ о подходе. VD>6. Решение задачи с помощью паттерна. VD>7. Демонстрация встроенных средств языка. VD>8. Анализ приемуществ встронных средств языка над использованием паттерна.
VD>Уверен, что при таком подходе крышу сносить не будет. VD>Так что продаю идею.
т.е. сначала надо научить людей структурному программированию, чтобы они поняли что это бяка и освоили ООП? а перед этим научить их програмимровать на асме, чтобы затем преподнести им идеи стурктурного программирования? а перед этим — в машинных кодах, да?
твой подход хорош для доучивания людей, которые уже владжеют некоей неэффектвиной парадигмой. с нуля же их учить этой парадигме только чтобы продемонстрирвоать её неэффектинвость, нет никакого смысла. их надло сразу учить мыслить в правильном ключе, и pfmtv уже более простые подходы давать только для парктических нужд
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Вполне можно, с определенной точки зрения, рассматривать как "функцию foo, которая принимает на вход кортеж параметров и статически контролирует количество и тип элементов кортежа".
Так вот по моему мнению, в рассмотрении с такой точки зрения передачи параметрам функции в C++ нет никакого практического смысла. Т.е. это чистое теоритизирование, не имеющее сухого практического остатка. А посему -- теоритизирование, сильно оторванное от действительности.
Более того, приведенная тобой запись мало чего контролирует на самом деле:
ни при компиляции, ни при исполнении, никто не даст по рукам за то, что в функцию real был передан совсем другой кортеж.
ЗХ>Ну и, возвращаясь к тому, с чего была поднята эта тема, метафора кортежа была употреблена вполне корректно, в диалоге "зачем возвращать из функции кортеж (список разнотипных значений)? — затем же, зачем мы передаем в функцию кортеж (список разнотипных значений)?"
Ничего не имею против возврата кортежей из функций в языках с поддержкой кортежей. Но, имхо, проводя аналогии и используя примеры нужно придерживаться объективной реальности. На практике нет в C++ кортежей, поэтому использование C++ в качестве примера использования кортежей при вызове функции не корректно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Так вот по моему мнению, в рассмотрении с такой точки зрения передачи параметрам функции в C++ нет никакого практического смысла. Т.е. это чистое теоритизирование, не имеющее сухого практического остатка. А посему -- теоритизирование, сильно оторванное от действительности.
Значит, не видишь суслика. А он все-таки есть! Ведь зачем-то придумали в С++ функции нескольких аргументов, не так ли? Хотя вполне можно было упростить всё и потребовать чтобы был только один параметр. А если кому-то надо передавать сразу два — пусть явно опишут структуру. Иначе это архитектурная ошибка.
Соображения симметрии требуют, чтобы функция умела не только принимать, но и возвращать много значений. Ничего укуренного в этом нет. Нужно только немножко абстрагироваться от конкретного языка С/С++.
E>Более того, приведенная тобой запись мало чего контролирует на самом деле: E>ни при компиляции, ни при исполнении, никто не даст по рукам за то, что в функцию real был передан совсем другой кортеж.
Мы все в курсе, что компилятор С++, как и законы берегового братства, скорее рекомендует, нежели запрещает. Это скорее проблема, чем преимущество.
ЗХ>>Ну и, возвращаясь к тому, с чего была поднята эта тема, метафора кортежа была употреблена вполне корректно, в диалоге "зачем возвращать из функции кортеж (список разнотипных значений)? — затем же, зачем мы передаем в функцию кортеж (список разнотипных значений)?"
E>Ничего не имею против возврата кортежей из функций в языках с поддержкой кортежей. Но, имхо, проводя аналогии и используя примеры нужно придерживаться объективной реальности. На практике нет в C++ кортежей, поэтому использование C++ в качестве примера использования кортежей при вызове функции не корректно.
Корректно-корректно. Просто некоторые паттерны встроены в язык С++, и в частности использование кортежа при вызове функции.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
E>>На практике нет в C++ кортежей, поэтому использование C++ в качестве примера использования кортежей при вызове функции не корректно. S>Корректно-корректно. Просто некоторые паттерны встроены в язык С++, и в частности использование кортежа при вызове функции.
Скорее уж так: некоторые решения, встроенные в C++, могут интерпретироваться как реализации различных паттернов.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Timur I., Вы писали:
TI>Здравствуйте! TI>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
Друг, здесь мнений много, но послушай и моё. С помощью таких вещей как Java или C# уже можно зарабатывать миллионы долларов.
Мой тебе совет: заработай их, а потом решай, нужно тебе что-то или нет, т.е. отталкивайся от цели к средствам, а не от средств в поисках цели. Жинь коротка, а дни лукавы и обманчивы, стоит ли её тратить на все языки мира или лучше это время подарить своей семье?
Здравствуйте, c-smile, Вы писали:
CS>Вообще языки *изучать* не надо. Желание на посмотреть чего-то придет само (если придет).
По-моему, "изучать" языки не делая на них конкретный проект — пустая трата времени. В университетах Object Pascal дают по нескольку лет, и то после этого человек его не знает. Полевые условия — самый верный вариант обучения... ну и икра на хлебе появится.
Здравствуйте, EvilChild, Вы писали:
IT>>Главное, что проблема стоит выеденного яйца. Вариант туплов в Н не требует никакой рантайм поддержки и не имеет таких проблем. EC>И при этом CLS compliant?
Дык без проблем.
EC>Можешь привести пример использования?
Можно даже больше чем пример. Tuples в Н представляют собой структуры/классы следудующего вида:
public struct Tuple[T1, T2]
{
public field0 : T1;
public field1 : T2;
}
public struct Tuple[T1, T2, T3]
{
public field0 : T1;
public field1 : T2;
public field1 : T3;
}
что в переводе на C# означает
public struct Tuple<T1, T2>
{
public T1 field0;
public T2 field1;
}
Именно так эти структуры и видны из внешнего кода. Сам же компилятор просто обеспечивает встроенную, более удобную работу с этими структурами.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, Timur I., Вы писали:
TI>>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
ЗХ>Однозначно последнее.
Здравствуйте, VladD2, Вы писали:
VD>1. C# — классика ООП, компонентность, статическая типизация, обобщенное программирование. VD>2. Руби — классика скриптов, динамика, гибкость. VD>3. Хаскель — функциональный подход, вывод типов, красивая идея классов типов (похожая на интерфейсы в C#, но которые можно подключать к уже имеющися типам), ленивое исполнение. VD>4. XQuary/XSLT — как пример языков трансформации данных. VD>5. Схема — как пример языка без синтаксиса и мощи макросов. VD>6. Рад, что даждались ожидаемого. Правильно немерле как квинтесенция свсего перечисленного выше. VD>7. Пролог, как демонстрация красивой идеии логического программирования практичски бесполеной на прктие. VD>8. SQL — пример декларативного языка обраобтки данных. VD>9. Регулярные выражения и Перл, как пример того что и на системах фирования можно писать программы.
Я бы добавил
10. Erlang, как сoncurrency oriented language
Здравствуйте, VladD2, Вы писали:
L>>Ты же не добавлял, когда говорил, что С# классический ОО,
VD>Для особо невнимательных цитирую себя любимого: VD>[b]Мой список языков котрый может расширить кругозор:[/b]
При чем тут твой список? Где ты сказал, что то, что С# классический ОО, это твоё мнение?
Указывать другим на то, что им делать — это запросто. Наплести логически несвязанного винегрета — пожалуйста! Но как только ты слышишь мнение отличное от своего, то сразу поднимается оскорбленный вопль о списках, находящихся в частной собственности. Очень по детски.
VD>Еще раз. Создай отдельно свой список и хоть Перл туда запиши. Мой списко трогать не надо.
Правила форума это запрещают?
VD>За самобразованием обращайся к Википедии. Ключевое слово для поиска Prototype-based.
Термин я знаю. Ок, обратимся к Википедии.
Prototype-based programming is a style of object-oriented programming in which classes are not present, and behaviour reuse (known as inheritance in class-based languages) is accomplished through a process of cloning existing objects which serve as prototypes.
Я, наверное, что то путаю, но в Смолтолке есть и классы и переиспользование там достигается совсем другими механизмами.
Так что ты опять что то изобрел. Я и спрашиваю — что?
VD>А мне по барабуну ты лично и то что ты думаешь о моей логие в частности.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, fmiracle, Вы писали:
L>>>А основы электроники-то зачем?
F>>Думаю — для общего развития. Представлять себе как примерно функционирует компьютер — от этого хуже не будет, а помочь иногда может
L>Ну эдак и до квантовой механики можно опуститься.
Здравствуйте, konsoletyper, Вы писали:
K>А то многие начинают выпендриваться и говорить "прочитай Кнута и научишься программировать".
Здесь, ИМХО, нужно добавлять: "...наконец-то".
K>Совершенно согласен, что Кнута нужно изучать далеко не в первую очередь.
Естественно. А как его читать без предварительной теории графов, например?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Last Cjow Rhrr, Вы писали:
LCR>Грязь и бедность — это не одно и то же однако. То что ты привёл — это бедность в выразительных средствах. Грязь (то есть именно непоследовательность и обилие граблей) в Jave конечно есть, я бы туда отнёс некрасивую работу с плоскими типами (особенно когда туда приплели автобоксинг в 5-й джаве).
ИМХО, (ИМХО!) главная грязь Java заключена в крайне запутанной концепции inner classes. Ну и в вытекающей из этого грязности (грязноте?) анонимных классов.
Здравствуйте, Cyberax, Вы писали:
>> C>Кхм. А что в них такого запутанного? >> Нелогично. Из разряда "понять нельзя, можно только запомнить". C>Мне хватило 10 минут, чтобы понять как оно работает — когда я C>декомпилировал их и посмотрел что там внутри. Все сразу становится ясно.
Ключевой момент я пометил жирным. ИМХО, это неприемлемо для понимания концепций языка.
C>Ты можешь привести пример "непрозрачности"?
Что значит пример? Inner classes и их взаимодействие с outer class, особенно когда речь заходит об экземплярах и есть такой пример.
>> намного печальнее. Там есть разновидности, которые остаются inner >> классами и в рантайме со всеми вытекающими. И вот взаимодействие >> экземпляров этих классов с экземпляром класса владельца это весьма >> хитрая конструкция. C>Обычные прокси-методы. Что тут такого?
Нет там в языке никаких прокси-методов. Ты вот смотри что постоянно делаешь — как только пытаешься объяснить почему сделано так и не иначе, так тут же скатываешься на детали реализации. Именно об это я и говорю.
).
VD>Да, уместно. Но о нем еще надо знать. А rsn81 явно не из тех кто обсуждает то, что знает.
-1
VD>Еще можно было бы упоминуть дизайн делегатов и пару других вещей.
+1
[]
VD>Языки типа Явы и C# ВООБЩЕ не рассчитаны на работу в многопоточном окружении. В них проблема гонок и неатомарности функций может возникнуть где угодно и когда угодно.
повеселил А может еще расскажешь, что такое атомарность функций?
PS: тот, кто часто использует кортежи в качестве возвращаемых значений явно что-то не то делает. Или у него слишком специфичная задача. Отсутствие кортежей — не смертельно.
Здравствуйте, Константин Л., Вы писали:
КЛ>повеселил А может еще расскажешь, что такое атомарность функций?
Слушай, ты бы не позорился бы, а?
КЛ>PS: тот, кто часто использует кортежи в качестве возвращаемых значений явно что-то не то делает. Или у него слишком специфичная задача. Отсутствие кортежей — не смертельно.
Тебе, конечно, видней.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
L>В целом я согласен. Но под "знать язык" я подразумеваю не "прочитал книжку, глянул пару семплов и написал HelloWorld". Такие знания гроша ломаного не стоят и счастливый обладатель таких знаний сам через полгода забудет большую часть. А реальное изучение отнимет много времени. А если оно еще и не под конкретную задачу, а просто "чтоб было"... В плане ознакомления с новыми концептами другие языки просматривать стоит. Знакомиться с их парадигмами и идеями. Но полноценно изучать я бы их не рекомендовал.
сиё от тебя зависит. я например C++ с 90-го знаю, а ты? яву/C# я в своё время тоже прочёл, но остался ранодушен. зато в другие языки влез по самые уши. но это у меня хобби такое, ты может предпочитаешь рыбу ловить или в футбол играть
Здравствуйте, Константин Л., Вы писали:
FR>>Нужен результат: например вернуть из функции N (разнотиповых) переменных, есть несколько альтернатив как это сделать, в языке подерживающем туплы, это элементарно просто вернуть тупл. В языке не подерживающем туплы или завести структуру из этих N переменных (единственное предназначение которой только возврат этих переменных) или что еще хуже завести у функции out параметры. Тупл здесь средство упростить и очистить от мусора код и ничего больше.
КЛ>вот в чем ошибка, которую мы сами совершаем и сами же фиксим с пом. туплов.
Хоть это только пример объясни в чем ошибка-то?
Мне кажется если бы в C++ были туплы или ты достаточно часто писал на другом языке с туплами, то твое мнение было бы совсем другим.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>>>C# же, как и Delphi — язык чисто практический, я лично в нём ничего концептуального не вижу.
VD>>В них выражены все концепции ООП. Причем используется система типов основанная на классах, то есть так что родилась в Симуле. Смоток и Риби пошли своим путем. Лично мне он не нравится. Но в любом случае достаточно одного представителя этого направления — Руби. Теболее что Руби на мой взгляд более интересный язык.
BZ>вместо C# и Delphi с теоретической точки зрения лучше изучать Eiffel, это дейсвтивительно красивый и мощный язык с чистой ООП идеологией. руби отличается от него динамической титпизацией, это отдельная парадигма со своими преимуществами и недостатками
И тут влезу я
Я давеча для себя сформулировал, что, вообще говоря, есть два "совсем разных" ООП — "мейнстрим-ООП" и "радикальное ООП".
Мейнстрим-ООП — это то, что пошло от Симулы и наиболее чисто (почти без грязи-для-большей-практичности) выражено в Eiffel. У него ноги растут от "стремления структурности", главный лозунг — "основная единица организации кода — это класс" ("класс" здесь, — это в душе всегда "модуль на стероидах"). Т.е. предлагается думать о программе в терминах "декомпозиции на классы".
Радикальное ООП — пошло от Smalltalk (точнее, от некоторых более ранних разработок, но эту деталь мы опустим). У него ноги растут от "стремления к естественности и простоте", главный лозунг — "все есть объект", "программа это взаимодействие объектов". Классы здесь могут быть (Smalltalk, Ruby), а может и не быть (Self, Io) — это как бы вторичная по отношению к объекту сущность; все потому, что классы — это тоже объекты, но со специализированной задачей.
Приверженцы двух традиций друг друга не очень любят, и только свое ООП считают истинным (помнится, Влад где-то выше по ветке весь второй вариант широким жестом нарек "языками с прототипной орканизации"). Понятно, что в какой-то степени они обмениваются "приемчиками" (иначе Руби не считался бы наследником некоторых идей и Смоллтолка и Эйфеля)
А вот связан ли "тип ООП" с динамичностью самого языка — я не вполне уверен. Сходу кажется, что да (иначе классы нельзя менять в рантайме, и тогда они не полноценные объекты), но так ли оно?
ЗЫ: кстати, высказывания на тему "Ruby — это правильный Smalltalk" считаю примерно настолько же экстремистскими как "Nemerle — это правильный Haskell" (хотя, кажется, я знаю человека, который с последним согласится).
Здравствуйте, VladD2, Вы писали:
BZ>>ну а тезнически запрет таких вызовов, заодно с явным описанием плорядка вызова процедур, решается "эстафетной палочкой" — фиктивным значением типа RealWorld, передаваемым от порцедуры к процедуре, и недоступным функциям. т.е. функция не может вызвать процедуру потому, что она такую эстафетную палочку не получает сверху, и не может создать её сама
VD>В лес всю фикцию. Проблема рашается намного проще. Надо всего лишь отказаться от пуританства.
Здравствуйте, Lloyd, Вы писали:
L>>>На счет того, что оба варианта — грамматически правильны я и не спорил. Просто было употребелно не то слово.
AVK>>Там есть и толковые словари. И употреблено правильно.
L>Нет, извини, но употреблено неправильно.
Вообще то тема "Альтернативные языки". Так что зависит от того, в каком языке употреблено
Блин, совсем вылетело из головы, что ты меня спрашивал...
List<String>[] data = new ArrayList<String>[10]; // такие коллекции недопустимы
List<String> data1 = new ArrayList<String>(); // а так мона
VD>Что за проблема не дает создать массив ArrayList-ов?
Всё из-за того, что дженерики исчезают в рантайме.
Если глянуть рефлекшном data1, то он окажется обычным ArrayList. Таким образом, невозможно в рантайме отличить ArrayList<String> от ArrayList<Integer>, и теоретически можно написать
data[0] = new ArrayList<String>();
data[1] = new ArrayList<Integer>();
Здравствуйте, Java2, Вы писали:
J>Здравствуйте, Timur I., Вы писали:
TI>>Здравствуйте! TI>>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
J>Друг, здесь мнений много, но послушай и моё. С помощью таких вещей как Java или C# уже можно зарабатывать миллионы долларов.
Здравствуйте, awson, Вы писали:
A>Вы с какой Луны свалились? Сегодня говорить о системе Хиндли-Милнера в применении к Хаскеллу — все равно, что уподоблять, к примеру, Лаурин-Клемент 1904 года Макларену MP4-21.
Это пустой треп. Факт остается файктом. Хаскелевская система типов основана на системе типов Хиндли-Миллера и переняла у нее все ее недостатки. То что она была расширена — это уже к делу не отностися.
A>В GHC — а это, фактически, референсный компилятор Хаскелла — давно уже есть: A>1. Multiparameter typeclasses + functional dependencies A>2. GADTs
Какой это отношение имеет к тому о чем говорю я?
Сие замечание является банальной попыткой докопаться до слов.
A>Недавно GHC был переведен на system Fc, что позволило реализовать еще и type-indexed data types и устаканить все сложные взаимодействия между упомянутыми возможностями.
Да хоть колеса от карьерного самосвала. Такиех вещей как перегрузка фукнций, неявное привдение типов система типов Хаскеля не позволяла и никогда не будет позволят.
VD>>Ну, мы уже наблюдали как Хаскель сливает Немерлу .
A>Немерл ... мухаха. Детский лепет.
Да хоть горшком назови. Всем плевать. Хаскель красивая игрушка не пригодная для реальной жизни. А на Немрле или на его аналоге будут тонны кода в ближайшем будущем, и получать от этого огромные приемущества. Так что свои безасновательные можешь оставить при себе. Они никого не колышат.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, awson, Вы писали:
A>Как прикажете посчитать, например, foobar "Fucking overloading!" ???
Да легко. В Немерловском выводителе поддержка перегрузки по результату есть, правда включена она только для операторов преобразования типов и generic методов. Но я ради интереса включал поддержку для любых методов. Вывод типов просто откладывается до того момента, когда точно известен необходимый нам тип.
Когда мы считаем foobar("a***n — дурилка картонная!"), то мы же не просто выбрасываем это значение, так? А например делаем вот что: (foobar("a***n — дурилка картонная")-3). Из этого компилятор делает вывод, что тип foobar должен быть string->int.
A>Иногда лучше жевать.
Иногда лучше не жевать.
Здравствуйте, Vermicious Knid, Вы писали:
VK>Когда мы считаем foobar("a***n — дурилка картонная!"), то мы же не просто выбрасываем это значение, так? А например делаем вот что: (foobar("a***n — дурилка картонная")-3). Из этого компилятор делает вывод, что тип foobar должен быть string->int.
Какая-то ахинея. Вы уж, если пытаетесь меня критиковать, хоть почитайте. Я же сам потом написал, что там ничего не помогает!
Например, явное указание foobar :: String -> String.
А Вы пытаетесь из строки вычесть целое, потом говорите, что компилятор отсюда выведет string->int, что это вообще за бред?
A>>Иногда лучше жевать. VK>Иногда лучше не жевать.
Здравствуйте, lomeo, Вы писали:
VD>>Самое смешное, что лично я хотел бы чтобы ты был прав, так как не вижу смысла в выводе типов выше тел методов,
L>Ты не пробовал, вот и не видишь.
Ну, тебе виднее. Как говорится, с очевидцами не спорят.
VD>>но вижу приемущества от такого ограничения.
L>Ага! Так это, значит, всё таки ограничение?
Ты точно здоров?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Обнаружен новый язык — конкурент Nemerle! Называется Lexico, далее следует пример кода:
/*Fibonacci source*/
tarea:
{
los objetos i, n, primero, segundo, tercero son cantidades
muestre: "Entre el numero de terminos deseados: "
entre: n
copie 0 en i, primero
copie 1 en segundo
mientras i<n haga:
{
copie i + 1 en i
muestre primero
copie primero + segundo en tercero
copie segundo en primero
copie tercero en segundo
}
}
Единственный недостаток — требует .NET:
incluya "System.Windows.Forms"
clase ventana derivada_de "System.Windows.Forms.Form"
{
publicos:
mensajes:
ventana copie "Este es el título de mi primera ventana" en ventana.text
}
OCTAGRAM wrote: > C>Если требуется использовать операции синхронизации — это УЖЕ источник > C>для трудноуловимых ошибок. > Да нет, Яве до Ады далековато будет Да Ява и не преследовала удобство > параллельного программирования. Впрочем, удобство родового > программирования она тоже не преследовала до поры до времени. Кто знает, > быть может, однажды придёт мода и на параллельное программирование.
Да ничуть Ада не удобнее. Отличается только синтаксическим сахарком и
мелкими деталями.
> В Аде нет мьютексов. И вообще нет примитивов. Ни мьютексов, ни сигналов. > Синхронизация встроена в объекты.
И? Мьютексы никуда не исчезают, если даже встраиваются в объекты. И все
те же проблемы с порядком блокировки и priority inversion никуда не
исчезают.
> Метолы protected объектов могут выполняться одновременно максимум в > одном потоке. Разве не это требуется? Только это синхронизация с > человеческим лицом.
Нет. Остаются все те же проблемы мьютексов.
> Про задачи долго объяснять, там механизм рандеву используется, гляньте в > Интернете. Если Вы не ещё знали, что это такое, я уверен, Вам понравится.
Я использую паттерн "рандеву" уже много лет, в том числе и в Java. В
JDK1.5 он даже в стандартную библиотеку вошел.
Еще раз — рекомендую посмотреть на Erlang. Вот там действительно
уникальный подход к решению проблемы.
Несмотря на то, что некоторые механизмы в Java эффективнее
OCT>обеспечивают решение отдельных задач программирования параллельных
OCT>вычислений, в целом Ада предлагает более доступные и надёжные
OCT>механизмы поддержки программирования для параллельных
OCT>вычислительных систем.
Нда... Я бы постеснялся такие статьи цитировать.
Хотя бы потому, что в Java кроме мониторов+volatile есть и:
Короче говоря, автор "сравнения" не знает нормально Java (хотя бы потому, что метод destroy() для потоков не реализован). Про возможность создавать в Java потоки с помощью внутренних анонимных классов — он тоже не подозревает.
Здравствуйте, fmiracle, Вы писали:
L>>А основы электроники-то зачем?
F>Думаю — для общего развития. Представлять себе как примерно функционирует компьютер
На электрическом уровне? А зачем? И, что забавно, ПТЦА было вобще не упомянута, хотя она то точно будет полезна, если уж гнаться за кругозором.
Здравствуйте, Vermicious Knid, Вы писали:
VK> Я не так давно смотрел данные опросов — пользователям GHC это все просто не нужно. То что им нужно, разработчикам GHC улучшать не особо и интересно — они же занимаются чистой наукой.
В потверждение моих слов — вот оно. Небольшой отрывок:
Second, here's a super-quick summary of what we've learned:
— The #1 complaint was the compilation speed and memory usage of GHC.
— Next most unpopular was performance and size of the generated code.
— The most-requested feature, after performance improvements, is some kind of debugger.
— Portability and the difficulty of compiling GHC was raised a lot.
— API and feature changes breaking code between releases was also a common gripe.
— Many people mentioned the quality of error messages as something that could be improved.
— Many people want improvements to documentation, especially library docs.
— Lots of requests for an IDE and better GUI support.
— There is some concern over the complexity of GHC affecting its maintainability and portability,
and how difficult it is to contribute.
Здравствуйте, EvilChild, Вы писали:
VD>>Глобальная глупость решения МС в том, что анонимные типы нельзя будет описать. EC>А какой смысл в описании анонимных типов?
У меня такого вопроса даже не возникает. Лично я не вижу смысла в них без возможности их выразить. Вообще странно что тип есть, а описать его нельзя.
EC>Можешь пример использования привести?
Возврат значения из метода. Сделал ты красивый запрос через LINQ и хочешь поместить его в фукнцию. Ан та тебе — нельзя. Ведь запрос твой возвращает анонимный тип. А их то как раз описать невозможно.
EC>И какой синтаксис тебе видится? На манер анонимных делегатов?
Если уж они пошли по пути именования полей анонимных типов, то можно использовать синтаксис типа:
Здравствуйте, VladD2, Вы писали:
VD>Это относится к системе типов Хаскеля. Точнее примитивности системы Хинли-Миллера. Она конечно позволяет довольно ээфективно выводить типы, но страдает достадными ограничениями вроде невозможности перегрузки функций по имени. Например, мы не можем определить свойство (метод, поле, функцию) "x" у типа Point и скажем у типа Point3D. Разруливание на уровне модулей не катит, так как оба типа данных могут понадобиться в одном коде. Посему фукнции начинают вбирать в себя префиксы вроде pointX и point3dX. Сто лично мне очень не наравится. И вообще, я привык к "излишествам" рожденным С++: перегрузка, неявные приведения типов, объекты...
Вы с какой Луны свалились? Сегодня говорить о системе Хиндли-Милнера в применении к Хаскеллу — все равно, что уподоблять, к примеру, Лаурин-Клемент 1904 года Макларену MP4-21.
В GHC — а это, фактически, референсный компилятор Хаскелла — давно уже есть:
1. Multiparameter typeclasses + functional dependencies
2. GADTs
Недавно GHC был переведен на system Fc, что позволило реализовать еще и type-indexed data types и устаканить все сложные взаимодействия между упомянутыми возможностями.
VD>Ну, мы уже наблюдали как Хаскель сливает Немерлу .
Здравствуйте, Константин Л., Вы писали:
КЛ>>>повеселил А может еще расскажешь, что такое атомарность функций?
VD>>Слушай, ты бы не позорился бы, а?
КЛ>ну дай попозориться, пожалуйста
КЛ>так ссылочку может даешь или еще что...А то вот говоришь умные слова, хочется узнать откуда дровишки.
ОК. Я думал ты прикалываешся, а ты похоже иправда не понял о чем я говорю.
В математике все фукнкции чистые. Это значит, что они не имеют побочных эффектов. Взывая чистую фунцию ты можешь быть уверен, что ничего не изменится. Таким образом каждый вызов можно рассматривать как атомарную операцию. Ты гарантированно застрахован от того, что во время ее вызвова что-то изменится.
Такую фукнцию ты можешь выполнять параллельно или даже автоматически распараллеливать. В отличии от нее фукнция в императивных языках всегда может что-то изменить или на что-то повлиять. Такие фукнции нельзя рассматривать как атомарные операции и в многопоточном окружении их нужно синхронизировать применяя примитивы синхронизации.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
КЛ>кортежи настолько простая вещь, что не надо быть академиком, чтобы рассуждать о ней.
Ага. От того твои заявления выглядят еще более нелепо.
Хочешь я тебя удивлю? Ты используешь кортежи постоянно! Не веришь?
А чем по-твоему иявляются параметры функций?
Это ни что иноге как список фиксированной длинны разнонипных значений передающихся как единая сущность.
С/C++/Java/C# позволяют использовать их только для передачи значений. А Хаскель/ОКамл/Немерле и для возврата.
Согласись, что раз мы ввели ограничение на возврат несколькоих значений с аргументацией "Зачем возрващать несколько значений когда можно вернуть именованную структуру?", то эту же логику можно распространить и на параметры — "Зачем передавать несколько значнений когда можно передать именованную структуру?". Блее того такие языки есть! Хаскель и ОКамл так и поступают! В них фукнция может иметь только один параметр и только одно возвращаемое значение. Функции с множеством параметров у них считаются соедененными (каррированными в терминалогии этих языков). Причем единственным параметром может служить кортеж. Тоже и с возвращаемым значением.
Немерле блее традиционен, но он позволяет передавать кортеж вмесо списка отдельных параметров. Таким образом мы можем результат одной фукнции передать другой не залпом, а не по одному параметру:
def f1() : int * string
{
(1, "!!!")
}
def f2(x : int, y : string) : void
{
WriteLine($"x = $x; y = $y")
}
f2(f1());
// вместо
def (x, y) = f1();
f2(x, y);
Не находишь это красивым?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>В математике все фукнкции чистые. Это значит, что они не имеют побочных эффектов. Взывая чистую фунцию ты можешь быть уверен, что ничего не изменится. Таким образом каждый вызов можно рассматривать как атомарную операцию. Ты гарантированно застрахован от того, что во время ее вызвова что-то изменится.
VD>Такую фукнцию ты можешь выполнять параллельно или даже автоматически распараллеливать. В отличии от нее фукнция в императивных языках всегда может что-то изменить или на что-то повлиять. Такие фукнции нельзя рассматривать как атомарные операции и в многопоточном окружении их нужно синхронизировать применяя примитивы синхронизации.
функции с побочными эффектами удобно называть прцедурами — как раз чтобы не входить в разрез с математикой
далее, "чистоту" ещё называют ссылочной прозрачностью (referential transparency), и это означает, что результат функции зависит только от её аргументов и никак не зависит от состояния внешнего мира. для того, чтобы гарантировать это, *достаточно* запретить ей обращаться к глобальным переменным, вызывать процедуры, сохранять своё состояние в static vars
вот в этом как раз и состоит проблема вызова процедурного кода из функционального, которую ты объявил несуществующей
запретив такие вызовы, мы можем *гарантировать* referential transparency, т.е. теперь это проверяет компилятор. если разрешим — придётся проверять программисту. более того, на самом деле такие вызовы возможны с помощью unsafePerformIO — это и есть тот механизм, который позволяет программисту взять ответственность на себя *явно*
ну а тезнически запрет таких вызовов, заодно с явным описанием плорядка вызова процедур, решается "эстафетной палочкой" — фиктивным значением типа RealWorld, передаваемым от порцедуры к процедуре, и недоступным функциям. т.е. функция не может вызвать процедуру потому, что она такую эстафетную палочку не получает сверху, и не может создать её сама
кроме того, благодаря наличию этой "эстафетной палочки" среди параметров процедуры она тоже становится чистой. просто один из её параметров — это значение realworld, которое прошло через все предыдущие вызовы процедур, так что несмотря на эту чистоту, компилятор не может "соптимизировать" вызов прцедуры — она гарантированно никогда раньше с такой эстафетной палочкой (возвразённой предыдущей вызванной порцедурой) не вызывалась!
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Timur I., Вы писали:
TI>>Здравствуйте! TI>>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
L>Имхо, стоит.
Какие языки из "альтернативных" для общего развития посоветуете?
Здравствуйте, Андрей Хропов, Вы писали:
VD>>4. XQuary/XSLT — как пример языков трансформации данных. АХ>Ну, опять же, это практически мейнстрим (ну или скоро будет (XQuery)). Хотя я считаю, что использовать синтаксис XML для программирования (XSLT) — это извращение . Лучше нормальная языконезависимая модель (типа DOM) преобразований и ее реализация в библиотеках для разных языков.
Типа DOM? Тогда лучше сразу застрелиться.
Из вынесения языка транформации в библиотеку вряд ли что-то хорошее получится кроме ужасного синтаксиса.
Да и зачем? Подходящая модель данных для XML есть, есть язык для работы с ней (XPath), непонятно только зачем было строить синтаксис XSLT на основе XML.
Здравствуйте, lomeo, Вы писали:
VD>>1. C# — классика ООП, компонентность, статическая типизация, обобщенное программирование.
L>Идея ООП чище выражена в Smalltalk, можно поглядеть его.
Добавляй, что это твое мнение. Я считаю Смолток языком с прототипной орканизации. И она мне категорически не нравится. Так что мое мнение — смолток для начального обучения лучше не применять. Он даст отрицальный эффект.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Если ты уже делишь языки на "основные" и "альтернативные" — это уже ошибочная постановка вопроса. Посему предложу тебе другую методику. В начале, пожалуй, математика в объёме первых 3-х курсов любого вуза. Это — минимум. Дальше в некотором роде смесь: системное программирование, формальные языки и построение компиляторов, дискретная математика, основы электроники, вопросы связанные с искусственным интеллектом. Присоединюсь к тем, кто советовал SICP и добавлю сюда ещё дядьку Кнута. Потом — применение тех или иных языков для определённых задач. Ну и в процессе уже определишься, что к чему и почему, и откуда и куда у чего ноги растут.
CU>Ну и ты нас пойми, нас очень интересует не сам список, а _почему_ он именно такой! CU>Или так сильно влом вежливо и без наездов объяснить, почему именно этот язык не включён в список? CU>Или с тебя шапка упадёт/нимб свалится, если ты признаешся, что не знаешь какой-то язык?
мне этот список очень понравился, и я его готов поддержать на все 100. и не только поддержать, но и объяснить его. разные языки программирования поддерживают разные парадигмы. при этом парадигмы не являются полностью взаимоисключающими. основные из них:
чистое (функциональное) vs императивное программирование
процедурный / АТД / ООП / функциональный / логический подход
динамические / статические языки
для того, чтобы изучить все эти подходы, нужно изучать поддерживающие их языки, и разумеется брать наилучших их представителей. теперь смотрим. процедурный и АТД подход стали частью ООП, так что их можно отдельно не изучать. лучшие ООП языки — эйфель (компилируемый) и руби (интерпретируемый). функциональные — схема (динамический, императивный), окамл (компилируемый, императивный, с прикрученным сбоку ООП), хаскел (чистый, компилируемый); логические — пролог (динамический, условно-императивный). немерл — противоположность окалму, это ООП язык с прикрученным императивным FP
если человеку рассказать про парадигмы программирования и дать изучить эти языки, то у него появится гибкость в осмысленрии задачи, в порджумывании алгоритма её решения. даже если писать он будет продолжать на C++
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, FR, Вы писали:
КЛ>[]
FR>>Так нужно и это осмысленные операции, только от бестолковых временных структур это не избавляет. FR>>Те же std::pair, boost::tuple тоже нафиг не нужны?
КЛ>не знаю...ты сам себе противоречишь. Так нужно — но бестолковые структуры...
Нужен результат: например вернуть из функции N (разнотиповых) переменных, есть несколько альтернатив как это сделать, в языке подерживающем туплы, это элементарно просто вернуть тупл. В языке не подерживающем туплы или завести структуру из этих N переменных (единственное предназначение которой только возврат этих переменных) или что еще хуже завести у функции out параметры. Тупл здесь средство упростить и очистить от мусора код и ничего больше.
Здравствуйте, Константин Л., Вы писали:
КЛ>поинт в том, что если ты возвращаешь "бестолковые временные структуры", то значит у тебя метод делает "все сразу и еще кучу вещей", что часто говорит о его избыточности или неправильности. Если же так нужно и это осмысленная операция, то эти "бестолковые временные структуры" должны стать нормальными логическими сущностями и уж тут кортежи нафиг не нужны. Кароче моё мнение, что кортежи — это затычки для костылей, которые мы сами и сажаем.
Как грится, с очевидцами не спорят!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>для того, чтобы изучить все эти подходы, нужно изучать поддерживающие их языки, и разумеется брать наилучших их представителей. теперь смотрим. процедурный и АТД подход стали частью ООП, так что их можно отдельно не изучать. лучшие ООП языки — эйфель (компилируемый) и руби (интерпретируемый). функциональные — схема (динамический, императивный), окамл (компилируемый, императивный, с прикрученным сбоку ООП), хаскел (чистый, компилируемый); логические — пролог (динамический, условно-императивный). немерл — противоположность окалму, это ООП язык с прикрученным императивным FP
Примерно так. Но проблема в том, что у каждого языка есть поклонники и кто-то обязательно захочет, чтобы его любимый язык попал в списко. Но в списке не нужны два, пусть даже приблизительно одинаково хороших ООЯ. И не нужно два статических ФЯ. Список нужно деражать минимальным чтбоы он остался полезным тем кто зохочет въехать во все современные парадигмы. А то что я вижу в данном случае — это попытка впихнуть в этот список все известные языки. Ну, или их популярную часть. Причем кто-то будет считать, что ради его любимого языка нужно исключить другой. Например, включить Смолток и исключить C#. Или вклчить ОКамл и исплючить Хаскель. При некотором обобщении языки ведь действительно похожие.
Объяснять и доказывать каждому почему это так или иначе задача не благодарная. Вот я попытался обяснить свою позицию по поводу C# и Смолток, но фанатикам и слуашать не охота. У них уже установка докапаться до чего получится и завязать флэйм в надеждне на победу каким-то образом. А мне это не нужно. Я не против других списков. Вот толко никто свой так и не представил. Куда как интересно поковыряться в чужом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Хочешь я тебя удивлю? Ты используешь кортежи постоянно! Не веришь?
VD>А чем по-твоему иявляются параметры функций?
VD>Это ни что иноге как список фиксированной длинны разнонипных значений передающихся как единая сущность.
VD>С/C++/Java/C# позволяют использовать их только для передачи значений.
Ага, фрейм стека в C/C++ в перемешку со значениями регистров уже стал кортежем.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
VD>Объяснять и доказывать каждому почему это так или иначе задача не благодарная. Вот я попытался обяснить свою позицию по поводу C# и Смолток,
все возможности *яызка* Смоллток в руби есть. правда, изменилась терминоллогия, и главное — нет той замечательной среды. ведь это же была первая IDE в мире! и до сих пор, как я понимаю, нет ни одной среды, где было бы так легко работать со структурой классов и проверять, что возвратят те или иные методы
C# же, как и Delphi — язык чисто практический, я лично в нём ничего концептуального не вижу. и вообще, на мой взгляд, изучать ФП надо с наиболее теоретичсеких, удобных в программировании, но неэффективных (пролог, хаскел), и далее спускать к более практичным, но сложным в использовании языкам. и заканчивать на C#, яве или чём-то ещё, что будет реально использоваться. языки более низкого уровня, типа C++, изучать необязательно — разве что чтобы понять, как функционирует процессор, да и это начинающему ни к чему
такой подход научит человека мыслить на наиболее высоком возможном уровне — ведь здесь важно, с чего ты начнёшь. если первым яхзыком будет бейсик, то он для человека станет "родным", и дальше все новые концепции будут перекладываться на его "архитектуру" если же начать с наиболее высокоуровневых языков, то человек будет думать об *алгоритме* решения задачи и потом уже, тяжко вздохнув, сооьрадать, как его реализовать на этом ограниченном языке
кроме того, высокоуровневые языки медленней стареют, чем низкоуровневые, поскольку это не языки реального прогнраммирвоания с их сотнями мелких полезных деталей, а концепции в чистом виде (т.е. сами-то языки стареют, но нас в них интересует только ввечно молодая общекоцептуальная часть)
Здравствуйте, Константин Л., Вы писали:
КЛ>как тебе сказать...Неплохо, удобно. Но есть один недостаток — отсутствие имен элементов кортежа в функции, его возвращающей.
Это не есть обязательный признак кортежа. К примеру, в LInQ у кортежей элементы именованные (у них, правда, есть другая проблема).
... << RSDN@Home 1.2.0 alpha rev. 673 on Windows Vista 6.0.6000.0>>
Здравствуйте, Константин Л., Вы писали:
VD>>Перебирать из довольно бессмысленно так как они могут иметь разные типы данных. Хотя в макросах их можно и переберать и даже генерировать. К примеру, параметры методов тоже генерируеются как кортежи.
КЛ>хаха, и что? От этого это становится бесмысленным? Че за бред?
Ну, придумай осмысленную задачу. И вообще, ты же сам сравнивал кортежи со структурами. Тебя не удивляет, что струтуру тоже нельзя перебрать?
Еще интересно почему ты не считашь бредом тот факт, что параметры метода тоже невозможно перебрать (если список фиксирован)?
КЛ>>> А об их отсутствии (точнее о том, что это плохо и они заменяются кортежами.) я уже писал.
VD>>(задумчиво) Да, ты много пишешь...
КЛ>а это к чему? У тебя с этим проблемы? Не читай
Не догадливый?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
BZ>> мимхо, надо изучать разные параддигмы по их чистым представителям, а не язык, где они как-то сбиты вместе.
VD>Ну, мы уже наблюдали как Хаскель сливает Немерлу . VD>Так что не надо этой предвзятости. Немерле позволят писать функционально ни чем не хуже чем Хаскель. И что характерно он так же качественно позволяет писать ОО- и иммеративные программы. Единственное существенное отличие от Хаскеля является то что ленивость в Немерле по умолчанию не используется. Но ее без проблем можно использовать там где надо. Так что все концепции объясняются "на ура".
Если бы не список
, я бы решил, что ты предлагаешь человеку учть *только* "язык на букву N".
ИМХО, язык всегда заточен под определенную парадигму/стиль/как там еще назвать. Если программировать на нем в ключе этой парадигмы — хорошо, если нет — не очень.. Даже у Н есть свой стиль программирования, который ты так рассхваливаешь. Друое дело, что в Н очень малы затраты при программировании в чуждом ему ключе (например, строго императивно). В той же Жаве можно программировать функционально, но синтаксический оверхед (с) при этом будет огромным. Т.о. Жава подталкивает программиста к Жава-ООП(использую такое словосочетание, потому что меньше всего хочу спорить о терминах), Схема — к ФП и тд. Каждый язык разный и, ИМХО, фишки определенных подходов лучше показывать на языках, которые ориентированы на определенную парадигму.. Во всяком случае, я жалею, что у меня в институте учили Pascal, Delphi и С++ (поубивать бы за такое однобокое развитие! Я на пятом курсе института только узнал, что код программы — это не обязательно последовательность инструкций). Думаю, если бы мне преподавали только Немерле, я бы тоже жалел.. Да и, в конце концов, разные языки учить — это фан
Здравствуйте, AndrewVK, Вы писали:
L>>Привел, но видимо сам их не прочитал. Вряд ли Влад имел в виду одно из течений в протестантизме.
AVK>Читал внимательно?
Осталось выяснить связь между моралью и стремлением к "чистоте" языка.
КЛ>>так вот если бы кортеж можно было перебрать, то это было бы знач. преимущество над структурой. Иногда очень нужно пребрать поля какой-либо структуры.
BZ>"кортеж с перебором" называется полиморфным списком. в языках типа явы он будет иметь тип что-то типа List<Object>
не знаю как он там называется, но то что он не есть Java::List<Object> (если я все правильно понял) — это точно. В том то и прокол, чтобы сохранить информацию о типе.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>>>"кортеж с перебором" называется полиморфным списком. в языках типа явы он будет иметь тип что-то типа List<Object>
КЛ>>не знаю как он там называется, но то что он не есть Java::List<Object> (если я все правильно понял) — это точно. В том то и прокол, чтобы сохранить информацию о типе.
BZ>в static языках за это отвечает reflection
я тебе про Фому, ты мне про Ерёму. Кортеж с разнотипными элементами отличается от списка однотипных объектов, пусть даже полиморфных. Равзе разница не очевидна?
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>>>"кортеж с перебором" называется полиморфным списком. в языках типа явы он будет иметь тип что-то типа List<Object>
КЛ>>>не знаю как он там называется, но то что он не есть Java::List<Object> (если я все правильно понял) — это точно. В том то и прокол, чтобы сохранить информацию о типе.
BZ>>в static языках за это отвечает reflection
КЛ>я тебе про Фому, ты мне про Ерёму. Кортеж с разнотипными элементами отличается от списка однотипных объектов, пусть даже полиморфных. Равзе разница не очевидна?
Здравствуйте, Timur I., Вы писали:
TI>Здравствуйте! TI>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
Можешь глянуть также Форт. Нестандартный язык. Не похожий ни на один из тех что я изучал ранее.
Очень помог мне посмотреть с "другой стороны" на программирование.
На сайте в списке литературы есть книжица:
"Способ мышления — ФОРТ. Язык и философия для решения задач." (c) Лео Броуди.
Даже если не будешь использовать сам Форт, то советую ее прочитать, помогает правильно мыслить при написании программ.
Здравствуйте, EvilChild, Вы писали:
EC>Т.е. когда мы возвращаем экземпляр анонимного типа, компилятор молчаливо создаёт в метаданных новый тип и это дело можно спокойно юзать в публичных интерфейсах сборки? Имена наверное стрёмные? Как у перечислителей, что C# компилятор создаёт? А если мы из 2х методов возвращаем структурно эквивалентные типы он их сведёт к одному в метаданных?
Эти типы представляют из себя буквально то, что я написал. Т.е. это просто generic типы, которых тупо набито в библиотеки поддержки компилятора примерно до 20 штук. Соотвественно, из других .NET языков они так и будут видны. Например, в Н:
void Bar()
{
Tuple<string,int> tp = Foo();
string x = tp.field0;
int y = tp.field1;
}
В самом Н для них сделана специальная, очень удобная поддержка, которая, естественно, не доступна из C#. Но, тем не менее, использовать сами типы из других языков вполне возможно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, EvilChild, Вы писали:
EC>Вижу, это я протупил. Тогда действительно странно почему разработчикам C# это не сделать.
Потому что дизайнеры C# 3.0 решили сделать именованные поля у неименованных типов. Мол это привычнее обывателям и больше защищает от ошибок (ведь в кортеже можно легко перепутать значения местами, если они имеют один тип). Но такой тип уже дженериком не опишишь. Компилятору приходится каждый раз порождать новый (скрытый) класс. Ну, а так как разные библиотеки порождают разные (физически) классы, то они не совместимы. Далее думаю ясно.
EC>Я правильно понимаю, что если мы воспользовались этой фичей, то мы попадаем на деплоймент библиотеки поддержки?
Правильно. Только C# 3.0 тоже вынужден ввести новую библиотеку которую прийдется поставлять отдельно. Так что это не проблема для разработчиков этого языка.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Java2, Вы писали:
TI>>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
J>Друг, здесь мнений много, но послушай и моё. С помощью таких вещей как Java или C# уже можно зарабатывать миллионы долларов.
Миллионы долларов проще заработать при помощи нефти/банков/героина, etc. А вот с Java/C# заработать миллионы крайне трудно. Если только самому не основать мегакорпорацию, в которой мартышки будут за ломоть хлеба писать на Java/C#
J>Мой тебе совет: заработай их, а потом решай, нужно тебе что-то или нет, т.е. отталкивайся от цели к средствам, а не от средств в поисках цели. Жинь коротка, а дни лукавы и обманчивы, стоит ли её тратить на все языки мира или лучше это время подарить своей семье?
Иногда нужно уделить своё время самосовершенствованию. Хотя бы для того, чтобы в будущем заработать больше денег за меньшее время, и подарить сэкономленное время (и деньги) семье. В этом вопросе поможет только здравый смысл. Главное — не ударяться в крайности.
Нельзя "лучше изучить" Java/C#. Можно только стать лучшим специалистом. А для этого, в том числе, нужно и расширить кругозор. Причём это касается не только языков, и даже не только программирования.
Здравствуйте, VladD2, Вы писали:
VD>А, ну, это многое обясняет. Я уже понял, что если слышишь слово "контракт" то сейчас начнут обосновывать что-то страшеное.
Демагогия.
VD>Если серьезно, то я не понял причем тут реализация? Мы говорим о введении в язык типа данных который невозможнона этом языке описать (выразить).
Анонимный тип это не новый тип данных, этосинтаксический сахар для создания класса.
VD> То есть компилятор этот тип может вывести из использования, но программист его поисать не в силах.
В случае, когда контракт отделен от реализации, мы не можем его вывести, потому что вывести можно только из реализации.
VD>Опять не понял причем тут кривое проектрование кокретной библиотеки.
См. выше.
AVK>>Так он уже введен, зачем еще один вводить?
VD>Где это они введены?
Еще раз. Если у нас уже есть явный класс, вводить еще один или описывать другой анонимный уже не нужно. Вот и вся мысль.
VD> У меня каждый запрос может порождать отдельный класс.
А может и не порождать. Если запрос выдается наружу, и контракт этой наружи уже описан, то кортежи не нужны. А вот вопрос генерации кортежа по контракту и генерации контракта по реализации это уже совсем другой вопрос.
Тут, в принципе, у меня есть две точки зрения. Первая, это мое мнение как, ну, скажем, практикующего архитекта. С этой стороны, как мне кажется, никакая зависимость контракта от реализации (а именно к такой зависимости приведет вывод типа кортежа на основании внутренности метода) не является приемлемой.
Вторая, это моя оценка такой фичи с точки зрения абстрактной "тотально агрессии с Марса". При таком раскладе я, наверное, вижу полезность кортежей вне внутренности метода. Но надо понимать, что, при сохранении собственно LInQ в языке, такие кортежи обязательно приведут к существенной ломке рантайма, прежде всего к появлению first class сущности. Решение вроде Nemerle ввиде заранее объявленных в библиотеке компиляторов набора туплов не прокатывает, потому что LInQ нормально жить без именованных элементов кортежа не может. Вопрос же изменения рантайма лежит за рамками компетенции создателей языка и обсуждать его надо именно в маркетологическом ракурсе.
VD> Точнее конечно кортеж. Или я буду вынужден делать классы заведомо избыточные
Насчет избыточности тоже не все так просто. К примеру, разметка для контракта сервисов WCF требует (при использовании родного для WCF форматтера) наличия на типах данных контракта атрибутов DataContract/DataMember. Будем вносить в синтаксис анонимных типов атрибутивную разметку?
AVK>>Он для другого сделан.
VD>Я в курсе. Еще мама учила не делать уродов ради частных случаев, а пытаться делать гормоничный дизайн. Вот этого я и не вижу. Причем не вижу причины зачем так делать.
То, что ты не видишь, еще не значит что их нет.
AVK>>Он не является кортежом в том смысле, который ты ему присвоил.
VD>Точнее будет сказать в том смысле в ктором его принято употреблять в сообществе функциоальных программистов.
У нас здесь не сообщество функциональных программистов.
VD>Он вообще-то из математики (реаляционной алгебры).
Совершенно верно.
VD> Вот только там он имеет тип и его можно описать. Даже в БД записи можно описать (хотя и не всегда чисто). А тут получается тип есть, а описать его нельзя.
Что такое в твоем понимании "описать"? И, кстати, в SQL DML кортеж можно только вывести. Частичное исключение составляет только CTE, да и то, типы элементов кортежа там указать нельзя, можно только имена.
AVK>> И анонимный тип в шарпе это тоже кортеж, поскольку является как раз той сущностью, которая соответствует кортежу в источнике данных.
VD>Не совсем.
Совсем.
VD> Точнее кострированный.
Нет такого понятия в математике.
AVK>>Именно он и есть. То, что хочешь ты с текущей идеологией шарпа несовместимо.
В следующем предложении обосновано. Ты для начала хотя бы абзац прочитывай целиком, а потом уж отвечай.
AVK>> При разрешении анонимных типов нужно прежде всего разрешать вывод типов по последующему использованию и разрешение вывода в декларациях класса, а не только внутри метода.
VD>С кагого боку?
А как ты выведешь типы?
VD> Нужна возможность описать тип, а так же чтобы рантайм считал все типы с одинаковым описанием одинаковыми. И все!
Такая возможность уже есть. Класс называется. Если ты скажешь, что его описание довольно избыточно, то я с тобой соглашусь. Но вопрос введения краткого синтаксиса (но с указанием типов!) описания класса это совсем другой вопрос. Вопрос совместимости разных описаний ввиде duck typing это третий вопрос.
AVK>>Теперь что касается изменений фреймворка. Я тебе это уже говорил, но повторю — все не так просто, как ты думаешь.
VD>На что я тебе отвечал, что справился бы за неделю сам лично.
А, ну ну. Значит МС не умеет софт писать.
AVK>> Это прежде всего промышленное программирование со своими заскоками.
VD>О! Оставл эти магические базворды для кого-то с более обвисшими ушами. VD>Меня больше интересуют доводы и файты.
Ну а ты сам включи голову и подумай. Факты такие:
1) О LInQ было публично объявлено в сентябре 2005. При этом на тот момент полагалось, что он выйдет летом 2006 ввиде отдельного продукта, не завязанного ни на рантайм, ни на студию.
2) Framework 3.0 вышел со старым рантаймом. Но при этом маркетологи вынуждены обозвать его именно 3.0, а не WinFX, как планировалось ранее.
3) Рантайм 2.0 интегрирован в Висту.
4) Летом 2006 было объявлено о привязке линка к Оркасу.
5) Оркас на тот момент планировался к выходу сразу после висты, т.е. в конце 2006 года.
6) В настоящий момент дата предполагаемого релиза Оркаса — конец 2007.
7) Дизайн C# 3.0 был зафиксирован в середине апреля 2006 (надеюсь, сей факт под NDA не попадает)
8) CLR team ничего не анонсировал с момента выпуска 2.0, но его никто не распускал
Свои логические рассуждения на базе этих фактов я приводить не буду. Из принципа.
VD>Как я понял LINQ — это не просто проект команды C#.
Неверно ты понял. Это личная инициатива Хейлсберга и Коробкина.
VD> Да и средства ФП в Шарпе и Васике появляются точно не только для LINQ.
Но как побочный продукт LInQ. Конечной целью был именно он. Об этом говорил в том числе и Хейлсберг.
VD> Так что уж могли бы они как-нибудь между собой договориться.
Видимо не могли. Видимо маркетинг важнее.
VD> А если у них там есть капризные менеджеры которые как взбалмошные барашни заявляют "неть! не дадим кромсать рантайм", то это уже их личные проблемы.
Так никто их проблемы тебе и не навязывает.
AVK>>Поздравляю. Только проблемы это не отменяет. Один черт ты эти abc каждый раз по новой объявляешь.
VD>Хм. Дык в запросе это просто перечесление имен полей кторые я возращаю.
Имена каждый раз нужно переобъявлять. Т.е., по сути, информация из семантики определения функции (имена элементов кортежей) перекочевывает в место использования этой функции. Вот простой пример из SQL:
SELECT * FROM MyTable
Здесь, в запросе, я нигде не указал количество, типы и имена элементов, но при этом результирующий рекордсет будет иметь вполне осмысленные имена колонок. ИМХО, это более естественно, чем вариант немерле.
VD> Синтаксический сахар вроде LINQ-а может их сам задавать выводя из имен полей или из конструкций вроде SQL-ых "as".
Здесь я обсуждал вариант Nemerle, а не гипотетический LInQ. То, что можно сделать лучше вообще, я как бы и не спорю.
VD>Тем хуже для них.
Ну да.
VD>Хотя судя по многозначительным словам из приведенной тут статьи "сумашедшего ученого" — "это остается предметом для дальнейших исследований"
Боюсь, слова этого "сумашедшего ученого" имеют исключительно рекомендательный характер. Те ребята, которые собственно решения принимают, говорят несколько иное. Хотя конечно все течет, все изменяется, и что будет через несколько лет вряд ли кто предскажет.
VD> Ведь если есть шанс повлиять на плохое решение, то его обязательно надо использовать.
Есть ли он в ситуации, когда дизайн языка утвержден? Может и есть, если вспомнить про nullable типы.
VD> Уверен, что мы не одни кто понимает, что такая половинчатасть — это плохо.
Здравствуйте, IT, Вы писали:
IT>А в чём проблема создать внутренний паблик класс и выставить наружу его? Нужно только подумать о наименовании.
А дальше? Как заставить tuple1.GetType() == tuple2.GetType() вернуть true, если tuple1 и tuple2 совместимы по сигнатуре, но при этом физически это два разных класса? Тут хак в рантайме нужен типа делегатов, бо это duck typing в чистом виде. Ну или работать через TransparentProxy, но производительность такого решения ты наверное представляешь.
Спасибо. Да, я и без пдсказаок заметл, что твои слова про контракты — это демагогия.
[Много неубедительной защиты кривых решений поскипаны]
VD>> Ведь если есть шанс повлиять на плохое решение, то его обязательно надо использовать.
AVK>Есть ли он в ситуации, когда дизайн языка утвержден?
Всегда самая удобная позиция — это сидеть на пятой точке и ничего не делать. Потом всегда можно сказать "А что я мог сделать?".
AVK>Может и есть, если вспомнить про nullable типы.
Темболее надо попробовать воздействовать. Сказать, что мол это мнение всего комьюнити РСДН и т.п.
VD>> Уверен, что мы не одни кто понимает, что такая половинчатасть — это плохо.
AVK>Да понимают они это. 100%.
Значит лишний пинок под зад может сдвинуть дело в нужном направлении.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Hi IT
AV>>В этом отношении мне нравиться как сделано в Питоне
IT>Именно об этом и речть. Только для одной переменной это выглядит так:
IT>def (_, b) = Fun();
Спасибо. Буду знать. Хотя еще не скоро будет возможность даже попробовать Nemerle.
P.S. Правда, слишком рьяно идет здесь реклама Nemerle. Даже отбивает желание смотреть на это. Но я сволочь любознательная — при возможности попробую посмотреть.
Hi VladD2
AV>>Посмотреть-то посмотрю как-нибудь. Но к моим текущим задачам его никак не приложить будет. Поэтому только в свободное время (которого катастрофически не хватает). К моим текущим задачам скорее приложим OCaml
V>Ты бы все же сначала поглядел о чем рассуждаешь. А то забавно получается. Nemerle по сути клон O'Caml с С-подобным синтаксисом, но O'Caml тебе подходит, а Nemerle нет. Парадокс одноако.
Облом подкрался незаметно. Ты пытаешься судить о моих потребностях не зная задач, которые мне необходимо решать сейчас и в ближайшее будущее. Дам краткое описание проекта, а ты скажи мне каким боком мне сюда прикрутить Nemerle. ОК?
Краткая постановка задачи: Необходимо разработать Application Server. Все это должно работать на кучу платформ (на данный момент 5. Винда считается одной платформой). Приложения, которые крутяться на нем должны собираться из разных компонентов (то есть фактически надо реализовать на свой лад COM). Компонеты должны могут писаться на разных языках (в списке есть OCaml, но нет Nemerle). Там еще куча ограничений. Но они тебе и большинству будут не интересны, да и NDA есть.
Так какой язык стоит мне смотреть в первую очередь учитывая периодический цейтнот?
Здравствуйте, awson, Вы писали:
A>Вы с какой Луны свалились? Сегодня говорить о системе Хиндли-Милнера в применении к Хаскеллу — все равно, что уподоблять, к примеру, Лаурин-Клемент 1904 года Макларену MP4-21.
Только разница в том, что по твоей аналогии Макларен MP4-21 будет еле ползать и будет перегружен бесполезными для болида f1 функциями — 7 сиденьями, возможность использования в качестве кареты скорой помощи и интегрированную систему противоракетной обороны. Но при этом все равно обладать теми самыми ограничениями, о которых говорит VladD2.
A>Недавно GHC был переведен на system Fc, что позволило реализовать еще и type-indexed data types и устаканить все сложные взаимодействия между упомянутыми возможностями.
По-моему это просто небольшие, инкрементальные изменения. Причем непонятно чего и для кого. Я не так давно смотрел данные опросов — пользователям GHC это все просто не нужно. То что им нужно, разработчикам GHC улучшать не особо и интересно — они же занимаются чистой наукой.
VD>>Ну, мы уже наблюдали как Хаскель сливает Немерлу . A>Немерл ... мухаха. Детский лепет.
“First they ignore you, then they laugh at you, then they fight you, then you win.”
Здравствуйте, VladD2, Вы писали:
VD>>>По сути же... проблема в том, что классы в разных сборках должны быть совместимы. IT>>Я понимаю проблему. Вопрос, проблема ли это и нужно ли её решать. VD>В текущем варианте имеется просто недоделанность приводящая к тому, что анонимные типы мало на что годны и применяются в основном только для LINQ-запросов.
Мой вопрос был про нужность обсуждаемой фичи. Скажем так, такая фича — must have, очень полезная фича, nice to have, а шо это такое. Мой вопрос, если это последние два варианта, то надо ли было вообще затеивать это всё.
VD>Если поступить как предлагаешь ты, то будет уже явный косякт который уже потом будет невозможно исправить не внося ломающие изменения.
Я предлагаю не явный косяк, я предлагаю точку, от которой можно начать обсуждение. Уверен, что в MS этот вопрос обсуждался и эту точку тоже проходили, но вот чем всё законичилось было бы интересно выведать у AVK, прикрывающегося NDA.
VD>Правильным решением было бы внести измеения в рантайм. Там дело вто на день.
Опять же вопрос. Стоит ли эта фича того, что бы из-за неё менять рантайм?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, ambel-vlad, Вы писали:
V>>Ты бы все же сначала поглядел о чем рассуждаешь. А то забавно получается. Nemerle по сути клон O'Caml с С-подобным синтаксисом, но O'Caml тебе подходит, а Nemerle нет. Парадокс одноако.
AV>Облом подкрался незаметно. Ты пытаешься судить о моих потребностях не зная задач, которые мне необходимо решать сейчас и в ближайшее будущее.
Я сужу не о твоем проекте, а алогизмах в твоих суждениях.
AV> Дам краткое описание проекта, а ты скажи мне каким боком мне сюда прикрутить Nemerle. ОК?
Не вопрос.
AV>Краткая постановка задачи: Необходимо разработать Application Server. Все это должно работать на кучу платформ (на данный момент 5. Винда считается одной платформой).
На остальных Моно работает?
AV> Приложения, которые крутяться на нем должны собираться из разных компонентов (то есть фактически надо реализовать на свой лад COM).
Ага. Если пользоваться С++, то еще не то надо реалзовывать. Немерле же бегает на базе CLI которое проектировалось как COM 2.0.
AV> Компонеты должны могут писаться на разных языках (в списке есть OCaml, но нет Nemerle).
CLI бегает море языков. В том числе и очень близкий к OCaml язык F# (клон с некоторыми расширениями под дотнет).
AV>Там еще куча ограничений. Но они тебе и большинству будут не интересны, да и NDA есть.
Значит их опускаем.
AV>Так какой язык стоит мне смотреть в первую очередь учитывая периодический цейтнот?
Зависит от ответа на вопрос "Поддерживается ли Моно на остальных четрых платформах?". Если ответ — да, то даже думать не чего. Немерле однозначно лучший выбор. Проблемы будут искючительно организационного характера (нужно учить людей программировать на нем, и учить дотенту).
Единственное что я тебе точно могу скзать — это то, что С++ это неимоврено плохой вобор для вашего проекта. И того кто принял такое решение надо банально гнать с работы.
Для таких проектов выбор может идти между дотнетом и Явой (как технологии, а не как языка, Ява тоже поддерживает массу языков).
Немерле помог бы тут тем, что продоставил мощьный язык для реализации непримитивной логики.
Что касается O'Caml... Он практически не имеет динамических возможностей. Так что поддержка компонентношго подхода на нем выльется в сущий ад. В этом языке даже повышающее приведение типов отсуствует так как оно может привести к исключению во время исполнения, а в дизайн языка пытались заложить чтобы их не было.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Vermicious Knid, Вы писали:
VK>Но при этом все равно обладать теми самыми ограничениями, о которых говорит VladD2.
Какими, черт подери, ограничаниями? Написано же — typeclasses. В том виде, как они поддерживаются в GHC (multiparameter typeclasses + fundeps), они не просто обеспечивают перегрузку, а вообще позволяют программировать внутри системы типов.
Здравствуйте, ambel-vlad, Вы писали:
AV>Бедный, богатый, какая разница в данном случае. Тут считать надо. Насчет стоимости ОС можно согласиться. А вот как насчет переучивания работников на какой-то язык? И с учетом того, что работники время от времени меняются? Может лучше предоставить возможность им использовать то, что знают?
Да это аргумент. Но тогда надо на Яве писать. Ява програмистов много и они относительно дешевы. Плюс полная переносимость и надежность. Но С++ для сервера приложений — это точно перебор. Это себе только топ-компании вроде IBM/MS безболезненно могут позволить.
AV>Давай опустим домыслы. На анализ существующих вариантов заказчиком было потрачено очень много времени и денег. И раз они пришли к такому мнению, значит оно им дешевле.
Решать конечно им. Но я бы назвал такое выбор очень рискованным.
AV>Кстати, ты так и не ответил, почему в моей ситуации изучение Nemerle предпочтительнее изучения OCaml?
В твоей ситуации тебе надо Яву учить. С точки же зрения просто развития как программиста Nemerle — это OCaml++. Потому вообще довольно бессмысленно учить OCaml если можно выучить Nemerle. Это и проще и позновательнее. Причем после Nemerle выучить OCaml уже довольно просто, так как остается только въехать в его кудрявые конструкции. Семантика же очень близка.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>В контексте глобального вывода типов перегрузка "в чистом виде" невозможна в принципе.
VD>Это не соотвествует действительности. Сложность алгоритма получается высокой. Но на практике все будет работать. Собствнно это как раз описано в дисере Москаля на www.nemerle.org
Здравствуйте, awson, Вы писали:
A>В контексте глобального вывода типов перегрузка "в чистом виде" невозможна в принципе.
Ну, так а я о чём!
Насчёт остального — от вывода типов отказываться не собираюсь В общем то, спорить не о чем, я всего лишь хотел сказать, что (удобной) перегрузки в Хаскеле нет. А с чем это связано я представляю.
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, awson, Вы писали:
A>>В контексте глобального вывода типов перегрузка "в чистом виде" невозможна в принципе.
L>Ну, так а я о чём!
L>Насчёт остального — от вывода типов отказываться не собираюсь В общем то, спорить не о чем, я всего лишь хотел сказать, что (удобной) перегрузки в Хаскеле нет. А с чем это связано я представляю.
Я выше уже написал. Перегрузка несовместима с глобальным выводом по определению, т.е. тривиально.
Hi VladD2
AV>>Бедный, богатый, какая разница в данном случае. Тут считать надо. Насчет стоимости ОС можно согласиться. А вот как насчет переучивания работников на какой-то язык? И с учетом того, что работники время от времени меняются? Может лучше предоставить возможность им использовать то, что знают?
V>Да это аргумент. Но тогда надо на Яве писать. Ява програмистов много и они относительно дешевы.
Нда. А мужики-то о java и не знали. Не так уж много у них спецов по java есть в штате. Что делать с остальными? Переучивать? Увольнять и набирать других?
V>Плюс полная переносимость и надежность.
Это далеко не самые определяющие факторы были. Да и насчет полной переносимости и надежности тоже преувеличение. Да, по сравнению с C/C++ там сложнее что-то перемудрить, но хватает мест где можно наворотить.
AV>>Давай опустим домыслы. На анализ существующих вариантов заказчиком было потрачено очень много времени и денег. И раз они пришли к такому мнению, значит оно им дешевле.
V>Решать конечно им. Но я бы назвал такое выбор очень рискованным.
Риск оправдался. Комплекс уже работает. Тем более, что если отсечь откровенно опасные моменты, то и на C++ можно относительно безопасно писать.
AV>>Кстати, ты так и не ответил, почему в моей ситуации изучение Nemerle предпочтительнее изучения OCaml?
V>В твоей ситуации тебе надо Яву учить.
Вот уж что-что, а Java учить не надо. Работал я с ней. Ну не лежит душа у меня к ней.
V>С точки же зрения просто развития как программиста Nemerle — это OCaml++. Потому вообще довольно бессмысленно учить OCaml если можно выучить Nemerle. Это и проще и позновательнее. Причем после Nemerle выучить OCaml уже довольно просто, так как остается только въехать в его кудрявые конструкции. Семантика же очень близка.
Ну выучу я Nemerle. И где мне его применить сейчас? Ну нету у меня пока задач под него. И не предвидиться.
Далее, выучил я немерле. А мне надо OCaml сейчас для работы. Дальше сел учить OCaml. Тебе не кажеться, что это удаление гланд паяльной лампой через одно отверстие?
Кстати, времени свободного не так уж и много есть. И я предпочитаю его тратить на жену, дочь и друзей. В крайнем случае, если на меня нашла блажь и мне охота что-то изучить, то я предпочитаю изучать то, что я так или иначе могу применить. Даже если не сейчас, то в обозримом будущем. А не через N лет.
Как видишь, Nemerle ничего не даст мне в данный момент. В отличии от OCaml.
Здравствуйте, Vermicious Knid, Вы писали:
VK>Когда мы считаем foobar("a***n — дурилка картонная!"), то мы же не просто выбрасываем это значение, так? А например делаем вот что: (foobar("a***n — дурилка картонная")-3). Из этого компилятор делает вывод, что тип foobar должен быть string->int.
А если мы делаем print(foobar("Громозека — грубиян и невоспитанный тип"))?
Здравствуйте, lomeo, Вы писали:
L>А если мы делаем print(foobar("Громозека — грубиян и невоспитанный тип"))?
Тут вообще все банально. Если тип можно определить в принципе, то он выводится. Если нет, компилятор говорит, что у мего неоднозначность.
Вот только это никак не завист от того на каком уровне делается вывод типов.
Кстати, еще надо понимать, что Немерловый алгоритм вывода типов не выводит полиморфные типы. По этому ему несколько проще.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
VD>>Самое смешное, что лично я хотел бы чтобы ты был прав, так как не вижу смысла в выводе типов выше тел методов, L>Ты не пробовал, вот и не видишь. VD>>но вижу приемущества от такого ограничения. L>Ага! Так это, значит, всё таки ограничение?
а этот на нее ссылается. Я понимаю, когда защищают сильные стороны любимого дитяти, понимая, что для этого приходится жертвовать чем-то еще. Но наезжать на Хаскелл с точки зрения type machinery, приводя в пример немерле, (и упоминая, что "Немерловый алгоритм вывода типов не выводит полиморфные типы") — это за гранью.
Пойми наконец то одну вещь. Всё, что ты здесь написал относительно моих мотивов — твои домыслы. Спрашивая, почему в Немерле есть такое ограничение я не имел в виду хорошо-плохо — это ты так воспринял. Мне были интересны причины такого выбора.
И вообще, может хватит рассматривать меня при ответе на вопрос, ко мне не относящийся? Это и называется между прочим переходом на личности. Не смог ответить — не надо, ответит другой. WolfHound же ответил, я получил интересующую меня информацию. Сказал "спасибо" в оценках. С тобой же получился бестолковый флейм, в котором меня же и обвиняют в неконструктивности.
OCTAGRAM wrote: > * /Thread management by the system via > await on pre-condition for continuation > (transparently on single or multiple processors)/
Та же самая Ява с немного большим числом примитивов. Ничего это не
решает, нужно что-то типа Эрланга.
OCTAGRAM wrote: > C>Та же самая Ява с немного большим числом примитивов. Ничего это не > C>решает, нужно что-то типа Эрланга. > Ну тогда Ада — проверенный временем язык, что касается многозадачного > программирования. > Активные и пассивные мониторы, механизм рандеву, оператор select...
Та же самая Ява, вид в профиль. Изменяя набор примитивов синхронизации
добиться чего-то революционного не получится. В конце концов, они все
сводятся к мьютексу.
Если требуется использовать операции синхронизации — это УЖЕ источник
для трудноуловимых ошибок.
Здравствуйте, lomeo, Вы писали:
L>Пойми наконец то одну вещь. Всё, что ты здесь написал относительно моих мотивов — твои домыслы.
Агащазблин. (с)
L>Спрашивая, почему в Немерле есть такое ограничение я не имел в виду хорошо-плохо — это ты так воспринял. Мне были интересны причины такого выбора.
Дык что же ты тогда выясняешь "зачем сделно такое ограничение?" и кричишь, что это плохо?
Причины выбора тебе объяснили, но ты даже слушать не захотел о них. Ты же умудрился сказать, что тебе так о них и не скзали и попер снова выяснять "зачем вели ограничение?".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ambel-vlad, Вы писали:
AV>На изучение сначала Nemerle, а потом OCaml (причем мне все таки надо не поверхностное знание) мне понадобиться больше времени, чем на изучение только OCaml. Согласен?
Нет. Причем катигорически. Но ты помжешь попробвать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте!
Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
01.02.07 23:57: Перенесено модератором из 'О работе' — Хитрик Денис
Здравствуйте, Timur I., Вы писали:
TI>Здравствуйте! TI>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
Здравствуйте, VladD2, Вы писали:
VD>1. C# — классика ООП, компонентность, статическая типизация, обобщенное программирование.
+Java.
VD>4. XQuary/XSLT — как пример языков трансформации данных.
+более частные спецификации: XSL-FO, SVG, X-Path и т.п.
VD>8. SQL — пример декларативного языка обраобтки данных.
+объектные подходы в БД
И самое главное, все перечисленное является все же универсальными инструментами, а есть специализированные платформы (+ЯП), к примеру, M-язык в Matlab.
Здравствуйте, c-smile, Вы писали:
TI>>>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
ЗХ>>Однозначно последнее.
CS>Присоединяюсь. Ибо если такой вопрос к публике (а не к себе самому) возникает в принципе то не надо. CS>Вообще языки *изучать* не надо. Желание на посмотреть чего-то придет само (если придет).
Во!
А то я уж было забоялся, что придется долго и нудно объяснять свою экстремистскую выходку
VladD2 wrote: > Мой список языков котрый может расширить кругозор: > 1. C# — классика ООП, компонентность, статическая типизация, обобщенное > программирование. > 2. Руби — классика скриптов, динамика, гибкость.
А ещё можно посмотреть на shell (желательно zsh, в котором некоторые
грабли и странности убраны), чтобы увидеть, как раньше выглядел
зарождающийся компонентный подход.
> 3. Хаскель — функциональный подход, вывод типов, красивая идея классов
Более точно — чистый функциональный подход. Обратить внимание, как
изысканно преодолевается требование чистой функциональности... > типов (похожая на интерфейсы в C#, но которые можно подключать к уже > имеющися типам), ленивое исполнение. > 4. XQuary/XSLT — как пример языков трансформации данных. > 5. Схема — как пример языка без синтаксиса и мощи макросов.
Ну почему в русском языке нет нормальных синтаксических скобок... Я-то
знаю, что "без" относится только к синтаксису, но просто прочитав
предложение, этого не понять.
Кстати, если учить Схему ради кругозора, стоит обратить внимание на
continuations и то, что с их помощью делают. Также вокруг Схемы крутится
много функционального подхода в умеренной форме. С другой стороны, есть
Common Lisp, с большей библиотекой, объектной системой (исходно
написанной на макросах) и даже с шансами скомпилировать. Можно
посмотреть, только не надо пытаться посмотреть в нём всё.
> 6. Рад, что даждались ожидаемого. Правильно немерле как квинтесенция > всего перечисленного выше.
Хочется добавить — и пример их загона в русло максимально практичного
использования. Можно посмотреть на Схему или Lisp, на макросы, и найти
те действия, которое на Nemerle надо делать сложнее — посмотреть, для
чего так сделано. Можно сравнить вывод типов с Haskell, убедиться, что
типы надо указывать чаще — посмотреть ради чего.
> 7. Пролог, как демонстрация красивой идеи логического программирования > практически бесполезной на практике.
Возможно, это связано с мощностями...
> 8. SQL — пример декларативного языка обработки данных. > 9. Регулярные выражения и Перл, как пример того что и на системах > фирования можно писать программы.
Системах чего? Perl — скорее, для понимания того, как написать
программу, которую нельзя читать, и как написать программу, которую
можно читать как текст (речь не про комментарии), но не как программу.
VD>7. Пролог, как демонстрация красивой идеии логического программирования практичски бесполеной на прктие.
Не сказал бы, что совсем уж бесполезной. У меня был опыт реализации бизнес-логики для информационной системы как раз на Прологе. И конструкция эта до сих пор нормально работает. В коммерческой, кстати, организации.
А польза от всяких "альтернативных" языков действительно большая, поскольку учишься смотреть на проблему с такого угла, с какого и в голову бы раньше не пришло.
Здравствуйте, VladD2, Вы писали:
VD>7. Пролог, как демонстрация красивой идеии логического программирования практичски бесполеной на прктие.
Кстати, прологоподбные языки замечательно используются для описания бизнес-логики для запутаных случаев.
Кодт wrote: > VD>9. Регулярные выражения и Перл, как пример того что и на системах > фирования можно писать программы. > > В качестве систем шифрования лучше выбирать J или K.
А вот не всегда.. У J очень жёсткий синтаксис, да и семантика
последовательная. Единственная тонкость — краткие имена в стандартной
библиотеке (а для единства стиля — и в коде) и непривычность
синтаксических решений. Первое можно имитировать и в Perl, второе
автоматически можно преобразовать в любой функциональный язык, возможно,
дописав небольшую понятную библиотеку для. Причём не так много и надо
(если не думать про производительность и всю ту часть стандартной
библиотеки, что на J, тупо конвертировать). А вот с Perl трюк может не
пройти... Он большой, состоит из граблей и всё связано.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Timur I., Вы писали:
TI>>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
VD>Мой список языков котрый может расширить кругозор:
Тут говорили про альтернативные языки
VD>1. C# — классика ООП, компонентность, статическая типизация, обобщенное программирование.
Ну это мейнстрим. Тут все равно что его, что Java. Это и так все знают.
VD>2. Руби — классика скриптов, динамика, гибкость.
Я бы не сказал, что это классика, классика скриптов — Bourne Shell . Но опять же BASh — это мейнстрим в Linux.
VD>3. Хаскель — функциональный подход, вывод типов, красивая идея классов типов (похожая на интерфейсы в C#, но которые можно подключать к уже имеющися типам), ленивое исполнение.
+1
VD>4. XQuary/XSLT — как пример языков трансформации данных.
Ну, опять же, это практически мейнстрим (ну или скоро будет (XQuery)). Хотя я считаю, что использовать синтаксис XML для программирования (XSLT) — это извращение . Лучше нормальная языконезависимая модель (типа DOM) преобразований и ее реализация в библиотеках для разных языков.
VD>5. Схема — как пример языка без синтаксиса и мощи макросов.
+1, Хотя можно и Common Lisp, правда он больше, зато более практичен.
VD>6. Рад, что даждались ожидаемого. Правильно немерле как квинтесенция свсего перечисленного выше.
+1
VD>7. Пролог, как демонстрация красивой идеии логического программирования практичски бесполеной на прктие.
Полезной, полезной. На нем делаются вполне практические коммерческие системы. Правда в России это мало заметно.
VD>8. SQL — пример декларативного языка обраобтки данных.
Опять же, это мейнстрим который все знают.
VD>9. Регулярные выражения и Перл, как пример того что и на системах фирования можно писать программы.
Регэкспы — это мейнстрим. Перл, в принципе, тоже. Хотя я думаю, что его постепенно вытеснят Python/Ruby.
Здравствуйте, VladD2, Вы писали:
VD>Ява идет в лес за грязный дизай языка.
Разжуйте, пожалуйста.
VD>X-Path часть XQuary/XSLT, а остальные в лес за ненадобностью.
?
VD>В лес по тем же сообрежениям.
?
Здравствуйте, VladD2, Вы писали:
L>>Идея ООП чище выражена в Smalltalk, можно поглядеть его.
VD>Добавляй, что это твое мнение.
Ты же не добавлял, когда говорил, что С# классический ОО, а я всего лишь говорю об идее "всё есть объект, объекты общаются сообщениями". В смолтолке эта идея выражена чище. Ой, прости, это моё мнение.
VD>Я считаю Смолток языком с прототипной орканизации.
Твоё изобретательство в области новых определений старых терминов не знает границ, поясни. что ты понимаешь под прототипной организацией?
VD>И она мне категорически не нравится. Так что мое мнение — смолток для начального обучения лучше не применять. Он даст отрицальный эффект.
"Мне не нравится, так что лучше не применять". Железная логика! :-)
Да, собственно, забыл сказать. Я не зря упоминул Руби. Это как раз язык из серии продолжателей идей Смолтока только с "человеческим лицом". Так что еще раз поторюсь, смысла включать в свой список такой архики как Смолток не вижу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
VD>>>Ява идет в лес за грязный дизай языка. R>>Разжуйте, пожалуйста.
VD>Ява перенела довольно много граблей из С++. Например, отсуствие явного указания переопределения методов (ключевое слово override) или отсуствие возможности явно описать, что функция возращает множество результатов (в виде кортежей или ref/out-параметров). И таких проблем в ней много.
Грязь и бедность — это не одно и то же однако. То что ты привёл — это бедность в выразительных средствах. Грязь (то есть именно непоследовательность и обилие граблей) в Jave конечно есть, я бы туда отнёс некрасивую работу с плоскими типами (особенно когда туда приплели автобоксинг в 5-й джаве).
Ещё совершенно непоследовательно введение свойств (!) length и class. Без скобок и в качестве ключевых слов. Идиотизм.
synchronized методы — это взведённые грабли, ждущие когда на них наступят.
проваливающийся switch/case. Редкие, но грабли.
char d = '9' - '0'; // ашыпка
Если есть байтовое значение, большее 127 и к нему прибавить другое значение, то получаем не то что ожидали. Нужно сначала преобразовать значения к интам, потом уже производить арифметику.
List<String>[] data = new ArrayList<String>[10]; // такие коллекции недопустимы
List<String> data1 = new ArrayList<String>(); // а так мона
Если разобраться, конечно понятно почему, но тем не менее непоследовательно это. Либо запрещать ковариантность для всех коллекций, либо обеспечивать.
Ну в течение работы можно ещё встречал, но сейчас прямо всё упомнить не могу.
Yuri Khomich,
LCR>>synchronized методы — это взведённые грабли, ждущие когда на них наступят.
YK>О как. И в чем же там грабли?
В том, что доступ к this может иметь все, кому не лень, отсюда следует угроза дедлока. Синхронизация должна производиться по внутреннему (желательно приватному) объекту.
Здравствуйте, Last Cjow Rhrr, Вы писали:
LCR>Yuri Khomich,
LCR>>>synchronized методы — это взведённые грабли, ждущие когда на них наступят.
YK>>О как. И в чем же там грабли?
LCR>В том, что доступ к this может иметь все, кому не лень, отсюда следует угроза дедлока. Синхронизация должна производиться по внутреннему (желательно приватному) объекту.
Дедлок можно сделать и синхронизируясь по приватному объекту.
Кроме того, возможность синхронизироваться по самому объекту может быть частью публичного интерфейса. Например, в Java перебрать элементы синхронизированной коллекции можно (и нужно) так:
List list = Collections.synchronizedList(other);
// . . .synchronized (list) {
for (Object item : list) {
// . . .
}
}
Если бы методы синхронизированной коллекции были синхронизированы не по this, а по какому-то приватному объекту, то невозможно было бы гарантировать, что коллекция не изменится во время перебора ее элементов.
Можно, конечно, было бы сделать синхронизируемый объект публичным, но в таком случае непонятно чем такой код
synchronized (list.syncRoot()) {
// . . .
}
лучше такого
synchronized (list) {
// . . .
}
поскольку все равно доступиться к синхронизированному объекту опять же может кто угодно.
Здравствуйте, Геннадий Васильев, Вы писали:
TI>>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
ГВ>Если ты уже делишь языки на "основные" и "альтернативные" — это уже ошибочная постановка вопроса. Посему предложу тебе другую методику. В начале, пожалуй, математика в объёме первых 3-х курсов любого вуза. Это — минимум. Дальше в некотором роде смесь: системное программирование, формальные языки и построение компиляторов, дискретная математика, основы электроники, вопросы связанные с искусственным интеллектом. Присоединюсь к тем, кто советовал SICP и добавлю сюда ещё дядьку Кнута. Потом — применение тех или иных языков для определённых задач. Ну и в процессе уже определишься, что к чему и почему, и откуда и куда у чего ноги растут.
ГВ>А так... Ну скажут тебе, что, к примеру, Lisp полезно знать. А почему? Его же относительно редко применяют. Потому что Пол Грэхем о нём балладу спел? Так баллады много о чём пели! Что ж теперь?
ГВ>Так что, копай, а там вопросы подобные онтопику сами собой отпадут.
Здравствуйте, Last Cjow Rhrr, Вы писали:
LCR>>>synchronized методы — это взведённые грабли, ждущие когда на них наступят.
YK>>О как. И в чем же там грабли?
LCR>В том, что доступ к this может иметь все, кому не лень, отсюда следует угроза дедлока. Синхронизация должна производиться по внутреннему (желательно приватному) объекту.
Ничего такого отсюда не следует. С таким же успехом ты можешь получить дедлок в случае использования в качестве локов внутренних объектов, если локи берутся в неверном порядке. Ну так думать же надо.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, VladD2, Вы писали:
VD>>Ява перенела довольно много граблей из С++. Например, отсуствие явного указания переопределения методов (ключевое слово override) R>В чем собственно недостаток? Если уж грабельный разговор... заодно расскажите, используете ли вы модификатор new в C#?
).
VD>> или отсуствие возможности явно описать, что функция возращает множество результатов (в виде кортежей или ref/out-параметров). R>Возвращение примитива по ссылке противоречит объектно-ориентированному методу. Это уже множество раз обсуждалось: передача параметра "по ссылке"
— в C# это оставили, потому на нем удобно писать в том числе и "процедурно" (к примеру, вычислители), а Java более "чистый" в этом отношении ООЯ.
Лично я не разделяю крайне пуристские взгляды на ref-out параметры. И считаю, что они в некоторых случаях бывают весьма полезны. Тем более, что в C#'е они реализованы, на мой взгляд, лучше, чем в C++ (например, есть разделение на ref и out (а не просто ссылка); и необходимость явно помечать ref out аргументы при вызове).
Однако, если говорить о Java, то ref-out в ней до сих пор не реализовано не только по "историческим причинам" и еще и потому, что ref-out параметры могут "добавить" граблей в программу.
Например, необходимость в ref-out параметрах часто демонстрируется на примере функции Swap, которая меняет значения двух переменных, передаваемых в качестве параметров.
Swap может быть реализована так:
void Swap(ref int a, ref int b)
{
int t = a;
a = b;
b = t;
}
Однако, если попытаться ею обменять значения полей некоторого объекта (в одном потоке), то другой поток может "увидеть" частично измененный объект (т.е. после "a = b" и до "b = t") и это промежуточное состояние может нарушать внутренний инвариант класса. Ситуация может быть еще более критичная, если Swap будет реализован так:
void Swap(ref int a, ref int b)
{
a ^= b;
b ^= a;
a ^= b;
}
ведь a и b могут быть индексами массива, а промежуточное значение (a ^ b) врядли будет осмысленным.
Т.е. для того, чтобы пользоваться таким Swap'ом необходимо понимать, что происходит внутри (т.е. невозможно воспринимать Swap как черный ящик) и предпринимать некотороые действия для того, чтобы избежать негативных последствий. Скажем, поместить вызовы Swap в lock блок. Кроме того, функции с ref параметрами могут возбуждать исключения, а это добавляет сложностей, поскольку в случае возникновения исключения в общем случае может потребоваться привести ref параметры в некое "разумное" значение.
Дима,
D>Дедлок можно сделать и синхронизируясь по приватному объекту.
Ну для этого стараться гораздо надо больше. Предположим, мы ссылки на приватные объекты-локи наружу нигде не выставляем — ни прямо, ни косвенно. Отсюда следует, что получить дедлок можно только получив цикл на этих локах, которые — заметим! — все перечислены в начале определения класса.
D>
D>Если бы методы синхронизированной коллекции были синхронизированы не по this, а по какому-то приватному объекту, то невозможно было бы гарантировать, что коллекция не изменится во время перебора ее элементов.
Здесь ты немножечко прав. Но совсем немножечко.
Во-первых, компилятор мог бы обеспечить (а может обеспечивает, кстати) атомарность участка от входа в функцию до первого оператора. Или более слабое утверждение — если первый оператор synchronized(...). На самом деле ползать по первым стэйтментам компилятору не в первой — см. super.
D> Можно, конечно, было бы сделать синхронизируемый объект публичным,...
А во-вторых, можно было бы передавать объект синхронизации в качестве параметра конструктору:
List list = Collections.synchronizedList(other, lock);
// . . .synchronized (lock) {
for (Object item : list) {
// . . .
}
}
Yuri Khomich,
LCR>>В том, что доступ к this может иметь все, кому не лень, отсюда следует угроза дедлока. Синхронизация должна производиться по внутреннему (желательно приватному) объекту.
YK>Ничего такого отсюда не следует. С таким же успехом ты можешь получить дедлок в случае использования в качестве локов внутренних объектов, если локи берутся в неверном порядке. Ну так думать же надо.
Далеко не с таким же успехом. У приватных объектов есть (гораздо меньший) scope. Думать? Ну да, думать в любом случае надо.
Здравствуйте, fmiracle, Вы писали:
L>>А основы электроники-то зачем?
F>Думаю — для общего развития. Представлять себе как примерно функционирует компьютер — от этого хуже не будет, а помочь иногда может
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ> и добавлю сюда ещё дядьку Кнута.
А то многие начинают выпендриваться и говорить "прочитай Кнута и научишься программировать". Совершенно согласен, что Кнута нужно изучать далеко не в первую очередь.
Здравствуйте, Lloyd, Вы писали:
L>А основы электроники-то зачем?
Хотя бы для того, чтобы понимать, почему производительность не бесконечна.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, rsn81, Вы писали:
R>По-моему, "изучать" языки не делая на них конкретный проект — пустая трата времени. В университетах Object Pascal дают по нескольку лет, и то после этого человек его не знает. Полевые условия — самый верный вариант обучения... ну и икра на хлебе появится.
(Object) Pascal это отдельная сущность.
Это прародитель всех языков Паскалевской группы и базовых алгоритмов. Т.е. именно его и надо изучать — ибо сие есть база для всего остального. Тако ж Lisp и Java. Ну и С туда же.
Здравствуйте, rsn81, Вы писали:
VD>>Ява перенела довольно много граблей из С++. Например, отсуствие явного указания переопределения методов (ключевое слово override) R>В чем собственно недостаток? Если уж грабельный разговор... заодно расскажите, используете ли вы модификатор new в C#?
Понимешь ли в чем дело? Некоторые вещи для осмысления требудт нехилой подготовки и опыта. Вот чем плохи грабли одна из таких вещей. Ее очень сложно объяснить. Более того если человек не видел как можно жить по другому, то ему обычно вообще ничего объяснить нельзя. Очень редкий человек может адекватно судить о том, что он не знает, и что он не пробовл.
VD>> или отсуствие возможности явно описать, что функция возращает множество результатов (в виде кортежей или ref/out-параметров). R>Возвращение примитива по ссылке противоречит объектно-ориентированному методу. Это уже множество раз обсуждалось: передача параметра "по ссылке"
— в C# это оставили, потому на нем удобно писать в том числе и "процедурно" (к примеру, вычислители), а Java более "чистый" в этом отношении ООЯ.
Извини, а ты знаешь что такое кортежи? Или ты просто пропускаешь все назнакомые слова?
ОК, тогда ответь мне нормально ли возвращать значения из фунций запаковывая их в одноэлементные массивы или специальные обертки?
VD>> И таких проблем в ней много. R>Да?
Я не знаю, что ты радуешься. Ты явно имеешь очень небольшой кругозов в обсуждаемом вопросе. Ту плакоть надо. Или хотя бы не выступать.
Ты бы изучил 2-3 языка кроме Явы (причем не только ООП, но и поддерживающие другие парадигмы). Вот тогда бы мы с тобой компетентно поговорили бы.
VD>> C# можно считать наследником Явы в котором вычещено большинство проблем этого языка. R>Извините, но вы пока не убедили.
Кого? Тебя? Я и не соберался убеждать тебя лично. Я высказал свое мнение основанное на анализе и изучении (пускай иногда и поверхностном) этих языков. Ты же влез судить явно зная только одну Яву.
R>Да как вам угодно: на ваш список никто не посягает — просто вы сказали достаточно резкое утверждение без аргументации, вот и заинтересовало.
Я высказал свое мнение. Он не то чтобы резкое или не резкое. Оно мое. А ты пыташся его исправить так чтобы он удовлетворяло тебя. Так вот я с этим не согласен. Создавай свой список. Мой не трогай.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ты явно что-то не понимаешь. Мне плевать на твое мнение. Я просто не хочу провести неделю в оправданиях. Я шел 15 лет к тому чтобы сформировать это мнение и не хочу от него отказываться. По крайней мере без весомых на то причин. Вокруг много крикунов неспособных сказать ничего интересного, но каждый из них с радостью докопается до любых слов и начент развивать почему его любимую игрушку не включили в список.
Это ты явно чего то не понимаешь, что ты там включил или не включил в свой список мне пофиг. Что ты носишься с ним, ей-богу не понимаю
VD>>>Еще раз. Создай отдельно свой список и хоть Перл туда запиши. Мой списко трогать не надо.
L>>Правила форума это запрещают?
VD>Нет. А тебя сдерживают от глупых поступков только правила форума?
Ну, тебя то они не сдерживают.
Моё замечание о Смолтолке стоит расценивать исключительно как предложение для дополнительного изучения. Оно находилось в ответе на твой пост в связи со сравнением с ОО языками. Ты зря думаешь, что я как то хочу задеть твой список. О Смолтолке -- это не к тебе, это к спросившему. Жаль, что это так сильно тебя зацепило.
L>>Термин я знаю. Ок, обратимся к Википедии.
VD>Значит я его не выдумал? ОК, так и запишем — ты погорячился.
"Согласно постулатам логики Влада" :-)
Я говорил о "новых определениях старых терминов" ;-)
VD>Смолток позволяет вмешиваться в структуру объектов в рантайме. Это свойства тех самых прототипных языков. Смолтон не чистный прототипный язык. Но он был преттече Сэлфа. Идеи Сэлфа почерпнуты именно из природы Смолтока.
Елки. Смолтолк позволяет в рантайме менять классы, а не объекты, ну добавишь ты каждому объекту класса А по полю... да и вообще это никаким боком к прототипным языкам. Смолтолк не то что не чистый прототипный язык, он вообще не прототипный язык. Для прототипного языка как минимум необходима возможность порождения от прототипа нового объекта с возможностью изменения его поведения.
VD>>>А мне по барабуну ты лично и то что ты думаешь о моей логие в частности.
L>>Зачем тогда ты это пишешь?
VD>Ты серьезно считашь, что я это делал специально для тебя?
AndrewVK wrote: > ИМХО, (ИМХО!) главная грязь Java заключена в крайне запутанной концепции > inner classes. Ну и в вытекающей из этого грязности (грязноте?) > анонимных классов.
Кхм. А что в них такого запутанного? Все ясно и понятно — это просто
(почти) синтаксический сахар.
Там из несинтаксического сахара только один хак в верификаторе.
Здравствуйте, Cyberax, Вы писали:
C>Кхм. А что в них такого запутанного?
Нелогично. Из разряда "понять нельзя, можно только запомнить". Нет, я конечно понимаю, что если поглубже закопаться в проблемы языка и VM, то понять причины такого варианта можно, но, ИМХО, для основополагающих концепций языка это слабая отговорка. Такие концепции должны быть кристалльно прозрачны без наличия каких то специфичных знаний и сложной логики. Если не получается, то лучше такую конструкцию выкинуть и заменить другой, решающей сходные проблемы другим способом.
C> Все ясно и понятно — это просто C>(почти) синтаксический сахар.
Увы нет. Вот в шарпе это дейтвительно понятно (ну, если не брать некоторые тонкости, связанные с дженериками), поскольку это (за исключением контроля доступа) синтаксический сахар. А вот в Java все намного печальнее. Там есть разновидности, которые остаются inner классами и в рантайме со всеми вытекающими. И вот взаимодействие экземпляров этих классов с экземпляром класса владельца это весьма хитрая конструкция.
C>Там из несинтаксического сахара только один хак в верификаторе.
AndrewVK wrote: > C>Кхм. А что в них такого запутанного? > Нелогично. Из разряда "понять нельзя, можно только запомнить".
Мне хватило 10 минут, чтобы понять как оно работает — когда я
декомпилировал их и посмотрел что там внутри. Все сразу становится ясно.
> конечно понимаю, что если поглубже закопаться в проблемы языка и VM, то > понять причины такого варианта можно, но, ИМХО, для основополагающих > концепций языка это слабая отговорка. Такие концепции должны быть > кристалльно прозрачны без наличия каких то специфичных знаний и сложной > логики. Если не получается, то лучше такую конструкцию выкинуть и > заменить другой, решающей сходные проблемы другим способом.
Ты можешь привести пример "непрозрачности"?
> C> Все ясно и понятно — это просто > C>(почти) синтаксический сахар. > Увы нет. Вот в шарпе это дейтвительно понятно (ну, если не брать > некоторые тонкости, связанные с дженериками), поскольку это (за > исключением контроля доступа) синтаксический сахар.
В Java это именно сахар. Ну почти сахар — есть несколько методов в
классе Class для работы с вложенными классами.
> намного печальнее. Там есть разновидности, которые остаются inner > классами и в рантайме со всеми вытекающими. И вот взаимодействие > экземпляров этих классов с экземпляром класса владельца это весьма > хитрая конструкция.
Обычные прокси-методы. Что тут такого?
> C>Там из несинтаксического сахара только один хак в верификаторе. > Ты это, с шарпом не попутал?
Нет. Там есть хак, который позволяет в конструкторах inner-классов иметь
код ДО вызова super-конструктора. Как раз для того, чтобы
инициализировать прокси.
AndrewVK wrote: >> > C>Кхм. А что в них такого запутанного? >> > Нелогично. Из разряда "понять нельзя, можно только запомнить". > C>Мне хватило 10 минут, чтобы понять как оно работает — *когда я* > C>*декомпилировал их и посмотрел что там внутри*. Все сразу становится ясно. > Ключевой момент я пометил жирным. ИМХО, это неприемлемо для понимания > *концепций языка*.
Можно было бы в tutorial'е по языку просто написать, что такая
конструкция просто аналогична другой. Вот и все.
> C>Ты можешь привести пример "непрозрачности"? > Что значит пример? Inner classes и их взаимодействие с outer class, > особенно когда речь заходит об экземплярах и есть такой пример.
Inner-класс имеет доступ к переменным экземпляра outer-класса и к
final-переменным того метода, в котором он был создан (если он был
создан внутри метода). Что тут сложного?
Здравствуйте, Cyberax, Вы писали:
C>Можно было бы в tutorial'е по языку просто написать, что такая C>конструкция просто аналогична другой. Вот и все.
Это и называется нельзя понять, можно только запомнить.
C>Inner-класс имеет доступ к переменным экземпляра outer-класса и к C>final-переменным того метода, в котором он был создан (если он был C>создан внутри метода). Что тут сложного?
Здравствуйте, AndrewVK, Вы писали:
AVK>И, что забавно, ПТЦА было вобще не упомянута, хотя она то точно будет полезна, если уж гнаться за кругозором.
Да, согласен.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Last Cjow Rhrr, Вы писали:
LCR>Грязь и бедность — это не одно и то же однако. То что ты привёл — это бедность в выразительных средствах.
Нет, это как раз грязь. Грязь это когда язык содержит грабли которых можно было бы избежать. Грязь — это когда он непродуман.
LCR> Грязь (то есть именно непоследовательность и обилие граблей) в Jave конечно есть, я бы туда отнёс некрасивую работу с плоскими типами (особенно когда туда приплели автобоксинг в 5-й джаве).
Не знаю что плохого в автобоксинге, без него было куда хуже. Соглашусь, что если бы разницы между вэлью-типами и ссылочными типами небыло, то было бы уроще. Но без супер-оптимизаций компилятора это привело бы к серьезному замедлению выполнения множества приложений. Собственно Смолток это замечательно показал. Ни один ХотСпот его не спас. А Ява очень даже шутсро бегает. Дотнет и подавно.
LCR>synchronized методы — это взведённые грабли, ждущие когда на них наступят.
Вот это вообще заблуждение. Это не большие грабли чем возможность создать публичное поле. Позволяет нарушать инкапсуляцию — да, но это можно сделать сотней других способов.
А многопоточность в Яве вообще не продумана. Ввели какие-то примитивы (да еще и через зад), но толку от этого == 0. Писать многопоточный софт так же трудно как на С++. Тут нужны другие решения: 1) автоматическое распараллеливание, 2) аналог системы сообщений Эрлэнга. Вот это дало бы толк. А ручная синхнонизация крути, не крути все равно приведет к ошибкам которые будет трудно найти.
LCR>проваливающийся switch/case.
Согласен.
LCR>Редкие, но грабли.
У когда как. Да и редкая проблема может остановить проект лучше частой. Ведь к частым привыкают.
LCR>
LCR>char d = '9' - '0'; // ашыпка
LCR>
LCR>Если есть байтовое значение, большее 127 и к нему прибавить другое значение, то получаем не то что ожидали. Нужно сначала преобразовать значения к интам, потом уже производить арифметику. LCR>
+1
LCR>List<String>[] data = new ArrayList<String>[10]; // такие коллекции недопустимы
LCR>List<String> data1 = new ArrayList<String>(); // а так мона
LCR>
LCR>Если разобраться, конечно понятно почему, но тем не менее непоследовательно это. Либо запрещать ковариантность для всех коллекций, либо обеспечивать.
Незнал. Действительно задница. И разбираться тут смысл нет. Она от этого не пропадет. В Шарпе это нормальный код.
Что за проблема не дает создать массив ArrayList-ов?
В общем, как я уже сказал, таких проблем море. Их описание может занять много времени и естественно все фанаты Явы скажут что это все фигня, и так и надо.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Aquila, Вы писали:
TI>>>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
ЗХ>>Однозначно последнее.
A>Многозначно сомневаюсь.
А откуда берутся сомнения? Изучать новый язык просто так? Даже несмотря на то что сейчас он не нужен? Из логики "Может быть пригодиться"? (с). Это и есть пустая трата времени. Это самое время можно потратить более продуктивно. Имхо, конечно.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Timur I., Вы писали:
TI>>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
VD>Мой список языков котрый может расширить кругозор: VD>1. C# — классика ООП, компонентность, статическая типизация, обобщенное программирование. VD>2. Руби — классика скриптов, динамика, гибкость. VD>3. Хаскель — функциональный подход, вывод типов, красивая идея классов типов (похожая на интерфейсы в C#, но которые можно подключать к уже имеющися типам), ленивое исполнение. VD>4. XQuary/XSLT — как пример языков трансформации данных. VD>5. Схема — как пример языка без синтаксиса и мощи макросов. VD>6. Рад, что даждались ожидаемого. Правильно немерле как квинтесенция свсего перечисленного выше. VD>7. Пролог, как демонстрация красивой идеии логического программирования практичски бесполеной на прктие. VD>8. SQL — пример декларативного языка обраобтки данных. VD>9. Регулярные выражения и Перл, как пример того что и на системах фирования можно писать программы.
Добавил бы еще
Eiffel — за "все объект", понятия контрактов, систему множественного наследования, четкую и достаточно простую систему параллельного исполнения.
Pascal и Delphi не упомянули...
И я так думаю что уже правильно... Время их уходит. И никакие Chrome и обещанная в этом году поддержка .NET2 в Delphi не помогут им в будущем...
Поймите, просто перечислить все языки которые знаешь или о которых слышал — это задача для дауна. Я попытался создать минимально достаточный список. В него ничего не надо вставлять!
Я понимаю, что у разных людей разные предпочтения, но и вы меня поймите. Это мои предпочтения. Не надо в них добавлять ничего! Создайте свой и хоть всю вселенную в него впихните.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
).
VD>Да, уместно. Но о нем еще надо знать. А rsn81 явно не из тех кто обсуждает то, что знает.
VD>Еще можно было бы упоминуть дизайн делегатов и пару других вещей.
VD>Все это достадные ошибки дизайна. Но их все же не много. И их наличие никак не умоляет того факта, что ошибки дизайна Явы были проанализированы и в оснвном устранены.
D>>Лично я не разделяю крайне пуристские взгляды на ref-out параметры. И считаю, что они в некоторых случаях бывают весьма полезны. Тем более, что в C#'е они реализованы, на мой взгляд, лучше, чем в C++ (например, есть разделение на ref и out (а не просто ссылка); и необходимость явно помечать ref out аргументы при вызове).
VD>В С++ их вообще нет. За то есть указатели позволяющие эмулировать их, но эта эмуляция черевата ошибками, и опасными. Плюс явное указание этих модификаторов четко описывает намерение, а значит делает код более понятным и предсказуемым.
Здравствуйте, creatman, Вы писали:
C>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, dshe, Вы писали:
D>>>Здесь наверное более уместно упомянуть оператор as (As is или история о том как не надо писать код
).
VD>>Да, уместно. Но о нем еще надо знать. А rsn81 явно не из тех кто обсуждает то, что знает.
VD>>Еще можно было бы упоминуть дизайн делегатов и пару других вещей.
VD>>Все это достадные ошибки дизайна. Но их все же не много. И их наличие никак не умоляет того факта, что ошибки дизайна Явы были проанализированы и в оснвном устранены.
D>>>Лично я не разделяю крайне пуристские взгляды на ref-out параметры. И считаю, что они в некоторых случаях бывают весьма полезны. Тем более, что в C#'е они реализованы, на мой взгляд, лучше, чем в C++ (например, есть разделение на ref и out (а не просто ссылка); и необходимость явно помечать ref out аргументы при вызове).
VD>>Плюс явное указание этих модификаторов четко описывает намерение, а значит делает код более понятным и предсказуемым.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
КЛ>>повеселил А может еще расскажешь, что такое атомарность функций?
VD>Слушай, ты бы не позорился бы, а?
ну дай попозориться, пожалуйста
так ссылочку может даешь или еще что...А то вот говоришь умные слова, хочется узнать откуда дровишки.
КЛ>>PS: тот, кто часто использует кортежи в качестве возвращаемых значений явно что-то не то делает. Или у него слишком специфичная задача. Отсутствие кортежей — не смертельно.
VD>Тебе, конечно, видней.
Здравствуйте, Константин Л., Вы писали:
FR>>Конечно не смертельно. Но такая вроде с виду фигня реально сокращает объем кода. Но дело даже не в сокращении объема, а в удобстве, уже привыкаешь что не нужно заводить бестолковые временные структуры, не нужно задумыватся о том как вернуть результат.
КЛ>поинт в том, что если ты возвращаешь "бестолковые временные структуры", то значит у тебя метод делает "все сразу и еще кучу вещей", что часто говорит о его избыточности или неправильности. Если же так нужно и это осмысленная операция, то эти "бестолковые временные структуры" должны стать нормальными логическими сущностями и уж тут кортежи нафиг не нужны. Кароче моё мнение, что кортежи — это затычки для костылей, которые мы сами и сажаем.
Так нужно и это осмысленные операции, только от бестолковых временных структур это не избавляет.
Те же std::pair, boost::tuple тоже нафиг не нужны?
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, Константин Л., Вы писали:
КЛ>>> Кароче моё мнение, что кортежи — это затычки для костылей, которые мы сами и сажаем.
Q>А мое мнение, что вы с умным видом рассуждаете о вещах, о которых понятия не имеете.
кортежи настолько простая вещь, что не надо быть академиком, чтобы рассуждать о ней.
[]
FR>Так нужно и это осмысленные операции, только от бестолковых временных структур это не избавляет. FR>Те же std::pair, boost::tuple тоже нафиг не нужны?
не знаю...ты сам себе противоречишь. Так нужно — но бестолковые структуры...
VD>Но у них есть одна проблема — они неудобны. Или скажем, так в большинстве случаев вместо них удобнее использовать озврат множетсва значений (котреж, напимер). Такой подход решает и проблему многопточности (при условии что весь многопоточный код написан в фукнциональном стиле) решает, и просто удобен.
поправь меня, но в Nemerle можно обращаться к элементам кортежа только по индексам, которые должны быть известы в compile-time и нельзя по элементам пробежаться. Так что это лучше "бестолковых безымянных структур" только их отсутствием (структур). А об их отсутствии (точнее о том, что это плохо и они заменяются кортежами.) я уже писал.
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, VladD2, Вы писали:
КЛ>[]
VD>>Но у них есть одна проблема — они неудобны. Или скажем, так в большинстве случаев вместо них удобнее использовать озврат множетсва значений (котреж, напимер). Такой подход решает и проблему многопточности (при условии что весь многопоточный код написан в фукнциональном стиле) решает, и просто удобен.
КЛ>поправь меня, но в Nemerle можно обращаться к элементам кортежа только по индексам, которые должны быть известы в compile-time и нельзя по элементам пробежаться. Так что это лучше "бестолковых безымянных структур" только их отсутствием (структур). А об их отсутствии (точнее о том, что это плохо что они заменяются кортежами.) я уже писал.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>видишь ли, в чём прикол — мы все используем наши языки не совсем по назначению, вносим в них те концепции (паттерны программирования), которые изначально в языке отсутствуют. используем продцедурное программирование с ассемблером, ООП — с Си, функциональное — с С++. и для того, чтобы знать, как можно улучшить свои паттерны программирования, и полезно знать другие языки. кроме того, некоторые сами выбирают, на чём им писать
В целом я согласен. Но под "знать язык" я подразумеваю не "прочитал книжку, глянул пару семплов и написал HelloWorld". Такие знания гроша ломаного не стоят и счастливый обладатель таких знаний сам через полгода забудет большую часть. А реальное изучение отнимет много времени. А если оно еще и не под конкретную задачу, а просто "чтоб было"... В плане ознакомления с новыми концептами другие языки просматривать стоит. Знакомиться с их парадигмами и идеями. Но полноценно изучать я бы их не рекомендовал.
Здравствуйте, BulatZiganshin, Вы писали:
VD>>>Языки типа Явы и C# ВООБЩЕ не рассчитаны на работу в многопоточном окружении.
C>>synchronized? lock? Это не расчет на многопоточность???
BZ>это как раз костыли вокруг mutable values, чтобы затащить их в brave new world эрланг, созданный для программирования АТСок, таких затычек не имеет, а ведь там тысячи процессов — это не подвиг, а норма
Согласен, но я бы уточнил, что это все же костыли не для изменяемых значений, а в следствии отсуствия толковой идеологии распараллеливания вычислений. Конечно тсуствие изменяемых значений позволяет автоматически распараллеливать (в основном теоритически) программы. Но есть и другие подходы. Эрланг, например, исползует идею изолированных программных процессов и пердачу между ними сообщений. Точно такой же подход используется в Сингулярити — эксперементальной ОС МС. Так еж есть идеология Активных объектов. Практически тоже что и в Эрланге, но вместо сообщений испоьзуются вызовы методов объетов привязанных к потоку.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
VD>>Но у них есть одна проблема — они неудобны. Или скажем, так в большинстве случаев вместо них удобнее использовать озврат множетсва значений (котреж, напимер). Такой подход решает и проблему многопточности (при условии что весь многопоточный код написан в фукнциональном стиле) решает, и просто удобен.
КЛ>поправь меня, но в Nemerle можно обращаться к элементам кортежа только по индексам, которые должны быть известы в compile-time и нельзя по элементам пробежаться. Так что это лучше "бестолковых безымянных структур" только их отсутствием (структур).
Поправляю. В Немерле есть возможность:
1. Передавать кортежи вместо параметров фукнций.
3. Использовать их образцах при паттерн-матчинге.
4. Ну, и действительно индексировать.
Перебирать из довольно бессмысленно так как они могут иметь разные типы данных. Хотя в макросах их можно и переберать и даже генерировать. К примеру, параметры методов тоже генерируеются как кортежи.
КЛ> А об их отсутствии (точнее о том, что это плохо и они заменяются кортежами.) я уже писал.
(задумчиво) Да, ты много пишешь...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, cl-user, Вы писали:
CU>"Я тут сказал мысль, а вы не сметь критиковать!"
Я не вижу тут критики. Я вижу желаете у многих впихнуть свою любимую игрушку.
CU>Ну и ты нас пойми, нас очень интересует не сам список, а _почему_ он именно такой!
Этого вопроса пока не звучало. Если это интересует, то могу ответить. Толко чур не обижаться когда первый же спорщик будет послан далеко и на долго. ОК? Вы же мое объяснение хотите услышать или поспорить итаки впихнуть в список то что желаете?
CU>Или так сильно влом вежливо и без наездов объяснить, почему именно этот язык не включён в список?
Не то что бы влом, а я знаю чем это кончится. Это совершенно флэймовая тема. Каждый будет птытаться впихнуть свою игрушку переходя все пороги разумности и не разумности.
CU>Или с тебя шапка упадёт/нимб свалится, если ты признаешся, что не знаешь какой-то язык?
Знаешь, я болшинство перечисленных мной языков знаю очень поверхносно. В основном по описаниям. Это не мешает мне анализировать их и выявлять концептуально значимые вещи.
Да и на понт меня взать нельзя. Можнно тлько попросить.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Но в списке не нужны два, пусть даже приблизительно одинаково хороших ООЯ. И не нужно два статических ФЯ.
дело в том, что всякая классификация — лишь наш способ упорядочить мир, придать ему в нащитх глазах большую структуру. скажем, хаскел — ленивый, а окамл — нет. считать ли это разными концепциями? всё зависит от ого, насколько глубоко ты в эту тему хочешь погрузиться
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
КЛ>>>>повеселил А может еще расскажешь, что такое атомарность функций?
VD>>>Слушай, ты бы не позорился бы, а?
КЛ>>ну дай попозориться, пожалуйста
КЛ>>так ссылочку может даешь или еще что...А то вот говоришь умные слова, хочется узнать откуда дровишки.
VD>ОК. Я думал ты прикалываешся, а ты похоже иправда не понял о чем я говорю.
прикалывался.
VD>В математике все фукнкции чистые. Это значит, что они не имеют побочных эффектов. Взывая чистую фунцию ты можешь быть уверен, что ничего не изменится. Таким образом каждый вызов можно рассматривать как атомарную операцию. Ты гарантированно застрахован от того, что во время ее вызвова что-то изменится.
VD>Такую фукнцию ты можешь выполнять параллельно или даже автоматически распараллеливать. В отличии от нее фукнция в императивных языках всегда может что-то изменить или на что-то повлиять. Такие фукнции нельзя рассматривать как атомарные операции и в многопоточном окружении их нужно синхронизировать применяя примитивы синхронизации.
Ок, спасибо. Но все равно к практике имеет опосредованное отношение. Никто referential transparency (взято из поста выше) никто не отменял и заявлять, что язык не предназначен для нап. многопоточных программ из-за отсутствия атомарных функциий, по-моему, неправильно. Тем более что эту атомарность может обеспечить сам разработчик.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
КЛ>>кортежи настолько простая вещь, что не надо быть академиком, чтобы рассуждать о ней.
VD>Ага. От того твои заявления выглядят еще более нелепо.
VD>Хочешь я тебя удивлю? Ты используешь кортежи постоянно! Не веришь?
[]
применительно к с++ это все абстракция. И не надо со мной разговаривать как с детем, надоело уже.
[]
VD>Не находишь это красивым?
как тебе сказать...Неплохо, удобно. Но есть один недостаток — отсутствие имен элементов кортежа в функции, его возвращающей. С параметрами методов этого нет. Читабельность страдает, имхо.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Константин Л., Вы писали:
КЛ>>Здравствуйте, FR, Вы писали:
КЛ>>[]
FR>>>Так нужно и это осмысленные операции, только от бестолковых временных структур это не избавляет. FR>>>Те же std::pair, boost::tuple тоже нафиг не нужны?
КЛ>>не знаю...ты сам себе противоречишь. Так нужно — но бестолковые структуры...
FR>[b]Нужен результат: например вернуть из функции N (разнотиповых) переменных[b], есть несколько альтернатив как это сделать, в языке подерживающем туплы, это элементарно просто вернуть тупл. В языке не подерживающем туплы или завести структуру из этих N переменных (единственное предназначение которой только возврат этих переменных) или что еще хуже завести у функции out параметры. Тупл здесь средство упростить и очистить от мусора код и ничего больше.
вот в чем ошибка, которую мы сами совершаем и сами же фиксим с пом. туплов.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
КЛ>>поинт в том, что если ты возвращаешь "бестолковые временные структуры", то значит у тебя метод делает "все сразу и еще кучу вещей", что часто говорит о его избыточности или неправильности. Если же так нужно и это осмысленная операция, то эти "бестолковые временные структуры" должны стать нормальными логическими сущностями и уж тут кортежи нафиг не нужны. Кароче моё мнение, что кортежи — это затычки для костылей, которые мы сами и сажаем.
VD>Как грится, с очевидцами не спорят!
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
VD>>>Но у них есть одна проблема — они неудобны. Или скажем, так в большинстве случаев вместо них удобнее использовать озврат множетсва значений (котреж, напимер). Такой подход решает и проблему многопточности (при условии что весь многопоточный код написан в фукнциональном стиле) решает, и просто удобен.
КЛ>>поправь меня, но в Nemerle можно обращаться к элементам кортежа только по индексам, которые должны быть известы в compile-time и нельзя по элементам пробежаться. Так что это лучше "бестолковых безымянных структур" только их отсутствием (структур).
VD>Поправляю. В Немерле есть возможность:
ой спасибо
[отлично что ты опять решил блеснуть знаниями]
VD>Перебирать из довольно бессмысленно так как они могут иметь разные типы данных. Хотя в макросах их можно и переберать и даже генерировать. К примеру, параметры методов тоже генерируеются как кортежи.
хаха, и что? От этого это становится бесмысленным? Че за бред?
КЛ>> А об их отсутствии (точнее о том, что это плохо и они заменяются кортежами.) я уже писал.
VD>(задумчиво) Да, ты много пишешь...
Здравствуйте, VladD2, Вы писали:
CU>>Ну и ты нас пойми, нас очень интересует не сам список, а _почему_ он именно такой!
VD>Этого вопроса пока не звучало. Если это интересует, то могу ответить.
Ок, с учётом всего изложенного есть "контрпреложение": дополнить тебе твой список по каждому из пунктов альтернативами в порядке убывания значимости с твоей точки зрения.
Здравствуйте, Константин Л., Вы писали:
КЛ>как тебе сказать...Неплохо, удобно. Но есть один недостаток — отсутствие имен элементов кортежа в функции, его возвращающей. С параметрами методов этого нет. Читабельность страдает, имхо.
Согласен. Но это уже зависит от дизайна языка. В MATLAB, например, эти имена есть.
Здравствуйте, eao197, Вы писали:
E>В Ruby можно аргументы метода получать в виде одного объекта штатными средствами языка, там хоть как-то можно кортежи за уши притягивать. А вот в C/C++ -- только, если трава забористая попалась.
Кстати D в этом отношении очень близок к C++, но позволяет получить аргументы в виде кортежа, так что принципиальных припятствий не видно.
BZ>>а причём тут процессор? речь идёт о языке. и тут Влад прав — с теоретичсекой точки зрения это кортёж и есть, пока ты не используешь переменнное число аргументов
E>Какая-то оторванная от практики теория, укуренная, я бы сказал. E>Нет в C++ штатных средств получения аргументов метода в виде одного объекта (т.е. никакого экземпляра кортежа получить нельзя). Да, если компилятор не засовывает аргументы в регистры, то хаками на ассемблере можно получить копию стекового фрейма, но к языку это не имеет отношения.
скажем так — для теоретического осмысления языка это может быть не так важно. в языках с отдельными арщументами можно передать только один параметр и получить частично применённую функцию. если это невозможно — то с некоторой точки зрения удобно считать, что передаётся один tuple
Здравствуйте, BulatZiganshin, Вы писали:
BZ>такой подход научит человека мыслить на наиболее высоком возможном уровне — ведь здесь важно, с чего ты начнёшь. если первым яхзыком будет бейсик, то он для человека станет "родным", и дальше все новые концепции будут перекладываться на его "архитектуру"
Тут у многих первый язык — Бейсик, в том числе и у меня.
... << RSDN@Home 1.2.0 alpha rev. 673 on Windows Vista 6.0.6000.0>>
BZ>>такой подход научит человека мыслить на наиболее высоком возможном уровне — ведь здесь важно, с чего ты начнёшь. если первым яхзыком будет бейсик, то он для человека станет "родным", и дальше все новые концепции будут перекладываться на его "архитектуру"
AVK>Тут у многих первый язык — Бейсик, в том числе и у меня.
если бы вторым был пролог — это бы сказалось я к тому, что сейчас вузы т у нас, и за рубежом учат людей шравным образом императивным языкам, и потому-то они и считают это естественным. имхо, функциональный подход даже более естественен, особенно если идти от чистой математики
а когда человек изучит десяток императивных языков, ему в функциональные врубиться уже совсем тяжело, и возникает у него ощущение "а они почему строем не ходят?" у меня-то к моменту изучения хаскела было с пяток языков, обнаруживающих те или иные свойства ФП, и я уже представлял, что мне нужна именно лёгкость записи сложных алгоритмов. вот именно для того, чтобы человек легко сложные алгоритмы осмысливал, и надо его с высокоуровневых языков начинать гонять
Здравствуйте, Константин Л., Вы писали:
КЛ>как тебе сказать...Неплохо, удобно. Но есть один недостаток — отсутствие имен элементов кортежа в функции, его возвращающей. С параметрами методов этого нет. Читабельность страдает, имхо.
Конечно это можно считать проблемой, но практически тоже самое ты имеешь когда смотришь на вызов фунции:
f(1, "aaa", 1.2);
Ты ведь без заглядвания в хэлп тоже не можешь сказать, что означает каждый из параметров. А с заглядыванием и с кортежами проблем не бывает.
Обычно если кортеж используется явно, то он подвергается декомпозиции и каждый его элемент получает имя. Конечно можно ошибиться при задании этих имен, но как показывает практика этого не происходит. Ведь имена задаются теми кто понимает что означает каждый член кортежа. А при чтении мы просто доверяем этим имена. В общем, полная аналогия с параметрами ведь мы тоже можем передать в параметр что-то не то, но совпадающее по типу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>функции с побочными эффектами удобно называть прцедурами — как раз чтобы не входить в разрез с математикой
Термин "процедура" уже занят. Он означает фукнцию которая ничего не возрващает. Так что все же прийдется делить функции на чистые и грязные.
BZ>далее, "чистоту" ещё называют ссылочной прозрачностью (referential transparency),
Да, называют. В мире функциональщиков. В этом мире вообще обожают придумывать невнятные термины. Потому ФП и сидит в такой глубокой заднице.
BZ>и это означает, что результат функции зависит только от её аргументов и никак не зависит от состояния внешнего мира. для того, чтобы гарантировать это, *достаточно* запретить ей обращаться к глобальным переменным, вызывать процедуры, сохранять своё состояние в static vars
Ты забыл изменение объектов в методах.
BZ>вот в этом как раз и состоит проблема вызова процедурного кода из функционального, которую ты объявил несуществующей
Нет такой проблемы. Ее придумали пуристы.
BZ>запретив такие вызовы, мы можем *гарантировать* referential transparency, т.е. теперь это проверяет компилятор.
Можем. Но я бы предпочел чтобы такой запрет насил опциональный характер. Скажем хочу я чобы компилятор мог распараллелить код, помечаю фукнцию соотвествующим атрибутом и получаю что хочу. Ну, или наоборот. Помечаю функцию как императивную и могу творить в ней все что хочу. А можно даже явно указывать что я хочу изменять (определять иныариант фукнции).
BZ> если разрешим — придётся проверять программисту. более того, на самом деле такие вызовы возможны с помощью unsafePerformIO — это и есть тот механизм, который позволяет программисту взять ответственность на себя *явно*
Я не против этого. Я против выдумывания для этого соврешенно не естественых идиом. Есть одна идиома котора и так решает все проблемы — изменение переменной. Ее за глаза хватает.
BZ>ну а тезнически запрет таких вызовов, заодно с явным описанием плорядка вызова процедур, решается "эстафетной палочкой" — фиктивным значением типа RealWorld, передаваемым от порцедуры к процедуре, и недоступным функциям. т.е. функция не может вызвать процедуру потому, что она такую эстафетную палочку не получает сверху, и не может создать её сама
В лес всю фикцию. Проблема рашается намного проще. Надо всего лишь отказаться от пуританства.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>все возможности *яызка* Смоллток в руби есть.
+1 Даже больше. Но действитльно языки одного направления, хотя Руби вроде дрался с Перла.
BZ> правда, изменилась терминоллогия, и главное — нет той замечательной среды. ведь это же была первая IDE в мире! и до сих пор, как я понимаю, нет ни одной среды, где было бы так легко работать со структурой классов и проверять, что возвратят те или иные методы
Сполток конечно обладал первой IDE, но на сегодня IDE Явы и Шрпа намного мощьнее. Тут ты не прав. И причина тут в том, что для этих языков доступна полная информация о типах. Кстати, для Хаскеля хорошую IDE сделать можно, хотя язык имеет плохие особенности вроде уникальных идентификаторов (из-за выбранной системы типов и уращения клгоритма вывода типов), что весма странно будет выглядить в современном мире. А у Руби и Смолтока их динамическая типизация приводитк к серьезным ограничениям.
BZ>C# же, как и Delphi — язык чисто практический, я лично в нём ничего концептуального не вижу.
В них выражены все концепции ООП. Причем используется система типов основанная на классах, то есть так что родилась в Симуле. Смоток и Риби пошли своим путем. Лично мне он не нравится. Но в любом случае достаточно одного представителя этого направления — Руби. Теболее что Руби на мой взгляд более интересный язык.
BZ> и вообще, на мой взгляд, изучать ФП надо с...
А причем тут ФП? У тебя случае мунктика на нем нет? В списке били и Хаскель, и Схема. Вот на них пусть ФП и изучается.
BZ> наиболее теоретичсеких, удобных в программировании, но неэффективных (пролог, хаскел),
С каких пор Пролог стал ФЯ?
BZ> и далее спускать к более практичным, но сложным в использовании языкам. и заканчивать на C#, яве или чём-то ещё, что будет реально использоваться. языки более низкого уровня, типа C++, изучать необязательно — разве что чтобы понять, как функционирует процессор, да и это начинающему ни к чему
А я так не считаю. Как раз я бы сначала познакомил людей с выражениями, потом с основами процедурного программировнаи, а потом бы уже давал бы ФП и ООП как его расширения (заужение). На мой взгляд так будет проще донести до людей эти идеии. Возможно даже вначале показывать сам подход в виде паттернов, а потом показывать соотвествующие языковые конструкции.
Что касается языка, то я бы как раз выделил на роль первого языка Немерле или Руби. Руби я бы посоветовал тем учетилям которые считают, что вначале людям не надо морочить голову с типизацией, а Немерле тем кто считает, что типизация важнеший аспект. Ну, и по той причине, что на немерле можно показать практически все приемы кроме разве что ЛП.
BZ>такой подход научит человека мыслить на наиболее высоком возможном уровне — ведь здесь важно, с чего ты начнёшь.
Твой подход привьет человеку конкретный образ мышления и осложнит восприятие других парадигм. Точно так же плохо давать в начале ООП, а потом пытаться обучить ФП. В обоих случаях будет отторжение второй парадигмы и ломка. Особенно это актуально для ФП, так как литература по нему полное дерьмо. Вообще удивительно как казалось бы стольк умные люди придумавшие все это так бездарны в писательстве! Ну, да это отдельная тема.
В общем, я виду к тому, что ООП и ФП надо давать параллельно и обязательно как развите стурктурного программирования.
BZ> если первым яхзыком будет бейсик, то он для человека станет "родным", и дальше все новые концепции будут перекладываться на его "архитектуру"
Забавно, что ты заметил, что первый язык привязывает к образу мышления. Стало быть твое предложение сделать ФП первым в изучении ни что иное как попытка привязать программирование к нему. На мой взгляд это ошибка.
Бэйсик же бывает разным. Бывает 70-ых годов с жудчащими goto вместо функций. А бывает VB.NET почти не отличающийся от C#. В прочем VB.NET — это ООЯ, что опять же привяжет к ООП. Что плохо.
А вот как средство изучения структурного программирования Васик довольно хорош. Так чта... а пуркуа бы собственно не па?
Я вот первым языком учил С. И особых проблем не вознкло. ФП крышу рвал по началу, но только от того что писатели пытающиеся его объснить были бездарностями.
Кстати, ООП я освоил на раз. И уверен, что это произошло так легко потому, что я сначала испытал в нем потребность, а затем прочел о нем. Я в 93-ем писал программу выводящую окна на экран и после первого лобового опыта стал задумываться как бы это дело реализовать. Патом я стал читать книжку про Виндвс и восхищался идеями сообщений и окон. Далее я изобразил что-то подобное на структурах и указателях на фукнции. Ну, а потом я уже читалш про С++ и мне все казалось логичным и стройным.
Уверен, что именно так надо преподносить знания в учебных заведениях. То есть:
1. Базовые знания.
2. Постановка задачи хорошо решающеся с помощью некого подхода.
3. Решение в лоб.
4. Анализ проблем.
5. Теоритический рассказ о подходе.
6. Решение задачи с помощью паттерна.
7. Демонстрация встроенных средств языка.
8. Анализ приемуществ встронных средств языка над использованием паттерна.
Уверен, что при таком подходе крышу сносить не будет.
Так что продаю идею.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, cl-user, Вы писали:
CU>Ок, с учётом всего изложенного есть "контрпреложение": дополнить тебе твой список по каждому из пунктов альтернативами в порядке убывания значимости с твоей точки зрения.
CU>Если дополнишь объяснениями — вообще будет супер
CU>Идёт?
Считаю это предложение бессмысленным. Мой список я бы разбавил разве что ассемблером и С как средствами демонстрирующими низкоуровневый подход в оптимизации.
Что до альтернатив, то создавайте свои списки сколько влезет. Со своим я определился четко.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>И тут влезу я ЗХ>Я давеча для себя сформулировал, что, вообще говоря, есть два "совсем разных" ООП — "мейнстрим-ООП" и "радикальное ООП".
Скорее согласен
ЗХ>А вот связан ли "тип ООП" с динамичностью самого языка — я не вполне уверен. Сходу кажется, что да (иначе классы нельзя менять в рантайме, и тогда они не полноценные объекты), но так ли оно?
В Яве класс — это объект (полноценный), ему можно посылать сообщение. Менять в рантайме нельзя, нет таких методов. От этого он не перестаёт быть объектом. В других ОО-языках может вообще не быть классов.
ЗХ>ЗЫ: кстати, высказывания на тему "Ruby — это правильный Smalltalk" считаю примерно настолько же экстремистскими как "Nemerle — это правильный Haskell" (хотя, кажется, я знаю человека, который с последним согласится).
ЗХ>Я давеча для себя сформулировал, что, вообще говоря, есть два "совсем разных" ООП — "мейнстрим-ООП" и "радикальное ООП".
ЗХ>Мейнстрим-ООП — это то, что пошло от Симулы и наиболее чисто (почти без грязи-для-большей-практичности) выражено в Eiffel. У него ноги растут от "стремления структурности", главный лозунг — "основная единица организации кода — это класс" ("класс" здесь, — это в душе всегда "модуль на стероидах"). Т.е. предлагается думать о программе в терминах "декомпозиции на классы".
ЗХ>Радикальное ООП — пошло от Smalltalk (точнее, от некоторых более ранних разработок, но эту деталь мы опустим). У него ноги растут от "стремления к естественности и простоте", главный лозунг — "все есть объект", "программа это взаимодействие объектов". Классы здесь могут быть (Smalltalk, Ruby), а может и не быть (Self, Io) — это как бы вторичная по отношению к объекту сущность; все потому, что классы — это тоже объекты, но со специализированной задачей.
имхо твоё разделение — на самом деле статические языки портив динамических, и все вытекаюбщие отсюда плюшки. в eiffel тоже everything is object, это c++/java — языки со смешанной парадигмой, в c# опять все данные — объекты, за исключением unmanaged кода
ЗХ>ЗЫ: кстати, высказывания на тему "Ruby — это правильный Smalltalk" считаю примерно настолько же экстремистскими как "Nemerle — это правильный Haskell" (хотя, кажется, я знаю человека, который с последним согласится).
руби порсто имеет все средства смолтокаЮ, насколько я в курсе. его объектная модель — именно смолтоковская. плюс к этому удобный синтаксис из паскале-подобных языков
кстати, я впервые слышу про предшественников смолтока. не расскажешь зотя бы вкратце о них?
ЗХ>>Я давеча для себя сформулировал, что, вообще говоря, есть два "совсем разных" ООП — "мейнстрим-ООП" и "радикальное ООП".
ЗХ>>Мейнстрим-ООП — это то, что пошло от Симулы и наиболее чисто (почти без грязи-для-большей-практичности) выражено в Eiffel. У него ноги растут от "стремления структурности", главный лозунг — "основная единица организации кода — это класс" ("класс" здесь, — это в душе всегда "модуль на стероидах"). Т.е. предлагается думать о программе в терминах "декомпозиции на классы".
ЗХ>>Радикальное ООП — пошло от Smalltalk (точнее, от некоторых более ранних разработок, но эту деталь мы опустим). У него ноги растут от "стремления к естественности и простоте", главный лозунг — "все есть объект", "программа это взаимодействие объектов". Классы здесь могут быть (Smalltalk, Ruby), а может и не быть (Self, Io) — это как бы вторичная по отношению к объекту сущность; все потому, что классы — это тоже объекты, но со специализированной задачей.
BZ>имхо твоё разделение — на самом деле статические языки портив динамических, и все вытекаюбщие отсюда плюшки. в eiffel тоже everything is object, это c++/java — языки со смешанной парадигмой, в c# опять все данные — объекты, за исключением unmanaged кода
Хм. Похоже, мне пора фиксить mental model. Чегой-то у меня с everything is object в яве и эйфеле не укладывается в голове. Буду учиться.
ЗХ>>ЗЫ: кстати, высказывания на тему "Ruby — это правильный Smalltalk" считаю примерно настолько же экстремистскими как "Nemerle — это правильный Haskell" (хотя, кажется, я знаю человека, который с последним согласится).
BZ>руби порсто имеет все средства смолтока, насколько я в курсе. его объектная модель — именно смолтоковская. плюс к этому удобный синтаксис из паскале-подобных языков
Я же не зря, как аналогию, Хаскель привел В Руби идеи "радикального (динамического) ООП" несколько "запачканы" смешением нескольких методологий, удобством синтаксиса и т.п. (например, в Руби структурные конструкции типа if, while и проч. не являются сообщениями).
BZ>кстати, я впервые слышу про предшественников смолтока. не расскажешь зотя бы вкратце о них?
Ну, откуда "черпались идеи" — это были Lisp, Logo, та же Simula. Но вот откуда была взята основная идея "супа из объектов" — это (сюрприз!) программа Sketchpad, над которой Иван Сазерленд работал некоторое время совместно с Кеем (в смысле, ее написал Сазерленд, а Кей на каком-то этапе поучаствовал). Так вот там, на ассемблере PDP-11 (емнип), и был создан соответствующий DSL, понятие моря/супа объектов и т.п. Кои Кей впоследствии адаптировал к Smalltalk (привнеся классы из соображений, по-моему, эффективности — изначальные идеи Сазерленда были ближе к Self и "прототипной орканизации").
Примерно так.
E>Нет в C++ штатных средств получения аргументов метода в виде одного объекта (т.е. никакого экземпляра кортежа получить нельзя). Да, если компилятор не засовывает аргументы в регистры, то хаками на ассемблере можно получить копию стекового фрейма, но к языку это не имеет отношения.
У меня вопрос к господам, поставившим минусы на мое сообщение. Как известно, практика -- критерий проверки теории. Итак, хотелось бы увидеть практический пример интерпритации параметров функции в C++ в качестве объекта-кортежа (будь то передача параметров при вызове или получения всех параметров внутри функции в качестве объекта-кортежа). Стандартными средствами языка.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>семантика — смолток, синтаксис — эйфель, фичи — перл. вообще, руби — это просто фантастическая коллекция наиболее удачных решений из разнообразных языков.
Это можно сказать об очень многих ЯП. Вот только в случае с Руби, на мой взгляд, не все решения удачные. Много и не удачных.
BZ> например, в книге "жемчужины прогшраммирвания" описан гипотетический язык с очень удобным операторм case. нигда в реальных яхзыках такого так и не сделали. кроме руби!
Ты меня конечно извини, я возможно полохо знаю руби, но мне кажется, что никакой case не может сравниться с паттернм-мачтингом. Приведи, плиз, пример этой крутости.
BZ>не видел ни ту, ни другую, ни третью, так что могу ошибаться.
100% ошибаешся.
BZ>но фишка в том, что смолток динамчисекий язык и в его среде во-первых ты работал непосредтсвеенно с классами, а не исходными файлами, во-вторых, мог проверить работу любой функции непосредственно запустив её
Все то же самое сегодня доступно и для императивных языков. Единственное чего нет — это возможности менять классы на лету (во время исполения программы), но это уже не заслуга Смолтока и не ограничение C#-а, а заслуга Динамики и интерпретации и не ограничение статики и компиляции. Собственно эта фича так же приводит и к другому эффекту — невозможности контролировать ошибки до вызова методов. Что уже становится ограничением динамики, и заслугой статики.
BZ>что означает "уникальные идентификаторы"? я вообще лучше знаю английскую терминологию
Это относится к системе типов Хаскеля. Точнее примитивности системы Хинли-Миллера. Она конечно позволяет довольно ээфективно выводить типы, но страдает достадными ограничениями вроде невозможности перегрузки функций по имени. Например, мы не можем определить свойство (метод, поле, функцию) "x" у типа Point и скажем у типа Point3D. Разруливание на уровне модулей не катит, так как оба типа данных могут понадобиться в одном коде. Посему фукнции начинают вбирать в себя префиксы вроде pointX и point3dX. Сто лично мне очень не наравится. И вообще, я привык к "излишествам" рожденным С++: перегрузка, неявные приведения типов, объекты...
BZ>вместо C# и Delphi с теоретической точки зрения лучше изучать Eiffel, это дейсвтивительно красивый и мощный язык с чистой ООП идеологией.
А нафиг теоритическая точка зрения не нужна при выборе языков для обучения. Eiffel как и Смолток прошляпили свое время. Так что учить надо C# и Ruby, а про Eiffel и Смолток можно потом (или в процессе) рассказать и сказать, что мол так и так имеют такие-то особенности.
В конце концов проблем у этих языков выше крыши. Тот же Eiffel уступает Немерлу и Spec#-у в олласти декларации инваринатов и пред/пост-условий, так как Eiffel порождает только рантайм-проверки, а Немерле и Spec# повзоляют многое контролировать во время компялции с помощью Буги (утилиты из Spec#).
BZ> руби отличается от него динамической титпизацией, это отдельная парадигма со своими преимуществами и недостатками
Я уже сказал, что Руби и C# являются представителями разных подходов. Причем живыми предтавителями. Можно без проблем найти работу на обоих. Особенно на Шарпе.
BZ>есть. я вроде и говорил про эти два языка, ты не заметил?
Пунктик то?
VD>>С каких пор Пролог стал ФЯ?
BZ>логичнсеколе программирование — тоже мощная, хотя и медлительная парадигма
Парадигм не может быть медленной. Медленные реализации. И понятно почему. Но опять же, то что ЛП интересно не значит, что оно равно ФП. Это разные вещи.
BZ>имхо после выражений нужно переходить к более сложным выражениям
Вот тут мы с тобой расходимся. Я как раз читаю, что выражения — это база. А "сложне выражения" — это фукнциональная надстройка. И ее логично было бы давать параллельно с императивно-объектоориентированной надстройкой. Так человек не прикипит к одной парадигме и раньше поймет истенную суть вещей.
Блни, зать за обучение не платят хороших денег.
VD>>Что касается языка, то я бы как раз выделил на роль первого языка Немерле или Руби. Руби я бы посоветовал тем учетилям которые считают, что вначале людям не надо морочить голову с типизацией, а Немерле тем кто считает, что типизация важнеший аспект. Ну, и по той причине, что на немерле можно показать практически все приемы кроме разве что ЛП.
BZ>вот именно, и ничего хорошего я тут не вижу.
А что плохого? Хрошее же то, что все можно продемонстрировать в чистом виде по одтельности и в смесе.
BZ> мимхо, надо изучать разные параддигмы по их чистым представителям, а не язык, где они как-то сбиты вместе.
Ну, мы уже наблюдали как Хаскель сливает Немерлу .
Так что не надо этой предвзятости. Немерле позволят писать функционально ни чем не хуже чем Хаскель. И что характерно он так же качественно позволяет писать ОО- и иммеративные программы. Единственное существенное отличие от Хаскеля является то что ленивость в Немерле по умолчанию не используется. Но ее без проблем можно использовать там где надо. Так что все концепции объясняются "на ура".
BZ> что касается руби... он очень хорош для некадровых программистов. профессионалы должны думать более систематчисеким путём, они должны жить со сторгой типизщацией в уме, и для них руби будет полезен ближе к концу курса как красивый практический язык
Тут я с тобой полностью согласен. Темоблее, что все приемущества Руби в Немерле имеются по полной. Разве что контюниэшоны по слабей, но это опять таки заслука тинтерпретируемой природы Руби.
Но тут прлема в том, что есть назные учителя с разным взглядом на мир. И вот в том же MIT почему-то считают, что учить на нетипизированных Лиспе и Питоне лучше. В прочем, возможно они просто не видили Немерле .
BZ>а ты собираешься их смешанно давать, типа одно предложение их одной парадигмы, второе из другой?
Я предлагаю давать систематические знания. База — выражения, за которой ветвление в разные подходы. Возможно вообще не называть слова ФП, ИЯ и ООП, а просто демонстрировать паттерны, а затем показвать языковые их реализации. Ну, а когда люди уже освоют все что унжно просто классифицировать полученные знания введя эти самые ФП, ИЯ и ООП и отнеся фичи к ним.
BZ> имхо надо изучить каждую из них — ООП, ФП, ЛП в чистом виде,
И получим то что имеем. Фанатство и частичные знания. А так мы получаем взвешенных и всетаронних специалистов которые не будут орать "ФП фтопку!" или "ФП рулеззз!".
BZ>на чистых языках,
Да, нет в природе чистых языков. Нет вообще. Ты не назавешь мне ни одного языка на котором нельзя было бы писать в другой парадигме. Это все предпочтения. А они при неразумной подаче вызвают фанатизм. Безмозглый тупой фанатизм. Я уже этого на нашем сайте насмотрелся через край. Узкий специалист подобен флюсу. Полнота его одностороння. (с)
BZ> и затем уже идти к тому, как они могут сочетаться. иначе вчедловек, привыкший к ФП-поверх-ООП в Немерле будет *очень* обескуражен ООП-поверх-ФП в окамле, и скорей всего до него долго не дойдёт в чём тут приницпиальная разница
На самом деле единственный побочный эффект который будет при таком подходе — это то, что люди будут с недоверием относиться к "чистым" решениям. Так как будут чйтко осознавать их однобокость и искуственность. Но это, по-моему, как раз большой плюс. Проблемой это может стать только для фанатиков. Им будет трудно расширять свои ряды.
Такие специалисты смогут очень быстро изучать любые новые языки и успешно писать на них. Причем знание все подходов им поможет даже если выбранный язык не поддерживает ту или иную парадигму.
BZ>а ты читал книгу Вадлера или Худака или судишь по Хал-Ван Даму?
Что только я не пробовал читать. ФП по книгам не изучается в принципе. Там один булшит. Ну, разве что ты математик. Тогда может быть и прокатит. ФП изучается только на практике. Нужно освоить один язык где проддерживается ФП и пописать с его использованием. Но конечно же можно написать доступное введение. Просто пока что это никто не сделал. Видимо потоу, что за перо берутся однобокие фанатики созданные такими же однобокими фанатиками.
Можешь попробовать горькую чашу писателей. Может у тебя выйдет выше. Только учти, что если не поборишь догмы которые у тебя тоже есть, то выйдет очередная абракадабра которую прекрасно будут понимать посвященные и снова не поймут начинающие.
VD>>В общем, я виду к тому, что ООП и ФП надо давать параллельно и обязательно как развите стурктурного программирования.
BZ>почему? потому, что ты сам начинал с него?
Потому что я в этом убежден. В отличии от многих я умею остраняться от собственных предпочтений или опыта и давать чистые оценки. Данную мысль я анализировал не раз. И оно является отнюдь не спантанной. Я вижу плоды всех подходов. И вижу ломку сознания и неприятие. Так же сейчас я вижу откуда растут ноги. И считаю, что обучение по тем же направлениям даст людям ясность понимания и предупредит зацикливание.
В общем, это была моя мысль. Не согласен? Ну, и ладно. Один фиг я вряд ли буду кого-то обучать программировать.
BZ> в хаскеле неструктурное программирование вообще трудно поредставить, оно лежит в самой идеологии языка. то же самое в прологе
Хаскль столько же структурен как С даже больше. ЛП конечно другое. Но но то оно и ЛП. Я не призваю изучать ЛП как развитие структуроно подхода. ЛП вообще скорее средство решения конеретного класса задач. Оно по сути ближе к SQL-запросам, когда есть БД и мы пишем запросы отвечающие на те или иные вопрсы. ЛП можно давать как практику программирования вырадившуюся в конеркетный язык.
BZ>я вообще-то предлагал начать с Пролога, поскольку считаю ЛП наиболее высокоуровневой парадигмой.
Боюсь, что у людей сложится неверное отношение к программированию в целом.
BZ> и дальше идти по остальным парадигмам, чтобы человек с самого начала усвоидл каждую из них. но по отдельности, а не в виде nuj бутерброда, которы они приняли в том или ином конкретном языке. иначе он не научится видеть, что здесь принадлежит к ФП, что к ООП, и как их можно соединить иначе или вообще одну из них выкинуть
Еще раз. Я вообще против парадигм в обучении.
BZ>с.п. на данный момент уже можно считать частью ООП.
Ошибочный взгляд, на мой взгляд.
BZ>имхо, ты м сейчас мыслишь в императивном стиле, используя ФП только локально. на что несомненно откладывает отпечаток используемый тобой язык
А мне не надо мыслить функционально. Я мыслю как мыслю. Удобнее так думаю, так удобнее эдак думаю эдак. Остальное догмы.
BZ>т.е. сначала надо научить людей структурному программированию, чтобы они поняли что это бяка и освоили ООП?
Нет. Сначала учить писать выражения. Язык тут монопенисуален:
1 + 2 * (33 + 1)
затем разбавлять их переменными:
def a = 33 + 1;
def b = 1 + 2 * a;
затем дать понятие мзменяемой переменной:
mutable a = 33 + 1;
def b = 1 + 2 * a;
a = 22;
def c = 1 + 2 * a;
это и так будет рвать крышу по началу у всех.
Далее дать if-выражение. Потом if-стэйтмент (надеюсь ты понял о чем я говорю). Ну, и так далее. В конце концом начинаем давать более менее практические задачи. Ну, нарисовать окно. Показываем примитивы рисования и предлагаем создать окно в лоб. Далее предлагаем подумать над тем как создать универсальное окно и плавно подводим к паттенну "объект".
ФП дается примерно так же. Почти игра.
BZ> а перед этим научить их програмимровать на асме, чтобы затем преподнести им идеи стурктурного программирования? а перед этим — в машинных кодах, да?
Отнюдь. Это лишнее. Выражений более чем достаточно.
BZ>твой подход хорош для доучивания людей, которые уже владжеют некоей неэффектвиной парадигмой.
В тебе говорит фанатизм. Не могут быть парадигмы неэффективными. Неэффективными могут быть только человеческие мысли и программы. А парадигмы — это взгляд на проблему. Для одной проблемы лучше подойдет один вгляд, для другой другой. Как минимум с помощью ФП ты не напишешь эффективно сортировки по месту. А с помощью императива получишь неопревданно громоздкий код во многих случаях.
BZ> с нуля же их учить этой парадигме только чтобы продемонстрирвоать её неэффектинвость, нет никакого смысла. их надло сразу учить мыслить в правильном ключе, и pfmtv уже более простые подходы давать только для парктических нужд
В первую очередь нет смысла в фанатичной вере в парадигму. Это маразм и самообман. Человек должен обладать информацией и уметь сделать верный выбор. Вот тогда он будет отличным специалистом, а не фанадом отстаивающим ошибочную точку зрения не смотря ни на что.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
L>>На счет того, что оба варианта — грамматически правильны я и не спорил. Просто было употребелно не то слово.
AVK>Там есть и толковые словари. И употреблено правильно.
, я бы решил, что ты предлагаешь человеку учть *только* "язык на букву N".
Это список того что нужно изучять для расширения кругозора. А начинать надо по любому с одного языка. И только Руби с Немерле подходят для этого. Причем я бы выбрал естественно послелдний.
G>ИМХО, язык всегда заточен под определенную парадигму/стиль/как там еще назвать. Если программировать на нем в ключе этой парадигмы — хорошо, если нет — не очень.. Даже у Н есть свой стиль программирования, который ты так рассхваливаешь.
Ошибашся. Немерле одинаково хорошо поддерижват все стил (кроме ЛП).
Для обучения это самое оно. И это никак не свзяано с предпочтениями в реальном программировании.
G> Друое дело, что в Н очень малы затраты при программировании в чуждом ему ключе (например, строго императивно).
Нет там никаких затрат, так как нет там никаких "чуждых ключей". Он просто поддерживает структуроное програмировани, ООП, ФП, МП.
G>Да и, в конце концов, разные языки учить — это фан
Это кому как. Можно и перегрузить. В общем, я считаю, что перечисленный список хорош для общего развития. И чтобы не зацикливаться на одном решении. А начинать обучать можно и нужно на одном универсальном языке. Вот еще бы ЛП включить. Было бы вообще здорово. Может со временем так и будет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
насчёт case в руби. в его альтернативах можно писать любые значения, которые будут сопоставляться с выюбираемым специальным оператором. определение этого оператора для различнх типов ты можешь написать сам. так что case там программируемый. пример:
case x of
1, 2..5, even -> do_something
/regexp/, "str" -> do_nothing
за синтаксис не отвечаю, я давно им не пользовался. в целом, руби у меня стоит на втором месте в списке любимых после хаскела хотя крупные системы я на нём писать естественно не рекомендую
Здравствуйте, BulatZiganshin, Вы писали:
BZ>насчёт case в руби. в его альтернативах можно писать любые значения, которые будут сопоставляться с выюбираемым специальным оператором. определение этого оператора для различнх типов ты можешь написать сам. так что case там программируемый. пример:
BZ>case x of BZ> 1, 2..5, even -> do_something BZ> /regexp/, "str" -> do_nothing
Сдается мне, что match (сопоставление с образцом) по мощьнее будет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
VD>>>Перебирать из довольно бессмысленно так как они могут иметь разные типы данных. Хотя в макросах их можно и переберать и даже генерировать. К примеру, параметры методов тоже генерируеются как кортежи.
КЛ>>хаха, и что? От этого это становится бесмысленным? Че за бред?
VD>Ну, придумай осмысленную задачу. И вообще, ты же сам сравнивал кортежи со структурами. Тебя не удивляет, что струтуру тоже нельзя перебрать?
так вот если бы кортеж можно было перебрать, то это было бы знач. преимущество над структурой. Иногда очень нужно пребрать поля какой-либо структуры.
VD>Еще интересно почему ты не считашь бредом тот факт, что параметры метода тоже невозможно перебрать (если список фиксирован)?
КЛ>>>> А об их отсутствии (точнее о том, что это плохо и они заменяются кортежами.) я уже писал.
VD>>>(задумчиво) Да, ты много пишешь...
КЛ>>а это к чему? У тебя с этим проблемы? Не читай
VD>Не догадливый?
КЛ>так вот если бы кортеж можно было перебрать, то это было бы знач. преимущество над структурой. Иногда очень нужно пребрать поля какой-либо структуры.
"кортеж с перебором" называется полиморфным списком. в языках типа явы он будет иметь тип что-то типа List<Object>
КЛ>так вот если бы кортеж можно было перебрать, то это было бы знач. преимущество над структурой. Иногда очень нужно пребрать поля какой-либо структуры.
Так во многих языках кортежи без проблем перебираются:
питон:
def aprint(*args):
for arg in args:
print arg
aprint(1, 2, 3, "test")
D:
import std.stdio;
void aprint(A...)(A a)
{
foreach(t; a)
writefln(t);
}
void main()
{
aprint(1, 2, 3, "test");
}
В D кстати и структура легко превращатся в тупл:
import std.stdio;
void aprint(A...)(A a)
{
foreach(t; a)
writefln(t);
}
struct S
{
int x;
char [] msg;
}
void main()
{
static S s = {123, "test"};
aprint(s.tupleof);
}
Здравствуйте, Константин Л., Вы писали:
КЛ>так вот если бы кортеж можно было перебрать, то это было бы знач. преимущество над структурой. Иногда очень нужно пребрать поля какой-либо структуры.
Дык есть языки которые позволяют это сделать. Только перебирать их в рантайме смысла немног. Это делается во время компиляции.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
КЛ>>так вот если бы кортеж можно было перебрать, то это было бы знач. преимущество над структурой. Иногда очень нужно пребрать поля какой-либо структуры.
VD>Дык есть языки которые позволяют это сделать. Только перебирать их в рантайме смысла немног. Это делается во время компиляции.
отлично. Это мне нравится. Я с тобой за немерле уже все видеть перестал
BZ>>"кортеж с перебором" называется полиморфным списком. в языках типа явы он будет иметь тип что-то типа List<Object>
КЛ>не знаю как он там называется, но то что он не есть Java::List<Object> (если я все правильно понял) — это точно. В том то и прокол, чтобы сохранить информацию о типе.
но ведь можно сделать и язык с поддержкой туплов в foreach. для хаскела есть такая библиотека — OOHaskell, если не ошибаюсь, и в ней модуль OOList, реализующий полиморфные списки для хаскела черех туплы. вот такая вот загогулина..
Hi Константин Л.
VD>>Ну, придумай осмысленную задачу. И вообще, ты же сам сравнивал кортежи со структурами. Тебя не удивляет, что струтуру тоже нельзя перебрать?
КЛ>так вот если бы кортеж можно было перебрать, то это было бы знач. преимущество над структурой. Иногда очень нужно пребрать поля какой-либо структуры.
А зачем перебирать надо? Может проще сразу присвоить соответсвующим переменным нужные значения.
Вот тебе пример из Питона
def testFun():
return ("aaa", "b")
(a,b)=testFun()
print a
print b
Да полюбому надо!
Вот банальный пример — тебя не затрахало писать скрипты в формате cmd без возможности обработать исключения?
Наверное да. Python может сделать то же самое, только остановиться если что-то не так.
Ты пробовал делать эксперную систему на строго-типизированном языке? На Prolog это сделать проще — особенно если "мышцы" на ОО языке сделаны.
Ты пробовал сделать анализатор языка на С? А на FP(например haskel)? Что тебе больше по-душе?
КЛ>>так вот если бы кортеж можно было перебрать, то это было бы знач. преимущество над структурой. Иногда очень нужно пребрать поля какой-либо структуры.
BZ>"кортеж с перебором" называется полиморфным списком. в языках типа явы он будет иметь тип что-то типа List<Object>
Кортеж с перебором называется "кортеж", а список списоком. Я еще не видел языков где допускались бы списки с разными типами элементов. Обычно допускаются списки с элементами одного типа в которые можно помещать некие подтипы этого типа. Причем выявлять конкретные типы можно только в рантайме. Что с одной стороные несколько медленее, а с другой может привести к рантайм-ошибкам. К тому же, обычно, кортеежи организуются в памяти как непрерывный кусок памяти, а списки в виде некий ссылочных структур. Это приводит к тому. что кортежи более эффектинвы.
В общем, это разные структуры данных. А то можно и массивом все проблемы решать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi Константин Л.
VD>>>Ну, придумай осмысленную задачу. И вообще, ты же сам сравнивал кортежи со структурами. Тебя не удивляет, что струтуру тоже нельзя перебрать?
КЛ>>так вот если бы кортеж можно было перебрать, то это было бы знач. преимущество над структурой. Иногда очень нужно пребрать поля какой-либо структуры.
AV>А зачем перебирать надо? Может проще сразу присвоить соответсвующим переменным нужные значения. AV>Вот тебе пример из Питона
[]
а может я к каждому элементу шаблонную/generic функцию зааплаить хочу?
Hi Константин Л.
КЛ>>>так вот если бы кортеж можно было перебрать, то это было бы знач. преимущество над структурой. Иногда очень нужно пребрать поля какой-либо структуры.
AV>>А зачем перебирать надо? Может проще сразу присвоить соответсвующим переменным нужные значения. AV>>Вот тебе пример из Питона
КЛ>а может я к каждому элементу шаблонную/generic функцию зааплаить хочу?
Hi VladD2
AV>>Ну если где-то не реализован проход по кортежу, то это не значит, что это вообще невозможно.
V>На само деле он реализован, но только для времени компиляции, где он и имеет смысл. А в рантайме это бессмысленно.
Мне тоже такое не приходилось делать. Но человек просил — ему показали что и такое можно сделать.
V>Приведенный пример на ди тоже производит перебор во время компиляции.
Здравствуйте, ambel-vlad, Вы писали:
AV>А зачем перебирать надо? Может проще сразу присвоить соответсвующим переменным нужные значения. AV>Вот тебе пример из Питона
AV>
AV>def testFun():
AV> return ("aaa", "b")
AV>(a,b)=testFun()
AV>print a
AV>print b
AV>
Извини, но это просто возврат кортежа из метода. Это любой язык поддерживающий кортежи поддерживает. Тут никакого перебора нет и в поминке.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AV>>А зачем перебирать надо? Может проще сразу присвоить соответсвующим переменным нужные значения. AV>>Вот тебе пример из Питона
AV>>
AV>>def testFun():
AV>> return ("aaa", "b")
AV>>(a,b)=testFun()
AV>>print a
AV>>print b
AV>>
VD>Извини, но это просто возврат кортежа из метода.
Плюс декомпозиция "на лету" (я не спорю, а уточняю. я не в курсе, есть ли языки, поддерживающие кортежи, но не поддерживающие их inline-декомпозицию).
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Плюс декомпозиция "на лету" (я не спорю, а уточняю. я не в курсе, есть ли языки, поддерживающие кортежи, но не поддерживающие их inline-декомпозицию).
Думаю, что нет. Это родом из ML-я. Так что все кто драли кортежи содрали и идею его декомпозиции. Хотя в C# 3.0 будут аналоги кортэжей (анонимные типы) в которых не будет декомпозиции, но элементы будут именованными. Глобальная глупость решения МС в том, что анонимные типы нельзя будет описать. Они могут быть только выведены компиляторо из использования. Но это не позволяет использовать и для возврата данных и методов. Что, на мой взгляд, является откровенным дизайнерским промахом. Причем обосновывается он тем, что мол для этого прийдется менять рантайм дотнета. И это особснование?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Глобальная глупость решения МС в том, что анонимные типы нельзя будет описать.
А какой смысл в описании анонимных типов? Можешь пример использования привести?
И какой синтаксис тебе видится? На манер анонимных делегатов?
Здравствуйте, EvilChild, Вы писали:
VD>>Глобальная глупость решения МС в том, что анонимные типы нельзя будет описать. EC>А какой смысл в описании анонимных типов? Можешь пример использования привести? EC>И какой синтаксис тебе видится? На манер анонимных делегатов?
Главное, что проблема стоит выеденного яйца. Вариант туплов в Н не требует никакой рантайм поддержки и не имеет таких проблем.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>ну, и совместимасть по совпадению типа и имени поля.
По типу было бы достаточно — структурная эквивалентность. Было бы действительно полезно. VD>Короче огнаниченная утиная типизация.
Утиная типизация вроде как предполагает позднее связывание, если не брать в расчёт C++ templates,
а здесь всё статически можно проверить или я что-то путаю?
Здравствуйте, IT, Вы писали:
IT>Главное, что проблема стоит выеденного яйца. Вариант туплов в Н не требует никакой рантайм поддержки и не имеет таких проблем.
И при этом CLS compliant?
Можешь привести пример использования?
Здравствуйте, IT, Вы писали:
IT>Именно так эти структуры и видны из внешнего кода. Сам же компилятор просто обеспечивает встроенную, более удобную работу с этими структурами.
Т.е. когда мы возвращаем экземпляр анонимного типа, компилятор молчаливо создаёт в метаданных новый тип и это дело можно спокойно юзать в публичных интерфейсах сборки? Имена наверное стрёмные? Как у перечислителей, что C# компилятор создаёт? А если мы из 2х методов возвращаем структурно эквивалентные типы он их сведёт к одному в метаданных?
Здравствуйте, EvilChild, Вы писали:
IT>>Именно так эти структуры и видны из внешнего кода. Сам же компилятор просто обеспечивает встроенную, более удобную работу с этими структурами. EC>Т.е. когда мы возвращаем экземпляр анонимного типа, компилятор молчаливо создаёт в метаданных новый тип и это дело можно спокойно юзать в публичных интерфейсах сборки? Имена наверное стрёмные? Как у перечислителей, что C# компилятор создаёт? А если мы из 2х методов возвращаем структурно эквивалентные типы он их сведёт к одному в метаданных?
Здравствуйте, IT, Вы писали:
IT>Эти типы представляют из себя буквально то, что я написал. Т.е. это просто generic типы, которых тупо набито в библиотеки поддержки компилятора примерно до 20 штук. Соотвественно, из других .NET языков они так и будут видны. Например, в Н:
Вижу, это я протупил. Тогда действительно странно почему разработчикам C# это не сделать.
Я правильно понимаю, что если мы воспользовались этой фичей, то мы попадаем на деплоймент библиотеки поддержки?
now playing: Future Prophecies — Miniamba (featuring Mari Boine)
Здравствуйте, Shisaa, Вы писали:
S>Даже если не будешь использовать сам Форт, то советую ее прочитать, помогает правильно мыслить при написании программ.
Раскрыт сикрет мастера Йоды: "Программист форте на старый он."
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, VladD2, Вы писали:
VD>>ну, и совместимасть по совпадению типа и имени поля. EC>По типу было бы достаточно — структурная эквивалентность. Было бы действительно полезно.
Это был бы еще один косяк. Делая "а" (вводя имена у полей), надо делать и "б" (учитывать их при сопоставлении).
Проблема в том, что без изменения рантайма (по словам Хейслсберга) сопсоставление сдаелать нельзя. А менять рантайм они что-то боятся. В общем, прогнали лажу, на мой взгляд.
VD>>Короче огнаниченная утиная типизация. EC>Утиная типизация вроде как предполагает позднее связывание,
Нет. Она предпологает сопоставление по именам. Объект (или тип) должен всего лишь крякать как утка, плавать как утка и летать как утка.
EC>если не брать в расчёт C++ templates, EC>а здесь всё статически можно проверить или я что-то путаю?
Путаешь. Шаблоны С++ работают на уровне АСТ на котором типизации еще просто нет. С их помощью генерирвется АСТ которое уже в готовом виде типизируется. Учитывая отсуствие поддержки компонентности это в С++ прокатывает. В дотнете это не прокатывает, так как типы должны храниться в бинарном виде (типизированными по определению). Так что решение из С++ тут никак не катит. Но можно просто подменять типы имеющие одну и ту же структуру в рантайме. Скажем загружается сборка использующая анонимный тип { string Name; DateTime Age } который уже был загружен другой сборкой... рантайм определяет это и подменяет ссылку на тип той что была порождена первой сборкой.
Собственно это и есть изменение которое нужно сделать в рантайме. Если предполжить, что код рантайма хорошо струтурирован и спокойно подвергается расширения, то это работа на день (максимум неделю). Так что зачем в МС прогоняют лажу я понять не могу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Главное, что проблема стоит выеденного яйца. Вариант туплов в Н не требует никакой рантайм поддержки и не имеет таких проблем.
Проблема в том, что они выбрали другой дизайн, но не смогли его довести до ума при воплощении в жизнь.
А сам дизайн, в общем-то, выглядит даже лучше чем кортежи из из ФЯ... на мой взгляд.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, Java2, Вы писали:
TI>>>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
J>>Друг, здесь мнений много, но послушай и моё. С помощью таких вещей как Java или C# уже можно зарабатывать миллионы долларов.
K>Миллионы долларов проще заработать при помощи нефти/банков/героина, etc. А вот с Java/C# заработать миллионы крайне трудно. Если только самому не основать мегакорпорацию, в которой мартышки будут за ломоть хлеба писать на Java/C#
Честным путём деньги везде трудно зарабатывать и под силу только сильным людям.
J>>Мой тебе совет: заработай их, а потом решай, нужно тебе что-то или нет, т.е. отталкивайся от цели к средствам, а не от средств в поисках цели. Жинь коротка, а дни лукавы и обманчивы, стоит ли её тратить на все языки мира или лучше это время подарить своей семье?
K>
K>Иногда нужно уделить своё время самосовершенствованию. Хотя бы для того, чтобы в будущем заработать больше денег за меньшее время, и подарить сэкономленное время (и деньги) семье. В этом вопросе поможет только здравый смысл. Главное — не ударяться в крайности.
K>Нельзя "лучше изучить" Java/C#. Можно только стать лучшим специалистом. А для этого, в том числе, нужно и расширить кругозор. Причём это касается не только языков, и даже не только программирования.
Здравствуйте, VladD2, Вы писали:
VD>Возврат значения из метода. Сделал ты красивый запрос через LINQ и хочешь поместить его в фукнцию. Ан та тебе — нельзя. Ведь запрос твой возвращает анонимный тип.
Запрос совсем не обязан возвращать именно анонимный тип. Для публичных контрактов вполне можно кортеж и явно описать. Единственное, где были бы полезны анонимные типы снаружи метода — в пределах одного класса. И тут, наверное, можно было бы реализовать подобное и без правки рантайма.
Здравствуйте, AndrewVK, Вы писали:
AVK>Запрос совсем не обязан возвращать именно анонимный тип.
Ни кто и не спорит. Вопрос только в том, что описать тип кортежа можно по месту в описании фукнции. А описать отдельный класс это геборой. Да и не будут совместимы иэти типы (анонимный и такой же, но явный). В общем, это криво.
AVK> Для публичных контрактов вполне можно кортеж и явно описать.
Дык нельзя. Нет такой возможности. Можно только классы описывать. А это несколько не то.
AVK> Единственное, где были бы полезны анонимные типы снаружи метода — в пределах одного класса. И тут, наверное, можно было бы реализовать подобное и без правки рантайма.
Анонимные типы были бы полезны везде. Текущее решение — это банальная недоработка.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alexander_S_U, Вы писали:
A_S>Здравствуйте, Lloyd, Вы писали:
L>>Здравствуйте, Timur I., Вы писали:
TI>>>Здравствуйте! TI>>>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
L>>Имхо, стоит.
A_S>Какие языки из "альтернативных" для общего развития посоветуете?
Здравствуйте, VladD2, Вы писали:
AVK>>Запрос совсем не обязан возвращать именно анонимный тип.
VD>Ни кто и не спорит. Вопрос только в том, что описать тип кортежа можно по месту в описании фукнции.
Ну да. Но когда кортеж является частью публичного контракта, делать этого в любом случае не стоит. Остаются приватные, и, возможно, internal методы. Но в таком раскладе править рантайм нет нужды.
VD> А описать отдельный класс это геборой. Да и не будут совместимы иэти типы (анонимный и такой же, но явный).
А зачем нужен анонимный, если уже есть явный?
AVK>> Для публичных контрактов вполне можно кортеж и явно описать.
VD>Дык нельзя. Нет такой возможности. Можно только классы описывать.
А линковский кортеж это и есть банальный класс и ничто иное. И в этом, кстати, одно из его полезных свойств, потому что другие реализации кортежей порождают код вроде x = tuple(0) или x = tuple.First вместо линковского x = tuple.X.
Здравствуйте, IT, Вы писали:
IT>Главное, что проблема стоит выеденного яйца. Вариант туплов в Н не требует никакой рантайм поддержки и не имеет таких проблем.
И как они обеспечили совместимость туплов между сборками. И что насчет именованных элементов кортежа? Нет, ну то есть я понимаю что все это сделать при желании можно, интересно как это выглядит в реальности.
Здравствуйте, AndrewVK, Вы писали:
AVK>И как они обеспечили совместимость туплов между сборками. И что насчет именованных элементов кортежа? Нет, ну то есть я понимаю что все это сделать при желании можно, интересно как это выглядит в реальности.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, IT, Вы писали:
IT>>Главное, что проблема стоит выеденного яйца. Вариант туплов в Н не требует никакой рантайм поддержки и не имеет таких проблем.
AVK>И как они обеспечили совместимость туплов между сборками. И что насчет именованных элементов кортежа? Нет, ну то есть я понимаю что все это сделать при желании можно, интересно как это выглядит в реальности.
Здравствуйте, nikov, Вы писали:
N>См. здесь внизу страницы.
def x = tup[1];
Вот с моей точки зрения это весьма ухудшает читаемость кода, бо все эти числовые константы при беглом взгляде ни о чем не говорят. Вон для шарпа тоже можно налепить комплект Tuple<T1..Tn>, только это не очень хорошее решение ИМХО.
Здравствуйте, IT, Вы писали:
AVK>>Я там не увидел ситуации когда мне нужно обратится к единственному полю, не объявляя промежуточных переменных.
IT>Ты о C# или о Немерле? Честно говоря не совсем понимаю проблему.
О немерле. Проблема в появлении всяких tuple[6].
AVK>>P.S. Вчера весь вечер пытались до тебя достучаться — ты в MSN бываешь?
IT>Бывают, но мой вечер наступает в твои 3 часа ночи.
А пораньше никак? Нужно уже обговорить план мероприятий.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну да. Но когда кортеж является частью публичного контракта, делать этого в любом случае не стоит.
Почему не стоит? Потому что в C# нельзя, что ли?
AVK> Остаются приватные, и, возможно, internal методы. Но в таком раскладе править рантайм нет нужды.
Вообще-то в дотнете в метаданные экспортируются все описания вне зависимости от того являются ли они публичными или нет. Возможно это не правильно, но...
VD>> А описать отдельный класс это геборой. Да и не будут совместимы иэти типы (анонимный и такой же, но явный).
AVK>А зачем нужен анонимный, если уже есть явный?
Чтобы ради результата запроса не вводить новый класс.
Это точно так же как намного удобнее определить параметр функционального типа по месту:
Find[T](predicate : T -> bool) : IEnumerable[T];
а не описывать левый делегат, и потом использовать его в качестве параметра:
Хотя все же делегат ведь довольно компактная, не то что тип.
AVK>>> Для публичных контрактов вполне можно кортеж и явно описать.
VD>>Дык нельзя. Нет такой возможности. Можно только классы описывать.
AVK>А линковский кортеж это и есть банальный класс и ничто иное.
Не. ЛИНКовский анонимный тип — это урод кастрированный. Его не описать не использовать публично нельзя. Да и кортежем он не является. По крайней мере он явно не тянет на то что понимается под кортежами в ФЯ. В общем, это нечто странное. Некий сахар для упрощения синтаксиса запросов в ЛИНКе.
AVK> И в этом, кстати, одно из его полезных свойств, потому что другие реализации кортежей порождают код вроде x = tuple(0) или x = tuple.First вместо линковского x = tuple.X.
Серьезно? А я все по старинке декомпозицией пользуюсь.
def (a,b,c) = tuple;
Понимаеш ли, в чем дело... Если бы в МС взяли за основу нормальные кортежи, то им вообще изобретать велосипед не пришлось бы. Ведь их запросы просто кортежи и возвращали бы. Все было бы прозрачно.
В прочем я могу понять выбор именованных полей вместо позиционного доступа. Но я не могут понять почему я не погу описать тип типа. Это извините лажа и бред. И это им еще не раз аукнется. Булшит про нежелание менять рантайм пусть тоже своему начальству рассказвают. У них несколько лет было чтобы его изменить.
Единственное что они могут сделать, так это исправить эту лажу в одной из следующих версий С# введя таки возможность описывать эти типы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Ну да. Но когда кортеж является частью публичного контракта, делать этого в любом случае не стоит.
VD>Почему не стоит? Потому что в C# нельзя, что ли?
Потому что контракт должен быть отделен от реализации, а по хорошему должен допускать множественные реализации одного котракта. А не как у МС — вот есть одна реализация XmlDocument, к примеру, и нифига ты с этим не поделаешь. Можно написать новую, но при этом все алгоритмы, рассчитаные на XmlDocument шатный идут лесом. Они сами на этом обожглись по полной программе с XLInQ.
AVK>> Остаются приватные, и, возможно, internal методы. Но в таком раскладе править рантайм нет нужды.
VD>Вообще-то в дотнете в метаданные экспортируются все описания вне зависимости от того являются ли они публичными или нет.
Да это заради бога. Совместимости при этом кортежей между сборками все равно не нужно. Анонимные методы, вон, тоже в метаданные попадают, однако это не означает что их можно статически использовать снаружи.
AVK>>А зачем нужен анонимный, если уже есть явный?
VD>Чтобы ради результата запроса не вводить новый класс.
Так он уже введен, зачем еще один вводить?
AVK>>А линковский кортеж это и есть банальный класс и ничто иное.
VD>Не. ЛИНКовский анонимный тип — это урод кастрированный. Его не описать не использовать публично нельзя.
Он для другого сделан.
VD> Да и кортежем он не является.
Он не является кортежом в том смысле, который ты ему присвоил. А вобще термин кортеж появился очень давно. Вектор-строка это тоже кортеж, и запись в таблице БД это тоже кортеж. И анонимный тип в шарпе это тоже кортеж, поскольку является как раз той сущностью, которая соответствует кортежу в источнике данных. Так что давай не будем переходить на спор о терминах.
VD> По крайней мере он явно не тянет на то что понимается под кортежами в ФЯ.
Разумеется. А этого никто и не утверждал.
VD> В общем, это нечто странное. Некий сахар для упрощения синтаксиса запросов в ЛИНКе.
Именно он и есть. То, что хочешь ты с текущей идеологией шарпа несовместимо. При разрешении анонимных типов нужно прежде всего разрешать вывод типов по последующему использованию и разрешение вывода в декларациях класса, а не только внутри метода. А это, в свою очередь, уже совершенно другой дизайн, нежели предложенный в новом шарпе. Ты конечно можешь сколько угодно осуждать авторов за дизайн целиком, но выдергивать одну фичу и думать, что ее можно было сделать совсем по другому, это не очень конструктивно.
Теперь что касается изменений фреймворка. Я тебе это уже говорил, но повторю — все не так просто, как ты думаешь. Это прежде всего промышленное программирование со своими заскоками. Есть ряд причин, по которым нельзя менять рантайм (и не все из них я могу публично озвучить). И не может команда C# по своему усмотрению вот так просто это решение отменить.
AVK>> И в этом, кстати, одно из его полезных свойств, потому что другие реализации кортежей порождают код вроде x = tuple(0) или x = tuple.First вместо линковского x = tuple.X.
VD>Серьезно? А я все по старинке декомпозицией пользуюсь.
Поздравляю. Только проблемы это не отменяет. Один черт ты эти abc каждый раз по новой объявляешь.
VD>Единственное что они могут сделать, так это исправить эту лажу в одной из следующих версий С# введя таки возможность описывать эти типы.
Насколько я в курсе, таких планов нет. Впрочем, я могу в очередной раз попинать товарищей из соответствующего тима. Но вряд ли от этого будет толк.
Здравствуйте, AndrewVK, Вы писали:
VD>>Почему не стоит? Потому что в C# нельзя, что ли?
AVK>Потому что контракт должен быть отделен от реализации, а по хорошему должен допускать множественные реализации одного котракта.
А, ну, это многое обясняет. Я уже понял, что если слышишь слово "контракт" то сейчас начнут обосновывать что-то страшеное.
Если серьезно, то я не понял причем тут реализация? Мы говорим о введении в язык типа данных который невозможнона этом языке описать (выразить). То есть компилятор этот тип может вывести из использования, но программист его поисать не в силах. Если же этот программист попробует получить описание с помощью рефлексии, то получит кучу деталей реализации — грязи то бишь.
AVK> А не как у МС — вот есть одна реализация XmlDocument, к примеру, и нифига ты с этим не поделаешь. Можно написать новую, но при этом все алгоритмы, рассчитаные на XmlDocument шатный идут лесом. Они сами на этом обожглись по полной программе с XLInQ.
Опять не понял причем тут кривое проектрование кокретной библиотеки. Вроде бы речь то шла о кривом проктировнии (точнее недоделанности) языка. Не уж то анонимные типы помогли бы XmlDocument спроектирвать лучше?
VD>>Чтобы ради результата запроса не вводить новый класс.
AVK>Так он уже введен, зачем еще один вводить?
Где это они введены? У меня каждый запрос может порождать отдельный класс. Точнее конечно кортеж. Или я буду вынужден делать классы заведомо избыточные и все время проверять заполненность полей. Или я вынжден клепать тонну левых классов (как компилятор). Что глупо.
VD>>Не. ЛИНКовский анонимный тип — это урод кастрированный. Его не описать не использовать публично нельзя.
AVK>Он для другого сделан.
Я в курсе. Еще мама учила не делать уродов ради частных случаев, а пытаться делать гормоничный дизайн. Вот этого я и не вижу. Причем не вижу причины зачем так делать.
VD>> Да и кортежем он не является.
AVK>Он не является кортежом в том смысле, который ты ему присвоил.
Точнее будет сказать в том смысле в ктором его принято употреблять в сообществе функциоальных программистов.
AVK> А вобще термин кортеж появился очень давно.
Он вообще-то из математики (реаляционной алгебры). Вот только там он имеет тип и его можно описать. Даже в БД записи можно описать (хотя и не всегда чисто). А тут получается тип есть, а описать его нельзя. Тлько вывести из использования. Не красыво как-то.
AVK>Вектор-строка это тоже кортеж,
Нет конечно. Не придумывай.
AVK> и запись в таблице БД это тоже кортеж.
Вот это да. Но ее таки мы может описать и создать без вывода типов.
AVK> И анонимный тип в шарпе это тоже кортеж, поскольку является как раз той сущностью, которая соответствует кортежу в источнике данных.
Не совсем. Точнее кострированный. Его нельзя создать и его нельзя описать. Ну, да я уже повтояюсь.
AVK> Так что давай не будем переходить на спор о терминах.
Давай. В МС назвали это анонимным типом. Это сооветствует этому делу и по сути, и по реализации. И перепутать с кортежами нельзя. Вот и давай придерживаться этой терминлогии. А когда они добавят возомжность описать этот анонимный тип, то можно будет обсудить его эфвивалентность кортежам из других ЯП.
AVK>Именно он и есть. То, что хочешь ты с текущей идеологией шарпа несовместимо.
Обоснуй.
AVK> При разрешении анонимных типов нужно прежде всего разрешать вывод типов по последующему использованию и разрешение вывода в декларациях класса, а не только внутри метода.
С кагого боку? Нужна возможность описать тип, а так же чтобы рантайм считал все типы с одинаковым описанием одинаковыми. И все! Никаких ограничений на вывод типо ненужно. Более того тогда появится возможность ипользовать их в языках где вобще нет вывода типов.
AVK>Ты конечно можешь сколько угодно осуждать авторов за дизайн целиком, но выдергивать одну фичу и думать, что ее можно было сделать совсем по другому, это не очень конструктивно.
Весьма странный и не обоснованный вывод.
AVK>Теперь что касается изменений фреймворка. Я тебе это уже говорил, но повторю — все не так просто, как ты думаешь.
На что я тебе отвечал, что справился бы за неделю сам лично.
AVK> Это прежде всего промышленное программирование со своими заскоками.
О! Оставл эти магические базворды для кого-то с более обвисшими ушами.
Меня больше интересуют доводы и файты.
AVK> Есть ряд причин, по которым нельзя менять рантайм (и не все из них я могу публично озвучить).
Это смешно. Ей богу.
AVK>И не может команда C# по своему усмотрению вот так просто это решение отменить.
Как я понял LINQ — это не просто проект команды C#. Да и средства ФП в Шарпе и Васике появляются точно не только для LINQ. Так что уж могли бы они как-нибудь между собой договориться. А если у них там есть капризные менеджеры которые как взбалмошные барашни заявляют "неть! не дадим кромсать рантайм", то это уже их личные проблемы. Кривизну половинчатого решения это не изменяет.
VD>>Серьезно? А я все по старинке декомпозицией пользуюсь.
AVK>Поздравляю. Только проблемы это не отменяет. Один черт ты эти abc каждый раз по новой объявляешь.
Хм. Дык в запросе это просто перечесление имен полей кторые я возращаю. Синтаксический сахар вроде LINQ-а может их сам задавать выводя из имен полей или из конструкций вроде SQL-ых "as".
VD>>Единственное что они могут сделать, так это исправить эту лажу в одной из следующих версий С# введя таки возможность описывать эти типы.
AVK>Насколько я в курсе, таких планов нет.
Тем хуже для них. Хотя судя по многозначительным словам из приведенной тут статьи "сумашедшего ученого" — "это остается предметом для дальнейших исследований" — похоже ребата из МС и сами все это понимают, и просто еще не нашли полностью подходящего решения. Возможно просто спорят.
AVK>Впрочем, я могу в очередной раз попинать товарищей из соответствующего тима. Но вряд ли от этого будет толк.
На самом деле, если все действительно так плохо, то пинать надо. Причем пинать обязательно и беспощадно. Ведь если есть шанс повлиять на плохое решение, то его обязательно надо использовать. Уверен, что мы не одни кто понимает, что такая половинчатасть — это плохо. Так что даже слабенький пинок может привести к сдвижке решения в правильную сторону.
Так что я лично бы пинал бы как только мог бы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
AVK>>О немерле. Проблема в появлении всяких tuple[6].
N>Да, сейчас можно только или через промежуточную переменную, или по индексу.
Еще как вариант кортеж можно передать методу с соотвествующим списком параметров что список полей кортежа.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
AVK>Вот с моей точки зрения это весьма ухудшает читаемость кода, бо все эти числовые константы при беглом взгляде ни о чем не говорят. Вон для шарпа тоже можно налепить комплект Tuple<T1..Tn>, только это не очень хорошее решение ИМХО.
Не очень хорошее решение — это на каждый чих создавать новый класс или использовать out/ref параметры. Сбаиндить тупл с локальными переменными не так смертельно.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Не очень хорошее решение — это на каждый чих создавать новый класс или использовать out/ref параметры. Сбаиндить тупл с локальными переменными не так смертельно.
Ну, скажем так, тут я с тобой не соглашусь. Но это уже отчасти вопрос вкусов и приоритетов.
Hi IT AVK>>def x = tup[1];
AVK>>Вот с моей точки зрения это весьма ухудшает читаемость кода, бо все эти числовые константы при беглом взгляде ни о чем не говорят. Вон для шарпа тоже можно налепить комплект Tuple<T1..Tn>, только это не очень хорошее решение ИМХО.
IT>Не очень хорошее решение — это на каждый чих создавать новый класс или использовать out/ref параметры. Сбаиндить тупл с локальными переменными не так смертельно.
В этом отношении мне нравиться как сделано в Питоне
(a,b)=Fun()
где a,b — локальные переменные. И перебор не надо.
Здравствуйте, ambel-vlad, Вы писали:
AV>В этом отношении мне нравиться как сделано в Питоне AV>
AV>(a,b)=Fun()
AV>
AV>где a,b — локальные переменные. И перебор не надо.
В Nemerle тоже можно так. Более того, с левой стороны можно использовать любой образец (pattern). Например, если на этапе компиляции известно, что второй элемент кортежа — список, то можно написать так:
Здравствуйте, AndrewVK, Вы писали:
AVK>Но надо понимать, что, при сохранении собственно LInQ в языке, такие кортежи обязательно приведут к существенной ломке рантайма, прежде всего к появлению first class сущности.
А в чём проблема создать внутренний паблик класс и выставить наружу его? Нужно только подумать о наименовании.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, nikov, Вы писали:
IT>>А в чём проблема создать внутренний паблик класс и выставить наружу его? Нужно только подумать о наименовании.
N>Хе-хе! А сколько он параметров будет иметь? Или надо будет накладывать искусственное ограничение на количество элементов к кортеже?
Каких параметров?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
IT>>А в чём проблема создать внутренний паблик класс и выставить наружу его? Нужно только подумать о наименовании.
AVK>А дальше? Как заставить tuple1.GetType() == tuple2.GetType() вернуть true, если tuple1 и tuple2 совместимы по сигнатуре, но при этом физически это два разных класса?
Вопрос зачем это надо?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>А в чём проблема создать внутренний паблик класс и выставить наружу его? Нужно только подумать о наименовании.
N>>Хе-хе! А сколько он параметров будет иметь? Или надо будет накладывать искусственное ограничение на количество элементов к кортеже?
IT>Каких параметров?
Может быть, я не понял тебя... Какой тип ты предлагаешь создать и выставить?
Здравствуйте, IT, Вы писали:
IT>Вопрос зачем это надо?
Чтобы кортежи, использованные в разных сборках, но совместимые по сигнатуре, были совместимы между собой. Т.е. для того же, для чего duck typing между делегатами и методами.
Здравствуйте, nikov, Вы писали:
N>Может быть, я не понял тебя... Какой тип ты предлагаешь создать и выставить?
Насколько я понимаю, сейчас создаётся private internal класс для таких анонимных типов, который соответственно доступен только внутри класса. Если решить вопрос с именованием этого типа, то можно его делать не private, а public и смело выставлять наружу.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
IT>>Вопрос зачем это надо?
AVK>Чтобы кортежи, использованные в разных сборках, но совместимые по сигнатуре, были совместимы между собой. Т.е. для того же, для чего duck typing между делегатами и методами.
Вот я и спрашиваю зачем это надо.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Насколько я понимаю, сейчас создаётся private internal класс для таких анонимных типов, который соответственно доступен только внутри класса. Если решить вопрос с именованием этого типа, то можно его делать не private, а public и смело выставлять наружу.
Значит, я неверно понял вначале. Тогда игнорируй то мое замечание.
Здравствуйте, AndrewVK, Вы писали:
IT>>Вот я и спрашиваю зачем это надо.
AVK>Ну, типа, чтобы не был "кастрированный кортеж" (С).
Ну понятно.
Вообще, конечно, сранное решение. Не то чтобы я переживал как Влад, но чесно говоря, если нельзя выставить такой тип наружу, то чисто с практической точки зрения такая фича видится мне пока совершенно бесполезной, хотя возможно я и не прав Столько усилий непонятно ради чего.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Вообще, конечно, сранное решение. Не то чтобы я переживал как Влад, но чесно говоря, если нельзя выставить такой тип наружу, то чисто с практической точки зрения такая фича видится мне пока совершенно бесполезной, хотя возможно я и не прав Столько усилий непонятно ради чего.
Ну ради чего как раз понятно. Анонимные типы придумывались ради query comprehension, чтобы текст запроса был читаем и с минимумом "синтаксического оверхеда"(С). Но Владу очень хотется и ФПшные кортежи.
VD>Я в курсе. Еще мама учила не делать уродов ради частных случаев, а пытаться делать гормоничный дизайн. Вот этого я и не вижу. Причем не вижу причины зачем так делать.
AV>>В этом отношении мне нравиться как сделано в Питоне AV>>AV>(a,b)=Fun() AV>>
AV>>где a,b — локальные переменные. И перебор не надо.
n>В Nemerle тоже можно так. Более того, с левой стороны можно использовать любой образец (pattern). Например, если на этапе компиляции известно, что второй элемент кортежа — список, то можно написать так:
n>def (x, h :: t) = Fun();
Спасибо. Буду знать что в Nemerle тоже так можно сделать.
Здравствуйте, IT, Вы писали:
IT>Насколько я понимаю, сейчас создаётся private internal класс для таких анонимных типов, который соответственно доступен только внутри класса. Если решить вопрос с именованием этого типа, то можно его делать не private, а public и смело выставлять наружу.
private internal — не бывает. Но это так... мелкое замечание.
По сути же... проблема в том, что классы в разных сборках должны быть совместимы.
Если мы, скажем, создали в одной сборке анонимный тип { DateTime Age; string Name; }, то нам надо, чтобы если в другой сборке будет такой же, то чтобы мы могли передать экземпляр этого туда. А если каждая сборка для реализации нашего анонимного типа создаст по классу, то они (по правилам дотенета) окажутся несовместимыми.
Проблема решается прой if-ов в загрузчеке типов дотнета. Надо просто тупо проверять не загружен ли уже такой тип и если загружен все отсальные вхождения подменят на первый. Но это изменение в рантайме, а по словам АВК Хейлсберг и ко. говорят что по не озвученым причинам они не хотят править рантайм.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну ради чего как раз понятно. Анонимные типы придумывались ради query comprehension, чтобы текст запроса был читаем и с минимумом "синтаксического оверхеда"(С). Но Владу очень хотется и ФПшные кортежи.
Честно говоря теперь не то что бы очень хотелось. Откровенно говоря сейчас возвращаться на Шарп нет никакого желания. Я уж лучше потерплю позиционные кортежи.
Просто мне всегда не нравятся половинчатые решения приводящие к решению частных проблем, но не пригодных ни для чего больше (хотя очевидно полезных и для других задач).
В прочем хардкодинг query comprehensions сам по себе решение кривое. Но хотя бы поняты основания почему это так.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>Насколько я понимаю, сейчас создаётся private internal класс для таких анонимных типов, который соответственно доступен только внутри класса. Если решить вопрос с именованием этого типа, то можно его делать не private, а public и смело выставлять наружу.
VD>private internal — не бывает. Но это так... мелкое замечание.
Под internal имелся ввиду класс, вложенный в другой класс.
VD>По сути же... проблема в том, что классы в разных сборках должны быть совместимы.
Я понимаю проблему. Вопрос, проблема ли это и нужно ли её решать.
Если нам не помогут, то мы тоже никого не пощадим.
Hi IT
AV>>P.S. Правда, слишком рьяно идет здесь реклама Nemerle. Даже отбивает желание смотреть на это.
IT>То что мы наблюдаем, это не ръяная реклама, а просто восторг по поводу "Бритни"
Возможно это связано с личным восприятием каждого участника форума. Но у меня большинство моментой касающихся Nemerle на данном форуме ассоциируется именно с рекламой.
AV>>Но я сволочь любознательная — при возможности попробую посмотреть.
IT>Посмотри.
Посмотреть-то посмотрю как-нибудь. Но к моим текущим задачам его никак не приложить будет. Поэтому только в свободное время (которого катастрофически не хватает). К моим текущим задачам скорее приложим OCaml
Здравствуйте, IT, Вы писали:
VD>>По сути же... проблема в том, что классы в разных сборках должны быть совместимы.
IT>Я понимаю проблему. Вопрос, проблема ли это и нужно ли её решать.
В текущем варианте имеется просто недоделанность приводящая к тому, что анонимные типы мало на что годны и применяются в основном только для LINQ-запросов.
Если поступить как предлагаешь ты, то будет уже явный косякт который уже потом будет невозможно исправить не внося ломающие изменения.
Правильным решением было бы внести измеения в рантайм. Там дело вто на день.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ambel-vlad, Вы писали:
AV>Посмотреть-то посмотрю как-нибудь. Но к моим текущим задачам его никак не приложить будет. Поэтому только в свободное время (которого катастрофически не хватает). К моим текущим задачам скорее приложим OCaml
Ты бы все же сначала поглядел о чем рассуждаешь. А то забавно получается. Nemerle по сути клон O'Caml с С-подобным синтаксисом, но O'Caml тебе подходит, а Nemerle нет. Парадокс одноако.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Опять же вопрос. Стоит ли эта фича того, что бы из-за неё менять рантайм?
Что такое кортежи ты знаешь. Анонимные типы в Шарпе были бы их аналогами если бы были реализованы полноценно. Ну, а стоит ли их вводить ты сам можешь сказать. Мое мнение — стоит. Правда я лично предпочел Немерловый варинат. Он может и имеет гипотетическую проблему — значения можно перепутать, так как они позиционные, но на практике я таких проблем не видел. Дополнительные же выгоды очевидны: совместимость со список параметров, легная копоциция, декомпозиция (патетрн-мтачинг) и т.п. Правда вряд ли все это будет в Шарпе. Плюс, похоже, в Шарпе их хотя сделать изменяемыми, а это убивает возможность использовать их как замену вэлью-типам. Помнишь, как ты заменил одну переменуню на кортеж и все продолженло работать далее? Вот тут может быть облом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, awson, Вы писали:
VK>>Но при этом все равно обладать теми самыми ограничениями, о которых говорит VladD2. A>Какими, черт подери, ограничаниями? Написано же — typeclasses. В том виде, как они поддерживаются в GHC (multiparameter typeclasses + fundeps), они не просто обеспечивают перегрузку, а вообще позволяют программировать внутри системы типов.
Программировать внтури системы типов позволяет и С++. Достоинством только это не является. Скоре недостатком.
Базворды же вроде "multiparameter typeclasses + fundeps" мало чего говорят окружающим.
Возможно конечно, что те описания Хаскеля которые я читал сильно устарели или попросту врут, но в них четко описывалось, что перегризить функцию по количеству параметров в Хаскеле невозможно. И приведения типов могут быть только явные. Если это не так, то продемонстрируй обратное. И по возможность без базвородов, а на практических примерах и доходчиво.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это пустой треп. Факт остается файктом. Хаскелевская система типов основана на системе типов Хиндли-Миллера и переняла у нее все ее недостатки. То что она была расширена — это уже к делу не отностися.
VD>Да хоть колеса от карьерного самосвала. Такиех вещей как перегрузка фукнций, неявное привдение типов система типов Хаскеля не позволяла и никогда не будет позволят.
Загляните, чтоль, сюда. Когда настанет просветление, можно будет продолжить.
Hi VladD2
V>>>Ты бы все же сначала поглядел о чем рассуждаешь. А то забавно получается. Nemerle по сути клон O'Caml с С-подобным синтаксисом, но O'Caml тебе подходит, а Nemerle нет. Парадокс одноако.
AV>>Облом подкрался незаметно. Ты пытаешься судить о моих потребностях не зная задач, которые мне необходимо решать сейчас и в ближайшее будущее.
V>Я сужу не о твоем проекте, а алогизмах в твоих суждениях.
Ты судишь об аллогизмах в моих суждения не зная чем эти суждения вызваны.
AV>>Краткая постановка задачи: Необходимо разработать Application Server. Все это должно работать на кучу платформ (на данный момент 5. Винда считается одной платформой).
V>На остальных Моно работает?
Обломись. Как минимум на HP-UX не работает. Да и AIX маячит в дальней перспективе.
Далее, в списке языков есть Java. Как ее прикрутить к Mono? Да и рассчитывать на Mono в 2004 году странно было бы.
Список языков постоянно расширяется. Поэтому закладываться на .NET опять же нельзя.
Как видишь все дальнейшие твои размышления обламываются хотя бы тем, что даже Mono не работает на всех нужных платформах. Не говоря о куче других ограничений. Неужели ты думаешь, что код начали писать сразу без анализа существующих вариантов?
Поэтому получается, что мне OCaml на данный момент гораздо нужнее чем Nemerle.
Здравствуйте, awson, Вы писали:
A>Загляните, чтоль, сюда. Когда настанет просветление, можно будет продолжить.
Да ладно, это же трюк. Приходится заводить на каждое имя фунции по классу, и на каждую сигнатуру по инстансу.
В "чистом" виде перегрузки на самом деле нет
к сожалению, не напишешь. А писать для каждого такого случая
type Properties = [(String, String)]
class OpenConnection a r | r -> a where
openConnection :: String -> a -> r
instance OpenConnection Properties Connection where
openConnection url props = ...
instance OpenConnection String (String -> Connection) where
openConnection url username password = ...
Здравствуйте, ambel-vlad, Вы писали:
AV>Ты судишь об аллогизмах в моих суждения не зная чем эти суждения вызваны.
Причина алогизмов не имеет значения. Важен факт их наличия.
AV>Обломись. Как минимум на HP-UX не работает. Да и AIX маячит в дальней перспективе.
Забавный у вас выбор платформ.
С ним и С++-то проблематично убдет перенсти. Так что Ява становится самым разумным решением.
AV>Далее, в списке языков есть Java. Как ее прикрутить к Mono? Да и рассчитывать на Mono в 2004 году странно было бы.
А можно узнать как вы собираетесь к С++-ному коду Яву подключать?
Вообще, у вас забавнишие требования.
AV>Список языков постоянно расширяется. Поэтому закладываться на .NET опять же нельзя.
А что за странная такая задача? Зачем серверу приложений поддерживать постоянно расширяемый список языков и соврешенно эксзотические платформы?
AV>Как видишь все дальнейшие твои размышления обламываются хотя бы тем, что даже Mono не работает на всех нужных платформах. Не говоря о куче других ограничений. Неужели ты думаешь, что код начали писать сразу без анализа существующих вариантов?
Я вижу, что у вас очень странный проект.
AV>Поэтому получается, что мне OCaml на данный момент гораздо нужнее чем Nemerle.
O'Caml для системы требующей интероперабельности с Явой — это просто супер. Что-то мне подсказвает, что проект заранее провальный. Ну, да дерзайте.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, awson, Вы писали:
A>Загляните, чтоль, сюда. Когда настанет просветление, можно будет продолжить.
Хм. Красивое извращение. Если я правильно понял, то ребята выходят не мытьем, так кактаньем. Они порождают для всех типов которыми нужно "перегрузить" фукнцию отдельный класс-типа и создают воплощения. В итоге получается, что мы имеем несколько типо объявленных в класс и метод оперирующий с этим классом. Так?
Вот только при этом мы имеем опять же не перегрзуку, а один метод с истенным полиморфизом.
Классы типов конечно круты, но сути дела они не меняют.
Так что чудес небывает. Если бы оговоренных мной ограничений не было, то Хаскелевские компиляторы дохли бы на средних проектах. У Nemerle та же проблема. Допустимость перегрузки и приведений типов накладывает ограничения на синтаксис (нельзя описывать паттерн-матчинг на уровне функций) и влияет на производительность. По сему вывод типов допускается только логально. Иначе кубический алгоритм повесит любой современный компьютер.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Hi VladD2
AV>>Ты судишь об аллогизмах в моих суждения не зная чем эти суждения вызваны.
V>Причина алогизмов не имеет значения. Важен факт их наличия.
Имеет значение. Еще какое. В одной ситуации что-то выглядит абсурдом, в другой ситуации может быть оправданным. В моей ситуации изучение OCaml будет полезным, а вот Nemerle — нет. Где аллогизм здесь?
AV>>Обломись. Как минимум на HP-UX не работает. Да и AIX маячит в дальней перспективе.
V>Забавный у вас выбор платформ.
Клиент хочет, платит за это. У него обльшой зоопарк платформ. И менять их слишком дорого пока. Дешевле оказалось писать под кучу платформ.
V>С ним и С++-то проблематично убдет перенсти. Так что Ява становится самым разумным решением.
Да нету никаких проблем с С++. Надо только знать что можно, а что нельзя использовать. Это не занимает много времени (по факту подобные проблемы были только первые 3-5 недель). Джава не подошла по нескольким причинам.
AV>>Далее, в списке языков есть Java. Как ее прикрутить к Mono? Да и рассчитывать на Mono в 2004 году странно было бы.
V>А можно узнать как вы собираетесь к С++-ному коду Яву подключать?
А что поднять JVM в своей программе большая проблема? А наши программеры не знали об этом.
V>Вообще, у вас забавнишие требования.
Нормальные требования. Что тебя так сильно удивляет?
AV>>Список языков постоянно расширяется. Поэтому закладываться на .NET опять же нельзя.
V>А что за странная такая задача? Зачем серверу приложений поддерживать постоянно расширяемый список языков и соврешенно эксзотические платформы?
Там не только сервер приложений, там еще и своя реализация аналога COM/DCOM. Об этом я уже писал в самом начале. Вот для этого и надо поддержка разных языков. Чтобы можно было писать компоненты на разных языках.
Работники приходят и уходят. И каждого переучивать дорого обойдется. Дешевле один раз написать необходимый код для поддержки необходимого языка и все. Тем более, что разные задачи лучше решать на разных языках.
AV>>Как видишь все дальнейшие твои размышления обламываются хотя бы тем, что даже Mono не работает на всех нужных платформах. Не говоря о куче других ограничений. Неужели ты думаешь, что код начали писать сразу без анализа существующих вариантов?
V>Я вижу, что у вас очень странный проект.
Чем же он такой странный? Да, не такой как подавляющее кол-во проектов, в нем не надо дергать БД, рисовать формочки. А в остальном ничего странного. Тебе же не кажеться, например, Mono странным проектом?
AV>>Поэтому получается, что мне OCaml на данный момент гораздо нужнее чем Nemerle.
V>O'Caml для системы требующей интероперабельности с Явой — это просто супер. Что-то мне подсказвает, что проект заранее провальный. Ну, да дерзайте.
Не поверишь, но он даже уже работает в 2-х местах. Сейчас идет его развитие.
И чем тебе не нравиться интероперабельность между разными языками? Потому что тебе не приходилось сталкиваться с таким?
Здравствуйте, ambel-vlad, Вы писали:
AV>Клиент хочет, платит за это. У него обльшой зоопарк платформ. И менять их слишком дорого пока. Дешевле оказалось писать под кучу платформ.
...
AV>Да нету никаких проблем с С++. Надо только знать что можно, а что нельзя использовать. Это не занимает много времени (по факту подобные проблемы были только первые 3-5 недель). Джава не подошла по нескольким причинам.
Ваш клиент неимоверно богат, раз ему не жаль денег на разработку сервера приложений на С++ и жаль денег чтобы поставить на машинах Линукс или Виндовс.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Да ладно, это же трюк. Приходится заводить на каждое имя фунции по классу, и на каждую сигнатуру по инстансу. L>В "чистом" виде перегрузки на самом деле нет
L>
В контексте глобального вывода типов перегрузка "в чистом виде" невозможна в принципе.
Поэтому, нужно либо от него (глобального вывода типов) отказываться совсем — требовать обязательной сигнатуры и выводить типы локально (это лучший выход), либо начинать городить какие-нибудь мутные условия, типа, если сигнатура есть — делать так, если нет — делать эдак, если сигнатура такая — делать то, если сякая — се и т.д. и .т.п. Результатом будет хаос кромешный.
Вместо этого мы имеем красивый и очень мощный механизм typeclasses. Можно написать, например, буквально в 5 строчках функцию, принимающую любое количество параметров любого типа.
Hi VladD2
AV>>Клиент хочет, платит за это. У него обльшой зоопарк платформ. И менять их слишком дорого пока. Дешевле оказалось писать под кучу платформ.
V>...
AV>>Да нету никаких проблем с С++. Надо только знать что можно, а что нельзя использовать. Это не занимает много времени (по факту подобные проблемы были только первые 3-5 недель). Джава не подошла по нескольким причинам.
V>Ваш клиент неимоверно богат, раз ему не жаль денег на разработку сервера приложений на С++ и жаль денег чтобы поставить на машинах Линукс или Виндовс.
Бедный, богатый, какая разница в данном случае. Тут считать надо. Насчет стоимости ОС можно согласиться. А вот как насчет переучивания работников на какой-то язык? И с учетом того, что работники время от времени меняются? Может лучше предоставить возможность им использовать то, что знают?
А еще если учесть еще, что наш заказчик получается не самый последний пользователь. Время от времени они работают в кооперации с другими компаниями. Там тоже надо переучивать людей?
Давай опустим домыслы. На анализ существующих вариантов заказчиком было потрачено очень много времени и денег. И раз они пришли к такому мнению, значит оно им дешевле.
Кстати, ты так и не ответил, почему в моей ситуации изучение Nemerle предпочтительнее изучения OCaml?
Здравствуйте, awson, Вы писали:
A>В контексте глобального вывода типов перегрузка "в чистом виде" невозможна в принципе.
Это не соотвествует действительности. Сложность алгоритма получается высокой. Но на практике все будет работать. Собствнно это как раз описано в дисере Москаля на www.nemerle.org
A>Вместо этого мы имеем красивый и очень мощный механизм typeclasses. Можно написать, например, буквально в 5 строчках функцию, принимающую любое количество параметров любого типа.
Назвать красивым внеполовое извращение ссылку на которое ты привел я бы не отчаялся.
Что касаетя типов классов, то идея действительно красивая. Вот только у меня дос их пор сомнени по поводу того насоклько она сочетается с кмпонентым подходом. Боюсь она может работать только в рамках одного компилируемого модуля.
Ну, и надо понимать, что в этом мире большинство API в С++-подобных ЯП где перегрузка и привденеие типов исходно заложены в дизайн. А стало быть Хаскель в этом мире будет всегда чувтствовать себя неуютно. Его действительно неординарная систама классов типов не вписывается в систему типов ООП-языков доминирующих на сегодня.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, awson, Вы писали:
A>Перегрузка по типу возврата не работает вообще никогда. И это не зависит даже от типа вывода.
Как это не работает? Type classes вроде это позволяют?
Навскидку несколько примеров: mzero, fromInteger, fromIntegral, readIO, readLn (read, в конце концов) — все перегружены по типу возврата. Или что-то другое имелось в виду?
Здравствуйте, palm mute, Вы писали:
PM>Здравствуйте, awson, Вы писали:
A>>Перегрузка по типу возврата не работает вообще никогда. И это не зависит даже от типа вывода. PM>Как это не работает? Type classes вроде это позволяют?
type classes конечно позволяют, я имел в виду "наивную перегрузку" в том смысле как писал lomeo
Я тут привел не совсем корректный пример — перегрузки по типу возврата, который без typclasses не работает никогда.
Точно будет говорить так: обязательное указание сигнатур по определению делает вывод типов локальным. Поэтому глобальный вывод типов по определению не предполагает перегрузки.
Здравствуйте, ambel-vlad, Вы писали:
AV>Нда. А мужики-то о java и не знали. Не так уж много у них спецов по java есть в штате. Что делать с остальными? Переучивать? Увольнять и набирать других?
Ты говорил о текучести кадров и проблеме поиска новых. Ты уж определись, а то это больше похоже на поиск отмазок.
AV>Риск оправдался.
Это будет видно когда проект закончится успехом.
Что до отсуствия у тебя задач... У тебя не задачи отсуствуют. У тебя решения заранее предопределены. Тебе их даже обдумывать не надо. Так что ОКамл тебе тоже будет бесполезен. Хотя... возможно это будет началом перестройки мышления.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, awson, Вы писали:
A>Я выше уже написал. Перегрузка несовместима с глобальным выводом по определению, т.е. тривиально.
Это заблуждение. Если вывод типо осуществляется снизу-вверх как это делается скажем в Немерле, то принципиальных ограничений нет. Проблемой становится только возрастание вычислительной сложности.
Самое смешное, что лично я хотел бы чтобы ты был прав, так как не вижу смысла в выводе типов выше тел методов, но вижу приемущества от такого ограничения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>Самое смешное, что лично я хотел бы чтобы ты был прав, так как не вижу смысла в выводе типов выше тел методов,
L>>Ты не пробовал, вот и не видишь.
VD>Ну, тебе виднее. Как говорится, с очевидцами не спорят.
Что значит мне виднее? Ты же сам это признал.
VD>>>но вижу приемущества от такого ограничения.
L>>Ага! Так это, значит, всё таки ограничение?
VD>Ты точно здоров?
Здравствуйте, lomeo, Вы писали:
VD>>Ну, тебе виднее. Как говорится, с очевидцами не спорят.
L>Что значит мне виднее? Ты же сам это признал.
Где? Нет, ты точно не здоров. Я пробовал программировать на разных языках. В том числе с выводом типов (ОКамл, Хаскель).
VD>>>>но вижу приемущества от такого ограничения.
L>>>Ага! Так это, значит, всё таки ограничение?
VD>>Ты точно здоров?
L>Нечего сказать?
На бред? Не, нечего. Я не знаю как и что ответить человеку который в использование его терминалогии пытается разглядеть "признание" чего-то там.
Понимаеш ли. Ограничение подразумевает, что его отсуствие — это однозначное добро. Иначе можно говорить только о выборе рекоторого решения. Конечно любое решение в каком-то смысле ограничение. Ну, скажем если я решаю писать по русски, то ограничиваю себя символами русского алфавита, а решив писать на английском, английского. Но имеет ли смысл тут говорить об ограничениях? Точно так же решая ограничить вывод типов телами методов, я как дизайнер ЯП, добиваюсь какой-то цели (облегчаю поиск ошибок компиляции и т.п.). Напротив, если я выбираю полный вывод типов, то я автоматически ограничиваю возможности компилятора по диагностике ошибок и т.п. Так что какое бы я не принял решение все равно будет ограничение. Такие ограничения бессысленно рассматривать как ограниченность, что ты и пыташся делать. Это выбор дизайнеров языка. Компромис. Он достигает одной цели жертвуя другой. Задача дизайнера сделать правильный выбор, а не уменьшить ограничения. По этому вопрос "почему ввели такое ограничение" априори некорректен. Темболее глупо говорить о проблемах реализации и темболее лени или еще чем-то там.
Но тебе же важно не понимание вопроса, а поиск фатальных недостатков. Ты принципиально не объективен. По этому серьезно разговаривать с тобой нельзя. Ты все равно все воспримешь в извращенном виде.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Он то говорит о том в чем разобрался. А ты просто несешь чущь о вещах в которых не разобрался. Самоуверенно, нагло и без единого аргумента.
Запонми на будущее одну вещь. Иногда решения выходят за рамки нашего понимаиния. Чтобы понять их нужно взглянуть на вещи по другому и учесть множество предпосылок выпадающих из твоего ведения. В таких случаях проще всего назвать все чушью и далее начать обличительную речь. Вот только это не конструктивный и гиблый путь
Что до "фанатов", то IT тебе ответил очень точно. Это за твоей гранью, так как ты и есть фанат неспособный воспринимать чужие аргументы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Он то говорит о том в чем разобрался. А ты просто несешь чущь о вещах в которых не разобрался. Самоуверенно, нагло и без единого аргумента.
В чем он разобрался? Как из строки целое вычитать? Какие здесь могут быть аргументы?
VD>Запонми на будущее одну вещь. Иногда решения выходят за рамки нашего понимаиния. Чтобы понять их нужно взглянуть на вещи по другому и учесть множество предпосылок выпадающих из твоего ведения. В таких случаях проще всего назвать все чушью и далее начать обличительную речь. Вот только это не конструктивный и гиблый путь
Здравствуйте, awson, Вы писали:
VD>>Он то говорит о том в чем разобрался. А ты просто несешь чущь о вещах в которых не разобрался. Самоуверенно, нагло и без единого аргумента.
A>В чем он разобрался?
В том как работает алгоритм вывода типов в Nemerle. Причем разбирался под отладчиком и пробвал кое что менять. В частности отключал провекру запрещающую различать фукнции по их возравщаемому значению и убеждался, что вывод типов все равно работает.
A>Как из строки целое вычитать?
А надо?
A>Какие здесь могут быть аргументы?
У тебя, то кроме слов "чущь" других то нет. Я вообще не понимаю, как можно прочтя статью содержащую формальное обоснование алгоритма "споирь" и кидаться словами вроде "чушь".
VD>>Запонми на будущее одну вещь. Иногда решения выходят за рамки нашего понимаиния. Чтобы понять их нужно взглянуть на вещи по другому и учесть множество предпосылок выпадающих из твоего ведения. В таких случаях проще всего назвать все чушью и далее начать обличительную речь. Вот только это не конструктивный и гиблый путь
A>Вы программы тоже с помощью заклинаний пишете?
Мои порогаммы можно наблюать и пробовать их использовать. А вот ты пока что тут только языком чешишь. Так что не надо здесь про заглинания.
Прочти статью еще раз и попытайся понять принцип алгоритма. В общем-то он не так и сложен. По стути там выявляются прецеденты использования фукнций и делается заключение о их непротиворечивости. Если есть неопределенность сообщяется об ошибке. Никаких не приодалимых проблем при этом не возинкает. И локальность или глобальность вывоад типов ни на что не влияет. Неопределенность может быть разрешена путет аннотации типов. Например, метод Console.WriteLine() сильно перегружен и его прямое использование не всегда получается неоднозначным. Однако в большинстве слеучаев проблем не возникает, так как само использование указывает какй из вариантов перегрузки использовать. Ну, а если все же остается неоднозначность компилятор об этом рассказывает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В том как работает алгоритм вывода типов в Nemerle. Причем разбирался под отладчиком и пробвал кое что менять. В частности отключал провекру запрещающую различать фукнции по их возравщаемому значению и убеждался, что вывод типов все равно работает.
Да и потом, как показывает мой простейший пример, даже локального вывода в чистом виде не достаточно. Нужно что-то еще, типа дополнительных правил выбора инстансов, либо от ворот поворот компилятором.
Например, в Хаскелле в typeclasses тоже можно активировать неразрешимые и некогерентные инстансы.
Здравствуйте, awson, Вы писали:
A>Хм, кажется, я, наконец, понял в чем дело. Товарищ просто не знает, что такое композиция и читает ее в обратном порядке.
Не угадал.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
FR>Нужен результат: например вернуть из функции N (разнотиповых) переменных, есть несколько альтернатив как это сделать, в языке подерживающем туплы, это элементарно просто вернуть тупл. В языке не подерживающем туплы или завести структуру из этих N переменных (единственное предназначение которой только возврат этих переменных) или что еще хуже завести у функции out параметры. Тупл здесь средство упростить и очистить от мусора код и ничего больше.
Здравствуйте, AndrewVK, Вы писали:
AVK>А дальше? Как заставить tuple1.GetType() == tuple2.GetType() вернуть true, если tuple1 и tuple2 совместимы по сигнатуре, но при этом физически это два разных класса? Тут хак в рантайме нужен типа делегатов, бо это duck typing в чистом виде. Ну или работать через TransparentProxy, но производительность такого решения ты наверное представляешь.
Хм... а централизованно динамически генерить новые классы на каждую сигнатуру кортежа не получится?
Здравствуйте, VladD2, Вы писали:
VD>Потому что дизайнеры C# 3.0 решили сделать именованные поля у неименованных типов. Мол это привычнее обывателям и больше защищает от ошибок (ведь в кортеже можно легко перепутать значения местами, если они имеют один тип). Но такой тип уже дженериком не опишишь. Компилятору приходится каждый раз порождать новый (скрытый) класс. Ну, а так как разные библиотеки порождают разные (физически) классы, то они не совместимы. Далее думаю ясно.
А если имена протаскивать как параметризаторы? Каким-нибудь чудесным образом.
Hi VladD2
AV>>Нда. А мужики-то о java и не знали. Не так уж много у них спецов по java есть в штате. Что делать с остальными? Переучивать? Увольнять и набирать других?
V>Ты говорил о текучести кадров и проблеме поиска новых. Ты уж определись, а то это больше похоже на поиск отмазок.
И текучка и текущий состав учитывались.
Даже если остановиться на текучке. Ты берешь человека. Наш клиент предпочитает брать людей, которые знают как решить ту или иную задачу. И им по барабану, знает принимаемый java или нет. А если взять человека, который не знает java и начать его переучивать, то он на достаточно долгий срок выпадает. И получилось дешевле добавить поддержку еще одного языка, чем его переучивать.
И вообще, давай опустим причины такого выбора. Причины были объективны. Просто я не все могу рассказать из-за NDA. Прими это за факт.
AV>>Риск оправдался.
V>Это будет видно когда проект закончится успехом.
На базе этого сервака уже работает один проект. Второй находится на стадии тестирования. Так что успех уже есть. Это факт. А факты, как известно, вещь упрямая.
V>Что до отсуствия у тебя задач... У тебя не задачи отсуствуют. У тебя решения заранее предопределены. Тебе их даже обдумывать не надо.
Опять выдаешь свои измышления не зная поставленной задачи. Это не так. Затада была поставлена так, что были большие возможности для маневра (хотя список поддерживаемых языков устанавливает закзачик). Просто в результате анализа совместно с аналитиками заказчика были приняты те или иные решения. Далее, у нас уже создавалась архитектура приложения. Причем полностью. И заказчик принял ее полностью (после некоторых совместных консультаций). И сейчас практически все решения принимаются у нас (кроме требуемой функциональности). Они только утверждаются заказчиком.
V>Так что ОКамл тебе тоже будет бесполезен. Хотя... возможно это будет началом перестройки мышления.
Да ну? Функционал постоянно развивается. Поэтому постоянно надо что-то добавлять. Да, сейчас этим занимается другой человек. Но если я буду знать OCaml, то я смогу, в случае необходимости, помочь ему. Или даже, в крайнем случае, заменить его.
А что мне даст изучение Nemerle в моей ситуации? Ты так и не ответил на этот вопрос. Интересно дождусь я прямого ответа, а не отмазок.
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Хм... а централизованно динамически генерить новые классы на каждую сигнатуру кортежа не получится?
Нет конечно. Там же уже в сборках все статически слинковано будет, с указанием точного идентификатора метаданных. Здесь нужен именно что контракт-хамелеон, а такое в верифицируемом IL можно провернуть пока что только с помощью TP.
... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>
Здравствуйте, ambel-vlad, Вы писали:
AV>Там не только сервер приложений, там еще и своя реализация аналога COM/DCOM. Об этом я уже писал в самом начале. Вот для этого и надо поддержка разных языков. Чтобы можно было писать компоненты на разных языках.
Здравствуйте, VladD2, Вы писали:
VD>А многопоточность в Яве вообще не продумана. Ввели какие-то примитивы (да еще и через зад), но толку от этого == 0. Писать многопоточный софт так же трудно как на С++. Тут нужны другие решения: 1) автоматическое распараллеливание, 2) аналог системы сообщений Эрлэнга. Вот это дало бы толк. А ручная синхнонизация крути, не крути все равно приведет к ошибкам которые будет трудно найти.
Несмотря на то, что некоторые механизмы в Java эффективнее
обеспечивают решение отдельных задач программирования параллельных
вычислений, в целом Ада предлагает более доступные и надёжные
механизмы поддержки программирования для параллельных
вычислительных систем.
System.Threading library
General lock objects
Wait/Pulse for threads self-management
Zonnon approach ...
Activities built into objects, none or more
Syntax based dialogs governing interaction
Object level monitor locks via blocks Thread management by the system via
await on pre-condition for continuation
(transparently on single or multiple processors)
Statement level concurency also available
Hi OCTAGRAM
AV>>Там не только сервер приложений, там еще и своя реализация аналога COM/DCOM. Об этом я уже писал в самом начале. Вот для этого и надо поддержка разных языков. Чтобы можно было писать компоненты на разных языках.
O>Есть же XPCOM. Не подходит?
Здравствуйте, Cyberax, Вы писали:
C>OCTAGRAM wrote: >> * /Thread management by the system via >> await on pre-condition for continuation >> (transparently on single or multiple processors)/ C>Та же самая Ява с немного большим числом примитивов. Ничего это не C>решает, нужно что-то типа Эрланга.
Ну тогда Ада — проверенный временем язык, что касается многозадачного программирования.
Активные и пассивные мониторы, механизм рандеву, оператор select...
Несмотря на то, что некоторые механизмы в Java эффективнее
OCT>обеспечивают решение отдельных задач программирования параллельных
OCT>вычислений, в целом Ада предлагает более доступные и надёжные
OCT>механизмы поддержки программирования для параллельных
OCT>вычислительных систем.
Здравствуйте, Cyberax, Вы писали:
C>OCTAGRAM wrote: >> C>Та же самая Ява с немного большим числом примитивов. Ничего это не >> C>решает, нужно что-то типа Эрланга. >> Ну тогда Ада — проверенный временем язык, что касается многозадачного >> программирования. >> Активные и пассивные мониторы, механизм рандеву, оператор select... C>Та же самая Ява, вид в профиль. Изменяя набор примитивов синхронизации C>добиться чего-то революционного не получится. В конце концов, они все C>сводятся к мьютексу.
C>Если требуется использовать операции синхронизации — это УЖЕ источник C>для трудноуловимых ошибок.
Да нет, Яве до Ады далековато будет Да Ява и не преследовала удобство параллельного программирования. Впрочем, удобство родового программирования она тоже не преследовала до поры до времени. Кто знает, быть может, однажды придёт мода и на параллельное программирование.
В Аде нет мьютексов. И вообще нет примитивов. Ни мьютексов, ни сигналов.
Синхронизация встроена в объекты.
Метолы protected объектов могут выполняться одновременно максимум в одном потоке. Разве не это требуется? Только это синхронизация с человеческим лицом.
Про задачи долго объяснять, там механизм рандеву используется, гляньте в Интернете. Если Вы не ещё знали, что это такое, я уверен, Вам понравится.
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Да нет, Яве до Ады далековато будет Да Ява и не преследовала удобство параллельного программирования. Впрочем, удобство родового программирования она тоже не преследовала до поры до времени. Кто знает, быть может, однажды придёт мода и на параллельное программирование. OCT>В Аде нет мьютексов. И вообще нет примитивов. Ни мьютексов, ни сигналов.
Есть. В мониторах. Разница с мьютексами ничтожная.
OCT>Синхронизация встроена в объекты.
И чем оно отличается от явовского synchronized?
OCT>Метолы protected объектов могут выполняться одновременно максимум в одном потоке. Разве не это требуется? Только это синхронизация с человеческим лицом.
Это _сериализация_ "с человеческим лицом". Только очень ограниченная. Синхронизация не сводится к сериализации, это значительно более обширная и разнообразная тема.
OCT>Про задачи долго объяснять, там механизм рандеву используется, гляньте в Интернете. Если Вы не ещё знали, что это такое, я уверен, Вам понравится.
Редкое уродство, jIMHO. Народ попытался заменить схему очередей. Только одно в их идее непонятно — на кой вообще там обслуживающая задача, если можно обойтись одной? Потому что монитор не позволяет сделать удобную для этого случая сериализацию?
Здравствуйте, Aquila, Вы писали:
A>Обнаружен новый язык — конкурент Nemerle!
И чем он конкурировать будет?
A>Называется Lexico, далее следует пример кода:
Кошмар (на Испанском?) поскипан.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, OCTAGRAM, Вы писали:
OCT>А если имена протаскивать как параметризаторы? Каким-нибудь чудесным образом.
По идее конечно можено было бы приделывать имена как атрибуты к методам, но что делать если тип используется только локально? К чему этот атрибут приделывать? Ведь к выражениям атрибуты не прикрепишь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>"Что позволено быку, то не позволено Юпитеру".
Про быков не понял.
AVK> Выпустят .NET Framework 3.5 и всего делов.
Кстати, в Рефлекторе уже есть такой пунктик. Только тогда не ясно почему бы не исправить недоделку и не ввести анонимные типы на уровне этогт самого .NET Framework 3.5.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Хотя бы потому, что в Java кроме мониторов+volatile есть и:
Статья, скорее всего, из прошлого века. То биш, ссылки, со словами "1.5.0" можно вычеркнуть.
Andrei N.Sobchuck wrote: > C>Хотя бы потому, что в Java кроме мониторов+volatile есть и: > Статья, скорее всего, из прошлого века. То биш, ссылки, со словами > "1.5.0" можно вычеркнуть.
В 1.4 можно было бы тоже реализовать все это, кроме атомарных объектов,
для которых просто не было нужных примитивов. Собственно,
edu.oswego.concurrent это и делал.
Здравствуйте, Cyberax, Вы писали:
C>Еще раз — рекомендую посмотреть на Erlang.
+1 C>Вот там действительно C>уникальный подход к решению проблемы.
Слово радикальный тут больше подходит.
Видел где-то привильную фразу по этому поводу.
Проблем с примитивами синхронизации нет у тех, кто на них забил
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Здравствуйте, ambel-vlad, Вы писали:
AV>Да ну? Функционал постоянно развивается. Поэтому постоянно надо что-то добавлять. Да, сейчас этим занимается другой человек. Но если я буду знать OCaml, то я смогу, в случае необходимости, помочь ему. Или даже, в крайнем случае, заменить его.
AV>А что мне даст изучение Nemerle в моей ситуации? Ты так и не ответил на этот вопрос. Интересно дождусь я прямого ответа, а не отмазок.
Если ты будешь действительно знать Nemerle, та на изучение (поверхностное, конечно) ОКамла или скажем Хаскеля у тебя уйдет пара дней. И вообще, думаю у тебя резко изменится отношение к вопросу "как можно и нужно писать софт".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Hi VladD2
AV>>А что мне даст изучение Nemerle в моей ситуации? Ты так и не ответил на этот вопрос. Интересно дождусь я прямого ответа, а не отмазок.
V>Если ты будешь действительно знать Nemerle, та на изучение (поверхностное, конечно) ОКамла или скажем Хаскеля у тебя уйдет пара дней.
На изучение сначала Nemerle, а потом OCaml (причем мне все таки надо не поверхностное знание) мне понадобиться больше времени, чем на изучение только OCaml. Согласен? При этом я нигде не смогу применить знание Nemerle ни сейчас, ни в обозримом будущем.
Если согласен с оценками времени, то есть следующие отрицательные моменты. Свободного времени у меня не так уж и много. И тратить его я предпочитаю на дочь, жену и друзей. А не на компьютеры. Так я опять должен буду пожертвовать неизвестно для чего.
Если ты не согласен с оценками времени, то почему?
V>И вообще, думаю у тебя резко изменится отношение к вопросу "как можно и нужно писать софт".
Как знание Nemerle изменит мое отношение к вопросу "как можно и нужно писать AppServer и ему подобный софт"?
И на написание какого рода софта рассчитан Nemerle? В той области программирования, где я работаю сейчас, пока перспектив Nemerle не видно.
Hi VladD2
AV>>На изучение сначала Nemerle, а потом OCaml (причем мне все таки надо не поверхностное знание) мне понадобиться больше времени, чем на изучение только OCaml. Согласен?
AV>>Если ты не согласен с оценками времени, то почему?
V>Нет. Причем катигорически.
Почему? Аргументы будут? Или так лишь потому что ты так сказал.
V>Но ты помжешь попробвать.
Перекуём баги на фичи!
Если нам не помогут, то мы тоже никого не пощадим.
1.2.0 alpha rev. 655
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
