Комментарии: Программирование

Симонов Сергей : другие произведения.

Комментарии: Программирование
()

Самиздат: [Регистрация] [Найти] [Рейтинги] [Обсуждения] [Новинки] [Обзоры] [Помощь|Техвопросы]

Размещен: 20/03/2017, изменен: 20/03/2017. 0k. Статистика.

Аннотация:
Тема для обсуждения всего, связанного с программированием и софтом. Для "железа" будет скоро восстановлена тема "Электроника, ЭВМ, железо".

ОБСУЖДЕНИЯ: Фантастика (последние)
09:50 Колышкин В.Е. "Контрольное обрезание" (30/6)
09:37 Орлов Д.Е. "Маленький Саша. Прода. 96" (248/1)
09:34 Кротов С.В. "Чаганов: Война. Часть 4" (185/16)
09:20 Чернов К.Н. "Записки Империалиста Книга " (588/17)

Добавить комментарий Отсортировано по:[убыванию][возрастанию]Страниц (10): 1 2 3 4 5 6 7 8 9 10 Архивы (1): 1

ОБЩИЕ ГОСТЕВЫЕ: 09:44 "Технические вопросы "Самиздата"" (172/35) 09:44 "Форум: все за 12 часов" (249/101) 08:12 "Форум: Трибуна люду" (850/21) 19:02 "Диалоги о Творчестве" (207/1) 15/11 "Форум: Литературные объявления" (664) 25/11 "О блокировании "Самиздата"" (294)
ОБСУЖДАЕМ: Симонов С. 07:55 "Сельское хозяйство" (623/1) 04:12 "Электронная периферия, связь, " (183/1) 04:08 "Автомобили, мотоциклы автомотохотелки," (92/1) 04:07 "Общественный транспорт, градостроительство" (228/1) 21/11 "Коммунизм, сталинизм, троцкизм, " (961) 18/11 "Контейнеры и грузоперевозки, " (927) 17/11 "Новые технологии в промышленности" (624) 16/11 "Центральный флуд" (827) 12/11 "Вооружённые силы и техника" (970) 06/11 "Атомная промышленность, энергетика, " (851) 03/11 "Флот. Морские системы вооружений" (788) 02/11 "Проект советской космической " (960) 02/11 "Создание правильного образа " (557) 30/10 "Огас и Плановая экономика" (393) 30/10 "Медицина, биология" (1007) 26/10 "Законодательство, правоприменительная " (584) 24/10 "Гражданская авиация" (1004) 19/10 "Вертолёты" (820) 14/10 "Робототехника, сложная бытовая " (279) 13/10 "Наука и образование как ключ " (266) 10/10 "День хризантем" (33) 10/10 "Военная авиация" (715) 06/10 "Химия и материалы" (347) 04/10 "Строительство и быстровозводимые " (739) 22/09 "Цвет сверхдержавы - красный " (527) 13/09 "Демография и сопутствующее" (849) 29/08 "Цвет сверхдержавы - красный " (500) 18/08 "Цвет сверхдержавы - красный " (551) 16/07 "Кино" (108) 12/07 "Пво, Про, Зрк, Урвв" (1006) 07/06 "Жизнь бесценна" (41) 07/06 "Орион. Возможности, проблемы " (986) 28/05 "Музыка" (577) 25/05 "Цвет сверхдержавы - красный " (446) 09/05 "Телевидение, фототехника, " (466) 20/04 "Цвет сверхдержавы - красный " (234) 19/04 "Предложения по палубной авиации " (988) 20/02 "Дружба миров" (48) 13/02 "Культура" (990) 31/01 "Программирование" (361) 25/01 "Теории заговора" (130) 09/01 "Геология и горная промышленность" (484) 06/01 "Четвёртый Интернационал" (44) 26/06 "Цвет сверхдержавы - красный " (21) 05/05 "Low Orbital Ion Cannon" (46) 05/05 "Спираль истории Книга 1" (44) 23/04 "Система Енонла" (11) 21/04 "Невоенное противостояние с " (480) 21/03 "Председатель Галактики" (111) 20/11 "Актуальная тема - Международное " (963) 07/11 "Цвет сверхдержавы - красный " (78) 04/09 "Металлургия" (236) 14/05 "Время, континуум, и параллельные " (415) 16/03 "Цвет сверхдержавы - красный " (983) 23/02 "Разведка и контрразведка" (605) 22/01 "Экранопланы" (200) 13/07 "Нетехнические фанфики" (123) 09/07 "О магии стихий, рыжем кошаке " (96) 24/10 "Проект конституции Аи-Ссср" (116) 29/05 "Выставки 1959 года" (438) 16/10 "Спираль истории Книга 2" (30) 20/12 "Цвет сверхдержавы - красный " (30)
ОБСУЖДЕНИЯ: (все обсуждения) (последние) 09:50 Колышкин В.Е. "Контрольное обрезание" (30/6) 09:50 Юрьев О. "Когда будет 3-я или 4-я мировая " (2/1) 09:46 Ursa M. "Немного о реальности" (5/1) 09:44 Самиздат "Технические вопросы "Самиздата"" (172/35) 09:41 Баламут П. "Ша39 Гранаты" (572/2) 09:40 Ив. Н. "25 ноября" (1) 09:40 Ролько Т. "Гносеология наизнанку" (305/1) 09:40 Баранов М.В. "Муха" (39/2) 09:39 Бурель Л.Л. "Увы, опять о грусти" (3/2) 09:37 Чваков Д. "Шлак, версия" (2/1) 09:37 Орлов Д.Е. "Маленький Саша. Прода. 96" (248/1) 09:36 Егорыч "Ник Максима" (6/5) 09:34 Кротов С.В. "Чаганов: Война. Часть 4" (185/16) 09:25 Березина Е.Л. "Как-то юнга Дудочкин бросил " (4/3) 09:24 Никитин В. "Обращение к читателям" (2/1) 09:22 Никитин А.Д. "Единство Которое все ждут" (1) 09:21 Чернов К.Н. "Армия, флот, вооружение (Записки)" (338/4) 09:19 Берг D.Н. "Мы из Кронштадта, подотдел " (583/1) 09:15 Нейтак А.М. "В порядке похихи" (263/8) 09:12 Русова М. "Утро" (2/1) Полный список...>>
РУЛЕТКА: Путь Шамана. Шаг Ночлежка "У Крокодила" В родном краю Рекомендует Пузеп Н.В. ВСЕГО В ЖУРНАЛЕ: Авторов: 108551 Произведений: 1670555 Список известности России СМ. ТАКЖЕ: Заграница.lib.ru \| Интервью СИ Музыка.lib.ru \| Туризм.lib.ru Художники \| Звезды Самиздата ArtOfWar \| Okopka.ru Фильм про "Самиздат" Уровень Шума: Интервью про "Самиздат" НАШИ КОНКУРСЫ: Рождественский детектив-24	24/11 ПОЗДРАВЛЯЕМ: Белашова Ю.Ю. Белль С.В. Богатикова О.Ю. Богданов А. Бонд. П.Б. Бредникова Е.Е. Букаринов Д.Н. Веденин В.А. Ветер К. Визмор Э.Н. Виноградова А.В. Галицкая Д.И. Гамова Д. Гончарова Е.В. Егорова В.Ю. Ежова Е.С. Елисеева Н.В. Ельников А.Д. Жалилова Л.С. Желнов П. Иванов А.А. Инеева С. Ищенко Г.В. Казарян М.В. Келлер Е. Кизяева А.А. Кичилова К.Ф. Колодиец Д.Н. Кольцо-Гид Команов С.С. Кондрашов В.А. Копышов А.Н. Корнеева Т.М. Коршунова Т.В. Ксения Лобков А. Луковкин К. Лучистая Д.Т. Макарчук С.С. Маковская Н. Маркевич П. Митусова Л.П. Можар Е.П. Морозов М. Пашкевич С. Пимонов В.В. Пирумова А.Б. Приходько О. Пятница М. Радонин С. Ревельский Х. Романов Н.П. Рябенкова Д.П. Серебряная Е. Силаков Г. Соколовская Е. Солнечная Соцкая С. Сперанская И.В. Таа Трещев Ю.А. Тягин П.А. Шаповалова Д.В. Шеннон Р.А. Шишкина Д. Щедрин Р. Ak108u Ive Mollydolly Natkam Valxalla Viligodaeum Viscount M.D.
ПОСЛЕДНИЕ ПОСТУПЛЕНИЯ: (7day) (30day) (Рассылка) 00:39 Патрацкая Н.В. "Маг Грановский" 21/11 Кукин В. "Случайные рифмы" 21/11 Моисеева О.Ю. "Сердце Кометы" Полный список...>>

271. *Симонов Сергей (gann.lector@yandex.ru) 2021/03/14 08:47 [ответить]
  > > 270.Талипов Артём
   .
  >
  >> > 247.Симонов Сергей

  >
   >Набросок совещания. Без Серова там не обойтись, иначе Лебедев порежет cobol. К тому же изменение истории, а значит Келдыш. Полагаю, если Лебедев сам, чего-то порешает, в духе "я думаю, что так правильно и лучше, значит делаем так". За такое ему голову открутят и не посмотрят, что он академик.

  Совещание вполне вероятно. Вы так написали, будто предполагается совместная попойка :-)
  >

  >
   >Нафиг-нафиг. Ещё та мина замедленного действия.

  Хорошо, предлагайте варианты.

270. *Талипов Артём (eric50@yandex.ru) 2021/03/14 07:44 [ответить]
  > > 243.Габдрафиков Руслан Рамилевич
  >А иначе у меня тоже есть что сказать.

  Если бы у вас было что сказать, то почему молчали всё это время? Или хахотелось высказаться мне в пику?

  > > 245.Поляков Дмитрий
  >Ну как минимум прибить сразу предлагающих платформозависимые типы переменных можно
  >Все эти Инты Лонги и прочую ересь
  >Изначально указывать размерность в названии типа int8 uint8 итд
  >Нультерминированные строки и массивы туда же

  Спасибо Кэп! Да, согласен, что это было бы хорошо. Я и сам, ранее, высказывался в том же ключе.

  Но что делать с изначальной установкой АИ Хрущёва и Лебедева, чтоб присланные программы компилировалис?
  Брать те програмки, а затем доводить напильничком?
  С типами данных может прокатить, тем более, что обычно используют стандартные int8_t, int16_t, int32_t, int64_t и так далее.
  А вот как надругаться над строками, чтоб они стали нормальными, но при этом не сломать хаки? Размерности объектов сразу пойдут лесом.

  >Подобных "мелочей" вполне хватит чтобы избавить от кучи геморроя в будущем
  >Больше стандартизации богу стандартизации))

  Да, там действительно есть что править. Чуть-чуть тут, чуть-чуть там, а в итоге получится другой язык. И полная совместимость пойдёт лесом.

  > > 246.Antonov Andy
  >ЗЫ С нультерминированными строками ты знатно подгадил всем пейсателям на Си, особливо из Редмонда.

  Я тоже против C строк, но что прикажите делать? Извините, но малейшая попытка что-то исправить, приведёт к поломке кода. Это давно известная проблема, но ришения никто не придумал. Только замена к примеру std::string, std::string_view. и шаблонными перегрузками функций. Но даже так полностью избавиться от C строк не получилось.

  В АИ, можно было бы сделать язык C закрытым, только для посвященных. И только для компиляции исходников присланных из будущего. Затем доработать его напильничком, хорошенечко расширив и поправив баги. После чего, долго и мучительно, переписывать программы из будущего. А сколько человеколет на это уйдёт?

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

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

  > > 247.Симонов Сергей
  >Вот такого, полагаю, в реальности быть не могло. :-)

  Набросок совещания. Без Серова там не обойтись, иначе Лебедев порежет cobol. К тому же изменение истории, а значит Келдыш. Полагаю, если Лебедев сам, чего-то порешает, в духе "я думаю, что так правильно и лучше, значит делаем так". За такое ему голову открутят и не посмотрят, что он академик.

  >Согласен. Но на такой случай придуманы "недокументированные функции". Кстати, вполне возможно иметь версии языка - базовую и профессиональную / advanced.

  Нафиг-нафиг. Ещё та мина замедленного действия.
  До недокументированных функци обязательно доберуться и поднимут громкую вонь, а там и до теории заговоров рукой подать.
  Подобные версии языка, тоже плохо. Это создаст этакую элитарность, повод мерятся пиписьками и справоцирует классовое расслоение общества.

  >Я с ними не знаком, но раз они есть, то можно их упомянуть.

  Гым. Пожалуй можно. Но это мельком. Они всего лишь упрощают создание своего языка. А руками там ещё пилить.

  >Я представляю себе это, скорее, как список свойств в формате "ключ: значение", либо вообще как базу данных, содержащую в полях всю информацию.

  В упрощении, как-то так и есть. Но там и форматы кривенькие и задача специфичная. Так что в описании, ещё дополнительный код для обработки.
  Но я повторяю, это только генератор части программы, для разбора текста исходного кода. Осатльно надо делать самому.

  > > 251.Габдрафиков Руслан Рамилевич
  >Тут есть тонкий нюанс выделения памяти под разные кодировки в строковых типах. Хорошо иметь один универсальный тип под строки. Потому что строки не числа. Строки состоят из символов (char) а те в свою очередь из байт или бит.

  Спасибо, Кэп! Вы опять впомнили меня.

  Оба ваших варианта, в принципе правильные, но у них есть серьёзные минусы.

  >Первый - создать тип StringN где N размерность типа char внутри реализации строкового типа.

  Ага, что приводит к зоопарку и несовместимости строк, даже в одной программе. Зато покрывает потребности. И согласен, код проекта придётся менять. Это известное решение, например std::basic_string. По граблям потапатилсь изрядно.

  >Второй - забить создав один String который в будущем будет допилен когда подвезут больше разных кодировок.

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

  В итоге, оба варианта не годятся.

  > Если выбираем второй вариант то нам и int8 и uint64 нафиг не нужен.

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

  > > 252.Поляков Дмитрий
  >тем более длина того самого чара нифига не константа даже в пределах одной кодировки
  >даже в ansi

  Кхе-кхе, у вас тоже смешалис люди, кони.

  Во-первых, размер char это именно константа. sizeof(char) равен 1 всегда и везде. Эта такая шутка разработчиков стандарта.

  Во-вторых, то что вы назвали длиной чара, называется размерностью кодовой точки, а это несколько иное. Но это бумажная цифра.

  В-третьих, есть кодовые единицы, размерность которых относительна кодировки.

  В-четвёртых, для представления кодовой точки, используют от одной, до нескольких кодовых единиц. Количество зависит от кодировки и самого символа.

  >Нужно хранить кодировку как и длину в самой строке

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

  >вариант с приведением к единой кодировке был бы конечно куда красивее но невзлетит за отсутствием единой кодировки в природе да и по ресурсам слишком напряжен для древних компов

  А вот здесь полностью согласен.

  Эм-эм-эм, попадалось занятное и оригинальное решение. Но там тоже свои тараканчики побегали.

  1. В объекте строки хранится набор символов и длина. Кодировку знает только программа! Но это не важно.

  2. Строка принимает и возвращает текст в пользовательской кодировке. Та кодировка, которую настроил пользователь в системе. Или позднее в юникоде.

  3. Строка принимает бинарные закодированные данные, но нужно указать кодировку. Тогда бинарные данные автоматически раскодируются и сохранятся в строку.

  4. Строка отдаёт бинарные данные, если указать кодировку. Текст строки автоматически кодируется в указанную кодировку.

  Но такое решение, не идиально. Если надо подключить новую кодировку, то упс, проблема. Придётся самому раскодировать и задавать текст.

  > > 254.Габдрафиков Руслан Рамилевич
  >Просто работа с символами тоже очень важна. В разных языках о символах думают на очень последнем этапе проектирования языка.

  Согласен. Очень верное и справедливое замечание.

  > > 255.Габдрафиков Руслан Рамилевич
  >А если делать платформонезависимый int то под него будет выделяться столько памяти сколько символов в числе. Как с типом string в котором мы храним кодировку так и в типе int мы можем хранить размерность.

  Это верно только для большой или пользовательской арифметики. А на системном уровне это создаст проблемы.

  > > 258.Габдрафиков Руслан Рамилевич
  >> > 256.Поляков Дмитрий
  >>использовать же длинную арифметику которую вы скорее всего имели ввиду часто неразумно с точки зрения как быстродействия так и затрат памяти
  >Я имел в виду? О чем вы? Я что то пропустил?

  Констатируем незнание терминологии и поверхностное понимание проблематики.

  > > 265.Поляков Дмитрий
  >у человека и так люди с конями смешались


  Тема сложная. Емё можно долго курить. А потом обнаружить ещё что-то совсем новое.

  > > 267.Antonov Andy
  >> > 263.Поляков Дмитрий
  >>в той же utf8 символ может занимать от одного до бесконечности байт
  >Гм, разве бесконечности? Вроде, там 8 байт в пределе. Или я неправильно понял описание стандарта.

  Технически длина одной кодовой точке в utf-8 может доходить до 9 байт. Но по соображениям совместимости и разумности, длину ограничили 4 байтами, в порядке приказа. Любое привышение возможно, но это нарушает стандарт и должно считаться ошибкой.

  > > 269.Габдрафиков Руслан Рамилевич
  >В некоторых языках это называют utf-16. Но это скорее синтетический тип.

  Всё, не смешите мои тапочки. Вы уже спалили своё незнание темы.

  utf-16 если что, это сразу две кодировки! Также как utf-32. И utf-8 это тоже кодировка!

  Если в каких-то языках, говорят про строки utf-16, то это значит, что содержимое строки кодируется в utf-16.

  Значение char это уже кодовая единица, которая, тоже может быть в какое-то кодировке. Но внезапно, это ещё не код символа, хотя частенько принимается за код символа, ради упрощения.

269. Габдрафиков Руслан Рамилевич (the28awg@gmail.com) 2021/03/13 23:49 [ответить]
юникод постоянно развивается. Там появляются все новые и новые символы, а к старым добавляются цвета.
В некоторых языках это называют utf-16. Но это скорее синтетический тип.

268. Поляков Дмитрий 2021/03/13 23:49 [ответить]
  > > 267.Antonov Andy
  >Гм, разве бесконечности?
  можно прикрутить любое число модификаторов
  >Почти≠всегда!
  дык о том и речь что нельзя рассчитывать на то что символ гарантированно уложится в фиксированное число байт поэтому указывать что либо кроме кодировки бессмысленно
  а там уж зная кодировку перегруженные функции разберутся что делать

267. *Antonov Andy (andy.antonov@gmail.com) 2021/03/13 23:44 [ответить]
  > > 263.Поляков Дмитрий
  >> > 262.Габдрафиков Руслан Рамилевич
  >>Которая имеет размер.
  >не имеет
  >в той же utf8 символ может занимать от одного до бесконечности байт
  Гм, разве бесконечности? Вроде, там 8 байт в пределе. Или я неправильно понял описание стандарта.
  >хотя до появления эмодзи почти всегда укладывались до 3х байт на символ
  Почти≠всегда! Укладывались только при использовании европейских языков...

266. Габдрафиков Руслан Рамилевич (the28awg@gmail.com) 2021/03/13 23:40 [ответить]
  > > 264.Antonov Andy
  >> > 260.Габдрафиков Руслан Рамилевич
  Я согласен на оба варианта. Чтобы и int и int8 могли существовать. Один для экономных, другой для индусов. =)

265. Поляков Дмитрий 2021/03/13 23:40 [ответить]
  > > 264.Antonov Andy
  у человека и так люди с конями смешались
  имхо хватит добавлять обьяснения больше запутывая
  в предыдущем тексте и так все предельно ясно

264. *Antonov Andy (andy.antonov@gmail.com) 2021/03/13 23:37 [ответить]
  > > 260.Габдрафиков Руслан Рамилевич
  >Ну, такое извращение тоже имеет право быть. Но я думаю что делать размерность у int и не делать ее у String считаю лицемерием.
  Гм, повторюсь: в предлагаемой модели у int вообще нет разрядности. Это такой же контейнер, определяемый содержимым, как и String. И в нормальных языках это даже реализовано. Но поскольку нормальные языки и машины даже АИ 60-х бесконечно далеки друг от друга (опущу вполне себе РИ "Мир" как вещь в себе), предлагается в спецификации языка явно указывать разрядность типов данных. Таким образом int8 всегда будет иметь размерность 1 байт, в отличии от РИ аналога int, который имеет разрядность, определяемую целевой платформой (в большинстве случаев 8, 16, 32 или 64 бит).

263. Поляков Дмитрий 2021/03/13 23:35 [ответить]
  > > 262.Габдрафиков Руслан Рамилевич
  >Которая имеет размер.
  не имеет
  в той же utf8 символ может занимать от одного до бесконечности байт
  хотя до появления эмодзи почти всегда укладывались до 3х байт на символ
  вот та же mysql сэкономила на спичках и приняла размер в 3 байта и теперь если не сменить кодировку базы падает нафиr если в тексте есть эмодзи

262. Габдрафиков Руслан Рамилевич (the28awg@gmail.com) 2021/03/13 23:32 [ответить]
> > 261.Поляков Дмитрий
Ладно, это все вкусовщина. Оба варианта имеют право быть.

261. Поляков Дмитрий 2021/03/13 23:27 [ответить]
  > > 260.Габдрафиков Руслан Рамилевич
  >Ну, такое извращение тоже имеет право быть. Но я думаю что делать размерность у int и не делать ее у String считаю лицемерием.
  у строки вместо размерности кодировка ибо единая размерность есть далеко не в каждой кодировке

260. Габдрафиков Руслан Рамилевич (the28awg@gmail.com) 2021/03/13 23:23 [ответить]
Ну, такое извращение тоже имеет право быть. Но я думаю что делать размерность у int и не делать ее у String считаю лицемерием.

259. Поляков Дмитрий 2021/03/13 23:25 [ответить]
  > > 258.Габдрафиков Руслан Рамилевич
  Да не будет типа int
  вообще не будет
  будут только варианты с указанной разрядностью
  всякие переполнения будут вызывать исключения ибо нефиг
  и уже в обработчике исключения если возникнет такая необходимость можно будет при необходимости привести к большей размерности или тупо завершить программу
  >Я имел в виду? О чем вы? Я что то пропустил?
  >>если делать платформонезависимый int то под него будет выделяться столько памяти сколько символов в числе
  вот это вот когда число хранится в строке называется длинной арифметикой https://ru.wikipedia.org/wiki/Длинная_арифметика
  >Кто грозился подсчитать все зерна?
  и где вы видите противоречие?
  максимальное значение int64 по моим прикидкам значительно больше чем количество зерен в урожае всего ссср
  > Ну и так далее.
  сразу выделили столько сколько нужно и не паримся
  нужно чтобы гарантировано влезало 8 байт(они же int64) используем 8 байт

258. Габдрафиков Руслан Рамилевич (the28awg@gmail.com) 2021/03/13 23:15 [ответить]
  > > 256.Поляков Дмитрий
  >> > 255.Габдрафиков Руслан Рамилевич
  >использовать же длинную арифметику которую вы скорее всего имели ввиду часто неразумно с точки зрения как быстродействия так и затрат памяти
  Я имел в виду? О чем вы? Я что то пропустил? Кто грозился подсчитать все зерна?
  На самом деле просто внутри типа int будет несколько оптимизаций под разную размерность.
  1+1=байт+байт=байт
  300+1=2 байта+байт=2 байта
  Ну и так далее.

257. *Antonov Andy (andy.antonov@gmail.com) 2021/03/13 23:12 [ответить]
  > > 255.Габдрафиков Руслан Рамилевич
  >> > 252.Поляков Дмитрий
  >>> > 251.Габдрафиков Руслан Рамилевич

  >Просто универсальный тип подразумевает что от платформы int может стать как 32 так и 64.
  Ни фига. Универсальный тип определяется не платформой, а содержимым!

  >А если делать платформонезависимый int то под него будет выделяться столько памяти сколько символов в числе. Как с типом string в котором мы храним кодировку так и в типе int мы можем хранить размерность.
  Верно. Но это значит,что int≠int8 на 6502 и ≠int16 - на 8086. Это именно платформо-независимый тип произвольной рязрядности. Как в Ruby, ога. Сравните это с РИ Сями!

256. Поляков Дмитрий 2021/03/13 23:07 [ответить]
  > > 255.Габдрафиков Руслан Рамилевич
  >А если делать платформонезависимый int то под него будет выделяться столько памяти сколько символов в числе.
  сколько будет выделяться памяти на самом деле не имеет значения(платформа может банально не поддерживать аппаратно необходимую размерность)
  важно только то что компилятор зная размерность(хранящуюся непосредственно в названии типа) обеспечит абсолютно одинаковый результат независимо от возможностей платформы при необходимости используя эмуляцию
  использовать же длинную арифметику которую вы скорее всего имели ввиду часто неразумно с точки зрения как быстродействия так и затрат памяти

255. Габдрафиков Руслан Рамилевич (the28awg@gmail.com) 2021/03/13 22:58 [ответить]
  > > 252.Поляков Дмитрий
  >> > 251.Габдрафиков Руслан Рамилевич
  >зы как вы перескочили от размерности чара к отсутствию необходимости в int64 я так и не понял
  Просто универсальный тип подразумевает что от платформы int может стать как 32 так и 64.
  А если делать платформонезависимый int то под него будет выделяться столько памяти сколько символов в числе. Как с типом string в котором мы храним кодировку так и в типе int мы можем хранить размерность.

254. Габдрафиков Руслан Рамилевич (the28awg@gmail.com) 2021/03/13 22:55 [ответить]
  > > 252.Поляков Дмитрий
  >> > 251.Габдрафиков Руслан Рамилевич
  Меня устраивает хранение кодировки внутри строки. Я за. Можно и длину строки хранить соответственно.
  Просто работа с символами тоже очень важна. В разных языках о символах думают на очень последнем этапе проектирования языка.

253. *Antonov Andy (andy.antonov@gmail.com) 2021/03/13 22:59 [ответить]
  > > 249.Поляков Дмитрий
  >> > 246.Antonov Andy
  >это ограничение давно неактуально

  Расскажите это швитой винде. Которая, с одной стороны, даёт создавать пути абсолютно любой длины (лишь бы локально не было более 255 символов), с другой - при работе с дисками, оные пути имеющие, вылезают такие грабли, что проще вызвать format disk: , чем с ними мудохаться. Потому что такое файлО даже тупо удалить - и то проблемно!

  >но хитромудрые экономители на спичках понаставили ограничений непосредственно в коде своих программ(в туже копилку программы требующие пути без пробелов, без русских символов, обязательно в определенной папке куда давно запрещена запись итд итп)
  Я ещё помню отдельно украинскую букву "і", ога. Ограничение SMB1. И да, до сих пор заменяю все пробелы на "_". На фиг, ибо не фиг.
  ЗЫ Экономителей спичек - давить!
  ЗЗЫ То Вы ещё не сталкивались с азиатским, в частности - японским софтом. Просто поставить поддержку иероглифов в системе - мало. Надо всю локаль сделать под иппонский езыг, включая язык по умолчанию в профиле админа. И то не факт, что поможет.

252. Поляков Дмитрий 2021/03/13 22:53 [ответить]
  > > 251.Габдрафиков Руслан Рамилевич
  ни то ни другое))
  тем более длина того самого чара нифига не константа даже в пределах одной кодировки
  даже в ansi
  Нужно хранить кодировку как и длину в самой строке
  вариант с приведением к единой кодировке был бы конечно куда красивее но невзлетит за отсутствием единой кодировки в природе да и по ресурсам слишком напряжен для древних компов

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

251. Габдрафиков Руслан Рамилевич (the28awg@gmail.com) 2021/03/13 22:44 [ответить]
  > > 246.Antonov Andy
  >> > 245.Поляков Дмитрий
  >>> > 242.Талипов Артём
  По поводу размерности.
  Тут есть тонкий нюанс выделения памяти под разные кодировки в строковых типах. Хорошо иметь один универсальный тип под строки. Потому что строки не числа. Строки состоят из символов (char) а те в свою очередь из байт или бит.
  И тут есть два варианта решения этой проблемы.
  Первый - создать тип StringN где N размерность типа char внутри реализации строкового типа.
  Второй - забить создав один String который в будущем будет допилен когда подвезут больше разных кодировок.

  Если выбираем второй вариант то нам и int8 и uint64 нафиг не нужен. А если первый то старые программы не потянут новые кодировки без изменения кода проекта.

250. *Antonov Andy (andy.antonov@gmail.com) 2021/03/13 22:42 [ответить]
  > > 247.Симонов Сергей
  >> > 241.Талипов Артём

  >Согласен. Но на такой случай придуманы "недокументированные функции". Кстати, вполне возможно иметь версии языка - базовую и профессиональную / advanced.
  Прижигать калёным железом. И "недокументированные функции", и всякие /advanced версии языка.
  Язык - стандартен! Точка. Абзац.

249. Поляков Дмитрий 2021/03/13 22:40 [ответить]
  > > 246.Antonov Andy
  это ограничение давно неактуально
  но хитромудрые экономители на спичках понаставили ограничений непосредственно в коде своих программ(в туже копилку программы требующие пути без пробелов, без русских символов, обязательно в определенной папке куда давно запрещена запись итд итп)

248. Поляков Дмитрий 2021/03/13 22:23 [ответить]
  > > 247.Симонов Сергей
  >>Это утилиты для генерации лексического и синтаксического анализаторов.
  >Я с ними не знаком, но раз они есть, то можно их упомянуть.
  нужно только учитывать что эти анализаторы и на треть компилятора не тянут в нем еще куча другого кода должна быть

247. *Симонов Сергей (gann.lector@yandex.ru) 2021/03/13 22:03 [ответить]
  > > 241.Талипов Артём
  >>
   >Разошёлся. Гым, Лебедев, Келдыш и Серов соображают на троих.

  Вот такого, полагаю, в реальности быть не могло. :-)
  >

  >
   >В самом наличии действительно ничего секретного нет. Но между строк можно многое прочесть.
   >К примеру если в языке есть встроенные функции для музыки или для трёхмерной графики, то это уже намекает, что язык и компьютер это поддерживают.

  Согласен. Но на такой случай придуманы "недокументированные функции". Кстати, вполне возможно иметь версии языка - базовую и профессиональную / advanced.


  >

  >
   >Есть системы flex и bison. Ну или их альтернативы. Вообще-то стандартные утилитки в linux. Они, конечно старые, но многие продолжают пользоваться. Это утилиты для генерации лексического и синтаксического анализаторов.

  Я с ними не знаком, но раз они есть, то можно их упомянуть.
  >

  >
   >Господа Бэкус и Наур, кстати, участвовали в разработке стандарта algol. И вроде бы algol-60 был первым языком, описанной БНФ (формула Бэкуса Наура).
  >
   >Но вот какой-то универсальной формулы, пытались, но созданть не смогли. А америке, на это, кстати, угробили много сил.

  Я представляю себе это, скорее, как список свойств в формате "ключ: значение", либо вообще как базу данных, содержащую в полях всю информацию.
  >

  >
   >Из здешней переписки уже сильно поменялось изначальная задумка.

  И это тоже нормально.
  >

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

  Так то в реале, а что у нас будет - увидим.

  >243. Габдрафиков Руслан Рамилевич

  Так напишите свои соображения.

246. *Antonov Andy (andy.antonov@gmail.com) 2021/03/13 22:36 [ответить]
  > > 245.Поляков Дмитрий
  >> > 242.Талипов Артём
  >Изначально указывать размерность в названии типа int8 uint8 итд
  >Больше стандартизации богу стандартизации))
  Всеми лапами за!...
  ЗЫ С нультерминированными строками ты знатно подгадил всем пейсателям на Си, особливо из Редмонда. Напомню, что полная длина пути файла в венде не может превышать 255 символов, ога. При этом создать такой путь (и файлО в нём) - как два байта переслать!
  ЗЗЫ Я не прикалываюсь: такие пути дейссно можно создать. И юзверги их реально создают. Просто потому, что им по сараю на длину имён. Ни о каких ограничениях они не знают, и знать не желают! (Особливо при сохранении из инета, когда брозверь радостно подставит в имя файла тайтл из 2^32 символов.) Но потом использовать это - БОЛЬ!

245. Поляков Дмитрий 2021/03/13 21:51 [ответить]
  > > 242.Талипов Артём

  >Можно создать. А можно и не создать.
  Ну как минимум прибить сразу предлагающих платформозависимые типы переменных можно
  Все эти Инты Лонги и прочую ересь
  Изначально указывать размерность в названии типа int8 uint8 итд
  Нультерминированные строки и массивы туда же
  Подобных "мелочей" вполне хватит чтобы избавить от кучи геморроя в будущем
  Больше стандартизации богу стандартизации))

244. Поляков Дмитрий 2021/03/13 21:44 [ответить]
Влияет довольно слабо
Примерно на уровне фанфика ридера

243. Габдрафиков Руслан Рамилевич (the28awg@gmail.com) 2021/03/13 21:36 [ответить]
Эта дискуссия как то влияет на содержание книги? Меня беспокоит то что техническое задание формулирует Артем. И если это просто его хотелки то я не буду влезать. А иначе у меня тоже есть что сказать.

242. *Талипов Артём (eric50@yandex.ru) 2021/03/13 21:22 [ответить]
  > > 239.Поляков Дмитрий
  >Мне в принципе Паскаль направится куда больше чем си но объективности ради должен сказать что они оба плохи если рассматривать их с точки зрения истории развития программирования.

  Все плохие. Ничего годного нет.

  > Используя накопленный опыт можно сразу создать куда лучший язык.


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

  >Зы действительно важная разница между языками не в синтаксисе а в библиотеке стандартных функций и в этом си и Паскаль отличаются кардинально вплоть до разных способов передачи параметров функций.

  Передачу параметров функций, можно сломать и наплевать. Это как раз не особо критично.
  Я считаю, что стек должен освобождать тот, кто его заполнил.
  "родитель обязан убить своего ребёнка"

  А вот различие типов, как раз более критично. Что-то можно унифицировать без всяких проблем, вроде чисел. А со строками и массивами будет ой.

241. *Талипов Артём (eric50@yandex.ru) 2021/03/13 21:14 [ответить]
  > > 238.Симонов Сергей
  >Ага, оно всегда так. :-)

  Разошёлся. Гым, Лебедев, Келдыш и Серов соображают на троих.

  >Алгол и Фортран тоже языки высокого уровня. ИМХО, в самом наличии нескольких языков высокого уровня нет ничего секретного

  В самом наличии действительно ничего секретного нет. Но между строк можно многое прочесть.
  К примеру если в языке есть встроенные функции для музыки или для трёхмерной графики, то это уже намекает, что язык и компьютер это поддерживают.
  А если будет где-нибудь инструкция, вроде "ткните мышкой в пункт... перетащите объект на форму... отредактируйте свойства объекта..."
  Это я уже из более современного, чисто для наглядности, но по всяким таким оговоркам, можно многое узнать о техническом уровне.

  >Возможно, АЛМО следует превратить в некое подобие системы, выдающей автоматически генерируемые компиляторы.

  Есть системы flex и bison. Ну или их альтернативы. Вообще-то стандартные утилитки в linux. Они, конечно старые, но многие продолжают пользоваться. Это утилиты для генерации лексического и синтаксического анализаторов.

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

  Господа Бэкус и Наур, кстати, участвовали в разработке стандарта algol. И вроде бы algol-60 был первым языком, описанной БНФ (формула Бэкуса Наура).

  Но вот какой-то универсальной формулы, пытались, но созданть не смогли. А америке, на это, кстати, угробили много сил.

  >Теперь понятно, что вы имели в виду.
  >Обсудим подробнее в почте, когда меня домой выпишут.

  Из здешней переписки уже сильно поменялось изначальная задумка.

  >Условно, Алголом в СССР может заниматься одна группа, созданная "для совместимости с внешним миром"
  >А для внутреннего применения и союзников использовать что-то другое, тот же Паскаль.

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

240. *Antonov Andy (andy.antonov@gmail.com) 2021/03/13 21:49 [ответить]
  Раз уж речь зашла о Паскале...
  https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D0%B5%D1%80%D0%BE%D0%BD_(%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)
  Оберон. Синтаксически проще Паскаля. Точно так же строгая типизация. Но появился garbage grabber.
  Ну, и его наследники:
  https://ru.wikipedia.org/wiki/Active_Oberon
  https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D0%B5%D1%80%D0%BE%D0%BD-2
  https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%BD%D1%8B%D0%B9_%D0%9F%D0%B0%D1%81%D0%BA%D0%B0%D0%BB%D1%8C
  https://ru.wikipedia.org/wiki/Go
  Причём, по времени, всё это может быть в посылке.

239. Поляков Дмитрий 2021/03/13 19:58 [ответить]
  > > 238.Симонов Сергей

  >Возможно, АЛМО следует превратить в некое подобие системы, выдающей автоматически генерируемые компиляторы.

  Это не ересь но в реальности появилось значительно позже, лет на 40 если склероз не изменяет

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

  Зы действительно важная разница между языками не в синтаксисе а в библиотеке стандартных функций и в этом си и Паскаль отличаются кардинально вплоть до разных способов передачи параметров функций.

238. *Симонов Сергей (gann.lector@yandex.ru) 2021/03/13 19:43 [ответить]
  > > 237.Талипов Артём

  >
   >Да я как бы в теме написания текстов. Но тут идёт уж совсем медленно. Добавил ещё лишь 4 абзаца. Зато перечитал десяток статей.

  Ага, оно всегда так. :-)
  >

  >
   >Может быть. Но я реально не знаю, насколько algol похож на pascal.

  Чисто внешне, для программиста-любителя, большинство функциональных языков различаются разве что операторами вывода, оформлением циклов и массивов да типизацией переменных. Это очень грубо и упрощённо, конечно, а что там "под капотом", пользователь не задумывается, да и не должен.
  >

   >Эм. Ну, в книжные магазины, врят ли попали учебники языков высокого уровня. Там могло оказаться, что-то для тогдашних советских машин. Да и то, такой учебник ррассекретит уровень развития советских компьютеров. Самое большее, это учебники для приставок и сетуней. А остальное, как минимум, для служебного пользования.

  Алгол и Фортран тоже языки высокого уровня. ИМХО, в самом наличии нескольких языков высокого уровня нет ничего секретного
  >
   >К тому же заседание первое по algol было в 1958 году. Увы, по времени не стыкуется.

  Вот. Это более существенно
  >
   >Кстати, попалось, что представители СССР были на собрании algol 1968.

  Тоже читал об этом
  >

   >Ха-ха! Но машин слишком много и под каждую придётся писать. Тут уж точно без системы АЛМО вообще никак не вытянуть.

  Возможно, АЛМО следует превратить в некое подобие системы, выдающей автоматически генерируемые компиляторы.

  Т.е. мы забираем в качестве исходных данных формально описанную архитектуру целевой машины, и система генерит компилятор под неё.
  Если это ересь - поправьте сразу.
  Дополнение

  Таки влез в почту и прочитал письмо.
  Теперь понятно, что вы имели в виду.
  Обсудим подробнее в почте, когда меня домой выпишут.
  >
  >>
   >Это только моё предположение. Надо перепроверять. Или же сделать algol на всякий случай, ради совместимости. шоб было. Просто не концентрироваться на нём.
   >В реале очень много сил угробили, пытаясь реализовать тот бред, который напридумывали. Причём наши сделали даже больше, расширив и дополнив язык.
   >Вот эти бы силы, да на что-то более полезное. Эх, ладно, кто же знал.

  Условно, Алголом в СССР может заниматься одна группа, созданная "для совместимости с внешним миром"
  А для внутреннего применения и союзников использовать что-то другое, тот же Паскаль.

237. *Талипов Артём (eric50@yandex.ru) 2021/03/13 17:55 [ответить]
  > > 236.Симонов Сергей
  >Никто не обещал что будет легко :-)

  Да я как бы в теме написания текстов. Но тут идёт уж совсем медленно. Добавил ещё лишь 4 абзаца. Зато перечитал десяток статей.

  >Тогда возможно и прокатит

  Может быть. Но я реально не знаю, насколько algol похож на pascal.

  >Конечно, кто-то из иностранцев мог просто купить учебник. Более того, нам это даже будет выгодно - распространение правильной идеи.

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

  К тому же заседание первое по algol было в 1958 году. Увы, по времени не стыкуется.

  Кстати, попалось, что представители СССР были на собрании algol 1968.

  >ИМХО, надо тупо сделать центр распространения, бесплатно, с оплатой только пересылки, и распространять языки под GPL, подсаживал весь мир на "наше, правильное"

  Ха-ха! Но машин слишком много и под каждую придётся писать. Тут уж точно без системы АЛМО вообще никак не вытянуть.

  >Так это хорошо. Годный вариант

  Это только моё предположение. Надо перепроверять. Или же сделать algol на всякий случай, ради совместимости. шоб было. Просто не концентрироваться на нём.
  В реале очень много сил угробили, пытаясь реализовать тот бред, который напридумывали. Причём наши сделали даже больше, расширив и дополнив язык.
  Вот эти бы силы, да на что-то более полезное. Эх, ладно, кто же знал.

236. *Симонов Сергей (gann.lector@yandex.ru) 2021/03/13 17:04 [ответить]
  > > 235.Талипов Артём
  >> >
   >Успел переделать один абзац, оставив только первое ваше предложение. Затем осторожно копипастил фразы из википедии с адоптацией, так уже семь потов сошло.
   >Понятно, что потом согласования будут, но я жестоко всё ломаю.

  Никто не обещал что будет легко :-)
  >

  >
   >Конечно, pascal это не algol. Но Никлаус Вирт, сделал его по мотивам algol-68, в попытке исправить косяки. Так что это очень похожие языки, близкие и почти заменяемые.

  Тогда возможно и прокатит
  >

  >
   >Что-то могло просочиться. Особенно идеи. То же структурное программирование это великое откровение.

  Конечно, кто-то из иностранцев мог просто купить учебник. Более того, нам это даже будет выгодно - распространение правильной идеи.
  >

  >

  >А на счёт ввода/вывода, там не "сложно", а "разнообразно".

  Примеры более чем понятные, спасибо.
  >
   >Команды были не стандартизированы. И каждый фигачил что мог и как мог. Но следует помнить, что и компьютеры тоже были своеобразными.

  Да, учитывая, что даже разрядности единой в реале не было
  >

  >
   >В этом свете, даже если не получится договориться с комитетом по стандартизации, можно самим разработать и распространить pascal и пусть разработчики algol кусают свои локти.

  ИМХО, надо тупо сделать центр распространения, бесплатно, с оплатой только пересылки, и распространять языки под GPL, подсаживал весь мир на "наше, правильное"
  >
  >
   >Из международных последствий... Вот даже не знаю. Язык algol долго (до 1980) использовался в качестве описаний алгоритмов при публикации в литературе. Но тут его прекрасно заменит pascal. И очень может быть, что подмены даже не заметят!

  Так это хорошо. Годный вариант
  >

  >
   >Да там ничего такого сложного не предполагалось. Разве только организационные перестановки.

  ОК

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

  Да, так будет более реалистично

235. *Талипов Артём (eric50@yandex.ru) 2021/03/13 15:21 [ответить]
  > > 234.Симонов Сергей
  >Жду, не спешите

  Хе-хе. *нервно*
  Успел переделать один абзац, оставив только первое ваше предложение. Затем осторожно копипастил фразы из википедии с адоптацией, так уже семь потов сошло.
  Понятно, что потом согласования будут, но я жестоко всё ломаю.

  >Так-то да, но надо учитывать распространенный синдром "not invented here". Разработчики Алгола едва ли легко согласятся от него отказаться.

  Конечно, pascal это не algol. Но Никлаус Вирт, сделал его по мотивам algol-68, в попытке исправить косяки. Так что это очень похожие языки, близкие и почти заменяемые.

  >Внутри Союза - безусловно. Там уже вовсю должны писать на Focal, Forth, Python и Unix shell, на Паскале и Си, как минимум. Но за рубежом об этом мало кто может знать, если только в соцстранах.

  Что-то могло просочиться. Особенно идеи. То же структурное программирование это великое откровение.

  >Вполне вероятно. Алгол не знаю, в институте давали Fortran, и там ввод/форматированный вывод тоже с непривычки выглядел сложно

  Я алгол тоже не знаю, вынужден уточнять по справочникам.
  А на счёт ввода/вывода, там не "сложно", а "разнообразно".
  К примеру на одном компьютере для вывода сообщения надо написать команду:
  print( "Hello-" )
  На втором компьютере:
  output( "Hello-" )
  А на третьем:
  echo( "Hello-" )

  Команды были не стандартизированы. И каждый фигачил что мог и как мог. Но следует помнить, что и компьютеры тоже были своеобразными.

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

  В этом свете, даже если не получится договориться с комитетом по стандартизации, можно самим разработать и распространить pascal и пусть разработчики algol кусают свои локти.

  >Согласен. Тут, скорее, надо на международных последствиях сосредоточиться.

  Из международных последствий... Вот даже не знаю. Язык algol долго (до 1980) использовался в качестве описаний алгоритмов при публикации в литературе. Но тут его прекрасно заменит pascal. И очень может быть, что подмены даже не заметят!

  > Сразу предупреждаю - я не писал ничего на Паскале или Си, для меня это > Возможно, что-то придется мне разжёвывать

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

234. *Симонов Сергей (gann.lector@yandex.ru) 2021/03/13 14:49 [ответить]
  > > 233.Талипов Артём

  >
   >Вас понял. Тогда начинаю.

  Жду, не спешите
  >
   >>М-м-м... Cobol с 1959г широко используется в банковских программах на Западе. ..
  >
   >Вот, в том числе из-за таких моментов я и опасался ломать Это же надо согласовывать.

  Само собой. Ваш исходный текст, скорее всего, пройдет несколько итераций согласования. Это нормально. Это не значит, что вы написали плохо, или мне не понравилось - это всего лишь технические моменты согласования деталей.
  Авторов фанфиков иногда приходится убеждать, что их вариант решения - не лучший. Кто-то соглашается, кто-то нет. Нормальный процесс.
  >

  >
   >Переходить с одного языка на другой, с того же алгола, всё равно придётся, рано или поздно. И лучше сделать это раньше. А силы, потраченные на разработку алгола, лучше потратить на разработку чего-то иного.

  Так-то да, но надо учитывать распространенный синдром "not invented here". Разработчики Алгола едва ли легко согласятся от него отказаться.

   >А ещё, у вас в самом начале, когда Лебедев подключил машину из будущего. и предоставил к ней доступ, были разосланы учебники по языкам программирования.
   >Так что эти языки программирования из будущего, наверняка изменили историю. Местные уже знают, что и как можно. И вместо долгих штурмов, будут вылизывать уже имеющееся.

  Внутри Союза - безусловно. Там уже вовсю должны писать на Focal, Forth, Python и Unix shell, на Паскале и Си, как минимум. Но за рубежом об этом мало кто может знать, если только в соцстранах.
  >

  >
   >Хорошо. Попробую уделить этому внимание. Есть мысли.

  Отлично.
  >
   >У алгола есть несколько косяков. Самый эпичный это ввод/вывод из-за чего, программы созданные для разных машин, оказывались несовместимыми.

  Вполне вероятно. Алгол не знаю, в институте давали Fortran, и там ввод/форматированный вывод тоже с непривычки выглядел сложно, тем более, в интерактивном режиме мы с компами тогда не работали, бегали на ВЦ с перфокартами. Результат обучения был нулевой
  >
   >Передача параметра по имени это какая-то дикость, которую трудно реализовать. Пусть сразу передают по ссылке и не пытаются родить ежа иголками вперёд.

  Тут вам виднее, полагаюсь на ваш опыт
  >
   >Американцы много скандалили на счёт десятичной точки, продавили дикие формулировки в стандарте, а в итоге сами алголом почти не пользовались. Так что на пиндосов можно наплевать.
  >
   >Вообще, можно бы попробовать в 1958 году влезть на конференцию в Цурихе и втюхать им уже готовый pascal.

  Это будет логично, в свете вышеизложенного (десятичной точки, стандартов)
  Разработчики Алгола, конечно, будут обижаться, но только пользователи решают, на чём кодить.
  >
   >Так-то американцы без алгола жили, в СССР тоже ничего страшного не случится.

  Согласен. Тут, скорее, надо на международных последствиях сосредоточиться.

  Сразу предупреждаю - я не писал ничего на Паскале или Си, для меня это тёмный лес. Возможно, что-то придется мне разжёвывать.
   Есть опыт кодинга на разных вариантах Basic (Zx-Basic, Qbasic, Corel Visual Basic 6 - кстати, очень мне понравилось на нём писать.), Также писал на Forth, Python, Unix-shell.

  Есть некоторый опыт блочного программирования - HiAsm и Unreal Engine 4 Blueprint.

233. *Талипов Артём (eric50@yandex.ru) 2021/03/13 14:22 [ответить]
  > > 232.Симонов Сергей
  >Всё, что помогает установить истину - годно.
  >Если будет время и возможность - напишите свой вариант мне в почту, буду признателен.

  Вас понял. Тогда начинаю.

  >М-м-м... Cobol с 1959г широко используется в банковских программах на Западе. Едва ли его получится так лихо отменить.

  Вот, в том числе из-за таких моментов я и опасался ломать Это же надо согласовывать.

  >Алгол можно теоретически заменить Паскалем. Но опять же, это язык международный, созданный на Западе. Мы можем предложить вместо него Паскаль в нашей реализации. Но у многих уже есть собственные программы на Алголе. Согласятся ли они от них отказаться?

  Переходить с одного языка на другой, с того же алгола, всё равно придётся, рано или поздно. И лучше сделать это раньше. А силы, потраченные на разработку алгола, лучше потратить на разработку чего-то иного. Это же ведь по сути разработка заведомо устаревшего языка. Строить угольный пароход в эпоху ядерных двигателей.
  А ещё, у вас в самом начале, когда Лебедев подключил машину из будущего. и предоставил к ней доступ, были разосланы учебники по языкам программирования.
  Так что эти языки программирования из будущего, наверняка изменили историю. Местные уже знают, что и как можно. И вместо долгих штурмов, будут вылизывать уже имеющееся.

  >Надо ведь так аргументировать в тексте, чтобы для читателей это выглядело убедительно

  Хорошо. Попробую уделить этому внимание. Есть мысли.

  У алгола есть несколько косяков. Самый эпичный это ввод/вывод из-за чего, программы созданные для разных машин, оказывались несовместимыми.

  Передача параметра по имени это какая-то дикость, которую трудно реализовать. Пусть сразу передают по ссылке и не пытаются родить ежа иголками вперёд.

  Американцы много скандалили на счёт десятичной точки, продавили дикие формулировки в стандарте, а в итоге сами алголом почти не пользовались. Так что на пиндосов можно наплевать.

  Вообще, можно бы попробовать в 1958 году влезть на конференцию в Цурихе и втюхать им уже готовый pascal.

  Так-то американцы без алгола жили, в СССР тоже ничего страшного не случится.

232. *Симонов Сергей (gann.lector@yandex.ru) 2021/03/13 13:54 [ответить]
  > > 231.Талипов Артём
  >> > 230.Симонов Сергей

  >
   >В идеале, там надо бы переписать несколько абзацев. И ещё сколько-то добавить новых. Я, собственно, так и хотел сделать. Но засомневался в корректности линии партии.

  Всё, что помогает установить истину - годно.
  Если будет время и возможность - напишите свой вариант мне в почту, буду признателен.
  Возможно, что-то подправлю стилистически, но не более.

   >Ещё, есть мысль, возможно еретическая... А что если вообще отказаться от языков программирования algol и cobol? Вместо них зафигачить какой-нибудь pascal? С тем же cobol сейчас проблемы, поскольку новых версий нет, программистов нет, а программы есть и с ними ничего не поделать.

  М-м-м... Cobol с 1959г широко используется в банковских программах на Западе. Едва ли его получится так лихо отменить. Тем более, у нас упоминался Сингапур как центр перехвата банковских транзакций
  Алгол можно теоретически заменить Паскалем. Но опять же, это язык международный, созданный на Западе. Мы можем предложить вместо него Паскаль в нашей реализации. Но у многих уже есть собственные программы на Алголе. Согласятся ли они от них отказаться?
  Надо ведь так аргументировать в тексте, чтобы для читателей это выглядело убедительно

Страниц (10): 1 2 3 4 5 6 7 8 9 10 Архивы (1): 1

Связаться с программистом сайта.

Новые книги авторов СИ, вышедшие из печати:
О.Болдырева "Крадуш. Чужие души" М.Николаев "Вторжение на Землю"

Как попасть в этoт список

Кожевенное мастерство | Сайт "Художники" | Доска об'явлений "Книги"

Симонов Сергей : другие произведения.

Комментарии: Программирование ()

Комментарии: Программирование
()