Антиквар, спасибо за ответ!
И чем плох эмулятор DOSBOX? Он прост в настройке и заодно позволяет использовать другие ДОС-программы.
Тем, что не нативное приложение со всеми вытекающими последствиями, например:
1. проблемы с кодировками (русский текст в bas-файлах превратится в "крокозябры" в нативных Win редакторах вроде Wordpad и Notepad);
2. нет буфера обмена. Очень часто в процессе работы над программой нужно слазить в другой файл и скопировать оттуда кусок. Или, например, скопировать из какого-то документа — из вашей статьи, например;
3. я бы поспорил о том, что полная установка и настройка происходит легко: сам эмулятор, GUI к нему, русификатор DOS'а, среда программирования... — получается большой комплект. Довольно сложно для типичного современного пользователя (если он не интересуется старыми ПК и т.п.). Мой товарищ, например, изучает программирование на Си с web-IDE, т.е. пишет и запускает программы прямо в браузере — довольно показательный пример, я считаю.
эти проблемы актуальны для программиста-профессионала
int64 — соглашусь. Но Unicode и работа с http(s) — это современные реалии, а не что-то сугубо специфическое для IT.
Любитель может даже не знать, что такое регулярные выражения smile И тем не менее, делать расчеты и писать игрушки на бейсике.
Да может, может. Только получится индусский код 
У меня даже есть история на этот счёт. Когда я был маленьким и глупым, решил на VB написать оболочку-интерпретатор текстовых квестов (что-то вроде Z-Machine или современных движков визуальных новелл Ren'Py, только гораздо примитивнее). Там был свой скриптовый язык, позволяющий выводить текст, изображения, аудио, добавлять список игровых действий, использовать внутриигровые переменные, организовывать ветвления и т.п.
Всё бы хорошо, но получившийся "скриптовый" язык требовал неукоснительного соблюдения синтаксиса, вплоть до пробелов в нужных местах, заглавных\строчных букв и т.п. Потому что в программе-"интерпретаторе" везде были строгие сравнения, а "парсинг" аргументов был организован с помощью оператора Mid$, который получал это значение из "нужной" (прибитой гвоздями прямо в программе) позиции в строке. Соответственно, любой лишний пробел сдвигал аргумент, и Mid$ вырезал уже не то, что нужно.
Смотреть без боли сейчас на тот код я не могу. Ах, если бы я знал тогда про регулярные выражения.. Поэтому мой ответ таков: программировать-то можно без знаний, но лучше всё-таки всё изучать предметно и сразу стараться использовать общепринятые подходы, а не изобретать велосипед.
мы наверно понимаем под задачами что-то разное
Нет, я примерно в таком же ключе и рассуждал.
Вот допустим, мне надо перевести градусы Фаренгейта в градусы Цельсия.
И каждый раз запускать DOSBOX, чтобы выполнить конвертацию? Хм...
В общем, мне много что есть сказать на эту тему, но я понимаю, что всё равно никуда это не приведёт, так что остановлюсь на этом. Со времён QB появилось большое число более гибких инструментов, после которых — я гарантирую это — никому не захочется возвращаться на Бейкик (ну разве что из чувств ностальгии, но никак не для решения практических задач). И, тем более, когда привыкаешь к "фичам" современных языков, советовать кому-то QBasic кажется просто абсурдом.
Однако я соглашусь с тем, что существуют такие платформы, где Basic действительно оправдан. Ну, например, если вам вдруг захочется написать что-то для Commodore 64 или GameBoy Advance. Но, опять же, написание программ для подобных экзотических девайсов мало связано с решением практических задач.
Поэтому моё итоговое мнение таково: для собственного удовольствия можно писать хоть на QB, хоть на brainfuck, хоть в хексах вводить машинные команды. Но для решения практических задач нужно стремится использовать актуальные общепринятые инструменты, а не подобную экзотику.
