Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 245
Пока есть возможность закидывать железом - будут закидывать. Когда исчерпают возможность, пойдут оптимизировать.
Никто не слушает советов, как сделать всем лучше, каждый решает как сделать лучше лично себе (теория игр, ага). В итоге все идут в кризис и никто не может остановиться, потому что остановись сейчас, погибнешь сейчас, а не потом.
Боюсь это все уже проще обоссать и поджечь, чем оптимизировать. И чем дальше - тем хуже.
Вопрос финансов - только и всего.
Слабое и дорогое железо, а время инженера дешево - "Оптимизация наше все!".
Быстрое и дешевое железо, а время инженера дорого - "Железо все вытянет!".
Добавить сюда нюансы принятия решений (поиск "серебряной пули", личные интересы и прочее-прочее-прочее) и получим текущую картину.
Когда исчерпают возможность, то просто всё сломается и будет глобальный крах. Некому уже будет оптимизировать. Даже сейчас уже некому.
Почти все всех сферах жизни так, на самом деле. Никому невыгодно думать наперед, делать качественно и все такое, выпуская то что сегодня на 3 копейки дешевле по себестоимости чем у конкурента - ты выигрываешь, в итоге остаётся только то что на 3 копейки дешевле (заметьте, что не для потребителя). Ну а что потом проблемы вылазят - так без разницы, у тебя уже монополия, связи с властями и в итоге на содержание твоего поделия уже всей страной (любой), а то и всем миром скидываются.
Так выглядит системный кризис капитализма, он уже просто не может нормально применять технологии которые даёт миру
Когда я не так давно про это же самое (что дело в кривом и жрущем коде) писал - мне сказали, что потребление чипов не растёт же, всё норм. Ну норм, так норм. Может хоть умного человека (который оригинал статьи написал) послушают.
Напоминает историю создания игры "The Witness", и почему Блоу решил запилить собственный 3D-движок.
Мы создали идеальный шторм
Кто мы-то? Есть 2 конкретных актора безобразия. ИИ-провайдеры, которые сапогом забивают свой продукт вам в глотку ради прибылей или KPI. И ИИ-гики вроде этого самого Джейсона Лемкина, которые думают, что поймали б-га за яйца. Вот в это спортлото и пишите.
Почему в формуле:
инструменты, которые усиливают некомпетентность, используются разработчиками, которые не могут оценить результаты, и проверяются менеджерами, которые доверяют машине больше, чем своим сотрудникам.
Вы увидели только ИИ? :)
Потому что Zeitgeist, контекст времени. С одной стороны весь бигтех орёт с пеной у рта что у них 146% кода пишется ИИ. С другой стороны калькуляторы, которые якобы потребляют 32Гб оперативки (пруфов не видел, так что верю наполовину). О чем тут еще думать, кроме ИИ? О байткоде джавы?
Ну самое неприятное это когда AI код подмешивают с обычным. Чаще всего это трескается по избыточным комментариям с большой буквы на русском (если промпты на русском, в комментарии в проекте на английском) и длинным тире(— вместо -).
Мб мы придем к тому, что введем аннотации для обозначения AI кода и будем следить за соотношением таких строк к количеству строк кода в проекте по аналогии с покрытием тестами.
Пример: лид предлагает реализовать фичу через вызов метода foo из библиотеки. Я не нахожу такого метода и даже близких методов тоже не нахожу. Иду проверять другие версии библиотеки и исходники на GitHub - не слова. Оказывается этот оболтус скинул мне ответ какой-то LLM, не проверив. Если бы он скинул ответ целиком, а не только название несуществующей функции, я бы понял, что это ответ ИИ, и проверял бы в 5 раза меньше по времени и без ощущения, что я глупый и не догадался взять метод из библиотеки, с которой я столько работаю
Как итог, люди которые пишут код на постоянной основе знают как работают LLM, а если не знают, то знают, что им нельзя верить. А всякие менеджеры, мимо крокодилы и те, кто код не пишет, воспринимают ИИ, как реальный интеллект, верят и даже не знают, как часто они брешат (если спец уже 3 года не пишет код, то он тоже сюда относится, поскольку не успел поработать с LLM).
Проблема наверное в том, что в первичном приближении ИИ реально машина. А по факту все на этом хайпят, а сценарии использования у него гораздо меньше, чем нам обещают
В статье кстати тоже длинные тире
Вот и мне показалась статья нагенерированной. Но скорее всего автор написал что-то вроде черновика, а потом попросил ИИ подготовить текст к публикации.
Это не длинные тире, а просто тире. Просто автор (переводчик) пишет грамотно, и использует тире, а не дефис.
Ворд автоматически заменяет тире на длинные, например.
По поводу длинного тире - когда пишешь таски/репорты в гитлабе/ютреке или ещё где-нибудь - система сама предлагает заменять короткие на длинные. Меня эти подчёркивания бесят и я вручную потом со всем соглашаюсь. В итоге те же длинные тире как у "ИИ", хотя я даже хз как их напечатать на клаве самому.)
Еще очень весело когда спрашиваешь компетентного мнения, а в ответ тебе кидают скрины с ГПТ.
У меня недавно был вопрос к коллеге, как интерпретировать исходные данные. Короче, нужно компетентное мнение (или отказ, мол "я не знаю"). Что делает товариСЧ? начинает кидать скрины с чатГПТ... с кусками кода. Да блин, у нейронки я и сам спросить могу, как и погуглить. Раз я к тебе обращаюсь, значит на первых n-страницах гугла ответа нет (или интерпретация не ясна). Второе, вопрос был не в коде, а в понимании процесса. Кончилось все тем, человек 1.5 дня отвлекал меня уточнениями, тратил время на промт, который сгенерил какой-то код(300+ строк), предложил мне в нем разобраться, при этом на вопрос - а как оно интерпретирует ИД? последовал ответ - х.з. На вопрос - что это за хардкод и return 13**10? почему 13 и почему 10? ответ х.з.. На вопрос а оно вообще работает? Шедевральный ответ - ну на тестовом кейсе все ок. Да, б*я, на тестовом кейсе с хардком у меня тоже все работает (хардкод же), но надо же чтобы код работал на любом кейсе
Уххх у меня до сих пор горит от того бесполезности потраченного времени
Это Вы очень скромно ограничили круг почитателей ИИ.
А как же бизнес, который, закусив удила, принялся с усердием внедрять ИИ где надо и где не надо, почуяв запах крови экономии?
А как же тимлиды и сеньоры, которые не видят разницы между джунами и ИИ?
А как же вайб-кодеры, которые, не написав в жизни ни строчки кода, с удовольствием осваивают новую стезю - кто в качестве хобби (да и хрен бы с ними), а кто и в айтишники-волчары (подутих, кстати, хайп на Хабре, а?) подался.
А так - да, никто в глотку не забивает...
Неверно. К появлению ИИ на рынке IT-индустрия шагала к краху уже лет так 14. Первыми ласточками были облака и гонка циферок версий браузеров.
Это говно началось задолго до ИИ, и уже много лет как выходят статьи подобные этой, только раньше других обвиняли, а не ИИ. Вот, например: https://habr.com/ru/articles/673236/
Для меня первым шоком было когда в начале нулевых на Delphi 5 (кажется 5, но может и более ранняя версия) проект с пустой формой и одной кнопкой экзешник занял аж 600кб, этож охренеть как много! Такой-же но на чистом WinAPI занимал всего 5кб.
Насколько помню, то и на стандартных компонентах дельфы тогда можно было делать очень маленькие экзешники, но конечно же с одним большим НО - для работы такой программы в системе должны быть обязательно все нужные bpl'ки.
Но само собой по сути никто с этим не запаривался и почти все использовали вариант "все пихаем в экзешник", т.к. вариант с использованием bpl ради экономии размера самого экзешника только затруднял распространение написанного на дельфе софта.
За то Делфи компилил любой проект за секунды, в отличие от канонического и "экономного" c++. А время компиляции это куда большие деньги и энергия чем лишние килобайты на диске
А теперь сделайте тот же проект на "современном" стеке. С высокой вероятностью туда притащат электрон, и будет у вас не 600кб а 600мб
Значит ли это, что тестирование не работает, не работают методологии разработки?
Почему нет упоминая про биткоин, который потребляет огромные объемы электроэнергии?
Крах это про человечество в целом.
Вы звездочку возле названия Meta поставили, а расшифровать её забыли.
А у меня лет 6ть назад был такой прикол.......... И тогда я понял к чему все идет. Я врач и чтоб расслабить пациентов веду с ними беседы. И в отношении программистов я прикалывался так.... Математику любите, спрашиваю..... Хотите задачку, большинство конечно говорили да. После чего я давал несколько задач. Допустим 2 класс, 5класс на алгоритм, это все со звездочкой. И третья вступительная в Гугл или Майкрософт. Все задачи решил сам, ну мне иногда по приколу..... Так дальше 5 го класса никто не продвигался. А один особо умный мне сказал, а на х...... Мне математика я же программист. И был мне виден переломный момент в возрасте, 35, 40 лет. Они как раз решали, а все кто до сорока, этот квест сливали в основном
Задачи в студию
Вот три задачки в стиле того врача:
2 класс (со звёздочкой):
У тебя 100 рублей. Покупаешь шоколадку за 67 рублей. Продавец даёт сдачу только монетами 5 и 10 рублей. Какую минимальную сумму он переплатит тебе, если у него нет монет по 1 рублю? И 2 рублевых тоже нет.
5 класс (алгоритмическая):
Есть 3 кувшина: 8л (полный), 5л и 3л (пустые). Как отмерить ровно 4 литра? Переливать можно только из кувшина в кувшин.
Google/MS:
У тебя есть функция rand5() - даёт случайное число от 1 до 5. Напиши rand7() - равномерно от 1 до 7. Использовать можно только rand5().
---
🧮 Модель: #Claude 4.1 Opus
На 3й задаче я всё-таки срезался, просто по невнимательности. Болею...
А вообще, возьмите Перельмана (Якова)
В моей схеме задача про кувшины это 2 ой класс., правда правда.... 🤣 . задача за пятый класс советской школы со звездочкой. Алладин нашел в пещере 10 мешков монет. Один мешок монеты фальшивые. Отличить можно по весу. Положим весят на грамм больше или меньше. В пещере есть весы ( тип весов любой). Из мешков с монетами можно брать любое количество монет. Как за одно взвешивание определить в каком мешке фальшак.
Ай я яй. Ошибочка. Про кувшины задача для второго класса есть два кувшина 5 и 3 литра а воды сколько хочешь. Как отмерить 4 литра.... Вот эта за второй класс. И на ней люди с высшим образованием ломаются. Экономисты руководители ломаются на вопросе чему равна диагональ квадрата со стороной 1.
здесь ключевое что в одном мешке все монеты фальшивые и одинаковые
весы вешают в граммах, то есть тип весов не любой
а фальшивая монета отличается ровно на 1 грамм
незачет вам
Вы что-то напутали. Если весы сравнивают два груза, то за одно взвешивание вы никак не определите фальшивый мешок. Или у нас с вами разное понимание о том, что считать взвешиванием.
Пусть фальшивые монеты весят на грамм меньше, для примера
Из первого мешка берём 1 монету, из второго 2, из 3его 3 итд. Всю эту кучу взвешиваем, видим что вес на 4 грамма меньше, чем если бы все монеты были настоящие. Значит 4 монеты в куче фальшивые, значит это 4ый мешок
P. S. Извиняюсь, я ошибся и привёл решение задачи под комментарием про тип весов и оно с этим комментарием не связано
Del
Ilyawolpert
только что
Я возьму из 1го мешка одну монету, из 2го 2е монеты, ....... Из 10мешка 10 ть монет. Положу на весы и взвешу. Потом просто посчитаю. Мне кажется элементарно. А Вы кстати, что закончили? Какой Вуз?
только что
Я возьму из 1го мешка одну монету, из 2го 2е монеты, ....... Из 10мешка 10 ть монет. Положу на весы и взвешу. Потом просто посчитаю. Мне кажется элементарно. А Вы кстати, что закончили? Какой ВУЗ?УЗ?
Это требует, чтобы весы показывали вес в граммах. Просто в задачах такого типа (найдите фальшивую монету), которые я раньше видел, чаще встречаются весы для сравнения (легче-тяжелее), а формулировке, приведённой выше, тип весов вообще не указан.
Для весов легче-тяжелее за одно сравнение определить невозможно. Для весов в граммах тоже есть закавыка: даже если мы заранее знаем, что фальшивка на грамм тяжелее (или на грамм легче) мы должны как минимум знать вес одной настоящей монеты, что потребует ещё одного взвешивания. Потому что иначе мы не будем знать ожидаемый вес кучки монет, чтобы сравнить его с реальным.
У тебя есть функция rand5() - даёт случайное число от 1 до 5. Напиши rand7() - равномерно от 1 до 7. Использовать можно только rand5().
(картинка осла из "Шрека")
i=rand5()+rand5()+rand5()+rand5()+rand5()+rand5()+rand5();
return mod (i,7)+1;
Нет. Получится гауссиана в качестве распределения. Точнее - грубое приближение к гауссиане.
Получится гауссиана в качестве распределения.
С чего бы? У контрольной суммы файлов, к примеру (такая же сумма случайных байтов по модулю) никакой гауссианы не получается.
Есть такое свойство. Гуглите "центральная предельная теорема".
Математика программисту не нужна. (Ц)
Неправда, нужна математика уровня 5 класса
нужна математика уровня 5 класса
Именно, а то иногда случается оверматематинг. Например, та задача про летающую между велосипедистами муху, прочитав условия которой математики тут же бросаются рисовать интеграл вместо того, чтобы немножко подумать.
А что это за задача?
Скрытый текст
Два города, А и Б, находятся на расстоянии 300 км друг от друга. Из этих городов одновременно выезжают навстречу друг другу два велосипедиста со скоростью 50 км/ч. Вместе с первым велосипедистом из города А вылетает муха со скоростью 100 км/ч. Встретив второго велосипедиста, муха разворачивается и летит обратно к первому. Встретив первого, разворачивается и летит ко второму. И так она продолжает летать, пока велосипедисты не встретятся. Сколько километров пролетела муха?
Скрытый текст
Велосипеды встретятся проехав 150 км. 150/50 = 3 часа. Муха будет летать три часа. 3 * 100 = 300км.
Правильно?
Правильно?
Для пятиклассника правильно. А математик не сможет решить без какой-нибудь теоремы Гольдзильбера - Баумвассера об инвариантной сходимости знакопеременных рядов в замкнутом кольце Нибелунга.
Вот как здесь при решении фактически арифметической задачи про генератор случайных чисел первым делом углубились в теорию вероятностей и вспомнили центральную предельную теорему.
Программисту бы ещё и физики немного... Муха, способная пролететь 300 километров со скоростью 100 км/ч это немного перебор.
Кстати, если обратить внимание, то в формулировке задачи не сказано, какое распределение у исходной RAND5. И из этого надо сделать именно равномерное. Если это не косяк формулировки, а именно целенаправленный нюанс, то будет ещё интереснее.
А если распределение не важно - то достаточно return rand5() )))
return rand5()
Скрытый текст
xkcd дает более простой ответ )))
Центральная предельная теорема здесь неприменима. Она рассказывает про сумму и про среднюю величину. А у нас в результате не сумма и не средняя величина, а остаток, который циклически крутится от 0 до 6.
Любителям математики предлагаю отвлечься от учебников и написать программу, которая генерирует вышеуказанные случайные числа. Я вот написал, на Бейсике (задача же для второклассников была?). Из 1 000 000 попыток у меня получилось 143153 единицы, 142543 двойки, 143090 троек, 143019 четверок, 143062 пятерки, 142486 шестерок и 142647 семерок. Как видите, никакого Гаусса здесь нет, как было исходное распределение равномерным, так оно и осталось.
Скрытый текст
Dim sums(7)
For a = 1 To 1000000
i = Int(Rnd * 5) + Int(Rnd * 5) + Int(Rnd * 5) + Int(Rnd * 5) + Int(Rnd * 5) + Int(Rnd * 5) + Int(Rnd * 5)
i = (i Mod 7) + 1
If i = 1 Then sums(1) = sums(1) + 1
If i = 2 Then sums(2) = sums(2) + 1
If i = 3 Then sums(3) = sums(3) + 1
If i = 4 Then sums(4) = sums(4) + 1
If i = 5 Then sums(5) = sums(5) + 1
If i = 6 Then sums(6) = sums(6) + 1
If i = 7 Then sums(7) = sums(7) + 1
Next a
For a = 1 To 7
Print sums(a)
Next a
Из 1 000 000 попыток у меня получилось 143153 единицы, 142543 двойки, 143090 троек, 143019 четверок, 143062 пятерки, 142486 шестерок и 142647 семерок
И если увеличим количество итераций, то будет отчетливо видно, что распределение не равномерное, а имеет края выше середины:
0: 143050067 (14.31%)
1: 143008336 (14.30%)
2: 142826145 (14.28%)
3: 142650806 (14.27%)
4: 142652002 (14.27%)
5: 142815262 (14.28%)
6: 142997382 (14.30%)Небольшая модификация — 8 слагаемых вместо 7 — уже дает что-то похожее на правду:
func rand5() int {
return int(rand.Float64() * 5)
}
func main() {
var sums [7]int
iter := 1_000_000_000
for a := 0; a < iter; a++ {
i := rand5() + rand5() + rand5() + rand5() + rand5() + rand5() + rand5() + rand5()
sums[i % 7]++
}
for a := 0; a < 7; a++ {
fmt.Printf("%d: %d (%.03f%%)\n", a, sums[a], float64(sums[a])*100.0/float64(iter))
}
}
0: 142812749 (14.28%)
1: 142906698 (14.29%)
2: 142943984 (14.29%)
3: 142907381 (14.29%)
4: 142856271 (14.29%)
5: 142788806 (14.28%)
6: 142784111 (14.28%)Но после множества проходов становится видно, что середина таки стабильно немного выпирает.
Увеличение количества слагаемых до 16 дает еще более плоский результат:
0: 142824764 (14.282%)
1: 142857973 (14.286%)
2: 142857043 (14.286%)
3: 142875534 (14.288%)
4: 142859056 (14.286%)
5: 142861467 (14.286%)
6: 142864163 (14.286%)Известны случаи ошибок дизайна контрольных сумм, когда давали неравномерное. В протоколе SCTP так пришлось аж несовместимый новый RFC выпускать.
Известны случаи ошибок дизайна контрольных сумм, когда давали неравномерное.
Значит, программист знал достаточно математики для того, чтобы уверенно взяться за написание своей формулы хеширования, но недостаточно для того, чтобы эта формула заработала правильно. "A little knowledge is a dangerous thing".
Если бы не было операции взятия модуля, вы были бы правы. Распределение суммы - действительно гауссиана. А вот распределение модуля от суммы по значительно меньшему числу - вполне себе нормальное.
Тут как раз вопрос, какую мы задачу решаем: математическую или инженерную. При взятии модуля происходит искажение гауссианы (можете проверить сами - взять упомянутую выше сумму по разным модулям, от 35 до 5), и в итоге результат начинает всё больше становиться похожим на нормальное распределение. Но на действительно больших выборках будет видно, что это распределение всё-таки "чуть-чуть не равномерное". Другое дело - что для реальных применений на эту неравномерность с какого-то момента будет наплевать.
Только "нормальное распределение" и есть гауссиана.
А что если вместо повторения делить на 5 и умножить на 7 и округлить в большую сторону?
У тебя есть функция rand5() - даёт случайное число от 1 до 5. Напиши rand7() - равномерно от 1 до 7. Использовать можно только rand5().
Что то типа дернуть 7 раз rand5, сосчитать сумму по модулю 7?
от 1 до 5 - целые или с плавающей точкой?
rand7() = rand5() / 5 * 7
tailrec def rand7() =
val n = (rand5() - 1) * (rand5() - 1)
if (n > 13) return rand7()
return n % 7 + 1
Неа, неравномерненько)
def rand5() = Random.nextInt(5) + 1
@tailrec def rand7(): Int = {
val n = (rand5() - 1) * (rand5() - 1)
if (n > 13) rand7() else n % 7 + 1
}
val iters = 100000
Range(0, iters)
.map(_ => rand7())
.groupBy(identity)
.map { case (n, l) => n -> l.size }
.toList
.sortBy(_._1).foreach {
case (num, freq) => println(s"$num freq: ${freq * 1.0 / iters}")
}1 freq: 0.37639
2 freq: 0.12641
3 freq: 0.12314
4 freq: 0.08475
5 freq: 0.12431
6 freq: 0.08249
7 freq: 0.08251Я ошибся, надо (rand5() - 1) + 5 * (rand5() - 1).
Чтобы получилась сетка с 25 равномерными значениями.
И ещё условие отсечения можно поменять на n >= 21 для большей эффективности.
Вызывая k раз ф-цию rand5, получаем число от 0 до 5^k-1 (записывая цифры из rand5 как число в 5-ричной системе). Далее берём от этого числа mod 7, и получаем ответ. Ясно, что не идеально точный, потому что остаётся маленький "хвостик" между 5^k и 7*n. Но чем больше k, тем меньше эта разница. Например для k=10 вероятность попасть в эту погрешность будет не выше 7/(5^10), т.е. пренебрежимо малой.
Взять 7 ячеек, посчитать 7 раз ранд 5, выбрать номер ячейки где максимальное число. Если его не было - повторить. А вообще у вас с формулировками всё очень нематематично
Взять 7 ячеек, посчитать 7 раз ранд 5, выбрать номер ячейки где максимальное число. Если его не было - повторить.
Получилась процедура с непредсказуемым временем выполнения - вплоть до необъяснимых зависаний раз в год, если звезды удачно сойдутся. А потом удивляются, почему люди программистов не любят...
Избыточное условие.
нет монет по 1 рублю? И 2 рублевых тоже нет.
Это для тех, кто не понял, что значит
только монеты 5 и 10 рублей ?
def rand1():
while 1:
r = rand5()
if r < 5: return r % 2 #генерим равновероятностные 0 или 1
def rand7():
while 1:
r = 2*rand5() - rand1() #генерим равновероятностные 2, 4, 6, 8, 10, вычитая rand1() получаем равновероятностные [1,9]
if r <= 7: return r #получаем равновероятностные [1,7]
Про ранд простейшее же решение - используй if и повторно используй ранд.
Скрытый текст
#include <iostream>
#include <random>
#include <algorithm>
#include <cstdint>
int r5(int a,int b){
std::random_device rd;
std::mt19937 gen(rd());
std::uniform_int_distribution<> distrib(a, b);
return distrib(gen);
}
void updateb(int &t,int n){
int a=r5(1,5);
int b=r5(1,5);
t= (std::clamp(t,a+b,7) >> n ) & 0xFF;
}
int r7(){
int t=0;
updateb(t,7);
updateb(t,6);
updateb(t,5);
updateb(t,4);
updateb(t,3);
updateb(t,2);
updateb(t,1);
updateb(t,0);
return t;
}
int main(){
int a=r5(1,5);
a = r7();
std::cout<<a<<std::endl;
return 0;
}я так сделал ), только у меня не равномерно наверно
(5*(rand(5)-1)+rand(5)-1)%7-1
Посмотрел на ответы и ощущение что мне лучше доверять себе делать криптографию...
А не, нельзя доверять себе
(5*(rand(5)-1)+rand(5)-1)%7+1
исправленное
У этого решения проблема: выражение в скобках перед %7 даёт равномерно распределённое случайное число X от 0 до 24, и таким образом операция %7 даст по 3 числа 0-6 для значений X=0..20 и числа 0,1,2,3 для X=21,22,23,24. То есть, числа 1,2,3,4 будут выпадать заметно чаще, чем 5,6,7. Выше я приводил обобщение вашего решения, чтобы уменьшить эту проблему.
Прикольно.
Действительно невозможно сделать roll7 из roll5, за фиксированное количество шагов и равномерным распределением.
roll5 дает 5 исходов. Два roll5 дадут 25 исходов и тд
Сколько бы бросков я не делал, исходы не получится точно поделить на 7.
Первая и вторая совсем никакие, третья ничего, для неаккуратного решения пойдет 5 rand5 - 5 + rand5 mod 7 <= 21, для аккуратного можно в вариантах 22-25 запоминать хвост, который суть rand4, из двух rand4 делаем следующую генерацию с хвостом rand2, из трех rand2 делаем генерацию с хвостом 1/8, который отбрасываем. Итого статистически за 10000 генераций rand5, выдадим 4200 + 350 + 14-15 rand7, и отбросим 2 генерации из rand2
Можно запоминать хвост выше 7 динамически, то есть берём те же 2 rand5, получаем хвост rand4, к нему снова добавляем rand5, получаем хвост rand6, к нему снова добавляем rand5, получаем хвост rand2, потом получаем rand3, и потом 1/15 придется отбросить. Тут нужен код уже чтобы посчитать сколько получится выбросов и rand7 на 10к rand5 вызовов
Вот ещё
Две свечи разной длины сгорают за час. Как отмерить 45 минут? Каждая свеча горит равномерно.
Для тех, кто свечей в глаза не видел: их можно зажигать с обоих концов
Для тех, кто свечей в глаза не видел: их можно зажигать с обоих концов
Чайная свечка.жпг. Да ладно ? ;)
Обычные, кстати, тоже нельзя. Скорость горения будет совершенно другая.
поэтому и не люблю такие задачи из-за скрытых зависимостей от контекста
один преподаватель спрашивал задачу
продолжите ряд чисел 7, 11, 15, 20...
правильный ответ 48, потому что это цены на мороженное в том году - типа все знают цены и должны догадаться (цены и ассортимент в СССР были фиксированы)
ну дебил же
Да, свечи разной или равной длины? ;)
Я дороже 25копеек не видел мороженого. Как не видел и за 7. Минимальная цена была 10копеек за молочное, потом шло сливочное за 14 кажется, а потом 20 за пломбир. 25 стоил пломбир в виде гитары с двумя вкусами
ну дебил же
Наоборот, умный тролль. Он показал ученикам, что задачи типа "продолжить ряд" математически некорректны.
Две свечи разной длины сгорают за час. Как отмерить 45 минут?
С линейкой и циркулем?
Представим, что одна свеча имеет длину 1 час, а вторая 0 часов.
Как имея свечу длиною в 1 час отмерить 45 минут?
Никак.
А если докапываться до формулировки, то с помощью часов. Нет условия что пользоваться можно только свечами.
ну блин...
обе сгорают за час, но имеют разную длину
Поджечь первую с двух концов, вторую с одного.
Первая сгорит за 30 мин (горит вдвое быстрее). В этот момент поджечь второй конец у второй свечи.
Вторая уже 30 мин горела с одного конца - осталось на 30 мин. Теперь горит с двух концов - догорит за 15 мин.
Итого: 30 + 15 = 45 минут.
Ясно, я понял условие как первая + вторая сгорает за час, а не каждая сгорает за час. Решение не читал
обе сгорают за час
Очевидно же, что Т1 + Т2 = 1 час. Ну, как с ценами на мороженное ;) Если бы хотели сказать что каждая горит 1 час - так и сказали бы. А еще возможен вариант, когда обе сгорают за 1 час, но 1 немного раньше.
А для чего уточнение про равномерность горения? С ним возникает вопрос, что мешает отмерить по длине свечи. Чтобы задача работала в задуманном виде, нужно чтобы горение было неравномерным.
Поставляйте медленнее
Звучит хорошо. Но не работает в рыночной экономике.
Пипл хавает©
Если к этому рынку добавить регулятора (государство), то сразу начинает работать.
Собственно, причина низкого качества ПО - тотальная безответственность разработчиков. Они от багов, лагов и падений не теряют примерно ничего - за всё платит конечный пользователь (в первую очередь более мощным и дорогим железом). А вот как начнут терять свои, а не пользовательские, деньги - вот тут-то по законам рынка говноделы поразоряются.
Да, это я о тех самых гостах-снипах-регламентах, которые государства заставляют соблюдать всех производителей, кроме айтишников, и которые так ненавидят все айтишники (неудивительно, с их-то привычками к "не отвечаю ни за что, все проблемы скидываю на самого потребителя" это худший из их кошмаров).
"Примите, что качество важнее скорости." - это не так, к сожалению. Пока вы выпустите тщательно проверенный, качественный продукт, весь рынок уже будет захвачен конкурентами, продукты которых будут с багами, но будут работать и решать проблему здесь и сейчас и приносить конкурентам прибыль. Не говоря уже о том, что ваш продукт к моменту выпуска, из-за долгой разработки, может уже морально устареть .
Нет, ваш довод работает в очень редких случаях. Например, это стартапы.
Но:
1) калькулятор от компании Эппл в МакОси
2) пуск в 11-ой винде
3) обновление CrowdStrike
4) Microsoft VS Code
5) и далее бесконечный список
все это делалось компаниями, которые никуда не спешили. Если Microsoft отложит обновление Windows, никакой Linux / MacOS завтра не захватит их рыночную долю.
Если Apple не включит в поставку новую, непротестированную версию калькулятора, никто не умрет. Они могут поставлять калькулятор хоть из 86-го года (только собрав под нужную архитектуру). Они могут вообще не поставлять калькулятор со своей ОС, как они делали более десятилетия с отсутствующим калькулятором на айпадах, и что ни разу не мешало стать айпадом самым продаваемым планшетом долгое время (и, кажется, самым маржинальным и по сей день).
Оправдывать отсутствующее качество могут студенты, которые отчислились из универа, и на волне хайпа пытаются запрыгнуть в товарняк с деньгами. Компании, которые работают на венчурных инвестициях, и еще не зарабатывают сами. Никак не корпорации, которые не тестируют обновления существующих продуктов. Бета-версии новых фич - окей, да, могут быть непротестированы достаточно хорошо.
Хочется двадцать два раза плюсануть.
Этот идиотизм, о том что какие-то конкуренты что-то там захватят, если ты не будешь быстрее быстрее выпускать говно в мир, повторяется не одно десятилетие. К реальности он не имеет никакого отношения.
Да даже если ты выпустил говно, остановись, и удели 3-4 месяца чисто на оптимизации, "Пуск" в 11 винде это канонический пример. Но куда им... Конкуренты из линукса щас всё захватят, да.
Не обязательно в редких.
Есть, например, аутсорс-контора, которая делает приложение для ритейлера. У этого ритейлера бюджет распланирован до копейки и дня: тогда запускаем контекстную рекламу, тогда офлайн-рекламу, потом блоггеров закупаем и т.д. Закупаем под нагрузки оборудование, настраиваем, обучаем персонал работе с приложением. Смотрим с тревогой на конкурентов, которые тоже должны в этом году выпустить своё приложение. Запускаем в магазинах акции, чтобы привлечь аудиторию низкими ценами. Ну и множество других-прочих активностей/ограничений.
И вот если ты во все сроки не уложишься, заказчик потеряет и/или недополучит несколько сотен миллионов. Поэтому здесь всё равно, что твоё CRUD-Android-приложение после установки будет весить 800 Мб, жрать половину оперативы и иметь критические уязвимости для пользователя. Нужно, чтобы заказы с мобилки лились и генерировали кеш-флоу, а с какими костылями, багами и несовершенствами -- неважно.
Потому что ставят повозку впереди лошадей. Запустили приложение -- после запускаем маркетинговую компанию.
Разницы, когда запустить маркетинговую компанию особо нет, но если мы контрактуем запуск до выхода приложения с конкретной датой начала кампани, мы получаем жесткий дедлайн.
Знаете, я перестал ходить в Ленту, не потому что они позже запустили приложение со скидочной картой, а потому, что в "моем" магазине из 10 касс никогда не работало больше 3. Ни днём, ни вечером в час пик.
Я перестал ходить в одну Пятерочку у дома не потому, что у них позже конкурентов появилось приложение, а потому что там продавали просрочку и бегали тараканы. Стал ходить в другую Пятерочку с более адекватным управляющим, благо их было аж 3 в моем районе.
Надо понимать, что откладывание релиза может нести какие-то упущенные выгоды (особенно, когда есть жесткий контракт и санкции), но эта ситуация, в которую участники сами и добровольно вошли -- а потребителям, в целом, все равно (в рамках разумного) когда выйдет приложение.
Потому что ставят повозку впереди лошадей. Запустили приложение -- после запускаем маркетинговую компанию.Разницы, когда запустить маркетинговую компанию особо нет,
Был у меня знакомый, который работал в Qualcomm. Он мне рассказывал, как проходит выпуск нового процессора. Дата выпуска объявляется за месяцы\годы вперёд и обычно приурочена к какой-то выставке. Процессор "в железе" всегда появляется на несколько недель позже чем было обещано. И он никогда не совпадает с программным эмулятором. С этого момента, обычно за 2-3 месяца до релиза, программисты- писатели драйверов\микрокода переходят на режим работы 24\7. Кроме шуток. Коврики и спальные мешки на рабочих местах, в туалетах есть душевые кабины. Еда и кофе за счёт фирмы. Отсутствие на работе по любой причине кроме смерти - саботаж и чёрная метка, первый кандидат на увольнение.
И всё равно не успевают. А раз не успевают они - не успевают те, кто использует их драйвера. Настоятельно рекомендовал никогда не покупать флагманские смартфоны на их процессорах в день релиза, а подождать два - три месяца. Поскольку вся начинка пишется по принципу "лишь бы явно не висло и сообщения об ошибках не выдавало".
Его это задолбало и он ушел в AMD. В Customer Support. Сказал, что там намного спокойнее.
Потому что ставят повозку впереди лошадей. Запустили приложение -- после запускаем маркетинговую компанию. Разницы, когда запустить маркетинговую компанию особо нет
Ну... Это смелое заявление) Боюсь, что маркетологи с вами не согласятся.
эта ситуация, в которую участники сами и добровольно вошли -- а потребителям все равно когда выйдет приложение
Потребителям всё равно когда выйдет ТВОЁ приложение, и именно по этому они будут пользоваться тем, что выйдет РАНЬШЕ.
Энивей, маркетинговая компания -- лишь одна из причин укладываться в срок, в комментарии указал и другие. А ещё @Dr_Faksov добавил пример с процессором.
Так что если возвращаться к изначальному тезису, всё же чаще всего именно скорость разработки важнее качества. Для нас, инженеров, это больно и неприятно, для бизнеса -- это нормально и приемлемо.
Потребителям всё равно когда выйдет ТВОЁ приложение, и именно по этому они будут пользоваться тем, что выйдет РАНЬШЕ.
Работает только в узко ограниченных случаях - фактически, это ТЕБЕ надо приводить примеры, когда работать будет. Потому что в типичном случае, например, пользователь не перейдёт с условного Telegram на условный Max, если обнова того выйдет раньше. И даже с Microsoft Word на конкурирующий пакет скорее всего не перейдёт.
А вот обратные случаи, когда конкурент выпускал позже, и у него лучше работало и было больше фич, чем у текущего, в истории вполне случались.
надо приводить примеры
Все социальные сети. Не успел вовремя создать ФБ/ВК -- дальше можно даже не пытаться. Убер/Я.Такси -- пытался зайти китайский конкурент, но не вышло. Шиндоус/Айос/Линукс -- сейчас никто даже не задумывается о создании собственной ОС. Хромиум/Геко -- никто не пытается сделать свой движок. Ну это первое, что в голову пришло. Но в целом эффект колеи и человеческая инертность творит чудеса, именно поэтому в новое ПО вливается огромное кол-во маркетинговых денег, чтобы принести хоть какую-то аудиторию.
Это примеры специально чтоб на поржать? Они ж все как раз подтверждают мою точку зрения, а не "будут пользоваться тем, что выйдет РАНЬШЕ" - потому что буквально все они первыми как раз не были. Социальные сети были до ФБ/ВК, мессенджеры тем более ("можно даже не пытаться" сказал бы WhatsApp телеге), уже несколько поколений сменили. С операционками точно так же. С браузерами совсем смешно - Хром залезал на давно поделенную поляну, где была Opera, но плотнее всех обосновался клятый IE6.
Да и телега тоже лезла на поляну где всё уже было поделено и даже щёлочки не было видно, при том, что телега не несла ничего принципиально нового, она влезла и влезла успешно (супер успешно за счёт качества передачи контента).
Скорее всего влезла именно потому, что акынов которые перепевали старые песни о главном "скорее скорее, а то конкуренты всёвсёвсё выпустят, быстрее быстрее строим парусную лодку, а парус и дно приделаем потом" отогнали от процессов разработки вовремя
А уж сколько появилось программ видеоконференций после zoom и Skype.
Более того, http появился после Gopher (о чем была недавно статья). И Гоферу тот факт, что он появился раньше, ни на йоту не помог. А ведь это даже не программа, это протокол - то есть, он врастает в культуру намного сильнее, чем программа-браузер.
Эээх. Жаль никто не напишет, что до HTTP и даже до IP была довольно продуманная экосистема для межплатформенной коммуникации с названием Kermit, сразу с кодировками, командами (без всяких REST надстроек), скриптами (!!!) разделением бинарного и текстового содержимого, серверным режимом и удалённым управлением файлами :)
Всё было заново изобретено (конечно многое улучшено), но никто не хлестал изобретателей по глазам с криками скооореейй.
Зато "бизнес-торопыги" убили довольно милый и популярный Skype всякими "фичами" которые ну ооочень были нужны в соот. с "упоительными пользовательскими историями" и так торопились вывести на рынок, что глючность и тяжесть новых фич утянули скайп на дно....
А вот обратные случаи, когда конкурент выпускал позже, и у него лучше работало и было больше фич, чем у текущего, в истории вполне случались.
Еще был случай, когда программиста ну очень попросили за шесть недель написать новую игру, чтобы успеть к предрождественским продажам. Получился настолько эпичный фейл, что вся индустрия видеоигр упала на несколько лет, пока Нинтендо ее не оживила своей NES.
Боже мой, человек без FOMO!
Ожидайте, не меняйте дислокацию! За вами уже вылетели чёрные вертолеты ©
Поздравляю за отличное описание, почему рыночная экономика фундаментально делает говно (то есть должна быть заменена чем-то лучше).
Конкуренты не захватят, конечно, но это ж вкладывать надо время (деньги) в разработку, а главная задача секономить, удешевить и распилить. Если вам кажется, что это ж потом надо тратиться на поддержку и патчи, значит какая тут экономия? А простая:
Разработкой и поддержкой вполне могут заниматься разные люди или отделы с разным бюджетом.
Все максимально переводят на подписки, соответственно вариант предложить качественный законченный продукт вообще не рассматривается. И в этом огромный плюс, ведь можно дарить пользователя в выдоенное годами экономить и пилить. А продукт законченным быть и не должен, ибо не продукт а сервис же
продукт законченным быть и не должен, ибо не продукт а сервис же
Так так, я записываю.
То есть сервис не должен быть хорошим?
Как раз плата за время использования вместо платы за покупку увеличивает мотивацию производить качественный продукт.
Но FOMO, копрономика и т.п. всё-равно гонят модель ship fast, fix later
Вот немецкий автопром успел попробовать за 40 лет
легковой дизель,
турбо+ даунсайзинг,
электромобиль
Каждый раз поиграл и выбросил. Чаще всего это защита рынка от дешёвых китайских/корейских/японских производителей.
А если в обратную сторону защитить то получится ВАЗ 1.3-1.4-1.6-1.8 (начало серии с 2108, 21083 от 1984 года совместно с Порше) и всё это 40 летняя эволюция одного и того же движка. ИЧСХ не кардинально отличается от немецкого результата (я только про движок в этой ценовой категории, с остальным значительно хуже).
Защита рынка работает в обе стороны - и стагнация ВАЗа, и "инновации" VAG это про барьеры входа, а не про технологии
Вот именно поэтому рынок в конечном счете и рухнет. Жаль только, много чего под обломками погребёт...
Пока вы выпустите тщательно проверенный, качественный продукт, весь рынок уже будет захвачен конкурентами
Это если продукт новый и рынок не поделен. Бывает и наоборот, когда ломают то что уже работало и было популярно.
Был шикарный Windows 7, который прекрасно решал задачи пользователя, был стабилен и доминировал на рынке. В итоге его убирают и начинают всем в глотку пихать новые версии, которые ломали привычные интерфейсы, пользовательские привычки, еще и порой не слабо глючили.
В итоге помучившись с 8 версией, потом с 10, я послал этих новаторов подальше и уже много лет сижу на Linux Mint.
А может просто не умеют в качество?
Когда нет компетенций, мантра "скорость важнее качества" несомненно помогает оправдать любые косяки.
Но вот странно получается что софт (CRM, калькуляторы, интернет-магазины и прочее) уже писали много раз десятки лет до этого. И вот уже год 2025-ый и снова спешка, снова надо торопиться чтобы захватить рынок, снова вся накопленная годами экспертиза улетучивается и любой проект начинается как будто с нуля. И снова его нельзя сразу начать писать качественно из-за этих проклятых конкурентов.
Это в ширпотребе и в бесплатной сфере. А в бизнесе продукт с багами может таких убытков принести (и приносит), что бизнес с радостью платит за годный продукт в четыре раза дороже после нескольких лет траханися со скорострелом, да еще и приплатит за миграцию.
Самый неудобный вопрос: сколько проживёт программист, вылизывающий свой калькулятор без абстракций? И противопоставленный: сколько проживёт программист, который фичерит приложение, исправляет баги, не особо гонится за скоростью, использует доступные ресурсы (для себя ИИ, для программы железо)? И у какого из них больше шансов выжить, имея собственных бизнес, основанный на простом приложении калькулятора?
Всяко дольше, чем недопрограммист, видящий только две крайности. Калькулятор вылизывать до последнего байта ни к чему, но устранять детские косяки - must have. Кстати, опытный программист скорее всего их и не допустит, ситуации, угрожающие утечкой памяти (состоянием гонки итп) достаточно типичны.
гугление показывает что калькулятор эпл имел просто адово количество проблем
особенно первые версии iOS.
Самые дикие баги:
Поворот экрана сбрасывал вычисления
Анимации "съедали" нажатия - быстрый ввод 1+2+3 = давал 24
Копирование чисел ломало точность
Причина - приоритет анимаций над логикой. Пока кнопка красиво отжималась, следующее нажатие терялось.
Apple исправляли это годами. Для "просто калькулятора" - позорище.
Каковы перспективы программиста, который написал Калькулятор для Win11?
И где-то в стороне надо всем этим ржут эмбеддеры, которые еще не разучились считать байты и микросекунды)
Чё-то надоело уже это нытьё. Ничего особо страшного не случилось в последние 10 лет. Индустрия работает так же с середины 90-х, когда распространилась разработка на ПК. И ничего, как видите, живы все. Зарплаты большие, капитализации большие, пузырь, в целом, большой. В 26-м, может, лопнет. Потом короткая депрессия и надуется новый. Капитализьм-с.
Кроме того, в статье полно откровенных передёргиваний и ошибок:
Я отслеживаю показатели качества программного обеспечения уже три года.
уже три года!!! Оглядите предыдущие 30 лет, тогда будет о чём говорить. За 3 года ни трендов, ни циклов не увидеть.
В чём причина? Ожидалось 21 поле, но было 20.
Одно. Отсутствующее. Поле.
Погуглите, что случилось с первым запуском РН Ариан 5. А там были не смузишные хипстеры из Долины, а настоящие суровые европейские программисты на Аде. В растянутых маминых свитерах и толстых пыльных очках. И ни одного реакта.
Вот так калькулятор в итоге теряет 32 ГБ. Не потому, что кто-то этого хотел, а потому, что никто не замечал кумулятивных расходов
Утечки памяти тоже не в 2020-м году появились. Утечка, на то и утечка, что сжирает всё. Возможно, никто не замечал, потому что никто не держал калькулятор открытым достаточно долго.
Мы притворялись, что электричество бесконечно. Это не так.
Это очень так если вместо зелёной повестки, третьих энергопакетов и веры в то, что рыночек порешает, будет адекватное планирование и инвестиции
Вместо того, чтобы решать фундаментальные проблемы качества, технологические гиганты выбрали самый дорогостоящий из возможных вариантов: вложить деньги в инфраструктуру.
Я так понимаю, что вы авторитетно заявляете потому что знаете других гигантов, выбравших другой путь и достигших лучших результатов?
Примите, что качество важнее скорости. Поставляйте медленнее, поставляйте то, что работает
Это для нас — инженеров, важнее. Для бизнеса время разработки важнее. Капитализм-с.
Спасибо за адекватное мнение +1. Нытьё из серии: раньше, вон Колоссус, на перфокартах и лампах взламывал Энигму, а теперь погляди - утечка у калькулятора)))
Все эти программные калькуляторы всё равно настолько ужасны по юзабилити, что в итоге взял и положил калькулятор себе на стол. Обычный, с ламповым дисплеем и двумя батарейками, из 1982 года.
А сегодня захожу в кабинет, а калькулятор не включается, и под ним в районе батарейного отсека лужа сомнительного цвета и запаха. Да чтоб тебя, даже в таком калькуляторе утечка!
Да и измерять качество софта по трем продуктам тоже нифига не репрезентативно. Хотя я в своё время и в ядро Линукса репортил баги, и с инженером Кассандры корпел над крешдампом, и дотнет умудрялся уронить.
В 2018 просто уже даж достаточно плохо видящие заметили. К моменту появления ИИ на рынке IT-индустрия шагала к краху уже лет так 14. Первыми ласточками были облака и гонка циферок версий браузеров.
Я так понимаю, что вы авторитетно заявляете потому что знаете других гигантов, выбравших другой путь и достигших лучших результатов?
Кто-то мешает им всем совершать одну и ту же ошибку?
В 2018 просто уже даж достаточно плохо видящие заметили. К моменту появления ИИ на рынке IT-индустрия шагала к краху уже лет так 14
К какому такому краху? Крах будет, когда софт засунут везде куда можно и к интернету подключат каждые трусы и каждую розетку. Тогда расти будет некуда, инвестиции уйдут в другие отрасли и зарплаты упадут до уровня других инженеров, а спрос на программистов прекратит свой экспоненциальный рост. Пока что наблюдается прямо обратное.
Первыми ласточками были облака и гонка циферок версий браузеров.
Может ещё гонка циферок мегагерцов процессоров из первой половины нулевых? Вообще, гонка циферок очень характерна и, я бы даже сказал, имманентна, для товарного производства.
Кто-то мешает им всем совершать одну и ту же ошибку?
Никто. Но на каком основании автор считает это ошибкой? Без основания, это мнение "космического масштаба и космической же глупости"
И где же оно наблюдается? Массовые увольнения, спрос упал, причем не только в РФ, но и у западных гигантов.
Может ещё гонка циферок мегагерцов процессоров из первой половины нулевых?
Это было запахом, но еще не не каким-то необратимым трендом.
Вообще, гонка циферок очень характерна и, я бы даже сказал, имманентна, для товарного производства.
Отнюдь, как раз наоборот - физические ограничения никто не отменял, в товарном производстве их достичь легче.
Но на каком основании автор считает это ошибкой? Без основания, это мнение "космического масштаба и космической же глупости"
Им показывают прогнозы, они всё равно не понимают. Ну, тут только "не мечите бисер перед свиньями".
И где же оно наблюдается? Массовые увольнения, спрос упал, причем не только в РФ, но и у западных гигантов.
Ну если горизонт ограничен полугодом, тогда конечно можно обычную сезонность принять за глобальных мегатренд.
Отнюдь, как раз наоборот - физические ограничения никто не отменял, в товарном производстве их достичь легче.
Вы продавана живого видели когда-нибудь, вообще? Это совсем не те люди, которых волнуют какие-то там физические ограничения. А поскольку, при товарном производстве во главе стоят именно продаваны, то и цифры у нас будут расти столько сколько нужно. Самый яркий из свежих примеров — это размер транзисторов в названии техпроцессов
Им показывают прогнозы, они всё равно не понимают. Ну, тут только "не мечите бисер перед свиньями".
Это вот эта статья, по вашему, прогноз? С таким же успехом, можно применять прогнозы таролога
Ну если горизонт ограничен полугодом, тогда конечно можно обычную сезонность принять за глобальных мегатренд.
Это расценивать как прогноз "через полгода всё снова будет как прежде" ? ОК, "запомните этот твит" (с)
Вы продавана живого видели когда-нибудь, вообще? Это совсем не те люди, которых волнуют какие-то там физические ограничения. А поскольку, при товарном производстве во главе стоят именно продаваны, то и цифры у нас будут расти столько сколько нужно. Самый яркий из свежих примеров — это размер транзисторов в названии техпроцессов
Видел. Про таких вот и говорят "только массовые расстрелы спасут родину". И даже они в тех же техпроцессах уже не рисуют циферки так же быстро как ранее.
Это вот эта статья, по вашему, прогноз? С таким же успехом, можно применять прогнозы таролога
Да уж у астрологов как-то лучше выходит, чем.
Статья прямо в душу, спасибо!
Спасибо автору за интересную и компетентную статью! Что бы вы посоветовали начинающему программисту-самоучке за сорок? На что обратить особое внимание при обучении? Я использую нейросети, но не для слепого копирования кода, а чтобы получать оперативные разъяснения по возникающим в ходе учебы вопросам - на мой взгляд, это гораздо эффективнее, чем искать ответы на форумах.
это вы еще про игры на Unreal Engine 5 не написали )
Спасибо за статью, очень правильные мысли.
Чем больше смотрю на то, как развивается IT тем чаще вспоминаю рассказ Азимова "Чувство силы" кажется к этому всё и идёт
Дурная идея которая пришла в голову, пока думал над статьёй и проблемами с энергетикой. Не удивлюсь если в ближайшее время произойдут серьёзные подвижки в области управляемой термоядерной энергии под лозунгом "каждому ДЦ своё солнышко" Правда это может надолго сделать возможным заливание деньгами и железом проблем с софтом
А началось всё с того, что какой-то диверсант (мягко говоря) когда-то юридически приравнял ПО к литературе и придумал «ограничение ответственности» и вот это вот всё.
Если бы все эти говнокодинговые конторы хотя бы частично возмещали миллионы человекочасов, потраченные на возню с глюками их продуктов жизнедеятельности - «рыночек порешал» бы совсем по-другому.
Я не понимаю, почему если накосячил разработчик шкафа с реле и завод взорвался (или больница не смогла провести экстренную операцию и пациент умер) - его съедят с костями. А если накосячил разработчик такого же шкафа с реле в виде машинного кода - он ни за что не отвечает.
Да, лет десять уже считаю, что во всем виноваты лицензии коммерческого софта с отказом от ответственности. Зарабатываешь деньги - будь добр нести ответственность, это только бесплатному опенсорсу можно.
Так там где это действительно жизненно важно совсем другие требования к качеству, надежности и ответственности, нежелени в менее критических системах. А применять везде стандарты и ответственность как для критических систем - это тот еще идиотизм.
Калькулятор, отжирающий 32 гигабайта оперативки - это на самом деле проблема дизайна операционной системы. Все современные настольные ОС сейчас имеют устаревший дизайн, который позволяет каждой прикладной программе слишком много вольностей - потреблять память и процессорное время, сколько она пожелает, читать и писать все пользовательские файлы (только системные файлы нельзя менять), выходить в интернет, да даже запускаться в полноэкранном режиме и перехватывать управление курсором. По-хорошему ОС должна максимально ограничивать пользовательские программы, чтобы не было таких вольностей и чтобы для превышения этих ограничений нужно было вмешательство пользователя. Тогда бы вышеупомянутый калькулятор достаточно быстро бы падал, отожрав больше положенных ему 16 мегабайтов памяти (или сколько ему там реально надо?), что позволило бы отловить эту проблему ещё на стадии разработки.
По-хорошему ОС должна максимально ограничивать пользовательские программы, чтобы не было таких вольностей и чтобы для превышения этих ограничений нужно было вмешательство пользователя.
Вот-вот. А то пользователь тыкнет по ссылке в письме, и скриптик сам загрузится-запустится, пойдет файлы шифровать по всему диску, и все это незаметно для юзера, а системе хоть бы хны.
16 мегабайтов памяти (или сколько ему там реально надо?)
ну максимум 640 Кб
Если учесть, что компилятор - это графическое приложение и плотность пикселей на компьютерах Apple весьма немаленькая, то ему нужен достаточно весомый буфер кадра, или даже два или три (для двойной/тройной буферизации). В 640 Кб он с такими требованиями не влезет.
А зачем ему держать этот буфер самому, если это может делать графическая подсистема? А он знай только виджетами управляй.
Математика проста: сегодня нет младших разработчиков = завтра нет старших = некому чинить то, что ломает ИИ.
Ну и славненько, до пенсии возможно дотяну
Шо, опять? https://habr.com/ru/articles/596517/
Смотрю никто не сказал за JetBrains - а ведь понижение качества IDE так же влияет на разработку. Все взаимосвязано, IDE всегда был помощником разработчика.
Если бы сам редактор кода говорил о забытых освобождениях памяти... Ведь это не сложно потому как IDE и так держит в памяти все дерево зависимостей.
Но увы сейчас эпоха эффектности, а не эффективности. Потому в формошлепство и новые дизайны каждые пару лет вливают в разы больше денег, чем непосредственно в функционал.
Относительно JetBrains - некоторым чисто функциональным багам судя по трекеру уже больше 5 лет, они переползают от версии к версии но разрабам не до них. Зато новых багов добавляют с избытком
Судя по полярности комментариев, тут нужно было бы добавить 2 опроса:
за что вы: качество ПО и оптимизация или скорость и простота кодинга.
какой у вас телефон: айфон или андройд.
И посмотреть взаимосвязь результатов. Ну и плюс еще больше полярных комментов получить в адрес сабжа ).
Перестаньте прятаться за абстракциями. Каждый слой между вашим кодом и оборудованием может привести к потенциальной потере производительности на 20–30%. Выбирайте тщательно
Пишите на Ассемблере, а лучше сразу в двоичном коде.
Шутка, но тем не менее: кто и как устанавливает границы избыточности абстракции? Есть ли какая-то формула, которую можно применить к множеству технологий и сказать "вот тут норм, а дальше лишнее потребление ресурсов"?
Наверное, всё упирается в экономику: если у меня огромный рынок Ассемблер-разработчиков, которые готовы работать за миску риса, я найму их, и пусть делают самое оптимизированное приложение в мире. Если мне дешевле купить лишние десять высокопроизводительных серверов, то пусть джуны говнокодят утечки по 32Гб, экономика всё равно будет сходиться.
Всё сломалось гораздо раньше, когда разрешили делать халтуру и не нести за это никакой ответственности. Когда принцип "as is" приобрёл юридическую силу. Но и потребители постарались: если я имею выгоду от использования ПО на 100 рублей и несу убытков на 10, то всё равно я в плюсе, при этом прощаю разработчикам их косяки.
Закономерности-то простые:
- VS Code - написано на TypeScript, JavaScript, HTML, CSS
- Microsoft Teams - написано на TypeScript, Angular, React
- Discord - написано на TypeScript (with ReactDiscord)
Прекратите писать приложения на скриптовом JS Ховне со скриптовыми библиотеками,
вернитесь к Си / C++ / Objective-c / ObjectPascal. Либо развивайте такие языки как D и т.п.
И будут тогда ваши приложения летать и при этом потреблять килобайты вместо гигабайт.
НО только для этого нужно будет послать в #опу все мега-Хениальные "идеи" от эФФФективных мЭЭЭнеджеров, а "мамкиных кодеров" не брать на работы, а отправлять после школы учиться в университеты.
А вот как это сделать при главенствующем тупом подходе, который формулируется как "всё должно было сделано ещё вчера, а-то у меня диаграммы Ганта будут некрасивые" (tm) - кто бы знал? )))
Disclaimer: я бэкендер.
Так вот, во всём вышеперечисленном проблема вовсе не в языке, TypeScipt великолепен. Проблема в том, что эти десктопные приложения тащат за собой Chromium. Но вот в чём дело, тот же VS Code практически моментально стартует и совершенно не мешает жить. И, кажется, стал уже дефакто редактором для фронтедеров. Дискордом не пользуюсь, но масштабных жалоб не слышал. Тимз это боль, да, но тем не менее каждый день в течении рабочих часов оно у меня открыто и проблем не причиняет.
Верно, причина не сводится сугубо к одному лишь языку (JavaScript), а размазана по экосистеме. Но не всей экосистеме индустрии, а вполне именуемой - проще говоря, причиной является Web. То есть, если кто-то потрудился вылизать конкретно VS Code, это исключение, а не правило.
VS Code?
Серьезно?
Хотя сейчас большинство запросов решает именно он.
Когда я пользовался им на удаленной VDI-виртуалке (таковы требования безопасности заказчика), я не заметил тормозов, которые превышали бы лаги удаленного рабочего стола. Впрочем, он и не обвешивался особо ничем, просто допускаю, что коммент выше про "нормально" вполне соответствует правде. Так-то я vim предпочитаю, конечно.
TypeScipt просто чуть меньше воняет, чем сам JS, да то лишь на этапе написания.
Но по сути это тоже самое JS скрипто-ложество поверх Хромиума, как вы и написали, вместо нормального оптимизированного найтивного кода.
Кому вообще нужен т.н. фронтенд, если можно было бы за то же время создать несколько клиентских десктопов, работающих и выглядящих одинаково на всех операционках?
Flutter+Dart - вот действительно многообещающий проект, который способен дать пинка всем фронтендным скрипто-кодерам.
Qt+QML - тоже не плохо, но требуют знакомства с C++, что для "мамкиных кодеров" будет сложновато.
Ну а по цифрам:
VS Code только стартует без проекта и тут же выжирает на моём ПК ~900 Мбайт
На этом фоне Lazarus стартует с открытым большим проектом и потребляет всего 55 Мбайт (сама среда написана на том же FPC).
Как говорится, комментарии излишни )))
А что там такого многообещающего, если это всё тот же Google, то есть избавления от Веба нет?
Многообещающего там много, например:
Dart - язык не очень сложный, при этом современный, безопасный (с автоматической сборкой мусора), со строгой статической типизацией, с async/await шаблонами и т.п.
Синтаксис Си-подобный - напоминает Java, C#, даже C++ ( в плане вызова инициализаторов в конструкторах ).
Изначально задумывался как более эффективная замена JS, но по мере развития и вместе с библиотекой Flutter уже перерос в нечто существенно большее.
Есть свои "тараканы" (странности), как, например, своеобразный подход к модификаторам доступа и т.п., но в целом от лидеров жанра мало чем отличается и очень быстро развивается.Для десктопа Flutter+Dart использует Ahead-of-Time (AOT) компиляцию в целевой найтивный код и порождает один найтивный исполняемый файл для целевой платформы (в случае с Win - EXE-шник), без тонн библиотек как, например, Qt. Для мобилок тоже самое - в случае Android стандартный apk.
Для всех платформ используется один и тот же собственный способ отрисовки поверх библиотеки SKIA, которая в свою очередь работает поверх OpenGL / Vulkan.
Платформенные или сторонние библиотеки виджетов (типа Qt, GTK) не используются, поэтому отображение одинаково на всех платформах.Для случая ВЕБ это компилируется в оптимизированный JS, а отрисовка идёт через SKIA на Canvas. Для индексации поисковыми машинами такой ВЕБ не годится, но с другой стороны это и рассчитано на приложения, а не на сайты.
Я чуть поясню: чтоб быть "способен дать пинка всем фронтендным скрипто-кодерам", надо быть не просто "многообещающим", а "прорывным". Поэтому я трактую в этом ключе.
с async/await шаблонами и т.п.
Руки за этот архитектурный костыль отрывать.
Синтаксис Си-подобный - напоминает Java, C#, даже C++ ( в плане вызова инициализаторов в конструкторах ).
То есть ничего прогрессивного.
но в целом от лидеров жанра мало чем отличается и очень быстро развивается.
Ну вот, раз не отличается, то и толку?
Для десктопа Flutter+Dart использует Ahead-of-Time (AOT) компиляцию в целевой найтивный код и порождает один найтивный исполняемый файл для целевой платформы (в случае с Win - EXE-шник), без тонн библиотек как, например, Qt. Для мобилок тоже самое - в случае Android стандартный apk.
Неплохо, но мы всё это видели давно, хоть в том же Delphi.
Для всех платформ используется один и тот же собственный способ отрисовки поверх библиотеки SKIA, которая в свою очередь работает поверх OpenGL / Vulkan.
Платформенные или сторонние библиотеки виджетов (типа Qt, GTK) не используются, поэтому отображение одинаково на всех платформах.
Иными словами, это еще одна "библиотека виджетов", как Qt, GTK, поэтому и сравнивать стоит с соседями в этом ряду.
Для случая ВЕБ это компилируется в оптимизированный JS, а отрисовка идёт через SKIA на Canvas. Для индексации поисковыми машинами такой ВЕБ не годится, но с другой стороны это и рассчитано на приложения, а не на сайты.
А вот это уже минус, причем жирный. Да, в случае .EXE это нормально, но в случае вещей типа Веба это нафиг убивает открытость, интеграция должны была бы быть выше, а не ниже. Не, конечно для Гугла это как раз хорошо, он хочет убить свободный Веб, подмяв его под себя. Но для меня, скажем, это повод сразу отмести его и даже не тратить время на изучение.
P.S. Тут вот пишут "по инфе от знакомого, в дарте, нет векторов как типа, только списки.
производительные коды (клинтские) не напишешь, если это так". Это правда?
Руки за этот архитектурный костыль отрывать.
Это ещё почему?!
Лет ~16 тому назад я даже реализовывал похожую логику работы на древних Delphi. Причём, мы делали свой собственный вариант Task-ов поверх собственного же пула потоков. И даже собственно похожую логику типа async/await там делали, но сложно-извращенным способом.
К слову, на тот момент async/await даже в тот же C# ещё не завезли.
Но когда я уже позже увидел те же идеи уже на уровне языка через async/await то был сильно удивлён и обрадован, что наконец-то это появилось в такой простой форме.
Поэтому, если лично вам не надо - то это возможно лично ваши проблемы с пониманием нового и действительно полезного.
То есть ничего прогрессивного.
Чего вам прогрессивнее? Си-подобный синтакис сейчас стандарт де факто для большинства новых языков. И для большинства программистов он крайне привычен. И как раз хорошо, что не отличается диаметрально, поскольку с тех же майнстримовых Java/С# будет проще перелезть.
Или вам Питоные извраты с обязательными отступами нравятся больше? ;)
Неплохо, но мы всё это видели давно, хоть в том же Delphi.
Тогда вы и должны понимать, что это есть хорошо.
Иными словами, это еще одна "библиотека виджетов", как Qt, GTK, поэтому и сравнивать стоит с соседями в этом ряду.
Это не совсем библиотека виджетов. Это скорее соврменный декларативный подход к интерфейсу, на манер того же QML,
где вы сами вольны очень легко создавать свои собственные виджеты на основе богатой библиотеки графических примитивов.
Это подход не такой простой как классическое формашлёпство a-la Delphi/Lazarus/C#+WinForms, но зато по сути ни в чём вас не ограничивает в плане стиля и дизайна и никак не привязан к контролам самой операционки (как древний VCL)
Ну а третьи фирмы и интузиасты как всегда накидают вам готовых виджетов по самое нехочу.
Да, в случае .EXE это нормально, но в случае вещей типа Веба это нафиг убивает открытость, интеграция должны была бы быть выше, а не ниже.
В случае ВЕБ-а это практически ровно тоже, что предлагает подход через WebAssembly от многих конкурентов.
Если вам нужно приложение, с равнозначной мордой в WEB для какого-то заказчика, который почему-то чистый десктоп "так не любит, что даже кушать не может" (tm), то это как раз очень хороший и оптимальный подход.
А вот если заказчику, нужно не приложение - а ВЕБ-сайт или ВЕБ-магазин и т.п., то это уже другая задача и должна решаться другими инструментами - ручки и блокнот / Adobe Dreamweaver / Готовые движки типа WorldPress и т.п.
Тут вот пишут "по инфе от знакомого, в дарте, нет векторов
В Dart массивы и списки объеденены в понятие generic List.
Они могут быть как расширяемыми так и константными.
За производительность не скажу. Скоро (через пару недель) сам буду прогонять реальные серьёзные тесты на Dart. Скорее всего, sсimark2 для начала. Самому интересно, какие результаты покажет финальный exe-шник.
Я вам больше скажу. Там ещё и типа byte как такового нет. Эффективная работа с отдельными байтами только через библиотеку.
НО лично я пока рассматриваю Flutter+Dart как хорошую возможность закрыть мобильное направление и ВЕБ-морду. Поэтому, мне там супер-скорость чистого незамутнённого С++ вряд ли нужна.
А вот буду ли переносить какой-нибудь следующий десктоп на это - как раз и покажут реальные тесты и прочие оценки.
НО в любом случае мне это уже больше нравится в рамках моего проекта, чем Qt+QML по целому ряду параметров.
Причём, мы делали свой собственный вариант Task-ов поверх собственного же пула потоков. И даже собственно похожую логику типа async/await там делали, но сложно-извращенным способом.
К слову, на тот момент async/await даже в тот же C# ещё не завезли.
Но когда я уже позже увидел те же идеи уже на уровне языка через async/await то был сильно удивлён и обрадован, что наконец-то это появилось в такой простой форме.
Поэтому, если лично вам не надо - то это возможно лично ваши проблемы с пониманием нового и действительно полезного.
Оно "новое и полезное" исключительно для тех, кто слаще морковки ничего не ел. Почитайте длинную статью https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ - в ней хорошо объясняется, почему это костыль, и каков должен быть правильный ответ (корутины/greenthreads).
Чего вам прогрессивнее? Си-подобный синтакис сейчас стандарт де факто для большинства новых языков. И для большинства программистов он крайне привычен. И как раз хорошо, что не отличается диаметрально, поскольку с тех же майнстримовых Java/С# будет проще перелезть.
"Привычен" само по себе не аргумент. Это означает лишь, что в новом дизайне не надо отходить слишком далеко от Си-подобного синтаксиса, но не значит, что не нужно исправлять его ошибки. Вот хороший пример - Go. Да, часть его изменений для меня вырвиглазна, как например порядок [] через жопу, но другие совершенно правильные, как например убирание скобок в if и for.
Или вам Питоные извраты с обязательными отступами нравятся больше? ;)
Не. Я когда вижу новые языки "как питон", сразу закрываю. Тоже, понимаешь, бездумные с силой привычки.
Это не совсем библиотека виджетов. Это скорее соврменный декларативный подход к интерфейсу, на манер того же QML, где вы сами вольны очень легко создавать свои собственные виджеты на основе богатой библиотеки графических примитивов.
Это подход не такой простой как классическое формашлёпство a-la Delphi/Lazarus/C#+WinForms, но зато по сути ни в чём вас не ограничивает в плане стиля и дизайна и никак не привязан к контролам самой операционки (как древний VCL)
Ну а третьи фирмы и интузиасты как всегда накидают вам готовых виджетов по самое нехочу.
QML, конечно, прогресс по сравнению с традиционным способом Qt, но именно "формошлёпство" - причем на базе именно контролов операционки - являяется правильным. Когда появился HTML, это был дикий прогресс в удобстве по сравнению с подходами, существовавшими перед тем (ну кроме Tcl/Tk конечно, но они тут чуть-чуть ровесники). Почему? Потому что очень легко, парой фраз, можно было описать виджет, который иначе требовал бы сложной логики даже для просто отрисовки. Причем отрисовки именно в стиле МОЕЙ СИСТЕМЫ. То самое "выбрать тему" в каком-нибудь KDE, во времена HTML4 этот подход еще сохранялся. И что же? Дальше всё заглохло, новых тегов долго не появлялось. Вот я не знаю, хотя бы сейчас появился какой-нибудь стандартный виджет календаря? Ну, выбора даты? Или опять каждый рисует кто во что горазд? Этот зоопарк достал, если честно, верните мне мой 2003 (когда кастомная отрисовка бывала только по делу, в каком-нибудь винампе или играх).
В случае ВЕБ-а это практически ровно тоже, что предлагает подход через WebAssembly от многих конкурентов.
Одна из причин, по которой я не люблю WebAssembly.
Если вам нужно приложение, с равнозначной мордой в WEB для какого-то заказчика, который почему-то чистый десктоп "так не любит, что даже кушать не может" (tm), то это как раз очень хороший и оптимальный подход.
А нельзя ли их всех просто убить? (с)
А вот если заказчику, нужно не приложение - а ВЕБ-сайт или ВЕБ-магазин и т.п., то это уже другая задача и должна решаться другими инструментами - ручки и блокнот / Adobe Dreamweaver / Готовые движки типа WorldPress и т.п.
А вот плохо, что это другая задача. Простой пример, нужно мне было получить денежный перевод, вот сайт - даже еще не приложение! - "Золотая корона", на нём встраивается виджет Яндекс.Карт. Но встраивается через жопу - я, например, хочу к выбранной точке маршрут построить - и не могу! И только лишь благодаря тому, что это, несмотря на тонны JS, пока еще сайт, я могу средствами браузера выделить текст во всплывашке, скопировать его и вставить в приложение Яндекс.Карты и получить то что мне надо. А вот было бы, как пропагандируете, приложение - всё, пиши пропало (нет, что 0.01% авторов приложений о таком позаботилось бы - не аргумент, остальные-то нет). Интеграция, открытость и текст - это не только поисковики, как видите.
НО в любом случае мне это уже больше нравится в рамках моего проекта, чем Qt+QML по целому ряду параметров.
Ну понятно. На этом фоне, действительно, любое что-то более удобное смотрится как прогресс.
Оно "новое и полезное" исключительно для тех, кто слаще морковки ничего не ел....
Ой-ой-ой, сколько высокомерных слов! )))
А я ведь не поленился внимательно прочесть статью. И вместе с автором ничего не имею против чистых и не замутнённых потоков.
НО беда в том, что почти всегда, когда мы имеем дело с многопоточным приложением, которое имеет пользовательский интерфейс, то мы тут же упираемся в однопоточность этого самого интерфейса.
И тут-то и начинаются проблемы с синхронизацией.
Если вы писали на Delphi/Lazarus то прекрасно помните классические вызовы через Synchronize. На C# это было через Control.Invoke.
И местами логика обновления интерфейса из-за этого становилась весьма запутанной.
И ещё с этим можно мириться, если вам нужен постоянно работающий поток, поскольку при этом можно придумать и другие способы передачи результатов или синхронизации.
А что делать, если вам нужны разовые задачи/действия в параллельном выполнении, по завершении которых что-то должно происходить и синхронизироваться с потоком GUI?
Создавать для каждого такого действия отдельный полноценный поток:
a) неудобно и многословно б) те же самые проблемы с синхронизацией в) создание и запуск нового потока на всех операционках занимает время.
Для упрощения всего этого и были сначала созданы такие объекты как Task и Future, которые чаще всего реализуются поверх какого-нибудь пула потоков. А затем уже в языках введены такие патерны как async/await поверх них.
И эти идеи, как помню, летали на рубеже 2000-2010 повсеместно.
Я говорил, что подобные подходы мы делали даже на Delphi ещё ~ в 2008-2009-м. И это было очень удобно. Тем более, что не надо было разделять никакие функции на "красные" и "синие", а просто указать задаче, что выполнить в потоке, что по окончанию, что синхронно в рамках одного понятного вызова.
Но собственно async/await делает почти то же самое (и автор в статье это тоже подтверждает).
Everything after the await gets hoisted into a new function that the compiler synthesizes on your behalf...
И кстати, если уж про Dart, то там кроме async/await есть и более классический подход к параллелизму.
Я понял, что вы топите за Go. Да пожалуйста, но только это тоже Google.
И попробуйте догадаться сами почему для продвижения своей GUI библиотеки Google выбрала не Go, а именно Dart. В статье, кстати, даже одна из причин этого есть.
но именно "формошлёпство" - причем на базе именно контролов операционки - являяется правильным.
Практика показывает, что таки нет. И никому это толком кроме Lazarus пока не удавалось. Но даже там с этим постоянные серьёзные проблемы на Линухе и на Маках, из-за неадекватной или своеобразной отрисовки, поэтому кроссплатформенные приложения на другой операционке там порой выглядят очень криво.
Поэтому, подход с собственной кроссплатформенной отрисовкой одинаковой на всех платформах - более перспективный с точки зрения собственно кроссплатформенности. А эксклюзивы как писались под одну операционку так и будут писаться.
Одна из причин, по которой я не люблю WebAssembly.
Любите, не любите, но это как раз выход для тех кто не хочет переписывать навороченный GUI с нуля на HTML+JS, только ради якобы острой необходимости кому-то из клиентов иметь такую возможность.
А вот плохо, что это другая задача.
Это действительно другая задача. Но можно интегрировать часть HTML+JS и в WebAssembly приложение и наоборот.
А вот если бы хотелось что-то кардинально поменять с ВЕБ-ом, то текущий его формат нужно "пристрелить" (сделать deprecated) и разработать новый формат, который стал бы общим как для ВЕБ так и для десктопной разметки. Возможно, что-то похожее на QML, или типа того, НО лучше без явной привязки к языку скрипта.
Но мы с вами прекрасно понимаем, что в ближайшем будущем этого не случится.
Зато есть интересные и современный инициативы типа QML или Flutter. Последний так к тому же вообще-то пока полный opensource, а за использование Qt+QML в коммерции требуют дорогие лицензии.
Извините, но я не могу часто отвечать.
Мне школота на Хабре давно рейтинг понизила за мой стёб над их нежно любимым Питоном и прочим откровенным Ховном для школьников, админов и домохозяек, которое зачем-то пихают теперь в каждый чайник. А писать статьи и играть по идиотским рейтинговым правилам Хабра мне некогда - работы много.
Поэтому, всего хорошего. А вы присмотритесь к Flutter+Dart - лично по-моему у него есть хороший потенциал в качестве замены богомерзкого HTML+JS фронтенда.
Всего!
Delphi не ограничивается только VCL фреймворком. В нем несколько фреймворков и они имеют собственные дизайнеры. В том числе штатный кроссплатформенный (все платформы) фреймворк - FMX, который немного гибче чем даже QML или подобный. Отдельно дизайнер окна, отдельно дизайнер представления контрола.
https://www.assemblyscript.org/ все давно "решено" (или нет)
похож на TS, но с компиляцией в Wasm
https://leanylabs.com/blog/assemblyscript-intro/
https://ecostack.dev/posts/wasm-tinygo-vs-rust-vs-assemblyscript/
Инцидент CrowdStrike 19 июля 2024 года представляет собой прекрасный пример нормализованной некомпетентности.
Отсутствие одной проверки границ массива в одном файле конфигурации привело к сбою 8.5 миллионов компьютеров Windows по всему миру.
Общий экономический ущерб: минимум 10 миллиардов долларов.
В чём причина? Ожидалось 21 поле, но было 20. Одно. Отсутствующее. Поле.
Причина - кривая архитектура MS Windows. В ней нет стабильного ядра, способного контролировать все остальные процессы. Упал драйвер - упала система.
MS зала о ущербности своей системы, но позволяла сторонним разработчикам лезть на уровень ядра. Здесь 99% вина MS. Или запрещай кому-попало лезть на уровень ядра, или проверяй и подчищай за ними. Или делай устойчивую архитектуру. Ничего из этого MS не делало.
ИИ, конечно, подливает масло в огонь, но, в основном-то, шило в заднице у бизнеса. С каких-то пор менеджемент стал считать выпуск недоработанного продукта ещё вчера - таблеткой от всех болезней конкуренции и продолжает работать по такой схеме при любых обстоятельствах. А то, что продукт тонет в тех. долге и фунционально начинает отличаться от того, что на бумаге как будто никто и не замечает
Это вы ещё преуменьшаете проблему. Мобильна версия What's Up в браузере в Windows 11 выжирают 4-х ядерный процессор в ноль, не помогает закидывание 16 Гб памяти...
всё так и было так уже в 2000 году, когда я студентом асоиу в мгапи столкнулся с дискуссией о том, что компании предпочитают быстро написанный код, не оптимальность которого компенсируется железом, а алгоритмизацию изучать вообще никто не хочет, потому что на практике вдумчивый подход проигрывает конкурентную борьбу на рынке труда… логика капитализма неумолима и бесчеловечна )
https://www.youtube.com/watch?v=ziVpqh9UXmI запитать нацисткую луну хватит
Chrome: потребление 16 ГБ для 50 вкладок теперь «нормально»
Тут проблема не столько в браузерах, сколько в сайтах. Обвешаны по самое не могу фотографиями по 1-2Мб, скриптами типа React или Vue.js, баннерами и т.п.
Мы все тоже за все хорошее и против всего плохого, но ваши призывы выглядят бледно, простите.
Вот возьмите и оптимизируйте что-нибудь ресурсоемкое. Да хоть те же LLM. Сделайте модель хотя бы уровня второго эшелона, но потребляющую в 10-100 раз меньше ресурсов. Вас же засыпят деньгами проклятые капиталисты, а программисты будут считать вас пророком и поклоняться
Это бессмысленно, т.к. метод фундаментально ограничен - именно поэтому на рубеже 1960-х-70-х после публикации соответствующей книги все резко и переключились с нейронных сетей, популярных тогда как и в нынешние годы, на другие направления. Это в XXI веке уже попытка "а давайте попробуем залить ресурсами, ведь мощности в миллионы раз выше, чем тогда" дала то, что имеем. Соответственно, точно так же упрёмся в фундаментальные ограничения (ресурсы-то не резиновые) и в этот раз. Уже скоро, ждите лопания пузыря в течение нескольких лет.
По собственным ощущениям, в нулевых и начале десятых годов со стабильностью софта и железа было даже хуже, а рост системных требований для типичного компьютера пришёлся на начало-середину десятых и после этого, в большинстве случаях заметно не повышался. Исключения вроде игр и локальных игр с LLM конечно есть, но это как раз нормально.
Та же проблема сейчас в embedded разработке
«Лучшие» Образцы Си-Кода / Хабр https://share.google/dEQ9GTG4Yx35dRf4S
Большая часть проблем с безопасностью и значительная часть утечек памяти решилась бы выбором хорошего языка программирования, Rust, Pony, Haskell, в идеале что-то типа Idris. Но примеров для обучения ИИ маловато, а люди слишком ленивые, чтобы осваивать что-то новое.
Rust сообщество настолько агрессивно-токсично в своем догматизме что с ними мало кто хочет иметь дел. И интерес к этому языку ожидаемо падает https://www.tiobe.com/tiobe-index/ Скоро так и Ada догонит ¯\_(ツ)_/¯
Вот так всегда, какие-то социальные заморочки мешают правильным техническим решениям, что в свою очередь негативно и на социуме отражается...
Но другие то комьюнити не такие "агрессивно-токсичны"? Можно на Pony писать.
Nim несколько популярнее. На Amazon (даже) книга продается - Mastering Nim: A complete guide to the programming language. Очень "крутой" язык оставшийся увы в тени. https://www.slant.co/versus/395/15833/~nim_vs_pony
https://habr.com/ru/companies/ru_mts/articles/883160/
"Если бы Python и C решили завести ребенка, то это был бы Nim. От Python он унаследовал читаемость и выразительность, а от C — скорость и контроль над ресурсами."
"А еще Nim умеет компилироваться транспилируется в C, C++ и JavaScript, что делает его универсальным инструментом. Можно писать на Nim, а затем получить быстрый C-код, совместимый практически с любой платформой. Поэтому его часто используют там, где нужна высокая производительность, но без сложностей C++."
"высокая производительность, сравнимая с C и Rust;
автоматическое управление памятью, но без сборщика мусора (можно использовать разные стратегии)."
и Zig
Nim в плане надежности особо ни чего не дает. Ну позволит он писать также быстро, как на питончике, и работать будет также быстро, как на си, но игючить и падать будет также.
У Zig есть интересные идеи, в частности в области Capabilities-based Security, но он еще сырой для продакшена. Pony, если не нужен совсем жесткий realtime, сейчас предпочтительнее.
V вспомнился https://vlang.io/compare
"Getting Started with V Programming" о нем также есть книга
Его хвалили за свербыструю компиляцию. Заботы о надежности и качестве кода я там не нашел, да и со скоростью компиляции сложные проверки не очень совместимы.
Хотя "immutability, no null, option types, free from data races", "No global state" (как и в Pony). Наверно стоит еще раз посмотреть. Правда мне обязательный return не нравится, врядли я начну его использовать, но это личные вкусы.
Судя по первому месту здесь https://www.slant.co/topics/22835/~which-programming-languages-have-the-most-powerful-type-systems Nim раскручивают. Система типов там не особо powerful.
Повторюсь, язык сам по себе хороший, лучше почти всех мейнстимовых. Но основную проблему индустрии, надежность и качество кода, он не пытается решать.
Мне на работе каждый день говорят, отдай код ии, я стараюсь сопротивляться, но убеждения менеджеров ни слепая вера в ии делают своё дело, я просто махнул рукой
В недавнем интервью Павел Дуров рассказывал насколько его команда заточена на оптимизацию. Да, не всегда у них получается. Но подход верный.
как мы нормализовали катастрофу
Высокооплачиваемые разработчики из FAANG, прошедшие 10 этапов собеседований, каждый день трудятся в поте лица над нормализацией катастрофы. И у них получается.
Meta just killed native WhatsApp on Windows 11, now it opens WebView, uses 1GB RAM all the time
Примите, что качество важнее скорости
Вашими бы устами, да мёд пить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Великий крах качества программного обеспечения: как мы нормализовали катастрофу