drafterleo

Вот в этой косой черте и кроется дьявол — на подобных клавиатурах всё время вместо шифта попадаю в слэш (у меня переключение раскладки как раз Alt+Shift). Самое обидное, что во всём остальном клавиатуры с такой конфигурацией достаточно удобны (большой Enter, вытянутый Backspace), но короткий шифт слева просто выбешивает :).

P.S. Да, функциональные сенсорные клавиши придумал Сатана.

Сатана придумал маленький Shift слева ;).

Никакая.

Пуркуа бы и не па… метемпсихоз

Вот интересные люди — навтыкали минусов, а за что — неясно. Чего не так-то?

умножение матриц используется в...

Мне кажется, изначально всё-таки лучше понимать основную идею: скалярное произведение векторов даёт их корреляцию — то, насколько в целом (линейно говоря) похожи две последовательности чисел. А умножение матриц — это такой компактный способ скалярно перемножать вектора оптом (который хорошо распараллеливается). Ну а дальше и коню понятно, как оно работает, например, в задачах, где требуется сопоставление с образцом — хоть в распознавании сигналов, хоть в преобразовании Фурье.

Собрал модели по афоризмам Ежи Леца и гарикам Губермана:

• пример по афоризмам
• пример по гарикам

Спасибо, всё получилось.

Хм… После регистрации загружаю блокнот ThingsToTry.nb, выбираю ячейку «2 + 2», жму Shift + Enter (как рекомендовано) — ничего не происходит. Выбираю мышкой Evaluation / Evaluate Cells — в ответ тишина. Что я делаю неправильно? Одному мне так не повезло?

Отчего же, охотно верю. Но это отражает удобный Вам подход к разработке. Я, например, прежде чем кодить собственно проект, пишу много маленьких эскизов-черновичков, в которых решаются-проверяются-тестируются частные задачи-идеи-библиотеки, предположительно необходимые для реализации проекта. А потом вспоминаю паттерны проектирования и пишу большое полотно с учётом общей картины (видение которой как раз формируется на эскизном этапе). Причём подобным образом работаю и на С++ и на Питоне (надо ли говорить, что на Питоне в таком стиле работать удобней). Кстати, в последнее время стал замечать, что «большое полотно» всё чаще оказывается не таким уж большим, если правильно подобрать «фреймворк».

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

Про порог в полтысячи строк не совсем ясный принцип — это на весь проект или на один модуль (класс, компонент)?

А если человек выучил и Питон, и C++? :)

Но мы же ведь не знаем, каким путём к человеку попал интерпретатор Питона, правда? А в целом статья — толковая. Если бы ещё код в тетрадку (Jupyter Notebook) был упакован (безусловно-бесплатную) — цены б ему не было.

Глухой телефон в действии.

Испорченный телефон… :)

Запилил простенький веб-сервис — работает не всегда и не навсегда.

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

У меня в трудовом договоре написано «инженер-программист» :). Кстати, по этой логике получается, что «чистый» программист — это тот, кто разрабатывает программно-инструментальный софт (компиляторы-интерпретаторы, IDE, фреймворки и т.п.).

Кто ж с Аристотелем Никомаховичем спорит. Однако, ведь, и лень разная приключается. Бывает пишешь скрипт, потому что лень двадцать раз копипастить. А бывает копипастишь двадцать раз, потому что лень придумывать скрипт. А вот когда и скрипт лень, и копипастить неохота, и сидишь мучительно мечтаешь, как бы оно всё само рассосалось, тогда таки точно — уныние во всей красе. И про тоску-печаль согласен — это совершенно другой вид песеца. Типа засасывающая скорбь о разных тяжких обстоятельствах, мало-помалу переходящая в отчаяние (стон, плач и скрежет зубовный).

Из профессионального источника:

Это конкретно-операционный подход. На ступеньку ниже магическое мышление (культ карго). Уровнем выше — формальное оперирование (создание моделей исходя из понимания общих принципов с учётом перспективы развития). Насколько я понял, Ваши задачи и технологическая среда, в которой работают Ваши решения, позволяют оставаться в рамках конкретно-операционного подхода, т.е. вполне хватает силового, горизонтально-кругозорного расширения (грубо говоря, школьнику третьего класса проще посчитать площадь треугольника по квадратикам на миллиметровке, чем вникать в геометрию Евклида, а такому же школьнику постарше — с хорошей памятью — проще запомнить формулы, чем разбираться, откуда и как они выводятся). Хотя, даже по тексту статьи видно, что Ваше приложение потихоньку, на ощупь выкарабкивалось из горизонтального растекания (Excel -> Delphi + dbf -> MySql), пару раз перерождаясь в новом качестве. Следующий этап — удалённый доступ, распределённая аллокация, микросервисы :).

Что это за программист, который не знает, зачем в коде строка implementation… я и не хочу знать всего этого

Вот прямо-таки совсем неинтересно? :) Кстати, чего-то подобного (модулей) очень не хватает в C++.

А если несколько групп или инверсный счёт? :)

можно использовать localStorage

О! Спасибо за наводку.

Касаемо объективных показателей и когнитивных искажений, в чём-то Вы безусловно правы. Однако, согласитесь, не помнить свою среднюю скорость прохождения таблицы при регулярных упражнениях — это немного странно. Да, в процессе может казаться, что я пробегаю числа очень быстро, но ведь в конце мне явится правильное время и всё станет на свои места. Опять же, стойка на скорость на первых порах может сыграть дурную службу. Привычный скачкообразный паттерн внимания будет давать лучший (более быстрый) результат, чем непривычный деконцетративный. И человек, вместо того, чтобы (спокойно и с удовольствием :)) осваивать новый режим внимания, будет кочегарить старый с логарифмическим приростом (дельта усилий — в бесконечность, дельта выхлопа — в нуль).

Можно отключить, сняв галочку Show Trace в настройках.

С клавиатурой — интересная идея. Постараюсь выкроить время.

По поводу таблицы рекордов… Можно, конечно, заморочиться с сохранением в файл на устройстве пользователя, но зачем? Понимаю, что вопрос философский, однако у меня ко всем этим рекордам есть мировоззренческая претензия. Как мне кажется, «престижный инстинкт» (назовём это так) — безусловный лидер по причинению людям совершенно необязательных страданий. Да, в профессиональной сфере он может быть полезен в качестве стимула (пока не войдёшь в поток). Во всех же других областях желание получить рейтинг повыше — практически всегда напрасное самоистязание. По-моему, базовых волевых навыков (способности выходить из «зоны комфорта» без сравнительно-сопоставительной привязки к конкретным достижениям других людей) — для полноценной жизни вполне достаточно.

Добавил. Опция «Show 69 Dot» в настройках.

Принял, подумаю.

Точно, хорошее предложение. Обязательно сделаю в ближайшее время.

Глаза уже на подсознательном уровне за курсором идут.

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

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

По-моему, это уже излишняя перестраховка из серии «бережёного Бог бережёт» (монашка, свечка, презерватив :)). Даже не припомню, чтобы у меня в программах когда-нибудь вылазила ошибка из-за неправильно поставленной блочной скобки. Влепить лишнюю или, там, случайно затереть — такое бывало. Но тогда вообще не компилируется. А чтобы в них запутаться — это, наверное, только с недосыпу возможно.

P.S. Кстати, я не считаю Ada сложным языком (учитывая, что в своё время съел собаку на Object Pascal) и поэтому, если бы, вдруг, пришлось включаться в проект на этом языке, не морщился бы и не плевался. А вот, например, сказать, что достаточно хорошо знаю C++ (несмотря на то, что программирую на на нём много лет), я бы, положа руку на сердце, не рискнул ;).

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

без фонетики… только смысл, воспринимаемый с экрана

Для этого придуман ихьтаиль (içtaîl) — оригинальная система письма ифкуиля :). Графический вариант, действительно, считывать проще, хотя семантические корни, основанные на котрежах согласнных фонем (да и вообще — фонотактика) и разноплановые сочетания многомерных грамматических матриц никуда не деваются.

Кто ж спорит, однако у этой гармоничности есть своя цена. В качестве аналогии — ифкуиль на уровне грамматики «заставляет» выражать свои мысли чётче и однозначней и в этом гораздо круче любого из естественных языков. Засада в том, что мало кто из реальных людей (даже теоретически) способен его выговорить (58 фонем с тонами!), свободно сочетая многомерные грамматические таблицы по вариативными правилами организации формативов.

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

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

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

Против Ada (как подхода) ничего не имею, идея синтезировать статический анализатор с компилятором вполне себе разумная мысль (нечто подобное пытаются осуществить и упомянутая Farma-C, и набирающий популярность Rust). Но ведь это же не единственный подход. Есть, например, TDD. Опять же, статический анализатор к C++ всегда можно подключить «сбоку». Это как выбор между кухонным комбайном (всё в одном) и набором специализированных устройств (блендер, соковыжималка, мясорубка и т.д.).

Что касается «новых фич», уверяю, ни в одном из языков (в классической вычислительной парадигме) никогда не будет «новой фичи», которой бы до этого не было в Lisp. Да и фича, фиче рознь. По крайне мере то, что я использую из C++[11-14], (на мой взгляд) существенно понижает вероятность ошибок, повышая удобство разработки.

В медицине можно выделить два полюса приложений — учётно-статистические и оперативно-мониторящие. В чистой учётке каждый извращается как может — вплоть до 1С и макросов на Excel, но чем ближе к пульсирующему в realtime телу (когда жизненно критична скорость обработки и отклика), тем больше C\C++ и меньше экзотики. Полагаю, в авиации похожая ситуация. А так, в целом, и SCADA-системы на C# пишут и ЧПУ-станки питоном программируют.

Непременно мутите. Разобраться может и не разберусь (тем более — предельно честно), однако прочту с удовольствием. Если опубликуетесь, закиньте, пожалуйста, ссылочку в этот блог.

P.S. Что примечательно, комбинация « Ctrl + ] / [ » прекрасно работает и в PyCharm — в питоновских блоках.

Присоединяюсь, средство, действительно, замечательное (многие редакторы так же перескакивают на парную скобку по «Ctrl + [»). Однако здесь хотелось бы отметить пару моментов:

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

В современных редакторах есть такие пимпочки, которые позволяют сворачивать-разворачивать структурные блоки (а некоторые даже вертикальные полоски рисуют, чтобы ненароком не прокосоглазить :))