Миром всё ещё управляет язык С

https://www.toptal.com/c/after-all-these-years-the-world-is-still-powered-by-c-programming
  • Перевод
Многие из проектов на языке С, существующих сегодня, начинали разрабатываться ещё десятилетия назад. Операционная система UNIX стартовала 1969 году (и писалась на ассемблере), но уже в 1972 была переписана на С. Точнее, это язык С был создан для того, чтобы появилось что-то, на что было бы удобно переписать с ассемблера ядро UNIX и получить чуть более высокоуровневый код, менее зависимый от архитектуры и позволяющий выполнять больше полезной работы на каждую строчку написанного кода.

Разработка базы данных Oracle началась в 1977 году (тоже на ассемблере) и тоже была переписана на С в 1983 году. К тому времени это был уже один из самых популярных языков в мире.

В 1985 году вышла Windows 1.0. Хотя код операционной системы Windows не является открытым, общеизвестно, что ядро в основном написано на С с небольшими вставками ассемблера. Разработка Linux началась в 1991 году и началась сразу на С. В следующем году она была опубликована под лицензией GPL и использована как часть GNU Operating System, которая и сама начиналась как проект на С и Lisp, так что многие компоненты были написаны на С.

Но проекты на С — это не только то, что стартовало десятилетия назад, когда выбор языков, скажем прямо, был достаточно ограничен. Много С-кода пишется и сейчас, на нём начинаются и новые проекты. Для этого есть причины.

Как именно язык С управляет миром?


Не смотря на современную тенденцию к использованию высокоуровневых языков, фундамент мира ИТ всё ещё держится на языке С. Вот лишь некоторые из систем, написанных на С и ежедневно используемых миллионами людей.

Microsoft Windows


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

Linux


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

Mac


Вы не поверите, но и третья «большая» ОС в нашем списке тоже написана на С (по крайней мере её ядро).

Драйвера


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

Мобильные ОС


Ядра iOS, Android и Windows Phone тоже написаны на С. По сути они являются мобильными адаптациями уже существовавших ранее ядер Mac OS, Linux и Windows. Так что прямо сейчас в вашем кармане работает С-код.

image

Базы данных


Все наиболее популярные базы данных в мире (Oracle Database, MySQL, MS SQL Server, PostgreSQL) написаны на С (некоторые — на комбинации С/С++). Базы данных используются во всех типах систем: финансы, медиа, телеком, здравоохранение, образование, продажи, веб и т.д. Если вы не живёте на необитаемом острове — вы сталкиваетесь с системами на базах данных (и, как следствие, с работой кода на С) ежедневно.

image

Графика, видео, спецэффекты


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

Embedded-разработка


Просто вспомните свой обычный день. Вы просыпаетесь от будильника (который, возможно, управляется микроконтроллером с кодом на С). Затем ваша микроволновка (тоже с микроконтроллером) разогревает ваш завтрак. Вы наливаете кофе из кофеварки (ну, вы уже поняли). За завтраком вы включаете телевизор или радио (снова embedded железо и код). Дальше вы открываете дверь гаража (с пульта). Очень большая часть кода во всех вышеперечисленных устройствах написана на С.

И вот вы добрались до своего автомобиля. В нём работают (и, скорее всего, написаны на С), следующие системы:

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

… этот перечень может быть сильно расширен в зависимости от навороченности вашего авто.

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

image

Почему люди всё ещё пишут на С?


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

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

Комбинация портируемости и эффективности


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

Язык С также стал чем-то вроде универсального языка для общения программистов. Не знаешь, на каком языке выразить идею, чтобы незнакомый тебе разработчик на другом конце мира понял, что за алгоритм ты написал? Просто пиши на С. Alex Allain из команды Dropbox сказал так:
С — это отличный язык для выражения общих идей в программировании способом, удобным для большинства людей. Многие из соглашений и принципов языка С были заимствованы другими языками, так что с помощью кода на С вам, вероятно, удастся объясниться даже с теми программистами, которые на С никогда и не писали

Прямой и быстрый доступ к памяти


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

Микроконтроллер может быть спроектирован таким образом, например, что байт по адресу 0x40008000 будет отправлен UART к какому-то периферийному устройству, тогда, когда бит номер 4 в ячейке памяти по адресу 0x40008001 будет выставлен в 1.

Код на С для оправки байта для такого микроконтроллера будет выглядить вот так:

#define UART_BYTE *(char *)0x40008000 
#define UART_SEND *(volatile char *)0x40008001 |= 0x08 

void send_uart(char byte) 
{ 
   UART_BYTE = byte;    // записываем отправляемое значение в ячейку 0x40008000
   UART_SEND;           // поднимаем бит номер 4 в ячейке 0x40008001 
}

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

Детерминированность использования ресурсов


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

Размер кода


Рантайм С очень невелик. Бинарник, полученный после компиляции и линковки кода на С, будет меньше бинарников на многих других языках. Даже по сравнению с С++ размер часто бывает в 2 раза меньше. С++ вынужден поддерживать абстракции, вроде исключений, что не даётся бесплатно. Это, безусловно, неплохой в некоторых случаях инструмент, но он требует дополнительного кода.

Давайте посмотрим вот на такой код на С++:

// Объявление класса А. Реализация методов находится где-то в другом месте
class A
{
public:
   A();                    // Конструктор
   ~A();                   // Деструктор (called when the object goes out of scope or is deleted)
   void myMethod();        // Просто метод
};

// Объявление класса В. Реализация методов находится где-то в другом месте
class B
{
public:
   B();                    // Конструктор
   ~B();                   // Деструктор
   void myMethod();        // Просто метод
};

// Объявление класса С. Реализация методов находится где-то в другом месте
class C
{
public:
   C();                    // Конструктор
   ~C();                   // Деструктор
   void myMethod();        // Просто метод
};

void myFunction()
{
   A a;                    // Вызван конструктор a.A()
   {                       
      B b;                 // Вызван конструктор b.B()
      b.myMethod();       
   }                       // Вызван деструктор b.~B()
   {                       
      C c;                 // Вызван конструктор c.C()
      c.myMethod();        
   }                       // Вызван деструктор c.~C()
   a.myMethod();         
}                          // Вызван деструктор a.~A()

Методы классов A, B и C объявлены где-то в других файлах. Таким образом, компилятор пока не может проанализировать их и понять, генерируют ли они исключения. То есть он должен быть готов к тому, что да, генерируют. И их нужно обрабатывать. Если возникнет исключение — нужно суметь отмотать стек и вызвать деструкторы всех созданных объектов. Это всё увеличивает объём сгенерированного кода. Мы получаем оверхед языка С++ по сравнению с С. Для многих приложений это не допустимо. И, хотя компиляторы С++ часто дают возможность отключить использование исключений, это тоже не даётся даром, поскольку код стандартной библиотеки С++ использует их для сообщений об ошибках. Придётся или жить без этой информации, либо переписывать части стандартной библиотеки.

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

Причины изучить С (если вы ещё этого не сделали)


Язык С не так сложно выучить, а вот польза от этого может быть существенная.

Общий язык


Как уже говорилось выше: если вы пишете на С — вас всегда поймут. Много реализаций алгоритмов в книгах или статьях приводятся впервые именно на языке С. Это даёт максимальную портируемость, максимальную простоту использования на любой платформе. Я видел, как программисты на некоторых высокоуровневых языках рыскали по интернету в поисках реализации какого-то алгоритма на их языке просто потому, что не понимали деталей его реализации на С.

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

Понимание того, как работает ваш компьютер


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

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

image

Возможность работать над интересными проектами


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

image

Вывод


Миром управляют не масоны. Миром управляют программисты на С.

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

Мир полон устройств, в которых работает код на С. Мы используем их каждый день. Язык С — это не только прошлое, настоящее, но и, насколько хватает взгляда, будущее во многих областях разработки ПО.
Инфопульс Украина 111,21
Creating Value, Delivering Excellence
Поделиться публикацией
Комментарии 142
  • +15
    www.youtube.com/watch?v=cdX8r3ZSzN4

    Простите, не удержался :)
    • +1
      я подсел на Научно-технический рэп )
      • –3
        Они еще те кидалы, на Chaos Constructions 2017 кинули всех(не уверен точно, но вроде как на $$$), в первую очередь посетителей, отказавшись выступать в последний момент, из-за «неправильного» звука на площадке.
        <ИМХО>Поэтому, я только убедился в том, что реперы, в большинстве своем — мрази.</ИМХО>
      • +1

        Ну тогда уж вот ещё: https://youtu.be/1S1fISh-pag

      • +2
        С — крутой язык, сложно представить какой ЯП сможет его заменить.

        Чуть личной истории
        Помнится, лет десять назад, программировали на С используя Borland С++, славные были времена.

        Сейчас что не более-менее новый язык — так сразу плагины для него к многим IDE и т.п., автодополнения строк\функций и т.п…

        … у нас в универе были контрольные работы по программированию: дают аркуш А4, и сиди пиши программу ) потом бумажку на проверку преподу и можешь переносить свой код в ПК и компилировать.

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

        С давних времен — привычка похожая осталось, когда на серваке быстро чтото сделать\проверить — открывается nano, и пишешь) полезная практика.
        • –11
          Если вам надо «на серваке» быстро что-то сделать/проверить на C, то у меня для вас плохие новости.
          • +8
            Если читаете по диагонали и отвечаете не понимая контекста — у меня для вас плохие новости.
            • –9
              Если вы додумываете за собеседника то, чего он не делал и не писал — у меня для вас плохие новости.
              /* Я этим до вечера могу заниматься. */
              • +11
                Но человек реально не писал, будто ему нужно что-то сделать/проверить на С, вы эту часть действительно додумали (специально или невольно — неважно).
          • +5
            ИМХО только С++.
            После С++ голый С кажется языком, подходящим только для отстреливания себе ног.
            • +12
              ИМХО только Rust.
              После Rust голый C++ кажется языком, подходящим только для отстреливания себе ног.
              Не подвергайте себя и других опасности, используя небезопасные языки. Ваш код может и убить кого-нибудь.
              • +16
                ИМХО только Haskell.
                После Haskell голый Rust кажется языком, подходящим только для отстреливания себе ног.
                Не подвергайте себя и других опасности, используя нечистые языки. Ваш код может и убить кого-нибудь.

                Да что там…
                ИМХО только Idris.
                После Idris голый Haskell кажется языком, подходящим только для отстреливания себе ног.
                Не подвергайте себя и других опасности, используя неверифицируемые языки без проверки тотальности и с неразрешимой проверкой типов. Ваш код может и убить кого-нибудь.
                • 0
                  А какое мнение насчёт С#?
                • –16
                  С++? О, да — замечательный язык!


                  myprint(a);
                  b = a;
                  myprint(b);

                  0x00143020
                  0x00285040

                  Я был в полном… «восторге»! Operation overload!
                  • +11
                    Ничего не понял, кроме того, что С++, как и С — непростой инструмент, перед использованием нужно прочитать инструкцию.
                    • –9
                      Скажите, если не секрет — вам приходилось адаптировать под новую платформу некую, систему на C++ размером в двоичном коде от 10MB до 16MB кода и числом строчек исходного кода за 200000?

                      Мне пришлось, и она тупо падала неизвестно где и откуда. Я потратил дня 3-4 прежде чем понял, что результат присвоения не гарантирован. Инструкцию к языку я конечно прочел годы назад. Но не был готов, что на C++ надо проверять каждый шаг и если упустил перезагрузку оператора в 200тыс строк кода для этого типа данных, то увы…
                      • +3
                        То есть кто-то перезагрузил оператор, явно не документировав это, а виноват С++?
                        • +1
                          О! Документированые перезагрузки. Извините, не встречал, ни разу. Комментарии около текста, где определяется перезагрузка еще могут быть, но их еще найти надо в коде на тысячи строк и сотен файлов. А чтобы искать, надо ЗНАТЬ, что они есть и какие есть, между прочим.
                          • 0
                            Комментарии около текста, где определяется перезагрузка еще могут быть, но их еще найти надо в коде на тысячи строк и сотен файлов.

                            IDE обычно позволяет перейти к определению и реализации метода.
                            • –1
                              Ну IDE не всегда доступен, если это работает на голом железе да еще и хитро собирается, то никак.
                    • +3
                      Я так понимаю, что Вам ближе языки где нет перегрузки функций/методов и запрещено не явное приведение типов? Но тогда причем тут C++, такой пример можно написать много на чем.
                      • –4
                        Здесь идет речь про С vs С++, так что про другие языки не стоит толковать как оправдание кривостей C++.
                      • 0

                        У нас есть класс для возвращаемых ошибок. Он может содержать одну ошибку. Иногда возникает необходимость вызова подряд нескольких функций, каждая может вернуть ошибку. Без перегрузки операторов пришлось бы иметь два объекта, в первый получать результат функции и если во втором нет ошибки приравнивать второй к первому.
                        С перегрузкой же это реализуется элементарно и перегрузив оператор |= вызываем функции подряд, а в конце получаем первую возникшую ошибку.
                        P.S. все ошибки фатальные, важно получить первую возникшую и не замаскировать ее успешным выполнением следующей функции.

                        • –2
                          Извините, но это несерьезный аргумент в пользу overloading. Он может работать на небольшой программе, но в случае комплексов на сотни тысяч строк кода поиск ошибок слишком дорого обходится.
                          • 0
                            Несерьезный аргумент — это ругать перегрузку, хотя на самом деле стоит ругать свою неопытность.
                            Присвоение объектов без попытки разобраться как это работает — вот это несерьезно!
                            Объект а мог выделять себе память и использовать её по указателю, когда вы присвоили объект a объекту b произошло копирование указателя, затем вы уничтожили объект a и его деструктор освободил память… что будет при попытке вызвать у объекта b функцию работающую со скопированным указателем???
                            Первые вопросы которые у вас должны были возникнуть "А что что это за объекты? А можно ли их копировать? А что происходит при копировании?". Но, по своей неопытности, вы этого не сделали. За что и получили столько минусов в карму. Впрочем, минусующие тоже хороши — им стоило бы вам сказать за что.

                            Есть проекты на кучу строк кода, на миллионы долларов и от которых зависят жизни людей(медицинское оборудование). А поиск ошибок неопытными работниками в любом случае обходится слишком дорого.
                      • 0
                        С++ кажется языком, подходящим для отстреливания чужих ног.
                        А Perl просто отстреливает всех, кто пытается прочесть исходники.
                        • 0
                          Да не помянем язык ADA всуе :)
                          Про него неплохо написал (раскритиковал) в 1994 году Мэлор Стуруа.
                        • +1
                          Вы сильно ошибаетесь, в плюсах не меньше способов отстрелить себе ногу, а может даже больше, учитывая, что он сильно сложнее голого си…
                          • +1
                            Тогда на ассемблере таких способов меньше, а меньше всего — в машинных кодах?
                            • +2
                              Вы умеете вести диспут без гипербол и доведения до абсурда?
                              • 0
                                Доведение до абсурда помогает увидеть, когда в логических высказываниях пропущены какие-то предикаты. Отличный метод, на самом деле, как доказательство от противного.
                              • 0
                                В пересчете на строчку кода пожалуй меньше. Но в итоге все равно получится больше.
                          • 0
                            Embarcadero Rad Studio (C++Bulder) — по прежнему — один из лучших инструментов для написания C кода :)
                            • 0
                              И это хорошо! Потому что я знаю, что могу в Си запросто отстрелить себе ногу 1000 способами. Свобода! А вот в явах всяких и прочих похапе попробуй-ка? Шаг в сторону — и… и ничего. Скукота и тошнота, прям как бейсик.
                              • +3
                                Шаг в сторону — и… и ничего. Скукота и тошнота, прям как бейсик.

                                Я попрошу не оскорблять Бейсик! В нем тоже есть возможность стрелять по ногам — POKE, например.
                                • 0
                                  Согласен. Значит Бейсик лучше, чем явы и похопе.
                                  • 0
                                    Несмотря на то, что Basic считался учебным языком (в моё время им Фортран заменили в ВУЗе), существует приличный вариант DarkBASIC Professional, который теперь позволяет всем желающим поковыряться в своих исходниках.
                                  • 0
                                    Переходите на плотное использование JNI в Java и жизнь станет немного ярче.
                                    • 0
                                      Попробовал на Rust сделать 1 << 65, а он мне не дал. Я сел и заплакал: как же без этого? Или целочисленное переполнение… Куча милых фич недоступна. В Сях выстрел в ногу ценен и сам по себе, и удовольствием, когда ногу успел отдёрнуть.
                                      • +3

                                        А что вы имели ввиду под 1 << 65? Что оно вообще должно делать? При компиляции результат не влезает в 64 бита, о чём компилятор и говорит.


                                        Или целочисленное переполнение…

                                        Там оно есть. Просто по умолчанию считается, что эта фигня не должна происходить и debug-сборка паникует на этом. release-сборка паниковать не будет.


                                        Если же нам требуется переполнение, как часть того, чего мы хотим достичь, то есть удобные варианты сказать "здесь должно быть переполнение". Все эти checked_, saturating_, wrapping_, overflowing_ версии позволяют задокументировать сей процесс. https://doc.rust-lang.org/std/primitive.i64.html (для остальных типов тоже самое). Плюс тип std::num::Wrapping.


                                        Куча милых фич недоступна.
                                        В Сях выстрел в ногу ценен и сам по себе, и удовольствием, когда ногу успел отдёрнуть.

                                        Всё там есть. Нужны UB? Есть их там. Так что спортивная стрельба по ногам тоже присутствует. Можно ставить у всего unsafe и радоваться. К вашим услугам нестабильная функциональность. Там тоже изредка можно в биатлон поиграть. В том числе и с компилятором.


                                        Или вам не нравится, что подобное можно найти в коде простым grep? Хочется творить какую-то магию, которая by design нечитаема? Тогда да, rust не для вас.

                                      • 0
                                        Интересно, что в рамках этой метафоры можно сделать с ногами, например, в Хаскеле…
                                        • 0
                                          Ну, единственный раз, когда мне в хаскеле нужно было работать с битами, я ноги себе чуточку отстрелил, по своей глупости (Word32 не в том месте конвертировался в Word64).

                                          К счастью, quickcheck эту ошибку поймал сразу после написания кода.
                                          • 0
                                            Сделать ленивую структуру зависимой от самой себя
                                            let a = a ++ [1] in a

                                            Воспользоваться функцией (!!) и удивиться изменению в типе второго аргумента.
                                            Написать let n1 = n+1 in… и внутри перепутать значения n и n1.

                                            На моей практике пожалуй самые заметные проколы.
                                          • 0
                                            Джава поможет отстрелить — используйте JNI
                                          • +1
                                            (покашливает) Как насчет С99?
                                            • 0
                                              А почему не спрашиваете о С11?
                                              • 0
                                                Потому что С11 от С99 отличается не так существенно. А вот С89 с его объявлениями только в начале функций, отсутствием однострочных комментариев, отсутствием stdbool.h, отсутствием нормального inline, отсутствием designated-initializer'a для структур и т.д. довольно сильно раздражает.
                                                • +1
                                                  Я с чего-то решил, что это было добавлено начиная с C11, а не C99. Мне designated-initializer не хватает временами в C++ :) Жаль в него этого не добавили.
                                                  • +3
                                                    Вроде как в С++20 его одобрили.
                                          • +2

                                            Как говорил один мой преподаватель в университете(в который мы пришли после колледжа) "В колледже учат КАК сделать, а в университете учат КАКУЮ КНИГУ взять с полки, что бы прочитать как сделать".
                                            Помнить наизусть все библиотечные функции языка — далеко не главное в программировании.

                                            • +5
                                              Тоже на первых курсах предпочитал писать код в Far Manager, без подсветки и автокомплита, воспринимая это как тренировку памяти и доказательство превосходства над одногруппниками. Разумеется, как только дело дошло до более-менее серьезных проектов, детская бравада закончилась.

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

                                              Во-вторых, память в голове не бесконечна. Лучше потратить ее на что-то важное, а тонкости API оставить компьютеру.

                                              В-третьих, может и вообще не нужно запоминать функции на случай, если они понадобятся только через год. Что это за ситуация, в которой не будет ни того же автокомплита, ни интернета, но необходимо срочно что-то написать?
                                              • 0
                                                Что, кроме нежелание учить что-то новое и унаследованный код, мешает заменить C и C++ на Rust или Ivory?
                                              • +1
                                                Надеюсь раст будет готов заменить этот «отличный язык». А то он такой замечательный, но только написать на нем код без уязвимостей практически невозможно, по крайней мере еще никому не удалось это сделать (в большом проекте)
                                                • +6
                                                  Раст настолько крут, что сам фиксит любые баги за программистом?
                                                  • +7

                                                    O.o анекдот_сибирские_лесорубы_бензопила.docx

                                                    • +1
                                                      Нет, он фиксит самих программистов.
                                                      • +1
                                                        Вы не верите, что количество ошибок на реализацию той же функциональности может сильно зависеть от языка?
                                                        • +1
                                                          Я не верю в серебряные пули) В крайности впадать наивно.
                                                          • +1
                                                            Но и пользоваться первобытным луком в эпоху огнестрельного оружия со свинцовыми и стальными пулями — тоже не самая полезная крайность.
                                                            • 0
                                                              В самом деле, есть же C++
                                                              • +1
                                                                Английский длинный лук.
                                                      • +3
                                                        Был бы «талант», а написать уязвимости можно на любом языке. :) Программист никогда не сможет до конца предвидеть как будет использоваться его продукт, для чего и как его будет применять пользователь. А программист это обычный пользователь со своими потребностями и желаниями, когда речь заходит о компиляторе. Раньше попадались байки, как «баги» компилятора использовались «во благо», а на пустом месте байки редко рождаются. :)
                                                        • +3
                                                          Очень сомнительно, что это произойдёт в ближайшие 10 (если не больше) лет. Даже если это случится, Rust займёт какую то полку, в лучшем случае вытеснит от туда какой нибудь язык (или просто слегка подвинет) и всё на этом закончится. Си ему не заменить.
                                                          • +3
                                                            Си ему не заменить.

                                                            Какие-нибудь аргументы будут? Ну кроме «на нем столько всего написано». Как показывает опыт какого-нибудь COBOL'а, это не карт-бланш.
                                                            • +2
                                                              Чтобы заменить С, нужен язык с малой стандартной библиотекой + компилятор, который за короткое время пробежит 40 лет эволюции для достижения лучшей скорости и / или меньшего размера бинарника.

                                                              Как вы сами оцениваете вероятность появления такого языка общего назначения и чудо-компилятора под него?
                                                              • +2

                                                                Скоростью и размером бинарника занимается LLVM. Ему почему-то не понадобилось 40 лет, чтобы догнать GCC. Или вы про какой-то другой компилятор говорили?

                                                                • 0
                                                                  Не будем забывать, что llvm начался в 2000 году, 18 лет назад. Кроме того, llvm является бэк-эндом, который работает не с синтаксисом языка напрямую, а с ассемблером виртуальной risc машины. При создании нового языка нужно ещё написать фронт-энд для него, что тоже небыстро и недешёво (индустрия любит стандарты, а комитеты быстро ничего не решают).

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

                                                                  Наконец, по данным Phoronix, в конце 2017 года связка clang + llvm всё-таки немного отставала от gcc по производительности.
                                                                  • +1
                                                                    Я, конечно, не Phoronix, и публичных бенчмарков у меня нет, но в моей практике clang/llvm опережает gcc, иногда существенно.
                                                              • 0
                                                                Например огромный недостаток по сравнению с C — отсутствие стандарта. Пока что стандарта языка не только нет, он даже не планируется: постоянно подкачивать новые фичи языка с гитхаба — это модно, молодежно, динамично, но не годится для индустрии.
                                                                Еще есть проблема со стандартной библиотекой. Насколько я смог понять, там большие проблемы с модульностью. Если в С, например, я пишу под микроконтроллер, я могу использовать урезанную стандартную библиотеку без тредов хэш-мапов и всего такого, и все еще иметь возможность вызывать printf или memcpy. Даже нажористую плюсовую библиотеку, кажется (см. Christopher Kormanyos «Real-time C++») можно использовать на системах без динамической памяти подсовывая кастомные аллокаторы.
                                                                Растовая библиотека же работает по принципу «все или ничего». Или ты ограничен функциональностью core или же будь добр портируй std целиком: с динамической памятью, тредами и прочими радостями.
                                                                • +1
                                                                  Например огромный недостаток по сравнению с C — отсутствие стандарта. Пока что стандарта языка не только нет, он даже не планируется: постоянно подкачивать новые фичи языка с гитхаба — это модно, молодежно, динамично, но не годится для индустрии.

                                                                  По-моему ничем не отличается от переизобретения в каждой компании своего си-подобного языка при помощи макросов. Точнее, отличается, но в лучшую сторону
                                                                  Растовая библиотека же работает по принципу «все или ничего». Или ты ограничен функциональностью core или же будь добр портируй std целиком: с динамической памятью, тредами и прочими радостями.

                                                                  Кто вас так жестоко обманул?
                                                                  • 0
                                                                    Прошу прощения, перечитал еще раз. Да, много чего завязано на std, но вообще в планах это починить: internals.rust-lang.org/t/refactoring-std-for-ultimate-portability/4301. Подключаем отдельные крейты и готово.

                                                                    Microsoft распилил дотнет на кучу мелких пакетов, сотни, возможно тысячи, сделать то же в расте ничего особо не мешает, если будет желание.
                                                                    • +1
                                                                      Про «ultimate portability» — интересно, спасибо. Надеюсь, у них получится.
                                                                      Аналогии с макросами я не понял, честно говоря. Я вот о чем: для C сейчас существует множество компиляторов. С открытым кодом, с закрытым кодом, оптимизированные под конкретный процессор, со встроенным theorem-prover'ом, компилирующие в прошивку для FPGA и т.д. — полный зоопарк под любую бизнес-модель и область применения.
                                                                      Все это стало возможным благодаря тому, что язык С стандартизирован, любой может взять стандарт и написать под него компилятор. С Rust же это невозможно в принципе, просто потому что стандарта нет и не планируется. По сути Rust = rustc, и это достаточно серьезное ограничение для языка, который хочет захватить мир.
                                                                  • –1
                                                                    Ну, например, кроме крохотной кучки энтузиастов, увидевших в Rust будущее индустрии, на него нужно пересадить еще производителей железа, огромное сообщество Linux и игровую индустрию (последнее — C++, но это дела не меняет). И так далее, дополнять можно еще долго. Каков процент вероятности, что это произойдёт?
                                                                • +1

                                                                  Rust какой-то "инопланетный" и многословный, что ли. Хорошо, если он "взлетит", но сейчас попытки его использования оставляют странные впечатления. Он почему-то отпугивает больше, чем любой из C, C++, Java, Scala, Python, Lua, Delphi, R, Haskell.

                                                                  • +5
                                                                    Засунуть в одну копилку R, Hashell, Delphi и скриптовые языки это сильно :)

                                                                    Хаскель отпугивает намного сильнее, моё мнение. По крайней мере его я освоить так и не мог, а с растом спокойно подружился — достаточно прочитать растбук. Из сложных концепций можно разве что лайфтаймы назвать, но стоит понять, что это просто декларативный способ указания отношений «Х живет дольше У» и все становится очевидно.
                                                                    • +2
                                                                      Хаскель отпугивает намного сильнее, моё мнение.

                                                                      А поделитесь вашим опытом! Сам язык-то простой как дуб, просто подход к написанию программ как к составлению графа уравнений — не самый классический, пожалуй.
                                                                      • 0
                                                                        Да особо рассказывать нечего. Поставил IDE, начал смотреть примеры, книжки, статьи. Не сказать, что что-то непонятно: опыт F# у меня, например, уже был, как и лиспов всяких. Но как-то не зашло. Хотя я как раз хотел проникнуться всей мощью IO монад и прочих методов гамбургера. Мб попробую еще раз позже. Сейчас приоритет — научиться писать на расте :)
                                                                        • 0
                                                                          Может, от статей-книжек зависит. Мне в своё время по Real World Haskell отлично зашло. Сейчас уже всякие Haskell From The First Principles рекомендуют.
                                                                    • +2
                                                                      попытки его использования оставляют странные впечатления

                                                                      Надо ли полагать, что это из-за его главной фичи? Которая ownership. Такого действительно нет в других ЯП.

                                                                      • 0
                                                                        По сравнению с C++ Rust не многословен. И там и там приянто полностью прописывать пространства имен, но в библиотеках Rust они организованы более продумано и лучше работает вывод типов.
                                                                    • +9
                                                                      Меня смущает, что допускают публиковать дубликаты.

                                                                      И кстати, это не первый перевод, мягко говоря, давней статьи.

                                                                      тоже самое

                                                                      PS: искал инфу про С, случайно напоролся.
                                                                      • +4
                                                                        Это вам нельзя. А тем кто ведет корпоративный блог, наверное, можно. Вообще-то надоели эти статьи в духе КО от крупных контор, которые на самом деле просто пиарятся
                                                                        • +2
                                                                          Вот бы движок хабра позволял искать по урл оригинала или имени автора — не было бы и дубликатов. Способ «случайно напоролся» — единственно возможный вариант найти уже существующий перевод.
                                                                      • +7
                                                                        > Миром управляют не массоны.

                                                                        Массоны — это такие масоны, которые пишут на С.
                                                                        • +5

                                                                          Имхо, почти про любой язык из TOP-10 Tiobe Index (ладно, TOP-5) можно сказать, что он "управляет миром". У них нет многих преимуществ C, но есть масса других преимуществ.
                                                                          Какая-то односторонняя статья. Создаёт впечатление, что других языков почти нет, или они не работают.

                                                                          • +1

                                                                            Имхо, есть неиллюзорная вероятность того, что рантайм и интерпретаторы тех языков в Топ10 написаны на С.
                                                                            Какой-то односторонний отзыв. Создает впечатление, что С почти ничего не стоит, или он легко заменим.
                                                                            ;)

                                                                          • +1
                                                                            Embedded-разработка

                                                                            Замечаю, что в этом деле все больше набирает обороты С++.
                                                                            Часто не используются классы, но код все же именно на С++ (используются фишки именно этого языка).
                                                                            Да и классы тоже частенько стали пользовать.
                                                                            Даже ардуина программируется на С++ (даром что Wiring, но это всего лишь библиотека-обертка).

                                                                            • 0

                                                                              А чему удивляться? C++ — это структуры данных + функции обработки данных в этих структурах с неявным указателем this… ну и ещё немного приятных мелочей.

                                                                              • 0
                                                                                Исключения все равно надо прибивать. И stl не всегда влезает.
                                                                              • +1
                                                                                Оверхед C++ всё же отключается, и да, при системной и embedded разработке на C++ стандартная библиотека заменяется специально спроектированной под нужную среду. В целом на сегодняшний день нет смысла что-либо писать на си, любую задачу, выполнимую на си можно выполнить и на плюсах (каком-то его подмножестве, но в любом случае это будет удобнее). Проблема обычно только в наличии специалистов с нужной компетенцией, для таких задач все особенности языка и его рантайма нужно знать досконально.
                                                                                • 0
                                                                                  В советские времена слышал высказывание «Язык C придуман западными программистами для борьбы с капиталистическими эксплуататорами»… а в 90х видел комментарий в коде «на C писать — идиотом стать»
                                                                                  • –1
                                                                                    Ох уж эти хипсторы 90х, пихающие С куда можно и нельзя…
                                                                                  • –7
                                                                                    А я не люблю C. В нём нет защиты от дурака и он стар. А бы писал на нём только для embedded решений, где каждый байт на счету. Хотя я уверен, что если бы был процедурный язык, который устранил бы недостатки С и добавил бы синтаксического сахара, то C «умер» бы очень быстро…
                                                                                    • +5
                                                                                      От дурака никакая защита не спасет. Чем ниже порог вхождения в технологию, тем более бестолковые люди придут в IT.
                                                                                      • 0
                                                                                        Ну в ИТ уже много бестолковых пришло, но от этого толковых меньше не стало, а их ценность только повысилась. А про защиту от дурака могу сказать одно — "=" в условиях. Кому нужно присваивать что либо в условиях?! Почему разработчики языка сразу не заблокировали этот источник ошибок?! А таких вещей в С очень много… И именно поэтому я его и не люблю…
                                                                                        • +1
                                                                                          Кому нужно присваивать что либо в условиях?!
                                                                                          Ну, сишники любят лаконичные циклы, например
                                                                                          while ((nbytes = getline(&buffer, &bufsiz, fp)) != -1) {...}
                                                                                          или
                                                                                          if ( B *b = dynamic_cast<B*>(a) ) {...}

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

                                                                                          • 0
                                                                                            Можно было бы сделать присваиванием ':=', а сравнение '==' — тогда бы их сложнее было перепутать.
                                                                                            • –2
                                                                                              Может просто освоить слепую печать и контролировать свои действия визуально?)
                                                                                        • +1
                                                                                          Откуда мысль, что защита от дурака сильно снижает порог вхождения? Вот скажем хорошо защищенный язык ATS сможет освоить не каждый плюсовик и ембедщик. Да и Rust все-таки сложнее чистых C.
                                                                                          • 0
                                                                                            Очевидный вывод из того, что при прочих равных снижается количество факторов, которые необходимо учитывать.
                                                                                            • 0
                                                                                              Факторов меньше не становится. Просто компилятор вовремя сообщает, что какой-то фактор неучтен.
                                                                                              • 0
                                                                                                Зачем глубже изучать технологию и читать блоги с умными советами, если компилятор/рантайм и так покажет в чем беда еще до того?
                                                                                                • 0
                                                                                                  Что бы понимать, что компилятору не понравилось.
                                                                                                  • 0
                                                                                                    Мой компилятор обычно пишет причину и даже указывает предполагаемое место проблемы, а рантайм бросает исключения, которые подробно описаны в референсе. А ваш?)
                                                                                                    • 0
                                                                                                      Это компенсация за то, что он не может найти более серьезных ошибок. А вот над сообщением, что два выведенных типа не отождествляются, или время жизни переменной не соотвествует ожиданиям, голову прихолится поломать, несмотря на достаточно качественную диагностику.
                                                                                                      • –1
                                                                                                        Компилятор не может и не должен искать логические ошибки.
                                                                                                        От дурака никакая защита не спасет.
                                                                                                        • +3
                                                                                                          Логическая ошибка — это поделить на два там, где нужно умножить, перепутать дату рождения с датой регистрации или еще что-то в этом духе. От этого компилятор действительно не может спасти.
                                                                                                          Ошибки же управления ресурсами — это другое, и как показывает мой скромный опыт с Rust, тут компилятор способен очень на многое. Но понимать, что как работает, все равно нужно: компилятор выдает чаще ошибки вида «сходи-ка дружок поучи матчасть», чем «сделай как я говорю, и все заработает».
                                                                                                          • 0
                                                                                                            В контексте обсуждения, это (попытка управлять выносить бизнес-логику в компилятор) как раз повышает сложность: необходимо придерживаться некоторых правил и уметь читать ошибки. Такой себе встроенный «фреймворк» со статическими тестами.
                                                                                                            • +1
                                                                                                              Можно по-разному понимать «защиту от дурака», наверное. Java, например, реализует такой способ защиты, который позволяет дураку программисту не думать о многих вещах, а Rust (не знаю про ATS) именно заставляет его подумать, и еще доказать компилятору, что хорошо подумал. Это заставляет повозиться, да.
                                                                                        • –2
                                                                                          Этот язык просто попал в классическую ловушку — для него написано слишком много библиотек чтобы от него можно было отказаться и в то же время по этой же причине никто не будет писать аналогичные библиотеки для других языков. ИМХО лучше было бы чтобы победил именно паскаль. Если бы его развивали, сейчас по свойствам был бы на том же уровне что и С но более выразительный. Просто видимо изначально кому-то не понравилось много писать begin-end и подкупили краткие скобочки {} языка С, но это как раз и есть АД си-шечки — в более-менее сложных программах просто в глазах рябит от этих скобочек.
                                                                                          • 0
                                                                                            но это как раз и есть АД си-шечки — в более-менее сложных программах просто в глазах рябит от этих скобочек

                                                                                            (Чувствую (на (лиспе (вы (не (писали))))))
                                                                                            • +1
                                                                                              Скобочки это хорошо и намного более короче и нагляднее, чем begin-end. А вот настоящий ад C — это всё что связано с указателями (*, ^ и т.д.), а также особая любовь к _ в названиях переменных и функций, а также разбавление кода знаками вроде <>, # и % Из-за этого код C выглядит как набор символов. Добавьте к этому не очень явное наименование стандартных функций вроде scanf или puts и получится мощный язык, на котором не очень-то хочется писать…
                                                                                              • 0
                                                                                                Скобочки это хорошо и намного более короче и нагляднее, чем begin-end.

                                                                                                Короче — да. Нагляднее — ничуть. Обозначение блока словами создает «отчеркивание» сверху и снизу, это визуально выделяет блок, причем много сильнее, чем со скобками.
                                                                                              • 0
                                                                                                Паскаль гораздо конвервативнее, чем C.
                                                                                                Так разделение statement/expression в нем заметно более выраженое, а современная тенденция как раз в сторону expression-based языков.
                                                                                                На тот момент все-таки C был лучшим выбором, просто не надо было делать его окончательным.
                                                                                                • 0
                                                                                                  У Паскаля несколько тяжёлых недостатков, которые его по сути и убили, jIMHO, а в общем он просто сырой. Можно посмотреть на то, какими получились языки линии Modula, в которых некоторые самые тяжёлые проблемы были устранены.

                                                                                                  Самое серьёзное — это стиль ввода-вывода. Язык явно задаёт особый стиль для read[ln]/write[ln], со всеми этими write(x:10:5). Программисту сделать свою функцию, которая будет уметь то же самое, нельзя. Сделать различие write() для stdout и write() для заданного хэндла — тоже нельзя. Сделать средствами языка свою реализацию файлов — тоже нельзя. В C — можно. Этого фактора было достаточно, чтобы слой хакеров (в реймондовском смысле) категорически отверг Паскаль и стал смотреть в сторону Си, у которого таких ограничений нет. Причём это не исправлено, насколько мне известно, даже в современных активно развиваемых реализациях! хотя могли давно придумать какие-то макросы, например.

                                                                                                  Большая группа проблем при изучении языка (а каждая такая проблема вылазит и у профессионала, если он устал или не сосредоточен!) Я провёл через это нескольких школьников, пишу по своим впечатлениям:

                                                                                                  Вечная борьба с блоковыми скобками — ставить begin/end или не ставить, ставить ';' перед else или не ставить, ставить перед end или не ставить (а некоторые психи настаивали, что перед end нельзя ставить ';')… И портит картину то, что постоянно эти скобки пропускаются в примерах и учителями, а понять, как их расставлять — например, как после then и после else раздельно ставить, или не ставить — это для совсем юных очень сложно.

                                                                                                  В Си за счёт более коротких скобок эта проблема замаскирована, но осталась. В Modula — имплицитное begin и обязательное end — это один из лучших вариантов стиля. Go/Swift/Perl/etc. с форсированием {}, Python с отступами — это всё решения лучше, чем в Паскале. Для обучения вообще форсирование отступов очень полезно для формирования стиля.

                                                                                                  Ещё сбивает с толку то, что repeat — until это само по себе скобки, а все прочие — нет.

                                                                                                  И снова те же read[ln], write[ln] — тут пиши файл, а тут рыбу заворачивай — у школьников головы дымятся, у профессионалов тоже. Разделение printf/fprintf как в C — сильно лучше.

                                                                                                  Вечная идиотская проблема с тем, что and, or приоритетнее сравнений, поэтому написать a=b and c=d нельзя, нужно (a=b) and (c=d).

                                                                                                  Никлаус Вирт орал на весь мир «Не используйте Паскаль! Есть Modula, есть Oberon, в них все дурости Паскаля исправлены!», но так как в IT почти всегда идёт в массы не лучшее, а первое из минимально приемлемых, то застрял Паскаль.

                                                                                                  > но это как раз и есть АД си-шечки — в более-менее сложных программах просто в глазах рябит от этих скобочек.

                                                                                                  От begin-end рябит в разы хуже, потому что читается медленнее. И, повторюсь, блоковые скобки лучше форсировать даже для одного оператора — мировая практика постепенно пришла к этому. Сразу уходит куча дурных проблем типа «висячий не там else» или «тут воткнул ещё один оператор в теле под if, а почему старый перестал выполняться по условию?» Можно спорить, как именно должны выглядеть эти скобки, но они должны быть.
                                                                                                  • 0
                                                                                                    Чего пенять на стиль ввода-вывода, если он стал «Deprecated» ещё в самом турбопаскале… и не убрали их лишь из вопроса совместимости. Сейчас файловый ввод-вывод осуществляется исключительно через объекты. Более того, даже пришлось немного покорёжить обратную совместимость старые функции открытия/закрытия файла создали интерференцию с другими функциями стандартных классов. Аналоги функций с переменным количеством аргументов появлялись в последних версиях турбопаскаля, когда там даже динамических массивов ещё небыло.
                                                                                                    А насчет выражений, так в любом языке лучше расставить приоритеты явно скобками, паскаль просто подталкивает к этому порождая полезные привычки. Взять даже обычные калькуляторы — оказывается, даже у них нет единого стандарта по приоритету операций. Инженерный и бухгалтерский калькулятор могут дать разный результат из-за разного приоритета операций. Классическое 1+2*2 какой-то калькулятор даст 5 а другой 6… и поди пойми их! и ещё ньюанс «1+2(2+3)» и «1+2*(2+3)» могут быть посчитаны по-разному. Как в таком мире жить?
                                                                                                    • 0
                                                                                                      Взять даже обычные калькуляторы — оказывается, даже у них нет единого стандарта по приоритету операций.
                                                                                                      Характерной особенностью инженерного является возможность вводить скобочки. Стандартный же не умеет считать выражения (только отдельные операции), поэтому приоритетов у него нет вообще.
                                                                                                      • 0
                                                                                                        Блин, вы открыли мне глаза. Стандартный виндовой считает 2+2*2 по разному в зависимости от режима.
                                                                                                      • 0
                                                                                                        > Аналоги функций с переменным количеством аргументов появлялись в последних версиях турбопаскаля, когда там даже динамических массивов ещё небыло.

                                                                                                        Ну да, когда поезд ушёл — тенденция перехода на C стала массовой.

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

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

                                                                                                        > Как в таком мире жить?

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

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

                                                                                                          А неадекватные приоритеты в языках постоянно лечат, где нет необходимости сохранять старые баги. В C приоритет у &, | был занижен неадекватно — ниже сравнений. В Go, Swift — & на уровне с "*" "/", | — на уровне с "+" "-" — это уже не провокация, количество ошибок от нарушенных ожиданий резко ниже.

                                                                                                          > А насчет выражений, так в любом языке лучше расставить приоритеты явно скобками

                                                                                                          Вы реально расставляете скобки даже в выражениях типа a*b+c за пределами виндового калькулятора? Позвольте не поверить…
                                                                                                        • 0
                                                                                                          Самое серьёзное — это стиль ввода-вывода

                                                                                                          Это — надуманная претензия. Никто не запрещает вам отказаться от встроенных средств и использовать библиотеки в стиле Си.

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

                                                                                                          Есть best practises и style guide. И никаких споров.

                                                                                                          И снова те же read[ln], write[ln] — тут пиши файл, а тут рыбу заворачивай — у школьников головы дымятся, у профессионалов тоже. Разделение printf/fprintf как в C — сильно лучше.

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

                                                                                                          Вечная идиотская проблема с тем, что and, or приоритетнее сравнений, поэтому написать a=b and c=d нельзя, нужно (a=b) and (c=d).

                                                                                                          И замечательно — второй вариант читается лучше.

                                                                                                          От begin-end рябит в разы хуже, потому что читается медленнее.

                                                                                                          Строго наоборот — они лучше «отчеркивают» блоки. Естественно, если используются примерно так же, как скобки в С в GNU style, т.е. каждый begin и end строго на отдельной строке с соблюдением отступов.

                                                                                                          Сразу уходит куча дурных проблем типа «висячий не там else» или «тут воткнул ещё один оператор в теле под if, а почему старый перестал выполняться по условию?»

                                                                                                          Скорее это проблема тех, кто работает с Python или просто новичок. Ни разу за уже 9 лет работы с Delphi (Object Pascal т.е.) такого не было.

                                                                                                          Остальное все вкусовщина — кто к чему привык.
                                                                                                          • 0
                                                                                                            > Это — надуманная претензия. Никто не запрещает вам отказаться от встроенных средств и использовать библиотеки в стиле Си.

                                                                                                            И вы отказываетесь читать то, что написано прямым текстом.
                                                                                                            Сейчас, да, есть подобные библиотеки, и их можно использовать. Тогда — не было. Поезд ушёл тогда, до середины 90-х, а не сейчас.

                                                                                                            > Как раз наоборот: то, что все работает с handle'ами — замечательно,

                                                                                                            И во второй раз не хотите читать. Проблема не в самой работе с хэндлами, а в том, что в writeln с компанией или есть скрытый аргумент в виде stdout (или как он там зовётся в Паскале), или его нет.

                                                                                                            > И замечательно — второй вариант читается лучше.

                                                                                                            С такой аргументацией прямая дорога к Лиспу. У вас может сколько угодно «лучше читаться» второе, но если не ставить скобки, то ожидаемое не соответствует реальному.

                                                                                                            > Строго наоборот — они лучше «отчеркивают» блоки.

                                                                                                            Необязательные begin-end — худший вариант из четырёх рассмотренных.

                                                                                                            > Естественно, если используются примерно так же, как скобки в С в GNU style, т.е. каждый begin и end строго на отдельной строке с соблюдением отступов.

                                                                                                            А со стилем Modula/Ruby/etc., например, не надо ставить таких искусственных условий.

                                                                                                            > Скорее это проблема тех, кто работает с Python или просто новичок.

                                                                                                            Вы не в теме. Проблема висячего else это проблема, которая известна давно до появления Python (а в Питоне её не может быть по определению). А что «просто новичок» — согласен, профессионал, пару раз обжёгшись, просто введёт принцип «скобки обязаны быть всегда».

                                                                                                            > Ни разу за уже 9 лет работы с Delphi (Object Pascal т.е.) такого не было.

                                                                                                            А у меня было, когда с ним работал. И у тех, кто сейчас учится — постоянная проблема.

                                                                                                            > Остальное все вкусовщина — кто к чему привык.

                                                                                                            «Остального» не было, но статистика вкусовщины это уже не вкусовщина. А по ней таки упорно движутся в сторону тех подходов, что я описал как исправленные. Только паскалисты продолжают цепляться за своё легаси, хотя даже автор языка давно советует обновиться.
                                                                                                            • 0
                                                                                                              И вы отказываетесь читать то, что написано прямым текстом.
                                                                                                              Сейчас, да, есть подобные библиотеки, и их можно использовать. Тогда — не было. Поезд ушёл тогда, до середины 90-х, а не сейчас.

                                                                                                              Паскаль в той или иной ипостаси существует и поныне. А смысла в претензиях к версиям давно минувших дней — немного.

                                                                                                              И во второй раз не хотите читать. Проблема не в самой работе с хэндлами, а в том, что в writeln с компанией или есть скрытый аргумент в виде stdout (или как он там зовётся в Паскале), или его нет.

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

                                                                                                              С такой аргументацией прямая дорога к Лиспу. У вас может сколько угодно «лучше читаться» второе, но если не ставить скобки, то ожидаемое не соответствует реальному.

                                                                                                              Ваши некорректные ожидания — ваша проблема. С такими аргументами вы можете требовать, чтобы программа работала корректно, несмотря на ваши логические ошибки — вы же ожидали иное.
                                                                                                              Необязательные begin-end — худший вариант из четырёх рассмотренных.

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

                                                                                                              А со стилем Modula/Ruby/etc., например, не надо ставить таких искусственных условий.

                                                                                                              По большому счету — это просто еще одно правило для автоформатера.

                                                                                                              Вы не в теме. Проблема висячего else это проблема, которая известна давно до появления Python (а в Питоне её не может быть по определению).

                                                                                                              Нет, это вы не поняли. Мой ответ относился ко второй вашей фразе, а не к висящему else.

                                                                                                              А у меня было, когда с ним работал. И у тех, кто сейчас учится — постоянная проблема.

                                                                                                              Здесь нет предмета для спора — у вас свой опыт, у меня свой. Разные команды, разные правила, разная среда, разный результат — кто-то так не обжигается, а кто-то во весь рост.

                                                                                                              «Остального» не было, но статистика вкусовщины это уже не вкусовщина

                                                                                                              Было. Отнюдь, это остается вкусовщиной, и то, что мейнстрим пошел в другом направлении, само по себе ничего не значит. У некоего языка есть набор параметров, преимуществ и недостатков. И если по тем или иным обстоятельствам язык Х потерял рынок и ушел на обочину, это вовсе не означает, что все его свойства и особенности (включая синтаксис) плохи.
                                                                                                              • 0
                                                                                                                > Паскаль в той или иной ипостаси существует и поныне. А смысла в претензиях к версиям давно минувших дней — немного.

                                                                                                                Ага, «существует». В следовых количествах.

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

                                                                                                                Когда нельзя самому такое сделать — это не вариация неопределённого списка, это другое, недоступное.

                                                                                                                > Ваши некорректные ожидания — ваша проблема.

                                                                                                                Ожидания совершенно корректные и конкретные — эргономические и POLA.

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

                                                                                                                Среди рассмотренных четырёх вариантов опциональные begin-end — самый мусорный вариант.

                                                                                                                > Нет, это вы не поняли. Мой ответ относился ко второй вашей фразе, а не к висящему else.

                                                                                                                Принципиально проблема не меняется. Посмотрите тут рядом рассказы от PVS-Studio — случаев «забыли обернуть в скобки», мягко говоря, дофига.
                                                                                                                Питонист тут как раз скорее сам всегда будет ставить скобки, для страховки.

                                                                                                                > И если по тем или иным обстоятельствам язык Х потерял рынок и ушел на обочину, это вовсе не означает, что все его свойства и особенности (включая синтаксис) плохи.

                                                                                                                Про «все» я и не говорил. Но упомянул те, которые однозначно плохи.
                                                                                                                • 0
                                                                                                                  Принципиально проблема не меняется. Посмотрите тут рядом рассказы от PVS-Studio — случаев «забыли обернуть в скобки», мягко говоря, дофига.

                                                                                                                  Поэтому в компиляторы впилили соответствующий warning, например. А с весьма прошаренными программистами, у которых за плечами лет 40 опыта, и которые не ставят скобки вокруг однострочных тел, я встречался. Да и самому мне они претят, уродливо выглядит оно как-то.
                                                                                                                  • 0
                                                                                                                    Да и самому мне они претят, уродливо выглядит оно как-то.

                                                                                                                    Мне тоже немного не нравятся. Но я осознаю, что это вопрос привычки. А объективная польза от них достаточно высока, чтобы это терпеть.


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

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

                                                                                                      • +1
                                                                                                        А чем Rust не такой язык?
                                                                                                      • 0
                                                                                                        Язык С не так сложно выучить, а вот польза от этого может быть существенная.

                                                                                                        Наверное стоило бы добавить — «однако писать на нём очень не просто».
                                                                                                        • –1
                                                                                                          Прадед мой лопухом подтирался.
                                                                                                          Дед мой лопухом подтирался.
                                                                                                          Отец мой лопухом подтирался.
                                                                                                          Я сам лопухом всю жизнь подтирался.
                                                                                                          И тебе, сынок, придется.
                                                                                                          • +10
                                                                                                            Спят подружки вредные
                                                                                                            Безмятежным сном.
                                                                                                            Снятся мышкам хлебные
                                                                                                            Крошки под столом,
                                                                                                            Буратинам — досточки,
                                                                                                            Кошкам — караси,
                                                                                                            Всем собакам — косточки,
                                                                                                            Программистам — Си.
                                                                                                            • +3
                                                                                                              Помнится, первая (а может и вторая) версия Windows была написана на Pascal. От него осталась соответствующая конвенция вызова функций Win16 API.
                                                                                                              • +1

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


                                                                                                                Впрочем, не все довольны возможностями, предоставляемыми C. Microsoft использует SAL (source-code annotation language) в драйверах, API и, надо полагать, в ядре. SAL позволяет в машиночитаемой форме сказать что-то вроде: "Этот параметр — не просто указатель, а указатель на массив, длина которого содержится вот в этом параметре", а также многое другое.

                                                                                                                • 0

                                                                                                                  Дополнение. QWERTY не предотвращает сцепление рычагов (клавиши E и R для часто встречающегося в английском "er" расположены рядом) и не самая удобная раскладка для печати.

                                                                                                                  • 0
                                                                                                                    Емнип, ходит легенда про то, что на высокой скорости печати соответствующие узлы ломались/стопорились и для этого сделали искусственное замедление скорости печати.
                                                                                                                    Но мне больше нравится легенда о том, что это сделано было в рекламных целях — что бы название конторы, выпускающей первые машинки с QWERTY раскладкой можно было напечатать используя символы одного ряда клавиатуры.
                                                                                                                • +2

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


                                                                                                                  А я утром встал, сходил в туалет, умылся — и уже опаздываю (с)

                                                                                                                  • –1
                                                                                                                    Еще Redis, Nginx, SQLite, которые есть в большинстве проектов.
                                                                                                                    • –1
                                                                                                                      Более того, все промышленные «вещи» спроектированы в CAD системах, написанных на С/С++. Думаю С/С++ на сегодня самый лучший язык.
                                                                                                                      • +2

                                                                                                                        А что за мифический язык "C/C++" такой? Это C или C++? Или что-то другое? Прошу прощения, наверное глупый вопрос, но слишком давно мучает, много где встречается подобная формулировка. Не придираюсь, и не стеб, правда интересно, что вкладывают люди в этот термин.

                                                                                                                        • –1
                                                                                                                          То что большие проекты не пишут на одном языке, обычно используют связку С и С++. С — для низкоуровневого функционала, где нужна скорость и компактность а на С++ более высокий уровень — основной GUI, бизнес-логику и т.д. где распыляться на мелочи нет времени.