| 1.1, Crazy Alex (ok), 10:49, 15/08/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
 Я, конечно, совершенно не в теме, но как нечто похожее на AWK может быть удобнее нормальных языков?
| | |
| |
| 2.2, Аноним (2), 10:59, 15/08/2019 [^] [^^] [^^^] [ответить]
| +17 +/– |
Набросик так себе.
Люди, могущие в AWK, повидали достаточно, чтобы отреагировать на подобные заявления снисходительно улыбкой.
| | |
| |
| 3.5, Аноним (5), 11:43, 15/08/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ну я могу в awk, когда прижмёт. Но не представляю задачи, котору на нём было бы удобнее решать, чем на perl.
| | |
| |
| |
| 5.14, Аноним (14), 15:36, 15/08/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Это типа perl намного удобнее awk на практически всех задачах, для которых в принципе может сгодиться awk.
| | |
|
| 4.19, Аноним (19), 17:40, 15/08/2019 [^] [^^] [^^^] [ответить]
| +4 +/– | |
>Но не представляю задачи, котору на нём было бы удобнее решать, чем на perl.
Обработка таблиц без сложной логики - получается лаконичнее, чем на perl
| | |
|
| 3.18, Crazy Alex (ok), 17:01, 15/08/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Да это даже не набросик. Ну, то есть можно и в машинных кодах писать, но оно ж чудовищно. Чем это может быть лучше, чем нормальная структурированная запись? Когда оно создавалось - это было логично, тогда каждый байт экономили. А сейчас, уж простите, я лучше явно напишу while(line = read(file){...} чем буду использовать заклинания из AWK. Так его хоть прочесть и поправить можно без расшифровки.
| | |
| |
| 4.24, Hewlett Packard (?), 23:31, 15/08/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Вопрос привычки. Через несколько сотен раз набирания "while(line = read(file)" захочется добавить макро, делающее "while (defined($_ = <file_E>))" из "while(<file_E>)", например. Ну так уже добавлено.
Кому-то надоедает писать foreach i in L { sum += i }, и он начинает использовать foldr (+) L, а потом, может быть и +/L, ну а кому-то наверное и нет.
| | |
|
|
| |
| 3.13, имя (?), 14:40, 15/08/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Это он про D-as-in-DTrace-не-путать-с-D-который-(C++)++
| | |
|
|
| 1.8, Hewlett Packard (?), 12:37, 15/08/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Хорошая штука eBPF.
> Ashish Bijlani of Georgia Tech presented at this week's Linux Foundation Open-Source Summit on the work they are pursuing for making user-space file-systems faster. The short explanation of what they are doing with this project called "ExtFUSE" is to provide an extension framework of a "thin" layer of handlers within the kernel that leverage the eBPF in-kernel virtual machine for speeding up some I/O operations.
> By using these "thin" kernel extensions they are able to avoid some user-space context switching and handling some metadata caching within the kernel while still sticking to the concept of the file-system implementation in user-space. | | |
| |
| 2.9, Andrey Mitrofanov_N0 (??), 12:42, 15/08/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Хорошая штука eBPF.
>>"thin" kernel extensions they are able to avoid some user-space context switching and handling some metadata caching within the kernel while still sticking
Почти как MS-DOS .
| | |
|
| 1.10, Аноним (10), 13:37, 15/08/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Мне одному кажется концепция монолитного ядра и необходимость тащить всё в него - устаревшей и тупиковой?
| | |
| |
| 2.11, Andrey Mitrofanov_N0 (??), 13:48, 15/08/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Мне одному кажется концепция монолитного ядра и необходимость тащить всё в него
> - устаревшей и тупиковой?
Не мешайте Землину-Торвальдсу таки делать свой гешефт !
| | |
| 2.21, КО (?), 18:05, 15/08/2019 [^] [^^] [^^^] [ответить]
| +/– |
Вы внимательно читаете новость?
Всё уже идет к тому, что в ядре будет только jit компилятор, а все остальное будет загружаться динамически. :)
| | |
| |
| 3.25, Hewlett Packard (?), 05:47, 16/08/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Лучше всего если JIT будет прямо в CPU. Но так как JIT для всех языков туда не засунешь, будет для WebAsm.
| | |
|
|
|
