Студентка писала программу. Тыкала кнопки в Visual Studio, получила библиотеку с именем по умолчанию `ClassLibrary1`. Я ей, в числе прочих замечаний, предложил библиотеку назвать как-нибудь более заботливо. Теперь библиотека называется `MyLovelyLibrary`. Ми ми ми.

Или я чего-то не догнал, или в Котлине, если ты хочешь сделать функцию с локальными переменными, тебе придётся возвращать значение при помощи `return`. Я это объехал, от чего код не стал очень красивым: ``` fun bugaga() : Int = when(true) { else -> { val z = 5 z }} ``` Или я чего-то очень-очень не догнал, или Котлин пилили фанаты `goto`...

Есть тут люди, которые рубят во всяких Мавенах и прочих унылых ужасах? * Есть Hello World на Котлине: http://pastebin.com/QWwn6WcX * Есть описание проекта для Мавена: http://pastebin.com/1zb8Dy7T -- тоже ничего особенного, фактически минимум, чтобы Котлин собирался. Если билдишь в чистый каталог, то всё зашибись. А если билдишь поверх уже собранного, то выдаёт следующую дрянь: ``` [INFO] Kotlin Compiler version 1.0.0-beta-2189 [INFO] Compiling Kotlin sources from [D:\tmp\mav\mavk2\my-app\src\main\kotlin] [INFO] Classpath: D:\tmp\mav\mavk2\my-app\target\classes;C:\Users\d\.m2\repository\org\jetbrains\kotlin\kotlin-stdlib\0.1-SNAPSHOT\kotlin-stdlib-0.1-SNAPSHOT.jar;C:\Users\d\.m2\repository\org\jetbrains\kotlin\kotlin-runtime\0.1-SNAPSHOT\kotlin-runtime-0.1-SNAPSHOT.jar [INFO] Classes directory is D:\tmp\mav\mavk2\my-app\target\classes [INFO] Module name is my-app [ERROR] D:\tmp\mav\mavk2\my-app\src\main\kotlin\name\dluciv\test1\App.kt: (4, 1) 'public fun main(args: kotlin.Array<kotlin.String>): kotlin.Unit' is already defined in name.dluciv.test1 ``` Т.е. он **до смерти** пугается только что откомпилированного самим собой кода. С Java таких дурацких проблем, понятное дело, нету. С какой стати это происходит и как бороть?

Интересно, а собирали ли в M$ статистику того, насколько часто при ошибках сборки в Visual Studio пользователь соглашается запустить последний успешно собранный вариант (они это до сих пор предлагают)?.. А отдельно после того, как говнокодить в Visual Studio на C++ стали меньше?..

В 10-й Винде консоль якобы стала лучше. Я не заметил. По крайней мере она как UTF-8 не поддерживала, так и не поддерживает нормально. Можно сказать ей `chcp 65001`, и тогда можно будет нормально выводить текст в UTF-8. Но ввести его при помощи, например, fgets как раньше нельзя было, так нельзя и сейчас. Что характерно, если взять Cygwin или MinGW, и воспользоваться их `cat.exe`, то умная кошка знает, что имеет дело с долбанутой виндовской консолью, и всё поправляет как надо. Т.е. если запустить `cat | моя_программа.exe`, то в `stdin` уже пойдут строчки вполне себе в UTF-8. Не знаю, м.б. это и не консоль, а стандартная библиотека в исполнении M$ в составе Visual C++. Пофиг. Всё равно разочарован. Когда они наконец это поправят?.. А если я чего-то не понял, то чего именно?..

Структурная обработка исключений -- вещь тормозная, известное дело. Занятно сделано в Rust. Примерно как принято в Эрланге -- не проматчилось -- до свидания. Хотя в Эрланге можно, пусть и не особо принято, ловить ошибки и структурно. Но уж если в Rust действительно есть опасения, что что-то внезапно долбанёт, то туши свет: http://stackoverflow.com/a/30824812/539470 Согласен, вероятность невелика, если программировать, как учат, но когда отлов, например, деления на ноль (которого может и не произойти) требует запуска отдельного потока -- вот это мощь. Тормозная плюсовая раскрутка стека не то что курит в сторонке, она вообще уже ушла %).

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

Насколько Лого функциональный язык? http://dluciv.livejournal.com/178394.html

Тупо переписал свой стандартный любимый вычислительный тест (объём N-мерных шаров методом Монте-Карло) с Юли на Си. На Юле программа считала 3 секунды, на Си 14. На Си безбожно тормозили случайные числа. Более 90% времени. После того, как заменил вызов `rand` на константы (смищно, да) и в Си, и в Юле, Си стал вдвое быстрее Юли. Тогда я убрал из программы на Юле аннотации типов, откуда можно было. И внезапно она стала не вдвое, а всего в полтора раза медленнее Си. Отсюда три вывода: 1. Мой дурацкий пример вполне вписывается в эту картинку: http://julialang.org/benchmarks/. 2. Компилятор ставит аннотации типов лучше меня (логично, я Юлю второй день знаю). 3. Юля няша.

Интересно, Julia когда-нибудь станет "языком общего назначения", на котором пишут более или менее всё?.. Тот же Хаскелль стал же. Пусть у него целевая аудитория и состоит, в основном, из не очень большого количества задротов, но зато никому в голову не придёт сказать, что он заточен под какой-то определённый класс задач. Потому что всем понятно, что основная идея программирования на Хаскелле -- сам процесс программирования на Хаскелле. Вот под что Хаскелль заточен на самом деле %). А Julia похоже к этому в принципе не стремится.

Кто-нибудь юзал http://julialang.org/ ? По-моему она не такая платная, как Матлаб, не такая тормозная, как Питон, и не такая отстойная, как они оба. А ещё на видео бородатый чувак в халате, прямо как я https://youtu.be/Eb8CMuNKdJ0 Кто-нибудь скажет pros/cons?..

У многих языков с неизменяемыми данными есть одна неприятная особенность: если надо поменять что-то в здоровой структуре данных где-то в глубине, приходится тяжко. Когда надо поменять одно поле в записи, это не страшно: http://stackoverflow.com/questions/14955627/shorthand-way-for-modifying-only-one-field-in-a-record-copy-a-record-changing . Аналогичный синтаксис есть и у Эрланга, и у F#, и наверняка ещё до фига у кого (думаю, у большинства даже). А вот возможности поменять _одно_ грёбаное поле в середине здорового дерева нет ни у кого... Даже у F#, у которого она просто таки напрашивается, на мой взгляд, из синтаксиса. Можно конечно всякий раз заливать, что раз, мол, языки функциональные, так пусть все куски, которые требуется менять, и будут функциями, но это не всегда удобно. Например, (де)сериализация функциональной структуры данных -- геморрой, а если между сериализацией и де сериализацией успел поменяться код, то серьёзный геморрой. За что такая несправедливость, и чем себя утешить?

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

У многих программных проектов, если посмотреть полную историю со всеми ветвями, ветвистость просто бешеная. Первое впечатление обычно -- люди сидят, ломают голову, поддерживают код и процесс разработки в целостном и непротиворечивом состоянии. Однако секунд через 15 становится ясно, что все просто делают commit, потом push, потом круглые глаза, следом pull, затем merge, и наконец опять push.

Судя по https://developers.google.com/apps-script/, Apps Script загибаться не планирует. Вроде же его хотели тоже прикрыть. Или я с чем-то путаю?

Интересно, многие ли будут рвать на себе волосы из-за Google Code?..

Когда-то сравнительно давно, в #82SN7E, спрашивал я про точные координаты тегов в XML и как их достать из Питона. Я для этого использовал SAX, и @stiletto мне то же самое советовал, но SAX выдавал слишком мало информации о привязке по координатам к исходному тексту. Дык вот. Если хотите до хрена информации, то юзайте Pygments. Забавно, да? Он вообще-то совсем не для того нужен, но в итоге с задачей справляется лучше, чем специально предназначенные для XML парсеры (хотя по моим прикидкам работать он будет заметно медленнее, но меня почти любая `O(n)` устроит, а там она). В частности, Pygments позволяет очень хорошо различать `<тег></тег>` и `<тег/>`, с чем я при использовании SAX трахался до полусмерти.

LGPL отличается от GPL тем, что допускает динамическое связывание с закрытым кодом. Всё чудесно, но только в нынешних реалиях слова "динамическое связывание" по сути не говорят вообще почти ни о чём. Вот например пишу я программу на C. В ней, допустим, реализован алгоритм, который я не хочу показывать. Тогда GPL мне использовать нельзя. А LGPL можно, но только если лицензированные под ней артефакты будут отдельными файлами. А если я эту прогу соберу под, например, Андроид, где никто без распаковывания этих файлов не увидит, это считается?.. Ладно, вот пример экстремальнее. Я пишу программу на Питоне и юзаю PyQt, который GPL. Ок, всё, что непосредственно взаимодействует с Qt, тоже будет GPL (либо прощайте £350, или сколько там). Но другие модули своей программы я могу лицензировать, как захочу (WTFPL например, чтобы убрать вирусность). Причём я по идее даже могу из них вызвать GPL-ный модуль, так как это ни фига не динамическое связывание: интерпретатор Питона просто загрузил оба файла, как данные, и что-то с ними делает. Это по сути неправильно, но формально-то как? Я чего-то принципиальноне так понял? Если да, то как правильно?

Я тут внезапно вспомнил, кто ещё любит Rust: http://youtu.be/wpVTORX_ifk

Кто с metalua сталкивался вплотную? Её можно заставить выдавать исходный код на lua, а не байткод?