Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Религиозные войны > присваивание и сравнения

Автор: 502 7.9.2011, 21:38

<присваивание> | <равно>, <не равно>, <меньше>, <больше>, <меньше или равно>, <больше или равно>

Автор: newbee 7.9.2011, 21:54

setq | eq/eql/equal/equalp/=, (not (eq/...)), <, >, <=, >=. О каком вообще сравнении идет речь? Арифметическом? Почему только о нем?

Автор: 502 7.9.2011, 21:58

Цитата(newbee @  7.9.2011,  21:54 ) Арифметическом?    Цитата(newbee @  7.9.2011,  21:54 ) Почему только о нем? ну, мне пока только это интерестно а какие еще ты хочешь обсудить? Добавлено через 1 минуту и 50 секунд мой вариант <- | =, /=, <, >, <=, >=   Добавлено через 6 минут и 51 секунду вот какие еще варианты встречал <не равно> : #(в Oberon) <меньше или равно> : \< <больше или равно> :  >/

Автор: newbee 7.9.2011, 22:07

502, я поняла, что весь цимес вокруг присвоить/равно, не понятно, зачем сюда приплетать больше, меньше и т.д. Еще в юниксах прикольные сравнения (http://unixhelp.ed.ac.uk/CGI/man-cgi?test) и вроде бы в перле что-то похожее. ЗЫ. Мне кажется, слабоват вопрос для разжигания холивора

Автор: A5uKa 8.9.2011, 07:20

is | =, ≠, <, >, ≤, ≥

Автор: 502 8.9.2011, 09:07

Цитата(newbee @  7.9.2011,  22:07 ) не понятно, зачем сюда приплетать больше, меньше и т.д имхо, если этого не делать, то получится так:  <равно> : ==,  <меньше или равно> : <= хотя логично было бы <==    Цитата(A5uKa @  8.9.2011,  07:20 ) is | =, ≠, <, >, ≤, ≥  прикольно, а как набрать на клавиатуре?

Автор: k0rvin 8.9.2011, 11:27

Цитата(newbee @ 7.9.2011,  21:54) setq setf же!

Автор: Vex 8.9.2011, 12:26

Вариант паскаля самый логичный

Автор: A5uKa 8.9.2011, 13:02

Цитата(502 @ 8.9.2011,  09:07) Цитата(A5uKa @  8.9.2011,  07:20 ) is | =, ≠, <, >, ≤, ≥  прикольно, а как набрать на клавиатуре? ALT + Код символа Добавлено через 33 секунды Альтернативно - доп кнопки-макросы

Автор: LSD 8.9.2011, 13:06

Цитата(A5uKa @  8.9.2011,  14:02 ) ALT + Код символа Ага и файлы исходников в юникоде

Автор: newbee 8.9.2011, 13:12

Цитата(k0rvin @  8.9.2011,  12:27 ) setf же!  Почему бы и нет Цитата(A5uKa @  8.9.2011,  14:02 ) ALT + Код символа Добавлено через 33 секунды Альтернативно - доп кнопки-макросы  Неудобно. Такая запись хороша на бумаге. Цитата(LSD @  8.9.2011,  14:06 ) Ага и файлы исходников в юникоде И?

Автор: LSD 8.9.2011, 13:41

Цитата(newbee @  8.9.2011,  14:12 ) И? Сразу видно человека который не разу не наступал на грабли связанные, с настройками компилятора, VCS и т.п.

Автор: newbee 8.9.2011, 13:49

Цитата(LSD @  8.9.2011,  14:41 ) Сразу видно человека который не разу не наступал на грабли связанные, с настройками компилятора, VCS и т.п.  Раз язык содержит юникодовые лексемы, значит его компилятор однозначно без всяких настроек жрет юникод. Какие проблемы в поддержке юникода в VCS? Какие проблемы в поддержке юникода в и т.п.? Сразу видно человека, застрявшего в веке однобайтовых кодировок.

Автор: A5uKa 8.9.2011, 15:14

Цитата(newbee @ 8.9.2011,  13:49) Сразу видно человека, застрявшего в веке однобайтовых кодировок.    Цитата Неудобно. Такая запись хороша на бумаге. ну а если взять IDE, которое транслирует >= в ≥ и т.д.

Автор: newbee 8.9.2011, 15:38

Цитата(A5uKa @  8.9.2011,  16:14 ) ну а если взять IDE, которое транслирует >= в ≥ и т.д.  Это понятно, ты что-то вроде того и имел в виду, говоря о макросах и хоткея, как я понимаю. Я часто работаю удаленно по ссш на железе, не знающем о графических интерфейсах. В такой конфигурации IDE идут нафиг  ПС, это вообще из какого языка?

Автор: LSD 8.9.2011, 15:58

Цитата(newbee @  8.9.2011,  14:49 ) Раз язык содержит юникодовые лексемы, значит его компилятор однозначно без всяких настроек жрет юникод. Какие проблемы в поддержке юникода в VCS? Какие проблемы в поддержке юникода в и т.п.? Не все diff утилиты нормально работают с юникодом, не все редакторы могут сразу распознать кодировку. Ту же виндовую консоль, надо настраивать на поддержку юникода. Где гарантия что на удаленном сервере с SSH доступом, будет настроен юникод, чтобы можно было правильно увидеть листинг программы. В общем сразу видно людей которые не работали с legacy системами.

Автор: newbee 8.9.2011, 16:12

Цитата(LSD @  8.9.2011,  16:58 ) Не все diff утилиты нормально работают с юникодом, не все редакторы могут сразу распознать кодировку. Ту же виндовую консоль, надо настраивать на поддержку юникода. Где гарантия что на удаленном сервере с SSH доступом, будет настроен юникод, чтобы можно было правильно увидеть листинг программы. В общем сразу видно людей которые не работали с legacy системами.  Я че и говорю, человек, может быть по долгу службы, застрявший в прошлом. Юникод - это светлое настоящее и, думаю, будущее. Скептическое к нему отношение из-за того, что 15 лет назад он мало где работал, попахивает глупостью и закостенелостью мышления.

Автор: LSD 8.9.2011, 16:41

Цитата(newbee @  8.9.2011,  17:12 ) Я че и говорю, человек, может быть по долгу службы, застрявший в прошлом. Юникод - это светлое настоящее и, думаю, будущее. Скептическое к нему отношение из-за того, что 15 лет назад он мало где работал, попахивает глупостью и закостенелостью мышления. Выигрыш от использования ≠, ≤, ≥ минимален, а возможный геморрой трудно предсказуем. На данный момент все mainstream языки позволяют писать программы на чистом ASCII. Тот же компилятор Java перед компиляцией переводит весь код в UTF-16, но при этом нет необходимости использовать не ASCII символы, все можно написать на чистом ASCII.

Автор: Фантом 8.9.2011, 17:00

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

Автор: newbee 8.9.2011, 17:10

Цитата(LSD @  8.9.2011,  17:41 ) Выигрыш от использования ≠, ≤, ≥ минимален С этим я полностью согласна, скажу даже больше, выигрыш сомнителен. Цитата(LSD @  8.9.2011,  17:41 ) а возможный геморрой трудно предсказуем А с этим - нет, если речь идет о перспективной разработке, а не поддержке легасей и cmd.exe.

Автор: LSD 8.9.2011, 17:23

Цитата(newbee @  8.9.2011,  18:10 ) А с этим - нет, если речь идет о перспективной разработке, а не поддержке легасей и cmd.exe.  Ну да, конечно. Я тоже пару недель назад, не думал что на свежем дистрибутиве линукс, могут быть какие-то проблемы с распаковкой zip архивов. Чем сложнее система и больше в ней разных компонентов, тем выше шанс что будут грабли с кодировкой. Нет такой достаточно сложной системы, которая бы не взаимодействовала с legacy системами. Хотя если это язык для написания Hello world, то конечно нет проблем.

Автор: A5uKa 9.9.2011, 05:43

Цитата(newbee @ 8.9.2011,  15:38) Цитата(A5uKa @  8.9.2011,  16:14 ) ну а если взять IDE, которое транслирует >= в ≥ и т.д.  Это понятно, ты что-то вроде того и имел в виду, говоря о макросах и хоткея, как я понимаю. Я часто работаю удаленно по ссш на железе, не знающем о графических интерфейсах. В такой конфигурации IDE идут нафиг  ПС, это вообще из какого языка? по ssh невозможно работать    особенно когда хост далеко (был опыт). это придумано )

Автор: LSD 9.9.2011, 10:04

Цитата(A5uKa @  9.9.2011,  06:43 ) по ssh невозможно работать Работать да, а фиксить баги иногда приходится.

Автор: newbee 9.9.2011, 13:22

Цитата(LSD @  8.9.2011,  18:23 ) Ну да, конечно. Я тоже пару недель назад, не думал что на свежем дистрибутиве линукс, могут быть какие-то проблемы с распаковкой zip архивов. Могу предположить, что проблема оказалась в том, что кодировка имен файлов в архиве была cp1251. Разве юникод виноват в твоей проблеме? Ну поставь себе cp1251 локаль, я тебе пришлю архив с KOI8-R-именами файлов. Ты мне все больше напоминаешь ождного моего упоротого знакомого, использующего везде KOI8-R-локали, "потому что так надежнее" и во всех своих проблемах винящий современные utf8-линуксы и винды, а не свою больную голову. Цитата(LSD @  8.9.2011,  18:23 ) Чем сложнее система и больше в ней разных компонентов, тем выше шанс что будут грабли с кодировкой. Нет такой достаточно сложной системы, которая бы не взаимодействовала с legacy системами. Хотя если это язык для написания Hello world, то конечно нет проблем.  Ну что за демагогия на техническом ресурсе? Цитата по ssh невозможно работать  smile  особенно когда хост далеко (был опыт). Если соединение совсем труба, да. В таком случае удобнее пользоваться sshfs, nfs или ftp. У меня проблем с работой по ssh не возникает, может потому, что пользуюсь консольными редакторами?..

Автор: A5uKa 9.9.2011, 13:41

Цитата(newbee @ 9.9.2011,  13:22) Цитата по ssh невозможно работать  smile  особенно когда хост далеко (был опыт). Если соединение совсем труба, да. В таком случае удобнее пользоваться sshfs, nfs или ftp. У меня проблем с работой по ssh не возникает, может потому, что пользуюсь консольными редакторами?.. У меня сервер в США

Автор: newbee 9.9.2011, 13:46

Цитата(A5uKa @  9.9.2011,  14:41 ) У меня сервер в США  В СШП все так плохо с интернетами?

Автор: A5uKa 9.9.2011, 13:47

Цитата(newbee @ 9.9.2011,  13:46) Цитата(A5uKa @  9.9.2011,  14:41 ) У меня сервер в США  В СШП все так плохо с интернетами?  Скорее у нас.

Автор: LSD 9.9.2011, 14:09

Цитата(newbee @  9.9.2011,  14:22 ) Могу предположить, что проблема оказалась в том, что кодировка имен файлов в архиве была cp1251. Разве юникод виноват в твоей проблеме? Ну поставь себе cp1251 локаль, я тебе пришлю архив с KOI8-R-именами файлов. Ты мне все больше напоминаешь ождного моего упоротого знакомого, использующего везде KOI8-R-локали, "потому что так надежнее" и во всех своих проблемах винящий современные utf8-линуксы и винды, а не свою больную голову. Предположение неверное, все имена были в ASCII. И не стоит уподобляться тому самому упоротому знакомому, заявляя что юникод панацея от всех проблем. А если где то юникод не поддерживается, то это устаревшая система и ее надо немедленно выкинуть. Цитата(newbee @  9.9.2011,  14:22 ) Ну что за демагогия на техническом ресурсе? Ты просто не понимаешь о чем я

Автор: 502 22.12.2011, 12:36

ещё вариант присваивания Код set answer to 42

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)