В том то и дело, что может возникнуть работа, подобную которой ты уже раньше выполнял. Тогда тупо копируешь скрипт, чуть меняешь и вуаля.
Получается очень мощное позитивное подтверждение. В результате пересиливать уже не надо, а наоборот когда нет возможности заскриптовать аж ломки начинаются. Только и думаешь: «а это я бы в циклик засунул», «а это вообщее одной строчкой можно сделать»...
насчет матлаба - и в самом деле неинтересно.
А чем вам питоновский репл не угодил? И почему многословен? Мне питон для численных задач не нравится убогостью (на мой взгляд)
массивов в Numpy
питон как ни крути это язык общего назначения. всё полезное вставленное в него выглядит для меня как обернутое лишним слоем что ли.
по крайней мере более короткий код чем на R получается только в J (но его я использую только как калькулятор на телефоне :) ).
это тоже полезно, может очередной придурок из очередного гогле задумается прежде чем рекомендовать всем писать «=» вместо "->" ну или аналогичную херню с инструментами которыми кто то пользуется как положено, а не «как мне тупому удобно». беда в том, что когда таких «как удобно» становиться много, то «миллионы мух перестают ошибаться».
а кончается это тем, что ходить на ногах вместо рук становится неприлично, и приходится это делать тайком.
что-то я не видел там мотивацию писать в функциональном стиле, там кроме слов о том, что нужно максимально автоматизировать и писать reusable код, ничего и нет:) в таких статьях обычно примеры очень сладкие, а здесь...
логичнее (тоесть можно опираться на интуицию), я уже приводил пример абсолютно неинтуитивного кода на октаве (а поскольку я практически на ней не пишу и столкнулся в первом же практическом применении, то всё с легаси перетащенной из матлаба ясно).
Я тоже предаочитаю автоматизировать, вместо того, что бы «работать на результат» (с).
Угу. Если есть возможность, вестимо.
Кстате, разрабам прикладного локального софта не мешало бы включать скриптовые возможности для адвансед юзерз. Если, конечно, рентабельность позволяет.
ну, пусть хоть for()ом оформляют свой код, рано или поздно придут к мысли что руки не казенные и выразительные конструкции языка намного экономнее чем копипаста и имитация вручную с помощью вложенных циклов.
это первая ступенька по крайней мере и она ведет на поле языка в котором возможно нормальное программирование.
Кстате, разрабам прикладного локального софта не мешало бы включать скриптовые возможности для адвансед юзерз. Если, конечно, рентабельность позволяет.
Столман прав как никогда, и как всегда не понят. Это его идея что архитектура свободного приложения вокруг интерпретатора схемы должна быть построена (ну а схема уже дергает за сишные и прочие функции в которые выносят уже сложившийся и неэволюционирующий код (или код который исходно критичен по памяти и скорости)). естественно репл схемы торчит как интерфес адванцед пользователя.
Ошибка его в том, что не дал детям «написать свою схему» в каждом новом проекте. Ну к примеру как в R написали :) Это дает фан разработчикам и воспитывает их сообщество.
Ну дык проблема передачи знаний актуальна всегда. Точнее, не самой передачи, но адекватного восприятия замысла передающего.
Иногда это зовётся «школой», но это не совсем точное определение.
Поэтому, собсна, и имеем в ИТ, что имеем. Да и не только в ИТ.
репл схемы торчит как интерфес адванцед пользователя
Особенно актуально, когда ты сидишь за тыщи км от разрабов, юзаешь ихнее поделие, оно виснет и глючит, на саппорте сидит какой-нить «инженер-программист», который толком ни архитектуру не понимает, ни айпи не знает, и ты сделать не можешь ничего, кроме написания имэйлов в саппорт.
И поправил бы сам под локальные нужды, да не можешь: нет ни исходников, ни возможностей.
в статье эта тема не раскрыта, она вообще там упоминается в паре предложениях типа «хороший код удобно использовать, быстрый код приятно использовать» =)
а код на R где то так и пишу, только часто приходится себя пересилить оформлять функции, а не пытаться все оформить одним блоком кода :) умом чувствуешь что лучше будет, а руки так и тянутся соорудить в шесть строчек конструкцию где все подстановки выполнены по месту :) да и возможность в репле просоо нажать срелку вверх и повторить на редакцию всю конструкцию провоцирует.
ну в моём случае это лиспы и F#, не принципиально конечно, просто статья слабая, вот я о чём :) В ней сначала пишут как не для программистов, а потом зачем-то говорят как код писать нужно, даже без примеров. Но если я не программист, какая мне разница как код писать, для меня это всё равно что рассуждать про несферический коллапс у нейтронных звёзд, когда я не знаю что такое нейтронные звёзды) Или про смысл твинтурбо, когда я не в курсе как работает одна турбина.
нет призыв писать код красиво нужны всегда, это просто логичное продолжение основной мысли статьи --- «механическая работа на результат» вредна и проигрышна.
отсюда эти все for() писатели в R берутся, а там не за горами и «неошибающееся большинство» :(