- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
std::optional<int64_t> readNumber(const wchar_t *&str)
{
const wchar_t *origStr = str;
if (*str == L'-' || *str == L'+') {
str++;
if (!std::iswdigit(*str)) {
str--;
return {};
}
} else {
if (!std::iswdigit(*str)) {
return {};
}
}
while (std::iswdigit(*str)) {
str++;
}
return wcstoll(origStr, NULL, 10);
}
HoBorogHuu_nemyx 07.01.2019 13:43 # −1
gost 07.01.2019 13:50 # −1
ASD_77 07.01.2019 19:51 # −1
roman-kashitsyn 07.01.2019 20:12 # −1
Поясните мысль.
> без указания "копировать" или "передать"
void f(const string& s); // "передать"
void f(string& s); // "передать" и разрешить нагадить в строку
void f(string s); // "копировать"
Что тут должен угадывать "умный" компилятор и зачем? Где компилятор "умный"?
fuckyou 07.01.2019 20:50 # −105
В таких случаях можно даже нарисовать график. Кривая долгое время идёт по фазе плато, затем наступает компенсаторный крах.
1024-- 07.01.2019 20:58 # −1
Всякие T, T*, T&, const, std::move, std::foward, std::shared_ptr, std::uniqie_ptr, стек, кучу, раскладку структур по байтам, паддинги, раскладку аргументов в стеке надо знать.
Передать массив, вернуть массив? Сразу надо продумывать, два массива это или один, где их хранить. Даже простой fmap не реализуешь.
fuckyou 07.01.2019 21:22 # −102
gpyrou_nemyx 07.01.2019 21:30 # 0
bormand 07.01.2019 23:19 # −10
HoBorogHuu_nemyx 08.01.2019 00:27 # 0
Я теперь понял, почему Dummy против тайпдефов и почему он так любит явно каждый раз писа́ть слово «struct».
rOMOCEKCYAjluCT 08.01.2019 01:13 # −100
Распевы петуха
И говорю,
Что если был бы в силе,
То всем бы петухам
Я выдрал потроха,
Чтобы они
Ночьми не голосили.
Но я забыл,
Что сам я петухом
Орал вовсю
Перед рассветом края,
Отцовские заветы попирая,
Волнуясь сердцем
И стихом.
vaceknt 08.01.2019 01:15 # 0
vaceknt 08.01.2019 01:18 # −1
gost 07.01.2019 22:05 # 0
То ли дело «Java».
То ли дело «PHP».
То ли дело «
roman-kashitsyn 08.01.2019 00:38 # +1
> простой fmap не реализуешь
возьмём для примера fmap для std::vector ЧЯДНТ?
bootcamp_dropout 08.01.2019 01:00 # 0
gost 08.01.2019 01:23 # +2
bootcamp_dropout 08.01.2019 01:39 # 0
А написать чтобы оно принимало все возможные итерируемые контейнеры сложно?
roman-kashitsyn 08.01.2019 02:00 # +1
Чтобы принимало — легко, сложно возвращать контейнер того же типа. Если возвращать всегда вектор, то тривиально, только это уже не настоящий fmap будет. Тут пример gost снова не компилится, но по другой причине — компилятор не осиливает вывести тип Seq. Вот так вроде работает:
Если можно добавить перегрузки для f, если хочется, но так с выводом типов для лямбд проблемы начнутся.
gost 08.01.2019 02:42 # +2
https://ideone.com/OXbnXL
bootcamp_dropout 08.01.2019 02:51 # +2
gost 08.01.2019 03:19 # +1
https://wandbox.org/permlink/LzoO6uc9s4p06erE
1024-- 08.01.2019 03:43 # +1
https://ideone.com/tbe7wk
Только не прокатит с контейнерами с кастомными аллокаторами. *
Зато вывод типов - почти тот же, что и был:
P.S. * Хотя, с точки зрения функтора из ФП это не требуется. С точки зрения функтора пользователь сам пердолится с дополнительными параметрами, а нам отдаёт контейнер как однопараметрический тип.
gost 08.01.2019 11:12 # +1
https://ideone.com/UIa7Kw
Правда, получилось дерьмо, которое копирует входную последовательность целиком. Можно, конечно, в Generator хранить константную ссылку, но тогда получается ещё большее дерьмо, и в gmap не получается передать временные объекты вроде «{1, 2, 3}».
gost 08.01.2019 11:21 # 0
gost 08.01.2019 12:36 # +1
«Ideone» не поддерживает божественный «C++17»: https://wandbox.org/permlink/B0Cebyx4ORrq7YB2 (хотя можно убрать «if constexpr» и получить то же самое на «C++14»).
gost 08.01.2019 15:05 # 0
gost 08.01.2019 21:53 # 0
https://wandbox.org/permlink/jvCQLPgFM34d03Yd
roman-kashitsyn 08.01.2019 10:46 # +2
gost 08.01.2019 12:38 # 0
gost 08.01.2019 01:15 # 0
Стоит убрать это уёбищное <int, int> — и получаем:
https://ideone.com/t1E4yA
1024-- 08.01.2019 01:37 # 0
gost 08.01.2019 01:40 # 0
1024-- 08.01.2019 01:43 # +1
1024-- 08.01.2019 01:42 # +1
Только внутри какие-то копирования странные, число которых варьируется чёрт знает по какой логике: https://ideone.com/XwiHUb.
Неясно, что будет с монадическими значениями питухами, чувствительными к этому (хранящими ресурсы и т.п.).
ASD_77 08.01.2019 13:24 # 0
а как насчет такой читабельности и почему нормальные компайлеры могут это скомпилисть :)?
```
for(const x of [1, 2, 3].all(x => x * 1.5).all(x => x * 2))
// print (x)
```
bootcamp_dropout 08.01.2019 13:44 # +1
1024-- 08.01.2019 16:37 # +1
Хотя, в Haskell есть синонимы покороче:
gost 08.01.2019 16:39 # 0
roman-kashitsyn 08.01.2019 16:45 # +2
gost 08.01.2019 16:51 # +1
> ⍳
Я знаю, я знаю! Это std::iota йота, которая генерирует натуральные числа с единицы! Спасибо крестам за широту кругозора!
gost 08.01.2019 14:03 # +3
1) Что такое «[1, 2, 3]», где оно хранится, какой размер имеет и когда будет уничтожено?
2) Где хранятся, какой размер имеют и когда будут уничтожены элементы из списка (если, к примеру, мы хотим так проитерировать по списку строк)?
3) Что принимает «all()», где хранится, какой контекст захватывает?
4) Что возвращает «all()», где этот объект хранится и когда будет уничтожен?
5) Что «возвращает» оператор «of» и где хранится x?
Все эти вопросы, кажущиеся несколько надуманными, приобретают смысл тогда, когда нам надо сделать что-то чуть менее тривиальное:
1) Сохранить для дальнейшего использования результат вызова «all()» или какой-нибудь из x;
2) Получить модифицированную коллекцию и куда-нибудь сохранить;
3) Использовать кастомный аллокатор (для тестов памяти, например);
4) Не использовать динамическую память вообще, только стек;
5) И так далее.
Язык с более простой моделью памяти и меньшим контролем над ней самостоятельно решает эти вопросы, при этом:
1) Тратит такты на разруливание этих вопросов в рантайме;
2) Позволяет изменять стандартное поведение размещения объектов только в жёстких и узких рамках.
Короче говоря, все эти конструкции — последствия ебли с памятью. Другое дело, что синтаксис и инструменты крестов для этого — дерьмо, да.
ASD_77 08.01.2019 14:50 # 0
gost 08.01.2019 15:02 # 0
ASD_77 08.01.2019 16:52 # 0
1) [1, 2, 3] - компилятор видит что это массив констант численного типа и все они не больше 8 бит (16 или 32). значит он знает что это "const int[]"
2) далее компилятор видит что размер масива не такой уж большой и можно его хранить к стэке
3) далее компилятор видит что это итерационный тип данных
4) далее компилятор видит что Х в лямбдах это типа целого числа
а вот и все... никакого ИИ не надо
bormand 08.01.2019 16:54 # −10
1024-- 08.01.2019 17:01 # 0
bormand 08.01.2019 17:04 # −10
Привет ветвлениям прямо посреди горячего кода. Предсказатель всё-таки не резиновый.
gost 08.01.2019 18:10 # 0
Нет, это не надуманная проблема: http://www.osronline.com/article.cfm?article=347. Спойлер: за 15 лет ничего не изменилось.
И да, «соптимизировать» тривиальный пример можно и на крестах:
1024-- 08.01.2019 16:54 # +1
Не надо оптимизировать произвольные программы, нам надо оптимизировать только те программы, которые реально написаны и важны. Программы пишутся людьми, которые либо в молодости пишут всякую неважную фигню, которую не надо оптимизировать, либо в старости пишут важный софт, но уже мыслят шаблонами. Человек учится порядка 50 лет, набор его шаблонов ограничен.
Соответственно, знатно попердолившись, можно наковырять шаблонов под текущие мышление и моду и создать такие оптимизаторы.
Здесь ситуация аналогична парсингу регулярками и управлению АЭС. Людям кажется, что регулярка сама по себе не распарсит грамматику выше регулярной, а АЭС сама по себе сдохнет без ИИ, поэтому не надо их использовать. Но регулярка может запускаться произвольное количество раз программой под машину Тьюринга, а за АЭС постоянно следит несколько живых людей, которые принимают решения.
Так и тут, можно не мечтать о сильном ИИ, который будет оптимизировать программы, а посадить лучшие умы, чтобы следили за разработкой оптимизатора.
Любителей низкого уровня у нас достаточно, и они будут обеспечены пожизненно почётной и интересной работой метапрограммистов. С появлением нового паттерна мышления или новой моды программирования они будут добавлять их в оптимизатор, который будет всегда работать хорошо, но чуть хуже работы самых передовых умов, что на практике достаточно.
roman-kashitsyn 08.01.2019 16:59 # +2
> рассуждает о перфомансе
Какие же вы лалки.
Самый умный компилятор из тех, что я видел — GHC. Но даже его заставить генерить быстрый код — чёрная магия, передающаяся из уст в уста и сопровождающаяся долгим и томным чтением Коры. А самое смешное, что следующая версия компилятора легко может сломать все твои намёки компилятору, даже если ты сам Брайен О'Салливан.
И вот, после долгих ночей ручной настройки прагм, написания рулов оптимизации и тонкой ручной параллелизации ты будешь награждён программой, которая весит всего 2 гигабайта (ИНЛАЙН, детка!) и работает всего лишь в 4 раза медленнее простой крестовой версии.
Умные компиляторы — это сильно текущая абстракция. Если хочется предсказать пирфоманс, нужно детально понимать, как они работают, а это зачастую сложнее, чем просто наговнявкать на C++ за полдня.
Все ваши рассуждения окончатся тем же, чем когда-то закончилась "автоматическая параллелизация программ". Только наивные простачки верят в эти сказки.
>> синтаксис и инструменты крестов для этого
синтаксис какой-нибудь растишки не сильно лучше, скорее наоборот.
bootcamp_dropout 08.01.2019 17:09 # 0
По-моему, отличная абстракция. Вся информация, которая нужна для оптимизации, уже есть - исходный код.
Другой вопрос - что, конечно, на данном этапе это нереализуемо, но в долгосрочной перспективе веб-макаки, пишушие тормозной говнокод, вносят в развитие этой идеи гораздо больший вклад, чем разработчики с++, которые подсказывают компилятору как компилировать огромным количеством конструкций, отношения к самой логике программы не имеющим. А это - как минимум хороший повод для словоблудия, времени-то у веб-макак за счет быстрого вываливания говна полно.
1024-- 08.01.2019 17:16 # 0
У нас наверно 90% программирования в этом стиле.
Решить задачу? Нет.
* Перевести задачу с человеческого на программистский
* Изучить компиляторный язык, библиотеку, фреймворк
* Перевести с программистского на компиляторный, объяснить всякую питушню
* Смёрджить то, что насрали коллеги.
* Написать коммент к коммиту в VCS, отчитаться в баг-трекере и на совещании
* Написать документацию (хотя хороший интерфейс - отсутствие интерфейса, хорошая программа - самодокумментирующаяся)
* Переписать код, чтобы его лучше поняли коллеги
* Переписать документацию, поскольку код изменился
* Проверить почту на уведомления от начальства, VCS, баг-трекера
* Искать очередной баг
roman-kashitsyn 08.01.2019 17:22 # +2
НЕТ. Документация описывает не ЧТО происходит, она описывает контекст, ПОЧЕМУ это происходит.
bormand 08.01.2019 18:27 # −10
bootcamp_dropout 08.01.2019 17:22 # 0
Другой вопрос - что когда ты садишься за компьютер и начинаешь программировать, ты думаешь не о совещании и интерфейсах, а о том как бы чего лишнего не скопировалось и не просадило тебе performance, ведь уже точно никто не оптимизирует.
1024-- 08.01.2019 17:31 # 0
Совещания, интерфейсы, перфоманс - только палки, которые жизнь вставляет в колёса программостроительной машины. Соответственно, чем быстрее с ними разобраться, тем лучше поедет машина.
bormand 08.01.2019 17:33 # −10
А вот нихуя подобного.
1024-- 08.01.2019 17:50 # 0
bormand 08.01.2019 17:53 # −10
Всё ясно, необратимая деформация сознания.
Написание программы может быть одним из элементов решения (а может и вообще не быть).
1024-- 08.01.2019 18:04 # 0
Если мы имеем дело с конторой, занимающейся созданием программ, то и приходят туда для того, чтобы их проблему автоматизировали написанием программы. Максимум - приходят для того, чтобы поддержали их старую программу, т.е. посмотрели бы, выкинули из неё немного плохого кода и написали немного хорошего.
Если же в контору, занимающуюся написанием программ приходят затем, чтобы решить проблемы нехватки офисной мебели и компьютеров, то это просто увольняющийся сотрудник под шумок своенравно продаёт казённое имущество.
bormand 08.01.2019 18:09 # −10
А, ты о галере. Ну ок.
1024-- 08.01.2019 18:21 # 0
И здесь, когда задача программирования уже поставлена, будут совещания, интерфейсы, возня в перфомансом - вынужденная нефункциональная питушня.
bootcamp_dropout 08.01.2019 18:11 # 0
bormand 08.01.2019 18:18 # −10
Вся эта хуета в комплексе и будет решать проблему юзера. Да, согласен, многое из этого будут делать другие люди. И многое уже сделано и можно заюзать готовое. Но как минимум подумать об этом всём стоит.
bootcamp_dropout 08.01.2019 17:41 # +1
Проблему клиента решают манагеры и сейлзы. Роль программиста в этом празднике жизни настолько малозначительна, что его можно выбросить и выкинуть разработку на аутсорс каким-то индусам.
1024-- 08.01.2019 17:58 # 0
https://www.youtube.com/watch?v=Y7uKmQS__jc
Я, конечно, согласен, что программисты (как и писари в своё время) получают деньги только за то, что остальной люд тупо не может осуществлять элементарные действия.
Но называть прокладку между клиентом и разработчиком решателем проблем - это сильно.
Я бы отдал звание решателя проблем архитектору. Этот человек действительно делает самое важное, и его хрен заменишь в отличие от заедушных манагеров.
bormand 08.01.2019 18:00 # −10
В тред призывается девочка-волшебница архитектор.
bootcamp_dropout 08.01.2019 18:09 # 0
Сейлз не является прокладкой между клиентом и программистом. Програмист является прокладкой между ненаписанным и готовым продуктом.
1024-- 08.01.2019 18:34 # 0
Если гусар сидел на бирже и проиграл в карты два имения, которых у него не было, то они нигде магически не построились.
Если банк выдал в кредит сумму, не обеспеченную не то что ресурсами, даже реальной валютой, то от этого нигде новые поля, колхозы, заводы и небоскрёбы не построились.
Экономика так или иначе завязана на реальные ресурсы. Экономика стабильна только пока не более некоторого процента людей занимается выводом игровых денег в реальный мир; пока не более некоторого процента людей занимаются лохотронами.
Если будет 90% честных контор и 10% лохотронов, которые делают упор на рекламу, не имеют разработчиков и продают воздух, то отрасль выдержит.
Если будет 10% честных контор и 90% лохотронов, которые делают упор на рекламу, не имеют разработчиков и продают воздух, то никто не будет покупать программы, которые с вероятностью 9/10 представляют собой чистый DVD-R в яркой коробочке.
Просто пока процент честных контор и процент честности велик, и некоторые могут сэкономить на разработке.
Но всё равно, конторы с продавцами сырого говна в долгосрочной перспективе будут терять клиентов (кроме распилоориентированных проектов).
Основную прибыль приносит не кассир, которому клиент принёс деньги, а те, кто работал над созданием программы напрямую - архитекторы и разработчики.
Все остальные (кассир, техничка, менеджеры, сисадмины, охранники, юристы) - обслуживающий персонал, без которого контора будет работать нестабильно.
bootcamp_dropout 08.01.2019 18:40 # 0
Чтобы каждый отдавал по способностям и получал по потребностям, и чтобы платили за заебанность.
1024-- 08.01.2019 18:59 # 0
> чтобы платили за заебанность
Это на загнивающий запад. Вроде там рабочему человеку достойно платят.
Капиталист вполне себе хорошо разруливает подобные ситуации. В долгосрочной перспективе (а) без программистов новые программы не будут продаваться, (б) сложно вырастить новое поколение программистов. Соответственно, ценные программисты вполне могут дать отрасли почувствовать, кто тут приносит деньги и выровнять зарплату за счёт незаменимости.
Правда, для капитализма нужно ещё мыслящее население, которое умеет голосовать рублём и не покупает тонкие стеклянные смартфоны без 3.5мм разъёма и сырые недописанные программы.
bootcamp_dropout 08.01.2019 19:12 # 0
На загнивающем западе благодаря товаrищам платят достойно даже безработным. К капитализму, как понимаешь, это имеет опосредованное отношение
>Капиталист вполне себе хорошо разруливает подобные ситуации
Да капиталист вообще отлично разруливает такие ситуации - выкинет выебщиков и найдет того кто напишет.
То что ты пишешь, конечно, замечательно, но несколько утопично, может даже нереализуемо. Давай лучше остановимся на практике, а на практике вещи сложились таким образом, что место среднего прикладного программиста - у параши.
1024-- 08.01.2019 19:51 # 0
> К капитализму, как понимаешь, это имеет опосредованное отношение
Вообще-то, у каждого молодого капиталиста автоматически обнаруживается соответствующая часть материальных ресурсов страны, которые он автоматически инвестировал и получает дивиденды.
Если этих дивидендов нет, то значит, что орудуют не капиталисты, а шулеры.
> Да капиталист вообще отлично разруливает такие ситуации - выкинет выебщиков и найдет того кто напишет.
Согласен. Заказчик найдёт контору, в которой руководят те, кто разбирается в вопросе. Окажется, что без дармоедов-менеджеров программа будет написана быстрее, качественнее и дешевле.
bootcamp_dropout 08.01.2019 20:30 # 0
gost 08.01.2019 17:41 # 0
Это далеко не вся информация. Конпелятору надо как минимум знать:
1) Рахитектуру и конфигурацию машины, на которой будет выполняться код (нет, вариант «оптимизируем под то, на чём компилируем» — плохой);
2) С какими данными будет работать код: обработка десятимегабайтного файла и, скажем, терабайтного — принципиально разные вещи, различить которые без подсказок компилятор не сможет никак;
3) Примерные лимиты использования ресурсов, в первую очередь — памяти (связано с первым пунктом).
А ещё у нас есть библиотеки, которые далеко не всегда доступны для включения в проект в виде исходных кодов. А оптимизировать крупную библиотеку для общего случая — так это вообще нереализуемая задача, потому что у компилятора не будет даже всего кода итогового приложения.
bootcamp_dropout 08.01.2019 17:57 # 0
gost 08.01.2019 18:23 # +1
Впрочем, тут возникает вопрос, кто «умнее» — программист, (обычно) не обладающий высокой теоретической квалификацией, но имеющий представление о предметной области, либо же оптимизатор, с которым всё ровно наоборот. Без подробных статистических исследований вопрос этот — по большей части философский.
bootcamp_dropout 08.01.2019 18:35 # 0
N^2 в N - сложность исключительно алгоритмическая, она интересует разработчика.
Допустим в рамках этого N нам надо получать элемент из списка. Можно получать из односвязного списка, а можно из массива. Это вроде как сложность алгоритмическая, но к алгоритму отношения не имеющая, ее вполне решит компилятор.
А архитектура, нужная процедура для обработки терабайтного файла, размер стека - вещи, которые вообще к программе отношения не имеют - их поручим рантайму.
gost 08.01.2019 19:17 # 0
Если бы. С точки зрения чистой математики — да, исключительно алгоритмическая. А в реальных компьютерах абстракции текут, и вроде бы линейные алгоритмы совершенно незаметно раздуваются (https://www.joelonsoftware.com/2001/12/11/back-to-basics/ — статье больше 18 лет, а актуальность никуда не делась). Ну вот, к примеру:
Добавляем к строке N символов. Абстрактный O(N) алгоритм, превращающийся из-за потёкших абстракций в O(N^2), а потом — как рандом на душу положит. Последняя версия Хромиума, к примеру, успешно сводит его обратно к линейному:
Это время выполнения одного вызова с 100 и 10000 символами соответственно. Вторая версия взята из текущей версии: https://github.com/stevemao/left-pad/blob/master/index.js.
Да, не квадрат, оптимизатор работает. Только вот всё равно сосёт у ручной оптимизации аж на два порядка — потому что при всей своей крутости (превратил «Шлёмелевские» O(N^2) в O(N)) оптимизатор ниасилил превратить O(N) в O(log2(N)).
А если он не осиливает даже такой максимально тривиальный пример — то как можно говорить о каких-то супероптимизациях массива в бинарное дерево и прочей магии?
Что касается терабайтных файлов — увы, отдать это на откуп рантайму нельзя, потому что они требуют совершенно другого подхода. Магическое автораспараллеливание как было, так и осталось сказкой, а программисты продолжают пердолиться с MapReduce.
bootcamp_dropout 08.01.2019 19:29 # 0
Да и я оговаривался в начале: все эти рассуждения исключительно умозрительны, можно о них поговорить как о светлом будущем.
>Что касается терабайтных файлов — увы, отдать это на откуп рантайму нельзя, потому что они требуют совершенно другого подхода.
Почему же нельзя? простейшая эвристика: если размер файла превышает столько-то, "подсунуть" под вызов из программы другую процедуру.
roman-kashitsyn 08.01.2019 19:52 # +1
Которая построит датацентр, купит железа, настроит сеть оптимальным образом, а всё расходы оплатит с кредитки разработчика.
bootcamp_dropout 08.01.2019 20:10 # 0
roman-kashitsyn 08.01.2019 20:20 # 0
И решение о том, будете вы выполнятся в браузере пользователя/Azure/GCP/AWS принимает V8 в рантайме исходя из результата вызова stat(). Понятно.
bootcamp_dropout 08.01.2019 20:25 # 0
1024-- 08.01.2019 20:14 # 0
А вот эта графовая питушня с весами из подавленности проводов дверьми, глюкавости оборудования, меняющейся со временем загрузки и т.п. уже и правда плохо поддаётся расчётам живыми людьми, пусть её софт оптимизирует.
1024-- 08.01.2019 20:09 # +1
Тогда можно программирование закрывать. Везде, кроме НИИ и подобных мест, где заказчики сами пишут код, будет нечестный пример.
ТЗ всегда будет выражено на недостаточно высоком уровне чтобы можно было всю ответственность передать на программиста.
Компилятор должен быть телепатом, как и программист.
bootcamp_dropout 08.01.2019 20:28 # 0
gost 08.01.2019 21:14 # +1
Ну а в контексте умозрительных рассуждений так и подавно это всё питушня. ЯП — нинужная прослойка между мешком с мясом (и деньгами) и компьютером. Даёшь ИИ-программиста!
> Почему же нельзя? простейшая эвристика: если размер файла превышает столько-то, "подсунуть" под вызов из программы другую процедуру.
Потому что чтобы «подсунуть» процедуру — эту процедуру кто-то должен напейсать. Если это должен делать программист — то непонятно, зачем вообще городить рантайм, когда можно обойтись банальным «if file.size > 1000000 { drugaya_procedura(); }». А если она должна генерироваться автоматически — то мы возвращаемся к компиляторам и умным оптимизаторам, которые должны будут предусмотреть все возможные варианты файлов — и маленькие, и большие, и зожатые, и sparse, и с высокой энтропией, и лежащие на дискетах, и на удалённых дисках… Почему все возможные варианты? А потому что компилятор имеет доступ только к исходному коду. Он не знает, зачем этот код нужен. А программист знает, что обработка зожатых удалённых файлов ему по ТЗ не нужна — и может оптимизировать только те кейсы, которые ему по этому ТЗ нужны.
1024-- 08.01.2019 20:07 # 0
O(log2(N)) - какая-то питушня. Если строка - массив символов, лежащих в одном куске памяти, то даже программист не может сделать O(log2(N)), т.к. самый простой алгоритм будет либо дописывать N нулей, либо двигать len(str) символов.
O(log2(N)) достигается только сменой контейнера. Бинарное дерево, хранящее ветви по ссылке, может с этим справиться, делая что-то вида
Но это на стороне программистов означает либо смену контейнера, либо смену языка, а на стороне оптимизатора - подстановку этого контейнера. Странно, если бы программист в рамках недеревянного JS String добился бы O(log2(N)) сам.
gost 08.01.2019 21:05 # 0
…даёт в итоге [25, 20, 20, 16, 16, 18, 17, 18, 15, 17, 17, 17, 17, 20, 18, 18, 16, 19, 20, …, 19, 20, 21, 21, 20, 20, 21, 22, 19, 20, 20, 22, 21, 21, 22] (округлено до целого). Видимо, оптимизатор как раз во что-то такое древоподобное и оптимизировал.
Но в любом случае, вручную оптимизированный пример наивной реализации даёт пососать.
1024-- 08.01.2019 22:42 # +1
Потому, что с точки зрения математики любой невыведенный результат считается за O(1).
Попробуйте, константа USE_IO_MONAD_FOR_RESULT переключает сложность алгоритма с O(logN) до O(N):
Если константу включить, из строки сохраняется один символ для последующего использования (я хотел брать случайный, но оптимизатор в Node.js 11.6.0 не настолько хорош, поэтому уже с нулевым начинает тормозить). Если выключить - сохраняется пробел - чисто для симметрии, чтобы никто не говорил, что это += тормозит.
Для случая с взведённой константой я уменьшил количество вызовов leftpad, но это компенсируется тем, что печатается результат для одного вызова.
1024-- 08.01.2019 22:50 # 0
gost 08.01.2019 22:50 # +1
[18, 17, 24, 24, 26, 31, 37, 39, 44, 52, 60, 64, 72, 77, 70, 82, 88, 91, 87, 93, 96, 100, 106, 107, 113, 118, 119, 134, 131, 144, 144, 165, 188, 179, 183, 180, 185, 194, 178, 193, 221, 210, 187, 204, 222, 209, 227, 224, 224, 237, 231, 235, 242, 263, 265, 262, 271, 296, 313, 311, 322, 289, 328, 317, 335, 292, 311, 375, 362, 352, 349, 351, 372, 391, 408, 392, 394, 423, 421, 394, 439, 477, 405, 451, 437, 485, 493, 506, 503, 460, 482, 431, 473, 495, 494, 553, 498, 504, 486, 573]
1024-- 08.01.2019 23:54 # 0
Хотя, у меня leftpad_1 даёт результат, который больше на O(N) похож.
gost 08.01.2019 23:56 # +1
stepanPlus7 09.01.2019 00:05 # −1
Faike 05.04.2023 23:24 # 0
1024-- 09.01.2019 00:15 # 0
bormand 09.01.2019 07:14 # −10
Пишут, что D8 должен уметь.
roman-kashitsyn 09.01.2019 00:02 # +2
Ну так строки в ЖС вроде как раз как деревья местами реализованы. Мы это как-то обсуждали уже почти 3 года назад
http://govnokod.ru/19692
gost 09.01.2019 00:12 # 0
Alina_Poksenova 04.04.2023 08:05 # −10
Ну и слава богу!
gost 08.01.2019 19:18 # 0
bootcamp_dropout 08.01.2019 19:30 # 0
gost 08.01.2019 21:15 # 0
bormand 08.01.2019 21:57 # −10
bootcamp_dropout 04.09.2022 17:17 # 0
guest6 04.09.2022 17:18 # −10
guest6 04.09.2022 17:19 # −10
Ладно, я в детстве тоже много хуйни нёс и хуёвого кода писал и совершенно идиотские мысли отстаивал
guest6 04.09.2022 17:21 # −10
guest6 04.09.2022 17:22 # −10
bootcamp_dropout 04.09.2022 17:22 # 0
guest6 04.09.2022 17:28 # −10
Этому поверью уже лет тридцать примерно, и всё как-то не случилось.
bootcamp_dropout 04.09.2022 18:00 # 0
> Этому поверью уже лет тридцать примерно, и всё как-то не случилось.
https://wiki.c2.com/?SufficientlySmartCompiler
1024-- 08.01.2019 17:10 # 0
Мне кажется, программы, оптимизированные JSными движками, работают быстрей, чем программы на языках с ручной памятью, оптимизированные веб-программистами. И стоят дешевле, и писать их легче.
> И вот, после долгих ночей ручной настройки прагм, написания рулов оптимизации и тонкой ручной параллелизации ты будешь награждён программой, которая весит всего 2 гигабайта (ИНЛАЙН, детка!) и работает всего лишь в 4 раза медленнее простой крестовой версии.
Мясные программисты тоже ошибаются.
Чукче не надо бежать быстрее медведя, чукче надо бежать быстрее геолога.
bormand 08.01.2019 17:12 # −10
А самое главное - они работают. В отличие от "программ на языках с ручной памятью, оптимизированных веб-программистами".
gost 08.01.2019 18:02 # +1
«Компьютерная программа» сейчас — это по сути руководство, по которому компьютер проводит какие-то вычисления и получает какой-то результат. Императивные, декларативные, функциональные, объектно-ориентированные программы — все они в конечном дают процессору какие-то указания, которые он должен выполнить. Проблема же состоит в том, что для божественной оптимизации недостаточно сказать «возьми вот этот массив и сделай с ним вон ту операцию». Чтобы оптимизировать код, компилятор должен понимать, для чего этот код нужен, и что он в конечном будет делать. Не «обрабатывать массив чисел с плавающей точкой», а «подсчитывать медиану цен на акции Apple». Не «рисовать окошко с красным цветом», а «информировать пользователя, что он неправильно ввёл пароль».
Никакие современные языки программирования общего назначения не дают возможности указать компилятору, что хочет заказчик. Даже в супер-мега-овер-высокоуровневом «JS» программисты всё равно сношаются с какими-то текущими абстракциями — числами, строками, массивами, хэш-таблицами, списками, функциями, коллбэками, промисами, запросами и прочей хренью. В «PHP» ничего из этого нет, поэтому я за «PHP». Современные ЯП общего назначения не имеют возможностей выражения задачи в терминах предметной области. Поэтому «идеального компилятора» нет и не будет — пока не сменится сам подход к написанию программ (и, разумеется, языки).
Собственно, решений это проблемы — целых три:
1) Развивать DSL'и (гораздо глубже, чем есть сейчас). В результате получим очень много компиляторов разных языков, которые божественно компилируют крайне простые и многофункциональные программы — но только в своей, крайне узкой области.
2) Налегать на ИИ и развивать язык программирования, на котором можно будет действительно объяснить компьютеру, что мы хотим сделать.
Faike 05.04.2023 23:25 # 0
до тех пор, пока на них не пишут строки кода, они не говно.
gost 08.01.2019 18:02 # +1
1024-- 08.01.2019 18:46 # 0
Хотя, вместо (1) и (2) я бы предложил развивать ИИ, который будет понимать естественный язык, поскольку у нас уже сейчас происходит минимум один перевод с языка на язык до процесса программирования - в момент, когда заказчик объясняет задачу исполнителю. Если же заказчик и исполнитель комплексные (группы людей), дополнительные переводы возникают внутри заказчика и исполнителя. Если ещё всё происходит в межнациональных конторах, то перевод осуществляется не на уровне описания идей, но и с формального языка на формальный, а то и два раза - со своего на английский и обратно.
Формальный программистский язык для ИИ - такое же говно, как и формальный английский язык для межнационального сообщества - вынужденное говно, на котором сливается лишняя доля смысла.
gost 08.01.2019 19:21 # 0
gost 08.01.2019 17:29 # 0
Есть божественный «Си» с божественным синтаксисом (кроме синтаксиса указателей на указатели на подпрограммы, принимающие указатели, это всё первородный грех). Все остальные попытки создать «Си, только чтобы модно-стильно-молодёжно» пока что закончились либо пшиком, либо крестами (синтаксис Ржавого входит в последнюю категорию).
roman-kashitsyn 08.01.2019 17:58 # +1
У меня были большие надежды на http://claylabs.com/clay/
Жаль, что он сдулся.
inkanus_gray 06.04.2023 18:25 # 0
Жаль, что он сдулся.
И что? Из-за этой хуйни ты покинул говнокод?
OcemuH 08.04.2023 13:37 # 0
gost 08.01.2019 17:17 # +1
Кхм.
1024-- 08.01.2019 17:23 # 0