LINUX.ORG.RU

Вышла Scala 2.10

 


1

3

Объявлено о выходе новой версии языка программирования Scala 2.10.

Основные нововведения:

  • классы-значения (value classes) — новый механизм, позволяющий уменьшить расходы на выделение памяти;
  • неявные модификаторы (implicit classes) теперь относятся к определению классов и призваны упростить расширения для других типов;
  • интерполяция строк (string interpolation) — новый механизм создания строк;
  • Futures и Promises призваны упростить создание многопоточного кода;
  • библиотека Akka Actors теперь является частью языка;
  • наконец-то в состав языка добавлена поддержка макросов.

Текущая стабильная версия языка программирования Scala может быть получена на странице загрузки проекта; исходные коды распространяются на условиях лицензии BSD.

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: mono (всего исправлений: 2)
Ответ на: комментарий от anonymous

Сделай свой if через функции на не-ленивом языке.

В известных мне не-ленивых языках присутствуют базовые ленивые конструкции (или операторы). В чем проблема-то?

Сделай эффективный компилятор eDSL на фвп.

Эффективный-неэффективный это шашечки.

alienclaster ★★★
()
Ответ на: комментарий от Ritmik

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

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

border-radius
()
Ответ на: комментарий от alienclaster

В известных мне не-ленивых языках присутствуют базовые ленивые конструкции (или операторы). В чем проблема-то?

Не трепись. Делай.

Эффективный-неэффективный это шашечки.

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

Кроме того, реализация на макросах неизбежно проще и чище, чем реализация на ФВП. Просто по тому, что компилятор всегда проще, чем интерпретатор, а DSL на ФВП - это всегда ad hoc интерпретатор.

anonymous
()
Ответ на: комментарий от dizza

многие выпускники мгу, мфти.

Редкостно убогие быдлятники. Еще бы ПТУшниками хвастался, лошара!

anonymous
()
Ответ на: комментарий от tailgunner

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

dizza ★★★★★
()
Ответ на: комментарий от anonymous

Нет, это ехать. Неэффективная реализация регулярных выражений, или там, например, PEG-парсера просто не нужна.

Кто спорит, рассматриваемый момент - она *возможна*.

Лучше ничего, чем неэффективная тормозня.

О, да ты что ты :)

Кроме того, реализация на макросах неизбежно
неизбежно

Сходу виден беспристрастный инженерный подход, ага.

Просто по тому, что компилятор всегда проще

Макрос раскрывается в эти же фвп и спецформы.

а DSL на ФВП - это всегда ad hoc интерпретатор.

DSL на фвп ненужен, начнем с этого. Потому что не элегантно. А вообще зря ты так взъерепенился, ты хоть прочти на что отвечаешь - я говорил о мощи макросов по сравнению с функциями, *только* в разрезе модульности. И эта «мощь» эквивалентна :)

alienclaster ★★★
()
Ответ на: комментарий от Ritmik

Прочитай еще раз, что я написал: «если можно». Если я могу решить задачу без осиляторства, значит она простая по натуре. Если не могу, то тут да, нужно копать.

dizza ★★★★★
()
Ответ на: комментарий от dizza

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

Естественно. Но решение примнимать вам самим.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

dizza ★★★★★
()
Ответ на: комментарий от dizza

Это бич нашего времени: решение простых задач сложными методами.

border-radius
()
Ответ на: комментарий от dizza

Ну тут была речь о том, что требования нет, но мы сделаем по-сложнее, по универсальнее

Речь была о том, что, хотя явных требований и нет, но мы подумаем и сделаем так, как сочтем нужным.

tailgunner ★★★★★
()
Ответ на: комментарий от alienclaster

Кто спорит, рассматриваемый момент - она *возможна*.

«Возможна». Но - через жопу и с уродливым синтаксисом, с кучей ошибок и то, что получится, будет крайне непросто поддерживать.

Макрос раскрывается в эти же фвп и спецформы.

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

DSL на фвп ненужен, начнем с этого.

Я-то согласен, но ты расскажи это какашкелистам.

я говорил о мощи макросов по сравнению с функциями, *только* в разрезе модульности. И эта «мощь» эквивалентна :)

Да не эквивалентна она! С макросами мы можем легко выстроить цепочку из совершенно независимых преобразований (такой вот unix way), а с функциями этого не получится, любая реализация dsl на фвп будет с большим количеством текучих абстракций.

anonymous
()
Ответ на: комментарий от dizza

Гы, небось сам из одного из этих быдлятников вылупился? Да ты просто никто рядом с любым бауманцом.

anonymous
()
Ответ на: комментарий от TheKnight

А с учетом того, что числа у нас не бесконечной размерности и апроксимируются на бесконечность за счет использования нескольких машинных слов - не может выплыть этот самый log n?

День одаренных анализаторов алгоритмов на ЛОРе. Ну ты уже про ограниченные размеры кэшей на реальном железе вспомни тогда уж.

pitekantrop ★★★
()
Ответ на: комментарий от alienclaster

А ты оказывается божественно невежествен.

Что еще сказать, правда?

Я кажется понимаю в чем загвоздка. Ты живешь в «королевстве существительных» и думаешь соответственно.

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

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

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

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

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

Постой. Ты сначала сказал, что «известные мне мультиметоды это диспетчеризация по типу.», потом когда я тебя поправил, что диспетчеризация идет по значению функции диспетчеризации, ты изменил формулировку на «Правильное начало перечисления параметров диспетчеризации должно было звучать так: «мультиметоды (множественная диспетчеризация) - это выбор реализации ф-ии в зависимости от: типа параметров, значения параметров, ...»». В ответ я тебе скинул ссылку на документацию по мультиметодам, чтобы ты наконец просветился и так не позорился. В ответ ты пишешь какую-то ахинею про баззворды и комплексы. Лол.

Покажешь, где я определял фп как «структуры и ф-ции над ними»?

Твои слова «Если бы ты написал структурами и функциями над ними - было бы более конкретно.»

Определение фп знает любой школьник (возможно, кроме тебя).

Получается, что ты не знаешь определения, раз для тебя вместо ФП нужно «конкретно» писать «структуры и функции над ними».

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

Полудурок, БД это и есть реальный мир, запрос в бд тоже есть реальный мир. А твой ORM это имитация реального мира, чтобы все было объектами. У меня в программе реальные запросы на DSL которые реально исполняются в бд и возвращают реальные данные, а не объекты.

Кстати твои объекты, которые абстрагируют данные в базе это DAO (data access objects), не могут быть просто так переданы в бизнес слой, а должны быть переделаны в какие нибудь DTO (data transfer objects), которыt в свою очередь будут для дальнейших действий преобразованы в business objects, и т.д.. И это ты называешь реальным миром? Идиот, чтоле? Это не реальный мир, это тупиковый путь развития, нисколько не оправдавший своих маркетинговых обещания. Запомни, спец ты наш, OO это один из способов решения задачи, хорошо подходящий, например, к моделированию, но не как всеобщая парадигма программирования.

Ответ «функциональным программированием» такая же глупость как и «святым духом».

Функциональное программирование противопоставляется императивному ООП, которое ты тут пропогандируешь.

Ну, я уже понял, что ты тупой - можешь не отвечать.

Ага, я тупой, а ты тут по всем пунктам уже обкакался. Чудеса.

Есть яп с функциями, про которые ты говоришь, а есть яп с функциями высокого порядка

Речь конечно про языки высокого уровня с фвп, это *очевидно*.

Ой, не спрыгивай теперь:
Мои слава: «Реюз - ... модульность, также функции высокого порядка + иногда макросы позволяют добиваться реюза без громоздкости ООП.»
Твой ответ: «А мощь инструмента реюза «макросы» на уровне функций, которые есть в любом яп.»

То у тебя в любом яп, теперь ты «про языки высокого уровня с фвп» и для тебя это «*очевидно*.» Что теперь скажешь? Будешь дальше оправдываться?

Еще и с макросами так опозорился: «Функции есть во всех яп. Уровень мощности инструмента «функция» для решения задачи реюза (в общем случае) эквивалентен мощности инструмента «макрос».»

функциями гражданами первого класса.

Это то же самое, что и фвп,

Дебилушка, это главное свойство любого функционального языка. И это не одно и то же. Если функция является в языке гражданином первого класса (ГПК), то появляется возможность создавать ФВП. С другой стороны функция может быть ГПК, но не быть ФВП. Опять пернул не в тему? Или уже привык?

у тебя овердоз баззвордов. Почисти словарь.

Хватит позориться, тебе уже все термины разжевали. Или для тебя они все еще баззворды?

Теперь иди почитай книжки по фп и возвращайся.

Там не о чем читать, все элементарно.

Не определение в википедии почитай, дурень. А тот же SICP, например.

Уровень мощности инструмента «функция» для решения задачи реюза (в общем случае) эквивалентен мощности инструмента «макрос».

Ну и позор. Быстро читать, что такое макросы в лиспе!

Кроме кукареканья мы сегодня увидим хоть один ответ?

Для тебя вменяемые ответы это кукарекание? Почитай, как люди спрашивали и что им отвечали http://stackoverflow.com/questions/267862/what-makes-lisp-macros-so-special. А ты только и можешь, что печатать свои высеры и кичиться своим невежеством.

Не сливайся так позорно, ты верещал что-то о макросах и dsl, а оказалось это все можно реализовать на библиотечных ф-циях.

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

Вначале показываешь обычные функции и называешь это DSL, а затем eDSL'ем.

И в чем проблема? Зачем каждый раз добавлять embedded?

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

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

Макросы используют только как *крайний* случай - для введения новых языковых конструкций с сохранением обратной совместимости с хостовым языком (eDSL), ...

Сразу видно - специалист. Такую пургу нести. Почитай чтоли Грэма «On Lisp», где очень хорошо описаны причины использовать макросы и конкретные примеры. Да наверно это лишнее, вот какой-то анонимус высрет, а ты подберешь и будешь потом бредить в темах про фп и макросы.

Ritmik
()
Ответ на: комментарий от anonymous

В таком случае объясни мне, каким образом функции высшего порядка, отсутствие сайд-эффектов и каррирование ... призваны решить задачи information hiding, separation of concerns и low coupling

1) каррирование всё-таки не является ключевым понятием ФП, это скорее математический приём, упрощающий формализацию понятия функции + синтаксический сахар.

2) information hiding в ФП (по крайней мере в haskell) происходит на этапе экспорта символов из модулей.

3) separation of concerns и low-coupling. Не вполне представляю, что значат эти термины в ынтерпрайзной среде, но изолировать независимые задачи можно в любом языке.

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

imtw
()
Ответ на: комментарий от Ritmik

Ну-ка, изобрази на фвп foreach

Это-то как раз не проблема - map. И надеяться на то, что компилятор лямбду заинлайнит.

anonymous
()
Ответ на: комментарий от anonymous

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

«С улицы» «прибежит десяток» явно с небольшой квалификацией. Хороших специалистов мало в любой области.

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

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

Все зависит от проекта. Иногда дешевле иметь 2-3 дорогих хороших специалистов, использующих мощные инструменты, чем 50 чернорабочих, которые могут и не «поднять» задачу. А иногда достаточно 5 студентов, которые побыстрому наклепают продукт и ты получишь прибыль.

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

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

Про работодателей со вторым мною описанным случаем или похожим разговора нет.

Ritmik
()
Ответ на: комментарий от anonymous

Предположим, я - дебил, и я позволил задроту-очкарику притащить говнолисп или какашкель в проект. Задрот попадает под трамвай. Оцени, как долго я буду искать ему замену в ДС, что мне потребуется для адекватной оценки квалификации кандидатов (задрота-то уже нет, даже собеседовать их некому). Оцени, сколько будет стоить простой на время поиска очередного задрота.

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

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

Если у тебя второй вариант, то вломишь и будешь прав 100%. Или получишь по почкам, но все равно будешь прав, что не потащишь маргинальщину в проект.

Ritmik
()
Ответ на: комментарий от Ritmik

«С улицы» «прибежит десяток» явно с небольшой квалификацией. Хороших специалистов мало в любой области.

С улицы прибегут люди с сертификатами, надежно подтверждающими, что их квалификация достаточна. И они достаточно хороши - работу свою работают, а больше ничего и не надо. Мне с ними творчество Кьеркегора не обсуждать.

Если у тебя бизнес построен на содержании большого количества негров,

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

Иногда дешевле иметь 2-3 дорогих хороших специалистов, использующих мощные инструменты, чем 50 чернорабочих, которые могут и не «поднять» задачу.

Это никогда не дешевле. Это всегда запредельный, недопустимый риск.

Правильная модель - это взять 2-3 дорогих, хороших, обвешанных сертификатами архитекторов, и дать им в помощь 50 специалистов подешевле (тоже с сертификатами должного уровня).

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

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

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

anonymous
()
Ответ на: комментарий от Ritmik

Если проект интересный и зп хорошая и ты находишься не в где-нить в жоподрыпинске - найдешь.

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

А что с задротами-то делать?

anonymous
()
Ответ на: комментарий от pitekantrop

Ок, в clojure PersistentHashMap != хэш-таблица. И понятно, почему. Давай зачетку.

Такая имплементация для persistent data structure. Представляешь, язык задизайнили сразу с этим. И все остальное в языке сделали тоже грамотно: STM, ленивость, лучшее из фп и лиспа, интероперабельность с хостовым языком (джава, дотнет).

Ritmik
()
Ответ на: комментарий от anonymous

Макрос раскрывается в эти же фвп и спецформы.

Не в эти же. В случае с регвырами так и вовсе запросто может раскрыться в простыню из goto

goto - это и есть специальный оператор, если что.

Да не эквивалентна она! С макросами мы можем легко выстроить цепочку из совершенно независимых преобразований (такой вот unix way)

С ф-ями тоже самое.

любая реализация dsl на фвп будет с большим количеством текучих абстракций.

Скорее, это будет просто громоздко.

alienclaster ★★★
()
Ответ на: комментарий от tailgunner

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

dizza ★★★★★
()
Ответ на: комментарий от alienclaster

goto - это и есть специальный оператор, если что.

Но ты не можешь сделать реализацию на фвп, использующую goto.

С ф-ями тоже самое.

Нет.

Скорее, это будет просто громоздко.

Именно. Громоздко и не модульно.

anonymous
()
Ответ на: комментарий от border-radius

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

Модульность и описанные мною возможности ортогональны. Или я тебя не понял. Что такое «модулярность»? Разъясни, плиз.

А если при этом ещё и имеется сбалансированный (богатый, но не огромный и не тормозной) рантайм, так это вообще песня.

Есть пример?

Ritmik
()
Ответ на: комментарий от anonymous

Но ты не можешь сделать реализацию на фвп, использующую goto.

Оно по-другому и не получится - макросы, как известно: «раскрываются в функции и goto^W специальные операторы». То есть в итоге остаются именно ф-ции и спецопы. «Это не невозможно, это неизбежно!» :)

Скорее, это будет просто громоздко.

Именно. Громоздко и не модульно.

Почему не модульно? Просто уродливо.

alienclaster ★★★
()
Ответ на: комментарий от dizza

какой то терминологический спор выходит.

Разве?

anonymous> Здесь клиент 100% захочет гибкую кастомизацию на лету. Поэтому мне стоит потратить сегодня NN часов на освоение и прикручивание rules engine

Собственно, вопрос только «клиент 100% захочет». На основании опыта вполне можно делать такие заключения, а когда заключение сделано - просто привинчивается rule engine.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Ну-ка, изобрази на фвп foreach

Это-то как раз не проблема - map. И надеяться на то, что компилятор лямбду заинлайнит.

Не пойдет. foreach и map не эквивалентны. Надо чтобы было типа

foreach(n in collection)
{
  ... использование n...
}

Необязательно в таком синтаксисе, но обязательно наличие переменной, которая принимает значения из коллекции и выполняет тело, в котором используется эта переменная.

Сможешь или сразу сдаешься?

Ritmik
()
Ответ на: комментарий от Ritmik

Ну-ка, изобрази на фвп foreach

Это-то как раз не проблема - map

Надо чтобы было типа
foreach(n in collection)

for each(mycoll) |x| {
   io::println(x)
}

Это Rust.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Чувак, у тебя своя правда у нас своя. Не надо быть до конца уверенным, это просто впечатление о твоей работе. У меня тоже, но мне, возможно, посчастливилось видеть все в разных ракурсах. Например работал я как то в негритянской компании, как ты описываешь: 80 негров, несколько техлидов-гениев. И куча жавы. А потом пришел кризис, и уволили половину. И разработка пошла быстрее! Это было открытие. Потом наняли еще умных чуваков, стали выпиливать жаву, добавили питона. Стало еще быстрее.

dizza ★★★★★
()
Ответ на: комментарий от alienclaster

Последний вопрос - какой язык был перед clojure - php или java?

Это все твои знания? Хочешь найти с чем сравнить? Прости, не получится.

Ritmik
()
Ответ на: комментарий от alienclaster

Оно по-другому и не получится

Читай внимательнее - сделай так на фвп.

Почему не модульно? Просто уродливо.

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

anonymous
()
Ответ на: комментарий от tailgunner

В каком-то частном соучае возможно. Строить разработку на этом нельзя. Правило по умолчанию: делаем лишь бы покрыть требования.

dizza ★★★★★
()
Ответ на: комментарий от dizza

А потом пришел кризис, и уволили половину. И разработка пошла быстрее!

А сертификаты у них были?

anonymous
()
Ответ на: комментарий от dizza

Строить разработку на этом нельзя.

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

Правило по умолчанию: делаем лишь бы покрыть требования.

Не пртиворечит словам анонимуса.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Правильная модель - это взять 2-3 дорогих, хороших, обвешанных сертификатами архитекторов, и дать им в помощь 50 специалистов подешевле (тоже с сертификатами должного уровня).

Видишь, ты как работодатель лучше знаешь, как строить свой бизнес.

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

Если в твоих проектах все зашибись, то ты все сделал правильно.

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

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

Кстати, ты всех специалистов, развивающихся в невыгодном/непонятном для тебя направлении называешь дибилами и задротами?

Ritmik
()
Ответ на: комментарий от anonymous

сделай так на фвп

Нафига делать, если и так ясно, что это возможно.

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

Завернем еще в пару функций, скроем.

alienclaster ★★★
()
Ответ на: комментарий от alienclaster

Нафига делать, если и так ясно, что это возможно.

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

Завернем еще в пару функций, скроем.

Это невозможно. А с макросами - элементарно.

anonymous
()
Ответ на: комментарий от Ritmik

Кстати, ты всех специалистов, развивающихся в невыгодном/непонятном для тебя направлении называешь дибилами и задротами?

Да, всех. Из жалости к ним же. Потому как будут они нищими и голодными всю оставшуюся жизнь.

anonymous
()
Ответ на: комментарий от anonymous

Опиши процесс поиска замены задроту в ДС. Опиши способ оценки его квалификации. Времени на все - не больше недели. В случае с Java, я просто позвоню в агентство, и на следующий день у меня очередь из десятка кандидатов выстроится.

Видишь, как хорошо. У тебя такая привлекательная работа, что в течении суток 10 человек в очередь выстроиться. Ты так много платишь? Или у тебя проект очень интересный?

Смогу выбрать не просто подходящего по квалификации, но еще и вопросы про гномиков и люки позадаю (тоже ведь развлечение!),

Значит, ты сам специалист, а не бизнесмен? Кем ты все-таки работаешь?

и подберу того, с кем пить интереснее. А что с задротами-то делать?

Ну да, «задроты», пока ты пьешь пиво, корпят, изучают, не останавливаясь на достигнутом. Тяжело и упорно расширяют границы своих знаний. Каждому свое.

Ritmik
()
Ответ на: комментарий от tailgunner

Это Rust.

Можешь привести имплементацию твоего each на фвп?

Ты наверно пропустил. alienclaster сморозил, что «практически любой макрос (если не любой) можно написать используя только фвп, это обсуждалось даже здесь на лоре уже неоднократно.»

Я предложил на фвп написать foreach. Пока кроме неправильного ответа с map-ом ничего не получил.

Ritmik
()
Ответ на: комментарий от anonymous

Ну так (map (lambda (n) ... использование n ...) collection)

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

Ritmik
()
Ответ на: комментарий от Ritmik

Можешь привести имплементацию твоего each на фвп?

Эээ... я не совсем, понял, что тебе нужно, но вот примерная сигнатура each:

each(v: [int], fn(v: int) -> ())

Фактически each принимает вектор и коллбек, а в роли коллбека выступает замыкание. Вот рассахаренная форма:

each(v, |x| { io::println(x) })

Я предложил на фвп написать foreach. Пока кроме неправильного ответа с map-ом ничего не получил.

Тебе дали два ответа. Чем они тебя не устраивают?

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.