Языки программирования – 14

Для написания, например, ASP страниц есть два языка – C# и VB. В справках по функциям и объектам обычно есть несколько описаний:
https://msdn.microsoft.com

C# C++ - два вида Си, VB это Visual Basic. F# - появилось только что, не знаю что это.
Просто для наглядности две программы делающие одно и то же на Си и на VB:
C#:


VB:


Эта функция, которая вызывает хранимую процедуру на SQL Server-е и переписывает полученные строки информации во таблицу HTML страницы, которая будет показана на экране. В качестве параметров хранимой процедуре передаются параметры поиска. Например в варианте для VB (просмотр содержимого документа) можно выбрать не все строки документа а только те, в примечании которых введена подстрока поиска введённая в поле txtName.
Кусок хранимой процедуры просто чтобы было понятно, что там внутри:

Теоретически можно было бы все варианты засунуть в SQL строку, сгенерированную по тому, какие параметры поиска введены, а какие нет. Всё будет найдено, но это потребует больше времени чем отработка скомпилированной и готовой к выполнению хранимой процедуры, в которой те же варианты находятся в отдельных IF ветках: Если НЕ переданы
LS и Ek – SQL строка вообще без условий, если передано LS и не передано Ek – другой вариант строки и т.д.
Тексты на Си и VB отличаются только мелкими деталями. В Си все строки заканчиваются знаком «;», в VB его вводить не надо.
Ввод или отсутствие этого символа происходит автоматически. Это первая причина почему из двух языков так и не сделалось одного. У одних привычки такие, у других другие. Переучить половину программистов –задача неподъемная. Проще оставить два языка.
VB с его EndSub, EndIf вместо “}” – более читаем, хотя кто-то может сказать, что нажимать лишние кнопки утомительно.
В VB есть очень приятный “with”, позволяющий не писать каждый раз полный путь к свойству или функции. Именно поэтому VB варианте:
With modMain.MainClass
    .cmd_sp(cmd, "sp_hfg_Peredv_A")
    .AddCmdParI(cmd, "@intNew", intNew)
а в Си приходится каждый раз писать “NSSQLFunc.sql_func”, что тоже менее читаемо:
  NSSQLFunc.sql_func.cmd_sp(cmd, pri_sp_List);
  NSSQLFunc.sql_func.AddCmdParI(cmd, "@intNew", intNew);
VB удобнее, читаемее и даже выгладит более доделанным по среде программирования:

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

Т.е если смотреть на язык с точки зрения программиста – пользователя, т.е человека, которому просто нужен рабочий инструмент, на котором надо быстро и удобно писать наверное VB лучше. По возможностям они ничем не отличаются. В примерах видно, что чуть по-разному но вызываются одни и те же функции.
С другой стороны диалекты Си например в виде JS это всё-таки общепринятый стандарт. Здесь, например:
http://akostina76.ucoz.ru/blog/2016-10-09-3503

… внутренний скрипт AJAX написан на JS. Причём просто потому что такие вещи приятно писать на JS.
Переключение языков происходит очень легко:

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

В сторону: Вот интересно, по какой пьяни так было написано?... (с). То ли из опасений, что если точку с запятой стереть случиться что-то страшное. То ли потому, что лень было искать, что там надо для VB писать вместо “javascript”…
Т.е на поверхности эти языки на данный момент не отличаются ничем. Более того, всё сделано для того чтобы их использование ничем не отличалось, а различие осталось этакой данью традиции и результатом истории развития.
Но возможно есть ещё один, более глубокий уровень. Просто для иллюстрации: Парень в офисе поинтересовался когда будет новая бумажка. Я сказала, что если с первого раза получится то через полчала. Помню искренне недоумение в глазах и голосе: «А почему с первого раза не должно получиться?». В этот момент я поняла, что постоянное ожидание какой-то подлянки это моя личная профессиональная черта.
Специфика работы описывается просто. Есть батарейка и есть лампочка. Между ними куча проводов. Если хоть один подключен неправильно, то лампочка гореть не будет. А проводов действительно очень много. Ещё один анекдот про программиста:
- Папа, Солнце встаёт каждое утро на востоке а вечером садится на западе.
- Точно?
- Да.
- Ты проверял? Каждый день?
- Да, каждый день.
- Только пожалуйста, сынок, ничего не трогай.
А это уже не анекдот а самый настоящий случай из жизни моего приятеля. Он купил в магазине брюки. Видимо, чтобы брюки лучше смотрелись на вешалке боковые карманы были парой стежков прихвачены в середине. Он не распарывал. Так и лез в карманы двумя пальцами.
- Почему?...
- А вдруг что-нибудь случиться?
Видимо он тихо опасался что у него все штаны развалятся если он уберёт эту наметку.
С проблемой случайных ошибок каждый борется по своему. Могут быть например банальные опечатки в названиях. В Си все переменные должны быть описаны и только потом использованы. Т.е описание переменной это сознательное действие, которое делает программист, ещё один «контакт» - провод, который он сознательно соединят чтобы «лампочка» зажглась. Во времена ассемблера под переменные сознательно выделяли место в памяти. Во времена Турбо Си строка заранее неизвестного размера создавалась отдельной функцией и там тоже были отдельные хитрости. Сейчас компиляторы способны и сами выполнить эти действия если они вдруг обнаружат использование неописанной переменной. Это и делает VB.
Но пусть сделана ошибка в названии, т.е данные например залиты в таблицу tblData, а читать их пытаются из tblDate. Компилятор VB ничего не скажет и придётся потом долго искать место «обрыва» потому что на экране, например, ничего не появится или всё наоборот пропадёт после каких-то действий.
VB позволяет большую расхлябанность при написании. Если человек на нем пишет, то он борется с опечатками и прочим как-то иначе чем в Си. Но возможно тут есть ещё и психологический момент. В Си действия более осознаны, а это отчасти хорошо, когда понятно что происходит внутри и точно известно что (по списку) должно быть сделано для достижения результата.
Например при использовании Си надо в явном виде прицепить обработчики событий для используемых элементов экрана:

Выглядит это какой-то недоработкой. Если я помещаю на страницу элемент для ввода текста наверное мне надо будет обрабатывать событие его изменения. Чего же он сам не пропишет это событии в нужном месте?!...
Про место, в котором это всё должно быть прописано чтобы всё вместе заработало тут:
http://akostina76.ucoz.ru/blog/2016-09-30-3477

… Т.е это какой-то аналог WinAPI->WM_COMMAND или просто он самый.
Но в каком-то смысле это логично. Я вижу весь «провод» ведущий от «батарейки» к «лампочке». Я описываю переменные, примерно зная, что за ассемблерный текст будет там внутри. Я рисую, пусть и в HTML виде то, что будет на экране. Но для меня это аналог текстов, помещаемых в ветке WinAPI->WM_CREATE. Наконец я в явном виде вставляю обработчики событий, понимая что чтобы всё заработало должен быть и этот «провод». Во всяком случае я не придумала другого объяснения того что обработчики надо присоединять в явном виде. Не представляю в каком случае может быть нужно чтобы их не было (т.е чтобы была возможность их отключить).
Насколько всё это ценно большой вопрос. С одной стороны понимание того как это всё внутри работает и видение обычно скрытых «проводов» может повысить уверенность в результате. Это приучает к самоценной аккуратности которая и сама может работать на результат. С другой стороны простота работы как правило важнее.
Знание того, что происходит внутри нужно очень редко. Здесь описана ситуация при которой начал разваливаться формально прочный файл базы данных:
http://akostina76.ucoz.ru/blog/2016-10-11-3507

… Я не знаю как внутри устроен GDB файл. Но я знаю, как устроен DBF файл и сильно сомневаюсь, что хранение данных в GDB чем-то принципиально отличается. А с чего действительно отказываться от простого и удобного хранения строка за строкой? Это всё мне не надо. Мне надо знать, как писать SQL строки. Всё остальное скрыто чтобы не засорять мою голову ненужной информацией. Теоретически инструмент должен быть надёжным и позволять делать всё и без этих знаний. Практически же того, что там внутри никто не отменял. И знание позволяет представить что скорее всего не надо делать даже если оно явно нигде не запрещено. 
Так что я не возьмусь сказать, что лучше осознанная прокладка вручную всех «проводов» с возможность что-то прикрутить своими руками или максимальная автоматизация скрывающая от глаз часть этого «провода» но обычно ускоряющая процесс.