Середовище розробки

[BM]

Я виклав свої претензії до мов програмування (частково) тут: http://news.ycombinator.com/item?id=832030 (і продублював у своєму блозі).

Ми торочимось тут про ябка, йно там про апельсини.

Як на мене, то все там що описано — бібліотеки та фреймворки, а не мови як такі.  А MapReduce то-й взагалі на Bash написати можна при великому бажанні (http://blog.last.fm/2009/04/06/mapreduce-bash-script). Претензії–ж до самих мов у мене все–таки «де–що» інші та значно скромніші. Все що я хочу це:
1. Файну читабельність коду. Я лінивий і хочу за 4 секунди розібратись із кодом, написаним рік тому.
2. Гнучку динамічність, але при тому жорстку статику. Останнім часом я вважаю динамічні мови не найкращим варіантом для великих проектів.
3. Крос-платформенність. Write once, debug everywhere. :-)
4. Якомога більшу швидкість.
5. Безболісне життя. Це коли я свої наробки передаю єнчому матолку і тре шоби він второпав отеє за мінімальний час та не зробив із того шпаґєтті.

[Володимир Лісівка]

Поясню трохи по іншому.

Якщо є мова, то є і словник мови - набір слів, з якими асоційовані певні поняття (якщо точніше - семантика).

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

Поняття ООП чи ФП можна використовувати у мовах, які не мають підтримки цих парадигм. Напр. бібліотека GTK+ - ООП на мові без підтримки ООП. Але погодьтеся, що якщо відповідних слів немає в мові, то текст стає значно багатослівнішим при передачі тих самих понять.

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

Напр. значний приріст в швидкості завантаження і роботи принесли такі технології:
  * засипання/прокидання комп’ютера (hibernation);
  * система паралельного запуску процесів ініціалізації побудована на залежностях і подіях (upstart);
  * виконання певних типових дій один раз при встановленні програми (prelinking, попередня компіляція для інтерпретаторів);
  * оптимізація в процесі виконання (JIT);
  * розбиття програми на прості примітиви, які легко розпаралелюються (map-reduce);
  * автоматичне розв’язання залежностей (apt-get/yum/etc., IoC/DI, Lazy programming, make, etc.);
  * автоматичне відновлення у випадку збою (throw/catch/finally, maybe, checkpoints, transactions, journals, etc.);
  * і т.д. - якщо уважно подивитися, то можна знайти ще багато подібного;

[BM]

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

То очікувати у скорому майбутньому VL++? :-)

[Володимир Лісівка]

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

То очікувати у скорому майбутньому VL++? :-)

Я вважаю, що мова - похідна. Ми не придумували нову мову, щоб описати комп’ютери і програмування - ми лише ввели декілька нових термінів. Який сенс придумувати нову мову на кожен чих?

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

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

Напр.

Код: [Вибрати]

"Прямокутник" - це об’єкт. Воно має такі властивості:
  * поле "ширина" - цілого типу, захищене, незмінне;
  * поле "висота" - цілого типу, захищене, незмінне.

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

Розібрати такий код не складно. Можна вводити свої скорочення чи поняття, так само як ми, напр., вводимо їх в матиматиці. Напр. "=" - це оператор рівності, або "=" - це оператор присвоєння.

НМД, програма має бути написана звичайною мовою, так як програми пишуться людьми і для людей. Разом з програмою повинно поставлятися роз’яснення певних термінів, якщо їх немає в базовому словнику, але воно повинно поставлятися окремо. Все що не зрозуміло компілятору, має бути розжовано за межами програми. Напр., якщо компілятор не розуміє речення "Цей конструктор повинен взяти свої аргументи і присвоїти їх відповідним полям.", то потрібно буде створити шаблон чи набір шаблонів, які співпадуть з цим реченням. "присвоїти X, в просторі імен X', відовідному Y, в просторі імен Y'" означає "знайти  в просторі імен X' таке Y, назва якого співпадає з назвою X в просторі імен X'."

Це, фактично, створення експертної системи, область компетенції якої буде виключно компіляція цієї програми.

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

Я створив домени http://zeroframefork.com і http://dzenframework.com (вони зараз порожні) саме для цієї мети.

Якщо комусь цікаво - звертайтеся.

[romi]

 8-)
Гарна ідея.

[BM]

Ойнє. І скажу чому я так вважаю.

Взагалі-то English. Бо то міжнародна де-факто (хто хоче де-юре — будь-ласка розмовляйте з французами). Дуже і дуже сумніваюсь, що гарна бібліотека на санскриті буде популярна взагалі, а щось написане на сваґілі буде відоме в Китаї чи Америці. :-)

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

По-третє, все-таки треба зауважити, що всі програми пишуться власне для компютерів, які повинні їх потім виконувати. І ні в якому разі не для людей. Бо люди ними тільки користуються, управляють та отримують результат. Тому фрази «програма для людини» (use case) та «програма для компютера» (технолоґія) — зовсім ріжні поняття та сфери діяльности.

А ще-й щодо української, то тут вже філософсько-політичні питання пішли, бо програмувати українською будуть тільки українці, і тільки там, де ще тієї України лишилось. :-) Добавити сюди ще і той кататрофічний факт, що український Інтернет та ринок вцілому і так в наджахливому стані, то це зробить іще гірше: оскільки 40% українців розмовляють взагалі іноземною російською (української не знають взагалі), а 20% вважають українську сільським діалектом Галичини при цьому російську — своєю рідною. Лишиться 40% народу, з якого 35% — загальні матолки, а 5% потенціяльні писаки програм, які на це плюнуть і повернуться до С++/Java.

:-)

[Володимир Лісівка]

Ойнє. І скажу чому я так вважаю.

Взагалі-то English. Бо то міжнародна де-факто (хто хоче де-юре — будь-ласка розмовляйте з французами). Дуже і дуже сумніваюсь, що гарна бібліотека на санскриті буде популярна взагалі, а щось написане на сваґілі буде відоме в Китаї чи Америці. :-)

Ніхто не пише програми англійською мовою. Пишуть штучними мовами, спеціально розробленими для програмування, мнемоніки у яких мають походження від англійських слів. Напр. "memcpy" походить від двох англійських слів "memory" і "copy" і означає "copy memory area". Немає ніякого значення, якою мовою написана бібліотека (хоч на brainfuck) якщо до неї є документація англійською мовою і нормальний програмний інтерфейс.

Ви, коли запускаєте програми, хіба спочатку роздивляєтеся якою мовою написана програма? "Ой, ні  - текст цієї програми написаний українською - я не буду її запускати, краще я виконаю всі дії руками". :-)

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

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

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

Приклади: XML, JSON, Лісп, Форт. Не потрібно вчити новий синтаксис для того, щоб зрозуміти нову програму на цих мовах, чим програмісти і користуються для створення своїх мінімов (Domain Language). Як правило, через близькість мінімови до предметної області, відпадає необхідність в документації, так як документація буде 1:1 відповідати тексту програми.

По-третє, все-таки треба зауважити, що всі програми пишуться власне для компютерів, які повинні їх потім виконувати. І ні в якому разі не для людей. Бо люди ними тільки користуються, управляють та отримують результат. Тому фрази «програма для людини» (use case) та «програма для компютера» (технолоґія) — зовсім ріжні поняття та сфери діяльности.

Ви самі собі суперечите - так це комп’ютери відмовляться виконувати програми написані не англійською мовою? Так це комп’ютеру важливо гарне форматування, синтаксис, змістовні назви, коментарі і документація? Комп’ютери відмовилися від асемблера з естетичних міркувань? :-)

Раніше вузьким місцем були комп’ютери, і програми писалися так, щоб комп’ютери працювали якнайефективніше.

Зараз вузьким місцем є програмісти, і популярності набувають мови які в 50-т раз повільніші за Сі, зате в 5-6 раз швидші в розробці: Пітон, Перл, Яваскрипт, Рубі, Скала, Shell, та інші.

Але постає інша проблема - на якійсь новій мові X ту ж роботу можна буде зробити в 2-3 рази швидше, АЛЕ потрібно стратити 2-3 роки на її вивчення. Тобто мова, яка не потребує вивчення, може отримати значний бонус за рахунок відсутності потреби у перенавчанні.

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

У української мови є одна суттєва перевага - українська мова дуже подібна на мову програмування. Може так статися, що перекласти всі знання і всі програми світу на українську (чи китайську) буде економічно вигідніше, ніж на штучно створений діалект XML-ю (як зараз і роблять). Все таки в світі живе кілька десятків мільйонів (чи мільярд з копійками) людей, які вже цю мову знають. ;-)

Добавити сюди ще і той кататрофічний факт, що український Інтернет та ринок вцілому і так в наджахливому стані, то це зробить іще гірше: оскільки 40% українців розмовляють взагалі іноземною російською (української не знають взагалі), а 20% вважають українську сільським діалектом Галичини при цьому російську — своєю рідною. Лишиться 40% народу, з якого 35% — загальні матолки, а 5% потенціяльні писаки програм, які на це плюнуть і повернуться до С++/Java.

:-)

Я хоч і люблю Яву, сам віддаю перевагу або Перлу або Яваскрипту або Башу так як від них менше руки болять.

Я думаю, що Яваскрипт скоро стане мовою номер 1 для прикладного програмування так як він має знайомий Сі-подібний синтаксис і гнучку модель, на яку добре лягають як ООП, так і ФП чи ЛП (Логічне Програмування, див. YieldProlog) чи модель Ерланга (шукай Er.js), і т.д.

[DalekiyObriy]

Я думаю, що Яваскрипт скоро стане мовою номер 1 для прикладного програмування так як він має знайомий Сі-подібний синтаксис і гнучку модель, на яку добре лягають як ООП, так і ФП чи ЛП (Логічне Програмування, див. YieldProlog) чи модель Ерланга (шукай Er.js), і т.д.

мови без строгої типізації і інших засобів контролю за якістю кода не масштабуються, тому для серйозних проектів вони не будуть №1, а для плазмоїдів і веб-сторінок — так, звичайно

[DalekiyObriy]

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

[Володимир Лісівка]

мови без строгої типізації і інших засобів контролю за якістю кода не масштабуються, тому для серйозних проектів вони не будуть №1, а для плазмоїдів і веб-сторінок — так, звичайно

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

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

Для прикладу, подивіться на Лінукс і якусь іншу монолітну ОС-ку, напр. BeOS. Що би ви хотіли - мати кілька тисяч пакетів з маленькими програмульками, кожна з яких вирішує своє окреме завдання, чи один великий моноліт на всі випадки життя?

[Володимир Лісівка]

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

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

[DalekiyObriy]

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

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

[Володимир Лісівка]

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

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

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

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

Крім того, динамічність і строга типізація не є протилежностями. Є динамічні мови з дуже строгою типізацією (scala), є статичні мови, в яких строгої типізації нема (Сі, напр., має вбудовані фічі по перетворенню типів, такі як union, void* та інші).

[DalekiyObriy]

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

[BM]

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

Так, але що більш Володимиру зрозуміло:

Код: [Вибрати]

如 回答 == '有':
      写 '好吧, 让我们一起努力!'
不然 回答 == '没有':
      写 '好吧,中文并没有作为程式语言的价值.'
否则:
      写 '请认真考虑后再回答.'

Чи: if (somestr.equals("foo") ...? А я власне про цей бар'єр і говорю.

А що складного у програмуванні звичайною мовою?

Тому що вона занадто гнучка і тому її дуже важко розібрати (певно ви займались Natural Language Processing і знаєте про що я говорю). Це буде море баґів або непередбачених моментів, які потім будуть ще-й обсуджуватись лінґвістами. :-)

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

Абсолютно згоден. Тому тут і буде біда якраз: натуральна мова тільки принесе купу зайвого до того зайвого що вже є. Докажіть зворотнє.

Приклади: XML

Я собі уявляю як-би звучала /уявляю українська мова в XML /в /мова /українська /собі /Я. :-)

Ви самі собі суперечите - так це комп’ютери відмовляться виконувати програми написані не англійською мовою?

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

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

Ага, і потім вчити китайську 10 років... та вічно розпитувати місцевих китайський бабусьок що за холєру значить ота закарлючка... ))

Я хоч і люблю Яву, сам віддаю перевагу або Перлу або Яваскрипту або Башу так як від них менше руки болять.

Гмм-гмм-гмм. Трохи дивне порівняння. Java все-ж таки не для написання 5-ти строчного скриптика для марципанізованого копіювання файлів з одного місця в інший...

Я думаю, що Яваскрипт скоро стане мовою номер 1 для прикладного програмування

Не стане. Це динамічна мова і залишиться у просторі скриптів. Щодо самої Java, то саме вона якраз і має отой файний баланс між динамікою (Class ForName, рефлекція, JSR 294, JSR 291, JSR 277 і т.д.) та строгою статикою, що однозначно дає величезну перевагу на дуже великих системах.

Але мушу сказати, що для юзерленду Rhino в мене чудово вбудовується для всяких користувацьких правил потоків роботи (workflow), які все-ж краще писати коротенькими вставочками на JS, ніж ліпити жахливі гори в XML та процесити XSL, шоб він здох.