Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've been wanting to get into a pure-OO language for a while now, but I'm put off by the fact that they all seem to demand an IDE and I can't find any good tutorials that aren't in video format.
I'm happy to use an IDE later, but I don't want to learn the language through one. What I'm looking for is a simple console interpreter or command-line compiler such as gcc, ghc, ghci and the python IDLE (yes, it's an IDE, but it's so minimalist that it may as well just be a commandline interpretter). I find that I learn a language faster, better and more comprehensively when I'm not trying to grapple with an IDE at the same time. So please, don't tell me that squeak is the only way to do it :P
I'm also looking for tutorials that are presented textually rather than visually. Again, I learn faster when I can stare at a page and read someone's sentance over and over tossing and turning it in my mind rather than having to pause a video, take it back 10 seconds, press play, do it again, and again, and again.
I'm interested in various languages with various degrees of OO-purity, and I plan to learn them all at some point. Any of the smalltalk dialects interest me, Self (an extreme prototype-oriented version of smalltalk (Very interesting, the more radical the better imo)), strongtalk, vanilla smalltalk (or some implementation which is as vanilla as you can get).
I'm interested in Eiffel as well, the code snippets I've seen make it seem very elegant and I've read that it actually was very innovative (introduced code-contracts and other such things). However I would give preference to a language from the smalltalk camp over one from the Eiffel side because Eiffel at face value seems to be a hybrid between OO and imperative programming. Similarly I'd rather avoid Scala (Hybrid OO and functional) and other hybrid languages. So no C#, Java, C++, D, python etc etc etc. I'm not dismissing these languages because I believe they are bad, it's just that I'm setting out to learn pure-OO and those languages are hybrid OO: Not really what I'm looking for.
Also, would anyone be able to recommend the official books? For smalltalk there's the "Blue book" AKA "Smalltalk-80: The Language and its Implementation". And for Eiffel there's "Eiffel: The Language". I ask because in my experience you can pick up so much by reading books written by the author of the language (see K&R the C programming language), and by reading books in general.
So yes, my questions: What pure-OO language would be good to start off with? How would I go about learning it without having to use an IDE? And is there an associated book written by the language author(s)?
It is not helpful to learn Smalltalk as just another language. You would be missing the point entirely.
Smalltalk's graphical environment is not just an IDE. The core of the system is simply objects. The interface provides various ways to create objects and interact with them. The language is just a convenient way to create messages to the objects. It is secondary to the objects themselves.
In other OO languages, you write your program, then you run it, which creates objects in memory. Not so in Smalltalk. You create objects in memory (e.g. class objects) and then send messages to e.g. add methods. But a class object is only created once, not every time you "run your program".
There is no such thing as "your program", in fact. There is no "main". It's just a world of objects, some longer-lived, some temporary. In fact, in the system there are objects that were created 30 years ago. Literally. The objects are just frozen to disk as a memory dump (a file which we call "image") and unfrozen later (possibly on a different machine).
That image, the world of objects, is the primary artifact in Smalltalk. There is a sources file, yes, but that's just a database of text snippets to not take up so much RAM. You cannot edit this file by hand (objects in the image use absolute file offsets into the sources file). You cannot re-create the system from the sources file - the system was bootstrapped a long time ago and from then on only modified.
It's true that superficially the Smalltalk GUI looks just like another IDE. No coincidence - Eclipse was originally written by Smalltalkers in Smalltalk. But there is the crucial difference that in regular IDEs you just manipulate text files. A text editor is a valid alternative for that. In Smalltalk, the GUI manipulates objects in memory. A text editor can not do that.
And as for what Smalltalk to use, I would recommend Squeak. Very friendly community, very nice environment, and subscribing to the original Smalltalk vision of creating a great personal computing environment for everyone.
As someone who has went through process of learning Smalltalk (at least to a decent degree), I can say that you are taking harder and riskier path, in a sense that some things may take much longer to clear up, or never actually do.
But, if you insist, you can download GNU Smalltalk, for which no GUI is a norm. It also contains all sources of the system written in Smalltalk in a chunk format and you can open your text editor on them and enjoy while slowly reading through the guts of the system.
You could also startup any other Smalltalk, like Pharo, and just stick with a workspace window - this is your equivalent of command line interpreter.
Pharo also includes ProfStef quick interactive tutorial on Smalltalk, which combines text instructions and evaluating Smalltalk expressions.
As for reading, there is Pharo By Example - free book that you can browse, download or buy hardcopy.
There is also a collection of free books in which I would recommend "Smalltalk-80: The Language and its Implementation" By Adele Goldberg and David Robson, if you are interested in the innards and detail of the language.
Late David N. Smith Smalltalk FAQ is also exelent resource.
So, there you go. And take advice, and give in to the Smalltalk IDE as soon as possible, since it makes understanding of Smalltalk much, much, faster.
Richard Gabriel gave a talk recently about a paradigm shift that occurred in the programming language community in the early 90s. He claims that most experts today are incapable of understanding many of the papers from the 80s. He has evidence to back this up. This was the first time he gave the talk, and he expects to give it many times, so I imagine that many parts of the talk will change. At first, he described this paradigm shift as engineering -> science, but then he described it as system -> language. I think that describing it as a shift from systems thinking to language thinking is a better description.
Richard Gabriel is a Lisp guy. (I'm a Smalltalk guy). Lisp is like Smalltalk in that there isn't a clear boundary between the language and the library that it uses. Arithmetic and control flow are in the libraries, not the language. (Well, Lisp has some in the language and some in the libraries, while Smalltalk has it all in the libraries, except that the compiler cheats and hard codes some of them, so there isn't really much difference in the end.) In Lisp, a program is an S-expression, and editing programs is editing S-expressions. In Smalltalk, a program is a collection of objects, and editing programs is editing objects. When you are programming, you are building a system, and you program with the system.
System thinking is different from language thinking. Language thinkers want a precise description of a language. They want a book that describes the whole thing, or (if they are academics) they want a formal semantics for the language. But system thinkers know that as soon as they start to use the system, it will change. They want to understand how the system works, but are prepared to look at the system itself to figure out the details.
These are two ways of thinking, and there are advantages and disadvantages of each. Smalltalk is a wonderful example of systems thinking. I think all software developers should know at least one system that exemplifies systems thinking. Lisp is good. Forth is another old example. Naturally, I think that Smalltalk is great and am happy to help people learn it but I think the importance of learning systems thinking is more important than the particular system you learn.
Unfortunately, learning a system is harder than learning a language. You have to do more than just learn the syntax, you have to learn the libraries, the patterns of naming and of coding, and usually the tools. (Which, if this is a system, are extensible.) That is one of the advantages of language thinking. But systems thinking has long-term advantages, because once you taylor the system to your needs then you can become very productive.
To lean smalltalk syntax, you need to read ONE page of text (see Syntax section on wiki http://en.wikipedia.org/wiki/Smalltalk).
Now, to learn a smalltalk libraries and how to use them, you need to use browser not the text editor, otherwise your will just waste a lot of time.
I think that it is like factor of 10 difference in time, between trying to understand some code by reading in textual format and navigating it using browser and! debugger.
In smalltalk system a living objects could tell a lot about themselves and help you learn how to use them much faster than if you look at it as a static chunks of text, because you won't grasp the idea at all.
I've been playing with Squeak Smalltalk (and its close cousins, Pharo and Cuis) for a while now. There's no better way to learn Smalltalk than by using the system already provided.
I've devised a series of short youtube tutorials ranging in length from 50 seconds to 15 minutes that show how to take advantage of Squeak's ultra-cool features within a few minutes of first starting the system.
In fact, the very first line of code demos the OOP-ness of Squeak. Squeak from the very start
Python is a pure OOP . Actually this is an easy mistake that newcomers make when they come to python.
Python like smalltalk follows the mantra "Everything is an object". So everything inside python is an object, including built-in types. The difference is that python unlike smalltalk and Java does not force OOP as it allows procedural programming. And this is the trap, it easy to assume that makes python less OOP , but being a snake, is so devlish that does not tell you that even functions are objects ;)
http://www.linuxtopia.org/online_books/programming_books/python_programming/python_ch10s04.html
Going back to smalltalk its IDE is the huge deal here, contrary what other smalltalker may believe. If you like me are heavily disappointed with how non flexible IDEs are you are going to love Squeak's IDE. The IDE goes a great deal making easy to navigate through all the libraries and making you understand what , where and why , something happens. I cant see the benefit of using a text editor. But you can, with file ins and file outs. But doing so you cripple smalltalk into becoming as efficient as other programming languages ;)
I am only studying squeak and pharo for a week now but even for me as a beginner the benefits of the IDE is obvious from the first minute.
The fact that code is fragmented into easy to digest methods, those methods grouped into protocols , protocols grouped to our familiar Classes and Classes grouped to packages. Hence the code is so well organized that I never feel lost, everything belongs somewhere, everything is just a click away, everything is inspectable, browseable , you just select right click and sends you there. And it shows you exactly the code you need rarely more than 10 lines long. This is the IDE. Why would you prefer a text editor that will expose to information that you don't need , don't care and is likely to confuse you ?
Then everything is inside a single image , not a collection of files, your code, your libraries, system libraries , even the language itself. Everything is at your grasp, waiting for you, begging you to test, modify it, use it and abuse it. You are part of the language and the language is part of your, if something does not fit your thinking, change it. This is the IDE. Why you want to go back to the disconnected way of files and folders ?
Then you are start being afraid with all this power, all this flexibility its not unlikely that you will do something that could completely destroy the language and the libraries. Its possible , mistakes can and will happen. Again the IDE jumps in offering you a hand of help, every change is stored in a local cvs system, every change is categorized, stored and monitored any time. No lousy undos and any kind of other nonsense . What you get is old , mature well tested version control. You can change back exactly what you want any time, nothing is lost, no mistake is irreversible.
And if you don't trust you hard driver , the vcs extends online to squeaksource . And does it let you at the mercy of command line ? Hell no . You are offered the simple yet efficient Monticello browser , which will make sure you install and unistall with no conflicts .
And of course you don't want your software to have bugs , do you ? Unit Testing tool is offered to make sure your code is reliable , stable and does exactly what you want how you want it. Again a beautiful yet brilliant GUI is utilized to make complicate tasks a button away.
And because none is perfect , there will be time you will come against the dreadful error. Are you left alone ? You guessed right , a tool again is offered. The debugger. You don't need to call it, you don't need to setup it , you don't even need to figure out how it works. Like all other tools, is simple in design yet sophisticated. Not only it will spot the error , not only will tell you what you did wrong , not only will navigate through back to most basic language elements that trigger the error offering a unique perspective on how exactly the language behave like nothing I have seen before, it also allows you to do live coding. Live coding is the ability to code a program while its code runs. Isn't that impressive and infinitely useful ?
Finally , maybe you are one of those people impossible to please, maybe you still find flaws , omissions and thinks you simple don't like. The IDE is written in smalltalk , smalltalk is written in smalltalk , and the IDE can edit itself and the language, there is nothing you can't change besides some very basic functionality of the language and the VM that is compiled C. And you will guess right if you think you can use all the above tools to do exactly that.
And the tools don't stop here , smalltalk might be not that popular as other languages but it has been here for a very long time and it has some very enthusiastic programmers that love to contribute. And frankly with such an amazing IDE and such a well designed language , while with other languages contributing to them might seem a challenge, in case of smalltalk the challenge is to resist the temptation not to contribute as the IDE makes it so easy.
By the time others still code you will finish your code and actually understand what have you done and why. Thats not a small thing at all . I wish Python had such a good IDE or any other language. But the only thing that comes abit close, from my experience , is Delphi. And even in the case of Delphi I still prefer squeak and pharo.
What I find annoying about other IDEs is that they are not IDES at all, they are nothing more than glorified editors, locked, non flexible , non editable (Unless you are willing to use another programming language and navigate through tons of source code) . Squeak , Pharo and all other smalltalk dialects offer a real elegant IDE offering you really useful tools. Other IDEs better take a deep a look at smalltalk and really understand what it means to be an IDE.
Saying all those good things, smalltalk is far from perfect. And I think its biggest weakness and flaw is lack of some enjoyable and useful documentation that can help beginners jump in head first. Squeak By Example as well Pharo By Example has been a big disappointment for me. They both are still two extremely important books that provide a extremely valuable insight in both platforms , but the quality of documentation is from mediocre to bad at times. The main reason is both books follow a non noob friendly approach. First they send you deep diving in the IDE , introducing you from chapter 1 , to debugger and even unit testing !!! For me this a big mistake, and even though I am far from new to programming had to struggle to follow up what was explained. Then the book itself , lets a lot of unanswered questions. For example the explanation of instance vs class variables is not enough, I would prefer several example that not only show the how but also the why . Several areas of the book are also full of gaps or just hard to follow.
My life got a lot easier when I found this link http://stephane.ducasse.free.fr/FreeBooks.html and from there I downloaded "Smalltalk by Example" which unlike the other book not only it does what it says in the title but makes no assumption on who you are and what you know. I can only highly recommend it. I read that the other books there that are offered freely are very good as well, I will certainly download and read all of them eventually.
Alot of help has been also #squeak at irc.freenode.net, people there has been answering my questions and helping me understand.
Squeak wiki, is ok but not enough, its also not very well organised, and I dont like that comments and discussions appear inside the wiki documentation. So documentation generally can be abit of a struggle for the begginer and certainly Smalltalk IS NOT AN EASY programming language to learn. I hear many smalltalkers say otherwise and I could not disagree more, when I compare smalltalk with python is like night and day. BUT ! Once understand smalltalk , it become much easier to program in it then any other programming language I have learned so far, and I have learned most of them. So in the end I think Smalltalk is a clear win , I also love the FFI library that lets you call any C library with ease, which unleashes serious power for smalltalk.
I dont think you need to learn the language first and then the IDE, its actually a very bad idea for the simple fact that the IDE helps you understand the language and its libraries and any type of code in it. Language and IDE is like brother and sister, yin and yang.
Well, if you decide to learn Eiffel a good book would be "Object-Oriented Software Construction" by Betrand Meyer (he created the Eiffel programming language).
The book provides great insight into object-oriented design using Eiffel. In my humble opinion is one of the best OO books around.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I was talking with some of the mentors in a local robotics competition for 7th and 8th level kids. The robot was using PBASIC and the parallax Basic Stamp. One of the major issues was this was short term project that required building the robot, teaching them to program in PBASIC and having them program the robot. All in only 2 hours or so a week over a couple months. PBASIC is kinda nice in that it has built in features to do everything, but information overload is possible to due this.
My thought are simplicity is key.
When you have kids struggling to grasp:
if X>10 then <DOSOMETHING>
There is not much point in throwing "proper" object oriented programming at them.
What are the essentials needed to foster an interest in programming?
Edit:
I like the notion of interpreted on the PC as learning tool. Due to the target platforms more than likely being somewhat resource constrained, I would like to target languages that are appropriate for embedded work. (Python and even Lua require more resources than the target likely to have. And I actually kinda like Lua.) I suppose that is one of the few virtues BASIC has, it has been ran on systems with less than 4K for over 30 years. C may not be a bad option if there are some "friendly" tools available such as Ch.
The most important is not a lot of boiler plate to make the simplest program run.
If you start of with a bunch of
import Supercalifragilistic from <expialidocious>
public void inherited security model=<apartment>
public : main .....
And tell them they "not to worry they aren't supposed to understand that" - you are going to put off both the brightest and the dumbest.
The nice thing about python is that printing "hello world" is print "hello world"
Fun, quick results. Capture the attention span of the kid.
Interpretive shells like most scripting languages offer (command line) that lets the student just type 1 or 2 liners is a big deal.
python:
>>> 1+1
2
Boom, instant feedback, kid thinks "the computer is talking back". Kids love that. Remember Eliza, anyone?
If they get bogged down in installing an IDE, creating a project, bleh bleh bleh, sometimes the tangents will take you away from the main topic.
BASIC is good too.
Look for some things online like "SIMPLE" : http://www.simplecodeworks.com/website.html
A team of researchers, beginning at Rice, then spreading out to Brown, Chicago, Northeastern, Northwestern, and Utah, have been studying this question for about 15 years. I can't summarize all their discoveries here, but here are some of their most important findings:
Irregular syntax can be a barrier to entry.
The language should be divided into concentric subsets, and you should choose a subset appropriate to the student's level of knowledge. For example, their smallest subset is called the "Beginning Student" language.
The compiler's error messages should be matched to the students' level of knowledge. If you are using subsets, different subsets might give different messages for the same error.
Beginners find it difficult to learn the phase distinction: separate phases for type checking and run time, with different kinds of errors. For this reason, beginners do better with a language where types are checked at run time, i.e., a dynamically typed language.
Beginners find it difficult to reason about mutable variables and mutable objects. If you teach pure functional programming, by contrast, you can leverage students' experience with high-school and middle-school algebra.
Beginning students are more engaged by an interactive programming environment than by the old edit-compile-link-go model.
Beginning students are engaged by splash and by interactivity. It's good if your language's standard library provides built-in support for creating and displaying images. It's better if those images are supported within the interactive programming environment, instead of requiring a separate player or viewer. And it's even better if your standard library can support moving images, or some other kind of animation.
Interestingly, they have got very good results with just 2D images. Even though we are all surrounded by examples of 3D computer graphics, students seem to get very engaged working with just two-dimensional images.
These results have been obtained primarily with college students, and they have been replicated at over 20 universities. However, the research team has also done some work with high-school and middle-school students. The first papers on that work are just coming out, so I'm less aware of the new findings and am not able to summarize them.
When you have kids struggling to grasp:
if X>10 then <DOSOMETHING>
Maybe it's a sign they shouldn't be doing programming?
What are the essentials needed to foster an interest in programming?
To see success with no or little effort. To create something running in a matter of minutes. A lot of programming languages can offer it, including the scary C++.
In order to avoid complication with #includes, multiple source files, modularization and compilation, why not have a look elsewhere? Try to write some Excel macros or use any other software with some basic built-in scripting language to automate certain tasks?
Another idea could be to play with web pages. It is not exactly programming, but at least easy to achieve something and show to others with pride.
This has been said on SO before, but... try Scratch. It's an incredible learning tool for kids. It teaches the basics of programming concepts in a hands-on and language-independent way. After a bit of playing around with it they can get down to learning a specific language's implementation of the concepts they already understand.
The common theme in languages that are easy for beginners - especially children to pick up is that there's very little barrier to entry, and immediate feedback. If "hello world" doesn't look a lot like print "Hello, world!", it's going to be harder for people to pick up. The following features along those lines come to mind:
Interpreted, or incrementally JIT compiled (which looks like an interpreter to the user)
No boilerplate
No attempt to enforce a specific programming style (e.g. Java requiring that everything be in a class definition, or Haskell enforcing purely functional design)
Dynamic typing
Implicit coercion (maybe)
A REPL
Breaking the problem (read program) down into a small set of sections (modules) that do one thing and do it very well.
You have to get them to stop thinking like a user and start thinking like a programmer. They need to take it one step at a time. Ask them what they have to think of in order to figure out the problem them selves and then write them down as steps. If you can then you break each step even more in the same mater. When done you will have the program in english making it simpler to program for real.
I did this with a friend that just could not get it and now he can. He used to look at something that I did and be bewildered and I would say that he has done more complex stuff than this.
One of the more persistently-present arguments I have had with other programmers is whether or not one's first language should require explicit type languages. Many are of the opinion that learning a language which requires you to explicitly declare type information is one which will teach you to program typefully. Conversely, it can be said that dynamic languages might present a less demanding learning curve. It goes either way, I suppose.
My advice: start with a simple model of how a computer works. I am particular to stack machines as good tools for teaching computation.
Remember that beginners are learning two disciplines at the same time: how computers work and the abstract logic involved (the basics of Computer Science), plus how to write programs that match their intended logic (learning a specific language's syntax and idioms). You have to address both concerns in an interwoven fashion in order for the students to quickly become effective. This is also the reason experienced programmers can often pick up new languages quickly.
It's worth noting Python grew out of a project for a language named ABC, which was targeted at beginners. For example, the required colon isn't strictly required, but was found to improve readability:
if some_condition:
do_this()
I got 3 words : Karel the Robot.
it's a really really simple 'language' that is designed to teach people the basis of programming :
Look for it on the web. You can look at this, though I never tried it :
http://karel.sourceforge.net/
While this isn't related to programming a robot, I think web programming is a great place to start with kids that age. It's how I started at that exact age. It easily translates to something kids understand if they use the web at all. Start with HTML, throw in Javascript, and soon they want to be doing features requiring server-side scripting or some sort, and things progress from there.
With the kind of kids who are already interested in robotics, though, I'd actually go for a different language like the ones already described. If you want to work in a field like robotics, you don't need to be convinced to try something hard. You need to be challenged.
A few years ago I saw a presentation at Ignite! Seattle from one of the people working on the project now known as Kodu who envisioned as a programming language for children. He spent time talking about what common language features could simply be thrown out in a programming environment meant to teach fundamentals.
A lot of cherished imperative constructs, like C-style for loops, were simply left out in favor of a simple object-messaging approach. Object-oriented programming isn't hard to understand when you think about "objects" and "messages"; the hard part is when you deal with things that programmers, but not children, care about, like inheritance and contracts and sweeping abstractions. I've got this thing (noun), now act on it (verb), in this way (adverb like quickly), when thing (sees/bumps into) something (with some attribute) (that's your if). Events are really conditions, and have all of the power of conditions, but it's up to the runtime to identify when those events happen.
This kind of event and messaging driven approach probably translates even better to robots than procedural programming would, anyway, so it might be a good way to look at the problem. Try not to think about what you'd "need" to know to program in C or Pascal or something; think about what you'd want to be able to make something do.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I never worked with SAP solutions. I have a reasonable understanding of business, but no accounting background. How to learn ABAP on examples that will simultaneously enlighten me with the "way of SAP"?
It doesn't have to be a deep knowledge, just something to start for somebody who was in the world of Python and C# but needs understand how SAP world works.
(this is not a duplicate of "Learning SAP-ABAP")
Learning ABAP is not particularly difficult if you know other programming languages.
Let's first distinguish between ABAP and ABAP OO. ABAP is the old, procedural language and ABAP OO is its extension with classes.
ABAP has the usual control structures, like if-then-else or loops. Its syntax takes a bit of getting used to (I found especially annoying the part about putting or not putting spaces before parentheses), but is definitely doable.
There are some structures you don't find in C++ and C#, for example the grouping of functions in function groups, which have their own local variables, so if you call something that is in a different function group, things can get messy.
But generally, if you understand scope and namespaces, it shouldn't be a problem.
I found ABAP OO pretty straightforward compared to ABAP, because it basically only added the classes / packages that I knew from C++ / C# before.
How to learn them, I would propose the following for someone who is new to ABAP and wants a DEEP knowledge of it (see later the more functional aspects):
-buy yourself a proper ABAP book, e.g. something from SAP Press
-don't read it just yet
-start with a web course or a simple book, along the lines of "learn ABAP in 24 hours"
-start coding
-as you are coding, you will inevitably ask yourself: "how does this and that work? is the PERFORM using pass-by-reference or pass-by-value for passing the arguments?" Look those questions up in your proper ABAP book
-probably after a few months, you will be familiar enough with the language that you can read through the book without falling asleep
Just a caveat: It IS a useful skill to know ABAP programming, but even if you don't consider the other technologies SAP consists of (like workflow or PDF Forms, that don't have anything to do with ABAP), there are still a lot of frameworks that differ in their logic. So just like even though you know C++, knowing the Win32 framework does not mean you can start banging out code that runs under UNIX, knowing ABAP does not mean that you can work productively in a specific module right away. Unfortunately, SAP modules tend to use different frameworks, some of them more reused than others.
If you do not want a deep knowledge of ABAP, but want to understand the SAP modules functionally, you should consider using the products themselves in addition to programming and learning about the functional aspects.
I'm afraid there is really no quick way to learn how the "SAP World" functions; you need to have a bit of technical, functional and also architectural knowledge for that and since the modules are so vastly different from all those aspects, it takes a lot of time until you can have a vast overview of everything. But even with technical and some functional knowledge you would be well on your way; as they say, "in SAP, nobody expects you to know everything".
There are at least two different sets of issues you should be looking for:
Knowledge of ABAP as a programming language
Knowledge of the "Business Domain" that your writing your software for and its implementation in SAP - tables, forms, programs, reports etc, (and each of the modules such as FI HR etc. is more than a normal person can usually be proficient in)
(1) gives you general knowledge on how to write a program, read and update the database, and maybe write a GUI. But the programs that you write will almost always be in the context of (2), so you will need to know that as well.
If you want to get started, it is best to have some general knowledge of the ABAP language, the business domain can't really be learned from a book. Actual project work is much more helpful.
Start by downloading one of the netweaver trial systems from sdn.sap.com (choose one of the ABAP trial systems).
For reference you have the ABAP manuals online here (the reference documents also have a lot of small example programs). For more example code you can enter transaction SE38 (report editor) and search for programs starting with BC or starting with DEMO (put BC* in the name box and press F4).
since you asked me to respond to this question as well. I was hired as a sap-java-developer because there are very very few on the market, even though I didn't know anything about sap java before I entered. I got advice from my co-workers and learned as fast as possible to become productive. It wasnt such a big deal in the end.
I'm one year into the business now but I'm still in a newbie-state. The sap technology environment is huge. SDN (Sap Developer Network) is my best friend whenever I'm stuck.
It definitely helps when you end up in a company with sap-knowledge because you dont have to build up all systems from scratch and you have the licenses for the various sap products at hand. Most trial versions from sap just wont do the trick on the long run.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have noticed I do not code as much as I use to. Today I dedicate more time to analysis and design, then I communicate that design to programmers. Then they do the coding. This has affected my coding productivity, because I must consult references and rely on intellisense. Things are becoming more complex everyday
Now, here is the irony. If I were to hire a programmer and ask him/her to sit in front of a computer, I may ask to do some coding and I would check abilities. I would evaluate them based on their use of memory vs. consulting references. Maybe I will prefer that programmer who did not consult too much, but who knows what they are doing.
What is your opinion and experience?
I would say that a developer who knows how to find the answers is better than one who has an overall good knowledge already. I find that intellisense is a good tool for finding answers, besides it is too much to remember all method names, arguments, overloads, etc.
I use memory to get me into the right general area (e.g. knowing which classes to use or at least which namespace they'll be in) and then often Intellisense/MSDN for the exact method name or arguments to use.
Having said that, Stack Overflow is improving my ability to code without any references (or even compilation) - I'm sure code will just work out of the box for me more often now than it used to. (I tend to post and then check the code works, add links to MSDN etc - assuming I'm reasonably confident in the approach.)
Someone knowing what resources are available, and how to find the answers, and how to effectively debug - these are qualities I look for now in prospective employees.
I used to consult my memory only, but two things have happened:
Class libraries have gotten larger, so has the number of languages available
The ratio of programming-related memory to personal-life-related memory has shifted away from code
Programming today is also eight times harder than it was when I started. I used to work on 8-bit machines, now I'm working on 64-bit ones. :)
I once was at a job interviewed with the CTO of a company. He asked a question based on a real life problem the company had a while back and solved. It was a multi step problem.
I was standing in front of a whiteboard working through my solution and struggling through a particular part, a part I would use google for before even attempting it, had I been tasked with solving this problem for real instead of for an interview. He asked me at that point, "would you do anything different if this wasn't an interview question." I responded, "Yes. I would exhaust all possibilities of using a third party component for this part of the task and look up the solution, because it is a well defined problem thats been solved several times." There was a bit more discussion where I justified my answer, explained exactly what I would research, and I solved some other parts of the question. In the end I was offered and accepted the job, partly because of knowing how to find out what I didn't know.
Being able to use references is as important as being able to code from memory. Obviously, if you are a one language shop, and want people proficient in that language,the person should be able to write a complete hello world app in notepad. Interview problems should focus on small problems, and one should not worry about small syntax errors. This is why a whiteboard is the best IDE for interview questions.
Unless you demand all your coders use notepad and don't give them internet access, don't be as concerned by the syntax. If you do sit them down in front of a computer, worry about the finished product as well as the technique used to get there.
I'm a PHP programmer in my early 30's. I rely on PHP's excellent documentation, for several reasons:
Programming concepts don't change. If I know what my object models are and how I want to manipulate data, then there's dozens of ways to implement the details. The details are important, but a better grasp of the design and structure is more important
PHP has notoriously inconsistent functions. One string function might use ($needle,$haystack) as parameters, and another might use ($haystack,$needle). Trying to keep them straight isn't worth the hassle when you can just type php.net/function_name and get the reference.
I don't rely on intellisense, simply because I haven't found a decent IDE for PHP that does it well. Eclipse is ok, but it's not fantastic. Netbeans gives me 'PHPDoc not found' for all the built-in PHP functions whenever I install it. There's nothing that I've found so far that beats out the documentation.
The bottom line is that the ability to memorize functions isn't indicative of coding ability. Obviously there's a key set of basic functions that a good programmer will know just from extensive usage over time, but I wouldn't base a hiring decision on whether someone knows substr_replace vs. str_replace from memory.
Because I've read either the documentation, or articles, or a book on a subject, the things I learn on a topic are organized. The result is that, if I can't bring something up from memory, I can probably find it quickly through IntelliSense or the Object Browser.
Worse come to worst, I can pick up the book again; something these youngsters are not being taught to do.
John Saunders
Age 51
Pretty much Google + Old Projects + my memory (of course)
References will not solve your problems though, its only for the nuts and bolts, the higher level of problem solving is the actual "programming" part IMHO.
I tend to use Intellisense and Resharper much more than I used to before, but this has helped my overall productivity. If I can get the idea of how I want to solve something and then use tools to get the more boring parts like class names and function signatures, why shouldn't I use the tools I have? I feel relieved that Jon Skeet has a similar approach it seems.
I rely on my bookmarks and books... and my ability to use them effectively. I have multiple books above my desk, including a copy of the ISO C90 standard. Moreover, I use Xmarks to have access to my bookmarks wherever I go. Sometimes, I make a pdf out of a particular page and upload it to my web-site if it is important enough.
Sometimes the information provided by the resources I use makes its way into my terrible memory... maybe.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am learning programming. I plan on learning C and Objective-C this summer. I bought the C for Dummies book but it is a complete waste of time. It's way too many pages! Are there any good books I should read? Or should I just learn C from websites? What would be the fastest way because I really want to learn it fast and start learning Objective-C too.
Thank you
Also, how long does it take to learn C? Until I move to Objective-C 2.0
There's no need to rush. Learn at your own pace and find your optimal way of learning.
If reading is your thing, then try to read some books and take it slowly.
If you find a concept you grasp, practice. If you find a concept that you don't quite get, experiment. Once you think you understand the concept, try re-reading the material to see if you understand it the second time.
I found out that I wasn't really good at learning though books -- I generally had to get the first kick-start with a structured lessons in a classroom. A semester course at a community college on Java was able to nudge in the direction of being able to begin effectively learning on my own. See if there are any programming courses offered in your school.
(Although at your age it may be a little bit difficult to find -- I didn't get any formal classes until community college -- my high school did not offer any programming courses.)
One of the things to be careful of is learning it the wrong way.
Rushing through material, or reading poorly written, inaccurate learning material can lead to a situation where you'll need to "un-learn" the concepts and re-learn it the right way.
In that respect, the K&R book (The C Programming Language by Kernighan and Ritchie) would be the "right way" of learning, but it's not a very approachable book. That isn't to say that it is the definitive book on C -- but even after programming in C for a couple years, I still try to take read it a bite-size at a time.
But then again, I can't really think of other "great" sources for learning C. My recommendation would be to take a look at K&R and work on a few pages at a time. Don't think about reading it like a regular book -- read one section, try it out. Do it little-by-little. Once again, don't rush. Work at your own speed.
And be sure to write code. Without seeing it working, it's going to be difficult to learn programming. And don't have huge expectations at first, as most of learning C at the beginning will involve programs that deal with only text.
Once you get a handle of things, try to write clean code that is readable by others -- that should be a motivation to write clean and clear code, and it will force you to think harder about what you're doing.
It's going to be a long adventure, so take it a step at a time. Good luck!
For learning C, I highly recommend Learn C on the Mac, by Dave Mark. Not only is it aimed at beginners, but it also teaches you a lot about the important fundamentals of programming and computer science (e.g. data structures, recursion, etc.). It's very accessible, well-written, and easy to read. Plus, I found the examples engaging and interesting to work with. After that, if you really want to solidify your foundations in C, I'd recommend trying to moving on to The C Programming Language. It's a challenging book, so take it slowly. If you find yourself having too much trouble with it, I'd say you can just skip to Objective-C, and then come back to The C Programming Language later, once you've gained more familiarity with programming in general.
A lot of people will probably recommend The C Programming Language (a.k.a. "K&R") as your first book to read on C. No doubt it is a very well-written C book (and it's short too—only around 200 pages), but I'd say it'd be a little intimidating as a 12-year-old's first exposure to C: it's pretty dense and hardcore. You can tell that it's definitely aimed at an older audience with a strong background in computers/engineering. But nevertheless, if you already know the basics of programming, reading K&R will give you invaluable insight and understanding of C. You should definitely read it at some point in your programming endeavors.
Anyways, for Objective-C, if there's only one book I could recommend, it would most definitely be Cocoa Programming for Mac OS X, by Aaron Hillegass. It's really not that long (~400 pages or so, although I'd reckon that a lot of that is due to the number of illustrations in the book), and you can get some pretty cool projects up and running in an afternoon. It's very clear and easy to read, the examples are practical and interesting to follow, but most importantly, it's got this right blend of not being too intimidating while still managing to provide you with solid information. Plus, it'll teach you more than just Objective-C: I found that I had learned some very useful design patterns, for example, by learning how some of the components of Cocoa worked.
When I look at the title of this question, I am guessing you are 12.
I started programming when I was 13 (I am now 14).
I found that learning depends on what kind of a learner you are!
I hate reading, I have the attention span of a moth and I learn best from videos. Therefor, I am a "visual learner". Try to find out what kind of "learner" you are, then do it that way. Remember, the easiest way is the fastest.
PS, here is a little tip. It may be frustrating (aseptically at our age). If you get frustrated, just put it down for like 10 minutes. Then come back and do research on what your learning. Programming WILL get very frustrating at times.
EDIT:
By the way, I like to learn through video :p
Stanford University posts online the lectures, class notes, and assignments for CS193P (an iPhone development class). If you don't know C or Objective-C at all, it might be tough, but I highly recommend this if you intend to do iPhone development.
I think I've read every Cocoa and Objective-C book out there, and most enjoyed Aaron Hillegass' Cocoa Programming for Mac OS X.
I would take a look at The C Programming Language (K&R C). It's much less than 1000 pages and I think you'll find it well worth your while. As htw said, books do serve a purpose in that they provide a thorough and structured approach. K&R C in particular will give you real insight directly from the creators of C.
That's not to say you shouldn't Google things, read open source code, write little practice programs, etc. It all helps. Just remember to be patient. There's a lot out there.
Checkout out http://www.cprogramming.com/ or and online K&R type book
Don't be impatient; take your time. Follow tutorials, dissect short snippets of code, you'll get the hang of the language. Most importantly, write code yourself and learn from your bugs/errors.And follow Stack Overflow ;)
I've been where you are. It wasn't fun. This is what saved me:
(Apparently new users aren't allowed to post hyperlinks, so google for "steve summit C", use either the first or the third link, and then click "introductory C programming class notes")
It's a C class by a guy named Steve Summit. Super easy to follow, much easier than K&R, imo.
Also, it's free, and there aren't any ads. I loved it. It's how I learned C. I hope it'll do the same for you.
There is nothing so educational as a piece of code you can run and tweak. Code examples in books can be really bland and not very applicable. The exception to this rule was the Perl Cookbook which is jammed packed with really useful little snippets for your perl programs.
The topics (or 'idioms') in it were so useful and so applicable across languages that some smart folks have taken to replicating them in different languages. Each has a varied level of completeness, but it's interesting to see how different languages do the same things.
Take a look here http://pleac.sourceforge.net/ for nuggets of programming wisdom that you can shake a stick at. At the very least its interesting to see how simple things written in one language require reams of code in another.
Were I starting to learn programming again I would probably pick something easy and forgiving, a dynamic language, like Python, Ruby etc. Once you get your head around the basics in one of these (flow control, data structures etc) it will make learning C/Objective-C so much easier. Also you'll find that you'll want to write once-off tools and scripts to help you in your Objective-C development that would be tedious and time consuming to write in C but are a matter of lines in a modern dynamic language. Never hurts to have another tool in your belt.
Good luck
Honestly, I learned Java as my first programming language (I discovered it in high school and decided programming was fun and it was what i wanted to do)
I just now picked up Obj-C in a few weeks, reading a little bit from some books, but not a whole book, and using the internet a lot if i can't figure out the syntax (format/grammar of how the program should be structured and written) for something etc.
How fast you can pick up a language depends on how much you understand the fundamentals of programming. You will only get better at it with time and practice.
If you can understand the fundamentals of programming in general then you should be able to apply it to any language, the hard part is learning and remembering the syntax of different languages. Like in Java, you don't have to do memory allocations, but in C, C++ and Obj-C you do. I've never written a C or C++ program, but now that I've learned and written some programs in Obj-C (i've been making iPhone stuff, it is fun) I'm sure I could pick up C and C++ like it's nothing.
You don't have to learn C first in order to learn Obj-C is what i'm trying to say. But it never hurts to know multiple languages.
It is all about your level of understanding how a program works, how to structure one. I love objective-C because it is Object Oriented like Java so it was easier for me to understand and learn quickly, just had to get used to some of the differences in syntax
(I'm also getting close to graduating from college now so I'm surrounded by programming stuff, from procedural languages like ada to object oriented like java, and knowing the nitty gritty behind the scenes stuff that makes a program work, so understanding and learning a new language has gotten a lot easier for me, you start seeing how they relate and don't relate and it is cool)
It is great that you are starting so young. I'm sure you'll pick up on this stuff real fast, and if it is something you really enjoy, it will be even easier.
Good Luck! and have fun! programming can be so frustrating... like, spending 3 hours debugging when you find out it was because you if statement used a grater than instead of grater than or equal too or something like that. but, once you are done with the program, it is so rewarding, and then you just want to make it better and better haha.
I dunno if this helped at all, I hope it did, somehow...
=)
the way i learned quickest was to watch short video tutorials.
If you really want to start with C, I would start by just reading the first three or so chapters of C for Dummies, just to get a feel for how the language works. After that, I recommend going through web tutorials. Good web tutorials will have short code that explain specific functions, and the like.
As a 13-year old, though, I recommend starting with PHP. It's a simpler language to learn than C, but it's based off of C, so it won't be hard to make the transition, whenever you do so.
Different people have different preferred ways of learning. You can see that in the variety of responses above.
So how do you like to learn? Do you like to sit by yourself with a book and a computer? Do you like to sit in a classroom and absorb learning? Do you prefer set exercises, or mini-projects?
When I learn new programming languages, I find it helps me if I have a small application or problem to work on. I prefer to have a problem to work on. If you have a little project of your own that you always wanted to do, use that. If not, as someone above suggested, join a robotics group. Set up a web page and write some programs to do stuff for that.
Look on the web for programming challenges. Google has a fun one every year.
If you want an idea, write a sukoku checking program. Then later, write a sudoku solver!
I like to use a variety of books, rather than just sticking to one or two of the ones suggested above. Find a book whose style you like. Try a few from the library until you find one or two that really click for you.
Personally, I like O'Reilly Publishing books for their chatty and readable style. I learnt C from Deitel, which is more of a classroom style textbook, but it has lots of examples and discussion points.
As you work through examples on your computer, you might wonder how things change if you tweak the code. I learn a lot by first running the example code suggested in a text, but then changing it to see what happens. If I get what I expect, it's a sign that my understanding is pretty good. If I get something unexpected, I try to figure out how I misunderstood what I did.
One last suggestion. Why not start with Python rather than C? I hear that a lot of schools are teaching Python to their kids. The reasons I suggest this are:
Python is pretty easy. You don't have to lay out memory, declare variables and such. No tedious bookkeeping.
Python gives you a nice growth path. You can start off just writing script style programs, using the built in types like lists and dictionaries. Then you progress to using new modules as you need them, and advance into object-oriented coding using classes. There's some functional programming stuff in there too, which you can start learning once you have the basic mechanics of the language under control.
I just love visiting new parts of python all the time.
You can get a lot done in python. It comes with a whole lot of built in modules to do almost anything you like - email, web, xml, graphics, gui, etc.
:)
When I was learning to program in C, I found that Practical C Programming was a good resource. It's a very approachable book with lots of examples.
The fastest way in my view is through learn through websites.
Set a goal of what you want to do and start a simple project
Instead of reading too many books theoretically,google what you want to know to get it instantly as you go through your project.This way you get PRACTICAL knowledge.
Watch online videos as well.Check out my question on VIDEOS here
Ask whatever you don't understand on stackoverflow. We're here to help :)
Follow these steps and I can assure you that you will be a great programmer soon!
Cheers!
With others, I highly recommend Kernighan and Ritchie—perhaps the best language book ever written. I'd also recommend that you slow down and enjoy yourself: don't be wide and shallow; start out narrow and deep. If you like programming, you will want to master the craft rather than be in a hurry. This essay by Peter Norvig explains how not to be in such a rush.
P.S. I started programming at age 12 with APL/360. I had a blast and have been doing it ever since—35 years and counting. Good luck and don't forget to have fun!
By far the best way (and usually the fastest) to learn programming is to find a good mentor. That's easier said than done. But I think you'd be surprised how many people would be willing to help you out. My advice would be just don't be afraid to ask.
If I were you I would find a local FIRST robotics team and see if you can hang out for some of the coding. Odds are you'll be working on a similar problem and will have some support from people who have a decent amount of experience. That's what I would have done, anyway.
I started learning to program in Basic in about 1981 when I was 10. Not many years later it was 6502 assembly to try to get more speed out of a 1 MHz Apple IIe clone.
Pascal was a revelation in 1988 - programming without line numbers.
Modula-2, C, Eiffel, Miranda, Haskel, and Prolog at university as well as scripting in any number of languages.
C++ professionally for about 6 years.
C#, then Java, Ruby, and now back to C# for the last 18 months.
Python somewhere along the way.
My advice, pick the language that is best suited to the problem you need to solve today.
The first problem you have is to learn the basics ie how to break down a problem and express it in a clear and concise manner. I suggest you choose something other than C. I recommend Python as the online documentation is excellent and the libraries are great and you will spend more time writing interesting code and less time trying to figure out why your code stopped due to a segmentation fault.
When you've got the basic concepts under your belt, try some assembly and learn what's going on under the hood. If nothing else, you'll learn how fast CPUs really are. C is a good step after that. I also suggest you try Java or C# before Objective-C.
As to how long before moving to Objective-C, it really depends on how talented you are. If you're really good, then once you've learnt your 3rd or 4th language you'll can be more productive than most coders within 6 weeks of starting a new language (although changing language families (ie imperative, functional, object oriented) takes longer). If you're no good then don't expect to get past the first. Hopefully you make it into the first category.
In addition to whatever books and websites you end up using, you might consider looking around your area for local support groups. Many areas have a Linux user group or a group for Java or Ruby programming. Professional programmers use these groups to help each other with their programming problems, but the groups are generally friendly to young people and beginners. Don't feel embarrassed or awkward because of your age and inexperience. Most people will admire your initiative and curiosity and be happy to help you when you run into problems.
Assuming you have some basic programming knowledge, Cocoa Dev Central have a series of articles that explain basic C then Objective-C, in a somewhat-less-than-1000-pages way..
Learn C for Cocoa, then Learn Objective-C
Shouldn't take even an hour to go through. The articles don't cover anything remotely advanced, but if you're learning ObjC to write OS X applications, the ObjC bit is basically trivial, it's Cocoa that is difficult to learn!
If you want to learn Objectif-C to create iPhone application, don't waste your time on C and learn Objectif-C now, then a book on iPhone programming. It will be more than 1000 pages but if you want to program in your life, you have to be used to read these types of book.
I created an online interactive C tutorial, you can start using it without installing an IDE.
http://www.learn-c.org