Language that is sneaking up on me

[nitro]

What really is the difference between these languages? I'm self taught, started with machine languages and Basic. I can do scripting in any of the trading environments and that is all I need so I don't learn beyond that.

Basic taught me to do things in modular fashion, otherwise I couldn't debug something without adding more problems. I recall that there was a language that had a cult following in the '70's but unable to recall the name. It had the feature that if a module was written then said module could be added to the language as a command. That appealed to me.

I discovered early on that anything that could be flowcharted could be coded. I talked to many professional programmers and never found one that used flowcharts. That perplexes me to this day because I can't complete anything without first flowcharting it. If I start writing something without a flowchart I will hit the wall at some point and have to stop, make the flowchart, then debug the mess I created. Maybe the newer languages force the flowchart into place somehow, object orientation does that somehow?

Inspite of what you read on ET, a language with certain features makes a huge difference for 98% of all programmers, maybe all programmers. However, the language of choice is not that important the smaller the project is or the lower the realtime demands of the running program has.

For example, in High Frequency Trading, provability is extremely important since bugs can bankrupt a business. So functional programs (as close to pure as possible) are critical.

Expressiveness is another important aspect of a language. The smaller the equivalent two programs are, usually it is easier to understand the smaller program unless the language itself is terse. So once again, easier to understand usually means less bugs.

A language should support concurrency and parallelism in a safe expressive way. This is probably the hardest thing to get right in modern languages, and leads to all sorts of bugs, EVEN by languages that are pushed by "experts".

Finally, there is a programming style where instead of writing programs in a language, you first build a language where the problem space is very naturally expressed in this language, THEN write your program ontop of this language. These are often called DSLs in modern parlance. Some languages make this very pleasant, and they are highly desirable.

Choosing the "correct" language for a given project is not a trivial issue, but the above reasons can give a person a clearer idea as to why the way a language is constructed from the ground up can have such a huge impact on productivity and correctness.

 

[2rosy]

I hear it takes 5 to 10 years to become a good coder.

you don't have to be good to be productive. you can be productive in a few weeks.

 

[2rosy]

Inspite of what you read on ET, a language with certain features makes a huge difference for 98% of all programmers, maybe all programmers. However, the language of choice is not that important the smaller the project is or the lower the realtime demands of the running program has.

For example, in High Frequency Trading, provability is extremely important since bugs can bankrupt a business. So functional programs (as close to pure as possible) are critical.

Expressiveness is another important aspect of a language. The smaller the equivalent two programs are, usually it is easier to understand the smaller program unless the language itself is terse. So once again, easier to understand usually means less bugs.

A language should support concurrency and parallelism in a safe expressive way. This is probably the hardest thing to get right in modern languages, and leads to all sorts of bugs, EVEN by languages that are pushed by "experts".

Finally, there is a programming style where instead of writing programs in a language, you first build a language where the problem space is very naturally expressed in this language, THEN write your program ontop of this language. These are often called DSLs in modern parlance. Some languages make this very pleasant, and they are highly desirable.

Choosing the "correct" language for a given project is not a trivial issue, but the above reasons can give a person a clearer idea as to why the way a language is constructed from the ground up can have such a huge impact on productivity and correctness.

do you have a code repo somewhere? github?

 

[nitro]

do you have a code repo somewhere? github?

I have a private one.

 

[eusdaiki]

Hey nitro,

I'm fairly new to programming and have a much shorter list of languages under my belt (R, Python, Matlab, SQL and currently learning C to progress later to ++)
I use mostly python for my coding, but I spend more and more time working with SQL since a lot of the problems I face have to do with moving and accessing a lot of data quickly.

So I was a bit surprise to see that you didn't add SQL to your list... do you use a DB for your systems?

 

[nitro]

To me, knowing SQL is not optional. I only listed those languages in which we do most of our domain programming in. All of us (old timers anyway) have to do SQL regardless of the language we program in, at least unless you wrap SQL inside abstractions like ORMs like Microsofts Entity Framework etc. So yes I know enough SQL to get by in 99% of the things that matter to me.

I haven't listed all sorts of other things ("languages") that you need to know if you program for the markets, for example, FIX.

Hey nitro,

I'm fairly new to programming and have a much shorter list of languages under my belt (R, Python, Matlab, SQL and currently learning C to progress later to ++)
I use mostly python for my coding, but I spend more and more time working with SQL since a lot of the problems I face have to do with moving and accessing a lot of data quickly.

So I was a bit surprise to see that you didn't add SQL to your list... do you use a DB for your systems?

 

[eusdaiki]

To me, knowing SQL is not optional. I only listed those languages in which we do most of our domain programming in. All of us (old timers anyway) have to do SQL regardless of the language we program in, at least unless you wrap SQL inside abstractions like ORMs like Microsofts Entity Framework etc. So yes I know enough SQL to get by in 99% of the things that matter to me.

I haven't listed all sorts of other things ("languages") that you need to know if you program for the markets, for example, FIX.

Ah ok, yeah, that makes a lot of sense...

 

[sprstpd]

Check out nimrod.

 

[2rosy]

Check out nimrod.

do you use nimrod? I was just looking at that to generate javascript.

 

[sprstpd]

do you use nimrod? I was just looking at that to generate javascript.

Just dabbled with it. I wanted to try out the Aporia editor for it just to check it out but I would have to recompile the latest head of nimrod for that to work on my machine. Since I am tight on time for the moment, I have pushed that aside for now. It definitely seems like an interesting and fast language but I'm not an expert.