IDE-то се ползва само за дебъгване,как дебъгвате с тия шелове само вие си знаете 
Защо рамта е 500 лв
Дърти Хари Major Obvious Дърти Хари всеки професионален програмист ползва среда
Vim-a за среда ли се брои? Ако не, това е супер. Щом и като аматьор ми плащат, като стана професионалист представям си какво ще е.
На Линукс или Юникс както и да е, като няма какво друго трябва с текстов едитор, но на другите операционни системи си има IDE и те ускоряват работата. Не виждам смисъл да си утежнявам работата.
Егати и идиотската дискусия се заформи,ама с идиоти като Пайпа всички дискусии завършват така.
Верно ли няма друго на Линукс "и Юникс" (хехе)? Абе, ти наистина ли си въобразяваш, че си професионалист? :)
| Дърти Хари Major Obvious Дърти Хари всеки професионален програмист ползва среда
Vim-a за среда ли се брои? Ако не, това е супер. Щом и като аматьор ми плащат, като стана професионалист представям си какво ще е.
На Линукс или Юникс както и да е, като няма какво друго трябва с текстов едитор, но на другите операционни системи си има IDE и те ускоряват работата. Не виждам смисъл да си утежнявам работата.
Егати и идиотската дискусия се заформи,ама с идиоти като Пайпа всички дискусии завършват така.
Верно ли няма друго на Линукс "и Юникс" (хехе)? Абе, ти наистина ли си въобразяваш, че си професионалист? :)
Ами шест цифри стигат да си плащам някои от сметките.
Courvoisier | Да си чувал за текстови редактори, които могат да отварят повече от един файл? Ти повече от един файл ли можеш да редактираш във всеки един момент? Как го правиш този номер?
Чувал съм, но нямат reference, не билдват в бекграунда, нямат follow и т.н.
А ти каза шел. За да бачкам в шел с вим или нано ми трябва да отворя всеки файл. Поне с кат да ги гледам. Помни се до едно време, после туулувете правят живота по- лесен. Макар, че пиша по 20-30 файла, преди да рънна нещо, предпочитам когато ми се наложи на натисна клавиш/комбинация, отколкото да си местя папката в шела и да търся кое къде е.
Ами за теб IDE е по-лесно, за мен не е. Просто е малоумно да смяташ, че каквото е лесно за теб е лесно за всички. А Дъртия Хари се оказа пълен идиот, смятащ, че щом е Мак, трябва да изполваш Xcode. :)
Дърти Хари | Верно ли няма друго на Линукс "и Юникс" (хехе)? Абе, ти наистина ли си въобразяваш, че си професионалист? :)
Ами шест цифри стигат да си плащам някои от сметките.
Мда, явно наистина няма хора...
Дърти Хари Абе идиот, ти си пиши с Notepad, аз ще си пиша на Visual Studio, Android Studio и Xcode. Като всеки нормален програмист.
Ако под "нормален" имаш предвид "среден", мисля че ще се съглася с теб. Някъде между "некадърен" и "среден" си. :)
Courvoisier Обаче не разбрах защо ъпгрейда на рам ми е 500 лв, а не 100-200. Поят го със някакъв специален калай ли?
Защото за толкова го продават от Апъл. Какво толкова не можеш да разбереш?
IDE-то се ползва само за дебъгване,как дебъгвате с тия шелове само вие си знаете :-)
Ми лесно, то не е много по-различно ако трябва да съм честен, където с IDE-то примерно ще нацвъкаш breakpoint на някой ред, с gdb-то слагаш breakpoint-а на адрес в паметта, е след като имаш дебъг символи имаш и адреса на който е тоя ред, абе накратко дето в IDE-то цъкаш с мишката, в конзолата пишеш една вълшебна нищонезначеща якосъкратена команда и копипействаш адреса с мишката.
saruman IDE-то се ползва само за дебъгване,как дебъгвате с тия шелове само вие си знаете
Аз рядко дебъгвам с дебъгер. Мисля, че бях го пускал това вече:
As a personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code a1 critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugger sessions are transient.
gat3way IDE-то се ползва само за дебъгване,как дебъгвате с тия шелове само вие си знаете :-)
Ми лесно, то не е много по-различно ако трябва да съм честен, където с IDE-то примерно ще нацвъкаш breakpoint на някой ред, с gdb-то слагаш breakpoint-а на адрес в паметта, е след като имаш дебъг символи имаш и адреса на който е тоя ред, абе накратко дето в IDE-то цъкаш с мишката, в конзолата пишеш една вълшебна нищонезначеща якосъкратена команда и копипействаш адреса с мишката.
То това е само началото,ми след това - print a,print b,bt,s,n,print a,print b, .... ,иначе не е по-различно да,той дебъгера е еднакъв
Не мисля че някой пише "print" там, всички ползват просто "p".
gat3way Не мисля че някой пише "print" там, всички ползват просто "p".
И п да е,тия лайна в едно нормално иде ги няма,имаш си и call stack ,и watch variables прозорец
saruman gat3way Не мисля че някой пише "print" там, всички ползват просто "p".
И п да е,тия лайна в едно нормално иде ги няма,имаш си и call stack ,и watch variables прозорец
Wow, имаш прозорец, а? Това е невероятно ценно. Какво е това call stack, никога не съм чувал за него? Това в отделен прозорец ли е, или го пускат през вратата? :)
П.П. В gdb ако искаш call stack, просто пишеш bt.
Това дето наистина ти трябва го има, всъщност то всичко го има, в крайна сметка иде-то си е фронтенд към същия шит, това което ти трябва обаче е достъпно сравнително бързо и лесно. И това не е мое си субективно мнение, просто с времето е еволюирало по този начин, явно е имало причина.
Тези спорове са все едно да спориш дали филмите по телевизията са по-добри от четенето на книги. Някои предпочитат да четат книги, други да гледат телевизия.
А спорът започна заради канадския малоумник, според който на МакОС има само едно ИДЕ. Всъщност не, положението е още по-зле, идиота си мисли, че единствения начин да програмираш на Мак е с Xcode.
| saruman gat3way Не мисля че някой пише "print" там, всички ползват просто "p".
И п да е,тия лайна в едно нормално иде ги няма,имаш си и call stack ,и watch variables прозорец
Wow, имаш прозорец, а? Това е невероятно ценно. Какво е това call stack, никога не съм чувал за него? Това в отделен прозорец ли е, или го пускат през вратата? :)
П.П. В gdb ако искаш call stack, просто пишеш bt.
Не че ги няма,достатъчно съм дебъгвал с gdb през конзолата,имах предвид,че всичко става в пъти по-бавно
saruman | saruman gat3way Не мисля че някой пише "print" там, всички ползват просто "p".
И п да е,тия лайна в едно нормално иде ги няма,имаш си и call stack ,и watch variables прозорец
Wow, имаш прозорец, а? Това е невероятно ценно. Какво е това call stack, никога не съм чувал за него? Това в отделен прозорец ли е, или го пускат през вратата? :)
П.П. В gdb ако искаш call stack, просто пишеш bt.
Не че ги няма,достатъчно съм дебъгвал с gdb през конзолата,имах предвид,че всичко става в пъти по-бавно
Изобщо не съм съгласен, че става по-бавно. Въпрос на навик и опит.
| saruman IDE-то се ползва само за дебъгване,как дебъгвате с тия шелове само вие си знаете
Аз рядко дебъгвам с дебъгер. Мисля, че бях го пускал това вече:
As a personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code a1 critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugger sessions are transient.
Това не мога да се съглася,че е вярно,едно е да пишеш по правила за clean code,съвсем друго е да мяташ принтове на всеки ред щото не ползваш дебъгер
saruman | Аз рядко дебъгвам с дебъгер. Мисля, че бях го пускал това вече:
As a personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code a1 critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugger sessions are transient.
Това не мога да се съглася,че е вярно,едно е да пишеш по правила за clean code,съвсем друго е да мяташ принтове на всеки ред щото не ползваш дебъгер
Ами ако видиш Роб Пайк и Брайън Кърниган някъде може да им кажеш, че не разбират от програмиране. :)
| Тези спорове са все едно да спориш дали филмите по телевизията са по-добри от четенето на книги. Някои предпочитат да четат книги, други да гледат телевизия.
А спорът започна заради канадския малоумник, според който на МакОС има само едно ИДЕ. Всъщност не, положението е още по-зле, идиота си мисли, че единствения начин да програмираш на Мак е с Xcode.
Аве идиот, казах, че е по-удобно. Ти пробвай да публикуваш ап в апстора без Xcode.
Навремето докато бях асистент в един германски университет имах колега същия ненормалник. Писа си дисертацията на LateX понеже било по-тарикатски.