Ещё в школьные годы я разработал программный продукт, одной из фич которого было наличие встроенного ЯП и IDE (у меня он назывался XCode); это не было центральной фишкой той софтины, но это был как приятный бонус, как VBA в Excel — обычно вам должно хватить штатных возможностей Excel, но если вдруг не хватает, вы можете написать что-то нестандартное. За эту работу была получена золотая медаль Intel ISEF.
VBX и OCX писать в одном месте вот так через запятую — это 5.
Это как сравнивать прерывания BIOS/DOS и WinAPI. VBX это устаревшая и узкопециализированная вещь. OCX — гениальная и крутая. Писать OCX на VB не неудобно и не сложно. Если вы собрались писать OCX на Си, это другой разговор, но в таком случае и реализовать дотнетовский элемент управления на Си будет ещё на пару порядков сложнее.
Думаю, что всё-таки внутри Microsoft всегда была предвзятость к VB как к побочному продукту существования VBA. Если смотреть на это через призму такого подхода, то для Microsoft продукт не умер, не прекратил развитие в 1998 — он продолжил развитие в виде всё новых и новых версий VBA. Просто к нему больше не прикручивали куперовский Ruby для получения побочного продукту/ответвления. А нишу этого ответвления решили закрыть дотнетом — Microsoft всегда хотела сделать свою Джаву, и вот наконец после Microsoft J++ получилась более удачная попытка.
В общем, на 85% это маркетинг, на 15% — технические сложности.
Ничего хорошо (если рассматривать его как альтернативу или замену VB). Если просто рассматривать к какой-то ещё один бейсик — ради бога, больше бейсиков богу бейсиков.
Как бы 3 этапа - разбор исходного текста - генерация промежуточного кода (p-code) - исполнение.
Это теоретизированный подход в духе «Как заработать миллиарды?»:
Придумать хитрый план
Начать работать по нему
???
Заработать миллиарды.
В случае VB/VBA промежуточных этапов и форм представления кода сильно больше, чем 3. Другой интересный факт состоит в том, что машинный код x86, когда он генерируется, не генерируется и P-кода, который при этом генерируется для работы проекта в режиме отладки (человек не произошёл от обезьяны, а человек и обезьяна происходят от общего предка)
Я не понимаю, с чем вы вспорите? Если вы предлагаете рассмотреть гипотетический вариант, где исполняемый файл содержит в себе прикладной код программы, представляемый в виде 4-битных элементов, полученных путём предварительной обработки исходного кода в момент компиляции, а также исполняющий системы, которая бежит по этой цепочке 4-битных элементов, то это не по адресу, потому что я не про такой подход говорил, что он дорогой до ресурсов. Нет смысла оспаривать то, чего я не говорил.
Я говорил, что что интерпрератор, который в момент выполнения прикладной программы будет интерпретировать исходный код прикладной программы с нуля, с сырого человеко-читаемого представления — вот он будет и медленный, и объямный по памяти.
Опять, когда вы говорите про 4-бита, про 8/12 на функцию — вы говорите о компактности представления пользовательского кода, а я говорю о [не-]компактности machinery, которая всё это делает.
С какой стати 3-й вариант медленный и унылый? Пруфы? Доводы?
Первая версия VB вышла в 1991, генерация появилась в 1997, последняя версия вышла в 1998. Он не так долго успел побыть зрелым инструментом разработки, чтобы это вошло в историю.
Я что-то не понял: когда в 1998 вышла последняя версия, возможность компилировать в Native-код убрали? Да? Нет. В 1998 ничего не изменилось. Поэтому на временной шкале если и отмечать точки переломных моментов, то 1998 год как точка явно вообще не должен был отмечен.
EXE собирал из исполняющей среды и исходников, точнее, не исходников, а байт-кода,
Обычно говорят «точнее», когда хотят уточнить и без того достаточно точное первое утверждение. Например «она была зелёного цвета, точнее фисташкового». Его странно видеть в предложениях типа «он был чёрным, точнее белым» и т.п.
Исходники и байт-код — на двух диаметрально противоположенных концах жизненного цикла программного продукта. Это руда и экскаваторы. Мука и булочки.
Если вы понимаете, что там не исходники, а байт-код, то почему называете это «интерпретируемым языком»? Точно так же работает дотнет, точно так же работает Java. Никто не говорит, что Java интерпретируемая, что C# интерпретируемый, что VB.NET интерпретируемый.
Python, PHP и современный JS тоже генерирует байт-код и выполняют его на своей виртуальной машине. Но они это делают в момент запуска и на конечном устройстве. В случае VB это было делалось один раз, при компиляции и происходило на машине разработчика.
появилась только в VB5, до этого он
Даже если бы до появления VB5 там реально вшивался бы исходный код (что not the case, как мы выяснили, исходный код не вшивался никогда), почему-то никто никогда не делает эту ремарку с указанием версии, хотя, грубо говоря, 10 лет генерации нативного машинного кода не было, после чего 20 лет эта генерация была — то есть она была бОльшую часть времени, но этого факта как будто бы не существует, зато положение дел, которое существовало меньшую часть времени, акцентируется и извращается до непомерных масштабов (готовый оптимизированный байт-код для виртуальной машины выдаётся за исходный код).
Можно убрать это нафиг и больше никогда не возвращать? Или чтобы нужно было принудительно в настройках профиля включать эту кнопку-объяснялку где-нибудь рядом с опциями для слабовидящих и слабослышаших?
Это такая бестактная наглая ложь,что она выдернула меня из постели и заставила написать комментарий.
Не поленитесь скачать QuickBasic, написать какую-нибудь простенькую программу, скомпилировать, а потом посмотреть полученный EXE-файл в hex-редакторе и найдите там исходник.
И что? Они там не просто так, наверное. И всегда существует масса способов оформить внешнее восприятие кода так, чтобы не путаться в скобочках. А если кого-то пара ВНЕШНИХ скобочек огорачает своей избыточностей, то может надо чем-нибудь другим заниматься?
Разве у новых языков это не так?
Плевать, как там хипстеры выделываются. У них design decisions делаются по принципу «лишь бы выпрендриться и отличиться от классики».
Категорически против убирания круглых скобок у условий.
Визуальную нагрузку — вы серьёзно? Дело попахивает СДВГ, если пара лишних скобочек мешает вам работать и адекватно воспринимать код.
К тому же, есть общая логика в том, что все control structure имеет унифицированный синтаксис keyword(...) statementsblock
Если убирать скобочки у if, то тогда по общей логике нужно убирать и у while, for, switch, а это не совместимо с тем, что у for внутри скобочек не просто выражение, а несколько выражений.
К тому же, скобочки у обычного if прекрасно контрастируют с отсутствием скобочек у #if, а устранение скобочек сближает по степени схожести.
Желание убрать скобочки — это когда делать больше нечего, а что-то сделать хочется.
А электро-энцефалограмма что в таком случае пишет при исследовании активности мозга?
Пишет побочный эффект протекания электрохимических процессов в миллиардах клеток (среднюю температуру по больницы).
Пока у нас в компьютерах вольты, на ЭЭГ даже не милливольты, а микровольты. Миллионная доля вольта. Потому что это побочный продукт.
Давайте зайдём в другой стороны: слово «нейромедиаторы» вам о чём нибудь говорит? Глутамат, серотонин, ацетилхолин? Если бы нервная ткань была просто сплетением проводов (но не металлических, а органичвеского происхождения), передающих электрические импульсы, то зачем бы всё это было необходимо?
Нужно очень сильное воздействие, в естественных условиях такой мощности "помех" просто нет.
Как насчёт аппарата МРТ? Как насчёт металлургических предприятий с печами дуговой плавки? Военные радары с киловаттными излучателями? Не в одном из перечисленых случаев люди не испытывают галлюцинации, не сбиваются с мыслей, не теряют сознание и не срываются в эпилептический припадок. От военных радовов воздействие наступало, но в виде поджаривания плоти.
Но, возможна например электро-судорожная терапия, когда мозг "перезагружают" именно электрическим разрядом.
Что если всё дело в том, что протекание электрических токов просто ломает и подавляет внутреннюю химию мозга?
Отвратительный синтаксис; такое впечатление, что создатели новомодных языков соревнуются в том, как бы эффективнее вызвать кровотечение из глаз читающего.
Также при встрече с очередной такой статьей ещё раз проникаешься мыслью, насколько же гениальны были создатели Си, и что лаконичнее уже ничего быть не может.
Все эти fn и двоеточия даром не нужны. Особенно сильно бесят сокращения pub и fn. Это какая жалкая экономия на спичках. Так и представляю себе, как автор языка уделал всех остальных программистов мира в скорости разработки за счет экономии на буквах. Только вот есть один большой просчет. Как же это так, что у нас есть красивый и компактный fn, и при этом остался омерзительный жирный return? Должно быть ret, а ещё лучше просто r. Экономия должна быть экономной. Ну и const нужно сократить до cn.
Спасибо, но я остаюсь на Си, ваш синтаксический сахар меня не усластил.
Естественно, мы люди бедные, мы будем нацеливаться повторить рентген-томограф из фекалий и древисины.
Интересующий моментов, естественно, много. У вас линейные (одномерные) детекторы или матричные (двумерные)? Полностью готовое изделие (детектор) ставите в своё устройство или сами производите?
Рентген-КТ неживых объектов сильно проще, потому что не нужны высокие скорости перемещения, высокие быстродействия опроса детектора, передачи и сохранения информации, не нужно беспокоиться и дозовой нагрузке (в большинстве случаев).
Но всё равно хватает технических сложностей. Охлаждение трубки/источника. Как у вас вопрос решён? И вообще, режим работы — импульсный или непрерывный?
Какую мощность в целом потребляет источник, учитывая, что у них смехотворные КПД?
Сам уже могу писать такие книжки ;-)
Ещё в школьные годы я разработал программный продукт, одной из фич которого было наличие встроенного ЯП и IDE (у меня он назывался XCode); это не было центральной фишкой той софтины, но это был как приятный бонус, как VBA в Excel — обычно вам должно хватить штатных возможностей Excel, но если вдруг не хватает, вы можете написать что-то нестандартное. За эту работу была получена золотая медаль Intel ISEF.
VBX и OCX писать в одном месте вот так через запятую — это 5.
Это как сравнивать прерывания BIOS/DOS и WinAPI. VBX это устаревшая и узкопециализированная вещь. OCX — гениальная и крутая. Писать OCX на VB не неудобно и не сложно. Если вы собрались писать OCX на Си, это другой разговор, но в таком случае и реализовать дотнетовский элемент управления на Си будет ещё на пару порядков сложнее.
Думаю, что всё-таки внутри Microsoft всегда была предвзятость к VB как к побочному продукту существования VBA. Если смотреть на это через призму такого подхода, то для Microsoft продукт не умер, не прекратил развитие в 1998 — он продолжил развитие в виде всё новых и новых версий VBA. Просто к нему больше не прикручивали куперовский Ruby для получения побочного продукту/ответвления. А нишу этого ответвления решили закрыть дотнетом — Microsoft всегда хотела сделать свою Джаву, и вот наконец после Microsoft J++ получилась более удачная попытка.
В общем, на 85% это маркетинг, на 15% — технические сложности.
Ничего хорошо (если рассматривать его как альтернативу или замену VB). Если просто рассматривать к какой-то ещё один бейсик — ради бога, больше бейсиков богу бейсиков.
Это теоретизированный подход в духе «Как заработать миллиарды?»:
Придумать хитрый план
Начать работать по нему
???
Заработать миллиарды.
В случае VB/VBA промежуточных этапов и форм представления кода сильно больше, чем 3. Другой интересный факт состоит в том, что машинный код x86, когда он генерируется, не генерируется и P-кода, который при этом генерируется для работы проекта в режиме отладки (человек не произошёл от обезьяны, а человек и обезьяна происходят от общего предка)
Я не понимаю, с чем вы вспорите? Если вы предлагаете рассмотреть гипотетический вариант, где исполняемый файл содержит в себе прикладной код программы, представляемый в виде 4-битных элементов, полученных путём предварительной обработки исходного кода в момент компиляции, а также исполняющий системы, которая бежит по этой цепочке 4-битных элементов, то это не по адресу, потому что я не про такой подход говорил, что он дорогой до ресурсов. Нет смысла оспаривать то, чего я не говорил.
Я говорил, что что интерпрератор, который в момент выполнения прикладной программы будет интерпретировать исходный код прикладной программы с нуля, с сырого человеко-читаемого представления — вот он будет и медленный, и объямный по памяти.
Опять, когда вы говорите про 4-бита, про 8/12 на функцию — вы говорите о компактности представления пользовательского кода, а я говорю о [не-]компактности machinery, которая всё это делает.
Медленно и уныло — это как раз второй вариант.
С какой стати 3-й вариант медленный и унылый? Пруфы? Доводы?
Я что-то не понял: когда в 1998 вышла последняя версия, возможность компилировать в Native-код убрали? Да? Нет. В 1998 ничего не изменилось. Поэтому на временной шкале если и отмечать точки переломных моментов, то 1998 год как точка явно вообще не должен был отмечен.
QBasic вообще не делал EXE-файлы.
QuickBasic делал, и это были настоящие полноценные полноправные EXE, как показано в статье.
Не жалко занять всю имеющуюся память интерпретатором, если по изначальной задумке это единственное, чем должно быть занято ПЗУ вашего изделия.
Обычно говорят «точнее», когда хотят уточнить и без того достаточно точное первое утверждение. Например «она была зелёного цвета, точнее фисташкового». Его странно видеть в предложениях типа «он был чёрным, точнее белым» и т.п.
Исходники и байт-код — на двух диаметрально противоположенных концах жизненного цикла программного продукта. Это руда и экскаваторы. Мука и булочки.
Если вы понимаете, что там не исходники, а байт-код, то почему называете это «интерпретируемым языком»? Точно так же работает дотнет, точно так же работает Java. Никто не говорит, что Java интерпретируемая, что C# интерпретируемый, что VB.NET интерпретируемый.
Python, PHP и современный JS тоже генерирует байт-код и выполняют его на своей виртуальной машине. Но они это делают в момент запуска и на конечном устройстве. В случае VB это было делалось один раз, при компиляции и происходило на машине разработчика.
Даже если бы до появления VB5 там реально вшивался бы исходный код (что not the case, как мы выяснили, исходный код не вшивался никогда), почему-то никто никогда не делает эту ремарку с указанием версии, хотя, грубо говоря, 10 лет генерации нативного машинного кода не было, после чего 20 лет эта генерация была — то есть она была бОльшую часть времени, но этого факта как будто бы не существует, зато положение дел, которое существовало меньшую часть времени, акцентируется и извращается до непомерных масштабов (готовый оптимизированный байт-код для виртуальной машины выдаётся за исходный код).
Можно убрать это нафиг и больше никогда не возвращать? Или чтобы нужно было принудительно в настройках профиля включать эту кнопку-объяснялку где-нибудь рядом с опциями для слабовидящих и слабослышаших?
Это такая бестактная наглая ложь,что она выдернула меня из постели и заставила написать комментарий.
Не поленитесь скачать QuickBasic, написать какую-нибудь простенькую программу, скомпилировать, а потом посмотреть полученный EXE-файл в hex-редакторе и найдите там исходник.
И что? Они там не просто так, наверное. И всегда существует масса способов оформить внешнее восприятие кода так, чтобы не путаться в скобочках. А если кого-то пара ВНЕШНИХ скобочек огорачает своей избыточностей, то может надо чем-нибудь другим заниматься?
Плевать, как там хипстеры выделываются. У них design decisions делаются по принципу «лишь бы выпрендриться и отличиться от классики».
Категорически против убирания круглых скобок у условий.
Визуальную нагрузку — вы серьёзно? Дело попахивает СДВГ, если пара лишних скобочек мешает вам работать и адекватно воспринимать код.
К тому же, есть общая логика в том, что все control structure имеет унифицированный синтаксис
keyword(...) statementsblockЕсли убирать скобочки у if, то тогда по общей логике нужно убирать и у while, for, switch, а это не совместимо с тем, что у for внутри скобочек не просто выражение, а несколько выражений.
К тому же, скобочки у обычного if прекрасно контрастируют с отсутствием скобочек у #if, а устранение скобочек сближает по степени схожести.
Желание убрать скобочки — это когда делать больше нечего, а что-то сделать хочется.
Ах как всё легко и просто у людей. Ардуино головного мозга.
Дальше можно было бы прдискутировать относительно каких-то моментов, но автора тут нет, это перевод.
Человек просто любит кошек.
Пишет побочный эффект протекания электрохимических процессов в миллиардах клеток (среднюю температуру по больницы).
Пока у нас в компьютерах вольты, на ЭЭГ даже не милливольты, а микровольты. Миллионная доля вольта. Потому что это побочный продукт.
Давайте зайдём в другой стороны: слово «нейромедиаторы» вам о чём нибудь говорит? Глутамат, серотонин, ацетилхолин? Если бы нервная ткань была просто сплетением проводов (но не металлических, а органичвеского происхождения), передающих электрические импульсы, то зачем бы всё это было необходимо?
Как насчёт аппарата МРТ? Как насчёт металлургических предприятий с печами дуговой плавки? Военные радары с киловаттными излучателями? Не в одном из перечисленых случаев люди не испытывают галлюцинации, не сбиваются с мыслей, не теряют сознание и не срываются в эпилептический припадок. От военных радовов воздействие наступало, но в виде поджаривания плоти.
Что если всё дело в том, что протекание электрических токов просто ломает и подавляет внутреннюю химию мозга?
Отвратительный синтаксис; такое впечатление, что создатели новомодных языков соревнуются в том, как бы эффективнее вызвать кровотечение из глаз читающего.
Также при встрече с очередной такой статьей ещё раз проникаешься мыслью, насколько же гениальны были создатели Си, и что лаконичнее уже ничего быть не может.
Все эти fn и двоеточия даром не нужны. Особенно сильно бесят сокращения pub и fn. Это какая жалкая экономия на спичках. Так и представляю себе, как автор языка уделал всех остальных программистов мира в скорости разработки за счет экономии на буквах. Только вот есть один большой просчет. Как же это так, что у нас есть красивый и компактный fn, и при этом остался омерзительный жирный return? Должно быть ret, а ещё лучше просто r. Экономия должна быть экономной. Ну и const нужно сократить до cn.
Спасибо, но я остаюсь на Си, ваш синтаксический сахар меня не усластил.
Естественно, мы люди бедные, мы будем нацеливаться повторить рентген-томограф из фекалий и древисины.
Интересующий моментов, естественно, много. У вас линейные (одномерные) детекторы или матричные (двумерные)? Полностью готовое изделие (детектор) ставите в своё устройство или сами производите?
Рентген-КТ неживых объектов сильно проще, потому что не нужны высокие скорости перемещения, высокие быстродействия опроса детектора, передачи и сохранения информации, не нужно беспокоиться и дозовой нагрузке (в большинстве случаев).
Но всё равно хватает технических сложностей. Охлаждение трубки/источника. Как у вас вопрос решён? И вообще, режим работы — импульсный или непрерывный?
Какую мощность в целом потребляет источник, учитывая, что у них смехотворные КПД?
Хорошая стать для сайта, где сидят люди, балдеющие по археологии.
Но для Хабра хотелось бы совсем другого: разбор томографа, его конструкции, какая трубка, какой сенсор, параметры среза, напряжение трубки.
Самодельный или серийный, на чем выполняется реконструкция и т.п.