21st century calling

Why are you still coding in unsafe, primitive languages such as C and C++, both are more than 30-40 years old?
There is like zero type safety or even guarantees it works right after compiling. You could be corrupting your memory right and left and never know that as long as it compiles.

>>1
clang --help | grep "--analyze"

This post convinced me to switch to Pythong.

You know, I just...program things. The Haskell has safety, Rust has safety, Ada got plenty of safety. You know, they’re schemers. Schemers trying to control their little worlds. I’m not a schemer. I try to show the schemers how pathetic their attempts to control things really are.

>>3
In this moment i'm pythonic. Not because of phony lambdas and type classes, but because i'm enlightened by my indentation.

>>1

both are more than 30-40 years old?

Have you even heard of ML?

>>5
If indentation so bad, how come Python is so popular?

When naming the features that a 21^st century /prog/-ramming language must have to be non-obsolete, I'd list the following:

1) no null pointers (1 billion dollar mistake and an instant show-stopper), heterogenous types (aka sum-types, tagged unions) instead.

2) encourage wholemeal programming - manipulation of arrays and matrices without mentioning any indices, no manual loop variable mutation, etc.

3) closure principle everywhere - values of type A must always be composable to produce a value of the same type A, not of some "subtype" or any other type, not the A -> A -> B bullshit from OOP.

"Those who give up freedom for security deserve neither."

>>9
Enjoy reinventing GC in your every project.

dubs

>>10
If you plan your algorithms right, you don't even need dynamic memory allocation.

Of the few cases that something like GC is needed, I'll enjoy reinventing a specialised version that's actually fit for the purpose.

>>12
Try writing a tree without dynamic memory allocation.

>>13
Try looking at lzhuf.c

>>1
There's literally nothing better

that's how much computing has advanced in those years

>>14
It's horrible. For example, this is just the insertion:

static void InsertNode(int r) { /* insert to tree */
int i, p, cmp;
unsigned char *key;
unsigned c;

cmp = 1;
key = &text_buf[r];
p = N + 1 + key[0];
rson[r] = lson[r] = NIL;
match_length = 0;
for ( ; ; ) {
if (cmp >= 0) {
if (rson[p] != NIL)
p = rson[p];
else {
rson[p] = r;
dad[r] = p;
return;
}
} else {
if (lson[p] != NIL)
p = lson[p];
else {
lson[p] = r;
dad[r] = p;
return; } }
for (i = 1; i < F; i++)
if ((cmp = key[i] - text_buf[p + i]) != 0)
break;
if (i > THRESHOLD) {
if (i > match_length) {
match_position = ((r - p) & (N - 1)) - 1;
if ((match_length = i) >= F)
break; }
if (i == match_length) {
if ((c = ((r - p) & (N-1)) - 1) < (unsigned)match_position) {
match_position = c; }}}}
dad[r] = dad[p];
lson[r] = lson[p];
rson[r] = rson[p];
dad[lson[p]] = r;
dad[rson[p]] = r;
if (rson[dad[p]] == p)
rson[dad[p]] = r;
else
lson[dad[p]] = r;
dad[p] = NIL; /* remove p */}

match_position = c; }}}}
}}}}

What

>>1
I am not coding, I am programming. Don't get them mixed up.

test

>>15
Dethroning C/epples will take decades even if some magical lang fixes all problems,running faster than C.
Even with games and OSes switching from C/epples, C/epples will be improved by getting new compiler upgrades/standards and developers could switch back.
Lets say Ada suddenly got major upgrades that would put it on par with C++, do people start migrating to it? No, they'll wait for new Ada to stabilize/get implemented, benchmark it, test it, debate it etc.
It would have to be clearly superior in all aspects to switch. All talk about safety and correctness wouldn't cut. Realistically Pascal family(Ada,FreePascal,Oberon) are the only non-C languages that can evolve into a C contender in the future because they don't depend on C/C++ codebases and are simple enough to program/read/port/etc for all architectures.

http://www.youtube.com/watch?v=KlPC3O1DVcg

>>17
LISP

>>20

Ada suddenly got major upgrades that would put it on par with C++

It would need downgrades, not upgrades, for that.

Ada, SPARK, Eiffel and all those Franco-languages using DESIGN-BY-CONTRACT are shit. You only need to enforce your team to do things when some of the members are incompetent apes who shouldn't be programming in the first place. That's why FOIC is also useless shit.

Excuse me, I meant FIOC.

>>24
Bullshit. It's just that in your company, buggy and error-prone code is considered okay because you're so AGILE and TEST-DRIVEN. Programmers who care about getting stuff right actually need to enforce invariants at various interfaces, and contracts are one of the ways to do it.

>>26
No, we don't use mememethodologies because we know exactly what we're doing. A good macro-assembler, well designed algorithms, and proper documentation and comments are everything you will ever need iff you are a good programmer.

>>27
Except that good programmers would never a use macro-assembler, as it is really unproductive and unportable. Your opinion was disregarded.

>>28
But it's a macro-assembler.

>>1
Because in 22nd century, my programs will still run due backward compatibility, legacy support and portability of C runtimes.