ללמוד לתכנת באינטרנט

[wa11a]

אתה יכול לתת דוגמה?

נראה לי שהוא מתכוון שבשפות העיליות החדישות יותר זמן הפיתוח קצר יותר, והפיתוח קל יותר , שזה הגיוני לשם כך הן קיימות(בעיקר).

 

[אבא עשיר]

אתה יכול לתת דוגמה?

בשפת C צריך להקצות מקום בזיכרון ולבדוק אם הוקצה וכ"ו(realloc,malloc,calloc).
וב JAVA זה נעשה מ"אחורי הקלעים".

 

[כסף_כסף]

בשפת C צריך להקצות מקום בזיכרון ולבדוק אם הוקצה וכ"ו(realloc,malloc,calloc).
וב JAVA זה נעשה מ"אחורי הקלעים".

למשל
אבל באופן כללי, רמות אבסטרקציה גבוהות יותר ושימוש באלפי שנות אדם שמוטמעות ב 30 שכבות שבהם אתה משתמש בפועל אל מול שפות ישנות יותר
שלא לדבר על סביבת הפיתוח עצמה

אני זוכר עוד בסביבות שנת 2000 שעברתי מ VB6 ל C++ לאיזה שנה ועוד עם MFC זה הרגיש לי כאילו חזרתי 10 שנים אחורנית
מאז לשפות כמו .NET היו איזה 15 שנה להשתפר
ואני רק מדמיין לעצמי איך ניראת סביבת פיתוח של AS/400..

 

[c881]

כלומר, אתה מדמיין...
הבעיה עם סביבות העבודה ה"ישנות" שהמפתח צריך ממש לזכור פקודה ולא רק ללחוץ "." אחרי שם משתנה או פונקציה כדי לקבל את האופציות של אותו גורם.
גם הצבעים לא משהו. מסך שחור עם כל המלל באותו צבע.
לגבי הקצאת זכרון, יותר מדוייק הקצאת קבצים, צריך לזכור לשחרר קבצים באופן יזום תוך כדי תכנית למקרה וכמה אנשים עובדים על אותם קבצים.
תוכנית ה"הרצה" צריכה לבדוק שיש לה את כל המשאבים שהתוכנית מבקשת.

זו גם הסיבה שאני בטוח ש- @Syxok יכול ללמוד איזו שפה שלא ירצה "מהאינטרנט" אחרי 6~8 שנים על עבודה בשפה "ישנה".

לגבי זמן פיתוח קצר יותר...
הכל תלוי מה אתה מפתח.

 

[כסף_כסף]

כלומר, אתה מדמיין...
הבעיה עם סביבות העבודה ה"ישנות" שהמפתח צריך ממש לזכור פקודה ולא רק ללחוץ "." אחרי שם משתנה או פונקציה כדי לקבל את האופציות של אותו גורם.
גם הצבעים לא משהו. מסך שחור עם כל המלל באותו צבע.

נכון, והרבה מתכנתים בכלים האלה ממש מתגאים בכך שזה המצב, כאילו זה הישג שהם אשכרה מצליחים לתכנת ככה
קשה לי להבין את זה
הרי תיכנות זה לא תחרות שחיה, שנגיד מי שמצליח לשחות עם יד אחת קשורה מאחורי הגב בהכרח שחיין יותר טוב
בסופו של דבר זאת עבודה עם מטרה והדברים האלה פוגעים בפרודוקטיביות
מה גם שבסביבות פיתוח מודרניות כמות האובייקטים והפקודות היא כל כך גדולה, במיוחד אם אתה מתכנת בתחומים שונים בכל פעם, שאין סיכוי לזכור את הכל בעל פה
מתכנת טוב בעיני הוא לא אחד שזוכר הרבה פקודות, הוא אחד שיודע למצוא אותן מהר

לגבי זמן פיתוח קצר יותר...
הכל תלוי מה אתה מפתח.

זה נכון

 

[דגגגג]

בשפת C צריך להקצות מקום בזיכרון ולבדוק אם הוקצה וכ"ו(realloc,malloc,calloc).
וב JAVA זה נעשה מ"אחורי הקלעים".

ברור זה הרבה יותר יעיל מהג'אווה שפשוט מפרק לך את הזיכרון כאילו זה משאב בלתי נגמר. ב embedded אין לך את הפריבילגיה של לתת למשתמש הודעה להפעיל מחדש את התכנית כי הזיכרון הולך להגמר.
יותר מזה גם אם יוצרים struct מסויים צריך לדעת לסדר את המשתנים בסדר מסויים כדי שלא יקחו יותר מדי זיכרון כתוצאה מ padding.
בקיצור צריך לחשוב כדי לכתוב תכניות יעילות.

 

[כסף_כסף]

ברור זה הרבה יותר יעיל מהג'אווה שפשוט מפרק לך את הזיכרון כאילו זה משאב בלתי נגמר. ב embedded אין לך את הפריבילגיה של לתת למשתמש הודעה להפעיל מחדש את התכנית כי הזיכרון הולך להגמר.
יותר מזה גם אם יוצרים struct מסויים צריך לדעת לסדר את המשתנים בסדר מסויים כדי שלא יקחו יותר מדי זיכרון כתוצאה מ padding.
בקיצור צריך לחשוב כדי לכתוב תכניות יעילות.

אני רחוק מלהיות מומחה ב embedded, אך בתור מסתכל בחוץ נראה לי שהחשיבות של מה שאתה כותב הולכת ופוחתת ככל שהטכנולוגיה מתקדמת
ב99% מהתוכנות למחשב האישי זה חסר חשיבות לחלוטין כבר היום.
המשאבים העומדים לרשות סביבות ה embeded למיניהם גודלים גם כן ובעוד מספר שנים גם שם זה יהיה חסר חשיבות לחלוטין, אולי מלבד למספר מאוד מצומצם של אנשים שממש בונים את מערכות ההפעלה.
המיקוד בתכנות עובר מעולם היעילות והחסכון במשאבי מערכת ליעילות וחסכון במשאבי הפיתוח.

 

[c881]

@כסף_כסף אתה מצחיק בזה.
פעם המחשב השתמש ב-640K זכרון ולפני גם ב-8K. הצליחו לתכנת לדבר הזה תוכניות.
היום אתה מפעיל מחשבים כל כך חזקים במשאבי החומרה שלהם ועדיין כל מה שעושים זה לגלוש באינטרנט ולהריץ סביבת עבודה לפיתוח.
חצי ממשאבי המחשב אם לא יותר - הולכים על להריץ את מערכת ההפעלה.

ב-MF של IBM יש כמה וכמה חלקים לזכרון. בהתאם לשנים בהם פיתחו - ****, 2GB, 4GB, 64GB- זכרון RAM.
בהתחלה היה רק **** וכל התוכנות היו צריכות להסתדר עם זה - יחד עם מערכת ההפעלה.
אחר כך גדל ל-4GB והשתמשו ב-**** הראשונים רק בשביל פוינטרים לאיפה יושבת מערכת ההפעלה, עם חלוקה בין 2GB ומעל 2GB עד 4GB.

ואז קרה מקרה וקפצו אל מעל ל-4GB - ישר לעד 64GB (אני חושב שהיום כבר יש גם 128).
הלכו לאחראי על פיתוח החומרה ושאלו "מה נעשה עכשיו? עד אתמול עבדנו עד ה-2GB ומעל 2GB, עכשיו נאלץ לוותר על הביט דגל ולמעשה איבדנו 2GB".
הבחור חשב קצת ואמר "אז הלכו 2GB, יש לכם 62GB אחרים. תסתדרו".

לגבי שהמיקוד בתכנות עובר מעולם היעילות במשאבי המערכת ליעילות במשאבי הפיתוח...
אם התוכנית שלך רצה על מחשב אחד פעם בחודש - כפרה על היעילות במשאבי המערכת - נחיה עם זה.
אם התכנית שלך רצה על 100,000 מחשבים 60 פעם בשעה - כפרה על היעילות במשאבי הפיתוח - התכנית צריכה לחסוך במשאבי מערכת.

 

[כסף_כסף]

@כסף_כסף אתה מצחיק בזה.
פעם המחשב השתמש ב-640K זכרון ולפני גם ב-8K. הצליחו לתכנת לדבר הזה תוכניות.
היום אתה מפעיל מחשבים כל כך חזקים במשאבי החומרה שלהם ועדיין כל מה שעושים זה לגלוש באינטרנט ולהריץ סביבת עבודה לפיתוח.
חצי ממשאבי המחשב אם לא יותר - הולכים על להריץ את מערכת ההפעלה.

ב-MF של IBM יש כמה וכמה חלקים לזכרון. בהתאם לשנים בהם פיתחו - ****, 2GB, 4GB, 64GB- זכרון RAM.
בהתחלה היה רק **** וכל התוכנות היו צריכות להסתדר עם זה - יחד עם מערכת ההפעלה.
אחר כך גדל ל-4GB והשתמשו ב-**** הראשונים רק בשביל פוינטרים לאיפה יושבת מערכת ההפעלה, עם חלוקה בין 2GB ומעל 2GB עד 4GB.

ואז קרה מקרה וקפצו אל מעל ל-4GB - ישר לעד 64GB (אני חושב שהיום כבר יש גם 128).
הלכו לאחראי על פיתוח החומרה ושאלו "מה נעשה עכשיו? עד אתמול עבדנו עד ה-2GB ומעל 2GB, עכשיו נאלץ לוותר על הביט דגל ולמעשה איבדנו 2GB".
הבחור חשב קצת ואמר "אז הלכו 2GB, יש לכם 62GB אחרים. תסתדרו".

לגבי שהמיקוד בתכנות עובר מעולם היעילות במשאבי המערכת ליעילות במשאבי הפיתוח...
אם התוכנית שלך רצה על מחשב אחד פעם בחודש - כפרה על היעילות במשאבי המערכת - נחיה עם זה.
אם התכנית שלך רצה על 100,000 מחשבים 60 פעם בשעה - כפרה על היעילות במשאבי הפיתוח - התכנית צריכה לחסוך במשאבי מערכת.

נראה לי שפשוט נסכים לא להסכים.. כל אחד מסתכל על זה מנקודת המבט שלו ושל התחום שבו הוא עוסק

 

[c881]

כנראה שכן.
זה די בעייתי מבחינתי שאם יש לי גרסה של .NET משנה 2005, אני לא יכול לפתח/לקמפל תוכניות שנכתבו עם .NET גרסת 2008. כאילו שמדובר ב-OFFICE.
אם הייתי צריך רק לקנות מחשב חדש כי אני לא מצליח להריץ משחק חדש - ניחא.
אבל צריך לקנות מחשב חדש רק כדי להריץ סביבת עבודה כבדה יותר.

נ.ב.
קטע שפעם מצאתי -

My experience as a programmer has taught me a few things about writing software.
Here are some things that people might find surprising about writing code:

A programmer spends about 10-20% of his time writing code, and most programmers write about 10-12 lines of code per day that
goes into the final product, regardless of their skill level.
Good programmers spend much of the other 90% thinking, researching, and experimenting to find the best design.
Bad programmers spend much of that 90% debugging code by randomly making changes and seeing if they work.
“A great lathe operator commands several times the wage of an average lathe operator,
but a great writer of software code is worth 10,000 times the price of an average software writer.” –Bill Gates
A good programmer is ten times more productive than an average programmer.
A great programmer is 20-100 times more productive than the average.
This is not an exaggeration – studies since the 1960's have consistently shown this.
A bad programmer is not just unproductive – he will not only not get any work done,
but create a lot of work and headaches for others to fix.
Great programmers spend very little of their time writing code – at least code that ends up in the final product.
Programmers who spend much of their time writing code are too lazy, too ignorant, or too arrogant to find existing solutions
to old problems. Great programmers are masters at recognizing and reusing common patterns.
Good programmers are not afraid to refactor (rewrite) their code constantly to reach the ideal design.
Bad programmers write code which lacks conceptual integrity, non-redundancy, hierarchy, and patterns,
and so is very difficult to refactor. It’s easier to throw away bad code and start over than to change it.
Software obeys the laws of entropy, like everything else.
Continuous change leads to software rot, which erodes the conceptual integrity of the original design.
Software rot is unavoidable, but programmers who fail to take conceptual integrity into consideration create
software that rots so so fast that it becomes worthless before it is even completed.
Entropic failure of conceptual integrity is probably the most common reason for software project failure.
(The second most common reason is delivering something other than what the customer wanted.)
Software rot slows down progress exponentially, so many projects face exploding
timelines and budgets before they are killed.
A 2004 study found that most software projects (51%) will fail in a critical aspect,
and 15% will fail totally. This is an improvement since 1994, when 31% failed.
Although most software is made by teams, it is not a democratic activity.
Usually, just one person is responsible for the design, and the rest of the team fills in the details.
Programming is hard work. It’s an intense mental activity. Good programmers think about their work 24/7.
They write their most important code in the shower and in their dreams.
Because the most important work is done away from a keyboard, software projects cannot be accelerated by
spending more time in the office or adding more people to a project.​

 

[c881]

@Syxok
א. אם אתה מחפש להחליף מקום - בשבוע האחרון קיבלתי טלפונים מ-4 חברות כח אדם שונות לגבי קורות חיים של חברים, כי אני מוותר על חיפוש עבודה כרגע.
אאל"ט למנורה.
ב. אם אתה רוצה בארה"ב - חברת ניהול הפנסיה של חברת הרכבות מחפשת מתכנתים לשימור/תיקון/הרמת המערכת של 7 מליון שורות קוד ב-COBOL -
https://www.linkedin.com/e/v2?e=197...3509148161974273&itemType=member&anetID=70143

רק אם משעמם לך...

 

[whybe]

מוסיף את השנקל שלי לדיון:
מזכיר כאן את treehouse, אחלה בי"ס ללימוד תכנות וכל מיני טכנולוגיות.

התחלתי ללמוד אצלם, צעדים ראשונים בווב. מגיע מתחום אחר לגמרי, אבל קשור.

 

[Delta]

אגב, מה דעתכם על Lynda?

 

[הדיוט בכלכלה]

בסופו של דבר זאת עבודה עם מטרה והדברים האלה פוגעים בפרודוקטיביות

אנשים שיודעים לתכנת ב-vim טוענים שהם דווקא הרבה יותר יעילים ומהירים. אז זה לא פוגע בפרודוקטיביות אלא דווקא משפר אותה.

 

[עומר]

חייב להמליץ על אתר תרגול לקראת ראיונות עבודה שהכרתי היום - הטוב ביותר שאני מכיר:
http://interviewbit.com/invite/bggjb

משתמש בקונספט של gamification כדי לייצר מוטיבציה לתרגל. ממשק מעולה. חבל שהאתר לא היה קיים כשלמדתי לראיונות בעצמי...

 

[MSS]

אגב, מה דעתכם על Lynda?

אנחנו עושים בזה שימוש נרחב ומאוד מרוצים. (לא רק בנושאים של תיכנות אלא גם עיצוב גרפי והעשרה כללית)