I have no idea how the programming works.

If I spend all my time and effort into learning the basics and etc., how long would it take me to be able to program top-notch Tsumego-solver, sgf editor, and etc.?

Just a rough estimate plz

That is like asking how long it takes to learn a new language. It all depends on your instrinsic ability. It would take me very little time to learn a new programming language but years to learn a new linguistic language. That is a result of my experience and general abilities. It could be very different for you.

_________________
Still officially AGA 5d but I play so irregularly these days that I am probably only 3d or 4d over the board (but hopefully still 5d in terms of knowledge, theory and the ability to contribute).

Learning a programming language is the easy part. Programming GUI is an extra burden. The really difficult parts are learning fluent and efficient use of data structures, algorithms and software engineering for the sake of finishing a program instead of programming eternally and aimlessly. Before you start, familiarise yourself with what are data structures and algorithms so that you get to know whether programming is something you will be able to do successfully or will forever be above your mental skills. Error handling, security etc. are additional fun.

Hmm. From scratch, well, you're going to have to learn programming concepts (like design patterns, object orientation, concurrency, etc), and a language, Java, C++, Ruby, Python, whatever. This includes patterns specific to the language, and each language will have different ideas about graphics and GUIs. If you want to do it in the browser so that you have a distributable program, you are also going to have to know something about distributed programming concepts (model view controller, security), and if you want other people to save progress and such, you might want to also learn some sort of framework (Django, dot net, Rails, etc). I mean, there's thousands of ways to do it. I'm just giving you an idea of one path you could take. Then, there's databases, you're going to have to store things persistently, so you also need some knowledge about relational databases. I mean, yeah, you could also do it in text files if it's a microscopic program. Then you're going to have to actually do some research so that you at least have an idea about other people have tackled similar projects, then design it, program it, test it, and then you'll have a working program.

So it kind of depends. If you're asking me for a time, for a person with reasonable intellect and analytical skills and a quick learner, I'd say maybe between 3 and 6 months of doing this and nothing else. More if you're going to look into ALL the things listed above. If you want your program to actually do intelligent stuff, you're going to have to learn some basic AI concepts and practical algorithms, so again, add more time.

If you want to know where to start, try to describe to yourself in writing and in pictures what at least part of your program should do, right down to the individual buttons and layout and what it actually does. Then work on this part, and build the program up in sections. If you start by staring at a text editor without having done your prep, it's not going to work.

_________________
12k: 2015.08.11; 11k: 2015.09.13; 10k: 2015.09.27; 9k: 2015.10.10; 8k: 2015.11.08; 7k: 2016.07.10 6k: 2016.07.24 5k: 2018.05.14 4k: 2018.09.03 3k: who knows?

As a retired professional, I will second that opinion that PROGRAMMING (designing software) and learning a programming language aren't the same thing. It is quite common to teach the two concurrently so that the programing itself won't be completely abstract, but we should remember that at least one famous "early days" book (see Donald Knuth) was teaching the programming using an abstract language. You should also realize that at least a couple languages began as abstract languages (and THEN actual implementation of them came into existence --- LISP, PASCAL, etc.)

Many of the programmers with whom I worked were SEVERELY handicapped by never having learned data structures and algorithms in the abstract. So I strongly recommend that if you do want to learn programming, at least semi abstract (and you want your "course" to cover all the standard data structures and algorithms.

The high level languages are NOT a way around this for the beginner. Productivity in a "shop" is a different matter, because the "shop" could be expected to contain people like myself capable of designing in terms of structures (or abstract procedures) that the less experienced programmers could then just use.

Also experience plays a role. Don't expect to become really skilled starting from scratch in less than say five years, and that assumes the right choice of learning materials and enough innate talent.

PS: Don't let that discourage you from getting started. These days, most language texts will have you getting "hello world" output within just a couple hours if that.

In terms of how long to learn a (new language) well that depends on how many you have already learned and of what sort (a "procedural" language does not necessarily help you learn your first "functional" language and vice versa). Somebody like myself, decades in the cypher mines and fluent in half a dozen languages could read almost anything and be fluent writing in this new language within weeks. Don't go by THAT.

You should be reasonably fluent is six months. But that doesn't mean you would be able to design correct, efficient programs in that amount of time. Also important characteristics, clearly written, easy to debug, easy to maintain. And if for "clients", designed flexibly because they WILL always be changing their minds.

Start with quite "simple" tasks.

Try to get a clear picture of what your "program" should do.

In the beginning, use a well known "language" for writing down the details of your "picture". It is very likely that this "well known language" will be your native one.

After your "picture" is finished, do the "translation" into the programming language of your choice.

Do not worry about your programming code becoming quite long. Be happy with your program doing the intended task.
You will realise later -- the better, and quicker, the more experience you have got -- which parts of your initial code can be optimised, and shortened.

And -- last, but not least -- be well aware that your program always (!!!) will do exactly (!!!) what you have told the program to do (even if this did not really match your intentions ). This will help you finding errors in your code.

+ + + + + + + + + +

If you intend that your program should be used by others than you, be prepared that making your program "idiot-proof" will need at least the same time (may be double that time) as doing the core programming for "you". This refers to making your program "understandable" (and tracable) for other programmers (i.e. by adding comments to the code), as well as to get around potential "incorrect" inputs of other users that you never dreamed of beforehand.

_________________
The really most difficult Go problem ever: https://igohatsuyoron120.de/index.htm
Igo Hatsuyōron #120 (really solved by KataGo)

There's a large difference between the question in the post subject "How long would it take for a novice to be able to program" and the question in the text "how long would it take me to be able to program top-notch Tsumego-solver, sgf editor, and etc.?" (emphasis added)

The difference is similar to that between: "How long would it take me to learn how to play go?" and "how long would it take me to become a strong dan player?".

You can learn basic programming in a few months, but to be really good at it will take you years, and will depend on your innate talent and how much time you're willing to invest.

Thanks for all the advice guys...

Although half of your comments sound like alien language to me right now... if I do my work I'd understand more of em and they'll be a tremendous help.

I will take some Computer Science classes in university this fall. Hope it helps.

Well THAT is a good place to start.

And pay particular attention to that "as well as to get around potential "incorrect" inputs of other users that you never dreamed of beforehand". That is known as "input editing" (verify inputs are legal). Where I spent my working days all incoming programmers had to go through the "training pool" (classes run by the company). The "case problem" did not specify "input editing" so I asked my instructors "shouldn't I add input editing?" They all cracked up laughing! "Don't do THAT Mike or you won't get the hangs to debug" (in other words, part of the exercise was to drill home to us NEVER trust the inputs). But actually, I blew through those hangs so fast they transferred me to the "advanced debugging" course for programmers who had been on the floor a couple years.

If you're keen on having a go at this there's a lot you can get on with now - designing what your program would look like and exactly what you want it to do*. The tasks you mention don't sound particularly complex (relatively speaking) and if you picked a language like Python there should be plenty of example code freely available to give you a head start.

*what makes a "top-notch Tsumego-solver, sgf editor"? obviously it has to work, but IMO it's design design design.

_________________
I am John. John-I-Am.

5 years, if you are quite diligent and make rapid progress.

_________________
Occupy Babel!

My "two cents" to see if it helps.

I work as a programmer, I would divide a go program in (at least) 3:
- rules : how the program response, counts points, etc..
- interface : Is it visual? or just text-like (useful for servers)?
- AI/solver

All of these have it's own problems, as a solo work, my advice, is to work on one of them.
After you feel comfortable, add another.
I can use many other go programs to do the others, no need to reinvent the wheel, and there is lot of work in each of them.

PS: Learning a computer language means some hard work but there are a lot of information online, sites like coursera have some great online free courses.

What ever body said is right. But let me try to put it in terms a non-programmer might understand.

Lets say you are an astronaut. You go to a different planet and meet an alien species. What do you need to do to communicate? You need to learn their language, of course - but you are a linguist, there is a manual they give you, so this part is easy. However - to communicate any more complex ideas between the species, you need to also learn how the aliens actually think - and they think completely differently from you. This is the hard part, and might take years before you can communicate fluently.

Same with computers - they are like alien species, they think differently. All this talk about "data tructures" and "algorithms" and stuff like that - this is how computers think. Programming on a higher level, which is needed for creating a good Go program, will force you to learn that.

Part of this thinking is to be able to split every action into its "atoms" - its basic parts. Humans don't think like that. To boil some water for tee, humans think "Lets boil some water" - and this is the command you would give to another human. When you talk to a computer, you have to say: (1) move 5 feet to your left, (2) extend your hand, (3) lower your hand 7 inches, (4) clamp your fingers around the pot's handle, (5) lift your hand 7 inches, (6) step 5 feet to your right, (7) lower your hand 7 inches, (8) unclench your fist to let the pot go, (9) move your hand 3 inches down, (10) turn the knob 30 deg clockwise to start the burner - and so on... On a higher level you will just have a function called "boil water" which you wrote before (or somebody else did) and you can reuse, but the same idea applies then too - except you deal with bigger building blocks.

But, as Mike said - do not get discouraged.
It is a wonderous world, and no matter how deep you get, every step will be fascinating and rewarding, this I promise you!!

_________________
- Bantari
______________________________________________
WARNING: This post might contain Opinions!!

"How long will it take me to get to 1dan?" You probably heard this before OP, but your question is almost the same. If you're extremely motivated and talented you can do it in a year. Maybe 3-4 years if you take it at a more relaxed pace. Maybe you won't ever achieve 1dan, there are plenty of people who don't. The goal you have in mind requires a solid understanding of computer science and programming, it's kindof like trying to get to 1dan in go, just to give you a perspective. If you're a beginner I would recommend against trying to do it immediately because it's so far out of your reach at the moment that you will probably get burnt out if you try. Incremental improvement is the way to go, so try doing something easier - good place to start is creating a program that let's you play go against yourself. Then add multiplayer support. Then add support for creating/editing SGF files. It should keep you busy for a while.

Good luck.

I came up with the same idea half a year ago: to write a strong tsumego solver and use it in sites like goproblems. At that moment I estimated the task as "rougly two days of work to implement a basic depth-first search and another day to make it handle ko fights" and I had good reasons to think so: I had exceptionally solid math, computer science and programming background. Today, after half a year of study, I have only realized that this task at the edge of my mental ability (I made the "wtf? this stone's disappeared!" -> KGS 1 dan path in 8 months) and I'm barely able to comprehend algorithms that are necessary to write a decent (not a top notch, just decent) tsumego solver. This is just to give you an idea how hard this task is

I highly recommend to not spend time on learning any programming language at the moment - that's the simplest and the least significant part of the task. Learn how search on graphs work: start with basic best-first and depth-first search algorithms and advance to the lamda depth-first proof-number search that handles repetitions (lambda df-pn(r)). Read the Kishi's PhD thesis about tsumego solvers and the Martin Muller's paper about lambda df-pn(r):

www.is.titech.ac.jp/~kishi//pdf_file/ki ... thesis.pdf
www.ijcai.org/papers07/Papers/IJCAI07-387.pdf

I also recommend to take a look at machine learning / neural networks. Even if you don't find it directly applicable to the tsumego solvers, it will let you look at existing problems at an entirely new angle:

arxiv.org/abs/1412.3409
en.wikipedia.org/wiki/Backpropagation

This is why I think we are only in the "infancy" days with neural nets and go and have no idea how far we can get with this approach to a go playing program.

1) We know that (simply) training to predict "the move an expert would make" can at least play the game an not too shabbily.

2) I don't know if anybody is yet working on a neural net "tsumego solver" and I don't think all by itself could even play go.

3) But the training of neural nets involves "annealing" (repeated slight disruption of cell values, like a "mild stroke" followed by retraining --- how to escape from a "local summit" in the learning surface. What if "tsumego training" were used as the "annealing disrupter" in "expert prediction" training.

4) Not to say that there aren't other possibilities.