Еще на тему
Один мой преподаватель говорил по этому поводу такую штуку: "Неважно какой язык. Важно понимание принципов. А разобраться в синтаксисе - дело недели-двух."
+++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++.+++++++++++++++++
++++++++++++.+++++++..+++.-------------------
---------------------------------------------
---------------.+++++++++++++++++++++++++++++
++++++++++++++++++++++++++.++++++++++++++++++
++++++.+++.------.--------.------------------
---------------------------------------------
----.-----------------------.
+++++++++++++++++++++++++++.+++++++++++++++++
++++++++++++.+++++++..+++.-------------------
---------------------------------------------
---------------.+++++++++++++++++++++++++++++
++++++++++++++++++++++++++.++++++++++++++++++
++++++.+++.------.--------.------------------
---------------------------------------------
----.-----------------------.
На плюсах пишешь, похвально.
Ну здорово, коль не шутишь.
Brainfuck
Hello World!
Ну что за показушное сидение на подоконнике без прыжка вниз?
int main(int argc, char*argv[]) {
switch (argc) {
case 0: return 0;
case 1:
printf("goodbye, world!\n");
default:
printf("%s\n", argv[1]);
}
}
int main(int argc, char*argv[]) {
switch (argc) {
case 0: return 0;
case 1:
printf("goodbye, world!\n");
default:
printf("%s\n", argv[1]);
}
}
Ага, щаз. У тебя код нерабочий.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++.-----------.
-----------------------------------------.+++++++++
++++++++++++++++++++++++++++++++
+++++++.-------.-----.+++++++++++.+++.
-----------------------------------------.+++++++++
++++++++++++++++++++++++++++++++
+++++++.-------.-----.+++++++++++.+++.
Синтаксис то хуйня, и за один вечер можно. А вот подобрать и разобрать нужные библиотеки и фрейворки - дохуя времени.
Ну зато не приходится врать что за месяц сделаем. Дохуя и все тут
Универсальная таблица оценки задач
изян - 1ч
изи - 2ч
просто - 4ч
вроде просто - 6ч
норм - 8ч
норм так - 12ч
хз - 16ч
хз как-то - 20ч
как-то сложно - 24ч
сложно - 30ч
очень сложно - 40ч
бля - 48ч
пиздец - 60ч
пиздец какой-то - 80ч
вроде изян - 100ч
Дохуя - ∞
изян - 1ч
изи - 2ч
просто - 4ч
вроде просто - 6ч
норм - 8ч
норм так - 12ч
хз - 16ч
хз как-то - 20ч
как-то сложно - 24ч
сложно - 30ч
очень сложно - 40ч
бля - 48ч
пиздец - 60ч
пиздец какой-то - 80ч
вроде изян - 100ч
Дохуя - ∞
учу Ларавел, до этого долго упарывался в Yii.
И таки язык должен быть современным. Выбор турбо паскаля будет крайне странным.
зависит от проекта.
может надо на древний комп что-то написать. и заменить его на что-то современное не получится
может надо на древний комп что-то написать. и заменить его на что-то современное не получится
Такое проектом не назовешь. Шабашка какая-то.
Как нам препод говорил, на Fortran написано очень много качественных библиотек. Именно поэтому он ещё используется.
Турбопаскаль - не язык, а среда.
Паскаль как язык вполне норм. Особенно весело получается, когда его годами хоронят, а потом в новом стандарте С++ появляются фичи, которые были в паскале с самого начала.
Паскаль как язык вполне норм. Особенно весело получается, когда его годами хоронят, а потом в новом стандарте С++ появляются фичи, которые были в паскале с самого начала.
Ну хз... Если человек раньше кодил на какой-нибудь Java или C#, а потом садится за JavaScript, то он вынесет себе голову всеми странностями.
Все таки языки должны быть +- в одной категории.
Все таки языки должны быть +- в одной категории.
ты преувеличиваешь странность js. Единственное в чистом, что вызывает затруднения с освоением - это замыкания. Все остальные странные штуки идут из фреймворков, и как правило они не такие уж и странные
ненене, замыкания фигня
а вот йобаная асинхронность там где её не ждешь после привычных языков - это уже приз-сюрприз
мне как-то начальник (бывший, да) сказал "нутыж жабист! не ну а чё там. жаба... жабаскрипт, одно и то же ведь. иди на js проект!"
так и начался 2х-недельный фестиваль, со мной в роли скворечника. nodejs 6 crash cource блджад, без async/await.
код то я написал, и он даже работал, но скорее всего опытного js-ника удар хватит когда он это увидит.
а вот йобаная асинхронность там где её не ждешь после привычных языков - это уже приз-сюрприз
мне как-то начальник (бывший, да) сказал "нутыж жабист! не ну а чё там. жаба... жабаскрипт, одно и то же ведь. иди на js проект!"
так и начался 2х-недельный фестиваль, со мной в роли скворечника. nodejs 6 crash cource блджад, без async/await.
код то я написал, и он даже работал, но скорее всего опытного js-ника удар хватит когда он это увидит.
Так тут дело не js, а в node. Язык - непричем...
асинхронность в принципе тема специфическая, и общая для всего программирования. На мой взгляд, она не особо отличается от асинхронности в какой-нибудь жабе, без учета того, что в жабе ее часто спихивают на фреймворк и блаженно забывают
Ну вот те же мысли.
Какой-нибудь Observable ведет себя примерно одинаково в любых языках. И таки да, это вроде везде либа. Могу, конечно, ошибаться, ибо всех имплементаций во всех языках не видел, но базовое понимание этой штуки дает умение работать с ним везде.
Ну или банальные future. Один раз понял, что оно за хуйня, и везде пользуешься.
Какой-нибудь Observable ведет себя примерно одинаково в любых языках. И таки да, это вроде везде либа. Могу, конечно, ошибаться, ибо всех имплементаций во всех языках не видел, но базовое понимание этой штуки дает умение работать с ним везде.
Ну или банальные future. Один раз понял, что оно за хуйня, и везде пользуешься.
Замыкания есть везде, и в них ничего странного нет.
А вот что сносит башку - так это отсутствие типизации и вообще система типов. Это ещё и бесит.
А вот что сносит башку - так это отсутствие типизации и вообще система типов. Это ещё и бесит.
да ладно, зато в объект можно запихнуть функцию и передать куда надо
Тут опять приколы отдельных библиотек или фреймворков, особенно для фронта, там вообще есть способы сделать очень точную типизацию или следовать нескольким важным парадигмам функционального программирования
А в системе объектов и вообще прототипно-ориентированном программировании есть фишки, вокруг которых можно строить уникальную архитектуру, отличную от ООП`шных SOLID или KISS
И вообще,для привыкших к типизации есть typescript, сильно снижающий порог вхождения для устоявшихся сишников и джавистов
Тут опять приколы отдельных библиотек или фреймворков, особенно для фронта, там вообще есть способы сделать очень точную типизацию или следовать нескольким важным парадигмам функционального программирования
А в системе объектов и вообще прототипно-ориентированном программировании есть фишки, вокруг которых можно строить уникальную архитектуру, отличную от ООП`шных SOLID или KISS
И вообще,для привыкших к типизации есть typescript, сильно снижающий порог вхождения для устоявшихся сишников и джавистов
Ничего не мешает запихнуть функцию в объект в любом другом языке.
И со строгой типизацией можно будет вызвать именно такую функцию именно с заданными параметрами в том месте, куда она передается. А не вызывать наугад хуйего знает что.
И со строгой типизацией можно будет вызвать именно такую функцию именно с заданными параметрами в том месте, куда она передается. А не вызывать наугад хуйего знает что.
динамическая типизация - это просто, единственная реальная проблема с нею - это если тебе надо как-то по разному обрабатывать разные типы и никакой информации о типе внутри переданной переменной нет. Но и она довольно просто решается.
Единственное что, стоит понимать, что в js сигнатура метода состоит только из имени, остальное в расчет принято не будет - типов нет, смотреть не на что.
С замыканиями беда в том, что они порой довольно неинтуитивны в своем поведении(когда разберешься становится попроще, конечно). Конечно, можно не парить мозг и повсеместно использовать костыль var self=this; но это такое себе
Единственное что, стоит понимать, что в js сигнатура метода состоит только из имени, остальное в расчет принято не будет - типов нет, смотреть не на что.
С замыканиями беда в том, что они порой довольно неинтуитивны в своем поведении(когда разберешься становится попроще, конечно). Конечно, можно не парить мозг и повсеместно использовать костыль var self=this; но это такое себе
Понимаешь, какая штука.
Ты, чтобы использовать любую переменную/объект класса, всё равно обязан знать её фактический тип (функция это такой же тип, как и всё остальное). Так почему бы не заставить следить, чтобы типы совпадали, компилятор или другую хуйню(какой-нибудь статический анализатор, в случае некомпилируемого языка). В принципе, та же идея частично позволяет это делать, но из-за базовой незаточенности js под статическую типизацию, всё равно хуйня получается.
И да, мне после скалки смешно читать про трудности понимания замыканий ).
Ты, чтобы использовать любую переменную/объект класса, всё равно обязан знать её фактический тип (функция это такой же тип, как и всё остальное). Так почему бы не заставить следить, чтобы типы совпадали, компилятор или другую хуйню(какой-нибудь статический анализатор, в случае некомпилируемого языка). В принципе, та же идея частично позволяет это делать, но из-за базовой незаточенности js под статическую типизацию, всё равно хуйня получается.
И да, мне после скалки смешно читать про трудности понимания замыканий ).
а мне как-то странно читать про трудности динамической типизации. Ну и да, замыкания приехали из функциональщины, неудивительно, что после скалы тебе они интуитивны.
> С замыканиями беда
> использовать костыль var self=this
Но это не проблема замыканий. Это, во-первых, проблема скоупов и, во-вторых, проблема правил, по которым this получает своё значение. this с замыканиями связан настолько же, насколько с ними связана переменная iii, которую создал в своём скрипте какой-то говнокодер.
Подобная неинтуитивная херня может быть и без замыканий:
{ let a = 1; { let a; }} сука, одна буква и два значения? a != a, что за дебильная математика?
{var a;} OK, undefined. { a = 1; var a; } сука, почему не undefined, код задом наперёд что ли выполняется?
Замыкания сами по себе крайне интуитивны. Кто-то написал функцию внутри функции, и это заработало. Наружные переменные используются внутри. Всё как в C, сразу и не догадаешься, что для этого пришлось продлевать время жизни переменных, которые раньше лежали на стеке.
> использовать костыль var self=this
Но это не проблема замыканий. Это, во-первых, проблема скоупов и, во-вторых, проблема правил, по которым this получает своё значение. this с замыканиями связан настолько же, насколько с ними связана переменная iii, которую создал в своём скрипте какой-то говнокодер.
Подобная неинтуитивная херня может быть и без замыканий:
{ let a = 1; { let a; }} сука, одна буква и два значения? a != a, что за дебильная математика?
{var a;} OK, undefined. { a = 1; var a; } сука, почему не undefined, код задом наперёд что ли выполняется?
Замыкания сами по себе крайне интуитивны. Кто-то написал функцию внутри функции, и это заработало. Наружные переменные используются внутри. Всё как в C, сразу и не догадаешься, что для этого пришлось продлевать время жизни переменных, которые раньше лежали на стеке.
Так что там с замыканиями в жс? Разве они не захватывают по умолчанию весь наружный контекст, включая this?
Проблема с динамической типизацией и интерпретируемыми языками ,в том, что у тебя нет компилятора, который надает по бошке заранее. Ну, есть всякие статические анализаторы, но это все даёт меньше гарантий, что его не переклинит (например, видел, как питонный анализатор mypy в упор не видит гарантировано неправильный код). Ну а ещё, в случае скриптов, всякие JIT должны иметь возможность "разджитировать" функцию обратно, ведь типы могут измениться в рантайме. Чем V8 и занимается
Вопрос не в компилируемости.
Вопрос в самом языке. Если он не заточен под типизацию, под него хуй ты напишешь как анализатор, так и компилятор. Когда у тебя в языке во всех местах просто переменная хз какого типа, метод хз какого типа и принимает хз какие параметры, а функция - это просто функция, которая неизвестно, какие параметры и какое значение возвращает, то не напишешь ты статический анализатор.
Вопрос в самом языке. Если он не заточен под типизацию, под него хуй ты напишешь как анализатор, так и компилятор. Когда у тебя в языке во всех местах просто переменная хз какого типа, метод хз какого типа и принимает хз какие параметры, а функция - это просто функция, которая неизвестно, какие параметры и какое значение возвращает, то не напишешь ты статический анализатор.
Статический анализатор для языка с динамической типизацией сделать можно. Он так же, как и для статической, позволит проанализировать бесконечность программ, и ещё бесконечность останется без анализа.
На практике анализатор для динамического языка просто дороже делать, и кушать процессор он будет сильнее, но сделать реально.
Пример. Есть программа целиком:
function f(x) { return x.x; }
console.log(f(null));
1. Очевидно, что x должно быть любой фигнёй кроме null и undefined - вторая строка говно, выкинуть
2. Очевидно, что эта программа не изменяет стандартные прототипы, поэтму x может быть только Object
3. Очевидно, что в этой программе не определяются никакие объекты со свойством x, поэтому f всегда либо возвращает undefined, либо бросает исключение для null, undefined.
Вполне себе выводы из "кода без типов". Их и закодить можно.
На практике анализатор для динамического языка просто дороже делать, и кушать процессор он будет сильнее, но сделать реально.
Пример. Есть программа целиком:
function f(x) { return x.x; }
console.log(f(null));
1. Очевидно, что x должно быть любой фигнёй кроме null и undefined - вторая строка говно, выкинуть
2. Очевидно, что эта программа не изменяет стандартные прототипы, поэтму x может быть только Object
3. Очевидно, что в этой программе не определяются никакие объекты со свойством x, поэтому f всегда либо возвращает undefined, либо бросает исключение для null, undefined.
Вполне себе выводы из "кода без типов". Их и закодить можно.
Дада, особенно это хорошо работает на дабаскрипте, где можно динамически создавать поля объектов из того же json. И у тебя тип объекта целиком зависит от пришедшей из сети структуры, и он может быть любым с любыми именами и значениями полей.
Очень мне, блять, интересно, как ты это статически проанализируешь.
var propertyName=// взятое извне, строка, например "xuy"
obj[propertyName]=someValue
...
var some = obj.xuy
Очень мне, блять, интересно, как ты это статически проанализируешь.
var propertyName=// взятое извне, строка, например "xuy"
obj[propertyName]=someValue
...
var some = obj.xuy
Есть прединтерпретатор, который "надает по бошке заранее".
Для этого есть TypeScript в котором все хорошо с типами.
Наоборот. Сочетание c#+javascript - вполне себе норма для веба.
Javascript достаточно сильно отличается от c# и java. И логикой работы и синтаксисом. А вот скакать с c# на java - это много нервов надо.
Javascript достаточно сильно отличается от c# и java. И логикой работы и синтаксисом. А вот скакать с c# на java - это много нервов надо.
Как раз C# и Java очень похожи. Парадигма и логика совершенна одинакова, синтаксис очень близок. Единственное, что нервирует - это naming convention. Когда прывык к джавовскому принципу наименований, шарповский немного подбешивал поначалу.
А вот javascript, хоть он и мультипарадигменный, но всё же вынуждает въезжать в парадигму функционального программирования.
Сочетание-то часто встречается такое (С# + js), но это из-за необходимости, а не из-за лёгкости изучения такого комплекта.
А вот javascript, хоть он и мультипарадигменный, но всё же вынуждает въезжать в парадигму функционального программирования.
Сочетание-то часто встречается такое (С# + js), но это из-за необходимости, а не из-за лёгкости изучения такого комплекта.
А может кто-нибудь объяснить, что это за функциональное программирование, о котором постоянно говорят именно в контексте джаваскрипта? Шо, лямбды и функции высшего порядка завезли - сразу ФП?
Если говорить строго, то ФП - это исключительно про то, что все функции не имеют эффектов (https://ruhaskell.org/posts/theory/2018/01/10/effects.html), грубо говоря, функцию можно безболезненно заменить ее результатом. Вроде, все. И так писать можно даже на сишечке, только будет медленно и неудобно.
И для того, чтоб было удобно и эффективно использовать ФП, в ФП языки завозят различные фишки, за которые их и любят, такие как мощная система типов © и строгая типизация, вывод типов, ленивость и пр. И за что мне нравится тот же хаскель (дисклеймер: знаю его плохо) и прочие фп-вдохновленные языки, вроде раста (но все равно не труЪ) - это, в первую очередь, способность описать как можно больше ограничений на языке типов, чтоб ловить баги компилятором. Ну или в хаскеле есть HKT и монады, являющиеся очень-очень абстрактной абстракций, позволяющей в одном стиле работать с коллекциями, асинхронщиной, maybe и прочим, что делает фп библиотеки так легко интегрируемыми друг с другом.
Так какого хрена про жс говорят, что там фп? В чем сложность парадигмы? На хаскеле сложно, да, я ещё не осилил. А в жс что? Писать чистые функции сложно? (На сишечке можно). Функции высшего порядка сложно ? (Все ещё можно на сишечке). Лямбды?
Если говорить строго, то ФП - это исключительно про то, что все функции не имеют эффектов (https://ruhaskell.org/posts/theory/2018/01/10/effects.html), грубо говоря, функцию можно безболезненно заменить ее результатом. Вроде, все. И так писать можно даже на сишечке, только будет медленно и неудобно.
И для того, чтоб было удобно и эффективно использовать ФП, в ФП языки завозят различные фишки, за которые их и любят, такие как мощная система типов © и строгая типизация, вывод типов, ленивость и пр. И за что мне нравится тот же хаскель (дисклеймер: знаю его плохо) и прочие фп-вдохновленные языки, вроде раста (но все равно не труЪ) - это, в первую очередь, способность описать как можно больше ограничений на языке типов, чтоб ловить баги компилятором. Ну или в хаскеле есть HKT и монады, являющиеся очень-очень абстрактной абстракций, позволяющей в одном стиле работать с коллекциями, асинхронщиной, maybe и прочим, что делает фп библиотеки так легко интегрируемыми друг с другом.
Так какого хрена про жс говорят, что там фп? В чем сложность парадигмы? На хаскеле сложно, да, я ещё не осилил. А в жс что? Писать чистые функции сложно? (На сишечке можно). Функции высшего порядка сложно ? (Все ещё можно на сишечке). Лямбды?
типизация, вывод типов и так далее - не атрибуты функциональщины. Эо атрибуты языка, скорее.
Функциональщина - это подход к программированию, когда базис - функция, а не переменная. И js есть плод насилия между функциональной и процедурной парадигмой, полулошадь-полушлюз.
Функциональщина - это подход к программированию, когда базис - функция, а не переменная. И js есть плод насилия между функциональной и процедурной парадигмой, полулошадь-полушлюз.
Вероятно, размышления уровня "в сишечке программа - это функция main, значит сишечка функциональная".
Ну и явно изучатели JS не видели "взрослое" ФП, поэтому что-то там кричат.
Ну и явно изучатели JS не видели "взрослое" ФП, поэтому что-то там кричат.
В этом и суть. Они очень похожи, но каждый со своими нюансами. Переключаться между непохожими языками проще, чем между похожими.
Я пишу под веб где-то 20 лет. Ничего безобразнее и паскуднее, чем .NET я не встречал. Это просто какой-то сплошной кошмар из антипаттернов и люди, которые по неосторожности вляпались в него - очень страдают.
Немногим лучше обстоят дела и у Asp.Net Core - да, оно даже может работать под линуксом и это огромный шаг вперед, потому что Windows Server - это удивительный сорт говна. Но часто вся эта радость идет в комплекте с EF и MSSQL и вот тогда пиздец становится полным и окончательным.
Немногим лучше обстоят дела и у Asp.Net Core - да, оно даже может работать под линуксом и это огромный шаг вперед, потому что Windows Server - это удивительный сорт говна. Но часто вся эта радость идет в комплекте с EF и MSSQL и вот тогда пиздец становится полным и окончательным.
Он просто будет долго материться на коллбеки, асинхронность, динамическую типизацию и потерю контекста.
*мимо C#, иногда имею дело в с JS*
*мимо C#, иногда имею дело в с JS*
И наверняка этот препод застрял в турбо паскале и Си времен Кернигана и Ритчи. Но понятно, что зафигачить сайт на ангуляре для него "дело недели двух"
Поэтому твой преподаватель работает преподавателем, а не программистом.
Он работает программистом. Преподавание - скорее гражданская позиция. Впрочем я понимаю, что мои слова - это слова очередного анона в интернете и не несут какого-либо веса.
одно таки не исключает другое
у меня многие преподаватели-технари из универа работали не только в универе, и при этом говорили что преподавание - не основной источник заработка.
причем не только программеры (про то, что универ - побочный заработок говорил в том числе физик).
а из знакомых прогеров-преподов в продакшене работали чуть менее чем все.
я если честно хз зачем им универ.
у меня многие преподаватели-технари из универа работали не только в универе, и при этом говорили что преподавание - не основной источник заработка.
причем не только программеры (про то, что универ - побочный заработок говорил в том числе физик).
а из знакомых прогеров-преподов в продакшене работали чуть менее чем все.
я если честно хз зачем им универ.
Студенток кадрить, мб.
Достаточно посмотреть зарплаты преподавателей, чтобы понять, какую нагрузку надо иметь, чтобы хватало на "не сдохнуть от голода", и что эта работа в 99% случаев не может быть основной.
Если ты частник из фирмы, в вузе можно вылавливать и вербовать себе новых сотрудников. Если сравнить свою зарплату и зарплату в универе, ты тупо уходишь в минус, тратя своё время, но зато у тебя появляются стажёры, которым поначалу можно не так много платить, и на образование которых не надо тратить деньги, в отличие от сотрудника со стороны, т.к. сам их всему научил, ну и они будут ещё более лояльные. Золотое дно.
Если ты из науки, придётся поиметь преподавательскую нагрузку. Тебе нужно иметь столько-то таких-то спецкурсов, написать столько-то методичек, иначе потеряешь звезду с погон и твоя зарплата учёного будет меньше.
Если ты частник из фирмы, в вузе можно вылавливать и вербовать себе новых сотрудников. Если сравнить свою зарплату и зарплату в универе, ты тупо уходишь в минус, тратя своё время, но зато у тебя появляются стажёры, которым поначалу можно не так много платить, и на образование которых не надо тратить деньги, в отличие от сотрудника со стороны, т.к. сам их всему научил, ну и они будут ещё более лояльные. Золотое дно.
Если ты из науки, придётся поиметь преподавательскую нагрузку. Тебе нужно иметь столько-то таких-то спецкурсов, написать столько-то методичек, иначе потеряешь звезду с погон и твоя зарплата учёного будет меньше.
Где-то после 5 года работы реально начинаешь понимать, что похуй, какой язык. И фреймворки похуй, потому что все базовые принципы тебе понятны, и ты, видя фреймворк первый раз в жизни, и читая описание, уже примерно представляешь, что оно, как сделано, и как работает, остаётся выяснить нюансы. Типа, как именно называется класс, который должен бы в этом фремворке быть, и делать примерно вот то и это.
Между базовыми принципами и синтаксисом ещё куча всего, и чтобы уметь эту кучу всего применять, нужна практика. Внутри одной предметной области - поверю, что со скрипом можно за несколько месяцев перейти. Внутри одной парадигмы - тоже. А если ты писал прошивку для микроконтроллеров на чистых сях и полез в какой-нибудь реакт (или наоборот) - уже не верю, что так скоро выйдет толк.
Ну, если ты всё время сидишь и дрочишь одну область, и не задумываешься о том, как оно устроено, то может быть.
Я после джавы писал прошивку для торгового девайса на сях, и никаких месяцев мне не потребовалось. За месяц я ее написал без всякого переобучения. Но потому, наверное, что я неплохо разбираюсь в тех же нутрях джавы, например.
Я после джавы писал прошивку для торгового девайса на сях, и никаких месяцев мне не потребовалось. За месяц я ее написал без всякого переобучения. Но потому, наверное, что я неплохо разбираюсь в тех же нутрях джавы, например.
Если ты писал на контроллеры, то можно пойти писать и реакт, пусть и матерясь. Если ты всю жизнь писал на жс в модных стилях, сишечка сделает больно
Да, а потом выясняется, что вызов Dispose у HttpClient:IDisposable может приводить к спорадическим исключениями, потому что он не гарантирует, что закроет соединения, и пул соединений может исчерпаться. И эти чудеса в .net standard.
Изучение фреймворка, это изучение его подводных камней. Иногда методом прощупывания дна лбом.
Изучение фреймворка, это изучение его подводных камней. Иногда методом прощупывания дна лбом.
Да, бывает. Причем иногда ты можешь пару лет использовать фреймворк, а потом в один прекрасный момент найти в нем какую-нибудь адовую хуйню.
А вот бетесду за решение использовать движок, который они знают, все чот говном поливают.....
Ну так надо модифицировать его так чтобы работало, а не "it just works". Так что у меня некоторые сомнения, что так уж они его знают. Скорее они о чем то догадываются.
Ну они явно знают, что на нём, например, нельзя нормально реализовать движущиеся объекты окружения. Но по ТЗ сделать надо. Поэтому в драгонборне движущиеся коридоры в царстве Хермеуса движутся с такими дёрганиями, которые не заметить невозможно.
Ну а про шлем-поезд из третьего фолла, наверно, только ленивый не слышал.
Ну а про шлем-поезд из третьего фолла, наверно, только ленивый не слышал.
не то чтобы нельзя..... просто анимировать придётся. А можно просто скриптом, без анимаций.
Это, пожалуй, один из самых долгоживущих мемов.
Охуеть! Древний мем в HD качестве
Тот случай, когда чувака правильно выкинули в окно. Самое важное для языка сейчас -- развитая экосистема. Иначе, как ты будешь гуглить свои ошибки на каком-нибудь фортране?
Фортран прекрасно живет. Во всяких научных расчетах и высокопроизводиельных вычислениях у него есть своя стабильная доля. И ряд научных инструментов на нем написан и по сей ден используются и поддерживаются. Да и сам фортран, внезапно, развивается, там какие-то новые версии выходят, хоть и не так часто, как у плюсов.
Требуются программисты на фортране для поддержки проекта!
ну, не сказать что вообще нет, но тяжело, да
https://www.monster.com/jobs/search/?q=fortran
https://www.monster.com/jobs/search/?q=fortran
>Hourly rate: $60-$65 per hour on w-2 OR $70-$75 per hour Corp to Corp (C2C) (depending on experience - TBD)
иначе говоря это от 48k$ до 60k$ в месяц
иначе говоря это от 48k$ до 60k$ в месяц
блин обсчитался - всего-то 180k$ в год
Выбирать трендовые технологии при прочих равных имеет смысл - это повышает привлекательность проекта для программистов.
Мотивация "хочу проект с новыми технологиями" довольно часто встречается.
Мотивация "хочу проект с новыми технологиями" довольно часто встречается.
Отличный комментарий!
+++++++++++++++++++++++++++.+++++++++++++++++
++++++++++++.+++++++..+++.-------------------
---------------------------------------------
---------------.+++++++++++++++++++++++++++++
++++++++++++++++++++++++++.++++++++++++++++++
++++++.+++.------.--------.------------------
---------------------------------------------
----.-----------------------.