О применении C++ и других монстрами индустрии

Прикольная статейка на dev.by о тех языках программирования, что в реальной работе применяют:
dev.by/...​e-reddit-i-drugie-giganty

Как-то так получается, что это С, С++ и немного Python. B никаких суперсовременнх Go, Rust и т.п.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

www.oreilly.com/...development-salary-survey
The most common languages that respondents used in the past but no longer use were C/C++, Java, and PHP.

Все ушли на
Top languages currently used professionally in the sample: JavaScript, HTML, CSS, Java, Bash, and Python.

наскока я помню вояки это Ada в первую очередь
ну раньше так было во всяком случае
что характерно и в совке тоже

Плюсую, как-то общался с кодерами из французской armée de terre и они все занимались сишкой. У нас не знаю, в рф тоже хотят сишки

не фантазирую
натыкался на статью по военке в штатах, там Ada очень часто использовалась для всякой хрени в 80-х
сейчас может и на плюсах пишут

ну вот софт Ариан-5 на аде написан, и ничего так летает вроде
только не говори что это гражданка:)

www.seas.gwu.edu/.../ada-project-summary.html
особенно раздел „Military Applications” в самом конце

Ну и когда поднимешь Аду на микроконтроллере, коих там море, расскажешь.
Проблема не в Аде, которую на микроконтроллере поднять нечего делать, а в стиле кодирования. Чем-то она мне С++ напоминает со своими эксепшенами. Вон в том же F22 там такое нахеровертили на Аде, что софт без перезагрузки не работает и пары часов.

Для С++ есть JSF AV стандарт кодирования: www.stroustrup.com/JSF-AV-rules.pdf

Ада на АВР-ках без проблем. Ну кроме тех которые без ОЗУ вообще.

jobs.dou.ua
Java 179
.NET225
PHP 289
PM 100
C++ 85

ПМів тре більше чим приплюснутих!!!

Так они все на С++ проекты

Пользуясь случаем высокой концентрации специалистов по C++, хочу задать один чайниковский вопрос.
Нормально ли передать в функцию указатель, например на 10й элемент массива (ну вроде как slice получается), а потом, внезапно, в этой функции, используя этот указатель, обращаться к минус второму элементу этого slice?

Мне вот показалось, что это какой-то выстрел себе в ногу, но, может, я чего-то не понимаю?

Я портировал код с C++ на C# пару лет назад. Какой-то алгоритм компрессии написанный AT&T если мне не изменяет память. Вот там такого насмотрелся, что временами волосы на жопе шевелились. Вот с тех пор мучил вопрос, то ли я чего-то недопонимаю, то ли говнокод это.

Теоретически, если массив исключительно константен, хотя и очень некрасиво. Как и в C, собственно.
Чуть лучше, чем использовать goto.

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

Спасибо, сам бы не додумался, что это может быть нужно для оптимизации.

при чем здесь стек? Массив не на стеке передается. Нет абсолютно никакой разницы — передавать указатель на середину массива или на начало.

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

Садитесь, двойка. Массив в C и C++ — указатель на первый элемент. Указатель на непервый элемент — просто такой же указатель, со значением + n * sizeof(элемент)

Явно имелся в виду случай
void f(int *ptr) vs void f(int *ptr, int index)

Совершенно верно.

Массив в C и C++ — указатель на первый элемент.

Мы вам перезвоним.

Ну да, в С++ особые массивы и пахнут розами. Я вобще удивляюсь, как светлые сипипи эльфы снисходят до такой пошлой материи, как плебейский встроенный указатель.

Имеете в виду STL-контейнеры?

Еще один сколько-то-там-летний синьор неасилил array-to-pointer decay в сях?

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

c-faq.com/aryptr/aryptr2.html

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

comp.lang.c
Крестами даже не пахнет

Я про образ мышления (схоластический).

Никакого тумана и никакой специфики C/C++, такая ситуация была бы с любым языком, где понятие указателя на переменную некоего типа объединяется с понятием ссылки/указателя на массив или его часть. Это, считаем, все языки-современники, включая даже Pascal.

Более поздние языки от этого пытаются уйти и предлагают в качестве ссылки представление «слайса» массива в конкретном диапазоне индексов, это одновременно и надёжнее. Кстати, Fortran пошёл по этому пути практически независимо и раньше (слайсинг такого рода появился в нём в 80-х, стандартизован был afaik в F90).

Аргументы в функцию можно передать двумя способами:
1. Путем копирования самих данных
2. Путем копирования адреса этих данных.
Что реализовано на уровне ассемблера мейнстримовых процессоров и унаследовано высокоуровневыми языками.
Все остальное — ссылки, указатели, объекты не более чем различные названия одного и того же.

Этот твой спич не имеет никакого отношения к тому, о чём я говорил.
Слайсы всяких Fortran и Go это не просто адрес или копия данных, это объект, который контролирует доступ через себя и хак которого недоступен программисту. И он никак не может быть разложен на просто копию данных или указатель — если бы это могло быть, то защита была бы нарушена.

нет, это нарушает автономность данных, если передавать — то ссылку на всю дата стракчер + какой сдвиг нужно сделать относительно начала.

Передавать в функцию указатель на актуальные данные — норм.
А вот ездить указателем в обратную сторону — хреновая идея.

Зависит от кода. Мне например сразу видится парсер бинарного пакета.
Но тут неплохо бы приводить его к структуре.

А зачем в обсчете матриц?

Ну они как-то слишком упростили. Например dropbox не только питон (это интерфейс только), но и много Go + Rust для своих систем хранения ...

Статья написана в стиле КГ\АМ, хотя толика правды есть.
У нашого отделения одной громадной конторы, по моим субъективным очучениям, на клиент сайде 90% С++, остальные 10 — жаба под андроид, а на сервер сайде 90% скалы, остальные 10 ресерч на R да тулы на Go.

C++ is my favorite garbage collected language, because it’s generates so little garbage.
© Bjarne Stroustroup

If Java (or C++) had true garbage collection, most programs would delete themselves upon execution. — Robert Sewell

C++ - мультипарадигменный over-engineeted уродец.

There are only two things wrong with C++: The initial concept and the implementation

harmful.cat-v.org/software/c

Вот цитата, отлично характеризующая любителей с++:


If you like C++, you don’t know C++. There’s a mutual exclusion going on here, and I’ve yet to see a counter-example other than possibly a few of the members of the standards committee.
Взята из harmful.cat-v.org/software/c

Еще одна оттуда же:

C++ is a language strongly optimized for liars and people who go by guesswork and ignorance.

Вы бы еще бояны Торвальдса запостили. Слишком толсто, попробуйте тоньше.

А что не так с высказываниями Линуса о С++? Вроде не к чему придраться — все отлично аргументировано — harmful.cat-v.org/software/c /linus

все отлично аргументировано

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

idiotic «object model» crap

Забавно читать подобное после выхода ядра 2.6 с его kobject’ами и костылями ОО-на-сях.

Давайте разберем высказывания Линуса по частям:

C++ is a horrible language. It’s made more horrible by the fact that a lot
of substandard programmers use it, to the point where it’s much much
easier to generate total and utter crap with it.
Нечего добавить. Действительно, большинство „программистов” на С++ слабо в нем разбираются и пишут ужасный неподдерживаемый говнокод.
Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.
 Асболютная правда.
In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said „to piss you off”, but it’s actually true. I’ve come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn’t come and screw up any project I’m involved with.
Полностью согласен. C+±"программисты" любят уродовать и запутывать код с помощью сомнительных „фишек” C++:

— Не к месту использованных шаблонов. Привет Александреску :)
— Перегрузки операторов и методов.
— Наследования.
— Исключений.
— Implicit преобразование типов.
— Головоломных конструкторов с виртуальными деструкторами.

Очевидно, что, перейдя на другой язык программирования, эти горе-„программисты” будут пытаться внедрить свои „лучшие практики” из С++.

C++ leads to really really bad design choices. You invariably start using
the „nice” library features of the language like STL and Boost and other
total and utter crap, that may „help” you program, but causes:

— infinite amounts of pain when they don’t work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it’s not even funny)

— inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn’t very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.

Попробуйте опровергнуть эти утверждения по STL и особенно boost. Некий Джон Кармак тоже не очень доволен boost’ом:

It took 69 single steps to get past a BOOST_FOREACH() statement. Madness.

Saw comment // NEW BOOST CODE, and had a moment of panic before realizing it was vehicle boost, not C++ boost.

Идем дальше:


In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don’t screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don’t screw things up with any
idiotic „object model” crap.
Посмотрите на coding style любого успешного проекта на C++ — там вы найдете over9000 ограничений по использованию самых „полезных” фишек С++, перечисленных мной выше. Например, google chrome coding style guide.
Вопрос: зачем использовать С++, урезанный до уровня С?
If you want a VCS that is written in C++, go play with Monotone. Really.
They use a „real database”. They use „nice object-oriented libraries”.
They use „nice C++ abstractions”. And quite frankly, as a result of all
these design decisions that sound so appealing to some CS people, the end
result is a horrible and unmaintainable mess.
Где теперь этот monotone, написанный на „правильном” С++, а где git, „собранный из говна и палок”, как ошибочно полагают любители С++?

Своїми мердж-конфліктами...

:) да уж.. мерж конфликты негативный атрибут гита как системы хранения версий? больше никому такого лучше говорить не стоит...

Бажаю вам й надалі їх не отримувати...

Лол, я не один кто не словил мерж конфликта и в итоге пришлось фиксить одно и то же пару раз?))

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

хочеш побачити гівно? Спробуй TFS (;

Был ещё CVS он не поддерживал атомарность коммитов P4 по-моему их так до сих пор и не поддерживает процесс на «блокировке файлов» основан насколько я помню...

ЗЫ: чел заблочил на себя файл и ушёл приходит а его уже все ждут и всё... ))

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

Вот этот тезис

И весь нынешний хайп линукса держится только на том, что винда, начиная с 2000 года становилась только уродливее и хуже. И сейчас ее убожество сравнялась с убожеством линукса.
вызывает у меня один вопрос: если Вы действительно в IT уже несколько десятков лет, то все системы существующие сейчас наоборот должны выглядеть, как rocket science по сравнению с тем как это все начиналось?

Windows может и мастдай, но говорить что линукс — убожество? Хотел бы увидеть что такое не убожество в Вашем понимании.

Может поэтому кстати и проблемы с нахождением единомышленников и трудоустройством? Может просто поискать хорошие черты в окружающем и постараться самому сделать мир вокруг себя лучше?

Вы никогда не задумывались, что проявляя свои взгляды публично в стиле «то говно, это говно, а это еще хуже» Вы просто изливаете свой депрессивный взгляд на мир в целом
Это не баг, это фича!
Windows может и мастдай
но говорить что линукс — убожество?

Если Windows мастдай то Линукс десктоп маст_нот_би_борн. Узбагойтесь уже, линукс хомячки. Ваша ОС годится только для задротов или просмотра котиков в интернете. На ней нет ни нормальных программ, ни игр, ничего. Кроме того она сама по себе бывает не работает как надо.

она сама по себе бывает не работает как надо.

а как надо расскажи? а то может использую неправильно. уже 12 лет работает и вроде как норм.

После плясок с бубном может и работает, да. Но если нужна ОС которая работает по дефолту то линукс не подходит. Вообще пытаться сравнивать эту поделку с тем что делают корпорации это смешно.

аххахаха. а можно поинтересоваться кто делает линукс? и что конкретно делают корпорации?

Какой именно дистрибутив интересует? Впрочем все из них делаются контрибюторами или малой командой, т.е. школотой.

и что конкретно делают корпорации?

Хорошие и мощные ОС: Windows, OS X, Android, iOS. Покажите хоть один пример где бы компании использовали убунту вместо винды или ос х, или же покажите где ваш линукс десктоп, какой там процент рынка? 0,001%?

Вот убунта может ставится даже на мобайл, но кому это овно нужно?

Мир полон сюрпризов ;)

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

www.google.com/...corporations contribution

В ядро контрибютят в основном сотрудники корпораций, иногда под своим частным аккаунтом. Иногда работая в аутсорсе. Сюрприз! Иногда даже в Украине!

а также первой строкой здесь
en.wikipedia.org/...ndroid_(operating_system

По сути каждый андроид телефон это адаптированное линукс ядро с адаптированным libc с Java рантаймом вокруг.

Лень перечислять, но ты бы удивился как много электроники вокруг использует linux. В нормальных странах где принято за софт платить, а особенно в корпоративном секторе linux desktop достаточно распространен.

Не сравнивайте Андроид с другими поделками линуксоидными. Андроид сделан корпорацией, потому он и является хорошей ОС. Да, ядро там линуксовое но поверх там разработки корпорации Гугл.

По сути каждый андроид телефон это адаптированное линукс ядро с адаптированным libc с Java рантаймом вокруг.

По сути Андроид это куча проделаной работы и улучшения ОС продолжаются. Не сравнить с овноподелками линуксоидов типа убунту мобайл.

но ты бы удивился как много электроники вокруг использует linux

В качестве ядра или сервера — да.

В нормальных странах где принято за софт платить, а особенно в корпоративном секторе linux desktop достаточно распространен.

А как понять «достаточно»? Сколько это? И пруфы.

Окей, а RHEL тоже гаражная поделка? А Ubuntu Server, который во многих облаках используется как основная ОС и для инфраструктуры и для клиентских инстансов?

Друже, не трать время. Этот — необучаемый.

Хорошие и мощные ОС: Windows, OS X, Android, iOS

Интересно, на чем основан Android?

При чем тут основано. Там поверх того столько работы сделано что никакой кучке школьников не сделать за всю жизнь. Одно только SDK.

Я каждый день использую некий Goobuntu — так же как и еще пара десятков тысяч сотрудников этой же компании.

Вы что не знаете — Linux пишет один Торвальдс, сидя по ночам в темном сыром подвале.

И табун школоты комитящей овнокод. Без корпораций ничего хорошего не делается.

Не знаю, windows 10 выглядит симпатично и работает быстро. Я вообще не очень задрот ОС, мне многого не надо от них, по крайней мере сейчас, потому всю ее и не пощупал еще. Но общее впечетление хорошее. По крайней мере не надо трястись будет ли у тебя программа нормально работать как при линуксе.

Последний, действительно продуманный и удобный интерефейс был — это win95

ээх. тогда и девки были горячее и ... ого-го...

это win95 (тогда реально продумали юзабилити).

Версии от Win95 до Win2000 включая оба конца — это IBM CUA. Потом начали от него отходить. В качестве простейшего примера — жёсткое требование делить в настроечных диалогах OK и Cancel сменилось на «Close, а если вы не хотите сделанные настройки, то сами виноваты, что не запомнили, что было раньше». Зато ближе к жизни — как на реальном приборе: сдвинул ручку и опаньки.

Одна подобная волна бреда уже прошла, когда всех понесло рисовать разные извращенные окошки, молодежь этого не застала уже.

Они все ушли на мобилки :)

Xerox в виде Palo Alto Research Centre это самая общая концепция рамочек на экране и попадания в них событий.
А CUA это уже конкретные требования в виде кнопочек, оформления меню и т.п.

Xerox в виде Palo Alto Research Centre это самая общая концепция рамочек на экране и попадания в них событий.
У них были вполне рабочие реализации — Alto, Star, позже DR GEM (c которым уже судился Джобс на предмет кто у кого что украл).

Я имел в виду, что реализация W95-2000 с Xeroxʼовской имеет общее только такое.

Но вообще вопрос интересный — кто первый придумал и стандартизовал основные элементы UI — модальные диалоги, те же наборы кнопок «Ok — Cancel», радиобаттоны-чекбоксы-листбоксы, меню, хоткеи доступа к элементам. Необязательно, кстати, графические — на алфавитно-цифровых терминалах без мышки оно тоже ж существовало.

Чекбоксы и радиокнопки существовали ещё давно на бумаге, американцы одними из первых осознали их удобство для заполнения форм :) Потом просто перенесли в компьютер, как только стало возможно.
OK/Cancel, мне кажется, очевидно.
Модальность — близко к очевидности.
Меню — в нынешнем графическом виде это уже вытвор, кажется, таки Xerox.
Hotkeys — явно из собранных пожеланий пользователей.

на алфавитно-цифровых терминалах без мышки оно тоже ж существовало.

Да. Там было, например, световое перо.

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

мой опыт работы с linux на десктопе: напомните мне пожалуйста что такое драйвер и что такое вирус?

:) Виктор, это был сарказм. Что такое драйвер я в свое время читал в LDD, а не на википедии. Все страшилки про то что linux не поддерживает железо, да еще и на обыкновенных рабочих станциях были актуальны лет 15 назад.

Смысл сказанного был в том что все эти годы у меня не было необходимости ни искать драйвера ни бороться с вирусами.

В той же убунте при установке достаточно в инсталляторе поставить «install 3rd party packages».

Вот пару глюков(все не буду вспоминать ибо лень) с убунтой которые я словил за короткий период:

1. в хроме артефакты
2. пропадал звук, причем так что приходилось перезагружаться. Теперь сидя на винде 10 я не нарадуюсь как я могу легко переключать звук с наушников на колонки(там hdmi к экрану в котором колонки).
3. алерт вылезал регулярно о том что что-то нае.нулось, при чем я то ничего не трогал такого.
4. после обновления с 14 на 16 пришлось переставлять систему, так как начались разные алерты о сбоях
5. некоторые сторонние программы очень хреново работали. Апворк ап только на 16 после переустановки запустился
6. артефакты в джава айдишках, мелкие но не очень приятные как выделение жирным цветом некоторых файлов в експлорере

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

И стоит заметить что это я ж еще ничего такого не пробовал как работа с несколькими мониторами или прочие продвинутые фичи. Один раз попробовал эту линукс поделку что под ОС Х косит, так в ней айдишка вообще не запустилась а тупо комп зависал.

Я ж не говорю, что linux идеальная система для всех. Не подходит, ну.. не сложилось. Я оспариваю тезис о том что linux говно в целом.

Ну, то что линукс говно в целом, нужно же набрасывать как то, а то не в доу стайл будет)

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

В целом линукс десктоп это просто другой уровень, уровень пониже. Ну не может групка девов конкурировать с Microsoft ом. Но у него есть плюсы — бесплатная и легкая.

Мне вот более интересно сравнение линукс и виндовс сервера. Шарп теперь официально кроссплатформенен и было бы забавно понять какой профит от юзания виндовс сервера лицензия на который стоит от 500 дол. Все что я слышал так то что в том сервере все хорошо настроено и не надо дрочить консольку.

Шарп еще с хадуп зоопарком научился работать)

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

а уменя полный список то же на win 10 наблюдалося. я уж молчу про апдейт с win 8. а еще было автовыключение какждые 5 минут неактивности(с выставленными настройками на 1час) — никто ни на SO ни в поддержке win/lenovo не смог помочь.

а у меня hdmi аудио отпадает при уходе ноута в сон и звук вместо наушников которые в монике идет на колонки ноута, чем бесит сидящих рядом коллег.
а на домашний десктоп 7 винда вообще не встала, падала с синим экраном на этапе установке, какой-то конфликт с видеокартой, а дебиан стал нормально.

следую твоей логике я должен теперь ходить и говнять винду повсюду.

деталей уже не помню, но до установки драйверов дело не доходило. Тогда гуглил, писали что из-за карты, я тогда забил и остался на XP :)

сборка ядра от редхата мамку поняла
редхат патчит ядро, насколько я помню.

может то криво взломанная «семерка» была?)

хз, надо еще попроблвать как то, а то на хр стремновато сидеть
но мне бы вот кто нибудь подсказал что делать с этим:

hdmi аудио отпадает при уходе ноута в сон
и не поднимается при выходе
напомните мне пожалуйста что такое драйвер и что такое вирус?

Драйвер — это такая штука, без которой когда-то под линуксом у меня не завёлся USB-ADSL модем. Под виндой всё было, разумеется.

USB-ADSL модем.
Он же «винмодем», он же «софтмодем», он же тупенький ЦАП-АЦП с наглухо закрытым API и реализацией всего через наглухо же закрытый софт.
Помню, как же.

Мне как пользователю никакой разницы, что там внутри. Важно, что под виндой работает, а под пингвином нет. И с учётом «разницы в весе» это проблема пингвина, а не модема или винды.

Так я и не спорю. Когда винды было 95%, а доля линуксов и маков терялась в статпогрешности, это было вполне логично.

Это как сейчас с винфонами — андроид+иос те же 95%, никто портированием на вин не заморачивается. Что впрочем не говорит что ОС плохая в обеих случаях.

Ваша ОС годится только для задротов или просмотра котиков в интернете. На ней нет ни нормальных программ, ни игр, ничего. Кроме того она сама по себе бывает не работает как надо.

media0.giphy.com/...a/aSTJbOerwCKqc/giphy.gif

в топіку можна проводити перепис неосиляторів

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

Ви самі підтвердили тут що лінукс не дотягує до віндовса, бо з ним треба осилювати ще щось замість просто користуватися як білі люди.

еммм.... де?

Именно баги и быть готовым их фиксить своими ручками, перерыв пол инета до этого.

Можно подумать винда — это поляна одуванчиков. Юзеры линукса уже забыли (а некоторые и не знали никогда) о том что такое BSOD, так что не нужно про баги.

И попробуйте, поймав BSOD, найти его точную причину в ивент логах, а потом нагуглить как ее пофиксить — никакой поиск солюшена для линуксового бага имхо не сравнится с этой болью и унижением. Если для линукса вы выбираете из решений разной степени адекватности, то для винды 99 из 100 солюшнов — это «обновите драйвера» в той или иной форме, которые конечно же помогают, как ежу футболка.

2. Жрет много памяти, на уровне теперешнего КДЕ.

аж цікаво стало, скільки жере теперішній КДЕ.
плазма 5.8.0 — в холодному старті 590 Мб.

вінда же (7, 8.1, 10) в холодному старті одразу більше 1Гб жере

швидше за все тормозило через графіку, в віртуалці графіка не дуже добре працює

Лінуксова графіка взагалі не дуже добре працює

тут мова йшла про особливості роботи графіки в віртуал боксі, це перше.

графіка на лінуксі працює чудово, на всіх іграх, які запускаю в лінуксі і запускав під віндою (він10), в лінуксі фпс на 20-30 вище, це друге.

на всіх іграх, які запускаю в лінуксі і запускав під віндою (він10), в лінуксі фпс на 20-30 вище, це друге.

Ахахаха це ви жартуєте так, напевно?)) Пробував на двох відеокартах — амд і інтел, все працює просто жахливо в питаннях ігор. Крім того бажить по чорному.

амд
ясно.
в мене ж відеокарта geforce

Що ясно?) Що лінукс не вміє працювати ні з амд ні з вбудованими сучасними інтел відеокартами?)

в мене ж відеокарта geforce
це вас спасає від того що далеко не всі ігри портовані на лінукс а якщо і портовані то методом чисто щоб було? Це ж треба нести таку херь що лінукс підходить для геймінгу.

Ви про що взагалі розповідаєте? Що саме ви маєте на увазі, коли використовуєте слово «графіка»?

Айдішки в лінуксі у мене мали артефакти. Потім ігри тормозять. Потім хром також мав артефакти, які дуже бісили. Потім в лінуксі нема аналогічного графічного редактору як фотошоп в віндовсі. Потім і простого хорошого як пеінт нена. Це те що моя скромна персона помітила. До речі згадав не все, там ще щось було з графічними артефактами. О, одне важливе забув — в одній із дистрибутивів айдішка взагалі не запустилася а зависла, потім прогуглив що проблема з версією гтк, коротше йдемо лісом.

в кедах точно так само, є хоткей, яким можна виключити всі свистілки

. Если для линукса вы выбираете из решений разной степени адекватности, то для винды 99 из 100 солюшнов — это «обновите драйвера»
ще можна переусановіть Вєнду, теж помогає в 99 випадках із 100,
Про вірусню і антивірусню що тормозять комп чомусь не згадуютью.
Ядро от красной шапки мое железо поняло, я ядро от бубунты нет
ядро лінукса і там і там, може версії різні?

недавно апгрейдил старый сервак с генто. Был в шоке что некотыре вещи застряли в 2005 году, типа инсталлер ихний и репозиторий в котором хранится одна версия пакетов. Если пакет имеет баг, а уменя таки один пакет имел баг известный аж с 2010 года, то ничего не компилится вообще, и в репо ничего другого нет. приходилось все качать и ручками ставить, так оказалось что разные пакеты пользуют разные пути и пути нада тоже ручками задавать в конфиге. Вообщем жесть еще та, я думал что все уже как у убундту — гет инсталл и поехали, а оказалось что нет

Тут много «неокрепшей» психики в виде боевых жуниоров и они просто могут получить неправильную установку.
єто Спарта!!
git г-но
git прекрасен
після мержа: «git прекрасне г-но»

Каждый раз когда вижу такое мнение, это обычно означает что у человека просто было недостаточно опыта работы с гитом. Он... сложен, наверное, для вхождения... и больше подходит для работы с языками где можно быстро и много кодить логики полезной для бизнеса, а не барахтаться с мемори ликами и/или прочими низкоуровневыми проблемами.

Когда нужно в один день запрограммировать несколько фич, пофиксить несколько багов, и на проекте есть нормальный процесс с бранчеванием и пул реквестами (в идеале github или stash/bitbucket), разумной альтернативы гиту мало.

Когда я гуглю как сделать что то в гите и нахожу в теме 20 вариантов реализации то как то не кажется гит таким уж хорошим. Кроме того именования у него странные, т.е. логика, что произойдет при такой то команде и такой, это достаточно сложно понять. И почему то мне кажется что это следствие .овняной архитектуры. Имхо, ибо другие не пробовал еще.

Я написал сверху.. вхождение в гит требует небольшого напряжения :)

рекомендую посмотреть на learngitbranching.js.org. большинство вопросов отпадает сразу.

Еесли работать самому или в команде из 2 человек, то прелесть гита трудно будет оценить. Чем больше команда/лучше процессы и чем более высокоуровневый язык, тем больше ощущаешь преимущества.

Ну и ... сравнивать с системами типа SVN/CVS... вообще нелепо, ибо при адекватных размерах проекта не-распределенные системы использовать невозможно вообще.

вхождение в гит требует небольшого напряжения :)

Этим можно «оправдать» любую систему с проблемами. Типа тратим +х времени и все стает ок. Это да, но сама суть.

За линк спасибо.

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

Не вижу, чем это отличается от просто пуша какой-то ерунды.

Альтернатива гиту есть и не одна, но маркетологи пропихали именно гит

Маркетологи чего?

Не вижу, чем это отличается от просто пуша какой-то ерунды.
Тем, что пуш изнутри интерактивного ребейза — заведомо некорректное действие.
Маркетологи чего?
Гита.

А чо, «с сегодняшнего дня для ядра мы юзаем гит, а несогласные могут писать в спортлото» — клёвый маркетинговый прием уровня майкрософта.

Тем, что пуш изнутри интерактивного ребейза — заведомо некорректное действие.

Если какие-то коммиты считаются уже готовыми (несмотря на очередь за ними) — что некорректного?
А если это push во временную ветку для показа коллегам «я не знаю, что тут делать, помогите»?

Не надо решать административные проблемы техническими методами.

«с сегодняшнего дня для ядра мы юзаем гит, а несогласные могут писать в спортлото»

Так а кто вас заставляет для всего использовать средство для ядра? :)
А для ядра он использован потому, что банально удобнее.

Если какие-то коммиты считаются уже готовыми (несмотря на очередь за ними) — что некорректного?
Нет, не считаются. Предполагается редактировать текущий коммит и некоторые последующие.
А если это push во временную ветку для показа коллегам «я не знаю, что тут делать, помогите»?
Не-не-не, закончить ребейз, а потом уже пушить в эти ваши временные ветки.
Так а кто вас заставляет для всего использовать средство для ядра? :)
Заставляет толпа фанбоев, которые считают, что гит — это единственная в мире DVCS. Самое смешное, что эти же самые фанбои будут доказывать, что винда не единственная ось для ПК.
А для ядра он использован потому, что банально удобнее.
Вы просто не пробовали альтернативы (mercurial).
Нет, не считаются. Предполагается редактировать текущий коммит и некоторые последующие.

Или не редактировать текущий.

Заставляет толпа фанбоев, которые считают, что гит — это единственная в мире DVCS.

Мне плевать на фанбоев. Я не считаю, что единственный. Я считаю, что для меня он лучший.

Вы просто не пробовали альтернативы (mercurial).

Ваши домыслы на ровном месте чётко показывают Вашу ангажированность. Я его пробовал. Я с ним работал. Потом расплевался и больше не хочу — этот сплошной идиотский мозговыверт с отсутствием базовой нужной мне функциональности непригоден ни для чего, как сделать checkout и забыть.

На битбакете меркуриал, не надо тут.
там и гит насколько помню есть.
или его уже убрали с битбакета совсем?

Нікуди його не заберали. Є там гіт.

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

Краткое содержание всех комментов)

— команды многословны слегка
— некоторая опасная нелогичность, типа git checkout может просто переключить/создать ветку, а может стереть нахрен, что ты там писал полдня

а так да, неплох

Если не брать распределенность, то тот же subversion на порядок удобнее и продуманее
Советую mercurial. И распределенный, и интерфейс почти как у svn.

>убожество винды
>убожество линукса
Ты только что оскорбил труд тысяч своих коллег. Я уверен что ты даже не представляешь как это все работает. Книжки саттера и александреску прочитал и возомнил из себя умника.

Если не брать распределенность, то тот же subversion на порядок удобнее и продуманее.

SVN — выбредок, прошедший 1/3 пути в направлении нормальных SCM и сломавший при этом всё от старого, но не получивший нормально ничего нового. По сравнению с ним даже CVS удобнее. А Git — тем более.

До сих пор lapack и blas хотят fortran.

Просто нет смысла переписывать.

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

Я на FreeBSD с 2001-го :) и ничего, изначально удобнее винды.

Не так страшен Кастанеда, как тот, кто его прочитал.

ой та лайдно.
головне старатись не привертати увагу санітарів

большинство «программистов» на С++ слабо в нем разбираются и пишут ужасный неподдерживаемый говнокод.

на самом деле должно быть так

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

Аргументы по поводу языка будут или опять «вокруг все п-дрсы, один я Д`Артаньян»?

сомнительных «фишек» C++
Кстати говоря, ваша неспособность пользоваться инструментами является только аргументом на счет вашей же низкой профпригодности.
Попробуйте опровергнуть эти утверждения по STL
and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it’s not even funny
Чувак даже не понял, что STL идет в комплекте с компилятором, как часть стандартной библиотеки, что уж можно говорить о его знании плюсов?
inefficient abstracted programming models
Ни цифр, ни чего. Одно трепание языком.
Некий Джон Кармак
Опять апелляция к авторитетам. И как обычно аргументы уровня «ниасилил, значит не нужно».
Посмотрите на coding style любого успешного проекта на C++
Критерии успешности?
Где теперь этот monotone, написанный на «правильном» С++, а где git, «собранный из говна и палок», как ошибочно полагают любители С++?
Причем тут маркетинг к программированию? git был протянут на популярности ядра, прямо как винда на популярности PC.

И при этом git г-но. Ужасный командлайн интерфейс (checkout резетит working directory, reset очищает подготовленные к коммиту файлы, checkout -b создает бранч --- где логика?), множественные возможности отстрелить себе ногу (запушить ветку в процессе rebase? запросто!), отсутствие постоянных бранчей, нелогичное разделение на stash и staging area и так далее. Но правильный маркетинг — и опля, этим поделием пользуются и даже говорят, что вкусно.

P.S.

Привет Александреску :)
А сколько вам лет? А то ваше трепетное отношение к собственным кумирам и показушное презрение к другим как бы намекает на первый-второй курс универа. Я угадал?

Мосье, а сколько лет вам, и в каких языках кроме крестов имеете практику? Ибо смахивают ваши откровения наhttp://lurkmore.to/%D0%A1%D0%B8%D0%BD%D0%B4%D1%80%D0%BE%D0%BC_%D1%83%D1%82%D1%91%D0%BD%D0%BA%D0%B0

C и С++ весьма отличаются по парадигме, особенно сейчас.
Но меня больше интересует господин 23-летний синьор, который не знаком с передачей аргументов по указателю.

На совеременном этапе нет необходимости создавать монуметнальные произведения на каком-то одном языке. Куски на С склеиваем Питоном и ставим клиентом под сервер на Джаве.
И суммарно получаем месте скорость С с гибкостью Питона и устойчивостью Джавы.
Волочь за собой весь темплейтный мусор, чтобы написать утилитку на 100 строк, как это предлагает С++ не надо.

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

ликвидировалли это багу от рождения
Заменили простое и ясное — «на каждый malloc по free», на кучу смартов, у которых у каждого свои особенности и потенциальные уязвимости.
Басня дедушки Крыладзе «Тришкин кафтан».
Вот тот же Go намного умнее спланирован — простенький синтаксис, встроенная многопоточность и сборщик мусора. И он таки крестового динозавра убьет.

Go это Docker, и как подсказывают здесь Dropbox. Скорость компилируемого языка при простоте и гибкости скриптового. Удобнее чем С, быстрее чем Питон, легче чем Джава. Экологическая ниша очерчена весьма четко.

Го — синоним говно.
сумнівне твердження,
на відміну від С і С++ він по визначенюю розпаралелюваний і багопоточний, без сторонніх бібліотек, і до того із GC та і може підключати С файли/бібліотеки.

Го не один такой

на відміну від С і С++ він по визначенюю розпаралелюваний і багопоточний, без сторонніх бібліотек,
а erlang/elixir многопоточен по дефолту, вместо обьектов оперируешь акторами, которые выполняются в разных потоках по дефолту(при желании, можно указать, чтоб выполнялись на одном)

в ерлангу спрацьовує «куяк куяк і всі довольні» (актори з реакторами)

сумнівне твердження, на відміну від С і С++ він по визначенюю розпаралелюваний і багопоточний, без сторонніх бібліотек
C11 и C++11 тоже многопоточные без сторонних библиотек

en.cppreference.com/w/cpp/thread
en.cppreference.com/w/c/thread

до того із GC
Язык с GC в 2016ом году — моветон.

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

Да да да ,
пару лет меня принудительлно подскадили на питоне питонить...

Блин, к этому идиотскому синтаксису, где границы блока опредеяются колл-вом пробелов/табов с начала строки, я так и не привык. Хотя есть в питоне и свои удобности.

Кстати, портировал как-то движок GNU Backgammon c C на C++, получилось короче и проще. На Java/Scala еще короче.

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

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

Но меня больше интересовало удобство разработки

А не писать функции на два скролла слабо?
Это кстати любого языка касается, просто смартпоинтеры создают опасную иллюзию безопасности такого подхода.

А не писать функции на два скролла слабо?
Задайте этот вопрос опенсорсным С писателям. 2 скролла — это было очень скромно еще. Я замахался это в подобие божеского вида приводить.

Безотносительно противостояния с крестами, просто ремарка: Go спроектирован ужасно.

Обширная тема, и я давно хочу написать по ней пост, но если вкратце, то очень хорошо плохой дизайн языка виден на примере функций GetEnv и LookUpEnv. Они обе предназначены для получения значений переменных среды, но GetEnv возвращает строку, которая будет пустой в случае отсутствия такой переменной, а LookUpEnv возвращает кортеж из строкового значения и булевого флага, сигнализирующего о том, найдено ли значение. Зачем же понадобились две функции для выполнения одной и той же задачи? А понадобились они потому, что обработка ошибок в стиле Go слишком многословна. Поэтому, в дополнение к идиоматичной, но неудобной LookUpEnv сделали уродца GetEnv, который возвращает валидное значение в случае ошибки. Можно было бы назвать это частным случаем, но такой подход проистекает из общего плохого дизайна языка. Правильным решением этой конкретной задачи были бы опции, но опций в Go нет и не будет, потому что нет дженериков. Та же история и с типами Result/Try. И из-за этого обработка ошибок в Go обладает целым списком фатальных неодстатков:

  • Возможность обратиться к полю кортежа, которое неопределено. Возвращать кортеж для сигнализации об ошибке — несусветная глупость, потому что в нём всегда валидно только одно поле, а возвращаются сразу два
  • Проигнорировать наличие ошибки проще, чем проверить
  • Необходимость наличия в языке такой пакости, как нулевые указатели для маркировки неопределённого значения
  • Общая многословность обработки ошибок.
Возвращать кортеж для сигнализации об ошибке — несусветная глупость, потому что в нём всегда валидно только одно поле, а возвращаются сразу два
io.Reader может вернуть одновременно ошибку и ненулевое количество прочитанных байт.

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

У Го нестандартный ABI. Я не представляю кто рискнет пустить эту зверушку в свой зоопарк.

А в чем собственно проблема?

В усилиях на интеграцию в существующие системы.

А в чём собственно нестандартность? Речь о его внутреннем ABI или о требованиях на связь с другими языками?

У каждой системы есть свой стандартный ABI. Или несколько как у винды. Во большинстве студенческих поделок типа Го на него или на них положен болт. В результате ты можешь без каких либо проблем импортить из Ады в Яву. Или наоборот. Но в случае с Го в лучшем случае получится выкрутится при помощи «прослойки» FFI. Или не получится. Это делает масштабируемость хуже чем в С++. Тоесть в обозримом будущем Го для серьезных масштабных проэктов рассматриватся не будет.

For illustration: stackoverflow.com/.../call-go-functions-from-c

В результате ты можешь без каких либо проблем импортить из Ады в Яву. Или наоборот.

Не надо тут этих сказочек, все вроде взрослые. «Без проблем» можно «импортить» только между теми, кто работает в идентичной среде идентичными методами. Между Паскалем и Си, например (и то — пока не используется динамическая память так, что один аллоцирует, а другой освобождает). Или между C#, F# и VB.NET — все под дотнетовой машиной с общими подходами. Но чтобы вызвать что-то из Java за пределы логики её VM — в ту же Ada — нужно через JNI выйти из её контекста, с соответствующими последствиями (например, GC не будет анализировать стек треда в поисках первичных ссылок).

У Go в этом смысле самый обычный FFI, с учётом того, что он из GC среды переходит в не-GC, и наоборот. Подобные переходы — всегда проблема, ресурс каждого вида должен обрабатываться своим менеджером.

Тоесть в обозримом будущем Го для серьезных масштабных проэктов рассматриватся не будет.

Независимо от того, будет это так или нет, Ваше обоснование полностью некорректно.

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

Во всей вселенной пахнет нефтью ©

куча неисправимых недостатков, главный из них именно работа с указателями.
це фіча

Это у вас такой сарказм? Как-то сильно плоско.

— Не к месту использованных шаблонов. Привет Александреску :)
— Перегрузки операторов и методов.
— Наследования.
— Исключений.
— Implicit преобразование типов.
боюсь тебя расстроить, но все это — стандарт для большинства ОО языков — Java и c# тоже ненавидишь?

ОО — обьектно-ориентированные, а не процедурные

прошу прощения, провтык. есть функциональные же, где ООП и не пахло. правда,их как-то неохотно используют

OO це парадигмаю. і в асм. і С можна реалізувати ОО

Мне как-то попадалась на глаза книжка, как работать с COM в plain C. Махровейший мазохизм

а мені попадалась на очі книжка обжект орієнтед С
швидкий пошук в гуглі викинув таке
ooc-coding.sourceforge.net
чого нема так, Operator overloading і Function / method overloading
дихсн, не буде ран-тай поліморфізма

Ну я подобным и на асме баловался в студенческие годы, но в продакшене ну нафиг

На Си можно прекрасно писать в ОО-стиле. В каждом методе добавляется один параметр, первый, ссылка на структуру. Единственное с наследованием и инкапсуляцией немного сложнее.
Так что теже яйца.

Можно и руками таблицу виртуальных функций заполнять

С++ уже зашкварился с множественным наследованием от которого в шарпе отказались. Да и другие патерны с еаследовпнием стали многие под вопросом. Архитектуры с include и интерфейсами гибче

Я сторонник больше Poor C++.
Если к Си++ добавить весь тот зоопарк с шаблонами STL и тд, так лучше уж сразу менеджед язык джава или Шарп. Код чище и лучше.
Только без всего этого барахла Си как и Си++ прекрасен.

Си++ в котором из новых фич по сравнению с Си только ООП и возможно еще exception. Вот эти все STL и их дерьмовые реализации, к примеру std::map
github.com/...ray_Benchmarks_Ubuntu.txt
лучше бы совсем выпилили из С++. Поверь, там большинство «новомодных и современных фич» подобного качества.

Ну если в

map
хранить и искать ключи это «перевозить на запорожце цемент», то Ок. Просто я тогда не знаю что еще можно с ним делать и как мерять.

Но речь не об этом. То что творят с Си++, когда добавляют фичи пытаясь сделать из Си++ «почти менеджед безопасный» язык вполне смешно. Настолько смешно, что в этой гонке нередко Джава и Шарп заявляет что их код быстрее выполняется чем в Си++, и ведь бывают правы. А это ведь само по себе должно быть нонсенсом. Просто команда С++ заигралась в такие «улучшения».
Ну и тут правильно заметили что на тиобе Си язык почемуто популярней чем С++, тут я Торвальдса полностью поддерживаю. Хотя мог бы уже давно вынести Си за свою 35 летнюю историю развития.

Ну я тебе скажу что скорей всего буду переходить на Линукс и Убунту после 15 лет виндыобожания по крайней мере дома. Убунта уже достаточно зрелая на десктопе. Линукс тот что был пять лет назад и сейчас земля и небо. Убунта 16 сейчас на оба ноута ставится за 15 мин и намного более скромна в требованиях. Семерка у меня сейчас отжирает 10 гиг озу и нивадном глазу. Постоянно проц грузит на 30% и не могу докопаться до причины. А переставлять как-то лень все это.

Слухай ну как уже достало заезженое «у тебя чтото не работает — у тебя проблема с руками». Я могу тебе абсолютно тоже написать. У тебя не работает Линукс какието глюки с драйверами ? Проверь ровность своих рук, чтото недонастроил.

В Линуксе как видишь есть варианты. В Винде если что серьезно заглючило то только переустановка.
Но вернемся к нашим баранам.

Но последствия С в линухе — это постоянные дыры с переполнением буфера. В итоге это затыкают костылями и код становиться укуренный.

Ядро Виндовс тоже писали на дырявом Си. А заплаток в проприетарном коде еще в разы больше.

Какие варианты? Вот что то заглючило в ОС, что можно сделать? Я не про программы или драйвера, ибо их и в виндовсе можно переустановить и даже полегче и не надо левое ставить, а от самих производителей железа.

Такой халявы, как тиснул на кнопочку и всё работает в линухе нет.

Так это ж только лучше, по тыжпрограмисткому(сарказм)

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

Нет более тормознутой системы чем Винда с навешеными антивирусами. Под Линукс банально на порядки меньше вирусов пишут. Поэтому безопасность — слабый аргумент.

Нет более тормознутой системы чем Винда с навешеными антивирусами

1. на десятці антивірус вбудований, лайт версія. Більшого й не треба. А що значить антивірусами? Ви собі ставили декілька антивірусів на вінді? Ну тепер зрозуміло чому у вас вона глючила))
2. Все працює швидко. Подекуди швидше ніж в лінуксі. Про графіку думаю й писати не треба. А так, і про інші речі які під вінду написані краще.

Більшого й не треба.
Хакери задоволені вашим рішенням.
А так, і про інші речі які під вінду написані краще.
Угу, знаємо, проходили. Записати систему на флешку? Ой, без додаткової утиліти не можна. Ага, є безкоштовна утиліта, рекомендована МС. Ой, вона не вміє нові iso із UDF... Конвертація? Качай нову програму. А-а-а-а-а... dd це зробив би швидше й з меншими рухами.
Хакери задоволені вашим рішенням.

Якщо лізтм куди не треба і качати що не треба то вони завжди щасливі будуть. Хоча звичайно на лінуксі складніше їм і профіта менше бо кому нафіг лінукс десктоп здався(я про звичайних юзерів)

Записати систему на флешку? Ой, без додаткової утиліти не можна

Записувати системи на флешки це не та операція яку звичайні юзери роблять, і не та яка потрібна постійно. Тому не бачу складного поставити програму. Хоча може в десятці вже й вбудовано.

Ага, є безкоштовна утиліта, рекомендована МС. Ой, вона не вміє нові iso із UDF...

Хз про що ви. Я колись спокійно записав убунту на флешку з сьомого віндовсу. Але не памятаю, напевне не майкрософтською програмою. А от коли я на убунті хотів записати десятий віндовс на флешку то стандартна програма це не вміла, і взагалі важко було знайти щось що б це зробило. На щастя знайшов і воно навіть запрацювало(бо в лінуксі це норма коли щось не буде працювати, і ти підеш лісом)

Конвертація? Качай нову програму

Конвертація чого? Відчуваю що це теж не та операція що кожному бзеру потрібна.

dd це зробив би швидше й з меншими рухами

Ви ж не вважаєте що типовий юзер вмів би нагуглити і вбити правильні команди в консолі?

Мани? Я вас прошу, в інеті валом покрокових інструкцій. Для особливо-одарованих навіть є графічні утилітки.

Так в тому то й справа що щоб зробити щось раз в рік треба вичитувати ті інструкції замість зручної гуі програми. І типовий юзер таке не осилить.

Хоча звичайно на лінуксі складніше їм і профіта менше бо кому нафіг лінукс десктоп здався(я про звичайних юзерів)
Хакери задоволені вашим ставленням до безпеки та вашою оманою.
Записувати системи на флешки це не та операція яку звичайні юзери роблять
Для тих операцій, що зазвичай роблять користувачі, навіть віндовс не потрібна. Андроїда або iOS з головою вистачить.
Хз про що ви. Я колись спокійно записав убунту на флешку з сьомого віндовсу.
Ага, спробуйте на сьомці записати флешку з вісімкою. А я на вас подивлюся.
Конвертація чого?
ISO одного формату в інший. В той, який розуміє ота дебільна застаріла програма.
Ви ж не вважаєте що типовий юзер вмів би нагуглити і вбити правильні команди в консолі?
Ви не повірете, але це знайти легше в сотні разів, ніж знайти правильну програму, яка вміє без проблем записувати ISO файли не флешку.
Для тих операцій, що зазвичай роблять користувачі, навіть віндовс не потрібна. Андроїда або iOS з головою вистачить.

Цікаве твердження. Можливо й так. І тут вже постає питання чи потрібні пк взагалі, коли є смартфони і планшети плюс інші залізки для ігор і відео.

Ага, спробуйте на сьомці записати флешку з вісімкою. А я на вас подивлюся.

Ви напевно застряли в часі бо сімка і вісімка вже давно устарівші.

ISO одного формату в інший. В той, який розуміє ота дебільна застаріла програма.

Не зрозумів навіщо його конвертувати. Якщо в лінуксі якась дебільна програма не може записати ІСО то це вже проблема її. До речі в убунті вона таки і не записала десяту вінду. Прийшлося ліву гуглити і надіятися що не знати що запрацює. Помолився і все пішло ок.

Ви не повірете, але це знайти легше в сотні разів, ніж знайти правильну програму, яка вміє без проблем записувати ISO файли не флешку

Ахаха, гарний жарт. Я тут Ванга:

Сейчас пойдет про то что в гуи все якобы наоборот сложнее
Ви напевно застряли в часі бо сімка і вісімка вже давно устарівші.
Ви напевно з іншої планети й не знаєте, що в багатьох ще XP стоїть...
Не зрозумів навіщо його конвертувати. Якщо в лінуксі якась дебільна програма не може записати ІСО...
Ви напевно неуважно читаєте, мова йшла про Віндовс та рекомендовану MS програму.
Ахаха, гарний жарт
Зробіть запит в гугл «linux write iso to flash», в мене вже друге посилання на потрібні консольні команди. Гариний жарт, так? Ну давайте посміємося разом.
що в багатьох ще XP стоїть...

Це в країнах третього світу? Ну ок. Тоді інше питання — навіщо ставити вісімку коли є десятка?)) Вісімку яка ще й не дуже насільки я знаю.

про Віндовс та рекомендовану MS програму.

За 10 секунд легко гуглиться стороння гуі програма. Ще через хвилини вона вже закінчує записувати образ. А тепер зрівняйте з вивченням консольної лінукс програми про яку ще й треба знати. Я наприклад не знав.

Сейчас пойдет про то что в гуи все якобы наоборот сложнее

Проблема не клікати, проблема досягти результата. А коли вам програма каже, що неправильний iso-формат на msdn-івський образ, от тут навіть в мене починається когнитивний дісонанс.

От от. Вбудована програма на убунті мені саме так і сказала. Я трошки офігів і пішов гуглити щось ліве.

в C++ есть крутейшая фишка — шаблоны, ради которой только его и можно любить. дженерики в жаве и шарпе — слабая попытка имитации мощи шаблонов , мне их в джаве сильно не хватает

Ща прибегут гого-бои с криками, что дженерики не нужны

Это ничем не лучше и не хуже чем функциональное программирование в плане читаемости. Но ФП сейчас модно а плюсы поносят все кому не лень

Полноценное ФП не взлетит по причине специфики человеческого мозга.
не) причина не в человеческом мозге, а в том, что первый язык — это обычно что-то типа паскаля , пхп или джавы. т.е. до тех пор, пока первым языком для обучения будет какой-нить императивный или ООП-язык типа джавы или плюсов — функциональщина не взлетит. И специфика человеческого мозга тут ни причем ИМХО)
Для нас естественно алгоритм по шагам последовательно думать, именно так, как в нефункциональных языках программирования и сделано.
ну перед тем, как последовательно думать алгоритм, сперва нужно правильно сформулировать задачу и понять, что именно мы хотим получить в итоге (чтобы алгоритм получился правильный). И вот как раз для того, чтобы описать то, что нам надо получить — это прерогатива функциональщины)

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

---

Подчеркну, основная сложность функциональщины в том, что обычно у программеров первым языком был императивный (и чаще всего именно си-подобный), и он уже привык к ООП-мышлению и сишному синтаксису.
Думаю для начиначинающего программиста (у которого мозг еще не заполнен объектами и циклами) изучение что джавы, что лиспа будет одинаковым по сложности. Иначе как объяснить то, что в MIT долгое время курс по программированию вели на примере языка Scheme (диалект лиспа), а не на плюсах? Да и сам Scheme разрабатывался как для обучению программированию.

Преобразование функций от нескольких аргументов к функциям от одного


scala> val foo = (x:Int,y:Int) => x + y // функция от 2(ДВУХ) аргументов x и y.
scala> foo(1,2) // просто сложили и получили три
scala> val moo = foo.curried // получили функцию от 1(ОДНОГО) аргумента, которая возвращает
scala> val zoo = moo(1) // функцию от 1(ОДНОГО) аргумента
scala> zoo(2) // урраа! получили три
scala> // можно каррировать и так:
scala> def noo(x:Int, y:Int) = x * y
scala> val a = noo _ // получили функцию от 2-х аргументов
scala> val b = a.curried
scala> b(2) // = фунция 2 * аргумент
scala> b(2)(3) // = 6
Ну, я написал, как я вижу. В реальности, конечно тут нужны работы тех, кто с мозгом работает. Вот они могут сказать, что людям проще императив или функциональщина.
та можно совмещать. Это как изучение английского, вначале читаешь литературу заглядывая в словарь на каждом слове, потом оно както запоминаеться в памяти, и понятно уже без словаря.
Также и в фп видишь какойнить фолд на листе, и вначале нужно мозгом декопилировать в цикл чтобы понять что происходит. Потом с практикой мозг запоминает, и это делать уже не нужно.
Больше просто практики нужно.

Есть один характерный синдром (я не знаю общего названия, а называть именами одноклассников и сокурсников, которые им страдали, как-то не совсем красиво). В качестве примера лучше всего привести такую запись:

x = x + 1;

Тот, кто поймёт, что речь о изменении состояния среды исполнения в целом, осилит это. Кто не поймёт — останется неспособным что-то запрограммировать на императивном языке, как один мой одноклассник, который на все объяснения говорил, что это может выполняться, только если x бесконечно :)

В то же время если объяснять через функциональный подход — такому клиенту будет понятнее (а после того, как он понял, можно и объяснить императивную форму через последовательность функциональных состояний).

Да просто ’=’ матанов с толку сбивает, не зря в паскале ’:=’ юзают :-)

Нет, замена на «:=» или «->» (как в языке Рапира, целевая переменная — справа, а не слева) всё равно не помогала.

Та не тільки в паскалі, в XQuery теж

Хрена себе — Рапира. Я думал, динозавры на доу повывелись...

Логическое мышление в нашем мозгу однопоточно.
Неправда, подсознательное мышление как раз сродни VHDL. А это чистая многопоточность.
А вот пока, то что я слышал и видел, сознательный поток у нас один (вне зависимости от того, как там сигналы бегают по нейронам).
Кто как. Многие думают проговаривая про себя слова, чем затормаживают своё мышление, многие читают проговаривая про себя слова, чем занижают скорость чтения на порядок. Да мало ли ещё как люди себе вредят...
А программируем мы, используя сознание.
Судя по всему 90% вообще неиспользуют мозг при программировании, так что по сути это рудиментарный орган. Ещё 9% используют спиной мозг.

Но на VHDLях же как-то пишут.

а чо там писать, понімаєш RTL: куяк — куяк і в продакшен,

Патчить код хреново, он-то уже в камне высечен %)

так його ложать готовими ІР блоками, провіреними ще від часів Фарана

Патчить код хреново, он-то уже в камне высечен %)

Именно так. Поэтому разработчики пытаются драйверами хоть как-то заткнуть баги в железе. Была нашумевшая статья на эту тему, «почему ваш смартфон не получит апдейт ОС».

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

Распространено — см. хотя бы микрокод в процессорах. Бывает ещё интереснее: например, когда при инициализации контроллера драйвер должен каждый раз вливать программу работы в него, иначе не запустится. Возможно, это возникло в начале как средство обработать ошибки дизайна, но с тех пор зафиксировалось.

Распространено — см. хотя бы микрокод в процессорах.
На самом деле как выяснилось — это никакой не микрокод, а гигантская битовая маска, где выбирается конфигурация внутренних блоков, часто процессор имеет несколько вариантов имплементации одного и того же и этим «микрокодом» выбирается тот или иной блок, либо исключается из процессинга вообще.
не микрокод, а гигантская битовая маска

Тут бы хорошо URL, причём на особенности версий не позднее K8 и Core2. А то я вначале точно так же предполагал — про маски и поля конфигурационных регистров, но мне стали доказывать, что там местами есть и явные команды.
Вот рассказывают, что это таки код.

Тут бы хорошо URL, причём на особенности версий не позднее K8 и Core2.
Тут хорошо бы получить схематику процессора %) Какой URL? %) Просто за последний год я нашёл с несколько аппаратных багов на инженерных образцах и все они исправлялись самым тривиальным образом, а через месяц выходила новая ревизия с исправлениями.

Интел внутри называет такие маски chicken bits (от идиоматического выражания chicken out).

о мне стали доказывать, что там местами есть и явные команды.
Микрокод был у Transmeta, AMD/NS Geode, Cyrix MediaGX, у высокопроизводительных процессоров его по сути нет для обычных операций, есть небольшая декомпозиция на примитивы для организации суперскалярной архитектуры. В таком микрокоде «патч» обычно выглядит как блокирование суперскалярности, по сути глобальный аппаратный спинлок. Я бы очень хотел послушать как исправить а ля FDIV bug с помощью микрокода. Ты же не думаешь, что там на микрокоде деление в столбик? %)
Вот рассказывают, что это таки код.
Они рассказывают только, что ничего толком они не узнали.

Я таки согласен, что основная часть файла патча микрокода должна быть этими самыми chicken bits. Это банально логично, потому что метод очень прост и эффективен.

С другой стороны, в том примере таки приводятся какие-то намёки на программу.

Микрокод был у Transmeta, AMD/NS Geode, Cyrix MediaGX, у высокопроизводительных процессоров его по сути нет

Вопрос в «обычности» операций. Если помнишь, совсем недавно ещё была жива рекомендация поменьше использовать denormalized floats и загрублять их в 0, потому что управление выпадало на настоящий микрокод, который чего-то с ними делал. Чего — не знаю, потому что в денормализованных нет ничего сложного, что успешно доказано легко переносимыми в железо софтовыми алгоритмами. Если посмотреть на современные процессоры, то куча таких случаев уже залечена, но тем не менее Intel успешно спотыкается за пределами столбового пути на FPU, а AMD — на SSE, я недавно мерял.

Также наверняка все сложные хитрые операции вокруг VMX и тому подобных навёрнутых механизмов превращаются в микрокод.

А, ещё и старт. Вот Константин Белоусов (ядерный хакер FreeBSD) говорил, что от пинка процессора стартовать до реального старта проходит дофига — где-то 0.3 секунды. Он в это время явно не суперскалярные примитивы гоняет...

Я бы очень хотел послушать как исправить а ля FDIV bug с помощью микрокода. Ты же не думаешь, что там на микрокоде деление в столбик? %)

FDIV bug в Pentium не лечился микрокодом. А вот свежий баг в Skylake наверняка просто тем же chicken out выключал какие-то особо параллельные режимы работы.

А по поводу деления в столбик — ну а почему бы и нет? (Только это будет не столбик, а что-то другое — например, базовый SRT, или Goldschmidt.) Имея набор команд для соответствующего блока — это вполне можно реализовать в несколько сотен байт, как и вообще для любого «лёгкого» процессора (RISC-like с минимальным параллелизмом).

Они рассказывают только, что ничего толком они не узнали.

Ты не согласен с тем, что они нашли таки кодовые последовательности?

А, ещё и старт. Вот Константин Белоусов (ядерный хакер FreeBSD) говорил, что от пинка процессора стартовать до реального старта проходит дофига — где-то 0.3 секунды. Он в это время явно не суперскалярные примитивы гоняет...
Если десктопный или серверный процессор, то скорей всего селф-тест проходит, если для встраиваемых систем, то мы за это время и ОС успевает с драйверами загружать ;) Это частое требование автопроизводителей, чтобы система работала меньше чем за секунду, потому что всегда есть джигиты, который проворачивают ключ зажигания, включают передачу и давят педаль акселератора за время меньшее чем пол секунды.
А по поводу деления в столбик — ну а почему бы и нет?
Уж лучше тогда вообще исключить такое из набора команд, чтобы компиляторы не вступали в такое. И реализовывать умножение софтово.
Ты не согласен с тем, что они нашли таки кодовые последовательности?
Я уже сказал, что они нашли, это не тот микрокод команд, о которых мы думаем, это обычное управление суперскалярностью, запрос на свободный регистр (register renaming), проверка доступности и резерверирование ALU и т.п.. Расширения команд — да, могут быть построены из кирпичиков, но какое до них нам дело, ведь это не базовый набор команд.
Если десктопный или серверный процессор, то скорей всего селф-тест проходит

Да, скорее всего. Но этот тест таки управляется встроенным "микро"процессором, который исполняет микрокод.

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

И получить замедление в разы? Ну как супер-аварийный вариант, может, и годится, но никак не в общем случае.

ведь это не базовый набор команд.

Да, базовый туда не входит.

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

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

Забавное другое — это Machine Check Architecture, которое может случиться в любой момент и процессор может сказать, «всё, приехали, кина не будет», а ОС должна решить будем продолжать агонию или сворачиваем лавочку и идём спать. Чем-то это напоминает перехватывание SEGFAULT и дальнейший возврат в код, расходимся и продолжаем работу...

это обычный аппартный блок, который в параллели делает сброс каждому блоки и собирает ответы.

Для машины сложности уровня процессора x86 так проектировать уже не оптимально. Давно проще встроить внутреннюю управлялку на чём-то предельно тупом (она может даже не иметь минимального конвейера на предвыборку одной команды, чтобы не усложнять).

Machine Check Architecture, которое может случиться в любой момент

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

Для машины сложности уровня процессора x86 так проектировать уже не оптимально. Давно проще встроить внутреннюю управлялку на чём-то предельно тупом (она может даже не иметь минимального конвейера на предвыборку одной команды, чтобы не усложнять).
В упор не понимаю зачем это там нужно.

Чтобы не рисовать FSM для сложных операций, которые всё равно не имеют узким местом скорость исполнения. Это, например, xsave/xrestore, действия VMX и SGX, разные бесполезные команды типа RCL/RCR более чем на 1 бит, FSIN, и тому подобное.
Причём работать этот процессор может и в 2-3 раза быстрее основной тактовой — он крошечный.

Я имел в виду зачем микропроцессор для селф-теста?

А ты представляешь себе, какие именно действия могут выполняться для _качественного_ селф-теста в звере уровня современного x86?

Это частое требование автопроизводителей, чтобы система работала меньше чем за секунду, потому что всегда есть джигиты, который проворачивают ключ зажигания, включают передачу и давят педаль акселератора за время меньшее чем пол секунды.
А с датчика двери и сиденья нельзя запускать ваш компьютер? У меня в 7 летней машине бортовой компьютер запускается при открытии двери. А ключа зажигания нет вообще, только кнопка.
А с датчика двери и сиденья нельзя запускать ваш компьютер? У меня в 7 летней машине бортовой компьютер запускается при открытии двери. А ключа зажигания нет вообще, только кнопка.
Да хоть по распознаванию голой задницы, наше дело, чтобы ОС крутилась, а то всё остальное адрессуйте автопроизводителю :)

Не згоден.

Для нас естественно алгоритм по шагам последовательно думать
Насправді це справа звички, не більше. Наприклад я використовую event-based FRP модель. Будь-яка задача не вирішується за один підхід, вона взагалі не вирішується у звичний для імперативщиків спосіб. В моєму світові підхід до вирішення задачі більше схожий на реальний світ, ніж імперативний аналог. Типовий приклад, який я дуже люблю наводити, це як нагодувати собака. Ви одразу собі малюєте в голові щось на кшталт
dog = new Dog; master = new Master; master.feed(dog);
Проблема в тому, що реальний світ набагато складніший. Хазяїв може бути декілька, це взагалі можуть бути ліві люди зі сторони, собак може бути більше ніж один, це можуть бути взагалі не собаки, собака не обов’язкого годувати, він може пожерти самостійно. Все, триндець, імперативщина почне ускладнюватися з катастрофічним приксоренням. Для мене це лише системи обміну сигналами. Хто це, що вони роблять, як саме, чому — не важливо взагалі. Це той рівень абстракції, в якому сутностей мінімум, а можливостей — максимум.
Продумувати таку систему не треба послідовно, її можна реалізовувати поступово по мірі виникнення проблем. Ось саме так ми зазвичай вирішуємо складні задачі.

Каррирование функций, например, — естественная для человека вещь?

ну каррирование — это сугубо математическая заумь, суть которой проста — пошаговый поиск неизвестных (насколько я понимаю).
Например, задача: дано уравнение с двумя неизвестными (х и у), найти значения этих неизвестных. Ну и насколько помню по урокам математики, значение одной переменной зависит от значения другой переменной. Т.е. сперва находится значение одной переменной, потом значение другой переменной.

Ну или монады в хаскеле — которые являются костылем (ну да, функциональщиные языки не лишены недостатков, поэтому императивные и ООП-языки никогда никуда не денуться) для работы с изменяемым состоянием.

можно бросить монетку (орел — зависит, решка — не зависит). :D

Ну или монады в хаскеле — которые являются костылем
 Не костылем, а фичей.

ну это смотря с какой стороны посмотреть) (а вообще да)

Говоря о естественности ФП, лучше таки использовать в качестве образца не Хаскель и прочий «матан» ©, а что-то уровня и стиля Erlang.

Например, если мы считаем НОД (простейший метод, с вычитанием) кодом типа


unsigned gcd(unsigned a, unsigned b) {
  while (a != b) {
    if (a > b) { a -= b; }
    else { b -= a; }
  }
  return a;
}

То в Erlang это превращается в


gcd(A, A) -> A;
gcd(A, B) when A>B -> gcd(A-B, B);
gcd(A, B) -> gcd(A, B-A).

что как раз ближе всего по логике к классическому методу Евклида и, что главное, его доказательству по редукции.

От всего ФП тут остались только
1) Неизменность именованных значений (поэтому в Erlang говорят не assignment, а binding);
2) Рекурсия как главный механизм редукции и периодического выполнения (циклов нет; есть развилки в виде if и case), отражающая «бытовое» понятие пошагового сведения к более простой задаче.

То же самое можно было получить на LISP (любом диалекте; MIT в своём курсе SICP использовал Scheme, до перехода на Python), но с бо́льшим количеством скобочек :) и поэтому немного менее наглядно.

То в Erlang это превращается в

gcd(A, A) -> A;
gcd(A, B) when A>B -> gcd(A-B, B);
gcd(A, B) -> gcd(A, B-A).

Так це ж Prolog!

У Erlang много из Пролога, но они заметно различны.

У меня в универе был пролог. Мозг повыворачивало изрядно, но препод так и не смог объяснить чем оно круто

Круто в Prolog те що не треба писати алгоритм, а достатньо лише правильно записати повний набір правил. Далі під час виконання написаного включається магія «перебираємо усі можливі варінти», кожен варіант (комбінація) перевіряється на відповідність вказаних правил і таким чином буде знайдено рішення, або неможливість рішення. Звісно перебір варіантів має різні оптимізації, але у наведеному прикладі буде якось так.
Для виклику gcd (8, 5):
— правило 1 не підходить
— правило 2 підходить, відповідь — gcd(3, 5), продовжуємо обчислення для gcd(3, 5)
— правило 1 не підходить
— правило 2 не підходить
— правило 3 підходить, відповідь — gcd (3, 2), продовжуємо для gcd (3, 2)
— правило 1 не підходить
— правило 2 підходить, відповідь — gcd (1, 2), продовжуємо для gcd (1, 2)
— правило 1 не підходить
— правило 2 не підходить
— правило 3 підходить, відповідь — gcd(1, 1), продовжуємо для gcd(1, 1)
— правило 1 підходить, відповідь — 1

Сейчас я это понимаю. Тогда с потока никто так и не догнал, нафига оно надо.

Оно ровно для задачи типа «мы не знаем, как можно тут что-то вычислить, пусть компьютер подумает, он быстрый».

Адаптированный для народных масс Prolog называется make.

Читайте Ивана (Иоанна) Братко, у него отличная книжка по прологу.

У нас мало того что был пролог, так и вел его еще тот «пролог» — какой то старый спившийся маразматик с ментовской корочкой.

Примерно та же фигня, только чувак был слишком фанатик, чтобы толком что-то объяснять

Как один из аргументов почему С++ аццтой приводили:

«Шаблоны являются полными по Тьюрингу, поэтому компиляторы должны решить проблему останова (неразрешимую), чтобы выяснить, можно ли, вообще, скомпилировать код.» %)

аццкий аццтой.

«Шаблоны являются полными по Тьюрингу, поэтому компиляторы должны решить проблему останова (неразрешимую), чтобы выяснить, можно ли, вообще, скомпилировать код.» %)
Ну крестовые шаблоны то детский сад, есть же всякие идрисы с депендент типами, кторые какраз эту задачу академически решают %)

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

Если ты в своём коде соблюдаешь разделение по логике между интерфейсами и реализациями, и наследованием только от одной реализации, то тебе пофиг, это сделано на C++, Java или чём-то ещё — оно уже работает как надо.

Тем более что это сломано, например, со введением методов по умолчанию в интерфейсах в Java 8 — фактически, с этого момента мы имеем то же множественное наследование.

Если же тебе зачем-то действительно нужно множественное наследование, включая более одной реализации, то на языках, где это запрещено, начинаешь заниматься полной фигнёй с копированием всей реализации, а на C++/Python/etc. тебе всего лишь надо отнаследоваться от их двух :)

Архитектуры с include и интерфейсами гибче

Так что ничуть они не гибче. Безопаснее — да, но это противоположность гибкости.

два одинаковых дефолтных метода в разных интерфейсах хрен отнаследуются в джаве

Ну поржем тогда, че. Еще немного до 666 комментов добить

И средства управлять этим нет? Тогда это ещё хуже, чем в C++.

Да никак. Эти слова для программиста существуют. Помаркируй что это паблик метод в названии метода и все.

можна в .h не або лажить або не лажить, а

private, protected и public
протектед, як на мене — лишня ланка. Дані (методи) відкриті або закриті для доступу зовні, а ще ліпше доступ через гетери/сетрери і баста

С++ нах,
скрізь де серйозні вимоги до кода, С++ фічі обрізані по самі яйця,
виходить недоС++ в стилі С з класами, бугагга

да неужелі?
стільки язиків придумали, а С++ нізамєнім

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

Именно поэтому Google переводит крупные продакшн сервисы с C++ на Go — matt-welsh.blogspot.nl/...duction-system-in-go.html .

В ембеде то есть? Вот не зря на С++ вакансии на эмбеддеров косо смотрят.

аутомотів і телеком смотрить на С++ як на овно

Та и флаг им в руки, этому сборищу древнего железа и таких-же технологий.

Но факт есть, эмбеддеры С++ не умеют

а для чого,
ти скажи ембедери JS не уміють

Когда апплаятся на С++ не в ембед. Да и насчёт телекома это не всегда правда.

то саме можу сказати, що коли аплаяться С++ в ембедед виходить івно

Возможно, я всегда от эмбеда отказывался

Ну и С раздражает своей тупостью в сравнениии с С++.
а Лінукс убогостью в порівнянні із Віндовозом (шутка юмора, єслі шо)
Но если мелкомягкие продолжат свой путь, выбранный в 8-10, то у них есть шанс сравняться с линухом и в десктопе. Они сейчас стремительно изгаживают свою ось.

Неужели винда пытается скопипасть gnome? Не юзал винду на десктопе после 2000й, расскажите что там.

А как должно быть? Как в 95й (3.11)?

Та немає різниці взагалі, який інтерфейс. Бо звикаєш навіть до останнього лайна. Кращий інтерфейс — відсутність інтерфейса. Не пам’ятаю хто сказав, але він був рівня бог у промисловому дизайні.

Бо звикаєш навіть до останнього лайна.

Hі, якщо поруч є альтернатива.

Не пам’ятаю хто сказав, але він був рівня бог у промисловому дизайні.

І такий же «стратег» :) Бо реалісти шукають рішення, коли ідеал недосяжний.

Hі, якщо поруч є альтернатива.
Інколи альтернативу не виходить використовувати. Наприклад, на старих компах новітні операційні системи не запускаються. Або запускаються, але гальмують.
І такий же «стратег» :) Бо реалісти шукають рішення, коли ідеал недосяжний.
Там більше філософія дизайну в цілому. Реалісти потім дійсно будуть шукати :)
Наприклад, на старих компах новітні операційні системи не запускаються.

Все одно нервуватимуться. Наприклад, «коли же цю рухлядь повикидають?»

Там більше філософія дизайну в цілому. Реалісти потім дійсно будуть шукати :)

Раскін? Такого ідеаліста-екстреміста, дійсно, ще пошукати треба.

ну так не всім дано, це тобі не патерни на бізнес логіку натягувати

Я и на асме могу. Но я ипал лезть в мир искусственных ограничений.
Ну некоторые и линк, стримы и лямбды запрещают, ибо некоторые синиоры не осилили.

ну так не всім дано

В эмбеддеде просто г-но выходит, там илликтронщики вместо программистов

ти явно не в тємє, і не знаєш про що балакаєш

то саме можу сказати, що коли аплаяться С++ в ембедед виходить івно
п.с.
до чого тут електронщикі?????

ні Богу свічка, ні чорту кочерга

Та не, для реализации наследования тот же protected — самое оно.

Если в базовом классе ты решишь, что вот эта хренька — не должна попасть в паблик интерфейс, но наследнички должны его юзать в любом случае.

Этот стандарт идет в нагрузку к гарбадж коллектору и продуманной иерархии классов.

Ну извините, что в С++ сборщик мусора не предусмотрен по дизайну

Там среди цитат перл хорошим языком назвали

If you like C++, you don’t know C++.
Проблема в том, что если тебе не нравится С++, ты тем более его не знаешь.

Не совсем так. Раньше мне нравился С++. До тех пор, пока несколько раз мой прекрасный код не превращался в головоломный говнокод после не очень успешных попыток использовать фичи С++ по-максимуму, а не как в «Си с классами».

мой прекрасный код

Кажется я знаю в чем проблема.

В hotspot кстати как раз си с классами.

На простом С тоже можно запилить foobaz Enterprise Edition

На С это сделать намного сложнее. Дополнительно, получившийся говнокод можно моментально отличить от нормального кода на С. В С++ так не получится — там неподдерживаемый говнокод намного сложнее отличить от нормального кода.

Не надо вам в С++, однозначно.

До тех пор, пока несколько раз мой прекрасный код не превращался в головоломный говнокод
Может дело не в С++, а в том, что руки не оттуда...?
а не опыт 23-летнего сеньора.

А что не так с опытом 23х-летнего сеньора? (Был сеньором в 21 если чо)

19 річна ПМша, як на мене все ж лучшє

Риторический вопрос: зачем переписывать по три раза код на С++ вместо того, чтобы один раз написать на каком-нибудь С или Go?

dou.ua/forums/topic/16012
«фигак фигак и сервисы на Go лучше»

использовать фичи С++ по-максимуму
Вот в этом ваша проблема

Когда человек пишет о максимальном использовании это звучит как — используем, потому что можно, а надо немного наоборот, используем только тогда когда все остальное нельзя

Чтобы «знать» С++ надо не работать, а перманентно заниматься изучением новых костылей и лонгридов по их применению.
Для того, чтобы прилично программировать на С достаточно прочитать 40-летней давности Кэрнигана, на Питоне — Лутца, для Core Java за глаза хватит оракловских туториалов.
Современный С++ ИМХО существует только для того, чтобы саттеры и александрески имели вечный заработок на толковании темных мест.

Чтобы «знать» С++ надо не работать, а перманентно заниматься изучением новых костылей и лонгридов по их применению.

А на сях их нужно будет еще и переизобретать. В результате получаются фрактальные костыли типа gtk и glib.

Для того, чтобы прилично программировать на С достаточно прочитать 40-летней давности Кэрнигана
прилично

На самом деле нет.

фрактальные костыли типа gtk и glib.
Не являющиеся частью языка.
прилично
На самом деле нет.
Перечислите плз, для каких языков издаются ежегодники «ХХХ — еще 50 способов не выстрелить себе в ногу».
Не являющиеся частью языка.

Являющихся. Костыли же, а не экстеншоны.

Перечислите плз, для каких языков издаются ежегодники «ХХХ — еще 50 способов не выстрелить себе в ногу».

Для всех популярных. Ваш К.О.

Являющихся. Костыли же, а не экстеншоны.
Костыли это friend, mutable и зоопарк смарт-поинтеров перетянутых из сторонних библиотек в стандарт. А glib и gtk это сторонние библиотеки, вторую я думаю большинство С-программистов никогда и не использвало.
Для всех популярных. Ваш К.О.
Примеры?
Костыли это friend, mutable

Только в вашей фантазии.

зоопарк смарт-поинтеров перетянутых из сторонних библиотек в стандарт.

Зоопарк = аж целых полтора std::shared_ptr/std::weak_ptr, отлаженные в реальных боевых ситуациях. Кошмар-кошмар!

А glib и gtk это сторонние библиотеки

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

Примеры?

В гугле/на ютубе. Справитесь?

Инлайн это цивилизованная редакция макроса и может применятся как угодно.
Вопрос почему до сих пор существуют макросы отличные от __TIME__ и __DATE__?

Ну а макросы в плюсах — это однозначно костыли.
А как же компиляция под разные платформы?

Макросы нужны в сях потому что нет шаблонов, а также передачи параметров по ссылке.

а также передачи параметров по ссылке

Для этого там всю жизнь указатели юзали...

На самом деле ситуация С модными указателями в С++11 мне напомнила картину с C#.

Имеем в С++11 всякие шаред_птр а по факту приходится получать/передавать всякие void* в допотопные либы.
На шарпе, в практическом применении, тоже часто приходится юзать всякие ВинАПИ а анменеджмент коде и вся эта Нетовская безопасность до задницы.

Managed C++ был ещё веселее

В линуховом ядре кстати есть целая пачка макросов, которые принимают «ссылку» (на самом деле --- lvalue)

А тебе доводилось где-то когда-то как-то использовать ключевое слово register?

Это понятно. Просто интересно использовал ли кто-то из старых разработчиков это на практике.

имело смысл ну в очень древних компиляторах

да, а шо?
тіко із висоти Це++ не ясно, яка архітектура, і що можна часто використовані змінні тримати не на стеці а в регістрах тогож АРМ процесора

современный компилятор С
шо за звєрь?

да любой. *.c файлы будет компилировать как Си без поддержки всяких классов

ви пам"ятаєте, про що була мова?

современный компилятор С
auto_ptr

А в чем проблема с auto_ptr в C++03? Rvalue нет, выкручиваемся как можем.

vector<bool>

А тут что не так?

(что по-другому никак не сделать).
Та лихко пишешь static и она пердолится простите везде.

ЗЫ: нет такой «единицы трансляции» как «заголовочный файл»...

А я понял в чём разночтение.

и она пердолится простите везде
— здесь «во все единицы трансляции».

ЗЫ: я вчера проверил если чО. ))

Інлайн — код тіла (а не виклик) функції вставляється кожний раз , і до статіка це не має відношення абсолютно.
А гуру як Штріліц, мабуть, пам"ятають лише останню фразу (як приклад сучасний С компілєр і register keyword)

я теж,
тема інлайн функцій і статік, одна з улюблених на інтрерв«ю, тому має відскакувати від зубів, напр.:
stackoverflow.com/...nd-static-inline-function
але мені цікаво послухати альтернативні варіанти гуру, що відписуються вище.
п.с.
там до речі і про register який як видно і не not useless,
але то таке, не для «сучасних компіляторів»

як що так, то поясни, що ти наразі робиш у мої фантазії?
побочний ефект із бага в Матриці?

Тот же STL на 60% очень удобен и приятен.
STL — это еще тот старый добрый теплый ламповый С++
А добавка auto и лябмб — это же реально удобно.
Чем же без лямбд было плохо?
Простые функции нужно было пихать в функторы. Лямбы позволили писать более лаконичный и читаемый код.
Честно говоря не очень в курсе плюсовых лямбд, но функторы были хорошо отлаженной технологией, а сейчас опять начнется серия самострелов.
Есть старый инженерный принцип «Работает — не трогай». Беда в том, что за С++ стоят не инженеры.
Добавление умных указателей очень облегчило жизнь.
std::auto_ptr — концепция древняя, как говно мамонта.
Кстати, а как быть с легаси-кодом компилируемом в новых стандартах?
а сейчас опять начнется серия самострелов.
Не началась. Больше 5 лет прошло уже.
Есть старый инженерный принцип «Работает — не трогай». Беда в том, что за С++ стоят не инженеры
Так может стоило продолжать писать всё на ассемблере? Работало ведь, иногда.

Форматирование кода здесь никак нельзя добавить?

Именно о таком коде и речь за такой код надо бить. Именно об этом и речь что для понимания простейшего (ну да ну да) MFCC т.е. что это вообще об нём речь и вообще нужно продраться сперва через множественные transform и... и что!? с хуле вообще скалярное произведение в std:: делает!? Об том же ж и речь что сейчас в «стандарт» напихано такую кучу всяческой чехуты что ты чувак сидишь без работы а старпёры идут в стартаперы и фигачат тихонечко на гошечке.

ЗЫ: у меня только сегодня #внезапно одинаковая версия gcc для FreeBSD и для Linux (NDA) оказывается вроде простейший без заковырок код но в линуксе уже скомпилять не может ладно бы хоть компиляторы там разные были... А первый же ж вопрос по transform «а зачем это был же ж for_each?» но да кому-то не хватало кому-то мешало по ходу ещё один итератор запустить ну правильно давайте запихнём всё в стандарт ну а чо йо у меня падаваны на лямбдах пишут то что раньше в тупой switch заворачивалось и читалось с ходу не знаю как писалось может на лямбах удобнее свернуть что-нибудь вместо банального свича?

Вот скажи мне MFCC сам по себе выдуман когда? В 70-х? На Фортране работал? На банальных циклах? Чем был плох? Заново пущен в строй в применении когда? В начале 2000-х? Лямбды уже были? Ну да википедия пишет что с лиспе с 58-го года уже есть но готов спорить запись самого алгоритма MFCC на всё тех же ж банальных циклах никому не мешала и прекрасно работала так что же ж было не так зачем вот это просто потому что теперь можно? А смысл? Только потому что можно двухэтажные лямбды?

Причём это уже проходили прекрасно когда в тех же ж «плюсах» шаблоны начали появляться внезапно шаблоны стало так модно всё что не писать пишут на шаблонах «а зачем!?» «ну как же ж это же ж шаблоны!» (к) (тм) кстати почему не на шаблонах что это за ерунда с фиксированными double и сабконтейнерами vector? Где же ж сила Си++!? ((

ЗЫ: std::plus? вы смеётесь? где вообще универсальная реализация std::main?

Вот мне и интересно отчего же ж не реализовать абстракции высокого уровня и не записать на них прямо и дословно:
if (sumpower) aspectrum = wts * pspectrum; else aspectrum = (wts * sqrt(pspectrum)).^2; end

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

20 летней давности мануалов
И что там есть на предмет, например, смарт-поинтеров?
Кстати, вспомнив Страуструпа и Гради Буча, в очередной раз порадовался их толстовским объемам.
«Истина не может быть столь длинной» ©

Темплейты уже были на то время, из них + перегрузка операторов слепить смартпойнтер не проблема. Не нашёл, когда они появились, но 10 лет назад уже неспешно готовились к депрекации auto_ptr

Можно же и на асме или C писать а ООП стиле,
Давайте не будем путать ООП и С++.
А как раздражает засилье глобальный переменных в С или функции с 100500 параметрами.
Никто не запрещает использовать static и паковать данные в структуры и передавать указатели. Вернее — это диктуют правила хорошего тона.
но очень неудобно.
Вполне себе удобно и намного лучше читаемо, чем нагромождение шаблонного кода.
github.com/...s/ari/resource_asterisk.c
(Да, согласен — пространства имен не помешали бы)

Вы хотели сказать — код из RADов.
Особенно из С++ Билдера.

Обычно код на С от эмбедеров — это вынос мозга:
пан хотів сказати від «електриків» ( ЕЕ — ілектрік інженір)

я ще такі, що PLC програмують з допогою ladder diagrams & sequence tables

А std::transform с 9-ю (девятью) параметрами 4 их которых спецификаторы типов не раздражает?

Блин да там «условная реализация» записывается проще короче и понятнее чем сама спецификация:
while (first1 != last1) { *d_first++ = binary_op(*first1++, *first2++); } return d_first;

Как до такого можно было дойти? Это же ж гениально придумать такое «синтаксическое упрощение» которое само по себе записывается на порядок сложнее того во что реально разворачивается. Я уже говорил за банальный свич? Вот как?

А std::transform с 9-ю (девятью) параметрами
Где? Максимум только 5.
Блин да там «условная реализация» записывается проще короче и понятнее чем сама спецификация
Точно не короче, вы забыли объявить переменные first1, first2 и d_first.

Ну binary_op (как и last1) типа «инлайнятся», а вот остальное --- не очень

Так почему же shared/weak не сделали сразу, если все настолько очевидно? Это же не синтаксический сахарок, а фундаментальная конструкция.

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

В каких-таких

других языках
?
Более того — такие вещи, как подсчет ссылок и взаимоблокировка чуть ли не со времен Дейкстры хорошо известны.

Подразумевались фичи вообще, а не только смарт-пойнтеры.
А конкретно С++ унаследовал голые указатели из C, т.е. by design. Какие тут претензии.

Которые благополучно похерил.
И получилась ни Богу свечка, ни черту кочерга.
Ни чистой объектности Джавы, ни близости к железу С.

никуда не похерил, баловаться с void * ничто не мешает

Виртуальность — здесь уже можно спорить удобнее или нет, эта часть плюсов нетривиальна и требует знаний, опыта и аккуратности.
Это лучше, чем в линуховом ядре, где vtable нужно писать руками.
Насколько я знаю только один очень скользский момент для эмбедед — это исключения.
Там всё зависит сильно от связки ABI+компилятор+конкретная сборка компилятора. И не только эксепшены.

Я имел ввиду, что конкретные сборщики того же gcc забивают установку флагов оптимизации для стандартной библиотеки, а потом «упс, libc+stdc++ весят сотни килобайт, сраные плюсы!!11одинодин»

A lot of effort over several years by the Boost group (boost.org) went into making sure the C++11 smart pointers
are very well-behaved and as foolproof as possible, and so the actual implementation is very subtle.

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

Я просто пытаюсь представить себе С в который прикрутили указатели или структуры через двадцать лет после начала использования.
А ответ прост — изначально хреновый дизайн, постоянно требующий костылей.

Отлично сдизайненная обертка. Кстати именно поэтому я верю в Go — дизайнили лучшие мозги, а библиотеки напишутся — был бы удобный инструмент.

В этом и проблема Си++. Сначала ктото подумал что высокоуровневый язык может быть просто оберткой над Асмом. Потом комуто пришла в голову идея что хороший UI это может быть просто обертка над Си++ (ныне приснопамятный уже MFC кто помнит). Потом комуто пришла в голову что «безопасный и высокоуровневый язык с итераторами, медведями и циганями» может быть тоже всеголишь оберткой над Си++.
И в этой гонке Си++ накажут, потому что любой высокоуровневый синтаксис имеет хороший люфт к низкоуровневым оптимизациям. Ибо в какойто мере это Есмь Декларация. Поэтому я уверен что теже итераторы в шарпе бегают куда быстрее чем те смешные обертки в С++ которые ведут себя как итераторы. А все потому что Шарп видя что это интератор может это все сконвертить в чтото эффективное и низкоуровневое, а обертка на Си++ останется оберткой с оверхедом и уродством.

на описание совпеменной системы распознавания речи
Кому нах. может понадобиться писать саму математику «совпеменной системы распознавания» — на плюсах вместо того чтобы генерировать его из математики напрямую? Вот зачем?

С 1998 по 2011 никаких новых костылей там небыло, не считая всяких мелкософт-специфик...

Больше думаешь не о том, что написать, а как написать
 В точку! Поэтому нужно переходить на Go — там не нужно думать, как написать — просто пишешь и все работает )

может хватит гадить людям в моск?
надо будет — они и на VB перейдут обратно, если требования такие будут
если это будет обусловлено реальными причинами
влезь в любую тему и напиши что узконишевый язык захватит мир
Бггг

все работает

Целых три с половиной хеллоуворда? Потому что при попытках написать что-то больше, ноги очень быстро отстреливаются в процессе импорта модулей с гитхаба.

ПлакалЪ. (к) (тм) Не пускайте этого чувака больше программить точно вам говорю.

сильно удивишься — на его коллег оказываеццо есть спрос:)

У мене є цитата приблизно такої ж цінності:

> If you like Go what’s wrong with you?

Думаю больше всего строк кода налапачено на SQL и «вирутально» в экселе.

Еще не так давно Кобол держал первенство

Точно! Кобол и все его реинкорнации — например вот та прикольная на ЕС, зачем то переведенная на русский язык.

Статья видимо написана тем кто переживает за судьбу С/С++ :-) Не стоит переживать — ничего с ними еще долго не случится. А по поводу дропбокса то там уже скоро от питона ничего не останется: www.quora.com/...duction-are-written-in-Go

Новые системы будут пробовать писать на новых системных языках таких ка Go и Rust, есть и другие.

JS, Ruby, Python и всеми ненавидимый (совершенно не заслужено) PHP были, есть и будут языками для построения быстрых MVP и для систем с низкой нагрузкой. Как только нагрузка превышает разумные пределы — их начинают переписывать на том что дает прирост в производительности и уменьшение нагрузки на память.

Мир Java и .NET находится между максимальным перформансом и скоростью разработки — потому и освоили энтерпрайз и тяжелые системы где важна консистентность которую никто из интерпретируемых языков не предоставит.

Все ныне существующие инфраструктуры давно зарекомендовали себя в продакшене и имеют право на жизнь. А кто из них покинет олимп зависит только от рынка.

Волна JS и меня честно говоря пугает — это один из самых отвратительных языков в топ-5, по крайней мере в текущем виде, es6 уже ближе к языку :-)

Мб typescript + всякие rxjs? Мне очень понравилась концепция. Я с ним пересмотрел свое отношение к фронту

Скоро отрелизят WebAssembly, вот тогда заживем!

Мне это немного напоминает эволюцию. Js похож на грызунов, крыс) Быстро развивается, быстро адаптируется к новым условиям, ненужное отмирает и выживают самые лучшие ветки развития. И чувствует себя лучше многих носорогов/тигров. (да, этим я себя успокаиваю когда читаю доки)
А насчет плюсов — они у нас больше на продуктовых. Из описаний вакансий, которые мне прилетали, всё что выходит за пределы энтерпрайза включало в себя хотя бы базовые знания плюсов.

Волна JS и меня честно говоря пугает — это один из самых отвратительных языков в топ-5
«PHP Dev»

Тут еще надо разобраться который из этих двух более уродский гг)

Вообще вся проблема в подходе «гуд енаф» который рулил и до сих пор рулит в вебе, когда пофиг как главное чтобы работало. Никого не беспокоит архитектура вещей. В последнее время правда что то меняется в лучшую сторону.

Давай, раскажи мне про архитектуру на ЖС :-)

JS, Ruby, Python и всеми ненавидимый (совершенно не заслужено) PHP были, есть и будут языками для построения быстрых MVP и для систем с низкой нагрузкой.
Никогда не были.
Как только нагрузка превышает разумные пределы — их начинают переписывать на том что дает прирост в производительности и уменьшение нагрузки на память.
Никогда не будут. Будут разбрасываться на +100500 нодов хоть на гипер-серверах хоть прямо на контейнерах по вкусу и баланситься довольно простыми техническими средствами в результате на +100500 дешевше переписывания (и надёжнее) хоть и есть имеет место быть рост расходов на DevOps.
Ну и денег у конкретной конторы не достаточно всегда и в какой-то момент просто нарищивание мощностей перестает работать.
Не перестанет: разработка существенно дороже и имеет смысл только в крайний пределах окупаемости. Например когда чип дешевле на $5 на партии миллион дивайсов сразу экономит $5 млн в серии. Или когда оно просто физически не помещается на силиконе. Или когда пишут «материально-техническую базу» поверх которой уже ляжет то самое «горизонтальное масштабирование из говна и палок». Но везде там изначально не было «сперва написано на костылях а потом запилено до ракеты» — строят всегда изначально космодром «вертикальная оптимизация полным переписыванием на быстрых языках» редкость.

Я считал всякий раз считаю там цимес в двух вещах а) расход на вертикальную оптимизацию нелинейный и следующая глубина по стоимости отличается на порядки; б) упор до уровня «экономической целесообразности» достигается практически сразу а упор до «физической возможности» очень быстро именно исходя из уровней оптимизации; в) исходя уже из п.п.«б». переход на горизонтальное масштабирование всё равно неминуем. На сабжевых системах.

ЗЫ: вопрос покупать против арендовать против облаков слишком широк и глубок для краткого обсуждения. ))

Никогда не говори никогда :-) Все всегда зависит от ситуации в бизнесе. По твоей логике SoundCloud мог просто скейлить свой руби монолит и не париться? Но видишь — не клеится тут — переписывают на Go. Dropbox мож жить на оригинальной версии на питоне? Может быть — но нет, переписывают на Go и Rust критичные для нагрузки части.

Угу а не клеится потому что монолит не скейлится горизонтально или не импрувится перформенс вертикально? Питон в ту же ж степь... Опять таки не сели же ж всё на расте а гошечка у них кошерненькая а раст только в «критичные для нагрузки части» уважают значит...

www.stroustrup.com/applications.html — список побольше. Но и это малая часть.

И при всем при этом, большая часть аутсорс проектов — это похапе/дж-с.

Можно подумать, будто кроме ядра системы, сетки и математики плюсы больше применять некуда. Тот же AutoCAD и прочие подобные хрени, не?

Как выжить плюсовику?

Не ныть! Нести свои кресты!

Крутые проекты на других ЯП пишутся вот прямо в эту самую минуту. Вы рассматриваете проекты которым десятки лет и которые когда начинались, то ничего кроме C++ толком и не было.

Ну и не стоит отбрасывать тот факт что многие проекты написаны на 2-3 языках. Даже если используется всемогучий С++, то еще есть какой-то вспомогательный ЯП. Что, как по мне, вполне нормально.

Глубже надо смотреть внутре там у неё неонка и думатель. (к)

Ну ладно, жачем прикалываццо? Ну не в духе дядько последнее время, це ж не повод для столь печальных параллелей:)


В отчаянии и меланхолии я понес какую-то околесицу насчет самообучающихся машин. Он слушал, раскрыв рот, и впитывал каждый звук — по-моему, он запоминал эту околесицу дословно. Затем меня осенило. Я спросил, достаточно ли сложной машиной является его агрегат. Он немедленно и страстно заверил меня, что агрегат невообразимо сложен, что иногда он, Эдельвейс, даже сам не понимает, что там где и к чему. Прекрасно, сказал я. Хорошо известно, что всякая достаточно сложная электронная машина обладает способностью к самообучению и самовоспроизводству. Самовоспроизводство нам сейчас пока не нужно, а вот обучить эвристический агрегат Бабкина... тьфу... Машкина печатать тексты самостоятельно, без человека-посредника, мы обязаны в самые короткие сроки. Как это сделать? Мы применим хорошо известный и многократно испытанный метод длительной тренировки.

По одному проекту по линку данные точно устаревшие. Dropbox активно экспериментирует с новыми языками. Большую часть Python-кода (но не весь, в основном — более-менее перформанс-критикал места) они уже давно поменяли на Go, а сейчас core проекта активно перепиливают на Rust (информация точная, Джессика Маккелар упомянала об этом на пайконе в этом году).

Ну я как бы, последние лет 20, догадывался, что никто ядра OS на node.js писать не будет...
Ну а если по серъезному, то в статье,выборка не репрезентативна.

HN — Racket aka PLT Scheme.
GitHub и GitLab юзерский интерфейс на Ruby. Инфраструктура вроде C.
Docker — Go.

причем он юзает всё тот же VB — и нафига мне эта лишняя прослойка?

с какого это перепуга докер юзает VB? он юзает pid namespaces, control groups и Union file systems. Виндовсовый разве что?

HN = news.ycombinator.com

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

Не показательно, есть реализация докера на bash на питоне на js даже на лиспе, потом понесло остапов уложить реализацию докера в определенное кол-во строк но тут уже стало неинтересно, если интересны детали — гуглите, так что оно не го и нифига там внутрях нету кроме концепта.

Хороший оптимизированный компилятор написать это десятки человеколет работы. Как только влупят столько же инженерного труда в качество генерированого кода в Гоу, Раст, Руби и иже с ними так и сразу и перейдут. А пока что по сравнению с тем же GNU GCC эти языки годятся разве что для прототипирования на приятном синтаксисе.

налепить столько ненужных #ifdef

Есть отдельно взятые компиляторы (avr-gcc, я имею ввиду тебя), в которых либо код без ifdef, либо производительность. В качестве примера могу предложить написать код, который читает big endian поля из массива байт.

И интеловский далек от идеала, ручками допиливать приходится

в плане автовекторизации не всегда мышей ловит

Оптимизирующий компилятор нужен, когда городят горы ненужных сущностей, как в С++.
Для простых языков, как С и Go особенной оптимизации и не надо — конструкции очевидны.

В исходниках ядра колупаться не доводилось, а вот в libc довелося.
Так там такие «жопорукие конструкции» на С написаны, что без бутылки и не разберешься.

Это же все-таки не компилятор, а код несущий на себе тяжкую ношу кросс-п
латформенности и совместимости.

А вот не надо проблемы glibc на всех переносить.
BSD libc / bionic / musl гораздо чище.

>>> BSD libc / bionic / musl гораздо чище

и секьюрнее

Хороший компилятор умеет инлайнить функции, правильно предсказывать ветвления и расставлять их в оптимальный порядок и даже раскладывать рекусию в циклы. О каких простых конструкциях речь. Даже если компилятор просто вычисляет мат выражения в одну строчку там есть целый список оптимизаций.

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

В смысле вынести лишние переменные за цикл, то конечно всегда пожалуйста. А вот оптимизировать создание/присвоение/копирование объектов на стеке это немножко другое.

Очень упрощенно. Я могу объявить переменную встроенного типа и присваивать ей какие-то промежуточные значения:
int a = foo(); int b = bar(); int c = a+b;
Если посмотреть ассемблерный код, то с очень большой вероятностью эта переменная не будет создаваться и все промежуточные вычисления будут сбрасываться в конечный результат.
Как поведет себя компилятор, если эта временная переменная — пользовательский тип?


In a throw-expression, if the operand is the name of a non-volatile object with automatic storage duration, which isn’t a function parameter or a catch clause parameter, and whose scope does not extend past the innermost try-block (if there is a try-block), then copy/move is omitted. When that local object is constructed, it is constructed directly in the storage where the exception object would otherwise be moved or copied to.
When handling an exception, if the argument of the catch clause is of the same type (ignoring top-level cv-qualification) as the exception object thrown, the copy is omitted and the body of the catch clause accesses the exception object directly, as if caught by reference. This is disabled if such copy elision would change the observable behavior of the program for any reason other than skipping the copy constructor and the destructor of the catch clause’s parameter.
Вот-вот. Именно это я и имел в виду:
Хороший оптимизированный компилятор написать это десятки человеколет работы.

Я подозреваю, что оптимизация на уровне ассемблера примерно одинакова для всех компилируемых ЯП.

Вернусь к исходному посту:

Оптимизирующий компилятор нужен, когда городят горы ненужных сущностей, как в С++.
Для простых языков, как С и Go особенной оптимизации и не надо — конструкции очевидны.
Например, возврат локального std::vector<t> из функции гарантированно вызовет конструктор перемещение (а это по сути просто копирование 24-х байт).

RVO, не?

Прост

гарантированно вызовет конструктор перемещение

не очень. «Вызовет move либо вообще ничего не вызовет» более корректно.

Не рокет сцаинц но ровно то что скорее всего не реализовано в новомодном языке. И ровно то, из-за чего выбор языка не будет стоять если нужно будет создать самый эффективный код (Форт упустим). Не потому что у Си лучший синтаксис, а потому что именно под него написали лучший компилятор.

Для VM — оптимизируется байткод.
А с С интеловские SSE/AVX интринсики, которые казалось бы, напрямую переводятся в ассемблерный код, тоже оптимизируются.

і не згадали жодного проекту на Scala

Linkedin, частично. Но вроде откатились назад на Java.

на плюсы — никогда, если сильно поест то на джаву максисмум.

Но вроде откатились назад на Java.
То они не умеют скалу готовить. Надо им Головача с курсами посоветовать, иначе им никогда не достичь совершенства самостоятельно.

LinkedIn, Twitter, Foursquare, Netflix, Tumblr, The Guardian, precog, AirBnB, Klout
ну і пару проектів від Apache: Spark, Kafka, Samza.

KDE написан полностью на C++

На джаваскрипте кеды написаны.

А где джава?

Во-первых, konqueror давно RIP

Во-вторых, ищите проекты с QtQuick, там сплошной дж-с

малонужных вещей из KDE

Например плазма, ага

Вроде mate с cinnamon на джаваскрипте написаны.

Я по памяти писал, помню что когда-то читал что один из десктоп менеджеров минта написан на джаваскрипте
en.wikipedia.org/wiki/Cinnamon_(software
Written in C, JavaScript, and Python

QML это, все таки, не дж-с. Да и транслируется он в cpp

QML это, все таки, не дж-с.

QML --- это как html, вроде не дж-с, но без дж-с ничего интерактивного нельзя сделать.

Да и транслируется он в cpp

Лолшто? Ни черта там не транслируется. Компиляция qml кода происходит в рантайме (при старте).

Во-первых доступно только начиная с Qt 5.3

Во-вторых, “.qml files as well as accompanying .js files can be translated into intermediate C++ source code.” — о да, вставки дж-с кода в плюсах.

Подписаться на комментарии