/prog/ - Programming

I'd call you a retard because C isn't inherently fast and Python isn't simple.

Maybe something more to make this a bit less of a shitpost: C looks inherently fast to the layman for two main reasons: First of all, because a typical C program does less than a typical program in another language. In the C world, it is not at all uncommon to say "we only accept MAGIC_NUMBER items at most, you're shit out of luck if you have more" (was more common when "real unix" was still alive); of course such a program will be faster than a program that dynamically adjusts buffers to account for whatever it is fed, because it doesn't do the same thing! I'm not even going to touch on bounds checking and all that because that is well-trodden territory by now, but you should still keep it in mind as well.

Additionally, C's compiler technology is probably the most advanced of all simply because of its age and because many languages are just implemented on top of it. However, C is not even particularly close to the hardware ( https://queue.acm.org/detail.cfm?id=3212479 ) and languages like Pascal which have their own implementation can reach the speed of a C implementation while providing a much saner language.

There is also another big reason C (as a language, rather than an implementation) seems fast: While it makes sense to sacrifice some speed for say debugging features, this is extraordinarily difficult with C because it is specifically defined so that the straightforward implementation (pointer = address, whatever an address is; int = machine fixnum, whatever size that is and whatever overflow behavior it has; ...) is a legal implementation. But that comes at the cost of rather ridiculous abstract semantics that

(a) are difficult to keep up with when you stray from the obvious implementation

(b) are adhered to by basically no program anyway because it's easier to think about the obvious implementation while writing C.

As a result, slower more helpful implementations like this are not written for C, creating the impression that there is something about the language that makes it fast. Well, technically you can argue there is, but for all the wrong reasons.

>>5316

What do you mean by simple? Do you mean I can get a lot done with little code? Or I'm going to be learning assembly?

True. It's called money.

>>5316

Speed isn't a property of languages, it's a property of implementations. But tell me more, what did you have in mind?

>>5317

a lot with little code. i see simpler as having to make less decisions (ex: int size, data structure choices, ...).

>>5319

implementations are constrained by the language. for example C++ dictates the order you define member variables is the order they are layed out in memory, thus the compiler isnt allowed to optimize their layout (to minimize padding for example).

you can design a language to take control over things that you can optimize in the implementation.

>>5322

yeah, is that a problem?

I think there are programs that do this. There is software that translates python to C or C++. Then you can compile it to arch of choice then dump the assembly code and do micro-optimizations on ASM. I think if you have a program written correctly it can pretty much run inside of the CPU's registers and caches without much need of outside memory or storage. I'm not sure how to do this but I think it can be done. I was thing about this briefly while I was learning X86_64.

IDK it would be nice to have a language script kiddie easy like python, ruby or BASIC that you can dump to optimal assembly or even shellcode with some scripts.

I think this could be done. We should talk about code a little.

Python 2.7

#!/usr/bin/python
print 'hello world'

X86_64

global _start

section .text

_start:
  mov rax, 1        ; write(
  mov rdi, 1        ;   STDOUT_FILENO,
  mov rsi, msg      ;   "Hello, world!\n",
  mov rdx, msglen   ;   sizeof("Hello, world!\n")
  syscall           ; );

  mov rax, 60       ; exit(
  mov rdi, 0        ;   EXIT_SUCCESS
  syscall           ; );

section .rodata
  msg: db "Hello, world!", 10
  msglen: equ $ - msg

C++

#include<iostream>  
using namespace std; 
int main() 
{ 
    cout<<"Hello World"; 
    return 0; 
} 

Java

public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello, World");
    }
}

BASIC

Gotta love BASIC

PRINT "Hello World"

I was looking around I found this page: Hello world in 28 languages. https://excelwithbusiness.com/blog/say-hello-world-in-28-different-programming-languages/

/tech/ we should build a translation program that will translate code from one language to another like Google does with languages. Probably actually simpler since you can write most assmebly programs with just 13 or so instructions.

OP I'm not really sure what you had in mind here, but you have my attention, only for a minute because I'm busy.

>>5329

It's easy to construct an example like this, but output in many languages (especially if based on C's stdio.h) is buffered and relatively complex, so reductions to a straight syscall are not as simple in general. You'd either need a language whose features map cleanly onto the hardware/OS (which runs either the risk of being tied to a particular setup or the risk of becoming another C where the features are not very useful) or rather advanced full program optimization.

>/tech/ we should

Hey buddy, I think you've got the wrong door. The logo club is two blocks down.

>>5329

what i had in mind is different, a new language, but what you want to do is achievable with LLVM - compiling a language to LLVM IR and then from the IR to other langs (see Emscripten for example).

>>5329

Isn't syscall slower than regular int because of all the redundant register pushes?

asking for a friend.

>>5314

I'm going to call YOU a retard because python is easy as fuck, even a 12 year old can write advanced code understanding the OOP and C is much faster than most languages with an exception of C++.

>>5313

OP, it's LISP or a dialect of it.

Have a nice day.

>>5329

>using namespace std;

>>5357

>C++ is faster than C

>>5358

Why is this such a cargo cult thing in C++? Nobody sane would explicitly name the standard library for every single thing in a different language, but every C++ programmer parrots this. It makes the code utterly unreadable, especially in small examples.

i found new optimizations that C++ compilers don't do.

>>5360

>uuuuuuuuhhhhhh muh muh reaaddiabluty

yeah sure, fucking christ, you just cant type fast enough

>>5367

Did you have a stroke writing this?

Nim vs Crystal, prove me wrong

>>5368

>uhhhhhhhhhhh oh no he kno truth!!! what do nwo????

nice ad hominem fag

>>5360

Only do using namespace whatever if you are calling stuff from that library more than a few times. like if I'm writing an image processing program that uses opencv libraries im going to have a ton of things that reference opencv so i would definitely use the namespace for that. for a simple hello world program, however, it isn't necessary. If your calling cout like 3 times in the same program then yeah use using namespace;

>>5329

> all those redundant REX prefixes

>>5367

Actually programmers spend more time READING their code than writing it. So readability and clean code are really important.

>>5370

Wut?

>>5359

munging together necessarily disparate data types in algorithms that require is almost always faster in C++ than C, using C++'s static polymorphism facility (templates).

>>5315

See djb's 'Death of Optimizing Compilers' talk.

Pretty much everything is slow as fuck, 1990s tier. If you want something 'fast' you have to hand optimize ie: write your own assembly. Once upon a time these 1970s computer scientists like Dijikstra realized there should exist a high level programming language where you can hand roll compiler optimizations in the high level language, with some kind of special annotations or something. Nobody bothered to do so and so we are stuck with hand optimization in (current year).

That said new languages are coming out all the time in specialized industry, we just don't hear about them like domain specific network programming languages done in probability 'paradigm' languages where you can do annotations for compiler optimizations but they're domain specific, so unless you're into massive networking you haven't heard of them.

>>5416

domain specific languages are a meme and virtually always could have been written as a library.

the nature of computing doesn't change when you change the problem domain. all these DSLs still compile to run on the same architecture, proving there's nothing different.

Why people create them?

>>5425

In order to make use of domain specific features as matters of convenience and productivity. The theory of Turing completeness means that the functionality will be equivalent in the end. That doesn't mean that the programming effort to reach that point is equivalent.

>>5432

that's a fallacy.

as i already said same can be achieved with a library.

>>5315

>C's compiler technology is probably the most advanced of all

LOL. Fortran has been far ahead of C forever. They just finally got a major optimization into C compilers on par with Fortran and there are others.

IIRC they also got Common Lisp (CMUCL?) on par with Fortran for some numerical compilations ages ago and kept it for a little while.

No specific memory but I bet Java got up there pretty good.