Tales of coding from a beginner • Hacker News Board

Re: Tales of coding from a beginner

#71

Post by tikhonj » Sun, Oct 04, 2015, 6:49 PM UTC

chestnut-tree wrote: post #51

"3. Equals is a lie: = ≠ =" This is why languages like Pascal (and it's descendents) use := as assignment. There are contradictory opinions about sytnax among programmers. Many programmers don't like the example assignment syntax above, but then many programmers also say that syntax is a relatively minor aspect of learning a language (even though the syntax of a language shapes the way you think about solving problem…

As contradictory as it sounds, syntax is both important and unimportant at the same time.

It's important because it affects how code is read and how code is written. Programmers naturally lean towards constructs with light syntax and away from constructs with heavy syntax: just think about defining maps in Python or JavaScript (with nice literals) vs in Java, or think about higher-order functions in Haskell (with currying and tiny lambdas) vs JavaScript vs Java. And, as the article pointed out, the syntax can affect how somebody learns a programming language.

On the other hand, syntax is unimportant because we learn to see beyond syntax, to the concepts underneath. Syntax is ultimately just notation and notation is not the most important thing. Semantics are important! There are much deeper differences between languages than mere syntax. At this point, I don't even think of code in terms of concrete syntax most of the time, although this might be exacerbated by my background studying programming language design and theory.

Personally, I think different people tend to overemphasize one side of this or the other, with more people over valuing syntax than not. In my perfect world the solution to confusing syntax would be to teach people to disassociate syntax and semantics early on, but that's a tall order. Perhaps people could read Godel Esher Bach, which engenders the right mindset :).

Re: Tales of coding from a beginner

#72

Post by jimkri » Sun, Oct 04, 2015, 6:58 PM UTC

#2 The Fear. This is what I have struggled the most with. During all of my programming classes I worried that I was not cut out for it, because I am business student minoring in comp sci in the world of students who live for programming. But after a while I really learned that everyone in class always struggled with the same problems that I had, everyone was just to proud in a way to ask each other for help. Eventually everyone broke down and that was when the most fun happened in class, and with the programming. It was really cool struggling with other programmers.

By the end of all my programming classes my fear was not that bad, but I still fear doing any hack-a-thons or anything like that, because I shoot myself down.

I am working on getting over that fear, but its good to know I am not the only one.

Re: Tales of coding from a beginner

#73

Post by YeGoblynQueenne » Sun, Oct 04, 2015, 7:21 PM UTC

chestnut-tree wrote: post #51

"3. Equals is a lie: = ≠ =" This is why languages like Pascal (and it's descendents) use := as assignment. There are contradictory opinions about sytnax among programmers. Many programmers don't like the example assignment syntax above, but then many programmers also say that syntax is a relatively minor aspect of learning a language (even though the syntax of a language shapes the way you think about solving problem…

The funny thing is that there is a mathematical symbol for assignment, the left-arrow, "<-". At least it's used widely in algorithmic notation to show assignment- and also in R.

Re: Tales of coding from a beginner

#74

Post by GFK_of_xmaspast » Sun, Oct 04, 2015, 7:35 PM UTC

bottled_poe wrote: post #47

V-2 wrote: post #45

Earlier quoted context omitted.

Well, good chefs do, it's called author's cuisine I believe. Someone, somewhere, has to come up with some recipes - and hold on there, I know it sounds like crazy talking, but why wouldn't these people be chefs, who already cook for a living?

My point was that chefs do create recipes, but not while cooking the food.

Haven't you ever done improv-cooking?

Re: Tales of coding from a beginner

#75

Post by noonespecial » Sun, Oct 04, 2015, 8:11 PM UTC

chestnut-tree wrote: post #51

"3. Equals is a lie: = ≠ =" This is why languages like Pascal (and it's descendents) use := as assignment. There are contradictory opinions about sytnax among programmers. Many programmers don't like the example assignment syntax above, but then many programmers also say that syntax is a relatively minor aspect of learning a language (even though the syntax of a language shapes the way you think about solving problem…

I had a wise teacher early on who without fail used "becomes the same as", "is assigned to", and "points at" when reading code out loud. "Is equal to / equals" was only for comparisons.

This has helped me to this day.

Re: Tales of coding from a beginner

#76

Post by Jimmy » Sun, Oct 04, 2015, 8:17 PM UTC

morokhovets wrote: post #35

gaius wrote: post #13

9. Learn to call it programming, not "coding". It's like a professional chef referring to what they do as "chopping".

For me, "software engineering" is even better term.

I'm not a fan of that term. It sounds so stiff and formal. When people ask what I do, I make it a point to always say "programmer" rather than "developer" or "software engineer".

Re: Tales of coding from a beginner

#77

Post by QuercusMax » Sun, Oct 04, 2015, 8:18 PM UTC

gaius wrote: post #13

9. Learn to call it programming, not "coding". It's like a professional chef referring to what they do as "chopping".

For me, coding is the act of physically working in my editor. Software development is the whole thing - coding, writing docs, troubleshooting, support, etc.

Re: Tales of coding from a beginner

#78

Post by mojoe » Sun, Oct 04, 2015, 8:41 PM UTC

YeGoblynQueenne wrote: post #73

chestnut-tree wrote: post #51

"3. Equals is a lie: = ≠ =" This is why languages like Pascal (and it's descendents) use := as assignment. There are contradictory opinions about sytnax among programmers. Many programmers don't like the example assignment syntax above, but then many programmers also say that syntax is a relatively minor aspect of learning a language (even though the syntax of a language shapes the way you think about solving problem…

The funny thing is that there is a mathematical symbol for assignment, the left-arrow, "<-". At least it's used widely in algorithmic notation to show assignment- and also in R.

I program a decent amount in R, and this left-arrow assignment operator is incredibly annoying. I believe it's a holdout from the days when there was a single key that would input '<-'.

Re: Tales of coding from a beginner

#79

Post by wyclif » Sun, Oct 04, 2015, 9:14 PM UTC

PuffinBlue wrote: post #16

Just what the doctor ordered! I'm just starting out[1] and recognise all of these points, especially number 4 even though on first glance it might seem the wrong attitude. Every time I run into something new I feel the need to 'fully' understand it before moving on. With such a vast corpus of information out there and a lifetimes worth of skill development in just one particular branch (database admin anyone?) I have…

This is good, but I don't get what "Odin" is in this context (e.g. not the Germanic deity).

Re: Tales of coding from a beginner

#80

Post by antod » Sun, Oct 04, 2015, 9:59 PM UTC

kawera wrote: post #65

morokhovets wrote: post #35

Earlier quoted context omitted.

For me, "software engineering" is even better term.

"Software engineering" certanly feels better but I think generally our work is closer to a craft than an engineering practice; imagine if we built bridges, tunnels and planes as we build software - catastrophes every day!

As someone who learnt to code as a kid, then studied and worked in civil/structural engineering, then ended up later on back in software, I do find comparisons (somehow always involving bridge analogies) between software engineering and 'traditional' engineering to always be off somehow.

Most traditional engineering projects are not magical bastions of rigor and certainty. It is really only in very large budget or critical projects that a lot of analysis or rigour comes into play to create that certainty.

At least in the civil/structural world you'd be surprised how much comes down to just gut feel by experienced engineers who then throw down some very quick calculations (budgets don't allow for much more than that) to back up their choices. Most numbers are looked up in tables. They then hopefully get run past another experienced engineers gut feel for validation then get signed off. And most of the time the public agency will just accept that uncritically - as they no longer have the resources to double check designs themselves.

The main difference with software as I see it, is that software is binary and the real world is analogue. Civil/structural engineering standards have factors of safety for materials and loading codes etc to cope with inconsistencies or minor mistakes/oversights or unforeseen circumstances etc. Even most failures are not catastrophic and can be detected and fixed before a catastrophic failure eg things can yield or crack rather than snap.

Software being binary though means for a certain set of circumstances it either works or it doesn't. You don't have the luxury of factors of safety and just overspeccing components to be sure.