Комментарии 160
Kivy — питоновский фреймвок, в т.ч. для GUI. Можно собирать под основные десктопные и мобильные платформы.
А вот здесь пример калькулятора.
Два интересующих файла — Calculator.kv и main.py.
А вот здесь пример калькулятора.
Два интересующих файла — Calculator.kv и main.py.
Буду рад, если кто-нибудь подскажет более простые варианты создания GUI.
Пишем веб-интерфейс, а затем встраиваемый его в любое приложение на любой платформе на любом языке. Например, электрон, cef, Cordova.
… и получаем калькулятор, тянущий за собой chromium и node.js и отжирающий чуть менее чем полгига RAM на ровном месте. Это из категории "вредные советы"?
Не знаю, как у вас, а у меня 36 мб на голосовой чат (cefpython). Возможно, вам стоит прочитать про профайлер и заняться оптимизацией вашей половины гига.
Я прямо сейчас вижу как, прямо скажем, не очень-то навороченный гуй Skype на электроне отжирает у меня на машине ~300Mb RAM. Возможно, вам стоит рассказать разработчикам из Microsoft про профайлер и все такое, а то они не знают, наверное.
У меня всё хорошо.
Вы же страдаете, а не я. Никогда не задумывались, почему одно приложение потребляет 30 мб, а его аналог в 10 раз больше? Это как бы намекает на скрытые функции…
Возможно, вам стоит рассказать разработчикам из Microsoft про профайлер и все такое, а то они не знают, наверное.
Вы же страдаете, а не я. Никогда не задумывались, почему одно приложение потребляет 30 мб, а его аналог в 10 раз больше? Это как бы намекает на скрытые функции…
Я не в курсе, что у вас там за приложение, и никогда его не видел, но вот все, что я видел из написанного на электроне (тот же новый скайп или дискорд) по какому-то странному совпадению является сильно охочим до ресурсов мусором. При этом я сильно сомневаюсь, что авторы этих приложений никогда не слышали про профайлер.
Я вам про технологию, вы мне про реализацию. Я вам показал, что существует нормальная реализация, вы мне про электрон. Да, у электрона большой оверхед, это знает каждый второй. Но не я ведь его писал.
это без браузера, а значит без CEF
впрочем, Process Explorer может доказать что я неправ
впрочем, Process Explorer может доказать что я неправ
Это с браузером. Но вы в какой-то мере правы, т.к. process explorer показывает в 2 раза больше. Впрочем, 60 мб — всё-равно приемлемое число.
Process Exprorer я предложил просмотреть список загруженных приложением DLL, чтобы понять, есть там браузер в адресном пр-ве или нет.
Я перепутал, у меня голосовой чат написан на pyWebView. Внутри он запускает clr, а в ней стандартный webview из wpf. Если не верите, посмотрите оф. сайт, но других связанных процессов я не смог найти.
Впрочем, 60 мб — всё-равно приемлемое число.
Для калькулятора?
С одной стороны я согласен с вами, что делать «калькулятор» на chromium и node.js это полный бред.
Но, с другой стороны, тот же дискорд, что вы упоминаете ниже, работает отлично и хороших кроссплатформенных аналогов фактически не имеет. И в 2019 жаловаться на обьем оперативной памяти это моветон. Этим летом я купил 64Gb оперативной памяти с частотой 3200 всего лишь за жалкие 200$.
Очень надоело это нытье из разряда «раньше было лучше, на моем нетбуке с xp-шечкой все шустро запускалось, и бравзер и ворд и винумп и даже видосики 720p!!!.. А вот сейчас веб макаки все испортили и моих ЦЕЛЫХ!!! 512mb уже не хватает!!!»
И оказывается что никому не интересно в текущих реалиях жрет приложение 300 или 500mb. Зато интересно другое, в случае того же слака или скайпа, и в ситуации когда девайса под рукой нет, есть гостевой комп и срочно нужно что-то порешать аж за океаном.
И последний момент. Не нравится — не пользуйся. Очень доставляет категория людей считающая что им все должны.
Но, с другой стороны, тот же дискорд, что вы упоминаете ниже, работает отлично и хороших кроссплатформенных аналогов фактически не имеет. И в 2019 жаловаться на обьем оперативной памяти это моветон. Этим летом я купил 64Gb оперативной памяти с частотой 3200 всего лишь за жалкие 200$.
Очень надоело это нытье из разряда «раньше было лучше, на моем нетбуке с xp-шечкой все шустро запускалось, и бравзер и ворд и винумп и даже видосики 720p!!!.. А вот сейчас веб макаки все испортили и моих ЦЕЛЫХ!!! 512mb уже не хватает!!!»
И оказывается что никому не интересно в текущих реалиях жрет приложение 300 или 500mb. Зато интересно другое, в случае того же слака или скайпа, и в ситуации когда девайса под рукой нет, есть гостевой комп и срочно нужно что-то порешать аж за океаном.
И последний момент. Не нравится — не пользуйся. Очень доставляет категория людей считающая что им все должны.
Мне — интересно. Поэтому дискордом я не пользуюсь вовсе, а скайпом — только при очень большой необходимости, и то потому, что пара моих контактов другого способа оперативной связи не имеет. Рано или поздно откажусь и от него, так как считаю, что писателей откровенно плохо написанного софта поощрять не стоит. Эти "веб-макаки", как вы выражаетесь, в случае Скайпа даже не смогли толком воспроизвести уже имевшийся функционал из Скайп Классик, зато раздули потребление ресурсов сверх всякой меры. Это не тот путь, которым следует идти.
Все имеет свои причины — я более чем уверен, что возможность повторить функционал старого скайпа была — но наверняка такая задача просто не ставилась.
Грубо говоря всем управляют «бабки», то есть запросы по функционалу неплатежеспособных (это даже не зависит от ваших реальных финансовых возможностей, а лишь от готовности тратить деньги) пользователей просто игнорируются. А платежеспособная часть просто может себе позволить более мощное железо. Именно по этой причине выпускают игры под новые консоли, а не под старые.
В целом я за сбалансированный подход. Специализированный и сложный софт должен быть нативным, быстрым и потреблять минимум ресурсов.
Остальной софт — выбор за пользователями и разработчиками. Если большинству выгоднее chromium — то почему нет?
Грубо говоря всем управляют «бабки», то есть запросы по функционалу неплатежеспособных (это даже не зависит от ваших реальных финансовых возможностей, а лишь от готовности тратить деньги) пользователей просто игнорируются. А платежеспособная часть просто может себе позволить более мощное железо. Именно по этой причине выпускают игры под новые консоли, а не под старые.
В целом я за сбалансированный подход. Специализированный и сложный софт должен быть нативным, быстрым и потреблять минимум ресурсов.
Остальной софт — выбор за пользователями и разработчиками. Если большинству выгоднее chromium — то почему нет?
"Более мощное железо" потихоньку тоже перестаёт решать, производительность уже давно не удваивается каждые 18 месяцев. Скайп теряет рынок:
не в последнюю очередь из-за применения сомнительных технических решений, которые удобны для разработчиков, но не для пользователей.
Да, железо тоже перестает решать. Вполне возможно будет обратная волна, когда софт будут оптимизировать и это будет экономически выгодно.
Скайп в основном же сожрали whatsapp, slack, viber и телеграмм. Так же сдох когда-то ICQ. Кстати ICQ работало даже на железе уровня микроволновки, но его это не спасло.
Кроме того компания, где я работаю, долго использовала Skype, но затем тоже перешла на Slack.
Скайп в основном же сожрали whatsapp, slack, viber и телеграмм. Так же сдох когда-то ICQ. Кстати ICQ работало даже на железе уровня микроволновки, но его это не спасло.
Кроме того компания, где я работаю, долго использовала Skype, но затем тоже перешла на Slack.
Да, но почему они его сожрали? Не потому ли, что MS тупо перестал прислушиваться к желаниям пользователей, а вместо этого начал ваять жручий, тормозной и малофункциональный мусор?
Просто раньше Skype был по сути монополией, потом появились конкуренты и отхватили свою долю рынка.
Насколько я знаю (могу ошибаться) Skype до сих пор очень популярен в латинской америке. Вот немного статистики по нему.
Насколько я знаю (могу ошибаться) Skype до сих пор очень популярен в латинской америке. Вот немного статистики по нему.
А и еще. К сожалению HTML5 + CSS это лучшее что смог предложить рынок для десктопа по уровню функционал/документация/примеры. Если взять так любимый многими QT — профессионально и быстро выполнить сложный высер дизайнерской мысли смогут лишь полтора бородатых разработчика, в доках пока разберешься — тысячи Раджешей Кутрапале уже наваяют тоже самое на HTML5 + CSS и все — ты вне игры. Да, будет течь. Да, будет жрать. Но они заработали, а ты нет. Потому что ты все еще ищешь как без костылей сделать custom traffic lights titlebar на MacOSX.
Кстати кому интересно есть проект node + qt5 — тоже кроссплатформа, тоже Javascript, но без chromium.
Кстати кому интересно есть проект node + qt5 — тоже кроссплатформа, тоже Javascript, но без chromium.
Лично я считаю, что тот же QML сделан гораздо более пригодным для standalone приложений, чем html/css, которые изначально вообще для приложений как таковых не предназначались. Раджеши Кутрапале, конечно, наваяют вам ЧТО-ТО… Но как бы потом с этим "что-то" не получилось, как у MS со Скайпом. ИМХО использование вещей типа Электрона допускается только как временное решение — если нужно быстро сделать приложение на базе уже имеющегося веб-решения, это их ниша. Застолбить преимущество. Но затем с этого нужно уходить, а то юзеры проклянут, и уйдут к более оптимизированным конкурентам, а такие обязательно появятся.
А какое вы видите решение?
Лично я предпочитаю Qt. Я из тех самых "бородатых разработчиков", правда, бороды у меня все-таки нет :) Но тут есть нюанс — Qt — это все-таки для вещей посложнее калькулятора. Вот для таких, например:
https://www.inobitec.ru/products/dicomviewer/
Для калькулятора Qt все-таки жирноват.
Спасибо.
Предупреждать же надо! Приложение, может, и хорошее, но я ослеп на первой же странице сайта. Белый текст на светло-голубых макаронах… я слишком стар для этого...
Наблюдаю у себя несколько лаунчеров от игр, сделаны на Qt+QtWebEngine. ИЧСХ частный рабочий набор тоже типично 80-90, и до 172Мб. Так что хрень редьки то…
С QtWebEngine — то неудивительно.
Вот такой куркулятор на QML:
у меня кушает под виндой ~35Mb RAM, при этом просто пустой Window кушает столько же. Но, согласен, для куркулятора это тоже немало (к слову, штатный виндовый куркулятор кушает ~20Mb), поэтому я и написал выше про «жирноват». Но все же не 80-90. EXE занимает 28 килобайт, но не будем забывать про набор Qt'шных dll'ек, которые смело добавят еще метров 15 минимум. Хотя можно попробовать собрать статически, но возиться неохота — у меня Qt собран только в динамическом варианте.
import QtQuick 2.12
import QtQuick.Controls 2.12
import QtQuick.Layouts 1.12
import QtQuick.Window 2.12
Window {
visible: true
width: 640
height: 480
title: qsTr("Calculator")
ColumnLayout {
anchors.fill: parent
spacing: 16
TextField {
id: textField
readOnly: true
Layout.fillWidth: true
Layout.alignment: Qt.AlignVCenter
}
GridLayout {
rows: 4
columns: 4
Layout.fillWidth: true
Layout.fillHeight: true
Repeater {
model: ["7", "8", "9", "+", "4", "5", "6", "-", "1", "2", "3", "*", "C", "0", "=", "/"]
Button {
text: modelData
Layout.fillWidth: true
Layout.fillHeight: true
onClicked: {
if (text === "C") {
textField.text = "";
} else if (text === "=") {
try {
textField.text = evaluate(textField.text);
} catch (e) {
textField.text = e.message;
}
} else {
textField.text = textField.text + text;
}
}
function evaluate(expression) {
return eval(expression);
}
}
}
}
}
}
у меня кушает под виндой ~35Mb RAM, при этом просто пустой Window кушает столько же. Но, согласен, для куркулятора это тоже немало (к слову, штатный виндовый куркулятор кушает ~20Mb), поэтому я и написал выше про «жирноват». Но все же не 80-90. EXE занимает 28 килобайт, но не будем забывать про набор Qt'шных dll'ек, которые смело добавят еще метров 15 минимум. Хотя можно попробовать собрать статически, но возиться неохота — у меня Qt собран только в динамическом варианте.
Вместе с Qt я получаю QML и все необходимые библиотеки и если на MacOS собираю приложение, то оно работает для MacOS. Можно ли собрать приложение на MacOS для Windows/Linux?
НЛО прилетело и опубликовало эту надпись здесь
Кстати, у меня тут возник вопрос. Допустим, я делаю приложение под Linux и хочу распространять еще и бинари, чтобы упростить людям жизнь. Не получится ли так, что мне придется делать версию под каждую поддерживаемую версию каждого поддерживамаего дистрибутива, ведь там могут отличаться версии Qt и вся бинарная совместимость накроется?
НЛО прилетело и опубликовало эту надпись здесь
В общем-то более новые версии Qt совместимы с более старыми в пределах той же самой мажорной версии (то есть приложение, собранное с Qt 5.5, будет работать с библиотеками от Qt 5.12, но приложение, собранное с Qt 4.x уже не будет работать с любыми библиотеками от Qt 5.x). Но… это при условии, что они собраны одним и тем же компилятором, потому что у разных C++ компиляторов может быть разная система декорирования имен, реализация виртуальных таблиц, и так далее, и тому подобное. Можно попытаться собрать Qt в статическом варианте и слинковать с вашим приложением статически, но… это в случае, если вы не используете модули из Qt, которые для работы используют плагины (например, работа с некоторыми форматами изображений или карты — OSM/HERE/Mapbox/...) — плагины существуют только в виде динамических библиотек, и их тогда придется поставлять в составе приложения тоже и обеспечивать, чтобы приложение могло их загрузить оттуда, где они будут лежать после его распаковки/установки. В общем, с этим все не так просто.
Если суметь сделать приложение на одном QML, его можно будет запускать при помощи qmlviewer на любой платформе без перекомпиляций.
Возможно. Я пока далек от JS.
НЛО прилетело и опубликовало эту надпись здесь
«раньше было лучше, на моем нетбуке с xp-шечкой все шустро запускалось, и бравзер и ворд и винумп и даже видосики 720p!!!
Ну да, и я должен пойти на поводу у веб-макак и выкинуть свой верой и правдой служащий мне >10 лет ThinkPad T60 потому что какому-то придурку лень запускать профайлер и оптимизировать софт.
Нуачо, ведь у абсолютно всех пользователей 64 гига оперативки. А тех, у кого 64 гигов нет — нужно спустить с парахода прогресса в биореактор, чтобы они не мешались.
Правильно объясняю? :)
Не правильно :) Всем просто плевать, что у вас ThinkPad T60 и специально под него оптимизировать ничего не будут.
P.S. На мне злость за это сгонять не надо. Это не я пишу глючный софт на электроне чтобы он у вас не запускался. А то вон понакидали минусов, словно я автор всех приложений на электроне.
P.S. На мне злость за это сгонять не надо. Это не я пишу глючный софт на электроне чтобы он у вас не запускался. А то вон понакидали минусов, словно я автор всех приложений на электроне.
Это возможный путь. Я иногда жалею, что начал с Python, а не с мира JavaScript.
Все от задач зависит. Python — это мир бэкенда, решения научных задач, искусственного интеллекта и т.п. JavaScript — фронтэнд, визуальщина (можно и на сервере использовать, но это уже на любителя)…
НЛО прилетело и опубликовало эту надпись здесь
Python — мир клея между библиотеками.
Вы предпочитаете не пользоваться библиотеками? Или суперобъёмная std вас смущает? На вашем языке библиотеки не принято использовать?
Алгоритмы ML не пишут на питоне
Я вас удивлю, но пишут.
бекенд, то рано или поздно либо умирают
Это проблема архитектуры и IDE, а не языке. Посмотрите PyCharm.
НЛО прилетело и опубликовало эту надпись здесь
Вы любите самобытные языки? Небось, на ассемблере пишете без всяких там опор и библиотек?)
Можно. Тем более, она в нём присутствует. Но даже если было бы нельзя, вам не хватило бы статического анализатора? Сдаётся мне, что какой-нибудь метод, который возвращает либо int, либо str, либо их кортежи, либо None, либо исключение — не есть проблема типизации.
Нельзя к языку адекватно прикрутить типизацию сбоку, если он был создан без расчёта типизации.
Можно. Тем более, она в нём присутствует. Но даже если было бы нельзя, вам не хватило бы статического анализатора? Сдаётся мне, что какой-нибудь метод, который возвращает либо int, либо str, либо их кортежи, либо None, либо исключение — не есть проблема типизации.
НЛО прилетело и опубликовало эту надпись здесь
Похоже, проблема динамической типизации в том, что она вам не нравится. Иначе я не могу объяснить, почему для вас тип входных параметров является проблемой. В конце концов, вы сами можете проверить типы, использовать аннотации типов, использовать библиотеки типизации. С другой стороны, люди, которые в этом не нуждаются, могут использовать «чистый» язык. По-моему, это намного лучше, чем:
new public List<[CanBeNull] Dict<int,(byte[],Hasher)>> GetNamedHashesByID<in Hasher>(ref [NotNull] CryptoContainer seed, params int[] ids) where Hasher:ICryptoHashAlgoritm {...}
Но так-то явно лучше:
чем так:
И гадать/всегда смотреть в доках, какого же типа аргументы.
GetNamedHashesByID(CryptoContainer seed, int[] ids)
чем так:
GetNamedHashesByID(seed, ids)
И гадать/всегда смотреть в доках, какого же типа аргументы.
Кому явно? Кому лучше? Людям, которые в этом не нуждаются?
Теперь вам придётся гадать/всегда смотреть в доках, правильные ли значения аргументов были переданы. Получается, что вы типы добавили, а проблему не решили.
Ну и почему я должен половину работы сбрасывать языку, а вторую половину брать на себя? Тогда уж пусть язык сам все необходимые проверки делает и не выбрасывает исключения в рантайме или вообще не вмешивается. А если уж и вмешивается, то я сам хочу настроить, где и как.
Проблема типизации в том, что вы про это не знаете и знать не можете.
GetNamedHashesByID(null, null);
GetNamedHashesByID(null, new int[0]);
Теперь вам придётся гадать/всегда смотреть в доках, правильные ли значения аргументов были переданы. Получается, что вы типы добавили, а проблему не решили.
Ну и почему я должен половину работы сбрасывать языку, а вторую половину брать на себя? Тогда уж пусть язык сам все необходимые проверки делает и не выбрасывает исключения в рантайме или вообще не вмешивается. А если уж и вмешивается, то я сам хочу настроить, где и как.
НЛО прилетело и опубликовало эту надпись здесь
Почему?
Потому что они правильные для компилятора, но неправильные для функции. Если функция рассчитывает на непустой массив, а на вход дали «правильный», но пустой, то в рантайме вылезет исключение, не смотря на все статические проверки.
У вас там NotNull было на первом параметре?
chersanya по каким-то причинам предлагает выкинуть половину сигнатуры.
Не надо в рантайме.
Согласен, я так и написал.
chersanya,
Про пример с null не понял, какое именно утверждение вы им иллюстрируете.
Nullable тип является указателем на этот тип, поэтому может оказаться «просроченным».
чтобы избавиться от этой «половины» работы/багов/тестов.
Всё-равно ведь придётся писать вторую половину. От 10 лишних строчек я не умру, а вот читать и учить мануалы про внутреннее устройство языка, чтобы опустить проверку на null… Это намного больше усилий потребует, чем написать
seed = seed || new DefaultSeed();НЛО прилетело и опубликовало эту надпись здесь
Только ведь всё равно получается лучше, чем в питоне.
1,228,588 репозиториев на гитхабе говорят об обратном (у С/С++ 549,210 репозиториев).
Nullable. Не понял. что значит «просроченным»
Это значит, что тип может иметь значение null. Такое значение нельзя привести к типу. Null — это отдельный тип. Поэтому, когда вы указываете nullable параметр в функции, вам надо это учесть. Компилятор не будет ругаться, даже если вы передали null вместо нормального значения. В итоге, в рантайме вылезет ошибка вида «Null reference exception».
Только она может оказаться сильно меньше.
А может и нет.
а 10 строк приходится писать постоянно.
Откройте для себя повторное использование кода.
Только вот, увы, все проблемы от nullability это не покрывает.
Какие?
В итоге, из обсуждения питоновских библиотек, алгоритмов и типов мы пришли к обсуждению null. Если вам нравится язык с 60% проверок, не надо говорить о бездарности языка с 40%, т.к. всегда найдётся 61% язык, который заявит о бездарности вашего.
1,228,588 репозиториев на гитхабе говорят об обратном (у С/С++ 549,210 репозиториев).
Если вы качество инструмента оцениваете по его популярности то лучше всех JS и PHP.
Только популярность с качеством не особо то коррелирует обычно.
НЛО прилетело и опубликовало эту надпись здесь
Кажется, мы обсуждаем количество информации, передаваемой при чтении кода, а не количество репозиториев.
Я это не обсуждал. Возможно, вы меня перепутали с другим юзером.
У типа есть значение, которое нельзя привести к этому типу?
Например, создадим класс. Затем вызываем метод Hi.
public class A {
public void Hi()
{
Console.WriteLine("Hi!");
}
}
A x = new A();
x.hi(); //>>HiТеперь присвоим переменной null. И повторим.
x=null;
x.hi(); //ошибка рантайма
x = new null(); //ошибка компиляцииУдивительно, но значение есть, а метода нет. Почему? Потому что null нельзя привести к A (у него нет смещения на метод Hi).
Как вы повторно используете тесты, проверки на входящие типы и прочие подобные вещи?
1. копипаст
2. макросы
3. библиотеки аннотаций, декораторов, атрибутов, других обёрток
3. ide
4. расширение компилятора, анализатора, языка
5. чистые функции
6. шаблонизаторы, генераторы и фреймворки
chersanya по каким-то причинам предлагает выкинуть половину сигнатуры.
Да, предлагаю, и при этом одновременно предлагаю брать язык, где null по-умолчанию не разрешён. Среди популярных языков выбор таковых имеется.
Потому что они правильные для компилятора, но неправильные для функции. Если функция рассчитывает на непустой массив, а на вход дали «правильный», но пустой, то в рантайме вылезет исключение, не смотря на все статические проверки.
Разумеется нельзя все требуемые свойства входных параметров в общем случае вывести в тип аргумента. Например, если функция принимает на вход имя существующего файла.
Но чем больше ошибок отлавливается автоматически языком без запуска программы, тем лучше и надёжнее.
Nullable тип является указателем на этот тип, поэтому может оказаться «просроченным».
Как уже правильно написали, «nullable-ность» типа и то, является ли он указателем, вещи не связанные. Вообще в прикладном программировании задумываться об указателях особо не приходится. И что значит «просроченным»?
НЛО прилетело и опубликовало эту надпись здесь
А предикат вида «итеративный алгоритм, реализованный этой функцией, сходится для данного значения X» выразить можно, но смысла в этом особо нет — для проверки нужно выполнить, собственно, функцию.
Про пример с null не понял, какое именно утверждение вы им иллюстрируете. Лично я, например, предпочитаю языки, где по-умолчанию никакой тип null не разрешает, и нужно наоборот явно указывать где он может быть. Но этот момент ортогонален статическим/динамическим типам.
По-моему ответ очевиден, разве нет? Чтобы избавиться от этой «половины» работы/багов/тестов.
Ну и почему я должен половину работы сбрасывать языку, а вторую половину брать на себя?
По-моему ответ очевиден, разве нет? Чтобы избавиться от этой «половины» работы/багов/тестов.
НЛО прилетело и опубликовало эту надпись здесь
Мне нравилось, что у lua динамическая типизация. Удобно для маленьких проектов и скриптов. Но я не изменять тип переменной и обращался с языком, как со статическим. Параметров в функциях не хватает.
GScript (язык движка Godot) позволяет указать явно тип, но пока не делает это правило обязательным.
После, близкого знакомства со swift, понял, что статическая типизация мне больше нравится, чем нет. Это просто удобно.
Динамическая типизация — это общее понятие, под которое можно подвести и nullable типы, и вариативность типов (
Ну да. Это получается динамическая типизация второго порядка. А ещё IDE умеют автоматически разбивать динамически типизированные переменные на статически и размечать типы, когда достаточно написать пример использования.
public type1, type2, type3 x = new type1();А было бы лучше
Ну да. Это получается динамическая типизация второго порядка. А ещё IDE умеют автоматически разбивать динамически типизированные переменные на статически и размечать типы, когда достаточно написать пример использования.
НЛО прилетело и опубликовало эту надпись здесь
Так как его сформулировать-то?
Так разве не вы написали? Привязка типов в райнтайме — динамическая, в компиляторе — статическая, причём 1 к 1.
Компилятор вас всего лишь заставляет писать с учётом возможной нулябельности. Где ж тут динамическая типизация?
В рантайме тип может поменяться на null.
public type1, type2, type3 x = new type1();
Переменная x может иметь либо тип1, либо тип2, либо тип3.
Касты проверяются статически
А выполняются в рантайме => динамическая.
Нет, апкасты всё равно происходят во время компиляции.
Только если типы можно вывести. Поэтому тоже динамическая.
И чем это отличается от гарантированного вывода типов
Большая гибкость, больше возможностей, меньше запретов, больше свободы.
НЛО прилетело и опубликовало эту надпись здесь
А можно пример апкаста, когда типы вывести нельзя?
class C:A,B {...}Множественное наследование, например. Куда будет приведён класс C? Непонятно, зависит от ситуации.
Если я на С стану писать, оперируя лишь структурами вида с ручными проверками typeTag перед каждой операцией, то динамически типизированным он от этого не станет.
Конечно, у вас типы уже привязаны заранее, а оперируете вы их значениями.
НЛО прилетело и опубликовало эту надпись здесь
Т.е. вы видите, что rust удобнее для вас чем известный вам с++?
НЛО прилетело и опубликовало эту надпись здесь
В растике вам точно так же придется бояться UB в unsafe блоках, так что ИМХО хрен редьки не слаще :) Я, поглядев на растик, пришел к выводу, что он, конечно, защищает… в каких-то очень тривиальных случаях, которые и так видны достаточно наметанным глазом. Но в нетривиальных случаях он так же беспомощен в плане защиты от дурака, как и C++. Растик, возможно, и хорош для джавистов/шарпистов, которые хотят написать что-то действительно быстрое и притом не облажаться, в пределах его safe подмножества, но не дай бог этим людям начать писать на нем unsafe код. Чтобы писать unsafe код на растике, нужно иметь ничуть не меньше опыта и понимания, чем чтобы писать на C/C++.
НЛО прилетело и опубликовало эту надпись здесь
Да, только на C++ у вас весь код ансейф, а на расте он явно выделен соответствующим образом.
Убер-аргумент, сдаюсь! :) Закрыли паллетами, значит, все хорошо. Да это я так, троллю, понятно, что все это уже по сто раз обсуждалось.
И не могу сказать про раст, но на том же хаскеле ансейф-код мне приходится писать примерно никогда. Даже FFI норм получается.
Вы просто выносите unsafe код в C/C++ либы, ну а к ним уже FFI :)))
Если точнее, python — это мир бэкенда+фронтенда, а javascript — только фронтенда.
Можно вместо встраивания сделать из вэб-интерфейса Progressive Web App. Либо вообще так и распространять в виде вэб-приложения. Пусть пользователь запускает index.html. Помню, делал так, вполне было юзабельно. Если надо в виде отдельного экзюка, то еще 10 лет назад писал простейший враппер на C++Builder, который использовал компонет WebBrowser и запускал то же самое вэб-приложение…
А размер standalone приложения для MacOS будет всего 1 MB.
Грустно конечно, что для простейшего калькулятора миллион байт — это «всего».
А когда то сишники кричали что делфи жирные программы делает.
Посмотрел среди старых исходников написанный интереса ради калькулятор — 360 кб.
Куда мы идем хз.
Посмотрел среди старых исходников написанный интереса ради калькулятор — 360 кб.
Куда мы идем хз.
С графическим интерфейсом? Без зависимостей?
На чистом WinAPI можно написать GUI приложение с кучей свистелок, и занимать оно будет десятки килобайт от силы. Но трудоемкость написания возрастет в разы.
если не считать винду (а точнее winapi) зависимостью то да без зависимостей
зы можно было и под другие платформы компилить.
зы можно было и под другие платформы компилить.
Но если под другую платфоому, то там должны быть библиотеки WinAPI, так? И тогда уже не 10 кб, а больше.
НЛО прилетело и опубликовало эту надпись здесь
Т.е. вы можете при сборке указать MacOS целевой платформой и получить бинарный файл готовый к использованию и без зависимостей?
Это работает только для консольных приложений. Если нужен кроссплатформенный GUI, то без зависимостей не обойтись.
НЛО прилетело и опубликовало эту надпись здесь
Вот я ищу максимально простое решение. Нечто, что может делать приложения для всех платформ из коробки, как игровые движки.
Взять в дорогу WinAPI можно в виде wine.
С графическим интерфейсом и без зависимостей моя кубикокидалка (d2, d3, d4, d6, d8, d10, d20, d100 и произвольный + произвольное AdB+C), написанная на дельфи в 2004 году занимает ровно 320000 байт.
И я считаю, что это очень много. По сравнению с JPEG Stripper'ом на 25600 байт. Или bred'ом на 183296 байт.
И я считаю, что это очень много. По сравнению с JPEG Stripper'ом на 25600 байт. Или bred'ом на 183296 байт.
На сегодняшний день, какая есть альтернатива? Кроме electron. Не обязательно с визуальным интерфейсом.
Ну, сейчас выгоднее то же самое приложение написать для веба и запускать в браузере. Займет оно килобайт 5-6 и будет прекрасно работать без инета (собственно у меня есть такая кубикокидалка на 3800 байт, но реализует она не всё что умела дельфёвая версия).
Электрон тут «нужен» разве что чтобы от браузера «отказаться», только это только видимость будет.
А вот так, чтобы на выходе был бинарник… тут я вам не подскажу. Особенно если хочется бинарник кроссплатформенный.
Электрон тут «нужен» разве что чтобы от браузера «отказаться», только это только видимость будет.
А вот так, чтобы на выходе был бинарник… тут я вам не подскажу. Особенно если хочется бинарник кроссплатформенный.
С динамической линковкой
Со статической будет в разы тяжелее
Со статической будет в разы тяжелее
НЛО прилетело и опубликовало эту надпись здесь
когда я учился в ходу была 6 версия
впрочем мог и 7 скомпилить давно было не помню
впрочем мог и 7 скомпилить давно было не помню
Хорошо, а в чем тогда подвох? Почему эта технология постепенно исчезает?
Дизайн виджетов устарел?
Можно ли на windows собрать программу для запуска в macOS, чтобы на macOS не устанавливать зависимости?
Например, вы перешлете мне файл на 12 кб и я смогу запустить калькулятор?
языковые войны однако
delphi практически вытеснили с рынка
настолько что их купила другая компания
сейчас разработкой занимается не borland а embarkadero
сломали интерфейс стремясь быть похожими на vs что оттолкнуло кучу разработчиков от новых версий.
а потом и совместимость со старым кодом частично сломали ради улучшения кросплатформенности
да, теперь кроме windows linux и macos можно компилировать и под ios с android
но это требует переписывания кода и использования значительно более тормознутой системы gui.
в общем на данный момент rad система практически мертва изза неправильного развития хоть разработчик и пытается увеличить популярность.
lazarus живее (за счет бесплатности) но куда менее оптимизирован
зы под линукс собрать точно можно было а вот под макось не пробовал
там куча лицензионных заморочек чтоб эпплу в аду икалось
delphi практически вытеснили с рынка
настолько что их купила другая компания
сейчас разработкой занимается не borland а embarkadero
сломали интерфейс стремясь быть похожими на vs что оттолкнуло кучу разработчиков от новых версий.
а потом и совместимость со старым кодом частично сломали ради улучшения кросплатформенности
да, теперь кроме windows linux и macos можно компилировать и под ios с android
но это требует переписывания кода и использования значительно более тормознутой системы gui.
в общем на данный момент rad система практически мертва изза неправильного развития хоть разработчик и пытается увеличить популярность.
lazarus живее (за счет бесплатности) но куда менее оптимизирован
зы под линукс собрать точно можно было а вот под макось не пробовал
там куча лицензионных заморочек чтоб эпплу в аду икалось
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за ответ, теперь стало понятнее. Я пока работаю с MacOS.
И пока из всех ответов я не нахожу решения проще чем предлагают разработчики языка Red.
Устанавливаешь один файл, в нем все что нужно для работы и компиляции GUI приложения для разных платформ.
Язык в версии 0.64, если доведут до конца, будет любопытная штука.
Кстати, в нем сильно чувствуется наследие Scheme.
В плане кроссплатформенности, посмотрите на flow9.
Спасибо.
Сегодня, пока общался на хабре открыл очень удобную библиотеку Python для визуализации данных streamlit
Извините, что без ссылки.
По принципу работы чем-то похоже на imgui и nuklear
Читаю обзор flow9 на сайте. Классная штука, завтра буду пробовать.
Если окажется, проще чем Dart, то непонятно, почему малоизвестна.
Для своих программок с GUI использую wxpython, это python версия кроссплатформенной библиотеки WX Widgets. Под нее есть и билдеры всякие, для создания интерфейса перетаскиванием кнопочек, но я пишу кодом, как-то уже привык, несложно и удобно.
НЛО прилетело и опубликовало эту надпись здесь
Пример на tcl/tk
За правильность логики самого калькулятора не ручаюсь, делалось на скорую руку. Но построение интерфейса видно. Количество строк можно сократить, но читать код будет труднее. Ну и сам внешний вид можно менять если взять ttk
За правильность логики самого калькулятора не ручаюсь, делалось на скорую руку. Но построение интерфейса видно. Количество строк можно сократить, но читать код будет труднее. Ну и сам внешний вид можно менять если взять ttk
wm title . "Tcl/TK calc"
pack [frame .frm] -expand true -fill both
grid columnconfigure .frm 0 -weight 1
grid rowconfigure .frm 0 -weight 1
entry .frm.ent
grid .frm.ent -row 0 -columnspan 5 -sticky nswe -padx 5 -pady 5
proc Calculate {ent txt} {
if [regexp -nocase -all -- {([0-9]+)(\+|\*|\/|-)([0-9]+)} $txt match v1 v2 v3] {
$ent delete 0 end
$ent insert end [expr double($v1) $v2 double($v3)]
}
}
set col 0
set row 1
foreach item {1 2 3 4 5 6 7 8 9 0 + - * /} {
button .frm.btn_$item -text "$item" -command [list .frm.ent insert end $item]
grid .frm.btn_$item -row $row -column $col -sticky nswe -padx 5 -pady 5
incr col
if {[expr fmod($col, 5)] eq "0.0"} {
incr row
set col 0
}
}
button .frm.btn_calc -text "=" -command {
Calculate .frm.ent [.frm.ent get]
}
grid .frm.btn_calc -row 3 -column 4 -sticky nsw -padx 5 -pady 5
import calc
calc()Две строчки. Я победил.
Раз уж пошли мериться размерами калькуляторов
1262 байт. Сохранить в файл с именем calc.hta (работает только под win)
1262 байт. Сохранить в файл с именем calc.hta (работает только под win)
calc.hta
<html>
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="ie=9">
<title>calc</title>
<HTA:APPLICATION border="dialog" maximizeButton="no" icon="calc.exe" applicationName="calc" innerBorder="no" navigable="no" scroll="no" />
<style>
* {
font-family: monospace;
}
</style>
</head>
<body>
<input type="text" id="c" /><br>
<script>
window.resizeTo(200,200)
var c = document.getElementById('c');
[
7, 8, 9, '-', 0,
4, 5, 6, '/', 0,
1, 2, 3, '*', 0,
'0', '.', '+', '='
].map(function (e) {
if (!e) {
document.body.appendChild(document.createElement('br'));
} else {
var i = document.createElement('input');
i.value = e;
i.type = "button";
document.body.appendChild(i);
i.addEventListener('click', function () {
if (e == '=') {
try { c.value = eval(c.value); } catch (e) { }
} else {
c.value += e;
}
});
}
});
</script>
</body>
</html>
Моих знаний JS, для такой штуки достаточно. Спасибо. Этой штуке не нужен браузер?
hta запускается в своём окне на движке ие (может эдж в более поздних виндах, у меня его нет).
ru.wikipedia.org/wiki/HTML_Application
Кроме стандартных браузерных js функций доступен системный api
Пример чтения локального файла
Кроме стандартных браузерных js функций доступен системный api
Пример чтения локального файла
Заголовок спойлера
<html>
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>TEST</title>
</head>
<body>
<div id="content"></div>
<script language="VBScript">
Function loadLocalFile(fileName)
set oFSO = CreateObject("Scripting.FileSystemObject")
set oFile = oFSO.OpenTextFile(fileName, 1)
text = oFile.ReadAll
oFile.Close
loadLocalFile = text
End Function
</script>
<script type="text/javascript">
document.getElementById('content').innerText = loadLocalFile('lorem.txt');
</script>
</body>
</html>
У меня создается ощущение, что в заголовке статьи вы пропустили слово. Идеальный в чем? В размере бинарника? В количестве строк для реализации калькулятора? В кроссплатформенности?
Я понимаю, что слово «идеальный» требует пояснений.
1. Простая установка на любую платформу (скачиваем установщик или собираем c помощью make или cmake имея только gcc или clang)
2. Возможность собрать приложение для работы на разных платформах. Компиляция или другие способы. Без проблем и дополнительных инструментов. Желательно одна или две команды в терминале.
3. Приложение на выходе меньше 50 мб
1. Простая установка на любую платформу (скачиваем установщик или собираем c помощью make или cmake имея только gcc или clang)
2. Возможность собрать приложение для работы на разных платформах. Компиляция или другие способы. Без проблем и дополнительных инструментов. Желательно одна или две команды в терминале.
3. Приложение на выходе меньше 50 мб
НЛО прилетело и опубликовало эту надпись здесь
Если у человека основная область деятельности далека от разработки ПО, то C++ ему все-таки в руки лучше не давать. Пусть уж прототипирует на том же Питоне то, что ему надо, а вот если это нужно будет потом запустить в продакшн под нагрузочкой, то тут уже можно и на C++ это перевести с помощью специально обученных людей. Тем более для Питона существуют официальные Qt-биндинги:
https://www.qt.io/qt-for-python
https://doc.qt.io/qtforpython/tutorials/qmlapp/qmlapplication.html
НЛО прилетело и опубликовало эту надпись здесь
Ну так нагрузка может для какой-то конкретной задачи и вовсе не предполагаться — скажем, уровня условного «калькулятора»: какие-то формочки там, в которые вбиваются определенные данные, затем над ними производятся какие-то несложные расчеты. Зачем там C++ в прикладном коде? Он там не нужен. Тем не менее кроссплатформенность даже в таких задачах вполне может быть нужна.
На python есть PySimpleGUI — кроссплатформенная библиотека, поддерживает tkinter, Qt, WxPython, Remi (в браузере).
Более 100 демо-программ
Более 100 демо-программ
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Поиски «идеального» GUI. Путь новичка