|
I bet Jon Skeet can have additional arguments after a params arg.
|
|
|
|
|
The VBA interface doesn't allow it.
|
|
|
|
|
Because if you could you wouldn't have homework to do.
|
|
|
|
|
Not sure how C# implement that, but I'm guessing it has to do with how the arguments are push onto a stack before a function address is invoked. Being that the stack doesn't have anything to manage what type each parameter are and the Parameter type can be any number of arguments, making it difficult to separate the actual arguments from the Parameter ones.
|
|
|
|
|
Examples of duck-typed, script languages:
Javascript  (what, me biased?)
Ruby
Python
Examples of statically typed compiled languages:
C
C++
C#
Go
This isn't a question of which you think is better (I know, the answer is "it depends") but feel free to answer that question, and why (particularly what it depends on).
My question is, if you were asked "how should I start learning programming?" would you a recommend duck-typed script languages or statically typed compiled language? Does it depend on what age the person is (for example, your kid, vs. a coworker interested in programming)?
Which would you prefer to teach to someone new to programming?
Why am I asking this? Because several sources of Python that I've encountered consider it a good learning language, and I'm curious what the experts here think!
Bonus (virtual) points for whether you'd pick an imperative programming language or a functional programming language!
Marc
|
|
|
|
|
Do I have to pick one of those?
I'd start with assembly. It's structurally simple and easy to learn incrementally. "Literally a list of instructions" is the simplest model to get used to.
|
|
|
|
|
harold aptroot wrote: Do I have to pick one of those?
Nope. 
harold aptroot wrote: I'd start with assembly. It's structurally simple and easy to learn incrementally. "Literally a list of instructions" is the simplest model to get used to.
That's a really good point -- I've always thought that a person learning programming should begin with what the processor is doing.
Marc
|
|
|
|
|
Marc Clifton wrote: That's a really good point -- I've always thought that a person learning programming should begin with what the processor is doing.
Than one can also argue that before learning what the processor is doing, they should learn about how it works and digit circuit design (AND gates, OR gates, Multivibrators, FlipFlops, FIFO, LIFO, etc...).
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Marc Clifton wrote: I've always thought that a person learning programming should begin with what the processor is doing.
I think that makes C a nice learning language. It is based on a fairly low-level processor abstraction.
Of course, it is like teaching your child how to cut their food using a chainsaw...
Software Zen: delete this;
|
|
|
|
|
Dude, I can't tell if you're serious. Because if you are, I'd say, "YIKES!" (and more below).
If you're not, then I'd be happy to pile on with more helpful suggestions, like "Forget Assembly. If you really want to dip your toes in the water you should start out with machine language -- go straight to the binary, so you can really understand the way the computer thinks!"
...And if I really have to explain my "YIKES" comment...
Assembly is a marginally useful language to explore for advanced coders. It is absolutely NOT what beginners should be introduced to. That's like giving entry-level math students a calculus book.
Seriously. Yikes. Please never teach an intro course.
|
|
|
|
|
I actually am serious. I don't disagree about the low relative usefulness. Of course assembly is not a convenient or easy-to-use language.
But none of that matters. At its core, assembly is simple. Literally a list of instructions, that is something everyone immediately understands. The syntax is trivial too. What people have trouble with is decomposing problems into the right parts, which is a bit harder in assembly. But you can jump right in. Other languages suffer the problem that in order to do anything (or even read anything), a lot of pointless syntax and other magic incantations have to be learned.
kdmote wrote: Seriously. Yikes. Please never teach an intro course.
Too late. I'm a teaching assistant for a computer architecture course. First year course, straight to assembly (architecture too, of course). They also learn Java in parallel, where they get confused about declarations and types, many stay confused until they take a course in compiler construction. Almost no one is fundamentally confused about assembly, they just find it hard to use.
|
|
|
|
|
kdmote wrote:
That's like giving entry-level math students a calculus book.
I would strongly disagree. It is much more like teaching them the basics of arithmetic by hand before letting them use a calculator.
|
|
|
|
|
Don't agree... There is a reason people don't use GOTO in c anymore... Assembly is a whole bunch on GOTOs with some non-portable code.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >></div>
|
|
|
|
|
Yes, but that reason was that it doesn't scale to large programs and is in general hard to use, not that it's hard to learn or to at least understand the fundamentals. The point of a first language is not writing large programs in it so that aspect doesn't matter.
|
|
|
|
|
If someone were learning to program I would recommend they start with Scratch - that way they get to understand the mechanics of programming (loops, variables, conditional branching) before they get bogged down in syntax.
|
|
|
|
|
Duncan Edwards Jones wrote: with Scratch
I actually wish programming was just like that!
Marc
|
|
|
|
|
|
I'd go with C.
It helps a lot understanding the basic flow of instructions, it enforces the need to think to the solution before writing as many typed languages do. It's clean and logical and helps keeping the clutter to the bare minimum until it is understood what inclusion of headers do - and the meaning of definition, declaration and modularity.
It allows to learn programming by steps, seeking new instruments when needed instead of providing with a messy garage of instruments with varying degrees of necessary skills to be used properly - the contrary of Java and VB6 (my first programming language excluding a brief and failed encounter with GW-BASIC) for example.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
"When you have eliminated the JavaScript, whatever remains must be an empty page." -- Mike Hankey
If a coffee bean is between the Earth and the Sun, is it a Java Eclipse? -- Sascha Lefèvre
/xml>
|
|
|
|
|
Marc Clifton wrote: Which would you prefer to teach to someone new to programming?
To teach someone programming then a strongly-typed OO language. That will teach concepts that can be translated to any language, and even adapted or "down played" for languages like javascript etc where there is a knack to keeping in mind that something might not have a fixed type. I think it's easier to go from typed to non-typed than the other way.
If you learned using javascript you're going to start something like c# and make everything "var" and wonder why nothing works (although people do that anyway), or try and implement a bad design you've learned from non-typed languages and end up with some horrible implementation to circumvent the languages strongly-typed nature. For example how many times have you seen questions in QA where people using c# ask things like
"I'm creating a dynamic form and I might have as many as twenty textboxes and if I do I want my class to have properties Textbox1, Textbox2, then I want to loop around those properties like this
for (int i = 1; i < 21; i++)
{
string text = obj.Textbox + i;
}"
They end up approaching problems from completely the wrong angle.
|
|
|
|
|
I agree. Strong typing, although initially confusing when first encountered makes for a clearer understanding of things in the long term. It's also easier to temporarily unlearn it for scripting languages, than to go the otherway around.
|
|
|
|
|
My kid has taken some classes in writing mods for Minecraft (Java).
MIT uses Python for its non-programming students.
One of the main reasons I bought a MicroVAX is because VAX BASIC still has interactive mode.  Just how I was introduced to programming in 1983. ![Jig | [Dance]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/jig.gif)
Personally, I would avoid scripting languages and OOP-only languages.
|
|
|
|
|
I would go with Compiled languages. Possibly with native ones like C/C++.
The process of Compile / Build to obj. Make to EXE everything goes with an edible flow. You don't need to learn a new framework to understand these.
And ultimately, to explain how these Exe's get executed on a CPU, you can explain it fairly straight, without the circus of JVMs/ Run times etc.
Having said all these, The ducktypes? There's nothing much to explain, you could just say that the last part of the pervious model is getting done line by line. Basically an Interpreted ones vs Compiled ones.
If you just want to learn Programming language, I would go with Scripts/Interpreters. The whole developement set up is not required. All you need is a browser and a notepad to start with.
But if you want to teach the whole of it, then we should not for the duck-type ones as you call it. Compiled ones do best there.
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
|
|
|
|
|
For a kid, the new Micro:bit initiative looks very interesting: BBC micro:bit : Create code[^]
The MS block editor makes syntax errors a thing of the past, and lest them concentrate on the essentials of development without worrying about the specifics. When they have got them down well, they will (hopefully) want to move to a more complex language which lets them control the code better (and the structure of the block editor would make a transition to C# fairly painless).
Block editor[^]
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
i'd go with the simplest dynamically-typed scripting language i could find. introducing the language plus a compiler & linker is just too much at once.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
