Learning programming languages *split*

If someone is learning "to code" just as a hobby, instead of doing it to find a future job, then I would recommend learning to cook instead, as cooking delicious foods will probably be more useful in daily life than coding. And most of what a person knows about cooking won't become "obsolete" in less than a decade like it's usually the case with software.
I'm personally refining my coding skills to see if I can make a few simple gaming apps in the near term.

I've already seen both apps as well as code, basically being cloned or modified, and the originator achieving peanuts while the cloner or modifier can get even multiple billions. The chance is remote, but it's there, and even minor success can be ace. All you need is the right art and concept, and even redressing an existing set of game mechanics can lead to success in the marketplace.

That said, what truly interests me in the long run is AGI. A working agi system is the most valuable conceivable technology possible. Given the fast pace and large scale funding of AI research, it is likely I will end up being a follower, and reading the discoveries of others, rather than being a pioneer, though it is not entirely impossible that one might actually end up being a pioneer in the field.
 
as does E.Dijkstra

Such lists are too hard to compile objectively. It's easy to mix skill with impact & success IMO. Which of these you prioritize or which should matter?

As a programmer I do care to an extent about knowing good programmers. Because I may be able to learn from them, they're my (usually) more experienced colleagues. Funny is that I found that the drive, the passion of others is more useful to me than the simple conveying of knowledge.

I've had job colleges (admittedly, very very few) whom I can place on such a list without any remorse.
As for people I've not met in person, the programmer I most admire and I've learned the most from is Paul Philips (a former poker player who the worked ~10 years on the Scala compiler)
 
Kristen Nygaard and Ole-Johan Dahl should be on those lists.

Does Bill Gates belong there?

Cheers
I've never admired Bill Gates as a programmer as I admired Carmack. Oddly enough he appears in two of the lists. It would be interesting to ask him directly if he feels like that. But I never considered him a programmer either, for some reason. As a philanthropist that's an entirely different thing.

Make a game in 60 minutes. A tutorial with the code explained in detail. Well worth the read:

https://msdn.microsoft.com/en-us/library/bb975644(v=xnagamestudio.31).aspx

Learn game programming with C#. A course by the University of Colorado which starts January 30th. The course is free. If you complete it and you want the certificate to officially add to your skills list, it's 45€ for the certificate, but you aren't compelled to do that.

https://www.coursera.org/learn/game-programming
 
Last edited:
I got my project to work with commands yesterday, all the way from angular 2 ui to a properly abstracted database layer. Quite happy how it turned out :)

it's all on Github btw, my account there is niwra
 
I got my project to work with commands yesterday, all the way from angular 2 ui to a properly abstracted database layer. Quite happy how it turned out :)

it's all on Github btw, my account there is niwra
you look like a nice guy, in the best possible sense of the word. .NET engineers are in the top 3 paid jobs in my country btw. Your pyramids of code remind me of this.

COYihdo_Wg_AE9q3_Y.jpg


Too bad I know nothing about Javascript
 
my god that code is horrible, has the programmer never heard of a case or switch statement
Case Key of
’a’ : WriteLn (’A pressed’);
’b’ : WriteLn (’B pressed’);
’c’ : WriteLn (’C pressed’);
else
WriteLn (’unknown letter pressed : ’,Key);
end;
 
It looks funny though. Switch can do a fall through, so could work. If you want to have fun, you can read about design patterns and then try a chain of responsibility pattern here.
 
'It looks funny' isn't really an argument against this type of code, though. Does it express what it needs to do, readably and concisely? I'd say that it does (provided you have sufficient horizontal screen space).
 
I think it's simply a matter of syntax. Normally people write this kind of code because there's a need for a clean-up if any of the conditions are not met, but many programming languages do not have a suitable syntax to handle this situation, other than split it into two functions, which is not always an ideal solution.

[EDIT] an example of a better syntax looks like this:

Code:
func doSomething() {
  do {
    if condition A not met {
      throw some exception
    }
    if condition B not met {
      throw some exception
    }
    if condition C not met {
      throw some exception
    }
    // etc
    doIt()  // only do this when all conditions met
  }
  catch(e) {
    // clean up when there's an error
  }
  // clean up for all
}
 
Last edited:
Ehm, it really is horrible code. There are lots of ways to do this better for sure.
 
It's surprising there still are programmers
This was actually a big deal back in the day (important enough to receive government money) some predicted it would mean the end of programming
ZmEcFKR.jpg

David James, the program's author says that he named it The Last One because 'it's the last human-produced program that needs to be written'...
 
Ehm, it really is horrible code. There are lots of ways to do this better for sure.
Sure there are better ways, for example inverting the conditionals to bring the error messages next to the corresponding check. But does the existence of better alternative warrant calling it "horrible"? Is this an aesthetic judgment?
 
It's surprising there still are programmers
This was actually a big deal back in the day (important enough to receive government money) some predicted it would mean the end of programming

David James, the program's author says that he named it The Last One because 'it's the last human-produced program that needs to be written'...

The problem with "automatic programming" is that the whole point of programming is to tell computer to do precisely what you want it to do, and that's sometimes not an easy task. A computer sometimes like a demon granting wishes, you need to be careful what you wish for :)

I think it's probably fair to say that the progress of programming languages is mostly about how to make it easier to express common tasks (otherwise, you can ask the computer to do anything using assembly). No matter how advance a programming language is, there will be tasks that's going to be difficult to express with it. So the point is to make the common task that's not only easy to express but also easy to read so you don't make stupid mistakes (and others can check your work to make sure that it does what you want it to do, also modify it if necessary).

Therefore, I think we'll continue to have better programming languages which are more expressive and, hopefully, with better compilers, more efficient, and they'll probably so easy to learn that most people can program, but you'll always have someone to do the programming.
 
I think it's simply a matter of syntax. Normally people write this kind of code because there's a need for a clean-up if any of the conditions are not met, but many programming languages do not have a suitable syntax to handle this situation, other than split it into two functions, which is not always an ideal solution.

[EDIT] an example of a better syntax looks like this:

Code:
func doSomething() {
  do {
    if condition A not met {
      throw some exception
    }
    if condition B not met {
      throw some exception
    }
    if condition C not met {
      throw some exception
    }
    // etc
    doIt()  // only do this when all conditions met
  }
  catch(e) {
    // clean up when there's an error
  }
  // clean up for all
}

If we use some general abstraction like Try :

Code:
//container that holds either a value of type A or a failure (exception)
Try<E, A> {
    func map(f : A -> B) : Try<E, B> //transforms the value if not a failure
    fumc bind : Try[E, B] //defined only if A is actually a Try<E, B>; a.k.a  `flatten`
    func flatMap(f : A -> Try<E, B>) : Try<E, B> //transforms the value if not a failure; i.e `map` followed by `bind`
    func get : A // throws exception if Try contains a failure, returns the A otherwise
    func filter(f : A -> Boolean): A //converts this Try into a Failure if f revaluates to false
    func getOrDefault : A ....
}
,

we can nuke the control flow stuff , have control whether the exceptions are thrown or not AND nicely state the error cases in our return type of doSomething like so :
Code:
func evalA {
    if condition A not met {
        throw some exception
    }
}

func evalC {
    if condition C not met {
        throw some exception
    }
}

func evalB {
    if condition B not met {
        throw some exception
    }
}

func doIT : A {.....}

func doSomething() : Try<Ex, A> {
    Try(evalA) flatMap {Try(evalB)} flatMap {Try(evalC)} map {doIt()}
    // etc
  // clean up for all
}

func Main() {
  doSomething() //here we can extract the result of type A, we can throw the exception in case of failure .
 //Or we may use the Try result directly in subsequent computions..
}

Edit : Mistakes were made, and additional Tries were needed. But the structure stands.. To make up for the now uglier code above, if we don't care about the specific exceptions for the condition A, B, C we could've used `filter` like so :

Code:
func doSomething() : Try<Ex, A> {
    Try(Try.Success) filter {condition A} filter {condition B} filter {condition C}  map {doIt()}
    // etc
  // clean up for all
}

This got us rid of all the `if`s and calls to the evalA, evalB ... functions
 
Last edited:
It's surprising there still are programmers
This was actually a big deal back in the day (important enough to receive government money) some predicted it would mean the end of programming
ZmEcFKR.jpg

David James, the program's author says that he named it The Last One because 'it's the last human-produced program that needs to be written'...
programming can be infinitely complex, even your mind can make it different, so I wonder which magical code is that, but I think that's the kind of a statement from someone with a galloping megalomania, and narcissism.

On a different note, if books don't give you all you want when you are learning programming, there are other possibilities like youtube channels. This is my favourite youtube channel to learn, it´s called Coding Homework, and it's just that, someone explaining some exercises and how to complete them. How to make a Almost Chess project, a Turtle Graphics game, a Knight's Tour problem, Star Trek Battle Project, a Poker game...and many others. He mostly focuses on C#, but also has videos of C++, Visual Basic, Java... You can learn a lot with him!

https://www.youtube.com/user/codingchallenges/playlists
 
The problem with "automatic programming" is that the whole point of programming is to tell computer to do precisely what you want it to do, and that's sometimes not an easy task. A computer sometimes like a demon granting wishes, you need to be careful what you wish for :)

I think it's probably fair to say that the progress of programming languages is mostly about how to make it easier to express common tasks (otherwise, you can ask the computer to do anything using assembly). No matter how advance a programming language is, there will be tasks that's going to be difficult to express with it. So the point is to make the common task that's not only easy to express but also easy to read so you don't make stupid mistakes (and others can check your work to make sure that it does what you want it to do, also modify it if necessary).

Therefore, I think we'll continue to have better programming languages which are more expressive and, hopefully, with better compilers, more efficient, and they'll probably so easy to learn that most people can program, but you'll always have someone to do the programming.

It depends if there's any truth to the possibility of agi, and superintelligent agi. If such is possible, it may come to pass that a program will be able to better tell what you want, and even override what you've asked with what's actually best for your particular problem, a task which may exceed your capacity.
 
Back
Top