Вхід і реєстрація
Різне · 1 травня 2024, 18:39 4667
DOU Community

А ви девелопери чи «фреймворкери»? Обговорюємо!

На Dev.to розгорілась дискусія щодо використання фреймворків. Зокрема, йдеться про таке:

Ми живемо в епоху, коли розробники знають Tailwind, але не знають CSS. Їм важко написати простий SQL-запит, але вони знають, як використовувати ORM.

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

Вони не знають, як працює JavaScript, але намагаються вивчити Next.js і просять поради у старших.

Правда в тому, що це не інженери-програмісти; це «фреймворкери» або ті, хто вміє краще копіювати та вставляти.

Чи погоджуєтеся ви з таким поділом на інженерів-програмістів та «фреймворкерів»? І чи справді останні вміють лише «копіювати та вставляти»?

Теми: розробники, фреймворк
👍ПодобаєтьсяСподобалось3
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Сіньйор Ухилянт Девелопер 03.05.2024 17:03

Забули ще додати «програмісти» vs «формошльопи», «кодери» vs «інженери», ну і ще там є кілька цікавих варіантів

Відповісти
Підтримати
Artem Shevchenko C++/C# Software Engineer 03.05.2024 18:48

А ти з яких будеш? Бо щось лінкедін-профіль твій не відкривається.

Відповісти
Підтримати
Сіньйор Ухилянт Девелопер
Artem Shevchenko C++/C# Software Engineer 03.05.2024 11:36

Ой, зачекайте, це ще епоха ШІ обертів не набрала. Скоро прості «інженерні» задачі стануть доступними домогосподарям/кам. Та й насправді, гадаю, більшість сеньйорів на теренах цього сайту (зі мною включно, звісно) теж не знають і половини того, що знали їхні попередники 20-30 років тому, оскільки все базове вже давно написане за нас. Так і далі буде — поріг входження у професію знижуватиметься, як і потреба у кваліфікованих фахівцях — їх буде достатньо всього кілька на всю компанію.

Відповісти
Підтримати
Igor Kravchenko Software developer 04.05.2024 11:04

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

Відповісти
Підтримати
Artem Shevchenko
Dmitry 03.05.2024 10:01

Я не знаю как другие, я инженер, который старается помочь бизнесу решить проблемы.
И пользуюсь для этого доступными инструментами.
и должен понимать как оно работает.
То есть я должен как владеть инструментом так таковым и что твориться под капотом. Чтобы в нужный момент сделать правильный выбор

Відповісти
Підтримати
Sergiy Morenets Java evangelist 03.05.2024 09:55

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

Відповісти
Підтримати
Марк Сахарчук 03.05.2024 08:26

Девелопер це той що ЖК будує. А ми софтваре інженери.

Відповісти
Підтримати
Evgeny Sergeev 02.05.2024 23:45

Майбутнє за ’промт чатжпт лоу ноу кодерами’. Швидко. Якісно.Дешево.

Відповісти
Підтримати
Oleksandr Viter Senior Software Engineer в SoftServe 02.05.2024 14:51

Коли я ще працював інженером-програмістом на заводі, то справжні токарі і фрезерувальники, оті які крутили ручки на верстатах, вважали «несправжніми» тих токарів і фрезерувальників, які працювали на верстатах з ЧПУ, бо «та шо там робити — кнопку натиснув і програма сама за тебе все робить». Проте у цих от «несправжніх» продуктивність праці була в десятки разів вища, тобто для бізнесу вони були набагато корисніше ніж ті, хто був «ближче до заліза та дідівських трушних методів».

Стосовно ІТ, та й взагалі будь-якої інженерної діяльності, моя думка така: розбиратися на глибокому рівні як працюють твої робочі інструменти — це плюс. Але якщо для твоєї роботи вистачає неглибокого знання інструментів і всіх все влаштовує: бізнес влаштовує результат твоєї роботи, а тебе влаштовує оплата за неї, то хіба дійсно має значення, ти «справжній» чи «несправжній»?

Відповісти
Підтримати
Nikita Podgorbunskyi Software Engineer 02.05.2024 16:34
Проте у цих от «несправжніх» продуктивність праці була в десятки разів вища, тобто для бізнесу вони були набагато корисніше ніж ті, хто був "ближче до заліза та дідівських трушних методів".

Десь рік тому виникла потреба зробити виріб з металу і от не можу сказати що оці діди з старим станком де треба навик і прямі руки якось програвали тим хто те саме робив на станку з чпу. Остані зазвичай виходили навіть дорожче бо на станку з чпу хоч так хоч сяк, а платиш за час його роботи. В той час як "діди"(дуже умовно бо вони не були старішими за тих хто мав чпу) робили на обладнанні яке в рази дешевше, а отже його час і амортизація і близько не такі дорогі як чпу станок. Тому цікаво як ви так порахували що продуктивність аж в десятки разів вища? Головна перевага чпу це те що не треба людей так довго і нудно вчити та і безпека вища.

Відповісти
Підтримати
Oleksandr Viter
Nikita Podgorbunskyi Software Engineer 03.05.2024 12:00
ви порівнюєте штучний виріб із серійним виробництвом. є так званні постійні затрати, які будуть завжди (налаштування станка). а далі вони просто діляться на кількість виробленого виробу.

Насправді пофігу хоч 10 хоч 100, хоч 1000. Ціна після 10 вже мало міняється. Ви платите за час коли станок працює. Це не теорія це практика. Більш того за велику партію їм не дуже цікаво братися бо це ризик втратити якогось ще клієнта якому доведеться відмовити бо станок завантажений на 100%.

Крім того, продуктивність вище на ЧПУ, а також стабільність якості того, що виходить в кінці.

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

Відповісти
Підтримати
anonymous
K Vadym 03.05.2024 11:25

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

Хоча для такого випадку, як на мене, повністю досить якогось стандартного «движка»..., і не обов’язково модні технології юзати..., які ще і дорожчі з точки зору оплати розробника...
Бо власнику напевно пофіг, що там під капотом.

Відповісти
Підтримати
Nikita Podgorbunskyi
Олександр Мощенко 03.05.2024 12:17

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

Відповісти
Підтримати
K Vadym
K Vadym 03.05.2024 19:00

Тобто ГО сама обрала «нам потрібен сайт на технологіях «вкажіть-що-саме»?
Хм... Ну, можливо і таке буває 😁

Відповісти
Підтримати
Олександр Мощенко
Oleksandr Multimedia Content Maker в Marketing agency 31.05.2024 10:59
то справжні токарі і фрезерувальники, оті які крутили ручки на верстатах

на них у свій час так само дивились ковалі і ливарі й казали: «що там робити, крутиш ручки під лінійку і верстат все робить за тебе»

Відповісти
Підтримати
Oleksandr Viter
Slavik Savko 02.05.2024 12:49

Ну добре, добре — ще накину
Хто прогулював мікропроцесорну техніку лохи. Ви програмуєте на от тих ваших мовах не знаючи як зібрати тригер. Ха ха

Відповісти
Підтримати
Slavik Savko 02.05.2024 16:45

Наче був вибір тоді на місцевому радіоринку

Відповісти
Підтримати
anonymous
Vic Programmer 02.05.2024 19:08

BTW Схемотезніку і справді не погано було би знати для загального розвитку.
Хоча погоджусь скажімо щоб написати Frontend/Backend зовсім не обов’язково. Разом з тим при CRUD будівництві та формошлеперсві і мобайл ляп ляп величезна кількість повністю інших проблем, головною з яких я би назвав розуміння бізнес домену (предметної галузі задачі автоматизації). Скажімо банківська справа або торгівля і так далі. Найбільша проблема як на мене — це з’ясувати чого же вони там мляха хочуть, бо формалізація це повністю не їх, а ще постійні конфлікти інтересів. Не маючи досвіду в домені — це робити дуже важко, якщо взагалі можливо.

Відповісти
Підтримати
Slavik Savko
K Vadym 03.05.2024 11:28
Найбільша проблема як на мене — це з’ясувати чого же вони там мляха хочуть,

Це виясняти повинен frontend розробник? Crud розробник?
.... Можливо і так, але напевно тоді це «не правильний» якийсь бізнес 🤔

Відповісти
Підтримати
Vic
Vic Programmer 03.05.2024 16:12

Ну тут ХЗ, правильний чи не правильний вирішує з рештою дві речі — ринок та суспільство в лиці влади — є ряд бізнесів які заборонили та криміналізували чи стали жорстко релюгувати : азартні ігри, наркотичні речовини, проституція, алкоголь, табак тощо.
З технічного — виробництво ламп каналювання та плазменних телевізорів, фреонів, двигунів ДВС із великим рівнем викидів, бензин антидетонаційною присадкою тетраетилсвинець тощо.
От різні вчені та бізнес тренери типу Адізіса кажуть в будь якого бізнесу має бути мета, крім грошей — бо гроші це засіб досягнення мети, а не мета інакше хана будь якому бізнесу в далекій перспективі, він перетвориться на бюрократію та припинення інновацій, після чого не минуча втрата ринку через неконкурентоздатність.

Відповісти
Підтримати
K Vadym
K Vadym 03.05.2024 19:18

Та здається до того, що Ви написали типовий CRUD розробник відношення не має (?)

Відповісти
Підтримати
Vic
Vic Programmer 04.05.2024 01:30

Чимось має, хоче так аутстаф мав лише одну мету рости в кількості співробітників. Це призвело до того, що започаткувала освіта. Почалось з англійської мови і пішло доволі далеко. В цілому як недивно саме мінцифри та Федоров єдині хто поставили стратегічну ціль — продуктовий бізнес. Щоправда якось криво почали реалізовувати через дурні норми в дії сіті (хоча закон і ініціатива, якщо з нього прибрати дурню типу не конкуренції прибрати невідповідності конституції і т.п. і правильно реалізувати — насправді розумна штука).

Відповісти
Підтримати
K Vadym
Evgeny Sergeev 02.05.2024 12:20

Наступна провокаційна тема про ’богомерзькі’ лоу ноу код. Чи то про програмування чи про вирішення проблем бізнесу?

Відповісти
Підтримати
Beaver Green 02.05.2024 10:12

Проблема не у фреймвоках. Так чи інакше зараз більшість використовують фреймвоки і дуже рідко пишуть прямі SQL запити чи ванільний JavaScript. І це — цілком логічний прогрес.
Зараз навіть більше: можна бути взагалі no-code девелопером і усю потрібну поведінку зібрати з SAAS інструментів у клауді. І це не робить девелопера «формошльопом».
Біда в іншому: коли автори розробляють якийсь фреймвок — вони базують його на якихось інженерних ідеях. Наприклад React побудований саме так аби швидко оновлювати UI. Але це добре працює, тільки коли девелопер, який використовує фреймвок, прочитав хоч одну статтю від авторів, де вони пояснюють свою ідею — і зрозумів її! Інша історія що до усяких саморобних велосипедів документації просто не існує — але це переважно проблема Жаба-скрипт світу.
Якщо ж девелопер не розуміє ідеї і різниці фреймвоків — то кожен з них він використовує однаково — як молоток. Йому треба забити цвях — він бере що є під рукою і забиває.
На жаль, різниця тут у підході до вирішення задач, яке закладається з дитинства. Хтось гарно вчився у школі і звик до «наукового» підходу: записуємо що в нас є, записуємо що треба знайти, виписуємо формули, вирішуємо по-кроках. Інші вирішують проблеми коли вони вже перед очима: 10 хвилин до класу — у кого списати домашку? Чи щось не працює? — Стукни сильніше!

Відповісти
Підтримати
Мамка Жука 02.05.2024 10:27
дуже рідко пишуть прямі SQL запити

Ты ничего сложнее тудулиста без рав sql не напишешь. Будешь часами сидить в оптимизаторе запросов и индексы правильно расставлять.

Відповісти
Підтримати
Beaver Green
Beaver Green 02.05.2024 10:34
Будешь часами сидить в оптимизаторе запросов и индексы правильно расставлять.

Хіба що на легасі монолітах де усе пхали в одну величезну базу, а потім не знали що б з ній ще зробити аби пришвидшити і позбутися дедлоків.
Вже років 10 як винайшли NoSQL — а зараз взагалі мікро-сервіси і реляційні бази вже не у пріоритеті.

Відповісти
Підтримати
Мамка Жука
Олександр Мощенко 02.05.2024 10:39
реляційні бази вже не у пріоритеті.

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

Відповісти
Підтримати
Beaver Green
Java Bee 02.05.2024 10:45
реляційні бази вже не у пріоритеті.

вгадайте, як база у вашому браузері (це щоб далеко не ходити)

Відповісти
Підтримати
Beaver Green
Karina Kosenko PHP developer в IT Craft 03.05.2024 07:00

То був очевидний сарказм

Відповісти
Підтримати
Java Bee
Дмитро 02.05.2024 11:16

пришвидшити і позбутися дедлоків? треба проектувати з ер-моделі, ще мати досвід та мозок, розмір бази тут не до чого
дедлок можна на трьох записах показати :)

Відповісти
Підтримати
Beaver Green
Emma Orlova SDE 02.05.2024 17:13

NoSQL feels soo 2010, графові бази, монга яка забуває дані

Відповісти
Підтримати
Beaver Green
Java Bee 02.05.2024 10:40

Усе можна написати з ORM, без SQL.
Але не можна зрозуміти, що воно працює оптимально, і чому.
Наприклад, робить update, замість deleteAll / insertAll.

Будешь часами сидить в оптимизаторе запросов и индексы правильно расставлять.

з ORM — дуже навряд.

Відповісти
Підтримати
Мамка Жука
Serge Loboda Senior Software Developer в Access Softek, Inc. 02.05.2024 11:46

Що до ORM, то мені більш за все подобається гра «вгадай C# код по SQL запиту» коли DBA починають скаржитися на якісь проблемі з перфомансом у певних кейсах.

Відповісти
Підтримати
Java Bee
Дмитро 02.05.2024 11:19

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

Відповісти
Підтримати
Мамка Жука
Бодя павук 02.05.2024 07:41

візьмімо Jetpack Compose. я можу написати кастомний лейаут, створити аналог практично будь-якого композаблу, вбудованого у Compose, і одночасно оптимізувати його так, що піде навіть без перегрівів та статерів на девайсах а-ля Ulefone S7 1/8GB, я — мрія найбільш скажених дизайнерів, бо можу імплементувати будь-який UI

аЛе кОмПоЗ Це фРеЙмВоРк і тИ КоПіПаСтЕр

Відповісти
Підтримати
Oleksii Baranovskiy Android Developer в dotcode 02.05.2024 11:05

А можете порадити де почитати про оптимізацію в Jetpack Compose?

Відповісти
Підтримати
Бодя павук
Olena Sharovar Senior Software Engineer (Billing) in a startup 02.05.2024 04:59

Анекдот про байкерів тут вже розповіли? Той шо «А чого з вами знайомитися-то, ви тут кожен рік нові 😝» це про деякі фреймворки

Відповісти
Підтримати
Danylo Yemchenko 02.05.2024 01:54

> Розгорілась дискусія
16 лайків, один коментар: «You are so true»

Відповісти
Підтримати
Александр Енотов 02.05.2024 00:22

Mcode -> ASM -> C -> Python -> Django -> DRF ...
На какой ступеньке надо остановиться, чтобы не считаться «фреймворкером»?

Відповісти
Підтримати
Dmytro 01.05.2024 21:52
Правда в тому, що це не інженери-програмісти; це «фреймворкери» або ті, хто вміє краще копіювати та вставляти.

Мені їх навіть фреймворкерами важко назвати. Коли пишешь проект навіть не великого, середнього розміру, рано чи пізно фреймворк «закінчуюється» — то просто неоптімально щось робить, то взагалі щось відсутнє, або просто погано задокументовано, або навіть не намагались документувати, максимум: «javadoc/jsdoc є? — є, чим не дока».

Ось я себе вважаю фреймворкером — в таких випадках доводиться копатись в коді фреймворку, якщо того що треба немає — я намагаюсь реалізувати якийсь модуль для фреймворку/ліби, щоб все було в одному стилі, гармонічно. А «фреймворкери» згадані тут — просто напилять купу іфів (що не обовʼязково погано, доречі, тут як подивитись), й буде якийсь полудекларатив-полуімператив.

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

Відповісти
Підтримати
Babii Mykhailo 01.05.2024 21:49

Який сенс в цьому питанні? Бізнес потребує різних розробників для різної роботи

Відповісти
Підтримати
Yaroslav Onofriichuk 01.05.2024 19:53

Вважаю що зараз немає фреймворкерів, зараз не можливо пройти співбесіду на джуна не знаючи теорії струн і цикл трикарбонових кислот

Відповісти
Підтримати
Emma Orlova SDE 01.05.2024 19:22

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

в тому і є робота, вирішувати проблеми.

Відповісти
Підтримати
Євген Воронюк Lead Software Developer в EPAM 01.05.2024 19:11

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

Відповісти
Підтримати
Pavlo Vuiko Senior Node.js Engineer в Yalantis 01.05.2024 19:01

Тут має бути баланс між тим і іншим, якщо ти супер девелопер, але не знаєш фреймворків, то time to market твоєї апки відправиться у безкінечність, на противагу якщо ти «фреймворкер», то швидше всього ти зможеш швидко зробити 80% будь якого функціоналу, проблеми почнуться саме з тими 20% що залишилися. На мою думку цілком окей починати вивчення з фреймворків, щоб швидко могти добитися практичного результату (перший пет-проєкт, перша робота) бо початківцям дуже важливо бачити результат своєї роботи, а не, вибачте за слово, надрочувати алгоритми на структури даних і аж через 1-2 роки добратися власне до практичної роботи, цей варіант підходить хіба що, якщо ви в університеті і у вас ще є 2 вагони вільного часу. Тому, я вважаю, що цілком окей починати з фреймворків, а потім вже (в ідеалі паралельно) розширювати свої знання на алгоритми, просунутий SQL, і якісь більш глибокі знання самої мови

Відповісти
Підтримати
Olexander Smolianinov frontend director в ZFORT Group 01.05.2024 18:57

Так це ж класика фронтенду. Проводжу співпесіди вже років 15, мабуть. Пам’ятаю, коли з’явилися jQuery-only-девелопери. Тобто ті, для кого jQuery був єдиний JS, який вони більш менш знали. Вони і сайти робили тільки на jquery-плагінах. Потім були react-девелопери. Типу знали реакт, але не знали різниці між let і var в ванільному ЖС. А ще були bootstrap-девелопери, іноді foundation-девелопери. Elementor-девелопери (це вже з всесвіту WP). Зараз прийшов час Tailwind. Вангую, наступними будуть AI/copilot-driven девелопери

Відповісти
Підтримати
Evgeny Sergeev 01.05.2024 20:44

Зараз світчнулся в JS prompt developers . Дуже непогано виходить , клієнт задоволений. Але хоча базу js треба знати

Відповісти
Підтримати
Olexander Smolianinov
Мамка Жука 01.05.2024 18:51

Та ну если бы ... Чуть что нужно нетривиальное и сразу приходиться сорцы фреймворка читать.

Відповісти
Підтримати
Serge Loboda Senior Software Developer в Access Softek, Inc. 02.05.2024 11:39

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

Відповісти
Підтримати
Мамка Жука
Dmytro Skorokhod Founder, iOS/macOS Developer в Mac Monsters 01.05.2024 18:50

Ми живемо в епоху, коли люди працюють за комп’ютером, але не в змозі вполювати мамонта.

Відповісти
Підтримати
Ювженко Денис System Architect в Intellias 01.05.2024 21:04

До речі один знайомий сініор-архітектор у мене в компанії до ІТ( чи на ранніх етапах роботи, не впевнений ) працював забойщиком свиней.

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

Відповісти
Підтримати
Dmytro Skorokhod
Andrii Malchyk Soldier. Ex. DataOps/Data Engineer в Armed Forces of Ukraine 01.05.2024 22:58
зв’язував і держав свиней поки більш старший родич їх різав

у власне забої участі не брав, але у всіх подальших процесах аж до смаженої свіжини на столі приймав участь на постійній основі років з 14

Відповісти
Підтримати
Ювженко Денис
Дмитро 02.05.2024 07:40

свиню колють, різати її безглуздо бо там сала 15см

Відповісти
Підтримати
Ювженко Денис
Ювженко Денис System Architect в Intellias 02.05.2024 10:43

О, бачу ви теж були долучені)
Саме так, колють в серце довгим металевим штирем.

Відповісти
Підтримати
Дмитро
Andrey 02.05.2024 13:16

мiй тато з мисливськоï рушницi стрiляв, а я потiм по дiрках в стiнах шукав кулю, бо вона прошивала свинку наскрiзь...

Відповісти
Підтримати
Дмитро
K Vadym 02.05.2024 15:20

Вмілі стріляли замість усього оцього.

Відповісти
Підтримати
Дмитро
Igor Tsvyak Systems Engineer 02.05.2024 23:11

Дехто й ріже, головне ніж гострий мати. Але частіше колють щоб зберегти кров для кров’янки, та й чистіше

Відповісти
Підтримати
Дмитро
Igor Tsvyak Systems Engineer 02.05.2024 23:12

Свиней різали, курей рубали, дехто й кролів бив. А потім комп’ютерні ігри зробили нас жорстокими

Відповісти
Підтримати
Ювженко Денис
Serge Loboda Senior Software Developer в Access Softek, Inc. 02.05.2024 11:39

Перш за все, за відсутністю мамонтів ;-)

Відповісти
Підтримати
Dmytro Skorokhod
Никита Прототип 01.05.2024 18:49

Ми живемо в епоху коли девелопери пишуть на Swift але не знають ассемблер

Відповісти
Підтримати
Gennady Oleynik 02.05.2024 05:05

Какой именно ассемблер? Под какое семейство? Свифт и тому подобные и придумали в том числе чтобы под каждую железку не учить отдельный язык

Відповісти
Підтримати
Никита Прототип
Maxim Deyneka Software Engineer 02.05.2024 07:37

Swift придумали щоб не як у всіх

Відповісти
Підтримати
Gennady Oleynik
skipper 01.05.2024 18:43

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

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

Відповісти
Підтримати

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.