Languages a programmer should know

[wtd]

I have frequently gone on record as saying that I prefer other languages as a beginner language. Interestingly the only language I've come close to recommending in that role that happens to be on your list is Python, and even that loses out to other similar languages.

OOP is one way to potentially create clearer code, especially in the context of patching over basic flaws in existing contemporaneous imperative languages. Unfortunately, a poor/incomplete understanding, which is sadly quite common, frequently ultimately leads to code which is less clear about its purpose.

A great deal of study in both object-oriented programming and alternatives is required to fully appreciate this.

[mirhagk]

I agree that good code design requires good understanding, and I don't think people should cater to programmers with poor understanding. I think clean OOP concepts should be employed in code. People who can't understand code design and proper commenting shouldn't be making changes to any real code IMO.

The benefit to using a clear code design paradigm, and proper OOP concepts, as well as standardized commenting is that you don't even need to review code to figure out if someone actually understands what they are doing. If they can't figure out OOP design then I don't want them coding anything for me. In an open source project I think if someone makes changes that don't conform to the OOP design philosophy used, then someone else should rewrite their code, so that it matches the design, and so that someone experienced has actually taken the time to understand it so that any code that seems innocent at a glance, but that it actually evil and terrible will be more likely to be caught.

There are 2 types of programmers, copy and paste programmers who memorize and repeat, and programmers who actually understand concepts. I believe that we should only ever allow the 2nd group to have any sort of say in programming a system.

[wtd]

I have to wonder, since you keep talking up OOPP if you have any experience with functional programming.

[btiffin]

mirhagk, on libraries;

I have to fall back to where I immerse myself, which is GNU/Linux. A vast array of libraries to play with. Most based on the C ABI (application binary interface). C++ link libraries are a pain without a C++ compiler. C makes linking far simpler, and the C ABI works with just about any language that supports dynamic linkage. It's where I live, and I expect that will remain the same for the rest of my programming days (at 50, that expectation is less than two decades, but still).

Wrapping C++ with extern "C" { } isn't very hard, but it's still an extra step in the build chain. I avoid it when possible.

My proof of concept GUI experiments for OpenCOBOL are GTK based, not Qt, mainly for ease of direct linkage.

Just sayin'.

Cheers

[[Gandalf]]

btiffin, I don't understand your point. Why is "without a C++ compiler" even a factor here? From an application developer perspective, what makes dynamically linking C++ libraries so much harder than C?

[mirhagk]

@wtd actually yes I have lots of experience with functional languages, and indeed I use functional programming nearly every day. Functional programming is extremely easy to convert algorithms and processes to because functional programming just makes sense mathematically. However for large scale projects I still prefer frameworks and overall language structure to be OOP structured. Core algorithms and libraries that my larger projects use are all structured functionally, while the project itself is OOP. It would be ignorant, and stupid to think that a single paradigm would solve all situations the best, and this mix works well for me, basically just choosing functional or OOP depending on each application.

EDIT: Also I'm curious what you do recommend as a beginner language, because that is an important question my old high school is going through right now. It's currently turing grade 10, with C# in 11 and 12. The teacher would like to replace Turing with another language, but it can't be C# because grade 11 doesn't have a pre req of grade 10, so it'd be weird to have students that are new to programming with students who have a year of experience with that language. I suggested looking into python a bit, but I'm personally not a fan of the whitespace matters part of python. The other language I suggested was small basic, because it was similar to turing in a lot of aspects, but teaches visual basic which is a completely viable programming language, and isn't horrendously slow.

[btiffin]

Gandalf;

somefunc.cpp

code:

int some_func() {     // does nothing } $ g++ -shared -o useless.so some_func.cpp

So, now a gfortran developer wants to dynamically link to some_func. What's the CALL?

From a C ABI linker it's _Z9some_funcv that's pretty hard to describe without looking.

So now she needs to

code:

extern "C" {     int     my_version_of_some_func_that_I_can_link_to()     {         return some_func()     } } g++ -c wrapper_file.cpp  -luseless gfortran -o mycode mycode.f wrapper_file.o

And for me that's the pain. Encoding the function signatures in the link names (not a bad thing mind you if you are using C++ ) makes linking to C++ shared libraries just that little bit harder than straight up C.

** please note I didn't actually try the above and probably missed some -Wl,soname flag or -fpic or somesuch on the compile lines, and the useless.so would likely be recreated as fuseless.so instead of a simple object file. etc etc cma **

Cheers

[bl0ckeduser]

wtd @ Wed Sep 05, 2012 12:46 am wrote:

I have frequently gone on record as saying that I prefer other languages as a beginner language. Interestingly the only language I've come close to recommending in that role that happens to be on your list is Python, and even that loses out to other similar languages.

OOP is one way to potentially create clearer code, especially in the context of patching over basic flaws in existing contemporaneous imperative languages. Unfortunately, a poor/incomplete understanding, which is sadly quite common, frequently ultimately leads to code which is less clear about its purpose.

A great deal of study in both object-oriented programming and alternatives is required to fully appreciate this.

wtd @ Thu Sep 06, 2012 12:37 am wrote:

I have to wonder, since you keep talking up OOPP if you have any experience with functional programming.

Agreed. I'm just a hobbyist programmer, but I think it's a fallacy to say that OOP is the only path to good programming.
An elegant, well-organized program can just as well be written in procedural or functional style (don't SICP and K&R show this ?)
In any case, I think what really matters is careful planning and forethought, as well as knowledge of good style and best practices.

[mirhagk]

Well I don't think the same program looks equally good in every paradigm, but I think each paradigm has it's own strengths and weaknesses. I use functional and OOP programming for completely seperate tasks, and doing a problem suited for one paradigm in another usually is awkward and slow and prone to bugs.

It's the same thing with nearly anything in life. Capitalism and communism produce very different results, it's arguable which is better in each scenario, but it's pretty obvious (just through statistics) that it's highly unlikely one of them would apply best to ever scenario.

[[Gandalf]]

btiffin, I see. But, even in the horrifying world where you have to regularly deal with name mangling and the like I would argue it's often worth the trade. Adding a few wrappers is a small price to pay if the underlying codebase benefits from using C++.

[btiffin]

Gandalf, I'll ditto your advice to all those reading along.

Don't fear the wrapper. Easy on the brain glue. But, as stated, watch that the joy of the linked code outweighs the grief of the extra source files.

And Gandalf, OpenCOBOL speaks Falcon. It was fun.

http://www.opencobol.org/modules/newbb/viewtopic.php?topic_id=1221&forum=1&post_id=6113

You might note that I actually prefer to run nm over the .so files, snag a mangled name and try things before writing the wrapper source files.

Adding for those reading along. Don't fear one off experiments with non-portable fragile things like mangled names, but finish off properly; write the wrappers and document the tectonic changes. Then enjoy the ever growing number of highly efficient C++ shared libraries, from just about any language that supports a dynamic link loader.

Cheers

[btiffin]

Old guy rant rave;

Just to add to the general thread. From my 30 some years in, if you are good at software development, most managers will allow you to bring your toolbox to work. By toolbox, I mean favourite language, libraries, frameworks, etcetera for "non-core" tasks like data extracts and transforms, paperwork management et al. Don't expect to rewrite the main ui of the company app in Ruby shoes, but it can't hurt to ask the boss if she minds if the next side project is written with IPython (or Vala or...). The yeses may come more often than you'd expect. Then back up your talk with functional source codes and you'll get to bring in more of your coding comfort items.

From years in, it happens all the time. Sometimes with epic fail and a scapegoat**, but usually with willing coworkers and successful things.

Cheers

** [Edits - added anecdote, cause I can cause I'm old and raving]

Yeah, I can speak to that fail thing. I love REBOL, love. I chair the international user group. So, at work I pressed it into service for a small network scrape and data dispersion task. Loaded the main PostgreSQL database from supplier information. REBOL Postgres linkage worked the charm, first try, and off we went. I ensured the team that I had a FreeBSD build that would be suitable for the production boxes. Yeah, wrong. 64bit up'ed version needed 32bit compatibility layer and suckishly bad show stopping sym links from libc.so.5 to libc.so.6. So after two weeks of setting up the various feeds and happy joy joy, my enthusiasm for a technology cost the team two weeks (and four days of retrofit with a port to the more main stream Python scripts we fling). Luckily I smile with coworkers and the scapegoating was all, err mostly, in jest and not a boot to the curb. I'd do it all again in a heart beat (knowing one more thing to check off a list before talking the talk).

[mirhagk]

Hmm that seems dangerous of a manager to allow ANY language or framework. I'm all for inter project freedom with languages and frameworks, but I'd try to make sure that every language and framework is well documented and commonly used (so that there are help forums, and others to ensure there won't be tons of show stopping bugs).

It might be fine for you to write your next project in Erlang, but if the next software developer to come along needs to learn an entirely new paradigm to understand your code just to fix that one little error you made (which is impossible to avoid) they may end up not bothering to fully learn it, and end up mucking up the program beyond repair.

[2goto1]

I agree less with btiffin and more with mirhagk on that tangent. There is some wiggle room to allow toolkit choice within a development team. I have two rules of thumb that I like my teams to follow:

1. If you get run over by a bus ensure that your deliverables are easy for the rest of your team to understand and to productively continue versus re-writing from scratch

2. If there is even the remotest possibility of re-use (ETL scripts included), the team should deliver using team standardized tools, languages, and coding practices. The deliverable once archived and documented has a higher possibility of re-use.

This can pigeonhole one into using their own personally favoured languages for just the most trivial of tasks, but it is in the best interests of your team. Client, company, team, me in that order when you're not the one paying your own salary.

[mirhagk]

Yeah the freedom I see that programmmers have is more along the lines of "I don't like this GUI framework, there's this more documented alternative that I'm going to use" and less of "I don't like C#, I'm going to use Prolog".