Favorite programming language(s)?

Space Banana

Space Banana

I use Scala the most. I like functional programming and I like to make good use of the JVM's platform-agnostic nature.
I also like Ruby, and it's a much saner alternative to Python, but I prefer statically typed languages.
I used many other languages before, but I prefer these 2 and avoid switching languages too much.
 
forums.freebsd.org

Favorite programming language

This question was asked on another forum, but since there is more activity here I thought it would be interesting to see responses to favorite programming languages. My favorites are classic Rexx and NetRexx. Classic Rexx because it has the simplicity of Basic and the power of PL/1...
forums.freebsd.org forums.freebsd.org

Let's not repeat this reddit-like question all over again.
 
For stuff I code in my spare time for fun, I keep coming back to C all the time, I still like its simplicity and elegance. All it offers at the language level is basically types, data structures, pointers and a "procedural paradigm" for evaluating expressions and calling functions, but you can build almost whatever you like on top of that.

Just as an example, for my latest project I wanted/needed a "stream" abstraction with a decorator pattern usable in an "almost fluent" way, and here's how I construct and use a stream with a write buffer (which is a completely separate aspect) now:
C: 
    Stream *out = Stream_createStandard(SST_STDOUT);
    out = BufferedWriter_create(out, 10*1024);
    printusage(out, prgname);
    Stream_puts(out, DOS2ANSI_HELP);
    Stream_destroy(out);

What's indeed hard to map to C is ("advanced") functional concepts. But of course you can work with immutable objects and functions transforming them ....
 
zirias@ said:
But of course you can work with immutable objects and functions transforming them ....
Click to expand...
I've seen people use a coding standard of "pass everything as a void* and cast inside the function because it avoids compiler warnings". Yeah, pain in the butt to debug but hey, debugging is easier than fixing compiler warnings, no?
 
mer said:
I've seen people use a coding standard of "pass everything as a void* and cast inside the function because it avoids compiler warnings". Yeah, pain in the butt to debug but hey, debugging is easier than fixing compiler warnings, no?
Click to expand...
Have you ever seen the office equivalent of a blanket party?
 
mer said:
I've seen people use a coding standard of "pass everything as a void* and cast inside the function because it avoids compiler warnings".
Click to expand...
Casting to/from void * is IMHO a bad code smell in C (although required in C++). In C, it explicitly is a "generic pointer type" which doesn't need any cast. Explicit casts sprinkled all over the codebase just increase the risk of hiding potentially important warnings.

That said, of course as soon as you need void *, all static type checking goes down the drain. I typically use it for generic container types (together with a "destruction" function pointer), there's no really sane alternative. I didn't say C was perfect 😉 -- it certainly requires strict discipline while coding.
 
  • Like
Reactions: mer
I've played with Swift for a few months last year and I found it to be a fun and clean language. It felt like it struck a good balance of C and Python IMO. Contemplated writing a UI toolkit for FreeBSD in it (in part because Apples stingy a**es won't open source SwiftUI) but that's biting off more than I can chew at the moment.
 
Every couple of weeks here is some kind of "which programming language is best/should be used only."
After a certain point the flaming against C/C++ starts, with all the very true, and proper arguments against them there are.
But besides the fact that there is no such thing as an all-purpose-language best usable for everything, so one always have to chose a language suiting the current purpose best,
I simply miss in every discussion someone stands up for C/C++

Almost all code of this system is written in them.
Unregarding all disadvantages those bring, you cannot win new people to get involved in projects as programmers like FreeBSD if you blame those only - as long as nobody rewrites the code within another language. Who's going to do that, btw? And it will for sure not solve all problems, but instead bring other/new ones -
such as the one I miss most I hoped one of the pros should have had remarked:
speed.

In IMHO speed is no minor point can be ignored when talking programming.

Fact is, Assembler, C, and C++ produces the fastest code there is - in that order.

Depending on which benchmark you're looking at - what's done to compare the speed -
also D, and Rust are almost even - in other benchmarks however they're not.
But in every test I saw Assembler, C, and C++ are always the fastest.
Most of the times with a significant distance to all others.
Next fast languages are at least two times slower, mostly way slower.
Scripting and interpreters are the slowest ones. Of course. They were not ment to be fast, but bring advantages for some total other kind of purposes.

I agree, all the arguments against Assembler, C, and C++, and for other languages are true, and for sure needed to to be thought of.
But if you talk programming in general you cannot ignore speed.
I want to see you whining when your system slows down to 50% speed, or even slower.
And when someone talking to you bringing all the arguments: ".... but memory safety, better to read, more elegant to program,..." you will just say: "I don't give a...my system just became fokkin' slow!!"
End of argument.

Ending with a quote of Bjarne Stroustrup:
"There are only two kinds of languages:
The ones people complain about,
and the ones nobody uses."

peace out.
 
user rude said:
I simply miss in every discussion someone stands up for C/C++
Click to expand...
Guess you didn't see my post? 🤷‍♂️

user rude said:
Fact is, Assembler, C, and C++ produces the fastest code there is - in that order.
Click to expand...
As with most generalizations, this won't hold.

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.

On a more technical level, a common performance issue with C or C++ is heap trashing/fragmentation (which is almost inevitable when you need lots of dynamically allocated objects with explicit alloc and free). There's a reason some larger C/C++ projects just mmap(2) some large chunk of address space and implement their own allocator on top of that, tailored to the behavior and needs of the application.
 
You must log in or register to reply here.
Back
Top