Французский разработчик, действующий под псевдонимом Dominus Carnufex, на практике продемонстрировал (https://dominuscarnufex.github.io/cours/rs-kernel/en.html) реалистичность идей по переписыванию ядра Linux на языке Rust (https://www.rust-lang.org/en-US/). В настоящее время Rust уже хорошо показал себя в качестве языка низкоуровневого системного программирования и даже существует несколько (https://www.opennet.me/opennews/art.shtml?num=46459) проектов (http://os.phil-opp.com/) по разработке новых операционных систем на языке Rust. Автор исследования относится к проектам по созданию новых ОС скептически, считая, что у них нет шансов на завоевание рынка. При этом, более полезной выглядела бы постепенная переработка ядра Linux на Rust, что позволило бы решить многие проблемы с безопасностью.
Чтобы не выглядеть голословным Dominus Carnufex подготовил рабочий прототип реализации интегрируемого в ядро системного вызова, код которого написан на языке Rust. Предоставленный пример может рассматриваться в качестве отправной точки для постепенного портирования различных системных вызовов ядра Linux на Rust. Интерес к Rust прежде всего вызван предоставляемыми языком возможностями по безопасному программированию, избавляющими от проблем, возникающих в Си из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера.
URL: https://news.ycombinator.com/item?id=14479435
Новость: http://www.opennet.me/opennews/art.shtml?num=46652
Rustовики просто как сектанты какие-то.
Да ладно, пусть играются. В основную ветку всё равно эти эксперименты не попадут, а в своих модулях пусть что угодно делают.
> В основную ветку всё равно эти эксперименты не попадутТорвальдс известен тем, что нормальные вещи не тащит, а всякое непонятное тащит.
Давай-ка нам пример парочки "нормальных" по-твоему, и парочки "ненормальных", тогда и поговорим.
BFS / MuQS и BFQ затачивались под десктоп. Если BFQ пол года как готовиться войти в ядро, то BFS/MuQS туда не войдут тупо из-за конфликта между разработчиком который хотел поправить косяки и, собственно, Торвальдсом. С Райзером в свое время похожие терки были, когда Ганс написал типо "дублирующий" код, из-за того что VFS кривой был, а когда все претензии разработчиков были исправлены, то те начали придумывать надуманные причины. Зато приняли BTRFS у которой был только один черт вышедший из того-же Namesys и появилось нечто, у которой нет ни мат. обоснований алгоритмов и решений (если сравнивать с теме-же ZFS и R4, которые сначала прорабатывались, а потом уже на практике делались).За всю историю список можно большой накалякать.
Все правильно рейзер не включили, ментейнер VFS уперся рогом, ножно было сначало VFS патчить а потом уже проталкивать рейзер. Ребята из паралелс всеже умудрились протащить большую часть кода. Они то знают какая это боль.
> BFS / MuQS и BFQ затачивались под десктопПроверял у себя - никакого выйгрыша в производительности они не дают. Да и исследования проводили - какие-то сотые процента выйгрыш там.
Я не защищаю Линуса, но просто всё, что ты тут перечислил не сильно то и нужно на десктопе. Если говорить про дектоп, конечно. Кому нужно - тот сам соберёт.
Планировщики сомнительно, но вот BTRFS может быть на серверах будет к месту. Насчёт Reiser мутная история с разработчиком, да и что-то я не видел, чтобы кто-то продолжал разработку.
Й я думаю, что баловство все этй планйровщйкй.
>> BFS / MuQS и BFQ затачивались под десктоп
>Проверял у себя - никакого выйгрыша в производительности они не дают. Да и исследования проводили - какие-то сотые процента выйгрыш там.Приветствуем новую волну линуксоЕдов - нескучную, молодёжную.
А мне как седожопому админу остаётся только попискивать в уголку - оно же ***ЛЯ! не для улучшения производительность!, оно же **ЛЯ! для улучшения ...
А впрочем - ладно, вы всё равно даже слова такого не знаете :-\Так победим! или ?
Не сообщение, а какой-то шизофренический бред, не обижайся :) Откуда стиль такой, бородатый ты наш?> А мне как седожопому админу остаётся только попискивать в уголку - оно же ***ЛЯ! не для улучшения производительность!, оно же **ЛЯ! для улучшения ...
Договаривай давай.
BFQ == CFQ == никакой разницы между этими двумя не существует на данный момент. Баловство и NIH синдром, в общем.
Даже на их сайте написано:
> BFQ achieves the same throughput as CFQ
Вопрос: на кой ляд?!
> MuQS
Есть в ядре, не помню с какой ветки. BFS писалась как замена ему. Не заменила, судя по всему. Используется по умолчанию в целых 3 (sic!) дистрибутивах! Даже гугля выкинул её из своего ведройда ещё на ветке 2.2, потому что не было видимых улучшений. Короче говоря не сильно то оно нужно кому-то.
> Давай-ка нам пример парочки "нормальных" по-твоему, и парочки "ненормальных",
> тогда и поговорим.Припоминается affix vs bluez (где чистой воды непонятка, покрмере для меня) и в какой-то мере evms vs lvm2 (где куда понятней, но всё равно досадно).
Уродливый синтаксис располагает к сектантству: см. лисп и другие. Разного пошиба шизофреники на такое моментально липнут.
> Уродливый синтаксис располагает к сектантству: см. лисп и другие. Разного пошиба шизофреники
> на такое моментально липнут.Ваш вброс настолько прекрасен, что прямо неймётся спросить, каков же Он, прекрасный синтаксис, на котоорый льнут строевым гранёным выверенным шагом солдафоны, стриженные под одну гребёнку?.... Сорвите же покровы, маэстро.
Си. Все популярные языки имеют Си-подобный синтаксис. Чем меньше язык похож на Си тем меньше у него шансов. Ну кроме, может, каких-то узкоспециализированных задач, где заточенность языка под конкретные нужды важнее удобства и красоты.
И не надо мне рассказывать про Фортран. Он омерзителен.
Хех. Так ведь как раз в лиспах удобства и красоты достичь куда легче за счёт гибкой системы макросов. В этом ведь и есть сила лиспов: не существует ситуации, когда тебе хочется сказать "было бы здорово иметь синтаксическую конструкцию, чтобы выполнить это действие в одну строчку", потому что если она возникает, ты раз - и изменяешь синтаксис языка, как тебе вздумается.Вы несколько нечестны, придавая большое значение синтаксису. Синтаксис языка выучить - это ж делов-то на неделю, каким бы язык ни был. Основная задача после этого - изучение библиотек, эффективных методов разработки, выработка стиля написания кода. Да будь там хоть BEGIN/END или let/in вместо фигурных скобок - от этого алгоритм сильно не изменяется.
> Так ведь как раз в лиспах удобства и красоты достичь куда легче за счёт гибкой системы макросов.Как показала практика, существенного успеха на рынке промышленных языков это не дает. Лисп так и остался местечковой игрушкой для фанатов.
> Вы несколько нечестны, придавая большое значение синтаксису. Синтаксис языка выучить - это ж делов-то на неделю, каким бы язык ни был.
Я считаю, что синтаксис должен быть удобным и понятным. Иначе получается в духе
"Вы несколько нечестны, придавая большое значение удобству кресла. Деформировать свой позвоночник до нужной формы - это ж делов-то на неделю, каким бы кресло ни было."
> Как показала практика, существенного успеха на рынке промышленных языков это не дает.
> Лисп так и остался местечковой игрушкой для фанатов.Даёт, даёт. Вас просто близко не подпустят к _такой_ промышленности, где макросы N-го уровня вложенности.
Там другие проблемы и они в первую очередь (меж)человеческие.
>в лиспах удобства и красоты достичь куда легче за счёт гибкой системы макросовВот только в Лиспе удобства и красоты нужно достигать, а в Си удобство и красота идут "из коробки".
> в Си удобство и красота идут "из коробки".Соболезную. Нет, правда, опускаю руки. Ваши стойкие убеждения вылечат только время и опыт.
Ви таки хотите сказать, что в Си уже не приходится ручками память себе выделять и освобождать?А ежели это до сих пор не так - кушайте сами такую красоту. И удобством обмазаться не забудьте...
>Ви таки хотите сказать, что в Си уже не приходится ручками память себе выделять и освобождать?Это настолько важный параметр для языка системного программирования? ORLY?! :-)
Для клепания складофф\магазинофф^W извиняюсь - The Business Logic Layer (о как звучит!) - есть 100500 языков сделанных именно для этого.PS: Но и в С, если уж так неймётся - есть соотв. либки, и даже работают.
>>Ви таки хотите сказать, что в Си уже не приходится ручками память себе выделять и освобождать?
> Это настолько важный параметр для языка системного программирования? ORLY?! :-)Ну, большая часть современных языков внезапно ее почему-то включает.
> Для клепания складофф\магазинофф^W извиняюсь - The Business Logic Layer (о как звучит!)
Да, да. Склады, системы компьютерной алгебры... 100500 реальных вещей, которыми в основном люди и занимаются.
> PS: Но и в С, если уж так неймётся - есть соотв. либки, и даже работают.
"Либки" способны расширять синтаксис С? Спасибо, повеселил.
>а в Си удобство и красота идут "из коробки"...которые, зачастую, куда-то пропадают при написании чего-то существенного.
Ну так плюсы надо брать. Современные (11 и дальше). Всё будет и быстро и красиво.
> Ну так плюсы надо брать. Современные (11 и дальше). Всё будет и
> быстро и красиво.Кроме компиляции и описания ошибок в каких-нибудь шаблонах.
Меня в C++11 и дальше раздражает то, что люди везде пихают std::. В результате простое и понятноеList.map (fun x -> x + 1) [1;2;3;4;5]
превращается в чёрт знает что о двух строках.
Если вас раздражает только это, значит С++ очень хороший язык
> Если вас раздражает только это, значит С++ очень хороший языкВ данном случае я пристрастен - тут лучше на кого-то другого смотреть, помоложе.
> Меня в C++11 и дальше раздражает то, что люди везде пихают std::.А мне наобарот не понимаю тех, кто использует using namespace std; и потом не понять, толи из std эта функция, толи откуда.
Самый треш — это когда
> using namespace std;написан в хедере... :S
>Ну так плюсы надо брать. Современные (11 и дальше).Вкусовщина. Щас тут и без меня объяснят что жаба давно уже быстрее процессора, а ребе можно распостранять как образ ВМ снятый с машины разработчика :-)
>Всё будет и быстро и красиво.Для делания аппликух всё будет лучше чем на голом С. Но если сравнить с чем то заточенным под это ... мнения начинают разделяться (С)
Удобство? Вы хоть один сложный проект пробовал писать на Си? Да, язык хорош, но как раз удобства ему и не хватает.
1. Нет switch..case для константных строк. Почему? Ведь это же удобно. Компилятор сам бы строил дерево по символам строк и это работало бы максимально быстро, т.к. автомат состояний встроен прямо в код.
2. Для того, чтобы из switch сделать break циклу приходится вставлять метку и делать goto. Удобно? Нет.
3. Почему я не могу в switch..case.. использовать continue (как ни странно он то применяется уже к циклу) для явного перехода к следующей case? Почему для этого мне обязательно требуется писать комментарий /* no break */, чтобы моя IDE не ругалась?
4. pthreads. pthread_cancel, освобождение ресурсов. Если сталкивались (без lazy), сразу поймёте о чём я.
5. static - только для одного файла. Если же я делаю внутреннюю переменную в библиотеке, состоящей из нескольких файлов, то она в любом случае будет доступна и вне библиотеки. private я её могу сделать только одним способом: через атрибуты компилятора. Задефайнено, непортабельно и некрасиво.
6. Макросы - гибкость. А теперь попробуйте сделать макрос с выполнением действия в зависимости от размера передаваемой в него переменной. Увы, придётся много гуглить и делать костыли. А в итоге просто найти другое решение проблемы. А всё почему? Потому что sizeof выполняется в runtime, чтобы можно было определять размер стековых массивов. Куча возможностей просто исчезла.
7. Попробуйте сделать следующее:
fmt = NULL;
if (fmt) {
fprintf(stderr, fmt, ##args)
}
Для компилятора с включенной опцией format-security это ошибка. Т.к. NULL нельзя передавать в качестве формата. Ещё куча возможностей исчезли, либо придётся жертвовать безопасностью и выключать опцию.И т.д.
> Удобство? Вы хоть один сложный проект пробовал писать на Си? Да, язык
> хорош, но как раз удобства ему и не хватает.Нет, на Си все проектые просты, будьто ОС, движек для любимого джит, браузер или другая элементарная вещь. В то время любой сложный софт уже на си не напишешь.
> 1. Нет switch..case для константных строк. Почему? Ведь это же удобно. Компилятор
> сам бы строил дерево по символам строк и это работало бы
> максимально быстро, т.к. автомат состояний встроен прямо в код.Самое время именно вам выдать эффективную реализацию, этой фичи. ))
> 2. Для того, чтобы из switch сделать break циклу приходится вставлять метку
> и делать goto. Удобно? Нет.Т.е. вот так вот нельзя?
int i = 10;
switch (i)
{
case 10:
{
size_t u;
for (u=0; u<100; u++)
{
printf("test");
break;
}
}
break;default:
break;
}
> 3. Почему я не могу в switch..case.. использовать continue (как ни странно
> он то применяется уже к циклу) для явного перехода к следующей
> case? Почему для этого мне обязательно требуется писать комментарий /* no
> break */, чтобы моя IDE не ругалась?Ну тут да, нерадивые разработчики не учли, возможность существования IDE для детей солнца.
> 4. pthreads. pthread_cancel, освобождение ресурсов. Если сталкивались (без lazy), сразу
> поймёте о чём я.Это намек на pthread_detach ? ))) А еще плохо в си то, что можно вот так написать
int* v = NULL;
*v = 0;
неудобный язык, потому что считает что программист не олигофрен и знает что делает. )> 5. static - только для одного файла. Если же я делаю внутреннюю
> переменную в библиотеке, состоящей из нескольких файлов, то она в любом
> случае будет доступна и вне библиотеки. private я её могу сделать
> только одним способом: через атрибуты компилятора. Задефайнено, непортабельно и некрасиво.Единственный пункт который можно считать сказанном по теме. И то, необходимость такова шаринга субъективна. Ну т.е. попахивает нехорошим кодом.
> 6. Макросы - гибкость. А теперь попробуйте сделать макрос с выполнением действия
> в зависимости от размера передаваемой в него переменной. Увы, придётся много
> гуглить и делать костыли. А в итоге просто найти другое решение
> проблемы. А всё почему? Потому что sizeof выполняется в runtime, чтобы
> можно было определять размер стековых массивов. Куча возможностей просто исчезла.Поддерживаю, это может писать либо наркоман, или человек который не имеет понятия о чем пишет вообще. Ну, хипстер по нашему.
> 7. Попробуйте сделать следующее:
> fmt = NULL;
> if (fmt) {
> fprintf(stderr, fmt, ##args)
> }
> Для компилятора с включенной опцией format-security это ошибка. Т.к. NULL нельзя передавать
> в качестве формата. Ещё куча возможностей исчезли, либо придётся жертвовать безопасностью
> и выключать опцию.Ты же овнокодер ))) Но если уже нужно писать такой трэш? то кто мешает отключить варнинг только для этого куска кода? Такую фичу даже не компилятор поддерживает, не говорю уже о gcc.
> И т.д.
Да продолжай позорится.
> 5. static - только для одного файла. Если же я делаю внутреннюю
> переменную в библиотеке, состоящей из нескольких файлов, то она в любом
> случае будет доступна и вне библиотеки. private я её могу сделать
> только одним способом: через атрибуты компилятора. Задефайнено, непортабельно и некрасиво.
>Единственный пункт который можно считать сказанном по теме. И то, необходимость такова >шаринга субъективна. Ну т.е. попахивает нехорошим кодом.Положи ее в анонимный неймспейс и будет тебе счастье.
Видимо, далеки от системного программирования и высокого мнения о своих знаниях. Со временем или сменой работы второе проходит.>> pthread_detach
valgrind вам в помощь, и огромного вам suppress. А если ещё и реентабельно должно быть, то удачного креша всего линукса через какое-то время.
>> Самое время именно вам выдать эффективную реализацию, этой фичи. ))
С понятием стандартов знакомы? Судя по ответу, - нет.
>> Поддерживаю, это может писать либо наркоман, или человек который не имеет понятия о чем пишет вообще. Ну, хипстер по нашему.
Типа обозвали разработчиков ядра? Или просто не знаете, чем вы пользуетесь на компьютере? Исходники хоть раз в жизни смотрели?
>>> 1. Нет switch..case для константных строк. Почему? Ведь это же удобно. Компилятор
>>> сам бы строил дерево по символам строк и это работало бы
>>> максимально быстро, т.к. автомат состояний встроен прямо в код.
>> Самое время именно вам выдать эффективную реализацию, этой фичи. ))
>С понятием стандартов знакомы? Судя по ответу, - нет.Уж чья бы корова мычала! (С) :-)
Скажи мне О Знаток Стандартов - есть ли в С тип строка? :-)))))))
А посему и остальной бред на-вид-шоколадо-кодера можно спустить в трэш :-)))))
Может перед тем как задавать вопрос, почитаете про NULL-terminated arrays?
Вот черновик стандарта:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1539.pdfУдачи.
На всякий случай ещё главу скажу: String literals. Если с английским проблемы.
О, нашелся поклонник, расставил плюсы/минусы. Держи вырезку из твоего источника:6.4.5 String literals
>In translation phase 7, a byte or code of value zero is appended to each multibyte
character sequence that results from a string literal or literals. 78) The multibyte character sequence is then used to initialize an array of static storage duration and length just sufficient to contain the sequence.
>The multibyte character sequence is then used to initialize an array
>initialize an arrayИ дальше, по тексту:
>For character string literals, the array elements have type char, and are initialized with the individual bytes of the multibyte character sequence.
>the array elements have type char
>type charПро юникод-строки:
>For UTF −8 string literals, the array elements have type char, and are initialized with the characters of the multibyte character sequence, as encoded in UTF −8. For wide string literals prefixed by the letter L, the array elements have type wchar_t and are initialized with the sequence of wide characters corresponding to the multibyte character sequence, as defined by the mbstowcs function with an implementation-defined current locale.
>the array elements have type wchar_tНу и вся оставшаяся простыня:
>For wide string literals prefixed by the letter u or U, the array elements have type char16_t or char32_t, respectively, and are initialized with the sequence of wide characters corresponding to the multibyte character sequence, as defined by successive calls to the mbrtoc16, or mbrtoc32 function as appropriate for its type, with an implementation-defined current locale. The value of a string literal containing a multibyte character or escape sequence not represented in the execution character set is implementation-defined.
Емое. Вы бы сами читали, что даете...
Контекст разговора читали? Человек, на мой взгляд, придрался к понятию строк из самого первого моего сообщения (по контексту дальше был отсыл в стандарт). Я дал ссылку на разъяснение, что в стандарте они прописаны. Извините, но я читаю быстро, сразу не дошло, что там пытаются придраться к терминологии.
> Контекст разговора читали?Не нужно оправдываться.
>Извините, но я читаю быстро, сразу не дошло, что там пытаются придраться к терминологии.
Да, мы все тебя простили. Тут дело не в терминологии, а ПОНИМАНИИ основ сишки. Если копать еще глубже, то даже не сишки, а то с чем работает процессор. Так вот, у процессора максимальный "тип" данных это байт (иногда еще считают "слова", но это только частный случай). В более старых микроконтроллерах (их уже никто не считает за компьютеры) максимальный тип был бит.
И нету никаких типов строк. Даже массив и то это не совсем тип, а абстракция, т.к. внутри всеравно байты. Именно по этой причине, sizeof не может работать в рантайме, т.к. неизвестно, где заканчивается поток _байтов_. Выбор нульбайта был в _свое_время_ очень хорошим решением, но как показала время, это не окончательное решение. Сам размер массива данных запихивают в регистры, но это уже совсем low-level programming, как раз то, чем занимаются писатели компиляторов. Об этом прикладному сишнеку _благо_ думать не нужно (и собственно sizeof это делает за тебя).
То, что в других ЯП можно в рантайме вычислять размер массива это не заслуга ЯП. Все, что он делают это такая банальщина:
struct string_s {
char **data; /* как определить -- на любителя */
unsigned length; /* length of string in data */
size_t size; /* total size of data, in bytes */
/* навороты */
size_t start; /* если делаем вырезку с начала строки, то вместо изменения ее, просто указываем откуда она начинается */
size_t end; /* если режем хвост строки, то не нужно ее перелапачивать, просто указываем, где ее конец, в случае "восстановления ", просто указываем предыдущее место, т.е. бывшее (текущее, зависит от реализации) значение length */
};Т.е. заранее _знают_ какой длины строка, заранее _знают_ какой размер отведен под данные, чтобы уместилась строка (чтобы меньше дергать *alloc и т.п.). И при необходимости делают за ТЕБЯ стандартный realloc(). Все это "удобство" пишется в сишке за день-два и про это забываешь как про кошмарный сон. Либо, ты берешь готовую либу и наслаждаешься тем же, чем наслаждаются другие.
Плюс сишки в этом вопросе в том, что ты МОЖЕШЬ от этой бесполезной ерунды отказаться, КОГДА ты захочешь. А они не могут.
>> Так вот, у процессора максимальный "тип" данных это байт.Нет, не обязательно. И уже достаточно давно. Это для компилятора минимальный тип данных. Подсказывать не буду, сами думайте, раз умничаете.
>> sizeof не может работать в рантайме
Он именно в рантайме и работает. А вот на этапе препроцессора его очень сложно заставить работать. Но разработчики ядра нашли одну "фичу" и могу сделать assert на размер типа данных. Этим применение в препроцессоре и ограничивается. В моём случае применение sizeof требовалось пару раз для определения размера типа переменной. Зачем уже не вспомню, давно было. Возможно, для определения double ли был передан или float в unit-тестах, кажется.
Ну а так, немного магии:
void abc(int size)
{
volatile int buf[size]; // volatile - на случай, если вы какой-нибудь там -O3 используете, чтоб препроцессор не спихнули
printf("%zu\n", sizeof(buf));
}
Для VLA - это Вы его описали в примере - сделано исключение, которое в компиляторе обрабатывается специальный образом. В остальных случаях sizeof() вычисляется в compiletime-е. Если не ошибаюсь, то в C++ поддержка VLA есть, а вот sizeof-а для него - нет.
VLA в C++ отсутствует.
Он есть исключительно в C.
В контексте вопроса не имеет значения, на этапе препроцессора sizeof всё равно не доступен как раз по причине того, что используется в runtime. За исключением того случая, который я упомянул. А выглядит он примерно так:
#define ASSERT(a) do { x[(sizeof(a) == 4) - 1]; } while (0)Проверять не хочу, правильно написал или нет, кому требуется сам добьётся эффекта. Но по идее должно сработать. Идея, думаю, понятна.
Нашёл таки файл, где находится файл, о котором тут рассказывал:
http://elixir.free-electrons.com/linux/latest/source/include...Макрос BUILD_BUG_ON. В новых версиях gcc он уже не используется, а со старыми приходилось так делать. И там ещё много интересных макрохаков на Си. И описано, зачем они вообще были сделаны. Думаю, чтение комментариев этого файлика будет завершающим ответом на вопрос про удобство Си.
Если б сделали новый язык, оставив синтаксис Си, но избавившись от его недостатков с полной потерей обратной совместимости, я был бы рад. А то до сих пор не могу делать анонимное наследование структур без расширения ms-extensions.
А разве в языках Alef и Limbo из Plan 9 и Inferno не избавились от недостатков С с полной потерей обратной совместимости?
>> sizeof не может работать в рантайме
>Он именно в рантайме и работает.Это не излечимо <сарказм>. Во-первых, sizeof это оператор. Чтобы понять, почему в рантайме sizeof не работает, достаточно [s]прочитать[/s], посмотреть на данный код:
#include <stdio.h>
int foo(int a[]) {
return a[1];
}int main(void) {
printf("%d\n", foo((int[]){1,2,3}));
//printf("%su\n", sizeof((int[]){1,2,3}));
return 0;
}Этот код вам уже показывали, однако, здесь в закомментированном участке указан НЕ работающий код. Это происходит потому, что sizeof работает только в момент компиляции.
Подробности:
1. http://en.cppreference.com/w/cpp/language/expressions#Uneval...
2. http://en.cppreference.com/w/cpp/language/sizeofЧтобы работало как вы хотите, нужно писать структуру, о которой я рассказывал. Плюс вам намекнули на VLA, однако реализация VLA не позволяет просто так в одиночку передавать массив в функцию, всеравно нужно указывать кол-во элементов.
Я уже говорил, что вам нужно больше читать книжки. Вот, рекомендую найти книгу Харбисонна, там многие ответы на ваши вопросы даны.
Я разве задавал вопросы или написал что-либо неправильно? На кой сдались мне ваши книжки? На практике вам нужны хорошие навыки алгоритмизации, творческое мышление и непрерывное чтение документации. Книжки на самом деле помогают только в начале, стартовый толчок. Конечно, есть классика, которую должен прочесть каждый, а-ля Таненбаум]6 что-нибудь по теории графов, немного нейронных сетей, генетических алгоритмов (честно, сам последних двух тем почти не касался) и подобные, но книги по конкретным языкам программирования бессмысленны для тех, кто уже знаком хотя бы с тремя языками. А пока ничего нового тут не написали. Обмусоливание темы run-time, compile-time. Это при том, что до всего этого можно догадаться чисто интуитивно, даже не имея большого опыта за плечами. Тут ещё не хватает, чтоб оптимизатор вспомнили или про align'ы заговорили. Какой курс то лучше скажи? Третий или четвёртый? :)
>книги по конкретным языкам программирования бессмысленны для тех, кто уже знаком хотя бы с тремя языкамиИзвините, г-н архитектор, просто с такими "идеалами" неудивительно, что кто-то потом путает типы с литералами. Я б еще понял, что вы автор хотя бы 1-го известного компилятора, а посему имеете право не читать книги, а так, вы скатились. Да, скатились, вам лень _вникать_. Хотя чего учить архитектора.
Не хотите говорить, как хотите. А ведь интересно проверить интуицию то. Книжки должны советовать два типа людей: студенты и преподаватели. Первые т.к. полны энтузиазма из-за того, что узнали много нового, отсюда и высокая самооценка идёт. А вторые по привычке. Вы ко вторым точно не относитесь.Желание учить людей и объяснять им как правильно, а как нет, что читать, что не читать, - это хорошая черта. Есть шансы в будущем стать тимлидом. Но тут как бы много нюансов.. например, вы должны научиться правильно это делать и правильно всё преподносить. И ни в коем случае не заявлять о превосходстве своих знаний, лучше задавайте вопросы, ждите пока не них ответят, полемика должна быть в форме диалога. В опенсурс-проектах есть одна хитрость. Когда человек делает merge request, даже если проверяющий уверен на 100% в своей правоте, он часто сообщает об ошибке в форме вопроса: "А вы уверены, что в этом случае не может быть то-то и то-то?". Здесь суть в том, что так вы не отпугнёте человека и заставите думать, нежели спорить. А если бы вы сделали уверенное заявление и сами ошиблись, то у контрибьютора просто упало бы о вас мнение и он остальные вещи стал бы делать наперекор с большей вероятностью.
Мотайте на ус и учитесь учтивости.
>Вы ко вторым точно не относитесь.Фиговый из вас психолог, продолжайте рисовать архитектуры.
Интересно что ли, почему такие выводы? Могу пояснить. У преподавателей есть собственный этикет. Они не то, чтобы матерные слова, но и мусорные говорить не могут. Если преподаватель (пусть даже анонимно) позволяет себе вести себя неподобающе, то такому не место в образовании. К тому же преподавание даёт невероятную выдержку и психологическую устойчивость. Такого человека очень трудно вывести из себя или взбесить. Такие издержки профессии. А умение находить подход к людям формируется за года два - три, поэтому преподаватели обычно должны быть хорошими психологами и должны уметь находить подход к разным типам людей, будь то практик, теоретик (отличник) или гуманитарий. И в этих подходах не будет попыток принижения или оскорбления, т. к. такие подходы ведут к обратным эффектам и недопустимы. Любой грамотный преподаватель знает всё это.
>Интересно что ли, почему такие выводы?Потому что ты людей делишь на студентов и преподавателей. Ты сам-то кто? А родители? А друзья? Тоже все студенты или преподаватели? Нет, это, конечно, возможно, что ты вырос именно в _такой_ среде...
Вобщем, с таким ограниченным взглядом на мир лучше в психологию не лезть.
Просто для человека, который до сих пор не похвастался, какой он крутой и чем занимается, после столько изливаний знаний... остальные варианты кроме студента достаточно печальные.
>остальные варианты кроме студента достаточно печальные.Печально, что твой кругозор такой узкий. Я не студент и я не преподаватель. Зови меня просто призрак =))
Ты понимаешь, что когда человек не выеживается, то он уже в возрасте? Нет. Ну, подрасти, поймешь почему выеживаться глупо. Как там в ватмане, человека обычно судят по поступкам. Все что я сделал знают определенные люди и я доволен этим. Да, я достиг чего-то, только этого мало. Нужно больше вкалывать, а на опеннете я болтаю на интересные _мне_ темы. Про себя говорить с кем попало НЕ интересно.
Беседовать одно, а умничать - другое. Я уже долгое время молодёжь пытаюсь направлять в правильные русла, четырёх программистов взрастил уже, научил всему чему мог научить. Так что к совету насчёт отношения к другим людям прислушайся. Если сейчас начнёшь работать над собой, в будущем будет намного проще, когда начнётся работа в команде. Программирование для себя и работа в команде - это два абсолютно разных мира.
Не понятно чего ты добиваешься. С чего ты взял, что у меня есть проблемы с отношением к другим людям? Может и есть, так это потому, что делю людей на своих и чужих. С чего ты взял, что нужно присмыкаться перед чужими людьми? С чего вдруг я должен к ним вежливым быть? Что они сделали для меня? А что сделал для них я? Вот именно, что ничего. Поэтому либо они принимают меня какой я есть, либо не принимают. Лично я их принимаю такими какие есть. Еще и даю какие-то подсказки. А знаешь, даже на твоем примере ты всю мою помощь отослал в лес. Видишь ли ты архитектор, у тебя за плечами пятое-десятое и т.д. Т.е. уже изначально ты поставил себя выше меня. С чего вдруг? С того, что ты себя мнишь умнее других? Ну, так я же не плачусь, не ругаю тебя. Мне-то что с того, что ты себя пиаришь анонимным людям? Ты что, политик? Нет. Ну, так зачем все это?Вобщем, люди вокруг совсем недружелюбны, потому что у них имеется такой же детектор "свой-чужой". Это просто прописано в генах. Ты бы поубавил свои обороты, да направил в нужное русло. Например, так распинаться нужно перед девушкой. Она будет тебя слушать. А обычные люди, мужики в частности, на это не ведутся. Это даже тебя отталкивает от других людей, потому что ты пытаешься _навязать_ свой авторитет, а не заслужить. А чтобы чего-то заслужить нужно это доказать, либо сделать услугу. Так вот, ты не сделал услуги и ты не заслужил авторитет, наоборот, ты своим невежеством "я не читаю книг" его профукал.
Надеюсь, ты что-то да почерпнешь из этой простыни. И это не стоит расценивать за обучение. Потом еще скажешь спасибо, что переосмыслил свое поведение. Адьос амиго.
>> С чего вдруг я должен к ним вежливым быть?Потому что ты часть общества. Общество влияет на тебя, а ты на общество. И твоё влияние может быть в данном случае пагубным. Чтобы осознать это, необходимо прочесть по крайней мере 3 книги:
* Эгоистичный ген Диккенса,
* Мозг и душа Криса Фрита,
* Я вижу, о чем вы думаете Джо Наварро.>> Ну, так зачем все это?
Почему я тут развёл всю эту демагогию? Потому я такая же ячейка общества, как и ты, и осознаю это.
>И твоё влияние может быть в данном случае пагубным.Может я этого и хочу. Тебе бы в политики, учил бы всех что делать и как жить.
> * Эгоистичный ген Диккенса,
> * Мозг и душа Криса Фрита,
> * Я вижу, о чем вы думаете Джо Наварро.Ах, да. Спасибо за книги.
Вобщем, прав был тот, кто сказал, что для VLA сделано исключение для sizeof. В последнем случае sizeof работает в момент исполнения программы, в остальных случаях в момент компиляции. Однако, поскольку все делается на стеке, то пользы от этого немного.И еще масса ограничений: http://docs.cray.com/books/004-2179-001/html-004-2179-001/z8...
Еще инфа для gcc: https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html>The length of an array is computed once when the storage is allocated and is remembered for the scope of the array in case you access it with sizeof.
>На всякий случай ещё главу скажу: String literals. Если с английским проблемы.Ohhh ... my dear, do you really wanna discuss how pure my English is?
Ok, lets go! my dear pidnish MgImO-finished friend :-)А чтобы показать насколько ты нуб сопливый в сях - покажи мне вот такое:
if ( "Anonimus" != "DubDubovy" ) { puts "Vy ffsie vreti!"; }
Ну как? КопилиЦЦо? :-)))) А что такое?!?! Не может сравнить два литерала существующего в языке типа??! Ну и лохи же были отцы-основатели! :-) Толи дело новые, модные, молодёжные Ыгспёрды :-))))
PS: А вообще спасибо! Давно не ржал так :) Сам наверное был таким .... давно :(
Вы вообще о чём? Зачем я буду это компилить? Тут банальное сравнение указателей, которое будет отброшено оптимизатором и заменится строкой puts. Я уже не говорю о том, что вы puts написан с ошибкой, без скобок. Сами б компилировали перед тем как умничать.
>NULL-terminated arraysЭто не тип. Хватит позориться! Можно со "строками" работать и без нуля, с известным значением размера МАССИВА: { 'h', 'e', 'l', 'l', 'o' }. Рекомендую больше читать книжек по сишке.
И уж совсем ж--а наступит, если понадобится работать с multibyte строками (я надеюсь, вы хоть знаете в чем их отличие от wide-string? :). Но еще круче, это уметь (а хотя че уметь-то) работать со строками, где разделить нуль-байт. И если, последние строки для все еще отдельный ТИП, то мне вас очень жаль (не, не жаль, это просто ахтунг с такими знаниями что-то доказывать).
P.S. Я если что, любитель :)
Да понятно, что любитель. Программист сразу писал бы про то, с чем сталкивался на практике (utf-*). Это для студентов такие строки multibyte будут. Да и программисты знают отличие понятия строки от типа данных (я вроде как дал ссылку на строковые константы, не?), не пытаясь высосать из пальца аргументы и придраться к терминологии, с которой сами особо не знакомы.Заметьте, те, кто у кого большой стаж программирования, будут стараться приводить примеры из своего опыта, нежели придираться к терминологии, чтобы повысить самооценку. Поверьте, здесь вы точно самооценку не повысите (если не уроните).
Но каждый раз вместо интересной дискуссии на тему, как было бы лучше, или как делаем "мы", видеть чьи-то попытки поднять свою самооценку, - немного огорчает.
>Программист сразу писал бы про то, с чем сталкивался на практике (utf-*). Это для студентов такие строки multibyte будут.Где будет? Что будет? Вы точно знаете ВСЁ про юникод или у вас это только наслуху? Там ничего фантастичного нет, сплошная математика и таблицы. Как по мне, вы просто мало работали со строками, поэтому вам кажется, что mb-строки это такое невиданное явление.
>>Программист сразу писал бы про то, с чем сталкивался на практике (utf-*). Это для студентов такие строки multibyte будут.
> Где будет? Что будет? Вы точно знаете ВСЁ про юникод или у
> вас это только наслуху? Там ничего фантастичного нет, сплошная математика и
> таблицы. Как по мне, вы просто мало работали со строками, поэтому
> вам кажется, что mb-строки это такое невиданное явление.Я про Юникод знаю лишь основы (коды служебных символов разумеется, я наизусть и не подумаю изучать), пока стараюсь его обработку обходить всеми возможными способами, хотя и активно использую. Конечно есть случаи, когда этого не избежать, например, когда требуется добавит строке ellipsize. Раз уж вы так много знаете, ответьте на вопрос. Почему я не хочу связываться с обработкой Юникода? Если правильно ответите, может ещё подискутируем.
>Почему я не хочу связываться с обработкой Юникода? Если правильно ответите, может ещё подискутируем.1. Я не телепат.
2. Это не клуб друзей.
3. Хочу/не хочу это для хобби, а в бизнесе либо ты решаешь _задачу_, либо не решаешь.И что-то мне подсказывает, что ваше "не хочу" означает, что для вас это хобби. Как выйдите работать в бизнес, тогда и подискутируем :)
>>Почему я не хочу связываться с обработкой Юникода? Если правильно ответите, может ещё подискутируем.
> 1. Я не телепат.
> 2. Это не клуб друзей.
> 3. Хочу/не хочу это для хобби, а в бизнесе либо ты решаешь
> _задачу_, либо не решаешь.
> И что-то мне подсказывает, что ваше "не хочу" означает, что для вас
> это хобби. Как выйдите работать в бизнес, тогда и подискутируем :)В бизнесе можно решить одну задачу парой сотен способов. Потом поймёте о чём я, как на работу, наконец сможете устроиться.
Сначала пройдёте этап сбивания спеси, будет длиться около года. С таким характером будут жёсткие споры с тимлидом, которые будут каждый раз в итоге заканчиваться фиаско для вас. Затем начнёте понимать, что вы делаете и зачем. Это ещё год - два. Уже настанет время, когда сможете писать качественный код, но, возможно, ещё плохо читабельный. Затем снова можно этап звезданутости настать, но он будет уже намного короче, быстро пройдёт, как только начнёте разбираться с исходниками не только своего проекта, но и сторонних. И как только тимлид вас снова потыкает носом, но уже в читабельность кода.
После всего этого научитесь уважать собеседников и коллег по работе, а также получите неплохую выдержку. А пока советую обратить внимание на личностные качества. В жизни подобные будут только мешать, даже если мозги есть. Сейчас, например, вы просто не переняли опыт программиста, который занимается разработкой архитектуры ПО, с достаточно большим стажем работы. Часто такой случай вам выдаётся? Я, например, по возможности никогда не упускаю такие случаи. И мне всегда интересно узнать мнение грамотных людей.
Ох, щи. Первое, я не перед кем не выеживаюсь. Второе, я не люблю учить других людей, потому что в 95% случаев они этого вообще не хотят. Третье, ваш вопрос был в стиле угадай мелодию. Простите, г-н архитектор, научитесь правильно ставить вопрос. Иначе получается, что mb-строки это такая несусветная фигня, которую _по-вашему_ мнению нужно выпилить. Увы, они были придуманы задолго до того момента как вы стали архитектором. Почему вы, да вы, когда изобретали mb-строки не сказали всем -- ЭТО фуфло, нужно делать так-то?Вывод таков, что нормальный умный ученик не станет задумываться и играть в игры архитектора, а пойдет писать код. Между прочим, я не программист и тимлиды для меня люди, которые принимают мои патчи. Да-да, принимают, и они в апстриме. Работают. Не, это было слишком пафосно. Я простой человек, чего пристали? :)
Рассказывай что там тебе не нравится в mb-строках, иначе не о чем будет дискутировать, кроме показухи.
Хуже когда switch внутри цикла.
Также вложенные циклы...
Но приходится отметить, что многоуровневый break n ещё гораздо хуже goto ...
> 7. Попробуйте сделать следующее:
> fmt = NULL;
> if (fmt) {
> fprintf(stderr, fmt, ##args)
> }
> Для компилятора с включенной опцией format-security это ошибка. Т.к. NULL нельзя передавать
> в качестве формата.Вообще-то ошибка потому что ,args есть инвалид (попытка склеить запятую с args)... Да и то должен быть макрос...
Макрос само собой, а со склеиванием не угадали. Это называется variadic macros:
https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
И сразу поправлю себя, видимо, у меня должно было быть ##__VA_ARGS__, тут я косякнул, да. Давно писал такие штуки.
> 6. Макросы - гибкость. А теперь попробуйте сделать макрос с выполнением действия
> в зависимости от размера передаваемой в него переменной. Увы, придётся много
> гуглить и делать костыли. А в итоге просто найти другое решение
> проблемы. А всё почему? Потому что sizeof выполняется в runtime, чтобы
> можно было определять размер стековых массивов. Куча возможностей просто исчезла.Открой файл curl/typecheck-gcc.h в поставке curl. Там такой макрос на проверку типов ...
Это обычный макрос. Я говорил о препроцессоре. Вот такое невозможно:
#if sizeof(expr) == sizeof(void *)
//...
#endif /* sizeof */В том файле это было бы бессмысленно, т. к. проверки просто удалятся оптимизатором, но через препроцессор, например, можно было бы объявить переменную того же типа, что ему передана для временных вычислений с проверкой на переполнение (а-ля auto для C++). Это просто для примера.
На самом деле в C есть возможность проверять тип переменной через typeof, но это всего лишь расширение GCC:
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
ПОэтому завязываться на него серьёзному проекту не стоит.
"Видимый" синтаксис - это прежде всего набор маркеров, позволяющий быстро понимать, что происходит, не вчитываясь в каждую строку. А, foreach - ясно, глянули, что и по чём итерируется - и всё. if - отлично, условие, ветка 1, ветка 2. Всё чётко отделено и визуально выделяется. А скобочки ваши - брейнфак в профиль, независимо от "мощности" и от того, что алгоритм не изменится. Потому что надо в первую очередь восприятие учитывать.Ну и к тому же - кастомный синтаксис это прикольно... Когда это небольшое дополнение к основному, перекрывающему абсолютное большинство потребностей. А основной - понимают IDE, линтеры, есть опыт его использования или наоборот - избегания, и так далее, и который знает абсолютное большинство пишущих на языке.
> "Видимый" синтаксис - это прежде всего набор маркеров, позволяющий быстро понимать, что происходит, не вчитываясь в каждую строку.Ну, этому помогает скорее не синтаксис, а кое-какие решения, принятые на этапе проектирования языка. Например отсутствие перегрузок.
А то как это часто бывает с плюсами, смотришь на код, там написано read(...), а у тебя этот самый read 7 раз переопределён в текущем пространстве имён.
Или отдельная песня с итераторами, для которых перегружен оператор стрелки, в результате чего оказывается, что i->clue.getExts() вызывает метод getExts класса, которому принадлежит поле clue текущего элемента, на который ссылается итератор i.> А, foreach - ясно, глянули, что и по чём итерируется - и всё.
(for ([i '(1 2 3)])
<code>)Вроде ясно, что i перебирает значения от 1 до 3, и для каждого выполняется блок <code>.
> if - отлично, условие, ветка 1, ветка 2.
(if <condition>
<true-branch>
<false-branch>)Офигенно "другой" синтаксис.
> Всё чётко отделено и визуально выделяется. А скобочки ваши -
> брейнфак в профиль, независимо от "мощности" и от того, что алгоритм
> не изменится.Есть у меня подозрение, что этого мнения придерживаются люди, которые полезли править sexp-ы в редакторе, который не поддерживает подсветку парных скобок и автоматическую расстановку равных отступов для выражений одного уровня вложенности. Детектирую это простым вопросом: а json или xml как способ хранения данных чем-либо отличаются от sexp-ов?
> Ну и к тому же - кастомный синтаксис это прикольно... Когда это небольшое дополнение к основному, перекрывающему абсолютное большинство потребностей.
Ну в общем да, тут есть нюанс: прежде, чем создавать новый макрос, надо трижды подумать, а нужно ли оно вообще. Ибо макрос визуально не отличается от любого другого символа, но можно огрести при попытке передать его параметром в функцию высшего порядка. Однако, справедливости ради, перед сишниками такой проблемы просто не возникает, потому что у вас тупо нет функций высшего порядка (точнее, есть, но очень сильно кастрированные).
> Однако, справедливости ради, перед сишниками такой проблемы просто не возникает, потому что у вас тупо нет функций высшего порядкаИ слава б-гу что нет.
>> Однако, справедливости ради, перед сишниками такой проблемы просто не возникает, потому что у вас тупо нет функций высшего порядка
> И слава б-гу что нет.Вот Вы говорите, "слава Богу", а программирование меняется самым кардинальным образом, когда у разработчика есть такой мощный инструмент.
Вот простейшую сигму реализовать на сях - надо извернуться. А в функциональных языках - одна строчка.
Вообще есть мнение, что если язык позволяет просто выражать сложные вещи, то такой язык определённо стоит учить.
И потом в этой одной строчке черт ногу сломит. Спасибо не надо.
Чёрт ногу сломит, ага:
; определяем сигму
(define (sigma fun start stop [step 1])
(for/sum ([n (in-range start stop step)])
(fun n))); определяем последовательность f(n)=n
(define (f n) n); находим частичную сумму первых десяти элементов последовательности f(n)
(sigma f 1 10) ; => 45А вот что мы делаем, когда нам нужно просто суммировать все элементы в списке:
(define (sum list) (apply + list))
(sum '(1 2 3)) ; => 6Комментарии, думаю, излишни.
И по вашему это сильно проще ? По моему вас кто-то обманул.
> И по вашему это сильно проще ? По моему вас кто-то обманул.Напишите аналогичный код на Си. Ваше непонимание резко пройдёт. :)
Угу излишни. Образцово не нужная вещь. Переписываемая практически один в один на C. Ещё в шаблонах там то же самое замудрили. Но это плохая замена нормальномуforиз C.
>Вот простейшую сигму реализовать на сях - надо извернуться. А в функциональных языках - одна строчка.И что? Я вот каждый только и делаю, что пишу сигмы %) Раз в 50 лет такая задача ставится перед сишнеком. Он ее пишет раз. И забывает еще на 50 лет, т.к. она будет работать везде. А вот ваши функциональные ЯП жрут тонны памяти, фиг скомпилишь и т.д. и т.п.
Везде есть свои плюсы и минусы. Ах, да. Забыл, у фанатиков такого не бывает, только черное. И белое.
Соглашусь насчет синтаксиса Си, он реально хорош, и наверное действительно лучшее что сейчас есть; недаром большинство языков взяло его за основу (C#, Java и многие web-языки включая тот же JS). Но сам язык си все-таки устарел и в общем нуждается в замене (как и С++ с его монструозными шаблонами). Крайне небезопасный лексический препроцессор, намертво прибитый к языку гвоздями; отсутствие модульности и архаичный механизм include; местами недостаточно строгая типизация (хотя и слишком строгая тоже ни к чему); да даже такая вещь как "имя массива является адресом первого элемента массива", делающая массивы не first-class сущностями и приводящая ко многим весьма неочевидным нелогичностям и неудобствам для развития языка...Rust это всего лишь эксперимент, как и Go, D, Nim и многие другие. Полигон для обкатки идей - в случае с Rust это семантика умных указателей встроенная в язык, хотя там и еще кое что есть. Если есть желающие обкатывать на реальных проектах типа ядра - почему бы и нет, пускай обкатывают и выявляют неудобные места в языке. Синтаксис там действительно тяжеловат для восприятия. Не знаю почему, но код на тех же C# или Java читается гораздо легче.
> Rust это всего лишь эксперимент, как и Go,...Блажен, кто верует. (c)
Тут все очень просто: если язык реально хорош во всем, то на нем будут писать и на него будут переходить с других языков. Если нет - то нет. Представьте себе, если появится такой "идеальный си", такой же эффективный, удобный и привычный как Си но со множеством улучшений, органично вписывающихся в концепцию языка - то на нем будут писать. Пока же все это лишь попытки зайти с разных сторон, эксперименты в различных направлениях.
> Тут все очень просто: если язык реально хорош во всем, то на
> нем будут писать и на него будут переходить с других языков.
> Если нет - то нет. Представьте себе, если появится такой "идеальный
> си", такой же эффективный, удобный и привычный как Си но со
> множеством улучшений, органично вписывающихся в концепцию языка - то на нем
> будут писать. Пока же все это лишь попытки зайти с разных
> сторон, эксперименты в различных направлениях."Множество улучшений" и "привычный" -- это взаимоисключающие параграфы.
Нет конечно. Привычный - это привычный синтаксис и привычная философия языка. Множество улучшений - это значит что улучшения будут в том же ключе что и существующие возможности. Они будут естественно и логично выглядеть на фоне существующих возможностей.
Ну вот самый простой пример пришедший в голову. Если в функцию можно передавать массивы, то почему нельзя передать литерал массива foo({1,2,3}); ? Этого вроде даже в расширениях gcc нет, хотя казалось бы чего сложного?
> Нет конечно.facepalm.jpg
Ладно, я объясню развёрнуто. Язык C имеет множество врождённых недостатков, о некоторых из них ты сам выше писал. Исправление любого из них автоматически сделает язык непривычным, потому что эти врождённые недостатки давно стали привычными.
Если из языка удалить какое-то привычные каловые массы, не затронув ничего остального, то язык станет непривычным.
> Если в функцию можно передавать массивы, то почему нельзя передать литерал массива foo({1,2,3});
Не знаю почему у вас нельзя, а у нас можно:
int foo(int arr[]) {
return arr[0];
}int main()
{
return foo((int[]){0, 1, 2, 3});
}Тип только приходится явно указывать приведением, но нестрогость строгой типизации в C делает это необходимым.
> язык реально хорош во всемА во всём не надо. Надо только в том, что составляет суть решаемой проблемы. Писать «скрипты на баше» на C — такой же бессмысленный тупняк, как и писать прикладной софт на Malbolge. Идеального языка программирования нет в первую очередь потому, что он просто не нужен. И лишь после этого потому, что он невозможен.
>GoЭто язык совсем другого назначения, нежели Rust и Nim. И он уже вполне взлетел в своей нише.
>Rust. Синтаксис там действительно тяжеловат для восприятия.
Авторы дают понять, что им пофиг на синтаксис.
>Rust это всего лишь эксперимент
Тогда все языки были "всего лишь экспериментами"
> Но сам язык си все-таки устарел и в общем нуждается в заменеНу есть D, например. Существует аж с 2007 года. Перешли на него? Нет. Значит не нуждается.
Ты ещё предложи ассемблер заменить. x86 ассмблер ух какой древний, нужно срочно заменить!!1111 Ну а чо, можно, стильно, молодёжно.> Крайне небезопасный лексический препроцессор
Что в нём небезопастного? Мне аж интересно стало. Я понимаю, если бы ты сказал ручное управление памятью -- небезопастно.
> архаичный механизм include
Я спешу тебя огорчить - во всех современных языках есть include в той или иной степени :) Просто реализован он немножечко по разному, но суть осталась та же.
> местами недостаточно строгая типизация
Примеры?
> (хотя и слишком строгая тоже ни к чему)
Ты уж определись.
Товарищи, давайте уж не будем гнать на С, а? У каждого языка свои недостатки, но я считал и буду считать всегда, что каждый язык нужен для своих целей. Давайте не будем плодить так называемые "языки общего назначения", тогда и синтаксис у них будет вменяемый.
>> Но сам язык си все-таки устарел и в общем нуждается в заменеМы с котом пол дня смеялись (С) :)
>Ну есть D, например. Существует аж с 2007 года. Перешли на него? Нет. Значит не нуждается.Оно было убийцей С++ ... но если ты не видишь разницы ...
>Ты ещё предложи ассемблер заменить. x86 ассмблер ух какой древний, нужно срочно заменить!!1111 Ну а чо, можно, стильно, молодёжно.Вам который из них? В списке если что сотни четыре 8-) И даже для x86 - даааалеко не один.
Но вот пришёл "высокоуровневый ассемблер" - то бишь С и на классике теперь только вставки пишут.>> Крайне небезопасный лексический препроцессор
>Что в нём небезопастного? Мне аж интересно стало.Ого! Дык ты Ыгсперт? :) Попробуй его по-использовать ... но я предупреждал :)
>> архаичный механизм include
>Я спешу тебя огорчить - во всех современных языках есть include в той или иной степени :)Чееегоооо?!?!?! Ну ка - ИмЬя его сестра!? (С)
Ни в одном из новых на такие явные грабли не наступали ... ну или говори ГДЕ? :)
>Просто реализован он немножечко по разному, но суть осталась та же.Му-ха-ха :))))
Ну то есть по твоему С-шный include и Go\Python import - это одно и то-же? :-)))
Воросов больше не имею! :-)))))>Товарищи, давайте уж не будем гнать на С, а?
Товарищи чертверть века как сдулись, но по сути согласен.
>У каждого языка свои недостатки, но я считал и буду считать всегда, что каждый язык нужен для своих целей. Давайте не будем плодить так называемые "языки общего назначения", тогда и синтаксис у них будет вменяемый.+100500
Тут согласен тоже.
> Оно было убийцей С++Ну хорошо, допустим. И кто убийца Си тогда? Нет таких?
> В списке если что сотни четыре
Ну уж 4 сотни. Известных и часто используемых не так уж и много. Хотя, по сути с ассемблерами тоже тот ещё цирк, примерно как с языками высокого уровня.
> Попробуй его по-использовать ...
Любой #define -- обрабатывается "лексическим препроцессором", постоянно его использую. Для макросов, например, очень удобно. А ещё в стандартной библиотеке Си всё на препроцессоре держится. Так примеры, желательно практического использования, этого "небезопастно" будут? Или всё только в теории, а потом оказывается, что работает только на седьмой день новолуния, когда в жертву принесена девственница.
> ну или говори ГДЕ? :)
Lua, Python, D -- это только из тех, что я использовал.
Что там у Джавы по другому работает, когда я делаю import? Ну да, я могу там отдельные классы подключать из файла, при этом не трогая другие, я правильно понимаю политику партии? Только плюсов я тут не вижу (ну может быть для джавы они и есть, но не для Си).
>> Попробуй его по-использовать ...
>Любой #define -- обрабатывается "лексическим препроцессором", постоянно его использую. Так примеры, желательно практического использования, этого "небезопастно" будут?Ну ты спросил! Целые труды написаны. Ну не езнаю, ну напиши сюда макрос для возведения числа в квадрат.
>> ну или говори ГДЕ? :)
>Lua, Python, D -- это только из тех, что я использовал.Про Lua я не знаю, про D не знаю и не помню :-)
Но если ты действительно считаешь, что Питонячий import и Cи-шный include - это одно и тоже, то ... то медицина тут практически бессильна! :-(>Что там у Джавы по другому работает, когда я делаю import?
А знаешь что тебя может спасти? Только если возьмёшь и __сам__ выяснишь. Оно того стоит. Честно.
> ну напиши сюда макрос для возведения числа в квадрат.Зачем для этого использовать макрос, если функция уже реализована в math.h? Зачем велописеды городить?
Но если тебе так хочется...#define pow2 (pow(x, 2))
Вызывается простым:
int x = pow2(integer_here);Но на самом деле это лишняя строчка кода, которая ещё и вводит в заблуждение.
> Но если ты действительно считаешь, что Питонячий import и Cи-шный include -
> это одно и тожеНу хорошо, хорошо, я хотя бы не считаю себя ИКСПЕРДОМ во всём. Объясни разницу, в таком случае.
> А знаешь что тебя может спасти? Только если возьмёшь и __сам__ выяснишь.
> Оно того стоит. Честно.Я честно пытался выяснить как это работает в джаве. Если я правильно понимаю, все классы подгружаются в память, а потом оттуда дёргаются. Но что там реально происходит я не знаю.
В Си просто подставляется полностью файл и всё склеивается в один.
Так разницу объяснить сразу можешь, а не говорить, мол: выясняй сам (потому что я не знаю, но продолжаю спорить).
>> Но если ты действительно считаешь, что Питонячий import и Cи-шный include -
>> это одно и тоже
>Ну хорошо, хорошо, я хотя бы не считаю себя ИКСПЕРДОМ во всём. Объясни разницу, в таком случае.Питоний импорт умеет выделять вещи, которые прописывать в main:: namespace. Чтобы такого добиться в сишке нужно много дефайнить, а в питоне в одну строчку. Хотя, можно извратится и написать имба-макрос, который тоже можно будет писать в одну строчку :))
> Питоний импорт умеет выделять вещи, которые прописывать в main:: namespace.Чего он умеет делать? Ничего не понял. Что значит "выделять" в данном случае? Ну короче говоря, кажется я понял -- он дёргает отдельные фукнции\классы из файла, которые в данный момент нужны. Я прав?
> Чего он умеет делать? Ничего не понял. Что значит "выделять" в данном
> случае? Ну короче говоря, кажется я понял -- он дёргает отдельные
> фукнции\классы из файла, которые в данный момент нужны. Я прав?Почти. Там ООП, поэтому смысл импорта в том, что ты можешь дергать функции или обращаться к переменным, минуя указание namespace. Например,
from sys import argv
print argv
Т.о, не указывая sys.argv. В сишке прямого аналога нет, но в плюсах подобное должно быть (сам не плюсовик). И возвращаясь к сишке, аналог должен быть такой, чтобы при include были "видны" только нужные тебе функции/переменные, а не все что указаны как extern.
> #define pow2 (pow(x, 2))
> Вызывается простым:
> int x = pow2(integer_here);Не надо так делать. Есть ключевое слово inline. Это во-первых. А во-вторых, неправильно. Надо вот так:
#define pow2(x) (pow(x, 2))>> Но если ты действительно считаешь, что Питонячий import и Cи-шный include -
>> это одно и тоже
> Ну хорошо, хорошо, я хотя бы не считаю себя ИКСПЕРДОМ во всём.
> Объясни разницу, в таком случае.Разница в том, что в плюсах этим занимается препроцессор, суть работы которого сводится к тому, чтобы сгенерировать текст, который будет скормлен компилятору. В питоне и яве это ключевое слово, часть языка, которое является интерфейсом к абстракции модуля, и обрабатывается соответственно компилятором.
Говоря проще, сишный #include осуществляет тупую подстановку текста из другого файла, а import позволяет, скажем, выдрать отдельные функции, да к тому же переименовать их.
>Разница в том, что в плюсах этим занимается препроцессор, суть работы которого сводится к тому, чтобы сгенерировать текст, который будет скормлен компилятору. В питоне и яве это ключевое слово, часть языка, которое является интерфейсом к абстракции модуля, и обрабатывается соответственно компилятором.Ну, если так рассуждать, то чем не угодил dlopen?
> Ну, если так рассуждать, то чем не угодил dlopen?Это вообще к чему?
> Не надо так делать. Есть ключевое слово inline.Я знаю, но попросили то на макросах. Вообще так никто не делает, я сразу это сказал.
> Надо вот так:
Да, действительно, потерял где-то.
> Разница в том, что в плюсах этим занимается препроцессор, суть работы которого
> сводится к тому, чтобы сгенерировать текст, который будет скормлен компилятору. В
> питоне и яве это ключевое слово, часть языка, которое является интерфейсом
> к абстракции модуля, и обрабатывается соответственно компилятором.
> Говоря проще, сишный #include осуществляет тупую подстановку текста из другого файла, а
> import позволяет, скажем, выдрать отдельные функции, да к тому же переименовать
> их.Наконец-то внятный и адекватный ответ. Спасибо за разъяснения.
>небезопастноЭто как у каскадеров. Они тоже делают небезопасНые вещи. Каскадеру скажи "прыгни в огонь", он прыгнет. А школота и прочие бабки на скамейках будут кричать "это небезопасно!" =)))
А потом такой херой как ты тоще прыгнет. И поджарит яйца :) А говорили же бабки то! :))))
> Си. Все популярные языки имеют Си-подобный синтаксис.Ну вот Питон имеет не Си-подобный, а скорее ISWIM'овский синтаксис.
>Все популярные языки имеюВсе которые не fortran, matlab или abap. Те те которые нужны когда нужен конкретный результат, а не какой-то там <<програаамный праадукт>> .
JavaScript. Приятнее по синтаксису языка я пока что не видел, хотя в прошлом - крестовик.
в прошлом - это месяца потора
В прошлом - это от десяти до семи лет назад (3 года). Потом ушел в вебдев и стартапы.
> Потом ушел в вебдев и стартапы.Деволюция? Назло Дарвину?
Эволюция.
С помощью веб-стека деньги поднимаются быстрее и проще, чем на системном программировании, плюс идея была в том, чтобы перестать кодить и уйти в менеджеры с техническим уклоном. Что я, собственно, и сделал.А на крестах проходить путь джун-миддл-сеньор-техдир - десяток лет. Задача же деньги заработать, а не кодить в свое удовольствие.
Ну с того и начни, что не программист, а манагер
> идея была в том, чтобы перестать кодить и уйти в
> менеджеры с техническим уклоном. Что я, собственно, и сделал.Смотрите, люди. Такие "менеджеры" ещё и работу "находят", и людьми "управляют".
Я не хочу больше упарываться и работать ночами, тратя свое здоровье - для этого существуют энтузиасты-пролетарии. Я ухожу домой не уставшим ровно по окончанию рабочего дня и получаю раза в два больше зарплату, чем они.
Деволюция, конечно же.А начал я это понимать, как раз, поработав 5 лет кодером (3-кресты, 2-веб), после чего начал активно действовать, чтобы прекратить этот кошмар.
Пфеу. И почему ты считаешь, что твоё мнение о языках кому-то важно? Может ещё мнение сантехника о языках нам должно быть важно?
Все просто - я руковожу кодерами, а для этого надо разбираться в предметной области.
> Все просто - я руковожу кодерами, а для этого надо разбираться в
> предметной области.Хахаххахаа.
> Все просто - я руковожу кодерами, а для этого надо разбираться в предметной области.Молодой человек, по Вашим комментариям здесь видно, что это далеко не так.
К тому же по Вашми же словам Вы -- менеджер, а не тимлид, не архитектор. Нам прекрасно известно, что менеджер занимается организацией бизнес-процессов и планированием сроков. Это сильно иные задачи.
Хотите менеджером быть - будьте. Но нефиг лезть со своим "авторитетным" мнением в область, в которой не разбираетесь. Это интернет, тут за такое могут и н###й послать. Что Вы собственно и имеете удовольствие наблюдать в комментариях.
> Все просто - я руковожу кодерамиАльфа-вэб-макак?
> Задача же деньги заработать, а не кодить в свое удовольствие.Ты изначально не ту профессию выбрал, значит. Тебе кодинг не нужен, сразу бы шёл в манагеры.
> JavaScript. Приятнее по синтаксису языка я пока что не видел, хотя в
> прошлом - крестовик.см. Ruby в части синтаксиса и реализации идеи того, что программа должна читаться как текст на естественном языке
Ушибленной этой идеей предлагаю пойти писать на COBOLе.
Ну товарищ говорит, что ему JS лучший синтаксис. Всё же JS лучше кобола
Хуже JS мало что можно себе представить.
> JavaScript. Приятнее по синтаксису языка я пока что не видел, хотя в прошлом - крестовик.Всё, что нужно знать о JS:
null == 0 // false
null > 0 // false
null >= 0 // TRUE!!!!По синтаксису-то оно, может, и приятнее... ))
Это уже достаточная причина избегать JS, а ведь еще есть variable hoisting...
Все, что нужно знать о freehck:Пишет код так, что в переменных у него будут лежать данные непредсказуемого типа, то null, то number.
А у него есть выбор?
Вы же сами так свои какашки пишете, что оно возвращает "данные непредсказуемого типа, то null, то number" ... :-\
Погоди, ты путаешь. Если конкретно у тебя там данные непредсказуемого типа, то это не значит, что у других такой же бардак. Это всего лишь значит, что конкретно ты не умеешь писать внятный код. В "стандартной библиотеке" яваскрипта свойства имеют один и тот же тип. window.scrollX -- это всегда number. Array#indexOf() -- это всегда number. А вот у тебя представляю, какой ужас.
учите матчасть, эксперт.i) null нестрого равен только самому себе и undefined-у.
ii) при относительных сравнениях оба операнда приводятся к числу; null приводится к нулю, в итоге получаем вполне логичные 0 > 0 === false и 0 >= 0 === true.
iii) в реальном коде таких ситуаций практически не возникает, а проблема не вылазит за пределы диванных теоретизирований о том, как абстрактный сферический кодер гипотетически смог бы абстрактно выстрелить себе в не менее сферическую ногу гипотетической пулей абстрактной формы. Вот, допустим, сишные переполнение буфера и разыменование нулевого указателя -- вполне себе реальные проблемы, возникающие отнюдь не из-за си.
iiii) трудно представить себе переменную, где помимо числа мог бы еще храниться null. Ненайденный индекс? Для этого есть -1. А даже если такая ситуация и найдена, разраб просто обязан учитывать все возможные значения переменной. Или в _этом_ случае вы бы их сравнивали, беря на веру, что там обязательно будут числа? Что ж, тогда счастливой отладки.
> учите матчасть, эксперт.Ммм, молодые яваскриптеры не знают шуток старых яваскриптеров? :)
Ну, ловите тогда ещё:
['10','10','10','10'].map(parseInt) // даёт [10, NaN, 2, 3]
> Ну, ловите тогда ещё:А теперь переходишь в доки и с удивлением узнаешь о том, что parseInt внезапно принимает в себя второй аргумент -- основание, а ты туда предумышленно передаешь индекс элемента. Так что матчасть все же местным экспертам подучить не мешает.
> parseInt(string, radix);
> radix -- An integer between 2 and 36 that represents the radix (the base in mathematical numeral systems) of the above mentioned string.
Ну вот и выросло новое поколение JS-ников. Ладно, объясню на пальцах, что ли. Мне-то всё равно, но Вам полезно. :)Так вот, все эти примеры были в начале нулевых тем, что сильно удивляло программистов, переходящих в веб с других языков. Именно перешедшие в JS из других областей больше всего с него и плевались по простой причине: методологии и именования, принятые в других языках, в JS сделаны шиворот-навыворот. И посему ещё в начале нулевых эти люди (теперь уже либо большие профессионалы в этой области), обильно шутили о новом "популярном языке".
Но вот взять parseInt: почему он принимает ещё и базу? В других языках функция с аналогичным названием парсит десятеричные числа, а для других баз существуют отдельные функции.
Взять map: почему по доке он должен принимать функцию от трёх аргументов, когда во всех языках принимает унарную?
Или почему не делается разницы для map и mapi, где вторая функция как раз и добавляет возможность передать индекс текущего элемента, как это сделано в других языках?
Или почему во время вызова функции, переданной в map, не проверяется её арность? В доке же написано, что функция должна быть тренарная, почему же map принимает функцию одного-двух аргументов и даже выполняется как-то вместо того, чтобы бросать исключение, или возращать какой-нибудь маркер ошибки, или просто завершать работу интерпретатора?Отдельная песня -- это гремучая сместь нестрогой типизации с неявным приведением типов. Очень легко представить себе функцию, которая выдирает число из какого-нибудь элемента DOM, а возвращаемое значение null использует в качестве маркера, чтобы обозначить, что элемент DOM не найден. В этом случае неявное приведение типа сыграет очень злую шутку. А ведь такое запросто случится: заложится как-то один программист, что этот элемент всегда присутствует, опустит проверку на null. Через год он будет модифицировать другой участок кода и элемент пропадёт. И начнутся удивительные по своей природе баги. И такое происходит сплошь и рядом. Не надо думать, что вы-то особенные, что вы-то все-все-все проверки напишете. Наступит час, когда вы будете уставшими, или (что гораздо чаще) дедлайн на носу будет. И вы ошибётесь. А дебаг этой проблемы превратится в сущий ад.
Вот такие вопросы и возникают, когда программисты со стороны смотрят на JS. То, что всё это прописано в документации, это конечно замечательно... Вот только нельзя же по каждому чиху в документацию смотреть. Нельзя же помнить все её талмуды наизусть. Из-за этого хорошие программисты с широким кругозором и опытом в других языках не идут в JS. Из-за этого большинство JS-ников являются молодыми программистами, которые в продакшене ничего, кроме JS не видели толком.
Вы -- новое поколение JS-ников. Вам кажется, что всё вышеописанное -- нормально. Но для программистов из других областей всё это выглядит как шутка юмора такая.
Вы -- новое поколение JS-ников. Вам стоит посмотреть вокруг, и понять, что чуток самокритики вам не повредит. Вот Vkni ниже совершенно верно замечает в #115: "кругозор от Эдиты Пьехи до ..."
> взять parseInt: почему он принимает ещё и базу?А нужно было плодить отдельные методы parseInt10(), parseInt16() и т. д.?
> а для других баз существуют отдельные функции.
Ах вон как. А как там называется функция, которая переводит из 15-ричного строкового представления (не опечатка: именно 15-ричного) в число? А 17-ричного? А 30-ричного?
> почему же map принимает функцию одного-двух аргументов и даже выполняется как-то вместо того, чтобы бросать исключение
Потому что проверка аргументов не лежит в ответственности map. Функция может принимать аргументы и из arguments[0], arguments[1] и т. д. Так что map, даже если бы он с чего-то вдруг начал проверять кол-ва аргументов через fn.length, не получил бы достоверные сведения о фактическом использовании параметров.
> гремучая сместь нестрогой типизации с неявным приведением типов
Потому-то и рекомендуется всячески избегать нестрогих сравнений. Использовать принципиально ===.
> легко представить себе функцию, которая выдирает число из какого-нибудь элемента DOM, а возвращаемое значение null использует в качестве маркера, чтобы обозначить, что элемент DOM не найден
Плохая практика. Если DOM-элемента нет, эта функция попросту не должна вызываться. Проверка на существование -- это еще одна ответственность, которую ты хочешь запихнуть в одну и ту же функцию.
> И такое происходит сплошь и рядом.
Ссылочку на какой-нибудь коммит в опенсорсном js-проекте попрошу я тебя. На моей практике такого не происходило никогда.
> Нельзя же помнить все её талмуды наизусть.
Какие талмуды? По сравнению с какой-нибудь Java с тамошними Spring/EE/JBoss/etc., JS -- это язык, в котором помнить приходится о на редкость малом.
Контекстно-клиповое мышление, или что это такое? На вырванные из контекста фразы ответили, а общую мысль проглядели? Новое поколение JS-ников...
Общей мысли тут никакой нет, есть лишь общая твоя проблема -- упорное нежелание читать документацию. На мои вопросы ты, кстати, не ответил. Что это, новое поколение фанатиков определенного языка? Надеюсь, не си? Страшно подумать, что будет, если фанатик, игнорирующий документацию, станет писать драйвера. "Ой, а у вас тут оборудование ведет себя не так, как я привык с оборудованием A и оборудованием B".
> Общей мысли тут никакой нетХей-хо. Народ, поглядите! Новое поколение JS-ников имеет настолько поломанное восприятие реальности, что даже не может прочитать и понять простой и максимально разжёванный ответ.
Уже всё было. И апелляция к мифическому "народу", и к какому-то "пасмари там внизу чо пишут". А вот ткнули тебя мордой в документацию -- до сих пор отплеваться не можешь. Как там, в "другом", "нормальном", "обычном" языке называется функция, перегоняющая из 30-ричной строки в число? parseInt30?
Эм... Так о том речь, что отплеваться сложно. От этого самого. Закреплённого в документации >:-)
> Эм... Так о том речь, что отплеваться сложно. От этого самого. Закреплённого в документации >:-)Спасибо, камень с сердца. Я уже думал, что никто не поймёт, о чём я. :)
Со своим виртуалом беседу ведешь от нехватки аргументов, а, parseInt30? :)
> а, parseInt30? :)Жабаскиптозы, как они есть:
http://en.cppreference.com/w/cpp/string/basic_string/stol
https://docs.python.org/2/library/functions.html#int
https://docs.oracle.com/javase/7/docs/api/java/lang/Integer....)
https://www.freepascal.org/docs-html/rtl/sysutils/strtoint.html
https://ruby-doc.org/core-2.4.0/String.html#method-i-to_i
Ой, вы тут друг дружку не покусайте:freehck> Но вот взять parseInt: почему он принимает ещё и базу?
> Но вот взять parseInt: почему он принимает ещё и базу?
> почему он принимает ещё и базу?stoi( const std::string& str, std::size_t* pos = 0, int base = 10 );
class int(x, base=10)
parseInt(String s, int radix)
to_i(base=10) → integerfreehck> В других языках функция с аналогичным названием парсит десятеричные числа, а для других баз существуют отдельные функции.
Выходит, что если в JS parseInt принимает базу -- это плёхо. Если то же самое в других языках -- это благодать.
> Ой, вы тут друг дружку не покусайте:
> freehck> Но вот взять parseInt: почему он принимает ещё и базу?
>> Но вот взять parseInt: почему он принимает ещё и базу?
>> почему он принимает ещё и базу?Хорош юлить. Изначально речь шла о черезжопности всей связки
> ['10','10','10','10'].map(parseInt) // даёт [10, NaN, 2, 3]'
> stoi( const std::string& str, std::size_t* pos = 0, int base = 10
> );
> class int(x, base=10)
> parseInt(String s, int radix)
> to_i(base=10) → integerint myint1 = std::stoi("42");
int foo = Integer.parseInt("1234");
x = int("123")В плюсах или той же жабе это и есть отдельные функции. В питоне и руби чисто семантически тоже.
> Выходит, что если в JS parseInt принимает базу -- это плёхо. Если
> то же самое в других языках -- это благодать.Нет, в Жопоскрипте это привычно через одно место, но ЖСники считают, что это норма:
>>> map(int,['10','11','12','13'])[10, 11, 12, 13]
>>> map(int,['10','11','12','13'], [2,10,16,32])[2, 11, 18, 35]
% cat даже_маргинальныйЯП.nim
import strutils
import sequtilsecho repr(["10","10","10"].map(parseInt))
% nim c -r даже_маргинальныйЯП.nim
0x800681048[10, 10, 10]
['10', '10', '10', '10'].map(t => parseInt(t))</thread>
Еще более короткий способ для тех, кто экономит пространство на жестком диске, которое тратится на объявление функции-обертки над parseInt:['10', '10', '10', '10'].map(Number)
> для тех, кто экономит пространство на жестком диске,
> которое тратится на объявление функции-оберткиОтличное понимание принципов работы железа и софта на низком уровне. Хотя чего можно ожидать от JSников?
> ['10', '10', '10', '10'].map(Number)
На дeбилоидность JS-ного map это как-то влияет?
Кстати, сравнивать в этом смысле JS с ЯПами со статистической, строгой типизацией "смотрите, им можно а нам низзя?!" как минимум, глупо.Там выше привели пример, как оно по нормальному делается для динамической типизации.
>>> map(int,['10','11','12','13'])[10, 11, 12, 13]
>>> map(int,['10','11','12','13'], [2,10,16,32])[2, 11, 18, 35]
Дал базы отдельно - работает. Не дал - работает с базой по умолчанию.
А вот чем нужно мыслить, чтобы додуматься передавать в мапе еще и по умолчанию индекс и сам массив в вызываемую функцию, да еще и воспринимать это как эталон ...
> На дeбилоидность JS-ного map это как-то влияет?
> как минимум, глупоПрекрати, о человек-аргументация.
> Дал базы отдельно - работает. Не дал - работает с базой по умолчанию.
Отлично. То есть получается этот твой мап принимает третьим аргументом доп. аргументы для приведения в число. Логично, че. К черту единую ответственность, давайте внедрим в map еще и функционал по байндингу аргументов и по тому, как и в каком порядке их применять. Как это убого и узкоспецифично...
Напиши мне при помощи своего супирмощного map следующие конструкции:
1) Применить основы в обратном порядке. Не порождая новый отреверсенный список, потому как а вдруг их мульён? И не мутируя оригинальный.
2) Применять ко всем строкам основу = 16. Не пользоваться лямбдами, потому что твой мап же супирмощный? Он же позволяет супирмощно внедрять аргументы?
3) Основ пусть будет всего два: 16 и 32, но чтобы по окончанию списка основ он начинал сначала (а не совал None) -- '10' как 16, '11' как 32, '12' как 16, '13' как 32. Не порождая новый список основ, потому как а вдруг чисел будет мульён?
4) Применить ко всем строкам основу = 16, потом к каждому числу прибавить его индекс: ['10','11','12','13'].map((s, i) => parseInt(s, 16) + i). Это пример на JS-ном мапе. А ты напиши на супирмощном питоновском.
>> Дал базы отдельно - работает. Не дал - работает с базой по умолчанию.
> Отлично. То есть получается этот твой мап принимает третьим аргументом доп. аргументы
> для приведения в число. Логично, че.Третьим? Там их можно передавать столько, сколько влезет. Прикольно, да?
map(...)
map(function, sequence[, sequence, ...]) -> list> К черту единую ответственность, давайте
> внедрим в map еще и функционал по байндингу аргументов и по
> тому, как и в каком порядке их применять. Как это убого
> и узкоспецифично...Рукалицо.жпг
Как все запущено.
Убого, это не знать ничего кроме ЖопоСкрипта, но мнение иметь. Ценное.
Оттуда и какие-то странные фантазии насчет мапа.
>>> def mymap(f, *args):... return [f(*myargs) for myargs in zip(*args)]
...
>>> mymap(int, ['10','12','1338'])[10, 12, 1338]
>>> mymap(int, ['10','12','1338'],[2,3,16])[2, 5, 4920]
Вот и вся магия. Наивный зип пишется тоже в десяток строк, если что.
Это при том, что к питону я уже лет шесть не притрагивался.> Напиши мне при помощи своего супирмощного map следующие конструкции:
Долго думали, конструируя cферического коня и подбирая примеры cпециально под ЖС?
Кстати, неплохо было бы вначале самому предъявить код, прежде чем кидать предъявы. Это так, на будущее. Да и на супермощность мапа никто не претендовал, это вы с какого-то перепугу придумали. Логичность, универсальность, простота - вот основные кирпичики.А теперь замените любимое кресло на то, которое не жалко, присядте, пристегнитесь или прибейте к потолку подушку, дышите глубоко:
> 1) Применить основы в обратном порядке. Не порождая новый отреверсенный список, потому
> как а вдруг их мульён? И не мутируя оригинальный.
>>> map(int,['10','11','12','10'], reversed([2,10,16,32]))
[32, 17, 12, 2]
Круто, правда?
> 2) Применять ко всем строкам основу = 16. Не пользоваться лямбдами, потому
> что твой мап же супирмощный? Он же позволяет супирмощно внедрять аргументы?А в ластах по фонарному столбу мне при этом не надо карабкаться? Нет? Ой спасибочки!
Тогда выбирайте, на вкус и цвет, без лямбд.
>>> map(partial(int,base=16),['10','11','12','10'])[16, 17, 18, 16]
>>> imap(int,['10','11','12','13'], repeat(16))'<itertools.imap object at 0x1338a0337>'
# а это вообще итератор, который позволяет обрабатывать последовательно нужные элементы,
# вместо героического втискивания нашего гипотетического мильенного списка в память
>>> list(imap(int,['10','11','12','13'], repeat(16)))[16, 17, 18, 19]
>>> list(imap(int,['10','11','12','13'], cycle((16,))))[16, 17, 18, 19]
> 3) Основ пусть будет всего два: 16 и 32, но чтобы по
> окончанию списка основ он начинал сначала (а не совал None) --
> '10' как 16, '11' как 32, '12' как 16, '13' как
> 32. Не порождая новый список основ, потому как а вдруг чисел
> будет мульён?
> '10' как 16, '11' как 32, '12' как 16, '13' как 32'11' как 32 и '13' как 32? Уличная магия? Именно так увы, нельзя :(
>>> imap(int,['10','11','12','13'], cycle((16,32)))
>>> list(imap(int,['10','11','12','13'], cycle((16,32))))[16, 33, 18, 35]
> 4) Применить ко всем строкам основу = 16, потом к каждому числу
> прибавить его индекс: ['10','11','12','13'].map((s, i) => parseInt(s, 16) + i). Это
> пример на JS-ном мапе.Долго думали над сферическим примером, подходящим именно под черезжо^W жс-но альтернативный parseInt? А зря.
>>> map(lambda (i,x): int(x, base=16) + i, enumerate(['10','11','12','13']))[16, 18, 20, 22]
Все? Кстати, как оно там, в луже?
> А ты напиши на супирмощном питоновском.
> супирмощном питоновском.
> что твой мап же супирмощный?
> супирмощномВ этом вся суть ЖСников, VBшников и прочих умников. Вместо конструирования из простых, понятных и универсальных кирпичиков любят всякие разные "сделай_все_за*бись_cуперпупирsubfunproc".
> JavaScript. Приятнее по синтаксису языка я пока что не видел, хотя в
> прошлом - крестовик.Т.е. "кругозор от Эдиты Пьехи до ...".
>> Уродливый синтаксис располагает к сектантству: см. лисп и другие. Разного пошиба шизофреники
>> на такое моментально липнут.
> Ваш вброс настолько прекрасен, что прямо неймётся спросить, каков же Он, прекрасный
> синтаксис, на который льнут строевым гранёным выверенным шагом солдафоны, стриженные
> под одну гребёнку?.... Сорвите же покровы, маэстро.Пусть меня проклянут всё true-пацаны но синтаксис Си не так уж и прекрасен, да он годен, но не прекрасен. Прекрасны C#, Java и т.д. Это тоже спорный вопрос конечно, но по крайней мере runtime языки консистентны, но ввиду того что на низком уровне такого соотношения удобства и функциональности добиться не особо возможно - возникают определенные парадигмы программирования, в рамках которых синтаксис и формируется. И этот синтаксис не так уж и уродлив если понимать саму парадигму, а не пытаться имея в голове старые конструкции (а может быть просто не понимая новые), использовать новый инструментарий.
>> Уродливый синтаксис располагаетпитон же взлетел. Раст по синтаксису по сравнению с питоном просто красавица
Python красив настолько что будучи похожим на псевдокод применяемый в книгах по информатике - заменил разнообразный этот псевдокод собойЛаконичность
Выразительность
Нет ничего столь же лаконичного но одновременно супер-читаемого. Даже nim многословнее
сраный гвидобейсик для ньюфагов
Вы просто бейсика не видели. Я вам даже завидую
> сраный гвидобейсик для ньюфаговЖелаю тебе,шоб тебе 10 номеров на вставку не хватило и шоб у тебя весь код был на
goto <line number>,шоб болело у тебя от бейсика и счастливой отладки тебе,поцанчик.П.С ну и шоб ты все время писал POKE && PUKE
Та я вас умоляю!
Вокруг таки 2017 год и даже BASIC ныне это вотЪ: https://www.freebasic.net/Но ты по ссылке не ходи - будет баттхерт. :)
А вообще нынешние проггеры - слабаки! :-\
Живут в роскоши и только и могут что _____НЫТЬ_____ мол язык виноват, задрали до коликов уже.
> Лаконичность
> Выразительность
> Нет ничего столь же лаконичного но одновременно супер-читаемого. Даже nim многословнееНу хоть полистайте функциональные языки для приличия что ли... Ну или ближайшего конкурента - Ruby, чтобы уж совсем глупости не писать
> Ну хоть полистайте функциональные языки для приличия что ли...У меня сложилось ощущение, что автор Питона таки читал статью Ландина про 700 новых ЯП и ISWIM. Питон очень похож на смесь Ocaml'a и Haskell'а, из которых удалили вывод типов.
Функциональные языки - это вообще образцовое "как не надо". Потому что заставляют думать о чём угодно, но только не о том, что делается (предметная область) и как делается (как код будет исполняться машиной).
Нормальные языки, просто требуют несколько выученных навыков. Ровно также, как ООП требует умения разделять предметную область на объекты + делать их иерархию. Ясен пень, если у тебя эти навыки не поставлены, писать будет сложно. Но то же самое, в общем, с ООП и структурным программированием.
Изучить навыки можно любые. Тем не менее, в контексте питона, его синтаксис ужасен. По моему опыту люди, которым нравится питон, реально не знают ни одного языка того же уровня. Прежде всего Ruby, Perl. Соответственно сравнивать не с чем.
> Изучить навыки можно любые. Тем не менее, в контексте питона, его синтаксис
> ужасен. По моему опыту люди, которым нравится питон, реально не знают
> ни одного языка того же уровня. Прежде всего Ruby, Perl. Соответственно
> сравнивать не с чем.Знаю PHP, Perl, JS, Go, Ruby и Python. Python прекрасен, Go прекрасен, Ruby сойдёт, на остальном даже за деньги писать не хочется. К счастью, боженька миловал и я не программист, а потому код пишу, чтобы он задачу выполнял в соответствияя с требованиями, а не чтобы всё было правильно напрогано.
> По моему опыту люди, которым нравится питон, реально не знают ни одного языка того же уровня.Аргументации на уровне одна бабка-сенмешница рассказала. Со стороны, по крайней мере.
Вместе с Е зацепилась Н, семешница конечно же ) Извините.
Увлечение ООП тоже доводит до забавных ситуаций когда адепты без конца пытаются придумать идеальную иерархию классов, а дело стоит.
> Увлечение ООП тоже доводит до забавных ситуаций когда адепты без конца пытаются
> придумать идеальную иерархию классов, а дело стоит.Есть такой оборот "черезмерное увлечение". Именно поэтому желательно иметь определённый кругозор и большой набор программистских навыков - структурного, функционального, ООП и т.д.
Это позволяет выбрать оптимальное архитектурное решение для задачи. Хотя, конечно, оптимальный выбор и не гарантирован. Но человек, знающий только как использовать молоток, будет видеть молоток во всём.
... будет видеть везде незабитые гвозди! (С)
Не перевирай классику :)
> Увлечение ООП тоже доводит до забавных ситуаций когда адепты без конца пытаются
> придумать идеальную иерархию классов, а дело стоит.Это перфекционизм - другая крайность и другое извращение.
> Функциональные языки - это вообще образцовое "как не надо". Потому что заставляют
> думать о чём угодно, но только не о том, что делается
> (предметная область) и как делается (как код будет исполняться машиной).Шёл бы ты гoвнoкoд лопатой кидать...
ну то есть все вот эти половые извращения вокруг ввода/вывода это нормально ?
> ну то есть все вот эти половые извращения вокруг ввода/вывода это нормально
> ?Нет, это не нормально. Но есть линейные типы (Clean), есть смешанные императивно-функциональные подходы (ML). И там, и сям есть свои недостатки, но есть и достоинства.
С другой стороны, и в монадах нет ничего страшного, просто требуется наработка определённых навыков для этого. Т.е. примеры, примеры, примеры.
Просто товарищи Хаскеллисты не очень трудятся объяснять, что к чему. Например, мало где говорится, что у них вся программа делается в Continuation-Passing-Style. Или что тип "IO ()" - это, на самом деле, функция с типом "() -> RealWorldChange ()".
> Просто товарищи Хаскеллисты не очень трудятся объяснять, что к чему.Почему же, они искренне пытаются пролить свет на ситуацию с IO, поясняя, что "монада это просто моноид в моноидальной категории эндофункторов". ;)
> ну то есть все вот эти половые извращения вокруг ввода/вывода это нормальноНе, извращение вокруг IO - это особенность языка Haskell, которую он обрёл в силу своей умолчательной ленивости. В других функциональных языках этого нет и в помине. )
> Не, извращение вокруг IO - это особенность языка Haskell, которую он обрёл
> в силу своей умолчательной ленивости. В других функциональных языках этого нет
> и в помине. )Есть решение той же проблемы на линейных типах - язык Clean (в их терминологии Uniqueness Typing). Это такой практически Хаскель, но без монад.
Грубо говоря, вводятся значения, которые могут быть в программе только в одном месте:
WriteABC:: *File -> *File
WriteABC file = fwritec 'c' (fwritec 'b' (fwritec 'a' file))Ну, собственно, компилятор смотрит, чтобы не было двух одновременно вызываемых процедур, в которые передаётся этот file.
> Функциональные языки - это вообще образцовое "как не надо". Потому что заставляют
> думать о чём угодно, но только не о том, что делается
> (предметная область) и как делается (как код будет исполняться машиной).Лисп прекрасен...
> Python красив настолько что будучи похожим на псевдокод применяемый в книгах по
> информатике - заменил разнообразный этот псевдокод собойУгу. Ни на что большее толком не годится, но раз вошёл в учебники — все теперь кодят только на нём. Это как когда-то было с васиком и с паскалем/дельфями.
Вот кстати да. Все фанаты Раста которых я встречал ИРЛ были весьма специфическими юными месье с неудержимой любовью реализовывать простые вещи самым диким и переусложнённым способом, причём даже повсеместно принятые Java/C#/Python (которые они люто ненавидят) не спасал бизнес от их изобретательств. Главное, не я один это заметил - многих тимлиды мне говорили, что для джуниоров Раст в резюме, как приговор - их позовут на собеседование в последнюю очередь. Лисп ещё не так страшно - его изучают в университетах и бывшие студенты часто добивают им резюме.
> см. лисп и другие. Разного пошиба шизофреникиИнтересно, сколько этому бывшему школьнику стабильно лепили по математике, чтоб наработать такую травму...
А ведь верно! :)
Похожи на местных комментаторов.
Давно пора.
>что позволило бы решить многие проблемы с безопасностью.
>с ассемблерными вставками, оформленными в виде unsafe-блоковЭто разве не взаимоисключающие параметры?
Rust'аманов это не остановит!
Dominus Carnufex доказал, что на чистом Rust'е функции ядра реализовать невозможно.
Линус доказал, что на чистом С функции ядра реализовать невозможно
Как Линус сказал: masturbating monkeys... :)
> Как Линус сказал: masturbating monkeys... :)Я до сих пор не могу простить астронавту, что он не назвал так выпуск Убунты на то время.
>>что позволило бы решить многие проблемы с безопасностью.
>>с ассемблерными вставками, оформленными в виде unsafe-блоков
> Это разве не взаимоисключающие параметры?Нет. Читай внимательнее и думай _головой_.
Ну и псевдоним, блин... "Dominus Carnufex" значит "Господь-истязатель" (хотя я не эксперт в латыни).
Ох уж эти растаманы. Еще и притворяются будто всё это они придумали, а линейных типов до этого не было.
Все красоту и мощь Rust не осиливают полные отморозки, и вот такие идиоты чтобы как-то самоутвердиться начинают рассказывать какой Rust плохой.
Я как потрерявшийся, не особо понимаю, что лучше си или rust, читал что rust в 2 раза медленнее чем си. Но раст типа безопасенее.К чему я веду.. Всегда будут те кто упарываются в производительность (Kalibi OS на ассемблере) и те кто упарываются в безопасность (Kaspersky OS)
Я больше склоняюсь к производительности.. Главное чтоб руки были ровные. А безопасность вроде и так ничего. Либо Линь не так много желающих ломать
> Я как потрерявшийся, не особо понимаю, что лучше си или rust, читал
> что rust в 2 раза медленнее чем си. Но раст типа
> безопасенее.Ровно в 2 раза? Независимо от задачи? Компилятора? Железа?
Не читайте больше такого :-)
http://benchmarksgame.alioth.debian.org/u64q/rust.html> Либо Линь не так много желающих ломать
OMG!!! Не могу поверить, что я вижу это на Опеннете.
Благодарю за критику, буду читать внимательней))
Ну, и победа конечно. На несколько миллисекунд ценой целых килобайт памяти.
Почему бы не конкатенативные языки программирования? Да еще и отказаться от монолитного ядра, сделать экзоядро формально верифицированное, засунуть это всё в кэш процессора с помощью шитого кода и запускать хоть на нанороботах, хоть на кластерах работающих от сферы Дайсона. Небывалые возможности по композиции функции (даже более того, конкатенативное программирование даже более функциональное в некотором смысле), всё есть выражение; возможность легко балансировать между совсем низким уровнем (манипуляцией со стеком и ассемблерными вставками) до комбинаторов и высоких уровней абстракции; возможность балансировки между функциональным и императивным программированием, возможность амбивалентного рассмотрения одного и того же кода, золотая средина; простота, гибкость и скорость компилятора/транслятора/интерпретатора и многое другое.К тому же, есть еще различные интересные штуки типа создание программы с помощью градиентного спуска на FORTH-подобном (ну, он чисто стековый правда, вроде как-бы) языке и прочие различные интересные исследования, которые из-за гибкости языков можно не так уж дабы совсем и сложно применить.
Красота и радость моих фантазий.
Есть люди с влажными мечтами, считающие, что их мечты должен исполнять кто-то другой
Потому что нужен результат, а не краса фантазий. Впрочем, до расто-фанатиков это тоже не доходит, кажется.
Лучше бы на D пробовали писать модули ядра. Хотя бы потому, что фронтенд D есть в GCC.
Дык займись, кто тебе мешает
А реально? Я не уверен, в каком там состоянии gc-less вариант. Им занимались, конечно, но до ума довели?
На фортране.
Ну и господь с ним, не буйнопомешанный, людям не мешает, пусть ковыряется себе
Язык - инструмент. Пока софт выполняет свои функции и не жрет в три горла - может быть хоть на пхп написан.
А сабжевые сектанты похуже хипсторов с хасвелем будут. Кто нибудь - доставьте копипасту про вована, будет очень в тему
а как же память стоит копейки?
> Пока софт выполняет свои функции и не жрет в три горла - может быть хоть на пхп написан.Нет уж, спасибо. Знаю проект веб приложения, который запускается в докере только под макосью, потому что стартовые скрипты написаны на пхп. Зато выполняет свои функции и не жрёт в три горла, чо.
В Rust'е даже нет зависимых типов, чего там уже говорить о различных штуках типа CoC. Как они формальную верификацию сделают нормально тогда? А без формальной верификации и безопасность будет не ахти. В общем, растаманы-с.
> В Rust'е даже нет зависимых типов, чего там уже говорить о различных штуках типа CoC. Как они формальную верификацию сделают нормально тогда? А без формальной верификации и безопасность будет не ахти. В общем, растаманы-с.Что в переводе значит: «не жили хорошо — нечего и начинать»
>> В Rust'е даже нет зависимых типов, чего там уже говорить о различных штуках типа CoC. Как они формальную верификацию сделают нормально тогда? А без формальной верификации и безопасность будет не ахти. В общем, растаманы-с.
> Что в переводе значит: «не жили хорошо — нечего и начинать»Лучше бы тоже объяснили зачем они вам, чем заниматься переводами бредовых замечаний.
>>> В Rust'е даже нет зависимых типов, чего там уже говорить о различных штуках типа CoC. Как они формальную верификацию сделают нормально тогда? А без формальной верификации и безопасность будет не ахти. В общем, растаманы-с.
>> Что в переводе значит: «не жили хорошо — нечего и начинать»
> Лучше бы тоже объяснили зачем они вам, чем заниматься переводами бредовых замечаний.Отвечает Edward Brady (с байками, картинками и увлекательными примерами; но без клоунов и пони, увы): https://manning-content.s3.amazonaws.com/download/a/580d6ba-...
Товарищ, каким образом в ЯП со статической типизацией и нацеленностью на zero-cost abstractions можно ввести dependent types, да так чтобы этот ЯП еще и оставался системным? Растолкуйте пожалуйста Вашу позицию, мне очень интересно.
Давайте уже на Java
На javascrit'e же. Модно, стильно, молодежно.
Позволит привлечь к разработке широкие массы вебмакак.
Сколько ненависти. Вам что реально не хочется чтобы исчезли проблемы, упомянутые в последнем абзаце?
>Сколько ненавистиПодленькая накрутка лайков у этой новости уж слишком явная, не верю что тут столько сторонников Rust, тем более учитывая уничижительный тон новости по отношению к C. Даже в новости про реактос накрутка лайков была не такая явная как здесь, противно всё это.
>>Сколько ненависти
> Подленькая накрутка лайков у этой новости уж слишком явная, не верю что
> тут столько сторонников Rust, тем более учитывая уничижительный тон новости по
> отношению к C. Даже в новости про реактос накрутка лайков была
> не такая явная как здесь, противно всё это.тут не любители раста, а нелюбители Сей (главной диверсии против человечества после "демократии" (в виде современного термина))
Хочется. Но не ценой роста потребления памяти втрое, падения производительности вдвое и адовым усложнением языка. Нет спасибо.
Это вы с прямым углом перепутали, тьфу, то есть с garbage collected языками в части памяти, с питоном в части производительности, и с С++ в части адового усложнения языка.
Все споры за "Си", это яркий пример того, когда люди привыкли "как все", но не понимают очевидного.
Язык "Си", на момент его разработки, был просто идеален. Потому что он разрабатывался для частного решения: заменить ассемблер на PDP-11. Его синтаксис полностью соответствует системе команд PDP-11. Его преимущество в том, что он позволил писать высокоэффективный код для PDP-11 на структурированном языке. Его главный недостаток в том, что он МАШИННО ЗАВИСИМЫЙ. Все недостатки безопасности связаны с тем что это язык НИЗКОУРОВНЕВЫЙ, т.е. он подразумевал минимальное вмешательство компилятора.
Такие попытки, как Rust, поэтому, весьма логичны. Я очень надеюсь, что язык "Си" всё-таки когда-нибудь останется в прошлом. PDP-11 всё-таки давно уже нет, а на его ассемблере продолжают писать миллионы.
Это все круто, но наличие unsafe блоков говорит о том что Rust ничего не решает.
>> но наличие unsafe блоков говорит о том что Rust решает, но не всепоправил
Ну и глупо поправил.
Если в заборе есть воот-такенная дыра, то ничего кроме задачи как бы создать тень на участке он не решает. :)
> Ну и глупо поправил.
> Если в заборе есть воот-такенная дыра, то ничего кроме задачи как бы
> создать тень на участке он не решает. :)Угу. По вашей же логике -- подушки вместе с ремнями безопасности не нужны, потому что помогают не всегда.
Не только подушки, а и парашут(ы) в самлётах - каждому пассажиру самолёта и даже пилотам.Отжеляю котлеты от мух:
Rust именно из-за "подушек безопасности" - тормоз, т.е.в ч.н.этим не лучше Java и C#,
так причём тут сравнение и притензии на замену Си?... кернел ОС переписывают? Так ОС и на Java сделать не проблема, только будет тот же тормоз.
А, Java то куда популярней.. и просто больше лобирования и документации, ну да: синтаксис - У.Г., но и в Rust тоже... Но, Java например есть везде - а, Rust...P.S.
Как по мне: что то что У.Г., даже не только из-за тормозов, а именно из-за охаянного выше у Си синтаксиса, у этих же обоих - вообще отвратного, у каждого по своемому.
> Отжеляю котлеты от мух:
> Rust именно из-за "подушек безопасности" - тормоз,Очередной иметель ценнейшего мнения? Еще расскажите нам, что отсутствие алиасов на указатели фатально для оптимизатора.
> т.е.в ч.н.этим не лучше Java и C#,
Мечты жабистов и шарперов такие мечты:
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
> так причём тут сравнение и притензии на замену Си?... кернел ОС переписывают?
> Так ОС и на Java сделать не проблема, только будет тот же тормоз.
> А, Java то куда популярней.. и просто больше лобирования и документации, ну
> да: синтаксис - У.Г., но и в Rust тоже... Но, Java например есть везде - а, Rust...А еще в жабке есть сборщик мусора и без него почти никак.
Здравствуйте, все те, кто использует линукс -Я переделываю операционную систему Linux на Rust. Я бы хотел получить отзывы о том, что людям нравится/не нравится в линуксе. Я уже подготовил рабочий прототип реализации интегрируемого в ядро системного вызова, код которого написан на языке Rust с ассемблерными вставками, оформленными в виде unsafe-блоков. Пример протестирован на ядре Linux 4.8.17 и всё, кажется, работает. Любые предложения принимаются, но я не обещаю, что реализую их :-)
Dominus Carnufex
> Я переделываю операционную систему Linux на Rust. Я бы хотел получить отзывы
> о том, что людям нравится/не нравится в линуксе. ...
> Dominus Carnufex...%тонна skipped для лаконичности%
n) Никому не нужен Linux на ...Rust, даже - просто пользователям... (у которых всё ПО на Си и оно должно безпроблемно не только запускаться, но и линковаться к API и ядру ОС, которое на Си...)
m) И да, Linux это не ОС... (если даже это вашей команде не известно - можно представить что у вас "вышло"...)
> ... переработка ядра Linux на Rust, что позволило бы решить многие проблемы с безопасностью.
> ... код которого написан на языке Rust с ассемблерными вставками, оформленными в виде unsafe-блоков./0
Муха-ха-шечки!(С)
И вот так вот со ржавыми во всём.
>> ... код которого написан на языке Rust с ассемблерными вставками, оформленными в виде unsafe-блоков.Чего вы все к этим ассемблерным вставкам пристали? В оригинальном ядре на Си их тоже есть. Делов-то.
>В оригинальном ядре на Си их тоже есть. Делов-то.___ Да но насильники никого за безопасный сЭкис и не парят! ___
В отличие от ! :) А у самих резики порваныее а под ними слой ржавчины :-)))))
на эту тему на лоре GoodRiddance как-то очень метко выразился:----
Разговор перешёл к священным коровам, опять. Всё ясно. Меня устроит, если в следующем раст-треде, куда меня кастанёт по совершенно другому тегу, фанбои будут писать свои обычные лозунги так «без сигфолтов и безопасно*!!!!** Быстрее устаревшей сишки!!!***»
* Не в 100% случаев***,
** Имеются противопоказания
*** В режиме unsafe
**** Точный процент мы не знаем, но он больше нуля!
"Быстрее устаревшей сишки!!!***»" - это только по их тестам...
джабаисты тоже самое сколько себя помню утверждали о своём божке
(правда скромней: что такая же скорость как на Си),
а сколько не смотрел исходных код их бенчмарков - сплошная дуриловка:
* либо Си код заведомо деоптимизирован(включая исп-ние С++ библиотек тормозов),
* либо Java код написан уже после написания на Си, с применением там оптимизаций - что соооовсем не натуральное написание...
И главное сам тест всегда - синтетика полнейшая! И уж точно никогда не realtime.
> "Быстрее устаревшей сишки!!!***»" - это только по их тестам...
> джабаисты тоже самое сколько себя помню утверждали о своём божке
> (правда скромней: что такая же скорость как на Си),
> а сколько не смотрел исходных код их бенчмарков - сплошная дуриловка:
> * либо Си код заведомо деоптимизирован(включая исп-ние С++ библиотек тормозов),
> * либо Java код написан уже после написания на Си, с применением
> там оптимизаций - что соооовсем не натуральное написание...
> И главное сам тест всегда - синтетика полнейшая! И уж точно никогда
> не realtime.Rust - это попытка оптимизировать для опенсурсного сообщества не машинные ресурсы, а, очень дорогие сейчас, человеческие затраты сил и времени на разработку путём отказа от ручной работы с памятью в большей части случаев, большей безопасности, достающейся "автоматически" - соответственно, идея в том, чтобы сделать ручную работу с памятью или иные неавтоматизированные действия необходимыми только тогда, когда без них не обойтись.
По сути, по своему назначению, это реинкарнация языка Ada в сфере его гражданского применения (которая изначально предназначалась для разработки сверхбольших программ, военных, а потом и гражданских, и при этом должна была использоваться ещё и для низкоуровнего программирования - для написания быстрых (часто и ещё параллельных) программ реального времени).
Сейчас большие опенсурсные программы пишут часто на С++, а у него много других недостатков, помимо скорости. Поэтому скорость выше явы и ниже С - компромисс.
Для начала rustc должен научиться ставить себя без сотни компонентов. Пока чт для него нужно выкачать половину UNIX мира вроде cmake и т.д. В этом плане golang пока решает у него есть и g build и т.д.
И должен появится в составе GCC, а то тащить в ядро LLVMщину - не путь.
Нормальный язык, этот Rust. Месяц мучений с переформатированием сознания - и дельше все замечательно. Без шуток.