0 1
Неска си мислех че количествените натрупвания действително водят до качествен скок нема нема сякаш от нищото. Джаваскриптчето го е направило последно през 1996-та за две седмици и чак десетина години по-късно се разбра кво се е случило. Преди тва батко му Цъ (без плюсовете).
Мисля че е възможно да сме некъде около тоя момент понастоящем въпреки че те у паралели са писали за летящи коли през 2000-та ама нещо не ги виждам много много да фъркат.
Та за езика си мислех по една линия че синтаксиса му ебава майката изначално обричайки го на obsolescence обаче пък е нещото което дава форма без която не може. Конундрум.
Отделно има куп неща дето се бият, примерно async е досада, тоя подразбиращия run to completion в рамките на функция модел на джаваскриптчето е едно от нещата дето неусетно го направиха голямо и концептуално сякаш така ни е по-сгодно да мислим в много домейни, стъпка едно, после две, етц.
Обаче пък в други случаи трябва асинхронност със съответната синтактична поддръжка.
Тоест вървим към това есенцията на езика да е в некъв вид форма позволяваща различни синтаксиси да се аплайват като вю-та отгоре на машина поддържаща множество парадигми. Примерно да мое да цъкнеш некво парче код да ти го форматне jquery чейн стайл, или пък друго да го форматне point free, друго, асинхронно, да го форматне без досадния синтактичен шум на ключовите думи/сигили, то реално есенцията отдолу не се губи но действително синтаксиса дава важна форма в КОНКРЕТЕН случай обаче за беда просто няма как хем да е достатъчно практичен хем достатъчно общ и гъвкав, дори езици като руби които се ползват умерено успешно за domain specific language стил програмиране се чупят в един момент и абстракцията е изнасилена.
Wasm изглежда като неква обещаваща поне примордиал база за такава сюжетна линия отначало с цар джаваскрипт като синтактичен мазаляк но постепенно и други докато в крайна сметка не изкристализира идеята че езикът посредством синтаксиса е просто вю към същността отдолу и има сгода това да е превключващо се, нещо като zoom in/out, от десет километра да са некви блокчета, после dsl парчета и натам доколкото е практично. Сичко това с директна поддръжка от езика, не адхок мазаляка сега.
Плюс дивелъп/диплой/съпорт цикъл сюжетна линия от самото начало, засега огромното ограничение (досега неизбежно) на езиците е да си измислят некъв свят с техни идеално или не чак толкова сферични тюринг магарета и после екосистемата дето е връзка с грозната зъбата реалност е въпросния адхок мазаляк, тоест, да се поставят ясно въпросите - кво всъщност са development time, run time, debugging, с всичките там произлизащи неща за типове, туулинг съпорт и екосистема от библиотеки/разширения. Как са свързани? Възможно ли е самият процес на билдване да се вкара в некъв вид проджект а защо не и езикова база знание, сега се изхвърля това, всеки билд цикъл е сам за себе си, ебати глупостта, дори рънването с ръчно цъкане ако следи машина отдолу и си записва в допълващ сорса файл формата на срещнатите обекти е далавера и може да се извлича полезна информация ако се пази и анализира.
Глей кви глупости си мисли човек като не му се налага да върти мотиката, ебахти :)
Във wasm няма нищо ново, това на практика е връщане към корените на Java и JVM.
Това с DSL-ите отдавна се говори, но на практика е трудно за реализация заради допълнителната инфраструктура (дебъгери, профайлъри, и т.н.) която е необходима. Аз лично смятам C++ за миш-маш от 4-5 DSL-а, а всички знаем какъв е резултата от това. Друг пример за смесица с DSL който се сещам в момента е OpenMP, също с неубедителен успех (според мен).
Според мен следващия език ще е този, който успее да интегрира съвременния хардуер (много processing elements, със/без unified memory) и го направи лесен за използване.
>Глей кви глупости си мисли човек като не му се налага да върти мотиката, ебахти :) Ами така е глупости са. Хващай се и почвай да предлагаш синтаксис, семантика, вид тестов редактор, среда за изпълнение и изобщо каквото се сетиш за някакъв твой нов език за програмиране. Така веднага ще може да се отговаря и да се получи приказката.
О да, това с хардуера го пропуснах, само тангенциално през async обаче всъщност е много по-дълбоко, затова с фиксиран синтаксис няма да стане, впрочем това е което май е направило Си без плюсовете силно - достатъчно добра абстракция ефективно утилизираща тогавашния хардуерен ландшафт.
Сега трябва нещо от рода да може да се съчетават примитиви които се гушват с начина на работа на хардуера отдолу но позволяват различни изгледи като синтаксис/визуализиране с идея за конкретни части да се ползва оптималното, не да плуваме срещу течението
Според мен най-трудния проблем с хардуера в момента е как да се направи език, който да позволява унифицирано изразяване на instruction-level parallelism (avx и подобни) и thread-level parallelism. GPU-тата с техния странен модел правят проблема още по-труден.
Прекалено много ентусиасти са оставили безславно костите си на тоя хълм тръгвайки със стахановски ентусиазъм :)
Цъкам бавно едно онлайн книжле на един образ замесен с Дарт - Crafting Interpreters, гледам сорса на Io и цъкам clojure и ramda за да попия функционално религиозен фанатизъм, срещу хидра требе да имаш кое друго като оръжие :)
едит: Деба, забравих едно важно - ползващо Цъ за комуникация
Всякакви опити за прогнозиране на езиците трябва да включват и обясняват как новият език ще решава два проблема:
1. Краят на ръста на производителност на хардуера. Реално значително по-бързи от сегашните компютри няма да има. Ще има ограничено нарастване на броя на ядрата, леки оптимизации тук и там. Но и това ще приключи скоро.
2. Увеличеният брой ядра не решава проблема – тук се намесва закона на Амдал който отрязва мечтите на тези, които си мислят че с хиляда ядра, компютрите ще станат хиляда пъти по-бързи.
Моят извод от тези факти е, че ще се наблюдава постепенно сваляне на нивото на езиците и постепенно масово завръщане към езици от нивото на C (без плюсовете) може да са обектни, функционални и каквито и да е, но трябва да осигуряват производителността на C.
Между другото, точно тази тенденция в момента ясно се забелязва.
А след това, ще се премине масово и към асемблер.
Това е относно езиците за програмиране. А специално за хардуера следва да се очаква масово внедряване на специализирани процесори, които да решават частни специфични проблеми по-бързо от софтуерните решения.
Тази тенденция също се наблюдава ясно.
1. Това зависи от дефиницията на "производителност". Каква е твоята?
2. Това, разбира се, зависи от проблема. Точно както казва закона на Амдал.
А това за асемблера са пълни бълнувания, особено като се има предвид че дори и в момента има поне 3-4 популярни архитектури с различни ISA.
Добре де, как се оправят с толкоз ядра при супер-компютрите?
Неска геедам в новите НВидиа 3090 вече не ползват двоична система. Някакви там междинни нива вкарват, не съм много наясно, ама с една линия кодират 2 бита.
За специализирания хардуер може и да си прав.
За Асемблера имаш много здраве. Дори да не е толко трудно, колкото на мен ми беше зор кат пишех на Асм. Като почнах на С за контролери и чак не повярвах че е истина и лукс.
Имаме предразсъдъци, с топ не мож ме накара да напиша тоя форум на Асм. На Жава - с удоволствие.
1. Аз говоря за производителността на компютрите - няма много дефиниции, първата производна на способността им да изпълняват алгоритми по времето.
Тоест, разбира се има различни дефиниции, но те са свързани и зависими помежду си, така че няма значение за коя говоря – всички те вече няма да се ускоряват в тези темпове с които бяхме свикнали. Никакъв експоненциален ръст е невъзможен по принцип.
2. Номерът е там обаче, че това означава, че паралелните изчисления могат да ускоряват само част от алгоритмите. Под голям въпрос е дали всеки алгоритъм има еквивалентен добре паралелезиращ се алгоритъм.
А ние обсъждаме производителността на универсални компютри. Тоест, такива, които могат да изпълняват всякакви алгоритми. И това е именно проблемът, който соча.
И да – супер компютрите могат да решават ефективно само и единствено задачи, които подлежат на паралелезация.
TУй е големия зор на directX 12. Новите игри се пишат да товарят всички ядра. WinZip примерно върви на 1 ядро, ама ти е се тая дали за минута ще намачка, или за 2. Където е критично си ползват многонишковост. Де го сега Ребата, той се занимава с подобни неща. Изтри му картинките и се фръцна завинаги.
Зависи от алгоритмите. Има срамно-паралелни алгоритми, които се изпълняват по-бързо на повече PEs. Производителността не зависи само от честотата, има там разни такива неща като memory wall и т.н. Има още много неща на хардуерно ниво, които могат да се изследват, и може би ще подобрят производителността. Един приятел, по типичен за него навик, вместо да работи по идеята си за стартъп, в момента си проектира език за програмиране, който да се компилира лесно до FPGA и да може да изрази естествената паралелност на елементите на такова ниво.
За щастие за ползвателите на суперкомпютри, физиката позволява лесно разпалеляване на алгоритмите. :)
Има една друга тангента - традиционно езиците за програмиране се напасват към съществуващата хардуерна реалност. Тва некъв природен закон ли е обаче?
Да, мечтите за лисп/джава и там къвто процесор не са реалност обаче неска нещата са малко по-други и може би е възможно да има поле за 'обратно' влияние диктуващо хардуерен дизайн пасващ на софтуера/езика който пък е напаснат към моделирането на там квото моделира
Бай музикантин не помни, ама ено време се продаваха хардуерни java платки. Както и хардуерен декодер да геедаш DVD. Монтирал съм такива.
Аз му викам свобода, това че теб нещо те обърква не означава, че е объркано. C++ е типичен пример за език, който дава познания в абсолютно всички аспекти на програмирането, обектно ориентирано, функционално, императивно, декларативно.
0 1