| Carp |
[сент. 28, 2020|02:30 am]
caml_programmer
|
Обнаружил реализацию ещё одного ЯП:
https://github.com/carp-lang/Carp
Похож на Clojure, но со статической типизацией из коробки.
Несколько отличается от Typed Racket. В Typed Racket даже
какой-то минимальный вывод типов встречается, пока не
понял есть ли такое в этом Carp-е. |
|
|
| Rust |
[ноя. 21, 2019|09:16 pm]
caml_programmer
|
Нафигарил макрос для Rust, чтобы поменьше писать.
macro_rules! p { ( $( $x:expr ),* ) => { println!($($x,)*); }; }
|
|
|
| Haskell, Erlang update |
[сент. 1, 2016|12:37 am]
caml_programmer
|
Haskell не перестает удивлять, одну и ту же задачу можно
решить неизвестным количеством способов, и каждый следующий
будет лучше предыдущего.
А вот компиляция Erlang очень существенно повлияла на его
производительность, почти в 3 раза. Судя по strace, он
какое-то время инициализируется, а потом довольно шустро
работает, не исключаю, что в случае сервиса - догонит
haskell и rust.
Постепенно скорости выравниваются и возможно придется
отдельно считать время запуска runtime-а, либо нивелировать
его тестовым файлом большего размера. С другой стороны,
если писать не сервис, а утилиты, то время запуска runtime-а
нужно тоже учитывать.
О, день знаний, всех короче с праздником! |
|
|
| Erlang update |
[авг. 30, 2016|10:20 pm]
caml_programmer
|
Erlang вариант переписали, стало гораздо лучше - 6.415 секунд.
https://github.com/DMSOFTWARE/cats/pull/2 |
|
|
| Haskell update |
[авг. 29, 2016|10:06 pm]
caml_programmer
|
Отлично, размер буфера haskell-варианту зачинили.
теперь он с результатом 2.019 вплотную догнал rust и python,
но до тройки go, c++, c - немного не дотянул.
https://github.com/DMSOFTWARE/cats/pull/1 |
|
|
| Заколхозил тест ввода/вывода для всех языков программирования |
[авг. 27, 2016|03:42 am]
caml_programmer
|
Вот такая ситуация пока получается.
https://github.com/dmsoftware/cats
Haskell и SBCL рисовать не стал, они оба где-то 2m50s отрабатывают,
и масштаб графика сильно портят. Ну Haskell там монады из себя
высасывает, а SBCL-то что капризничает?
Erlang - надо доработать, чтобы тест корректно завершался,
а то кажись там halt не срабатывает, что-то с этим надо
сделать. Но он тоже довольно задумчивый, наверное сопоставим
с Haskell и SBCL.
Nodejs меня как-то смутил прям - вроде пишу по документации,
а callback не вызывается, как ожидаешь, в результате этот
придурок качает всё в память пока не подыхает от обжорства.
В общем надо его тоже как-то зачинить что ли.
До APL-подобных языков я почти добрался, не знаю, есть ли
там ввод/вывод, но посмотрим. |
|
|
| Чистые функции против сайдэффектов. |
[авг. 11, 2016|12:53 am]
caml_programmer
|
В программировании, когда хочется сделать какой-нибудь счётчик,
первая мысля возникает, что нужен оператор присваивания, который
запишет по существующему адресу новое значение.
Но, если перевести это решение на бумажный материальный носитель,
то присваивание нового значения по тому же пространственному
адресу уже не кажется каким-то особо красивым решением.
Также можно вспомнить всякого рода сканеры электро-магнитного поля
для жестких дисков (чтобы считывать более старые записи по тому же адресу) -
в этом плане жесткие диски чем-то бумагу (материальный носитель)
напоминают.
Возникает вопрос, что для материальной реальности более естественно -
переаллокация или присваивание?
Например, явление размножения мне больше переаллокацию напоминает,
нежели присваивание. Соответственно, новые объекты живут, чтобы
выполнять задачу на них возложенную, а за старыми приходит
сборщик мусора. С другой стороны, если в какую-либо
пространственную точку поместить саморазвивающийся материальный
объект, то это можно рассматривать и как элемент присваивания,
можно даже сказать присовывания.
В общем, неоднозначно можно сказать что ничерта не понятно
как всё устроено. |
|
|
| Программерское |
[фев. 9, 2016|02:33 am]
caml_programmer
|
Около 12 лет мне потребовалось, чтобы окончательно упарить OCaml-ом всех на работе.
Ибо курс там взяли на jvm-язычки (clojure,scala,java), у которых туго с отдачей памяти обратно в
систему - для ситуации когда много серверов - на одно jvm-приложение - это не критично, но
в нашем случае могло быть и 20-30 jvm на одном серваке - налицо архитектурная неаккуратность.
У ЯП OCaml есть всего две проблемы, влияющие на производительность - наличие однопоточного
сборщика мусора и отсутвтие unboxed-типов данных. Но зато при рантайме в 5Mb - весьма приятный
fork - с которым проблем не возникает, если использовать в паре с асинхронным вводом/выводом.
Что там с параллельным сборщиком мусора - я так и не понял - то ли пока не сделали, то ли
сходу не получилось из-за последующих проблем с производительностью (при его включении).
В общем за более чем 12 лет я не нашел ни одной проблемы в компиляторе OCaml-а (хотя поискать
порой хотелось). Самое пожалуй неочевидное для новичка - это применение мутабельных строк и
массиовов по-умолчанию (можно организовать побочный эффект).
Последний год активно исследовал вопрос производительности приложений, написанных на различных
ЯП и пришел к очевидному выводу - что пора "тряхнуть стариной", это как со старыми ружьями - которые
из-за меньшего максимального давления в канале ствола - выглядят заметно легче и элегатнее
современных образцов. То бишь думаю повнимательнее посмотреть на программирование на голом C,
на крайняк C++ - речь тут конечно о задачах (где важна скорость и минимальное потребление
ресурсов оперативной памяти), а для обеспечения надеждности - есть достаточный запас ресурсов.
В общем принцип - чем ближе к железу - тем меньше ограничений. Соотвественно для меня
нормальным подходом всегда было и будет - достаточно низкоуровневое производительное ядро,
которое уже скриптуется поверх динамическими встроенными языками - либо ядро оформляется
как либа и используется в приложении на более высокоуровневом ЯП.
Сейчас, в течении какого-то времени буду отдыхать и смотреть вакансии по двум
направлениям - либо управление шайкой диких программеров, либо какая-нибудь новенькая
(хорошо забытая) для меня специализация (например С/C++). В общем, можно и ещё что-нибудь
рассмотреть, если дело стоящее так сказать. Про Haskell, Erlang я и не мечтаю - но если
вдруг, то почему бы и нет. Erlang - поприятнее java-технологий мне показался.
А Haskell - у меня ещё впереди (может когда-нибудь дорасту). |
|
|
| Книги, программирование |
[ноя. 26, 2015|10:08 pm]
caml_programmer
|
На работе подарили немного озоновских сертификатов, вот сижу, выбираю, каких бы книжек заказать.
Пока навыбирал две вот эти книжки:
Предметно-ориентированные языки программирования (Signature Series)
http://www.williamspublishing.com/Books/978-5-8459-1738-6.html
NoSQL: новая методология разработки нереляционных баз данных
http://www.williamspublishing.com/Books/978-5-8459-1829-1.html
Вроде ничего особо нового, но можно будет новым "программистам" ткнуть пальцем
в книгу, вместо того, чтобы о чем-то разговаривать.
Ещё присматриваюсь к:
Model Checking:
http://www.ozon.ru/context/detail/id/2182741/
http://www.ozon.ru/context/detail/id/4797670/
Методы оптимизации:
http://www.ozon.ru/context/detail/id/7106050/ |
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| [ |
go |
| |
earlier |
] |
| |
|
|
