The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Эксперимент по разработке частей ядра Linux на языке Rust, opennews (??), 04-Июн-17, (0) [смотреть все] +1

Сообщения [Сортировка по времени | RSS]


5. "Эксперимент по разработке частей ядра Linux на языке Rust"  +12 +/
Сообщение от Andrey Mitrofanov (?), 04-Июн-17, 11:53 
> Уродливый синтаксис располагает к сектантству: см. лисп и другие. Разного пошиба шизофреники
> на такое моментально липнут.

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

Ответить | Правка | Наверх | Cообщить модератору

6. "Эксперимент по разработке частей ядра Linux на языке Rust"  +18 +/
Сообщение от A.Stahl (ok), 04-Июн-17, 11:59 
Си. Все популярные языки имеют Си-подобный синтаксис. Чем меньше язык похож на Си тем меньше у него шансов. Ну кроме, может, каких-то узкоспециализированных задач, где заточенность языка под конкретные нужды важнее удобства и красоты.
И не надо мне рассказывать про Фортран. Он омерзителен.
Ответить | Правка | Наверх | Cообщить модератору

22. "Эксперимент по разработке частей ядра Linux на языке Rust"  +15 +/
Сообщение от freehckemail (ok), 04-Июн-17, 13:43 
Хех. Так ведь как раз в лиспах удобства и красоты достичь куда легче за счёт гибкой системы макросов. В этом ведь и есть сила лиспов: не существует ситуации, когда тебе хочется сказать "было бы здорово иметь синтаксическую конструкцию, чтобы выполнить это действие в одну строчку", потому что если она возникает, ты раз - и изменяешь синтаксис языка, как тебе вздумается.

Вы несколько нечестны, придавая большое значение синтаксису. Синтаксис языка выучить - это ж делов-то на неделю, каким бы язык ни был. Основная задача после этого - изучение библиотек, эффективных методов разработки, выработка стиля написания кода. Да будь там хоть BEGIN/END или let/in вместо фигурных скобок - от этого алгоритм сильно не изменяется.

Ответить | Правка | Наверх | Cообщить модератору

24. "Эксперимент по разработке частей ядра Linux на языке Rust"  –2 +/
Сообщение от Аноним (-), 04-Июн-17, 13:48 
> Так ведь как раз в лиспах удобства и красоты достичь куда легче за счёт гибкой системы макросов.

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

154. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от Michael Shigorinemail (ok), 05-Июн-17, 16:52 
> Как показала практика, существенного успеха на рынке промышленных языков это не дает.
> Лисп так и остался местечковой игрушкой для фанатов.

Даёт, даёт.  Вас просто близко не подпустят к _такой_ промышленности, где макросы N-го уровня вложенности.

Там другие проблемы и они в первую очередь (меж)человеческие.

Ответить | Правка | Наверх | Cообщить модератору

26. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от A.Stahl (ok), 04-Июн-17, 13:51 
>в лиспах удобства и красоты достичь куда легче за счёт гибкой системы макросов

Вот только в Лиспе удобства и красоты нужно достигать, а в Си удобство и красота идут "из коробки".

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

34. "Эксперимент по разработке частей ядра Linux на языке Rust"  –6 +/
Сообщение от freehckemail (ok), 04-Июн-17, 14:21 
> в Си удобство и красота идут "из коробки".

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

Ответить | Правка | Наверх | Cообщить модератору

40. "Эксперимент по разработке частей ядра Linux на языке Rust"  –5 +/
Сообщение от myhand (ok), 04-Июн-17, 15:28 
Ви таки хотите сказать, что в Си уже не приходится ручками память себе выделять и освобождать?

А ежели это до сих пор не так - кушайте сами такую красоту.  И удобством обмазаться не забудьте...

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

161. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от _ (??), 05-Июн-17, 18:51 
>Ви таки хотите сказать, что в Си уже не приходится ручками память себе выделять и освобождать?

Это настолько важный параметр для языка системного программирования? ORLY?! :-)
Для клепания складофф\магазинофф^W извиняюсь - The Business Logic Layer (о как звучит!) - есть 100500 языков сделанных именно для этого.

PS: Но и в С, если уж так неймётся - есть соотв. либки, и даже работают.

Ответить | Правка | Наверх | Cообщить модератору

237. "Эксперимент по разработке частей ядра Linux на языке Rust"  +1 +/
Сообщение от myhand (ok), 07-Июн-17, 13:16 
>>Ви таки хотите сказать, что в Си уже не приходится ручками память себе выделять и освобождать?
> Это настолько важный параметр для языка системного программирования? ORLY?! :-)

Ну, большая часть современных языков внезапно ее почему-то включает.

> Для клепания складофф\магазинофф^W извиняюсь - The Business Logic Layer (о как звучит!)

Да, да.  Склады, системы компьютерной алгебры...  100500 реальных вещей, которыми в основном люди и занимаются.

> PS: Но и в С, если уж так неймётся - есть соотв. либки, и даже работают.

"Либки" способны расширять синтаксис С?  Спасибо, повеселил.

Ответить | Правка | Наверх | Cообщить модератору

47. "Эксперимент по разработке частей ядра Linux на языке Rust"  +8 +/
Сообщение от e621 (?), 04-Июн-17, 16:35 
>а в Си удобство и красота идут "из коробки"

...которые, зачастую, куда-то пропадают при написании чего-то существенного.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

66. "Эксперимент по разработке частей ядра Linux на языке Rust"  –2 +/
Сообщение от Crazy Alex (ok), 04-Июн-17, 18:42 
Ну так плюсы надо брать. Современные (11 и дальше). Всё будет и быстро и красиво.
Ответить | Правка | Наверх | Cообщить модератору

74. "Эксперимент по разработке частей ядра Linux на языке Rust"  +1 +/
Сообщение от Aleks Revo (ok), 04-Июн-17, 19:22 
> Ну так плюсы надо брать. Современные (11 и дальше). Всё будет и
> быстро и красиво.

Кроме компиляции и описания ошибок в каких-нибудь шаблонах.

Ответить | Правка | Наверх | Cообщить модератору

90. "Эксперимент по разработке частей ядра Linux на языке Rust"  +1 +/
Сообщение от Vkni (ok), 04-Июн-17, 21:33 
Меня в C++11 и дальше раздражает то, что люди везде пихают std::. В результате простое и понятное

List.map (fun x -> x + 1) [1;2;3;4;5]

превращается в чёрт знает что о двух строках.

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

94. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от Аноним (-), 04-Июн-17, 22:01 
Если вас раздражает только это, значит С++ очень хороший язык
Ответить | Правка | Наверх | Cообщить модератору

96. "Эксперимент по разработке частей ядра Linux на языке Rust"  +1 +/
Сообщение от Vkni (ok), 04-Июн-17, 22:09 
> Если вас раздражает только это, значит С++ очень хороший язык

В данном случае я пристрастен - тут лучше на кого-то другого смотреть, помоложе.

Ответить | Правка | Наверх | Cообщить модератору

127. "Эксперимент по разработке частей ядра Linux на языке Rust"  +2 +/
Сообщение от Аноним (-), 05-Июн-17, 09:15 
> Меня в C++11 и дальше раздражает то, что люди везде пихают std::.

А мне наобарот не понимаю тех, кто использует using namespace std; и потом не понять, толи из std эта функция, толи откуда.


Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

172. "Эксперимент по разработке частей ядра Linux на языке Rust"  +2 +/
Сообщение от Аноним (-), 05-Июн-17, 20:58 
Самый треш — это когда
> using namespace std;

написан в хедере... :S

Ответить | Правка | Наверх | Cообщить модератору

163. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от _ (??), 05-Июн-17, 18:57 
>Ну так плюсы надо брать. Современные (11 и дальше).

Вкусовщина. Щас тут и без меня объяснят что жаба давно уже быстрее процессора, а ребе можно распостранять как образ ВМ снятый с машины разработчика :-)
>Всё будет и быстро и красиво.

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

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

92. "Эксперимент по разработке частей ядра Linux на языке Rust"  +1 +/
Сообщение от Аноним (-), 04-Июн-17, 21:38 
Удобство? Вы хоть один сложный проект пробовал писать на Си? Да, язык хорош, но как раз удобства ему и не хватает.
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 нельзя передавать в качестве формата. Ещё куча возможностей исчезли, либо придётся жертвовать безопасностью и выключать опцию.

И т.д.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

105. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от voice of universe (?), 04-Июн-17, 22:57 
> Удобство? Вы хоть один сложный проект пробовал писать на Си? Да, язык
> хорош, но как раз удобства ему и не хватает.

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

> 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.

> И т.д.

Да продолжай позорится.

Ответить | Правка | Наверх | Cообщить модератору

158. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Alex (??), 05-Июн-17, 18:33 
> 5. static - только для одного файла. Если же я делаю внутреннюю
> переменную в библиотеке, состоящей из нескольких файлов, то она в любом
> случае будет доступна и вне библиотеки. private я её могу сделать
> только одним способом: через атрибуты компилятора. Задефайнено, непортабельно и некрасиво.
>Единственный пункт который можно считать сказанном по теме. И то, необходимость такова >шаринга субъективна. Ну т.е. попахивает нехорошим кодом.

Положи ее в анонимный неймспейс и будет тебе счастье.

Ответить | Правка | Наверх | Cообщить модератору

162. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 05-Июн-17, 18:57 
Видимо, далеки от системного программирования и высокого мнения о своих знаниях. Со временем или сменой работы второе проходит.

>> pthread_detach

valgrind вам в помощь, и огромного вам suppress. А если ещё и реентабельно должно быть, то удачного креша всего линукса через какое-то время.

>> Самое время именно вам выдать эффективную реализацию, этой фичи. ))

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

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

Типа обозвали разработчиков ядра? Или просто не знаете, чем вы пользуетесь на компьютере? Исходники хоть раз в жизни смотрели?

Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

165. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от _ (??), 05-Июн-17, 19:32 
>>> 1. Нет switch..case для константных строк. Почему? Ведь это же удобно. Компилятор
>>> сам бы строил дерево по символам строк и это работало бы
>>> максимально быстро, т.к. автомат состояний встроен прямо в код.
>> Самое время именно вам выдать эффективную реализацию, этой фичи. ))
>С понятием стандартов знакомы? Судя по ответу, - нет.

Уж чья бы корова мычала! (С) :-)
Скажи мне О Знаток Стандартов - есть ли в С тип строка? :-)))))))
А посему и остальной бред на-вид-шоколадо-кодера можно спустить в трэш :-)))))

Ответить | Правка | Наверх | Cообщить модератору

166. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 05-Июн-17, 19:38 
Может перед тем как задавать вопрос, почитаете про NULL-terminated arrays?
Вот черновик стандарта:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1539.pdf

Удачи.

Ответить | Правка | Наверх | Cообщить модератору

167. "Эксперимент по разработке частей ядра Linux на языке Rust"  +1 +/
Сообщение от Аноним (-), 05-Июн-17, 19:41 
На всякий случай ещё главу скажу: String literals. Если с английским проблемы.
Ответить | Правка | Наверх | Cообщить модератору

182. "Эксперимент по разработке частей ядра Linux на языке Rust"  +1 +/
Сообщение от Аноним (-), 05-Июн-17, 22:05 
О, нашелся поклонник, расставил плюсы/минусы. Держи вырезку из твоего источника:

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.

Емое. Вы бы сами читали, что даете...

Ответить | Правка | Наверх | Cообщить модератору

184. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 05-Июн-17, 22:18 
Контекст разговора читали? Человек, на мой взгляд, придрался к понятию строк из самого первого моего сообщения (по контексту дальше был отсыл в стандарт). Я дал ссылку на разъяснение, что в стандарте они прописаны. Извините, но я читаю быстро, сразу не дошло, что там пытаются придраться к терминологии.
Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

186. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от Аноним (-), 05-Июн-17, 22:51 
> Контекст разговора читали?

Не нужно оправдываться.

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

Да, мы все тебя простили. Тут дело не в терминологии, а ПОНИМАНИИ основ сишки. Если копать еще глубже, то даже не сишки, а то с чем работает процессор. Так вот, у процессора максимальный "тип" данных это байт (иногда еще считают "слова", но это только частный случай). В более старых микроконтроллерах (их уже никто не считает за компьютеры) максимальный тип был бит.

И нету никаких типов строк. Даже массив и то это не совсем тип, а абстракция, т.к. внутри всеравно байты. Именно по этой причине, 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(). Все это "удобство" пишется в сишке за день-два и про это забываешь как про кошмарный сон. Либо, ты берешь готовую либу и наслаждаешься тем же, чем наслаждаются другие.

Плюс сишки в этом вопросе в том, что ты МОЖЕШЬ от этой бесполезной ерунды отказаться, КОГДА ты захочешь. А они не могут.

Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

187. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 05-Июн-17, 23:08 
>> Так вот, у процессора максимальный "тип" данных это байт.

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

>> sizeof не может работать в рантайме

Он именно в рантайме и работает. А вот на этапе препроцессора его очень сложно заставить работать. Но разработчики ядра нашли одну "фичу" и могу сделать assert на размер типа данных. Этим применение в препроцессоре и ограничивается. В моём случае применение sizeof требовалось пару раз для определения размера типа переменной.  Зачем уже не вспомню, давно было. Возможно, для определения double ли был передан  или float в unit-тестах, кажется.

Ну а так, немного магии:
void abc(int size)
{
    volatile int buf[size]; // volatile - на случай, если вы какой-нибудь там -O3 используете, чтоб препроцессор не спихнули
    printf("%zu\n", sizeof(buf));
}

Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

198. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от Другой Аноним (?), 06-Июн-17, 09:00 
Для VLA - это Вы его описали в примере - сделано исключение, которое в компиляторе обрабатывается специальный образом. В остальных случаях sizeof() вычисляется в compiletime-е. Если не ошибаюсь, то в C++ поддержка VLA есть, а вот sizeof-а для него - нет.
Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

199. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от tstalker (ok), 06-Июн-17, 09:48 
VLA в C++ отсутствует.
Он есть исключительно в C.
Ответить | Правка | К родителю #198 | Наверх | Cообщить модератору

214. "Эксперимент по разработке частей ядра Linux на языке Rust"  +1 +/
Сообщение от Аноним (-), 06-Июн-17, 19:29 
В контексте вопроса не имеет значения, на этапе препроцессора sizeof всё равно не доступен как раз по причине того, что используется в runtime. За исключением того случая, который я упомянул. А выглядит он примерно так:
#define ASSERT(a) do { x[(sizeof(a) == 4) - 1]; } while (0)

Проверять не хочу, правильно написал или нет, кому требуется сам добьётся эффекта. Но по идее должно сработать. Идея, думаю, понятна.

Ответить | Правка | К родителю #198 | Наверх | Cообщить модератору

244. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 07-Июн-17, 20:55 
Нашёл таки файл, где находится файл, о котором тут рассказывал:
http://elixir.free-electrons.com/linux/latest/source/include...

Макрос BUILD_BUG_ON. В новых версиях gcc он уже не используется, а со старыми приходилось так делать. И там ещё много интересных макрохаков на Си. И описано, зачем они вообще были сделаны. Думаю, чтение комментариев этого файлика будет завершающим ответом на вопрос про удобство Си.

Если б сделали новый язык, оставив синтаксис Си, но избавившись от его недостатков с полной потерей обратной совместимости, я был бы рад. А то  до сих пор не могу делать анонимное наследование структур без расширения ms-extensions.

Ответить | Правка | К родителю #214 | Наверх | Cообщить модератору

263. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от Вячеславemail (??), 09-Июн-17, 22:50 
А разве в языках  Alef и Limbo из Plan 9 и Inferno не избавились от недостатков С с полной потерей обратной совместимости?
Ответить | Правка | К родителю #244 | Наверх | Cообщить модератору

215. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от Аноним (-), 06-Июн-17, 19:45 
>> 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 не позволяет просто так в одиночку передавать массив в функцию, всеравно нужно указывать кол-во элементов.

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

Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

221. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 06-Июн-17, 21:15 
Я разве задавал вопросы или написал что-либо неправильно? На кой сдались мне ваши книжки? На практике вам нужны хорошие навыки алгоритмизации, творческое мышление и непрерывное чтение документации. Книжки на самом деле помогают только в начале, стартовый толчок. Конечно, есть классика, которую должен прочесть каждый, а-ля Таненбаум]6 что-нибудь по теории графов, немного нейронных сетей, генетических алгоритмов (честно, сам последних двух тем почти не касался) и подобные, но книги по конкретным языкам программирования бессмысленны для тех, кто уже знаком хотя бы с тремя языками. А пока ничего нового тут не написали. Обмусоливание темы run-time, compile-time. Это при том, что до всего этого можно догадаться чисто интуитивно, даже не имея большого опыта за плечами. Тут ещё не хватает, чтоб оптимизатор вспомнили или про align'ы заговорили. Какой курс то лучше скажи? Третий или четвёртый? :)
Ответить | Правка | К родителю #215 | Наверх | Cообщить модератору

224. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 06-Июн-17, 21:36 
>книги по конкретным языкам программирования бессмысленны для тех, кто уже знаком хотя бы с тремя языками

Извините, г-н архитектор, просто с такими "идеалами" неудивительно, что кто-то потом путает типы с литералами. Я б еще понял, что вы автор хотя бы 1-го известного компилятора, а посему имеете право не читать книги, а так, вы скатились. Да, скатились, вам лень _вникать_. Хотя чего учить архитектора.

Ответить | Правка | К родителю #221 | Наверх | Cообщить модератору

226. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 06-Июн-17, 22:05 
Не хотите говорить, как хотите. А ведь интересно проверить интуицию то. Книжки должны советовать два типа людей: студенты и преподаватели. Первые т.к. полны энтузиазма из-за того, что узнали много нового, отсюда и высокая самооценка идёт. А вторые по привычке. Вы ко вторым точно не относитесь.

Желание учить людей и объяснять им как правильно, а как нет, что читать, что не читать, - это хорошая черта. Есть шансы в будущем стать тимлидом. Но тут как бы много нюансов.. например, вы должны научиться правильно это делать и правильно всё преподносить. И ни в коем случае не заявлять о превосходстве своих знаний, лучше задавайте вопросы, ждите пока не них ответят, полемика должна быть в форме диалога. В опенсурс-проектах есть одна хитрость. Когда человек делает merge request, даже если проверяющий уверен на 100% в своей правоте, он часто сообщает об ошибке в форме вопроса: "А вы уверены, что в этом случае не может быть то-то и то-то?". Здесь суть в том, что так вы не отпугнёте человека и заставите думать, нежели спорить. А если бы вы сделали уверенное заявление и сами ошиблись, то у контрибьютора просто упало бы о вас мнение и он остальные вещи стал бы делать наперекор с большей вероятностью.

Мотайте на ус и учитесь учтивости.

Ответить | Правка | К родителю #224 | Наверх | Cообщить модератору

227. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 06-Июн-17, 22:09 
>Вы ко вторым точно не относитесь.

Фиговый из вас психолог, продолжайте рисовать архитектуры.

Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

230. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 07-Июн-17, 01:22 
Интересно что ли, почему такие выводы? Могу пояснить. У преподавателей есть собственный этикет. Они не то, чтобы матерные слова, но и мусорные говорить не могут. Если преподаватель (пусть даже анонимно) позволяет себе вести себя неподобающе, то такому не место в образовании. К тому же преподавание даёт невероятную выдержку и психологическую устойчивость. Такого человека очень трудно вывести из себя или взбесить. Такие издержки профессии. А умение находить подход к людям формируется за года два - три, поэтому преподаватели обычно должны быть хорошими психологами и должны уметь находить подход к разным типам людей, будь то практик, теоретик (отличник) или гуманитарий. И в этих подходах не будет попыток принижения или оскорбления, т. к. такие подходы ведут к обратным эффектам и недопустимы. Любой грамотный преподаватель знает всё это.
Ответить | Правка | К родителю #227 | Наверх | Cообщить модератору

234. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 07-Июн-17, 08:18 
>Интересно что ли, почему такие выводы?

Потому что ты людей делишь на студентов и преподавателей. Ты сам-то кто? А родители? А друзья? Тоже все студенты или преподаватели? Нет, это, конечно, возможно, что ты вырос именно в _такой_ среде...

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

Ответить | Правка | К родителю #230 | Наверх | Cообщить модератору

241. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 07-Июн-17, 19:37 
Просто для человека, который до сих пор не похвастался, какой он крутой и чем занимается, после столько изливаний знаний... остальные варианты кроме студента достаточно печальные.
Ответить | Правка | К родителю #234 | Наверх | Cообщить модератору

242. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 07-Июн-17, 20:05 
>остальные варианты кроме студента достаточно печальные.

Печально, что твой кругозор такой узкий. Я не студент и я не преподаватель. Зови меня просто призрак =))

Ты понимаешь, что когда человек не выеживается, то он уже в возрасте? Нет. Ну, подрасти, поймешь почему выеживаться глупо. Как там в ватмане, человека обычно судят по поступкам. Все что я сделал знают определенные люди и я доволен этим. Да, я достиг чего-то, только этого мало. Нужно больше вкалывать, а на опеннете я болтаю на интересные _мне_ темы. Про себя говорить с кем попало НЕ интересно.

Ответить | Правка | К родителю #241 | Наверх | Cообщить модератору

245. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 07-Июн-17, 21:09 
Беседовать одно, а умничать - другое. Я уже долгое время молодёжь пытаюсь направлять в правильные русла, четырёх программистов взрастил уже, научил всему чему мог научить. Так что к совету насчёт отношения к другим людям прислушайся. Если сейчас начнёшь работать над собой, в будущем будет намного проще, когда начнётся работа в команде. Программирование для себя и работа в команде - это два абсолютно разных мира.
Ответить | Правка | К родителю #242 | Наверх | Cообщить модератору

246. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 07-Июн-17, 23:22 
Не понятно чего ты добиваешься. С чего ты взял, что у меня есть проблемы с отношением к другим людям? Может и есть, так это потому, что делю людей на своих и чужих. С чего ты взял, что нужно присмыкаться перед чужими людьми? С чего вдруг я должен к ним вежливым быть? Что они сделали для меня? А что сделал для них я? Вот именно, что ничего. Поэтому либо они принимают меня какой я есть, либо не принимают. Лично я их принимаю такими какие есть. Еще и даю какие-то подсказки. А знаешь, даже на твоем примере ты всю мою помощь отослал в лес. Видишь ли ты архитектор, у тебя за плечами пятое-десятое и т.д. Т.е. уже изначально ты поставил себя выше меня. С чего вдруг? С того, что ты себя мнишь умнее других? Ну, так я же не плачусь, не ругаю тебя. Мне-то что с того, что ты себя пиаришь анонимным людям? Ты что, политик? Нет. Ну, так зачем все это?

Вобщем, люди вокруг совсем недружелюбны, потому что у них имеется такой же детектор "свой-чужой". Это просто прописано в генах. Ты бы поубавил свои обороты, да направил в нужное русло. Например, так распинаться нужно перед девушкой. Она будет тебя слушать. А обычные люди, мужики в частности, на это не ведутся. Это даже тебя отталкивает от других людей, потому что ты пытаешься _навязать_ свой авторитет, а не заслужить. А чтобы чего-то заслужить нужно это доказать, либо сделать услугу. Так вот, ты не сделал услуги и ты не заслужил авторитет, наоборот, ты своим невежеством "я не читаю книг" его профукал.

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

Ответить | Правка | К родителю #245 | Наверх | Cообщить модератору

247. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 08-Июн-17, 07:38 
>> С чего вдруг я должен к ним вежливым быть?

Потому что ты часть общества. Общество влияет на тебя, а ты на общество. И твоё влияние может быть в данном случае пагубным. Чтобы осознать это, необходимо прочесть по крайней мере 3 книги:
* Эгоистичный ген Диккенса,
* Мозг и душа Криса Фрита,
* Я вижу, о чем вы думаете Джо Наварро.

>> Ну, так зачем все это?

Почему я тут развёл всю эту демагогию? Потому я такая же ячейка общества, как и ты, и осознаю это.

Ответить | Правка | К родителю #246 | Наверх | Cообщить модератору

250. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 08-Июн-17, 14:22 
>И твоё влияние может быть в данном случае пагубным.

Может я этого и хочу. Тебе бы в политики, учил бы всех что делать и как жить.

Ответить | Правка | К родителю #247 | Наверх | Cообщить модератору

253. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от Аноним (-), 08-Июн-17, 19:44 
> * Эгоистичный ген Диккенса,
> * Мозг и душа Криса Фрита,
> * Я вижу, о чем вы думаете Джо Наварро.

Ах, да. Спасибо за книги.

Ответить | Правка | К родителю #247 | Наверх | Cообщить модератору

216. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 06-Июн-17, 20:06 
Вобщем, прав был тот, кто сказал, что для VLA сделано исключение для sizeof. В последнем случае sizeof работает в момент исполнения программы, в остальных случаях в момент компиляции. Однако, поскольку все делается на стеке, то пользы от этого немного.

И еще масса ограничений: http://docs.cray.com/books/004-2179-001/html-004-2179-001/z8...

Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

217. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 06-Июн-17, 20:11 
Еще инфа для 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.

Ответить | Правка | К родителю #216 | Наверх | Cообщить модератору

191. "Эксперимент по разработке частей ядра Linux на языке Rust"  –2 +/
Сообщение от . (?), 06-Июн-17, 06:06 
>На всякий случай ещё главу скажу: 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: А вообще спасибо! Давно не ржал так :) Сам наверное был таким .... давно :(

Ответить | Правка | Наверх | Cообщить модератору

194. "Эксперимент по разработке частей ядра Linux на языке Rust"  +1 +/
Сообщение от Аноним (-), 06-Июн-17, 07:20 
Вы вообще о чём? Зачем я буду это компилить? Тут банальное сравнение указателей, которое будет отброшено оптимизатором и заменится строкой puts. Я уже не говорю о том, что вы puts написан с ошибкой, без скобок. Сами б компилировали перед тем как умничать.
Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

177. "Эксперимент по разработке частей ядра Linux на языке Rust"  –2 +/
Сообщение от Аноним (-), 05-Июн-17, 21:44 
>NULL-terminated arrays

Это не тип. Хватит позориться! Можно со "строками" работать и без нуля, с известным значением размера МАССИВА: { 'h', 'e', 'l', 'l', 'o' }. Рекомендую больше читать книжек по сишке.

И уж совсем ж--а наступит, если понадобится работать с multibyte строками (я надеюсь, вы хоть знаете в чем их отличие от wide-string? :). Но еще круче, это уметь (а хотя че уметь-то) работать со строками, где разделить нуль-байт. И если, последние строки для все еще отдельный ТИП, то мне вас очень жаль (не, не жаль, это просто ахтунг с такими знаниями что-то доказывать).

P.S. Я если что, любитель :)

Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

181. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 05-Июн-17, 21:57 
Да понятно, что любитель. Программист сразу писал бы про то, с чем сталкивался на практике (utf-*). Это для студентов такие строки multibyte будут. Да и программисты знают отличие понятия строки от типа данных (я вроде как дал ссылку на строковые константы, не?), не пытаясь высосать из пальца аргументы и придраться к терминологии, с которой сами особо не знакомы.

Заметьте, те, кто у кого большой стаж программирования, будут стараться приводить примеры из своего опыта, нежели придираться к терминологии, чтобы повысить самооценку. Поверьте, здесь вы точно самооценку не повысите (если не уроните).

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

Ответить | Правка | Наверх | Cообщить модератору

183. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 05-Июн-17, 22:13 
>Программист сразу писал бы про то, с чем сталкивался на практике (utf-*). Это для студентов такие строки multibyte будут.

Где будет? Что будет? Вы точно знаете ВСЁ про юникод или у вас это только наслуху? Там ничего фантастичного нет, сплошная математика и таблицы. Как по мне, вы просто мало работали со строками, поэтому вам кажется, что mb-строки это такое невиданное явление.

Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

185. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от Аноним (-), 05-Июн-17, 22:25 
>>Программист сразу писал бы про то, с чем сталкивался на практике (utf-*). Это для студентов такие строки multibyte будут.
> Где будет? Что будет? Вы точно знаете ВСЁ про юникод или у
> вас это только наслуху? Там ничего фантастичного нет, сплошная математика и
> таблицы. Как по мне, вы просто мало работали со строками, поэтому
> вам кажется, что mb-строки это такое невиданное явление.

Я про Юникод знаю лишь основы (коды служебных символов разумеется, я наизусть и не подумаю изучать), пока стараюсь его обработку обходить всеми возможными способами, хотя и активно использую. Конечно есть случаи, когда этого не избежать, например, когда требуется добавит строке ellipsize. Раз уж вы так много знаете, ответьте на вопрос. Почему я не хочу связываться с обработкой Юникода? Если правильно ответите, может ещё подискутируем.

Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

197. "Эксперимент по разработке частей ядра Linux на языке Rust"  +1 +/
Сообщение от Аноним (-), 06-Июн-17, 08:48 
>Почему я не хочу связываться с обработкой Юникода? Если правильно ответите, может ещё подискутируем.

1. Я не телепат.
2. Это не клуб друзей.
3. Хочу/не хочу это для хобби, а в бизнесе либо ты решаешь _задачу_, либо не решаешь.

И что-то мне подсказывает, что ваше "не хочу" означает, что для вас это хобби. Как выйдите работать в бизнес, тогда и подискутируем :)

Ответить | Правка | К родителю #185 | Наверх | Cообщить модератору

218. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от Аноним (-), 06-Июн-17, 20:16 
>>Почему я не хочу связываться с обработкой Юникода? Если правильно ответите, может ещё подискутируем.
> 1. Я не телепат.
> 2. Это не клуб друзей.
> 3. Хочу/не хочу это для хобби, а в бизнесе либо ты решаешь
> _задачу_, либо не решаешь.
> И что-то мне подсказывает, что ваше "не хочу" означает, что для вас
> это хобби. Как выйдите работать в бизнес, тогда и подискутируем :)

В бизнесе можно решить одну задачу парой сотен способов. Потом поймёте о чём я, как на работу, наконец сможете устроиться.

Сначала пройдёте этап сбивания спеси, будет длиться около года. С таким характером будут жёсткие споры с тимлидом, которые будут каждый раз в итоге заканчиваться фиаско для вас.  Затем начнёте понимать, что вы делаете и зачем. Это ещё год - два. Уже настанет время, когда сможете писать качественный код, но, возможно, ещё плохо читабельный. Затем снова можно этап звезданутости настать, но он будет уже намного короче, быстро пройдёт, как только начнёте разбираться с исходниками не только своего проекта, но и сторонних. И как только тимлид вас снова потыкает носом, но уже в читабельность кода.

После всего этого научитесь уважать собеседников и коллег по работе, а также получите неплохую выдержку. А пока советую обратить внимание на личностные качества. В жизни подобные будут только мешать, даже если мозги есть. Сейчас, например, вы просто не переняли опыт программиста, который занимается разработкой архитектуры ПО, с достаточно большим стажем работы. Часто такой случай вам выдаётся? Я, например, по возможности никогда не упускаю такие случаи. И мне всегда интересно узнать мнение грамотных людей.

Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

219. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 06-Июн-17, 20:24 
Ох, щи. Первое, я не перед кем не выеживаюсь. Второе, я не люблю учить других людей, потому что в 95% случаев они этого вообще не хотят. Третье, ваш вопрос был в стиле угадай мелодию. Простите, г-н архитектор, научитесь правильно ставить вопрос. Иначе получается, что mb-строки это такая несусветная фигня, которую _по-вашему_ мнению нужно выпилить. Увы, они были придуманы задолго до того момента как вы стали архитектором. Почему вы, да вы, когда изобретали mb-строки не сказали всем -- ЭТО фуфло, нужно делать так-то?

Вывод таков, что нормальный умный ученик не станет задумываться и играть в игры архитектора, а пойдет писать код. Между прочим, я не программист и тимлиды для меня люди, которые принимают мои патчи. Да-да, принимают, и они в апстриме. Работают. Не, это было слишком пафосно. Я простой человек, чего пристали? :)

Рассказывай что там тебе не нравится в mb-строках, иначе не о чем будет дискутировать, кроме показухи.

Ответить | Правка | К родителю #218 | Наверх | Cообщить модератору

248. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Анонимный Алкоголик (??), 08-Июн-17, 14:03 
Хуже когда switch внутри цикла.
Также вложенные циклы...
Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

258. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Анонимный Алкоголик (??), 09-Июн-17, 17:22 
Но приходится отметить, что многоуровневый break n ещё гораздо хуже goto ...
Ответить | Правка | Наверх | Cообщить модератору

209. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Анонимный Алкоголик (??), 06-Июн-17, 16:51 
> 7. Попробуйте сделать следующее:
> fmt = NULL;
> if (fmt) {
>     fprintf(stderr, fmt, ##args)
> }
> Для компилятора с включенной опцией format-security это ошибка. Т.к. NULL нельзя передавать
> в качестве формата.

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


Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

232. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 07-Июн-17, 07:43 
Макрос само собой, а со склеиванием не угадали. Это называется variadic macros:
https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
Ответить | Правка | Наверх | Cообщить модератору

233. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 07-Июн-17, 07:51 
И сразу поправлю себя, видимо, у меня должно было быть ##__VA_ARGS__, тут я косякнул, да. Давно писал такие штуки.
Ответить | Правка | Наверх | Cообщить модератору

220. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 06-Июн-17, 20:41 
> 6. Макросы - гибкость. А теперь попробуйте сделать макрос с выполнением действия
> в зависимости от размера передаваемой в него переменной. Увы, придётся много
> гуглить и делать костыли. А в итоге просто найти другое решение
> проблемы. А всё почему? Потому что sizeof выполняется в runtime, чтобы
> можно было определять размер стековых массивов. Куча возможностей просто исчезла.

Открой файл curl/typecheck-gcc.h в поставке curl. Там такой макрос на проверку типов ...

Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

231. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от Аноним (-), 07-Июн-17, 07:32 
Это обычный макрос. Я говорил о препроцессоре. Вот такое невозможно:
#if  sizeof(expr) == sizeof(void *)
//...
#endif /* sizeof */

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

На самом деле в C есть возможность проверять тип переменной через typeof, но это всего лишь расширение GCC:
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
ПОэтому завязываться на него серьёзному проекту не стоит.

Ответить | Правка | Наверх | Cообщить модератору

65. "Эксперимент по разработке частей ядра Linux на языке Rust"  –3 +/
Сообщение от Crazy Alex (ok), 04-Июн-17, 18:41 
"Видимый" синтаксис - это прежде всего набор маркеров, позволяющий быстро понимать, что происходит, не вчитываясь в каждую строку. А, foreach - ясно, глянули, что и по чём итерируется - и всё. if - отлично, условие, ветка 1, ветка 2. Всё чётко отделено и визуально выделяется. А скобочки ваши - брейнфак в профиль, независимо от "мощности" и от того, что алгоритм не изменится. Потому что надо в первую очередь восприятие учитывать.

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

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

79. "Эксперимент по разработке частей ядра Linux на языке Rust"  +2 +/
Сообщение от freehckemail (ok), 04-Июн-17, 20:09 
> "Видимый" синтаксис - это прежде всего набор маркеров, позволяющий быстро понимать, что происходит, не вчитываясь в каждую строку.

Ну, этому помогает скорее не синтаксис, а кое-какие решения, принятые на этапе проектирования языка. Например отсутствие перегрузок.
А то как это часто бывает с плюсами, смотришь на код, там написано 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-ов?

> Ну и к тому же - кастомный синтаксис это прикольно... Когда это небольшое дополнение к основному, перекрывающему абсолютное большинство потребностей.

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

Ответить | Правка | Наверх | Cообщить модератору

86. "Эксперимент по разработке частей ядра Linux на языке Rust"  –4 +/
Сообщение от Аноним (-), 04-Июн-17, 21:04 
> Однако, справедливости ради, перед сишниками такой проблемы просто не возникает, потому что у вас тупо нет функций высшего порядка

И слава б-гу что нет.

Ответить | Правка | Наверх | Cообщить модератору

104. "Эксперимент по разработке частей ядра Linux на языке Rust"  +4 +/
Сообщение от freehckemail (ok), 04-Июн-17, 22:42 
>> Однако, справедливости ради, перед сишниками такой проблемы просто не возникает, потому что у вас тупо нет функций высшего порядка
> И слава б-гу что нет.

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

Ответить | Правка | Наверх | Cообщить модератору

108. "Эксперимент по разработке частей ядра Linux на языке Rust"  –3 +/
Сообщение от Аноним (-), 04-Июн-17, 23:07 
И потом в этой одной строчке черт ногу сломит. Спасибо не надо.
Ответить | Правка | Наверх | Cообщить модератору

144. "Эксперимент по разработке частей ядра Linux на языке Rust"  +3 +/
Сообщение от freehckemail (ok), 05-Июн-17, 13:49 
Чёрт ногу сломит, ага:


; определяем сигму
(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ообщить модератору

150. "Эксперимент по разработке частей ядра Linux на языке Rust"  –4 +/
Сообщение от Аноним (-), 05-Июн-17, 14:45 
И по вашему это сильно проще ? По моему вас кто-то обманул.
Ответить | Правка | Наверх | Cообщить модератору

156. "Эксперимент по разработке частей ядра Linux на языке Rust"  +4 +/
Сообщение от freehckemail (ok), 05-Июн-17, 17:56 
> И по вашему это сильно проще ? По моему вас кто-то обманул.

Напишите аналогичный код на Си. Ваше непонимание резко пройдёт. :)

Ответить | Правка | Наверх | Cообщить модератору

249. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Анонимный Алкоголик (??), 08-Июн-17, 14:17 
Угу излишни. Образцово не нужная вещь. Переписываемая практически один в один на C. Ещё в шаблонах там то же самое замудрили. Но это плохая замена нормальному
for
из C.
Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

179. "Эксперимент по разработке частей ядра Linux на языке Rust"  –3 +/
Сообщение от Аноним (-), 05-Июн-17, 21:50 
>Вот простейшую сигму реализовать на сях - надо извернуться. А в функциональных языках - одна строчка.

И что? Я вот каждый только и делаю, что пишу сигмы %) Раз в 50 лет такая задача ставится перед сишнеком. Он ее пишет раз. И забывает еще на 50 лет, т.к. она будет работать везде. А вот ваши функциональные ЯП жрут тонны памяти, фиг скомпилишь и т.д. и т.п.

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

Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

36. "Эксперимент по разработке частей ядра Linux на языке Rust"  –4 +/
Сообщение от nc (ok), 04-Июн-17, 14:52 
Соглашусь насчет синтаксиса Си, он реально хорош, и наверное действительно лучшее что сейчас есть; недаром большинство языков взяло его за основу (C#, Java и многие web-языки включая тот же JS). Но сам язык си все-таки устарел и в общем нуждается в замене (как и С++ с его монструозными шаблонами). Крайне небезопасный лексический препроцессор, намертво прибитый к языку гвоздями; отсутствие модульности и архаичный механизм include; местами недостаточно строгая типизация (хотя и слишком строгая тоже ни к чему); да даже такая вещь как "имя массива является адресом первого элемента массива", делающая массивы не first-class сущностями и приводящая ко многим весьма неочевидным нелогичностям и неудобствам для развития языка...

Rust это всего лишь эксперимент, как и Go, D, Nim и многие другие. Полигон для обкатки идей - в случае с Rust это семантика умных указателей встроенная в язык, хотя там и еще кое что есть. Если есть желающие обкатывать на реальных проектах типа ядра - почему бы и нет, пускай обкатывают и выявляют неудобные места в языке. Синтаксис там действительно тяжеловат для восприятия. Не знаю почему, но код на тех же C# или Java читается гораздо легче.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

41. "Эксперимент по разработке частей ядра Linux на языке Rust"  +4 +/
Сообщение от Orduemail (ok), 04-Июн-17, 15:43 
> Rust это всего лишь эксперимент, как и Go,...

Блажен, кто верует. (c)

Ответить | Правка | Наверх | Cообщить модератору

46. "Эксперимент по разработке частей ядра Linux на языке Rust"  –2 +/
Сообщение от nc (ok), 04-Июн-17, 16:26 
Тут все очень просто: если язык реально хорош во всем, то на нем будут писать и на него будут переходить с других языков. Если нет - то нет. Представьте себе, если появится такой "идеальный си", такой же эффективный, удобный и привычный как Си но со множеством улучшений, органично вписывающихся в концепцию языка - то на нем будут писать. Пока же все это лишь попытки зайти с разных сторон, эксперименты в различных направлениях.
Ответить | Правка | Наверх | Cообщить модератору

50. "Эксперимент по разработке частей ядра Linux на языке Rust"  +3 +/
Сообщение от Orduemail (ok), 04-Июн-17, 16:55 
> Тут все очень просто: если язык реально хорош во всем, то на
> нем будут писать и на него будут переходить с других языков.
> Если нет - то нет. Представьте себе, если появится такой "идеальный
> си", такой же эффективный, удобный и привычный как Си но со
> множеством улучшений, органично вписывающихся в концепцию языка - то на нем
> будут писать. Пока же все это лишь попытки зайти с разных
> сторон, эксперименты в различных направлениях.

"Множество улучшений" и "привычный" -- это взаимоисключающие параграфы.

Ответить | Правка | Наверх | Cообщить модератору

54. "Эксперимент по разработке частей ядра Linux на языке Rust"  –2 +/
Сообщение от nc (ok), 04-Июн-17, 17:23 
Нет конечно. Привычный - это привычный синтаксис и привычная философия языка. Множество улучшений - это значит что улучшения будут в том же ключе что и существующие возможности. Они будут естественно и логично выглядеть на фоне существующих возможностей.
Ну вот самый простой пример пришедший в голову. Если в функцию можно передавать массивы, то почему нельзя передать литерал массива foo({1,2,3}); ? Этого вроде даже в расширениях gcc нет, хотя казалось бы чего сложного?
Ответить | Правка | Наверх | Cообщить модератору

62. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Orduemail (ok), 04-Июн-17, 18:23 
> Нет конечно.

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ообщить модератору

81. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 04-Июн-17, 20:24 
> язык реально хорош во всем

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

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

45. "Эксперимент по разработке частей ядра Linux на языке Rust"  +2 +/
Сообщение от anon3000 (?), 04-Июн-17, 16:25 
>Go

Это язык совсем другого назначения, нежели Rust и Nim. И он уже вполне взлетел в своей нише.

>Rust. Синтаксис там действительно тяжеловат для восприятия.

Авторы дают понять, что им пофиг на синтаксис.

>Rust это всего лишь эксперимент

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

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

128. "Эксперимент по разработке частей ядра Linux на языке Rust"  –2 +/
Сообщение от Аноним (-), 05-Июн-17, 09:28 
> Но сам язык си все-таки устарел и в общем нуждается в замене

Ну есть D, например. Существует аж с 2007 года. Перешли на него? Нет. Значит не нуждается.
Ты ещё предложи ассемблер заменить. x86 ассмблер ух какой древний, нужно срочно заменить!!1111 Ну а чо, можно, стильно, молодёжно.

> Крайне небезопасный лексический препроцессор

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

> архаичный механизм include

Я спешу тебя огорчить - во всех современных языках есть include в той или иной степени :) Просто реализован он немножечко по разному, но суть осталась та же.

> местами недостаточно строгая типизация

Примеры?

> (хотя и слишком строгая тоже ни к чему)

Ты уж определись.

Товарищи, давайте уж не будем гнать на С, а? У каждого языка свои недостатки, но я считал и буду считать всегда, что каждый язык нужен для своих целей. Давайте не будем плодить так называемые "языки общего назначения", тогда и синтаксис у них будет вменяемый.

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

168. "Эксперимент по разработке частей ядра Linux на языке Rust"  +2 +/
Сообщение от _ (??), 05-Июн-17, 20:02 
>> Но сам язык си все-таки устарел и в общем нуждается в замене

Мы с котом пол дня смеялись (С) :)
>Ну есть D, например. Существует аж с 2007 года. Перешли на него? Нет. Значит не нуждается.

Оно было убийцей С++ ... но если ты не видишь разницы ...
>Ты ещё предложи ассемблер заменить. x86 ассмблер ух какой древний, нужно срочно заменить!!1111 Ну а чо, можно, стильно, молодёжно.

Вам который из них? В списке если что сотни четыре 8-) И даже для x86 - даааалеко не один.
Но вот пришёл "высокоуровневый ассемблер" - то бишь С и на классике теперь только вставки пишут.

>> Крайне небезопасный лексический препроцессор
>Что в нём небезопастного? Мне аж интересно стало.

Ого! Дык ты Ыгсперт? :) Попробуй его по-использовать ... но я предупреждал :)

>> архаичный механизм include
>Я спешу тебя огорчить - во всех современных языках есть include в той или иной степени :)

Чееегоооо?!?!?! Ну ка - ИмЬя его сестра!? (С)
Ни в одном из новых на такие явные грабли не наступали ... ну или говори ГДЕ? :)
>Просто реализован он немножечко по разному, но суть осталась та же.

Му-ха-ха :))))
Ну то есть по твоему С-шный include и Go\Python import - это одно и то-же? :-)))
Воросов больше не имею! :-)))))

>Товарищи, давайте уж не будем гнать на С, а?

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

+100500
Тут согласен тоже.

Ответить | Правка | Наверх | Cообщить модератору

170. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 05-Июн-17, 20:33 
> Оно было убийцей С++

Ну хорошо, допустим. И кто убийца Си тогда? Нет таких?

> В списке если что сотни четыре

Ну уж 4 сотни. Известных и часто используемых не так уж и много. Хотя, по сути с ассемблерами тоже тот ещё цирк, примерно как с языками высокого уровня.

> Попробуй его по-использовать ...

Любой #define -- обрабатывается "лексическим препроцессором", постоянно его использую. Для макросов, например, очень удобно. А ещё в стандартной библиотеке Си всё на препроцессоре держится. Так примеры, желательно практического использования, этого "небезопастно" будут? Или всё только в теории, а потом оказывается, что работает только на седьмой день новолуния, когда в жертву принесена девственница.

> ну или говори ГДЕ? :)

Lua, Python, D -- это только из тех, что я использовал.
Что там у Джавы по другому работает, когда я делаю import? Ну да, я могу там отдельные классы подключать из файла, при этом не трогая другие, я правильно понимаю политику партии? Только плюсов я тут не вижу (ну может быть для джавы они и есть, но не для Си).

Ответить | Правка | Наверх | Cообщить модератору

193. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от . (?), 06-Июн-17, 06:43 
>> Попробуй его по-использовать ...
>Любой #define -- обрабатывается "лексическим препроцессором", постоянно его использую. Так примеры, желательно практического использования, этого "небезопастно" будут?

Ну ты спросил! Целые труды написаны. Ну не езнаю, ну напиши сюда макрос для возведения числа в квадрат.

>> ну или говори ГДЕ? :)
>Lua, Python, D -- это только из тех, что я использовал.

Про Lua я не знаю, про D не знаю и не помню :-)
Но если ты действительно считаешь, что Питонячий import и Cи-шный include - это одно и тоже, то ... то медицина тут практически бессильна! :-(

>Что там у Джавы по другому работает, когда я делаю import?

А знаешь что тебя может спасти? Только если возьмёшь и __сам__ выяснишь. Оно того стоит. Честно.

Ответить | Правка | Наверх | Cообщить модератору

210. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 06-Июн-17, 17:18 
> ну напиши сюда макрос для возведения числа в квадрат.

Зачем для этого использовать макрос, если функция уже реализована в math.h? Зачем велописеды городить?
Но если тебе так хочется...

#define pow2 (pow(x, 2))

Вызывается простым:
int x = pow2(integer_here);

Но на самом деле это лишняя строчка кода, которая ещё и вводит в заблуждение.

> Но если ты действительно считаешь, что Питонячий import и Cи-шный include -
> это одно и тоже

Ну хорошо, хорошо, я хотя бы не считаю себя ИКСПЕРДОМ во всём. Объясни разницу, в таком случае.

> А знаешь что тебя может спасти? Только если возьмёшь и __сам__ выяснишь.
> Оно того стоит. Честно.

Я честно пытался выяснить как это работает в джаве. Если я правильно понимаю, все классы подгружаются в память, а потом оттуда дёргаются. Но что там реально происходит я не знаю.
В Си просто подставляется полностью файл и всё склеивается в один.
Так разницу объяснить сразу можешь, а не говорить, мол: выясняй сам (потому что я не знаю, но продолжаю спорить).

Ответить | Правка | Наверх | Cообщить модератору

222. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от Аноним (-), 06-Июн-17, 21:30 
>> Но если ты действительно считаешь, что Питонячий import и Cи-шный include -
>> это одно и тоже
>Ну хорошо, хорошо, я хотя бы не считаю себя ИКСПЕРДОМ во всём. Объясни разницу, в таком случае.

Питоний импорт умеет выделять вещи, которые прописывать в main:: namespace. Чтобы такого добиться в сишке нужно много дефайнить, а в питоне в одну строчку. Хотя, можно извратится и написать имба-макрос, который тоже можно будет писать в одну строчку :))

Ответить | Правка | Наверх | Cообщить модератору

236. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 07-Июн-17, 11:35 
> Питоний импорт умеет выделять вещи, которые прописывать в main:: namespace.

Чего он умеет делать? Ничего не понял. Что значит "выделять" в данном случае? Ну короче говоря, кажется я понял -- он дёргает отдельные фукнции\классы из файла, которые в данный момент нужны. Я прав?

Ответить | Правка | Наверх | Cообщить модератору

243. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от Аноним (-), 07-Июн-17, 20:37 
> Чего он умеет делать? Ничего не понял. Что значит "выделять" в данном
> случае? Ну короче говоря, кажется я понял -- он дёргает отдельные
> фукнции\классы из файла, которые в данный момент нужны. Я прав?

Почти. Там ООП, поэтому смысл импорта в том, что ты можешь дергать функции или обращаться к переменным, минуя указание namespace. Например,

from sys import argv

print argv

Т.о, не указывая sys.argv. В сишке прямого аналога нет, но в плюсах подобное должно быть (сам не плюсовик). И возвращаясь к сишке, аналог должен быть такой, чтобы при include были "видны" только нужные тебе функции/переменные, а не все что указаны как extern.

Ответить | Правка | Наверх | Cообщить модератору

223. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от freehckemail (ok), 06-Июн-17, 21:33 
> #define pow2 (pow(x, 2))
> Вызывается простым:
> int x = pow2(integer_here);

Не надо так делать. Есть ключевое слово inline. Это во-первых. А во-вторых, неправильно. Надо вот так:


#define pow2(x) (pow(x, 2))

>> Но если ты действительно считаешь, что Питонячий import и Cи-шный include -
>> это одно и тоже
> Ну хорошо, хорошо, я хотя бы не считаю себя ИКСПЕРДОМ во всём.
> Объясни разницу, в таком случае.

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

Говоря проще, сишный #include осуществляет тупую подстановку текста из другого файла, а import позволяет, скажем, выдрать отдельные функции, да к тому же переименовать их.

Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

225. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 06-Июн-17, 21:52 
>Разница в том, что в плюсах этим занимается препроцессор, суть работы которого сводится к тому, чтобы сгенерировать текст, который будет скормлен компилятору. В питоне и яве это ключевое слово, часть языка, которое является интерфейсом к абстракции модуля, и обрабатывается соответственно компилятором.

Ну, если так рассуждать, то чем не угодил dlopen?

Ответить | Правка | Наверх | Cообщить модератору

229. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от freehckemail (ok), 06-Июн-17, 22:33 
> Ну, если так рассуждать, то чем не угодил dlopen?

Это вообще к чему?

Ответить | Правка | Наверх | Cообщить модератору

235. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 07-Июн-17, 11:27 
> Не надо так делать. Есть ключевое слово inline.

Я знаю, но попросили то на макросах. Вообще так никто не делает, я сразу это сказал.

> Надо вот так:

Да, действительно, потерял где-то.

> Разница в том, что в плюсах этим занимается препроцессор, суть работы которого
> сводится к тому, чтобы сгенерировать текст, который будет скормлен компилятору. В
> питоне и яве это ключевое слово, часть языка, которое является интерфейсом
> к абстракции модуля, и обрабатывается соответственно компилятором.
> Говоря проще, сишный #include осуществляет тупую подстановку текста из другого файла, а
> import позволяет, скажем, выдрать отдельные функции, да к тому же переименовать
> их.

Наконец-то внятный и адекватный ответ. Спасибо за разъяснения.

Ответить | Правка | К родителю #223 | Наверх | Cообщить модератору

180. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 05-Июн-17, 21:55 
>небезопастно

Это как у каскадеров. Они тоже делают небезопасНые вещи. Каскадеру скажи "прыгни в огонь", он прыгнет. А школота и прочие бабки на скамейках будут кричать "это небезопасно!" =)))

Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

192. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от . (?), 06-Июн-17, 06:22 
А потом такой херой как ты тоще прыгнет. И поджарит яйца :) А говорили же бабки то! :))))
Ответить | Правка | Наверх | Cообщить модератору

55. "Эксперимент по разработке частей ядра Linux на языке Rust"  +2 +/
Сообщение от Vkni (ok), 04-Июн-17, 17:48 
> Си. Все популярные языки имеют Си-подобный синтаксис.

Ну вот Питон имеет не Си-подобный, а скорее ISWIM'овский синтаксис.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

91. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от Хорошийкомп (?), 04-Июн-17, 21:34 
>Все популярные языки имею

Все которые не fortran, matlab или abap.  Те те которые нужны когда нужен конкретный результат, а не какой-то там <<програаамный праадукт>> .

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

7. "Эксперимент по разработке частей ядра Linux на языке Rust"  –8 +/
Сообщение от Аноним (-), 04-Июн-17, 12:00 
JavaScript. Приятнее по синтаксису языка я пока что не видел, хотя в прошлом - крестовик.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

9. "Эксперимент по разработке частей ядра Linux на языке Rust"  +12 +/
Сообщение от Добрый (?), 04-Июн-17, 12:10 
в прошлом - это месяца потора
Ответить | Правка | Наверх | Cообщить модератору

35. "Эксперимент по разработке частей ядра Linux на языке Rust"  –3 +/
Сообщение от Аноним (-), 04-Июн-17, 14:29 
В прошлом - это от десяти до семи лет назад (3 года). Потом ушел в вебдев и стартапы.
Ответить | Правка | Наверх | Cообщить модератору

43. "Эксперимент по разработке частей ядра Linux на языке Rust"  +6 +/
Сообщение от Led (ok), 04-Июн-17, 15:50 
> Потом ушел в вебдев и стартапы.

Деволюция? Назло Дарвину?

Ответить | Правка | Наверх | Cообщить модератору

44. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от Аноним (-), 04-Июн-17, 16:25 
Эволюция.
С помощью веб-стека деньги поднимаются быстрее и проще, чем на системном программировании, плюс идея была в том, чтобы перестать кодить и уйти в менеджеры с техническим уклоном. Что я, собственно, и сделал.

А на крестах проходить путь джун-миддл-сеньор-техдир - десяток лет. Задача же деньги заработать, а не кодить в свое удовольствие.

Ответить | Правка | Наверх | Cообщить модератору

67. "Эксперимент по разработке частей ядра Linux на языке Rust"  +12 +/
Сообщение от Crazy Alex (ok), 04-Июн-17, 18:44 
Ну с того и начни, что не программист, а манагер
Ответить | Правка | Наверх | Cообщить модератору

83. "Эксперимент по разработке частей ядра Linux на языке Rust"  +3 +/
Сообщение от freehckemail (ok), 04-Июн-17, 20:42 
> идея была в том, чтобы перестать кодить и уйти в
> менеджеры с техническим уклоном. Что я, собственно, и сделал.

Смотрите, люди. Такие "менеджеры" ещё и работу "находят", и людьми "управляют".

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

130. "Эксперимент по разработке частей ядра Linux на языке Rust"  –2 +/
Сообщение от Аноним (-), 05-Июн-17, 09:37 
Я не хочу больше упарываться и работать ночами, тратя свое здоровье - для этого существуют энтузиасты-пролетарии. Я ухожу домой не уставшим ровно по окончанию рабочего дня и получаю раза в два больше зарплату, чем они.
Деволюция, конечно же.

А начал я это понимать, как раз, поработав 5 лет кодером (3-кресты, 2-веб), после чего начал активно действовать, чтобы прекратить этот кошмар.

Ответить | Правка | Наверх | Cообщить модератору

136. "Эксперимент по разработке частей ядра Linux на языке Rust"  +3 +/
Сообщение от Orduemail (ok), 05-Июн-17, 11:08 
Пфеу. И почему ты считаешь, что твоё мнение о языках кому-то важно? Может ещё мнение сантехника о языках нам должно быть важно?
Ответить | Правка | Наверх | Cообщить модератору

137. "Эксперимент по разработке частей ядра Linux на языке Rust"  –4 +/
Сообщение от Аноним (-), 05-Июн-17, 11:19 
Все просто - я руковожу кодерами, а для этого надо разбираться в предметной области.
Ответить | Правка | Наверх | Cообщить модератору

138. "Эксперимент по разработке частей ядра Linux на языке Rust"  +2 +/
Сообщение от Orduemail (ok), 05-Июн-17, 11:30 
> Все просто - я руковожу кодерами, а для этого надо разбираться в
> предметной области.

Хахаххахаа.

Ответить | Правка | Наверх | Cообщить модератору

148. "Эксперимент по разработке частей ядра Linux на языке Rust"  +4 +/
Сообщение от freehckemail (ok), 05-Июн-17, 14:27 
> Все просто - я руковожу кодерами, а для этого надо разбираться в предметной области.

Молодой человек, по Вашим комментариям здесь видно, что это далеко не так.

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

Хотите менеджером быть - будьте. Но нефиг лезть со своим "авторитетным" мнением в область, в которой не разбираетесь. Это интернет, тут за такое могут и н###й послать. Что Вы собственно и имеете удовольствие наблюдать в комментариях.

Ответить | Правка | Наверх | Cообщить модератору

176. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Led (ok), 05-Июн-17, 21:43 
> Все просто - я руковожу кодерами

Альфа-вэб-макак?

Ответить | Правка | Наверх | Cообщить модератору

129. "Эксперимент по разработке частей ядра Linux на языке Rust"  +1 +/
Сообщение от Аноним (-), 05-Июн-17, 09:30 
> Задача же деньги заработать, а не кодить в свое удовольствие.

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

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

14. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 04-Июн-17, 12:45 
> JavaScript. Приятнее по синтаксису языка я пока что не видел, хотя в
> прошлом - крестовик.

см. Ruby в части синтаксиса и реализации идеи того, что программа должна читаться как текст на естественном языке

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

27. "Эксперимент по разработке частей ядра Linux на языке Rust"  +4 +/
Сообщение от Аноним (-), 04-Июн-17, 13:52 
Ушибленной этой идеей предлагаю пойти писать на COBOLе.
Ответить | Правка | Наверх | Cообщить модератору

32. "Эксперимент по разработке частей ядра Linux на языке Rust"  –2 +/
Сообщение от Аноним (-), 04-Июн-17, 14:17 
Ну товарищ говорит, что ему JS лучший синтаксис. Всё же JS лучше кобола
Ответить | Правка | Наверх | Cообщить модератору

38. "Эксперимент по разработке частей ядра Linux на языке Rust"  +4 +/
Сообщение от антончик (?), 04-Июн-17, 15:20 
Хуже JS мало что можно себе представить.
Ответить | Правка | Наверх | Cообщить модератору

84. "Эксперимент по разработке частей ядра Linux на языке Rust"  –13 +/
Сообщение от freehckemail (ok), 04-Июн-17, 20:42 
> JavaScript. Приятнее по синтаксису языка я пока что не видел, хотя в прошлом - крестовик.

Всё, что нужно знать о JS:


null == 0  // false
null > 0   // false
null >= 0  // TRUE!!!!

По синтаксису-то оно, может, и приятнее... ))

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

116. "Эксперимент по разработке частей ядра Linux на языке Rust"  –12 +/
Сообщение от Сандибридж (?), 05-Июн-17, 01:08 
Это уже достаточная причина избегать JS, а ведь еще есть variable hoisting...
Ответить | Правка | Наверх | Cообщить модератору

139. "Эксперимент по разработке частей ядра Linux на языке Rust"  +11 +/
Сообщение от Аноним (-), 05-Июн-17, 11:42 
Все, что нужно знать о freehck:

Пишет код так, что в переменных у него будут лежать данные непредсказуемого типа, то null, то number.

Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

171. "Эксперимент по разработке частей ядра Linux на языке Rust"  –10 +/
Сообщение от _ (??), 05-Июн-17, 20:38 
А у него есть выбор?
Вы же сами так свои какашки пишете, что оно возвращает "данные непредсказуемого типа, то null, то number" ... :-\
Ответить | Правка | Наверх | Cообщить модератору

196. "Эксперимент по разработке частей ядра Linux на языке Rust"  +10 +/
Сообщение от Аноним (-), 06-Июн-17, 07:39 
Погоди, ты путаешь. Если конкретно у тебя там данные непредсказуемого типа, то это не значит, что у других такой же бардак. Это всего лишь значит, что конкретно ты не умеешь писать внятный код. В "стандартной библиотеке" яваскрипта свойства имеют один и тот же тип. window.scrollX -- это всегда number. Array#indexOf() -- это всегда number. А вот у тебя представляю, какой ужас.
Ответить | Правка | Наверх | Cообщить модератору

155. "Эксперимент по разработке частей ядра Linux на языке Rust"  +12 +/
Сообщение от Аноним (-), 05-Июн-17, 17:54 
учите матчасть, эксперт.

i) null нестрого равен только самому себе и undefined-у.

ii) при относительных сравнениях оба операнда приводятся к числу; null приводится к нулю, в итоге получаем вполне логичные 0 > 0 === false и 0 >= 0 === true.

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

iiii) трудно представить себе переменную, где помимо числа мог бы еще храниться null. Ненайденный индекс? Для этого есть -1. А даже если такая ситуация и найдена, разраб просто обязан учитывать все возможные значения переменной. Или в _этом_ случае вы бы их сравнивали, беря на веру, что там обязательно будут числа? Что ж, тогда счастливой отладки.

Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

202. "Эксперимент по разработке частей ядра Linux на языке Rust"  –11 +/
Сообщение от freehckemail (ok), 06-Июн-17, 10:37 
> учите матчасть, эксперт.

Ммм, молодые яваскриптеры не знают шуток старых яваскриптеров? :)

Ну, ловите тогда ещё:


['10','10','10','10'].map(parseInt) // даёт [10, NaN, 2, 3]

Ответить | Правка | Наверх | Cообщить модератору

203. "Эксперимент по разработке частей ядра Linux на языке Rust"  +8 +/
Сообщение от Аноним (-), 06-Июн-17, 11:02 
> Ну, ловите тогда ещё:

А теперь переходишь в доки и с удивлением узнаешь о том, что 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.

Ответить | Правка | Наверх | Cообщить модератору

206. "Эксперимент по разработке частей ядра Linux на языке Rust"  –5 +/
Сообщение от freehckemail (ok), 06-Июн-17, 14:23 
Ну вот и выросло новое поколение JS-ников. Ладно, объясню на пальцах, что ли. Мне-то всё равно, но Вам полезно. :)

Так вот, все эти примеры были в начале нулевых тем, что сильно удивляло программистов, переходящих в веб с других языков. Именно перешедшие в JS из других областей больше всего с него и плевались по простой причине: методологии и именования, принятые в других языках, в JS сделаны шиворот-навыворот. И посему ещё в начале нулевых эти люди (теперь уже либо большие профессионалы в этой области), обильно шутили о новом "популярном языке".

Но вот взять parseInt: почему он принимает ещё и базу? В других языках функция с аналогичным названием парсит десятеричные числа, а для других баз существуют отдельные функции.
Взять map: почему по доке он должен принимать функцию от трёх аргументов, когда во всех языках принимает унарную?
Или почему не делается разницы для map и mapi, где вторая функция как раз и добавляет возможность передать индекс текущего элемента, как это сделано в других языках?
Или почему во время вызова функции, переданной в map, не проверяется её арность? В доке же написано, что функция должна быть тренарная, почему же map принимает функцию одного-двух аргументов и даже выполняется как-то вместо того, чтобы бросать исключение, или возращать какой-нибудь маркер ошибки, или просто завершать работу интерпретатора?

Отдельная песня -- это гремучая сместь нестрогой типизации с неявным приведением типов. Очень легко представить себе функцию, которая выдирает число из какого-нибудь элемента DOM, а возвращаемое значение null использует в качестве маркера, чтобы обозначить, что элемент DOM не найден. В этом случае неявное приведение типа сыграет очень злую шутку. А ведь такое запросто случится: заложится как-то один программист, что этот элемент всегда присутствует, опустит проверку на null. Через год он будет модифицировать другой участок кода и элемент пропадёт. И начнутся удивительные по своей природе баги. И такое происходит сплошь и рядом. Не надо думать, что вы-то особенные, что вы-то все-все-все проверки напишете. Наступит час, когда вы будете уставшими, или (что гораздо чаще) дедлайн на носу будет. И вы ошибётесь. А дебаг этой проблемы превратится в сущий ад.

Вот такие вопросы и возникают, когда программисты со стороны смотрят на JS. То, что всё это прописано в документации, это конечно замечательно... Вот только нельзя же по каждому чиху в документацию смотреть. Нельзя же помнить все её талмуды наизусть. Из-за этого хорошие программисты с широким кругозором и опытом в других языках не идут в JS. Из-за этого большинство JS-ников являются молодыми программистами, которые в продакшене ничего, кроме JS не видели толком.

Вы -- новое поколение JS-ников. Вам кажется, что всё вышеописанное -- нормально. Но для программистов из других областей всё это выглядит как шутка юмора такая.
Вы -- новое поколение JS-ников. Вам стоит посмотреть вокруг, и понять, что чуток самокритики вам не повредит. Вот Vkni ниже совершенно верно замечает в #115: "кругозор от Эдиты Пьехи до ..."

Ответить | Правка | Наверх | Cообщить модератору

208. "Эксперимент по разработке частей ядра Linux на языке Rust"  +5 +/
Сообщение от Аноним (-), 06-Июн-17, 15:50 
> взять 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 -- это язык, в котором помнить приходится о на редкость малом.

Ответить | Правка | Наверх | Cообщить модератору

211. "Эксперимент по разработке частей ядра Linux на языке Rust"  –6 +/
Сообщение от freehckemail (ok), 06-Июн-17, 17:46 
Контекстно-клиповое мышление, или что это такое? На вырванные из контекста фразы ответили, а общую мысль проглядели? Новое поколение JS-ников...
Ответить | Правка | Наверх | Cообщить модератору

238. "Эксперимент по разработке частей ядра Linux на языке Rust"  +4 +/
Сообщение от Аноним (-), 07-Июн-17, 13:52 
Общей мысли тут никакой нет, есть лишь общая твоя проблема -- упорное нежелание читать документацию. На мои вопросы ты, кстати, не ответил. Что это, новое поколение фанатиков определенного языка? Надеюсь, не си? Страшно подумать, что будет, если фанатик, игнорирующий документацию, станет писать драйвера. "Ой, а у вас тут оборудование ведет себя не так, как я привык с оборудованием A и оборудованием B".
Ответить | Правка | Наверх | Cообщить модератору

239. "Эксперимент по разработке частей ядра Linux на языке Rust"  –4 +/
Сообщение от freehckemail (ok), 07-Июн-17, 14:22 
> Общей мысли тут никакой нет

Хей-хо. Народ, поглядите! Новое поколение JS-ников имеет настолько поломанное восприятие реальности, что даже не может прочитать и понять простой и максимально разжёванный ответ.

Ответить | Правка | Наверх | Cообщить модератору

240. "Эксперимент по разработке частей ядра Linux на языке Rust"  +3 +/
Сообщение от Аноним (-), 07-Июн-17, 14:52 
Уже всё было. И апелляция к мифическому "народу", и к какому-то "пасмари там внизу чо пишут". А вот ткнули тебя мордой в документацию -- до сих пор отплеваться не можешь. Как там, в "другом", "нормальном", "обычном" языке называется функция, перегоняющая из 30-ричной строки в число? parseInt30?
Ответить | Правка | К родителю #239 | Наверх | Cообщить модератору

251. "Эксперимент по разработке частей ядра Linux на языке Rust"  +2 +/
Сообщение от Анонимный Алкоголик (??), 08-Июн-17, 14:24 
Эм... Так о том речь, что отплеваться сложно. От этого самого. Закреплённого в документации >:-)
Ответить | Правка | К родителю #240 | Наверх | Cообщить модератору

252. "Эксперимент по разработке частей ядра Linux на языке Rust"  –4 +/
Сообщение от freehckemail (ok), 08-Июн-17, 19:05 
> Эм... Так о том речь, что отплеваться сложно. От этого самого. Закреплённого в документации >:-)

Спасибо, камень с сердца. Я уже думал, что никто не поймёт, о чём я. :)

Ответить | Правка | К родителю #251 | Наверх | Cообщить модератору

254. "Эксперимент по разработке частей ядра Linux на языке Rust"  +1 +/
Сообщение от Аноним (-), 09-Июн-17, 03:52 
Со своим виртуалом беседу ведешь от нехватки аргументов, а, parseInt30? :)
Ответить | Правка | К родителю #252 | Наверх | Cообщить модератору

255. "Эксперимент по разработке частей ядра Linux на языке Rust"  –2 +/
Сообщение от Аноним (-), 09-Июн-17, 05:44 
>  а, 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

Ответить | Правка | К родителю #254 | Наверх | Cообщить модератору

256. "Эксперимент по разработке частей ядра Linux на языке Rust"  +2 +/
Сообщение от Аноним (-), 09-Июн-17, 13:11 
Ой, вы тут друг дружку не покусайте:

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) → integer

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

Выходит, что если в JS parseInt принимает базу -- это плёхо. Если то же самое в других языках -- это благодать.

Ответить | Правка | К родителю #255 | Наверх | Cообщить модератору

257. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от Аноним (-), 09-Июн-17, 16:31 
> Ой, вы тут друг дружку не покусайте:
> 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) → integer

int 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 sequtils

echo repr(["10","10","10"].map(parseInt))
% nim c -r  даже_маргинальныйЯП.nim
0x800681048[10, 10, 10]

Ответить | Правка | К родителю #256 | Наверх | Cообщить модератору

259. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 09-Июн-17, 17:46 
['10', '10', '10', '10'].map(t => parseInt(t))

</thread>

Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

260. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 09-Июн-17, 17:49 
Еще более короткий способ для тех, кто экономит пространство на жестком диске, которое тратится на объявление функции-обертки над parseInt:

['10', '10', '10', '10'].map(Number)

Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

261. "Эксперимент по разработке частей ядра Linux на языке Rust"  +2 +/
Сообщение от Аноним (-), 09-Июн-17, 18:19 
> для тех, кто экономит пространство на жестком диске,
> которое тратится на объявление функции-обертки

Отличное понимание принципов работы железа и софта на низком уровне. Хотя чего можно ожидать от 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]

Дал базы отдельно - работает. Не дал - работает с базой по умолчанию.

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


Ответить | Правка | К родителю #260 | Наверх | Cообщить модератору

262. "Эксперимент по разработке частей ядра Linux на языке Rust"  –1 +/
Сообщение от Аноним (-), 09-Июн-17, 20:58 
> На д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-ном мапе. А ты напиши на супирмощном питоновском.

Ответить | Правка | К родителю #261 | Наверх | Cообщить модератору

264. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Аноним (-), 10-Июн-17, 00:43 
>> Дал базы отдельно - работает. Не дал - работает с базой по умолчанию.
> Отлично. То есть получается этот твой мап принимает третьим аргументом доп. аргументы
> для приведения в число. Логично, че.

Третьим? Там их можно передавать столько, сколько влезет. Прикольно, да?


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".


Ответить | Правка | К родителю #262 | Наверх | Cообщить модератору

115. "Эксперимент по разработке частей ядра Linux на языке Rust"  +2 +/
Сообщение от Vkni (ok), 05-Июн-17, 00:11 
> JavaScript. Приятнее по синтаксису языка я пока что не видел, хотя в
> прошлом - крестовик.

Т.е. "кругозор от Эдиты Пьехи до ...".

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

143. "Эксперимент по разработке частей ядра Linux на языке Rust"  +/
Сообщение от Andrey Kovtunenkoemail (?), 05-Июн-17, 13:41 
>> Уродливый синтаксис располагает к сектантству: см. лисп и другие. Разного пошиба шизофреники
>> на такое моментально липнут.
> Ваш вброс настолько прекрасен, что прямо неймётся спросить, каков же Он, прекрасный
> синтаксис, на который льнут строевым гранёным выверенным шагом солдафоны, стриженные
> под одну гребёнку?.... Сорвите же покровы, маэстро.

Пусть меня проклянут всё true-пацаны но синтаксис Си не так уж и прекрасен, да он годен, но не прекрасен. Прекрасны C#, Java и т.д. Это тоже спорный вопрос конечно, но по крайней мере runtime языки консистентны, но ввиду того что на низком уровне такого соотношения удобства и функциональности добиться не особо возможно - возникают определенные парадигмы программирования, в рамках которых синтаксис и формируется. И этот синтаксис не так уж и уродлив если понимать саму парадигму, а не пытаться имея в голове старые конструкции (а может быть просто не понимая новые), использовать новый инструментарий.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру