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

Ruby - це динамічна мова програмування з відкритим кодом з акцентом на простоту та продуктивність.

Python - мова програмування, яка дозволяє швидше працювати та ефективніше інтегрувати ваші системи.

Будучи розробником PHP протягом багатьох років, Вік Черубіні добре підсумовує моє становище:

Я добре знав PHP, мав власні рамки і міг швидко працювати, щоб щось почати працювати.

Я програмував так протягом усієї революції MVC. Я отримав кращу та кращу роботу (читайте: краща оплата, кращий титул) як розробник PHP, але все це розуміючи, що код, який я написав у свій час, був чудовим, і код, з яким я працював на роботі, був жахливим. Мовляв, гірше жахливого. Суворий. Рівень комерції ОС поганий. Побічні проекти змусили мене бути здоровим, тому що код, з яким я працював на роботі, зробив мене нещасним.

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

Язики, які я переглянув, включають JavaScript (для node.js), Ruby, Python та Erlang. Я навіть думав про Scala або C ++.

Проблема полягає у з'ясуванні, які з них побудовані, щоб найкращим чином відповідати моїм потребам.

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

Оновлення

Я просто не хочу проходити 4 місяці на дорозі з якоюсь мовою і вважаю, що це смокче, тому що кожен потік має 4 Мб накладних витрат, або максимум одночасних з'єднань становить 999, немає пакету, щоб виконувати функцію "X", або підтримка є поступово припиняється нова галузь мови.

Я не збирався розміщувати це як відповідь, але Xeoncross попросив мене, тож ми переходимо:

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

Опублікував Алекс Мартеллі на comp.lang.python : Що краще в Ruby ніж Python? від 18 серпня 2003 року, 5:50 вечора

Ерік Макс Френсіс написав:

"Брендон Дж. Ван Кожен" писав:

Що краще в Ruby ніж Python? Я впевнений, що є щось. Що це? Хіба не було б набагато більше сенсу запитати у цього Рубі людей, а не людей Python?

Можливо, чи не може, залежно від своїх цілей - наприклад, якщо цілі включають "соціологічне дослідження" спільноти Python, то поставлення запитань до цієї спільноти, ймовірно, виявить більше розкриття інформації про неї, ніж їх розміщення в іншому місці :-). Особисто я із задоволенням скористався можливістю переглядати одноденний підручник «Рубі» Дейва Томаса нарешті в OSCON. Нижче тонкого шпону різниць синтаксису я знаходжу Ruby та Python напрочуд схожими - якби я обчислював мінімальну діапазон дерев серед майже будь-яких мов, я впевнений, що Python та Ruby були б першими двома листами проміжний вузол :-).

Звичайно, я втомитися, в Ruby, щоб друкувати дурний «кінець» в кінці кожного блоку (а не просто unindenting) - але тоді я отримати , щоб уникнути друкуючи однаково дурні , : який Python вимагає в початку з кожен блок, так що це майже помивка :-). Інші відмінності в синтаксисі, такі як @fooversus self.fooабо вища значимість випадку у Ruby vs Python, для мене насправді так само не мають значення.

Інші, без сумніву, ґрунтують свій вибір мови програмування саме на таких питаннях, і вони породжують найгарячіші дебати - але, на мою думку, це лише приклад одного із законів Паркінсона в дії (сума дебатів щодо певного питання обернено пропорційна рівню випуску). фактичне значення). Одна синтаксична різниця, яку я вважаю важливою, і на користь Python - але інші люди, без сумніву, думають просто навпаки - це "як ви називаєте функцію, яка не приймає жодних параметрів". У Python (як у C) для виклику функції ви завжди застосовуєте "оператор виклику" - кінцеві дужки безпосередньо після об'єкта, який ви викликаєте (всередині цих кінцевих дужок йдуть аргументи, які ви передаєте під час виклику - якщо ви не передаєте аргументів, тоді дужки порожні). Це залишає просту згадку про будь-який об'єкт без участі жодного оператора, оскільки це означає лише посилання на об'єкт - у будь-якому контексті, без особливих випадків, винятків, спеціальних правил тощо. У Ruby (як у Pascal) для виклику функції З аргументами ви передаєте аргументи (як правило, в дужках, хоча це не завжди), АЛЕ якщо функція не бере аргументів, то просто згадування про функцію неявно називає її. Це може виправдати очікування багатьох людей (принаймні, без сумніву, тих, чий єдиний попередній досвід програмування був з Паскалем, або іншими мовами з подібними "невмілими дзвінками", такими як Visual Basic) - але для мене це означає проста згадка про об'єкт може ВСІГО означати посилання на об'єкт АБО дзвінок на об'єкт, залежно від типу об'єкта - і в тих випадках, коли я не можу отримати посилання на об’єкт, просто згадуючи його, мені потрібно буде використовувати явне "дайте мені посилання на це, НЕ називайте!" операторів, які не потрібні інакше. Я відчуваю, що це впливає на "першокласність" функцій (або методів чи інших об'єктів, що дзвоняться) та можливість плавного обміну об'єктами. Тому для мене ця специфічна синтаксична різниця є серйозною чорною позначкою щодо Рубі - але я розумію, чому інші поступатимуться інакше, хоча я навряд чи можу з ними більше погодитися :-). Нижче синтаксису ми стикаємося з деякими важливими відмінностями елементарної семантики - наприклад, рядки в Ruby - це змінні об'єкти (як, наприклад, у C ++), тоді як у Python вони не змінюються (як у Java, або я вважаю, C #). Знову ж таки, люди, які судять передусім за тим, що вони вже знайомі, можуть подумати, що це є плюсом для Рубі (якщо, звичайно, вони не знайомі з Java або C #, звичайно :-). Мені здається, непорушні рядки - це відмінна ідея (і я не здивований, що Java, незалежно, я думаю, винаходила цю ідею, яка вже була в Python), хоча я не заперечувала б і з типом "мутаційний буфер струнів" (і в ідеалі - з кращою зручністю у використанні, ніж власні "рядкові буфери" Java); і я не даю цього судження через знайомість - перед вивченням Java, крім функціональних мов програмування, де люди, які судять головним чином за тим, що вони вже знайомі, можуть подумати, що це плюс для Рубі (якщо, звичайно, вони не знайомі з Java або C #, звичайно :-). Мені здається, непорушні рядки - це відмінна ідея (і я не здивований, що Java, незалежно, я думаю, винаходила цю ідею, яка вже була в Python), хоча я не заперечувала б і з типом "мутаційний буфер струнів" (і в ідеалі - з кращою зручністю у використанні, ніж власні "рядкові буфери" Java); і я не даю цього судження через знайомість - перед вивченням Java, крім функціональних мов програмування, де люди, які судять головним чином за тим, що вони вже знайомі, можуть подумати, що це плюс для Рубі (якщо, звичайно, вони не знайомі з Java або C #, звичайно :-). Мені здається, непорушні рядки - це відмінна ідея (і я не здивований, що Java, незалежно, я думаю, винаходила цю ідею, яка вже була в Python), хоча я не заперечувала б і з типом "мутаційний буфер струнів" (і в ідеалі - з кращою зручністю у використанні, ніж власні "рядкові буфери" Java); і я не даю цього судження через знайомість - перед вивченням Java, крім функціональних мов програмування, де Я думаю, що незмінні рядки - це відмінна ідея (і я не здивований, що Java, незалежно, я думаю, винаходила цю ідею, яка вже була в Python), хоча я не заперечувала б і за типом "мутаційний буфер струнів" (і в ідеалі - з кращою простотою у використанні, ніж власні "буферні рядки" Java; і я не даю цього судження через знайомість - перед вивченням Java, крім функціональних мов програмування, де Я думаю, що незмінні рядки - це відмінна ідея (і я не здивований, що Java, незалежно, я думаю, винаходила цю ідею, яка вже була в Python), хоча я не заперечувала б і за типом "мутаційний буфер струнів" (і в ідеалі - з кращою простотою у використанні, ніж власні "буферні рядки" Java; і я не даю цього судження через знайомість - перед вивченням Java, крім функціональних мов програмування, девсі дані незмінні, усі мови, які я знав, мали мінливі рядки - але коли я вперше побачив ідею незмінної струни на Java (яку я навчився добре ще до того, як пізнав Python), це одразу ж вразило мене відмінно, дуже добре підходить для референтна семантика мови програмування вищого рівня (на відміну від значення-семантики, яка найкраще підходить для мов, ближчих до машини та далі від додатків, таких як C) із рядками як першокласного, вбудованого (і досить вирішальний) тип даних.

У елементарної семантики у Рубі є деякі переваги - наприклад, вилучення «списків проти кортежів» Питона надзвичайно тонкою відмінністю. Але в основному оцінка (як я вважаю, простота, великий плюс і тонкі, розумні розрізнення, помітний мінус) проти Рубі (наприклад, з закритими і напіввідкритими інтервалами, з позначеннями a..b і .. .b [хтось хоче стверджувати, що очевидно, що є? -)], нерозумно - ІМХО, звичайно!). Знову ж таки, люди, які вважають, що в основі мови багато подібних, але тонко різних речей, ПЛЮС, а не МІНУС, звичайно, будуть рахувати це "навпаки" від того, як я їх рахую :-).

Нехай вас не вводить в оману ці порівняння думок, що ці дві мови є дужеінший, зауважте. Вони ні. Але якщо мене попросять порівняти "capelli d'angelo" з "spaghettini", після того, як зазначив, що ці два види макаронів майже не відрізняються ні від кого і є взаємозамінними в будь-якій страві, яку ви хочете приготувати, я б тоді неминуче мав перейти до мікроскопічного дослідження того, як непомітно відрізняються довжини і діаметри, як кінці пасм звужуються в одному випадку, а не в іншому, і так далі - спробувати і пояснити, чому я особисто вважаю за краще "ангело, як макаронні вироби в будь-якому вигляді бульйону, але вважає за краще спагеттіні, як макаронні вироби, щоб їхати з підходящими соусами для таких довгих тонких макаронних форм (оливкова олія, фарш з часнику, фарш з червоного перцю і дрібно натертий анчоус, наприклад - але якщо ви нарізали часник і перець замість того, щоб фаршувати їх, то вибирайте тіло спагетті, а не більш тонке просочення спагетіні, і було б радимо відмовитися від ачворку і замість цього додати трохи свіжого весняного базиліка [ чи навіть - я єретик ...! - легка м'ята ...] листя - в самий останній момент перед подачею страви). Ой, вибачте, це свідчить про те, що я подорожую за кордон і мабуть не маю макаронних виробів певний час. Але аналогія все-таки досить хороша! -) і було б радимо відмовитися від ачхов'ю і додати замість нього свіжий весняний базилік [або навіть - я єретик ...! - легка м'ята ...] листя - в самий останній момент перед подачею страви). Ой, вибачте, це свідчить про те, що я подорожую за кордон і мабуть не маю макаронних виробів певний час. Але аналогія все-таки досить хороша! -) і було б радимо відмовитися від ачхов'ю і додати замість нього свіжий весняний базилік [або навіть - я єретик ...! - легка м'ята ...] листя - в самий останній момент перед подачею страви). Ой, вибачте, це свідчить про те, що я подорожую за кордон і мабуть не маю макаронних виробів певний час. Але аналогія все-таки досить хороша! -)

Отже, повертаючись до Python та Ruby, ми переходимо до двох великих функцій (з точки зору належної мови - залишення бібліотек та інших важливих допоміжних допоміжних засобів, таких як інструменти та середовища, як вставляти / розширювати кожну мову тощо, тощо) з це поки що - вони все одно не застосовуватимуться до всіх ВПРОВАДЖЕНЬ кожної мови, наприклад, Jython проти Classic Python є двома реалізаціями мови Python!):

1. Ітератори та кодові блоки Ruby проти ітераторів та генераторів Python;

2. ВСЬОГО Рубі, нестримна "динамічність", включаючи можливість "відкрити" будь-який існуючий клас, включаючи всі вбудовані, та змінити свою поведінку під час виконання - проти величезної, але обмеженої динаміки Python     , яка ніколи не змінює поведінку існуючих вбудовані класи та їх екземпляри.

Особисто я вважаю 1 мийкою (відмінності настільки глибокі, що я міг легко бачити людей, що ненавидять будь-який підхід і зворотний інший, але на моїх особистих масштабах плюси і мінуси майже рівномірно); і [2] важливе питання - той, що робить Ruby набагато більш придатним для "майстерності", але НЕ Python однаково більш придатний для використання у великих виробничих додатках. Це певним чином смішно, тому що обидві мови настільки динамічніші, ніж більшість інших, що врешті-решт ключова різниця між ними від моєї POV повинна залежати від цього - що в цьому відношенні Рубі "переходить до одинадцяти" (посилання тут, звичайно, "Спинальний дотик". У Рубі,Я можу це зробити ! Тобто я можу динамічно змінювати вбудований клас рядків так, щоб

a = "Привіт, світ" 
b = "привіт світ" 
якщо a == b 
    друк "рівний! \ n" 
ще 
    надрукувати "інше! \ n" 
кінець
 

БУДЕ друкувати "рівним". У python немає способу зробити це. Для метапрограмування, реалізації експериментальних рамок тощо, ця дивовижна динамічна здатність Рубі надзвичайно надзвичайна привабливий. АЛЕ - якщо ми говоримо про великі програми, розроблені багатьма людьми та підтримувані ще більше, включаючи всі види бібліотек з різних джерел, і потрібно запускати у виробництво на клієнтських сайтах ... ну, я НЕ ХОЧУ мова, ЯКА ЦІ ТИНА динамічна, дуже дякую. Я ненавиджу саму ідею, що деякі бібліотеки мимоволі ламають інші непов'язані між собою ті, що покладаються на те, що ці рядки відрізняються - ось такий тип "глибокого та глибоко прихованого" каналу "між фрагментами коду, який ЛОКУВАТЬСЯ і повинен бути окремим, що заклинає смерть у широкомасштабне програмування. Дозволяючи будь-якому модулю впливати на поведінку будь-якого іншого "приховано",

Якби мені довелося використовувати Ruby для такої великої програми, я б спробував покластися на обмеження стилю кодування, безліч тестів (щоб їх повторювати, коли що-небудь змінилося - навіть те, що повинно бути абсолютно не пов’язаним між собою ...) тощо. заборонити використання цієї мовної функції. Але, на перший погляд, НЕ мати цю функцію - це навіть краще - так само як Python був би ще кращою мовою для програмування прикладних програм, якби певна кількість вбудованих модулів могла бути "прибитими", тому я ЗНАЮ, що , наприклад, len("ciao")4 (замість того, щоб турбуватися підсвідомо про те, чи хтось змінив прив'язку імені lenв __builtins__ модулі ...). Я сподіваюся, що врешті-решт Python "прибити" свої вбудовані модулі.

Але проблема незначна, оскільки перезавантаження вбудованих модулів є досить застарілою, а також рідкісною практикою в Python. У Ruby це вражає мене як головного - так само, як занадто потужні макро-засоби інших мов (наприклад, Ділан) представляють подібні ризики на мою власну думку (я сподіваюся, що Python ніколи не отримає такої потужної макросистеми, ні Незважаючи на привабливість "дозволити людям визначати свої власні доменні маленькі мови, вбудовані в саму мову" - це, IMHO, погіршить чудову корисність Python для програмування прикладних програм, представивши "привабливу неприємність" потенційному майстру, який ховається в серці кожного програміста ...).

Олексій

Щасти

Жоден із наведених прикладів описів не є об'єктивним або перевіреним. Вони всі шуміть і думка.

... простота та продуктивність ... швидше ... ефективніше.

Спробуй це

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

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

Я підходжу до використання правильної мови для роботи. Ви спеціально запитуєте про веб-розробку , але це все ще досить широка категорія - начебто говорите, що вас цікавить фотографія. Мікро? Астро? Хоча я погоджуюся, що PHP не є емоційно виконуючою мовою для роботи, для багатьох клієнтів це правильна мова, заснована на будь-якій кількості факторів, не останньою з яких є довгострокова здатність знаходити програмістів, щоб виправити сайт після відходу. та / або потрапити на автобус.

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

Пітон

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

• Django - повноцінна, зріла рамка високого рівня з вдосконаленою ORM, системою шаблонів, обробкою форми тощо.
• Скручена - рамка для керованого подіями (асинхронного) мережевого програмування, її можна використовувати для чатів, сокет-серверів, веб-служб, ви їх називаєте.
• Tornado - також орієнтована на події рамка, але ця розроблена для асинхронних веб-сервісів.

Рубін

Рубі - це також досить універсальна мова. Але на сьогоднішній день найбільш помітним продуктом є Ruby on Rails. Його дизайн був натхненником для багатьох (включаючи згаданого вище Джанго).

JavaScript

Наразі єдиним вибором сервера для JS є node.js. Він дуже схожий на "Торнадо і Скручений" (яким він надихнувся). Однак йому все ще не вистачає повноцінних рамок, подібних до Django або RoR, побудованих на ній.

Скала

Будучи функціональною мовою, вона чудово підходить для масових паралельних обчислень, що стосується веб-програмування загального призначення, є Lift - веб-рамка, натхненна RoR, використовувана, наприклад, FourSquare.

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

Scala and Play Framework

Маючи вищезазначений досвід, мені дуже подобається мова програмування Scala, вона є статично типовою, має підтримку як об'єктно-орієнтованого, так і функціонального програмування, і має хороші показники порівняно з іншими мовами, які використовуються для веб-розробки. Але мені не сподобалися веб-рамки для Java та сервлетів, і я знайшов Play Framework , який підтримує і Scala, і Java, і це дуже швидкий цикл розробки - збережіть файл та оновіть веб-сторінку. Я був дуже задоволений програмою Scala & Play Framework минулого місяця. Але підтримка Scala в Play Framework ще не дуже зріла, і жодна підтримка інструментів.

Коротше кажучи, я рекомендую Scala як мову програмування та Play Framework як веб-рамку.

Насправді ви шукаєте, ймовірно, три види ресурсів:

• Той, що пояснює основи мови та чому ви хочете нею користуватися,
• Той, який порівнює кілька мов.
• Той, що критикує певний аспект мови.

Обидва ці ресурси будуть упередженими.

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

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

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

Це означає, що вам доведеться або витрачати час (місяці, а то й роки) на практикуванні. Або ви можете багато читати. Але постарайтеся прочитати суперечливі речі . Якщо хтось пише, що він ненавидить PHP, а PHP - це одна з найгірших мов, особливо в порівнянні з реальними мовами, такими як Ruby, C # або Java, спробуйте також знайти людину, яка каже, що PHP чудова, і її легше використовувати, ніж ніж C #, набагато швидше, ніж Java, і набагато ... (я справді не знаю що), ніж Ruby.

Пам’ятайте одне: якщо ви вже добре знаєте мову, ви будете дуже критикувати на початку, коли вивчаєте іншу , вважаючи, що мова, яку ви вже знаєте, є кращою та значно простішою у використанні. Це як користувачі Linux, які ненавидять Windows, так і користувачі Windows, які ненавидять Linux: насправді жодна ОС не краща; це просто те, що користувач Linux не знає, як користуватися Windows, і навпаки. Лише після того, як ви набудете достатнього досвіду в обох, ви зможете правильно вирішити, який з них краще для вас.

І останнє, про що часто забувають: також дуже важливо вміти оцінювати "оточення" мови:

• Наскільки хороший фреймворк (або найбільш використовувані рамки)?
• Чи легко знайти хостинг-послугу? Чи цінуєте ви IDE?
• Чи достатньо добре написаних сторонніх бібліотек?
• Чи спільнота складається з високопрофесійних розробників або здебільшого початківців, які нічого не знають ні про програмування взагалі, ні про саму мову?
• Чи достатньо деталізована документація та її легко знайти та зрозуміти?
• Чи часто оновлюються мова та рамки?
• тощо.

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

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

Що стосується мов, які мають конкретні цілі, то багато мов їх не мають. Більшість перерахованих вами мов мають досить загальне призначення. Наприклад, мова Ruby - це досить загальна мова, яка підходить для багатьох завдань. Після того, як ви додасте до нього рамку, як Rails , це має досить конкретну мету.

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

Ви дійсно досягли межі PHP або просто межі PHP, як ви це знаєте?

Ви заглянули в Drupal ? Це система CMS та програмування на основі PHP, яка наполегливо заохочує хороші стандарти та практики кодування. (Доводиться працювати з OSCommerce на попередніх робочих місцях, я відчуваю ваші болі там.) Хоча на основі PHP, це досить різно, що часто "правильний" спосіб зробити щось у чистому PHP - це не правильний спосіб зробити це в Drupal, і у вас буде хороша крива навчання, щоб піднятися, щоб справді оволодіти нею. Однак це може змінити ваші уявлення про можливості PHP як мови та веб-розробки в цілому.