As you can see this is a highly contentious subject. What you naively asked (what's the best language for me) is a really good way to start a flame war with a bunch of programmers. To understand why, imagine you went to the American Kennel Club, and asked a bunch of the breeders there "What's the best dog for me?". You'd probably get a bunch of people asking for more details like "what size is your house/apartment", "how often are you home", "do you plan on using the dog for anything in particular or just as a pet", etc. as well as a handful of people arguing about "<my_favorite_breed> is better than <other_breed> because of <x>". What you've done is essentially the same thing.

Programming is a very complex field, with a lot of theory and concepts behind it. Fortunately you don't NEED to know all the theory and concepts in order to write a program, but the more you know, the better you will be able to write programs. Haskell because it has a very strong academic background tends to attract a lot of people with VERY strong backgrounds in CS theory, as well as handfuls of programmers that only know some of the theory but see a lot of potential in the language and are trying to brush up on it (like me). Unfortunately because it has such a strong academic backing a lot of the documentation available for Haskell is written for at a minimum experienced programmers, and a lot of it assumes a pretty strong CS background (E.G. any page talking about arrows), so it can be pretty rough for someone with absolutely no background in programming to get into.

Programming languages can usually be divided up into smaller groups on rather arbitrary axis, some of which are stylistic (E.G. white space vs. brace delimited blocks), and some of which are fundamental to the way programs are reasoned about and constructed (E.G. functional vs. object oriented). Each language is a unique blend of these various axis. Certain problems tend to be easier to solve along certain points on these axis, and so languages that are closer to those points will tend to be "easier" to use for that particular set of problems. That said, any programming language can, for the most part, be used to solve any problem given enough time and effort, and a programmers relative experience with a particular language goes a long way in determining how long a given task will take.

Some languages, for a variety of reasons, tend to be easier for novices to pick up. Python as others have indicated would probably be one of the best choices mentioned so far, but other options include javascript (it's ubiquitous, but learning the scope rules can be a bit tough, and there is a LOT of REALLY bad javascript code out there so pick your examples carefully), Assembly (this one is often frowned on, but understanding at its most basic exactly what a computer is doing can be a huge boost in understanding more advanced concepts), or even something like Go. Importantly, learning a language that exists at a particular point in the theory axis (functional, object oriented, procedural, logic) will make learning other languages on that same point easier, which is why a lot of people on here (Haskell is functional) are recommending other functional languages.

As for your original statement about "I am not a programmer, and have no intention of becoming one", that would be a bit like a programmer coming to you and saying "I'm not a stock and options trader and have no intention of becoming one, but can you tell me a simple way to make money on the stock market without having to learn anything about economics or finance?". By learning to use a programming language, you are in effect becoming a programmer, just not a very good one (that takes years and years of study/work to accomplish, and even then there's always someone better or more you can learn).

My recommendation is to pick a language, any language, and start experimenting. Don't worry about all the details right away, just find some tutorials and work through them until you understand how to do basic input and output, and then start working towards goals. Start simple (write a program that takes a series of numbers as input terminated with a newline, and then outputs the mean, median, and mode averages), and move on to more complex (program that reads a JSON formatted input file and outputs some sort of analysis of the data). Eventually you'll reach the point with whatever language you've chosen where you can do almost anything you want with it, and somewhere along the way you'll probably be ready to start learning/experimenting with other languages, maybe ones from completely different design paradigms.

-R. Kyle Murphy
--
Curiosity was framed, Ignorance killed the cat.


On Sun, Apr 29, 2012 at 11:08, Lyndon Maydwell <maydwell@gmail.com> wrote:
If you're interested in OS integration, it may be worth learning C# if
you're on windows. It's certainly quite amenable to 'glue', and it's
gaining more functional features all the time. Also, you have the
option of branching out to F# if you enjoy the .Net environment, but
crave a purer language.

I'd probably consider some combination of .Net and Mathematica if I
were doing trading on Windows and didn't mind paying for the software,
but it might not be a popular opinion :-)

Disclaimer -  I don't really know how trading works in practice.

On Sun, Apr 29, 2012 at 10:56 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 04/29/2012 10:28 AM, Lorenzo Bolla wrote:
>>>
>>> What's the difference? You're not passing around the actual function, in
>>> any language.
>>
>> $ python
>> Python 2.7.3 (default, Apr 14 2012, 23:17:33)
>> [GCC 4.7.0 20120407 (prerelease)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> def f():
>> ...     print 'foo'
>> ...
>>>>> def g(f):
>> ...     print 'bar'
>> ...     f()
>> ...
>>>>> g(f)
>> bar
>> foo
>>
>> Also: http://en.wikipedia.org/wiki/First-class_function#Language_support
>>
>
> You're not passing around the function, you're passing around the name
> of the function or a pointer. Python happens to know that when you write
> f(), you want to evaluate the function named f, much like when you say
> f.call() in Ruby.
>
> Ruby doesn't even have functions, only methods, so you have to entertain
> the idea that the same thing can have two different names to even have
> this discussion. Passing functions to other functions is so fundamental
> to Ruby that it's baked into the language:
>
>  irb(main):001:0> [1, 2, 3].map { |x| 2*x }
>  => [2, 4, 6]
>
> They're not called functions, but the distinction is imaginary. For an
> imperative language, the culture pretty strongly encourages you to use
> map, filter, fold etc. which are all passed functions (Procs) using the
> block syntax.
>
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners