Вы все задавались вопросом о растущих строках кода во всем, что мы делаем как разработчики? Это один из таких случайных размышлений от коллеги -разработчика.
Фактическая информация о количестве строк кода в различных повседневных продуктах – Здесь Анкет
Совершенно очевидно, что в будущем мы будем нажимать на критический момент.
Сложность обработки
Как знал любой из вас, все начинается как единый кодовый файл с простыми структурами моделей, предоставляя самую основную функциональность. С ростом использования, предполагая, что продукт действительно что -то решает, мы могли бы начать добавлять новые функции и оптимизацию в наше приложение. Таким образом, начинается путешествие нисходящей спирали к увеличению сложности.
Это две основные проблемы здесь. Увеличение зависимостей пропорционально увеличению признаков и снижению всех этих зависимостей.
Не существует такой вещи, как «статический» код и статический код кода. Так что в наши дни это неизбежная вещь – построить приложение с меньшими затратами или без зависимости от внешних библиотек. Этот вид «инфляции» со временем снова является проблемой с текущей формой развития.
В этом также есть человеческий аспект, поскольку разработчики в конце дня, люди. И люди меняются, люди движутся, а люди растут. Приложения смещаются между руками, они перемещаются между компаниями и между вариантами использования. Как объяснить все это?
Решение всего этого может быть самой проблемой. Изменения и разнообразие.
Спросите себя, сколько языков программирования вы знаете, по крайней мере по имени и по этому номеру, имейте в виду, в основном больше, чем количество реальных человеческих языков, которые мы знаем. Почему это?
Обязательно указать здесь очевидное. Некоторые языки были разработаны по определенным причинам. C, например, был разработан для запуска самых основных программ в самых основных аппаратных системах, а Python – нет. C, очевидно, побеждает Python в производительности, в то время как Python имеет лидерство в читабельности и удобстве использования.
Это также может быть связано с тем фактом, что сегодня разработчики гораздо больше, чем в течение дни Unix, когда группа людей выпускала компьютерное программное обеспечение из одного офиса или их гаражей. Теперь мы четко перешли на фазу программирования на уровне сообщества.
Поскольку все больше и больше людей участвуют в создании одного куска кода, читаемость имеет больше приоритета, чем производительность.
Будущее программирования
Два самых популярных языков 21 -го века должны быть явно питоном и JavaScript. Два очень похожих языка, оба динамически напечатанные с достаточной гибкостью и огромной поддержкой сообщества, каким -то образом построили параллельно с появлением Интернета.
Каким будет преемник этих двух языков?
Увеличение человеческого взаимодействия с цифровыми технологиями, разговор, который начался в начале 1960 -х годов, только станет намного лучше. Аспект ИИ также попадет в сферу хардкорного программирования.
Я предсказываю язык с нейронной сетью в качестве ее интерпретатора, который компилируется для машинного кода на его очень низком уровне. Для встроенных людей, читающих это, я имею в виду промежуточный уровень представления. Начиная с базового синтаксиса Python или JavaScript или любого языка нашего выбора, интерпретатор изменит свое поведение относительно того, как вы, как программист, будут кодировать.
Вы фанат функций Fat Arrow из JavaScript? Или вы Dunder Fanatic, который любит управлять своими переменными в Python, новый переводчик будет оптимизировать ваш машинный код соответственно. Это будет набирать или, скорее, преобразовать код в ваш личный стиль кодирования, так что вся сложность оптимизации будет взята из вашего отставания, и вы можете просто продолжить разработку или написание кода, как вам угодно. Чем больше вы используете этого переводчика, тем больше он будет адаптироваться к вашему стилю кода.
Простой вариант использования
Давайте возьмем JS в качестве примера. Каждый двигатель, который использует ваш код JS, имеет шаг оптимизации. Так, например, при объявлении объекта с определенным набором атрибутов двигатели JS (V8, Spidermonkey и т. Д.) Скомпилируют его в конкретный тип объекта в машинном коде. Чем больше вы получаете доступ или называете этот объект, компилятор отмечает этот объект как «горячий» и пытается оптимизировать это. Так, как указывает Франзиска Здесь Всегда лучше объявить тип и использовать его последовательно.
Мой вопрос в том, почему?
Если к двигателю прикреплена нейронная сеть, которая записывает и контролирует мой стиль кодирования, то компилятор может безопасно оптимизировать на основе моего стиля кодирования.
Может быть, мне нравятся декларации случайных объектов, но не люблю функции в функциональных вызовах или иметь тонны слушателей событий. Компилятор может воспользоваться этим и сделать лучше или более быстрый код.
В сочетании с веб -сборкой мы могли бы попытаться сделать эту функцию по всему Интернету независимо от компьютерной архитектуры.
Разработчик 2020
С появлением нового десятилетия я лично, как программист, не могу дождаться, чтобы увидеть, как развернутся следующие десять лет. Программирование было волнующим, расширяющим возможности и, самое главное, действительно весело.
Когда -либо улучшая аппаратное мастерство и супер мозговые разработчики программного обеспечения, несомненно, будут продвигать факел вперед и достигать новых высот с помощью цифровых технологий.
И, может быть, однажды весь мир будет состоять из программистов!:)
Оригинал: “https://dev.to/athulmuralidhar/towards-language-agnostic-programing-4m9m”