Розробка · 23 червня 2013, 0:24 8986

Максим Вовк, С, Ассемблер

Во что проще\быстрее вникнуть в IT?

Доброго вам всего форумчане ! Я работаю один год на предприятии где программирую контроллеры для станков и прошивки для различного очень большого оборудования, из знаний это чистый Си и Ассемблер а также SQL, очень слабо знаком с ООП на примере С++. Моя зарплата 250 баксов и НИКАКОЙ перспективы !!! Я хочу очень быстро куда ни-буть свалить, но не хочу убить ещё год или два на изучение например С++ где перспективы так же туманны. Смотрел в сторону JavaEE, а там такой зоопарк надо знать : Spring, Hibernate, XML, XSL, XSLT, xsd, Design Patterns, Unix/Linux, SVN,Tomcat, JBOSS application servers, JIRA, IDE (Eclipse, IntelliJ), SaaS, Web Services, SOAP, REST, WSDL
что года два всё это точно учить надо. Для себя выбрал уйти в MobileDev будь то Android или iOS или взяться за C# так как на первый взгляд вроде это проще выучить и быстрее (наверно месяцев 6) и легче, а также платят 500 баксов джуну. Может я ошибаюсь, но так подскажите коллеги как быстрее стартануть я же загнусь скоро.
PS: английский учу по выходным и понимаю что он нужен.

Теми: навчання, робота

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Ctrl + Enter

Ctrl + Enter

muzykdev Dev 15.10.2013 18:16

Почитал коменты автора и закралось подозрение, что это тонкий тролинг. Вы 0 после или 1 пред не забыли при указании вашей ЗП?
А если действительно все так печально может стоит попробовать в смежную область перебраться? Например писать драйвера под винду? Там можно получать ЗП раз в 4-6 больше и уже по вечерам медленно и уверенно заниматься изучением интересующих технологий? Идея в том что б разбираться с интересом, а не сваливать в первое попавшееся место на непонятную вам технологию.

Відповісти

Підтримати

Igor Barbashev Працює в все еще впереди 14.10.2013 22:26

MySQL и HTML5 для веб-приложений. ИМХО, неплохая связка

Відповісти

Підтримати

Настасий Петрович 12.10.2013 14:55

XML, XSL, XSLT, xsd, SOAP, WSDL — одна и тажа фигня. Этот зоопарк для запугивания «Вот какая у нас спискота, та. ОООО, бойся будущий кандидат».

Объясню по-крестьянски.
WSDL это как бы часть SOAP. SOAP тупо протокол взаимодействия между клиентом и сервером. Доступ к данным, удаленный вызов процедур и все такой.
Кароче, очередная текстовая фигня в виде XML. XML для профи, это такая недоделка HTML. А вообще XML это просто формат представления всякой спискоты, таблиц, деревьев там. Типа как хранить те же структуры в языки C. А всякие XSLT, XSL, XSD вспомагательное описалово, мол «Че там как там эти теги распарсивать, че оно вообще значит». И все.

Design Patterns

Книжку надо прочитать. Шаблоны это придуманные кем-то, кто считает что все программисты мира сталкиваются с этим постоянно.

Unix/Linux

Поюзать новую операционную систему. Изучить команды там, изучить настройки, как что отключатьи включать. Как файловые системы работают и все такое. Не сложно — здесь ты чисто юзер, учишься работать как c Windows только с вниканием.

SVN

Файловая помойка. Dropbox для кодерочков. Если просят SVN — расслабься, есть такие штуки как Mercurial, GIT — вот это серьезные контролки версий. Это не программирование, это чисто ты юзаешь прогу а-ля «Я писатель». Туды кинул кусок, сюды кинул кусок текста, просмотрел историю, и различные нужные фичи. Учится тупо пользоваться.
Это типа Word, но с только с историей правок и возможностью коллективно пилить один текст.

JIRA

Обычно, веб-фигня. Где ты числа вносишь, сколько работал, устраиваешь срачи в комментариях, таски раздаешь и всее такое. Это форум для кодерочков, где вместо темы ты пишешь в заголовке таск, баг, фичу, или просто потрындеть(например, обсудить какие мы умные и как нам строить архитектуру приложений).
Как на заводах и фабриках. Контроль, когда пришел, когда приступил, сколько времени потратил. Это ж чисто пользовательская фигня, здесь не надо быть программером.

IDE (Eclipse, IntelliJ)

Редактор для кодерочков. Абы не писать и не мучится в Notepad. Придумали такую вот фишку. По сути любая IDE — чисто редактор для текста, но с наворотами: запустить компиляцию, найти в говнокоде такой-то класс.
Опять таки, тут все проще. Тупо берешь и осваивашь с точки зрения пользователя: менюшки, фишки, плагины скачиваешь и прикручиваешь, проекты сохраняешь, а потом сновао ткрываешь. Поиграться надо.

JavaEE

... остальные словечки.
Это уже суть программирования. Тут алгоритмы, библиотеки, свои стандарты оформления кода. Тут уже чисто для программистов, тут надо углубляться и шарить.

Нечего пугаться :)

Відповісти

Підтримати

Настасий Петрович 12.10.2013 14:30

Есть проекты под Linux C\C++ embeded. Как бы уже не контролеры, но выше. От туда и до всяких умных словечек недалеко.

Відповісти

Підтримати

Aleksey Kolupaev CTO в eduki 09.10.2013 20:24

Боишься зоопарков — не иди в ИТ. Тут за 5 лет зоопарк еще и обновляется чуть не полностью. Не поспеешь — потеряешь востребованность.

Відповісти

Підтримати

Oleg Sergeev 09.10.2013 20:32

Это просто быдляццкие особенности рынка. Все что нужно — это плэйн си, английский и узкая ракетная предметная область, но все это должно быть на потрясающем уровне.

Відповісти

Підтримати

Aleksey Kolupaev

Oleg Sergeev 09.10.2013 20:35

Неужели думаете, что люди с 3-летним опытом могут знать это все

Spring, Hibernate, XML, XSL, XSLT, xsd, Design Patterns, Unix/Linux, SVN,Tomcat, JBOSS application servers, JIRA, IDE (Eclipse, IntelliJ), SaaS, Web Services, SOAP, REST, WSDL

?

Відповісти

Підтримати

Aleksey Kolupaev

Ще 10 коментарів

noname fordou 09.10.2013 20:45

ну не так и зло тут все что расписано:

IDE (Eclipse, IntelliJ),

— это понятно — просто юзать и знать пару шорткатов и про контрол клик.

XML, XSL, XSLT, xsd

— нуу. по верхам ничего прямо ужасного в XSLT и всяких там DTD нету, надо просто понятие иметь и когда нужно — сомтреть по ситуации, сам XML интуитивно понятен.

Spring, Hibernate,

— хз, основы вполне реально. Я не сильно в теме — но из Spring знать про IOC/ Dependency Injection сами концепции плюс что то там про security layer. Spting MVC — пройти тьюториал чтоб начать, а за три года я думаю будет все нормально. Hibernate по верхам на практике быстро концепция понимается, дьявол в деталях.

Web Services, SOAP, REST, WSDL

— REST почти интуитивно понятен. SOAP/Wsdl это смежные вещи — опять же при первой же надобности базово разбирается за пару дней, а за 3 года прокачивается нормально.

Design Patterns

— ну теорию знать и понимать по нескольким паттернам впринипе несложно, а вот с применением проблем чуть больше.

SVN,Tomcat, JBOSS application servers

— по верхам не выглядит сложно, за детали не в курсе.

за 3 года это все вполне реально освоить на среднем уровне.

Відповісти

Підтримати

Oleg Sergeev 09.10.2013 20:54

за 3 года это все вполне реально освоить на среднем уровне.

Скорее на таком себе начально-среднем. Плюс надо учитывать, изменчивость зоопарка.

Design Patterns

Это на всю жизнь. По книжке понять не реально. Надо на своей шкуре облажаться 100500 раз и придумать в итоге свои личные паттерны, которые работают.

Відповісти

Підтримати

Aleksey Kolupaev CTO в eduki 10.10.2013 14:23

По книжке понять не реально. Надо на своей шкуре облажаться 100500 раз и придумать в итоге свои личные паттерны, которые работают.

Опыт, конечно, великий учитель, но книги — тоже чей-то опыт. Если вы научитесь воспринимать конденсат чужого опыта — обучение идет гораздо быстрей.

Відповісти

Підтримати

Aleksey Kolupaev CTO в eduki 10.10.2013 14:16

Думаю, что таки да, могут.

Не все эти страшные аббревиатуры нужно знать на одинаковом уровне. Кое-что надо знать очень хорошо, кое-что — не обязательно, кое-что вообще поверхностно.

Spring и Hibernate — довольно сложные темы, надо много читать, и написать несколько проектов. Полгода вполне хватить чтобы сделать пару pet-projects или поработать в какой-то компании и уже не быть голым теоретиком.

XML, XSL, XSLT — одна обойма, тоже немало своих хитростей, и потребует некоторых усилий и практики. Ну, допустим, еще полгода. Несложно смешать с изучением Spring/Hibernate в одном проекте.

Design Patterns — общая теория программирования. Полезно знать, и неизбежно придется освоить при вдумчивом изучении Spring например. Там добрая половина паттернов активно используется. Ну добавим еще полгода.

Web Services, SOAP, REST, WSDL — это все одна пачка, ничего особенно сложного, но подчитать и попрактиковаться нужно. Грамотно включить их в pet projects — тоже можно. ОК, еще полгода.

IDE (Eclipse, IntelliJ), Tomcat и JBOSS application servers, Unix/Linux — знать «как сисадмину» не надо, надо знать как программисту — это значительно меньший объем знаний. Ставишь себе убунту с самого начала, IDE придется пользоваться в любом случае, сервер тоже никуда не денется — и через три года изучения Spring-а и прочих хибернейтов уже все само собой образуется.

SVN даже обсуждать нечего, хотя непонятно зачем модному пацану такое в мире, где есть git и mercurial. SaaS — простенькая бизнес-моделька, одно посещение стартаперской конференции — и ты шаришь.

Відповісти

Підтримати

Oleg Sergeev 10.10.2013 14:29

Ну даже не знаю, что сказать. По моему все что может человек, которого вы описали так это запилить сложную фичу. А вот сможет ли взять и зделать проект самостоятельно принимая все решения? Я думаю нет.

Відповісти

Підтримати

Aleksey Kolupaev

Aleksey Kolupaev CTO в eduki 10.10.2013 14:46

Ну наверное именно поэтому его называют разработчиком, а не CTO?

Відповісти

Підтримати

Oleg Sergeev 10.10.2013 15:04

Не понял если чесно.

Відповісти

Підтримати

Aleksey Kolupaev

Aleksey Kolupaev CTO в eduki 10.10.2013 15:24

Прочитайте еще раз?

Відповісти

Підтримати

Oleg Sergeev 10.10.2013 15:36

Ну наверное именно поэтому его называют разработчиком,

Его называют джуниор-разработчиком. Если человек не знает, как более-менее крупные фичи будут взаимодействовать и изменяться в будущем, то это джуниор. Джуниор делает фичи как ему сказали и используя то, что сказали и не несет никакой ответственности за то, что в конце будет катастрофа.
Не знаю что такое СТО. Щас погуглю.

Відповісти

Підтримати

Aleksey Kolupaev

Назар Казымов Java Developer 11.10.2013 18:31

станция техобслуживания

Відповісти

Підтримати

Oleg Sergeev 08.10.2013 17:34

Чювак, с твоим-то сишным опытом надо бы в обжектив-ц ударяться. А то знаешь ли в дотнете винформс окошко пустое открываешь, зыбаешь в диспетчер, а оно уже кучу потоков незнамо для чего поназапускало и тормозит падла...

Відповісти

Підтримати

Oleg Sergeev 08.10.2013 20:47

А вообще твоя проблема английский. А так ты программируешь на самом лучшем языке на свете.

Відповісти

Підтримати

Ivan Pomidorov 08.10.2013 13:01

Пойти в ADB, это телекомовская компания и у них очень-очень сильная команда С/С++

Відповісти

Підтримати

shadow 08.10.2013 16:35

В чем эта сильность выражается?

Відповісти

Підтримати

Ще 2 коментарі

СНИКЕРС 08.10.2013 16:59

В сильной течи памяти :)

Відповісти

Підтримати

shadow 08.10.2013 21:41

И расстрелом памяти из дробовика ;-)

Відповісти

Підтримати

Oleh Korotkov девелопер в шоке 08.10.2013 12:55

Если хорошо поискать то на чистом С и ассемблере можно найти очень даже высокооплачиваемую работы, вакансий там намного меньше чем на джаве, шарпе, руби и т.д. но и специалистов там единицы. Можно подтянуть английский и ехать за границу, там программирование станков на заводах оплачивается значительно лучше чем у нас.

Відповісти

Підтримати

Ilya Trushchenko SRE в Carta 07.10.2013 11:13

Я хочу очень быстро куда ни-буть свалить, но не хочу убить ещё год или два на изучение например С++ где перспективы так же туманны. Смотрел в сторону JavaEE, а там такой зоопарк надо знать : Spring, Hibernate, XML, XSL, XSLT, xsd, Design Patterns, Unix/Linux, SVN,Tomcat, JBOSS application servers, JIRA, IDE (Eclipse, IntelliJ), SaaS, Web Services, SOAP, REST, WSDL
что года два всё это точно учить надо

Извини за диагноз по интернету, но IMHO не быть тебе хорошим программистом, какую технологию или язык не выбирай. Я хоть и не зарабатываю на жизнь программированием, но от изучения нового языка или технологии получаю удовольствие, не задумываясь «а сколько мне за это заплатят?», а ты — убиваешь еще год... Будь ты хоть мегаталантлив — если постоянное, ежедневное изучение чего-то нового в ИТ — это для тебя всего лишь путь к «многоденег» — ты рано или поздно сломаешься, не через месяц, так через год. Будешь ненавидеть работу и гиков, которые без напряга и с удовольствием будут ежедневно бесконечно самосовершенствоваться, рано или поздно оставив тебя позади.
Так что в первую очередь попытайся поменять свои взгляды, жизненную позицию, отношение к ИТ. Если не сможешь — лучше не «убивать еще один год или два», потому что «быстро куда ни-будь свалить» у тебя 100% не получится

Відповісти

Підтримати

Egon Schiele 07.10.2013 14:55

Ох ты, неисправимый романтик... Когда жрать нечего, тогда отпадает все вдохновение что-то учить для удовольствия :)

Відповісти

Підтримати

Ilya Trushchenko

Ще 3 коментарі

Ilya Trushchenko SRE в Carta 07.10.2013 16:20

С одним годом опыта работы я получал куда меньше, вот только это меня абсолютно не волновало... да и сейчас особо не волнует...

Відповісти

Підтримати

Yurii Didkovskyi Software Engineer в Valor Software 08.10.2013 04:01

Илья — привет :)

Відповісти

Підтримати

Ilya Trushchenko

Ilya Trushchenko SRE в Carta 08.10.2013 08:38

Привет, Юра :) Нашел же ты тему для «привета», прям как призрак из прошлого :D
Кстати, к вам я тоже пришел на что-то поменьше $250 сайт на перле ковырять :) эхъ было время

Відповісти

Підтримати

Yurii Didkovskyi

Антон Харуйманов 07.10.2013 11:09

Автор, учите английский до уровня Intermediate. Хотя, на соседних проектах были товарищи с Pre-Intermediate, у них была не речь, а сущий ад. Почему это никого не смутило: там достаточно было переписываться с заказчиком, а не общаться голосом.
Ну и в командировку их не направляли, а ребята уровень не подтягивали, так как: ленивые жопы + никто прямо в тот момент их не гнал никуда.

Если знаете С, вряд ли будет сложно выучить Оbjective-C, надмножество языка С. О пороге входа (финансовом) в курсе?

Відповісти

Підтримати

Alexandr Gavriluk 07.10.2013 03:27

Блин, с вашими скилами лучше идти в driver developer
Windows File System Filter developer
grc.ua/...ne&utm_campaign=Jooble_it

Вакансий намного меньше, зато и конкуренция 0.1 человек на вакансию, так как все хорошие разработчики драйверов уже свалили.

А по сути понять разницу между Paged и NonPaged памятью или как как реализовать коммуникацию между сервисом в UserMode и драйвером в kernel-моде не сложнее понять WCF.

Для азов советую эту книгу
www.proklondike.com/...cpp/soldatov_drivers.html

PS
Хотя сам пошел в CV и C#.

Відповісти

Підтримати

Максим Вовк 06.10.2013 19:53

Решил для себя идти в дотНет направлении, но никак не получается, не выходит. Два дня назад было 9-тое собеседование в котором я понял что просто не тяну. Реально дотНет очень большой, всегда найдется момент о котором ты не знаешь на котором тебя обязательно поймают, после чистого «Си» этот C# имеет очень много всяких «финтифлюшек» в которых просто теряешься, не в обиду дотНетчикам но всякого мусора в C# просто навалом. Конечно я когда прошел кучу собеседований я познал много всяких тонкостей о которых не знал но всё равно, слишком много всего ! Я не знаю как там в Java но дотНет очень большая платформа, для меня это сложно, видать не тот мозг ! Уйду в Ruby или Python, хотя говорят что это для тех кто «неасилил» C#\Java наверно оно так и есть ! Последний надеюсь мой вопрос к вам коллеги : если строить web-приложение принципиальная разница есть между RoR или Python(Django) как по мне всё очень похоже! Спасибо всем, счастья, добра, удачи...

Відповісти

Підтримати

Viktoria Muzychko Senior Software Engineer 06.10.2013 19:58

Ты бы попробовал реализовать какой-то небольшой проект, и ссылку на него включать в резюме. Может так эффективнее будет.

Відповісти

Підтримати

Максим Вовк

Ще 1 коментар

anonymous 06.10.2013 21:55

-

Відповісти

Підтримати

Viktoria Muzychko

Pavel Kruchina CTO 06.10.2013 20:10

Простите за нескромный вопрос — а как вы учили c#? Какую литературу хотя бы осилили?

Не знаю ни одного человека, который пошел бы в ruby/python/php/js потому что не осилил java/c# (обычно этим тешат себя как раз состоявшиеся джависты/шарпники). Поверте, там своя пьянка, и свои тонкости — и вам их нужно будет учить с нуля. Не проще ли доучить оставшееся? Тем более за один «промах» вас не завалят на собеседовании.

А с таким подходом, у вас будет только каша в голове из отрывков знаний о разных языках.

Відповісти

Підтримати

Максим Вовк

Ще 3 коментарі

Максим Вовк 06.10.2013 20:18

Троелсена практически всего прочитал, про WinForm, WPF, WCF — читал статьи. Особенности WCF полностью так и не понял и на нём жестко лажал.

Відповісти

Підтримати

Pavel Kruchina CTO 07.10.2013 10:13

А по статьям тяжело понимать — лучше опять таки книжка (благо они существуют).

Відповісти

Підтримати

Максим Вовк

Blitz .net Developer 08.10.2013 13:19

Значит, фреймвёрков вы не знаете. Троелсен — введение в язык. WinForms не нужен, советую Макдональда по WPF или Фрмиена по ASP.net.

Відповісти

Підтримати

Максим Вовк

anonymous 06.10.2013 21:54

-

Відповісти

Підтримати

Максим Вовк

Ilya Trushchenko SRE в Carta 07.10.2013 10:02

Уйду в Ruby или Python

Там тебе тоже придется учить кучу сопутствующих технологий, ведь просто python, который можно за пару недель выучить на уровне «визитка на django», никому не нужен

Відповісти

Підтримати

Максим Вовк

Oksana Chuiko Software Engineer в Pure Storage 07.10.2013 22:24

Уйду в Ruby или Python, хотя говорят что это для тех кто «неасилил» C#\Java наверно оно так и есть

хз даже.. я пошла в джаву после того, как ниасилила питон..

Відповісти

Підтримати

Максим Вовк

Ще 9 коментарів

СНИКЕРС 08.10.2013 01:32

Да ладно вам, вы же вроде изначально учили Java ... А Python ну явно проще Java тем более после неё «асилить» Python вам бы не составило особого труда !

Відповісти

Підтримати

Oksana Chuiko Software Engineer в Pure Storage 08.10.2013 09:26

вы же вроде изначально учили Java

не, годом раньше была попытка изучить питон

А Python ну явно проще Java

ох, не сказала бы

тем более после неё «асилить» Python вам бы не составило особого труда !

после джавы питон взорвал мне мозх. Тяжковато привыкать к динамической типизации после статической :)

Відповісти

Підтримати

anonymous 08.10.2013 09:42

-

Відповісти

Підтримати

Oksana Chuiko Software Engineer в Pure Storage 08.10.2013 10:01

как то так, ага)

Відповісти

Підтримати

anonymous 08.10.2013 09:25

-

Відповісти

Підтримати

Oksana Chuiko Software Engineer в Pure Storage 08.10.2013 10:01

между джавой и питоном? правда что ли?)

Відповісти

Підтримати

anonymous 08.10.2013 10:12

-

Відповісти

Підтримати

Oksana Chuiko Software Engineer в Pure Storage 08.10.2013 13:11

действительно, никакой! между мышью и жирафом тоже разницы нет — у одного и у другого по 7 шейных позвонков :)

Відповісти

Підтримати

Java Adept 08.10.2013 20:08

/me facepalm

Відповісти

Підтримати

Oleg Yakovenko SE 09.10.2013 19:04

После почти пяти лет (2007.01-2011.09) в АСУ ТП и родимых ПЛК (языки IEC61131-3, VB, Delphi+MS SQL, C) ушел на RoR — и нисколько об этом не жалею

Відповісти

Підтримати

Максим Вовк

Ще 1 коментар

СНИКЕРС 09.10.2013 19:11

Везёт вам ... Я хотел на Python-не остатся но не вышло и теперь занимаюсь всякой хернёй !

Відповісти

Підтримати

Eugene Zavidovsky 31.08.2013 17:28

А что ответят опытные насчет моего предложения изучать Dataflow Programming начинающим?

>>> en.wikipedia.org/...low_programming

Відповісти

Підтримати

Sergei 31.08.2013 16:27

ТС, ну что выбрали?

Відповісти

Підтримати

Максим Вовк 31.08.2013 17:07

C#\ASP.NET, не знаю правильно ли я сделал выбор но будет видно !

Відповісти

Підтримати

СНИКЕРС 13.08.2013 22:16

А мне вот интересно как там ТС ? Что выбрали, работу поменяли ? Как дела в общем ?

Відповісти

Підтримати

Максим Вовк 13.08.2013 22:59

С работы не ушёл но выбрал для себя C# как лучший инструмент из возможных (личное мнение) изучаю его параллельно с английским.

Відповісти

Підтримати

Ще 3 коментарі

СНИКЕРС 13.08.2013 23:53

Это правельный выбор !!! Вы будете довольны ...

Відповісти

Підтримати

Максим Вовк

Максим Вовк 14.08.2013 10:35

Надеюсь на это.

Відповісти

Підтримати

Sergius von Bielersee Schweizergarde в Ziemer Ophthalmic Systems AG 07.10.2013 16:41

А он и есть лучший :-)
В плане мощности так точно.

Відповісти

Підтримати

Максим Вовк

Alex Batler заговорщик в Mutabor-science 11.07.2013 23:39

А какой SQL знаете? У меня просто в голове никак не сходится, зачем в контроллерах и очень большом оборудовании SQL?
Если по теме, то сначала надо решить куда именно свалить, а потом — что там делать)
О, попросите поднять зарплату на 100 баксов для эксперимента. Ну это если деньги есть на черный день.

Відповісти

Підтримати

idOne Арбузный 08.07.2013 16:51

Бабло забартывается примерно так habrahabr.ru/post/148665

Відповісти

Підтримати

Эдик Драуд 08.07.2013 16:28

А вот если опыта особого нет, а на работу хочется по быстрее, то на что обратить внимание, что бы быстрее выучить и пойти на работу, а не сидеть дома ? php ? Python ? SQL Dev ?

Відповісти

Підтримати

Pavel Kruchina CTO 08.07.2013 16:34

Веник и швабру

Відповісти

Підтримати

Эдик Драуд

anonymous 08.07.2013 16:58

-

Відповісти

Підтримати

Эдик Драуд

Ще 4 коментарі

Dmytro Gladkyi 31.08.2013 18:08

с RoR токо на мак хватает?

Відповісти

Підтримати

anonymous 31.08.2013 18:11

-

Відповісти

Підтримати

Valentin Nechayev архімаггриб в Дарницькі печери 07.10.2013 17:09

Сегодня в макдональдс видела листовки с набором персонала.

DevOps?

Відповісти

Підтримати

anonymous 08.10.2013 09:04

-

Відповісти

Підтримати

Valentin Nechayev

СНИКЕРС 09.07.2013 11:25

Возможно самое простое из всего возможного это php+js+sql ... Или js+css+html для фронта !

Відповісти

Підтримати

Эдик Драуд

Ще 12 коментарів

Эдик Драуд 09.07.2013 14:56

Самое простое из всего простого ?

Відповісти

Підтримати

СНИКЕРС 09.07.2013 19:19

Как по мне так, ДА самое простое !!! Допустим есть одно чмо, это чмо что-то знает о компах что-то о сетях и немного знает как это всё работает. Данное чмо покупает книгу по ПыХе+SQL и читает месяц, потом сфорганет сайт за недельку для портфолио идёт на работу быдло-кодером ! Вот и всё ! Всё очнь просто ...

Відповісти

Підтримати

Эдик Драуд

Java Adept 10.07.2013 11:14

facepalm.jpg

Відповісти

Підтримати

Pavel Kruchina CTO 10.07.2013 11:26

Вы не правы, ведь можно поставить джумлу, и посмотреть видео в интернете... И партфолио будет лучше, и разобраться быстрее... И чего уж там таить, компании «сайт за 300грн» лучше «специалиста» и не надо

Відповісти

Підтримати

Назар Казымов Java Developer 07.10.2013 18:12

а в чем чмошность то?

Відповісти

Підтримати

СНИКЕРС 07.10.2013 18:27

Чмошность заключается в том что поддерживать проекты после быдлo-кода чмошника очень сложно, а бывает практически нереально ...

Відповісти

Підтримати

Назар Казымов

Natalia Riabokon rainha da lua в gamedev 07.10.2013 18:46

Хм, интересно, это чаще провтык работодателя или сознательно так берут, настолько дефицит...
Когда смотрю на свой код n-летней давности, то его

поддерживать очень сложно, а бывает практически нереально

Відповісти

Підтримати

Natalia Riabokon rainha da lua в gamedev 07.10.2013 18:51

Кстати, чмошность тут не горе-кодера выходит. Если человеку без опыта предложили работу за достойную зп, кто ж откажется и скажет «я чмо, не берите меня, я недостоин».

Відповісти

Підтримати

Java Adept 08.10.2013 20:09

быдлo-кода чмошника

А ты пишешь идеальный код ?

Відповісти

Підтримати

СНИКЕРС 08.10.2013 20:14

Нет конечно, но уже не чмошник, а полу-чмошник, скоро буду просто разработчиком !

Відповісти

Підтримати

Эдик Драуд 13.08.2013 19:40

А почему говорят что C# сложнее Java, когда что бы работать «джавером» нужно очень много знать фреймворков и всякой лабуды, а в C# сам язык и ASP.NET ну там формы ещё под десктоп ?!

Відповісти

Підтримати

СНИКЕРС 13.08.2013 20:48

Шарп сам по себе сложнее как язык, не С++ конечно но всё же, там есть кучка всякой левой фигни типа структур, лямбд чего в Java нет, да и вообще Шарп сам по себе больше ...

Відповісти

Підтримати

Эдик Драуд

Igor Petruk Software Engineer в Google 10.07.2013 11:20

Все-таки обрати внимание, что большинство над тобой посмеялось. И только один, по неясным причинам, решил ответить о php.

Это знак что твой вопрос не правильный

Відповісти

Підтримати

Эдик Драуд

Ще 43 коментарі

Эдик Драуд 10.07.2013 19:10

Вы знаете, я конечно согласен что мой вопрос не правильный и те кто надо мной посмеялся, пусть смеются ибо земля круглая все равно это им вернется рано или поздно и больно ударит, я тоже таким был высокомерным и королём жизни и смеялся над другими, а теперь получил по заслугам и смеются надо мной что вполне закономерно. В данный момент я просто задал пусть и глупый но вопрос на который хотел получить не глупый ответ, конечно не знаю на что я тогда надеялся но всё же. Просто у меня так сложились обстоятельства, что приходится задавать глупые вопросы, загнал сам себя в угол, а теперь хочу выйти. И спасибо вам за адекватное общение со мной !

Відповісти

Підтримати

anonymous 10.07.2013 19:21

-

Відповісти

Підтримати

Эдик Драуд

Kirill Sablin Developer 11.07.2013 16:09

PHP — технология с достаточно низким порогом входа

собсно, как и руби:)

Відповісти

Підтримати

anonymous 11.07.2013 16:10

-

Відповісти

Підтримати

Pavel Kruchina CTO 11.07.2013 16:18

Да они задолбали входить! Вы искали когда нибудь php-джуна? Может у меня на одной из прошлых работы был невменяемый рекрутер, но из 5-6 соискателей 4-ро не могли написать ни строчки кода.

Так что хай идут в руби, в пхп и так навалом.

Відповісти

Підтримати

anonymous 11.07.2013 16:23

-

Відповісти

Підтримати

Pavel Kruchina CTO 11.07.2013 16:27

Блин. Давайте говорить что у джавы низкий порог входа? Может хоть немного туда уйдёт.

Відповісти

Підтримати

anonymous 11.07.2013 16:30

-

Відповісти

Підтримати

Kirill Sablin Developer 11.07.2013 17:09

ну на самом деле там тоже не особо и высокий порог

Відповісти

Підтримати

Victor Prokopovych 11.07.2013 17:18

хахаххах,такого я ещё не видел=)

Відповісти

Підтримати

Kirill Sablin Developer 11.07.2013 17:31

а на самом деле высокий?

Відповісти

Підтримати

Victor Prokopovych

Victor Prokopovych 11.07.2013 17:34

Для каждых компаний по разному и смотря какую зарплату хочешь. Я все чаще начинаю видеть коментарии о том,что джуны не могут и строчки кода написать,а ходят на собеседования,это шутка такая?

Відповісти

Підтримати

Kirill Sablin Developer 11.07.2013 17:37

что-то я потерял нить дискуссии

Відповісти

Підтримати

Victor Prokopovych

Victor Prokopovych 11.07.2013 17:43

а на самом деле высокий?

Для каждых компаний по разному и смотря какую зарплату хочешь.

Відповісти

Підтримати

Kirill Sablin Developer 11.07.2013 17:45

Тут разговор шел о пороге вхождения в язык/технологию. При чем тут компании/зарплаты?

Відповісти

Підтримати

Victor Prokopovych

Victor Prokopovych 11.07.2013 17:50

Джун который не умеет писать код и хочет 700-1000 долл,врят ли получит место в компании,еше в таких как Эпам,Циклум,Глобал.
Он может получить место в ООО за 200-300 долл и уже будет называться джуном.

Відповісти

Підтримати

Kirill Sablin Developer 11.07.2013 18:09

еше в таких как Эпам,Циклум,Глобал

вы так говорите, как-будто это что-то хорошее:)

Відповісти

Підтримати

Victor Prokopovych

Victor Prokopovych 11.07.2013 18:05

Мой порог вхождения был таков: Сначала я читал книги,потом понял что теорию знаю но кодить не умею и нашел препода,который был ЕЕ программистом.Учился у него где то 7 месяцев,платил ему деньги,паралельно учил инглишь,тоже с частным преподом.
Потом он мне сказал что я уже могу найти работу и обучение мы закончили. Я не поверил и хотел ещё подтянуть математику но создал топик на ДОУ,который потом удалил и начал отсылать резюме. По итогам он был прав,я получил работу и достаточно быстро.
Вложения в учебу составили более 10000 грн, потратил много сил и времени, и до сих пор трачу деньги на английский и скоро буду искать препода по матиматике.
Это низкий порог вхождения?
Я понимаю что не у всех так,но джун который не умеет писать код и ходит на собеседования,меня это смешит.

Відповісти

Підтримати

Kirill Sablin Developer 11.07.2013 18:11

Это не порог вхождения, а ваша история.

Відповісти

Підтримати

Victor Prokopovych

Victor Prokopovych 12.07.2013 12:50

Это моя история с моим же порогом вхождения.
Я Вам уже ответил, что каждая компания требует от джунов разные знания, одной хватит что бы джун понимал джава кор и ООП, другой этого будет мало на принятия его на работу.

Відповісти

Підтримати

Pavel Kruchina CTO 11.07.2013 17:46

ну, с этим не поспоришь... Хотя это для любого языка верно.

Відповісти

Підтримати

Victor Prokopovych

Pavel Kruchina CTO 11.07.2013 17:45

К сожалению, это не шутка. Да и джунами этих людей сложно назвать. Бывшие представители других профессий, которые увидели сколько получают программисты и стараются попасть на вакансии «без опыта».

Відповісти

Підтримати

Victor Prokopovych

Victor Prokopovych 11.07.2013 18:17

И их берут на работу?

Відповісти

Підтримати

anonymous 12.07.2013 10:08

-

Відповісти

Підтримати

Victor Prokopovych

Pavel Kruchina CTO 12.07.2013 10:18

Я — нет. Если руководитель не знает программирования, то может и возьмёт.

И да, мы с вами о толпах бродящих говорим, а не о принятии на работу.

Відповісти

Підтримати

Victor Prokopovych

Євген Козлов Front-end developer в SoftServe 12.07.2013 12:40

...и без знаний. об этом ведь речь? потому что я знаю success story о людях, которые вообще фиг знает откуда пришли в IT.
P.S. нет, не пешком из Владивостока.

Відповісти

Підтримати

Pavel Kruchina CTO 12.07.2013 13:02

И без знаний. Просто для многих «программисты — зажравшиеся мажоры современности», так что попасть в ИТ пытаются все подряд (типа — не работа а малина, платят дохрена).

К людям, которые полноценно переквалифицировались это не относится

Відповісти

Підтримати

Євген Козлов

anonymous 12.07.2013 13:07

-

Відповісти

Підтримати

Євген Козлов Front-end developer в SoftServe 12.07.2013 14:36

ну, дык, тогда никакой уникальной ситуации.
шо в юристы совсем недавно ломились люди с купленными дипломами, заработать на «евроремонтах» пытались люди, которые не знают, за какую сторону ответртку брать, так и в ИТ ломятся ща все подряд.
Ну, а собеседования на что? Пусть ломятся, в данном случае, действительно — время покажет.

Відповісти

Підтримати

noname fordou 07.10.2013 12:06

не работа а малина, платят дохрена

— а разве не так ?

Відповісти

Підтримати

Grez 12.07.2013 14:53

На самом деле был замечательный дельфи, куда порог вхождения, имхо, ниже пхпшного. Жаль дельфи уже никому не нужен...

Відповісти

Підтримати

Pavel Kruchina CTO 12.07.2013 15:15

Да нет, я думаю просто программы написанные человеком сразу после «входа» просто никому не нужны.

А так — на С# тоже можно мышкой программировать :)

Відповісти

Підтримати

Grez

Java Adept 12.07.2013 15:44

WinForms не сдохли еще?

Відповісти

Підтримати

Pavel Kruchina CTO 12.07.2013 15:46

А фиг их. Но то, что делали новички на делфи — вполне и там можно делать.

Відповісти

Підтримати

Grez 12.07.2013 16:34

Ну какраз во времена дельфи — вполне нужны были. Дешовые горе-пых программисты, тоже, иногда нужны бывают.

Відповісти

Підтримати

Alex Ua 11.07.2013 14:14

здесь все только и делают что ржут....я сам топик кинул что хочу стать фронт эндером))а половина только ржут...посмотри курсы СПЕЦИАЛИСТ JAVA одни из самых-самых.Могу ссылку выложить.

Відповісти

Підтримати

Эдик Драуд

Pavel Kruchina CTO 11.07.2013 16:23

чувак, когда на первом курсе мне захотелось найти работу, я открыл сайт с вакансиями, посмотрел каких больше всего, посмотрел основные требования — и вперёд. По требованиям учебники гуглятся на-ура.

А с вас ржут, потому что Вы ждёте решения на блюдечке с голубой коёмочкой. Ну и проф. снобизм, не без этого.

Відповісти

Підтримати

СНИКЕРС 22.07.2013 14:45

И сколько у вас потрачено времени для подготовки к первому собеседованию ?

Відповісти

Підтримати

Pavel Kruchina CTO 22.07.2013 15:10

Смотря как считать. Учебники я штудировал 3 месяца. Собственно к собеседованию не готовился вовсе (так и повелось — к собеседованиям я готовлюсь, только если участвую в них со стороны работодателя).

Відповісти

Підтримати

СНИКЕРС 22.07.2013 15:16

А ваша специализация ?

Відповісти

Підтримати

Pavel Kruchina CTO 22.07.2013 15:34

... кучу раз менялась :)
Ну а первую свою работу я искал как php-программист.

Відповісти

Підтримати

СНИКЕРС 22.07.2013 15:53

Ну главное найти себя ... Всё верно !!!

Відповісти

Підтримати

junkie 26.03.2018 00:03

это знак стадного инстинкта, которым пытаются подкормить чсв.

Відповісти

Підтримати

Ivan Pomidorov 11.07.2013 16:26

Чувак, уже почти четыре недели прошло, уже бы смог выучить Core Java на хорошем уровне.

Відповісти

Підтримати

Эдик Драуд

Ще 19 коментарів

Oksana Chuiko Software Engineer в Pure Storage 13.08.2013 21:49

некоторые по несколько лет учат и не могут

Відповісти

Підтримати

Gremlin 13.08.2013 22:11

некоторые по несколько лет учат и не могут

это нормально.
выучить язык Джава и научиться работать на Джаве
это примерно как
получить права и научиться водить машину.
Нужно время.

Відповісти

Підтримати

noname fordou 07.10.2013 12:09

хз, я вот за три месяца только половину Thinking in Java прочитал во время поездок метро. А реально его надо еще разок перечитать + сделать упражнения. Т.е. если не в рабочее время, то на java сore нужен год. При том что я давно в IT.
А вы тут про нулячего и за 4 недели (пусть и полных, а не только утром и вечером) — нереально, разве что по верхам совсем.

Відповісти

Підтримати

noname fordou 07.10.2013 14:54

оффтоп: Егор, а зачем Вы ушли с последней работы ?
судя по какому то из комментов, платили Вам там пристойно (2500+ не в киеве).
Не уж то во фриланце так шоколадно? Имхо, в последнее время, офис выгоднее ...

Відповісти

Підтримати

Ivan Pomidorov 07.10.2013 17:37

Скажу больше, gross у меня было больше 3к usd, а ушел я по личным причинам.
Во фрилансе развития больше, денег немногим больше, работать приходиться тоже больше чем офисе, работа ведь идет на результат. Говорят что потом твое портфолио будет работать на тебя, можно пиариться, конкурировать с кучей народу.

Відповісти

Підтримати

noname fordou 07.10.2013 18:51

за 2 года опыта не кисло так :) быстро обучаетесь ? а чо вообще надо чтоб так же рубить в Java в Киеве?

Відповісти

Підтримати

Ivan Pomidorov 07.10.2013 18:56

Я хз, оно само так получилось. Но знания надо таки иметь хорошие. Желательно кроме Spring/Maven/Hibernate/MySQL, еще и стандартный стек JavaEE(jax-rs, ejb, jms) и на фронтенде уметь лабать, на уровне выше чем нагромождения коллбеков в jquery. Надо еще задротом не быть.

Відповісти

Підтримати

noname fordou 07.10.2013 19:16

за 2 года и

Spring/Maven/Hibernate/MySQL

и

стандартный стек JavaEE(jax-rs, ejb, jms)

и

на фронтенде уметь лабать, на уровне выше чем нагромождения коллбеков в jquery.

как то не вяжется с

еще задротом не быть

Відповісти

Підтримати

Ivan Pomidorov 07.10.2013 19:22

Не путай инвестиции в себя, и задротство. Задрот — социально неприспособленный человек. А усваивание большого обьема знаний это часть твоей работы, тебе ведь надо конкурировать с кучей людей с опытом зачастую большим чем у тебя.

Відповісти

Підтримати

noname fordou 07.10.2013 19:31

довольно сложная задача нарыть проекты с сильным упором на JS, да еще чтоб бекенд прогера без сильной подготовки по JS пускали на фронт пилить.

Відповісти

Підтримати

Ivan Pomidorov 07.10.2013 19:34

Да это редкость. Но можно и петпроджекты делать, чисто для тренировки.

Відповісти

Підтримати

noname fordou 07.10.2013 20:16

как пример — что такого можно сделать на фронте крутого в пет проекте, что требует больше чем нашлепать лапши в jQuery ?

Відповісти

Підтримати

Ivan Pomidorov 07.10.2013 20:24

Сделай форум как single page application например. Выбери фреймворк вроде backbone.js или angular.js и педалируй.

Відповісти

Підтримати

noname fordou 07.10.2013 20:31

Выбери фреймворк вроде backbone.js или angular.js

— ну, я б не сказал что на фреймворке станешь трушным JS кодером — скорее научишься пользоваться фреймворком.

Відповісти

Підтримати

Ivan Pomidorov 07.10.2013 21:01

superherojs.com

Вот классный ресурс.

Відповісти

Підтримати

Євген Козлов Front-end developer в SoftServe 07.10.2013 23:59

не сказал что на фреймворке станешь трушным JS кодером — скорее научишься пользоваться фреймворком

не вижу, что мешает это мнение на любой язык эскалировать.
да и вообще, к черту фреймворки, даешь велосипеды!

Відповісти

Підтримати

noname fordou 08.10.2013 00:24

да и вообще, к черту фреймворки, даешь велосипеды!

— не говорил я такого, вы перекрутили. ну вот ипользуя Jquery можно вешать лапшекод, почти не зная JS, просто нагугливая солюшены. тот же angularJs можно базово юзать ВООБЩЕ не зная JS — а разбирать как он устроен изнутри, не факт что посильная задача для новичка.

а знать как определяются области видимости в JS, а также как можно реализовать наследование разными методами и в чем их отличие — скорее только если есть куски работы на чистом JS а не на фреймворке.

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 08.10.2013 00:37

слабо себе представляю, как без понимания областей видимости строить код на backbone(с angular не работал, знаю понаслышке), где события — практически единственный способ из вью о чем-то дать знать.
ну, положим, прототипное наследование успешно укрывается .extend(), а остальное-то? коллекции со всякими map/filter.

можно базово юзать ВООБЩЕ не зная JS

можно живой пример? ну, не просто форма, которая бесполезно синхронизируется с формой. А, пускай не REST, а GET/POST сохранение данных/подтягивание при загрузке.
я бы понял, если б претензии были в адрес ExtJS. а тут — структуризирующие фреймворки.

Відповісти

Підтримати

Назар Казымов Java Developer 07.10.2013 18:00

))))))))))))))

Відповісти

Підтримати

Кирилл Нечаев 26.06.2013 03:08

LOL
человек пишет, что _знает_ asm и Си, и «слабо знаком с ООП». Это такая шутка?

Відповісти

Підтримати

anonymous 26.06.2013 07:11

В эмбеддед ООП практически не используется

Відповісти

Підтримати

Кирилл Нечаев

Ще 3 коментарі

Кирилл Нечаев 26.06.2013 11:17

На ассемблере объяснять ту часть, что в памяти происходит при ООП, ну, минуты две. Еще минут пять, что скрипт в редакторе кода делает.

Відповісти

Підтримати

proger 26.06.2013 16:07

На ассемблере объяснять ту часть, что в памяти происходит при ООП, ну, минуты две. Еще минут пять, что скрипт в редакторе кода делает.

угу. а потом полгода учить названия паттернов

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 26.06.2013 17:08

а вот здесь-то и надо выжимать всю мощь из того, что есть под руками.

Мы же не перед окном терминала по последовательному порту прямо на железе ваяем? IDE, плагины, редакторы, комп обновить, линк в инет потолще, свои расширения написать... Не менее одного часа в день на то, чтобы еще что-то у себя автоматизировать.

Відповісти

Підтримати

gshcherb 26.06.2013 07:35

Вы случайно не из тех, кому С и С++ это одно и то же? :)

Відповісти

Підтримати

Кирилл Нечаев

Ще 7 коментарів

Кирилл Нечаев 26.06.2013 11:22

их не спутаешь, у них комментарии разные.

Відповісти

Підтримати

Mikhail Boiko SE в NVIDIA 26.06.2013 11:28

Что значит комментарии разные?

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 26.06.2013 11:35

приплюснутый ввел //

Відповісти

Підтримати

Mikhail Boiko SE в NVIDIA 26.06.2013 11:57

Вот эта странная команда

find linux-git -type f -name «*.c» | xargs grep ’[^:]//’ | wc -l

выдала мне странный результат 16707
Что бы это значило?

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 26.06.2013 12:21

не заморачивайтесь. Мой ответ был шутливый. Комментарии это те тонкости, которые знаешь при условии, что опыта хватило на компиляторы и того, и другого сорта.

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 07.10.2013 17:29

Потому что С99 :)

Відповісти

Підтримати

Egon Schiele 07.10.2013 14:36

Этапять!

Відповісти

Підтримати

Кирилл Нечаев

idOne Арбузный 08.07.2013 16:52

ЛОЛ, покажите нам ооп на асме

Відповісти

Підтримати

Кирилл Нечаев

Ще 8 коментарів

Pavel Kruchina CTO 08.07.2013 17:01

Как говорил один умный дядька — обьектно-ориентированно можно программировать и на асме, просто будет больше геммороя.

ООП — это парадигма, а не инструменты.

Відповісти

Підтримати

idOne Арбузный

idOne Арбузный 08.07.2013 17:14

один умный дядька

Андрей Аксенов?

Відповісти

Підтримати

Pavel Kruchina CTO 08.07.2013 17:20

Не, один из моих старших коллег, вот только не помню кто. Я распинался на тему чем один язык лучше другого (а-ля там ООП есть, а там оно плохое), и получил вопрос в лоб — «А на C[без плюсов] ты обьектно писать можешь?». Вот тут то я дзен и понял :)

Відповісти

Підтримати

idOne Арбузный

Java Adept 08.07.2013 17:50

«А на C[без плюсов] ты обьектно писать можешь?». Вот тут то я дзен и понял :)

Костыли а не дзен

Відповісти

Підтримати

Кирилл Нечаев 08.07.2013 18:13

А что, есть сомнения в реализации?
Гугл : "OOP assembler"
Но если есть _сомнения_, то ассемблером и машинной памятью Вы не мыслите. Так зачем Вам показывать?

К мысли об ООП в ассемблере приходят, когда надоедает выписывать, как размножать программные структуры программным же кодом. Если структуры в памяти не размножаются, то ООП не нужен.

ООП имеет две части: одна это исполняемый код, а вторая это метаязык для редактора, в котором пишут код. Значит, человеку, который сказал, что знает и умеет ассемблером, всего лишь нужно понять как кто-то реализовал вторую часть. В си++ это вот так, и скрыто в компилятор. В пайтоне вот так, и тоже скрыто. Можно и самому набросать, скриптами сверху редактора. Делов-то.

Відповісти

Підтримати

idOne Арбузный

idOne Арбузный 08.07.2013 23:02

с гуглом я работать умею, я про конкретный пример спрашивал.
Д’Артаньяньте до конца, без отсылок к авторитетам.

Вместо этого полотна — листинг с кодом

Відповісти

Підтримати

Кирилл Нечаев

Valentin Nechayev архімаггриб в Дарницькі печери 07.10.2013 17:17

ЛОЛ, покажите нам ооп на асме

Была в середине 90-х одна знаменитая книжка про TASM, и там была глава про ООП на ассемблере.
TASM позволяет описывать структуры, причём вложенные, сам вычисляет смещения их полей, позволяет в макро генерировать названия символов (меток). Это уже инкапсуляция и наследование.
Для полиморфизма достаточно введения виртуальных функций — макро по их вызову по имени поля — хранилища указателя писалось в два счёта, неважно, с выделенной VMT или без неё.

А Вы, видимо, путаете по незнанию ассемблер с автокодом (так принято называть средства перевода мнемонической записи команд в машинный код, не поддерживающие макросредства), и в лучшем случае используете первый как второй.

Відповісти

Підтримати

idOne Арбузный

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 07.10.2013 17:28

Блин, далеко лезть в загашник и искать CD-R на котором есть моя прога — CD Player for Windows 3.x на ООП асме :) Был там VMT настоящий и ещё оно хорошо сливалось и было совместимо с Borland C/C++ 5.0 32 битовым.

Відповісти

Підтримати

Valentin Nechayev

Grez 12.07.2013 14:57

Кстати, не смешно.
Переучивание стилю работы дело хитрое.
Имел опыт работы с такими бывшими Сишниками. Которые суть ооп кагбе понимали, но упорно продолжали писать «низкоуровневую лапшу».

Відповісти

Підтримати

Кирилл Нечаев

Ще 91 коментар

Кирилл Нечаев 13.07.2013 16:00

Сишники, да, могут быть такими.

Но не те, которые в Си видят язык метапрограммирования исходного кода на ассемблере или даже в машинном коде. Дело в том, что когда я носил перфокарты своих программ на втором курсе вуза, то Фортран-77, который я изучал, назывался транслятором, а исходным кодом назывался текст на ассемблере. Затем другое поколение стало называть исходным кодом текст в языке Фортран или вариации его типа Паскаль, Алгол, Си, ...

Если начинать знакомиться с программированием с Си, то уже нет разницы, можно начинать и с ВижуалБейсика, с Паскаля, или Пайтона. Это уже всё равно скриптовый образ мышления, он и закрепляется как навык.

ООП тогда, для такого Сишника, — это надстройка, сильно изменяющая его скриптовый образ мышления на мышление классами. И здесь появляется разрыв в мышлении у скриптовика. Он начисто теряется, что происходит в редакторе кода.

Дело в том, что на ООП мы пишем в тексте про классы, а все действующие сущности мы объективируем в сознании в виде объектов. Но объектов в исходном тексте — нет. В процедурном же языке, в отличие от, действующие сущности возникают как раз в тексте кода, и по тексту же кода можно проследить, как они действуют, и остановиться на каждой детали взаимодействия, глядя в текст.

Значит, мы имеем: разрыв № 1 в мышлении Сишника, в части представления им памяти машины, ЦПУ и структур данных в этой памяти (Си, например, прячет от программиста один действующий стек, и делает вид, что никакого этого стека у программиста нет. Если программист хочет, может создать свой, виртуальный). Наш Сишник инвалид в этой части.

В ООП тот же Сишник становится вторично инвалидом по причине разрыва № 2 его мышления между написанным текстом о классах и необходимым образным представлением о рождающемся объекте, которого в тексте (сюрприз для Сишника) — нет.

ООП в этом смысле недоделанный инструмент. Скажем, стек локальных и временных данных от нашего «Сишника из Си» скрыт полностью конструкцией языка, то есть, держать его мысленный образ вообще не нужно. Все шаги он следит по тексту программы, и не попадает в происходящее в стеке. А вот в ООП, узнать, что происходит в рождающихся объектах и как они «общаются», нужно отслеживать и держать в голове. Но для этого нужно лазить в тексте программы по всем объявлениям классов, а не объектов. Но всё что реально происходит в машине, происходит между объектами и с объектами.

В этом смысле ООП в программировании видится как какая-то действующая конструкция, от которой забыли убрать строительные леса и материалы, неумело и наспех сколоченные, и их так много, что они закрыли саму конструкцию. И чтобы понять конструкцию, ее надо представить без лесов. Люди справедливо шарахаются от вида этого монстра.

Если наш Сишник не хочет слышать о стеке локальных данных, то ему также страшно не понравятся и эти строительные леса в тексте его программы. С этой стороны, его понять можно, а мы и слышим, как Сишники хают Приплюснутых. С другой стороны, любой, кто к скриптовому языку Си приходит как удобному средству автоматизации того, что он уже просто устал делать средствами ассемблера, эти войны кажутся легкомысленными и бесплодными спорами. Масштаб мелкий.

Есть насущная необходимость для скриптовиков сделать ООП чистым и ясным. Плохой пример есть, Java и C++.

Но на безрыбье, как говорится...

Відповісти

Підтримати

Grez

Ivan Pomidorov 15.07.2013 13:48

В Java какбы эталонный, чистый, классический ооп. Скорее всего ООП это идея которая устраивает не всех, для кого-то она может показаться плохой. Но реализация ООП как, например, в Руби это именно ruby-way, а не OOP.

Відповісти

Підтримати

Кирилл Нечаев

Kirill Sablin Developer 15.07.2013 13:52

Точно так-же можно сказать, что в java — это java-way.

Відповісти

Підтримати

Java Adept 15.07.2013 15:43

В Java какбы эталонный, чистый, классический ооп

Поржал, пиши еще

Відповісти

Підтримати

Кирилл Нечаев 15.07.2013 18:36

Мы желаем писать программы очень кратко и емко, а машина должна исполнить точно то, что мы подразумеваем.

Си, Плюсы и Джава необычайно болтливы. Должен быть такой переключатель в языке, «новичок-средний-профи».

Профи всё понимает правильно. Если он пишет
Div(d,Sub(Add(a,b)),c))
То он точно знает, что никогда, никогда(!) не возникнет именно здесь ошибка деления на ноль. Просто так написано у него всё, что это получается автоматически.

От новичка требуется указать интерпретатору, как интерпретировать его байты, что он написал в текст программы. И еще обернуть всё в try-exception. Потому что от новичка можно ждать всего, чего угодно. Например, он путает клавиши, невнимательный, учился программированию не в вузе, а по википедии. По переключателю «новичок» интерпретатор компилятора должен полагать, что перед ним недоумок.

Если профи напишет байты в ASCII такие: CAFE, и куда-то их вставил в текст программы, то это точно то, что он хотел сделать. Компилятор не должен паниковать. Сказано, делай! Если в подпрограмму Add, значит, это число. Если в подпрограмму CatStr, значит это строка.

Но профи пишет для компилятора в одном режиме: ты придурковатый новичок, путающий клавиши и буквы.

Для новичка вводится тип данных. Тип данных, это переключатель в интерпретаторе, отвечающий на вопрос: какая функция будет преобразовывать в двоичный вид порцию литер.

В исполняемый файл все числа и команды в компьютере пойдут только в одном виде, бинарные. Вопрос лишь в том, в чем выгоднее их оставить до самого процесса счета (компьютер в переводе на русский — вычислитель. А фотографии компьютеров 20-х годов это фотографии людей).

Пишет новичок тип Int? Включаем преобразование у интерпретатора ASCII --> Int --> BIN -->STORE. А может, строка? Ничего не включаем, храним как есть, побайтово. Он пишет 10? Как это понимать интерпретатору? Потребуем, чтобы новичок дал команду:

Написание   бинарное представление
---------   -----------------------
b`dec`10    0000 1010
b`bin`10    0000 0010

Новичок имеет непоследовательное мышление, и как следствие, код. Он почти ничего не соблюдает, никаких правил не придерживается. Учить его этому нужно лет пять. А здесь его услуги нужны уже, и «еще на вчера». Новичок может посчитать что эти 4 байта ASCII --- цифры в бинарном виде. Профи не может. Он просто знает, что _здесь_ байтам ASCII нечего делать.

Профи просто помнит, что здесь должно быть. Ему не нужно оставлять в тексте для себя эти записки. Так пишут в ассемблере и системе Форт. Там нет никаких типов, это образ мыслей для профи.

Попытки избавиться от типажного многословия для новичков приводят к динамическим типам. Но подводные камни знают все. Те кто путает клавиши и путается в мыслях, напутает и здесь. Кроме того, эту динамику надо делать во время счета, а не компиляции. Для одноразовой утилитки — самое то. Для машины, молотящей числа (web server), это необычайная глупость.

Подход системы программирования ООП для профи должен быть совсем другим, чем для новичка. Профи должен быть в три раза минимум продуктивнее просто потому, что он больше думает и смотрит на задачу, а когда кодирует, то очень «опасно», кратко, и однозначно.

Відповісти

Підтримати

Ivan Pomidorov 16.07.2013 11:48

Почему на Форте тогда не пишут энтерпрайз приложения, умник? А вообще вышенаписанное — демагогия.

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 18.07.2013 07:30

Мне показалось, или Вы занервничали? )))

There is no syntax, no redundancy, no typing. There are no errors that can be detected. ...there are no parentheses. No indentation. No hooks, no compatibility. ...No files. No operating system.

Может звучать обидно, но причина банальна — Форт не язык, а система написания языков, фактически, это написание компилятора, осилят это — единицы. В сравнении с ним С++ это побрякушка.

Зачем Вам Форт? )))

Відповісти

Підтримати

Valentin Nechayev архімаггриб в Дарницькі печери 07.10.2013 17:28

Форт не язык, а система написания языков,

Тогда любой язык, где можно определять функции и подпрограммы — это система написания языков.

Метапрограммирование на Форте обычно выливается в дикий изврат, и лучше его там не пробовать.

Зачем Вам Форт? )))

Так давно известно, что за пределами его узкой ниши он никому не нужен. Везде есть средства лучше.

Хотя для того, чтобы быть хорошим программистом, надо знать Форт.

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 11.10.2013 00:21

Тогда любой язык, где можно определять функции и подпрограммы — это система написания языков.

Сегодня это не так. Давайте поразмыслим, что происходит с так называемыми языками программирования. У процессора х86 тысячи инструкций, как ключевых слов. А в языке Си их сколько?

Попробуйте детально описать узкоспециализированную прикладную задачу через первый шаг: сначала сократить словарь используемых понятий с пары тысяч до пары десятков. А потом плести кружева из глобальных переменных, имен функций. И для чего первый шаг?

Хотя для того, чтобы быть хорошим программистом, надо знать Форт.

Каждый пишет свой Форт, поэтому лучше сказать, написать свой собственный интерпретатор над данным вычислителем, что по сути, компилятор. Только это не чужой компилятор на чужих идеях, а точное отражение своего понимания, какие объекты должны появиться в системе. Но для этого нужно понимание вычислителя, а простые пользователи компиляторов-интерпретаторов к этому и не готовы, и заражены каким-то страхом перед интерпретатором под названием процессор.

Один из ярких представителей напуганных сложностью интерпретатора это Л.Торвальд. Он предпочел остаться в убогом мирке сущностей скрипта Си. Тем же путем пошли и создатели Джавы, приняв, что их интерпретатор построен над убогим процессором, цена которому 1доллар еще позавчера.

Відповісти

Підтримати

Valentin Nechayev

Valentin Nechayev архімаггриб в Дарницькі печери 11.10.2013 09:09

> У процессора х86 тысячи инструкций, как ключевых слов. А в языке Си их сколько?

> Попробуйте детально описать узкоспециализированную прикладную задачу через первый шаг: сначала сократить словарь используемых понятий с пары тысяч до пары десятков. А потом плести кружева из глобальных переменных, имен функций. И для чего первый шаг?

Верно, ни для чего. Потому что эти «тысячи слов» появляются позже постановки задачи, её алгоритмизации и перевода на формальный язык. Именно задача является основной (если Вы, конечно, пойдёте по пути >99.99% прикладников и станете решать заказанные задачи, а не исследовать в качестве исходной постановки эффекты сочетаний команд). И тот же Си — промежуточное средство для представления алгоритма в виде, который становится пригоден для обработки машиной. А переводит компилятор этот код в одну команду (есть такие теоретические разработки — процессор с 1 командой на всё) или в «тысячи их», как на x86 — вопрос уже вспомогательный.

А Вы считаете, как я понял, этот же вопрос главным, а направление работы — почему-то противоположным. Я верю, что оно может помочь в ряде специфических задач, типа анализа полиморфного вируса. Но в остальных случаях оно зачем? Тот же x86 это результат практического баланса компромиссов по тысячам параметров (и далеко не идеального компромисса).

> Каждый пишет свой Форт, поэтому лучше сказать, написать свой собственный интерпретатор над данным вычислителем, что по сути, компилятор.

Гм... и зачем мне писать компилятор? Нет, конечно, «не программист тот, кто не пытался написать компилятор», но это вопрос саморазвития, а не работы на дело.

> Только это не чужой компилятор на чужих идеях, а точное отражение своего понимания, какие объекты должны появиться в системе.

Я подключил диск по USB. Я должен знать и описать в деталях весь стек USB, чтобы точно отражать, какие объекты должны появиться в системе? Я всё-таки думаю, что в основном мне не надо туда лезть.

А в собственной прикладной области — а что, я не контролирую на том же C++? Контролирую, и не хуже (главное, удобнее; если разбираться со стеком, то мгновенно тонешь в ненужных деталях).

> Но для этого нужно понимание вычислителя, а простые пользователи компиляторов-интерпретаторов к этому и не готовы,

Это вопрос обучения, а не основной практической работы. «Понимание вычислителя» приходит, например, в вузе, при работе на ассемблере и ручном пересчёте в 16-ричную систему. Но при абстрагировании на уровень, например, как написать SQL запрос с тремя вложенными JOIN, такое понимание ничем не поможет, а скорее всего будет даже мешать. И если «простой пользователь» не знает, чем отличается PUSH от XCHG, ему это не мешает правильно строить базы данных:) А Вы, похоже, предлагаете свести всё на уровень байтов и команд. Зачем?

> Один из ярких представителей напуганных сложностью интерпретатора это Л.Торвальд. Он предпочел остаться в убогом мирке сущностей скрипта Си.

Вы корёжением фамилии решили изобразить своё презрение к его убогому миру? Пока что Вы показали этим только убогость своего наезда. Но задам таки встречный конструктивный вопрос: а что именно Вы предлагаете взамен Си для ядра Linux? Форт или ассемблер?

Відповісти

Підтримати

Кирилл Нечаев

Valentin Nechayev архімаггриб в Дарницькі печери 07.10.2013 17:30

Си, Плюсы и Джава необычайно болтливы. Должен быть такой переключатель в языке, «новичок-средний-профи».

После случая с точкой в DO в Фортране в это никто из руководителей разработки не верит, и правильно. Профи точно так же будет ошибаться, как и новичок, но его ошибки труднее найти.

Відповісти

Підтримати

Кирилл Нечаев

Blitz .net Developer 22.07.2013 15:40

C++ like ООП может и класический, но не эталонный ни разу.

Відповісти

Підтримати

Valentin Nechayev архімаггриб в Дарницькі печери 07.10.2013 17:22

Всё наоборот. Он эталонный (на сейчас), но не классический. Потому что классический это стиль Simula/SmallTalk — стиль «рыб в аквариуме»: жизненные процессы всех объектов независимы и параллельны, а между ними идёт обмен сообщениями, которые состоят только из примитивов, но не объектов. То, что видим изначально в Apple Object Pascal, а далее в C++, Java, C# и так далее — это смешение идеи инкапсуляции (достигающей предела в Simula/etc.) с проекцией «объекта» на структуру Си, и развитие уже на этом смешанном базисе.

Відповісти

Підтримати

Blitz

Valentin Nechayev архімаггриб в Дарницькі печери 07.10.2013 17:38

то Фортран-77, который я изучал, назывался транслятором, а исходным кодом назывался текст на ассемблере.

Это Вам какой-то особый, выдержанный в густом рассоле мамонт попался. Потому что в более широких кругах исходным кодом называли таки исходный код. Начиная с первых компиляторов. А во времена Фортрана-77 уже C++ вовсю расползался по миру.

Значит, мы имеем: разрыв № 1 в мышлении Сишника,

Не было ни одного разрыва! (tm)
Вам не кажется случайно «разрывом» различие между формальными и фактическими параметрами функции? Или между переменными в файле и их прочтёнными версиями?
А ведь тут такие же «пропасти», а на самом деле, просто шаги развития.

и необходимым образным представлением о рождающемся объекте, которого в тексте (сюрприз для Сишника) — нет.

struct s { int a; char *b; }; struct s* sp = calloc(sizeof(*sp)); sp->a = 1; sp->b = "прювет лунатикам";

Ой, я сделал разрыв. У меня в тексте не было ни единого экземпляра переменной типа struct s! Вся Украина смотрит в ужасе!

IMHO, те, кто не в состоянии пройти этот барьер, не имеют права писать и на Си. Из них могут получиться отличные программисты на Фортране, 1С или даже Лиспе. Но не на Си.
А для нормального сишника ничего «разрывного» в ООП не должно быть.

Есть насущная необходимость для скриптовиков сделать ООП чистым и ясным.

Есть предложения, как это сделать? Или хотя бы внятное описание, что на что заменить?

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 11.10.2013 00:05

в более широких кругах исходным кодом называли таки исходный код.

Тех, кто называет исходным кодом текст сценария, Си, Паскаль, Бейсик, Пайтон, я называю пользователями компиляторов/интерпретаторов. В отличие от тех, кто в состоянии написать собственных компилятор или кто просто правильный программист.

Уверенный пользователь сложнейших офисных пакетов имеет объем знаний сравнимый с программистом. Но это пользователь, и никакой не программист. Программист отличается от пользователя компилятора тем, что думает в понятиях областей памяти и инструкций процессора, того, что лежит ниже интерфейса программы. Код, который программист пишет под компилятор или интерпретатор, это просто команды-макросы которые дадут исходный код для вычислителя.

Вычислитель, казалось бы, один, процессор. Но это тоже всего лишь интерпретатор, не отличающийся от Бейсика или Пайтона. Он выполняет шаг за шагом декодированные инструкции. Значит, и это всего лишь интерфейс, придуманный незнакомыми нам инженерами, разработчиками вычислителя.

Как пакет MS Office навязывает образ мышления, так и компилятор Си или Бейсика навязывает вам не ваш образ мышления, и на свет рождается очередной пользователь компилятора. Его не интересует, что выдает компилятор, он этот текст не рассматривает, и в него не вмешивается. Если компилятор отказывается создать кусочек картины в бинарном образе, то пользователь не изменяет функцию в компиляторе, заставляя его сделать требуемое. Потому что это пользователь.

Вообще, сегодняшние объявления на работу надо писать так:

Вакансии:
1. Секретарша. Уверенный пользователь офисных пакетов.
2. Программист. Уверенный пользователь интерпретатора Джава (Си).

Что надо сделать в направлении более чистого ООП? Языков должно быть много. Для каждой задачи свой язык, ориентированный на данную задачу. Да, уникальный, если что. Всё стандартное это академическое, для обучения принципам. Реальность заставит делать перенастраиваемое оборудование, компиляторы-интерпретаторы под одно, данное изделие.

Мне лично, кажется, что компьютеры простаивают.

Відповісти

Підтримати

Valentin Nechayev

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 11.10.2013 00:12

Программист отличается от пользователя компилятора тем, что думает в понятиях областей памяти и инструкций процессора, того, что лежит ниже интерфейса программы.

Правильно, хороший программер компилирует _исходный код_ в голове, он знает, что получит на выходе с большой вероятностью.

Код, который программист пишет под компилятор или интерпретатор, это просто команды-макросы которые дадут исходный код для вычислителя.

Хорошо, а если я напишу так ?

#pragma aux __test = "mov eax,dword ptr [x + eax + ebx]"
void test( void )
{
    __test();
}

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 11.10.2013 01:02

За такую вставку будут выставлять порицание. В этом резон какой-то есть, ведь внутри мира объектов и правил языка Си эти команды — чужеродные понятия. Те, кто командует программистами, хотят унификации их продукта, и для этого идут по примитивному пути: режут словарь скриптового языка и заставляют писать на его примитивном множестве.

В итоге, если была бы возможность подняться невидимым духом над Землей, и заглянуть из-за плеча программистам, то мы увидим картину, как десятки тысяч людей одновременно пишут одни и те же функции для одного и того же компилятора с незначительными отличиями. Тысячи каждый день занимаются переизобретением колеса. Армия ремесленников.

Программисты-ремесленники очень дорого обходятся заказчику.

Відповісти

Підтримати

Valentin Nechayev архімаггриб в Дарницькі печери 11.10.2013 09:23

> Тех, кто называет исходным кодом текст сценария, Си, Паскаль, Бейсик, Пайтон, я называю пользователями компиляторов/интерпретаторов. В отличие от тех, кто в состоянии написать собственных компилятор или кто просто правильный программист.

Я в состоянии написать свой компилятор (и даже писал). Должен ли я всегда пользоваться только им? Или лучше применить gcc/clang/etc. с тысячами человеко-лет, вложенных в них и которые оптимизируют типичный случай лучше и быстрее?

Или Вы мне тут предложите Форт, который по нынешним временам сам в лучшем случае объектный код (потому что для чего-то сложного программист задолбётся считать смещения в стеке) и который на современном железе в десятки раз тормознее сишного выхода за счёт постоянных call/ret? Спасибо, я лучше пешком постою.

> Программист отличается от пользователя компилятора тем, что думает в понятиях областей памяти и инструкций процессора, того, что лежит ниже интерфейса программы.

Во-первых, это, по старой классификации, только системный программист. Да, системный программист отличается тем, что он 1) в состоянии думать «в понятиях областей памяти и инструкций процессора» и 2) делает это, когда нужно. Но он не обязан постоянно думать об этом. Например, да, я знаю, что функция, скомпилированная отдельно получит первый параметр в rdi, второй — в rsi, и так далее; но я уже не знаю и не хочу знать (если не полезу в тяжёлую отладку), как именно заинлайнил её компилятор в конкретном случае. Вы же предлагаете мне думать об этом каждый раз — и что, мучительно гадать, куда же блин попадёт параметр — в r8 или rcx? Спасибо, не надо.

Прикладной же программист может трижды плевать с высокой колокольни на детали реализации (он может даже не знать архитектуру процессора), пока, например, у него вычисления идут в десятичном виде с гарантированными 15 знаками после запятой. Зачем ему это? Ему важнее алгоритмическая оптимизация и устранение эффектов округления, например.

Вы говорите, Вы зовёте таких «пользователями компиляторов»? В христианстве такое называлось — гордыня.

Извините, дальше скипнул, ибо не могу воспринимать это хоть как-то всерьёз. Я верю, что Вы пытаетесь найти что-то для себя и пишете эти сообщения как способ сформулировать свои мысли. Только вот мне кажется, что Вы выбрали заведомо неверный путь. Решение должно найтись «перед носом» в ходе практической работы. А тыкая пальцем в небо Вы не получите ничего кроме теологии, которой, собственно, тут и занимаетесь.

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 12.10.2013 11:03

Я в состоянии написать свой компилятор (и даже писал). Должен ли я всегда пользоваться только им?

Вы не придали значения моим словам: для чего, для какой конкретно задачи Вы написали компилятор? Мое предположение, что для какой задачи пишется, для этой задачи и используется. Появилась новая задача, требуется новый компилятор-интерпретатор, например, путем модификации существующего.

Причина та же, по какой разные предметные области используют разные понятия и имеют разную терминологию. Попытка отобрать у фармацевтов, авиамехаников, моряков, математиков... всю их терминологию и дать вместо нее два десятка понятий в качестве универсального языка обречена на осмеяние. Им придется выпиливать из убогого подмножества всё те же понятия и давать старые термины. Эта же глупость делается, когда пишется универсальный компилятор. Его задача — демонстрации, сложности «хеллоуорлд», основных принципов в академические часы.

Или Вы мне тут предложите Форт, который ... в десятки раз тормознее сишного выхода за счёт постоянных call/ret?

Вы для ознакомления с Фортом взяли статью некомпетентного автора. Первое основание для разработки Форта — бардак в понятиях функция и подпрограмма, и их огромные накладные расходы (см. Бэкус, узкое место, bootleneck в современном программировании).

В Форте нет call/ret, не используют. call/ret созданы производителями процессоров для поддержки парадигмы Алгола. Процессоры трансформируются под существующие ЯВУ-компиляторы-интерпретаторы. Для сообщества Форта используется иная парадигма.

Во-первых, даже изучая ассемблер, люди на самом деле изучают парадигму скриптовых языков, произошедшие от Фортрана или Паскаля. Сишник на ассемблере всё равно напишет сишную программу, и сделает это во многих случаях хуже интерпретатора Си. Ассемблер это уже язык высокого уровня, и он прячет многие возможности от программиста, поскольку разрушает арифметические зависимости в своей записи). У программирующих в скриптовом стиле Си или Паскаля нет четкого различия, что такое программа, подпрограмма и функция. Под паскале-подобные языки разработан процессор, под него же ассемблер имеет парадигму опять же паскаля, и наконец, человек далее продолжает изучать Паскаль или Ада, Фортран или Си.

Теперь о различиях. В Форте мыслят программами, а в паскалеподобных скриптах — функциями и подпрограммами. При этом Форт это не скрипт, а компилятор-интерпретатор и одновременно само приложение. Там где сишник или пользователь иного интерпретатора мыслит функциями, и не думает о ее накладных расходах, фортер мыслит программами, и тоже не думает о накладных расходах. Фортер составляет вместо функции программу, и каждая такая программа может быть из кусочков в одну-три машинные команды.

В чем же разница между программой и функцией? Как программу можно составить из программ, а не из функций?

Всё очень просто. Объемлющую программу в Форте называют главный цикл. Разница между программой и функцией в том, что программа начинает свое исполнение где угодно программисту, но обычно не возвращается в место, следующее за тем местом, откуда ее вызвали. Программа вместо return как у функции по EXIT прыгает на следующую программу, или выходит по EXIT в одно и то же определенное место главного цикла. Что впрочем, совпадает с тем, что происходит и в ОС с программами.

Можно сказать, что парадигма pipe в Unix и threaded код в Форте это одна и та же парадигма.

Раскрутка Форта начинается с размышления под конкретный процессор. Мы хотим создать свой стек. Пусть верхушка стека лежит в регистре EAX, а остальное тело в обычной памяти. Или пусть два верхних элемента стека размером word лежат в одном ЕАХ. Нам нужен механизм, обслуживающий такой стек. Тогда мы пишем и отлаживаем маленькие программы, состоящие из двух-трех команд процессора. Ведь нужен же нам, по крайней мере, PUSH или DUP. Но такого стека нет в обычных процессорах, только в Форт-процессорах. Ни один фортер в здравом уме не подумает здесь о паскалеподобной функции.

Программы в Форт связываются, например, так

LODSW
XCHG di,ax
JMP [di] ;   indirect-threaded

или так:

LODSW
JMP ax  ;   direct-threaded

Как видим, никаких call/ret и фрейма локальных переменных в стеке, здесь нет. Вы можете сделать себе несколько стеков. Один только для хранения промежуточных результатов и адресов данных, а второй только для хранения адресов, стек возвратов.

Получается так называемый «шитый код». Название (очень точное) идет скорее всего от того, что адрес перехода на следующую программу всё время вычисляется на регистре (идет выборка через косвенную адресацию). Его нет в явном виде, поэтому процессор как швейная машинка с ниткой в иголке мечется по коду.

По скорости код уступает на мелких примитивных процессорах ассемблеру примерно 40%, на процессорах типа x86 будет около 80%. При этом одна и та же программа уровня сложности CAD, кодируемая в Форт, в 100 раз короче чем та же программа на Си. Что при этом получается, можно почитать в документе от NASA, где дается характеристика используемым в NASA языкам.
docs.google.com/...dit?usp=sharing
(по оригинальной ссылке www.hq.nasa.gov/...tree/871913.pdf документ не доступен, пишет, что в Америке шатдаун) ))

Но, хотел бы предостеречь от восхваления «светлого пути Форт». Мои исследования и практические написания разных Фортов позволяют мне сказать, что Форт это недостающий кусок в общей картине приемов программирования, а не многообещающий светлый путь. Этот кусок вставляет в картину недостающие элементы в парадигме паскалеподобных языков. Обобщенный путь, в моем представлении, я уже описал ранее.

Эта ограниченность одной парадигмой, и нежелание смотреть на результат интерпретации, и дает мне основание на личное мнение о том, что сегодня 99% программистов это уверенные пользователи специальных программ — компиляторов и интерпретаторов, в отличие от тех программистов, что были в 60-70х, и которые свои представления заложили в эти сегодняшние интерпретаторы. Людям помоложе этого не видно. Им не хватает исторической перспективы чтобы увидеть кризис в идеях программирования.

Відповісти

Підтримати

Valentin Nechayev

Valentin Nechayev архімаггриб в Дарницькі печери 12.10.2013 12:23

Переставлю цитируемые места.

> Вы для ознакомления с Фортом взяли статью некомпетентного автора.

Я вообще-то написал его интерпретатор (для Агата). А источником ознакомления была книга Баранова и Ноздрунова. Я, конечно, ценю Ваш энтузиазм, но когда Вы дошли до прямого высасывания из пальца фактов обо мне без всякого даже приблизительного их обоснования — Вам лучше остановиться и вначале хорошо думать, прежде чем писать ответы.

> В Форте нет call/ret, не используют.

То есть реализации на основе непосредственного шитого кода мне приснились? OK, пусть даже их мало используют (хотя то, что я вижу, показывает обратное — не так уж и мало). Формат записи в виде списка адресов вызываемых слов — это те же call и соответствующие им return.

> Получается так называемый «шитый код».

Спасибо, я в курсе о всех 4 базовых формах шитого кода. Вы можете приводить любые варианты клеевого кода на ассемблере; тот, что Вы привели, далеко не единственный (если говорить про 16-bit x86, сравните, например, MMX и MMV форты, у них это было сделано заметно по-разному). Проблема в другом: что код на Форте содержит переходов, причём (для всех форм шитого кода, кроме непосредственного) косвенных и заранее непредсказуемых, на порядки больше, чем обычный код после компилятора. Соответственно все обычно принятые подходы к оптимизации выполнения машинного кода идут лесом; нужно специализированное железо, чтобы в нём данный подход был хоть как-то оптимален, а не работал со скоростью даже не 8086, а хорошо разогнанного 8080 (у которого не было даже простого конвейера команд). Форт-машины потому и загнулись, что не получалось в такой обстановке обеспечить скорость выполнения (в расчёте на такт), хотя бы сравнимую с тем, что делают «обычные» архитектуры (как RISC, так и суперскалярный или хотя бы конвейерный CISC).

> бардак в понятиях функция и подпрограмма, и их огромные накладные расходы

Которые Форт не лечит, а только усугубляет — там, где в Си будут скомпилированы машинные команды, Форт, если не делать специальных хаков, даже загрузку константы на стек будет реализовывать через вызов специальной подпрограммы.

> Для сообщества Форта используется иная парадигма.

Я не знаю, кем и как по-Вашему она «используется», но если не рассматривать существующие где-то в эльфийских далях Форт-машины, то для текущего железа используется именно эта парадигма, которую можно определить как call/ret на каждое вызываемое слово. Все широко доступные на сейчас реализации Форта работают именно так, и в этом их проблема.
Вы, конечно, можете предложить JIT, и, может, где-то он будет реализован. Но мне слабо верится, что это будет в промышленном масштабе: проще эти средства бросить, пардон, на C++ или Java.

> на процессорах типа x86 будет около 80%

Вот Вы и подтвердили: использование Форта вместо Си даёт 5-кратное торможение. Знаете, даже Java обычно не даёт такого результата:)

> При этом одна и та же программа уровня сложности CAD, кодируемая в Форт, в 100 раз короче чем та же программа на Си.

Чем меряли? Уложили все слова Форта в одну строку?;) Извините, маргинальные примеры не в счёт, а такую цифру можно получить только на какой-то безумной маргинальщине. Например, сравнивается одно слово, выполняющее что-то уровня hello world, с программой, где надо нарисовать несколько #include<>, рамку main() и так далее.

Ссылку посмотрел, но не вижу оснований даже к тому, чтобы называть это «NASA about Forth language», это банально не соответствует содержанию.

Утверждение про краткость программ на Forth, таким образом, требует отдельного и серьёзного обоснования. На сейчас я этому банально не верю и никогда не верил (я слышал утверждения такого плана и раньше, и на поверку они все оказывались чудовищными натяжками).

> Сишник на ассемблере будет писать сишную программу.

Что Вы имеете в виду? Что он будет соблюдать сишные конвенции вызова?;) (Извините, Вы так неопределённо выражаетесь, что приходится гадать.)
Обычно, если сишник лезет на ассемблерный уровень, он пишет мелкие переходные клеевые кусочки. Например, как в ядре Linux — для переключения контекстов, связи обработчиков прерываний и т.д. Или он обходит какие-то недостатки Си (например, контроль целочисленного переполнения — adc + seto достаточно на x86, чтобы не извращаться с битами). Чтобы во что-то ещё лезть — это уже не чистый сишник.

> В Форте мыслят программами, а в паскалеподобных скриптах — функциями и подпрограммами.

Не вижу ни единого основания для такого сравнения. На том же уровне, на котором в C/Pascal/etc. мыслят функциями — в Форте мыслят словами. На том уровне, на котором в «паскалеподобных скриптах» мыслят программами — в Форте мыслят программами. Если Вы считаете иначе, это надо обосновать. Я у Вас никакого обоснования этому не увидел при всём желании.

> Фортер составляет вместо функции программу, и каждая такая программа может быть из кусочков в одну-три машинные команды.

Фортер составляет вместо функции — такую же функцию, только она называется «слово». Называя слово программой, Вы, не знаю, насколько намеренно, но сбиваете всех с толку. Я не буду поддерживать такую терминологию. Программа — это нечто, что выполняет целую задачу по ТЗ (неважно, насколько писанному и осознанному) и взаимодействует с внешним миром. Отдельное слово не может быть программой.

> При этом Форт это не скрипт, а компилятор-интерпретатор и одновременно само приложение.

Любой скриптовый язык с REPL позволяет такое. Например, Python, Ruby, Tcl. Объявил функции в интерпретаторе и тут же вызвал. Заметьте, без мучений с отсчётом cell’ов в стеке и с возможностью легко переопределить каждую функцию отдельно по необходимости, не «передёргивая» всё определённое в словаре после неё, как во всех реализациях с работой со словарём по умолчанию. А структуры данных? Где готовая реализация хотя бы простейшего dictionary на Форте «искаропки»? ;(

[skip остаток рассказа на пальцах для полных ламеров, где перевирается всё, что можно.]

> позволяют мне сказать, что Форт это недостающий кусок в общей картине приемов программирования

Вот-вот. Тут я с Вами категорически согласен. Это не более чем частный приём для особых случаев; приём более важный методологически, чем практически — он дополняет картину, добавляя одно из необходимых замыканий до полной. И одно из приятных — он показывает, как, например, можно не имея вообще ничего на машине, кроме голых битов, сделать рабочую среду, в которой уже запускать что-то более высокоуровневое, затратами в несколько килобайт легко пишущегося кода. За одно это его стоит помнить. И соответственно понимать, почему мы видим Форт, например, в спарковском OpenBoot или загрузчике FreeBSD, но его присутствие резко заканчивается, как только мы добираемся хотя бы до уровня ядра; или почему, например, его запихнули внутрь TTF фонтов (система хинтинга). В общем, это идеальное средство для небольших программ в негостеприимном окружении.

Главное — не пытаться из него сделать что-то заведомо большее, чем он есть.

> Вы не придали значения моим словам: для чего, для какой конкретно задачи Вы написали компилятор? Мое предположение, что для какой задачи пишется, для этой задачи и используется. Появилась новая задача, требуется новый компилятор-интерпретатор, например, путем модификации существующего.

А Вы заметили, что тут в разговоре Вы резко подменили предметную область? То, о чём Вы говорите, это уже тема для DSL (domain specific languages). Да, для них нужны свои языки и свои компиляторы. Но при чём тут языки программирования? DSL в общем случае и не должны быть языками программирования, а тем более теми языками, на которых пишется базовый код соответствующего продукта; во многих случаях им нужно быть чисто описательными языками. Вообще на тему DSL было несколько обширных интересных тредов на rsdn.ru, не хочу тут активно повторяться; если хотите поговорить об этом — вначале почитайте их.

И если уж вспоминать Форт, то DSL из него откровенно хреновый, как из любого языка, который больше посвящён переменным, адресам и указателям, чем понятиям и сущностям предметной области. Проблема не в том, что что-то на нём нельзя написать; проблема в том, что на нём можно написать слишком много сверх предметной области и нельзя проконтролировать последствия иначе, чем ревью этого кода.

> Причина та же, по какой разные предметные области используют разные понятия и имеют разную терминологию.

Во-во, тема DSL и есть.

> Эта же глупость делается, когда пишется универсальный компилятор.

Не-а. Глупость не тогда, когда он пишется. Глупость тогда, когда 1) кто-то неверно понимает понятие универсальности (напоминаю простой математический факт, что «множество всего» это внутренне противоречивое понятие), и далее 2) этот кто-то пытается применить средство там, где оно заведомо не подходит. А «универсальный компилятор» для какого-то одного определённого языка, безусловно, имеет место и смысл.

> и нежелание смотреть на результат интерпретации, и дает мне основание на личное мнение о том, что сегодня 99% программистов это уверенные пользователи специальных программ — компиляторов и интерпретаторов, в отличие от тех программистов, что были в 60-70х, и которые свои представления заложили в эти сегодняшние интерпретаторы.

На это я уже отвечал. Они смотрят тогда, когда действительно нужно смотреть вглубь. Но если слишком много туда смотреть, то получится классическое «за деревьями не видно леса». Не зря придумали компиляторы — они выполняют основную механическую работу за человека.

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 13.10.2013 07:08

> Формат записи в виде списка адресов вызываемых слов — это те же call и соответствующие им return.

---
То есть, я делаю вывод, какой код в машинных инструкциях генерирует Форт, Вы не поняли. Ну и далее, полагаю, не знаете устройство Форт и его основную идею. Ладно, оставим детали Форта.

Есть разница, с какой целью тратить время на программирование. Продавцы цветов на базаре продают букеты. Они их делают на заказы. Они креативны, и хорошо зарабатывают. Сегодняшние пользователи компиляторов точно такие же, они продают букеты из функций.

Им знание, какой код будет генерировать без синтаксиса и без ключевых слов голая система программирования, не нужно. Она получится нужной только себе. И тысячи сотен будут каждый в своей каморке продолжать делать повторяющиеся операции. Как сапожники или флористы. Ремесленнику — ремесленное. Оплачивается ведь )))

Пока оплачивается.

Відповісти

Підтримати

Valentin Nechayev

Valentin Nechayev архімаггриб в Дарницькі печери 13.10.2013 08:22

> То есть, я делаю вывод, какой код в машинных инструкциях генерирует Форт, Вы не поняли.

Ну, если Вы хотите продолжать закрывать глаза на факты... ваше дело. Я уже достаточно разъяснил в подробностях свою позицию.

> Сегодняшние пользователи компиляторов точно такие же, они продают букеты из функций.

Да. И что, это плохо? Когда надо строить «букеты» объёмом в десятки миллионов строк кода и миллиарды выходных команд, никто не будет следить за деталями нижнего уровня.
У хорошего генерала может быть и тысяча плохих солдат. Но остальная часть дивизии сделает что надо и с достаточным успехом. Вы пока что предложили только худшую форму микроменеджмента, когда лезете в детали каждого пука на местах.

> Ремесленнику — ремесленное.

Вам, видимо, кажется, что всё, что не залезает на уровень деталей команд процессора — тупое ремесло? Зачислить в ремесленники большинство программистов, вплоть до авторов великих алгоритмов или изобретателей Internet, зато считать не-ремесленниками тех, чьи достижения не выходят за пределы ручной шлифовки всего кода с выбором регистров и вариантов команд... знаете, я не могу принять такой подход.

> Пока оплачивается.

И дальше будет оплачиваться, что бы Вы ни думали по данному поводу. Есть, конечно, Стив Возняк с его дисководом, но тот, кто сделает алгоритм с O(n) вместо O(n**3), сделает значительно больше и получит за это больше, чем тот, кто сократит на 20% константу при n**3 за счёт укладки команд на конвейер. А ещё больше получит тот, кто быстро определит реальную потребность пользователя и создаст ТЗ по её удовлетворению. Ну а если ему таки придётся ускорить какой-то крошечный участок, он наймёт кого-то. Боюсь, таки не Вас.

Відповісти

Підтримати

Кирилл Нечаев

Eugene Zavidovsky 13.10.2013 08:43

@ Valentin Nechayev, Андрей Куликов

Да ладно вам уже :D

Відповісти

Підтримати

Valentin Nechayev

Eugene Zavidovsky 13.10.2013 09:37

@ Андрей Куликов

Пока оплачивается.

Недостаток денег у IT-компаний в ближайшей перспективе маловероятен:

>>> www.techrepublic.com/...-on-cash-piles
>>> www.networkworld.com/...ngs-273333.html

И даже если так случится, что в одном месте убыло — то в другом месте обязательно прибудет. Не?

@ Valentin Nechayev

...тот, кто сделает алгоритм с O(n) вместо O(n**3)...

Но это, похоже, можно сделать и таким способом:

>>> www.youtube.com/...h?v=CMdHDHEuOUE
>>> en.wikipedia.org/...hor’s_algorithm

Відповісти

Підтримати

Eugene Zavidovsky

Кирилл Нечаев 14.10.2013 12:20

Чем больше денег готовы потратить всё больше заказчиков, тем всё более их не устраивает несоразмерно дорогая цена на решение программистов.

Відповісти

Підтримати

Eugene Zavidovsky

Ivan Pomidorov 14.10.2013 12:23

И как их заменить? Изобрести полноценный ИИ? Боюсь что на наш век работы программистам хватит.

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 12:43

Как заменить «телефонисток»? Пока не знаю, но думаю и занимаюсь этим )))

Вначале оно будет неуклюжим и неказистым, как показывает история техники. Телефонистки и знать не будут, что где-то какой-то седобородый исследователь уже нащупал решение, которое их уволит. ))

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 14.10.2013 12:55

Телефонистки максимум, что могут делать — это обеспечить телефонный звонок, для программеров по интеллектуальной сложности — это как подсоединить монитор, клаву, мышь к системному блоку и включить питание.

Чего-то вспоминается 1С, когда гибкий продукт должен был вытеснить с рынка все кастомные решения и стать панацеей. Вот только он породил новую касту телефонисток, которые его обслуживают, да ещё и не за малые деньги.

Пока не знаю, но думаю и занимаюсь этим )))

Создайте систему, которой сможет пользоваться дурак, и только дурак захочет ею пользоваться. — Принцип Шоу

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 13:14

Насчет телефонисток Вы не правы, это я знаю из собственного опыта, поскольку служил в дивизии связи, и был (тесно) знаком с военными телефонистками. )))

Телефонистка это справочная служба, это бюро погоды, это хорошо знающий, как обойти упавший узел связи и эту связь достать, это хранитель некоторых секретов, например, где кого искать и для кого (для кого командир таки в бане, а для кого — на задании). И много чего еще )))

В 1С есть правильное направление мысли. Язык программирования в предметной области должен быть родным языком специалиста в предметной области. Реализация же, скорее всего, неправильная.

Відповісти

Підтримати

Kirill Sablin Developer 14.10.2013 13:17

Язык программирования в предметной области должен быть родным языком специалиста

для этого вроде жe всякие ddd и dsl и есть?

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 14:01

Ну вот как раз концепция кода в Forth дает ответ, в чем разница. В Форте пишут предложение из слов. Слова обязаны составить предложение, например:

15 45 высота 8 пушку довернуть огонь

Это совсем не то, что перевести ключевые слова из компилятора и оставить тот же синтаксис с бесконечными скобками, запятыми как разделителями, точек с запятыми, объявлениями типов, явной передачей параметров или ссылок на них, и всё это вывалить на специалиста, программирующего поведение робота.

Язык должен строится так, как мы будем даже в полусознательном состоянии о чем-нибудь просить сделать. То есть, по правилам родного языка.

В Форте нет проблемы «это я сам написал три месяца назад, или не я? и что этот код делает?»

Відповісти

Підтримати

Євген Козлов Front-end developer в SoftServe 14.10.2013 14:11

В Форте нет проблемы «это я сам написал три месяца назад, или не я? и что этот код делает?»

Идеальный язык?

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 14:23

Форт это не язык. Это заблуждение большинства. Попытки стандартизировать чью-либо реализацию убивают саму идею Forth (примерно так высказался Ч.Мур)

Думайте о нем, как об академическом примере, как о LISP, например.

Вот только разницу заметьте. Forth процессоры есть. А Си, Джава или Пайтон — нет, и не будет.

Відповісти

Підтримати

Євген Козлов

Valentin Nechayev архімаггриб в Дарницькі печери 14.10.2013 18:41

Вот только разницу заметьте. Forth процессоры есть. А Си, Джава или Пайтон — нет, и не будет.

Это же насколько надо быть уверенным в себе, чтобы нести опровергаемую за 10 секунд чушь...

en.wikipedia.org/.../Java_processor — список аппаратных реализаций Java virtual machine.

Может, ещё какое-то заведомо ложное утверждение выдадите? ;)

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 19:44

Признаю, да, здесь я ошибся. Я думал, после первого фейла Sun никто и не подумает выпускать такое примитивное убожество по архитектуре, как JVM. Но видно, армия программистов Джава дала спрос, рынок ответил ))

Впрочем, изобретатель Форта тоже зря делал свой 128-микрокомпьтеров-в-чипе, реализующих Форт.

Это общее заблуждение. Причина, на мой взгляд, не очень сильная подготовка в математике.

Відповісти

Підтримати

Valentin Nechayev

Valentin Nechayev архімаггриб в Дарницькі печери 14.10.2013 22:07

Причина, на мой взгляд, не очень сильная подготовка в математике.

Какая бы ни была подготовка в математике, читать выражения в инфиксной нотации человеку легче. И даже в префиксной (а-ля LISP) легче, чем в чистой постфиксной стиля Forth. Про остальные странности написания на нём можно и не вспоминать.

Я думал, после первого фейла Sun никто и не подумает выпускать такое примитивное убожество по архитектуре, как JVM. Но видно, армия программистов Джава дала спрос, рынок ответил ))

Сейчас даже в SIM картах, что показательно, урезанная Java, а не что-то другое;)

И причина не в армии программистов как таковой — те же миллионы индусов с таким же успехом пошли бы и на Forth, если б потребовалось.

Відповісти

Підтримати

Кирилл Нечаев

Kirill Sablin Developer 14.10.2013 14:14

15 45 высота 8 пушку довернуть огонь

честно говоря не думаю, что это чей-то родной язык:)

синтаксис с бесконечными скобками, запятыми как разделителями, точек с запятыми,

это практически тоже самое, что и обязательный порядок в вашем форте.
Кстати DSL не обязательно должен быть внутренним (частью языка программирования). Он может быть и внешним, и там не будет синтаксического шума.

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 14:17

не думаю, что это чей-то родной язык:)

---
а Вы в армии не были :))
я угадал? ))

Відповісти

Підтримати

Kirill Sablin Developer 14.10.2013 14:20

не был. Это язык прапорщиков?:)
вот пример современного внешнего DSL — github.com/...er/wiki/Gherkin

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 15:15

Что-то похожее на концепцию Кобола. Понятно, что идеи витают в воздухе. Говорят о той же проблеме, как уйти в еще более высокий и чистый HLL, но очевидно, что они утонут в накладных расходах. На написание кода интерпретатора, на процессорное время, на память, и наконец, на время запуска такой системы.

То есть, они не реализуют одну из заявленных и достигнутых целей в Форт: по сравнению с Си напечатать на клавиатуре в 100 раз меньше кода, и проиграть в скорости Си процентов 30%.

Вспомним, что минимальное требование к Форту это процессор с 1К памяти и com-port с терминалом на другой машине. И тогда их подход выглядит не более чем еще одной надстройкой над неповоротливой глыбой интерпретирующего кода.

Відповісти

Підтримати

Євген Козлов Front-end developer в SoftServe 14.10.2013 15:56

а можно распарсить конкретну эту фразу?
к чему относится «довернуть»?
я бы делал так:
пушка№ 7.заряжай().наводка(189).высота(7).огонь()

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 16:33

Форт для упрощения разбора кода предлагает писать код так, как он идет в инструкциях процессору. То есть, RPN, обратная польская запись. Не буду утверждать, хорошая ли это идея при выходе на раскрутку до HLL...

Я написал навскидку, сейчас поправлю в forth-way.

15 45 8 высота пушку довернуть огонь

15, 45 и 8 «кладутся в стек». На самом деле, следующие друг за другом цифры опознаются как вызов служебной программы (напоминаю, что Форт не использует стандартный вызов call/ret), можете думать, что это вызов подпрограммы. Можете представить эти действия, как заполнение структуры в стеке:

stack struct 
  azimuth word ?
  speed   word ?
  high    word ?
stack ends

Слово «высота» вызывает программу расчета угла возвышения ствола от текущего положения и затирает «8» на вершине стека и оставляет, там, на вершине, результат расчета.

Слово «пушку» вызывает программу «пушка», и программа «пушка» знает, что для нее данные в необходимом порядке лежат в стеке, в конце работы она удаляет все три слова со стека, и оставляет там адрес. Можете думать об этом адресе как о таблице виртуальных функций, где по смещениям лежат все методы объекта «пушка» (а не объекта «пулемет», скажем).

«Довернуть» «огонь» берут адрес со стека и по смещениям, определенных внутри них, зовут методы «довернуть» и «огонь».

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 14.10.2013 16:41

спасибо за ликбез.
я знаю, что такое RPN. и даже более того, калькулятор на её базе(mcalc под j2me) считал самым удобным в использовании.
но вижу проблемы:
а) заточена под стек; следовательно другие структуры надо будет либо конвертировать в стековые, либо воротить здоровенные конструкции. как обработать дерево?
б) понятность, особенно в примере, сильно хромает — для понятия сильно необходимо знать, какая команда сколько аргументов принимает и сколько — кладет в стек. «обычный» язык с перечисляемыми явно параметрами(а то и — с именованными) и с единственным возвращаемым результатом уже дает шанс обойтись без автора при чтении.

Відповісти

Підтримати

Кирилл Нечаев

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 14.10.2013 16:47

я знаю, что такое RPN. и даже более того, калькулятор на её базе(mcalc под j2me) считал самым удобным в использовании.

А если ещё учесть, что x86 FPU работает в RPN, от чего безумно сильно страдает.

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 14.10.2013 16:58

А если ещё учесть, что x86 FPU работает в RPN, от чего безумно сильно страдает.

незаконченная фраза.
А если еще учесть, что ... то что? RPN зло? RPN добро? RPN — RPN?

Відповісти

Підтримати

Кирилл Нечаев 14.10.2013 17:27

RPN это данность буквального следования правилам математического вычисления. И буквальное следование математике всегда будет определять механику и физику устройства вычислителя.

Пусть требуется вычислить написанное выражение:

3 + 4

Если следовать ему буквально по токенам, то у нас ничего не получится. «Три», запомнить. «Сложить», выбрать функцию сложения. И всё. У функции «сложить» доступен при вызове только один параметр. Ошибка.

Правила вычисления определяют и механику в процессоре.
сначала MOV в один регистр, R1 .
Затем MOV другой регистр, R2.
Затем ADD R1, R2
Результат экономнее оставить в R1 или R2, затерев ставшие ненужными слагаемые.

Последнее не поняли проектировщики процессора ARM. Это их огромный, эпический фейл. )))

Відповісти

Підтримати

Євген Козлов

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 14.10.2013 17:35

Последнее не поняли проектировщики процессора ARM. Это их огромный, эпический фейл. )))

add r1,r1,r2 ?
add r2,r1,r2 ?

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 17:36

add r1,r1,r2 ?

Ага, и дырка в коде на месте лишнего регистра )))

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 14.10.2013 17:43

Какая дырка? 32 битовый машинный код на инструкцию.

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 18:03

Это равносильно там-сям порасставлять в код для x86 команду

MOV edx,edx

Использовать одну длину для всех команд это общий фейл разработчиков ARM, уже следствие того что они не поняли, и почему разработчики x86 не пошли по такому пути. А старые разработчики советских процессоров давно над этим посмеялись, я читал переписку как-то. Им для обсчета равносильной задачи хватило бы частоты процессора раз в 5 меньшей, при более математичной архитектуре.

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 14.10.2013 18:09

То-то VLIW живёт и здравствует, а оказывается это глобальный фейл. Intel’овский VLIW GPGPU при частоте 1Ghz уделывает x86 при частоте 3GHz раза в три при серийной обработке данных.

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 18:14

Копипаст из вики:
код для VLIW обладает невысокой плотностью. Из-за большого количества пустых инструкций для простаивающих устройств программы для VLIW-процессоров могут быть гораздо длиннее, чем аналогичные программы для традиционных архитектур.
Разработчики процессоров говорят про такое: код получается рыхлый, с дырками. Это говорит о том, что будут проблемы с производительностью такого кода. Но что бы создать упакованный код, необходимо хорошее образование, опыт и талант.

Если и есть выигрыш, то он в чем-то другом. Рыхлый полупустой код это всегда фейл у разработчика процессора.

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 14.10.2013 18:17

Я как бы под них пишу, и, каюсь, вики не читал, а то бы расстроился :))))

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 18:26

Да это общеизвестно, еще наверное, с 70-х, про полупустой код, питающий процессор, как отрицательную характеристику его архитектуры. Специалисту это совершенно очевидно.

Мое предположение, было решение не тратить на R&D деньги, побыстрее сляпать процессор, с надеждой, что программисты, пишущие компиляторы сумеют упаковать достаточно, чтобы получить какой-то выигрыш. Но это не отменяет оценку как слабая и недоделанная архитектура.

На R&D нынче экономят )))

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 14.10.2013 20:39

Да это общеизвестно, еще наверное, с 70-х, про полупустой код, питающий процессор, как отрицательную характеристику его архитектуры. Специалисту это совершенно очевидно.

Вы же знаете, что VLIW — это подмножество MIMD?

Відповісти

Підтримати

Кирилл Нечаев

Valentin Nechayev архімаггриб в Дарницькі печери 14.10.2013 22:13

Вы же знаете, что VLIW — это подмножество MIMD?

Вот тут я уже удивляюсь. Даже если это формально и подмножество, то с настолько характерными чертами, что рассматривать его в общем русле имеет слишком мало смысла...

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 14.10.2013 22:30

Нет там характерных черт, есть просто типичные реализации, которые все принимают за эталон VLIW. Если понимать принцип MIMD, то тогда легче понять EPIC, который не так уж и похож, но всё-таки является VLIW’ом, где проблемы с простоем были решены довольно-таки давно.

Відповісти

Підтримати

Valentin Nechayev

Valentin Nechayev архімаггриб в Дарницькі печери 15.10.2013 09:26

Можешь накидать ссылок для более глубокого понимания? Что-то мне пока гугление не дало такого источника, который бы внятно объяснил то же отличие EPIC от VLIW на понятном уровне.

С другой стороны, прямой вопрос на сейчас — а насколько адекватно говорить про MIMD тогда, когда исполнительные устройства неоднородны (как имеем в случае, например, IA64, или внутреннего устройства post-PPro x86, насколько его можно понять по доступным источникам)?

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 15.10.2013 09:37

Можешь накидать ссылок для более глубокого понимания? Что-то мне пока гугление не дало такого источника, который бы внятно объяснил то же отличие EPIC от VLIW на понятном уровне.

Чуть позже, во второй половине дня постараюсь на пальцах объяснить, ссылок просто накидать не получится, ибо надо очень много читать, нахрапом быстро не усвоить :)

Відповісти

Підтримати

Valentin Nechayev

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 15.10.2013 13:46

EPIC и IA64(Merced) — это практически синонимы. Первое — это внутренняя архитектура, второе — это внешняя архитектура (система команд и т.д.).

Для понимания процессов, нужно обособить Execution Unit (EU) и ALU. EU делает все предварительные операции, памит внешние регистры на внутренние, занимается переименованием и т.д. и скармливает всё это ALU для совершения самой операции. В той архитектуре VLIW, которые ты и Андрей считаете классической (а она ни разу не классическая, в просто самая элементарная в реализации) к каждому EU фиксированно пристёгнут ALU. Команда состоит из заданий для каждого EU без исключения.

Сейчас я буду говорить не столько про EPIC (хотя 80% будет идентичными), сколько про их новую архитектуру, котора пошла в GPGPU и которая ближе к VLIW.

Теперь рассмотрим систему, допустим с 9 EU и 15 ALU (да, power of two сейчас, определенно, не в моде). Есть многопоточный процессор, не ядра, а именно потоки — thread’ы. Процессор берёт на выполнение столько потоков, сколько EU. И вот поток получил управление и забрал себе одно EU. Этот EU при выборке команд умеет анализировать код, например встретив такую команду в коде:

mul(8)          g14<1>F         g10<4,4,1>.xF   g1<0,4,1>F
mac(8)          g14<1>F         g14<4,4,1>.yF   g1.4<0,4,1>F

он реквестирует для выполнения работы одно ALU, т.к. результат следующей команды зависит от предыдущей. Да, это похоже на обычную суперскалярность.

Тут в коде встречается вот такой набор команд, где все операции можно выполнить параллельно:

dp3(8)          g14<1>.xF       g11<4,4,1>F     g3<0,4,1>F
dp3(8)          g14<1>.yF       g11<4,4,1>F     g3.4<0,4,1>F
dp3(8)          g14<1>.zF       g11<4,4,1>F     g4<0,4,1>F 
mov(8)          g161<1>.wF      g4.4<0,4,1>.xF
mov(8)          g176<1>F         g175<0,4,1>F

И EU начинает реквестировать 5 ALU из 11 для выполнения этого кода. Отличие от EPIC тут в том, что для EPIC необходимо в коде выставлять размер группы команд для параллельного выполнения (бит конца последовательности), а в новой архитектуре это делает сам EU. Удорожение чипа вместо нагрузки на компилятор. Если в данный момент времени будет доступен только один ALU, один ALU и будет использован для очередного выполнения команд, но если на следующей команде освободится 3 ALU, то будут использованы 3 ALU.

В этом же кроется и отличие от «классического» VLIW, где все EU и ALU загружаются одной командой, против другого подхода, где EU динамически распределяет количество ALU, необходимых для выполнения кода.

Так же компилятором можно подготовить код, который ничем не будет отличатся от «классического» VLIW’а по выполнению, где будем использовать 2,3,4,5 .. etc ALU на одну большую инструкцию, просто контроллируя очередь выполнения команд. И работать он будет по классическим правилам, с простоями и т.п.

Плюс динамического подхода — это масштабируемость в количестве ALU и EU, при которой сохраняется обратная совместимость, т.к. размер VLIW инструкции не фиксирован. При использовании множественных EU в потоках простой ALU сводится к нулю и начинается борьба за ALU ресурс.

EPIC мог выполнять 6 инструкций за цикл в идеальном случае.

Відповісти

Підтримати

Valentin Nechayev

Кирилл Нечаев 15.10.2013 17:16

Ну всё логично, направление развития отчетливо видно.

Правда, я всё же буду утверждать, что принцип здесь старенький, тот же, что и в организации параллельных pipe архитектуры x86. Там pipe — это потоки, реализованные комбинационной логикой на кристалле. Это о-ооочень трудоемкое дело. Как на рассыпухе серии 74 продумать и спаять макет процессора.

Но вот мне кажется, я знаю, что подумали инженеры, когда оценили бюджет на R&D. Поскольку готовые АЛУ уже готовы, то почему бы их просто не расставить сотами на кристалле, поставив их в подчинение супервайзера?

Вообще, забавно наблюдать, как пинают мяч друг другу проектировщики компиляторов и проектировщики конвейера (VLIW-процессоров). Вы оптимизируйте! Нет, это вы угадывайте чипом! )))

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 15.10.2013 18:07

Вообще, забавно наблюдать, как пинают мяч друг другу проектировщики компиляторов и проектировщики конвейера (VLIW-процессоров). Вы оптимизируйте! Нет, это вы угадывайте чипом! )))

Да, и так было всегда :) И всегда будет :)

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 15.10.2013 10:21

Смешение кода и инструкций есть у x86, все команды с immediate есть суп из операторов и данных:

mov WORD PTR [edi], 0A0Dh ; write CRLF to buffer

mov esi, lpString         ; address of source string to ESI

В чем новизна? Конвеер в x86 и его АЛУ есть полный эквивалент кода и аппаратной части для MIMD.

Если разные опции shared memory, так это еще в 60-х было реализовано, когда запускали первый спутник в СССР. Тогда станции слежения расставленные по всей территории СССР имели радиорелейную связь, и была реализована именно shared memory.

Американцы в то время только делали подскок на ту же высоту, следить они не умели.

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 15.10.2013 13:52

dou.ua/...ic/7678/#373681 :)

Відповісти

Підтримати

Кирилл Нечаев

Valentin Nechayev архімаггриб в Дарницькі печери 14.10.2013 18:46

Использовать одну длину для всех команд это общий фейл разработчиков ARM, уже следствие того что они не поняли, и почему разработчики x86 не пошли по такому пути.

Сравнивать таким образом CISC и RISC это, конечно, верх мудрости в анализе процессорных архитектур.

Разработчики x86 вообще-то несколько лет пытались отыметь весь мир с помощью IA64. И только когда не смогли его поднять — спёрли AMD64 (ещё одна наколенная поделка без малейшего взгляда хотя бы на шаг вперёд) и сделали вид, что они самые умные.

Відповісти

Підтримати

Кирилл Нечаев

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 14.10.2013 17:30

Фраза закончена. А RPN — это безумно неоптимально.

Відповісти

Підтримати

Євген Козлов

Valentin Nechayev архімаггриб в Дарницькі печери 14.10.2013 18:43

Да, 8087 это тяжёлый случай. Сэкономили на спичках...

Відповісти

Підтримати

Кирилл Нечаев 14.10.2013 17:12

Следует понимать термин «стек» в Форте только как стековый механизм . На самом деле это просто глобальный участок памяти, и обычно хватает 16 DWORD. В обычном программировании каждый раз при вызове функции указатель на вершину сдвигается, всё дальше в память, выделяя новые фреймы для под каждый вызов. В Форте фрейм один, глобальный, где всё затирается и пишется заново.

Вообще, девиз Форта: используйте глобальные переменные, и никого не слушайте. Врочем, в реальной жизни так и происходит, как только встает вопрос о скорости исполнения и краткости кода. Но академически вполне обоснованно лишить ученика соблазна устроить вакханалию из флагов и переменных в общей памяти, в которой он сам же по неопытности и запутается )) Просто потом только некоторые снимаются с тормозов ))

Конечно, нужно знать число аргументов и их порядок перед тем, как написать слово (вызвать функцию).

Но мы так и делаем в жизни.

Перед тем как написать «объем-параллепипеда», мы просто так, из жизненного опыта знаем, что перед вызовом нам уже подготовлены три числа. Это не особенность языка, а особенность требования тщательности выбора ключевых слов предметной области. Скажем, каждый военный-артиллерист знает, какие он получит данные от станции наведения, а какие данные будут лежать константами в описании его местонахождения. Пример с пушкой это пример кода задача-ориентированного языка. Специалист просто так, без обучения от программиста, из своей предметной области, знает, что придет и в каком порядке от станции наведения.

Відповісти

Підтримати

Євген Козлов

Valentin Nechayev архімаггриб в Дарницькі печери 14.10.2013 18:51

В Форте фрейм один, глобальный, где всё затирается и пишется заново.

Кольцевой, что ли? М-да, до такого разве что в 6502 докатывались.

Специалист просто так, без обучения от программиста, из своей предметной области, знает, что придет и в каком порядке от станции наведения.

Безусловно. И получать данные в виде (int a, double b, int c) ему будет всяко удобнее, чем в виде ячеек на стеке. А о соглашениях по вызову позаботится компилятор (может, он вообще inline сделает — фортовскому рантайму без JIT это недостижимая фантастика).

Відповісти

Підтримати

Кирилл Нечаев

Євген Козлов Front-end developer в SoftServe 14.10.2013 18:52

Конечно, нужно знать число аргументов и их порядок перед тем, как написать слово (вызвать функцию)

о, да, значения по умолчанию и именованные аргументы — это миф.

где всё затирается и пишется заново

то есть, если какая-то функция станет класть вместо двух значений на вершину — два, мы из-за специфики сначала получим аппокалипсис(из-за сдвига данных в стеке относительно предполагаемого порядка), а только потом начнем методом исключения искать причину?
отличный язык для масштабных разработок!
предсказуемость, понятность, широкие возможности отладки!
извините, вырвалось.

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 19:24

Ну, может, Вам нужно записывать на бумажку промежуточные значения для вычисления суммы двузначных чисел. Я не знаю. Но знаю, что большинство людей промежуточные результаты хранят в памяти. И к записи 45+77= добавляют только одну запись, числа суммы.

Незачем взрослому и маломальски обученному человеку всю эту промежуточную ерунду писать в код. Для начинающих --- в самый раз.

какая-то функция станет класть вместо двух значений на вершину — два

Вы как-то странно одушевляете Вами же написанные функции. У них своя жизнь, что ли?

Я там давал ссылку на ПДФ от НАСА, где они характеризовали языки, которые использует НАСА. Там как раз описан метод разработки, и совершенно ясным английским написано, что этот метод позволяет получать только отлаженные куски кода.

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 14.10.2013 19:35

Там как раз описан метод разработки, и совершенно ясным английским написано, что этот метод позволяет получать только отлаженные куски кода

это про «не допускать недопониманий и не делать ошибок в коде»? какой раздел-то такую магию описывает?

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 19:53

Дело в том, что когда англоязычный изобретатель Форта высказал идею, что программирование должно заключаться в подборе и написании слов в предложение, которое несет однозначный смысл, я сразу отметил:

В русском языке это не сработает.

В английском строгий порядок слов подлежащего и сказуемого.

В русском или польском, украинском, белорусском, можно переставлять слова, играя оттенками. Из-за этого англоязычные очень тяжело распознают оттенки наших оборотов речи.
--------------
Еще раз говорю: Форт это не светлый путь, избавьтесь от приписываемого мне положения.

Я ровно столько же могу написать и про ЛИСП, и также буду утверждать, что он тоже лишь академическая зарисовка в части общей картины.

Відповісти

Підтримати

Євген Козлов

Valentin Nechayev архімаггриб в Дарницькі печери 14.10.2013 22:21

Там как раз описан метод разработки, и совершенно ясным английским написано, что этот метод позволяет получать только отлаженные куски кода.

Там не было никакого мистического волшебства, чтобы сделать то, чего не могут сделать остальные:) Стандартные методики, которые всецело зависят от плотности и качества их применения.

Відповісти

Підтримати

Кирилл Нечаев

Valentin Nechayev архімаггриб в Дарницькі печери 14.10.2013 18:39

Слова обязаны составить предложение, например:
15 45 высота 8 пушку довернуть огонь

Теперь переставляем «огонь» и «довернуть», и никто, кроме магистра Йоды, не замечает проблему, пока не ткнут носом в ошибку.

В Форте нет проблемы «это я сам написал три месяца назад, или не я? и что этот код делает?»

Когда код начинает выглядеть переполненными DROP OVER 3 ROT 5 DUP IF 1 PICK DROP 0< THEN вместо того, чтобы просто адресовать локальную переменную — тут, действительно, не «что этот код делает?», а «куда бы его выбросить, чтобы не вонял?» И кто писал, тоже обычно пофиг в таком случае:)

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 19:29

Вы можете перепутать порядок в win32, сначала вызвать для окна Paint, а затем Resize. Так это вина программиста, который путает клавиши и порядок вызова функций, или будем жаловаться, что MSDN «как-то по дебильному» © написана? )))

переполненными DROP OVER 3 ROT 5 DUP IF 1 PICK DROP 0< THEN

C этим я согласен, не очень-то понятно.

Если бы не одно «но». Это для уровня голого железа или первых определений исполняемых слов, так всё выглядит. И насыщенность подобными комбинациями встречается в основном вот в таком коде: www.colorforth.com/ide.html

Сколько ясности проявится в драйвере для IDE на Си или Ассемблере, можно себе представить или поискать в исходниках.

Відповісти

Підтримати

Valentin Nechayev

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 14.10.2013 20:46

И насыщенность подобными комбинациями встречается в основном вот в таком коде: www.colorforth.com/ide.html

Oh, God! Please make me unsee it.

Відповісти

Підтримати

Кирилл Нечаев

Valentin Nechayev архімаггриб в Дарницькі печери 14.10.2013 22:11

Вы можете перепутать порядок в win32, сначала вызвать для окна Paint, а затем Resize. Так это вина программиста, который путает клавиши и порядок вызова функций, или будем жаловаться, что MSDN «как-то по дебильному» © написана? )))

Порядок аргументов и вызова функций значительно легче осознаётся при наличии поддерживающего контекста и синтаксиса. Избавление от них — спуск уже на уровень ассемблера.

Это для уровня голого железа или первых определений исполняемых слов, так всё выглядит.

Это так выглядит для любых достаточно нетривиальных манипуляций с данными в пределах одной функции (слова). Как только начинает участвовать больше 3 значений — код становится нечитаемым. Этот же порог для Си преодолевается значительно позже, в районе 20 переменных или даже выше, в зависимости от сложности алгоритма.

Сколько ясности проявится в драйвере для IDE на Си или Ассемблере, можно себе представить или поискать в исходниках.

В чистом ассемблере, конечно, всё ещё хуже, но там зато можно получить серьёзные оптимизации. Для Си см. выше.

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 15.10.2013 09:13

Это уже всё синтаксическая вкусовщина. Вы обсуждаете Форт на таком примитивном уровне, что мои возражения должны были бы превратится в первые страницы Хелпа.

На них написано, что вы можете полностью создать нужный вам язык, например, для тренировки, можете симулировать любой другой язык с его синтаксисом. Потому что у Форта нет своего синтаксиса.

Теперь, после первых страниц Хелпа, Ваши возражения по синтаксису увиденного выглядят э-ээ, как бы помягче сказать, результатом неведения.

К сожалению, глубже синтаксиса частной реализации частного языка в системе Форт, разговор не пошел. Но это и ожидаемо, поскольку мэйнстрим ручной ремесленной работы людей поглощает, воспитывает и привязывает к инструментам и способам выделки продукта.

Скажем, находясь среди мэйнстрима телефонисток, трудно им было бы пояснить, что где-то в лабораториях идут исследования простейших релейных автоматов, и ищутся способы проектирования логических схем и их упрощения. «Разве эти чудачества могут повлиять на нас?» — с недоумением сказали бы телефонистки )))

Відповісти

Підтримати

Valentin Nechayev

Valentin Nechayev архімаггриб в Дарницькі печери 15.10.2013 09:23

Это уже всё синтаксическая вкусовщина. Вы обсуждаете Форт на таком примитивном уровне, что мои возражения должны были бы превратится в первые страницы Хелпа.

Вот пока Вы будете воспринимать то, что я говорю, как «синтаксическую вкусовщину», Вы будете удивляться, почему распространение Форта как средства, непосредственно используемого для написания кода, достигло уровня менее сотой доли процента и продолжает стремительно падать.

Не вкусовщина это, а отражение того факта, что мы люди, а не роботы.

К сожалению, глубже синтаксиса частной реализации частного языка в системе Форт, разговор не пошел.

Естественно. Как не пойдёт обсуждение, например, пикника, если перед гостями возникнет трёхметровая стена без единой калитки. Только редкие перелезут через неё — и если для кого-то это морально окупится, то только для адреналиновых аддиктов.

Когда-то и я был таким аддиктом по отношению к средствам нижнего уровня. Это закономерно закончилось в вузе.:)

«Разве эти чудачества могут повлиять на нас?» — с недоумением сказали бы телефонистки )))

Охотно верю, что так и было. Проблема в том, что Ваши любимые средства были передним краем науки лет этак 40 назад. На сейчас то, где вырабатывается наше будущее, находится совсем в других местах.

Відповісти

Підтримати

Кирилл Нечаев

Valentin Nechayev архімаггриб в Дарницькі печери 15.10.2013 09:44

И еще:

На них написано, что вы можете полностью создать нужный вам язык, например, для тренировки, можете симулировать любой другой язык с его синтаксисом. Потому что у Форта нет своего синтаксиса.

Более традиционным образом это называется — язык со встроенными средствами метапрограммирования. Но проблема в том, что чрезмерно низкоуровневый характер этих средств приводит к тому, что на сложных задачах Форт неудержимо проигрывает тем языкам, где оно сделано вообще частью языка — Лисп (все флаворы), Tcl...

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 15.10.2013 11:03

Более традиционным образом это называется — язык со встроенными средствами метапрограммирования.

То, что не имеет синтаксиса и ключевых слов, не входит в объем понятия язык программирования.

Метапрограммирование это костыли, туманные догадки людей, работающих на HLL, и ощущающих смутное беспокойство, — а как бы им исправить постоянно встречающийся недостаток инструментального средства? И что они, бедные, делают? Прикручивают к существующему инструменту надстройку из свистелок и перделок.

То, что свобода сознания попала в рабскую зависимость от представления инструмента, у ремесленника редко осознается. Он готов на священные войны с другими ремесленниками, защищая свой и только свой инструмент. Тот дает ему пропитание, или он сдает себя внаем, это жизнь, и какое место в его сознании занимает инструмент, можно понять.

Но я опять о другом, о том, что армия программистов-пользователей-компиляторов есть путы и кандалы на ногах прогресса компьютеризации, как когда-то дорого обходящаяся армия телефонисток остановила развитие удешевление и распространение телефонизации.

Пользователь компилятора не в состоянии осознать, что можно изменять компилятор, он к этому не обучен. Также, как пользователь MS Word не обучен и не понимает оборот речи «изменять поведение Word, а не свои привычки».

А мысль о том, что можно вообще, как это и делается в Форте, приложение сделать неразрывным комплексом с компилятором и писать их одновременно, (ведь для фортера нет разницы, где поправить или добавить код, в компиляторе или в приложении) — это неслыханное богохульство их идола, что там у них сегодня висит на стенке, Джава или Си...

Вот до такого уровня обсуждение и не поднялось. Forth это трудно. Ни один прием программирования так не изменял мой мозг, как Forth.

Відповісти

Підтримати

Valentin Nechayev

Valentin Nechayev архімаггриб в Дарницькі печери 15.10.2013 12:29

То, что не имеет синтаксиса и ключевых слов, не входит в объем понятия язык программирования.

У Лиспа «нет синтаксиса» ровно в той же степени, что у Форта.

А мысль о том, что можно вообще, как это и делается в Форте, приложение сделать неразрывным комплексом с компилятором и писать их одновременно, (ведь для фортера нет разницы, где поправить или добавить код, в компиляторе или в приложении) — это неслыханное богохульство их идола, что там у них сегодня висит на стенке, Джава или Си...

Вынужден повториться — LISP даёт то же самое, и практически в разы удобнее.

Ни один прием программирования так не изменял мой мозг, как Forth.

Честно, по следам этой дискуссии я думаю, что этому изменению пора делать rollback.

Відповісти

Підтримати

Кирилл Нечаев

Євген Козлов Front-end developer в SoftServe 15.10.2013 12:30

Ни один прием программирования так не изменял мой мозг, как Forth.

Сильная антиреклама.

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 11:52

Чтобы показать, что мы говорим о разных вещах, я приведу пример из истории развития техники и технологии. Развитие технологии всегда идет по пути удешевления, упрощения, сокращения требований к материалоемкости и энергоемкости. Но очевидно, что программирование сегодня задает обратное направление. Продукт пользователей компиляторов требует больше памяти, более мощных процессоров, которые тратят энергию нерезиновых аккумулятор на нагрев окружающей среды, выполняя всё более неэффективные реализации простых функций.

Я встретил этот пример у какого-то программиста, 60-х годов, из IBM.

Когда-то изобрели передачу голоса на расстояние по проводам. Технически, пошел быстрый рост. Звук стал чистым, разборчивым, аппараты удобные, кабели протянулись. Это стало востребованным у населения. Но к этой технической стороне прибавилась целая армия телефонисток. Однако, пригласив сесть за коммутаторы даже всё население страны, способное работать телефонистками, это не решило бы задачу расширения технологии голосовой связи. Армия телефонисток стала кандалами и путами развития. Повсеместное распространение, удешевление, развитие технических возможностей телефонии остановилось.

Но телефонистки ни сном, ни духом не ведали о давлении рыночного спроса и недовольстве заказчиков ценами на зарплаты бригады телефонисток.

Телефонисток заменили автоматы. Сегодняшние программисты, которые попадают под определение пользователи компиляторов, это тогдашние телефонистки.

Телефонистки никогда бы не поверили, что люди быстро предпочтут услышать вместо приятного женского голоса «дежурненькой», умеющей слушать клиента, а особенно знакомого клиента, гудок готовности автоматической станции.

Использование труда таких телефонисток-программистов спутало по рукам и ногам развитие целой отрасли. Они не эффективны. Они делают бизнес-решения слишком дорогими. И они исчезли. Никто не спрашивал их мнение и никто не интересовался больше навыками быстрого решения кого соединить, а кого вежливо попросить заканчивать разговор, потому что каналы ограничены, и ждут еще клиенты.

При этом, и не в этих рядах всё знающих о нуждах клиентов в телефонной связи, и обеспечивающих эту самую связь, телефонисток, потихоньку вытачивалось и рождалось решение по их замене на дешевые реализации. И не в рядах 99% программистов-пользователей-компиляторов сейчас осознается давление спроса и несоразмерная цена на их одинаковую ручную работу за пультом коммутатора-компилятора.

Я говорю с позиций программиста, который не продает программу, которую пишет. Ученый, например, ищет средство написать код, который будет управлять устройствами, опрашивать датчики и выводить на экран. Они не обращаются к программистам, потому что те не в теме их научной области, и слишком дорог их ремесленный труд. ученый пишет сам себе инструмент, который не предназначен изначально для продажи.

Вы же говорите с точки зрения человека, который продает изготовленный на заказ букет связанных функций. Вы как и флорист-цветочник, ориентированы на продажу продукта, изготавливать который умеете по индивидуальному заказу. Вы умеете слушать клиента. Вы знаете, кому халтурку скинуть, а кто внимания требует. Вы не предполагаете, что законы развития техники и технологии сработают и в этом случае. Однажды клиенты предпочтут не бригады телефонисток-флористов, а гудок готовности автомата.

Форт меняет мышление, это исследовательская штучка. Форт программы не продаются. Они придаются к конкретному решению, как торпеда автомобиля придается к конкретной модели автомобиля. Выбросите вместе с вещью, потом. Сам Форт говорит, что нет никакого синтаксиса, вы его сейчас сами создадите. И нет никаких зарезервированных слов, вы их сейчас будете создавать. И вы можете симулировать Паскаль-Аду, или Джаву-Пайтон. Но зачем вам еще один коммутатор, если к нему еще нужна будет телефонистка? Вам нужно что-то другое.

Відповісти

Підтримати

Valentin Nechayev

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 14.10.2013 12:11

При этом, и не в этих рядах всё знающих о нуждах клиентов в телефонной связи, и обеспечивающих эту самую связь, телефонисток, потихоньку вытачивалось и рождалось решение по их замене на дешевые реализации. И не в рядах 99% программистов-пользователей-компиляторов сейчас осознается давление спроса и несоразмерная цена на их одинаковую ручную работу за пультом коммутатора-компилятора.

Вы просто замечательно подменяете интеллектуальную работу механической.

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 12:46

Я просто именно так и считаю, эта т.н. «интеллектуальная работа» есть просто навык быстрого выполнения операций. Профессиональный навык, ремесленника.

Відповісти

Підтримати

Valentin Nechayev архімаггриб в Дарницькі печери 14.10.2013 12:16

> Но очевидно, что программирование сегодня задает обратное направление. Продукт пользователей компиляторов требует больше памяти, более мощных процессоров, которые тратят энергию нерезиновых аккумулятор на нагрев окружающей среды, выполняя всё более неэффективные реализации простых функций.

Это совсем не очевидно. Разумеется, если судить по ярким извращениям, типа iPhone:), то кажется, что все ресурсы уходят на ерунду. Но если сравнить суммарные затраты на одну и ту же задачу, то сейчас они на порядки меньше. Вы пытаетесь судить даже не по вершине айсберга — а по той её части, которую зачем-то облили оранжевой краской.

> Использование труда таких телефонисток-программистов спутало по рукам и ногам развитие целой отрасли.

Отрасль избавилась от «телефонисток» тогда, когда научилось составлению библиотек кода и их цеплянию к прикладным программам. Действительно, для 60-х годов этот переход был ещё актуален. А вот выхватывание этого примера в 2010-х — уже нет. Сейчас другие проблемы и задачи.

> Ученый, например, ищет средство написать код, который будет управлять устройствами, опрашивать датчики и выводить на экран.

Верю. Но при чём тут сложный, неудобный, путаный Форт? Такому учёному лучше взять что-то вроде Basic или Python.

> Форт меняет мышление, это исследовательская штучка. Форт программы не продаются.

Ага — потому что никому нафиг не нужны:) Хотя разработки 80-х на Форте, может, ещё продаются.

> Они придаются к конкретному решению, как торпеда автомобиля придается к конкретной модели автомобиля. Выбросите вместе с вещью, потом. Сам Форт говорит, что нет никакого синтаксиса, вы его сейчас сами создадите. И нет никаких зарезервированных слов, вы их сейчас будете создавать.

Просто ура, однако. А это ничего, что вместо синтаксиса мы получили жёсткое ограничение реализации в виде стеков со всеми их особенностями, и необходимость возиться с ними напрямую, даже «без синтаксиса»?
А если вводим какую-то реализацию, которая это решает — тут синтаксис и встаёт в полный рост. Чудес тут не бывает, если Вы гордо вытащили хвост — то нос увяз по самое горло.

> И вы можете симулировать Паскаль-Аду, или Джаву-Пайтон.

Не могу, не написав достаточный транслятор. А его я предпочту писать на чём-то поудобнее.

> Вам нужно что-то другое.

Верно. Поэтому у меня основным средством, как правило, является Python. О Форте речь пойдёт только для очень специфического embedded.

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 14.10.2013 12:50

> Ученый, например, ищет средство написать код, который будет управлять устройствами, опрашивать датчики и выводить на экран.
Верю. Но при чём тут сложный, неудобный, путаный Форт? Такому учёному лучше взять что-то вроде Basic или Python.

Опрашивать датчики с помощью Python? Управлять течением физического процесса? ))

Відповісти

Підтримати

Valentin Nechayev

Valentin Nechayev архімаггриб в Дарницькі печери 14.10.2013 13:53

Опрашивать датчики с помощью Python? Управлять течением физического процесса? ))

Я вижу, Вам ещё много нового предстоит узнать:)
Представляете, мы такие задачи даже на Erlang писали. И работало, что характерно. А на Питоне — вообще тривиально.

Відповісти

Підтримати

Кирилл Нечаев

Євген Козлов Front-end developer в SoftServe 14.10.2013 13:56

Опрашивать датчики с помощью Python? Управлять течением физического процесса? ))

вы в курсе, на каких языках в текущий момент можно микроконтроллеры программировать? там не только Python в списке, даже с Javascript вариант есть, пускай и прототип пока что.
P.S. я не к тому, что предлагаю перейти на микроконтроллеры. я к тому, что даже в таком случае есть альтернатива.

Відповісти

Підтримати

Кирилл Нечаев

Mikhail Boiko SE в NVIDIA 25.06.2013 22:42

Еще можно попробовать фриланс. Писать программки под контроллеры, у вас там промышленный район, возможно народу требуются люди, способные вправить мозги станкам.

Відповісти

Підтримати

idOne Арбузный 08.07.2013 16:53

возможно

точно

Відповісти

Підтримати

Mikhail Boiko SE в NVIDIA 25.06.2013 22:29

Вам нравится заниматься тем, чем вы занимаетесь?

Я бы начал учить embedded linux и все что около, мне кажется что это близко к вашей тематике. Человек который может заглянуть «под капот» может получать на уровне джава и андройд разработчиков.

Я сам в свое время стоял перед похожим выбором — работал в фирме которая писала ПО для контроллеров автоматизации зданий, правда з/п была выше. Там я прокрутился 3 года, посмотрел за что готовы платить и что мне интересно, начал вечерами книжки умные читать, через год смог найти более денежную работу.

Відповісти

Підтримати

Димон 25.06.2013 22:02

По-моему глупо менять такую специализацию на нынешнюю попсу. Просто вам нужно все свои навыки в правильное русло направить. Ищите, ищите самореализацию в этой области, не гонитесь за мейнстримом, развивайтесь в своей области и подключайте смежные — все это будет востребовано и сегодня, и завтра. За это вполне можно не малые деньги получать, только ищите, не сдавайтесь. А ряды гуанокодерков вы всегда успеете пополнить.
250 бакинских рублей, конечно, мало. Но, коль скоро не загнулись еще, сумеете потерпеть и дальше.

Відповісти

Підтримати

Сергей Анисимов 26.06.2013 12:25

Бред, нужно идти в мейнстрим или так и проживешь нищебродом всю жизнь. Не ценятся у нас программисты контроллеров, не ценятся..

Відповісти

Підтримати

Ще 1 коментар

Димон 26.06.2013 12:44

Бред

Не нужно так категорично. Я не имел в виду остаться именно на мк.

развивайтесь в своей области и подключайте смежные

Т.е. посыл был в том, что асм и С есть куда применить и в других областях.

Відповісти

Підтримати

Сергей Анисимов

Andrii Muzychuk Salesforce Engineer в InCountry 25.06.2013 21:48

У моего друга такая же ситуация. Только он решил, что программирование не его и он начал штудировать QA.
Вы можете в Automated QA пойти, если программирование ваше.
А вообще, С и Ассемблер — это правильно. Ща роботы пойдут, их надо будет кому-то программить. Сейчас уже много роботизированно. Да, нужен ангглицкий, так как не в нашей стране это востребованно.
А вообще — dou.ua/...abota-studenta

Відповісти

Підтримати

СНИКЕРС 26.06.2013 01:01

Ого, редко когда программист идет в QA, чаще всего на оборот ...

Відповісти

Підтримати

Andrii Muzychuk

Ще 1 коментар

Andrii Muzychuk Salesforce Engineer в InCountry 26.06.2013 03:04

Для друга это слишком напрягающая деятельность. Проще тестером сидеть и монотонно клацать сценарии.

Відповісти

Підтримати

Artem Komisarenko C++ Software Developer в Zultys 24.06.2013 19:32

«Моя зарплата 250 баксов и НИКАКОЙ перспективы»
Да ладно, никакой. Никакой — это на вашем текущем предприятии. Посмотрите зарплатный опрос, поклацайте языки/опыт/город и тогда уже делайте выводы о своем языке, городе, фирме.

Вообще год опыта — это уже вполне комфортный опыт для смены места работы и перехода из дешевой «кузницы кадров» во что-то более приличное.

Відповісти

Підтримати

Олексій Пєніє 24.06.2013 13:52

ООП очень просто для понимания, и учить его противопоказано. Нужно начать пользоваться, и понимание займёт пару часов.

Насчёт туманных перспектив, всё-таки копай своё направление. Хотя рынок и небольшой, но найти на нём спеца — сложнее на порядок. Подумай о переезде в Киев. Просто разузнай как там с этой работой. Это полностью другой рынок. И всё-таки в той же стране, без переезда. Также не мешает Москву глянуть, всё-таки русскоязычная территория.

Рынок MobileDev находится на пике своего развития. Там огромны затраты на продажу продукта, а потому его ждёт серьёзнейшее падение, когда люди наиграются. Разве только игры делать — в них не наиграются никогда. Всё остальное — дефакто уже покрыто стартапами, и вклиниться туда будет ооочень сложно.

Я так считаю, что с годом работы в Си и Ассемблере ты освоишь ООП на С++ или Java очень быстро, я бы сказал за неделю максимум. И можешь идти Джуном в Днепре куда пожелаешь. Весь этот «зоопарк» досконально надо знать только сеньйору и выше, от джуна треуется весьма скромный набор инструментов. По секрету, опытные тоже пользуют из всего этого зоопарка лишь мааленькую часть.

Вот Английский — да. Его практически невозможно использовать частично. К его изучению стоит подойти очень серьёзно. Не по выходным, а каждый день.

Відповісти

Підтримати

Євген Козлов Front-end developer в SoftServe 08.07.2013 18:23

ООП очень просто для понимания, и учить его противопоказано. Нужно начать пользоваться, и понимание займёт пару часов.

угу, «освой ООП за 2.1 часа»
иногда от вида структуры классов хочется вырвать себе глаза.

Відповісти

Підтримати

Олексій Пєніє

Ще 2 коментарі

Олексій Пєніє 08.07.2013 20:33

Согласен. Настройка и освоение IDE — задача более сложная, чем изучение языка. К этому стоит добавить настройку системы, джентельменский набор софта.

Например меня до сих пор тошнит от дерева классов с левой стороны. Для быстрого восприятия ничего читаемого слева быть не должно! Например на ДОУ ничего нет слева. Но разве дерзнёт новичёк без посторонней помощи строить рабочее окружение? Точно нет. Этому нужно учить.

Кстати, это неверно что программирование начинается с Hello World. Настоящее программирование — это Hello World 2. Когда удаётся создать первые аналоги, наступить на первые грабли, прочитать первую документацию, и понять первое исключение. И это самая существенная дыра высшего образования — даются знания, но не даётся право их проверить. От чего они забываются, так и не родишись. Обязанность выполнить какие-то лабораторные только усугубляет картину: предписанные действия, предсказанный результат.

Может кто-то не знает, но джуны выгорают тем же механизмом: Достаточно поставить запреты и не дать возможности риска — и человек навсегда «присваивает» административную норму поведения, не может работать без указания сверху, боится ответственности, и отвергает право выбора.

Есть и другой механизм «выгорания» — избыточный выбор. Когда права даны такие, что все испробовать не хватит времени. И отпустить жалко, и продвинуться не может. Так рождаются «лентяи-трудоголики». Вечно занятые люди, у которых ни на что важное нет времени. Что-то мне подсказывает, топикпастер подсел на этот соблазн.

Золотой середины — нет. Единственное что удерживает баланс — право «младших» на ошибку. Если его лишить, старшие тут же оказываются с избыточным выбором. А пока такое право есть, неизбежны конфликты [и это часть права на ошибку]. Именно конфликт заставляет джунов включать мозг на 100% для рискованных действий (и подключать помощь старших). И только конфликт способен подтолкнуть старших к стремлению быть лидерами.

Такое знание можно получить в процессе работы либо в очень хорошей компании [конфликт — двигатель], либо в очень плохой [конфликты неизбежны]. А ещё — в изучении языка! Почему и рекомендовал ~~учить~~ использовать английский каждый день.

Пронаблюдайте за детьми, как учатся они: конфликтуют и мирятся по 10 раз в день. Что они делают? Неправильный ответ «играют». Правильный — учат язык. И отношения вместе с ним.

Відповісти

Підтримати

Євген Козлов

Valentin Nechayev архімаггриб в Дарницькі печери 07.10.2013 17:24

Для быстрого восприятия ничего читаемого слева быть не должно!

Вы бы за всех не говорили:)
Мне вот во многих случаях как раз не должно быть лишнего справа.

Відповісти

Підтримати

Олексій Пєніє

Максим Вовк 24.06.2013 13:12

Спасибо всем что помогаете мне, пока читаю Java и C# параллельно что бы понять на чём остановится, и если честно покамест больше нравится C#.

Відповісти

Підтримати

zdfv zdf 24.06.2013 13:54

Оно не удивительно, С# как язык намного лучше джавы, но на джаву спрос больше и на 10-15% больше ЗП, ну и с джавой ты не будешь привязан к Майкрософту.
А так, не суть важно, выбирай что больше понравится.

Відповісти

Підтримати

Максим Вовк

Misha Tab 13.07.2013 18:10

Я и на Java и на C# успел поработать. Честно — неважно что выбрать. Java и C# — это очень похожие языки. И тут я говорю не о синтаксическом сахаре, которого в C# больше, а о подходах, общих практиках, философии языка. Поработав на одном языке какое-то время, набравшись опыта в паттернах проектирования, известных фреймворках — вы быстро освоите аналогичные инструменты и технологии на другом языке. Это не сложно, потому что языки, технологии и область применения — очень похожи.
Такой трюк, конечно не пройдет, если вы переходите с Java на Perl, а для Java — C# и наоборот — работает.

Відповісти

Підтримати

Максим Вовк

СНИКЕРС 24.06.2013 12:50

Сейчас так много людей кинулись на Java и курсов без границ появилось по этому учите C# ибо вас «шарпистов» будет меньше и это будет лучше !!!

Відповісти

Підтримати

Victor Prokopovych 15.07.2013 14:46

Единицы заканчивают курсы.

Відповісти

Підтримати

Ще 1 коментар

СНИКЕРС 15.07.2013 19:06

Я просто хотел указать на то что «шарпистов» меньше чем «джавистов», а пользуються спросом одинаково (ну «джависты» чуть больше, но не критично) !!!

Відповісти

Підтримати

Victor Prokopovych

anonymous 23.06.2013 19:30

-

Відповісти

Підтримати

Grez 24.06.2013 01:26

Ага, а на собеседовании так и спросят, а сколько лет опыта конкретно работы с джирой. а сколько с свном ? )))

Відповісти

Підтримати

idOne Арбузный 08.07.2013 16:55

умение пользоваться еклипсом

берите выше — IDEA

Відповісти

Підтримати

Egon Schiele 07.10.2013 14:42

«Умеете ли вы программировать на Ajax?»

Відповісти

Підтримати

fuji F 23.06.2013 17:44

www.work.ua/jobs/1247151 ? Новомосковск который под Днепропетровском? Что в Днепре нет подходящих вакансий?

Відповісти

Підтримати

zdfv zdf 23.06.2013 17:24

Лучший для тебя вариант это выучить Джаву или шарп и идти джуном, с учетом того что программировать то ты уже умеешь, то до джуна выучишься за 1 месяц, это если заниматься хотя бы по 2-3 часа в день.
Лично я бы рекоменовал джаву, т.к. вакансий чуть больше чем на шарп и платят тоже чуть больше. Но на шарпе приятнее писать, сам язык значительно более продвинутый, хотя тебе после си++ и ассемблера и джава будет бальзамом на душу )
Весь тот зоопарк на джуна знать не надо. Главное — хорошее знание Java Core и иметь начальное общее представление о JavaEE.

В мобильную разработку сходу лезть не стоит, потом когда поработаешь джава джуном полгодика уйдешь в андроид, если будет желание.

Відповісти

Підтримати

anonymous 23.06.2013 15:44

-

Grez 23.06.2013 13:38

чистый Си и Ассемблер

250 баксов и НИКАКОЙ перспективы

Круто!
Подучите, чтоли С++, и ломитесь, чтоли в самсунг...

Відповісти

Підтримати

Max Ischenko Founder в DOU.ua 23.06.2013 17:47

Учитывая что Самсунг активно берет студентов вообще без опыта это неплохой вариант для старта.

Відповісти

Підтримати

Grez

СНИКЕРС 23.06.2013 10:13

Как по мне так супер просто и очень быстро это Python+Django\Pyramid (ну ещё надо CSS, HTML,JS)

Відповісти

Підтримати

Viacheslav 23.06.2013 15:20

А еще проще PHP

Відповісти

Підтримати

Ще 3 коментарі

Maks Slesarenko Web Developer 23.06.2013 16:10

Вот с чего вы взяли? Судя по вашим скилам ви незнаете ни пхп и питона.
Пхп проще когда хело верд или парсер писать. Ближе всего к джанге в пхп это наверное вторая симфони, как по мне так джанга проще (писать нужно меньше кода, как следствие меньше ошибок, пакеты намного стабильнее и их намного больше и так далее)

Відповісти

Підтримати

proger 23.06.2013 16:26

у питона одна проблема — их два

Відповісти

Підтримати

Maks Slesarenko

Valentin Nechayev архімаггриб в Дарницькі печери 07.10.2013 17:23

Это временно.

Відповісти

Підтримати

anonymous 23.06.2013 02:19

Не стоит кидаться в омут ради зарплаты, существует большая вероятность того что половина скилзов будут мало востребованы лет через 5-8.

Могу посоветовать найти свою модель работы которая начнет приносить растущий доход, а будет это PHP, Java, либо плюсы — дело десятое так как программирование — это прикладная наука, и используется для достижения конкретных целей в настоящий момент времени.

Відповісти

Підтримати

Максим Вовк 23.06.2013 10:18

Вы просто не представляете как я меня достала зарплата 2000грн, у меня высшее образование, а я даже машину продал потому что просто не могу её содержать, видел вакансию грузчик где обещают 3500грн !

Відповісти

Підтримати

Ще 9 коментарів

anonymous 23.06.2013 17:57

Вибачте, зроблю скрін. =)

Вибирайте що ближче — C++,Java, .Net і за 2 роки роботи джуном попутно вивчите зоопарк)

Відповісти

Підтримати

Максим Вовк

Yevhenii Rybakov Scrum Master в Prometheus RIS 26.06.2013 09:26

О местный трубный завод!

Выбирайте что по душе, идите джуном. Тем более Днепропетровск рядом, что-то найдете обязательно. На предмет большого количества непонятных аббревиатур

Spring, Hibernate, XML, XSL, XSLT, xsd, Design Patterns, Unix/Linux, SVN,Tomcat, JBOSS application servers, JIRA, IDE (Eclipse, IntelliJ), SaaS, Web Services, SOAP, REST, WSD

не заморачивайтесь.

Вам Успехом!

Відповісти

Підтримати

Максим Вовк

Egon Schiele 07.10.2013 14:45

Проблема в твоем городе. РНР и Явы всякие там так же будут оцениваться. Переезжай в другой город.

Відповісти

Підтримати

Максим Вовк

shadow 07.10.2013 15:40

А лидеры рынка не берут даже на $500?

Відповісти

Підтримати

Максим Вовк

noname fordou 07.10.2013 16:58

в Новомосковске, их, судя по всему, не густо.
а переезжать с условием аренды на 500 баксов зп джуном в бодишоп имхо сложновато.
хотя — снимите комнату и пойдите хотя бы в Днепропетровск на джуна...

Відповісти

Підтримати

shadow 08.10.2013 10:26

Вы шутите? Новомосковск совсем рядом доехать не проблема.

Відповісти

Підтримати

noname fordou 08.10.2013 11:58

Ехать 37 мин, 26 км. Ну не сильно и близко ... Хотя для начала сойдет.

Відповісти

Підтримати

Eugene Kyba 08.10.2013 13:34

37 мин, 26 км

Это вообще не расстояние.

Відповісти

Підтримати

noname fordou 08.10.2013 15:49

Это вообще не расстояние.

1) + 1.5 часа на дорогу
2) билет в одну сторону стоить будет гревен 12. т.е. + 500 грн в месяц на транспорт, что при зп в 2000 грн вполне заметно.
хз, может проще таки комнату снять.

Відповісти

Підтримати

Viacheslav 23.06.2013 00:56

Смотрел в сторону JavaEE, а там такой зоопарк надо знать : Spring, Hibernate, XML, XSL, XSLT, xsd, Design Patterns, Unix/Linux, SVN,Tomcat, JBOSS application servers, JIRA, IDE (Eclipse, IntelliJ), SaaS, Web Services, SOAP, REST, WSDL

Не очень то и зоопарк. Джуну всего этого знать глубоко не нужно. И то не факт что попадешь на проект с спрингом и хибернейтом. Возможно что будет какой-то EJB 2.1, Servlets и JDBC например, или что-то другое. Познай на глубоком уровне Java core и можеш идти джуном в энтерпрайз

Відповісти

Підтримати

Максим Вовк 23.06.2013 10:19

Вы думаете что стоит остановится на Java ?

Відповісти

Підтримати

Ще 1 коментар

Viacheslav 23.06.2013 15:21

Думаю стоит, хотя с опытом С и асма можно выучить С++ и в самсунг идти. Хотя решать тебе

Відповісти

Підтримати

Максим Вовк

proger 23.06.2013 00:54

из знаний это чистый Си и Ассемблер

это очень круто кстати

как быстрее стартануть

обзорно изучить выбранную технологию (написать простенькую программку, желательно связанную с бд) , затем нагуглить тесты-вопросы собеседований и разобраться с ними

все, можно двигаться в джуны

в принципе бєкграунд в виде асма и си лучше ложиться на сервер сайд разработку, чистая гуй разработка (что в мобилках, что в винде) достаточно сложная тема для новичка

Відповісти

Підтримати

Максим Вовк 23.06.2013 10:21

То есть с ваших слов MobileDev — это не так просто как на первый взгляд кажется ?

Відповісти

Підтримати

Ще 4 коментарі

Viacheslav Titov Mobile Fullstack Software Developer (Android, IOS, Flutter, React-Native) в Agiliway 23.06.2013 13:50

Я думаю Вам будет не просто, особенно без глубоких знаний ООП. Для Android\a придётся сначала выучить Java, а потом уже приступать к Android SDK. Я бы посоветовал выучить Java SE, и дальше уже можно джуном пытаться устраиваться будь то Java EE или Android

Відповісти

Підтримати

Максим Вовк

proger 23.06.2013 14:02

ну обычно чем проще работа тем меньше за нее платят (если конечно не трогать местных заказчиков, которые платят сколько могут )
так что первое правило — никогда не работать на местных

Відповісти

Підтримати

Максим Вовк

Kostiantyn Sokolinskyi CTO в company 23.06.2013 17:22

В мобайле в начале все просто просто, а потом начинается темный лес и гоблины + пиксели двигать еще тот геморрой :) ну и ООП везде.

Но если свой апп налабаете простенький и с базовыми вещами разберетесь, то джуном куда-нить да возьмут — людей всем не хватает. В сети сейчас море туториалов, можно быстро стартануть. И ООП подучите — там ничего военного. Obj-c кстати на порядок проще с++

Відповісти

Підтримати

Максим Вовк

anonymous 24.06.2013 20:47

То есть с ваших слов MobileDev — это не так просто как на первый взгляд кажется ?

Вообще не просто :) Если делать как надо, а не как все.

А из вот этого списка, кстати:

Spring, Hibernate, XML, XSL, XSLT, xsd, Design Patterns, Unix/Linux, SVN,Tomcat, JBOSS application servers, JIRA, IDE (Eclipse, IntelliJ), SaaS, Web Services, SOAP, REST, WSDL

четверть осваивается за ДЕНЬ (совокупно! — джира, томкэт, свн, ИДЕ...), еще часть — за месяц, а остальное — зависит от вашего усердия.
Да и такой зоопарк многие синьоры знают в качестве баззвордов, а на деле используют чуть реже, чем никогда (в рамках одного проекта).

Відповісти

Підтримати

Максим Вовк

Підписатись на коментарі

Ваша пошта

Не підписуватись