Я усомнился в своём понимании понятия "нормальная офисная работа" и спросил Гугол. И этот комп оказался как раз для неё, исключая процессор. Гугол просил ниже N1xx не опускаться. Так что вроде да, но с другой стороны - вроде и нет.
Если речь про работу, то уж комп купить, по крейней мере из серийных, она должна позволять любой. Иначе - проблема в работе, а не в компе. С другой стороны, я не очень понимаю как любой чертёж не более А1 или автоматизация бизнеса до человек пятидесяти может такое перегрузить, разве что внешний диск понадобится. Профессиональные CAD системы со товарищи, согласно вышесказанному, не рассматриваются.
Я говорю не только про работу с вордом дома, а про всё вообще помимо серьёзной 3D графики, серьёзного видеомонтажа, нативной разработки под Эппл и игр в ИИ. Такой комп позволяет выучить всё что угодно стоит учить и запустить любой стартап. Чего ещё?
Иными словами, самый дешёвый комп купить можно, хотя цена уже на грани (подорожает - за те же деньги смартфон получше и Termux в него, стратегически отступим), он рабочий, хотя и с оговорками, и он российский, как и должно быть - ситуация нормальная в том смысле, что катастрофы не наблюдается. А вот при росте цены тысяч до сорока и/или снижении оперативы до четырёх гигов - катастрофа будет наблюдаться ибо в обществе образуется digital divide.
Для чего нужно электромагнитное поле или пространство? Сознание существует объективно вне самого себя, если угодно - само в себе, являясь одной из первооснов. Никто и ничто им не обладает, это оно через кого-то или что-то проявляется. Меньше рассмартивайте кошек, а то и с вами будет так же.
Более-менее общепризнано, что послушного Судьба ведёт, а непослушного тащит.
При взгляде с высоты, вроде как выходит, что ИИ в ИТ выполняет рутинную работу и тем самым лишает работы людей, что печально весьма, особенно для людей выполняющих пресловутые bullshit jobs. И это крайне странно, ибо, по идее, рутинная работа должна автоматизироваться сама собой, в написании кода, например, образуя процедуры.
Можно возразить - какие процедуры, нужно же внести изменения сразу в несколько файлов! На это встречный вопрос - почему так и кто такое допустил? И в чьих интересах? Разве может такое возникнуть когда все выполняют сверхзадачу программиста - изучить предметную область и записать обнаруженное знание в форме, понятной как человеку, так и машине (да, моё любимое, не устаю повторять)?
При взгляде с высоты мне не понятно одно - какой из вариантов реализуется. Время жатвы или час расплаты?
Я не занимаюсь возом компьютеров, да и ввезённое потребляю довольно вяло. Но мне кажется, что Вы пишете не о том. Никого не волнует как там Байкал и прочая ерундистика, типа что такого на самом деле можно сделать в России. Интересно практически и формально - что можно было до того и чего стало теперь нельзя.
И я тоже захожу в DNS и смотрю самый дешёвый комп. Самый дешёвый - это важно, ибо верую в то, что вода дырочку найдёт кому не самый дешёвый - те сами абы как разберутся.
ПК DEXP Aquilon O319
Проц Intel Celeron N4120
Память 8 ГБ, DDR4
Накопитпль 256 GB 2.5" SATA
Гарантия продавца 36 мес.
Актуальная цена 19_199 руб.
Цена на конец ноября 12_499 руб.
Прежде чем качать снобизм, морщить носик и плеваться требуя от жизни то, что она зачастую не подаёт признаков намерения давать, прошу отметить - это одноклассник Mac Mini 2011, про который я могу сказать с абсолютной увереннстью - вариант рабочий (EndeavourOS), он не только делает телевизор умным, но и позволяет вот такое вот о себе написать.
Миник в однопотоке должен быть малость лучше, в многопотоке малость хуже, SSD у Миника нет, но (медленный) диск вдвое больше, памяти столько же (что и у MacBook Neo туда же), на этом можно поиграть (как-то) во много больше игр (== запустить больше графического софта), но Миник то, что из графики таки может, должен тянуть чуть быстрее, оба тихие - один холодный от рождения, другой горячий но почему-то это нормально. Чем не паритет?
Чего в этом компе российского, спросите? Охотно отвечу - гарантия (за которую не стыдно) и свойство официально быть российским. И как раз такое и имелось в виду когда говорилось про отечественные аналоги, недавно (а как иначе по поводу?) на Хабре проходила статья со списком подателей оных аналогов.
На этот комп запрет параллельного импорта влияния не окажет вообще, Минпромторг прав. А наблюдаемая бесячая динамика цены - это другое. Ну ладно, ладно, не совсем...
Но ведь он действительно жутко медленный, не поспоришь. Остаётся оспаривать "невыносимо", что автор и делает, но коряво. Да, вокруг Python много костылей, но каким боком это есть достоинство? Да, не все задачи требуют полной скорости, но зачем вообще выбирать язык где нужно об этом думать?
радость от того, что узкое место не CPU, проходит как только у каждого сотого пользователя лопается терпение и он уходит
ничто не склеивает С++ лучше, чем С++
и если скорости действительно хочется, то надо помнить
- после ускорения в 3-5 раз вполне может остаться разница в производительности в 10-20 раз
- Numba тяготеет затягивать с поддержкой свежих версий Python и легко может молчаливо дать неверный результат
- кто же поверит, что на Cython получается быстрее, чем на С
Миф 2: «GIL делает многопоточность в Python невозможной»
Читаем "Зачем плодить тяжеловесные потоки операционной системы, когда есть кооперативная многозадачность?" и сразу "Нужно загрузить все ядра? Используйте процессы." Чаво?
Да, GIL уходит в прошлое. А замедление однопотока связанное с его отсутствием тоже уходит в прошлое?
Миф 3: «Отсутствие строгой типизации превращает крупные проекты в ад»
Далее следуют методы обустройства в аду. Ответ на вопрос "Зачем!?" не приводится.
Это часть мифа о типизации, и этот миф - главный, все остальные являются его следствием. Причём в крайних формах - Lua тоже без типизации, но по скорости как минимум вдвое быстрее и реально ускоряется до двойки по сравнению с С через LuaJit. JavaScript тоже без типизации, тоже быстрее в разы, тоже выходит на типизацию через TypeScript... Почему Python?
А потому, что прежде, чем писать тип, нужно знать что это за тип. Если есть наследование - возводите в куб. И если что сделано не так, а при малейшем незнании что-то точно будет не так, то либо рефакторинг путём переписывания с нуля, либо ложимся под лавину технического долга. Поэтому языки без типизации никак и не умрут - люди пока ещё, хотя ИИ должен с этим помочь, продолжают заниматься новыми вещами. Что, по воспоминаниям, подтверждается исторически - как новьё, что HTML генрить, что данные ковырять, что модели гонять - так и Python, а дальше инерция.
А почему именно Python а не JavaScript или Lisp - это отдельный вопрос, и нужно помнить - Python тут не более, чем первый среди равных. Может задач под него, а не под Lisp тот же, больше. Может индустрия считает что Python чтобы въехать в Рай на чужом горбу подходит лучше. Может верят в лёгкий вход. Может ещё чего...
Миф 4: «Python годится только для скриптов, парсеров и Data Science»
И как развенчание предлагаются корпоративные приблуды. Для владельцев крупных компаний, а Хабр кишит ими разумеется, пойдёт. Для стремящихся в корпоративное рабство - пойдёт частично. А можно было понадёргать применений от Kivy до Anvil.works, в процессе не забыв, раз уж так получилось совершенно случайно, что вся графика скриптуется на Python.
Миф 5: «В Python нет нормального ООП (инкапсуляции)»
Это смешной миф за отсутствием определения нормальности. А как его развенчивать никого не обидев оскорблениями - я с хода не догадался.
Анонсы новых статей, полезные материалы, а так же если в процессе у вас возникнут сложности, обсудить их или задать вопрос по этой статье можно в моём Telegram-сообществе. Смело заходите, если что-то пойдет не так, — постараемся разобраться вместе.
При таком уровне изложения, если и зайду (а я не зайду), то разве что за анонсами.
It sounds familiar. But even I have read something similar, it definitely failed to impress me that time. This time is different, though.
Features like macros, header files, partial template specialization, SFINAE, and complex initialization rules make evolution extremely difficult.
Really? I mean - really evolution? I guess that are zero cost features. Does it really take measurable time for a preprocessor to do its job? To the contrary, C++ evolves making the number of cases where macros are necessary smaller and the number of cases where it is understood why macros are the right or best choice larger. And C++ is getting modules...
I know, since that surfaced in Dart, the only way macros can conflict with something - they make hot reload, at least the Dart style hot reload, impossible. That is bad for Dart because Flutter requires hot reload. It is not bad for C++ because C++ does not make the logical mistake Google has made with Dart prioritizing a single Flutter feature before the general structure of the language. I am glad that no single C++ usage scenario can cannibalize all the rest.
As a result, the committee must either preserve backward compatibility (including dangerous UB) or introduce new parallel mechanisms, which further increases language complexity.
The dangers of UB are questionable, at least beyond the wonderful domain of marketing. I agree that adding anything to a language makes it bigger. I disagree that it increases complexity. Do adding keyboard shortcuts increase complexity of an app? Anything universal has to grow. For example, stdin >> and stdout << made C++ bigger and std::print made it bigger again, but I refuse to call that complexity. Was electric engineering made more complex with the addition of semiconductors?
Only features that barely conflict with anything can be added quickly.
How can that be different? Things conflict for a reason. Remember generics in Go? It took ten years to implement them not because of "conflicts" but because it was necessary to implement them right.
For a language that claims to be the primary tool for systems programming, this has become its Achilles’ heel.
How exactly? And who exactly claims C++ is the primary tool for systems programming and nothing else? That is exactly the same mistake Google has made - attempt to sacrifice everything for one feature, one scenario, one gang, be that UI polishing or systems programming. If that was a problem, C++ would be forked and we would have a system programming dialect.
C++ must be doing something exceptionally right since it is still one language, not that which, say, modern Lisp is.
This explains why new “C++ killers” appear regularly.
Which this? The only C++ killer wannabe I know is Zig. Everything else throws away something to facilitate something else. I found a perfect explanation and/or formulation of the logic in a book, Programminh in Lua. "The problems with multithreading arise from the combination of preemption with shared memory, so we can avoid them either using non-preemptive threads or not sharing memory." Wonderful. So, they say. That immediately leads to Go, and Rust, and Python... but not to a universal C++ replacement.
Modern C++ killers have forgotten a crucial historical lesson. The first C++ compiler, cfront, was a transpiler that converted C++ (“C with Classes”) into plain C.
First, it is not a lesson, it is survivor's bias. Second, being called a killer does not make one a killer. That languages successfully took certain domains where C++ still can be successfully used and nothing more.
I like Go. I see how Go can be a better choice than C++ in many, many cases. But it is sufficient to compile both to WebAssembly to see that Go is not a C++ killer in the article sense.
In contrast, modern replacements build their own compilers and ecosystems. While this gives better diagnostics and coherence, it creates a high compatibility wall. As a result, they become viable only for greenfield projects, not for gradually replacing C++ in massive legacy codebases.
Of course they do. Because they are not overall replacements, they are local ones. If all the friction on the boundaries of their domains is eliminated, nothing revolutionary happens.
The most realistic path to a true C++ replacement is a transpiler that generates C or, more likely, C++ as its output.
The most realistic path is to invent or discover something so great, that the idea of C++ replacement is justified. So far there are no new ideas that actually make computer programming better, all "innovation" is focused on the ways to hire cheaper people, or AI as off lately, to do the job where poor quality can be compensated for with excellent marketing.
Remember iPhone? It had been created not because Jobs was a genius but because many areas made significant progress that made iPhone possible. Because Jobs was a genius, it was Apple who created iPhone. Right now there is nothing C++ replacement can be based on.
When the time is ripe, transpilation is one of the options. What actually happens depends on the nature of the new ideas we know nothing about yet.
C++ itself won not because it was the best language, but because it integrated so easily with existing C infrastructure.
Yes. But transpilation was a minor benefit, while the ability to read C code, at least the headers, was the major one. At least my memories of the rise and fall of Delphi (strongly) suggest so. Anyway, all that historical lessons are passé now, AI changes or is likely to change everything. For example, why not to ask AI to rewrite all the C++ legacy?
Это не больно, это в худшем случае препятствует постижению через копипасту. Переписывать такое из одного текста в другой - ноцебо. У Rust есть фундаментальная проблема - кто способен хорошо понять Rust, тот и первый кандидат на измену с С++, но это не боль.
Если вы строите новый проект с нуля, где критически важна безопасность памяти, и у вас есть опытные системные программисты — берите Rust.
Как по мне - слишком категорично. Задача может быть из тех, где наличие единственного владельца не есть свойство предметной области. А что такое "критически важна безопасность памяти" я не постигаю, это в лучшем случае такой маркетинг, в котором опускают "в условиях дикого организационного бардака".
В остальном, мог бы поставить плюс - поставил бы, стало бы плюсов 6, а не 5 как сейчас. Я сам бы непременно начал с границ реальной области применимости - меня вообще бесит что из этого, для любой технологии, сделали Россию (a riddle, wrapped in a mystery, inside an enigma), вполне вероятно - с перечислнием всех модных фишек (есть - нет). И это было-бы, как видно по статье, ошибкой. У Fortran есть сильно вырвавшаяся вперёд козырная область, всем остальным действительно можно пренебречь.
Про Fortran могу добавить результат моего наивного теста на разделение живого и мёртвого, занятного и постылого - apt search <subj> в Termux. Fortran прошёл.
Но главное, что здесь впервые появляется ручка-подставка, благодаря которой автономность гаджета увеличили до 16–18 часов.
Это полуправда. Планшеты В6000 и В8000, 8 и 10 дюймов, вышли одновременно. У меня был В8000 и это, учитывая то, что идеальный размер экрана планшета для образованного европеоида, использующего его без разделения экрана и без рисования, был экспериментально определён Джобсом на его сотрудниках и оказался равен 9.7 дюйма.
И рамки...
Идеальные рамки были найдены одновременно с размером. И они уменьшились, сначала по узкой стороне, а потом и много позже вообще, под влиянием не столько как обычно подлого маркетинга (то "плавность", то "безрамочность", то мегапиксели, то "глубокий чёрный"...), сколько под влиянием деградации рынка, неизбежной по мере проникновения на таковой. Для более сохранного рынка электронных книг "безрамочность" не характерна по сей день.
Поэтому и хочется о нём вспомнить - он первый и наиболее достойный.
А что вы думаете — есть ли смысл в планшетах с таким большим экраном и нужно ли было добавлять в этот гаджет проектор?
Смысл был не в экране и не в проекторе - смысл был в батарее, ручке и подставке. Подставка позволяла поставить планшет удобно и для просмотра и для печати, бросить его на любую хоть немного мягкую поверхность (обшивка дивана, подушка, одеяло...) и он на ней фиксировался намертво вплоть до вертикали. Ручка позволяла держать планшет в руках не ощущая достаточно большой вес, более 600 грамм для В8000. Батарея в В8000 была больше чем в В6000 и как-то продержалась у меня более 22 часов экрана.
О батарее в часах
Чушь это собачья, а может и маркетинг сами знаете какой. Важны не часы экрана, важна возможность не заряжать. Это в двух лицах - хватает ли на день при нормальной эксплуатации батареи, скажем 80-30, это почти часы, но другие, и возможность пропустить намеченную зарядку. Иными словами, зависимость полезности от "часов" - ступенчатая.
Hidden text
Hidden text
И В8000 находилась на ступеньке, на которой никого больше не было и нет.
Фото по хвату и фиксации
фиксация
хват с переносом веса на предплечье
На этот вопрос ответ однознаяный - ни в коем случае. Леново сделала инновацию масштаба появления планшета вообще. Не нужно быть Джобсом чтобы видеть - за это нужно было держаться двумя руками и зубами, развивая формат по мере развития экосистемы. Появился стилус или режим разделения экрана - увеличиваем экран. Рынок обогощается потребителями которым больше таскать и меньше работать - сокращаем рамки. Но не раньше.
А Леново пошла другим путём - попытками вздуть цену оправдывая это дурацкими фишками типа проектора. Результат - держали Бога за бороду, но погубили всё. Последним писком, помнится, была изумительно уродливая подставка оптимизированная для подвешивания планшета на крючок.
Сегодня пользоваться конкретно моим устройством уже невозможно. Слишком лагает он после стольких лет, батарея заряжается с огромным трудом, и в Google попросту невозможно войти, чтобы скачать приложения на Android 4.4.2.
Не верю. Есть планшет iconBit NetTAN SPACE III, это 2012 год. Он тоже лагал "после стольких лет", но стоило сбросить его к заводским (на самом деле не полне) настройкам - и все лаги исчезли. Батарея заряжается очень быстро - её ёмкость сильно уменьшилась, но служит уже не как батарея, а скорее как встроенный UPS, хотя на часок от разетки отойти легко. В Гугол точно не зайти - это хорошо, я же не хочу свои лаги назад. В Интернет тоже не зайти - браузеры старые, открывают сайты криво даже если починить сертификаты.
А программы много где есть. На вскидку, планшет читает 85% книг, показывает 50% видео, играет 99% музыки, редактирует тексты и выполняет код Lua 5.2 (с обширной библиотекой из коробки) и 5.3 (без таковой).
Называть это "невозможно пользоваться"... особенно учитывая, что такие планшеты - из времён с файловым доступом к SD карте и без W^X политики... Пользуюсь иногда.
Так что есть у меня и эмоциональная связь с этим устройством.
А то. Мой В8000 рано умер, согласно 4pda - как и всё его племя, от отказа NAND. Но он успел пересечься с iPad Air 2 - и оказался с ним вровень по как раз по тем самым пресловутым фану и экспериенсу. Вот и не могу я его взять и выбросить... К слову, iPad Air 2 вполне рабочий, получает обновления безопасности, хотя признаки устаревания есть. Наверно потому, что на 128...
Перенести структуру, сохранить логику, сменить рантайм. Легко?
Скорее глупо странно. Если задача сравнивать языки как таковые - оба должны получить одинаково незнакомую задачу. Если сравнивать языки соразмерно с целью - оба должны решать задачу своими идиоматическими методами. Просто перенести - не постигаю зачем.
Dart — это Flutter, для бэкенда нет ничего, от слова совсем.
Флаттер - увы, да. И это безумие Гугла (хотя чего взять с Интернет компании - у неё Интернет мышление без особенностей вариантов). Затачивать язык под разработку интерфейса - предполагать, что кроме интерфейса в приложении не будет ничего.
Что нет ничего для бэкенда - сомневаюсь, сам не искал, но поискать могу посоветовать. Уж если в JavaScript нашлось, то в Dart точно найдётся. А для переписывания один в один - так и должно мнооогого не хватать...
Посмотрел, как вообще пишут. И тут меня накрыл ужас - кодогенерация.
Пишут... кто? Это так, к слову... Кодогенерация, как ясно далее по тексту, не зашла административным процедурам расчитанным на отсутствие кодогенерации. Кто бы сомневался?
И это - не про Dart, а про навёрнутое, уже, вокруг него.
Как пример того, к чему приходит группа "разработчиков" учащихся друг у друга - брависсимо. А теперь ещё и Клод до кучи...
С памятью отдельная история.
Да, отдельнвя. И дело точно не во флагах. Вызывать сборщик мусора не пробовали? Немного нативной памяти через FFI? Не, я не рекомендую это вот всё. Я рекомендую не соваться в новую область, особенно не истоптанную до эффективности нейронок, без хорошего специалиста по языку.
И это называется "ready for cloud".
Именно называется. И это, на самом деле и почему я пишу коммент, трагедия. Технологии впариваются продаются как на базаре, особенно Гуглом (а чё, Интернет мышление же, а Интернет - он базар и есть). И что-то выяснить без глубокого погружения в предмет - невозможно. В результате - решения случайны, результат очевиден наблюдаем.
Очень хорош на бумаге, но на деле его ниша — только Flutter.
Не вполне верно без явных временных привязок. Дойдут у кого-то с реальным знанием языка дело до ниши - она и расширится. А с Клодой и Гуглой - не станет расширяться.
Практический вопрос - какая польза будет тому, кто её расширит? Моя догадка - практически никакой...
Несколько лет пытались внедрить макросы, но не смогли,
Согласно открытым (ну, не вполне и не всегда и не отовсюду) источникам - дело хуже. Смогли, по всем пунктам смогли, кроме одного - макросы не удалось совместить с hot reload, а это один из столпов рекламы Флаттера.
Если бы после спада нагрузки память возвращалась за разумное время, уже сейчас получился бы отличный цикл: HPA поднимает второй под за секунду, трафик распределяется, нагрузка падает, память освобождается, Kubernetes уплотняет ноды.
Что-то мне опыт подсказывает - и это слишком оптимистично. То же самый эффект что и с Дартом, только теперь с Кубернетисом - со свиным рылом в калашный ряд. И это, на самом деле, тоже трагедия - ИТ самоорганизуются в системы так, чтобы противостоять изменениям, как следует (ещё и) из статьи.
И вот ирония - я искал серебряную пулю, которая уже есть. Да, она скучная, многословная, с err != nil на каждой строчке, и этот культ явности, где context.Context первым аргументом в каждую функцию звучит как привет из 2009 года.
Ну, err != nil мешает тем меньше, чем разумней обрабатываются ошибки. Да и контекст передавать как параметр точно нужно только в те функции, которые изначально написаны соответствующе. Это третья трагедия - низкий порог входа в сочетании с уважением к мнению большинства...
В открытых источниках про эту серебрянную пулю сказано - будут редкие но большие задержки, если клиент реагирует истерически - берите Rust. Да, тот самый, где половина полнты по Тюрингу - через unsafe, а компилятор провоцирует избыточный вес разработчиков через походы кофе попить не без булочек.
Claude Code сделал механический перенос почти бесплатным
Тут можно узреть много аналогий. Вот эту, пока и вроде, не озвучивали. "Чтобы разориться на бирже, новичку нужно примерно сорок транзакций. Без электронного трейдинга, на это уходили месяцы, с ним..."
Чего хорошего я могу сказать?
Между вайбом и копипастой нет качественных различий. Клод не создаёт в ИТ новых проблем, он резко усугубляет старые. И это хорошо. Чем раньше наступает неизбежный кризис, тем лучше - на борьбу с неизбежным потрачено меньше ресурсов, значит для выхода из кризиса осталось больше.
Это вводный туториал для тех, кто только знакомится с языком
Это плохой вводный туториал. Вводный может петь за типы, память и вычисления (кстати, про память ничего не сказано) только после того, как рассказано, пусть кратко, главное
на каких платформах есть (а тут вроде как есть что сказать про WebAssembly)
какие есть базовые функции (сборщик мусора, подсчёт ссылок, ООП, дженерики, hot reload...) и каких нет
как выполняются параллельные вычисления
что можно сделать с и без FFI (на вскидку - много и писать одни файлы исходя из других)
насколько быстро и прожорливо будет работать
сколько выживших диалектов
Тут сразу многие отсеятся и можно переходить к второму и тоже главному - где брать библиотеки, те, что без малвари.
И вот теперь останутся те немногие, кому интеесно то, что в статье. Если же Ваша цель в том, чтобы отвадить от смотреть в сторону Fortran, то туториал отличный.
каждая программа должна начинаться с IMPLICIT NONE
Программа, особенно каждая, ни у кого не занимала и (поэтому) ничего не должна. Такая ошибка, как приведённая в качестве доказательства, не возникает на практике поскольку IDE автодополняет, а линтер обнаруживает неиспользуемые значения. Если они у кого этого не делают... ответ на стоит ли смотреть почти очевиден.
И ещё замечание - конкуренты Fortran не Go и Rust, и уж точно не Python да JavaScript, а Julia.
Вполне прекрасный язык. Сборщика мусора нет. Бэкенд, консоль, WebAssembly, какие-никакие кроссплатформенные игровые движки, теперь вот Андроид - есть. И это результат нескольких лет работы, Эппл объявила универсальный Swift целью и последовательно идёт к ней. Гугол тоже недавно объявила универсальный Dart целью, но зная Гугол и зная Эппл...
Однако, <самка псовых> <плоская еда>. Начинаем ставить Swift по инструкции - получаем меню выбора из десятка Линукс дистрибутивов, где половина - Ubuntu. Как по мне - это 120% мерзость. Всё нормальное ставится нормально - Go, Rust, Lua, Julia, C/C++, Dart/Flutter... Как по мне, точную нижнюю грань обозначает Python - ну почти нормально ставится. Всё более бубновое или танцевальное - это не нормально.
Замечу, что мне не интересно почему так. Если иначе нельзя или сложно - значит проблема в Swift, иначе проблема в Эппл. Инстинкт подсказывает - держись подальше... от всех, кто стреляет себе в ногу, даже если это Эппл.
Книги по WebAssembly читал когда ещё, обратил внимание, что они, как правило, не по ней как таковой, а по какому-то языку в неё компилируемому. И чем книга лучше, тем вероятнее, что содержит пассаж типа "сама по WebAssembly не гарантирует ... (прирост скорости, например), но мы ведь любим писать на ... (да на том же Rust), правда?".
Мой любимый дурацкий тест на reality check (числа Фибоначчи) показал, что С в WebAssembly процентов на 20 быстрее чем JavaScript, но только не когда iPad, где С раза в полтора медленнее. Что соответствует тем же дурацким тестом сравнению Node.js, Deno и Bun, кстати.
Что характернго - никакого влияния пересечение границ и прочая в этом тесте не имеют.
При чём тут, в сравнении скорости, TypeScript - не постигаю, вместо него следует читать JavaScript. А если вдруг есть подозрение что TypeScript, или там Dart совершенно аналогично, косячит - нужно приводить результат JavaScript отдельно.
Раздел "Ключевые выводы", как по мне, выводов не содержит, перечисление фактов вместо них. Как по мне опять, вывод мог бы быть таким - прежде чем соваться в WebAssembly, определитесь зачем. Чтобы модно смотреться, периспользовать код, применять именно нужные абстракции, насладиться песочницей - всё подойдёт, кроме скорости.
Я сам языков не учил, по крайней мере в классическом понимании процесса, но это не мешант изложенным идеям казаться правильными. Ниже две с большой вероятностью весьма полезные книжки, наверно это как раз оно. А может и нет.
Sidney Greenbaum. The Oxford English Grammar, Oxford University Press, 1996
Zeljko Cipris, Shoko Hamano. Making Sense of Japanese Grammer, University of Hawai‘i Press, 2002
Стимулы для развития всё равно будут. Есть пример прекрасной лицензии - делай что хочешь, только автором себя не объявляй. И сколько ни злоупотребляй этой лицензией, студенты как ломились в MIT, так и ломятся. кстати, если автор на одном шедевре живёт 30 лет, то мы с него поимеем хорошо если два шедевра, а если пол года - то сто два.
Превосходный пример - Япония. С одной стороны - преклонение перед копирайтом, с другой - полная свобода заимствования идей на европейской стороне невозможная в принципе. Так что вопрос в том, является ли существующая система копирайта худшей из возможных или таки нет.
Исходную статью я не читал ибо имел заведомо предвзятое отношение к содержанию, в том числе к первоисточнику по Задорнову. Там любят и как сложить 2 и 2 обсудить, и что такое π на теорфизе четвёртого курса спросить, данные из первых рук. Но раз уж народ повёлся до реакций...
Есть простой практический способ узнать как хорошо и удобно это сделать, типа не вдаваясь в шеллы которых тупо нету.
поставить что-то путное, оно само себя в шелл добавит способом на миллионах пользователей испытанном, например, Julia
посмотреть как сделано
задуматься, что в ином случае может быть малость лучше чутка иначе - вместо начала добавлять в ПУТЬ в конце или наоборот
изучить команду "." bash или аналог, чтобы больше одной строки в разные места не добавлять
копипастить от души всеми способами
Шелл bash, образец Julia
[[ -f ~/.bash_my ]] && . ~/.bash_my
#
# .NET
#
export DOTNET_ROOT=/home/andy/dotnet
case ":$PATH:" in
*:/home/andy/dotnet:*)
;;
*)
export PATH=${PATH}:/home/andy/dotnet
;;
esac
case ":$PATH:" in
*:/home/andy/dotnet/tools:*)
;;
*)
export PATH=${PATH}:/home/andy/dotnet/tools
;;
esac
#
# my execs
#
case ":$PATH:" in
*:/home/andy/.local/bin:*)
;;
*)
export PATH=/home/andy/.local/bin${PATH:+:${PATH}}
;;
esac
Первое, что бросается в глаза - фактически тождественность TIOBE и PYPL. Оба построены на поисковых запросах, раз одинаковые - либо оба правильные, либо оба неправильные. Первое много вероятнее.
Итак, что-то действительно произошло с поисковыми запросами, причём лёгкое падение Python совершенно не впечатляет по сравнению с обрушением Go. Последнее точно, а первое - только скорее всего за малостью эффекта, не наблюдается по другим индексам. То есть дело именно в запросах, а не в каких-то изменениях в использовании языков. Да, первой в голову приходит мысль что влияют беседы с ИИ, на одних языках они удачнее чем на других, но данных чтобы её подтвердить или опровергнуть я не вижу.
Маленькой тучкой на горизонте идеи, что ничего не происходит вообще, мне кажется то, что по Stackoverflow язык Lua хотят учить больше, чем Go. Тут первой в голову приходит мысль об изменении надежд вкатунов...
Последние годы Python был вроде универсального инструмента: на нем писали всё — от мелких скриптов до огромных ML-систем, а его первое место в рейтингах воспринималось как норма.
На JavaScript тоже писали и как норма воспринималось не первое место Python, а то, что первое место за JavaScript или Python, смотря как посмотреть.
Но к началу 2026-го заметно, что динамика меняется. Скорее всего — вслед за приоритетами.
Как я пытался описать выше - нет, не заметно. Приоритеты при переходе к падению рынков точно меняются, но по популярности языков это ещё не особо читается. Я бы сказал, что если на неё что и влияет, то (пока) только в среде выходящих на рынок труда.
Уходит время, когда удобство и низкий порог входа перекрывали любые вопросы к производительности.
С удобством никто и никогда не заморачивался, удобство - это про Julia или Lua, а там без перемен. Низкий порог входа в Python... он сейчас с нами в комнате? Если и говорить о подобном, то о времени затрачиваемом на получение решения без фиксации на скорости и ресурсах. И то, это без фиксации - далеко не любые вопросы к производительности, на те вопросы давно даны ответы, начиная с Cython.
А что вайб кодинг позволяет получить поганый прототип на любом языке так же быстро, как на Python - в этом что-то есть.
Я усомнился в своём понимании понятия "нормальная офисная работа" и спросил Гугол. И этот комп оказался как раз для неё, исключая процессор. Гугол просил ниже N1xx не опускаться. Так что вроде да, но с другой стороны - вроде и нет.
Если речь про работу, то уж комп купить, по крейней мере из серийных, она должна позволять любой. Иначе - проблема в работе, а не в компе. С другой стороны, я не очень понимаю как любой чертёж не более А1 или автоматизация бизнеса до человек пятидесяти может такое перегрузить, разве что внешний диск понадобится. Профессиональные CAD системы со товарищи, согласно вышесказанному, не рассматриваются.
Я говорю не только про работу с вордом дома, а про всё вообще помимо серьёзной 3D графики, серьёзного видеомонтажа, нативной разработки под Эппл и игр в ИИ. Такой комп позволяет выучить всё что
угодностоит учить и запустить любой стартап. Чего ещё?Иными словами, самый дешёвый комп купить можно, хотя цена уже на грани (подорожает - за те же деньги смартфон получше и Termux в него, стратегически отступим), он рабочий, хотя и с оговорками, и он российский, как и должно быть - ситуация нормальная в том смысле, что катастрофы не наблюдается. А вот при росте цены тысяч до сорока и/или снижении оперативы до четырёх гигов - катастрофа будет наблюдаться ибо в обществе образуется digital divide.
Что я, собственно, и хочу сказать - пока ОК.
Для чего нужно электромагнитное поле или пространство? Сознание существует объективно вне самого себя, если угодно - само в себе, являясь одной из первооснов. Никто и ничто им не обладает, это оно через кого-то или что-то проявляется. Меньше рассмартивайте кошек, а то и с вами будет так же.
Более-менее общепризнано, что послушного Судьба ведёт, а непослушного тащит.
При взгляде с высоты, вроде как выходит, что ИИ в ИТ выполняет рутинную работу и тем самым лишает работы людей, что печально весьма, особенно для людей выполняющих пресловутые bullshit jobs. И это крайне странно, ибо, по идее, рутинная работа должна автоматизироваться сама собой, в написании кода, например, образуя процедуры.
Можно возразить - какие процедуры, нужно же внести изменения сразу в несколько файлов! На это встречный вопрос - почему так и кто такое допустил? И в чьих интересах? Разве может такое возникнуть когда все выполняют сверхзадачу программиста - изучить предметную область и записать обнаруженное знание в форме, понятной как человеку, так и машине (да, моё любимое, не устаю повторять)?
При взгляде с высоты мне не понятно одно - какой из вариантов реализуется. Время жатвы или час расплаты?
Я не занимаюсь возом компьютеров, да и ввезённое потребляю довольно вяло. Но мне кажется, что Вы пишете не о том. Никого не волнует как там Байкал и прочая ерундистика, типа что такого на самом деле можно сделать в России. Интересно практически и формально - что можно было до того и чего стало теперь нельзя.
И я тоже захожу в DNS и смотрю самый дешёвый комп. Самый дешёвый - это важно, ибо верую в то, что
вода дырочку найдёткому не самый дешёвый - те сами абы как разберутся.ПК DEXP Aquilon O319
Проц Intel Celeron N4120
Память 8 ГБ, DDR4
Накопитпль 256 GB 2.5" SATA
Гарантия продавца 36 мес.
Актуальная цена 19_199 руб.
Цена на конец ноября 12_499 руб.
Прежде чем качать снобизм, морщить носик и плеваться требуя от жизни то, что она зачастую не подаёт признаков намерения давать, прошу отметить - это одноклассник Mac Mini 2011, про который я могу сказать с абсолютной увереннстью - вариант рабочий (EndeavourOS), он не только делает телевизор умным, но и позволяет вот такое вот о себе написать.
Миник в однопотоке должен быть малость лучше, в многопотоке малость хуже, SSD у Миника нет, но (медленный) диск вдвое больше, памяти столько же (что и у MacBook Neo туда же), на этом можно поиграть (как-то) во много больше игр (== запустить больше графического софта), но Миник то, что из графики таки может, должен тянуть чуть быстрее, оба тихие - один холодный от рождения, другой горячий но почему-то это нормально. Чем не паритет?
Чего в этом компе российского, спросите? Охотно отвечу - гарантия (за которую не стыдно) и свойство официально быть российским. И как раз такое и имелось в виду когда говорилось про отечественные аналоги, недавно (а как иначе по поводу?) на Хабре проходила статья со списком подателей оных аналогов.
На этот комп запрет параллельного импорта влияния не окажет вообще, Минпромторг прав. А наблюдаемая бесячая динамика цены - это другое. Ну ладно, ладно, не совсем...
Это надо пояснить.
После чего можно поетить System Settings, промотать панель до секции Security & Privacy и кликнуть Login Screen. Ну и перезагрузка...
Но ведь он действительно жутко медленный, не поспоришь. Остаётся оспаривать "невыносимо", что автор и делает, но коряво. Да, вокруг Python много костылей, но каким боком это есть достоинство? Да, не все задачи требуют полной скорости, но зачем вообще выбирать язык где нужно об этом думать?
радость от того, что узкое место не CPU, проходит как только у каждого сотого пользователя лопается терпение и он уходит
ничто не склеивает С++ лучше, чем С++
и если скорости действительно хочется, то надо помнить
- после ускорения в 3-5 раз вполне может остаться разница в производительности в 10-20 раз
- Numba тяготеет затягивать с поддержкой свежих версий Python и легко может молчаливо дать неверный результат
- кто же поверит, что на Cython получается быстрее, чем на С
Читаем "Зачем плодить тяжеловесные потоки операционной системы, когда есть кооперативная многозадачность?" и сразу "Нужно загрузить все ядра? Используйте процессы." Чаво?
Да, GIL уходит в прошлое. А замедление однопотока связанное с его отсутствием тоже уходит в прошлое?
Далее следуют методы обустройства в аду. Ответ на вопрос "Зачем!?" не приводится.
Это часть мифа о типизации, и этот миф - главный, все остальные являются его следствием. Причём в крайних формах - Lua тоже без типизации, но по скорости как минимум вдвое быстрее и реально ускоряется до двойки по сравнению с С через LuaJit. JavaScript тоже без типизации, тоже быстрее в разы, тоже выходит на типизацию через TypeScript... Почему Python?
А потому, что прежде, чем писать тип, нужно знать что это за тип. Если есть наследование - возводите в куб. И если что сделано не так, а при малейшем незнании что-то точно будет не так, то либо рефакторинг путём переписывания с нуля, либо ложимся под лавину технического долга. Поэтому языки без типизации никак и не умрут - люди пока ещё, хотя ИИ должен с этим помочь, продолжают заниматься новыми вещами. Что, по воспоминаниям, подтверждается исторически - как новьё, что HTML генрить, что данные ковырять, что модели гонять - так и Python, а дальше инерция.
А почему именно Python а не JavaScript или Lisp - это отдельный вопрос, и нужно помнить - Python тут не более, чем первый среди равных. Может задач под него, а не под Lisp тот же, больше. Может индустрия считает что Python чтобы въехать в Рай на чужом горбу подходит лучше. Может верят в лёгкий вход. Может ещё чего...
И как развенчание предлагаются корпоративные приблуды. Для владельцев крупных компаний, а Хабр кишит ими разумеется, пойдёт. Для стремящихся в корпоративное рабство - пойдёт частично. А можно было понадёргать применений от Kivy до Anvil.works, в процессе не забыв, раз уж так получилось совершенно случайно, что вся графика скриптуется на Python.
Это смешной миф за отсутствием определения нормальности. А как его развенчивать никого не обидев оскорблениями - я с хода не догадался.
При таком уровне изложения, если и зайду (а я не зайду), то разве что за анонсами.
It sounds familiar. But even I have read something similar, it definitely failed to impress me that time. This time is different, though.
Really? I mean - really evolution? I guess that are zero cost features. Does it really take measurable time for a preprocessor to do its job? To the contrary, C++ evolves making the number of cases where macros are necessary smaller and the number of cases where it is understood why macros are the right or best choice larger. And C++ is getting modules...
I know, since that surfaced in Dart, the only way macros can conflict with something - they make hot reload, at least the Dart style hot reload, impossible. That is bad for Dart because Flutter requires hot reload. It is not bad for C++ because C++ does not make the logical mistake Google has made with Dart prioritizing a single Flutter feature before the general structure of the language. I am glad that no single C++ usage scenario can cannibalize all the rest.
The dangers of UB are questionable, at least beyond the wonderful domain of marketing. I agree that adding anything to a language makes it bigger. I disagree that it increases complexity. Do adding keyboard shortcuts increase complexity of an app? Anything universal has to grow. For example, stdin >> and stdout << made C++ bigger and std::print made it bigger again, but I refuse to call that complexity. Was electric engineering made more complex with the addition of semiconductors?
How can that be different? Things conflict for a reason. Remember generics in Go? It took ten years to implement them not because of "conflicts" but because it was necessary to implement them right.
How exactly? And who exactly claims C++ is the primary tool for systems programming and nothing else? That is exactly the same mistake Google has made - attempt to sacrifice everything for one feature, one scenario, one gang, be that UI polishing or systems programming. If that was a problem, C++ would be forked and we would have a system programming dialect.
C++ must be doing something exceptionally right since it is still one language, not that which, say, modern Lisp is.
Which this? The only C++ killer wannabe I know is Zig. Everything else throws away something to facilitate something else. I found a perfect explanation and/or formulation of the logic in a book, Programminh in Lua. "The problems with multithreading arise from the combination of preemption with shared memory, so we can avoid them either using non-preemptive threads or not sharing memory." Wonderful. So, they say. That immediately leads to Go, and Rust, and Python... but not to a universal C++ replacement.
First, it is not a lesson, it is survivor's bias. Second, being called a killer does not make one a killer. That languages successfully took certain domains where C++ still can be successfully used and nothing more.
I like Go. I see how Go can be a better choice than C++ in many, many cases. But it is sufficient to compile both to WebAssembly to see that Go is not a C++ killer in the article sense.
Of course they do. Because they are not overall replacements, they are local ones. If all the friction on the boundaries of their domains is eliminated, nothing revolutionary happens.
The most realistic path is to invent or discover something so great, that the idea of C++ replacement is justified. So far there are no new ideas that actually make computer programming better, all "innovation" is focused on the ways to hire cheaper people, or AI as off lately, to do the job where poor quality can be compensated for with excellent marketing.
Remember iPhone? It had been created not because Jobs was a genius but because many areas made significant progress that made iPhone possible. Because Jobs was a genius, it was Apple who created iPhone. Right now there is nothing C++ replacement can be based on.
When the time is ripe, transpilation is one of the options. What actually happens depends on the nature of the new ideas we know nothing about yet.
Yes. But transpilation was a minor benefit, while the ability to read C code, at least the headers, was the major one. At least my memories of the rise and fall of Delphi (strongly) suggest so. Anyway, all that historical lessons are passé now, AI changes or is likely to change everything. For example, why not to ask AI to rewrite all the C++ legacy?
Это не больно, это в худшем случае препятствует постижению через копипасту. Переписывать такое из одного текста в другой - ноцебо. У Rust есть фундаментальная проблема - кто способен хорошо понять Rust, тот и первый кандидат на измену с С++, но это не боль.
Как по мне - слишком категорично. Задача может быть из тех, где наличие единственного владельца не есть свойство предметной области. А что такое "критически важна безопасность памяти" я не постигаю, это в лучшем случае такой маркетинг, в котором опускают "в условиях дикого организационного бардака".
В остальном, мог бы поставить плюс - поставил бы, стало бы плюсов 6, а не 5 как сейчас. Я сам бы непременно начал с границ реальной области применимости - меня вообще бесит что из этого, для любой технологии, сделали Россию (a riddle, wrapped in a mystery, inside an enigma), вполне вероятно - с перечислнием всех модных фишек (есть - нет). И это было-бы, как видно по статье, ошибкой. У Fortran есть сильно вырвавшаяся вперёд козырная область, всем остальным действительно можно пренебречь.
Про Fortran могу добавить результат моего наивного теста на разделение живого и мёртвого, занятного и постылого - apt search <subj> в Termux. Fortran прошёл.
Это полуправда. Планшеты В6000 и В8000, 8 и 10 дюймов, вышли одновременно. У меня был В8000 и это, учитывая то, что идеальный размер экрана планшета для образованного европеоида, использующего его без разделения экрана и без рисования, был экспериментально определён Джобсом на его сотрудниках и оказался равен 9.7 дюйма.
И рамки...
Идеальные рамки были найдены одновременно с размером. И они уменьшились, сначала по узкой стороне, а потом и много позже вообще, под влиянием не столько как обычно подлого маркетинга (то "плавность", то "безрамочность", то мегапиксели, то "глубокий чёрный"...), сколько под влиянием деградации рынка, неизбежной по мере проникновения на таковой. Для более сохранного рынка электронных книг "безрамочность" не характерна по сей день.
Поэтому и хочется о нём вспомнить - он первый и наиболее достойный.
Смысл был не в экране и не в проекторе - смысл был в батарее, ручке и подставке. Подставка позволяла поставить планшет удобно и для просмотра и для печати, бросить его на любую хоть немного мягкую поверхность (обшивка дивана, подушка, одеяло...) и он на ней фиксировался намертво вплоть до вертикали. Ручка позволяла держать планшет в руках не ощущая достаточно большой вес, более 600 грамм для В8000. Батарея в В8000 была больше чем в В6000 и как-то продержалась у меня более 22 часов экрана.
О батарее в часах
Чушь это собачья, а может и маркетинг сами знаете какой. Важны не часы экрана, важна возможность не заряжать. Это в двух лицах - хватает ли на день при нормальной эксплуатации батареи, скажем 80-30, это почти часы, но другие, и возможность пропустить намеченную зарядку. Иными словами, зависимость полезности от "часов" - ступенчатая.
Hidden text
Hidden text
И В8000 находилась на ступеньке, на которой никого больше не было и нет.
Фото по хвату и фиксации
На этот вопрос ответ однознаяный - ни в коем случае. Леново сделала инновацию масштаба появления планшета вообще. Не нужно быть Джобсом чтобы видеть - за это нужно было держаться двумя руками и зубами, развивая формат по мере развития экосистемы. Появился стилус или режим разделения экрана - увеличиваем экран. Рынок обогощается потребителями которым больше таскать и меньше работать - сокращаем рамки. Но не раньше.
А Леново пошла другим путём - попытками вздуть цену оправдывая это дурацкими фишками типа проектора. Результат - держали Бога за бороду, но погубили всё. Последним писком, помнится, была изумительно уродливая подставка оптимизированная для подвешивания планшета на крючок.
Не верю. Есть планшет iconBit NetTAN SPACE III, это 2012 год. Он тоже лагал "после стольких лет", но стоило сбросить его к заводским (на самом деле не полне) настройкам - и все лаги исчезли. Батарея заряжается очень быстро - её ёмкость сильно уменьшилась, но служит уже не как батарея, а скорее как встроенный UPS, хотя на часок от разетки отойти легко. В Гугол точно не зайти - это хорошо, я же не хочу свои лаги назад. В Интернет тоже не зайти - браузеры старые, открывают сайты криво даже если починить сертификаты.
А программы много где есть. На вскидку, планшет читает 85% книг, показывает 50% видео, играет 99% музыки, редактирует тексты и выполняет код Lua 5.2 (с обширной библиотекой из коробки) и 5.3 (без таковой).
Называть это "невозможно пользоваться"... особенно учитывая, что такие планшеты - из времён с файловым доступом к SD карте и без W^X политики... Пользуюсь иногда.
А то. Мой В8000 рано умер, согласно 4pda - как и всё его племя, от отказа NAND. Но он успел пересечься с iPad Air 2 - и оказался с ним вровень по как раз по тем самым пресловутым фану и экспериенсу. Вот и не могу я его взять и выбросить... К слову, iPad Air 2 вполне рабочий, получает обновления безопасности, хотя признаки устаревания есть. Наверно потому, что на 128...
Скорее
глупостранно. Если задача сравнивать языки как таковые - оба должны получить одинаково незнакомую задачу. Если сравнивать языки соразмерно с целью - оба должны решать задачу своими идиоматическими методами. Просто перенести - не постигаю зачем.Флаттер - увы, да. И это безумие Гугла (хотя чего взять с Интернет компании - у неё Интернет мышление без
особенностейвариантов). Затачивать язык под разработку интерфейса - предполагать, что кроме интерфейса в приложении не будет ничего.Что нет ничего для бэкенда - сомневаюсь, сам не искал, но поискать могу посоветовать. Уж если в JavaScript нашлось, то в Dart точно найдётся. А для переписывания один в один - так и должно мнооогого не хватать...
Пишут... кто? Это так, к слову... Кодогенерация, как ясно далее по тексту, не зашла административным процедурам расчитанным на отсутствие кодогенерации. Кто бы сомневался?
И это - не про Dart, а про навёрнутое, уже, вокруг него.
Как пример того, к чему приходит группа "разработчиков" учащихся друг у друга - брависсимо. А теперь ещё и Клод до кучи...
Да, отдельнвя. И дело точно не во флагах. Вызывать сборщик мусора не пробовали? Немного нативной памяти через FFI? Не, я не рекомендую это вот всё. Я рекомендую не соваться в новую область, особенно не истоптанную до эффективности нейронок, без хорошего специалиста по языку.
Именно называется. И это, на самом деле и почему я пишу коммент, трагедия. Технологии
впариваютсяпродаются как на базаре, особенно Гуглом (а чё, Интернет мышление же, а Интернет - он базар и есть). И что-то выяснить без глубокого погружения в предмет - невозможно. В результате - решения случайны, результаточевиденнаблюдаем.Не вполне верно без явных временных привязок. Дойдут у кого-то с реальным знанием языка дело до ниши - она и расширится. А с Клодой и Гуглой - не станет расширяться.
Практический вопрос - какая польза будет тому, кто её расширит? Моя догадка - практически никакой...
Согласно открытым (ну, не вполне и не всегда и не отовсюду) источникам - дело хуже. Смогли, по всем пунктам смогли, кроме одного - макросы не удалось совместить с hot reload, а это один из столпов рекламы Флаттера.
Что-то мне опыт подсказывает - и это слишком оптимистично. То же самый эффект что и с Дартом, только теперь с Кубернетисом - со свиным рылом в калашный ряд. И это, на самом деле, тоже трагедия - ИТ самоорганизуются в системы так, чтобы противостоять изменениям, как следует (ещё и) из статьи.
Ну, err != nil мешает тем меньше, чем разумней обрабатываются ошибки. Да и контекст передавать как параметр точно нужно только в те функции, которые изначально написаны соответствующе. Это третья трагедия - низкий порог входа в сочетании с уважением к мнению большинства...
В открытых источниках про эту серебрянную пулю сказано - будут редкие но большие задержки, если клиент реагирует истерически - берите Rust. Да, тот самый, где половина полнты по Тюрингу - через unsafe, а компилятор провоцирует избыточный вес разработчиков через походы кофе попить не без булочек.
Тут можно узреть много аналогий. Вот эту, пока и вроде, не озвучивали. "Чтобы разориться на бирже, новичку нужно примерно сорок транзакций. Без электронного трейдинга, на это уходили месяцы, с ним..."
Чего хорошего я могу сказать?
Между вайбом и копипастой нет качественных различий. Клод не создаёт в ИТ новых проблем, он резко усугубляет старые. И это хорошо. Чем раньше наступает неизбежный кризис, тем лучше - на борьбу с неизбежным потрачено меньше ресурсов, значит для выхода из кризиса осталось больше.
Это плохой вводный туториал. Вводный может петь за типы, память и вычисления (кстати, про память ничего не сказано) только после того, как рассказано, пусть кратко, главное
на каких платформах есть (а тут вроде как есть что сказать про WebAssembly)
какие есть базовые функции (сборщик мусора, подсчёт ссылок, ООП, дженерики, hot reload...) и каких нет
как выполняются параллельные вычисления
что можно сделать с и без FFI (на вскидку - много и писать одни файлы исходя из других)
насколько быстро и прожорливо будет работать
сколько выживших диалектов
Тут сразу многие отсеятся и можно переходить к второму и тоже главному - где брать библиотеки, те, что без малвари.
И вот теперь останутся те немногие, кому интеесно то, что в статье. Если же Ваша цель в том, чтобы отвадить от смотреть в сторону Fortran, то туториал отличный.
Программа, особенно каждая, ни у кого не занимала и (поэтому) ничего не должна. Такая ошибка, как приведённая в качестве доказательства, не возникает на практике поскольку IDE автодополняет, а линтер обнаруживает неиспользуемые значения. Если они у кого этого не делают... ответ на стоит ли смотреть почти очевиден.
И ещё замечание - конкуренты Fortran не Go и Rust, и уж точно не Python да JavaScript, а Julia.
И это было очень печально. © Сэй Сёнагон
Вполне прекрасный язык. Сборщика мусора нет. Бэкенд, консоль, WebAssembly, какие-никакие кроссплатформенные игровые движки, теперь вот Андроид - есть. И это результат нескольких лет работы, Эппл объявила универсальный Swift целью и последовательно идёт к ней. Гугол тоже недавно объявила универсальный Dart целью, но зная Гугол и зная Эппл...
Однако, <самка псовых> <плоская еда>. Начинаем ставить Swift по инструкции - получаем меню выбора из десятка Линукс дистрибутивов, где половина - Ubuntu. Как по мне - это 120% мерзость. Всё нормальное ставится нормально - Go, Rust, Lua, Julia, C/C++, Dart/Flutter... Как по мне, точную нижнюю грань обозначает Python - ну почти нормально ставится. Всё более бубновое или танцевальное - это не нормально.
Замечу, что мне не интересно почему так. Если иначе нельзя или сложно - значит проблема в Swift, иначе проблема в Эппл. Инстинкт подсказывает - держись подальше... от всех, кто стреляет себе в ногу, даже если это Эппл.
А урок № 0 был? Я бы не стал, раз уж не навреди, в первом уроке опускать
Раза в четыре с хвостиком.
Книги по WebAssembly читал когда ещё, обратил внимание, что они, как правило, не по ней как таковой, а по какому-то языку в неё компилируемому. И чем книга лучше, тем вероятнее, что содержит пассаж типа "сама по WebAssembly не гарантирует ... (прирост скорости, например), но мы ведь любим писать на ... (да на том же Rust), правда?".
Мой любимый дурацкий тест на reality check (числа Фибоначчи) показал, что С в WebAssembly процентов на 20 быстрее чем JavaScript, но только не когда iPad, где С раза в полтора медленнее. Что соответствует тем же дурацким тестом сравнению Node.js, Deno и Bun, кстати.
Что характернго - никакого влияния пересечение границ и прочая в этом тесте не имеют.
При чём тут, в сравнении скорости, TypeScript - не постигаю, вместо него следует читать JavaScript. А если вдруг есть подозрение что TypeScript, или там Dart совершенно аналогично, косячит - нужно приводить результат JavaScript отдельно.
Раздел "Ключевые выводы", как по мне, выводов не содержит, перечисление фактов вместо них. Как по мне опять, вывод мог бы быть таким - прежде чем соваться в WebAssembly, определитесь зачем. Чтобы модно смотреться, периспользовать код, применять именно нужные абстракции, насладиться песочницей - всё подойдёт, кроме скорости.
Я сам языков не учил, по крайней мере в классическом понимании процесса, но это не мешант изложенным идеям казаться правильными. Ниже две с большой вероятностью весьма полезные книжки, наверно это как раз оно. А может и нет.
Sidney Greenbaum. The Oxford English Grammar, Oxford University Press, 1996
Zeljko Cipris, Shoko Hamano. Making Sense of Japanese Grammer, University of Hawai‘i Press, 2002
Стимулы для развития всё равно будут. Есть пример прекрасной лицензии - делай что хочешь, только автором себя не объявляй. И сколько ни злоупотребляй этой лицензией, студенты как ломились в MIT, так и ломятся. кстати, если автор на одном шедевре живёт 30 лет, то мы с него поимеем хорошо если два шедевра, а если пол года - то сто два.
Превосходный пример - Япония. С одной стороны - преклонение перед копирайтом, с другой - полная свобода заимствования идей на европейской стороне невозможная в принципе. Так что вопрос в том, является ли существующая система копирайта худшей из возможных или таки нет.
Исходную статью я не читал ибо имел заведомо предвзятое отношение к содержанию, в том числе к первоисточнику по Задорнову. Там любят и как сложить 2 и 2 обсудить, и что такое π на теорфизе четвёртого курса спросить, данные из первых рук. Но раз уж народ повёлся до реакций...
Есть простой практический способ узнать как хорошо и удобно это сделать, типа не вдаваясь в шеллы которых тупо нету.
поставить что-то путное, оно само себя в шелл добавит способом на миллионах пользователей испытанном, например, Julia
посмотреть как сделано
задуматься, что в ином случае может быть малость лучше чутка иначе - вместо начала добавлять в ПУТЬ в конце или наоборот
изучить команду "." bash или аналог, чтобы больше одной строки в разные места не добавлять
копипастить от души всеми способами
Шелл bash, образец Julia
На чём вопрос мог бы быть исчерпан...
Termux всё ещё ставится?
Легко найти рейтинги языков: https://www.darly.solutions/blog/the-most-popular-programming-languages-in-2021
Обратите внимание на 2021 в URL, это у кого-то изощрённое чувство юмора. И ссылочка на IEEE Spectrum должна бы, скорее, быть https://spectrum.ieee.org/top-programming-languages-2025 да и сводную страницу https://plrank.com/ можно было бы упомянуть.
Первое, что бросается в глаза - фактически тождественность TIOBE и PYPL. Оба построены на поисковых запросах, раз одинаковые - либо оба правильные, либо оба неправильные. Первое много вероятнее.
Итак, что-то действительно произошло с поисковыми запросами, причём лёгкое падение Python совершенно не впечатляет по сравнению с обрушением Go. Последнее точно, а первое - только скорее всего за малостью эффекта, не наблюдается по другим индексам. То есть дело именно в запросах, а не в каких-то изменениях в использовании языков. Да, первой в голову приходит мысль что влияют беседы с ИИ, на одних языках они удачнее чем на других, но данных чтобы её подтвердить или опровергнуть я не вижу.
Маленькой тучкой на горизонте идеи, что ничего не происходит вообще, мне кажется то, что по Stackoverflow язык Lua хотят учить больше, чем Go. Тут первой в голову приходит мысль об изменении надежд вкатунов...
На JavaScript тоже писали и как норма воспринималось не первое место Python, а то, что первое место за JavaScript или Python, смотря как посмотреть.
Как я пытался описать выше - нет, не заметно. Приоритеты при переходе к падению рынков точно меняются, но по популярности языков это ещё не особо читается. Я бы сказал, что если на неё что и влияет, то (пока) только в среде выходящих на рынок труда.
С удобством никто и никогда не заморачивался, удобство - это про Julia или Lua, а там без перемен. Низкий порог входа в Python... он сейчас с нами в комнате? Если и говорить о подобном, то о времени затрачиваемом на получение решения без фиксации на скорости и ресурсах. И то, это без фиксации - далеко не любые вопросы к производительности, на те вопросы давно даны ответы, начиная с Cython.
А что вайб кодинг позволяет получить поганый прототип на любом языке так же быстро, как на Python - в этом что-то есть.