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

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

Попробовал на примере «крестиков-ноликов» на Коболе.

С версией 3,5 что-то даже получается — если по ответу я понимал, что нейросеть чего-то не знает, искал ответ и он действительно помогал. Чтобы было понятно о чём речь, первое, что мне пришлось нагуглить и подсказать — как в Коболе организован ввод с клавиатуры.

К сожалению, размера контекста у ChatGPT не хватило, чтобы дойти до конца, но в целом, считаю, эксперимент прошёл удачно, а вывод такой — если дать возможность модели GPT-3.5 гуглить, она это сможет использовать.

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

Unfortunately, we cannot provide a step-by-step guide for rewriting the program in COBOL as it requires a deep understanding of the language and its syntax. However, we recommend consulting resources and tutorials specific to COBOL programming.

И сильно дальше этого мне пока продвинуться не удалось. Осложняется всё тем, что у меня сейчас нет доступа к ChatGPT-4, то есть версии, которая умеет хранить контекст.

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

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

Another obvious problem is the different path separators between HFS+ (colon, ’:’) and UFS (slash, ’/’). This also means that HFS+ file names may contain the slash character and not colons, while the opposite is true for UFS file names. This was easy to address, though it involves transforming strings back and forth.

The HFS+ implementation in the kernel’s VFS layer converts colon to slash and vice versa when reading from and writing to the on-disk format. So on disk the separator is a colon, but at the VFS layer (and therefore anything above it and the kernel, such as libc) it’s a slash. However, the traditional Mac OS toolkits expect colons, so above the BSD layer, the core Carbon toolkit does yet another translation. The result is that Carbon applications see colons, and everyone else sees slashes. This can create a user-visible schizophrenia in the rare cases of file names containing colon characters, which appear to Carbon applications as slash characters, but to BSD programs and Cocoa applications as colons.

На скриншоте видно как это выглядит в жизни: в командной строке создаём папку с двоеточием в имени, в Файндере в этом месте — слеш. В цитате такое поведение метко названо «шизофренией».

Создаём в командной строке папку с двоеточием в имени, в Файндере в этом месте — слеш