Favorite programming language(s)?

user rude said:
I find those general anti-C/C++ - flame wars annoying.
Click to expand...
They are ... but didn't see that on here so far? ?

I personally very much dislike C++, because I think it has some unfixable design flaws from the very beginning ... but that's a different topic.

What's left is: There's certainly a place for these "old" languages. To me personally, coding in C is even fun, I enjoy it :cool:. But just saying "C is faster" can't be generally correct, as explained above. And regarding the "memory management" topic, this is a very complex issue, a simple interface like malloc(3) definitely can't give you well-performing code for every scenario, and it's quite possible some garbage collector will outperform manual memory management significantly for some scenario (unless, of course, you go down and dirty and work on your own allocator).

What's also left: It's somewhat easy to make mistakes in C, and it's also quite likely these mistakes lead to security flaws. The risk can be reduced a lot with good design, good coding discipline, and thorough testing using suitable tools (static and dynamic analyzers). It can't be eliminated, people make mistakes. So there's a point for languages like e.g. rust trying to do "the same as C" (compile to native code with a focus on efficiency), but in a "safer" way.

Things C has on the pro side, IMHO: Simplicity, elegance, portability (there's even a compiler targeting 6502, e.g. for the C64), standardization (and with that: many implementations, starting with gcc and llvm).
 
zirias@ said:
The risk can be reduced a lot with good design, good coding discipline
Click to expand...
I am fully aware of most of all that is brought up here, for and against the one or the other language, by you, cracauer, and others, of course - that's why there are more than one language.
And I personally also would not claim C++ as my personal favorite.
And as cracauer@ also pointed out: with bad programming habits, you can produce slow code in any language - even in Assembler, of course.

But when I read threads like this one seems to start beeing another example again, I simply wanted to make a clear statement for C/C++, because they have their purposes, and if it's just that most of the existing system's code is written in them, which I felt missing in other threads I've seen so far here.

I also personally believe there a many programmers - or, to be more correct, wannabe-programmers, trying focus on one language only, hoping this will be the one you just lick and promise without any discipline, and the language does the rest.
What I learned so far is:
Forget it!
Within programming languages you always have to compromise:
The more freedom to do, the more discipline you need, the easier the programming, the less freedom.
And you have to have the knowledge about it anyway.
Nothing is going to change that.
Not even LLM.

Of course this is also another general truism.
But I'm not sure everybody is aware of that.
So I just wanted to make some kind of provoking statement instead of just having another collection of "best programming languages."
 
I'd say it's horses for courses.
C is a pretty goot take at being a portable macro assembler, C++ was even better at that - before it got a case of featureitis. Hopefully not terminal. For certain domains, other languages are better. For numerics, you need to be a really good programmer to be faster than fortran. Plain assembler is fast, and is among the fastest to produce hard to spot bugs. Fact is, you can do almost all the checks and protections those "safe" languages do in C. It was thought to be automated in C++ - before that fell to a comitee. But that takes your time, and the compiler will not know when these checks are not needed. Thus the slower code. And most of the time the programmer does not know, either. Or we would not see these buffer overruns in C/C++ code. C/C++ is a pretty good all-rounder. I would sacrifice performance for safety in some cases, but there are cases where I would spend the extra time to place checks myself and have fastest code - like device drivers. How fast my menue is constructed in the GUI, who cares?
 
Crivens said:
case of featureitis.
Click to expand...
? I didn't know that one yet.
Yeah, featuritis is a pest befall way more things than just C++.
(Currently it happens to cars.)

It's my point exactly:
One have to chose the right language for a certain purpose.
For that one has to be open.
It doesn't mean you have to like every language.
But it's also no help to blame some, and hype others.
Learning a language is one thing.
Learning to program something else.

And I simply believe it's not a good idea to blame the language(s), only,
which the most system's code is written in we have.
If one doesn't motivate people to learn C/C++ but put them off only,
one may run sooner or later into the problem that there not enough motivated programmers left maintaining the systems we have, or even to rewrite them in another language, becasue one have at least read and understand the "old" code.

Since I don't have nothing really bring on this table anymore, I'm actually out of here.
 
user rude said:
? I didn't know that one yet.

(Currently it happens to cars.)
Click to expand...
I spent 10 years in that industry, and found myself building things for cars I would deny to drive or switch off all that stuff. As with languages, it tends to make you soft and depend on these features. Only to find out the border cases where it does not work, and then someone is gonna dieeee.
 
I have been playing with Crystal recently and enjoying it. It is inspired by Ruby in terms of syntax, standard library, and testing tools. It is statically typed with type inference; and provides exhaustive type handling, case statements, and error handling. It uses UTF-8 strings, but still includes a null-terminator for compatibility with C. I suspect it will be my go-to language for simple CLI utilities.
 
zirias@ said:
The fastest code is the one using the best algorithm for the purpose. Using a simple language that compiles more and less directly to machine code won't help you with your O(2^n) algorithm.
Click to expand...
This is the common argument by classically trained Computer Scientist people. And of course you have a strong point here.

However: The Big-O-Notation – by definition – hides the constants. But constants matter: A factor of 2 can make the difference between 4 hours and 8 hours of computing time. Also, nifty algorithms are harder to implement, i.e. they are more prone to coding errors. So you always have to ask yourself: Does the complicated algorithm really pay off for the amount of data I am processing?
 
tankist02 said:
Would be interesting to see examples where "casting to/from void * is required in C++.
Click to expand...
I think the following C idiom does not compile without warnings in C++:
Code: 
int *data;
data = malloc(size * sizeof(int));

malloc returns a void*, which requires a cast in C++.
 
Holger said:
I think the following C idiom does not compile without warnings in C++:
Code: 
int *data;
data = malloc(size * sizeof(int));

malloc returns a void*, which requires a cast in C++.
Click to expand...
Because this is a C-style idiom, in C++ they use operator new which uses the right types. No need to cast. And if you insist on using malloc still no casting to void * is involved
 
I REALLY do not like the Visual Studio environment, so I don't write any more C/C++ code after Borland C went away.
The Embaracero environments are FAR too pricey so I ignore them.

I write Delphi 7 to get things done, then port over to Lazarus if I need true 64 bit code.
I have a project in mind that can really benefit from the 64-bit memory space, so Lazarus it will be.
 
tankist02 said:
Would be interesting to see examples where "casting to/from void * is required in C++.
Click to expand...
Really templates should avoid the need for a void* to be used in the first place in C++ (yes... not all C++ libraries are equal ;))

The C-style void* userdata in GUIs is probably the only place I commonly encounter it with C++ because I feel this is still better to deal with than wrapper libraries and their many issues.

bgavin said:
I REALLY do not like the Visual Studio environment, so I don't write any more C/C++ code after Borland C went away.
The Embaracero environments are FAR too pricey so I ignore them.
Click to expand...
You didn't miss much. Borland C++Builder 6 was the pinnacle! (arguably 5 was). Now they feel terribly inelegant and cheap quality.
 
tankist02 said:
Would be interesting to see examples where "casting to/from void * is required in C++.
Click to expand...
Everywhere you actually want to use it as a different (data) pointer type? ?‍♂️

Holger said:
I think the following C idiom does not compile without warnings in C++:
Code: 
int *data;
data = malloc(size * sizeof(int));

malloc returns a void*, which requires a cast in C++.
Click to expand...
Exactly. Although this is just one classic example ... when doing anything "generic" in C, you'll quickly have a lot more uses of void *.

Btw, IMHO this is better written as data = malloc(size * sizeof *data); (so you don't repeat the type, which would be another source for bad bugs when ever changing it).

tankist02 said:
Because this is a C-style idiom, in C++ they use operator new which uses the right types. No need to cast. And if you insist on using malloc still no casting to void * is involved
Click to expand...
So your argument is you don't need void * much, if at all, in C++? Sure. True for sane C++ code and as long as you don't have to interface with C code. It still doesn't change the fact that you're required to cast to/from void * in C++.
 
patmaddox said:
I have been playing with Crystal recently and enjoying it. It is inspired by Ruby in terms of syntax, standard library, and testing tools. It is statically typed with type inference; and provides exhaustive type handling, case statements, and error handling. It uses UTF-8 strings, but still includes a null-terminator for compatibility with C. I suspect it will be my go-to language for simple CLI utilities.
Click to expand...
An interesting web framework is,

Kemal - Guide

Lightning Fast, Super Simple web framework for Crystal
kemalcr.com kemalcr.com
 
> free pascal

Crivens said:
I use that, too
Click to expand...

Nobody else has been brave [foolish?] enough to say so ...

My seventh language since Fortran IV (UNSW '68), NCR-315 assembly then S/3{6,7}0 asm ($JOBS -'72) Signetics 2650 asm ('76-), Tiny Pascal (pcode VM in 2650 asm '79), Turbo Pascal ('81-), M68010 asm ($JOB '84) then fp ~'99 till present (own projects).

Apart from readonly languages along the way: COBOL patched with S/360 asm, perl, C etc (rendered into TP and fp) ...

Crivens said:
Nope. And I have reasons.
Click to expand...

Who makes better chocolate?
 
Holger said:
This is the common argument by classically trained Computer Scientist people. And of course you have a strong point here.

However: The Big-O-Notation – by definition – hides the constants. But constants matter: A factor of 2 can make the difference between 4 hours and 8 hours of computing time. Also, nifty algorithms are harder to implement, i.e. they are more prone to coding errors. So you always have to ask yourself: Does the complicated algorithm really pay off for the amount of data I am processing?
Click to expand...

Yes, low level speed matters. Especially since some languages are a factor of 100 slower than others.

And you can implement any algorithm in any Turing-complete language.
 
smithi said:
Nobody else has been brave [foolish?] enough to say so
Click to expand...
Why? We are grown adults here,bare we not? The old emacs./.vi ahem Atari./.Amiga ohrm C./. Pascal should be resolved by now, no? Horses for courses. Writing a portable GUI that works out of the box on FreeBSD/Windows/Linux/Haiku/... is pretty easy there.

smithi said:
Spot on.
Click to expand...
It is more important to have the tools to find the performance bottlenecks and attack them. It is good if your IDE/compiler/whatever can help you there. And with assembler, that can be a challenge. With a high level language, the system can help a lot.
 
This thread is still going on?
The OP question, "what is your favorite programming language"
No caveats, just "what do you like".
Lots of us old dogs simply go to C because fingers/brain is wired to #include <stdio.h> and prototypes.
But a lot depends on the "what are you doing" question. If you are creating a user interface prototype, C/C++ is not the easiest. Lots of scripting languages do that case with less effort.

Me? I kind of specialize in C/C++ for almost everything, but have enough familiarity with things like Java/Javascript/other stuff to reluctantly flip to them as needed.
 
Yep. I began life doing only micro-coding and assembly. Was dragged kicking and screaming into learning C. Whenever I try to learn another language--cause anything else is better than C I'm told--I start typing and my internal voice says, "This looks like C and I can do this better in C."

In the past, every time I needed to interface with something, there was always a C interface. Not true for any other language.

I'm only interested in Lisp and Smalltalk cause Lisp might be useful and Smalltalk is interesting. I have on my list of thing to learn: Haskell, cause it's functional programming and I think I'm into that already (the code that I write).
 
If you are interested in functional programming, F# is also interesting.
For object-oriented programming there is crystal.
I think smalltalk is dying...
 
You must log in or register to reply here.
Back
Top