HTML / CSS / JS

Татарин> Ну, это слишком просто, Вы лучше назовите разницу между 3.14%5 и 13.14%5

Очевидно, алгоритм взятия остатка оптимизирован: если делимое меньше делителя, оно возвращается как есть.

Вообще, брать остаток от нецелых чисел - это плохая идея.

tarasv> В общем случае что-то вроде sed просто не работает потому что вход у него текстовая строка, а не дерево.
Ну можно слегка смухлевать. В шаблоне в нужных тэгах проставляешь уникальные id (в любом виде), а уже sed меняет по ним. Но это всё из серии "квадратное катать"

Татарин> А почему во второй раз (а = а - 1) 10 получается?

Вот это как раз совершенно тривиально - приведение по оператору. JS же задуман так что должен падать только когда уже совсем бред на входе.

Татарин>> А почему во второй раз (а = а - 1) 10 получается?
Татарин>> А потому, что в строке а=а-1 меняется тип и представление, уже после конкатенации строки. И 1 вычитается из числа уже.
Zenitchik> Потому что при вычитании оба операнда приводятся к числу. Конкатенация тут ни при чём.
Сложение строк шло в первой строке, оно дало "11", как это она не при чём?

Zenitchik> Меня всегда поражало, что люди, которые поленились спеку почитать, ругают в этом не себя, а язык.
С одной стороны, Вы как бы правы в том, что спеки нужно читать. И да, как я сказал, логика в этом всём есть, безусловно.
С другой - если действия языка сплошь и рядом контринтуитивны вплоть до чтения спеки, если они противоречат всем устоявшимся традициям (без каких-то выгод от этого, просто на ровном месте), и если это язык, который намеренно заимствовал операторы, синтаксис и даже вид у языков, которым он внезапно(тм)! противоречит... то да, это реально что-то не то с языком.

И нет, это НЕ нормально. JS - есть за что ругать.

Т.Б.> Ну можно слегка смухлевать. В шаблоне в нужных тэгах проставляешь уникальные id (в любом виде), а уже sed меняет по ним. Но это всё из серии "квадратное катать"

Это ИМХО сработает только для одного дерева. Если оно поменялось то сразу мусор на выходе.

tarasv> Это ИМХО сработает только для одного дерева.
Я Вам как страрый FORTRANовец старому FORTRANовцу скажу: т.к. HTML уже организован в виде дерева (если угодно, объектно ориентирован), то макроязык для него совсем не обязан понимать, что такое дерево. Так, объектная ориентированность JS - одна из самых больших ошибок его проектирования.

tarasv> Это ИМХО сработает только для одного дерева. Если оно поменялось то сразу мусор на выходе.
Ну, если ты изначально строишь весь рабочий процесс в этой ублюдочной парадигме, то ты будешь очень аккуратно подходить к смене структуры, уникальности заменяемых паттерн и всему такому. Конечно, не было бы CSS - можно было бы и так работать. Сделать это дело отдельным постпроцессингом и, при большом желании, можно даже менять на разное, в зависимости от разрешения и прочих условий на стороне клиента.
Жить так конечно можно, но смысл жизни теряется...

Татарин>> Ну, это слишком просто, Вы лучше назовите разницу между 3.14%5 и 13.14%5
Zenitchik> Очевидно, алгоритм взятия остатка оптимизирован: если делимое меньше делителя, оно возвращается как есть.
Это меньшая часть ответа: в случае 3.14%5 ответ-то верный.
Да, я понимаю, что IEEE-754, а Александр Македонский - великий человек, но табуретки-то зачем ломать?
И вот тут тот ещё вопросец, а откуда, собссно, взялся IEEE-754 в скриптовом(!!!) языке, который весь из себя кричит, что он скриптовый и числа в строки и обратно переводит неявным образом в зависимости от операндов? Децимал-то с бесконечной точностью, как и полагается нормальному скрипту, чем не угодил?
Предполагалось джиэс для быстрых научных расчётов использовать, скорость была критична?

Я понимаю логику, я не понимаю, нафига нужна такая логика.
И никто током не понимает. Потому что оная спека продукт настоящего аджайла. Который не про спринты и ритуалы, а реально "хренак-хренак и в продакшн!".

Zenitchik> Вообще, брать остаток от нецелых чисел - это плохая идея.
Почему же?
Да, в нормальных языках с-семейства "%" - наследник того Сшного или даже ещё Bшного "%", который просто отдаёт второй результат машинного div. Но с чего бы ожидать невозможности или неверности оператора над вещественными числами от джиэса только потому, что в других языках этот оператор похож, но не тот? Спеки же нужно читать? или нет?

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

Gudleifr> Я Вам как страрый FORTRANовец старому FORTRANовцу скажу: т.к. HTML уже организован в виде дерева (если угодно, объектно ориентирован), то макроязык для него совсем не обязан понимать, что такое дерево. Так, объектная ориентированность JS - одна из самых больших ошибок его проектирования.

Как мы помним - JS активно используется на браузерной стороне для конструирования интерфейса.
Ок, у вас есть sed и доступ к телу html файла.
Про то, что это дерево, как вы утверждаете, знать совсем не надо

Вот вам задача: есть в html таблица такого вида:

Имя, Возраст
скажем ( я пишу смысл а не полный html чтобы не миксовать с текстом поста )
table id="Students"
tr
td id="Name" Вася
td id="Age" 25
tr
td id="Name" Коля
td id="Age" 21

По умолчанию сортировка по имени
На форме есть кнопочка сортировки по возрасту

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

yacc> Как мы помним - JS активно используется на браузерной стороне для конструирования интерфейса.
К сожалению. Как я писал рядом можно было бы гораздо проще и удобнее.

yacc> Ок, у вас есть sed и доступ к телу html файла.
sed порядочные люди используют в другом месте.

Татарин> И вот тут тот ещё вопросец, а откуда, собссно, взялся IEEE-754 в скриптовом(!!!) языке, который весь из себя кричит, что он скриптовый и числа в строки и обратно переводит неявным образом в зависимости от операндов? Децимал-то с бесконечной точностью, как и полагается нормальному скрипту, чем не угодил?

Всем. Вы реально хотите странного. IEEE-754 - единственный нормальный формат. Остальное - ересь.

Татарин> Но с чего бы ожидать невозможности или неверности оператора над вещественными числами

С того, что остаток от деления дробных чисел - не рассматривается в математике.

Татарин> Сложение строк шло в первой строке, оно дало "11", как это она не при чём?

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

Gudleifr> К сожалению. Как я писал рядом можно было бы гораздо проще и удобнее.
Вот я вам привел пример на sed ( можете выбрать другой языка регулярных выражение - типа grep и потоки ) - без доступа к дереву объектов - как вы и хотели
Но такое простой пример им у вас решить не получается...

yacc> Но такое простой пример им у вас решить не получается...
Тогда, пардон, уточните, в какой момент Вы хотите решать эту задачу:
1) в момент создания документа
2) загрузки его на хост
3) выдачи с хоста
4) получения браузером
5) в ответ на действия пользователя браузера

yacc>> Но такое простой пример им у вас решить не получается...
Вот тут очевидно
Gudleifr> 5) в ответ на действия пользователя браузера

Мы именно про JS, а не про CGI

Gudleifr>> 5) в ответ на действия пользователя браузера
yacc> Мы именно про JS, а не про CGI

Вообще-то, мы обсуждали замену CSS на sed...
Очевидно, на этапе (5) sed не нужен.

Gudleifr> Вообще-то, мы обсуждали замену CSS на sed...
А я ответил на вот это сообщение


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

Чем вам тут sed, который язык регулярных выражений, не нравится ?

Gudleifr> Я Вам как страрый FORTRANовец старому FORTRANовцу скажу: т.к. HTML уже организован в виде дерева (если угодно, объектно ориентирован), то макроязык для него совсем не обязан понимать, что такое дерево.

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

Gudleifr> Так, объектная ориентированность JS - одна из самых больших ошибок его проектирования.

чем она вам мешает если на JS можно писать как на любом другом скриптовом языке без всякого ООП вообще.

yacc> Чем вам тут sed, который язык регулярных выражений, не нравится ?
Тем, что здесь не нужен поиск текстовых фрагментов по шаблону.

Здесь было бы достаточно всего двух "операторов": ЗАПОМНИТЬ (получение значения) и ВСПОМНИТЬ (вставка значения). И в JS тут две большие проблемы: не все места [напрямую] доступны для получения значения, и места для вставки надо организовывать согласно структуре HTML. Но sed здесь ни при чем.

Gudleifr> Что такое, например, браузер? Что устаревший, что современный - это просто интерфейс между HTTP и HTML. Что в этом сложного? Ничего.

Webassembly задумчиво чешет репу...

Ну, теперь можно ответить и на это:

Bredonosec> Это нормальное грамотное разделение содержимого и представления.
Как можно считать нормальным разделение, при котором одну и ту же информацию приходится обрабатывать дважды? HTML все "знает" про теги. Зачем знать про теги его макроязыку?

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

Bredonosec> Вероятно, по опыту вот такого г**нокодинга и вынесена убежденность, что "хорошая практика программирования - это выкинуть всё целиком и делать с нуля заново"
Это не ко мне, это - к Д.Кнуту.

Bredonosec> наоборот. Для отображения данных он и нужен. И мы сейчас общаемся в таком.
Да. "Это куча навоза - Родина!" ©

Bredonosec> Короче, пурга это полная - насчет "мешает".
Ну, кто на что учился.

Tico> Webassembly задумчиво чешет репу...
Ничего, через годик появится еще более инновационный и близкий к нативному способ объединить все в одном флаконе. А потом - еще. Пока не помрет от старости последний электрик и веб-дизайнеры не начнут рисовать прутиком на песочке.

tarasv> ​Архитектура научного софт, с точки зрения software engineer, не сложная - структуры данных достаточно просты, конвейерная обработка с редкой асинхронностью, вычислений локальны, интеграция с другими программами минимальная

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

16-й> Тут уже и тупые кодеры идут в ход, и острые, ничего не жалеют, чтобы спасти статус кво.

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

Tico> Это всё-таки сильное упрощение. Если брать конечные продукты в реальном исполнении, параллельная обработка больших массивов данных, с даталейками, десятками пайплайнов, краулеров, фильтров, редюсеров и сервисных модулей это серьёзная архитектура с множеством вводных и ещё большим количеством ограничителей. Учитывая, что это ещё и стоит дохрена денег с непрестанными попытками уменьшить до "чуть меньше дохрена", то там всё может быть очень сложно.

это точно про научный софт? по описанию ты скорее банковскую экосистему нарисовал.

научный софт это про анализ результатов экспериментов и численное моделирование.