Andy Melnikov (nponeccop) wrote,
Andy Melnikov
nponeccop

Categories:

Зачем нужна человекочитаемость и дизайн

Это способ бороться с неграмотностью разработчиков и несовершенством компиляторов. Эти требования не нужны объективно, но нужны индустрии, чтобы бороться с языковым консерватизмом. Поэтому MS занимается подобной ерундой с TypeScript - потому что иначе все будет правильно, но не будет применяться говнокодерами.

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

По части обоснования у меня есть список литературы, я не сам это придумал

# Motivation and Terminology

Harsu, 2000. Re-engineering Legacy Software through Language Conversion.
Van De Vanter, 2002. The Documentary Structure of Source Code.
Bianchi, Caivano, Marengo, 2003. Iterative Reengineering of Legacy Systems.
Jones, 1995. Translating C to Ada.

# Design

Tolmach, Oliva, 1993. From ML to Ada: Strongly Typed Language Interoperability via Source Translation.
Walker, Crary, Morrisett, 2000. Typed Memory Management in a Calculus of Capabilities.

Пункт 2 нужен для обеспечения incremental reengineering, т.е. помодульного переписывания с JS на новый язык, ну и для лучшей интероперабельности с лигаси.

https://github.com/kayuri/HNC/wiki/PaperDraft
https://code.google.com/p/inv/wiki/Manifesto

Это в общих словах, что делается и зачем.

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

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

И текникал лидами, у которых всегда будут ответы на вопросы руководства о технических рисках

А что если предлагаемый никому не известный говнокомпилятор окажется багливым? - Ну, он маленький и можно самим поправить в нем баг, а если обнаружится фатальный недостаток - завсегда можно съехать с него и писать по старинке

А что если у нас всё будет тормозить, а нам для того чтобы исправить тормоза, придется переписать пол-проекта? - Не придется, так как дизайн тот же самый, максимум пару функций руками подправим в тех местах, где обнаружится жопа с производительностью.

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

  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 2 comments