Здравствуйте, VladD2, Вы писали:
VD>Дык если бы каждый чих этого требования, то проблему бы давно решили написав набор стандартных функций или введя синтаксис аналогичны сринг-формату. На на практике потребность фоматировать даблы столь редка, что о ней и говорить не приходится. К тому, же всегда можно настроить все через культуру. Это зачастую снимает много проблем.
Это от того, что единственное, что вы пишете — это компилятор. У вас там наверное во всём проекте ни одного дабла, кроме как в тесткейзах, нет.
А в жизни ни даты, ни даблы никто никогда не выводит в "дефолтном" формате. Слишком велик разброс вариантов. Задавать же, к примеру, количество знаков после запятой, через культуру — еще менее удобно, чем подставлять ad-hoc функцию. В культуре есть понятие стандартного вывода денежных значений. Но никакого типа currency нет, а сплайс-строки не предоставляют возможности использовать эту настройку. В String.Format я пишу {0:C} и всё — будет выводиться корректный префикс и количество цифр после точки.
VD>Все эти F2 и FX действительно затрудняют понимание и никакими курсами тут не поможешь. Я вроде уже боец не молодой, но запомнить эту ересь я не могу. А функция затрудняет понимание нее больше чем знаки форматирования. Скажу больше, функция может содержать описание которое будет видно из подсказки (хинта) в IDE. Это решает проблему чтения, в отличии от срок форматирования.
VD>Ладно, вопрос риторический. Я считаю, что решения должны быть интуитивно понятными. Тогда и документацию смотреть не потребуется. А формат в старин-формат сдалан в лучших традициях перла. Никакой логики, одни двухбуквенные согращения. Но за-то народ привыкший к этому дерьму и не видевший ничего более разумного начинает с пеной у рта отстаивать это уродство.
Ну, я, собственно, уговаривать тебя не собираюсь. Я не пользуюсь Nemerle, и задачи продвинуть его в top100 языков программирования у меня нету.
Но то, что вы позиционируете как killer feature штуку, которая сильно отстаёт по возможностям от "родного" аналога, удручает.
Так ты слона не продашь (с).
Понимаешь, идея не в том, чтобы сказать всем "вы косные тупые уроды, бросьте всё и пишите как мы, пусть это будет длиннее по строчкам кода", а в том, чтобы сказать "смотрите, привычные вам вещи умеют больше".
VD>Кстати, одно из соображений почему мы не сделали формат аналогичный стринг-форматному как раз и была полная непонятность этого формата. А ведь еще в 6-ом Васике вроде как были весьма интуитивно понятные средства форматирования.
Не вижу ничего непонятного. По сравнению с синтаксисом RegEx форматные строки — детский лепет. Реально, Влад, это еще один DSL, существующий в рамках .Net. Вот взяли бы его и замутили на Nemerle. Так, чтобы все там пряники типа компайл-тайм проверки, code completion, и так далее.
А то, что вы сейчас позиционируете как killer feature, извини, не намного лучше прямого вызова String.Concat.
VD>Это не правда. Ты просто плохо смотрел. Вот, например.
Да, правда, плохо смотрел.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VoidEx, Вы писали: VE>Пока что я не вижу массового въезжания программистов в идеи МП (хоть с трудом, хоть без), а про деньги МС и Блабов уже наслышан, но верится с трудом, нерелигиозен.
Странно. Лично у меня опыт на 100% обратный — т.е. я не припомню программиста, который не пробовал баловаться с метапрограммированием. Это прямо с 12 лет.
Я помню, что еще тогда удивлялся тому, что есть программисты, которые пишут программы, заточенные на совершенно конкретную структуру таблички в базе данных.
Ведь вместо этого можно сделать универсальную программу, которая будет читать метаданные и работать с любой таблицей!
Такие идеи постоянно посещают людей. То им хочется сделать универсальную доставалку любых данных из базы, то универсальную сохранялку любых объектов в XML, то универсальный генератор UI по метамодели. В моей деревне трудно найти разработчика, который не баловался генерацией кода.
Поэтому у "въезжания в идеи" с массовостью, имхо, всё ок. Помилуйте, да если 90% программистов эти идеи изобретают, то уж наверное остальным 10% их удастся хотя бы объяснить?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ikemefula, Вы писали: I>Слушай, не понял идею, твой пост сводится к "Объясните мне вот ту простую фичу которую легко объяснять другим"
Нет. Мой пост сводится к "объясните, как построить летучий корабль из мотка скотча и пилочки для ногтей".
Понятно, что объяснить скотч и пилочку нетрудно?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>>>Все что нужно сделать — это заменить "$" на "L". Далее при компиляции автоматически создается файл куда "выкидываются" все строковые литералы где вместо сплайсов стоят некие заменители вроде любимых тобою "{0}".
L>>Как это будет работать с source control-ом?
VD>А в чем проблема то?
И все-таки, если не сложно, можешь прояснить этот вопрос?
TFS, например, ставит readonly на файлы, взятые из репозитория. Если при компиляции создаются/меняются файлы, то получается компилятор должен знать, что делать с такими файлами, должен знать о том, что недостаточно снять атрибут readonly, нужно еще и зачекаутить файл в TFS-е.
Неужели макрос для L-строк делает и это? А как быть, если используется какая-то другая VCS? Непонятно.
Здравствуйте, q__q, Вы писали:
__>И все-таки, если не сложно, можешь прояснить этот вопрос? __>TFS, например, ставит readonly на файлы, взятые из репозитория. Если при компиляции создаются/меняются файлы, то получается компилятор должен знать, что делать с такими файлами, должен знать о том, что недостаточно снять атрибут readonly, нужно еще и зачекаутить файл в TFS-е. __>Неужели макрос для L-строк делает и это? А как быть, если используется какая-то другая VCS? Непонятно.
Очевидно, файлы создающиеся в процессе компиляции в репозиторий не кладут, следовательно макрос к VCS никакого отношения не имеет.
Здравствуйте, Sinclair, Вы писали:
S>Но то, что вы позиционируете как killer feature штуку, которая сильно отстаёт по возможностям от "родного" аналога, удручает.
Отставать, да ещё сильно, да ещё по возможностям стандартной библиотеки — это, конечно, ты дал маху
Не забывай, родной string.Format никуда не делся. Более того, для Немерле он такой же родной как и для C#. Так что возможности в этом плане у Немерле ну никак не могут быть меньше.
По поводу doubles. Специально посмотрел свой рабочий проект (на C#), тыщ на сто строк, обычное бузинес приложение. string.Format для форматирования даблов не используется ни разу, хотя самого форматирования полно в отчётах, в формах. Но там оно не делается средствами string.Format. Да и что-то я вообще не припомню, когда использовал последний раз string.Format не для тестовых консольных приложений.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Sinclair, Вы писали:
S>Это от того, что единственное, что вы пишете — это компилятор. У вас там наверное во всём проекте ни одного дабла, кроме как в тесткейзах, нет.
Ну, ты конечно лучше самих людей знаешь кто чем занимается. Самому то не смешно?
Люди пишут на Немерле много чего. Есть и безнес-задачи, есть и моды для игрушек, есть и компиляторы (ну, один точно).
На форуме языка было много предложений по фичам, от весьма полезных и интересных, до забавных и мало-полезных. Но никто, ни разу не попросил добавить стринг-форматовский формат.
А я как-то давно заметил, что код который пишется из соображений "Вдруг спросят, а у нас нет Зингельшухера..." ни когда не бывает удобным и часто-употребимым. Меж тем есть тонна задач которые реально ждут решения.
К тому же формат String.Format-а меня не вдохновляет. Вот если найдется красивое решение, то можно будет его реализовать. Пока что мне ничего умного в голову не приходит.
Для Nemerle.StringTemplate я использую простой подход основанный на том, что в шаблоне можно перегрузить метод ToString в котором реализовать подходящее форматирование для нужного типа. Это удобно и интуитивно понятно. Вот если удастся придумать нечто подобное для обычных сплайс-строк, то я его обязательно добавлю.
S>А в жизни ни даты, ни даблы никто никогда не выводит в "дефолтном" формате. Слишком велик разброс вариантов. Задавать же, к примеру, количество знаков после запятой, через культуру — еще менее удобно, чем подставлять ad-hoc функцию. В культуре есть понятие стандартного вывода денежных значений. Но никакого типа currency нет, а сплайс-строки не предоставляют возможности использовать эту настройку. В String.Format я пишу {0:C} и всё — будет выводиться корректный префикс и количество цифр после точки.
Да, да. В теории теория и практика одинаковы. На практике — нет.
В общем, ты увлекся тем, чем тут очень любят увлекаться — выискиванием фатальных недостатков.
Кто тебе сказал, что сплайс-строки — это какая-то там киллер-фича? Это просто удобно. Чертовски удобно! Но не более того. Это не замена String.Format на все случае жизни. Такой задачи и не ставилось. Просто люди сделали для себя простенькую макру которая со временем равилась в весьма удобное решение. Кайф Немерле не в том, что в нем есть сплайс-строки, а втом, что каждый может создать в не нечто удобное для себя и окружающих. Причем сделать это так как хочется, а не так как это заставляют сделать проклятые обстоятельства в форме компилятора, язка и т.п.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VoidEx, Вы писали:
VE>Нет, это твои иллюзии. Мне интересен ответ на поставленный вопрос.
Я могу давать ответ один раз, два, три, пять, но на десятый раз меня это начинает утомлять и надоедать.
Ты явно не хочешь услышать мои ответы. Ты хочешь услышать что-то, что тебе хочется услышать. Но я все равно не смогу тебе сказать этого. Так зачем сотрясать воздух?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, VoidEx, Вы писали:
VE>>Нет, это твои иллюзии. Мне интересен ответ на поставленный вопрос.
VD>Я могу давать ответ один раз, два, три, пять, но на десятый раз меня это начинает утомлять и надоедать.
Хорошо, по каким ключевым словам поискать тогда ответ? Ну или когда ты на этот вопрос отвечал?
Если тебе не нравится отвечать по сто раз, не надо лезть в споры, где вопросы и ответы всегда одинаковые. А не выезжать на фразе "я не хочу отвечать", когда ответить становится нечего. А то заходишь, говоришь "пацаны, вы не правы, но почему — ищите сами, мне надоело".
Здравствуйте, VladD2, Вы писали:
U>>1) Добавление в язык птичьей конструкции "$", которая не вызывает никаких ассоциаций, соответственно плохо запоминается. VD>Я даже не знаю что можно сказать на такое. Кроме как домыслами это назвать больше никак нельзя (ну, если оставаться в рамках приличия). VD>Ты без проблем сам запомнил все что нужно и процитировал прямо. Что тут еще запоминать?
В чем достоинство именования вроде string.Format? В том, что если я завтра захочу написать аналогичную функцию мне понятно как ее назвать (<тип объекта>.<действие>), оставаясь в рамках концепции предложенной разработчиками шарпа. Если же я завтра захочу написать свой макрос аналогичный $ как мне его назвать? $my, $$, L, $my_macros, my, my_macros? Как назвать правильно непонятно, потому что за названием $ нет концепции. А это очень плохо, т.к. приводит к тому, что разработчики будут называть свои макросы как бог на душу положит, соответственно с интуитивной понятностью чужого кода придется попрощаться. Отсутствие концепции это и есть птичий язык, который можно только запомнить, а не интуитивно вывести.
U>>2) Ошибок форматирования, пожалуй, станет меньше, но они не исчезнут, такое ни компилятор, ни рантайм не отловят: $"Некая константа: obj1, $obj2" // забыли спецсимвол перед obj1. VD>Другими словами мы нашли недостаток в том, что ошибок станет меньше, а не ноль?
Вот при такой записи допустить ошибку необнаруживаемую компилятором практически невозможно:
Здравствуйте, Undying, Вы писали:
U>В чем достоинство именования вроде string.Format?
А оно есть?
U>В том, что если я завтра захочу написать аналогичную функцию мне понятно как ее назвать (<тип объекта>.<действие>), оставаясь в рамках концепции предложенной разработчиками шарпа.
Да, да. Почти стройная теория если не вспоминать о наличии разных: Write, WriteLine, AddMeaasge и т.п.
U> Если же я завтра захочу написать свой макрос аналогичный $ как мне его назвать? $my, $$, L, $my_macros, my, my_macros?
Довольно бессмысленно решать проблему которой нет. Не правда ли?
Если тебя трогает только название, то открою тебе большой сикрет. Макрос называется sprint, а $ — это его синоним. VD>>Другими словами мы нашли недостаток в том, что ошибок станет меньше, а не ноль?
U>Вот при такой записи допустить ошибку необнаруживаемую компилятором практически невозможно:
U>"Некая константа: " + _.s(obj1) + ", " + _.s(obj2);
Такая запись полностью не читаема. А ошибки, как не странно, возможны. Никто не помешает поместить имя переменной внутрь строки. Если ты укажешь на подсветку, то не боись. Для сплайс-строк она тоже есть и прекрасно видно где находится имя переменной.
U>ps U>Вообще, если бы сплайс-строка выглядела примерно так:
U>string.Inline("Некая константа: {obj1:F2}, {obj2}");
Это весьма не трудно реализовать на макросах. Проблема тольк в том, что в отличии от знака $ фигурные скобки довольно часто используемые символы и их удвоение сильно портило бы внешний вид строк.
Бесполезная же гора букв "string.Inline" только теоретикам кажется хорошим решением. По жизни от строк хочется чтобы они занимали минимум места и создавали минимум шума.
U>То решение бы мне наверное даже понравилось, т.к. оставалось бы в рамках концепции шарпа.
Ну, что же бери и делай. Все в твоих руках. Я даже готов тебе помочь советами. А там поглядим будет ли кто-то пользоваться твоей версией.
ЗЫ
Читая рассуждения о Немерле мне вспоминается реклама майонеза:
— (девочка) Все говорят, что майонез Скит вкусный, а я не верю.
— А Вы его есть пробовали?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VoidEx, Вы писали:
VE>Хорошо, по каким ключевым словам поискать тогда ответ? Ну или когда ты на этот вопрос отвечал? VE>Если тебе не нравится отвечать по сто раз, не надо лезть в споры, где вопросы и ответы всегда одинаковые. А не выезжать на фразе "я не хочу отвечать", когда ответить становится нечего. А то заходишь, говоришь "пацаны, вы не правы, но почему — ищите сами, мне надоело".
Сформулируй все свои вопросы. Я отвечу на них, но это будет последний раз. Чтобы не создавать циклических ответов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
U>>В том, что если я завтра захочу написать аналогичную функцию мне понятно как ее назвать (<тип объекта>.<действие>), оставаясь в рамках концепции предложенной разработчиками шарпа.
VD>Да, да. Почти стройная теория если не вспоминать о наличии разных: Write, WriteLine, AddMeaasge и т.п.
И Console.Write, и Console.WriteLine, и TraceHlp2.AddMessage подчиняются той же концепции наименования, что и string.Format, т.е. название этих методов построено по принципу <тип объекта>.<действие>
Здравствуйте, VladD2, Вы писали:
VD>Если тебя трогает только название, то открою тебе большой сикрет. Макрос называется sprint, а $ — это его синоним.
Непонятно зачем в концепцию шарпа тащить элементы из концепции языков C (sprint) и перла ($). Смешивание концепций наименования никогда ни к чему хорошему не приводило. Если бы Nemerle создавался с нуля с полностью своим фрамеворком, то вопросов бы у меня не было, что лучше концепция наименования C или концепция наименования C# это уже вопрос идеологический. Но Nemerle позиционируется как расширение шарпа, соответственно концепция наименования шарпа продолжает поддерживаться, поэтому непонятно зачем эту концепцию ломать, вводя новые элементы, которые никак в нее не вписываются.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, VladD2, Вы писали:
VD>>Если тебя трогает только название, то открою тебе большой сикрет. Макрос называется sprint, а $ — это его синоним.
U>Непонятно зачем в концепцию шарпа тащить элементы из концепции языков C (sprint) и перла ($).
Нет в природе никаких концепций Шарпа. В начале МС тянул принципы из Явы, потом что-то сами придумали получилось то что мы имеем.
"$" к Перлу тоже отношение не имеет. Скажем в том же MSBuild он во всю используется.
В общем, ты сначала попробовал бы использовать то что пытаешся ругать, а потом поговорили бы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VoidEx, Вы писали:
VD>>... Но лучше формировать команду из людей способных развиваться. Тогда их можно будет легко, постепенно втянуть в новую среду. Опять же не все будут создавать макры. Но по крайней мере не придется объяснять что за непонятный код написан вот там, указывая на применение метода Map или Fold.
VE>Чем лучше?
Не чем, а для чего — для проекта. Тупые уроды все равно ничего путного не напишут. Они или завалят проект, или породят чудовище.
В общем, для меня ответ на этот вопрос очевиден и данный вопрос выглядит как издёвка.
Если ты со мной не согласен и считаешь что миллион обезьян могут написать "Войну и мир", то: VD>>Можно оставить орды кодманки которые будут пользоваться написанными нормальными программистами библиотеками и макросами. Это позволит решать задачи привычным вам способом шапкозакидательства...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>С точки зрения Блаба (отличныйе примеры Блабов в этой теме дискутируют) все языки равны по своим возможностям. Просто некоторые имеют непонятные феньки которые все запутывают (с их точки зрения).
Не надо бороться с ветряными мельницами.
В данном топике нет сообщений людей, которые считаюи что все языки равны по возможностям или сложности.
И про феньки туда же.
VD>102-ой раз повторяю — Немерле выглядит для блаба как его любимый Блад. Он может писать на Блабе и потихонечку изучать базис который позволит в итоге оценить мощность изучаемого языка. В итоге, он незаметно для себя, перестает быть блабом и его кругозор увеличивается.
Немерле много мощнее и стало быть много сложнее.
VD>Вот недавно один из наших форумчан решил изучить Немерле. Интересно, что основной проблемой для него стали не какие-то там заумности ФП, а банальная рекурсия. От нее многим крышу рвет. А как раз Map, Fold и Filter он освоил на раз. Макросы тоже оказались не самым простым орешком, но прошли намного проще по сравнению с банальной рекурсией. Вот такие наблюдения из жизни. А вы говорите блабы...
Здравствуйте, gandjustas, Вы писали:
G>>>90% людей с которыми я работал хотели изучать новое. Но далеко не у всех было время на изчение чего-то кардинально отличающегося от существующего.
I>>Вот это точно обманка. G>Какая обманка? Это реальные люди, которе реально изучают новые технологии.
Обычная. 90% людей не хотят учиться. Возможно ты работал только с людьми в основном из остальных 10%. В это охотно верю.
I>>И я считаю по старинке — чем мощнее инструмент тем сложнее его осваивать. G>А вам что надо, освоение инструмента или его эффективное использование?
Освоение. Если инструмент легко осваивается, например, как С#, то очень просто найти специалистов.
А если очень сложно даётся, например, как шаблоны из C++ или технология COM, то найти специалистов должного уровня почти невозможно, хотя С++ников бегает по собеседованиям вагоны или даже чуть больше.
Если специалистов найти легко, то имеет смысл переводить проекты именно на новый, который легко осваивается.
I>>Представь, с++ нормально знает единицы. Шаблоны на С++ есть давным давно, а знают их настолько мало людей, что просто страшно. G>И это не мешает им писать программы.
Шаблоны в большей массе никто не использует. Максимум тривиальные.
I>>Передача то происходит, но важна скорость этой передачи, а то вот с лета занялся проектом, на котором состав разрабов сменился несколько раз. Реально страшно G>Если у вас за полгода несколько раз меняется состав разработчиков проекта, то вам уже ничего не поможет.
Не надо размахивать шашкой просто так Смешно выглядит.
Я ничего не говорил про смену состава с тех пор как я там начал работать.
Если нам не помогут, то мы тоже никого не пощадим.
