Whats the difference bewteen scripting and programming?

[Doppel]

It only matters if it's on the cloud!

 

[IronWing]

I award one cookie to the OP. He is batting 100% on his troll threads.

 

[Ichinisan]

<-- Programming

 

[Cerb]

Yeah, because programmers don't use compilers to interpret (and compile) their code.

Indeed, they don't. Interpreters execute code. We may use interpreters to compile, but not compilers to interpret.

What you are referring to as interpretation, which would be correct outside of a programming context, is called parsing.

 

[Zeze]

Don't get mad that we actually have more influence and authority than you do

A couple leads and I were actually feeling sorry for a PM one day when one of our senior devs graphed each of our roles in terms of authority and accountability. If x=Accountability and Y=Authority, Project Managers are at (inf, 0).

Why would I get mad? We had an IT guy that just couldn't relate to real-world results and plain-speak.

The VP and I gave him and his team what we wanted, the specs, and the results. He came back looking very sorry and gave us something TOTALLY different.

We said, look does this perform the specs we provided? He threw in all the tech jargon, but it was obvious he just couldn't do it/didn't get it. He apologized and came back 3 weeks late with what we wanted in the first place, wtf? Some IT people just lack basic people skills and interdepartmental communication.

Based on that reply, you sound just like it. Don't you have other monitor-staring tasks we gave you to finish? What influence and authority? Most jobs I've been to, IT reports to same VP. You're just a tool.

All the jabs aside, it's stupid to argue which function is better in a corp. That's like saying heart and brain arguing who's important for survival.

 

[Stuxnet]

You're just a tool.

lol... defensive much? Have you already forgotten this:

Don't get mad because we use you and tell you what to do.

I interpreted that as tongue-in-cheek, and chimed in with the same. Looks like I hit a sore spot I don't take it personally though, so don't worry - most PM's get pretty pissy when you mention that they exist in the worst of both worlds. Your neck is on the line and there's virtually nothing you can do to protect it. No need to get so uppity about it - it's just the nature of your job and the relationship you have with the people who actually make the company money. If you don't like it, learn a skill.

Don't you have other monitor-staring tasks we gave you to finish?

Maybe in your fantasy land. In the real world, PM's are told (by me) what needs to get done, the order in which it must be done, how long it will take (at which point we argue, because you're measured on that piece and your metrics were decided without yours or my input, so you're pretty well fucked at that point), and who will be doing it based on my team's availability.

What influence and authority?

See above Also:

Can you influence the composition of the team? No.
Does anyone report to you? No.
Can you do anything other than whine when a project falls behind? No.

I'm sure there are companies out there who are exceptions to these statements, but they're few and far between, and the extent of those exceptions are minimal. As an Architect, on the other hand, I can answer yes to each of those questions. If a developer isn't cutting it, I can swap them out or flat-out let them go, depending on the severity of the problem. They also answer to me and I conduct their performance reviews. Unless you're working at a very unconventional shop, you're not doing my performance review... OUR Vice President is. I report directly to him; unless you're at a small shop, you report to someone who reports to someone who reports to him. If a project is falling behind due to legitimate staffing problems (and not just some PM's wishful deadline management - gotta stay GREEN!!!), I can hire additional resources as needed. If you want to do that, you have to ask someone who has the authority to do so (hint: it's me :biggrin: ).

As an SME with a broad range of responsibility (and not just an Excel / Project monkey), people actually listen to what I have to say. PMs, who generally can't get their heads off the paper, are glorified secretaries. They facilitate communication (read: bog skilled workers down with excessive/redundant meetings) and report project status. If a project goes down in flames, the PM's head gets rolled out the door and down the driveway. I just move on to the next project... where yet another PM is hanging on my every word.

All the jabs aside

LOL

Nice try

*** ALL JABS ASIDE ***

 

[yllus]

Not much really. With the boundless amount of CPU, memory and network capacity available to developers nowadays, it's wholly acceptable to work with a high level language that takes care of the details and lets you focus on getting the business logic for your program just right. In fact, "minimum viable product" has become a buzzword lately and relies on rapid development platforms like Ruby on Rails to work.

I figure pretty much the only people who have real bragging rights and can call themselves the elite are iPhone jailbreakers, who not only work at the assembler level but have to worm their way past intentional obfuscation by Apple and a complete lack of documentation to do their thing. The rest of us who mostly just make sure we allocate the correct amount of memory and close our file handlers are pretenders to the throne.

 

[Zeze]

lol... defensive much? Have you already forgotten this:



I interpreted that as tongue-in-cheek, and chimed in with the same. Looks like I hit a sore spot I don't take it personally though, so don't worry - most PM's get pretty pissy when you mention that they exist in the worst of both worlds. Your neck is on the line and there's virtually nothing you can do to protect it. No need to get so uppity about it - it's just the nature of your job and the relationship you have with the people who actually make the company money. If you don't like it, learn a skill.



Maybe in your fantasy land. In the real world, PM's are told (by me) what needs to get done, the order in which it must be done, how long it will take (at which point we argue, because you're measured on that piece and your metrics were decided without yours or my input, so you're pretty well fucked at that point), and who will be doing it based on my team's availability.



See above Also:

Can you influence the composition of the team? No.
Does anyone report to you? No.
Can you do anything other than whine when a project falls behind? No.

I'm sure there are companies out there who are exceptions to these statements, but they're few and far between, and the extent of those exceptions are minimal. As an Architect, on the other hand, I can answer yes to each of those questions. If a developer isn't cutting it, I can swap them out or flat-out let them go, depending on the severity of the problem. They also answer to me and I conduct their performance reviews. Unless you're working at a very unconventional shop, you're not doing my performance review... OUR Vice President is. I report directly to him; unless you're at a small shop, you report to someone who reports to someone who reports to him. If a project is falling behind due to legitimate staffing problems (and not just some PM's wishful deadline management - gotta stay GREEN!!!), I can hire additional resources as needed. If you want to do that, you have to ask someone who has the authority to do so (hint: it's me :biggrin: ).

As an SME with a broad range of responsibility (and not just an Excel / Project monkey), people actually listen to what I have to say. PMs, who generally can't get their heads off the paper, are glorified secretaries. They facilitate communication (read: bog skilled workers down with excessive/redundant meetings) and report project status. If a project goes down in flames, the PM's head gets rolled out the door and down the driveway. I just move on to the next project... where yet another PM is hanging on my every word.



LOL

Nice try

The hell? Someone needs validation. I even said 'all jabs aside'. Go outside more, IT kid. So typical.

 

[Stuxnet]

The hell? Someone needs validation. I even said 'all jabs aside'. Go outside more, IT kid. So typical.

I fixed my post for you :biggrin: Now don't you have a spreadsheet to play with? What are you doing in a programming thread? This is where those of us with tangible skills talk... all jabs aside, of course.

And 2000 called, it wants its "herp derp get outside more" back.

 

[exdeath]

lda #$00
pha
pld
lda #$07
sta $2105

^ this is programming.

 

[janas19]

I fixed my post for you :biggrin: Now don't you have a spreadsheet to play with? What are you doing in a programming thread? This is where those of us with tangible skills talk... all jabs aside, of course.

And 2000 called, it wants its "herp derp get outside more" back.

You're a major troll and an a-hole to boot. Good thing your SN is named an illegitimate virus - it fits you well.

 

[Zeze]

I fixed my post for you :biggrin: Now don't you have a spreadsheet to play with? What are you doing in a programming thread? This is where those of us with tangible skills talk... all jabs aside, of course.

And 2000 called, it wants its "herp derp get outside more" back.

Wow, my very first internet argument. Thanks, by none other than an IT kid (unsurprisingly) who puts shame to rest of real IT managers who manage and respect all resources like a man.

Thank god my company has an excellent IT director (20 yr exp) whom I work closely with so I don't have to deal with bunch of script kiddies asking dumbass questions only to be corrected by me what was there all along.

Thanks for the laugh, someone is frustrated and I'll gladly take it for you- as a real man. You win!

 

[dainthomas]

Girls don't care what the difference is between scripting and programming. That's what matters.

 

[LiuKangBakinPie]

Indeed, they don't. Interpreters execute code. We may use interpreters to compile, but not compilers to interpret.

What you are referring to as interpretation, which would be correct outside of a programming context, is called parsing.

So they they translate the source code to machine code themselves for all platforms?

 

[vi edit]

All programmers can(or should be able to) script. But not all scripters can program.

<------can barely even script his way out of a wet paper bag.

 

[Gibson486]

Scripting is very high level. You essentially direct things to do stuff, but you do not really give the actual instructions to do it. Usually, when you run a script, it has to be interpreted and it directs the computer to run code that tells it to do something. That is why when Java came out, it was huge. It kind of blurred the boundaries. It was sort of an interpreted language, but it was strong enough to stand on its own, which is why it's a programming language and not a scripting language.

Programming, you are actually telling the computer the instructions. The reason why C/C++ or whatever other programming language you want made it big was because those programs now handled the conversion to assembly code. So, in essence, programming is the actual instructions to the CPU.

The only time you do assembly is when you need to do embedded stuff. Even then, they now have it done in C because it is more efficient that way and it's easier to debug and understand. The only time we do stuff in assembly is if we really need to do some optimization (we can do some multiplication bit wise instead of requiring two registers).

Today, the line between the two is sort of blurred because there is overlap. Someone kind of eluded to it....that there are people who call themselves "programmers" when they really do not know much at all. I have met people who made a living off of just knowing Python and Java for Android. Pretty scary... In the end, it pretty safe to call them all programming languages. It's just that some of them have libraries that others do not have and that is what makes life easier and that is how you decide which language to use and which to wrap them with. I mean, for me, if Python did not have Numby or Scipy, I would have not even bothered with it.

 

[LiuKangBakinPie]

Compiler
Interpreter
Assembler

All types of translation program all used by programmers unless they work directly with machine code.

Assembler you will use when your working directly with machine code where one source code line usually translates directly into one machine code instruction.

 

[Stuxnet]

Wow, my very first internet argument. Thanks, by none other than an IT kid (unsurprisingly) who puts shame to rest of real IT managers who manage and respect all resources like a man.

I'm normally not such an acidic bastard, but you lashed out - what did you expect in return? We all have our adversarial relationships in the work place, but if you don't have to keep your feelings bottled up and politically correct here, why do I? I can assure you that the contempt you hold for those who actually bring in the bacon is a two-way street. That was my point.

Thanks for the laugh, someone is frustrated and I'll gladly take it for you- as a real man. You win!

Yes, PM's annoy me... and every single other productive worker out there, from software to manufacturing. You're not the hammer, the nail, or the carpenter... you're the whiny tenant who knows just enough about the process to be dangerous. I'm sure you think you're the Building Supervisor, but that would actually be me, sorry. I choose the contractors, the materials, and design the product from a high level. My only accountability to you is to tell you what my team's timeline is. It's not my fault that a much shorter, more unreasonable timeline was thrust upon you by your superiors, and that you'll be measured against that one, not the real one. And no, holding another meeting won't fix that.

Now, some PM's are actually former software developers - they usually make OUTSTANDING collaborators because they're not tepid little yes-men: they actually understand what's happening under the hood and they're not afraid to bring the truth and reality front and center at the earliest stages of the project so the customer can be told now - as opposed to a day after the delivery date - that the timelines are borked.

 

[Gibson486]

I'm normally not such an acidic bastard, but you lashed out - what did you expect in return? We all have our adversarial relationships in the work place, but if you don't have to keep your feelings bottled up and politically correct here, why do I? I can assure you that the contempt you hold for those who actually bring in the bacon is a two-way street. That was my point.



Yes, PM's annoy me... and every single other productive worker out there, from software to manufacturing. You're not the hammer, the nail, or the carpenter... you're the whiny tenant who knows just enough about the process to be dangerous. I'm sure you think you're the Building Supervisor, but that would actually be me, sorry. I choose the contractors, the materials, and design the product from a high level. My only accountability to you is to tell you what my team's timeline is. It's not my fault that a much shorter, more unreasonable timeline was thrust upon you by your superiors, and that you'll be measured against that one, not the real one. And no, holding another meeting won't fix that.

Now, some PM's are actually former software developers - they usually make OUTSTANDING collaborators because they're not tepid little yes-men: they actually understand what's happening under the hood and they're not afraid to bring the truth and reality front and center at the earliest stages of the project so the customer can be told now - as opposed to a day after the delivery date - that the timelines are borked.

Wow....you hit the nail on the head.

 

[Modelworks]

If you really want to understand programming and what is going on I think every pc programmer should do some embedded programming and I don't mean using something like an arduino where you write code and run it with libraries already waiting for you.

Instead download the emulator http://www.edsim51.com/
The 8051 is one of the oldest micros that is still in use. It was used repeatedly in the space shuttles flight computers and still remains a popular chip. At the chips heart is a very well thought out design and it really lets you see what is going on inside. Start with example 1 on the site .

start:
DEC P1 ; decrement port 1
JMP start ; and repeat

 

[LiuKangBakinPie]

If you really want to understand programming and what is going on I think every pc programmer should do some embedded programming and I don't mean using something like an arduino where you write code and run it with libraries already waiting for you.

Instead download the emulator http://www.edsim51.com/
The 8051 is one of the oldest micros that is still in use. It was used repeatedly in the space shuttles flight computers and still remains a popular chip. At the chips heart is a very well thought out design and it really lets you see what is going on inside. Start with example 1 on the site .

Pearl as well. It covers both sides

 

[janas19]

I'm normally not such an acidic bastard, but you lashed out - what did you expect in return? We all have our adversarial relationships in the work place, but if you don't have to keep your feelings bottled up and politically correct here, why do I? I can assure you that the contempt you hold for those who actually bring in the bacon is a two-way street. That was my point.



Yes, PM's annoy me... and every single other productive worker out there, from software to manufacturing. You're not the hammer, the nail, or the carpenter... you're the whiny tenant who knows just enough about the process to be dangerous. I'm sure you think you're the Building Supervisor, but that would actually be me, sorry. I choose the contractors, the materials, and design the product from a high level. My only accountability to you is to tell you what my team's timeline is. It's not my fault that a much shorter, more unreasonable timeline was thrust upon you by your superiors, and that you'll be measured against that one, not the real one. And no, holding another meeting won't fix that.

Now, some PM's are actually former software developers - they usually make OUTSTANDING collaborators because they're not tepid little yes-men: they actually understand what's happening under the hood and they're not afraid to bring the truth and reality front and center at the earliest stages of the project so the customer can be told now - as opposed to a day after the delivery date - that the timelines are borked.

Thank you for explaining that- I thought you were just being a major troll but that makes sense

 

[Markbnj]

If you're formulating instructions to tell a computer to perform a task, and assembling those instructions into a logical order that accomplishes some overall goal, then you're programming. Any other distinctions are highly subjective and usually driven by either a desire to elevate the status of one job over another, or spawn long threads on forums.

 

[Stuxnet]

Thank you for explaining that- I thought you were just being a major troll but that makes sense

Despite my less than cordial words for Zeze, I do have sympathy for the position most Project Managers are in. It's oftentimes an unwinnable situation: they are frequently told what the deadline is when the project first rolls in (usually because a customer said "we'll buy it if it's done on X date"... and some hapless salesperson was willing to agree to any terms that resulted in a commission).

Then an architect or solutions analyst is asked to perform an assessment (decide the what, how, who, and how long - some PM's like to think they have a role in this, but they don't - they lack the training and experience and are really just along for the ride for this phase). Unfortunately, this is what should have happened first. Anyway, once finished, the architect's timeline is given to the Project Manager. The problem is that a commitment to the customer has already been made at this point and the actual timeline is longer than the one dictated to the PM. This is one example of why the PM has no authority: he has two different parties - his superiors and the technical staff - telling him what the schedule is, and he's pretty much powerless to reconcile the conflict. It's not uncommon for a PM to be told "if you can get it done by X date, we'll find someone who will." This is why they panic and why PM turnover is sky high in many places. The date and the status is their entire world. If they flounder in these two areas, they'll be fired without so much as a blink.

This is a major contributing factor to the adversarial relationship between PM's and the people who work with them... because for the rest of the project, the PM is in panic mode and is constantly trying to get everyone up to a pace that satisfies the dictated deadline, not the one from the assessment. Making matters worse, the only tool at the PM's disposal is The Meeting. As the old saying goes, when all you have is a hammer, everything looks like a nail.

Of course, all these meetings really do is draw everyone away from creating product, which in turn just frustrates the technical staff and pulls things behind schedule even more. Contrary to what many PM's have been led to believe, leads from various groups are perfectly capable of determining critical deliverables/paths and working together to minimize lag. Throw an Architect or Solutions Analyst into the mix (someone who understands each of those groups' systems and the interplay among them), and you really wonder why a PM is attached to the project at all.

In a perfect world, a PM's primary job is to remove obstacles and make sure everyone has the information needed to do their jobs. While crude, that's where the 'glorified secretary' comment came from. Ideally, they're there to keep extraneous noise from distracting anyone attached to the project. That noise can be in the form of salespeople, the customer, impatient executives, etc. What a PM isn't, ironically, is a manager. They aren't empowered to affect change in any shape or form. They can't alter staffing, budgets, or timelines. Changes in any of those categories require someone else. All the PM can do is ask. The only real tool they have that gets them close is they can go banging on people's boss' doors when they have no choice but flip a project status from green to yellow or red. They'll avoid this at all costs, however, because at the end of the year, they're measured by how many of their projects stayed green through their duration. Yes, this is unfair as hell to them, but it's necessary to understand this if you are to understand the Project Manager.

 

[janas19]

Despite my less than cordial words for Zeze, I do have sympathy for the position most Project Managers are in. It's oftentimes an unwinnable situation: they are frequently told what the deadline is when the project first rolls in (usually because a customer said "we'll buy it if it's done on X date"... and some hapless salesperson was willing to agree to any terms that resulted in a commission).

Then an architect or solutions analyst is asked to perform an assessment (decide the what, how, who, and how long - some PM's like to think they have a role in this, but they don't - they lack the training and experience and are really just along for the ride for this phase). Unfortunately, this is what should have happened first. Anyway, once finished, the architect's timeline is given to the Project Manager. The problem is that a commitment to the customer has already been made at this point and the actual timeline is longer than the one dictated to the PM. This is one example of why the PM has no authority: he has two different parties - his superiors and the technical staff - telling him what the schedule is, and he's pretty much powerless to reconcile the conflict. It's not uncommon for a PM to be told "if you can get it done by X date, we'll find someone who will." This is why they panic and why PM turnover is sky high in many places. The date and the status is their entire world. If they flounder in these two areas, they'll be fired without so much as a blink.

This is a major contributing factor to the adversarial relationship between PM's and the people who work with them... because for the rest of the project, the PM is in panic mode and is constantly trying to get everyone up to a pace that satisfies the dictated deadline, not the one from the assessment. Making matters worse, the only tool at the PM's disposal is The Meeting. As the old saying goes, when all you have is a hammer, everything looks like a nail.

Of course, all these meetings really do is draw everyone away from creating product, which in turn just frustrates the technical staff and pulls things behind schedule even more. Contrary to what many PM's have been led to believe, leads from various groups are perfectly capable of determining critical deliverables/paths and working together to minimize lag. Throw an Architect or Solutions Analyst into the mix (someone who understands each of those groups' systems and the interplay among them), and you really wonder why a PM is attached to the project at all.

In a perfect world, a PM's primary job is to remove obstacles and make sure everyone has the information needed to do their jobs. While crude, that's where the 'glorified secretary' comment came from. Ideally, they're there to keep extraneous noise from distracting anyone attached to the project. That noise can be in the form of salespeople, the customer, impatient executives, etc. What a PM isn't, ironically, is a manager. They aren't empowered to affect change in any shape or form. The only real tool they have that gets them close is they can go banging on people's boss' doors when they have no choice but flip a project status from green to yellow or red. They'll avoid this at all costs, however, because at the end of the year, they're measured by how many of their projects stayed green through their duration. Yes, this is unfair as hell to them, but it's necessary to understand this if you are to understand the Project Manager.

I didn't understand any of that, but :thumbup: