Саме так, назва не дуже вдала. Багато хто дійсно думає, що це саме про візуалізацію обчислень. Заголовок статті, наприклад, це цитата колеги з Матеріалайза (тобто теж алгоритміста-геометра), якому я розказав про те, чим ми займаємося на кафедрі. І я досі не певен, що то був жарт.

Кажуть, що інженер, який проектував лондонську каналізацію (ще у 19 сторіччі) збільшив в проекті розмір труб настільки, що його запасу по площі потоку вистачило до наших днів. www.londonmuseum.org.uk/...​ondons-first-super-sewer Нечуваний на той час крок, який зекономив лондонцям неймовірну кількість грошей за півтора сторіччя. Якби замість нього каналізацію проектував ШІ, то в нього вийшла б якась копія каналізації давньоримської. Бо в корпусі на той час нічого іншого в Британії просто не було.

Цікавий фактоїд, перша масштабна перебудова лондонської каналізації із вікторіанських часів закінчилась... саме в цьому році. https://www.tideway.london/news/press-releases/2025/february/london-s-super-sewer-now-fully-connected-promising-a-greener-healthier-river-thames/

Жодна професія, якщо вона потребує навичок, знань і умінь, яких немає у 99% людей, які складають корпус для тренування моделі не може бути замінена моделлю.

А от посередність і непрофесіоналізм — запросто.

Це передній край, і моделі, які роблять моделі, все ще стають краще. Станом на сьогодні, Meshy справляється мабуть найвдаліше. www.unite.ai/...​-ai-3d-object-generators

Але це, знов таки, моделі, які усереднюють корпус. Тобто вони цілком годяться для ігор і рендерінгу якоїсь реклами, наприклад. А от, наприклад, в техніці потрібні моделі, які мають певні фізичні, або хоча б геометричні характеристики. Моделі про це нічого не знають і ані фізики, ані математики не враховують.

Окремі методи ШІ застосовуються і в техніці, тут, наприклад, мінімальна поверхня для забезпечення оптимального теплообміну будуєься нейросіткою: arxiv.org/abs/2504.02830 Але, як на мене, це радше данина моді. Там цілком можна було застосувати якийсь оптимізатор по типу PSO, і отримати результат не гірше.

А от якби ви пролистали статтю уважніше, то побачили, що там є посилання на дослідження, яке чітко вказує, що лінгвістичні моделі справляються із креативними задачами краще за 99% людей. pmc.ncbi.nlm.nih.gov/articles/PMC10858891

Треба бути кращим за 99%. У будь-якій професії.

Ну хіба що в тому ж сенсі, що і «Война і мір» написана французською.

.../gcc-12.2.0$ find -iname «*.c» | wc -l
134199

.../gcc-12.2.0$ find -iname «*.cc» | wc -l
19045

.../gcc-12.2.0$ find -iname «*.cpp» | wc -l
510

І це з тестсьютами.

Радше за все, навіть не GPU. GPGPU — це такий трохи химерний концепт, який вже років двадцять як просуває NVidia щоб забрати собі ринок акселераторів ще до того, як він сформувався.

TPU Гугла трохи ближчий для того, щоб бути виключно пічкою для ML моделек. Але передній край — це фотонні обчислення. Їх серьозно досліджували у 80ті, але там принципове обмеження технології — бранчінг. Його немає. Що серьозний мінус для ручного програмування, але зовсім не так страшно для масово-паралельних тензорних обчислень.

*думають що знають. Це проблема досвіду: знання застарівають і не встигають за розвитком технологій, а впевненість лишається на все життя.

Only a ginger can call another ginger ginger.

А це аргумент навіть не тридцятирічної давнини, а взагалі допромислової епохи. Це для того щоб зробити швидке лоша треба швидкого коня і швидку кобилу. А для того щоб зробити швидкий автомобіль чи літак, потрібні машини які геть не схожі на автомобілі чи літаки.

Clang (саме Сі) написаний на С++. GCC++ (C++) написаний на Сі. Чи це якось характерізує імплементації або тим більше мови? Аж ніяк.

А от CompCert © написаний на Coq (Gallina), який написаний на OCaml. Це якось характерізує Сі, Gallina чи OCaml з точки зору швидкодії чи навіть «зручності» для імплементації компіляторів? Знов ні. Але завдяки Coq, CompCert має цікаву властивість, якої було б непросто досягнути іншим інструментом. Це формальна веріфікація. Це перший і єдиний компілятор Сі, який, з точністю до специфікації, звісно, не міскомпілює.

А мораль тут така, не тримайтесь за упередження, обирайте інструмент під задачу — і все у вас вийде.

Spiral, Numba, ForwardCom. Не Rust.

Зауваження справедливе. «Час програмістів дорожчий за час виконання» — це класична мантра з дев’яностих, на якій виросло вже не одно покоління менеджерів. Але як тільки час виконання перейшов із категорії прихованих витрат та ще і чужих (як це було із коробковим софтом в тих самих дев’яностих) у категорію явних витрат і своїх, виявилось, що мантра працює... м’яко кажучи не завжди.

Ніщо так не міняє світогляд, як рахунок за AWS.

В програмуванні немає «абстракції» це слово украв із математики алгебраїст Стєпанов. Є автоматизація. Якщо не можете написати вектор на асемблері самостійно, покличте компілятор, він напише його за вас. Це не абстракція, це класична автоматизація. Машина робить роботу за людину.

Абстракція є в математиці. В алгебрі. Тому парадоксально, а насправді ні, що SymPy (або будь яка система комп’ютерної алгебри) справляється з роботою плюсів — перетворення абстрактних рівнянь на конкретний код — краще за плюси. Через це С++ вже помер. Питання лише, якою мірою.

Або не приходить. Або приходить коли ніхто не чекає.

З пам’яттю взагалі непросто. Наприклад, в Review Guidelines on Software Languages for Use in Nuclear Power Plant Safety Systems (www.nrc.gov/...​ontract/cr6463/index.html) перше правило роботи з динамічною пам’яттю — не використовувати динамічну пам’ять взагалі.

Раст сам по собі дуже крутий. Якщо глянути на результати щорічного опитування С++ програмістів, а саме на частину «що вас фруструє» (isocpp.org/...​cpp-developer-survey-lite), то не важко помітити, що Раст лікує більшість зазначених там проблем.

Але це все ще робота над помилками. Це, в термінах Форда, faster whorses. Це хороший і правильний крок від минулого, але ще не крок у майбутнє.

Мені шкода що мої факти ображають ваші переконання.

Да, естественно.

SICP перевели пару лет назад на русский.