• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

Best Programming first language

Do you think there is anything wrong with the C++ loops, do while, if-else statements? If not, I don't think the OP will go way beyond that. I got as far as "what a Class is" in Programming 101 in undergrad...


You are only describing constructs from imperative programming. There are also functional and declarative styles. Each is significantly more productive than the other in different contexts. Python offers exposure to a nice intersection of these different styles and that improves how the programmer thinks about a problem.

The OP knows Javascript. Javascript has a prototype-based object model rather than a class based object model. Javascript is weakly typed. Transitioning to Python, which supports duck-typing and is strongly but dynamically typed is a far easier transition than going to C++ which is statically and strongly typed.

Being able to create software and continue using it to get work done is the ultimate goal of learning to program. C++ (with header files, implementation files, linkers, loaders, complex grammar, uneven specification, etc) is too often a road to an unmaintainable mess.
 
And with that I have neither the knowledge nor the vocabulary to compete.

Therefore, I yield.

whiteflag.png
 
surpassed in productivity by people that know shell and scripting languages.

...

The task:

Read a file of text, determine the n most frequently used words, and print out a sorted list of those words along with their frequencies.

Knuth came up with a typically clever, lengthy, low-level implementation [...]. McIlroy then somewhat perversely wrote a six-line shell script that did the job, basically changing the subject away from literate programming and toward a critique of Knuth’s doing something low-level and complicated when unnecessary.

OK, I'll bite ;-)
Let me just quote the example code from the provided link first:
C++:
tr -cs A-Za-z '\n' |
tr A-Z a-z |
sort |
uniq -c |
sort -rn |
sed ${1}q

"The code is self-explanatory if you are familiar with basic Unix command-line tools." -- made me LOL :D
Note, that we're talking about the beginners here, who probably think that console window is "that old MS-DOS system"...

Here's how you do it in five lines for the workhorse part, with the code that actually *is* self-explanatory (especially if you're familiar with the basic constructs used; based on "Accelerated C++") so, hey, I've stripped the comments, too:
C++:
string word;
map<string, int> counters;
while (cin >> word) ++counters[word];
for (auto word_count : counters)
  cout << word_count->first << '\t' << word_count->second << '\n';

Note, that the "sort | ; uniq -c |; sort -rn |" part is *precisely* what I'd call "a typically clever, lengthy, low-level implementation" -- if you want to be closer to declarative (as opposed to imperative or "doing something low-level and complicated when unnecessary") programming you don't want to be thinking about all of this sorting and uniqueness and calling each of the respective functions to perform these operations manually, you much rather want to *declare* that this is what you want -- as in *declaring* that you're going to use an ordered map with unique keys (std::map).

Another piece of code from the link you've given:
C++:
import qualified System
import qualified Data.List as List
import qualified Data.Char as Char
import qualified Data.HashMap.Strict as HashMap
 
main :: IO ()
main = do
    [arg] <- System.getArgs
    text <- getContents
    let n = read arg
    putStr $ createReport n text
 
createReport :: Int -> String -> String
createReport n text =
    unlines $
    map (\(w, count) -> show count ++ " " ++ w) $
    take n $
    List.sortBy (\(w, count) (w', count') -> compare count' count) $
    HashMap.toList $
    HashMap.fromListWith (+) $
    map (\w -> (w, 1)) $
    words $
    map Char.toLower $
    map (\c -> if Char.isLetter c then c else '\n') $
    text

Apparently, the author feels this is "a simple program in Haskell that I feel is closest to McIlroy’s both in spirit and in letter."

Um... right, I guess I might as well add comments back:
C++:
#include <iostream>
#include <map>
#include <string>
 
int main()
{
  using namespace std;
  // store each word and an associated counter
  string word;
  map<string, int> counters;
  // read the input, keeping track of each word and how often we see it
  while (cin >> word) ++counters[word];
  // write the words and associated counts
  for (auto word_count : counters)
    cout << word_count->first << '\t' << word_count->second << '\n';
}

Which one is most beginner-friendly? You be the judge...

And, hey, don't get me wrong, I actually like Haskell, think shell scripting proficiency is a must for the day to day productivity, and Python makes a great first language.
This doesn't mean I have to agree with nonsensical argumentation used ;-)

While I actually think Python is a reasonable choice in general, for the more mathematically inclined (e.g., pure math, CS majors) I'd actually consider an FP language worth considering -- e.g., Scheme used to be used for many of the intro-to-programming university classes not that long ago (e.g., MIT 6.001 -- although, to be fair, I guess Python might be taking over that role there, staying with the MIT example), it has basic/minimal syntax (some would say it has no syntax at all) which doesn't obstruct from learning the core concepts, there's an excellent book series (SICP, The Little Schemer, The Seasoned Schemer, The Reasoned Schemer). Nowadays, I'd also add Haskell or F# to the list.

Learning an FP PL first might be a good thing to start the programming journey with the right frame of mind. While both Python and C++ are multi-paradigm, I think we have to be honest and admit that most "newbies" will solely use the imperative aspects thereof, making the FP seem harder to grok further along the way. OTOH, it's not that hard to learn imperative programming once you've grokked FP.
 
Learning an FP PL first might be a good thing to start the programming journey with the right frame of mind. While both Python and C++ are multi-paradigm, I think we have to be honest and admit that most "newbies" will solely use the imperative aspects thereof, making the FP seem harder to grok further along the way. OTOH, it's not that hard to learn imperative programming once you've grokked FP.

There are several axes to consider beyond syntax. Scheme is a great language but its ecosystem falls short when it comes to libraries. This was one of the primary reasons MIT switched to Python. As for your C++ example, a beginner will need to edit, compile, and link before their example works.

The real value in McIlroy's story (keep in mind that their tools were invented in a time with different technical constraints) is that it is still done the same way today. That knowledge has an incredible shelf life for technology. If a student learned those skills way back in the 80's, they can still benefit from that knowledge in a modern Linux shell.
 
OK, I'll bite ;-)
Let me just quote the example code from the provided link first:
C++:
tr -cs A-Za-z '\n' |
tr A-Z a-z |
sort |
uniq -c |
sort -rn |
sed ${1}q

"The code is self-explanatory if you are familiar with basic Unix command-line tools." -- made me LOL :D
Note, that we're talking about the beginners here, who probably think that console window is "that old MS-DOS system"...

Here's how you do it in five lines for the workhorse part, with the code that actually *is* self-explanatory (especially if you're familiar with the basic constructs used; based on "Accelerated C++") so, hey, I've stripped the comments, too:
C++:
string word;
map<string, int> counters;
while (cin >> word) ++counters[word];
for (auto word_count : counters)
  cout << word_count->first << '\t' << word_count->second << '\n';

Note, that the "sort | ; uniq -c |; sort -rn |" part is *precisely* what I'd call "a typically clever, lengthy, low-level implementation" -- if you want to be closer to declarative (as opposed to imperative or "doing something low-level and complicated when unnecessary") programming you don't want to be thinking about all of this sorting and uniqueness and calling each of the respective functions to perform these operations manually, you much rather want to *declare* that this is what you want -- as in *declaring* that you're going to use an ordered map with unique keys (std::map).

Another piece of code from the link you've given:
C++:
import qualified System
import qualified Data.List as List
import qualified Data.Char as Char
import qualified Data.HashMap.Strict as HashMap
 
main :: IO ()
main = do
    [arg] <- System.getArgs
    text <- getContents
    let n = read arg
    putStr $ createReport n text
 
createReport :: Int -> String -> String
createReport n text =
    unlines $
    map (\(w, count) -> show count ++ " " ++ w) $
    take n $
    List.sortBy (\(w, count) (w', count') -> compare count' count) $
    HashMap.toList $
    HashMap.fromListWith (+) $
    map (\w -> (w, 1)) $
    words $
    map Char.toLower $
    map (\c -> if Char.isLetter c then c else '\n') $
    text

Apparently, the author feels this is "a simple program in Haskell that I feel is closest to McIlroy’s both in spirit and in letter."

Um... right, I guess I might as well add comments back:
C++:
#include <iostream>
#include <map>
#include <string>
 
int main()
{
  using namespace std;
  // store each word and an associated counter
  string word;
  map<string, int> counters;
  // read the input, keeping track of each word and how often we see it
  while (cin >> word) ++counters[word];
  // write the words and associated counts
  for (auto word_count : counters)
    cout << word_count->first << '\t' << word_count->second << '\n';
}

Which one is most beginner-friendly? You be the judge...

And, hey, don't get me wrong, I actually like Haskell, think shell scripting proficiency is a must for the day to day productivity, and Python makes a great first language.
This doesn't mean I have to agree with nonsensical argumentation used ;-)

While I actually Python is a reasonable choice in general, for the more mathematically inclined (e.g., pure math, CS majors) I'd actually consider an FP language worth considering -- e.g., Scheme used to be used for many of the intro-to-programming university classes not that long ago (e.g., MIT 6.001 -- although, to be fair, I guess Python might be taking over that role there, staying with the MIT example), it has basic/minimal syntax (some would say it has no syntax at all) which doesn't obstruct from learning the core concepts, there's an excellent book series (SICP, The Little Schemer, The Seasoned Schemer, The Reasoned Schemer). Nowadays, I'd also add Haskell or F# to the list.

Learning an FP PL first might be a good thing to start the programming journey with the right frame of mind. While both Python and C++ are multi-paradigm, I think we have to be honest and admit that most "newbies" will solely use the imperative aspects thereof, making the FP seem harder to grok further along the way. OTOH, it's not that hard to learn imperative programming once you've grokked FP.

A beginner might ask, what is this #include <iostream> etc.? What is int main()? What are those {} for? None of which have satisfactory answers to a beginner. The general technique is - forget about them until later.

With Python you could do away with all that. I agree though that the example code is poor. I absolutely detest codes that use unix inbuilt binaries for more than one or two commands because they are so obscure even when you have a rough idea what they do.
 
nkabir

Sure, but once you've moved on to external libs/ecosystem part you're arguably an intermediate programmer, not a beginner anymore. Before that happens, I still think that it's a good idea to learn the core concepts first -- and starting with FP has certain advantages here.

As for running the programs -- granted, however, some minimal time investment is always required, no matter the PL, e.g., take a look at http://docs.python.org/faq/windows.html
Not that I think it's an insurmountable challenge. Conceptually, "compile+link+run" (I doubt any beginner would do all these steps separately, perhaps it'd be more appropriate to say "build+run") or "interpret+run" are both single steps -- and, as soon as we're dealing with a source code stored in a file, one has to learn either one. Where I think both Scheme and Python (and any other PL with an interactive REPL) are great is that you can tinker with the basic constructs and play with them with simple, toy experiments (while I think Cling is awesome -- see http://blog.coldflake.com/posts/2012-08-09-On-the-fly-C++.html & http://solarianprogrammer.com/2012/08/14/cling-cpp-11-interpreter/ -- it's a relatively recent development and still needs some time to mature, right now it remains to be seen how much adoption will it see "in the wild").

BTW, there are also some online REPLs supporting Scheme:
http://repl.it/
http://colabv6.dan.co.jp/lleval.html

That being said, I absolutely love the Online Python Tutor you've linked to, pretty awesome illustrations! :)

Barny

Well, if you want to use, say, collections you've got to import, too -- and whether you use curly braces or significant spaces, you still have to explain either concept to a beginner, right? (And you can cover all of this in the first week lecture.) But, again, I don't think we're arguing here, since I was mostly illustrating what you've also mentioned (the presented code samples weren't supportive of the argument(s) being made).
 
Although cryptic to new students, the shell is worth learning well.

...

Over a period from 1970 to 1972, McIlroy suggested proposal after proposal. He recalls the break-through day: "Then one day, I came up with a syntax for the shell that went along with the piping, and Ken said, I'm gonna do it. He was tired of hearing all this stuff." Thompson didn't do exactly what McIlroy had proposed for the pipe system call, but "invented a slightly better one. That finally got changed once more to what we have today. He put pipes into Unix." Thompson also had to change most of the programs, because up until that time, they couldn't take standard input. There wasn't really a need; they all had file arguments. "GREP had a file argument, CAT had a file argument."

The next morning, "we had this orgy of `one liners.' Everybody had a one liner. Look at this, look at that. ...Everybody started putting forth the UNIX philosophy. Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams, because that is a universal interface." Those ideas which add up to the tool approach, were there in some unformed way before pipes, but they really came together afterwards. Pipes became the catalyst for this UNIX philosophy. "The tool thing has turned out to be actually successful. With pipes, many programs could work together, and they could work together at a distance."

...

http://www.princeton.edu/~hos/frs122/precis/mcilroy.htm

It provides easy access to *nix services and complements Python well. But avoid writing shell scripts that are longer than a page.
 

I always pine when I see these language wars :D What are you suggesting?

Maybe Google is not approaching C++ in the way it should be approached. If you do it right and are careful ;) then it is fine as many C++ developers will testify to.

Go will never catch on IMO. BTW do you have something beyond 'Hallo World' in Go? E.g. take a Monte Carlo option pricer.

Don't blame the tools. Basically, just learn the fundamentals properly and avoid 'nice to have' features.
 
Why not?



Other than not having pointers, what are they missing? And what is so scary about Python?

Go is not mainstream and not ISO AFAIK (btw I never heard of it till recently). If it does catch on, hurry up because it takes 15 years to reach critical mass.

They said that Pl/I was the best in 1971.

We don't want to give new developers a false sense of security by dumbing down programming. First learn C. It's like learning how to break fall in judo.

Almost forgot: For good or bad, C++ is seen as the blue-chip language in this industry.
 
Wow!
Maybe Google is not approaching C++ in the way it should be approached. If you do it right then it is fine as many fine C++ developers will state.
If you're implying the people at Google can't get their heads around C++, I think you've nailed the problem with C++ better than I can. ;)

Go will never catch on IMO.
That's what the C++ folks said about Java. The point of the comment wasn't that Go would take over the world.
 
Go is not mainstream and not ISO AFAIK (btw I never heard of it till recently). If it does catch on, hurry up because it takes 15 years to reach critical mass.

Sure. Fair comment. But you did say, "will never catch on."

We don't want to give new developers a false sense of security by dumbing down programming. First learn C. It's like learning how to break fall in judo.

Again, this is an assertion without an argument to back it up. Other than pointers, what is so difficult about C vis-a-vis Python? This outlook just seems, well, a trifle dogmatic.
 
If you're implying the people at Google can't get their heads around C++, I think you've nailed the problem with C++ better than I can. ;)
No, this is a non-sequitor. The problem is independent of the organisation. It's a skills and experience problem.
But the Google development environment is completely different from computational finance. Then maybe Go and Python is better. Do you know IB development environments?

BTW it is extremely difficult to find good, experienced C++ developers. So, putting a rookie in a C++ project and expecting miracles will present major challenges (disclaimer: I started with C++ in 1988).
 
Sure. Fair comment. But you did say, "will never catch on."



Again, this is an assertion without an argument to back it up. Other than pointers, what is so difficult about C vis-a-vis Python? This outlook just seems, well, a trifle dogmatic.

How long did it take for post-it it to catch on Or even home computing?


Based on my old-timer background one does tend to get ideas based on historical evidence. Others might call it dogmatic, indeed. There again, what do I know:D
 
BTW it is extremely difficult to find good, experienced C++ developers. So, puttig a rookie in a C++ project will present major challenges (disclaimer: I started with C++ in 1988).

C++ has been around since 1985. Again, you're illustrating the shortcomings with C++ better than me.
 
BTW it is extremely difficult to find good, experienced C++ developers. So, putting a rookie in a C++ project and expecting miracles will present major challenges (disclaimer: I started with C++ in 1988).
This is reaallllyyy ironic because I hear this objection (and have myself thought about it) as a reason to not use a more productive but less common language like q/Haskell/Common Lisp etc. Developers for these languages are much harder to come by whereas C++ and Java guys are a commodity.

I understand you're probably talking about ground up development whereas the commodity aspect comes in mostly for maintenance, but the experience issue is relevant for maintenance as well.

Python sits in a nice local minima. You can get a lot of useful stuff done in it, and so it serves as a good structured intro to the idea of using a computer to automate tasks. Shell scripting is more probably more time efficient for simple things, but then there's no CS taught.

C++ will make you tear your hair out to do relatively simple things. I've written random small Python scripts to accomplish mundane tasks like deduping files or picking files at random. It would be so much work in C++ that it'd probably be faster to do these things by hand.

The Lisps have nice features, the main objection I can see is that they have a "weird syntax" for a beginner (until you learn the advantages of coding in AST with eg macros).

Haskell has a really high learning curve (Monads....).

ML could be nice as a first language, actually. Powerful, reasonably performant, not hard to do simple things. "Normal" syntax.

Once you get the idea of automation and medium level programming with Python, then you can dive into both the low level view (assembly, C) and high level (FP, DSL etc).

For the record, I started with SICP and Scheme and totally missed the point because I had no previous programming experience. It took the pain of C++ and the revelation of q to appreciate the concepts in the book. And only after extensive reading did the light bulb turn on for the magic of macros and code as data/direct AST coding.
 
C++ has been around since 1985. Again, you're illustrating the shortcomings with C++ better than me.

Nope. This is a non-sequitor. That's not the problem. It's one facet of a dumbing down process that has been going in for some years new. Just like it is difficult to find mathematicians in Europe.

BTW do you know computational finance challenges? I feel that conclusions are being extrapolated from one domain to others..

The real cruelty in education is the dumbing down of CS education.

Still, C++ is still the focal point of conversation, so it must be doing something good.

For the desktop, C# is very user-friendly.


The discussion is a bit one-sided I must say. At management and organisational level different considerations kick in.
 
Back
Top