- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
#include<iostream>
void suka( void(*callback)( void(*)( void(*)() ) ) ) {
std::cout << "Suka, ";
callback( suka );
}
void blyad( void(*callback)( void(*)( void(*)() ) ) ) {
std::cout << "Blyad !!!" << std::endl;
callback( blyad );
}
int main() {
suka( blyad );
return 0;
}
Follow us!
Вспомнить виндовые тайпдефы с префиксом LP
Вот с "тайпдефами", но в хаски:
Пока статический питушок вычисляет тип и задействует математику, у динамического питушка всё работает, и он рвётся к более продвинутым абстракциям.
Но ты очень точно описал суть
Уважаемый User@8172631, на вашем счету осталось null nullблей. Рекомендуем вам
Кстати, нулизацию можно проверять статические. У Intellij есть аннотации nullable/notnull, а в котлине этовообще разные типы.
Это тебе сильно поможет, когда ты напишешь "на вашем счету осталось " + amount;
У царя было три сына, у трёх сыновей - по 0..3 сына, а у них - по 0..3 сына и так далее.
Картина из реального мира, которую заказчик требует описать в программе. Статический питушок уже сломался, а динамический - построил дерево на ссылках.
auto o = static_perdolieren<game_of_life<42>>(x<1 0> + 1);
Ха-ха. Динамический питушок не обязан всегда использовать произвольное число аргументов, а делая это, осознает все последствия.
> Динамический питушок порой не может даже потребовать определенное количество передаваемых аргументов, что обязывает его пердолиться с проверками количества аргументов и их типов постоянно.
Статический питушок порой не может даже потребовать нужный домен, что обязывает его пердолиться с проверками значений аргументов постоянно и иногда - их типов.
Вот мы и вся суть статического питушка. Как динамика - так грешно, как покажешь void*, так "мы не такие", а в коде всё равно Object и джвойная диспетчеризация. Как статика - так "смотри документацию, соблюдай контракты", как динамика - так "проверяй типы и значения".
А ну-ка, продемонстрируй мне это на твоем любимом JS. Только без пердолинга в духе иф-аргументс-сайз-хуяйз-кукарек.
Остальной твой высер - обычное кудахтанье, не имеющее ничего общего с реальностью. Въебал минус.
> А ну-ка, продемонстрируй мне это на твоем любимом JS. Только без пердолинга в духе иф-аргументс-сайз-хуяйз-кукарек.
> Остальной твой высер - обычное кудахтанье, не имеющее ничего общего с реальностью.
Зачем бугуртить, если не понял? Непонятный термин можно было и погуглить.
OK, вот на первый раз: https://ru.wikipedia.org/wiki/Контрактное_программирование
Динамический питушок: весь контракт заэнфорсить не получается, да и хуй с ним, сам глазками всё буду проверять.
assert и throw как бы намекают, что всё равно придётся пердолиться в рантайме (if+throw ничем не лучше if+arguments.length+throw).
В распространённых статически типизированных языках нельзя сузить диапазон входных значений функции, из-за чего приходится обмазываться assert'ами, но также нельзя расширить диапазон входных значений, из-за чего приходится обмазываться шаблонами.
В тех же распространнёных крестах диапазоны типов можно сузить метушнёй. Да, останется рантайм проверка при касте из большего диапазона в меньший (она тут неизбежна). Но случайно просунуть в функцию значение, нарушающее контракт, ты уже не сможешь (фейл будет ещё до вызова).
Побочные эффекты тоже хрен сузишь (ну может быть, в C++ можно попробовать). Всё равно мануалы курить придётся до посинения. Хотя, в IDE статический питух лучше подсвечивается - это да, удобно.
Т.е. тебя совсем не напрягает, что пердолинга в рантайме получается больше? Что чем раньше будет выявлена ошибка, тем дешевле будет её фикс? Что без 100%(!) покрытия строк юнит-тестами в динамике нельзя даже банальные опечатки отловить?
Напрягает. Конечно, часто удобно удостовериться в том, что ошибок определённого рода нет.
Я не против статических проверок, и C++ мне нравится.
> Что без 100%(!) покрытия строк юнит-тестами в динамике нельзя даже банальные опечатки отловить?
Справедливо для практически всех языков и программ. Фигурную скобку не там поставил - и всё.
Овер 90% ошибок - всякого рода опечатки. Разница лишь в том, поймаешь ты их до или после запуска программы
Ок.
Расскажите уже Штульману про контрактное программирование, а то человек даже в статически типизированных языках на каждом сложении проверяет, что сумма операндов не приведёт к переполнению.
1023 прочитал про свое кококонтрактное программирование, возвел идею в абсолют, и решил, что сигнатуры вообще нинужны. Пусть переходит на баш, там вообще ни сигнатур, ни типов, прям контрактный рай
Я не пойму, Stallman слишком молод, ничего не знает и считает себя королём мира, слишком стар, что для экономии мышлит шаблонами 70х годов (когда ему было 20 лет), либо просто тролль.
Такое ощущение, что ему кто-то сказал, что JavaScript плохой и динамическая типизация - тоже плохая, вот он теперь ходит и всем это повторяет. И не имеет возможности анализировать ситуацию, всё динамическое стало угольно чёрным, а всё статическое - белым и пушистым.
Программирование - это не только искусство, но и наука. Тут думать надо и оценивать плюсы и минусы, а не кукарекать, что JS говно.
Просто раньше люди не умели сделать ее красивой. Не было вывода типов. Не было нормальных генериков/шаблонов, не было сахара для делегирования (чтобы делать адаптеры) и статическая типизация ассоциировалась у людей с тоннами унылого бойлерплейтового кода, который, к тому же, древние IDE не умели генерировать (его писали руками).
Кто видел Java 4 -- тот поймет.
Потому-то людям так нравились языки без статической типизации, а особенно когда им надо было написать что-то не очень больше.
Но современная стат типизация уже не так плоха, и потому ее по-тихоньку завозят в языки. Это pep-484 у питона, это пропозалы у JS (https://github.com/sirisian/ecmascript-types) и языки типа TypeScript, которые в JS компиляца.
Кстати, динамическая типизация вовсе не означает отсутствие статической: например в java или c# типы проверяются и в рантайме, и в момент компиляции.
JavaScript (в его нынешенем варианте) я, как и Stallman, считаю неудачным языком. У него убогая стандартная библиотека, его синтаксис непривычен для большинства программистов, нет нативных средств описания зависимостей и модулей, его прототипориентированность никому не нужна на самом деле: все эмулируют через нее обычное ООП (с костылями).
Наконец тот факт что люди пишут языки, которые компилирются в javascript, говорит о том что большинство программистов JS не любят.
Однако в JS 2015 внезапно ВСЕ стало сильно лучше. К сожалению без babel оно пока не везде работает, но в целом это говорит о том, что люди признали что у JS есть проблемы, и стали их исправлять.
Когда? В млях все было.
> динамическая типизация вовсе не означает отсутствие статической
Во-первых, означает. Во-вторых, это как раз статическая типизация позволяет сделать динамику только там, где надо.
а в жабах не было, например.
С функциональными ЯПами всё понятно: они опередили свое время на пол века, в них были вещи которые в мейнстримовых императивных появились только в нулевых:)
>>Во-первых, означает.
конечно же нет. Я даже пример привел.
>Во-вторых, это как раз статическая типизация позволяет сделать динамику только там, где надо.
Не понял фразы. ЯП со статической типизацией может вообще ничего в рантайме не проверять. Си, например.
Stallman в последние дни только хейтит JS и переносит свои мысли об этом языке на программистов.
Вот если бы были хорошие инструменты клонирования свойств и создания пустых объектов, ПП в JS было бы интереснее. Джвух фич (неявное прокидывание this в функцию и Function.prototype.setPrototype), как мне кажется, хватит для того, чтобы покрыть нужду в ООП.
А возможность унаследовать только поведение бесценна. Можно, например, унаследовать квадрат от прямоугольника, и квадрат не будет хранить лишние поля.
А тот факт, что страус сделал кресты, говорит о том, что он ненавидел няшную до посинения.
А схему стали делать, потому что от старинного лиспа их аж трясло.
А вирта так достал этот сраный алгол, что он оттуда только самое лучшее взял, потому что бесит реально.
Зато когда это нужно будет рефакторить то IDE пойдет вжопу, равно как и все другие питушки, потому что без запуска кода никто ничо не поймет
Благодарим за пользование нашим сервисом.
Всего хорошего, идите нахуй.
В копилку об ideone. На стаковерфлоу выразили мнение, что портянка кода перед передачей в гцц препроцессится какой-то НЁХ на джсе, который интерпретирует "0" по-своему. Ideone пока молчат.
[b]0[/b]
Наверняка ideone писали пэхапэшники и проверяли пустоту выхлопа функцией empty.
А теперь задание: придумать несколько способов вставки в комментарий жирного нолика.
govnokod.ru/23449#comment392370
— i
— b
— u
— s
— blink
— size
— color
— code
Результат: только code считает одинокий нолик непустой строкой.
Единственное, что у меня вызывало опасения, это CSS. Нет ничего более беспомощного, безответственного и испорченного, чем CSS-зомби. Я знал, что рано или поздно мы перейдём и на эту дрянь.
Можешь написать консольный браузер, который будет b рисовать жирным, а strong, например, капсом, стандарт ты соблюдёшь. Если b нарисуешь не жирным, а как-то иначе -- нарушишь.
В вебе многое -- единицы изменерия, терминология, принципы, волочется по наследству ещё из старинной типографики и верстки книг.
В нулевые была сильная увлеченность семантической версткой, и за b и i били по рукам.
Затем пришли сеточки, и всем стало похуй на семантику. Современная верстка напоминает табличную, и верстуны влегкую хуярят туда i и b. Причем i иногда вообще юзают не по на значению.
Веб попытался чуть-чуть побыть не говном, но потом он вспомнил что он всё таки веб и вернулся, так сказать, к дерьмоистокам
https://ideone.com/fSytdu
В "PHP" такой проблемы нет.
https://ideone.com/Wp73wt
https://ideone.com/wUUroF
https://ideone.com/2SxbDg
Я просто оставлю это здесь.
Так вот ты какой -- современный промышленный язык программирования
Удалось скомпилировать:
Кто придумает более короткий пример замыкания с шаблоном?
примитивы -- нет
а вот в C# примитивы это вроде бы value types (кажется). Ну, методы у них есть