Кстати, что интересно — сейчас проверял, в сети МГУ github доступен. Причём, что характерно, скажем, grani.ru там тоже так и не перекрыли. Там, наверное, больше следят, чем блокируют?
У меня было 3 колеса от нивы, комплект всесезонки от ВАЗ 2115 и 4 почти облысевших летних покрышки от Фокуса на слегка гнутых дисках. Не то, чтобы это был необходимый запас для разблокировки гитхаба…
Что интересно, я одно время наблюдал mitm-подмену сертификата для сайта navalny.com в МГУшной сети. При этом tcptraceroute на порт 443 navalny.com обрывался на одном из хостов, относящихся к RUNNet.
Стандартный CLOS в таких реализациях, как SBCL и CCL, работает достаточно шустро.
Но когда начинается использование кастомных метаклассов, целый ряд оптимизаций
отключается. У меня в одном проекте (встраиваемая система контроля и управления
ускорителя электронов) пришлось от активного использования MOP'а отказаться,
когда понадобилось запускать штуковину на 600MHz ARM'е (Cortex-A8).
Красит все иконки, найденные в текущей папке и её подпапках, воспроизводя
структуру папок в /tmp/out — с раскрашенными иконками. Можно записать
в одну строку (через ';').
Несложно доработать до полноценной утилиты (color="$1", out="$2" и т.д.)
Отмечу важное свойство языка: эксепшнов нет. Без полноценного GC, впрочем, от них, в зависимости от неаккуратности программиста, может быть немалый вред в связи с утечками — но, в любом случае, эту особенность стоит иметь в виду.
Присоединяюсь к этому требованию. Государство не должно вмешиваться в работу Сети. Только что-то мне подсказывает, что если подобный лозунг написать на плакате и пойти с ним на предстоящую «ностальгическую» демонстрацию 1-го мая — повинтят. Кстати, за ряды Фурье тоже повинтят, мне кажется — на всякий случай.
Ух ты, упустил такую дискуссию. Тем не менее, откоменчусь, как говорится, for posterity
Представим себе, что sugar и lodash перестали развиваться, sugar'у на смену пришёл не очень совместимый rafinad, а lodash'у — не очень совместимый zlodash (хотя у sugar'а шансов перестать развиваться больше — сами же авторы справедливо подчёркивают, что его нельзя использовать, например, в библиотеках, так что аудитория у него заведомо меньше).
В случае lodash/underscore _-конструкции, требующие корректировки, можно найти в большинстве случаев среднехитровыдуманным grep'ом. В случае же sugar… return hrenRedkiNeSlasche().nafig.map('qqq') — это sugar или нет? Там массив, или что-то другое? Type inference anyone?
Теперь ещё раз рассмотрим авторский справедливый запрет на использование в либах. Откуда они берутся, эти либы и фреймворки? Бывает, пишутся с нуля именно как либы. А бывает, извлекаются из имеющегося кода. Например, компания решает публиковать какие-то инструментальные части своего продукта в виде открытых библиотек. В либах sugar использовать нельзя, ок, значит, его надо оттуда убирать. И вот у нас либа на полмега JS-кода и в ней эти самые упомянутые hrenRedkiNeSlasche().nafig.map('qqq'). Увы :( Хорошее тестовое покрытие может слегка помочь, но боли всё равно будет очень много.
Скажете, надо заранее знать, какие части кода могут пойти в библиотеки, а какие нет? А всегда ли это можно предвосхитить?
К этому ещё DNS 8.8.8.8. (на d3 подсказали, что подсеть /22, а не /24)
Но когда начинается использование кастомных метаклассов, целый ряд оптимизаций
отключается. У меня в одном проекте (встраиваемая система контроля и управления
ускорителя электронов) пришлось от активного использования MOP'а отказаться,
когда понадобилось запускать штуковину на 600MHz ARM'е (Cortex-A8).
Красит все иконки, найденные в текущей папке и её подпапках, воспроизводя
структуру папок в /tmp/out — с раскрашенными иконками. Можно записать
в одну строку (через ';').
Несложно доработать до полноценной утилиты (color="$1", out="$2" и т.д.)
И ведро аутентичной таджикской стекломойки. Хм, впрочем, замёрзнуть может…
Представим себе, что sugar и lodash перестали развиваться, sugar'у на смену пришёл не очень совместимый rafinad, а lodash'у — не очень совместимый zlodash (хотя у sugar'а шансов перестать развиваться больше — сами же авторы справедливо подчёркивают, что его нельзя использовать, например, в библиотеках, так что аудитория у него заведомо меньше).
В случае lodash/underscore _-конструкции, требующие корректировки, можно найти в большинстве случаев среднехитровыдуманным grep'ом. В случае же sugar… return hrenRedkiNeSlasche().nafig.map('qqq') — это sugar или нет? Там массив, или что-то другое? Type inference anyone?
Теперь ещё раз рассмотрим авторский справедливый запрет на использование в либах. Откуда они берутся, эти либы и фреймворки? Бывает, пишутся с нуля именно как либы. А бывает, извлекаются из имеющегося кода. Например, компания решает публиковать какие-то инструментальные части своего продукта в виде открытых библиотек. В либах sugar использовать нельзя, ок, значит, его надо оттуда убирать. И вот у нас либа на полмега JS-кода и в ней эти самые упомянутые hrenRedkiNeSlasche().nafig.map('qqq'). Увы :( Хорошее тестовое покрытие может слегка помочь, но боли всё равно будет очень много.
Скажете, надо заранее знать, какие части кода могут пойти в библиотеки, а какие нет? А всегда ли это можно предвосхитить?