IT в России и мире в реалиях мирового кризиса
1,404,091 8,484
 

  Jack Doe ( Слушатель )
03 мар 2016 23:43:15

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

новая дискуссия Дискуссия  237

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

С++ - это переходной вариант. STL даёт коллекции Явы/С#, Qt - кросс-платформенные и простые в разработке окошки, ручное управление памятью и компиляция напрямую в машинные инструкции - достаточную скорость и гибкость. Ну и некоторые области не оставляют выбора, к примеру писать на чистом Си программу, взаимодействующую с OLE - очень сильный постмодернизьм, хотя и возможно.
Си и С++ фундаментально отличаются лишь более богатой семантикой последнего, но указатели и malloc никуда не делись, потому это все тот же Си со свистелками и перделками.

C#, Java - несмотря на синтаксическую схожесть с С++, имеют два фундаментальных отличия, переводящих их совсем в другой класс языков: автоматическое управление памятью, и компиляция в промежуточный байт-код. Первая особенность делает программы очень устойчивыми, не позволяет допускать большой и неприятный класс ошибок распределения памяти. Вторая особенность для программиста означает полную абстракцию от оборудования. Ну и ещё некую условную портабельность, хотя в реальности она не больше, чем портабельность кода на Си на разных компиляторах и окружения. Плюс богатейшие библиотеки классов из коробки - и готов кровавый Энтерпрайз.
Это очень хорошие языки, современные, мощные и удобные. На них можно писать даже некоторые системные вещи. Из недостатков - худшая скорость, необходимость тащить за собой runtime-окружение, но это все неважно для корпоративной разработки.

Дельфи делит нишу с С++. Ничего принципиально другого он не предоставляет - то же ручное управление памятью, прямая компиляция и адресная арифметика из-под полы. Я часто встречаю исходники на нем на форумах за 2000-2010 годы. Наверное где-то он ещё в ходу.

Дальше идёт, как ни странно, PHP. Несмотря на его одиозность, половина Интернета написана на нем. Все его сильные стороны являются также и слабыми, т.к. используются неправильно программистами квалификации чуть выше никакой: слабая (я бы сказал, нечёткая) типизация, автоматическая память и интерпретируемость. Рантайм-типы плюс eval потенциально создают ситуации, когда программист не в состоянии предсказать поведение программы.
 В итоге появляются такие монстры как Magento.
Ключевое достоинство/недостаток - очень низкий порог входа. Об этом чуть ниже.

JavaScript - его собрат с другой стороны http-сессии. Все то же, кроме отсутствия единого стандарта, как итог - библиотеки типа jquery для более-менее низкоуровневого письма, и в последние годы фреймворки а ля angular.js. Ключевое преимущество - отсутствие необходимости писать свой собственный клиент для клиент-серверного приложения. Можно взять броузер с js.

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

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

Теперь о том, как выбирается язык для задачи.
Во-первых, если твои подчиненные пишут на Х, скорей всего на нем будет написана и новая задача, т.к. брать кого-то в штат дорого, а осваивать новую компетенцию (не то же, что учить новый язык!) долго.
Во-вторых, если у тебя пока нет подчиненных, но есть эксперт, ты наберешь штат спецов, каких тебе скажет эксперт.
Если эксперта нет, ты наберешь спецов, которые дешевле и которые дадут продукт быстро. Это будет ява-сишарп для десктопа-энтерпрайза,или пэхапе для веба.
Ключевой для бизнеса критерий выбора - скорость разработки, порог входа (см.выше про пхп), доступность спецов на рынке. Последний критерий как бы не самый важный. Нужно, чтобы я без проблем мог заменить спеца, а не искать по олимпиадам чувака, знающего какую-нибудь scalу, потому что в наследство достался проект на ней.
Отредактировано: Jack Doe - 03 мар 2016 23:57:49
  • +0.08 / 7
  • АУ
ОТВЕТЫ (1)
 
 
  Удаленный пользователь
04 мар 2016 08:56:04

Немножко в сторону PHP. Предъявлять какие-то большие требования к нему не имеет смысла. Он нужен для прокладки между чем-то большим, темным и не понятным на сервере и красивым у клиента в браузере. На мой взгляд, прекрасно справляется. От явы я сейчас усиленно избавляюсь (со своей гребаной политикой постоянных латаний дыр и желанием браузера с ентой самой бедой работать). Получить данные от клиента, сформировать запрос к СУБД, сверстать страничку и отдать клиенту (оптимизированную по самое и не содержащую в своем теле какие-то важные элементы модели взаимодействия или структуры продукта). Ежели нужно что-то близкое к аппаратным средствам, то чем лучше компилятор, тем лучше (Сишный на мой взгляд). Ежели у вас мега проект, то будет однозначно своя среда разработки с кучей типизированных функций и штатом программистов. Для внедрения, чем меньше всяких магических действий нужно сделать на компе пользователя, тем лучше. По поводу богатой библиотеки. На мой взгляд это богатство юзают или прожженные, либо усидчивые (которые не любят изобретать велосипед и есть возможность пролопатить архимегапупер крутой набор библиотек и потом интегрировать в свой проект). По поводу синтаксиса. Это на мой взгляд обертка от конфеты. К чему человек привык так ему и нравится. Я на своем веку шкодил в очень многих средах от ASMа до делфей с VB и каждый раз сидишь и плюешься, то точка с запятой, то скобочки, то вызов не так организован, то еще какая-то особенность и уникальность супер удобной среды. На мой взгляд важно на сколько меньше "мусора" образуется в коде при компиляции. Но принимая во внимание производительность современных компов, то, что прога собрана крупно модульным методом (в которых может использоваться менее процента функционала модуля) является не таким уж критическим.
Далее, проекты делятся на категории. Где-то важна юзабельность, где-то производительность, где-то адаптивность. Всё это по большей части взаимоисключающие условия. Т.е. если вам надо супер пупер производительную систему, то в ней будет один процесс, если надо рюшечки с фигушечками и мусипусечками, то клиент имеет парк мощного железа с хорошими каналами или вообще не помышляет о сетевом обмене данных. Вспоминается мультик про Каштанку (плотник супротив столяра). Заставьте столяра дом трехэтажный построить? Смеющийся
  • +0.00 / 0
  • АУ