Почему большинство высокоуровневых языков медленно работают


Оглавление (нажмите, чтобы открыть):

KVERNER

Matlab Simulink Python Java HELP Работы программиста профессионала

Что такое языки низкого, среднего и высокого уровня?

Языки программирования можно разделить на три широкие категории. Это языки высокого уровня, среднего уровня и низкого уровня. Эти три типа языков различаются в зависимости от различных характеристик.

Высокий уровень относится к языкам программирования, написанным таким образом, который может быть понят человеком. Они независимы, и программистам не нужно иметь никаких предварительных знаний об оборудовании, в котором будет использоваться программа. Примеры языков программирования высокого уровня включают C ++ и Python.

Языки среднего уровня служат мостом между аппаратным и программным уровнем компьютера. Они работают на уровне абстракции компьютера. С другой стороны, языки низкого уровня написаны для удовлетворения потребностей конкретной архитектуры компьютера и требований к оборудованию.

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

1. Скорость

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

С другой стороны, программы, написанные на языке высокого уровня, относительно медленнее. Основная причина этого — они написаны на человеческом языке. Это означает, что компьютер вынужден переводить и интерпретировать их на человеческом языке, прежде чем он их выполнит. Все эти процессы требуют много времени.

Скорость среднего уровня языка находится между языками высокого и низкого уровня. Это не слишком высоко или слишком низко.

2. Требование к памяти

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

3. Простота использования

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

С другой стороны, языки высокого уровня благоприятны для людей. Они состоят из английских заявлений, которые можно легко узнать и запомнить. Это объясняет, почему они являются наиболее популярным типом языка программирования.

4. Портативность

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

Языки высокого уровня не зависят от машины. Один код можно использовать на другой машине и даже на другой архитектуре без каких-либо трудностей. Это означает, что высокоуровневые языки программирования очень портативны. Вы можете перенести программу, написанную на высоком уровне, из одной среды в другую, и она все равно будет работать.

5. Абстракция

В этом контексте абстракция относится к взаимосвязи между языком и компьютерным оборудованием. Это минимальная или даже нулевая абстракция между низкоуровневыми языками с компьютерным оборудованием. Эти языки легко взаимодействуют с памятью компьютера и регистрируются.

Разрыв между языками среднего уровня и аппаратными средствами весьма значителен. Он больше, чем язык низкого уровня, но меньше, чем язык с языками высокого уровня.

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

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

Современные языки программирования: краткий обзор

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

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

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

Зачем нужны языки программирования

Без языка программирования ни один компьютер работать не будет. С его помощью создаются определенные математические алгоритмы, которые помогают компьютеру выполнять команды пользователя.

  • Язык программирования выглядит совсем не так, как мы привыкли представлять себе язык — это набор различных символов, которые преобразуются в понятный компьютеру код.
  • Классификация языков программирования от низких до высоких уровней зависит от того, настолько близок язык к человеку. Чем меньше язык программирования понятен человеку, тем по уровню он ниже.
  • Большая часть языков преобразуется в понятный машине код с помощью программ-трансляторов. С их помощью прописываются лексические, семантические и синтаксические правила, которые определят, какие действия запросит пользователь и внешний вид программы.
  • Язык программирования — неотъемлемая часть работы любого компьютера. В современном мире с ними работают программисты, которые прописывают коды и создают программы с использованием сложных кодовых конструкций.

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

История языков программирования

Первыми «ласточками» в истории языка программирования считаются такие обычные вещи, как музыкальная шкатулка или жаккардовый ткацкий станок. Они появились еще в XVIII-XIX веках.

Начало же современному программированию было дано в 1930-1940-е годы, когда были написаны лямбда-исчисление и машина Тьюринга. То время можно назвать началом истории разработки языков программирования, ведь компьютеры становились все популярнее. В 1940-е годы появились первые электрические компьютеры, и тогда же немецкий инженер Ц. Кузе разработал Планкалькюль, первый высокоуровневый язык.

В 1950-е годы были разработаны машинные коды, которые считаются языками программирования первого поколения. Но их приходилось переписывать для каждой ЭВМ отдельно, так что первым реально работающим языком программирования можно считать «Краткий код». Он первым стал представлять собой не набор математических кодов, а выражения, которые потом перерабатывались в код.

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

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

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

После того, как стал развиваться интернет в 1990-е годы, появились еще языки для написания веб-страниц. Сейчас развитие языков программирования идет по большей части в сторону безопасности пользователя.

Список языков программирования

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

Basic

Basic или Бейсик называют группу языков программирования высокого уровня. Его создали профессора колледжа Дартмут в 1964 году с целью помощи студентам в создании собственных компьютерных программ. Сейчас детище Томаса Курца и Джона Кемени стало основным языком, на котором пишутся программы для ОС Windows.

В далеком 1972 году Дэннис Ритчи придумал язык, который остается популярен и сейчас. Программисты любят его за успешное сочетание в нем элементов как высокого, так и низкого уровней программирования. Кстати, для тех языков программирования, которые используются для написания сайтов, основой является как раз язык Си.

Этот язык произошел от Си, но он больше уделяет внимание обобщенному программированию. Сейчас он является одним из самых популярных языков, ведь на нем пишут огромное количество программ. Он подходит для создания ОС, драйверов, серверов, игр, прикладных программ и много другого. Си ++ является универсальным языком, который эффективен, многофункционален и доступен большинству программистов.

Python

Разработка этого языка началась в 1980-х годах голландцем Гвидо ван Россумом, но его первая версия была выпущена только в 2008 году. Он отличается постоянным усовершенствованием и активным сообществом пользователей. Python является высокоуровневым языком с большим объемом различных функций. Особенно хорошо он справляется с веб-разработкой, анализом данных и автоматизацией процессов.

Этот язык лидирует среди тех, что применяются в разработке веб-сайтов и поддерживается практически всеми хостинг-провайдерами. Он применяется, в основном, для разработки веб-сайтов и веб-приложений. Впервые PHP был представлен публике в 1995 году датским программистом Расмусом Лердорфом.

Язык программирования Java работает с веб-приложениями, которые транслируются в байт-код. Он может работать на любой компьютерной архитектуре, так как код преобразуется с помощью Java-машины. Он появился в 1996 году и последние годы он стал самым популярным языком программирования. Однако многие недовольны из-за того, что он работает медленнее, чем его конкуренты.

JavaScript

Хотя JavaScript похож на Java, но все же является отдельным языком. Чаще всего используется в качестве встраиваемого языка: приложения получают доступ к веб-страницам с его помощью. Он более легок в применении и дается даже тем, кто мало знаком с программированием. Доля его использования ежегодно растет.

Go (Golang)

В 2007 году компания Google занялась разработкой собственного языка программирования, с помощью которого бы можно было решать реальные проблемы. Созданием языка занимались Роб Пайк и Кен Томпсон, которые уже в 2009 году представили Go. Для компании Google он является заменой популярных языков Си и Си ++. Он не стал прорывом, но зато используется для создания серьезных проектов.

Этот язык программирования является системой, с помощью которой можно удобно управлять базами данных. Первые разработки были начаты еще в 1970-х годов, но первый вариант SQL был представлен в 1986 году. В современном мире SQL довольно популярен в качестве удобного языка для улучшения, управления и создания баз данных.

Swift

Компания Apple тоже придумала собственный язык программирования, чтобы создавать на нем приложения для всех родственных гаджетов. Apple представила свой язык в 2014 году как удобный, надежный, свободный и доступный любому программисту. Он был создан персонально для продуктов Apple.

Pascal

Никлаус Вирт создал этот язык в 1969 году, а назвали язык в честь математика Блеза Паскаля. Он является популярным языком программирования и в наши дни. Именно на нем обучают студентов на первом курсе университета и в старшей школе. На его основе построено множество других языков.

В современном мире без языков программирования невозможно обойтись. Все больше и больше людей самостоятельно выбирают профессию программиста, хоть она и сложна на первый взгляд, но быстро развивается и становится популярной с каждым годом. А языки программирования — сложный, но интересный процесс создания компьютерного мира!

Нравится статья? Поддержи наш проект и поделись с друзьями!

Является ли медленная работа языков программирования действительно плохой вещью? [закрыто]

Вот как я это вижу.

Существует машинный код , и это все, что нужно компьютерам для запуска чего-либо. Компьютеры не заботятся о языках программирования. Для них не имеет значения, идет ли машинный код из Perl, Python или PHP. Языки программирования не обслуживают компьютеры. Они служат программистам.

Некоторые языки программирования работают медленнее, чем другие, но это не обязательно потому, что с ними что-то не так. Во многих случаях это происходит потому, что они делают больше вещей, которые в противном случае должны были бы делать программисты (например, управление памятью), и, выполняя эти вещи, они лучше справляются со своими обязанностями — обслуживают программистов.

Так что, на самом деле, медленная производительность языков программирования — это плохо?

14 ответов

Я не думаю, что это автоматически плохо. Python медленнее, чем C ++, но когда оба они достаточно быстрые , Python может быть лучшим выбором для рассматриваемой проблемы, даже если он медленнее .

Это всегда компромисс. Для небольших одноразовых задач гораздо быстрее написать сценарий Python, чем приложение C ++, которое делает то же самое (типичным примером для меня будет какая-то пакетная обработка текста или обход дерева каталогов и выполнение каких-либо действий с файлами), и мне все равно, занимает ли это 10 мс или 1000 мс, даже если это в 100 раз медленнее, потому что на написание и тестирование у меня уходит половину времени.

Конечно, было бы неплохо, если бы Python работал так же быстро, как C ++, поэтому в этом смысле я согласен с вашим утверждением, что «slow = bad». Но тогда у меня есть мощный язык, который работает так быстро, как я хочу, не выполняя некоторые действия (скажем, проверку границ массивов на необработанных массивах), пока он позволяет мне решить, когда сделать этот компромисс (скажем, с помощью std: :. вектор)

Мастер Йода рекомендует:  Обзор конструктора uKit - возможности, примеры сайтов, ценовая политика

Довольно просто — медлительность — это плохо.

когда программа требует определенного уровня производительности

потому что без этой производительности вы не выполняете требования.

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

Посмотрите на это так: компьютеры глупы . Они с трудом следуют инструкциям, которым может следовать любой придурок с таблицей триггеров. Они упорно настаивают на том, что вы сказали, вместо того, что вы имели в виду. Не клочок самонаправления или интуиции. Это ужасно.

Единственное, что есть у компьютера, это быстро. В самом деле! Ножка с картотекой может выполнять ту же работу, что и база данных. Какой-то парень, заводящий печатный станок, может делать то же, что и Apache. Шутки в сторону! И они действительно, на протяжении сотен и сотен лет, на самом деле. Почему компьютер хорош для НИЧЕГО, так это его скорость.

Таким образом, язык программирования, который (по сравнению с другими языками) не может использовать, не имеет единственного преимущества использования компьютеров.

Язык программирования может быть очень высокого уровня, «делать много», но все равно быть очень быстрым. OCaml — это язык более высокого уровня, чем PHP, но он генерирует код почти так же быстро, как C. Javascript так же динамичен, как PHP, но он может быть выполнен очень быстро. Так что это в основном проблема с языковой реализацией, а не с дизайном. Динамические языки сложнее реализовать эффективно, но не невозможно.

Скорость может быть измерена с точки зрения времени выполнения, начального времени разработки и времени обслуживания (времени, необходимого для обработки проблем / ошибок, создания нового кода и его развертывания).

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


Поэтому многое зависит от скорости, которая вам нужна.

Контекст тоже важен. Загрузка вашей первоначальной конфигурации за 0,5 секунды вместо 0,1 секунды не представляет особой проблемы, но во время выполнения для выполнения запроса вместо 0,1 секунды может потребоваться 0,5 секунды, а для обработки 100 запросов может потребоваться больше усилий, то есть 50 секунд вместо 10.

Просто — клиенты любят быстрое программное обеспечение. На самом деле вся цель компьютеров — это быстрые вычисления.

Медленный относительный. Если у меня есть требование читать порт 10 раз в секунду, язык, который не может создать двоичный файл, который может это делать, является слишком медленным. Если да, то я пишу веб-приложение, в котором последовательность запросов / ответов между сервером и браузером / клиентом измеряется в секундах, и пользователь, скорее всего, потратит минуты на экран, прежде чем нажать кнопку, язык программирования, который может обрабатывать обработку запроса. в 1 секунду, вероятно, достаточно быстро (большинство, конечно, гораздо быстрее).

Конечно, язык программирования может быть фактором, определяющим скорость выполнения, но это будет не сам язык, а компиляторы и / или среды выполнения, которые идут с ним. Это ясно видно на примере разработки Java, где производительность JVM (даже в идентичных аппаратных средах) с годами радикально возросла. И, конечно, всегда можно написать ужасно медленный код в любой среде, которую вы выберете. Так как такие утверждения, как «C ++ в десять раз быстрее, чем Java», автоматически являются фальшивыми, если они не уточнены и количественно не определены, какие именно условия были проверены и как. В равной степени возможно создать тест, в котором Java работает быстрее, чем C ++, все зависит от того, что вы используете в качестве тестового кода и как вы его выполняете.

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

Если вам просто нужен маленький личный инструмент, чтобы сделать что-то один раз, он может быть настолько медленным, насколько вы хотите. Но как только вы начинаете развертывание для пользователей, они заботятся о скорости и масштабировании, особенно если они собираются использовать его повторно. (Например, установщик может быть медленным; лучше не устанавливать программу, которую он устанавливает.) И это не только язык; это программа в целом. Если ваша программа работает медленно, пользователям это не понравится. И если у вас есть конкуренция, пользователям не нравится ваша программа, это очень плохо. Так что язык, который помогает пользователям не любить вашу программу (делая ее медленной), плохой.

Я являюсь частью команды, которая пишет управляющее программное обеспечение для вещательных СМИ. Существует большая вероятность того, что ваш любимый телевизор или радиостанция работает на нем, если вы находитесь в США. Производительность — это одна из вещей, о которой мы чаще всего слышим от клиентов. Первоначально он был написан для небольших операций на одной станции, но теперь мы подписываем крупные вещательные и кабельные сети с сотнями каналов, и масштабирование начинает становиться проблемой. Если мы не сможем заставить их работать быстро, они передадут свои многомиллионные контракты людям, которые могут, и мы останемся без работы. Вот почему мы используем быстрый, скомпилированный язык и оптимизируем наши базы данных.

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

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

Так что скорость на самом деле важна для многих программ. Медленные языки в настоящее время считаются «плохими», потому что они действительно слишком медленные (Python может быть в 50-100 раз медленнее, и это слишком много)

Programming languages exist to serve programmers.

Я не знаю, как вы пришли к такому выводу. Я бы сказал: инженеры-программисты используют языки программирования для своих нужд.

Some programming languages are slower then other but that’s not because there is something wrong with them.

Это также ненормальное утверждение. Определите, что вы имеете в виду, используя здесь слово «медленнее». Медленнее может означать:

  1. Финальные программы, которые достигают то же самое, запустить «медленнее» в одном язык по сравнению с другим.
  2. Время, затрачиваемое на создание окончательной программы, может быть больше (следовательно, некоторые описывают ее как «более медленную»).

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

Как и любое программное обеспечение, медлительность может быть признаком основных проблем / плохого дизайна. По общему признанию, дизайн — немного дух времени, но это не умаляет того факта, что принципы дизайна, на которых он сейчас основывается, устарели и считаются «плохими».

Взять, к примеру, классический ASP и ASP.net.

Кто-то заметил, что «Клиенты любят программное обеспечение, которое соответствует требованиям и в рамках бюджета». Что ж, это правда — но это имеет отношение к медленному программному обеспечению, и это почти по определению означает более медленные языки программирования (и платформы), алгоритмы и конфигурацию. Медленный язык программирования, возможно, является наиболее важной частью всего вышеперечисленного просто потому, что он является основой, из которой вам будет сложнее всего изменить. Если вы используете БД Oracle и вам нужно больше возможностей, вы можете оптимизировать таблицы / index / и т. Д. Легко. Если у вас плохой алгоритм в коде, вы можете написать другой код. Если ваш фреймворк медленный, вы можете заменить его — это не так просто, но это выполнимо без переписывания всего. Если ваш язык слишком медленный, вы должны начать практически заново.

См. Facebook для получения информации о хлопотах, которые заставили PHP работать достаточно быстро, когда им нужно было масштабироваться.

Для остальных из нас «нефункциональные требования к производительности» часто записываются в спецификации, особенно для масштабируемых веб-приложений. Невыполнение «страница должна отображаться пользователю в течение 2 секунд после запроса», и вы теряете контракт (или платите штрафы). Итак, клиенты любят программное обеспечение, которое выполняет требования — и эти запросы скажут, что это должно быть быстро (вам может быть все равно, сколько времени пользователи тратят, глядя на песочные часы, но покупатель наверняка это делает — это огромные затраты).

Например, в крупном колл-центре мне сказали, что они определили, что за каждую секунду, которую вы можете сэкономить на процессе приема звонков, 1 колтакер может быть «сокращен». Внезапно это реальные деньги и огромный стимул для начальства получить более быстрое, эффективное и удобное в использовании программное обеспечение.

Много времени было потрачено на то, чтобы программисты производили код как можно быстрее (а затем все время выполняли модульное тестирование и рефакторинг, смеется). Я обнаружил, что это не такой важный фактор, как думают люди — если вы эксперт в своем языке, вы можете написать его гораздо быстрее, чем если вы неопытны. Таким образом, опытный разработчик C ++ может писать код быстрее и точнее, чем начинающий PHP-разработчик. Поэтому я думаю, что стать экспертом важнее, чем выбрать «легкий» язык, и поэтому мне не нравится культ «переписать в классной, новой вещи», который, кажется, повсюду сегодня.

Я укажу, что большинство проблем с производительностью существуют потому, что программист сделал плохую работу, а не потому, что язык был слишком медленным. На самом деле, есть гораздо больше уместных проблем с производительностью, чем выбранный вами язык. Это будет примерно номер 1 203 407-й в моем списке.

So, is slower performance, of programming languages, really, a bad thing?

При прочих равных, идти быстрее — это хорошо. В конце концов, никто не хочет больше ждать каких-то результатов, и как только этот результат будет достигнут, он может высвободить ресурсы для других целей.

Но не все остальное равно. Для начала также важно получить правильный результат или, по крайней мере, достаточно правильный. (Если допускаются совершенно неправильные результаты, вы можете действительно их получить очень быстро, и они будут иметь абсолютно нулевое значение для любого.) Если переход на несколько более медленный язык повышает вероятность получения правильного результата, это обычно отличный компромисс. Языки более высокого уровня имеют здесь преимущество перед языками более низкого уровня, поскольку их более богатый набор моделей обычно облегчает выражение сложной проблемы без подавляющего количества явных деталей.

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

И последнее ключевое замечание: нет необходимости использовать только один язык , и что во многих программных системах большинство компонентов не являются критичными для производительности. Использование низкоуровневого языка для производства высокопроизводительных компонентов для критических битов целесообразно, а менее важные части — для языка высокого уровня (чтобы минимизировать затраты на их создание) в высшей степени целесообразно. Более того, функции, которые делают хороший язык низкого уровня (способность точно контролировать, что делает машина), не являются функциями, которые делают хороший язык высокого уровня (способность выводить детали из гораздо меньших описаний): они диаметрально противоположны, так что возможность соединить их вместе и использовать их для своих сильных сторон и избежать их слабостей, это действительно здорово.

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

hitfounder

Путь программиста

Рассуждаю о культуре программирования

Решил посоображать на тему сабжа. Поводом послужила заметка Do you really need to know C? Ответ мне лично очевиден, он будет озвучен в конце, а пока некоторые размышления. Конечно формально С не является языком низкого уровня, однако в силу ряда особенностей лишь в одном единственном узком смысле в рамках этого топика я буду называть его именно так.

Итак, господин Джефф Этвуд (Jeff Atwood) и товарищ Джоэль Спольски (Joel Spolsky) сошлись в очной беседе в формате подкаста для сайта StackOverflow. В один прекрасный момент речь зашла о необходимости изучения С и мнения собеседников разошлись. Некоторые аргументы были приведены Джефом, хотя они не звучали слишком убедительно. Защита была построена на тезисе отсутствия необходимости в низкоуровневых языках в повседневной работе. Спольски успешно парировал выпады оппонента, настаивая на том, что низкоуровневый язык дает для программиста основу даже при использовании языков более высокого уровня.

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

1. Работа с памятью. Большинство программистов, владеющих лишь знаниями Java, C# и подобных даже не догадываются о многих тонкостях работы с памятью. Конечно, языки с высокой степенью абстрагирования были призваны освободить программиста от этих знаний, но не бывает ничего абсолютного. Сборщик мусора иногда делает интересные вещи, и программа неожиданно начинает расходовать нереальные объемы памяти, здесь пригодились бы знания о механизмах выделения и очистки памяти. Бывают также ситуации когда необходимо объединять в одну программу гетерогенные компоненты, а как же это сделать если используются родные регулярные win32 библиотеки, которые слыхом не слыхивали о NET и C#. Обмен данными между ними должен происходить через незащищенную область памяти, а тут без знаний низкоуровневых механизмов не обойтись.

Мастер Йода рекомендует:  Премиум-реклама в Facebook продолжает дорожать

2. Создание мультипоточных приложений. Современные языки предоставляют очень высокий уровень абстракций для создания потоков. Однако не лишним было бы знать о концепциях thread safe пришедших из языков предыдущего поколения. В конечном счете, это во много раз сократит время на отладку многопоточного приложения, которое по своей сути является сложным для понимания.

3. Общее понимание. Мало кто советует гнаться за эффективностью, т.к. в большинстве случаев это приводит к преждевременной оптимизации. Тем более не стоит пользоваться низкоуровневой оптимизацией, которая редко приносит значительный выигрыш, с огромными затратами труда. Но здесь стоит коснуться такого забытого многими языка как Assembler — именно он и является низкоровневым во всех смыслах. Так вот его знание совершенно необходимо для глубокого понимания вычислительной машины в целом. Без знания архитектуры процессора систем адресации памяти и механизмов ввода/вывода программировать на asm невозможно. Конечно, знание этого языка очень специализировано и ограничено лишь одним процессором и одной архитектурой, но оно дает общее представление о том, что можно ожидать от других производителей в настоящем и будущем. В идеале желательно освоить asm какого-нибудь RISC процессора, к примеру ARM, для сравнения. Но это только для особо фанатичных. Для чего нужно знание asm если он не используется в работе? Нет, не для оптимизации, а для того чтобы уверенно разбираться во всех тонкостях работы вычислительной машины.

Итак, думаю, ответ очевиден. Изучать низкоуровневые языки стоит даже в том случае, если они не используются в повседневной работе. Здесь возникают лишь трудности с освоением достаточно сложного материала, поэтому в обязательном порядке изучение таких языков должно даваться в университете, для фундаментального образования это необходимо.

Почему, несмотря на доступность знаний, мы не становимся умнее

Ребята, мы вкладываем душу в AdMe.ru. Cпасибо за то,
что открываете эту красоту. Спасибо за вдохновение и мурашки.
Присоединяйтесь к нам в Facebook и ВКонтакте

Согласно результатам исследования, проведенного американской компанией Dell EMC, объем мировой информации увеличивается более чем в 2 раза каждые 2 года и уже измеряется зеттабайтами. Только представьте себе: 1 зеттабайт получится, если все жители США будут печатать по 2 твита в минуту 30 тыс. лет без передышки. Казалось бы, оперируя такими объемами знаний, при этом легкодоступных благодаря интернету, люди должны были давно стать гениями. Однако ситуация складывается едва ли не с точностью до наоборот. И в этой статье мы расскажем почему.

AdMe.ru собрал несколько научных фактов, объясняющих, при каких условиях информация работает на повышение интеллекта, а при каких просто захламляет сознание.

Темпы роста объема информации в мире согласно докладу IDC’s Digital Universe
Study, сделанному по заказу EMC в 2011 году.

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

Согласно опросам, лишь 13 % пользователей применяют цифровые технологии и доступ к ресурсам для самообразования, а работодатели по всему миру бьют тревогу из-за синдрома выгорания и низкой эффективности своих суперпрофессиональных с точки зрения цифровой грамотности сотрудников.

Переизбыток бесполезной информации быстро превращает ее из источника мудрости в источник опасности под названием «информационная перегрузка». Когда-то это был научный термин из области когнитивной психологии, а в наши дни он стал расхожей метафорой, которая вышла далеко за пределы науки и теперь обозначает массовое явление.

Почему же эта информационная перегрузка мешает нам стать умнее? Вот основные причины.

1. Поток разнородной информации рассеивает внимание и не дает сосредоточиться на главном

Это доказал эксперимент «Инфомания», который несколько лет назад провел среди офисных сотрудников английский психолог Гленн Уилсон. Часть из них занималась своими прямыми обязанностями, а часть постоянно прерывалась на СМС, звонки и проверку почты. В конце дня анализ IQ показал, что у испытуемых из 2-й группы он был снижен на 10 пунктов.

И действительно, в наши дни проверка электронной почты стала синонимом работы. Согласно докладу «Социальная экономика» Глобального института McKinsey за июль 2012 года, средний работник тратит на управление электронной почтой 28 % своего рабочего дня. Времени на обучение, получение новых знаний и обретение новых навыков попросту не остается.

2. Доступность информации избавляет от необходимости ее запоминать

Ученые из Колумбийского университета обнаружили, что люди лучше запоминают источник информации (папки, диски, сайты), чем саму эту информацию. Они провели эксперимент, в ходе которого студентам поручили напечатать несколько простых фактов (например, что мозг страуса меньше, чем его глаз), но половине участников как бы между прочим сказали, что их файлы после работы не будут сохранены. Второй группе об этом ничего не сообщили, поэтому испытуемые были уверены, что смогут вновь перечитать файл.

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

Почему Языки Интерпретируются медленно?

Я читал о плюсах и минусах интерпретируемых языков, и одним из наиболее распространенных недостатков является медленность, но почему программы на интерпретируемых языках медленнее?

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

Интерпретированные языки — это просто «интерпретируемые». Некоторая другая форма инструкции считывается и интерпретируется во время выполнения, которая, в свою очередь, выполняет нативные машинные инструкции.

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

Обратите внимание, что то, что я описываю выше, — это когда язык работает в интерпретаторе. Существуют интерпретаторы для многих языков, в которых есть также встроенные компоновщики для создания собственных машинных инструкций. Уменьшение скорости (но размер этого может быть) применяется только к интерпретируемому контексту.

Итак, немного неверно сказать, что язык медленный, скорее это контекст, в котором он работает, который медленный.

С# не является интерпретируемым языком, хотя в нем используется промежуточный язык (IL), перед выполнением его выполняются JIT до нативных инструкций, поэтому он имеет некоторую скорость уменьшения скорости, но не все, но я ‘ d, что если вы построили полноценный интерпретатор для С# или С++, он будет работать медленнее, а также.

И просто чтобы быть ясным, когда я говорю «медленный», это, конечно, относительный термин.

Все ответы, кажется, пропустят настоящий важный момент здесь. Это подробная информация о том, как реализован «интерпретируемый» код.

Интерпретированные языки медленнее, потому что их метод, объект и модель глобального пространства переменных динамичны. Это требует большого количества дополнительных запросов хэш-таблицы для каждого доступа к вызову переменной или метода. Именно здесь большую часть времени проводят. Это болезненный случайный поиск в памяти, который действительно болит, когда вы получаете кеш-промах L1/L2.

Google Javascript Core8 настолько быстр и нацелен почти на скорость C для простой оптимизации: они берут модель данных объекта как фиксированную и создают внутренний код для доступа к ней, как структура данных собственной скомпилированной программы. Когда новая переменная или метод добавляются или удаляются, весь скомпилированный код отбрасывается и скомпилируется снова.

Этот метод хорошо объяснен в документе Deutsch/Schiffman «Эффективное внедрение системы Smalltalk-80».

Вопрос, почему php, python и ruby ​​не делают этого, довольно просто ответить: техника чрезвычайно сложна для реализации.

И только у Google есть деньги для оплаты JavaScript, потому что быстрый интерпретатор JavaScript на основе браузера — это их основная потребность в их бизнес-модели на миллиард долларов.

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

Короткий ответ заключается в том, что скомпилированные языки выполняются машинными инструкциями, тогда как интерпретируемые выполняются программой (написанной на компилированном языке), которая читает либо источник, либо байт-код, а затем по существу имитирует гипотетическую машину, которая имела бы запустите программу напрямую, если машина существует.

Подумайте о интерпретируемой среде исполнения как эмуляторе для машины, которой на данный момент не существует.

Это явно осложняется компиляторами JIT (Just In Time), которые имеют Java, С# и другие. Теоретически они так же хороши, как компиляторы «AOT» ( «В одно время» ), но на практике эти языки работают медленнее и имеют недостатки, требуя, чтобы компилятор работал с использованием памяти и времени во время выполнения программы. Но если вы скажете, что любой из них здесь, на SO, должен быть готов привлечь бешеных защитников JIT, которые настаивают на отсутствии теоретической разницы между JIT и AOT. Если вы спросите их, будут ли Java и С# такими же быстрыми, как C и С++, тогда они начинают немного оправдываться и немного успокаиваться.: -)

Итак, С++ полностью управляет играми, в которых максимальное количество доступных вычислений всегда можно использовать.

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

Это хороший вопрос, но, по моему мнению, его следует сформулировать немного иначе, например: «Почему интерпретируемые языки медленнее, чем скомпилированные языки?»

Я думаю, что распространенное заблуждение, что интерпретируемые языки медленны как таковые. Интерпретированные языки не медленны, но, в зависимости от варианта использования, может быть медленнее, чем скомпилированная версия. В большинстве случаев интерпретируемые языки на самом деле достаточно быстро!


«Достаточно быстро», плюс увеличение производительности от использования языка, такого как Python, например, C должно быть достаточным обоснованием для интерпретации языка. Кроме того, вы всегда можете заменить определенные части вашей интерпретируемой программы быстрой реализацией C, если вам действительно нужна скорость. Но опять же, сначала измерьте и определите, является ли скорость действительно проблемой, а затем оптимизируйте.

Петля 100 раз, содержимое цикла интерпретируется 100 раз в код низкого уровня.

Не кэшируется, не используется повторно, не оптимизируется.

Проще говоря, компилятор однажды интерпретирует код низкого уровня

Изменить, после комментариев:

  • JIT — это скомпилированный код, не интерпретируемый. Он просто скомпилирован позже не вверх
  • Я имею в виду классическое определение, а не современные практические реализации

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

Простой вопрос, без реального простого ответа. Суть в том, что все компьютеры на самом деле «понимают» — это двоичные инструкции, что и означает «быстрые» языки, такие как C.

Тогда есть виртуальные машины, которые понимают разные бинарные инструкции (например, Java и .NET), но они должны быть переведены «на лету» на машинные инструкции с помощью Just-In-Compiler (JIT). Это почти так же быстро (даже быстрее в некоторых конкретных случаях, поскольку JIT имеет больше информации, чем статический компилятор о том, как используется код.)

Затем существуют интерпретируемые языки, которые обычно также имеют свои собственные промежуточные двоичные инструкции, но интерпретатор функционирует так же, как цикл с большим оператором switch в нем с аргументом для каждой инструкции и как его выполнять. Этот уровень абстракции над базовым машинным кодом медленный. Есть больше инструкций, длинные цепочки вызовов функций в интерпретаторе, чтобы сделать даже простые вещи, и можно утверждать, что память и кеш не используются так эффективно, как результат.

Но интерпретируемые языки часто бывают достаточно быстрыми для тех целей, для которых они используются. Веб-приложения неизменно связаны IO (обычно доступ к базе данных), который на порядок медленнее любого интерпретатора.

Нет такой вещи, как интерпретируемый язык. Любой язык может быть реализован интерпретатором или компилятором. В наши дни большинство языков имеют реализации с использованием компилятора.

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

Обработан интерпретируемый язык во время выполнения. Каждая строка читается, анализируется и выполняется. Того, чтобы перерабатывать линию каждый раз в цикле это то, что делает интерпретируемые языки такими медленный. Эти накладные расходы означают, что интерпретируемый код работает от 5 до 10 раза медленнее, чем скомпилированный код. интерпретируемые языки, такие как Basic или JavaScript является самым медленным. Их преимущество не нужно перекомпилировать после изменений и когда вы учитесь программировать.

В 5-10 раз медленнее не обязательно верно для таких языков, как Java и С#. Они интерпретируются, но компиляторы «точно в срок» могут генерировать инструкции машинного языка для некоторых операций, ускоряя ситуацию резко (рядом со скоростью скомпилированный язык время от времени).

Интерпретированные языки должны читать и интерпретировать исходный код во время выполнения. С скомпилированным кодом большая часть этой интерпретации выполняется заранее (во время компиляции).

В настоящее время «интерпретируется» очень мало современных языков сценариев; они обычно компилируются «на лету», либо в машинный код, либо на некоторый промежуточный язык байт-кода, который (более эффективно) выполняется на виртуальной машине.

Мастер Йода рекомендует:  Что нужно изучить, чтобы быть востребованным

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

Это соответствующая идея в этой статье для вашей проблемы.

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

По той же причине, что он медленнее разговаривает через переводчик, чем на родном языке. Или, читая со словарем. Требуется время для перевода.

Обновление: нет, я не видел, чтобы мой ответ был таким же, как и принятый, до степени; -)

Да, интерпретируемые языки медленны.

Однако рассмотрим следующее. У меня возникла проблема. Мне потребовалось 4 минуты, чтобы решить проблему на Python, и программа заняла 0.15 секунды. Затем я попытался записать его на C, и я получил время работы 0,12 секунды, и мне потребовалось 1 час, чтобы написать его. Все это потому, что практический способ решения проблемы заключался в использовании хеш-таблиц, и хэш-таблица в любом случае доминировала в среде выполнения.

Интерпретация кода выполняется медленнее, чем запуск скомпилированного кода, потому что интерпретатор должен анализировать каждый оператор в программе каждый раз, когда он выполняется, а затем выполняет требуемое действие, тогда как скомпилированный код просто выполняет действие в определенном контексте по компиляции. Этот анализ времени выполнения известен как «интерпретационные накладные расходы». Доступ к переменным также медленнее в интерпретаторе, потому что отображение идентификаторов в места хранения должно выполняться повторно во время выполнения, а не во время компиляции.

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

В Java, хотя он рассматривается как интерпретируемый язык, он использует компиляцию JIT (Just-in-Time), которая смягчает вышеупомянутую проблему используя метод кэширования для кэширования скомпилированного байт-кода.

Компилятор JIT читает байт-коды во многих разделах (или полностью, редко) и динамически компилирует их в машинный код, чтобы программа могла работать быстрее. Это можно сделать для каждого файла, для каждой функции или даже для любого произвольного фрагмента кода; код может быть скомпилирован, когда он будет запущен (отсюда и название «точно в срок» ), а затем кэшируется и повторно используется позже, без необходимости перекомпилировать.

ТЫ, Я и ИНФОРМАТИКА

Еще одно популярное деление языков программирования – это деление на низкоуровневые и высокоуровневые языки программирования.

Низкоуровневые языки программирования близки к машинным языкам, они содержат набор машинных команд, записанных по правилам этого языка, а также директивы, макросы и другие элементы. Это, прежде всего, языки ассемблера и различные псевдокоды.

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

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

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

Особняком стоит язык «С», который по своему синтаксису является языком высокого уровня, но в его состав входят операции, позволяющие работать с отдельными байтами и битами, как это делают языки низкого уровня. Поэтому многие специалисты относят язык «С» к языкам никого уровня, иногда называя даже «переносным ассемблером».

Существует ли язык высокого уровня, который устойчиво быстрее C?

Возможно ли сделать язык программирования, который не будет содержать платформ-зависимых операций, но при этом позволит получить у готовой программы производительность не меньше чем у оптимально написанной программы на C?

Понятно что существует ассемблер, программу на котором можно сделать настолько быстрой, насколько это вообще возможно для данной машины за счёт контроля каждого байтика, но речь не о нём — я говорю о языке высокого уровня, который полностью абстрагируется от машины, так чтобы программа на нём могла быть скомпилирована на любой машине и для любой ОС.

Так вот, возможно ли сделать такой язык? Если да, то в каком направлении копать?

А может уже существуют такие языки, просто из-за популярности C на них мало кто пишет, поскольку всплывают проблемы совместимости с существующей базой уже готового кода?

А как-же хорошенько разогретая JVM!

Да, Z. Но в этой ветке времени его еще не изобрели.

Возможно ли сделать язык программирования, который не будет содержать платформ-зависимых операций, но при этом позволит получить у готовой программы производительность не меньше чем у оптимально написанной программы на C?

Только если компилятор этого языка будет содержать ИИ

Только если компилятор этого языка будет содержать ИИ

Дай определение ИИ. GCC содержит ИИ?

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

В принципе, некоторые утверждают, что компиляторы Фортран могут выдать неплохой код. Я сам не сравнивал, на Фортране не писал ничего с 1992-1993 года. Разузнай.

ATS Но это такой DSL который все равно компилируется в С пусть и нечитаемый. Staln Схема которая пытается прожевать все доступные исходники включая стандартную библиотеку. Лиспы имеющие на борту компилятор вобще могут сгенерерировать код более лучший чем C вобще для частногох набора входных данных. Выиграш как правило все равно не превышает 10% так что на статистику не очень влияет.

Вот определение с википедии

Искусственный интеллект — свойство интеллектуальных систем выполнять творческие функции, которые традиционно считаются прерогативой человека.

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

Или вот представь что у тебя есть некий высокоуровневый язык с jit eval-ом. Ты сделал консольный калькулятор. Пользователь вводит

А если у тебя будет искусственный интеллект, он каким-то сложным творческим способом должен будет понять, что вот тут-то этот jit eval используется только лишь для генерации кода для математических формул, функций одной переменной. И этот ИИ должен быть в состоянии сделать специализированный компилятор, узкозаточенный под конкретно эту область, который работает быстрее чем более общий компилятор.

Высокоуровневый язык программирования

Высокоуровневый язык программирования — язык программирования, разработанный для быстроты и удобства использования программистом. Основная черта высокоуровневых языков — это абстракция, то есть введение смысловых конструкций, кратко описывающих такие структуры данных и операции над ними, описания которых на машинном коде (или другом низкоуровневом языке программирования) очень длинны и сложны для понимания.

Высокоуровневые языки программирования были разработаны для платформенной независимости алгоритмов. Зависимость от платформы перекладывается на инструментальные программы — трансляторы, компилирующие текст, написанный на языке высокого уровня, в элементарные машинные команды (инструкции). Поэтому, для каждой платформы разрабатывается платформенно — уникальный транслятор для каждого высокоуровневого языка, например, переводящий текст, написанный на Delphi в элементарные команды микропроцессоров семейства x86.

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

Такого рода оторванность высокоуровневых языков от аппаратной реализации компьютера помимо множества плюсов имеет и минусы. В частности, она не позволяет создавать простые и точные инструкции к используемому оборудованию. Программы, написанные на языках высокого уровня, проще для понимания программистом, но менее эффективны, чем их аналоги, создаваемые при помощи низкоуровневых языков. Одним из следствий этого стало добавление поддержки того или иного языка низкого уровня (язык ассемблера) в ряд современных профессиональных высокоуровневых языков программирования.

Примеры: C++, C#, Java, JavaScript, Python, PHP, Ruby, Perl, Паскаль, Delphi, Лисп. Языкам высокого уровня свойственно умение работать с комплексными структурами данных. В большинстве из них интегрирована поддержка строковых типов, объектов, операций файлового ввода-вывода и т. п.

Первым языком программирования высокого уровня считается компьютерный язык Plankalkül, разработанный немецким инженером Конрадом Цузе ещё в период 1942—1946 годах. Однако транслятора для него не существовало до 2000 года. Первым в мире транслятором языка высокого уровня является ПП (Программирующая Программа), он же ПП-1, успешно испытанный в 1954 году. Транслятор ПП-2 (1955 год, 4-й в мире транслятор) уже был оптимизирующим и содержал собственный загрузчик и отладчик, библиотеку стандартных процедур, а транслятор ПП для ЭВМ Стрела-4 уже содержал и компоновщик (linker) из модулей. Однако, широкое применение высокоуровневых языков началось с возникновением Фортрана и созданием компилятора для этого языка (1957)

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Учись учиться, не учась! 10374 — | 7883 — или читать все.

3 причины, зачем изучать Си в 2020 году

Сразу должен оговориться — я просто люблю программировать.

Зачем изучать Си в 2020 году, если есть множество других языков, на которых писать гораздо проще и меньше шанс выстрелить себе в ногу? Ведь есть же языки, на которых писать еще сложнее — в эзотерических языках есть целые кучи условностей и ограничений, писать неудобно, но люди почему-то их изучают и даже пытаются решать какие-то задачи. Си тоже можно изучать как эзотерический язык. Он достаточно минималистичный, в нем нет очень многих уже привычных вещей, например даже списки делать приходится самостоятельно. Как и в других эзотерических языках в нем есть непривычные концепции вроде ручного управления памятью или отображением файла на память.

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

Для меня это было бы главной причиной для его изучения.

А вот дальше начинают появляться новые приятные следствия.

Знаешь Си — знаешь как все работает

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

Но это понимание тонкостей и знание того, как программы на самом деле выполняются на реальных компьютерах, на самом деле является очень полезным в некоторых областях. Обычно говорят о том, что в этих областях приходится писать на Си. Это не совсем правда. Скорее в этих областях надо знать все то, что приходит с изучением Си. А писать можно много на чем — С, С++, go, rust, наверняка еще много всего.

Обо всех тех случаях, когда есть какие-то требования к самой программе, а не только к тому, как она работает. Когда программа должна удовлетворять определенным условиям — скорость, размер или определенный бинарный формат экспортируемых функций, если это библиотека.

Нет ничего быстрее Си

Сейчас часто говорят о том, что рабочее время программиста стоит больше, чем дополнительная память или более мощный процессор. Но для меня размер и скорость работы программы значат очень многое. Я очень не люблю, когда программа тратит неоправданное количество памяти или работает неоправданно медленно. И вдвойне не люблю, если это моя программа. При использовании Си я имею возможность удовлетворить свое стремление к идеальной программе. Как это сочетается с бизнес-целями? Мне просто повезло найти такую работу, где это важно. А вообще, это очень полезно в embedded разработке, где каждый байт и каждая миллисекунда на счету. Например в том же IoT.

Си может ускорить программы на других языках

С библиотеками все немного сложнее. Требования к бинарному формату начинаются тогда, когда возникает необходимость связать между собой несколько языков. И поскольку формат прописан, то нужно, чтобы компилятор выдал что-то ровно в этом формате. Но современные умные компиляторы продвинутых языков берут на себя большую ответственность. Хорошо, когда компилятор можно попросить сгенерить результат в нужном формате. В случае Си можно просто сделать это самостоятельно. Поэтому именно на Си часто пишутся расширения для других языков.

Автор статьи может стать твоим ментором и научить писать расширения на Си для других языков Нанять

Простота Си позволяет сразу сделать такой интерфейс, какой требуется тому языку, который планируется расширять. Справедливости ради стоит заметить, что при использовании extern «C» ровно такой же эффект можно получить и в С++. Существуют также инструменты, которые могут сгенерить нужный код на языке Си, который будет использоваться в качестве прослойки между библиотекой и языком, в котором ее планируется применять. Если использовать эти инструменты, можно обойтись без знания Си или понимания формата библиотеки. Но с ними все-таки удобнее.

Мы рассказываем, как стать более лучшим разработчиком, как поддерживать и эффективно применять свои навыки. Информация о вакансиях и акциях эксклюзивно для более чем 8000 подписчиков. Присоединяйся!

Добавить комментарий