Printable View
I know HTML, some PHP, and of-course C/C++.
But I want to learn somthing new, I was thinking Java a first, but then I noticed that most people are moving on FROM Java TO C/C++. So that would be going down hill. Does any one know of any other languages that I might want to learn that are more advanced?
I think many people these days learn C and/or C++ after Java because they were taught Java first, possibly in school. It is not necessarily "going down hill".
That said, you might want to try something somewhat radically different, such as a variant of Lisp, or assembly language.
C# if you want to go Microsoft way
Here are two quotes about a language I recommend learning.
Quote:
<autrijus> Perl: "Easy things are easy, hard things are possible"
<autrijus> Haskell: "Hard things are easy, the impossible just happened"
Quote:
<Speck> "That's like cheating. It isn't even programming.
You just tell it what to do and it does it."
-- My friend upon seeing some Haskell code
Objective-C, J, Perl
Java is very nice to learn. The fact that you have to always write classes in Java forces you to think in a very OO way. The portability factor is also very nice, as is the ease with which to do relatively complicated tasks in C/C++ (ie. multithreading, sockets, etc.). There are down sides to Java as well, but overall it's pretty nifty if you want to make a simple graphical program, albeit it takes a long time to really learn their OO tree of objects although their APIs seem way more documented than most.
On the flip side, someone suggested assembly, and I would have to agree with that type of idea. And since you want something advanced, that would fit the bill. You pretty much have to handle everything manually, from loops to even unsigned and signed numbers. Everything has to be expressly done by you. By the end of learning it, even if you never use assembly, at the very least your C/C++ code will most likely be very efficient because you'll have a better idea of the relationship between what you write in a high level language and how it gets translated into assembly and ultimately into machine code. This is probably where I started loving bitwise operations. :) Even if you just write regular programs in assembly using the C standard library functions, you'll still end up learning a heck of a lot imo.
Overall, I would recommend learning both Java and assembly, albeit obviously probably not at the same time. Java is still being used, but the main competition seems to be either web languages such as PHP and Ruby or the .NET languages.
I would recommend against C# since it looks like it came about from an ugly cross between C/C++/Java and then some other few horrible languages ran over it and left some bad markings. :) Nevertheless, it seems to be the main language for .NET, so it might be something you could be interested in.
I also hate Perl, but that's because it has rediculous syntax.... As the writer of an article on Perl at howstuffworks.com noted, in reference to the Perl variable/value/whatever $#_, "If you like that sort of obtuseness, then you will love PERL." ;)
Ruby's kind of interesting. Oo-oo what about Python? Ada?
Or travel back in time and learn:
COBOL
FORTRAN
Or even B ( which was the language C inherieted some of it's features from )
Then learn Binary ;)
You could also forget about learning a new language and learn something that you can use with every language. A few ideas could be:
- XML: I specialized in Internet markup languages at my university and never regret my decision. There are SO MANY applications of XML, from the common usage for homepages to the more advanced B2B (business to business) applications that a strong background in XML is a strong asset. Furthermore, to get the most out of XML, you should also learn DTD, XML Schema and ofc XSLT.
- OpenGL: If you're not into 3D graphical applications, then forget OpenGL but if you'd like to try it, I recommend it absolutely. Not only is it usable in nearly any programming language, but the stunning results can be seen in most computer games.
- Design pattern: Design Pattern is a general repeatable solution to a commonly occurring problem in software design. As such, knowing your design patterns will make you a better coder.
- Write your own language: Even if this sounds very advanced, writing a simply language (interpretable: easy ... compilable: hard) that lets you write simple programs is the best way to learn the inner workings of your code. You can even implement new datatypes, add functionalities and turn it into your own favorite programming language.
What can I download a free assambler?
Searching the Web might help :)
Flat Assembler could be something to consider.
There is also the option of MIPS assembly, possibly using the SPIM simulator that runs MIPS assembly code. There appears to be quite a fair bit of info online about it, perhaps because it is taught in universities.
If you can get Borland's command line tools, you should be able to start with that. It's been a bit since I used it.... but I believe the following should work with it:
Quit simplistic, but it does assemble and run. ;)Code:.386
.model flat
public _main
extrn _printf:near
.data
msg db "Hello, World!",10,0
.code
_main proc
push offset msg
call _printf
add esp, 4
xor eax, eax
ret
_main endp
end
Asm is "unique", I'll give it a try, thanks.
i recommend assembly and python as a scripting language. i use scripts a lot on a day to day basis, it's really handy knowing a quick language
I whole heartedly recommend Haskell. I've been playing with it more and more and have come to really love it (you can't beat cabal and quickcheck for packaging and testing code.) The expressiveness is great. It works as a scripting language pretty well too. Other than Haskell, there's also OCaml which is pretty interesting in itself, although I never got into it.
If you're not interested in functional programming languages, check out Ruby or Perl instead (I've been getting interested in trying out perl 6 recently, I experimented with it once and it wasn't bad at all.)
And of course, the language I think every programmer should learn (or at least try a little): Lisp.
I found the following resource pretty helpful when teaching myself Haskell. It's called "Haskell for C Programmers" and it helped me sort out a lot of stuff that had me stuck before:Quote:
Originally Posted by Mad_guy
http://www.haskell.org/~pairwise/intro/intro.html
My personal vote goes to Python. People hate it because of the whitespace thing, and because it is only "pseudo-functional" but I think it's a perfect match of an imperative backbone with some carefully chosen functional concepts.
If only it ran 100 times faster... :-)
Assembly language is also what I'd recommend. It will give you a better understanding of computers and programming in general.
Speaking of which... who took an Arch & Assembly course in their Uni? What did they teach? Ours taught IBM 360 assembler. :)
I took architecture, advanced computer architecture, compilation and advanced compilation and they all used MIPS.Quote:
Originally Posted by SlyMaelstrom
We don't have Architecture and/or Assembly courses, but compiler development used the Alpha architecture.
Haskell is confusing, but I think I am going to give it a shot anyway, it seems really fascinating. :cool:
What's the point of learning a new language when there's so much more to learn that you could use in any language ?
Because some languages teach concepts better than others.
If you've never learned basic functional programming you're missing out on a LOT. The world of programming is not all about variables and loops...Quote:
Originally Posted by KONI
Woah, Haskell is a lot harder than I thought it would be.
Is there anything that one might acomplish faster or at all with Haskell than they would with c/c++?
It really isn't, it just seems totally mind-blowing when you first get into it (and it really is when you've never done functional programming before.) It took a while of just writing random and interesting little code snippets before I got a good handle on it.Quote:
Originally Posted by Queatrix
While learning Haskell, I probably wrote more little dumb programs and snips of code to get the hang of it than any other language I've done the same with, because I find programming in Haskell quite fun and interesting. You'd be really suprised at what you can make using some of the languages features.
Here's an easy and basic implementation of a unix cat program:Quote:
Is there anything that one might acomplish faster or at all with Haskell than they would with c/c++?
If you wanted a program that would output the lines in reverse:Code:[austin@continuum haskell]$ cat cat.hs
module Main where
main = interact id
[austin@continuum haskell]$ ghc cat.hs
[austin@continuum haskell]$ ./a.out < cat.hs
module Main where
main = interact id
[austin@continuum haskell]$
Or if you wanted every line in the file reversed and outputted in regular order:Code:module Main where
main = interact (unlines . reverse . lines)
Code:module Main where
main = interact (unlines . (map reverse) . lines)
Once you get used to it, you really, really begin to appreciate things in functional programming like higher order functions and monads. And there're even other benefits that're simply side effects of a functional programming language such as Haskell. Example: due to Haskell being a pure functional programming language, i.e. it eschews side effects (no global variables), haskell code is referentially transparent (which basically means that "f(x) = f(x)" in all cases), which is a factor in parallel execution of code on things like multiple cores.
I've having flashbacks of typing mira on the command line. Bad times. ;)
One thing you could learn is regular expressions. They can be really useful, and like KONI mentioned, it's something that can be used in many languages for many things. I first used regular expressions in Perl, but Python and probably Ruby and C or C++ with the right libraries (<regex.h>) support them too. It's just easier to saythen the equivalent in [pseudo-]english.Code:[Ii]mg_\d{4,4}\.(jpe?g|avi)
I'd like to apologize in advance for this ramble.Quote:
Originally Posted by Queatrix
Um, everything? :-) Well, not everything. Maybe.
It's a good language for making window managers. I have recently enjoyed writing a patch for xmonad, a 3-week-old baby written in Haskell. And it's apparently good for version control systems (darcs). And programming language interpreters (pugs). The last one is an example of "at all". It's also great at parsing, which is trivial in the language. (It's near trivial in Scheme or O'Caml, too.) It's used for a bunch of computer sciencey, research type things, too.
It's probably a bad language to use for a text editor extension language, but some people are trying...
If you were to have a months-long race between a C or C++ person and a Haskell person for the creation of some non-trivial application, I consider it a fact, without exaggerating at all, that the Haskell person will finish it more quickly. And the C++ program will be more buggy, and the Haskell version will run faster. If you had a really good C++ programmer, they'd run at the same speed. And if you were to force the Haskell programmer to stop and wait for the C++ programmer to catch up, and at that point change the specifications of the task, the Haskeller will fix things more quickly than the C++ programmer. I say all this without evidence. Well, besides the contrived evidence given by the ICFP programming competition. One reason I act sure that the Haskell version will run faster is that even if there's some operation like image manipulation that Haskell code won't do quickly, the Haskeller could always just drop down in C for that one particular algorithm. Which is sort of a cheap reason, but hey, it's a practical advantage.
The main problem with Haskell, I think, is learning it. When it comes to relying on past experience, it's just one big nsry. There are a few mental transitions I'd say you have to make.
1. Thinking that a function "does" something vs. thinking that a function "is" something. Instead of thinking in terms of algorithms, you have to think in terms of mathematical equivalence. Well, you don't want to have to think that way, but you should (in combination with all other ways of thinking) if you don't want to suck.
2. Tail recursion. Some people are familiar with the notion, but that depends on what language you're coming from. If you're coming from C or C++, it's the notion that the stack doesn't grow on tail recursion. If you're coming from Scheme, it's the notion that the stack actually does grow on tail recursion.
3. Monads. They just have a weird name, don't they? I don't really know what a Monad is: it's like asking what .NET means. But the stumbling block is not the idea that you can have 'do print 3 ; putStrLn "Hello, world!\n"' in a program and make it work, without really knowing what you are doing. You think, "okay, do notation is for actions, which are just things." But then you see it used for lists, or for nondeterministic execution, or to make parsers, or for abstract state transformation machines, or for transactional memory... There is a monad epiphany that you have to go through, and then you get it. It's a very strange pattern of abstraction.
4. Higher order functions. This one wasn't a problem for me because I already knew Scheme. Some people have had a taste for it in Scheme, or even C++. (But doing higher order programming in C++ is like dressing up a three-year old as Marilyn Manson). Most people are okay with 'map' -- it's foldl that gets them. Of course, you shouldn't use foldl. Use foldr. Why? Laziness.
5. Laziness. This one isn't so bad. It's when people use it for things like fibs@(_:fs) = 0 : 1 : zipWith (+) fibs fs that it gets you. If you're used to writing Haskell, you'll just want to curse other languages when they won't let you get away with infinite loops. And laziness isn't just good for writing infinite lists -- it's also good for say, writing parsers or anything involving infinite datastructures. (It's why writing parsers in Scheme and O'Caml is a bit more work than writing them in Haskell.)
6. Typeclasses. They're a new thing.
7. The hardest thing is the Whole New Ways Of Doing Things. You simply _don't_ use arrays. Or vectors. If you want to use an array, you should stop, think, and say, "What, am I mad?" They just aren't seen. The only time you do see them is if the data you're working on is itself array-like, such as images. Or if you're really desperate and need to use some array based algorithm. Or if you're interfacing with C. But, if you want to use them, you have to use some kind of monad. As an example, the window manager xmonad doesn't use any arrays. You'll never see hash tables, either; it's always Maps, because you can insert an element into map, creating a new one, without destroying the old one, in O(log n) time. And you never see iterators -- you can just convert your datastructure to a list and apply maps and folds. And hope the compiler will sort things out so that no list nodes actually get allocated.