Яка мова «програмування» вам імпонує найбільше та чому?

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

Отже, не буду тягти котика за тестікули, мій персональний топ це... xQuery. Я познайомився з нею десь років 10 тому. Емоції були від «Мати Василева!» до «Срали-мазали...». Але, з досвідом, все стало на свої місця та задоволення стало неймовірним.

Це в жодному разі не high-performance мова програмування, інтерпретатори доволі повільні, навіть ті, які написані на C/C++. Інтерпретаторів, які можуть виконувати xQuery код не так багато, основним з них є BaseX, далі Oracle DBMS, далі Zorba, але все це вже трохи застаріле та не підтримується. Може є ще щось, але воно все мертве.

Наскільки потужний xQuery? Саме ця мова програмування дозволила моїй команді написати систему для менеджменту кредитних історій в бюро кредитних історій за 4 тижні чистого часу.

То чому саме xQuery?

Pros:

  1. Немає ООП, бо це функціональна мова.
  2. Є модульна система як в JS, але тут вона ще й з неймспейсами.
  3. Параметри функцій, за бажанням, можна зробити типізованими, так само як й відповідь функції.
  4. Всі операнди є або функціями, або поводяться як фукнції. Наприклад, можна привласнити змінній результат switch або if.
  5. Купа фукнцій за замовчуванням, які дозволяють багато чого робити з коробки.
  6. Можна використовувати як темплейт-систему, бо результат роботи фукнції може бути як послідовність різних елементів, так й XML-документ, або JSON.
  7. xPath підтримується нативно, не треба писати багато зайвого коду, щоб його використовувати
  8. DOM під капотом

Cons:

  1. Вимагає багато памʼяті для виконання, бо структури даних є immutable та вимагають клонування для модифікацій чи обробки.
  2. Немає ООП ;)
  3. Трохи багатослівна в попередніх версіях, але з 4.0 додали купу синтаксичного цукру та нових конструкцій, які роблять код простішим.
  4. Призначена для обробки даних, драйвери на ній не напишеш.

А що є вашою любовʼю?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Bash. Якісному вивченню і навіть запам’ятовуванню піддаватися не хоче, але при цьому якось виходить на ньому реалізовувати всі скриптові хотілки, навіть коли раціонально було б взяти пітон.

Мені cподобалися/запамяталися мови:
— ассемблер (я в дитинстві любила в’язати і мені ото ковиряння з бітами та байтами дуже нагадувало в’язання, не знаю чому)
— prolog — ми на ньому робили дуже прикольні програми, типу програма яка замість доктора скаже тобі твій діагноз на основі твоїх відповідей, це прям як AI але **надцять років тому
— C/C++ прикольні були, бо ми на них для навчання ігри робили (хрестики-нолики, шашки, ще всяку єрунду)
— GPSS тому що він для рішення неординарних задач (емуляція реальних систем таких як конвейер на виробництві або потік пасажирів в аеропорту)

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

«Всі мови програмування однакові» (якщо вони «Тюрінг компліт»), і на кожен тип цвяхів — свій молоток...

Сучасний Пайтон з його тайп анотейшенами — улюблена тула (там, де йому вистачає швидкодії...))

C++ то ненависть (бо «комітет» то лебідь, рак та щука люди що писали ще на MFC) та любов (адже, насправді той C++ можна «транформувати», обравши інший сабсет під свої задачі, де улюблений сабсет, то «C з класами та ламбдою, й темплейтами замість макросів»).
(майбутня любов, то, напевно ж, Rust))

Але от щоб саме «мова програмування» і вона була прекрасна, саме як мова програмування, це... Lua!
Легко вчити (якщо маєш книжку PIL)) та дуже легко заембедити в свою аплікуху! Особливо якщо порівняти з абсолютним безумством процесу білда деяких роздутих «знаменитих» ЖС енжінів від «великих корпорацій» (та з їх огидним, божевільним API для «ембеддінга», з усіма отими «ізолейтами», «контекстами», та рештою переускладненого сміття, що дуже потрібно «великій корпорації», але не для моїх юзкейсів))!

Корутини в Lua дозволяють природньо уникнути цирку з «заразою» від async/await, як то відбувається в JS та Python (в Lua coroutine.yield може трапитися де завгодно у вкладених викликах без «інфікування» усіх вкладених функцій хворобою async/await! Корутини в Lua можуть робити yield та resume будь-де, що веде до більш гнучкого асинхронного коду)

«Протокол ітерації» в Луа простий і легко співпрацює з coroutine.wrap (замість винайдення окремої спеціальної «фічі» у вигляді «генераторів» на додачу до потворних «async/await» як то є заведено в JS/Python)...

Краще б в бравзері була Луа замість ЖС!

Я тоже достаточно долгое время использую Lua, уже больше 10 лет. Эмбедить его можно легко и без проблем, с предоставлением своего API хостовому коду. Для написания кода есть линтеры под VSCode, ещё ZeroBrane, где можно stand-alone код запускать. Lua не поддерживает многопоточность, как и js и python, но зато можно легко запускать копии виртуальных машин, что я и делаю. В эти копии можно передавать расшаренные данные, которые могут синхронизироваться обычным способом, через мьютексы. В целом это самый удобный язык для скриптования в отличие от всех остальных.

Найулюбленіша LUA Прям ООП здорової людини.

Да не пахло в LUA оопой никогда.

А я такого ніколи не стверджував, я на LUA не писав, не пишу, й наврядчи вже буду писати чи вивчати, немає на це часу.

Bash. Якісному вивченню і навіть запам’ятовуванню піддаватися не хоче, але при цьому якось виходить на ньому реалізовувати всі скриптові хотілки, навіть коли раціонально було б взяти пітон.

До сих пор в дрожь бросает, когда вижу эти case/esac.

Если сравнивать допустим с виндовым batch, то bash безусловно крут. Ну а под винду скрипты можно выподнять под git-bash, что очень круто и удобно.

1C, бо навіть на 11-му році війни і 3-му році вторгнення в Україні ще потрібні спеціалісти з цієї мови. Мабуть є щось в ній таке магічне

Може тому, що там пишуть все запоребриканською?

Правда! І «бітрікс» туди саме... та зараза пролізла всюди, не лише в Україні, ще й в світі багато де...

А з українських проектів, щоб замінити «запоребрикову» для програмування знаємо... хм, хіба «Мавка» (так і називається))

C++
Тому що складна і потужна
(але майже нічого на ній не пишу)

Яка мова «програмування» вам імпонує найбільше та чому?

Malbolge, бо такий же уйобіщний як моє життя

:D Недалеко ця мова від Brainfuck пішла...

ну якщо зайшла мова про «мови» — моя Laravel :)

Там же наче Delphi зараз це RadStudio, а там підвезли усе і web і mobile

ActionScript

Друга чи третя версія?

Третя, плюс Flex та AIR

Ні, я третю не любив за те, що вони стали більш «канонічною», але при цьому кількість коду зросла. Можливо, саме це й вбило ActionScript.

А ще Джобс посприяв.

Джобс був одним з факторів. Там більше спрацював факт, що флеш був капець яким дірявим, а Адобі не сильно булками любило шорхати, щоб своєвчасно патчити вразливості. Тому накопичилося незадоволення, яке потім перетворилося на бойкот.

SQL (вкл диалекты) за кажущуюся простоту и непотопляемость
C# за элегантность
Pascal — потому что первый
Python — вообще ни за что, г0вно и все на на нем сидят :)

SQL в мене викликає дику алергію. :D В простому вигляді воно ще більш-менш, але, як тільки складність запиту росте, читабельність та розуміння того, що там коїться, падає ледь не в квадратичній прогресії. В PL/SQL Оракл намагалися виправити ситуацію та вона там дійсно краща, але осад залишився...

Понять логику это пол беды, понять во что (план) запрос оптимизируется еще половина.
Поэтому и кажущуюся простота. Действительно не для всех

Кстати я был фанатом xquery и xslt когда писал проект с xml и трансформацией N терабайтов документов.
Ну то такое себе;)

Тільки не xslt! Це гидка качечка в світі XML. На простих прикладах працює може й чудово, але коли складність документів зростає, одразу зʼявляються випадки, коли ти не можеш відрізнити одну структуру від іншої, а їх треба трансформувати окремо одну від одної. Приходилося спочатку робити перейменування тегів перед трансформацією, щоб далі все працювало як потрібно. Тому ця технологія не прижилася ніде. Хоча ідея непогана. Академічно вивчити можна, як приклад, але не користуватися.

Остання буква в абревіатурі SQL як раз про мову ;)

Так, це гарно, ніхто ж не сперечається! Хоча ви можете написати власний DSL та робити аналогічне за 1 рядок запиту :D

Если безбрежное море сахара в C# вы называете элегантностью, то таки да, C# элегантен.

Все познается в сравнении.

10    PRINT "Hello ZX"
20    GO TO 10
от чьорд, чому я зараз реву як поранений гіббон???.. ой все...

Сльози на очах також... Це була ціла епоха... В мене навіть книжка була про бейсік ZX-спектрума.. Тільки от самого компа не було.

так брате, все так..
я теж у 80-х почав вивчати програмування без комп’ютера..
але у моєму випадку то була книжка з бібліотеки батьків (ну звісно ж, вони були радянські програмісти) щодо Бейсіку для IBM 360..

Свою першу програму я написав на бейсику на УКНЦ («Електроніка МС 0511»), вона робила геніальну на той момент річ — малювала коло десь на екрані. :D

Ха-ха. Теж саме. До сих пір пам’ятаю як УКНЦ на Бейсику-інтерпритатору малює кола великого радіусу

Ревіти треба як ошпарений динозавр. Бо якось BASI-ком запахло та ДВК-3М і Істра-1030 На спекртумі не те пальто, там в Sabatur.

Еще первая редакция K&R C в твердой темно-синей обложке — любовь к С/С++ на всю жизнь.

можна хоч один приклад де пітон найкращий?) по-моєму він костильно-кривий вкрай повільний будь-де))

Мови, які мені зламали мозок в свій час (в хорошому сенсі, це було дуже цікаво вивчати):
— Java/C# - (після C++) — вау не треба робити delete
— Prolog/Scala/Haskel — чо за хрінь, де змінні, де цикли?
— Rust — код з можливим race condition не компілюється? Ох**ть
— Go — і цей генератор бойлерплейта комусь подобається? Дивні люди

Rust — був моїм фаворитом, поки не спробував на ньому сервер писати. Мороки дофіга з цим borrow checker, а профіту майже немає — по швидкості так само як й в Java якщо брати мікрофреймворк, памʼять — ну так, в 10 раз економніше, але толку, оперативка рідко ботлнек. Але дизайн самої мови й кор ліб — просто офігєнний.

Тому довго любив Kotlin за його баланс у всьому, але останнім часом цей баланс як мені здається втрачається, занадто багато вже синтаксичного цукру + є тенденція до використання чисто котлін ліб, замість Java ліб — не фанат цього.

Зараз мені більше всього імпонує Java 22 + Lombok + Nullable анотації (так зробив собі котлін з джави). Знаю що багато хто хейтить анотації, а я люблю анотації ) Я не сприймаю це як магію, для мене це щось типу паттерна декоратор/делегат/проксі тільки в красивій обгортці.

Щодо нестачі RAM — як вузьке місце, сильно не погоджуюсь якраз це і є одною з головних проблем CRUD — бекендів, одразу після не ефективною роботою з базою данних. В більшості бекендів мінімум складних алгоритмів — просто звичайний CRUD. Тим не менше коли вони є, то починаються танці з бубном. У випадку як з Node так і Java — зазвичай не вистачає пам’яті. Скажімо усі хочуть брати дешеві інстанси в хмарах із двома гігабайтами пам’яті. З досвіду Java себе нормально почуває під навантаженням мінімум із 6 G RAM інакше постійно займається GC (а раніше ще і падала з OutOfMemory з фрагментацією). Node при великому навантаженні — хоче щонайменші 8G.
Для десктопів розробників з двома моніторами, відедокартами, теробайтними накопичувачами і т.д. — це зазвичай усе не проблема. Але щоб виділити такі інстанси на хостінгах та клаудах — це з рештою купа бабла. І на 2 GB воно зазвичай виходить що не масштабується. Взагалі щоби бекенд масштабувався, це далеко не так просто зробити як здається. Більшість програмістів не думають в такому руслі, від початку.
Звісно є купа методів зробити краще без портування на Rust, C++ і т.д. Наприклад змінити протоколи з текстових на бінарні — типу : ASN1, Avro чи Protocol Buffers — може знизити використання пам’яті від двох до двадцяти разів, а CPU до порядків. Серіаціалізація і десеріалізація данних в строкову форму і назад насправді дорога справа. Алгоритми типу attio та itoa використовують дорогі операції ділення навіть коли вони оптимізовані методами LUT і т.п. А парсинг тих же JSON і тим більше XML — доволі складна процедура, з купою операцій.
Так само можна прискорити оптимізувавши тільки складні алгоритми в native ти приєднати до Java чи до Node.

Java 22 + Lombok + Nullable анотації (так зробив собі котлін з джави).
Знаю що багато хто хейтить анотації, а я люблю анотації )

З досвідом це пройде.
Або ні.

Це дуже велика перевага мови, з контрактним програмуванням як парадигмою. Зокрема надає ексклюзивні можливості до aspect, при чому як під час роботи програми Runtime так і під час compile time через Annotation preprocessor.
В інших технологіях, крім C# (в якому насправді усе ще поліпшено) тому і нема повних аналогів : Spring, Hibernate і т.п. — які прискорюють написання базового бекенду в десятки разів.
З іншого боку зараз такий код стали генерувати за допомогою AI.

З досвідом як раз почав навпаки, любити анотації. Тому що спочатку це купа магії, ніхєра не зрозуміло, й звісно тягне до простого коду. А коли починаєш дійсно глибоко розибратись в фреймворках, розумієш всю логіку за ними, то розумієш наскільки це зручно й скільки бойлерплейта прибирає. Принаймні зараз я більше субʼєктивно не бачу різниці між http.get("/api", (req, res) -> ...) та @Get("api") — для мене це один й то ж самий код, просто з анотаціями воно більше відокремлено й краще читається.

Але так у анотацій два мінуси:
— Відокремелення логіки яка викликається по анотації (вирішаємо — якщо тримати код який викликається рядом з анотацією — тоді різниці немає особливо, що так клікаєш по методу й бачиш код, що по анотації).
— Немає autocomplete, написав http. й бачиш усі методи які там є, з анотаціями таке не катить. (Теж теоритично вирішаємо через nested classes але рідко таке бачив на практиці)

Цікаво що вони по суті продовження — макросів та метапрограмування

А чому продовження — це і є інструмент метапрограмування, constant time execution в стилі С++ в Java просто нема, зате є compile time аннотації і препроцессори, та рантайм які можна залучати з рефлексією, ще одним потужним інструментом метапрограмування.

— Rust — код з можливим race condition не компілюється? Ох**ть

Wrong. Код с race condition компилируется. Не компилируется код с data race.

Цікаво, не знав що це два окреми терміни, так, мав на увазі саме data race

Не окремі, data race це особливий випадок race condition. Якщо один потік інкрементує змінну, а других подвоює, то результат буде залежати від перетинання потоків, це race condition, але не data condition. Проте найбільший головний біль завдають саме data condition.

найбільший головний біль завдають саме data condition.

Як на мене це — data condition же в зовнішніх функціях. Якщо піти не далеко, то скажімо HeapAlloc/HeapFree learn.microsoft.com/...​papi/nf-heapapi-heapalloc Якось портував алгоритм написаний під Linux. В мене були аллокації активні, маленьких об’єктів з 30+ потоків, постійно вилітало на вінді з помилкою захисту пам’яті.
Під час дебагу змінив new/delete вони же malloc, free на прямі системні виклики HeapAlloc/HeapFree. Результат той самий (бо воно в CRT просто аліас). З рештою замінив розподілювач пам’яті на jemalloc — і усе стало добре. Не впевнений, що Rust з цим би допоміг принципово.

HeapAlloc/HeapFree

эти функции реализованы еще в 90х, в них багов нету то что это одни их самых часто вызываемых функций, причем сама винда их тоже постоянно использует.. Есть баги только в пользовательских аппликухах.

У меня єсть программа тестовая, которая, которая с гарантией генерирует защиту памяти на 32 потоках.
Сам смысл простой, выделяєм блок пам’яти, заполняем его чем-то, чтобы компилчтор не выбросил код при оптимизации, потом освобождаем . И С mscrt или прямыми API вызовами HeapAlloc/HeapFeee — получите ошибку, общая зашита пам’яти, когда запустите такой простий тест в 32 потока.
Кстати эту проблему давно выявили Mozilla и заметили распределитель памяти на Jemalloc (там внутри только VirtualAlloc а вся синхронизация сделана разными методами, в основном атомарными не блокирующими алгоритмами, где мютексы захватываются а исключительных случаях), а потом и на Rust стали писать новый движок на замену Gecko (старый написан вообще на С++ 98 -, С кучей макросов без поддержки пространств имён и т.д.)

Прошу пана, огласітє вєсь спісак, а можна «Minimal, Reproducible Example», тоді це буде або чудові поcиденьки в пошуках рейскондішена, або ж чудовий аргумент в розмовах за кастомний алокатор))

Реалізація HeapAlloc живе в юзер спейсі (окрім власне виклику VirtualAlloc), отож, теоретично можна навіть додебагати до «а що ж там нетак»...

Власне я погоджуюся з добродієм «юнит тест», в тому, що HeapAlloc/HeapFree вже достатньо «вилизали» за ці всі роки існування, тому найімовірніше «тут щось нете»... або якась «дуже специфічка вінда», що «живе в контейнері», чи взагалі wine, можливо упіймано якийсь невдалий момент між апдейтами вінди...

Іншими словами «таку бажище» мали б віднайти та зарепортити «вже давним давно», й вона легко знаходилася б гуглом...

Ожидания:

эти функции реализованы еще в 90х, в них багов нету то что это одни их самых часто вызываемых функций, причем сама винда их тоже постоянно использует.. Есть баги только в пользовательских аппликухах.

Реальность:

CVE-2021-30636 — Media Tek LinkIt SDK versions prior to 4.6.1 is vulnerable to integer overflow in memory allocation calls pvPortCalloc(calloc) and pvPortRealloc(realloc).
CVE-2021-27431 — Arm CMSIS RTOS2 versions prior to 2.1.3 are vulnerable to integer wrap-around inosRtxMemoryAlloc (local malloc equivalent) function.
CVE-2021-27433 — Arm mbed-uallaoc memory library Version 1.3.0 is vulnerable to integer wrap-around in function mbed_krbs.
CVE-2021-27435 — Arm mbed product Version 6.3.0 is vulnerable to integer wrap-around in the malloc_wrapper function.
CVE-2021-27427 — RIOT OS Versions 2020.01.1 is vulnerable to integer wrap-around in its implementation of calloc function.
CVE-2021-22684 — Samsung Tizen RT RTOS version 3.0.GBB is vulnerable to integer wrap-around in functions_calloc and mm_zalloc.
CVE-2021-27439 — TencentOS-tiny Version 3.1.0 is vulnerable to integer wrap-around in function ’tos_mmheap_alloc incorrect calculation of effective memory allocation size.
CVE-2021-27425 — Cesanta Software Mongoose-OS v2.17.0 is vulnerable to integer wrap-around in function mm_malloc.
CVE-2021-26461 — Apache Nuttx OS Version 9.1.0 is vulnerable to integer wrap-around in functions malloc, realloc, and memalign.
CVE-2020-35198/CVE-2020-28895 — Wind River VxWorks several versions prior to 7.0 firmware is vulnerable to weaknesses found in the following functions: calloc(memLib), mmap/mmap64 (mmanLib), cacheDmaMalloc(cacheLib) and cacheArchDmaMalloc(cacheArchLib).
CVE-2021-31571/CVE-2021-31572 — Amazon FreeRTOS Version 10.4.1 is vulnerable to integer wrap-around in multiple memory management API functions (MemMang, Queue, StreamBuffer).
CVE-2021-27417 — eCosCentric eCosPro RTOS Versions 2.0.1 through 4.5.3 are vulnerable to integer wraparound in function calloc (an implementation of malloc).
CVE-2021-3420 — Redhat newlib versions prior to 4.0.0 are vulnerable to integer wrap-around in malloc and nano-malloc family routines (memalign, valloc, pvalloc, nano_memalign, nano_valloc, nano_pvalloc) due to insufficient checking in memory alignment logic.
CVE-2021-27411 — Micrium OS Versions 5.10.1 and prior are vulnerable to integer wrap-around in functions Mem_DynPoolCreate, Mem_DynPoolCreateHW and Mem_PoolCreate.
CVE-2021-26706 — Micrium uCOS-II and uCOS-III Versions 1.39.0 and prior are vulnerable to integer wrap-around in functions Mem_DynPoolCreate, Mem_DynPoolCreateHW, and Mem_PoolCreate.
CVE-2021-27421 — NXP MCUXpresso SDK versions prior to 2.8.2 are vulnerable to integer overflow in the SDK_Malloc function.
CVE-2021-22680 — NXP MQX Versions 5.1 and prior are vulnerable to integer overflow in mem_alloc, _lwmem_alloc, and _partition functions. This unverified memory assignment can lead to arbitrary memory allocation.
CVE-2021-27419 — uClibc-ng versions prior to 1.0.37 are vulnerable to integer wrap-around in functions malloc-simple. This improper memory assignment can lead to arbitrary memory allocation.
CVE-2021-27429 — Texas Instrument TI-RTOS returns a valid pointer to a small buffer on extremely large values. This can trigger an integer overflow vulnerability in ’HeapTrack_alloc’.
CVE-2021-22636 — Texas Instrument TI-RTOS returns a valid pointer to a small buffer on extremely large values, which can trigger an integer overflow vulnerability in ’malloc’.
CVE-2021-27504 — Texas Instrument devices running FREERTOS, malloc returns a valid pointer to a small buffer on extremely large values, which can trigger an integer overflow vulnerability in ’malloc’ for FreeRTOS.
CVE-2021-27502 — Texas Instrument TI-RTOS, when configured to use HeapMem heap(default), malloc returns a valid pointer to a small buffer on extremely large values, which can trigger an integer overflow vulnerability in ’HeapMem_allocUnprotected’.
Google Cloud IoT Device SDK Version 1.0.2 is vulnerable to heap overflow due to integer overflow in its implementation of calloc.

там где сішний код крутиться на 150-200 Мб джававовська приблуда розжирається до 20-25Гб і неясно що з цим робити. це при тому що всі ці гарбадж колетктори позиціонувалися як інструмент боротьби з меморі ліками))

Гараж котлектор не зможе ефективно боротися з замиканнями та активними лінками на обʼєкти, які розшарені з іншими. Тому меморі ліки — це скоріше проблема рахітектури, ніж технології ;)

Вы точно программировали на С++? С 2011-го new/delete делать не надо. Более того, это официально bad practice. Но и никто не запрещает конечно.

С 2011-го new/delete делать не надо. Более того, это официально bad practice.

А как ето?

std::unique_ptr/std::shared_ptr/boost::shared_ptr/std::make_unique/std::make_shared/boost::make_shared итд

З любою технологією подобається та яка вирішує проблему замість того щоби її створювати. Мов програмування яки не би мали тих чи інших вад, які створюють проблеми людство ще не винайшло. Тим не менше більшість мов так само і вирішують ті чи інші проблеми.

Наскільки потужний xQuery? Саме ця мова програмування дозволила моїй команді написати систему для менеджменту кредитних історій в бюро кредитних історій за 4 тижні чистого часу

Чисте троллоло, траплялись мені бюро кредитних історій. Там onboarding на проект з пару пару місяців, купа папірців, drug test, перевірки на несудимість, затвердження акунтів та доступів менеджерами і т.д. І мова програмування там остання справа, та здебільшого ентрепрайсна Java та діалекти : Groovy, Scala, Kotlin і т.д.

Там onboarding на проект з пару пару місяців, купа папірців, drug test, перевірки на несудимість, затвердження акунтів та доступів менеджерами і т.д.

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

Та це вже буде мільярд + 1 холівар. Це дійсно як обирати між маленьким молотком, кувалдою та великим молотом. Дивлячись для чого. В принципі і молотом при певній сноровці можна і підошву прибити до ботинків, а при супер сноровці чи додатковому інструменті так і усі цвяхи одразу. Та і у чоботяря три різних молотка — а у коваля цілий набір, під різні типи робіт.

Я запитував не для того, щоб холіварити. Ви можете любити одну мову програмування, я — іншу. Це абсолютно нормально. Але тут основне питання не яка мова, а за що. Я використовую xQuery раз на рік в кращому випадку та не пишу на ній постійно. Просто немає задач. Інструментарій тут ні до чого, розробник, на моє переконання, мусить володіти багатьма мовами програмування щоб мати розуміння, як правильно користуватися різними підходами в написанні коду.

Ну якщо ви наприклад чоботар — а я наприклад коваль, то я більше люблю кувалди та молоти — а ви ви більше спеціальний чоботораскій молоток. Чому — та тому, що свою роботу робити зручніше відповідним інструментом.

Так. Безаперечно. Хоча є випадки, коли вам просто треба розбити скло, то тут підійде будь-який інструмент.

Я багато працював з PHP, Python, Perl, Golang, Kotlin.
Кожна з них була улюбленою в різний час.

Так можна деградувати в одній конторі на якомусь ПХП тільки через те що платять. Мій товариш один на галері якраз так працює, його скілли треба тепер обмеженому колу компаній. Але сидить бо платять.

Для мене улюбленою мовою є Kotlin. Подобається лаконічність та мультиплатформенні можливості. Також дуже зручно працювати з корутінами та потоками.

Мені cподобалися/запамяталися мови:
— ассемблер (я в дитинстві любила в’язати і мені ото ковиряння з бітами та байтами дуже нагадувало в’язання, не знаю чому)
— prolog — ми на ньому робили дуже прикольні програми, типу програма яка замість доктора скаже тобі твій діагноз на основі твоїх відповідей, це прям як AI але **надцять років тому
— C/C++ прикольні були, бо ми на них для навчання ігри робили (хрестики-нолики, шашки, ще всяку єрунду)
— GPSS тому що він для рішення неординарних задач (емуляція реальних систем таких як конвейер на виробництві або потік пасажирів в аеропорту)

prolog — ми на ньому робили дуже прикольні програми, типу програма яка замість доктора скаже тобі твій діагноз на основі твоїх відповідей, це прям як AI але **надцять років тому

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

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

Я люблю С, бо я дивлюся на код і бачу асемблер))))

Це ви, мабуть, після -O0 бачите :)) Те, що далі, — там уже зовсім інший код :))

С++ так, на Сі зазвичай не дуже впливає.

reordering, inlining, vectorization, loops unroll, common expression extraction, unused code elimination, aliasing — це все працює на C так само, як і будь-де.

Ну, можливо, ви пишете асемблер у C-шному синтаксисі — тоді може й так :))

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

Я люблю С, бо я дивлюся на код і бачу асемблер))))

C перестал быть «high level assembly» еще в 90-х годах.

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

Когда вы пишете на C, вы пишете не для какого-то процессора, а для абстрактной машины, описаной в C Standard www.open-std.org/...​2/wg14/www/docs/n3096.pdf

В тому ж С++ все залежить від конкретної реалізації компілятора.

У C и С++ в современных реализациях один и тот же бекенд.

моя любов колись була Modula 2 🤗

нє, Оберон то вже було занадто багато ООП :)
от Модула 2 то була бімба після Турбо Паскаля

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

Часи були не ті, здійняти хайп було набагато важче ;-)
Також Borland не зробили під неї IDE аналогічний Turbo Pascal (а ось ця штука була дійсно проривною і вартою хайпу).

Тоді достатньо було опублікувати статтю про неї в якомусь виданні. А також книжку видати про неї.

НІ тоді достатньо було продати комп’ютер IBM, DEC або SUN на якому було перевстановлено FORTRAN та PL1. І йшла документація з експлуатації. Як тоді так і зараз яку технологію використовувати вирішують зовсім не інженери — а вищі бізнес посадовці. Крім того Internet взагалі не існувало, тобто ви не могли собі нагуглити мануал. Навіть на серчити не могли — треба було працювати із книгою.
Едсгер Дейкстра та Ніклаус Вірт — характерні тим, що вони європейці, а не американці. На конференції щодо Algol 68 організованим NATO — їх не стали слухати, коли вони запропонували те — що стало зватись з рештою Pascal. Pascal не був популярним в США до його експорту з Парижа фірмою Borland. Зате як і FN FAL став стандартом в Європі, зокрема Франції які робила власні комп’ютери. Головна супер фішка Turbo Pascal — була у винайдені IDE. На великих машинах того часу бал правили С та PL/1. А на малих — безперечним королем був BASIC.
В СРСР Borland Pascal став мега популярним. тому що по перше він був зокрема через ціну і його вдалось звести з Болгарії разом з комп’ютерами Robotron клонами PC і піратити. По друге це був розвиток Algol 60, який використовувала АК СРСР — остання машина серії Ельбрус uk.wikipedia.org/wiki/Ельбрус_(комп’ютер
Уся наша школа програмування по усій системі освіти СРСР, була започаткована саме АН. С — реально ще в нульові і 90-ті тотально не любили. Але Microsoft та Linux змінили тренд.

С — реально ще в нульові і 90-ті тотально не любили

А його нема за що любити і зараз, на ньому просто доводиться писати.

Це інструмент гострий як лезо — за допомогою якого можно створити як шедевр, так і криваве місиво.

Ти б бачив, яке місиво можна створити на PHP

Часи були не ті, здійняти хайп було набагато важче ;-)

А що зробили Bell Labs із UNIX та С ? Хоча той же Ніклаус Вірт — автор Modula 2 (професор помер в цьому році dou.ua/forums/topic/46942), відоміший світовий експерт з мов програмування та лауреат премії Тюрінга за це — розніс С великим переліком аргументів, як морально застарілий розвиток BCPL з купою атавізмів походженням від Algol 60. Які в ретроспективі і справді коштували сотні мільярдів доларів на усунення.

Напевно вам вже дуже давно не казали — що ви занадто молодий для цього :) Вас в ті часи як дитину могли водити на екскурсію — показати комп’ютер типу : Дніпро, Мир 2 або ЄС. На БЕСМ екскурсій не було, там працювали на космонавтику та академія наук.

Так Borland Tubrbo Pascal та Object Pascal — це якраз не чистий Pascal, це розширення з фішками від Modula 2 та OOP з Simula 67.

Здається, середа це дійсно маленька п’ятниця :)))))))

Cobol та Ada, все інше — новоділ і не переживе навіть найближчі 50 років, не кажучи вже про 100

Ви активно користуєтеся цими мовами в роботі?

Кожен день — legacy наше все :) Ви не повірите, але кожен день більше коду стає legacy, ніж пишеться нового :) І комусь це все підтримувати ще багато-багато років.

Не хочете поділитися, що саме вам подобається в обох мовах, та що їх робить найкращими на вашу думку?

Без припущень, без зайвих прикрас — просто працює так, як написано, вже 50 років і буде працювати ще стільки ж :)

Гарна відповідь! Без жартів. Це доволі важливо, коли ти хочеш будувати щось на віки. Сучасна розробка має доволі обмежений термін «придатності» проектів. Десять років для мобільної розробки, або в вебдеві, — це вже динозаврячє легасі. Хоча за 10 років нічого принципово нового не було зроблено... Обсмоктують вчергове добре забуте старе...

Ada 2022 — по факту такий самий новоділ. По суті сучасна мова програмування. Чи воно комусь треба ? Напевно щось супер старе усе ще підтримують, кажуть щось військово-морське.
Cobol — як і FORTRAN зараз дуже важко для чогось використати, тільки якийсь старий код під’єднати.

До речі, BLAS доволі популярна ліба. А ще цікавіше, що під FORTRAN активно пиляються компілятори, як Intel, так й nVidia. Я теж думав, що мова мертва, але це не так.

Зтогт що і переліку — BLAS інтерфейс давно портований на усе що можна. clBLAS, cuBLAS або boost BLAS наприклад.
Дісно речі як NASTRAN підтримують, та ті хто програмує математику скажімо AI — зараз використовують здебільшого Python. Массово нові бібліотеки та програми на FORTRAN не пишуть, лише юзають старі бібліотеки, в новому коді. Ніж їх переписувати — дешевше виявилось робити компілятори із FORTRAN під нові платформи. Хоча от ARM забили — тільки С.

Ох, закортіло мені зробити певну дексктопну программуліну. Стукнуло — а давай Rust, пішов що там і як, загулив найкраще GUI — GTK (доводилось використовувати). Пишу код — не працює Hello World!
О це реальний показник зрілості технології. На С/C++ і Python — береш приклад і він працює при чому як на Linux так і на Windows так і Mac.

Я використовував iced
Але радити не буду, досить специфічна річ

Java. Сінтаксис, перформанс, швидкість розвитку, екосистема

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

Для мене це Python та Rust. Мені подобається сінтаксис мов. Майже все, що мені треба зробити/автоматизувати я можу зробити.

Потрібно швидко затестити PoC — Python. Потрібно впихнути на маленьку та дешеву віртуалку чи Raspberry — Rust.

Ну, в мене Python вже трохи вийшов з категорії «швидкий PoC», адже UI на server-rendered HTML вже якось не дуже виглядає...

А бекенд на Node/TS вже не виглядає так страшно, як колись на чистому JS. І навіть підтримка різних бібліотек, не пов’язаних з ML, вже трохи починає підлагувати на Python...

Так, Python ніколи і не був для frontend, не дивлячись на всілякі Brython... Але все, що від мене віддається до http-client це, зазвичай json/xml які я можу подивитись у браузері ;) І дизайн мені там не потрібен взагалі ;)

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

ну тоді питання — що є PoC :)) PoC бекенда без фронтенда виглядає якось не дуже... :)

Світ IT значно ширший, ніж web/frontend/backend ;)

ну просто навіть якщо це якійсь хардкорний бекенд, все одно мати якусь админку/дашборд статусний зазвичай треба...
не все ж sqlем в базі чекати :))

Не завжди, інколи з вимог лише юзергайд по АРІ-ендпоїнтам.

PoC на те й PoC, щоб досліджувати, як краще/зручніше, а не щоб імплементувати юзергайд :)

Знову ж таки, до чого backend та база? ;)

Мені цілком дотатньо боту для повідомлень що щось сталося, ботів для обміну файлами між мобільним пристроєм та десктопом.

Утіліти для парсінгу файлів та генерації нових, як результат (github.com/eking-go/tfvarsauto наприклад)

Синхронізація файлів між пристроями...

Я ж кажу, світ IT значно ширший.

І, доречі, взаємодія через ботів та месенджери мені здається зручнішою, ніж через браузер... Мабуть тому, що взаємодія через консоль для мене теж зручніше, ніж GUI :D

Це тому, що ви собі не можете самі швидко зробити адмінку, таку, як вам дійсно треба :))) А кожен раз комусь пояснювати, що саме потрібно — то вже легше руками JSON написати :)

Ой фсьо! Адмінка в django робиться на раз-два ;)

Просто мені зручніше асінхронна взаємодія — щось сталося, система мене сповістила. Дивитись та перезавантажувати веб-сторінку, ну, таке...

Ну, якщо на Django за раз-два — то так, треба буде перезавантажувати :) А можна зробити нормально не на Django, і воно саме з’явиться та засвітиться жовтеньким/червоненьким :)

20 івентів зафайрилося, 19 зарезолвилося, 1 залишився — ви його ручками будете викреслювати? :) Або почнете раз у 5 хвилин ’current status’ відправляти? :))

Тоді вже краще на сторінку дивитись :)

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

Краще: щось сталося — прийшло повідомлення в чат. виправилося — теж прийшло. Що мені, і навіщо, оновлювати? ;)

Я чудово пам’ятаю Nagios — майже всі мої знайомі перейшли на повідомлення в месенджерах, бо не треба нічого тримати відкрити та перезавантажувати.

Але це суб’єктивно ;) Може комусь подобається дивитись на різнокольорові статуси на екрані ;)

І я ж не проти фронтенду як такого — просто особисто мені його писати не треба. А все, що треба — я можу написати на Python/Rust.

Ні, правда є в твоїх словах. Для тих задач, що в тебе, мессенджери є безальтернативним рішенням, особливо коли є пуш-нотифікації та віджети на мобільних пристроях.

Дивитись та перезавантажувати веб-сторінку, ну, таке...

Websocket’s або Server Side Events та полетіли. Якщо дуже сильно хочеться нотифікашек, то ще можна нативні браузерні приліпити, а також упоротися із оновленням фавіконки, щоб воно там блимало щось ще й там. Не сказав би, що це доволі просто зробити, бот може бути набагато простішим. Але якщо треба, то все реалізується.

PoC бекенда без фронтенда виглядає якось не дуже... :)

Welcome to R&D 🍿.

Ну, у багатих свої примхи :) Методи роботи великих компаній — це за межами розуміння :)
Ви, мабуть, той PoC ще 3 тижні плануєте і 2 тижні на ітерацію робите :) І двох продактів та делівері-менеджера годуєте :)

В великих компаніях свої переваги. Наприклад, я не можу, та й не буду, викатувати релізом не стабільний код. Так, це довго, але з іншого боку — я можу бути абсолютно спокійний на вихідних. Бо код навіть на тестове оточення не задеплоїться без повного пайплайну зі статичними перевірками, секюріті перевірками, фінансовими (в тому сенсі що не буде історії що проект за попередній місяць коштував 1к баксів, а за ці вихідні вже закінчився бюджет на 5к до кінця кварталу), на прод воно не потрапить до тестів на препроді і затверджень перевірк людей тестерів ;) Звісно, що помилки бувають. Але раз на рік-два відкотити на попередню версію в робочий час (бо викатується завжди и без виключень з достатнім часом на роботу в робочі години) — не проблема. Додому все одно йдеш вчасно і без нервів ;)

Тож так, у багатих свої примхі, але цілком в межах розуміння. ;) Сталі процеси — здорові нерви :D

Скукотіщщааа... :D :D :D

Я ж про це і кажу :)

у багатих свої примхи :)

Важко сказати, бо є різні застосування... Якщо брати загальне програмування, то в теорії Idris. Все ж таки, гетерогенна рефлексія мені здається більш практичною, ніж гомогенна в Agda, хоча для математики це може бути й важливим. Також я вважаю ці мови дуже перспективними з точки зору розвинення ШІ, бо математичні докази дозволяють знаходити помилки під час LLM-генерації коду, та керувати нею. А от на практиці це Haskell, бо cabal та ком’юніті, хоча Rust теж виглядає тут доволі цікаво.

Для більш низького програмування, то знову ж таки в теорії тут скоріше за усе Ada, з огляду на контрактно-орієнтоване програмування, яке дозволяє верифікувати код. Але на практиці альтернатив C небагато. А от Rust я тут зовсім не бачу, окрім як Redox, коли увесь код задизайнений під Rust.

Якщо брати скриптові мови, то це суцільна практика і тут Python.

У Frontend у мене немає ніякого досвіду, але починав би з Elm.

Дуже цікавий вибір! Особливо для себе відкрив Idris. Але сфера його застосування не сильно широка, чи я помиляюся?

Ну... де він застосовується чи може застосовуватися? В принципі за весь час я бачив одну вакансію, де у переліку були Idris, Agda, CoQ. Теоретично це загальна мова програмування, близька до Haskell, тому де може використовуватися він, там може й Idris. На практиці екосистема дуже вузька, все потрібно писати самому, тому це нереально.

Agda вже більше використовується математиками, наприклад є проект по формалізації математики через унівалентні основи саме на Agda.

Якщо дійсно треба верифікація (математичне доведення властивостей програми), то тут скоріше CoQ + OCalm більш практичний підхід.

arxiv.org/pdf/2201.10280

Дехто вважає це практичним результатом :)

«Теоретично правильний компілятор підмножини C» на CoQ + OCaml

Ходять чутки, що AWS S3 також «теоретично перевіряли» за допомогою формальної верифікації.

«Теоретично правильний компілятор підмножини C» на CoQ + OCaml

А напоркуа?

Гранти пиляти :) Що тут незрозумілого? :))

Можна ще Boeing’у продати :)

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

Ну, тут проблема може бути як з нейронками та іншими ML моделями — коли вони абсолютно правильно роблять саме те, що написано :) Але це не завжди те, що мало бути насправді :)

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

Якщо брати верифікацію, то з мого досвіду дуже важко неправильно сформулювати теорему та ще потім її довести, бо сам процес доведення це гарне review. Якщо ти сформулював вимогу неправильно, то зазвичай зрозумієш це по доказу.

Наприклад, я нас є функція сортування sort, функція підрахунку count та оптимання n-го элементу nth. Фактично нам треба довести дві теореми

сортування списку лишає ті самі елементи у нього

Theorem count_preserved_by_sort :
  forall (T : Type) (lst : list T) (x : T),
    count lst x = count (sort lst) x.

та що список відсортований

Theorem sorted_sort :
  forall (T : Type) (lst : list T) (i : nat),
    i > 0 and i < length lst ->
    nth (i - 1) (sort lst) < nth i (sort lst).

Після цього великого тестування в принципі й не треба. Але, припустимо, що ми помилилися, та в останній умові написали i >= 0. Звісно, що у нас просто не вийде довести твердження. Якщо буде i >  1, то протягом доказу будуть дуже часто виникати тривіальні refl, коли ти цього не очікуєш.

А якщо у списку лише один елемент? А якщо список з комплексних чисел? А якщо у списку є дублікати?

Те, що кількість не змінилася, не означає, що елементи ті ж самі :)

count_preserved_by_sort це як раз твердження, що елементи ті самі.

А якщо у списку лише один елемент?

Яка теорема спростується? sorted_sort стає тривіальною, бо умови її ніколи не виконаються. Не першу взагалі ніяк не впливає.

А якщо список з комплексних чисел?

Написано ж, forall (T : Type) (lst : list T), тобто в теоремі ми прямо кажемо, для будь-якого типу. Якщо наша реалізація не буде спрацьовувать для якогось типу, ти не зможеш довести теорему, треба буде додавати умову some_condition T -> ..., тобто якщо для типу можна довести some_condition, то тоді...

А якщо у списку є дублікати?

count_preserved_by_sort про це дбає. Наприклад, у нас lst = [2, 1, 2]. Відсортований sort lst = [1, 2, 2]. Далі

x=1, count lst 1 = count [2, 1, 2] 1 = 1, count (sort lst) = count [1, 2, 2] 1 = 1
x=2, count lst 2 = count [2, 1, 2] 2 = 2, count (sort lst) = count [1, 2, 2] 2 = 2

Для будь-яких інших y, y != x тривіальним чином count lst y = 0 та count (sort lst) y = 0.

Але це все ж таки трохи не функціональний підхід, там зазвичай буде визначений предикат is_permutation який перевіряє, чи є перший список перестановкою елементів другого (і навпаки вже теорема).

Про нейронки — вони екстремально експлуатують будь-які помилки у формулюванні задачі. І те ж саме з верифікацією — ви не можете формально довести, що ваша формальна теорема дійсно відповідає задачі.

Стандартна проблема — хто перевіряє перевіряючого? Тобто, ви, скоріш за все, не сформулюєте теорему, яка внутрішньо неправильна, але можете сформулювати теорему, яка не покриває всі юзкейси, і ви цього ніколи не дізнаєтесь.

але можете сформулювати теорему, яка не покриває всі юзкейси

Скоріше навпаки, ми заносимо змінну під квантор, але потім з’ясовується, що довести теорему неможливо через юзкейз, про який ми забули. Бо теореми зазвичай мають більш загальний вигляд.

Стандартна проблема — хто перевіряє перевіряючого?

Саме за це я не люблю тестування. :D Тести є кодом, в якому теж можуть бути помилки. Щоб визначити, чи немає в тесті помилок, треба написати інший тест, який є кодом, який треба перевірити на помилки. Треба нескінченна кількість тестів, але при цьому немає 100% гарантії, що вони щось тестують вірно. :D

def sort(l):
   return list(range(len(l)))

Сорри, але це класика :)
Вашу верификацию пройде.

Чому пройде? Перевіряємо:

Theorem count_preserved_by_sort :
  forall (T : Type) (lst : list T) (x : T),
    count lst x = count (sort lst) x.

Дивимося що у нас під квантором: forall (T : Type) (lst : list T) (x : T),

Вибираємо в якості T=int, у якості lst=[2], у якості элемента x=2.

Далі, дивимося що нам треба довести: count lst x = count (sort lst) x

Але це не так, бо просте обчислення для обраних значень дасть

count lst x = count [2] 2 = 1
count (sort lst) x = count [0] 2 = 0
0 = 1
fail

Теорему спростовано, ця реалізація не підійде.

Мені здається, що ваш співрозмовник вважає, що count просто рахує кількість елементі списку, і звідси усі непорозуміння.

Так, дякую, я вже тут давав посилання на цей проект.

Теоретично це загальна мова програмування, близька до Haskell, тому де може використовуватися він, там може й Idris.

Теж про це подумав.

На практиці екосистема дуже вузька, все потрібно писати самому, тому це нереально.

Можна використовувати з академічної точки зору. ;)

Підписатись на коментарі