- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
_G = setmetatable(_G,{__index = function() return setmetatable({},{__index = _G}) end})
print(allah,_G) --Разные таблы, при этом аллах даже никак не объявлен
anus.n = 10 --Это будет табла и anus.n будет таблой
anus = {n=10} --Это будет хорошо и anus.n будет 10
HUYZOLOTOY.table.insert(anus,10) --Нормас работает
print(anus.opa) --А это не табла а просто nil
for k,v in uier8u43uirhn_________.pairs(_G) do
hjashsnasmm.print(k,v) --А где Allah и все остальное?
end
_G = setmetatable(_G,{__index = function() return setmetatable({},{__index = _G}) end})
Сколько скриптов сломает проверку на nil?
Follow us!
Вот бида...
Я по наивности кастовал структуру к указателю и запихал его в список в другом потоке, проверь.. Когда же я, ничего не подозревая нажал f5, раздалось страшное рычание, я почувствовал возню в правом кармане. Закрыв глаза от ужаса, я приготовился к худшему, но укуса не последовало; лев вдруг замолчал, а делфи выдала ошибку "Internal error! Save your work and restart Delphi", и в ту же минуту всё превратилось в govno: и даже небо, и даже аллах..
Да и раздражает такая хуйня.
Но вообще конечно всё зависит от цели: хотим-ли мы иметь инженера который умеет в алгоритмы и структуры данных, или мы хотим чтобы чувак через пол года уже мог делать сайты на вордпрессе и получать реальный доширак/мивину
> дотнет для гуя самое то
Где то на сисярпе учат, это кому как с пердузом повезёт.
Если бы я записывал лекции, я бы тут много накидал.
Для рукописной лекции вполне нормально.
scanf("%s", &s);
ничотак, безопасненько
Всегда так на продакшене делаю
В одном учат паять, в другом — думать.
и да, у нас тоже были базы данных, целых 2 семестра (курсе на 4), но к дельфи (1 курс) они не имели вообще никакого отношения, и это было, простите, ещё когда борланд был борландом и со своей 7кой был самым актуальным формошлёпством - сейчас же учить детей дельфи под винду это как учить перлу для создания веб-порталов
можно объяснить только тем, что преподы в вузах сидят на жопе ровно десятилетиями и нихуя не развиваются в такой живой области как айти - думают, что можно одно и то же читать всю карьеру, как курс общей физики или матана (с точки зрения вузовской программы там нихуя нового уже последние лет 100)
живо представил себе файл portal.cgi
верните мой 2001-й.
Многие курсы написаны под паскаль и ему до сих пор учат. Сделали его под дот нет (Pascal ABC), и мне кажется что в целом это не так уж страшно, хотя на чем учить лучше всего на самом деле я не знаю: почти все мейнстримные императивные языки -- говно, и для обучения не подходят.
Учить надо языку который:
1) имеет четкую спцификацию
2) не имеет кучи легаси и говна due to historical reasons
3) оперирует максимально приближенными к математике концепциями
Какой язык этим условиям отвечает?
а готовить кого собрался? теоретика в прикладной математике?
у нас была такая одна кафедра на факультете, вместо живых навыков люди учили как решать задачи на машине тьюринга, а также модула-2, симула и кучу других мертвых, но сука, вероятно, красивых и с четкой спецификацией языков (проверять я это, конечно, не буду)
я вообще не понимаю, зачем учить 1 языку, когда надо учить прежде всего подходам и давать прикладные навыки на примере актуальных языков
даже 15 лет назад нам почему-то дали паскаль, дельфи, с++, баш, асм, t-sql, vhdl, js/html, простите, фортран и ещё наверное что-то, что можно назвать языком программирования, причем, задача была не "научить студента языку", а наоборот, показать какой-то практический подход, открыть какое-то прикладное направление в сознании
Сначала надо научить одному языку. Потом надо научить другому языку. И тогда давать прикладные навыки на примере актуальных языков.
язык как синтаксис вообще учится довольно быстро, да и вуз - не то место, где тебе будут такие простые вещи объяснять, или тем более читать курс "%language% для чайников за 15 лекций", вуз не готовит специалиста в языке, он должен дать широту знаний для того, чтобы выпускник смог устроиться на работу джуном и хотя бы понимать что гуглить
по-хорошему, студент, если ему на самом деле интересно, идёт и покупает книжку после первой лекции, и к третьей, как скрипка в оркестре, уже все ноты знает - ему теперь нужен дирижёр, а не как смычок держать
а прикладные навыки - это обычно то, как и называется предмет
паскаль - "алгоритмы и структуры данных",
дельфи - хз, какой-нибудь "основы программирования оконных приложений",
с++ - "ООП, метапрограммирование",
баш и сишка - "операционные системы",
асм - "криптография" и как продолжение курса по схемоте (напишите-ка дрова к своей плате),
t-sql - "базы данных",
vhdl - ещё одно продолжение схемоты + курс про моделирование систем, js/html - "веб"
очевидно же
- особенно после Бьёрна он будет как скрипка
тащемта после первой лекции по крестам я и прикупил в ларьке Подбельского, прочитал целиком за 2 недели, понял, что хуйня, надо что-то посерьезнее, докупил Страуструпа и был охуенно рад
и да, и второй, и даже первый - просто заебись чтиво после огромной, но бестолковой книжки Архангельского по дельфи 7, в которой, по сути, тупо переведен мануал к куче компонентов VCL, но никак не к языку или подходам к разработке
Кстати, Фленов признался мне, что сильно разочарован в Delphi-якобы, будущего у него нет- посоветовал перейти на c#
Хуясе, какая неожиданная мысль! Кто бы мог подумать!
Teach yourself C++ in 10 years
Даже если я собрался готовить хорошего практика, всё равно будет хорошо если он будет понимать связь между математикой и структурами данных.
>>я вообще не понимаю, зачем учить 1 языку,
Ну с чего-то же надо начинать.
Разумеется, надо показать студенту разные языки: один функциональный, один скриптовый, один ассемблер итд, но какой-то язык должен стать первым, тем самым языком на котором ты напишешь свою первую "змейку".
У моего поколения таким языком был паскаль.
Что ты имеешь ввиду по "математикой"? Уравнения матфизики, алгебраическая топология и теория чисел будут показывать разную связь между вычислениями и математическими объектами.
Питон не подходит?
В смысле имеет кучу легаси и говна.
Положим, я хочу вернуть имя и фамилию. Взять мне кортеж? Или дикт? Или именованный кортеж? А может класс?
Хочу получить объект, имеющий определенный интерфейс. Используем утку? Или делаем явный интерфейс? Или взять ABC (AbstractBaseClasses)? Указать в pep-484 тип параметра или не указать? А если передадут не тот объект -- мне его проверять на тип? Делать assert isinstance(..? Или не делать?
Когда мне использовать map(..), а когда list comprehension?
Или может надо явно итерироваться? Как лучше?
Вся эта чепуха не представляет проблемы для опытного программиста, но новичок будет блуждать в дебрях.
C другой стороны такие важные понятия как управление памятью, стек, куча, кол конвеншен итд -- всё это остается за сценой. А этому лучше бы учить сразу.
Председатель собрал колхозниц, и говорит: Бабоньки, к нам едет репортер из центра, будет у вас брать интервью.
Колхозницы: а чо такое интервью?
Председатель: ой, не знаю.. но лучше подмойтесь
Ни в коем. Понадобится добавить отчество - и что тогда?
>дикт
Не в моде. Лучше уж namedtuple.
>assert
Работает только в дебаг моде, ты в курсе?
> Когда мне использовать map(..), а когда list comprehension?
По вкусу. Главное - лямбд сильно много не хуярить. Вообще, сильно не хватает какого-нибудь $_.attribute.
>C другой стороны такие важные понятия как управление памятью, стек, куча, кол конвеншен итд -- всё это остается за сценой. А этому лучше бы учить сразу.
Смотря кого. На непрофильных специальностях это лишнее.
Вы хотели кул стори? Окей, вот вам реальная история.
Вася взял дельфи, а Петя взял C++. У Пети получилось говно.
Отсюда мы делаем вывод что С++ говно.
> большую стоимость
Для мелкой конвейерной хуйни - да, пожалуй. Но не каждый проект можно запинать толпой джуниоров.
Для всякой бухгалтерской опердени и прочих формочек-с-базой — очень маловероятно, разве что какое-нибудь жуткое легаси на крестобилдере.
Всякие тяжелые графические и видеоредакторы по-любому до сих пор на крестах.
А вот те же браузеры относятся к гуйне на цпп? Вроде и гуйня и на цпп, но сами мордочки давным-давно на жс и кресты напрямую с юзером там не взаимодействуют…
Ну это выглядит как искуственное ограничение. Если бы sun oracle этим рынком заинтересовался и пробил все нужные сертификаты, то по-любому и на джаве можно было бы.
З.Ы. Кстати, а ведь хорошая тема для распила — импортозаместить JVM.
но что-то воз и поныне там
не знаю с чем связано, возможно, с тем, что в JVM (например, openjdk) плохо изолируются потоки исполнения, и поэтому невозможно пройти требования по разграничению доступа (хз просто предположил), или ещё какие-то проблемы, да и в целом очень много LoC
1) нахуй трехзвенку, давайте пердолить двузвенку, ведь во-первых это красиво
2) нахуй ORM, давайте писать sql запросы прямо в коде
3) нахуй model-repository-service, я лучше сделаю ещё один Form1.Button1.Click, который заполнит мне грид
4) нахуй AOP, IoC/DI и другие непонятные аббревиатуры, это всё для хипстеров и мудаков
и самое главное - нахуй это нужно?
кого готовит твоё ПТУ?
кому в 2018 нужны толстые шакальные win32-only приложения, способные работать только в ЛВС и от силы на 50 одновременных пользователей?
4 года потратить на то, чтобы прийти на работу и услышать "больше никогда так не делай"?
> 4) нахуй AOP, DI
Хм, не вижу подвоха... IoC действительно полезен, DI в топку
по-моему, классический вопрос на собеседовании - зачем нужен ORM и какие можете назвать плюсы и минусы, впрочем, как и по 4
т.к. у тебя есть очевидный ответ, то хотелось бы услышать какие минусы перевесили плюсы)
не включая ответ "просто в крестах это хорошо сделать нельзя"
ORM вполне себе приемлем как инструмент прототипирования, но в любом интересном проекте тебе потребуется много ДБ-специфики, и переехать на другую хранилку просто так не получится, тогда зачем создавать себе проблемы с лишними прослойками, которые умело создают проблемы производительности (вроде N+1 запрос с ленивой загрузкой и т.п.)?
который, замечу, всё ещё будет существенно меньшим, и, главное, заведомо исправимым пиздецом, чем весь проект написать на инжектах sql запросов и потом никогда-никогда-никогда больше его не поддерживать
у меня к ORM другие претензии - например, производительность всегда будет хуже, чем написать конкретные джойны, или тем более апсерты или рекурсивные запросы - ну, банально, из-за того, что оптимизаторы там ну прямо-таки не блещут погружением в особенности СУБД, но когда в схеме будет 150+ таблиц, большинство операций - тупой CRUD, а основные косяки производительности всё равно исправлять на стороне БД, одинаково и НЕЗАВИСИМО от того, использует бек орм или нет - тогда зачем кипятить?
>> создают проблемы производительности
Как же они у тебя другие? N+1 это просто так, для примера.
> если его не научиться держать правильно
ОРМ умело маскирует то, что происходит на самом деле, поэтому даже спец легко может на код ревью пропустить косяк.
> всё равно исправлять на стороне БД
А что если я хочу использовать классные фичи моей БД: кастомные типы данных, расширенные манипуляции с массивами, hstore и прочий доступ к полям json-a?
> написать на инжектах sql запросов
Нет, этого не надо, надо просто спроектировать нормальный слой доступа к данным, чтобы все запросы были в одном месте. Это прекрасно можно сделать без всяких ОРМ.
всё это приводит к зашкаливанию энтропии и к тому, что чтобы сделать/исправить какую-то фичу в будущем, тебе придется привлекать двух сеньоров вместо одного
сродни тому, как в 20 лет назад было модно половину логики проекта вынести в хранимые процедуры и нахуячить сотню пакетов в оракле, тупо потому что можем
я и сам иногда в этот содомский грех погружался, в реальности же совсем несложно сдерживать плоть
> спец легко может на код ревью пропустить косяк
профилирование тормозов покажет кто где срал
проблемы известной ORM давно известны, бек-обезьянка привыкает делать сразу нормально, или хотя бы предсказуемо
> Как же они у тебя другие
ну вот так
как ты писал выше
>> в любом интересном проекте
проектов, где надо выжимать последний 1% перформанса за +100% трудокостов - крайне немного, и, собственно, если бы потребовалось, я бы 7 раз подумал, чтобы брать в него именно постгрес (к вопросу о массивах hstore json и вот этому всему), большинство же других проектов - за приемлемые сроки получить приемлемый результат, и, кстати, предоставить выбор всё же, какую СУБД брать при разворачивании (особенно бесят криворукие пиздопроёбища, которые ничего кроме mysql и не способны, и тащить на сервер mysql - это пиздец)
тем более, что обычно описывая модель для ORM, ты заодно получаешь 2в1 - информационную модель для обмена с клиентами - т.к. именно эта срань и будет потом (де)сериализоваться как есть, при необходимости изменения в модель вносятся один раз в одном месте (а при code first - вообще один, но это отдельный диагноз)
Ну, начинается: я видел как погромисты плохо использовали $TECHNOLOGY_NAME, и теперь у меня с ним бэд экспириенс.
Я такое слышал про всё, включая джаву (джаватормозит), линукс (надопердолиться) и даже version control.
У меня не было проблем со спрингом: в Idea есть find usage, иконка около класса и даже дебагер.
Зато у меня были проблемы с парашей типа
А так же с ручной реализацей синглтона в каждом классе где он нужен, с ручным управлением скопом (когда один инстанс на реквест итд).
>>потребуется много ДБ-специфики
Закон Парето учит нас что в 80% случаев не понадобится.
А в 20% понадобится. И конечно нужно уметь выкинуть ORMный запрос и написать свой. Повторюсь: даже Django ORM умеет RAW SQL для этого.
>>, и переехать на другую хранилку просто так не получится
ORM используют для type safety и отсутствия бойлерплейта для маппинга в объекты. Понятно что ничего сложнее гостевой книги в принципе не может быть "database agnostic".
>>проблемы с лишними прослойками
Чем выше уровень -- тем проще обычно решить проблему, конечно если можно при необходимости спуститься ниже.
Ты же используешь выскоуровневые абстракции которые дает тебе STL или Boost, не трогая напрямую API операционки, но при необходимости можно хоть на асме написать. Так же и тут.
>>(вроде N+1 запрос с ленивой загрузкой и т.п.)?
Тут виноват не ORM, в бравые питушки которые притворяются что СУБД нет, и встраивают чудесные запросы прямо в код (причем иногда где-то на уровне view).
И начинается:
(псевдокод)
В итоге на каждую запись у нас вызывается три запроса.
Это решается нормальным data layer, который затем профилируется, и конечно логированием long queries.
К счастью, это не правда.
>> используют "MySQL"
К счастью, это не правда.
Ну вот у нас в проекте ручной DI (т.е. всё с интерфейсами как положено, объекты узнают друг о друге только через параметры, но граф запиливается вручную в main). Брат жив. Может быть Роман такую схему имел в виду?
> Может быть Роман такую схему имел в виду?
Именно. Я же белым по белому написал:
IoC действительно полезен, DI в топку, имея ввиду DI, выполняемый фреймворком. Передаём зависимости в конструкторы руками, брат жив.
>Закон Парето учит нас что в 80% случаев не понадобится.
>А в 20% понадобится. И конечно нужно уметь выкинуть ORMный запрос и написать свой. Повторюсь: даже Django ORM умеет RAW SQL для этого.
+100500 за принцип Парето. Вся хуета делается для 80%. Для 1% делается линупс.
https://www.theserverside.com/discussions/thread/23358.html
В энтерпрайзе бывают сотни сервисов, довольно глупо писать в каждом lookup для всех депенденсов.
DI это не обязательно портянка XML (хотя с Idea и с ней справится легко, за Emacs не скажу). Бывают DI без XML (см guice).
1) Под OR/M скрываются два понятия:
a) маппинг результатов запроса в объкты
2) генерация запросов.
Некоторые ORMы выполняют только a: например mybatis.
Некоторые (например Hibernate) всё.
Не очень понятно какой из низ ты не любишь. Всё в том же интерпрайзе сущесвует нереальное количество сущностей: писать для каждой тупой CRUD можно заебаться.
Разумеется, не всё можно покрыть ORMом: и тогда надо брать raw SQL и писать на базазависимом языке. Даже Django ORM это позволяет.
AOP удобен для логирования и проверки пермишеннов.
Те же декораторы в питоне (и их аналог в груви, не помню как называется) позволяют декларативно делать так:
@Require(group=pithhoks)
getPitushok() {}
Очевидно это лучше чем в каждой функции вручную проверять пермишен.
getPitushok() {}
> Очевидно это лучше чем в каждой функции вручную проверять пермишен.
Это принципильно отличается от кода без всякого AOP, угу Ты можешь мне всё это не рассказывать, я на жабе писал долго и много, большая часть "хороших практик" и "кошерного ООП" -- это банальный карго-культ.
Тарас был прав, с самого начала.
Разумеется, потому что в AOP ты можешь не вызвать функцию, вызвать другую функцию или изменить аргументы.
В твоем примере ты можешь только кинуть эксепшен. Посмотри на нормальное использование AOP прежде, чем хаять.
>>большая часть "хороших практик" и "кошерного ООП" -- это банальный карго-культ.
ООП не имеет отношения к AOP, но с такими рассуждениями лучше сразу сказать "джаваговно" и не углубляться в детали.
Вы мне тут все давеча доказывали что си не нужен, ну вот теперь настала пора узнать что не нужна джава, ок.
>>Тарас был прав, с самого начала.
Я не очень в курсе что он говорил. Что надо писать одинаковые CRUDы руками и не использовать ORM?
Я лет пять назад рассказывал людям лекции, как охуенно АОП и какие у него невпупенные применения.
Сейчас я считаю, что оно нахер не нужно.
> вот теперь настала пора узнать что не нужна джава
У джавы есть отличные качества, ни одно из которых не связано с ООП или АОП.
> AOP
В скольких проектах ты успешно применил какой-нибудь Aspect4J, только честно?
2, 3) так и делаем :)
4) а чоита? Ы-ы
> кого готовит твоё ПТУ
"востребованных специалистов"
> прийти на работу
Вряд ли кто-то возьмёт такого на работу, поэтому я в основном сам себя стараюсь образовывать.
хотя на самом деле я рад, что наконец-то среднее профессиональное образование помалу возвращает потерянное в 90х, когда образовался жуткий перекос в сторону вузов
А 4 года для ПТУ слишком дохуя.
если это Прикладная математика, то ясен хуй, должно быть много математики и численных методов
т.к. я, например, Инженер, то кроме общего матана (по 2 предмета х первые 4 семестра, но это специфика нашего вуза, скорее), "специальная" математика была не в тягость - учили арифметике и оптимизациям в куче систем счисления (т.к. потом и проц проектировали на fpga), дискретка немного совсем, ну и тервер, криптография, реляционная алгебра - тоже в какой-то мере математика
Перевеса матана не наблюдается.
ЗЫ. Почему то преподы между собой не договаривались, и мы некотырые вещи проходили несколько раз по разным предметам, например: системы счисления мы проходили по информационным системам, архитектуре, и по системному программированию.
Дельфя была у знакомого ещё в школьные годы в модном лицее (когда обычные школьники наблюдали турбосиний экран), там было формошлёпство, но это не образование же.
Блеее.... Тормозной нотепад на жаве, тормозит как эклипс, а функционала как у нотепада++
А без большой IDE это прям невозможно.
ЗЫ. почти всегда
Мне просто удобно всё из одного редактора делать.
VisualStudio, FlashDevelop, Delphi. Кстати, чому Geany не нормальная IDE?
Пишешь
Пару пассов - и у тебя есть сгенерированный каркас. Не понравились имена? Всё мигом переименовывается. Если бы это в питоне работало. pyшkripter - не ide, а нечто среднее между ide и npp. Функций рефакторинга там ровно 0.
У нас в школе был ПоцкальАБВГД, а вот в колледже сперва ТубоПескарь, а потом делфи.
Так это и не вуз
Может, брал указатель на структуру?
ЗЫ. Тыж дельфист, говори "запись" :)
Структуры в делфях, очевидно, имеют счётчик ссылок, кроме того идёт неявные разыменование и распределение памяти. Память строковых полей никогда не находится в пределах структуры (если это не array of char фиксированного размера), во всех остальных случаях это всего-навсего указатели на блоки в куче.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366920(v=vs.85).aspx
ZeroMemory macro
Обычные table.insert и table.remove рассматривают таблу как массив, и если вызывать их с головы состава (чтобы делать очередь а не стек) то огромные массивы данных будут двигаться туда-сюда, и именно потому они пишут что slow?
А размер таблы-массива (оператор #) у нас явно хранится или считается каждый раз? Он O(1) или O(N)? Я в сорцы не сомтрел пока, но логично бы конечно его явно хранить, а с другой стороны почему тогда разреженные таблицы с дырами в середине работают так, что # возвращает размер первого участка без дыр (но nil)?
PIL предлагает превратить таблу из массива в ассоц.массив (aka hash, map, dict) чтобы ничего никуда не двигалось и заfirst и last следить вручную?
Но hash ведь внутри наверняка какое-нить дерево (какое, кстати?) получается что вставочка у нас будет O(log N)?
Так ведь и поиск будет не за O(1) как в массиве а тоже за log.
#алгоритмы-и-структуры-данных-для-старшего-школьного-возраста-с-lua
Да огромные массивы, если сортировать, удалять, исёртить в какое то место не в конце, будут медлеными.
Оператор # это вообще функция получения длины, и явно нигде не храниться.
PIL лучше знает. Но я считаю что хеш или массив в луа эквивалентны по скорости работы, по этому что ты просто в массиве сделаешь дырку, что хеш нилом обзовеш. Тут именно скорость в стандартных функциях, а именно в sort, insert, remove, так как они массив двигают.
Отслеживать либо next либо pairs. Помниться еще есть фича с table.concat, так как оно может собрать всю хуйню в месте.