← All posts tagged программирование

habrahabr.ru

Ставлю на то, что это фейк. Если нет, то у парня что-то с мозжечком, или там ещё с чем. Посмотреть бы, как он выглядит. Дело не в том, что он программки научился писать, я в это верю как раз сравнительно легко. Дело в том, какой он текст написал.

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

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

Я это объехал, но код красивее что-то не стал:

```
fun bugaga() : Int = when(true) { else -> {
val z = 5
z
}}
```

Или я чего-то очень-очень не догнал, или Котлин пилили фанаты `goto`...

Есть тут люди, которые рубят во всяких Мавенах и прочих унылых ужасах?

* Есть Hello World на Котлине: pastebin.com
* Есть описание проекта для Мавена: pastebin.com — тоже ничего особенного, фактически минимум, чтобы Котлин собирался.

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

```
[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.
Не знаю, м.б. это и не консоль, а стандартная библиотека в исполнении Visual C++. Пофиг. Всё равно разочарован. Когда они наконец это поправят?.. А если я чего-то не понял, то чего именно?..

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

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

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

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

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

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