- 1
- 2
- 3
- 4
Я не считаю, что писать сайты на С++ - это бред. По-моему бред - это использовать динамически типизированный скрипт, типа PHP, у которого даже нормального ООП нет.
Я писал на PHP и знаю, как это не удобно. Я считаю, если создать нормальную удобную обертку, то на С++ писать гораздо удобнее.
Самый главный минус С++ в том, что свой сайт я могу держать только на своем собственном сервере, и не могу его залить на какой-нибудь бесплатный хостин,
как в случае с PHP.
Follow us!
Денис Попов, перелогинься )
Я не прафессианальный сайтостроитель с гейдева.
Да почему, можно залить на тот же openshift. Один хер посещаемость этого говносайтца будет чуть менее чем нулевая, и фришный small gear вполне вытянет нагрузку.
Всепопустительства админов плоды беспечные цветут.
***
Таджики трахнули Азула:конча струится,кровь течет.
На помощь прибежал Диаз: теперь не парень - пидорас.
Несчастный модер крикнул: "No-o-o-o!!!!!", но гомосекам все равно.
***
А где админ? А вот и он:
Вот, кто-то в рот его ебет.
Певец в стоячий микрофон - Азам Азизов хуй сосет.
Этим говном сегодня пользоваться нельзя, все тормозит и лагает, а жаль.
Их нет, как и переполнений буфера*.
* если не делать вид, что ты пишешь на си, а не на крестах
P.S. Ну да, возможны утечки как в жабе - бесконечно растущие кеши и т.п. Но они в любом языке возможны (кроме, пожалуй, пыхи, из-за ее любви к рестарту после каждого запроса).
Есть другая проблема - слегка неудобно менять страницы, но это поправимо, если логику засунуть в библиотеки.
Да ну... Остановить старый бинарь, подменить на новый, да запустить. Заодно спасёт от желания править скрипты прямо на боевом сервере.
Если вся эта байда работает через балансер - никто даже и не заметит перебоя в работе.
> если логику засунуть в библиотеки
Имхо, будет менее удобно, чем с монолитным бинарником.
http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModMagnet
http://redmine.lighttpd.net/projects/lighttpd/wiki/AbsoLUAtion
САЙТ НА C++ САМ НЕ НАПИШЕТСЯ
НАПИШИ ЕГО, НАПИШИ ЕГО ЕЩЕ РАЗ
ЗАЧЕМ МНЕ НУЖЕН PHP, У МЕНЯ НЕТ ВРЕМЕНИ ЧТОБЫ ЕБАТЬСЯ С НИМ
ЛУЧШЕ ЕЩЕ РАЗ НАПИСАТЬ САЙТ НА C++
Я ПИШУ САЙТ НА C++ ПО 3 РАЗА В ДЕНЬ
КАЖДОЕ НАПИСАНИЕ ЗАНИМАЕТ ДВАДЦАДЬ МИНУТ
Я ЖИВУ АКТИВНОЙ И ПОЛНОЦЕННОЙ ЖИЗНЬЮ
Я УСПЕШЕН И ПОЭТОМУ ЦЕЛЫЙ ДЕНЬ ИГРАЮ В ИГРЫ
А ПОСЛЕ ЭТОГО ПИШУ САЙТЫ НА C++
ТУПЫЕ ПОХАПЭКОДЕРЫ ОДЕРЖИМЫ НЕДО-ООП
А Я СВОБОДНЫЙ ОТ ЗАДРОТСТВО ЧЕЛОВЕК
СКОЧАТЬ БЕЗПЛАТНО И БЕЗ РЕГИСТРАЦИИ МОКРЫЕ ПИСЕЧКИ
КРЯК УЛЬТИМАТ КЕЙГЕН РАЗБЛОКИРУЙ ВЕНДУ
ЛУЧШЕ Я НАПИШУ САЙТ НА C++
И НАБЛЮЮ НА ВОРНИНГИ, СТАБИЛЬНОСТЬ НЕ НУЖНА
Я НЕ ПИСАЛ САЙТ НА C++ НЕДЕЛЮ
ПОЙДУ НАПИШУ
В C++ ВСЕ ПРОСТО И ПОНЯТНО
ОШИБКА ACCESS VIOLATION 0XC0000005. ЭТО ЖЕ ОЧЕВИДНО КАК ЕЕ РЕШИТЬ
ПРИШЛО ВРЕМЯ ПИСАТЬ САЙТ НА C++
ККОКОКОКОКОКОКО
ПШП ХТМЛ ПИТУХИ
КОКОКОКОКОКОКО
Я нихуя не понял
Есть версия, что это ошибка в слове "всё".
>Бесконечноразрядный компьютер вселенной тик за тиком раскрывает бесконечный ленивый персистентный вектор иммутабельных состояний пространства-времени.
http://govnokod.ru/11978#comment157061
Вижуал Студия
Главная страничка Гугла, насколько мне известно, обслуживается с++-бэкэндом.
Facebook раньше деплоился не в виде php-скрипта, а путём кросс-компиляции в c++ c последующей сборкой бинарника (сейчас не уверен).
У нас на работе есть внутренний fastcgi framework, позволяющий писать веб-бэкэнд на C++ не менее удобно, чем какой-нибудь Play Framework. На нём написана куча разных сервисов.
Чтобы получить хоть какой-нибудь перфоманс, нужно переходить на статическую типизацию. Но всё равно не будет решена главная проблема PHP — смерть процесса после каждого запроса.
>потому что компилятор воспроизводит весь функционал PHP, включая динамическую тупизацию с ненужной питушнёй (обычная переменная, хранящая числовое значение, превращается в объект).
Движкам браузеров это не мешает быть адски шустрыми *. Всё дело в JIT.
Он собирает статистику, если переменная в методе используется только как число, он будет хранить число.
Когда происходит "питушня" VM просто деоптимизирует и начинает интерпретировать код.
* В сравнении с другими динамическими языками
Это всё виртуально - с точки зрения программера. Думаю там запилены пулы и кеши.
На самом деле пыха у fb и vk работает намного лучше чем у многих кресты там жаба или шарп.
$a = "10";
$a *= 2;
Другой пример: в Яве есть т.н. два типа полиморфизма (они же механизмы, которые регулируют диспатч методов): статический и динамический. Статический предполагает определенную оптимизацию еще на стадии компиляции, а динамический будет разруливать применимые типы в рантайме, что по-сути никак не отличается от того же Питона, ж.скрипта и т.п. Если программист не понимает разницу, и, например, пишет код используя восновном интерфейсы, не конкретизируя, то есть большой шанс того, что работать это будет точно так же, как в том же Питоне или ж.скрипте.
> динамический будет разруливать применимые типы в рантайме
Это только invokedynamic разруливает, да и он всего раза в 3-4 медленнее прямого вызова.
Если речь идёт о вызове метода интерфейса, то это по сути вызов функции по указателю, никакого разрешения не нужно. Разница в производительности между вызовами статических методов и полиморфных смехотворна. И уж пистон с его строковым лукапом по иерархии словарей там даже рядом не стоял.
Но опять же, ответ не совсем по теме. Главное, что статическая типизация ортогональна производительности, потому что регулирует когда, а не как интерпретируются типы (при условии, что интерпретатору вообще интересно работать с типами).
Да вот не ортогональна.
Если все типы проверены, а вызовы разрешены на этапе компиляции, то во время выполнения этого делать не придётся, следовательно, программа должна работать быстрее (иногда существенно).
Компилятор, выполнив свою работу, может отнять у значений знание о собственном типе, сократив кол-во требуемой памяти, оптимизировав использование кэша.
Вместо указателей на типы в кэш теперь поместится больше полезной информации.
Если вся работа выполнена в статике, рантайму не придётся отслеживать сложные связи между сущностями и оптимизировать куски заново в связи с изменившейся политикой партии.
Да, рантаймовый оптимизатор иногда может знать больше статического и может оптимизировать более сложные кейсы, частично компенсировав свои недостатки.
Но пока ещё статика и производительность идут бок о бок.
> в В8 схема похожая
Не похожая. В V8 жабоскрипт в рантайме компиляется в практически плюсовые классы, хэш-таблички по возможности заменяются структурами, методы превращаются в нативные функции, которые дёргаются по указателям. Но если кто-то вдруг решит добавить к объекту полей, рантайму придётся менять определение класса и генерить нативный код заново, что является весьма затратной операцией.
А мне казалось, что там какой-то псевдоассемблер.
Brilliant!
Пф, O(n) удовлетворяет только неудачников. Крутые пацаны ровняются на Джеффа Дина и не пользуются алгоритмами хуже O(1/n)
Меняется. Программа на JS динамична и может так себя изменить, что для эффективного её представления потребуется повторная оптимизация.
За бОльшую выразительность и гибкость в процессе выполнения приходится расплачиваться производительностью.
У меня аналогии с обратным индексом в вебе. Когда у нас есть статичный набор документов, можно спокойно построить индекс и выполнять запросы очень быстро. Если набор документов постоянно меняется, возникают проблемы с шардированием и мёржем индексов, слежением за удалёнными документами, необходимость слияния на запросах и вообще куча сложностей. Если сделать всё грамотно, производительность не сильно упадёт, но повозиться придётся, да и запросы бегать будут медленнее, хотя амортизированная сложность алгоритмов будет той же.
Но я уже устал повторять. Это ошибка в определениях: неправильно понято что такое "статическая типизация", ну и дальше ей приписываются магические свойства основаные на очень ограниченых личным опытом наблюдениях. Нет даже никакой корелляции между тем когда проверяются типы и тем как быстро работает програма. Но людям приятно верить в чудеса.
> людям приятно верить в чудеса.
Вы, как всегда, абсолютно правы.
Скорость програмы меряется в атомарных операциях необходимых для ее выполнения, при условии, что мы говорим о компутере Фон Ноймана. Может ли так получиться, что програма со статической типизацией справится хуже с поставленой задачей, чем програма с динамической, или отсутствующей типизацией? - да. Аналогично, верно и то, что програма со статической типизацией может справиться с задачей лучше.
Утверждать, что програмы со статической типизацией быстрее програм с другими видами типизации - это просто демонстрировать отсутствие понимания терминологии. Нет никакой закономерности, в том чтобы первое или второе было исключительно верно. Просто так получилось, что в нашем очень маленьком мире программирования, который и просуществовал-то всего-ничего, было написано несколько компиляторов, которые лучше справлялись с ограниченым спектром задач.
Но этот мир существует, используется и формирует мнения. На крестах пишут люди поумнее тех, кто пишет на жс. Думают и пишут оптимальный код без лапши, красивостей и замыканий замыканий замыканий шестиуровневых лямбд. Слабая динамическая типизация и сахарок привлекают и развращают. Пишут программы реальные люди.
Это, если не говорить о каком-то правильном мире (которого нет, потому такие аргументы никому не нужны) или конкретных проектах (которые есть). Можно на C++ написать интерпретатор внутреннего языка и программа на C++ будет тормозить, но этот случай не подходит под "обычно у нас" и среднюю температуру по палате.
P.S. Непропорционально больно Вы в комметариях бьёте за неточные и интуитивные высказывания.
Почему это не правильно думать, что языки со статической типизацией быстрее языков с другой типизацией? - Потому, что это неправильное понимание причины и следствия, это как думать, что ветер дует потому, что деревья шатаются. Если мы делаем неправильные выводы из ситуации, которую мы наблюдаем сейчас (даже если они не противоречат наблюдениям), мы не будем развиваться в правильном направлении (т.е. мы не будем в состоянии адекватно предсказать результаты наших последующих действий). Если мы так думаем, потому, что нам так "здесь и сейчас" удобнее, вместо того, чтобы думать потому что "этому есть логическое объяснение". Если мы будем продолжать думать догматически, а не формально, то мы придем верным путем к системе требующей эпициклов и т.п. неоправданых сложностей.
> Если мы делаем неправильные выводы из ситуации, которую мы наблюдаем сейчас
Можно и правильные сделать, выражаясь более политкорректно. Скажем, "Вывод: В исследованных 60% проектов статическая быстрее на январь 2020 года", где-то в глубине души осознавая, что всё могло быть наоборот.
А от "здесь и сейчас" мы так просто не оторвёмся. За неправильными выводами стоят большие дяди и их деньги. Увидели, что параметр N позволит получить больше денег - подкрутили N, пока мода не сменилась. В итоге за деньги дядь суетится большая толпа народа. Стоит только почитать посты на хабре о увеличении посещаемости. Здесь и сейчас модно зелёное - значит сделаем зелёный фон, чтобы получить +2 человека. В этом году пользователи жмут на круглые кнопки чаще на 0.00002% - сделаем круглую кнопку.
Всё это позорно, конечно, но сложно игнорировать. Разве что действительно начать строить мощный лазер.
Нет никаких исследований которые это подтверждают. Исследования должны выдвинуть гипотезу, а данные должны ее подтвердить. Тут нет никакой гипотезы вообще. Это даже сформулировать нельзя так, чтобы это можно было подтвердить, или опровергнуть.
Такое предположение можно выдвинуть руководствуясь наблюдением, что регулируя движение, светофоры сопутствуют тому, чтобы водители могли не опасаться неожиданых изменений ситуации и свободнее планировали движение. И можно провести эксперимент в годордких условиях, где на дороге со светофорами автомобили будут всреднем двигаться быстрее.
Естесственно, это предположение - не правильное. Т.как его можно опровергнуть, например, сравнив скорости на междугородней трассе, или на специальном спортивном треке.
Точно так же, проверка типов не является фактором влияющим на скорость програм. Просто мы ее наблюдаем в таких условиях, где ее эффект совпадает с желаемым. Естесственно, программист, который лучше проверяет свой код, скорее всего, при наличии ограниченых ресурсов (времени, знания системы) напишет вцелом лучший код, который, кроме остальных показателей, будет еще и быстрее работать. Но, аналогично ситуации с автогонками, из этого не следует причинно-следственная связь, и возможно, когда в будущем роботы будут управлять автомобилями, светофоры будут не нужны.
Красиво.
> И можно провести эксперимент в годордких условиях, где на дороге со светофорами автомобили будут всреднем двигаться быстрее.
> Естесственно, программист, который лучше проверяет свой код,<...>
> Но, аналогично ситуации с автогонками, <...>
Да.
Да, всё верно. Утверждение работает локально, но может перестать.
один раз при компиляции на машине разработчика, и далее эффективное использование стека, регистров и оптимизаций и, главное, ровно 0 секунд затрат на проверку реальных типов в реалтайме,
либо N раз при каждом исполнении этого блока, каждый раз с потенциально разным результатом, и потому пессимистичным размещением операндов и отсутствием оптимизаций
действительно, никакой разницы вообще
Если бы идиотские утверждения о типизированых програмах были бы правильными, то, поскольку в машинном коде типов нет, любая програма на Ц++ была бы быстрее этой же програмы, но скомпелированой.
И да, перечитай ещё раз. Твоя динамическая программа не может получить тот же машинный результат. Физически. У неё будет иное представление. С кучей дополнительных проверок и именно что убогое размещение данных и в случае интерпретатора - и кода. На то она и динамическая типизация.
Взять любую книжку по теории типов, как правило, автор сначала сваяет в ней свою версию нетипизированого лямбда-исчисления, а потом к нему добавит типов. Как правило, там же будет такое или подобное заявление "добавив типов, мы не расширили выразительности языка, но некоторые выражения теперь стали невозможными"). Например, 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.
Никому даже в голову не прийдет выступать заявлениями о скорости. Еще раз. Скорость измеряется, для компьютера Фон Ноймнана, гарантировано завершающихся програм, в количестве элементарных операций нужных для выполнения поставленой задачи. Присутствие или отсутствие типов в принципе не могут на это повлиять. Типы это способ ограничить возможные выражения языка, и все.
Типы влияют на то, сколько выражений можно построить инструментами языка.
Время проверки типов влияет на то, как скоро программист обнаружит ошибки в своем коде.
Доступность информации о типах компилятору может (но не должна) помочь сгенерировать новую програму (не ту, которую написал программист), которая будет работать быстрее написаной программистом.
Доступность типов компилятору не зависит от этапа, на котором осуществляется проверка типов. Она зависит от выразительности языка которым типы описаны. Т.е. мономорфный язык со статической типизацией будет в худшем положении, чем полиморфный язык с динамической типизацией.
Нет никакой статистики подтверждающей влияние выбраной схемы типизации (или полного отказа от типизации) на скорость работы програм. Более того, у нормальных людей такой вопрос даже не возникает, т.как скорость и корректность програм явления достаточно хорошо изученые, чтобы делать такие предположения.
И для теоретиков на засыпку - сколько тактов реального процессора потребуется затратить в обоих случаях.
Почему у людей без выдающихся аналитических способностей бытует мнение, что динамические языки медленнее?
- Потому, что компиляция, которая будет делать много проверок относительно корректности программы занимает много времени. Для практических задач, иногда можно пожертвовать корректностью в пользу скорости. Выполнить скрипт на Питоне может оказаться гораздо быстрее дождаться загрузки Ява компилятора, сборки и запуска програмы на Яве. Другая сторона медали - отсутствие специфики в проверках (которое позволяет сократить время компиляции) приводит к тому, что какую-то часть этих проверок удобнее оставлять до времени исполнения програмы.
Т.е. в конце концов, програмы тормазаят изза того, что в них есть проверки типов. Именно там они проводят бесполезное время, которое не делает никакого вклада в вычисление результата програмы.
Хм) Размерность операнда самый что ни на есть тип! В x86 есть такие типы как byte, word, итд.
Сама по себе инфорамция о том, сколько битов есть в каком регистре ничего такого интересного нам не дает. Ее можно дополнительно интерпретировать как типы, но:
1. Это будет интерпретация не заложеная в сам язык.
2. Эта интерпретация не будет даже похожей на исходные типы, которые были в програме из которой получился этот машинный код.
Конечно можно интерпретировать byte (или qbyte) как signed или каждый его бит как флажок, ну так и в сях можно точно так же делать с интом. Или в сях тоже нету типов?
Пример типа: b в системе { a -> b, ~a }. Или описаный словами: "тип b в системе правил состоящей из b следует из a, и не a". Т.е. система не должна быть перечислением всех типов, но типы должны не противоречить системе.
Вот тут та же ситуация: почему-то комментаторам кажется, что они точно знают, что такое типы в то время, как говорят о вещах которые к типам прямого отношения не имеют.
Слово "катастрофа" по-разному понимается в разных областях наук. Слово "функция" по-разному понимается в математике и программировании. Более того, его смысл различен даже в отдельных ЯП. Или функторы в Haskell и функторы в C++. Везде используются свои термины.
А Вы приходите со своими математическими типами на ГК словно математик на новостной сайт и просите более никогда не употреблять слово "катастрофа" в отношении "ДТП, Холокост, Титаник и т.д." из-за того, что кто-то использовал это понятное слово в своих корыстных целях (передаём привет компании "Яблоко").
P.S. Если булевы значения в Вашей математике образуют тип, то чем int не его расширенный вариант (либо с трактовкой Анонимуса, либо просто как многозначный boolean)? Если же true|false - не тип, то Ваша математика не имеет практического смысла, а значит будет пылиться на полке до нужных времён.
И вообще, математика - это не наука, но это уже я цепляюсь к словам.
Я говорю не про какие-то специальные "математические типы", а про типы в программировании, которые описываются математической теорией.
Не нужно приплетать сюда разногласия, которые не имеют отношения к теме разговора. Я не говорил про функции и про то, что под этим подразумевается в разных языках.
В "моей" математике? Какие вообще булевые значения? О чем это вообще? Возьмите, блин книжку, да просто хотя бы статью в Википедии и прочитайте, зачем мне высказывать личное мнение о вопросе в котором личных мнений быть не может? А может у вас есть личное мнение о том, как должно работать сложение и умножение? Или личное мнение о скорости света?
Вот, для начала: http://en.wikipedia.org/wiki/Type_(model_theory).
Тип - это абстрактное математическое понятие, такое же, как "множество", или "коммутативность". Програмы на Ассемблере не являются каким-то показателем / предметом в обсуждении того, что такое тип. К ним можно подойти с определенной точки зрения, и охарактеризовать в них что-то как систему типов. Но это не будет значить, что эти програмы выражают, или описывают эти типы. Перепутать эти две вещи, это т.н. use-mention error (в моем дословном переводе: ошибка интерпретации, т.е. ошибка которая возникает когда описание чего-то принимается за само явление, или, наоборот, явление интерпретируется как описание этого явления).
Типы никто не "придумывал", и уж тем более с исторической точки зрения это не правильно. Типы существовали и спокойно себе существуют безотносительно компьютеров, битов и байтов. Более того, человечество вымрет, вместе с компьютерами, а типы останутся.
Где я говорю, что типов нет? Я говорю, что тип - это такое же понятие, как "множество", и даже ссылку дал, где доступно описано, что такое тип. Просто люди, которые используют это слово в этом обсуждении используют его не по назначению, но хотят прийти к выводу, который не в определении этого термина.
Типы есть везде кроме ыортрана
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>.
Как это не известен размер числа и как это нет битов? В компьютере так не бывает.
Как это не известен размер числа? - никто не сообщил, вот и не известен. А вы вообще компьютеры видели, что так уверенно рассуждаете о том, что там бывает, а что нет?
Но вы все равно ничего не поняли, и делаете всю ту же ошибку: типы говорят о другом качестве вещей, нежели сколько битов нужно для их описания в конкретном языке на конкретной архитектуре и т.д. Вы не понимаете разницу между концепцией и ее реализацией.
Речь идет не о каком-то процессоре, а о типах. Типы вполне могут оперировать такими понятиями, как "вещественное число", потому что это понятие достаточно хорошо определено для того, чтобы его можно было использовать в контексте типов, и это все, что нужно.
Где я говорю, что никем кроме меня? Я что-ли статью эту написал? Я говорю, что вы не понимаете о чем речь. Но есть много людей, которые таки да понимают. Более того, это люди, которые пишут книжки об этом, разрабатывают языки программирования, компиляторы к ним и т.д. Например, Чарч, Мартин-Леф, Хиндли, Милнер, Скотт, Пирс, Кардели, Констейбл и еще куча людей, силами которых типы существуют в програмировании.
>> Где я говорю, что типов нет?
Занавес.
Этот товарищ месяц назад доказывал мне что статической типизации не существует. Теперь он утвреждает что и типов нет. Возможно что через три месяца мы узнаем что структуры данных и алгоритмы это тоже глупые выдумки.
Можем ли мы проинтерпретировать содержимое ячейки не зная команд, которые будут с ней работать? Нет, можно только ткнуть пальцем в небо. Причем одна команда может работать с этой ячейкой как с флоатом, вторая - как с беззнаковым целым, а третья - вообще как с последовательностью байт.
>> поскольку в машинном коде типов нет
>> Где я говорю, что типов нет?
*fxd
Годные примеры. Если говорить о скорости света, можно двигаться быстрее скорости света в некоторой среде. Если не придираться к словам, на практике есть объекты, которые движутся быстрее скорости света. Например, горбик волны или светлое пятно от пикселя на экране. И это ничему не противоречит.
Теория пределов даёт конкретные ответы, учит как делить на "почти ноль" и работает в выдуманном мире. Ничего не мешает (вернее, ничего не помешало) воспользоваться этим в реальном мире и создать float/double с некоторыми допущениями. Да, не учли асимптотику и x/x, x*x/x, x/(x*x) дают NaN. Но поскольку физическая бесконечность встречается крайне редко и скорее сигнализирует об ошибке, мы получили более удобную систему контроля. Хочу - включаю исключение, хочу - проверяю результат, хочу - передаю inifinity/NaN тому, кто это будет обрабатывать.
Математика - царица наук и служанка физики.
На ноль нельзя делить из совсем других соображений - изза определения того, что такое деление.
По мне - так всё связано и плавно перетекает из одного в другое. Когда мы говорим, что можем делить на ноль или делим на ноль в вычислениях с double, используем какую-то модель малой величины, но в быту называем её нулём, вызывая бугурты математиков. Я об этом говорил.
ложь-истина. Если они не образуют тип, мы говорим о совершенно разных понятиях "тип" и математические типы никак не связаны с типами в ЯП.
> личное мнение
Не совсем личное мнение. Конечно, я привык к типам в ЯП, и это слилось с моим личным мнением, но это как минимум не я напился на празднике и придумал. Это сложившиеся термины, Вы, можно сказать, сами "спорите с определением".
Нет, вы просто не понимаете о чем речь, и пытаетесь убедить кого-то, кто таки да понимает, в своей правоте, которая основана не более чем на ваших личных фантазиях.
Математических типов отдельно от типов в програмировании не существует. Математика описывает типы в програмировании. Математика - это род человеческих знаний, который описывает закономерности. Одна из множества таких закономерностей - типы в програмировании, и поэтому математика может их описать. Конкретно, она их описывает в теории типов.
Вы не "привыкли", вы просто как и другой комментатор не можете понять связь между частным и целым.
>Где я говорю, что никем кроме меня?
>Нет, вы просто не понимаете о чем речь, и пытаетесь убедить кого-то, кто таки да понимает, в своей правоте, которая основана не более чем на ваших личных фантазиях.
Опять же повторюсь, вопрос был как раз таки о конкретном представлении информации в памяти, а вы уже ушли к философии и к тому же теперь противоречите себе.
Кто сказал, что вопрос о конкретном представлении информации в памяти (конкретных процессоров / устройств памяти?)? Чего вы тогда решили говорить о типах? Типы тут-то при чем?
Где я противоречу себе?
Кроме этого, в программировании используется низкоуровневое определение типа — как заданных размерных и структурных характеристик ячейки памяти, в которую можно поместить некое значение, соответствующее этим характеристикам. Такое определение является частным случаем теоретико-множественного. На практике, с ним связан ряд важных свойств, требующих отдельного рассмотрения[⇨].
P.S. Нет, это не я редактировал Википедию ради цитаты для ГК.
Речь изначально шла о типах в программировании, а не о типах данных. Для понимания разницы: массив, это пример типа данных, и, в том же Форте массивы естесственно существуют, никто в этом не сомневается. Но програмных типов там не существует (или, другими словами, там все одного типа). Статическая проверка типов относится к проверке програмных типов, а не к проверке типов данных (их вообще никто не проверяет / это не такая вещь, которую можно осмысленно проверить).
Сивоконь -- король пиздаболов
HHVM?
Но если блин я не могу на сраном ютубе добавить субитры, в которых записана моя скорость движения, из-за того, что при наведении мышки на кнопку "добавить" надо дождаться ответа от сервака, потом отпустить кнопку, потом подождать 5 минут (проц при этом занят на 100% хуй знает чем, потому что на экране никаких изменений) и плюнуть, то мне хочется взять того пидора, что писал этот интерфейс для ютуба, засунуть клавиатуру ему в задницу, которой он елозил по клавиатуре, вместо того, чтобы писать код руками, а потом провернуть, чтобы у него кишки наружу вылезли и весёлые фонтанчии крови брызнули на стены!
Диалап не может занять проц на 100% (если, конечно, у пользователя не IE3-IE4).
я не пойму, если число страниц ограничено, то их все можно сгенерировать программкой, написанной на любом языке и сразу все залить на сайт, например, разве не так? зачем все эти цээсэс, пэхэпэ?
А пэхэпэ как раз и генерирует страницы на стороне сервера (это ведь программка, написанная на любом языке). Только обычно почему-то пэхэпэ используют как сервер, чтобы он генерировал на лету. А ведь можно сделать так, чтобы пэхэпэ сохранял html-файл на сервере и сервер отдавал клиенту готовый файл, не вызывая пэхэпэ на каждый чих. Буст перфоманса гарантирую!
С точки зрения пещерного человека, безусловно.
Реальность же такова, что создание api с сервисами чрезвычайно востребовано в нынешнее время.
Я хочу версию сайта на мобиле, кто-то хочет читалку под андроид, кому-то надо вставить в своё приложение только небольшой сервисок уведомлений ответов мне, кто-то хочет нотифайер стока. Монолитный html этого не обеспечит, а если и обеспечит, то заёбистым путём.
К тому же мелкие jsonы (которые к тому же кешируются) требуют меньше трафика чем цельный html, который надо пересылать заново на каждый чих.
А css обеспечивает великолепное повторное использование кода - можно поменять стиль половины сайта, добавить ховеры, градиент или затухание практически парой строк. Классы стилей придают нагромождению настроек хорошо описанную структуру.
>Генерировать страницы можно заранее, если у них не очень много вореций.
Цельный, статический html и теги font, i, b вместо css - это 90-е веба.
Хороший пример - отправка коммента на ГК. Тарас, ты и на это жалуешься и хочешь, чтобы форма отправки открывалась в отдельной странице, а потом перезагружался весь тред?
* На компьютерах. Для калькуляторов не гарантируется.
А вдруг он действительно на ГК скрипты отключил?
Ими же, собственно, можно настроить стили под разные девайсы.
> статический html и теги font
Ещё небось и тормозня по сравнению с CSS - надо же в каждый тег лезть и лэйаут пересчитывать, да и парсинга html существенно больше.
ГК застрял в девяностых? :)Ведь <span style="font-size:10px;"> мало чем отличается от <font size=...>...
Не застрял, а удобно расположился.
Цельный, статический html - 90-е
Генерируемый на пхп-сервере html - 00-е.
[b] -> <b>...</b>
Это ж пользователь по сути вводит. jshighlight/govnokod.css
> [i] -> <i>...</i>
Любители CSS, пощадите! Размер страницы увеличился вджвое, универсальность достигла Луны. Открыл страницу за городом, один из сотни стилей не подгрузился - на экране нечитаемая каша.
http://codepen.io/anon/pen/opGcL
Зато базы будут неплохо мерджиться между собой...
Можно и семантичное говно вместо i:
comment-text semi-sarcasm-4 troll-weight-500
Исход один: http://habrahabr.ru/company/abbyy/blog/173885/
А в CSS будет примерно так:
Или вообще устанавливать стили через jQuery, если требуются вычисления.
1. Сразу писать в атрибуте data, но это несемантично.
2. Использовать expression(), но это работает только в древних IE, которые не поддерживали HTML5, поэтому будет костыль на костыле.
3. Использовать препроцессоры CSS типа LESS/SASS для вычислений (но я не уверен, что они умеют извлекать атрибуты из HTML).
4. Использовать Жуквери для кроссбраузерности и энтерпрайзности.
P.S. Или так:
http://ideone.com/gc1ek0
http://jsfiddle.net/4bw3tcdb/embedded/result/
Для сгенерированного хтмл это тоже так.
Если какой-нибудь varnish настроить и из пыхи правильные хедеры отдавать - так и будет.
Как следствие, вся разработка вокруг ХТМЛ имеет привкус и запах интуиции, народных сказок, суеверий и т.д.
Т.е. отвечая на вопрос "а не лучше ли было сгенерировать ХТМЛ?" - вообще-то нет, скорее всего. Но как лучше - никто не знает. Вполне возможно, что формат вроде ПостСкрипта или Инфо был бы лучше. А может быть принципиально не возможно создать универсальный хороший формат. Даже не понятно, как, концептуально, нужно передавать информацию. Не говоря уже о том, что в большинстве случаев имеет место быть абсолютное нежелание интеграции между форматами. Всякие коммерческие войны, которые делают развитие и исследование еще более сложным.
Вобщем, хорошего в этой жизни, мы практически наверняка не увидим. Наш единственный шанс: создать поколение роботов с искусственным интеллектом качественно лучшим, чем человеческий. А потом лазерами сжечь остки человечества, для верности.
Тут он прав.
> А потом лазерами сжечь остки человечества, для верности.
Тут он тоже прав.
wvxvw вообще был прав во всём.
Кстати тоже самое можно сказать и про CSS и про HTTP и про JS и про Web в целом.
Хватит на селероне 600м сидеть который тебе предки в 2000м году купили
-----
Особенно няшно использовать C++ как шаблонизатор. "Эй верстун, поправь верстку" / "я поправил уже, компилируется"
http://govnokod.ru/11549
Это важно. Однажды меня пригласили в писать серьезное приложение, но я спросил их: "можно ли будет залить на какой-нибудь бесплатный хостин" и услышав отрицательный ответ, решил с ними не связываться
Да-да, ребята! Ваше приложение никогда не выстрелит, если его нельзя залить на какой-нибудь бесплатный хостин