- 1
- 2
- 3
- 4
Я не считаю, что писать сайты на С++ - это бред. По-моему бред - это использовать динамически типизированный скрипт, типа PHP, у которого даже нормального ООП нет.
Я писал на PHP и знаю, как это не удобно. Я считаю, если создать нормальную удобную обертку, то на С++ писать гораздо удобнее.
Самый главный минус С++ в том, что свой сайт я могу держать только на своем собственном сервере, и не могу его залить на какой-нибудь бесплатный хостин,
как в случае с PHP.
Smekalisty 15.07.2014 18:04 # 0
Денис Попов, перелогинься )
gost 15.07.2014 18:18 # 0
Я не прафессианальный сайтостроитель с гейдева.
bormand 15.07.2014 18:10 # +2
Да почему, можно залить на тот же openshift. Один хер посещаемость этого говносайтца будет чуть менее чем нулевая, и фришный small gear вполне вытянет нагрузку.
Cascader 31.07.2014 13:22 # 0
Abbath 15.07.2014 18:15 # +2
guest 15.07.2014 18:20 # 0
guest 15.07.2014 18:21 # 0
kipar 16.07.2014 12:20 # +1
guest 15.07.2014 18:28 # −10
guest 15.07.2014 18:37 # +3
guest 15.07.2014 19:28 # −5
Всепопустительства админов плоды беспечные цветут.
***
Таджики трахнули Азула:конча струится,кровь течет.
На помощь прибежал Диаз: теперь не парень - пидорас.
Несчастный модер крикнул: "No-o-o-o!!!!!", но гомосекам все равно.
***
А где админ? А вот и он:
Вот, кто-то в рот его ебет.
Певец в стоячий микрофон - Азам Азизов хуй сосет.
guest 15.07.2014 19:54 # −5
guest 15.07.2014 19:59 # −3
1024-- 15.07.2014 20:06 # +7
guest 15.07.2014 20:22 # +1
1024-- 15.07.2014 20:35 # 0
kegdan 16.07.2014 06:19 # 0
kipar 16.07.2014 12:21 # +2
inkanus-gray 16.07.2014 12:32 # 0
guest 06.12.2014 04:29 # 0
Этим говном сегодня пользоваться нельзя, все тормозит и лагает, а жаль.
3.14159265 16.07.2014 13:51 # 0
guest 15.07.2014 21:28 # +2
guest 06.12.2014 04:29 # 0
eth0 15.07.2014 20:11 # 0
bormand 15.07.2014 20:12 # +1
Их нет, как и переполнений буфера*.
* если не делать вид, что ты пишешь на си, а не на крестах
eth0 15.07.2014 20:13 # 0
bormand 15.07.2014 20:15 # +1
P.S. Ну да, возможны утечки как в жабе - бесконечно растущие кеши и т.п. Но они в любом языке возможны (кроме, пожалуй, пыхи, из-за ее любви к рестарту после каждого запроса).
eth0 15.07.2014 20:34 # 0
Есть другая проблема - слегка неудобно менять страницы, но это поправимо, если логику засунуть в библиотеки.
bormand 15.07.2014 20:37 # +1
Да ну... Остановить старый бинарь, подменить на новый, да запустить. Заодно спасёт от желания править скрипты прямо на боевом сервере.
Если вся эта байда работает через балансер - никто даже и не заметит перебоя в работе.
> если логику засунуть в библиотеки
Имхо, будет менее удобно, чем с монолитным бинарником.
eth0 15.07.2014 20:54 # 0
bormand 15.07.2014 20:55 # 0
inkanus-gray 16.07.2014 01:08 # 0
http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModMagnet
http://redmine.lighttpd.net/projects/lighttpd/wiki/AbsoLUAtion
Fike 15.07.2014 21:08 # +4
gost 16.07.2014 13:56 # 0
gost 16.07.2014 14:03 # +1
САЙТ НА C++ САМ НЕ НАПИШЕТСЯ
НАПИШИ ЕГО, НАПИШИ ЕГО ЕЩЕ РАЗ
ЗАЧЕМ МНЕ НУЖЕН PHP, У МЕНЯ НЕТ ВРЕМЕНИ ЧТОБЫ ЕБАТЬСЯ С НИМ
ЛУЧШЕ ЕЩЕ РАЗ НАПИСАТЬ САЙТ НА C++
Я ПИШУ САЙТ НА C++ ПО 3 РАЗА В ДЕНЬ
КАЖДОЕ НАПИСАНИЕ ЗАНИМАЕТ ДВАДЦАДЬ МИНУТ
Я ЖИВУ АКТИВНОЙ И ПОЛНОЦЕННОЙ ЖИЗНЬЮ
Я УСПЕШЕН И ПОЭТОМУ ЦЕЛЫЙ ДЕНЬ ИГРАЮ В ИГРЫ
А ПОСЛЕ ЭТОГО ПИШУ САЙТЫ НА C++
ТУПЫЕ ПОХАПЭКОДЕРЫ ОДЕРЖИМЫ НЕДО-ООП
А Я СВОБОДНЫЙ ОТ ЗАДРОТСТВО ЧЕЛОВЕК
СКОЧАТЬ БЕЗПЛАТНО И БЕЗ РЕГИСТРАЦИИ МОКРЫЕ ПИСЕЧКИ
КРЯК УЛЬТИМАТ КЕЙГЕН РАЗБЛОКИРУЙ ВЕНДУ
ЛУЧШЕ Я НАПИШУ САЙТ НА C++
И НАБЛЮЮ НА ВОРНИНГИ, СТАБИЛЬНОСТЬ НЕ НУЖНА
Я НЕ ПИСАЛ САЙТ НА C++ НЕДЕЛЮ
ПОЙДУ НАПИШУ
В C++ ВСЕ ПРОСТО И ПОНЯТНО
ОШИБКА ACCESS VIOLATION 0XC0000005. ЭТО ЖЕ ОЧЕВИДНО КАК ЕЕ РЕШИТЬ
ПРИШЛО ВРЕМЯ ПИСАТЬ САЙТ НА C++
ККОКОКОКОКОКОКО
ПШП ХТМЛ ПИТУХИ
КОКОКОКОКОКОКО
3.14159265 16.07.2014 14:05 # 0
roman-kashitsyn 16.07.2014 14:07 # +5
kegdan 16.07.2014 18:51 # 0
1024-- 16.07.2014 18:59 # 0
kegdan 16.07.2014 19:01 # −1
Я нихуя не понял
1024-- 16.07.2014 19:08 # 0
Есть версия, что это ошибка в слове "всё".
kegdan 16.07.2014 19:09 # +1
3.14159265 16.07.2014 19:21 # +2
>Бесконечноразрядный компьютер вселенной тик за тиком раскрывает бесконечный ленивый персистентный вектор иммутабельных состояний пространства-времени.
http://govnokod.ru/11978#comment157061
roman-kashitsyn 16.07.2014 20:06 # 0
Вижуал Студия
bormand 16.07.2014 20:10 # +5
kegdan 16.07.2014 20:32 # +2
guest 09.09.2014 20:37 # −2
roman-kashitsyn 16.07.2014 14:02 # +4
Главная страничка Гугла, насколько мне известно, обслуживается с++-бэкэндом.
Facebook раньше деплоился не в виде php-скрипта, а путём кросс-компиляции в c++ c последующей сборкой бинарника (сейчас не уверен).
У нас на работе есть внутренний fastcgi framework, позволяющий писать веб-бэкэнд на C++ не менее удобно, чем какой-нибудь Play Framework. На нём написана куча разных сервисов.
inkanus-gray 16.07.2014 14:10 # 0
Чтобы получить хоть какой-нибудь перфоманс, нужно переходить на статическую типизацию. Но всё равно не будет решена главная проблема PHP — смерть процесса после каждого запроса.
3.14159265 16.07.2014 17:10 # 0
>потому что компилятор воспроизводит весь функционал PHP, включая динамическую тупизацию с ненужной питушнёй (обычная переменная, хранящая числовое значение, превращается в объект).
Движкам браузеров это не мешает быть адски шустрыми *. Всё дело в JIT.
Он собирает статистику, если переменная в методе используется только как число, он будет хранить число.
Когда происходит "питушня" VM просто деоптимизирует и начинает интерпретировать код.
* В сравнении с другими динамическими языками
3.14159265 16.07.2014 17:16 # 0
Это всё виртуально - с точки зрения программера. Думаю там запилены пулы и кеши.
На самом деле пыха у fb и vk работает намного лучше чем у многих кресты там жаба или шарп.
3.14159265 22.07.2020 13:13 # 0
eth0 16.07.2014 20:57 # +1
$a = "10";
$a *= 2;
wvxvw 10.09.2014 09:07 # 0
Другой пример: в Яве есть т.н. два типа полиморфизма (они же механизмы, которые регулируют диспатч методов): статический и динамический. Статический предполагает определенную оптимизацию еще на стадии компиляции, а динамический будет разруливать применимые типы в рантайме, что по-сути никак не отличается от того же Питона, ж.скрипта и т.п. Если программист не понимает разницу, и, например, пишет код используя восновном интерфейсы, не конкретизируя, то есть большой шанс того, что работать это будет точно так же, как в том же Питоне или ж.скрипте.
roman-kashitsyn 10.09.2014 09:52 # +3
> динамический будет разруливать применимые типы в рантайме
Это только invokedynamic разруливает, да и он всего раза в 3-4 медленнее прямого вызова.
Если речь идёт о вызове метода интерфейса, то это по сути вызов функции по указателю, никакого разрешения не нужно. Разница в производительности между вызовами статических методов и полиморфных смехотворна. И уж пистон с его строковым лукапом по иерархии словарей там даже рядом не стоял.
wvxvw 10.09.2014 12:49 # 0
Но опять же, ответ не совсем по теме. Главное, что статическая типизация ортогональна производительности, потому что регулирует когда, а не как интерпретируются типы (при условии, что интерпретатору вообще интересно работать с типами).
roman-kashitsyn 10.09.2014 13:06 # +2
Да вот не ортогональна.
Если все типы проверены, а вызовы разрешены на этапе компиляции, то во время выполнения этого делать не придётся, следовательно, программа должна работать быстрее (иногда существенно).
Компилятор, выполнив свою работу, может отнять у значений знание о собственном типе, сократив кол-во требуемой памяти, оптимизировав использование кэша.
Вместо указателей на типы в кэш теперь поместится больше полезной информации.
Если вся работа выполнена в статике, рантайму не придётся отслеживать сложные связи между сущностями и оптимизировать куски заново в связи с изменившейся политикой партии.
Да, рантаймовый оптимизатор иногда может знать больше статического и может оптимизировать более сложные кейсы, частично компенсировав свои недостатки.
Но пока ещё статика и производительность идут бок о бок.
> в В8 схема похожая
Не похожая. В V8 жабоскрипт в рантайме компиляется в практически плюсовые классы, хэш-таблички по возможности заменяются структурами, методы превращаются в нативные функции, которые дёргаются по указателям. Но если кто-то вдруг решит добавить к объекту полей, рантайму придётся менять определение класса и генерить нативный код заново, что является весьма затратной операцией.
eth0 10.09.2014 13:56 # 0
А мне казалось, что там какой-то псевдоассемблер.
roman-kashitsyn 10.09.2014 14:00 # +1
wvxvw 10.09.2014 15:48 # +4
3.14159265 10.09.2014 16:21 # +3
Brilliant!
roman-kashitsyn 10.09.2014 16:38 # +1
Пф, O(n) удовлетворяет только неудачников. Крутые пацаны ровняются на Джеффа Дина и не пользуются алгоритмами хуже O(1/n)
3.14159265 10.09.2014 16:47 # +1
guest 06.12.2014 04:32 # 0
wvxvw 10.09.2014 15:53 # 0
roman-kashitsyn 10.09.2014 16:50 # +4
Меняется. Программа на JS динамична и может так себя изменить, что для эффективного её представления потребуется повторная оптимизация.
За бОльшую выразительность и гибкость в процессе выполнения приходится расплачиваться производительностью.
У меня аналогии с обратным индексом в вебе. Когда у нас есть статичный набор документов, можно спокойно построить индекс и выполнять запросы очень быстро. Если набор документов постоянно меняется, возникают проблемы с шардированием и мёржем индексов, слежением за удалёнными документами, необходимость слияния на запросах и вообще куча сложностей. Если сделать всё грамотно, производительность не сильно упадёт, но повозиться придётся, да и запросы бегать будут медленнее, хотя амортизированная сложность алгоритмов будет той же.
wvxvw 10.09.2014 17:52 # 0
Но я уже устал повторять. Это ошибка в определениях: неправильно понято что такое "статическая типизация", ну и дальше ей приписываются магические свойства основаные на очень ограниченых личным опытом наблюдениях. Нет даже никакой корелляции между тем когда проверяются типы и тем как быстро работает програма. Но людям приятно верить в чудеса.
roman-kashitsyn 10.09.2014 19:59 # 0
> людям приятно верить в чудеса.
Вы, как всегда, абсолютно правы.
wvxvw 10.09.2014 20:19 # 0
Скорость програмы меряется в атомарных операциях необходимых для ее выполнения, при условии, что мы говорим о компутере Фон Ноймана. Может ли так получиться, что програма со статической типизацией справится хуже с поставленой задачей, чем програма с динамической, или отсутствующей типизацией? - да. Аналогично, верно и то, что програма со статической типизацией может справиться с задачей лучше.
Утверждать, что програмы со статической типизацией быстрее програм с другими видами типизации - это просто демонстрировать отсутствие понимания терминологии. Нет никакой закономерности, в том чтобы первое или второе было исключительно верно. Просто так получилось, что в нашем очень маленьком мире программирования, который и просуществовал-то всего-ничего, было написано несколько компиляторов, которые лучше справлялись с ограниченым спектром задач.
1024-- 10.09.2014 20:46 # 0
Но этот мир существует, используется и формирует мнения. На крестах пишут люди поумнее тех, кто пишет на жс. Думают и пишут оптимальный код без лапши, красивостей и замыканий замыканий замыканий шестиуровневых лямбд. Слабая динамическая типизация и сахарок привлекают и развращают. Пишут программы реальные люди.
Это, если не говорить о каком-то правильном мире (которого нет, потому такие аргументы никому не нужны) или конкретных проектах (которые есть). Можно на C++ написать интерпретатор внутреннего языка и программа на C++ будет тормозить, но этот случай не подходит под "обычно у нас" и среднюю температуру по палате.
P.S. Непропорционально больно Вы в комметариях бьёте за неточные и интуитивные высказывания.
wvxvw 10.09.2014 21:14 # 0
Почему это не правильно думать, что языки со статической типизацией быстрее языков с другой типизацией? - Потому, что это неправильное понимание причины и следствия, это как думать, что ветер дует потому, что деревья шатаются. Если мы делаем неправильные выводы из ситуации, которую мы наблюдаем сейчас (даже если они не противоречат наблюдениям), мы не будем развиваться в правильном направлении (т.е. мы не будем в состоянии адекватно предсказать результаты наших последующих действий). Если мы так думаем, потому, что нам так "здесь и сейчас" удобнее, вместо того, чтобы думать потому что "этому есть логическое объяснение". Если мы будем продолжать думать догматически, а не формально, то мы придем верным путем к системе требующей эпициклов и т.п. неоправданых сложностей.
1024-- 10.09.2014 21:35 # 0
> Если мы делаем неправильные выводы из ситуации, которую мы наблюдаем сейчас
Можно и правильные сделать, выражаясь более политкорректно. Скажем, "Вывод: В исследованных 60% проектов статическая быстрее на январь 2020 года", где-то в глубине души осознавая, что всё могло быть наоборот.
А от "здесь и сейчас" мы так просто не оторвёмся. За неправильными выводами стоят большие дяди и их деньги. Увидели, что параметр N позволит получить больше денег - подкрутили N, пока мода не сменилась. В итоге за деньги дядь суетится большая толпа народа. Стоит только почитать посты на хабре о увеличении посещаемости. Здесь и сейчас модно зелёное - значит сделаем зелёный фон, чтобы получить +2 человека. В этом году пользователи жмут на круглые кнопки чаще на 0.00002% - сделаем круглую кнопку.
Всё это позорно, конечно, но сложно игнорировать. Разве что действительно начать строить мощный лазер.
1024-- 10.09.2014 21:41 # 0
wvxvw 10.09.2014 21:58 # 0
Нет никаких исследований которые это подтверждают. Исследования должны выдвинуть гипотезу, а данные должны ее подтвердить. Тут нет никакой гипотезы вообще. Это даже сформулировать нельзя так, чтобы это можно было подтвердить, или опровергнуть.
wvxvw 10.09.2014 22:15 # +1
Такое предположение можно выдвинуть руководствуясь наблюдением, что регулируя движение, светофоры сопутствуют тому, чтобы водители могли не опасаться неожиданых изменений ситуации и свободнее планировали движение. И можно провести эксперимент в годордких условиях, где на дороге со светофорами автомобили будут всреднем двигаться быстрее.
Естесственно, это предположение - не правильное. Т.как его можно опровергнуть, например, сравнив скорости на междугородней трассе, или на специальном спортивном треке.
Точно так же, проверка типов не является фактором влияющим на скорость програм. Просто мы ее наблюдаем в таких условиях, где ее эффект совпадает с желаемым. Естесственно, программист, который лучше проверяет свой код, скорее всего, при наличии ограниченых ресурсов (времени, знания системы) напишет вцелом лучший код, который, кроме остальных показателей, будет еще и быстрее работать. Но, аналогично ситуации с автогонками, из этого не следует причинно-следственная связь, и возможно, когда в будущем роботы будут управлять автомобилями, светофоры будут не нужны.
1024-- 11.09.2014 04:55 # 0
Красиво.
> И можно провести эксперимент в годордких условиях, где на дороге со светофорами автомобили будут всреднем двигаться быстрее.
> Естесственно, программист, который лучше проверяет свой код,<...>
> Но, аналогично ситуации с автогонками, <...>
Да.
Да, всё верно. Утверждение работает локально, но может перестать.
defecate-plusplus 10.09.2014 22:22 # +3
один раз при компиляции на машине разработчика, и далее эффективное использование стека, регистров и оптимизаций и, главное, ровно 0 секунд затрат на проверку реальных типов в реалтайме,
либо N раз при каждом исполнении этого блока, каждый раз с потенциально разным результатом, и потому пессимистичным размещением операндов и отсутствием оптимизаций
действительно, никакой разницы вообще
wvxvw 10.09.2014 22:31 # −1
Если бы идиотские утверждения о типизированых програмах были бы правильными, то, поскольку в машинном коде типов нет, любая програма на Ц++ была бы быстрее этой же програмы, но скомпелированой.
defecate-plusplus 10.09.2014 23:01 # 0
И да, перечитай ещё раз. Твоя динамическая программа не может получить тот же машинный результат. Физически. У неё будет иное представление. С кучей дополнительных проверок и именно что убогое размещение данных и в случае интерпретатора - и кода. На то она и динамическая типизация.
wvxvw 10.09.2014 23:25 # 0
Взять любую книжку по теории типов, как правило, автор сначала сваяет в ней свою версию нетипизированого лямбда-исчисления, а потом к нему добавит типов. Как правило, там же будет такое или подобное заявление "добавив типов, мы не расширили выразительности языка, но некоторые выражения теперь стали невозможными"). Например, On The Expressive Power of Programming Languages Матиаса Фелайзена (хрестоматийный текст, по-сути):
\Lambda^t [типизированый вариант варианта лямбда-исчисления расширеного вызовом по имени и вызовом по значению -- мое] has the same set of phrases as \Lambda [нетипизированый прототип первого -- мое] but uses a type checking algorithm for filtering valid programs.
Никому даже в голову не прийдет выступать заявлениями о скорости. Еще раз. Скорость измеряется, для компьютера Фон Ноймнана, гарантировано завершающихся програм, в количестве элементарных операций нужных для выполнения поставленой задачи. Присутствие или отсутствие типов в принципе не могут на это повлиять. Типы это способ ограничить возможные выражения языка, и все.
wvxvw 10.09.2014 23:39 # −1
Типы влияют на то, сколько выражений можно построить инструментами языка.
Время проверки типов влияет на то, как скоро программист обнаружит ошибки в своем коде.
Доступность информации о типах компилятору может (но не должна) помочь сгенерировать новую програму (не ту, которую написал программист), которая будет работать быстрее написаной программистом.
Доступность типов компилятору не зависит от этапа, на котором осуществляется проверка типов. Она зависит от выразительности языка которым типы описаны. Т.е. мономорфный язык со статической типизацией будет в худшем положении, чем полиморфный язык с динамической типизацией.
Нет никакой статистики подтверждающей влияние выбраной схемы типизации (или полного отказа от типизации) на скорость работы програм. Более того, у нормальных людей такой вопрос даже не возникает, т.как скорость и корректность програм явления достаточно хорошо изученые, чтобы делать такие предположения.
defecate-plusplus 11.09.2014 00:13 # +6
И для теоретиков на засыпку - сколько тактов реального процессора потребуется затратить в обоих случаях.
wvxvw 11.09.2014 08:46 # 0
Почему у людей без выдающихся аналитических способностей бытует мнение, что динамические языки медленнее?
- Потому, что компиляция, которая будет делать много проверок относительно корректности программы занимает много времени. Для практических задач, иногда можно пожертвовать корректностью в пользу скорости. Выполнить скрипт на Питоне может оказаться гораздо быстрее дождаться загрузки Ява компилятора, сборки и запуска програмы на Яве. Другая сторона медали - отсутствие специфики в проверках (которое позволяет сократить время компиляции) приводит к тому, что какую-то часть этих проверок удобнее оставлять до времени исполнения програмы.
Т.е. в конце концов, програмы тормазаят изза того, что в них есть проверки типов. Именно там они проводят бесполезное время, которое не делает никакого вклада в вычисление результата програмы.
roman-kashitsyn 11.09.2014 08:58 # +11
Анонимус 04.12.2014 02:19 # 0
Хм) Размерность операнда самый что ни на есть тип! В x86 есть такие типы как byte, word, итд.
wvxvw 04.12.2014 09:32 # 0
Сама по себе инфорамция о том, сколько битов есть в каком регистре ничего такого интересного нам не дает. Ее можно дополнительно интерпретировать как типы, но:
1. Это будет интерпретация не заложеная в сам язык.
2. Эта интерпретация не будет даже похожей на исходные типы, которые были в програме из которой получился этот машинный код.
Анонимус 04.12.2014 14:10 # 0
Конечно можно интерпретировать byte (или qbyte) как signed или каждый его бит как флажок, ну так и в сях можно точно так же делать с интом. Или в сях тоже нету типов?
1024-- 04.12.2014 16:21 # 0
wvxvw 04.12.2014 20:14 # 0
Пример типа: b в системе { a -> b, ~a }. Или описаный словами: "тип b в системе правил состоящей из b следует из a, и не a". Т.е. система не должна быть перечислением всех типов, но типы должны не противоречить системе.
cyperh 04.12.2014 21:52 # 0
wvxvw 04.12.2014 22:31 # 0
Вот тут та же ситуация: почему-то комментаторам кажется, что они точно знают, что такое типы в то время, как говорят о вещах которые к типам прямого отношения не имеют.
1024-- 04.12.2014 23:05 # 0
Слово "катастрофа" по-разному понимается в разных областях наук. Слово "функция" по-разному понимается в математике и программировании. Более того, его смысл различен даже в отдельных ЯП. Или функторы в Haskell и функторы в C++. Везде используются свои термины.
А Вы приходите со своими математическими типами на ГК словно математик на новостной сайт и просите более никогда не употреблять слово "катастрофа" в отношении "ДТП, Холокост, Титаник и т.д." из-за того, что кто-то использовал это понятное слово в своих корыстных целях (передаём привет компании "Яблоко").
P.S. Если булевы значения в Вашей математике образуют тип, то чем int не его расширенный вариант (либо с трактовкой Анонимуса, либо просто как многозначный boolean)? Если же true|false - не тип, то Ваша математика не имеет практического смысла, а значит будет пылиться на полке до нужных времён.
wvxvw 04.12.2014 23:20 # 0
И вообще, математика - это не наука, но это уже я цепляюсь к словам.
Я говорю не про какие-то специальные "математические типы", а про типы в программировании, которые описываются математической теорией.
Не нужно приплетать сюда разногласия, которые не имеют отношения к теме разговора. Я не говорил про функции и про то, что под этим подразумевается в разных языках.
В "моей" математике? Какие вообще булевые значения? О чем это вообще? Возьмите, блин книжку, да просто хотя бы статью в Википедии и прочитайте, зачем мне высказывать личное мнение о вопросе в котором личных мнений быть не может? А может у вас есть личное мнение о том, как должно работать сложение и умножение? Или личное мнение о скорости света?
Вот, для начала: http://en.wikipedia.org/wiki/Type_(model_theory).
cyperh 05.12.2014 00:14 # 0
wvxvw 05.12.2014 00:38 # 0
Тип - это абстрактное математическое понятие, такое же, как "множество", или "коммутативность". Програмы на Ассемблере не являются каким-то показателем / предметом в обсуждении того, что такое тип. К ним можно подойти с определенной точки зрения, и охарактеризовать в них что-то как систему типов. Но это не будет значить, что эти програмы выражают, или описывают эти типы. Перепутать эти две вещи, это т.н. use-mention error (в моем дословном переводе: ошибка интерпретации, т.е. ошибка которая возникает когда описание чего-то принимается за само явление, или, наоборот, явление интерпретируется как описание этого явления).
Типы никто не "придумывал", и уж тем более с исторической точки зрения это не правильно. Типы существовали и спокойно себе существуют безотносительно компьютеров, битов и байтов. Более того, человечество вымрет, вместе с компьютерами, а типы останутся.
cyperh 05.12.2014 00:53 # 0
wvxvw 05.12.2014 01:09 # 0
Где я говорю, что типов нет? Я говорю, что тип - это такое же понятие, как "множество", и даже ссылку дал, где доступно описано, что такое тип. Просто люди, которые используют это слово в этом обсуждении используют его не по назначению, но хотят прийти к выводу, который не в определении этого термина.
guest 05.12.2014 01:34 # 0
Типы есть везде кроме ыортрана
cyperh 05.12.2014 01:37 # 0
wvxvw 05.12.2014 08:37 # 0
More precisely, it is a set of first-order formulas in a language L with free variables x1, x2,…, xn which are true of a sequence of elements of an L-structure \mathcal{M}
Другой пример.
Допустим, вы хотите дать определение умножению. И вот вы смострите на то, как умножение работает, технически, чтобы понять что это такое. И первое, что вам приходит в голову, это что умножение - это последовательное применение побитового "или", побитового "и" и сдвига влево (так можно реализовать прибавление побитовыми операциями - тот же принцип, что и сложение "в столбик").
Но, естесственно, у такого определения тут же возникают проблемы:
- а что если не известен размер числа?
- а что если нам нужно сделать то же самое, но для рациональных, вещественных, комплексных, векторов, матриц, геометрических трансформаци и т.д.?
- а что если битов у нас вообще нет?
Т.е. определение оказалось, хотя и правильным, но очень частным случаем, которые не передает смысл того, что особенного в прибавлении.
Точно так же и с типами: да, можно найти какое-то соответствие между некоторыми типами и их реализацией в, например, С++. Но, например, если знаковый и беззнаковый чисельные типы в языке отличаются, то в их "реализации" они не отличаются. Но более того, мы можем определить типы, в которых одинаковое количество битов, например, две структуры с двумя полями, где первое поле в первой структуре занимает 2/3 от размера типа, а второе - 1/3, а во второй наоборот - тут вообще ни о какой совместимости речь идти не может. Ну и в конце концов, никто не знает сколько битов в типе List<T>.
cyperh 05.12.2014 09:06 # +1
Как это не известен размер числа и как это нет битов? В компьютере так не бывает.
wvxvw 05.12.2014 09:15 # 0
Как это не известен размер числа? - никто не сообщил, вот и не известен. А вы вообще компьютеры видели, что так уверенно рассуждаете о том, что там бывает, а что нет?
Но вы все равно ничего не поняли, и делаете всю ту же ошибку: типы говорят о другом качестве вещей, нежели сколько битов нужно для их описания в конкретном языке на конкретной архитектуре и т.д. Вы не понимаете разницу между концепцией и ее реализацией.
cyperh 05.12.2014 09:14 # 0
wvxvw 05.12.2014 09:19 # 0
Речь идет не о каком-то процессоре, а о типах. Типы вполне могут оперировать такими понятиями, как "вещественное число", потому что это понятие достаточно хорошо определено для того, чтобы его можно было использовать в контексте типов, и это все, что нужно.
cyperh 05.12.2014 09:24 # +1
wvxvw 05.12.2014 09:33 # 0
Где я говорю, что никем кроме меня? Я что-ли статью эту написал? Я говорю, что вы не понимаете о чем речь. Но есть много людей, которые таки да понимают. Более того, это люди, которые пишут книжки об этом, разрабатывают языки программирования, компиляторы к ним и т.д. Например, Чарч, Мартин-Леф, Хиндли, Милнер, Скотт, Пирс, Кардели, Констейбл и еще куча людей, силами которых типы существуют в програмировании.
Анонимус 05.12.2014 21:39 # +2
>> Где я говорю, что типов нет?
Занавес.
1024-- 05.12.2014 21:55 # 0
Анонимус 05.12.2014 22:01 # 0
Этот товарищ месяц назад доказывал мне что статической типизации не существует. Теперь он утвреждает что и типов нет. Возможно что через три месяца мы узнаем что структуры данных и алгоритмы это тоже глупые выдумки.
wvxvw 05.12.2014 22:26 # 0
kipar 05.12.2014 22:32 # 0
bormand 06.12.2014 08:58 # +1
Можем ли мы проинтерпретировать содержимое ячейки не зная команд, которые будут с ней работать? Нет, можно только ткнуть пальцем в небо. Причем одна команда может работать с этой ячейкой как с флоатом, вторая - как с беззнаковым целым, а третья - вообще как с последовательностью байт.
bormand 06.12.2014 09:07 # 0
cyperh 05.12.2014 23:59 # +1
>> поскольку в машинном коде типов нет
>> Где я говорю, что типов нет?
*fxd
1024-- 05.12.2014 12:26 # 0
Годные примеры. Если говорить о скорости света, можно двигаться быстрее скорости света в некоторой среде. Если не придираться к словам, на практике есть объекты, которые движутся быстрее скорости света. Например, горбик волны или светлое пятно от пикселя на экране. И это ничему не противоречит.
Теория пределов даёт конкретные ответы, учит как делить на "почти ноль" и работает в выдуманном мире. Ничего не мешает (вернее, ничего не помешало) воспользоваться этим в реальном мире и создать float/double с некоторыми допущениями. Да, не учли асимптотику и x/x, x*x/x, x/(x*x) дают NaN. Но поскольку физическая бесконечность встречается крайне редко и скорее сигнализирует об ошибке, мы получили более удобную систему контроля. Хочу - включаю исключение, хочу - проверяю результат, хочу - передаю inifinity/NaN тому, кто это будет обрабатывать.
Математика - царица наук и служанка физики.
wvxvw 05.12.2014 22:31 # 0
На ноль нельзя делить из совсем других соображений - изза определения того, что такое деление.
1024-- 05.12.2014 22:45 # 0
По мне - так всё связано и плавно перетекает из одного в другое. Когда мы говорим, что можем делить на ноль или делим на ноль в вычислениях с double, используем какую-то модель малой величины, но в быту называем её нулём, вызывая бугурты математиков. Я об этом говорил.
1024-- 05.12.2014 09:43 # 0
ложь-истина. Если они не образуют тип, мы говорим о совершенно разных понятиях "тип" и математические типы никак не связаны с типами в ЯП.
> личное мнение
Не совсем личное мнение. Конечно, я привык к типам в ЯП, и это слилось с моим личным мнением, но это как минимум не я напился на празднике и придумал. Это сложившиеся термины, Вы, можно сказать, сами "спорите с определением".
wvxvw 05.12.2014 10:07 # 0
Нет, вы просто не понимаете о чем речь, и пытаетесь убедить кого-то, кто таки да понимает, в своей правоте, которая основана не более чем на ваших личных фантазиях.
Математических типов отдельно от типов в програмировании не существует. Математика описывает типы в програмировании. Математика - это род человеческих знаний, который описывает закономерности. Одна из множества таких закономерностей - типы в програмировании, и поэтому математика может их описать. Конкретно, она их описывает в теории типов.
Вы не "привыкли", вы просто как и другой комментатор не можете понять связь между частным и целым.
cyperh 05.12.2014 10:16 # 0
>Где я говорю, что никем кроме меня?
>Нет, вы просто не понимаете о чем речь, и пытаетесь убедить кого-то, кто таки да понимает, в своей правоте, которая основана не более чем на ваших личных фантазиях.
Опять же повторюсь, вопрос был как раз таки о конкретном представлении информации в памяти, а вы уже ушли к философии и к тому же теперь противоречите себе.
wvxvw 05.12.2014 10:52 # 0
Кто сказал, что вопрос о конкретном представлении информации в памяти (конкретных процессоров / устройств памяти?)? Чего вы тогда решили говорить о типах? Типы тут-то при чем?
Где я противоречу себе?
1024-- 05.12.2014 12:33 # +2
Кроме этого, в программировании используется низкоуровневое определение типа — как заданных размерных и структурных характеристик ячейки памяти, в которую можно поместить некое значение, соответствующее этим характеристикам. Такое определение является частным случаем теоретико-множественного. На практике, с ним связан ряд важных свойств, требующих отдельного рассмотрения[⇨].
P.S. Нет, это не я редактировал Википедию ради цитаты для ГК.
wvxvw 05.12.2014 22:32 # 0
1024-- 05.12.2014 22:41 # 0
wvxvw 05.12.2014 22:57 # −3
Речь изначально шла о типах в программировании, а не о типах данных. Для понимания разницы: массив, это пример типа данных, и, в том же Форте массивы естесственно существуют, никто в этом не сомневается. Но програмных типов там не существует (или, другими словами, там все одного типа). Статическая проверка типов относится к проверке програмных типов, а не к проверке типов данных (их вообще никто не проверяет / это не такая вещь, которую можно осмысленно проверить).
guest6 29.10.2022 23:19 # 0
Сивоконь -- король пиздаболов
Fike 16.07.2014 14:58 # 0
HHVM?
roman-kashitsyn 16.07.2014 15:04 # 0
Vasiliy 17.07.2014 21:07 # 0
TarasB 15.07.2014 21:21 # +11
Но если блин я не могу на сраном ютубе добавить субитры, в которых записана моя скорость движения, из-за того, что при наведении мышки на кнопку "добавить" надо дождаться ответа от сервака, потом отпустить кнопку, потом подождать 5 минут (проц при этом занят на 100% хуй знает чем, потому что на экране никаких изменений) и плюнуть, то мне хочется взять того пидора, что писал этот интерфейс для ютуба, засунуть клавиатуру ему в задницу, которой он елозил по клавиатуре, вместо того, чтобы писать код руками, а потом провернуть, чтобы у него кишки наружу вылезли и весёлые фонтанчии крови брызнули на стены!
kegdan 16.07.2014 06:20 # +2
Vasiliy 18.07.2014 18:36 # −3
inkanus-gray 18.07.2014 18:38 # +3
Диалап не может занять проц на 100% (если, конечно, у пользователя не IE3-IE4).
bormand 18.07.2014 18:39 # +3
TarasB 09.09.2014 20:55 # 0
я не пойму, если число страниц ограничено, то их все можно сгенерировать программкой, написанной на любом языке и сразу все залить на сайт, например, разве не так? зачем все эти цээсэс, пэхэпэ?
inkanus-gray 09.09.2014 22:10 # +1
А пэхэпэ как раз и генерирует страницы на стороне сервера (это ведь программка, написанная на любом языке). Только обычно почему-то пэхэпэ используют как сервер, чтобы он генерировал на лету. А ведь можно сделать так, чтобы пэхэпэ сохранял html-файл на сервере и сервер отдавал клиенту готовый файл, не вызывая пэхэпэ на каждый чих. Буст перфоманса гарантирую!
TarasB 09.09.2014 22:15 # 0
3.14159265 10.09.2014 00:34 # +1
С точки зрения пещерного человека, безусловно.
Реальность же такова, что создание api с сервисами чрезвычайно востребовано в нынешнее время.
Я хочу версию сайта на мобиле, кто-то хочет читалку под андроид, кому-то надо вставить в своё приложение только небольшой сервисок уведомлений ответов мне, кто-то хочет нотифайер стока. Монолитный html этого не обеспечит, а если и обеспечит, то заёбистым путём.
К тому же мелкие jsonы (которые к тому же кешируются) требуют меньше трафика чем цельный html, который надо пересылать заново на каждый чих.
А css обеспечивает великолепное повторное использование кода - можно поменять стиль половины сайта, добавить ховеры, градиент или затухание практически парой строк. Классы стилей придают нагромождению настроек хорошо описанную структуру.
>Генерировать страницы можно заранее, если у них не очень много вореций.
Цельный, статический html и теги font, i, b вместо css - это 90-е веба.
bormand 10.09.2014 05:44 # +1
Хороший пример - отправка коммента на ГК. Тарас, ты и на это жалуешься и хочешь, чтобы форма отправки открывалась в отдельной странице, а потом перезагружался весь тред?
* На компьютерах. Для калькуляторов не гарантируется.
1024-- 10.09.2014 06:38 # +2
А вдруг он действительно на ГК скрипты отключил?
TarasB 10.09.2014 13:40 # +1
roman-kashitsyn 10.09.2014 09:57 # +1
Ими же, собственно, можно настроить стили под разные девайсы.
> статический html и теги font
Ещё небось и тормозня по сравнению с CSS - надо же в каждый тег лезть и лэйаут пересчитывать, да и парсинга html существенно больше.
bormand 10.09.2014 11:35 # +1
ГК застрял в девяностых? :) Ведь <span style="font-size:10px;"> мало чем отличается от <font size=...>...
roman-kashitsyn 10.09.2014 11:44 # +5
Не застрял, а удобно расположился.
3.14159265 10.09.2014 13:09 # 0
Цельный, статический html - 90-е
Генерируемый на пхп-сервере html - 00-е.
[b] -> <b>...</b>
Это ж пользователь по сути вводит. jshighlight/govnokod.css
1024-- 10.09.2014 14:48 # +2
> [i] -> <i>...</i>
Любители CSS, пощадите! Размер страницы увеличился вджвое, универсальность достигла Луны. Открыл страницу за городом, один из сотни стилей не подгрузился - на экране нечитаемая каша.
3.14159265 10.09.2014 14:57 # +1
inkanus-gray 10.09.2014 15:50 # 0
http://codepen.io/anon/pen/opGcL
bormand 10.09.2014 15:18 # +1
Зато базы будут неплохо мерджиться между собой...
inkanus-gray 10.09.2014 15:36 # 0
bormand 10.09.2014 17:54 # 0
inkanus-gray 10.09.2014 18:18 # 0
bormand 10.09.2014 18:24 # 0
inkanus-gray 10.09.2014 15:36 # +2
1024-- 10.09.2014 16:18 # +1
Можно и семантичное говно вместо i:
comment-text semi-sarcasm-4 troll-weight-500
Исход один: http://habrahabr.ru/company/abbyy/blog/173885/
inkanus-gray 10.09.2014 18:17 # 0
inkanus-gray 10.09.2014 18:28 # +1
А в CSS будет примерно так:
Или вообще устанавливать стили через jQuery, если требуются вычисления.
bormand 10.09.2014 18:31 # 0
inkanus-gray 10.09.2014 18:36 # 0
1. Сразу писать в атрибуте data, но это несемантично.
2. Использовать expression(), но это работает только в древних IE, которые не поддерживали HTML5, поэтому будет костыль на костыле.
3. Использовать препроцессоры CSS типа LESS/SASS для вычислений (но я не уверен, что они умеют извлекать атрибуты из HTML).
4. Использовать Жуквери для кроссбраузерности и энтерпрайзности.
P.S. Или так:
bormand 10.09.2014 18:39 # +1
inkanus-gray 10.09.2014 18:45 # +1
bormand 10.09.2014 18:48 # 0
inkanus-gray 10.09.2014 18:57 # +1
inkanus-gray 10.09.2014 19:39 # +1
http://ideone.com/gc1ek0
http://jsfiddle.net/4bw3tcdb/embedded/result/
gost 10.09.2014 20:54 # +1
TarasB 10.09.2014 13:39 # 0
Для сгенерированного хтмл это тоже так.
bormand 10.09.2014 05:40 # 0
Если какой-нибудь varnish настроить и из пыхи правильные хедеры отдавать - так и будет.
wvxvw 10.09.2014 20:57 # +1
Как следствие, вся разработка вокруг ХТМЛ имеет привкус и запах интуиции, народных сказок, суеверий и т.д.
Т.е. отвечая на вопрос "а не лучше ли было сгенерировать ХТМЛ?" - вообще-то нет, скорее всего. Но как лучше - никто не знает. Вполне возможно, что формат вроде ПостСкрипта или Инфо был бы лучше. А может быть принципиально не возможно создать универсальный хороший формат. Даже не понятно, как, концептуально, нужно передавать информацию. Не говоря уже о том, что в большинстве случаев имеет место быть абсолютное нежелание интеграции между форматами. Всякие коммерческие войны, которые делают развитие и исследование еще более сложным.
Вобщем, хорошего в этой жизни, мы практически наверняка не увидим. Наш единственный шанс: создать поколение роботов с искусственным интеллектом качественно лучшим, чем человеческий. А потом лазерами сжечь остки человечества, для верности.
gost 10.09.2014 21:09 # 0
3.14159265 11.09.2014 09:51 # +4
Тут он прав.
3.14159265 22.07.2020 13:09 # 0
> А потом лазерами сжечь остки человечества, для верности.
Тут он тоже прав.
wvxvw вообще был прав во всём.
inkanus-gray 10.09.2014 21:21 # 0
Анонимус 04.12.2014 02:12 # +1
Кстати тоже самое можно сказать и про CSS и про HTTP и про JS и про Web в целом.
1024-- 18.07.2014 19:03 # +1
gost 18.07.2014 20:28 # +1
1024-- 20.07.2014 22:56 # +2
gost 21.07.2014 11:51 # +2
guest 06.12.2014 04:17 # +1
Хватит на селероне 600м сидеть который тебе предки в 2000м году купили
guest 06.12.2014 04:33 # 0
Wuffur 04.12.2014 02:07 # +1
Анонимус 04.12.2014 02:10 # +1
Анонимус 04.12.2014 02:23 # +3
-----
Особенно няшно использовать C++ как шаблонизатор. "Эй верстун, поправь верстку" / "я поправил уже, компилируется"
bormand 04.12.2014 07:39 # +1
bormand 04.12.2014 07:42 # +1
http://govnokod.ru/11549
3oJIoTou_xyu 11.07.2019 16:02 # 0
guest6 29.10.2022 23:17 # 0
Это важно. Однажды меня пригласили в писать серьезное приложение, но я спросил их: "можно ли будет залить на какой-нибудь бесплатный хостин" и услышав отрицательный ответ, решил с ними не связываться
Да-да, ребята! Ваше приложение никогда не выстрелит, если его нельзя залить на какой-нибудь бесплатный хостин