Чи спільне для прототипу мовою вищого рівня? [зачинено]

В даний час я граю з ідеєю взяти участь у проекті, який значно перевищує мою теперішню здатність програмування мовою, в якій я маю дуже малий досвід реального світу (C). Чи було б цінним прототип мовою вищого рівня, з якою я більше знайомий (як Perl / Python / Ruby / C #), тільки щоб я міг отримати загальний дизайн?

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

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

Використання C автоматично не робить вашу програму швидшою. Коли у вас є можливість вибрати іншу мову програмування для вашої платформи, я дуже рекомендую її.

Як заявив Білл Харлан :

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

Якщо ви дійсно можете передбачити проблеми з ефективністю, подумайте про використання C ++. cprogramming.com слова це дуже красиво :

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

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

Це не було б цінним, тому що а) частини тих мов, які безпосередньо перекладаються на C, не було б простішим; б) частини, які не перекладаються безпосередньо на C, було б складніше переписати на C, ніж якби ти написав їх в С в першу чергу.

Це не питання з категоричним відповіді "так" чи "ні". Дозвольте мені зважити анекдот.

Приклад 1

Мені було доручено перенести гру, написану на Java, у Flash, AS3. На поверхні це має потенціал проходити відносно плавно. Зрештою, ви можете вважати таку роботу більш чіткою, ніж робота середнього клієнта, адже у вас вже є повністю вбудована функціональна специфікація у вигляді вихідної гри. Java та AS 3 - це мови високого рівня, і AS3 має багато спільних з Java ознак, таких як структура пакунків, однонавчальний / множинний інтерфейс, (ввімкнено) сильне введення тексту та поняття загальнодоступної / захищеної / приватної змінної та функції декларацій. У той час я ще був дуже зелений на Java і зовсім новий в оригінальній базі вихідних кодів. Тому я просто занурився, щоб побачити, що можу знайти, сподіваючись, що це буде швидко і легко.

Як виявилося, автор коду намагався створити абстрактний двигун, який можна було б перенести від Java в якесь невизначене інше середовище. Це дало мені надію, що це буде просто до порту. На жаль, те, що я виявив натомість, це те, що я дивився на перспективу переосмислити Flash на вершині Flash, без вигоди Threads. Буквальний порт, як виявилося, просто був би поганою ідеєю ... кошмаром виступу. Крім того, гра реалізувала власну власну зовнішню мову сценаріїв, що означало б створення аналізатора та лексеру для цієї мови, якби я сподівався використати всі вихідні файли вихідних даних.

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

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

Приклад 2

Зауваживши, що робив розробник Java, намагаючись створити портативну кодову базу, я почав робити щось подібне для себе в моїй роботі Flash ... писати код, який не так сильно покладався на розширення flash.display. * Класів, наприклад, і використовуючи композицію для створення поглядів. Я не сильно покладаюся на flash.event. * І натомість пишуть легку систему передачі власних повідомлень, не пов’язану особливо з мовою чи платформою. Нещодавно я закінчив гру, використовуючи згаданий фреймворк, і хотів дізнатися, чи буде легко перенести його на C # (мову, яку я знаю настільки, наскільки вона схожа на Java та AS3) як проект Unity 3D. Як виявляється, це було набагато успішніше! Тому що я думаю, що в AS3 більш вільно, ніж у C #, маючи вже написані алгоритми, ми заощадили тону часу. Все, що я повинен був зробити, - це просто змінити синтаксис,

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

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

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

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

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

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

Ви не дуже заробите, якщо вибрали C ++ або навіть Java або C # як "високий рівень", а C - як "низький рівень", оскільки посилення читабельності не буде суттєвим, а "переклад" все ще буде досить болісним і досить помилковим, схильний. Ідея полягає в суті: двигун вашого проекту у впровадженні на високому рівні не повинен займати більше, ніж екран або два, бути легким для розуміння, легким для читання, а всі застереження бути болюче очевидними - по суті, робочим, запущеним блоком діаграма.

Двигун бази даних здебільшого стосується оптимальної обробки вводу / виводу низького рівня та ефективної обробки складних структур, таких як b-tree та пов'язані списки.

Тож, безумовно, проблема C / C ++, але, мабуть, є кілька непоганих реалізацій Java.

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

Компромісним рішенням може бути написання початкової реалізації на одній з мов JVM вищого рівня (Jython, Groovy приходять на думку), а потім переміщення класу за класом до Java, коли реалізація стабілізується.

Я не вважаю його загальним, але це робиться. Один з найгостріших архітекторів, з якими я коли-небудь працював, раніше займався його моделюванням в Python, а потім реалізував цей код у C ++.

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

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

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

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

Якщо ви з будь-якої причини змушені робити це в C, то прототипування іншою мовою, яку ви знаєте, для мене не така вже й погана ідея, лише якщо ви прототипуєте, знаючи, які «проблеми» у вас будуть робити фактичну реалізацію C, це важко, якщо ви не впевнені в C. (Ви незабаром виявите, що, наприклад, у C / C std libs немає контейнерів, просто "звичайний" масив; вам потрібні не-std-бібліотеки). Більше того, C не є OO, так що якщо ви будете прототипувати OO, це буде складніше.

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

Є багато критично важливих для роботи програм, написаних мовою вищого рівня.

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

Є так багато речей, які будуть перешкоджати продуктивності, що я сумніваюся, що ви коли-небудь досягнете тієї частини, де саме мова є обмежуючим фактором. Це враховує, що це проти C # C #.

Скажімо, ви отримуєте 10% -15% підвищення продуктивності за мовою. Це ніщо в порівнянні з порядками збільшення масштабів при введенні правильного алгоритму.

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

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

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

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

У згаданому випадку ви розглядаєте можливість складати прототип мовою скриптів, скажімо, python та вводити фактичний код у C.

Оцінка деяких можливостей:

1 . Ви прототипуєте в python і пишете програмне забезпечення на C.

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

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

Цей метод підходить для перевірки логічної доцільності рішення.

2 . Ви прототипуєте в C і пишете програмне забезпечення на C.

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

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

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

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

Якщо це прототип UI, розгляньте якийсь інструмент макетування інтерфейсу користувача або знову якийсь папір.

Я думаю, що ви повинні прототипувати мовою, якою ви знайомі (Pytho / Ruby / C # що ні), щоб:

1. Ви максимально користуєтесь послугами / бібліотеками, які надає мова.
2. Ви витрачаєте свій час, вирішуючи вибір дизайну замість мовних обмежень.

Пізніше ви можете використовувати інструмент для профілювання, щоб знайти ділянки горловини пляшки. Повторна реалізація в C / C ++. Повторіть крок кілька разів, хто знає, що ваш прототип може бути "досить швидким"!

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

Один проект, з яким я брав участь, використовував такий підхід: розробка математичної бібліотеки для архітектур Cell / BE та Power7. Функції були змодельовані в Haskell (за допомогою CoCoNUT), а вихідні функції були в оптимізованій збірці для певної цільової архітектури.

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

Їжа, хоча, я сподіваюся, ви не голодуєте :)

Для високоефективного двигуна бази даних вам, ймовірно, потрібно:

• багатопотоковість,
• явне управління пам'яттю,
• асинхронні сповіщення,
• семафори або примітиви синхронізації,
• простий доступ до функцій файлової системи низького рівня.

Вибрані алгоритми мають вирішальне значення для продуктивності.

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

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

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

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

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

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

Я думаю, що слава C заслужена, тому що чудовий продукт Unix був написаний на C. Однак, порівняно з людьми, які найкраще знають C, я досить скептично ставився до того, чому його слід використовувати. Кажуть, що Кен Томпсон (після написання першої версії Unix на мові збірки) почав писати Unix у Fortran, але після тижня чи місяця відмовився, і почав використовувати C, який розробляв його колега Кен Річі в одночасно.

Нещодавно мене здивувало, коли Фортран швидший за С та С ++.

Річард Маллінз