Comments 280
Тоже не хочу разводить холивары, но чем людям так Ruby не нравится? Может кто-нибудь пояснить?
Я думаю тут уместна цитат: «Существует два типа языков программирования: те которые все обсирают, и те на которых никто не пишет».
выше вон появился пост с позитивными трендами
Вторые (с некоторым преувеличением) — это вероятно какие-нибудь Erlang или Clojure? В целом вещи часто очень хорошие, но для 99% задач этого мало — нужны типовые toolkit'ы, нужна среда разработки, средства сборки и ещё много чего. Такие, как я их называю, экспериментальные языки программирования, чаще всего хотя б по одному из таких пунктов очень слабы.
И немножко поподражаю root'овому сообщению ветки — а чем людям так Objective-C не нравится — по мне один из лучших языков программирования, особенно по мне он очень хорошо сохранился с такой ношей обратной совместимости.
И немножко поподражаю root'овому сообщению ветки — а чем людям так Objective-C не нравится — по мне один из лучших языков программирования, особенно по мне он очень хорошо сохранился с такой ношей обратной совместимости.
какие-нибудь Erlang
Какие-нибудь WhatsApp, RabbitMQ, ejabberd, flussonic и чертова куча софта для телекома, в том числе — мобильного.
Эрланг язык малозаметный, не то, что JavaScript (господи помилуй!).
Но говорить, что на нем «никто не пишет» — большая ошибка. И еще большая ошибка — называть его «экспериментальным», учитывая его историю.
Какие-нибудь WhatsApp, RabbitMQ, ejabberd, flussonic и чертова куча софта для телекома, в том числе — мобильного.
Эрланг язык малозаметный, не то, что JavaScript (господи помилуй!).
Но говорить, что на нем «никто не пишет» — большая ошибка. И еще большая ошибка — называть его «экспериментальным», учитывая его историю.
Может быть разработчики PHP и Ruby дизлайкают друг-друга?)
Почитать бы эти developer stories, но они, видимо, видны только автору или работодателям.
Субъективизм же. А почему он должен нравится с другой стороны? Когда он был в расцвете сил он делал нечто удивительное, но сейчас такое могут многие, если не все. Поэтому теперь все смотрят на его недостатки.
Например, "все есть объект" без исключений, в отличии от других ОО-языков. Модель наследования очень гибкая (самая гибкая?). Развитые возможности метапрограммирования. Но это все не оценят люди, знакомые с языком поверхностно.
Мог бы предположить, что дизлайкают за отсутствие статической типизации и проверки типов, но по результатам всем нравятся JS и Python. И bash :) Сейчас только обратил внимание.
Вообще, в предыдущих исследованиях SO вроде показали, что большая часть (с отрывом) аудитории — разработчики JS и SQL :) Так что столько дизлайков в сторону бэкенд языков, ничего могут и не значить кроме того, что они просто кому-то не нравятся в интернете.
Может за метапрограммирование и не любят, ведь оно сильно уменьшает предсказуемость поведения просматриваемого в данный момент кода.
Если плохо пользоваться шаблонами с++, можно столкнуться с бОльшими трудностями. Метапрограммирование в том или ином виде есть в большинстве языков с меньшим количеством негативных оценок. В руби, благодаря модели наследования, можно получить гораздо более предсказуемое и отлаживаемое поведение. А из-за гибкого синтаксиса, самые разные DSL можно реализовать без библиотек, только с использованием языка.
Сейчас это хочется сказать про C#. Конечно, в плане лямбд и LINQ он не 100%-й первопроходец, но значительной степенью с него началось их массовое использование, а ещё и как задел на будущее для абстракций рекурсий. 6 лет назад анонсировали async/await — тогда казалось круто, а нынче относительно ReactiveCocoa, — какой убожество. А позднейшие spoonful of syntactics sugar не сильно могут «подсластить» сие отставание.
Открыл первую попавшуюся статью, а там:
Так вот, на шарпе вся эта реактивщина лет 8 точно. Отставание? Не, не слышал…
Для .NET разработчиков все это может показаться очень знакомым. ReactiveCocoa, на самом деле, Objective-C версия Reactive Extensions (Rx) для .NET.
Так вот, на шарпе вся эта реактивщина лет 8 точно. Отставание? Не, не слышал…
UFO just landed and posted this here
Рискну опять нахватать минусов, но поделюсь своим опытом:
Последний ruby-разработчик, который нанимал меня на проект (я front-end разраб), сказал: «мы клиентский javascript пишем на coffee или на ES5, не хочу усложнять и добавлять в стек babel — он тормозит». Я подумал-подумал, и отказался.
Ну это так, частный случай. А вот общее наблюдение, которое случалось не один раз: проблема руби в том, что в руби всё идеально и «по линейке»! Но только до тех пор, пока ты в уютных рамках рельс. А «внешний мир» — он совсем не такой безоблачный, и мне, со своей колокольни, бывало очень сложно донести это руби-команде. Взять тот же snake_case, который чужд и в js, и в разметке, и в стилях. В ангуляре очень «здорово» такие поля_объектов иметь. И пробуй объясни, что это jbuilder должен отдавать вражеский camelCase. С названиями файлов та же ситуация.
Или вот, отсутствие фигурных скобок и табы — крутая идея. Только она не всегда хорошо работает. В sass есть проблемы с разбиением длинных строк. И порой, под возмущенные возгласы, приходилось коммитить старый добрый scss (точнее, новый добрый — потому что во всём остальном мире, кроме руби-сообщества, именно scss — стандарт!).
Кроме того, веб стремительно меняется — в ходу clientside MV* (angular, vue, polymer, etc), что конфликтует с изначальной идеей рельсового server-side MVC, и делает некоторую часть rails-boilerplate всё менее полезной. Например, хелпер-функции для пагинации, humanize, i18n — какой от них толк в динамическом ангуляре? Представьте, если они уже написаны и используются — у вас уйдет немало сил, чтобы убедить backend-команду, что это всё теперь нужно выбросить.
Но, надо отдать должное, руби (рельсы) — очень крутая экосистема. Сижу сейчас на Sequelize ORM (на node.js) и с большой тоской вспоминаю activerecord — тут рельсы вне конкуренции.
Последний ruby-разработчик, который нанимал меня на проект (я front-end разраб), сказал: «мы клиентский javascript пишем на coffee или на ES5, не хочу усложнять и добавлять в стек babel — он тормозит». Я подумал-подумал, и отказался.
Ну это так, частный случай. А вот общее наблюдение, которое случалось не один раз: проблема руби в том, что в руби всё идеально и «по линейке»! Но только до тех пор, пока ты в уютных рамках рельс. А «внешний мир» — он совсем не такой безоблачный, и мне, со своей колокольни, бывало очень сложно донести это руби-команде. Взять тот же snake_case, который чужд и в js, и в разметке, и в стилях. В ангуляре очень «здорово» такие поля_объектов иметь. И пробуй объясни, что это jbuilder должен отдавать вражеский camelCase. С названиями файлов та же ситуация.
Или вот, отсутствие фигурных скобок и табы — крутая идея. Только она не всегда хорошо работает. В sass есть проблемы с разбиением длинных строк. И порой, под возмущенные возгласы, приходилось коммитить старый добрый scss (точнее, новый добрый — потому что во всём остальном мире, кроме руби-сообщества, именно scss — стандарт!).
Кроме того, веб стремительно меняется — в ходу clientside MV* (angular, vue, polymer, etc), что конфликтует с изначальной идеей рельсового server-side MVC, и делает некоторую часть rails-boilerplate всё менее полезной. Например, хелпер-функции для пагинации, humanize, i18n — какой от них толк в динамическом ангуляре? Представьте, если они уже написаны и используются — у вас уйдет немало сил, чтобы убедить backend-команду, что это всё теперь нужно выбросить.
Но, надо отдать должное, руби (рельсы) — очень крутая экосистема. Сижу сейчас на Sequelize ORM (на node.js) и с большой тоской вспоминаю activerecord — тут рельсы вне конкуренции.
Правильные бэкенд разработчики будут рады выбросить humanize, i18n и что-бы фронтендеры сами с локализацией развлекались.
Про sass-scss тоже обобщение. Во всех проектах, где учавствовал, только scss использовали, про sass даже не обсуждали.
Про кэмлкейс — к языку не относится, в любом языке могут начаться холивары по стайлгайду. Кто-то бывает и на руби в кэмлкейсе пишет.
Я не веб-разработчик и использую в основном чистый ruby для шелл-скриптинга и chef/puppet. И знаете, нравится гораздо больше чем все остальное, чем python или bash. Гораздо удобнее, писать легко и лаконично что ли. Единственное что в нем не очень — скорость. Парсер данных, например для json-файла размером в гигов 20, на нем написать конечно легко и просто, но работает он раза в два (субъективно) медленнее чем тоже самое на Perl. Правда на Perl писать немного сложнее. Зато всякие cli утилиты на Ruby пишутся просто влёт, спасибо Rake, Thor и иже с ними.
И пробуй объясни, что это jbuilder должен отдавать вражеский camelCase.А кто мешает на фронте превращать при получении ответа все snake_case в camelCase, а при отправке запроса — camelCase в snake_case? Браузер, андроид, айос, виндовс фон, какие-то внешние системы — и каждый будет еще указывать беку, какой стайл-гайд для названий ему использовать.
Никто не мешает, просто jbuilder endpoint — он один и всегда в определенном месте, а entrypoint'ов в ангуляре — много (и они могут быть где угодно). Как-то из соображений естественности хочется, что водораздел был минимальной длинны, т.е. проходил по jbuilder'у.
Наличие того же ангуляра в стеке подразумевает, что куча кода написана именно на js-фронте. Почему бы API не быть в таком случае ангуляр-френдли.
Наличие того же ангуляра в стеке подразумевает, что куча кода написана именно на js-фронте. Почему бы API не быть в таком случае ангуляр-френдли.
Это типа шутка такая? В ангуляре есть интерcепторы, через них подобные штуки и делаются: обработка параметров перед отправкой запроса и после получения, обновление индикатора загрузки и тд. В итоге всего в двух местах нужно код написать. А в том же jbuilder, раз уж его упомянули — нужно в каждом описывать поля. Или, если с импортом jbuilder'ов друг в друга — то в одном на каждую сущность :)
Я интерсепторы не использовал (за намётку — спасибо), яжjsпрограммист — просто врапнул методы сервиса $http в свои.
Но как быть с полями форм? Ванильный сабмит ведь пойдет мимо интерсептора. Или нет?
Я в своём первом комментарии как раз об этом и говорил:
Другие стеки:
— Парни, нужен camelCase в json.
— Сильно нужен?
— Очень.
— Ок.
Rails:
— Парни, нужен camelCase в json.
— Это типа шутка такая?
Но как быть с полями форм? Ванильный сабмит ведь пойдет мимо интерсептора. Или нет?
Я в своём первом комментарии как раз об этом и говорил:
Другие стеки:
— Парни, нужен camelCase в json.
— Сильно нужен?
— Очень.
— Ок.
Rails:
— Парни, нужен camelCase в json.
— Это типа шутка такая?
Про шутку я писал в ответ на "а entrypoint'ов в ангуляре — много", а не на "нужен camelCase в json". Это почти самое первое, до чего доходит любой программист — повторяющийся код вынести и вызывать его по мере надобности, а не повторять его, как индус, которому платят за количество строк.
В остальном — как я уже писал, считаю, что бекенд должен диктовать правила. Просто потому, что он один, а разных клиентов под него — много. Но это истина лишь в первом приближении. В каждом конкретном случае могут быть особые требования или обстоятельства, из-за чего нужно будет делать по-другому.
В остальном — как я уже писал, считаю, что бекенд должен диктовать правила. Просто потому, что он один, а разных клиентов под него — много. Но это истина лишь в первом приближении. В каждом конкретном случае могут быть особые требования или обстоятельства, из-за чего нужно будет делать по-другому.
Лично я заочно не люблю Ruby (когда в глаза его не видел и не писал на нём) за что он отбирает фокус внимания разработчиков от моего любимого Python и способствует размыванию усилий сообщества, что опять же лично я считаю одним из главных зол в IT индустрии. Один язык, одна платформа, одна нация, один фюрер.
UFO just landed and posted this here
Показатели js, python и bash противоречат этому. Непонятно только, под магией что имеется в виду. Если магия рельс, то это не должно относится к языку. А так, огонь и затмения тоже когда-то считались магией.
Я бы назвал магией всё, что меняет базовую семантику языка или ожидаемое поведение стандартных классов. Например перекрытие арифметических операций, всякие __getattr__/__setattr__ в Питоне, метаклассы, манкипатчинг и т.п.
В принципе на Питоне тоже можно ничуть не хуже магию развести, но сообщество этого не одобрит. Среди вменяемых Питонистов магия считается крайним средством, обычно зарезервированным для матёрых разработчиков библиотек. Питонисты ценят читаемость и простоту кода.
На Руби я мало программировал, но у меня такое ощущение что у большинства Руби-программистов подход в духе: не боги горшки обжигают, я тоже магию могу. В сообществе ценятся элегантные компактные решения и хитрые хаки. Получается такой Перл-лайт (с более приятным синтаксисом, на мой вкус, но всё-же похожей культурой).
В итоге мы имеем весьма сходные языки, но сильно отличающиеся сообщества. Мне кажется Питонисты не одобряют культуру сообщества Руби а не язык как таковой.
В принципе на Питоне тоже можно ничуть не хуже магию развести, но сообщество этого не одобрит. Среди вменяемых Питонистов магия считается крайним средством, обычно зарезервированным для матёрых разработчиков библиотек. Питонисты ценят читаемость и простоту кода.
На Руби я мало программировал, но у меня такое ощущение что у большинства Руби-программистов подход в духе: не боги горшки обжигают, я тоже магию могу. В сообществе ценятся элегантные компактные решения и хитрые хаки. Получается такой Перл-лайт (с более приятным синтаксисом, на мой вкус, но всё-же похожей культурой).
В итоге мы имеем весьма сходные языки, но сильно отличающиеся сообщества. Мне кажется Питонисты не одобряют культуру сообщества Руби а не язык как таковой.
Без примеров мне сложно понять, что называют магией. Перегрузка операторов бывает полезна:
a = Money.new(1, 'usd')
b = Money.new(2, 'usd')
a + b
# не хуже, а может и лучше, чем
a.add(b)
# и, по мне, в разы лучше чем
import add from money.math
add(a, b)не боги горшки обжигают, я тоже магию могу. В сообществе ценятся элегантные компактные решения и хитрые хаки
Я с таким не сталкивался, наверное, мне повезло. Если есть примеры, поделитесь, пожалуйста.
PS. Плохие программисты могут писать на разных языках. Может быть, по ним не надо оценивать язык.
PPS. Я изначально обратил внимание только на то, что другие языки с указанными особенностями получили меньше негатива. Т.е. это негатив — не от этих особенностей. Немного подробнее написал в другом комментарии: https://habrahabr.ru/post/341516/#comment_10503278
Да, в вашем примере это хорошая перегрузка, от которой код становится более читабельным и понятным. Более спорна перегрузка >> и << для складывания чего-нибудь в контейнер или очередь. А вот перегрузить + для добавления узла (или поддерева) в дерево — это уже весьма спорно, так как операция некоммутативна, а обычно + должен быть коммутативен (хотя конечно есть + для некоммутативной конкатенации строк, но к нему все уже более-менее привыкли).
Реальных примеров сильно грязных хаков я сходу привести не могу, но я точно видел плагинные системы на Руби (да наверно и на Питоне), полностью основанные на манки-патчинге. Вы правильно заметили что плохие программисты могут писать (и пишут) плохой код на любом языке, но мне кажется у Питонщиков более принято бить по рукам за всякие заумные решения. Не то чтобы это всегда помогает, но из-за этого некоторым кажется что Питонщики такие все правильные и аккуратные в то время как на Руби везде сплошной манкипатчинг и магия.
С вашим другим комментарием я в основном согласен, кроме пожалуй частей про преимущества Руби перед другими языками. По-моему в плане самого языка Питон и Руби мало отличаются и если выбирать язык для проекта скорее имело бы смысл смотреть на доступные библиотеки и опыт команды. А если анализировать негатив и его причины — я думаю тут дело вообще не в языке, а в том как программисты из этих сообществ воспринимают друг друга. Это скорее социологический вопрос чем программистский.
Реальных примеров сильно грязных хаков я сходу привести не могу, но я точно видел плагинные системы на Руби (да наверно и на Питоне), полностью основанные на манки-патчинге. Вы правильно заметили что плохие программисты могут писать (и пишут) плохой код на любом языке, но мне кажется у Питонщиков более принято бить по рукам за всякие заумные решения. Не то чтобы это всегда помогает, но из-за этого некоторым кажется что Питонщики такие все правильные и аккуратные в то время как на Руби везде сплошной манкипатчинг и магия.
С вашим другим комментарием я в основном согласен, кроме пожалуй частей про преимущества Руби перед другими языками. По-моему в плане самого языка Питон и Руби мало отличаются и если выбирать язык для проекта скорее имело бы смысл смотреть на доступные библиотеки и опыт команды. А если анализировать негатив и его причины — я думаю тут дело вообще не в языке, а в том как программисты из этих сообществ воспринимают друг друга. Это скорее социологический вопрос чем программистский.
Вот тут коллеги как раз подкинули пример забавной Руби-магии. Импортируем модуль из стандартной библиотеки и математика во всём интерпретаторе начинает работать иначе.
https://github.com/ruby/mathn:
Deprecated library that extends math operations.
Вот пример из доки, тут лучше особенность показана:
# Without mathn:
#
# 20 / 9 * 3 * 14 / 7 * 3 / 2 # => 18
#
# With mathn:
#
# 20 / 9 * 3 * 14 / 7 * 3 / 2 # => 20Библиотека для специфичной аудитории, видимо. Для тех, кому нужно решать математические задачи, не задумываясь о том, что у программистов есть какие-то там integer (3/2 = 1).
Понятно что библиотека маргинальная, и что все поняли что это была плохая идея (надо было ввести новый тип с другим поведением вместо того чтобы менять поведение обычных чисел). Тем не менее, сам факт что такой модуль смог попасть в стандартную библиотеку говорит о том, что в какой-то момент многие считали что это ок. И уже не так важно что больше они так не считают, историю растащили по Твиттерам и теперь куча людей думает что почти все программисты на Руби невменяемы.
$ man irb
...
-m Bc mode (load mathn, fraction or matrix are available)
# С других источников:
Sets bc mode [...]
See Command line options at IRB and the unix manpage bc(1) for more information.
$ man bc
bc - An arbitrary precision calculator languageТ.е. это модуль, который делает bc из руби. 100 строчек чтобы эмулировать в руби другой язык.
Почему он в stdlib? Мне кажется, он очень похож "private" модуль для такого режима, который никто не должен реквайрить в обычных приложениях. Но если очень хочется, то можно, как и private метод вызвать, только вся ответственность уже на разработчике, который это использует.
О, то есть получается этот модуль вообще никому никогда не предлагали импортировать в нормальные приложения, и чуваки в твиттере либо не в теме либо специально FUD распускают. Вот так и возникают легенды про «другие языки, где всё ужасно».
Не исключено, что моя выборка Руби-проектов и Руби-программистов была нерепрезентативна, и моё убеждение про то, что в сообществе Руби больше одобряют магию и хитрые хаки, а в сообществе Питона больше заботятся о читаемости текста, не соответствует действительности. А вам, на основании вашего опыта, как кажется?
Не исключено, что моя выборка Руби-проектов и Руби-программистов была нерепрезентативна, и моё убеждение про то, что в сообществе Руби больше одобряют магию и хитрые хаки, а в сообществе Питона больше заботятся о читаемости текста, не соответствует действительности. А вам, на основании вашего опыта, как кажется?
О, то есть получается...
¯\_(ツ)_/¯
Я видел много плохого руби кода, но никогда повсеместного неправильного применения метапрограммирования, оверрайдов и тд. Основные причины, почему он был плохим — люди, писавшие его:
- не имели базовых знаний computer science,
- пытались применять подходы из других языков,
- просто не изучили или не поняли язык и инструменты.
Эти причины определены не языком, я видел такой код и в крупных проектах на других языках. Конечно, где таких программистов больше, там и вероятность встретить плохой код выше. Судя по всему, порог вхождения у руби ниже, и это является причиной.
в сообществе Питона больше заботятся о читаемости текста
Недавно делал несколько моделей для TensorFlow, в некоторых официальных примерах организация кода не очень удачно выполнена.
Касательно Python, по-моему, большое колличество особенных методов вида __len__ — это более магически. Даже их вид настораживает. При этом их необходимо использовать, чтобы пользоваться основными конструкциями языка. Мне особенно не нравится with с __enter__ и __exit__. Были бы многострочные лямбды, было бы лучше, наврное:
Заголовок спойлера
Дисклэймер! Я не гуру питона, может все не так надо делать :)
class Pool:
def __enter__(self):
# Нельзя передать аргументы :(
connection = self.checkout()
return connection
def __exit__(self, тут, какие-то, аргументы, еще, надо, знать):
if need_to_check_always:
self.checkin(one_of_args)
# return? неееет
value = None
with pool as connection:
prepare_something
value = connection.get('some')vs
class Pool
def with(timeout)
connection = checkout(timeout: timeout)
begin
yield connection
ensure
checkin(connection)
end
end
end
value = pool.with do |connection|
prepare_something
connection.get('some')
endА такое в питоне я знаю как сделать только, определяя локальную функцию, чтобы ее просто обернуть в лямбду:
class Logger
def with_level(new_level)
old_level = level
self.level = new_level
yield
ensure
self.level = old_level
flush
end
end
logger.with_level(:debug) do
something
more
end
logger.with_level(:error) do
again
and_again
endНо это не претензии к языку, просто наблюдение. Каждый пишет на чем хочет.
Не очень понял какой будет ответ на мой вопрос из предыдущего комментария, посчитаю что вам не кажется что вменяемые программисты на Руби, которые хорошо знают язык лучше относятся к магии чем их Питон-эквиваленты. Это хорошо, проапдейчусь в сторону меньшей разницы в одобрении магии между сообществами.
Методы типа __len__ — почти все магия (кроме разве что __init__). Лучше их не трогать если нет на то серьёзных причин. Конкретно __len__ нужен если реализуешь что-то типа коллекции и не можешь понаследоваться от чего-то, у чего уже есть __len__. Мне кажется что специальный вид магических методов оправдан — сразу всем видно что это не простые методы.
Ваш пример с пулингом соединений — в общем-то нормальный юзкейс для __enter__/__exit__, но реализация в вашем примере слегка против шерсти Питона. Пожалуй самый удобный способ это сделать пожалуй через декоратор contextlib.contextmanager (в этом случае мы сами магии не делаем а используем заготовки из стандартной библиотеки):
Пример с временным переключением уровня логирования мне кажется более спорным. Аналогичное решение с контекст-менеджерами на Питоне было бы, на мой вкус, слишком магично для обычного приложения и слишком не threadsafe для библиотеки. Как сделать лучше сходу не знаю, так как я не очень понимаю мотивацию этого примера.
Да, этого не хватает, было бы здорово.
Касательно Python, по-моему, большое колличество особенных методов вида __len__ — это более магически. Даже их вид настораживает. При этом их необходимо использовать, чтобы пользоваться основными конструкциями языка.
Методы типа __len__ — почти все магия (кроме разве что __init__). Лучше их не трогать если нет на то серьёзных причин. Конкретно __len__ нужен если реализуешь что-то типа коллекции и не можешь понаследоваться от чего-то, у чего уже есть __len__. Мне кажется что специальный вид магических методов оправдан — сразу всем видно что это не простые методы.
Мне особенно не нравится with с __enter__ и __exit__.
Ваш пример с пулингом соединений — в общем-то нормальный юзкейс для __enter__/__exit__, но реализация в вашем примере слегка против шерсти Питона. Пожалуй самый удобный способ это сделать пожалуй через декоратор contextlib.contextmanager (в этом случае мы сами магии не делаем а используем заготовки из стандартной библиотеки):
import contextlib
class Pool:
@contextlib.contextmanager
def get_connection(self, timeout):
connection = self._check_out(timeout)
try:
yield connection
finally:
self._check_in(connection)
with pool.get_connection(42) as connection:
connection.get('some')
Пример с временным переключением уровня логирования мне кажется более спорным. Аналогичное решение с контекст-менеджерами на Питоне было бы, на мой вкус, слишком магично для обычного приложения и слишком не threadsafe для библиотеки. Как сделать лучше сходу не знаю, так как я не очень понимаю мотивацию этого примера.
Были бы многострочные лямбды, было бы лучше, наврное
Да, этого не хватает, было бы здорово.
Логгер — абстрактный пример, пусть будет 1 инстанс на тред :) С contextmanager все ок получается.
contextmanager пробовал, забыл про него. Для меня это еще 1 минус языка — чтобы не добавлять многострочные лямбды, добавили сомнительную конструкцию языка и к ней костыль. Во мне негодует Оккам. Возвращать значения из with все равно нельзя вроде, поэтому мне этот способ не подошел в реальной ситуации.
Не очень понял какой будет ответ на мой вопрос
В руби тоже о читаемости заботятся, плохие хаки не одобряют. Хорошие применяют когда требуется и все это документируют.
Если "магия" — это просто нечто мощное, то почему нужно отказываться от этого, если кто-то этого не понимает. Когда я начинал писать на руби, для меня многое было удивительным, но под капотом все оказывалось очень простым. Для этого не обязательно читать исходники интерпретатора — все есть в документации и другом коде на руби. Многие руби программисты и через несколько лет не понимают, что на самом деле делает конструкция, которую они используют постоянно — им просто не интересно или не хочется разобраться. Для них это остается магией.
Вместо магии я вижу средства, которыми нужно уметь пользоваться, и понимать, когда их нужно использовать, а когда нужно обойтись без них.
contextmanager пробовал, забыл про него. Для меня это еще 1 минус языка — чтобы не добавлять многострочные лямбды, добавили сомнительную конструкцию языка и к ней костыль. Во мне негодует Оккам. Возвращать значения из with все равно нельзя вроде, поэтому мне этот способ не подошел в реальной ситуации.
Контекст менеджеры не являются заменой многострочных лямбд. Понятно что с помощью многострочных лямбд можно сделать что-то похожее, и это даже в некотором смысле элегантно, но контекст менеджеры — это менее универсальное и более простое решение только одной конкретное проблемы, а не всего что можно делать лямбдами. Ну и ещё Питонисты слишком подозрительно относятся к функциональному программированию, чтобы вместо контекст менеджеров использовать многострочные лямбды. Это конечно жаль что они не любят функпрог больше, но Питон был бы совсем другим, если бы он пошёл навстречу функциональным техникам и скорее всего потерялась бы часть простоты и читаемости, а это для Питона важнее.
Кстати, если негодует Оккам, надо пописать на Лиспе и обычно отпускает (не всегда правда отпускает, но это тоже ок :).
Добавлю, что язык и его инструменты изучать во многом проще чем другие. Для того чтобы посмотреть код модуля/метода, список методов объекта и, какие из какого модуля добавлены, не нужно никаких IDE — есть библиотека pry, написанная на руби. Похожего для других языков я не встречал.
Для того чтобы посмотреть код модуля/метода, список методов объекта и, какие из какого модуля добавлены, не нужно никаких IDE — есть библиотека pry, написанная на руби. Похожего для других языков я не встречал.
В большинстве ООП языков добавление методов в чужие классы считается хаком и не поощряется (а иногда и вообще невозможно). Потому что инкапсуляция от этого ломается. Если в Руби это обычная практика, то это довольно сильное отличие от ООП мэйнстрима.
https://ruby-doc.org/core/Enumerable.html для примера. Если класс предоставляет метод each, то include Enumerable добавит filter, find, inject/reduce, .... Это не кто-то посторонний делает, а автор класса: метод include — private.
Еще я не точно выразился: не только модули покажет, но и суперклассы, и в каком какой метод определен.
А, ну это mixin, это более мэйнстрим, хотя джависты наверно тоже не одобряют :)
Миксин миксину рознь. Там, где миксин внедряется в класс явно внутри этого класса, то нормально смотрится и поддерживается. А если в какой-то бустрап или, ещё хуже, бизнес-логике, да не локально, то жить с этим очень сложно.
Согласен. Я говорил про миксины, от которых класс просто наследуется. А прикручивание стороннего миксина на ходу из другого модуля по-моему не очень сильно отличается от манки-питчинга — мне не сильно легче от того что пять сторонних методов, которые неизвестно откуда оказались в моём классе, оказывается все пришли из одного класса.
С другой стороны, в некоторых языках вброс методов, или конструкции, на него похожие, выглядит довольно естественно. Например реализация трэйтов для чужих структур данных в Расте имеет что-то общее с вставкой методов в чужой класс. Но разработчики Раста защитились от хаоса: во-первых там нельзя реализовывать чужие трэйты для чужих типов (можно только реализовывать свой трэйт для чужого типа или чужой трэйт для своего типа), так как это редко нужно и приводит к проблемам, а во-вторых строгий компилятор со строгой системой типов сильно сужает возможности прострелить себе ногу. Ну и конечно Раст вообще не особо ООП язык и трэйты больше похожи на тайп-классы из Хаскеля.
С другой стороны, в некоторых языках вброс методов, или конструкции, на него похожие, выглядит довольно естественно. Например реализация трэйтов для чужих структур данных в Расте имеет что-то общее с вставкой методов в чужой класс. Но разработчики Раста защитились от хаоса: во-первых там нельзя реализовывать чужие трэйты для чужих типов (можно только реализовывать свой трэйт для чужого типа или чужой трэйт для своего типа), так как это редко нужно и приводит к проблемам, а во-вторых строгий компилятор со строгой системой типов сильно сужает возможности прострелить себе ногу. Ну и конечно Раст вообще не особо ООП язык и трэйты больше похожи на тайп-классы из Хаскеля.
Что это за приложения, которые необходимо написать быстро, причем выбирать для этого руби? Лично я на коленке леплю скрипты на PHP, если мне нужно, например, быстро скачать все видосы из плейлиста на ютубе, передать показания счетчиков в мою УК (да и вообще что-либо передать куда-либо) и так далее. А что еще может быть написано на коленке, плюс на руби? Может быть редактор БД, так, одноразовый, под конкретную задачу :D
Жаль, что ответа я не получу, а ведь я без всякого подвоха спрашивал…
Если не брать личные поделки, то прототипы для демонстрации идей каких-то инвесторам, например. Одно время даже практиковал демонстрации на рельсах априори зная, что их в продакшен не пустят, а если одобрят, то на PHP перепишу. Перестал после одного сильного конфликта, когда мне сказали прототип немного допилить и в продакшен прямо на рельсах, а я заявил, что только через мой труп если наймут спецов по рельсам, которые это поддерживать будут — и разработчиков, и админов.
Вот это другое дело, а-то как минусы, дак пожалуйста, а ответа не дождаться (хоть какого, даже не обязательно дельного). Уже даже привык к такому поведению аудитории на Хабре, но все-равно как-то вымораживает. Напоминает как в школе если кто-то что-то спрашивает у учителя что ему не понятно, дак по всему классу начинается сдавленный смех, как-будто бы человек… не знаю, снял штаны перед всеми. Вот и собралась аудитория, эдакий виварий с комплексами из детства, которые пытаются отыграться за все во взрослой жизни. Говорю, потому-что кто-то должен это говорить.
А что означает «на PHP перепишу, если одобрят»?) По мне дак PHP идеально подходит и для «хоп-хоп и в продакшн», и для сложных проектов полного цикла. У себя на работе пишу сложный проект с агиле и тестами, а дома в качестве свистелок коленочные скрипты для всего и вся. Что-то на курле написать, на крон подвесить и пусть стартует и что-то делает раз в час, красота же. Сам уже даже не помню сколько у меня на серваке таких скриптов крутится, что-то парсят, присылают на почту результаты. Да, возможно курла довольно многословна, не буду отрицать, ибо полностью гибкая, но можно же для нее обвертку небольшую написать, а не хочется если тащить ее за собой и иметь полностью автономные скрипты — можно копировать ее откуда-нибудь каждый раз. И самое главное — что он некомпилируемый, написал-запустил. Не знаю насчет рельсов. А в компилируемых подрпавил строку и сиди жди компиляции, понятно что на это может полминуты-минута уходит, но все-равно такие простои вынужденные снижают продуктивность.
А что означает «на PHP перепишу, если одобрят»?) По мне дак PHP идеально подходит и для «хоп-хоп и в продакшн», и для сложных проектов полного цикла. У себя на работе пишу сложный проект с агиле и тестами, а дома в качестве свистелок коленочные скрипты для всего и вся. Что-то на курле написать, на крон подвесить и пусть стартует и что-то делает раз в час, красота же. Сам уже даже не помню сколько у меня на серваке таких скриптов крутится, что-то парсят, присылают на почту результаты. Да, возможно курла довольно многословна, не буду отрицать, ибо полностью гибкая, но можно же для нее обвертку небольшую написать, а не хочется если тащить ее за собой и иметь полностью автономные скрипты — можно копировать ее откуда-нибудь каждый раз. И самое главное — что он некомпилируемый, написал-запустил. Не знаю насчет рельсов. А в компилируемых подрпавил строку и сиди жди компиляции, понятно что на это может полминуты-минута уходит, но все-равно такие простои вынужденные снижают продуктивность.
Уже даже привык к такому поведению аудитории на Хабре, но все-равно как-то вымораживает
…
Что это за приложения, которые необходимо написать быстро, причем выбирать для этого руби? Лично я на коленке леплю скрипты на PHP
А что вам на это отвечать? Выглядит как субъективное мнение без обоснований, за это минус. Кто-то точно так же напишет, что он на ноде эти задачи сделает, и не возьмет пхп. Пусть пишет, но это не к чему знать всем остальным.
Вы на руби писали? Много писали? В языке разобрались? Если да, то пишите по существу — чем он плох, почему вы вместо него выбираете пхп.
Подождите-ка, вопрос «Что это за приложения, которые необходимо написать быстро, причем выбирать для этого руби?» — это субъективное мнение? По-моему вполне дельный вопрос, на который возможен ответ из разряда «ну руби имеет больше встроенных библиотек, чище код, более быстрая работа, и т. д. (как варианты)», ни так ли? Если уж на то пошло, то почему лично я выбираю PHP я обосновал ниже более чем. Для того, наверное, вопросы и задаются более опытным, чтобы менее опытные в этой области могли сразу понять нужно ли это или нет, а не гуглить часами стек технологий, который в конечном итоге им может быть даже не понадобится. Не для этого существуют Тостеры, SO и тому подобные ресурсы? Да тот же Хабр. А уж если вдруг с каких-то пор комменты на нем вдруг перестали быть предназначенными для коротких ответов на короткие вопросы, то это тоже можно объяснить в тех же комментах. Поэтому и объясняю я такую реакцию пока только так, увы(
Я выше тоже писал, чем хорош руби по-моему: https://habrahabr.ru/post/341516/#comment_10503278. Интересное обсуждение с несколькими хорошими примерами было в этой ветке: https://habrahabr.ru/post/341516/#comment_10509174.
Что это за приложения...
По-мне, звучит как "нет таких приложений, для которых руби подошел лучше, чем рнр", не очень похоже на вопрос, заданный с интересом.
Не знаю насчет рельсов
Если действительно интересно, то сначала изучите то, что хотите критиковать (например: http://guides.rubyonrails.org/, https://www.ruby-lang.org/en/documentation/quickstart/).
Касательно вашего вопроса: все, что вы перечислили, можно написать на руби.
Но ведь это чистой воды домысливание. Я специально еще в самом начале написал, что «я без всякого подвоха спрашивал», рассказал что умеет PHP, мол, вот я на PHP такое делаю, а чем так хорош руби, что его используют для такого рода поделок вместо PHP, и так далее. Мне казалось это очевидно. В недавней статье вскользь прошла мысль, что люди не умеют читать, и читают то что написано у них в голове (если вкратце, то человек рассказывал о своей прошлой работе в Яндексе, и высказал такую мысль дабы пресечь попытки обвинить его в том, что он воткнул нож в спину бывшего работодателя). Еще тогда подумал, надо же, как интересно подмечено. И ведь понимаю: сущая правда же. Только почему только на Хабре? Вроде бы ресурс для айтишников, умные люди и все такое, но нет…
Что это за приложения, которые необходимо написать быстро, причем выбирать для этого руби? Лично я на коленке леплю скрипты на PHP
Специально не отвечал вечером, т.к. думал что с утра перечитаю эти фразы по-другому, как-будто вопрос с интересом написан. Но нет… :)
Извините, если я вправду неправильно её прочитал и все домыслил. Серьезно. Но на вопрос ответил уже.
Да, за ответ и за ссылки благодарю, собссно, ради чего весь сыр-бор и затевался. И отдельное спасибо за извинения, это дорогого стоит. Вы не поверите, но в таких ситуациях я оказываюсь время от времени. Чаще собеседники извиняются, и это не может не радовать, однако количество таких случаев все же удручает. И хорошо при этом если удается разойтись полюбовно, но тут все зависит от характера собеседника, бывает всякое. Самое худшее — это когда человек даже осознает что неправ, но всеми силами пытается выглядеть крутым в своих глазах и глазах окружающих, причем чаще окружающие с ним солидарны. Я много где сижу, но с таким сталкиваюсь только на Хабре. Даже недавно в очередном комменте (там эта проблема решилась спокойно, без поножовщины, но все же она имела место быть) сформулировал идею о том, что это, возможно, связано с большим объемом поступающей информации, которую мозг затрудняется обрабатывать подобно тому, как процессор в нагрузке пропускает такты. Возможно звучит логично, но все-равно не понятно: я такой же программер как и большинство аудитории тут, у меня так же имеется основная работа и проекты для души, я стараюсь максимально точно формулировать мысли, но самое смешное то, что неправы в большинстве случаев оказываются собеседники, но виноват в их глазах я. Мистика да и только!
А что означает «на PHP перепишу, если одобрят»?) По мне дак PHP идеально подходит и для «хоп-хоп и в продакшн», и для сложных проектов полного цикла.
То и значит, что на рельсах в стиле «хоп-хоп и в продакшндемо», а на PHP "для сложных проектов полного цикла". Просто если написать по быстрому демо на PHP и дальнейшую разработку одобрят, то не дадут, по личной практике, выкинуть "хоп-хоп" код
Ох, и снова приветствую) Ах наоборот! Дак это другое дело. Но я как раз и не могу понять чем PHP не подходит конкретно для «хоп-хоп» «по быстрому»? Если, например, дырявость и некое побуждение писать плохой код, то тогда как он может годиться «для сложных проектов полного цикла»? По мне, как я говорил выше, он подходит и «для сложных проектов полного цикла», и для «по быстрому» благодаря своей динамической типизации, что позволяет держать в голове парадигму и реализовывать ее не отвлекаясь на мишуру к приведению всего и ко всему. И ладно, как это часто бывает в случае нелюбви к PHP, как раз эта самая динамическая типизация и ставит на нем крест в области «для сложных проектов полного цикла». Но тут я вдруг узнаю, что именно для этого он в финале и используется. На мой взгляд тут все еще имеется явное противоречие. Или причина тут все-так в другом?
Да подходит в целом PHP для "хоп-хоп" проектов, часто как раз для таких его и используют. Тут чистой воды психология — демо надо написать быстро, гибкую архитектуру выстраивать, на слои делить и даже обработку ошибок делать некогда. А если дальнейшую разработку утвердят, то с большой вероятностью не дадут начать этот полный цикл с чистого листа, убедят дописывать то, что есть, причём будут ожидать той же скорости примерно. А так говоришь: "это не тот язык, что согласовали для продакшена, это сугубо демонстрация"
UFO just landed and posted this here
да фиг его знает.
Чем живет PHP — понятно. Самый очевидный выбор, много готовых CMS, много фреймов, много готовых решений для малого и среднего коммерса. Это никуда не уйдет.
Чем живет Python — понятно. Один из самых простых языков для изучения, язык общего назначения, тестирование, devops, веб, дата-анализ. Мб. в каждом из направлений не так много людей, но в куче набегает порядком.
Ruby — Да у него прикольная парадигма разработки, и весьма удобный веб-фреймворк. Но какого-то очевидного преимущества над Php/Python — он не имеет. Поэтому и видим тенденцию, что после хайпа, он начал сходить на нет.
Чем живет PHP — понятно. Самый очевидный выбор, много готовых CMS, много фреймов, много готовых решений для малого и среднего коммерса. Это никуда не уйдет.
Чем живет Python — понятно. Один из самых простых языков для изучения, язык общего назначения, тестирование, devops, веб, дата-анализ. Мб. в каждом из направлений не так много людей, но в куче набегает порядком.
Ruby — Да у него прикольная парадигма разработки, и весьма удобный веб-фреймворк. Но какого-то очевидного преимущества над Php/Python — он не имеет. Поэтому и видим тенденцию, что после хайпа, он начал сходить на нет.
Да просто руби такое авно как и похапэ.
По статье сразу видно, что автор писал на python/R =)
Я вообще тащусь с подобных тем. Не непосредственно с данного поста, а вообще с холиваров «нравится/не нравится язык программирования». Ниразу не видел спора на тему «мне молоток нравится больше, чем микроскоп». Особенно, если учесть, что одним и тем-же разработчиком порой в одном и том-же проекте приходится пользоваться и тем и другим.
Одно дело когда ты выбираешь, что ты ХОЧЕШЬ использовать, и другое, когда ПРИХОДИТСЯ пользоваться.
UFO just landed and posted this here
) хорошая аналогия, мне понравилась.
Но даже для таких случаев можно углубиться в особенности языка и его окружения, чтобы определиться насколько он подходит/не подходит для решения задачи. Ну может, разве что за исключением Java-клонов, которые на мой (не спорю) неискушенный взгляд отличаются совсем немного синтаксисом и сортами синтаксического сахара.
Но даже для таких случаев можно углубиться в особенности языка и его окружения, чтобы определиться насколько он подходит/не подходит для решения задачи. Ну может, разве что за исключением Java-клонов, которые на мой (не спорю) неискушенный взгляд отличаются совсем немного синтаксисом и сортами синтаксического сахара.
Какой-то размазанный анализ по всем языкам, эффективней было бы разделить их на группы по общим направлениям. Хотя выделить язык в какую-то определённую группу тоже не всегда очевидно, но собирать «среднюю по больнице» смысла несёт ещё меньше.
А вот сеть с полярными тегами очень занимательная вышла.
А вот сеть с полярными тегами очень занимательная вышла.
Любопытно, что backend хейтит frontend больше чем frontend — backend
и (к моему удивлению) R против SAS
че там удивляться. SAS махровый мамонт из 70-х, все кто на нем пишут, не любят все новое, типа R. Ну и алаверды.
p.s. Это я вам сам как мамонт знающий SAS говорю.
Просто хипстерам пригорает, вот они и прут дизлайкать старичков. А тем кто пишет рабочие продукты на старичках, не досух ходить дизлайкать хипстерские языки.
Ну а сравнение в одном ряду (выше): C# vs Delphi и C++ vs Rust только подтверждает это.
Ну а сравнение в одном ряду (выше): C# vs Delphi и C++ vs Rust только подтверждает это.
UFO just landed and posted this here
Дело в разном «профиле» использования тех или иных яп. Большинство программирующих на каком-нибудь delphi в основном занимаются поддержкой старых проектов и приятного в этом мало. Новые языки (скажем, rust/go) всегда привлекали оптимистичных энтузиастов. Однако молодые инфраструктуры этих языков ставят под сомнение коммерческую выгоду их использования в новых крупных проектах: специалисты на них в среднем менее опытные, дорогие и меньше представлены на рынке.
Дело не в профиле, а в проблеме курицы и яйца. Пока никто не платит за работу с новой технологией, никто не рвется изучать технологию. Так всегда было и всегда будет.
судя по Salary and Experience by Language (2017) rust/go/clojure предлагают самое высокое соотношение зп/стаж. А вот с точки зрения работодателя выгоднее яп с самым низким соотношением.
Самое высокое — самое высокое. А я говорю о количестве спроса. Пусть там 1-2 компании платят хоть миллиард. А надо, чтобы платили много и вакансий было много. Хоть это и не очевидно, но я именно это имел ввиду. На hh сложно найти вакансии на Rust, например. Даже так, именно по Rust вообще ни одной не видел за прошедший год, было лишь «если у вас опыт на rust/go/scala, это очень большой плюс», а вакансия в итоге все равно какая-нибудь плюсовая. В итоге имеем вакансии только на плюсах, поэтому и изучать смысла особо пока rust нет, если хочешь его применять именно при устройстве на работу. А если уже работаешь и разрешается че-нить такое делать, то люди и в исследовательских целях и в реально нужных используют rust, и много кто так уже делает даже в россии (из крутых — касперский, яндекс, mail.ru — это точно).
А мне Pascal нравится. За 11 лет работы, много всяких вкусностей создал для работодателей и для себя лично. И главное — быстро, просто и понятно.
Для себя написал пару программулек на Lazarus. Конечно догадываюсь почему Delphi попала в немилость. Основная причина-не кроссплатформенность.
Скорее цена лицензии. Кроссплатформенность-то уже имеется: Linux, OS X, iOS и Android.
Delphi попала в немилость только по причине стратегических\маркетинговых ошибок компании Borland (включая сюда появление C# и .net, в первую очередь, как ни странно).
Делфи уже как бы давно кроосс-платформенный :)
А на каких языках вы еще пишите, что вам Pascal нравится?
UFO just landed and posted this here
Для меня Delphi лучше, чем C++ Главное — как реализовываешь программу…
А для меня одного из проектов в моём отделе — VBA :)
И я спокойно на нём пишу, когда надо.
И я спокойно на нём пишу, когда надо.
Для разгона вентилятора было бы неплохо дополнить перевод альтернативным голосованием для пользователей хабра =)
UFO just landed and posted this here
Майкрософт прямо монополист в сфере ненавистных технологий.
Даже вернулся перечитал список, МС там не особо представлен :)
в списке «самых нелюбимых тэгов» один — microsoft, и еще 11 из 20 — технологии microsoft
internet-explorer
visual-basic
asp-classic
microsoft
webforms
vb6
asp
sharepoint
ms-access
iis
vbscript
Это всё тэги так или иначе относящиеся к microsoft.
Справедливости ради надо сказать, что половина там — это старые технологии(vb, asp, webforms).
visual-basic
asp-classic
microsoft
webforms
vb6
asp
sharepoint
ms-access
iis
vbscript
Это всё тэги так или иначе относящиеся к microsoft.
Справедливости ради надо сказать, что половина там — это старые технологии(vb, asp, webforms).
UFO just landed and posted this here
VBA незаменим
А как же .NET?
UFO just landed and posted this here
В некотором приближении это те же яйца, только со всей мощью .NET
Не объективно совсем, если сравнивать количество разработчиков в каждом языке. Ясен пень что на R пишут единицы, а PHP ненавидит большинство.
P.S. Perl вообще жив?
P.S. Perl вообще жив?
В Америке еще лет 15 назад, небыло ни одной вакансии на дельфи. Тут в опросе явно наши постарались.
Странно что нет моего любимого языка c++ builder. Это язык на котором я пишу для себя. К сожалению
Интересно, а в статистике учитывается количество голосовавших?
к примеру сообщество (а соответственно и ненавистников) php которому уже больше 20 лет гораздо больше, чем у swift.
По критерию количества ненавистников естесственно в топ попадут наиболее старые языки.Не все правда старые языки настолько ненавистны, но вот по новым языкам выборка 100% не репрезентативна.
к примеру сообщество (а соответственно и ненавистников) php которому уже больше 20 лет гораздо больше, чем у swift.
По критерию количества ненавистников естесственно в топ попадут наиболее старые языки.Не все правда старые языки настолько ненавистны, но вот по новым языкам выборка 100% не репрезентативна.
Писал на множестве языков, не люблю regexp (да, да "ниасилил"). Люблю SQL но терпеть не могу его реализацию T-SQL. Все остальные хороши по-своему.
Чем реализация T-SQL не угодила? И чем она принципиально хуже других реализаций: PL/SQL, MySQL? Там тоже огромное количество дополнительных команд.
Нет for select например
Правильней сказать, что синтаксис курсора несколько иной:
MS SQL, Oracle, PostgreSQL
В Firebird/Interbase, например, не нужно вообще явно курсор объявлять
https://firebirdsql.org/refdocs/langrefupd21-psql-forselect.html
Ну, да… А на функционал это как-то влияет?
Как-то влияет, но я именно про язык, про синтаксис и семантику. Понятно что можно и на SQL машину Тьюринга написать
Мне порой кажется, что regexp и стал причиной появления brainfuck :)
Немного неожиданно в самых не любимых тегах среди всяких монументальных вещей видеть банальную ЦМСку joomla. Хотя не скажу что я их не понимаю, скорее наоборот, у меня самого от джумлы до сих пор прямо вьетнамские флешбеки.
Странно, что у Жабы так мало хейтеров. )
По моим ощущениям ей как раз место в том разрыве между VBА и PHP.
Видимо сказывается то, что адептов она хорошо кормит, а прочие с ней редко сталкиваются.
По моим ощущениям ей как раз место в том разрыве между VBА и PHP.
Видимо сказывается то, что адептов она хорошо кормит, а прочие с ней редко сталкиваются.
Так тут ещё 1С-ники не прибегали…
Два года назад сделал ставку 100$, что в течении 5-ти лет R обгонит Python по популярности и использованию. Спасибо за графики — пока R идет в нужным темпом :)
Оценивать язык используя сайты для поиска работы и тому подобное — в принципе не правильно. Бизнес — это не программирование. Суть языка программирования в том, чтобы написать на нём код. Суть бизнеса — сделать это за наименьшее время, не используя копилефтные штучки. То есть на вот эти графики в статье сильно влияет наличие разнообразных библиотек, фреймворков и т.п., хотя по сути эти вещи к языку не относятся. Равно как и понятия о его «устаревшести» или «зелёности». Лучше смотреть на код, и на языки программирования вообще так, как если ты просто берёшь, и пишешь. Не оценивая объём поддержки от сообщества, рыночную сумму оплаты и прочее. Вот тогда будет честная оценка. Delphi будет отталкивать людей чуть больше чем python или rust, но точно не окажется на самом дне, как здесь — он же вполне последовательный и читабельный, и даже однозначно компилируется (в отличие от некоторых куда менее ненавистных...).
Тоже самое с технологиями. Я просто не способен понять людей которым нравится Linux, когда существует, например, Visual Studio… Как будто часть программистов волевым решением внезапно позабыла об изобретении Gui и ушла назад в прошлое, когда компьютер не предполагался как нечто, что должно взаиводействовать с человеком, и приходилось программмировать дыроколом на непрозрачных пластинках… Да, это можно — писать программы дыроколом, или делать всё через консоль — но зачем, когда уже кем-то придуманы и операционная система, и иде и многое другое? Честнее надо быть с самими собой.
Да, если что мои личные полюса:
+ Python, Julia, Rust; — Haxe, c/c++ (хоть и приходится с ними более всего работать)
+ W10/XP; — Dos, Linux
Тоже самое с технологиями. Я просто не способен понять людей которым нравится Linux, когда существует, например, Visual Studio… Как будто часть программистов волевым решением внезапно позабыла об изобретении Gui и ушла назад в прошлое, когда компьютер не предполагался как нечто, что должно взаиводействовать с человеком, и приходилось программмировать дыроколом на непрозрачных пластинках… Да, это можно — писать программы дыроколом, или делать всё через консоль — но зачем, когда уже кем-то придуманы и операционная система, и иде и многое другое? Честнее надо быть с самими собой.
Да, если что мои личные полюса:
+ Python, Julia, Rust; — Haxe, c/c++ (хоть и приходится с ними более всего работать)
+ W10/XP; — Dos, Linux
Не все можно собрать на Винде. Например, когда делаешь какую-то бекенд штуку, сильно завязанную на linux-экосистему, то либо мак, либо линукс нужен.
У вас какое-то странное представление о программировании под Linux. И там есть куча IDE.
Я уверен, что вы способны понять этих людей, если захотите понять их цели.
Я уверен, что вы способны понять этих людей, если захотите понять их цели.
для меня каменный век — это именно windows. Разрабатываю кроссплатформенные приложения под win/linux desktop, и для достижения одного и того же эффекта мне необходимо:
Это только этап разрешения зависимостей. И так во всём. GUI пользуется популярностью для тривиальных задач только потому, что консоль win отвратительна. Студия хороша только тем, что в ней проприетарные технологии майкрософт хорошо склеиваются друг с другом. Попробуйте разок написать кроссплатформенное приложение и посчитайте, сколько проблем у вас будет на linux и сколько на win. По моему опыту, соотношение 1 к 10.
- linux: прописать sudo apt install g++-7 cmake libboost-dev python libfftw3-dev
- win: скачать и прогнать 5 устанощиков/архива с разных сайтов, собрать буст, прописать в PATH несколько путей, добавить в сорцы приложения библиотеки и настроить их деплой
Это только этап разрешения зависимостей. И так во всём. GUI пользуется популярностью для тривиальных задач только потому, что консоль win отвратительна. Студия хороша только тем, что в ней проприетарные технологии майкрософт хорошо склеиваются друг с другом. Попробуйте разок написать кроссплатформенное приложение и посчитайте, сколько проблем у вас будет на linux и сколько на win. По моему опыту, соотношение 1 к 10.
Я чаще всего разрабатывал одноразовые вычислительные коды, но понять проблему могу. Один раз мучался с программой, которая должна была и на линуксе заработать — да, это сложно.
Могу дополнить ещё: чтобы собрать проект на линуксе какой угодно (хоть кроссплатформерный, хоть и не кросс), нужно собрать из исходников Все используемые библиотеки, пересобрать ядро всё, кучу программ установить таким же способом, корректность которых по отдельности проверить нельзя, только консоль начнёт ругаться при установке следующей библиотеки… А потом ещё и искать какой-такой формы заклинание нужно прописать в консоли, чтобы всё собралось. Лично мне понадобилось 2 недели на то чтобы разобраться в этом.
А на винде скачал иде, подключил нужное и нажал кнопку ран. Ну, для Джавы ещё среда исполнения нужна. Всё.
Ну не заработает код на линуксе, бывает и такое… Но совместимость только с виндой покроет больше пользователей чем совместимость только с линуксом. И было бы куда проще если бы другие программисты тоже так считали. Пользователям нужно обрабатывать фотки, играть в игры (и делать их), работать с информационными системами — пока на линуксе этого всего нет, он так и останется недопиленной виндой. Не заработает у человека прога на линуксе — переключится на свою другую систему (которая у него есть, потому что там все не работающие на линуксе програмки установлены) и запустит.
Могу дополнить ещё: чтобы собрать проект на линуксе какой угодно (хоть кроссплатформерный, хоть и не кросс), нужно собрать из исходников Все используемые библиотеки, пересобрать ядро всё, кучу программ установить таким же способом, корректность которых по отдельности проверить нельзя, только консоль начнёт ругаться при установке следующей библиотеки… А потом ещё и искать какой-такой формы заклинание нужно прописать в консоли, чтобы всё собралось. Лично мне понадобилось 2 недели на то чтобы разобраться в этом.
А на винде скачал иде, подключил нужное и нажал кнопку ран. Ну, для Джавы ещё среда исполнения нужна. Всё.
Ну не заработает код на линуксе, бывает и такое… Но совместимость только с виндой покроет больше пользователей чем совместимость только с линуксом. И было бы куда проще если бы другие программисты тоже так считали. Пользователям нужно обрабатывать фотки, играть в игры (и делать их), работать с информационными системами — пока на линуксе этого всего нет, он так и останется недопиленной виндой. Не заработает у человека прога на линуксе — переключится на свою другую систему (которая у него есть, потому что там все не работающие на линуксе програмки установлены) и запустит.
не надо ничего пересобирать — скачал зависимости (из централизованного менеджера пакетов) и запустил компиляцию. В винде вот этот вот этап: «подключил нужное» куда больше времени занимает. Пользователями бывают не только домохозяйки
Менеджер пакетов качал и устанавливал мне одну библиотечку в убунту два с половиной дня.
Это, конечно, самая кривая библиотека из всех что я видел, и я потратил на её ручное подключение в виндоусе наибольшее время — 25 минут. Правда, её при этом можно подключить и нюгетом — за две.
Пока что всё что я пытался установить на Линукс длится очень долго. Сидишь и втыкаешь в появляющиеся в консоли строчки, ничего не можешь сделать пока он не выкинет из процесса не найдя очередное что-то, что надо так же долго устанавливать и собирать.
Это, конечно, самая кривая библиотека из всех что я видел, и я потратил на её ручное подключение в виндоусе наибольшее время — 25 минут. Правда, её при этом можно подключить и нюгетом — за две.
Пока что всё что я пытался установить на Линукс длится очень долго. Сидишь и втыкаешь в появляющиеся в консоли строчки, ничего не можешь сделать пока он не выкинет из процесса не найдя очередное что-то, что надо так же долго устанавливать и собирать.
То есть если фотографу нужен фотошоп — то он сразу домохозяйка, потому что не способен постичь величие линукса?
Или если программист разрабатывает компьютерные игры?
Или программист делает картографические сервисы?
Или — о боже — пишет на C#?
Он, короче домохозяйка по такой логике…
Или если программист разрабатывает компьютерные игры?
Или программист делает картографические сервисы?
Или — о боже — пишет на C#?
Он, короче домохозяйка по такой логике…
То есть если фотографу нужен фотошоп — то он сразу домохозяйкаЕсли фоторафу нужен фотошоп, то вопросы к Adobe (Хотя именно Photoshop неплохо работает и под Wine). Если фотографу нужен годный графический редактор, то они и под линуксом есть.
Или если программист разрабатывает компьютерные игры?Что ему может помешать?
Или программист делает картографические сервисы?
Или — о боже — пишет на C#?
Unity ещё не так давно линукс не поддерживала. Многие другие среды вообще с линуксом не работают, особенно те что для левел дизайна (не говоря уже о том что сами игры не работают, и протестировать не получится)
ArcGIS не поддерживается. Скорее всего многие другие штуки для картографии тоже. Photoshop и Sketchup тоже не пашут, как и многие тулзы для отрисовки векторной графики и графов.
VS на линукс нет и не будет. Сред разработки cs под линукс по словам старожил — три. Причём нормально работающая — одна. И ни одна из трёх даже близко не VS.
Даже все аналоги офисных програм майкрософта — они вроде и не плохие… Но многие pptx презентации в либра импрес просто крашатся, а если и открываются — то не поддерживают форматирование. И как минимум две программы из либры имеют стабильное нежелание правильно отображать кодировки и тексты на неоторых языках переводятся непонятно во что, даже если напрямую указать.
Даже мой браузер под линуксами запускается только особенно одарёнными шаманами, и в итоге имеет урезанный функционал.
И такой «недопил» или нехватка программ ощущается во всех областях, с которыми я работал. Предполагаю, что во всём остальном что нужно людям от компьютера ощущается то же самое. Программирование ещё и наименее обделённая область на линуксе, пожалуй всё таки есть некоторый выбор инструментов и они работают — хоть и по-своему, через консоль куда надо вбить набор команд, которые надо сначала выяснить где-то, а не через нажатие кнопок и заполнение полей… Я бы посмотрел ещё на людей которые на телефон себе линукс поставят — захотел приложение скачать, и погнали — судо аптгет…
ArcGIS не поддерживается. Скорее всего многие другие штуки для картографии тоже. Photoshop и Sketchup тоже не пашут, как и многие тулзы для отрисовки векторной графики и графов.
VS на линукс нет и не будет. Сред разработки cs под линукс по словам старожил — три. Причём нормально работающая — одна. И ни одна из трёх даже близко не VS.
Даже все аналоги офисных програм майкрософта — они вроде и не плохие… Но многие pptx презентации в либра импрес просто крашатся, а если и открываются — то не поддерживают форматирование. И как минимум две программы из либры имеют стабильное нежелание правильно отображать кодировки и тексты на неоторых языках переводятся непонятно во что, даже если напрямую указать.
Даже мой браузер под линуксами запускается только особенно одарёнными шаманами, и в итоге имеет урезанный функционал.
И такой «недопил» или нехватка программ ощущается во всех областях, с которыми я работал. Предполагаю, что во всём остальном что нужно людям от компьютера ощущается то же самое. Программирование ещё и наименее обделённая область на линуксе, пожалуй всё таки есть некоторый выбор инструментов и они работают — хоть и по-своему, через консоль куда надо вбить набор команд, которые надо сначала выяснить где-то, а не через нажатие кнопок и заполнение полей… Я бы посмотрел ещё на людей которые на телефон себе линукс поставят — захотел приложение скачать, и погнали — судо аптгет…
Фатальная проблема подобных рассуждений в том, что автор ищет куда приткнуть имеющиеся инструменты, а не решения конкретных бизнес-задач. Если автор конкретного приложения не считает нужным поддерживать версии для остальных платформ — это его проблемы.
Сред разработки под линукс по словам старожил — три.По словам каких старожил? Сред разработки под какие языки? Если говорить про винды, то тогда выяснится, что она там вовсе одна. И ничего, выживают же как-то (=
Даже все аналоги офисных програм майкрософта — они вроде и не плохие… Но многие pptx презентации в либра импрес просто крашатся, а если и открываются — то не поддерживают форматирование.У меня никогда ничего не крашилось, может быть были когда-то проблемы с форматированием в презентациях, но ничего критичного. Свои презентации показываю со своего компьютера — полет нормальный.
как минимум две программы из либры имеют стабильное нежелание правильно отображать кодировки и тексты на неоторых языках переводятся непонятно во что, даже если напрямую указать.Видимо, я такими языками не владею, поэтому не встречал таких проблем) Печально, переводчику придется поставить другую программу, благо, она не одна.
Даже мой браузер под линуксами запускается только особенно одарёнными шаманами, и в итоге имеет урезанный функционал.IE или Edge?
хоть и по-своему, через консоль куда надо вбить набор команд, которые надо сначала выяснить где-то, а не через нажатие кнопок и заполнение полей…Конечно, вы же IDE не пытались искать, только по хардкору. А «где-то» — это за редким исключением «man команда» или «команда --help».
захотел приложение скачать, и погнали — судо аптгет…Например, в Ubuntu и Mint есть магазины приложений. Да, с кнопочками, картинками, рейтингами и комментами. Никто так же не мешает скачать дистрибутив с сайта и установить в Windows-way. Вполне себе мобильные Ubuntu Touch и MeeGo так же имели свои магазины приложений.
По словам каких старожил? Сред разработки под какие языки?Под c# — MonoDevelop, джетбрейновский райдер и ещё что-то совсем неудобное. Старожилы = мои коллеги которые с линуксом дружат.
У меня никогда ничего не крашилосьКрашатся большие презентации, или с мультимедиа.
Печально, переводчику придется поставить другую программу, благо, она не одна.Не только переводчику. Libre calc часто фейлит воспроизводить украинский — вплоть до того что единственный способ прочитать на линуксе — это пересохранить базу данных на компьютере с виндой с очень хитрыми настройками.
IE или Edge?Vivaldi
Например, в Ubuntu и Mint есть магазины приложений.Есть. Но там можно найти очень мало из того что нужно, к примеру — для разработки программ.
Крашатся большие презентации, или с мультимедиа.Презентации с мультимедиа — это моветон в серьезных заведениях. Насчет «большие» — это какие и зачем такие могут понадобиться?
Я не пытаюсь замести проблему под ковер, но мне кажется, что критичность этого как-то слишком преувеличена
Vivaldi
Надеюсь, вы сообщили разработчикам о своих проблемах. Сегодня вечером попробую поставить пощупать.
Но там можно найти очень мало из того что нужно, к примеру — для разработки программ.Зря вы так. Репозитории Ubuntu поистине огромны!
А что, Visual Studio IDE можно скачать через MS Store?
Если обучающая презентация о том как делать мультимедиа контент — и вставлены примеры, то очень даже не моветон.
Вообще многочасовые доклады и обучающие материалы бывают очень большого объёма.
На каждом сайте о программе есть установщик, чаще всего в виде иссполняемого фала, который сам всё сделает на винде. Если захочу — скину на флешку и увезу устанавливать на комп где нет интернета. С линуксом — чаще всего встречаешь вместо этого одного файла набор команд которые надо набрать, которые будут скачивать и собирать программу. А если есть один файл — это может быть ещё хуже, так как он может не работать вовсе (если предварительно ещё что-то не установлено). Получается что магазин для такой системы — единственный способ установить програмку без заклинаний.
Вообще многочасовые доклады и обучающие материалы бывают очень большого объёма.
А что, Visual Studio IDE можно скачать через MS Store?Речь не идёт о том что это должно быть доступно именно в магазине. Просто для Ubuntu вы привели пример с магазином.
На каждом сайте о программе есть установщик, чаще всего в виде иссполняемого фала, который сам всё сделает на винде. Если захочу — скину на флешку и увезу устанавливать на комп где нет интернета. С линуксом — чаще всего встречаешь вместо этого одного файла набор команд которые надо набрать, которые будут скачивать и собирать программу. А если есть один файл — это может быть ещё хуже, так как он может не работать вовсе (если предварительно ещё что-то не установлено). Получается что магазин для такой системы — единственный способ установить програмку без заклинаний.
На каждом сайте о программе есть установщик, чаще всего в виде иссполняемого фала, который сам всё сделает на винде
вот-вот. Надо зайти на каждый сайт, скачать каждый установщик, запустить каждый установщик, и убедиться, что ни один из этих установщиков не сделал ничего лишнего. Если речь идет о библиотеках, то в проекте еще надо еще настроить пути к заголовочникам и бинарникам.
Если захочу — скину на флешку и увезу устанавливать на комп где нет интернета.
Есть такое неудобство. Мне, например, куда критичнее, что в дистрибутиве windows (в отличие от популярных дистрибутивов linux) отсутствуют базовые паки драйверов, включая ethernet.
Как правило либо один файл, либо один архив.
Да, драйвера надо с собой носить отдельно… Но ведь их один раз установил — и всё. Программы чаще нужны.
Да, драйвера надо с собой носить отдельно… Но ведь их один раз установил — и всё. Программы чаще нужны.
ты не установишь ни программы, ни ethernet драйвер из интернета без ethernet драйвера.
Ну так диск. Всё равно же надо с чего-то установить систему. По такой логике вообще переустановка — зло.
С линуксом — чаще всего встречаешь вместо этого одного файла набор команд которые надо набрать, которые будут скачивать и собирать программу.Хм, нет. В бинарных дистрибутивах собирать через
.configure && make && make install считается плохой практикой.На каждом сайте о программе есть установщик, чаще всего в виде иссполняемого фала, который сам всё сделает на винде.… А если есть один файл — это может быть ещё хуже, так как он может не работать вовсе (если предварительно ещё что-то не установлено)На сайте разработчика тоже лежат готовые пакеты, которые так же мышкой можно установить. В пакете есть информация о зависимостях, которые пакетный менеджер будет устанавливать без вашего участия. Прям как в Windows, только это будет не какой-то кастомный установочник (который нередко настолько уныл, что не вычищает после себя реестр и различные каталоги системы), а стандартное решение, полностью интегрированное в окружение ОС.
На винде чаще всего и не думаешь о зависимостях — сборки стараются делать полными. Хотя вот прямо вчера столкнулся с такой пакостью, но это единичный случай.
Если бы по такому же принципу делали сборки для линукса — он бы загнулся от множества несовместимых версий одних и тех же библиотек.
Если бы по такому же принципу делали сборки для линукса — он бы загнулся от множества несовместимых версий одних и тех же библиотек.
¯\_(ツ)_/¯
Если бы по такому же принципу делали сборки для линукса — он бы загнулся от множества несовместимых версий одних и тех же библиотек.Windows же не загибается, с чего вдруг Linux должен?)
Windows либо не устанавливает уже установленную программу, либо обновляет её. Поменял чуть-чуть и ставишь вторую версию если надо. У меня на панели три оперы а в системных путях четыре opencv — и всё работает.
Linux не предупреждает, а просто качает и собирает. В итоге в системных путях одна версия, остальные можно запустить только врурчную пройдясь к ним по файловой системе. И тут вторая проблема линукса даёт о себе знать — запуск не от рута не даст программе нужных для работы прав, а запуск от рута вызывает одну версию, не всегда ту что нужно. В итоге на диске валяется куча версий, и все кроме одной проблематично использовать.
Linux не предупреждает, а просто качает и собирает. В итоге в системных путях одна версия, остальные можно запустить только врурчную пройдясь к ним по файловой системе. И тут вторая проблема линукса даёт о себе знать — запуск не от рута не даст программе нужных для работы прав, а запуск от рута вызывает одну версию, не всегда ту что нужно. В итоге на диске валяется куча версий, и все кроме одной проблематично использовать.
Какая-то дичь, если честно (= Зачем может понадобиться хранить на диске несколько экземпляров одной и одной и той же версии программы?
Linux не предупреждает, а просто качает и собирает. В итоге в системных путях одна версия, остальные можно запустить только врурчную пройдясь к ним по файловой системе.А вы как запускаете программы в Windows? С ярлыка?)
Я, видимо, непонятно написал. Версии разные, но одной программы.
-
для работы с разными версиями программ есть update-alternatives. Разные версии библиотек резолвятся корректно через симлинки и правила линковки.
Да ладно? И что, при каждом обновлении каждой библиотеки заменяете её в svn/git?
На винде чаще всего и не думаешь о зависимостях — сборки стараются делать полными
Да ладно? И что, при каждом обновлении каждой библиотеки заменяете её в svn/git?
C# — язык сделанный майкрософтом для написания программ под .NET (считай исключительно для win). Я с тем же успехом могу орать что на win нет нормальной ide для swift
сложно спорить об удобстве/качестве софта с человеком, который из всех браузеров выбрал вивальди
Vivaldi
сложно спорить об удобстве/качестве софта с человеком, который из всех браузеров выбрал вивальди
Ну, тем не менее — язык популярный, я не называл какой-то экзотической редкости (а многие из разработчиков таких языков вообще делают их для вин и только).
И да, браузер отличный. Я после падения Престо целый год в хроме по привычке кидал вкладку на вкладку и опрометчиво закрывал сайты надеясь на корзину. Вивальди — это как вернувшийся старый друг, после новомодных примитивизированых браузеров.
Эта фатальная проблема не в моих рассуждениях, а в экономике.
Несколько контор делают операционные системы, одна из них вкладывает больший ресурс и вырывается вперёд. Чтобы теперь создать новую систему — нужно повторить все успехи старой, и сделать нечто большее. А это значит, что нужно иметь ресурсы больше чем майкрософт и + все те фирмы что разрабатывали программы только для вин. У линукса, при всём участии сообщества таких ресурсов не нашлось. Кроме него многие микропроекты находят своё узкое применение на платках и экзотичных платформах — но ни одна из таких ОС, которая разрабатывается сообществом на энтузиазме, или за которой пусть даже стоит небольшая компания — не сможет догнать всё то, что уже сделано крупной майкрософт и большинством фирм за последние 20 лет. Даже если бы у них была классная идея и удачно выбраная brand new архитектура, всё равно — виндоус поддерживает больше программ. Он просто Больше.
Ну а линукс… Очень сомнительное удовольствие и само по себе. Реально отталкивает. Ребёнок просит компьютер — как скоро он с ним разберётся, если у него будет линукс? Скорее всего он просто не пожелает получать компьютерную грамотность, будет как бабушки с техникой обращаться.
Я всегда привожу такой пример ещё: в винде можно лазая по директориям увидеть что это всё твоё — и вон там маленький уголок это система, мы туда не ходим. А в убунте мы ходим по папкам — и это всё система. А вот эта папка хоум — это для тебя, жалкий пользователь. Чисто идеологически меняются отношения человека и компьютера с ног на голову. Не компьютер учится понимать людей чтобы угодить им, а человек должен заучивать команды консоли на языке компьютера. Вот как меняет всё линукс.
Несколько контор делают операционные системы, одна из них вкладывает больший ресурс и вырывается вперёд. Чтобы теперь создать новую систему — нужно повторить все успехи старой, и сделать нечто большее. А это значит, что нужно иметь ресурсы больше чем майкрософт и + все те фирмы что разрабатывали программы только для вин. У линукса, при всём участии сообщества таких ресурсов не нашлось. Кроме него многие микропроекты находят своё узкое применение на платках и экзотичных платформах — но ни одна из таких ОС, которая разрабатывается сообществом на энтузиазме, или за которой пусть даже стоит небольшая компания — не сможет догнать всё то, что уже сделано крупной майкрософт и большинством фирм за последние 20 лет. Даже если бы у них была классная идея и удачно выбраная brand new архитектура, всё равно — виндоус поддерживает больше программ. Он просто Больше.
Ну а линукс… Очень сомнительное удовольствие и само по себе. Реально отталкивает. Ребёнок просит компьютер — как скоро он с ним разберётся, если у него будет линукс? Скорее всего он просто не пожелает получать компьютерную грамотность, будет как бабушки с техникой обращаться.
Я всегда привожу такой пример ещё: в винде можно лазая по директориям увидеть что это всё твоё — и вон там маленький уголок это система, мы туда не ходим. А в убунте мы ходим по папкам — и это всё система. А вот эта папка хоум — это для тебя, жалкий пользователь. Чисто идеологически меняются отношения человека и компьютера с ног на голову. Не компьютер учится понимать людей чтобы угодить им, а человек должен заучивать команды консоли на языке компьютера. Вот как меняет всё линукс.
Ребёнок просит компьютер — как скоро он с ним разберётся, если у него будет линукс?Сильно недооцениваете детей) У вас сложились стереотипы о мироустройстве по версии MS, у них таких еще нет.
Я всегда привожу такой пример ещё: в винде можно лазая по директориям увидеть что это всё твоё — и вон там маленький уголок это система, мы туда не ходим. А в убунте мы ходим по папкам — и это всё система. А вот эта папка хоум — это для тебя, жалкий пользователь.Если смотреть через файловые менеджеры, то это «линукс» состоит из домашней папки и какой-то общей папки (где ничего делать нельзя, ибо прав нет).
Но ребёнку нужен видимый результат действий, а не строчки в консоли бегущие.
Чем вам строчки не результат? И какой результат у нажатия кнопок?
Строчки — это строчки. К примеру объект в результате некой ошибки отправляет в консоль сообщение одинакового содержания 50 раз в секунду. Если какой-то другой объект хочет обратиться к пользователю по делу — и напишет в консоль, то это очень сложно заметить в процессе выполнения. Консоль нужна как отчёт для отладки, консоль — это не интерфейс. Можно иногда и в консоль пописать. Но делать это нужно так хитро чтобы был визуальный результат — иначе смысла в этом нет. К примеру я могу на рантайме прикинуть где баг, вспомнить последовательность вызовов объектов и освобождения ресурсов, понять что вот этот объект ещё можно потрогать, и это даст видимый результат в поведении игры — тогда можно и скрипт в консоли написать, чтобы сразу всё проверить. Но смысл в этом есть только если это приводит к видимым изменениям в игре. Тогда я сразу же знаю где ошибка, могу её обойти и продолжить тестирование уже других компонент. Если же запись в консоль не приводит к видимым результатам, то мне придётся завершить тестирование чтобы посмотреть что там случилось. Если у меня есть возможность выйти-исправить-баг-перестроить-снова начать тест за приемлимое время (не по 6 часов как с некоторыми 3д шутерами бывает) то я бы в принципе не лез в консоль и сразу обращался бы к логу (куда попадёт всё то же из консоли). Вот это и есть видимый результат изменений. Нажимаешь кнопку установить — идёт установка, показывают бегущую полосочку от 0 до 100. Вбиваешь в консоль — видишь как бегут строчки какое-то время, содержащие абсолютно непонятную (т.е. мусорную) для пользователя информацию. Потом — не бегут. Это как бы не результат. Непонятно даже куда оно установилось, где находится в системе — чтобы это узнать надо выяснять куда в этой системе летят файлы определённых форматов, ведь они будут работать нормально только в одном месте.
консоль — это не интерфейсЭто начало типичного холивара. Здесь уже десятки лет война, так что, пожалуй, без меня)
а если действие X в консоли сделать быстрее?
Не быстрее. Слова «установка», или «старт» все знают. А чтобы написать в консоли — надо писать некий набор букв который от чего-то там сокращения. Т.е. надо вычислить какое заклинание будет соответствовать действию, которое ты хочешь сделать. В этом и смысл интерфейса, что в нём всё понятно без предварительного изучения словаря консоли (который пополняется с установкой каждого приложения). Если по большому счёту — в этом смысл программирования. Люди предпочитают создавать объекты, или функции, давать им осмысленые имена — а не кодить каждую вещь на ассемблере. Какая разница? Выучить команды ассемблера и писать на нём, или выучить команды в для консоли? И то и другое — переход на более низкоуровневое общение с машиной. Поэтому и то и другое одинаково неудобно.
Я, как человек не знающий на память команд линукса буду каждое действие делать дольше. И Каждый человек родился без этих знаний, поэтому находится в той же ситуации что и я. Все кто делает это быстро должен был бы выучить язык консоли, годик посидя на линуксе. А значит — целый год работать медленно по непонятной причине, когда рядом есть другие ОС. Более того, программист будет постоянно работать с новыми библиотеками и программами — значит постоянно тратить время. Лично видел опытных программистов на линуксе, которые сидят и угадывают правильный порядок команд, вместо того чтобы найти то же самое в меню. Это гораздо дольше. Быстрее только однотипные монотонные действия, когда пишется примерно один и тот же набор команд. Но такие действия доведённые до автоматизма — они и на виндоус будут быстро получаться.
Я, как человек не знающий на память команд линукса буду каждое действие делать дольше. И Каждый человек родился без этих знаний, поэтому находится в той же ситуации что и я. Все кто делает это быстро должен был бы выучить язык консоли, годик посидя на линуксе. А значит — целый год работать медленно по непонятной причине, когда рядом есть другие ОС. Более того, программист будет постоянно работать с новыми библиотеками и программами — значит постоянно тратить время. Лично видел опытных программистов на линуксе, которые сидят и угадывают правильный порядок команд, вместо того чтобы найти то же самое в меню. Это гораздо дольше. Быстрее только однотипные монотонные действия, когда пишется примерно один и тот же набор команд. Но такие действия доведённые до автоматизма — они и на виндоус будут быстро получаться.
Нажимать непонятные кнопки не более информативно, чем набирать непонятные слова) Но первое отточено годами лично вами, второе — в новинку.
UFO just landed and posted this here
В дистрибутивах где существует графика — всё происходит с такой же скоростью как и на винде убунту 16 у меня даже медленнее в10 работала. Но даже пусть где-то быстрее — человек не умеющий запоминать словари абревиатур и соответствующих им действий программ вынужден ещё гуглить тексты заклинаний, а на это тратится больше времени. Тут есть существенная разница — элементы управления визуальные — они либо универсальные, и изучаются один раз — как значок дискеты. Либо подписаные, иногда с подсказкой у курсора. А в линуксе к каждой программе свой словарь, которого, к тому же, нет — обычно максимумом будет список доступных для ввода непонятных команд.
В этом смысле даже программировать на ассемблере проще чем работать как пользователь в линуксе.
В этом смысле даже программировать на ассемблере проще чем работать как пользователь в линуксе.
Вот тут не надо, сам сижу в основном на винде, но знаю что есть очень много программ имеющих например интерфейс в стиле вим, и даже не только программ, но и оконных менеджеров, например awesome. Это после некоторой подготовки гораздо удобнее, поскольку при желании можно настроить чуть ли не всю систему под единое управление с клавиатуры. Ну и насчет тех же команд в терминале — обычно ключи стараются все же делать похожими. Например -f это файл или force, -o имя выходного файла, и т.п. Есть понятно что и исключения, и неудобства, но тем не менее логика во всем этом есть, + консоль чаще всего все же дает гораздо больше возможностей чем графические инструменты.
Быстрее или небыстрее зависит как от самого интерфейса, так и от знакомства с ним. Движения мышью или пальцем тоже можно считать заклинаниями, которые многие выучили. Один дабл-клик чего стоит, не говоря об "интуитивно понятных иконках". Лично видел, что люди не понимают фразы "кликни по дискетке, чтобы сохранить документ", потому что понятия не имеют, что такое дискета. И сам лично многих современных элементов GUI не понимаю. Например, новую вариацию чекбокса в виде горизонтальной овалоподобной фигуры — где он включен, а где выключен. Или каких-то иконок, связанных с соцсетями или подобными сервисами. А меню и в текстовых интерфейсах есть, и даже не в TUI, а в CLI.
Т.е. надо вычислить какое заклинание будет соответствовать действию, которое ты хочешь сделать
какое действие нужно сделать мышкой в win для самой простой задачи из возможных — пингануть сервер по ip?
На linux есть графические оболочки, позволяющие всё то же самое, что и графическая оболочка win. Есть и инсталляторы по типу виндузятных, которыми почти не пользуются, потому что через пакетный менеджер удобнее. И так во всём. Linux позволяет всё то же самое, но еще сверху много чего
Ребёнок просит компьютер — как скоро он с ним разберётся, если у него будет линукс? Скорее всего он просто не пожелает получать компьютерную грамотность, будет как бабушки с техникой обращаться.
Как показывает практика, работе в современных дистрибутивах Linux дети и бабушки ничуть не медленнее чем в Windows. И "опытные пользователи ПК" тоже без проблем переходят. Причём программы устанавливать из "магазина" начинают раньше, а с проблемами типа "ничего не работает" обращаются крайне редко, поскольку вирусы почему-то их не атакуют. Проблемы возникают когда дети начинают хотеть популярные игры без версий под Линукс, а взрослые специалисты — привычный windows-only софт.
Я всегда привожу такой пример ещё: в винде можно лазая по директориям увидеть что это всё твоё — и вон там маленький уголок это система, мы туда не ходим. А в убунте мы ходим по папкам — и это всё система. А вот эта папка хоум — это для тебя, жалкий пользователь.
Кажется ещё на Windows NT 3.51 пользователь без админских прав не мог "лазить по директориям", не говоря о записи в них. А в некоторые папки даже с админскими правами попасть было нельзя, не сделав себя их хозяином, поскольку они принадлежали учётке System. Ну и у каждого обычного пользователя своя папка появилась, если не ошибаюсь, в NT 4.0, а может и раньше. C:{Profiles|Documents & Settings|Users}\ 20+ лет как в винде для жалкого пользователя.
Это не то же самое. Если не трогать папку виндоус — в остальных можно творить что угодно, указывать любые пути установщикам и создавать свою иерархию. Линукс от такого поведения вне хоума может сыграть в ящик и уйти на восстановление.
А папка олицетворяющая пользователя в винде — это всего лишь формальность, большая часть людей не хранит свои данные там, она больше для тех данных которые сохраняют пользовательские программы, и которые ему трогать из фалового менеджера необязательно.
А папка олицетворяющая пользователя в винде — это всего лишь формальность, большая часть людей не хранит свои данные там, она больше для тех данных которые сохраняют пользовательские программы, и которые ему трогать из фалового менеджера необязательно.
UFO just landed and posted this here
Да ладно? Обычный пользователь без админских прав может указывать любые пути установщикам?
Откда дровишки про большинство людей, которые ничего не хранят в профиле? Ни в "моих документах", ни прямо на рабочем столе?
Не ничего, но на рабочем столе время от времени всё же убирают. Но документы делаются по делу — а значит на диске С вообще их хранить нежелательно. Или к примеру забивать папку изображения действительно нужными пользователю изображениями (по 20-30 тыс в фотоархивах...) — не знаю кто так делает. Обычно диск С размечают маленьким и оставляют для системы. Если пользователь умеет немного настраивать браузер — то и автоматически загружать в папку загрузок всё из интернета вряд ли станет.
Гораздо чаще я встречал пользователей которые в принципе не знают как выглядит путь к их пользовательским данным в папке с именем их учётки, но зато отлично разбираются в той иерархии, которую нагородили на несистемных дисках.
Гораздо чаще я встречал пользователей которые в принципе не знают как выглядит путь к их пользовательским данным в папке с именем их учётки, но зато отлично разбираются в той иерархии, которую нагородили на несистемных дисках.
Обычно разбивают диски только айтишники или продвинутые пользователи. Как правило, с переносом пользовательской папки на отдельный диск. На новых компах с предустановленной виндой я не припомню разбития одного физического диска на несколько, если не брать конфигурации времён Windows95, когда пошли диски с объёмом бОльшим, чем поддерживал DOS на один раздел. В NT такой проблемы не припомню, при использовании NTFS
разбивают диски только айтишники или продвинутые пользователи.… а непродвинутым обычно помогает сосед/муж/сын/админ на работе.
Непродвинутым продавец в магазине вместе с компьютером продаст предустановленную ОС. Да в придачу сервисный пакет от магазина или апртнёра по настройке. А там диски не разбивают, или дополнительные деньги просят.
Это где в магазинах не разбивают диски? А как же С и D? Это же почти универсальный стандарт. Ноутбуки такими с завода приходят, если с предустановленной. И магазин тут ни при чём. А если ставит магазин — ну это на совести продавца, но я ещё не видел такого чтобы без разбивки продавали.
В тему линукса скажу даже более того: есть ноуты, на которые в принципе производитель делает дрова только под одну систему — ту, которую он же и ставит. Такой ноут кроме как под виндой нужной версии вообще будет плохо работать.
В тему линукса скажу даже более того: есть ноуты, на которые в принципе производитель делает дрова только под одну систему — ту, которую он же и ставит. Такой ноут кроме как под виндой нужной версии вообще будет плохо работать.
Во-первых, бывает, что ноут продается с неразбитым диском. У отца такой бук с террабайтным C:. И вряд ли их мучает совесть
Во-вторых, магазины иногда накатывают левый (собственный) софт. Например, DNS
В-третьих, дрова-то не на ноуты делают, а на их комплектующие.
Во-вторых, магазины иногда накатывают левый (собственный) софт. Например, DNS
В-третьих, дрова-то не на ноуты делают, а на их комплектующие.
Да, на комплектующие. К примеру, драйвер графики поставится, а блютуз и встроенная камера требуют какую-нибудь Висту. И по-другому никак не запустишь. Но — должен заметить — в магазине он продавался с установленной вистой.
Это несерьезно. Обычно одну и ту же камеру/блютуз модуль/пр. суют в 100500 различных моделей ноутбуков. Вы либо говорите предметно, с примерами популярных моделей ноутбуков, в которых что-то не работает под linux, либо не говорите вообще.
Вот вам пример: в моем ASUS RoG GL552VW что-то не так с дровами на видеокарту (NVidia GeForce GTX 960M 4GB). Live CD десятка различных известных мне дистрибутивов либо виснут при загрузке, либо выдают kernel panic, единственный загрузившийся (хотя и с кучей ошибок) — Arch. Если при загрузке прописать modprobe.blacklist=nouveau, то начинает работать, хотя проблемы все равно остаются (например, live cd Ubuntu виснет при выключении). А если после установки попытаться использовать проприетарные драйвера из пакета nvidia, то проблема возвращается, но уже на живой системе, на не на live cd. Пробовал кучу разных версий драйвера, так ничего и не взлетело.
HP Pavilion у меня какой-то был, работал только на висте.
Это, конечно, лишь anecdotal evidence, но из всех ноутов, которые я когда-либо покупал, диски были разбиты лишь у одного — он шел с openSUSE. А у остальных да — либо только C:, либо C: и D:, если это SSD+HDD.
Попробуйте разок написать кроссплатформенное приложение и посчитайте, сколько проблем у вас будет на linux и сколько на win
По своему опыту написания кросс-платформенного софта Win+Linux (Delphi + Lazarus) — везде своих вопросов хватает. Аналога WaitForMultipleObjects в линухе так и не нашел, увы.
В студии еще дебаггер очень удобный.
Кто вам сказал, что в линуксе в наше время делается всё через консоль? Большинство популярных IDE кроссплатформенные. А что под линуксом консоль используется чаще, так только потому что в каком-нибудь bash удобнее некоторые вещи делать, чем в GUI, в отличии от cmd.exe
) Visual Studio — популярная IDE, но ниразу не кроссплатформенная. VS for Mac — отдельный продукт, VS Code — не полноценная IDE.
Четсно, я искал инструкции как всё делать через GUI, чтобы поменьше лазить в консоль, и при всём моём усердии, мне не удалось в итоге собрать и использовать хоть как-то ни одного проекта, обходясь без консоли.
Вы искали инструкцию по забиванию гвоздей микроскопом, чтобы меньше пользоваться для этого молотком. Но при всём вашем усердии вам не удалось сколотить ни одной табуретки без молотка.
Это замечательно, я считаю. Так и должно быть.
Это замечательно, я считаю. Так и должно быть.
Аналогия не совсем уместна. Скорее есть два варианта — взять оптический микроскоп и работать с ним — если не хватает света, можно руками зеркало поправить, если фокус навести надо — берёшь и делаешь, даже надпись есть: «настройка фокуса».
А можно взять громоздкий лабораторный микроскоп с которого зачем-то снели всю прошивку и удалили платы. Теоретически он может гораздо больше чем первый — только пока что там не предусмотрено даже возможности приближать фокус. Нужно делать это мотором, на мотор надо установить драйвер (так, конечно, делают новички и домохозяйки, тру пользователь должен сам настругать кремния и спечь микросхему для этого драйвера и вмонтировать его в систему), затем написать программу которая будет крутить мотор, и программу которая будет считывать как меняется фокус, а затем программу которая синхронизирует систему до линейной управляемости. И вот тогда уже можно крутануть ползунок (а, нет, простите, написать в консоли focusdist -prkjsv -avaavaava -chego-to-tam +6 ) и фокус сдвинется на 6 делений.
А в оптическом майкрософт (допустим) просто предусмотрел ручку управления, корорую нужно крутить и всё получится сразу.
А можно взять громоздкий лабораторный микроскоп с которого зачем-то снели всю прошивку и удалили платы. Теоретически он может гораздо больше чем первый — только пока что там не предусмотрено даже возможности приближать фокус. Нужно делать это мотором, на мотор надо установить драйвер (так, конечно, делают новички и домохозяйки, тру пользователь должен сам настругать кремния и спечь микросхему для этого драйвера и вмонтировать его в систему), затем написать программу которая будет крутить мотор, и программу которая будет считывать как меняется фокус, а затем программу которая синхронизирует систему до линейной управляемости. И вот тогда уже можно крутануть ползунок (а, нет, простите, написать в консоли focusdist -prkjsv -avaavaava -chego-to-tam +6 ) и фокус сдвинется на 6 делений.
А в оптическом майкрософт (допустим) просто предусмотрел ручку управления, корорую нужно крутить и всё получится сразу.
Интересно, перечитал и проанализировал тред. Сторонники линукса делают примерно так:
«кто вам сказал что там всё через консоль? Там есть удобные программы с GUI»
«а вот — я пытался сделать что-то не используя консоль — и не получилось.»
«забиваете гвозди микроскопом — не должно было получится, используйте консоль»
Или так: «у тебя даже браузер не кошерный, что с тобой разговаривать?»
«ты начинаешь холивар, так что я ухожу»
Конструктивность, последовательность… Зачем, если можно минуснуть каждый комментарий, даже тот где я констатирую что c# популярный язык, а не экзотика.
Между тем у меня есть вполне оправданная и чёткая позиция без внутренних противоречий, и она основана на практике, на рабочих случаях, и на здравом смысле. Есть сложные проекты, они должны принимать данные от других программ, использовать библиотеки… Иногда кто-то находит решение к проблеме, и годами пилит код на линуксе. В итоге ни на одной другой системе его не запустить, переписывать библиотеку — слишком затратно. Так и остаются комплиментарные решения, которые нужны одновременно на одной системе — часть совместимы с одной, часть с другой. И тогда месцами приходится выполнять тонны лишней работы (иногда опять — годы). А ведь паренёк молодец, нашёл решение. Но зачем же писать его на линуксе? Если бы все сконцентрировали усилия на одной платформе, а не распылялись бы на линукс и прочие хайку, и чего там ещё — мы могли бы достичь большего. Уже и искуственный интеллект тут бы бегал сто лет. Так уж сложилось что вы относитесь к тем 2% людей которые находят линукс удобнее винды — но неужели это повод минусовать?
«кто вам сказал что там всё через консоль? Там есть удобные программы с GUI»
«а вот — я пытался сделать что-то не используя консоль — и не получилось.»
«забиваете гвозди микроскопом — не должно было получится, используйте консоль»
Или так: «у тебя даже браузер не кошерный, что с тобой разговаривать?»
«ты начинаешь холивар, так что я ухожу»
Конструктивность, последовательность… Зачем, если можно минуснуть каждый комментарий, даже тот где я констатирую что c# популярный язык, а не экзотика.
Между тем у меня есть вполне оправданная и чёткая позиция без внутренних противоречий, и она основана на практике, на рабочих случаях, и на здравом смысле. Есть сложные проекты, они должны принимать данные от других программ, использовать библиотеки… Иногда кто-то находит решение к проблеме, и годами пилит код на линуксе. В итоге ни на одной другой системе его не запустить, переписывать библиотеку — слишком затратно. Так и остаются комплиментарные решения, которые нужны одновременно на одной системе — часть совместимы с одной, часть с другой. И тогда месцами приходится выполнять тонны лишней работы (иногда опять — годы). А ведь паренёк молодец, нашёл решение. Но зачем же писать его на линуксе? Если бы все сконцентрировали усилия на одной платформе, а не распылялись бы на линукс и прочие хайку, и чего там ещё — мы могли бы достичь большего. Уже и искуственный интеллект тут бы бегал сто лет. Так уж сложилось что вы относитесь к тем 2% людей которые находят линукс удобнее винды — но неужели это повод минусовать?
Между тем у меня есть вполне оправданная и чёткая позиция без внутренних противоречий, и она основана на практике, на рабочих случаях, и на здравом смысле.
Вы совершенно очевидно не научились пользоваться инструментом (что показывают удивительные пути, по которым пришли к вашим аргументам) и ругаете его, не принимая никаких контраргументов. В сухом остатке что-то смешное про унизительную идеологию файловой системы и классический холивар «мышка против консоли». Вот и минусят наиболее острые комментарии, а не карму.
А ведь паренёк молодец, нашёл решение. Но зачем же писать его на линуксе?
Почему некто, решая вставшую перед ним проблему, должен сделать так, как удобнее вам, а не ему? Лично я вижу сильно более, чем одну причину ориентировать продукт в первую очередь на Linux-системы:
- это что-то серверное (потому что серверы часто работают на Linux);
- это что-то научно-вычислительное (потому что суперкомпьютеры часто работают на Linux);
- это что-то для встраиваемых систем (потому что там часто ставят Linux).
В итоге ни на одной другой системе его не запустить, переписывать библиотеку — слишком затратно.
Насколько я могу судить по своему опыту, в Linux-сообществе принято при любой возможности использовать кросслатформенные технологии: языки, фреймворки и библиотеки, следовать отраслевым стандартам. Куча Linux-софта имеет готовые сборки для Windows (а часто и для OS X, FreeBSD и «прочих хайку»), потому что разработчики с самого начала понимали, что их любимая ОС не единственная в мире. Распространён ли этот подход в мире Windows? Вы лично готовы отказаться от WinAPI, DirectX, WPF, UWP (или что там теперь модно?) в пользу POSIX, OpenGL и Qt/Gtk ради хайку-пользователей? Или ваша «чёткая позиция без внутренних противоречий» направлена лишь на обеспечение вашего личного комфорта?
Кстати, многие «серьёзные» вендоры, оказывается, вполне готовы идти навстречу пользователям не-Windows: у Altera и Xilinx есть официальные версии их сред разработки для Linux (они работают, хотя иной раз и не без проблем), а также у Synopsis — несмотря на то, что их софт стоит на пару порядков дороже лицензии Windows.
Если бы все сконцентрировали усилия на одной платформе, а не распылялись бы на линукс и прочие хайку, и чего там ещё — мы могли бы достичь большего.
Нечто подобное сейчас и происходит, только усилия концентрируются не не той системе, к которой вы привыкли. Или вы правда хотите видеть все десктопы, серверы, вычислительные кластеры и смартфоны мира намертво связанными гигантским vendor lock-in'ом?
Вы не поняли меня. Я как раз говорю о том что развивать сторонние системы (многие из которых пытаются начинать с нуля) не очень продуктивно, и лучше бы всё это сообщество работало с программами для виндоус. А именно с виндоус — не потому что лично я считаю её лучше (а я считаю), а потому что на ней подавляющее большинство пользователей.
UFO just landed and posted this here
вы всерьез не понимаете или прикидываетесь? microsoft делает всё возможное, чтобы убить другие системы, кроссплатформенность, привязать в свою «экосистему», ведь это им коммерчески выгодно. Они хотят чтоб под другие ОС разрабатывали из-под win. Пробовали когда-нибудь пользоваться com объектами из msvc и из mingw? А не замечали, что visual c++ и с++ это разные языки?
Игровые движки уже переводят на linux, и не только их. Пройдет какое-то время и люди перестанут понимать за что платить $100-200, а win будет пользоваться популярностью только у закостенелых сеньоров. Не верите? А я не единожды видел ребят, пользующихся ubuntu/mint на macbook.
Игровые движки уже переводят на linux, и не только их. Пройдет какое-то время и люди перестанут понимать за что платить $100-200, а win будет пользоваться популярностью только у закостенелых сеньоров. Не верите? А я не единожды видел ребят, пользующихся ubuntu/mint на macbook.
Если в конце концов человечество придёт к тому чтобы откатить развитие технологий к консолям… То мне не понравится такое человечество, скажем так.
Сейчас уже линукс работает больше с клавиатурой, чем с мышью, хотя технология не нова. Дальше — больше. Разоры, смарт экраны, сабы, браслеты, голосовое управление (и синтез голоса) — в этом всём майкрософт продвинулся куда дальше, все остальные системы очень сильно отстают, многие новые вещи вообще работают только с виндоус. Так что пока ещё всё в порядке, we're still flying. Человек предпочтёт сказать роботу что ему нужно, чем пересобирать ему ядро, вшивать инструкцию и смотреть на бегущие строчки. Насколько мне известно, существующие на данный момент виртуальные помощники на линуксе только научились переводить запросы на человеческом языке в консольные команды (что линукс должен был сделать сразу с выпуском первой системы, ибо без этого (и без всезнающего гугла) работать в нём не возможно). И это тоже достаточно далеко от того что умеет майкрософт.
Сейчас уже линукс работает больше с клавиатурой, чем с мышью, хотя технология не нова. Дальше — больше. Разоры, смарт экраны, сабы, браслеты, голосовое управление (и синтез голоса) — в этом всём майкрософт продвинулся куда дальше, все остальные системы очень сильно отстают, многие новые вещи вообще работают только с виндоус. Так что пока ещё всё в порядке, we're still flying. Человек предпочтёт сказать роботу что ему нужно, чем пересобирать ему ядро, вшивать инструкцию и смотреть на бегущие строчки. Насколько мне известно, существующие на данный момент виртуальные помощники на линуксе только научились переводить запросы на человеческом языке в консольные команды (что линукс должен был сделать сразу с выпуском первой системы, ибо без этого (и без всезнающего гугла) работать в нём не возможно). И это тоже достаточно далеко от того что умеет майкрософт.
вам уже 5-10й раз говорят что linux это НЕ ТОЛЬКО консоль. Там есть графический интерфейс и его возможности ничуть не уступают таковым на win.
Как хорошо что вы припрели роботов. Не знали наверно, что ROS работает под linux? И ставится на win только через WSL? Вы некомпетентны
Человек предпочтёт сказать роботу что ему нужно, чем пересобирать ему ядро, вшивать инструкцию и смотреть на бегущие строчки
Как хорошо что вы припрели роботов. Не знали наверно, что ROS работает под linux? И ставится на win только через WSL? Вы некомпетентны
Вы невнимательно читаете, даже то на что я прямо указываю.
То у вас линукс это не только консоль, то выясняется вдруг что в линуксе без консоли ничего нельзя сделать. Нужно определяться уже, линукс — это консоли, или нет.
И то что вы сказали не отменяет лидерства виндоусных приложений и библиотек в этих сферах. Возможности — уступают. Я только что перечислял технологии разработанные для взаимодействия с десктопным виндоусом.
То у вас линукс это не только консоль, то выясняется вдруг что в линуксе без консоли ничего нельзя сделать. Нужно определяться уже, линукс — это консоли, или нет.
И то что вы сказали не отменяет лидерства виндоусных приложений и библиотек в этих сферах. Возможности — уступают. Я только что перечислял технологии разработанные для взаимодействия с десктопным виндоусом.
то, что в win можно сделать через gui, можно сделать и в linux через gui. То, что можно сделать в linux только из консоли, в win либо только через консоль, либо никак (чаще никак).
win никак не может быть лидером в сферах, для работы в которых используется исключительно linux.
И то что вы сказали не отменяет лидерства виндоусных приложений и библиотек в этих сферах. Возможности — уступают. Я только что перечислял технологии разработанные для взаимодействия с десктопным виндоусом.
win никак не может быть лидером в сферах, для работы в которых используется исключительно linux.
Гидра теоретически работает с линуксом, но ни одной программы, которая использовала бы их на линуксе, кажется, просто не написано. Загуглил другие 3д манипуляторы — они просто пишут в требованиях виндоус 7, или выше. У джарвиса (и даже у кортаны) версии для линукса не планировались. Ориентированые модемы оз завязаны на винсок (как и весь пак включая theme). Мио тоже не поддерживает. А Microsoft Surface Hub… Ну вы поняли. Где здесь «исключительно линукс» — я никак не могу понять.
Гидра теоретически работает с линуксом, но ни одной программы, которая использовала бы их на линуксе, кажется, просто не написано. Загуглил другие 3д манипуляторы — они просто пишут в требованиях виндоус 7, или выше
ноунеймов называете. Здесь перечислены лидеры роботостроения, никакой гидры там нет. Сам лично работал с kuka, из-под вышеупомянутой ROS под linux.
У джарвиса (и даже у кортаны) версии для линукса не планировались.
Android и iOS это тоже linux. Cortana это второсортная догоняющая технология.
Всё остальное перечисленное вами — microsoft и фиг пойми кто.
Это не роботостроение, это взаимодействие с пользователем. Манипуляторы, системы экранов и так далее.
Список «Industrial Robotics», это индустрия, уже отработаные технологии, а вот если говорить о передовых разработках, то это ИИ и лабораторные роботы свеженькие. Там либо без системы низкоуровневый код, либо виндоус почти везде. Если взять ИСПР то их ещё, бывает, на маках делают. Но линуксов я ещё не видел.
изначально предмет спора был «на какой ос разрабатывать лучше». Вы умудрились увести предмет беседы в такие дебри, о которых я даже никогда не слышал. Упомянутое вами сложно перепроверить
Ну все готовые программы — были когда-то разработаны. Драйвера для устройств — тоже предмет разработки. И разработка ИИ и роботов — тоже разработка. Я считаю что все упомянутые технологии — тут в тему.
Перепроверка простая — открыть пару видео на тему роботов и искуственного интеллекта, с названиями конкретных институтов где есть такие разработки. Там можно подглядеть в экраны и увидеть что люди на винде работают. Либо на самом действующем лице экран виндоус.
Я местных разработок нашёл 6 штук. Одну начали на XP разрабатывать, потом 8-10 (этот учится понимать задачи от людей в словесной форме), ещё одна до сих пор на семёрке разрабатывается (колёсный лабораторный робот), и имеет точного аналога в лице третьего робота. Ещё один тоже на винде 10, ещё один — был на винде, но часть модулей на линуксе (откровенно дурацкое решение и оно не работает) и про последний ИИ (чисто компьютер, без актуаторов) — я не нашёл информации, но его тот же университет делает где робот на семёрке бегает.
ИСПР на маке, которая мне вспомнилась — это научный робот который «живёт» в камере с очень высокой температурой и производит измерения там где человек находится не может.
Технологии которые я описываю — это не дебри, это просто очень новые технологии. Скоро они приживутся и будут такими же привычными как мышь.
Просто есть такие «мыши» которыми можно водить в пространстве и рисовать, чертить и играть в игры в 3д. А есть браслеты на руки, чтобы жестами управлять всей техникой в доме. А есть системы умных досок, которыми можно тоже управлять — и жестами, и стилосами и чем захочешь. Все эти технологии на слуху, вы наверняка слышали про них, просто не запомнили названия и не обратили внимание для какой они системы. Их существование говорит о том куда движется человечество — к тому чтобы общаться с машинами интуитивно, не изучая талмуды. У языка С около 30 специальных слов, большая часть синтаксиса — просто слегка формализованый английский язык. Для управления потоком достаточно 5ти. То же самое с другими языками программирования, в принципе. Все они наследуют идеи понятного управления. Некоторые комбинации иде могут даже включать элементы визуального программирования, где программа — это блоксема. И на фоне этого есть консоль — где надо точно заучить все правильные названия программ, спецслова, параметры и правильную их последовательность… И организация информации настолько неочевидна, что проверить правильность установки можно только в конце, а значит делать сначала билд на 5 суток каждый раз, когда не совпадает очередной уровень проверки наличия всех штучек. Это не программирование, это ад.
Когда я впервые начал пользоваться линуксом — я просто установил иде и скопировал код на винде — никогда ещё не ошибался так сильно… Переделка кода заняла три недели, хотя оригинальный на винде я написал за 2,5 дня. И в итоге он не поддерживал одну функцию, которую линукс, похоже, просто не умеет. И это самые простейшие вещи… Я не дурак какой-то, и не с луны свалился вчера, я человек с высшим образованием, и мне неприятно когда я оказываюсь неспособен сделать простые вещи, настолько элементарные, что люди даже не считают нужным писать по ним туториалы — как-будто это должно быть очевидно каждому. А мне непонятно — то ли родился таким глупым, то ли меня, получается, отупили 22 года использования виндоус…
Я местных разработок нашёл 6 штук. Одну начали на XP разрабатывать, потом 8-10 (этот учится понимать задачи от людей в словесной форме), ещё одна до сих пор на семёрке разрабатывается (колёсный лабораторный робот), и имеет точного аналога в лице третьего робота. Ещё один тоже на винде 10, ещё один — был на винде, но часть модулей на линуксе (откровенно дурацкое решение и оно не работает) и про последний ИИ (чисто компьютер, без актуаторов) — я не нашёл информации, но его тот же университет делает где робот на семёрке бегает.
ИСПР на маке, которая мне вспомнилась — это научный робот который «живёт» в камере с очень высокой температурой и производит измерения там где человек находится не может.
Технологии которые я описываю — это не дебри, это просто очень новые технологии. Скоро они приживутся и будут такими же привычными как мышь.
Просто есть такие «мыши» которыми можно водить в пространстве и рисовать, чертить и играть в игры в 3д. А есть браслеты на руки, чтобы жестами управлять всей техникой в доме. А есть системы умных досок, которыми можно тоже управлять — и жестами, и стилосами и чем захочешь. Все эти технологии на слуху, вы наверняка слышали про них, просто не запомнили названия и не обратили внимание для какой они системы. Их существование говорит о том куда движется человечество — к тому чтобы общаться с машинами интуитивно, не изучая талмуды. У языка С около 30 специальных слов, большая часть синтаксиса — просто слегка формализованый английский язык. Для управления потоком достаточно 5ти. То же самое с другими языками программирования, в принципе. Все они наследуют идеи понятного управления. Некоторые комбинации иде могут даже включать элементы визуального программирования, где программа — это блоксема. И на фоне этого есть консоль — где надо точно заучить все правильные названия программ, спецслова, параметры и правильную их последовательность… И организация информации настолько неочевидна, что проверить правильность установки можно только в конце, а значит делать сначала билд на 5 суток каждый раз, когда не совпадает очередной уровень проверки наличия всех штучек. Это не программирование, это ад.
Когда я впервые начал пользоваться линуксом — я просто установил иде и скопировал код на винде — никогда ещё не ошибался так сильно… Переделка кода заняла три недели, хотя оригинальный на винде я написал за 2,5 дня. И в итоге он не поддерживал одну функцию, которую линукс, похоже, просто не умеет. И это самые простейшие вещи… Я не дурак какой-то, и не с луны свалился вчера, я человек с высшим образованием, и мне неприятно когда я оказываюсь неспособен сделать простые вещи, настолько элементарные, что люди даже не считают нужным писать по ним туториалы — как-будто это должно быть очевидно каждому. А мне непонятно — то ли родился таким глупым, то ли меня, получается, отупили 22 года использования виндоус…
вот вы всё это нашли а ссылки не скинули. А если я буду искать и там везде будет мелькать линукс?
очевидно, что вместо кроссплатформенных технологий вы использовали WinAPI и проприетарные расширения MSVC. Можно точно так же написать код на linux (используя posix, например) и его не получится просто перенести на win. А на всех остальных ОС соберется и запустится. Более того, я могу написать корректный c++ код, который соберется gcc, но который msvc точно не соберет до версии 2023-его года.
какую же?
я бы на это поставил
Когда я впервые начал пользоваться линуксом — я просто установил иде и скопировал код на винде — никогда ещё не ошибался так сильно… Переделка кода заняла три недели, хотя оригинальный на винде я написал за 2,5 дня
очевидно, что вместо кроссплатформенных технологий вы использовали WinAPI и проприетарные расширения MSVC. Можно точно так же написать код на linux (используя posix, например) и его не получится просто перенести на win. А на всех остальных ОС соберется и запустится. Более того, я могу написать корректный c++ код, который соберется gcc, но который msvc точно не соберет до версии 2023-его года.
И в итоге он не поддерживал одну функцию, которую линукс, похоже, просто не умеет
какую же?
то ли меня, получается, отупили 22 года использования виндоус…
я бы на это поставил
А если я буду искать и там везде будет мелькать линукс?
Я таких не находил. Даже специально каждый проект гуглил вместе со словом linux. Сразу результаты не в ту степь.
Более того, я могу написать корректный c++ код, который соберется gcc, но который msvc точно не соберет до версии 2023-его года.
Вы можете. Но хоть такой код и будет работать на большем количестве разных систем чем виндовый — виндовый будет работать на 88% всех компьютеров, просто потому что их больше. Как пример — английский язык не самый простой для изучения, но самый популярный язык международного общения. А всякие искусственные языки может и более совместимы с лексикой самых разных языков, и потому их проще учить — но для международного общения их используют гораздо реже. Тут тоже самое. Совместимых с кодом на линуксе вариантов систем больше, но винда всё равно распространённее чем все они вместе взятые.
какую же?
Не имею права говорить. Но это связано с сетью. Вообще у Линукса много проблем с сетью. Например, конфигурация сети может испариться в никуда, если использовать вшитый в саму систему гуи для её настройки (гениальное решение разработчиков...). И даже приложения специально разработанные под линукс могут испортить wifi.
я бы на это поставил
Ну, как человек разбирающийся и в линуксе и в роботах, может вы просветите человека безграмотного — как построить библиотеку MRPT на убунте? У меня на это больше недели ушло, просто из-за постоянных требований докачивать ещё что-то, что также на линуксе только из исходников собирается. И то — теперь я понятия не имею какой версии компилятор нужен чтобы всё запустить — постоянное несовпадение флагов ABI на исполняемых файлах.
Но хоть такой код и будет работать на большем количестве разных систем чем виндовый — виндовый будет работать на 88% всех компьютеров, просто потому что их больше.
Вам уже упоминали, что мобильные устройства тоже работают на linux (и других posix-compatible ОС)
Не имею права говорить.
Не имеете права говорить какую часть публичного API windows не поддерживает linux? bullshit detected
Ну, как человек разбирающийся и в линуксе и в роботах, может вы просветите человека безграмотного — как построить библиотеку MRPT на убунте?
С официальной страницы:
sudo add-apt-repository ppa:joseluisblancoc/mrpt
sudo apt-get update
sudo apt-get install libmrpt-dev mrpt-appsНе имеете права говорить какую часть публичного API windows не поддерживает linux?
Не имею права указывать на то, какого функционала нет в программе. А насчёт того что не поддерживается — linux'овский sys/socket отличается от винсока и неадекватно реагирует на проброску порта на виртуальной машине. В итоге двустороннюю передачу данных можно реализовать сервером на виндоусе, но нельзя — сервером на линуксе (работают сервер на сервере: виндоус-виндоус, линукс-виндоус, виндоус-линукс при неравноправных системах в локалке, а если установить сервер на терминал, то работать будут виндоус-виндоус и линукс-виндоус, а у виндоус-линукс будет только односторонняя связь. При этом если сервер на винде, то можно вообще забить и использовать дотнетовский сокет и написать всё на шарпе).
С официальной страницы:
Ага. Только он потребует библиотеку, потом другую, третью… CMake'ом если конфигурировать — видно что он ещё много гигов разных библиотек хочет. Включая OpenCV, которую для поддержки tensorflow и прочих зрительных штук необходимо тоже из исходников собирать. И некоторые библиотеки надо ещё хитрыми способами даунгрейдить и пути переделывать.
И даже это итоговой проблемы с флагами не решает (люди просто запускают код палкой (удаляют строку которая проверяет совместимость) на свой страх и риск).
Ага. Только он потребует библиотеку, потом другую, третью… CMake'ом если конфигурировать — видно что он ещё много гигов разных библиотек хочет
вот как знал что это чепуха. 299 мб вместе со всеми пакетами-зависимостями
пруф
sudo apt install libmrpt-dev mrpt-apps
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages were automatically installed and are no longer required:
linux-headers-4.10.0-32 linux-headers-4.10.0-32-generic linux-headers-4.10.0-33 linux-headers-4.10.0-33-generic linux-image-4.10.0-32-generic
linux-image-4.10.0-33-generic linux-image-extra-4.10.0-32-generic linux-image-extra-4.10.0-33-generic
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
freeglut3 gfortran gfortran-7 libamd2 libassimp3v5 libblas-common libblas-dev libblas3 libbtf1 libcamd2 libccolamd2 libcholmod3 libcolamd2
libcxsparse3 libeigen3-dev libfreenect0.5 libftdi1-2 libgfortran-7-dev libgfortran3 libgfortran4 libklu1 liblapack-dev liblapack3 libldl2 libmetis5
libminizip1 libmrpt-base1.9 libmrpt-comms1.9 libmrpt-detectors1.9 libmrpt-graphs1.9 libmrpt-graphslam1.9 libmrpt-gui1.9 libmrpt-hmtslam1.9
libmrpt-hwdrivers1.9 libmrpt-kinematics1.9 libmrpt-maps1.9 libmrpt-nav1.9 libmrpt-obs1.9 libmrpt-opengl1.9 libmrpt-slam1.9 libmrpt-tfest1.9
libmrpt-topography1.9 libmrpt-vision1.9 liboctomap-dev liboctomap1.8 libopenni2-0 librbio2 libspqr2 libsuitesparse-dev libsuitesparseconfig4
libumfpack5 libwxbase3.0-0v5 libwxgtk3.0-0v5 mrpt-common
Suggested packages:
gfortran-multilib gfortran-doc gfortran-7-multilib gfortran-7-doc libgfortran4-dbg libcoarrays-dev liblapack-doc-man liblapack-doc libeigen3-doc
The following NEW packages will be installed:
freeglut3 gfortran gfortran-7 libamd2 libassimp3v5 libblas-common libblas-dev libblas3 libbtf1 libcamd2 libccolamd2 libcholmod3 libcolamd2
libcxsparse3 libeigen3-dev libfreenect0.5 libftdi1-2 libgfortran-7-dev libgfortran3 libgfortran4 libklu1 liblapack-dev liblapack3 libldl2 libmetis5
libminizip1 libmrpt-base1.9 libmrpt-comms1.9 libmrpt-detectors1.9 libmrpt-dev libmrpt-graphs1.9 libmrpt-graphslam1.9 libmrpt-gui1.9
libmrpt-hmtslam1.9 libmrpt-hwdrivers1.9 libmrpt-kinematics1.9 libmrpt-maps1.9 libmrpt-nav1.9 libmrpt-obs1.9 libmrpt-opengl1.9 libmrpt-slam1.9
libmrpt-tfest1.9 libmrpt-topography1.9 libmrpt-vision1.9 liboctomap-dev liboctomap1.8 libopenni2-0 librbio2 libspqr2 libsuitesparse-dev
libsuitesparseconfig4 libumfpack5 libwxbase3.0-0v5 libwxgtk3.0-0v5 mrpt-apps mrpt-common
0 upgraded, 56 newly installed, 0 to remove and 0 not upgraded.
Need to get 70,3 MB of archives.
After this operation, 299 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages were automatically installed and are no longer required:
linux-headers-4.10.0-32 linux-headers-4.10.0-32-generic linux-headers-4.10.0-33 linux-headers-4.10.0-33-generic linux-image-4.10.0-32-generic
linux-image-4.10.0-33-generic linux-image-extra-4.10.0-32-generic linux-image-extra-4.10.0-33-generic
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
freeglut3 gfortran gfortran-7 libamd2 libassimp3v5 libblas-common libblas-dev libblas3 libbtf1 libcamd2 libccolamd2 libcholmod3 libcolamd2
libcxsparse3 libeigen3-dev libfreenect0.5 libftdi1-2 libgfortran-7-dev libgfortran3 libgfortran4 libklu1 liblapack-dev liblapack3 libldl2 libmetis5
libminizip1 libmrpt-base1.9 libmrpt-comms1.9 libmrpt-detectors1.9 libmrpt-graphs1.9 libmrpt-graphslam1.9 libmrpt-gui1.9 libmrpt-hmtslam1.9
libmrpt-hwdrivers1.9 libmrpt-kinematics1.9 libmrpt-maps1.9 libmrpt-nav1.9 libmrpt-obs1.9 libmrpt-opengl1.9 libmrpt-slam1.9 libmrpt-tfest1.9
libmrpt-topography1.9 libmrpt-vision1.9 liboctomap-dev liboctomap1.8 libopenni2-0 librbio2 libspqr2 libsuitesparse-dev libsuitesparseconfig4
libumfpack5 libwxbase3.0-0v5 libwxgtk3.0-0v5 mrpt-common
Suggested packages:
gfortran-multilib gfortran-doc gfortran-7-multilib gfortran-7-doc libgfortran4-dbg libcoarrays-dev liblapack-doc-man liblapack-doc libeigen3-doc
The following NEW packages will be installed:
freeglut3 gfortran gfortran-7 libamd2 libassimp3v5 libblas-common libblas-dev libblas3 libbtf1 libcamd2 libccolamd2 libcholmod3 libcolamd2
libcxsparse3 libeigen3-dev libfreenect0.5 libftdi1-2 libgfortran-7-dev libgfortran3 libgfortran4 libklu1 liblapack-dev liblapack3 libldl2 libmetis5
libminizip1 libmrpt-base1.9 libmrpt-comms1.9 libmrpt-detectors1.9 libmrpt-dev libmrpt-graphs1.9 libmrpt-graphslam1.9 libmrpt-gui1.9
libmrpt-hmtslam1.9 libmrpt-hwdrivers1.9 libmrpt-kinematics1.9 libmrpt-maps1.9 libmrpt-nav1.9 libmrpt-obs1.9 libmrpt-opengl1.9 libmrpt-slam1.9
libmrpt-tfest1.9 libmrpt-topography1.9 libmrpt-vision1.9 liboctomap-dev liboctomap1.8 libopenni2-0 librbio2 libspqr2 libsuitesparse-dev
libsuitesparseconfig4 libumfpack5 libwxbase3.0-0v5 libwxgtk3.0-0v5 mrpt-apps mrpt-common
0 upgraded, 56 newly installed, 0 to remove and 0 not upgraded.
Need to get 70,3 MB of archives.
After this operation, 299 MB of additional disk space will be used.
Do you want to continue? [Y/n]
mrpt 1.5 билд+исходники 2.85 гигабайта
OpenCV (от которой он так же зависит), билд+исходники 3.9 гигабайт
Ещё нужны wxwidgets и всякое такое. Очень много мелочей.
OpenCV (от которой он так же зависит), билд+исходники 3.9 гигабайт
Ещё нужны wxwidgets и всякое такое. Очень много мелочей.
mrpt 1.5 билд+исходники 2.85 гигабайта
OpenCV (от которой он так же зависит), билд+исходники 3.9 гигабайт
это размеры бинарников при компиляции студией, я говорю про linux. mrpt под linux вместе со всеми зависимостями де факто весит в районе 300 мб.
Ещё нужны wxwidgets и всякое такое. Очень много мелочей.
если вам для кастомного билда mrpt нужен opencv более старшей версии чем в репозитории, все исходники которые вам нужны — mrpt и opencv. Всё остальное подойдет и из пакетов.
У меня почему-то складывается впечатление, что вы на самом деле пытались не компилировать под linux, а кросс-компилировать из-под win. Тогда да, можно собрать кучу проблем.
Вам уже упоминали, что мобильные устройства тоже работают на linux (и других posix-compatible ОС)
От создателей с++:
«Я мечтал, чтобы компьютеры стали такими же простыми в использовании, как телефоны. Недавно моя мечта сбылась — я не смог разобраться с моим новым телефоном.»
Ага. Только он потребует библиотеку, потом другую, третью…
А на win он ничего не требует чтоли? Сам работает? И не надо лазить по нескольким сайтам, скачивать библиотеки, конфигурировать каждую сборку отдельно и т.д.? Ах, да, там же есть precompiled for Visual Studio 2015. Упс, а на дворе-то конец 2017-ого!
От создателей с++:
обожаю ваш талант в приведении
А на win он ничего не требует чтоли?
Ну и требует поменьше… Я прекрасно знаю какие вещи я трогать не буду в своём проекте, и могу не устанавливать их — и Windows не будет проверять всё ли я правильно собрал и все ли версии подходят друг к другу. Он парень простой — запустит то что сказали, и чаще всего запустится всё сразу.
А Linux прекращает сборку и паникует без файлика который мне никогда нужен не был. В этом смысле он паникёр.
Ах, да, там же есть precompiled for Visual Studio 2015. Упс, а на дворе-то конец 2017-ого!
Несколько установленных версий студии решают проблему. Иногда у них ещё компиляторы немного отличаются, и тогда — если работаете со старыми проектами, приходится иметь их под рукой.
На данный момент на рынке мобильных устройств умирает именно windows phone
Я не пользовался windows на телефоне, но мне нравился симбиан больше чем андроид. Так что мне обидно что некоторые производители перешли на него.
Ну и требует поменьше…
предметно говорите. Что именно из зависимостей вам нужно в linux и не нужно в win, на какой файлик вам ругалась сборка?
Я прекрасно знаю какие вещи я трогать не буду в своём проекте, и могу не устанавливать их — и Windows не будет проверять всё ли я правильно собрал и все ли версии подходят друг к другу.
Несколько установленных версий студии решают проблему. Иногда у них ещё компиляторы немного отличаются, и тогда — если работаете со старыми проектами, приходится иметь их под рукой
В-первых, одна только 17-я студия весит ~15 гигабайт. Английская локализация — еще 2 сверху (как это вообще возможно?!). Во-вторых, у вас либо весь проект собран одной версией студии, либо он не работает ибо у студий каждая версия бинарно несовместима с предыдущей, причем даже минорные релизы. А пользоваться компилятором без полной поддержки даже с++11 — hell no. Доходит до абсурда — порт линуксового gcc в win, mingw, обладает более полным покрытием современного с++.
А вы знаете сколько весит Qt с полным функционалом? Разрабатывать программы и бояться лишних 15 гигов?
Про совместимость уже было…
Всё? На все файлики ругается сборка, и ни на один не ругается Windows, примерно так.
До такого меня жизнь не доводила…
Про совместимость уже было…
Что именно из зависимостей вам нужно в linux и не нужно в win, на какой файлик вам ругалась сборка?
Всё? На все файлики ругается сборка, и ни на один не ругается Windows, примерно так.
порт линуксового gcc в win, mingw, обладает более полным покрытием современного с++.
До такого меня жизнь не доводила…
А вы знаете сколько весит Qt с полным функционалом? Разрабатывать программы и бояться лишних 15 гигов?
Про совместимость уже было…
Знаю:
linux:
Комплект Qt 5.9.2 gcc_64 387 MB
win:
Комплект Qt 5.9.1 msvc2017 — 3.4/5.4 GB для 32/64 бит.
Комплект Qt 5.9.1 mingw53_32 — 3.8 GB
Напомню, что gcc/mingw обратно совместимы и для нескольких версий компилятора достаточно одного комплекта Qt. Плюс, Qt сам по себе backward compatible.
Всё? На все файлики ругается сборка, и ни на один не ругается Windows, примерно так.
Это значит, что вы не умеете писать кроссплатформенный код
Комплект Qt 5.9.1 mingw53_32 — 3.8 GB
А все остальные комплекты? А функцинал старых версий?
Это значит, что вы не умеете писать кроссплатформенный код
Это ещё без своего кода, это сама библиотека.
Чисто для информации
Моя первая ide (ну, первая после делфи) весила 50 гигабайт. 20 редактор и инструменты для графики, ещё 30 — пакет всех предсобранных библиотек которые могут понадобиться + инструменты анализа кода и автоматизации работы с гуи.
Так что студию я устанавливать уже не боялся. Как и несколько других ide в нескольких версиях.
И Qt (всё ещё не полный) весит у меня больше 20.
Моя первая ide (ну, первая после делфи) весила 50 гигабайт. 20 редактор и инструменты для графики, ещё 30 — пакет всех предсобранных библиотек которые могут понадобиться + инструменты анализа кода и автоматизации работы с гуи.
Так что студию я устанавливать уже не боялся. Как и несколько других ide в нескольких версиях.
И Qt (всё ещё не полный) весит у меня больше 20.
А все остальные комплекты? А функцинал старых версий?
А зачем больше одного комплекта если они бинарно совместимы? Изменения в API Qt обычно несущественны и код, написанный в рамках одной мажорной версии, переносится сравнительно легко. Это с msvc надо брать 32/64 битные версии для 12-й, 13-й, 15-й и 17-й студий. Вот и выйдет 25+ Гб. На линуксе, как я уже сказал, достаточно < 400 мб.
Это ещё без своего кода, это сама библиотека.
Пользуйтесь нормальными библиотеками.
Моя первая ide (ну, первая после делфи) весила 50 гигабайт
а сейчас для всего этого достаточно около 2 гб, но только на линуксе. The future is now, old man
Глянул на дисках — студии меньше весят.
Сейчас у меня 136 гигабайт заняті под разные ide — и я могу разрабатівать что угодно, это инструменты от тех что отображают регистры ассемблера и всё руками надо двигать — до инструментов собирающих ресурсы компьютерных игр автоматически по нажатию кнопки. Хоть сборку для девелоперов свою делай, честное слово… А вот на линуксе больше половины этих программ и sdk не работают.
Ну к чему я это пишу — разработчик 15 гигабайт жалеть не должен. И кстати, заодно глянул — комьюнити эдишн последней студии весит в разы меньше.
Сейчас у меня 136 гигабайт заняті под разные ide — и я могу разрабатівать что угодно, это инструменты от тех что отображают регистры ассемблера и всё руками надо двигать — до инструментов собирающих ресурсы компьютерных игр автоматически по нажатию кнопки. Хоть сборку для девелоперов свою делай, честное слово… А вот на линуксе больше половины этих программ и sdk не работают.
Ну к чему я это пишу — разработчик 15 гигабайт жалеть не должен. И кстати, заодно глянул — комьюнити эдишн последней студии весит в разы меньше.
когда я последний раз ставил студию, установщик участливо сказал, что займет 15 гигов на диске. И поверх этого попросил еще больше гигабайта на английскую локализацию.
Но это не значит, что у конкретно этих программ нет аналогов. И тем более, это не значит, что на линуксе нет аналогов лучше.
А вот на линуксе больше половины этих программ и sdk не работают.
Но это не значит, что у конкретно этих программ нет аналогов. И тем более, это не значит, что на линуксе нет аналогов лучше.
Современный линукс одинаково хорошо поддерживает работу как только с консолью, так и только с графическим интерфейсом (в том числе вообще без клавиатуры и мыши), а виндовс в роли догоняющего практически во всех кейсах, кроме типичного десктопа с графическим дисплеем, клавиатурой и мышью. Более того, Microsoft начала вводить чисто линуксовые вещи в свою ОС, начиная со своей реализации Linux Kernel для использования стандартных линуксовых текстовых интерфейсов.
Ещё раз — построить и запустить мой проект на с++ на линуксе с использованием только лишь гуи у меня не вышло. Располагая мышью и клавиатурой. Хотя в виндоусе я могу это сделать.
Что касается управления без мыши и клавиатуры — в виндоус уже есть, либо активно разрабатываются такие способы как управление через Neural Impulse Actuator, управление взглядом, управление через виртуальный слой экрана, управление голосом (настраиваемое и интеллектуальное), распределённое управление через помощника, управление пространственными манипуляторами и управление жестами… Кое что из этого (мало что) имеет полностью функциональные и не костыльные аналоги на линуксе (из того про что я знаю — только голосовые помощники) — и то они уступают в чём-то виндоусовым. Ещё бывает так что в магазинах и на сайте технологии пишут что вещь поддерживается и на линуксе, но если полезть на форум, то выяснится что люди не могут запустить или оборудование работает неадекватно. А иногда сообщество линукса подгоняет нужные драйвера и протоколы спустя 4-5 лет после выхода технологии совместимой с виндоус.
Что касается управления без мыши и клавиатуры — в виндоус уже есть, либо активно разрабатываются такие способы как управление через Neural Impulse Actuator, управление взглядом, управление через виртуальный слой экрана, управление голосом (настраиваемое и интеллектуальное), распределённое управление через помощника, управление пространственными манипуляторами и управление жестами… Кое что из этого (мало что) имеет полностью функциональные и не костыльные аналоги на линуксе (из того про что я знаю — только голосовые помощники) — и то они уступают в чём-то виндоусовым. Ещё бывает так что в магазинах и на сайте технологии пишут что вещь поддерживается и на линуксе, но если полезть на форум, то выяснится что люди не могут запустить или оборудование работает неадекватно. А иногда сообщество линукса подгоняет нужные драйвера и протоколы спустя 4-5 лет после выхода технологии совместимой с виндоус.
Ещё раз — построить и запустить мой проект на с++ на линуксе с использованием только лишь гуи у меня не вышло.
вам приходилось что-то менять в коде? А то 90+% msvc c++ программ проще переписать с нуля, чем превратить в стандартный c++.
Что касается управления без мыши и клавиатуры — в виндоус уже есть, либо активно разрабатываются такие способы как управление через Neural Impulse Actuator
вы говорите про политику 1-2х компаний из сотен
А иногда сообщество линукса подгоняет нужные драйвера и протоколы спустя 4-5 лет после выхода технологии совместимой с виндоус.
значит не надо
А ведь паренёк молодец, нашёл решение. Но зачем же писать его на линуксе?
А на чём писать? Если специально не заботится о кроссплатформенности, то, скорее всего, это решение можно будет запустить только на одной системе, какой бы целевая система не была. Причём в случае целевой Unix или Unix-подобной системы высока вероятность, что код будет рабочим и на других Unix-подобных (включая новые MacOSи, старые и самые новые Windows) без переделок. А если целевой системой будет код для Windows, то сбольшой вероятностью он будет Windows-only.
Лучше смотреть на код, и на языки программирования вообще так, как если ты просто берёшь, и пишешь. Не оценивая объём поддержки от сообщества, рыночную сумму оплаты и прочее. Вот тогда будет честная оценкаЧестная. Но бесполезная.
Перл и Дельфи им не нравятся? Да они просто не программировали на внутреннем языке программирования 1с бухгалтерии.
Понимаю, что в комментарии полно иронии, но должен всё-таки позанудствовать, что их сравнивать некорректно. 1с — проблемно-ориентированный язык, который применяется в одном месте для решения одной задачи. И программист 1с != программисту на том-же делфи или жаве. Система 1с — экспертная система со своим внутренним языком решения узкого сектора задач.
По поводу любви и нелюбви. На примере сайтов. Самыми нелюбимыми сайтами считаются Твитер и Фейсбук. Так, к слову :) Мало о чем сама по себе любовь говорит.
Perl, PHP, SQL (без TSQL) люблю и ценю. Вещи кроссплатформенные и довольно интересные.
Если у первого сфера применения довольно широкая, то у второго спецзаточка под веб.
SQL ценят даже ценителиприкладной проктологии 1С. Так что всем им еще долго и упорно работать в разных прикладных сферах. Рано все это дело хоронить
Если у первого сфера применения довольно широкая, то у второго спецзаточка под веб.
SQL ценят даже ценители
Среди огромного числа комментариев пусть потеряется ещё один. Perl — моя давняя любовь. Досадно видеть его в арьергарде. Но что поделать. Сам использую его в последнее время лишь для быстрого преобразования текстовых файлов. Под Windows у него нет конкурентов.
Sign up to leave a comment.
Какие самые нелюбимые языки программирования?