Other Programming in statically and strongly typed languages

[pyret]

z

 

[kpedersen]

C in particular is a little awkward with text because it treats them as raw bytes pretty much. This is why C++ is popular with std::string and std::stringstream. Whereas shell scripting in particular treats most things as text (actually one of the main flexibilities of how UNIX "tools" work). So I imagine that there will be some slight changes you might need to make to your approach with C.

Some tips:
As you load in data, try to store it as the correct type as soon as possible. There is no point having i.e Age as a string variable anywhere.

If you do plan to work with strings a lot, then possibly make a few reusable helper functions to help conversion between i.e float and string easily.

Make the most of structures. In many cases you pass round groups of data (i.e age, name, year) and so long as they are put in that structure as a variable with the most logical type in the first place, I very rarely see places where you would need to convert them (other than to string for a console / debug output).

I understand the point of C rather than C++ but if you can be flexible, then give that a play. Unfortunately with C++ you get a lot of additional complexity along with the few valuable facilities so isn't always worth it.

You mentioned Lua as a language. I am quite fond of this but I try to approach it the other way round, and have a C program which runs Lua code (via an embedded Lua interpreter). That way you get a massive benefit of being able to integrate with native C libraries and the OS but also retain the power of string handling, safety, memory management that Lua provides. Only really worth it for larger projects though. For small scripts, C isn't really my first choice.

 

[Nicola Mingotti]

Hello pyret,

In my opinion, if you want to become more proficient with C you should focus on building something that, for a reason or another, actually requires C.

I was not writing C code for a long time, I used extensively R and Mathematica during phd, Java for Android programming, I sold a few programs in Python, created a few web app in Javascript/Node and for general purpose scripting now my love is Ruby.

Rephrasing kpedersen, C thinks in bytes. What you can easily do in e.g. Ruby with a bunch of lists, dictionaries and regexp becomes substatially more difficult in C because lists, hashs and regexp are not concept exmbedded in the C language, you need to use libraries and make your own structs to represent objects. In my opinion it is not static typing creating you the most difficulties, it is the lack of pre-packaged (very useful) abstraction layers.

If you want to improve your static typing programming maybe you should give Java a shot.

2 years ago I became interested in embedded, in particular Arduino and BeagleBone; for those things C is the master tool so I restarted to write some C code. And i had some fun.

bye
n.

 

[olli@]

I don't have any real tips or clues for you, but let me describe my own situation. Maybe this is somewhat insightful.

Until about 10 years ago, I wrote most things in either POSIX shell (actually the subset of POSIX shell supported by FreeBSD's /bin/sh) or in C. And then I decided to make myself more familiar with Python – and that changed everything. I already knew Python before (as I knew Perl, Ruby, Java and others), but hadn't done anything serious with it. But then I discovered it is actually the perfect language, at least for myself.

Python is dynamically and strongly typed. Because of its type system, friendly syntax, functional features (like list comprehensions) and extensive standard library, it is well suited for rapid prototyping. You get results very fast, much faster than when using C. Interfacing with C code is so simple, it's almost ridiculous – both embedding Python in a C program and calling C code from a Python program. For example, I have written a video processor framework in Python that handles 1080p MPEG4 video in realtime; only the core frame functions are written in C (this is like 2 % of the code). The first working version of the whole thing took me one weekend to write.

As of today, I write simple things in /bin/sh. Almost everything else I write in Python, and if there are any parts that are performance-critical, I write just those in C.