Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Programming Shucksters

Name: Anonymous 2011-04-10 5:34

If you don't regularly program in either C or C++, you don't know shit about programming. Now, it might be true that that you do in fact program regularly in C or C++ AND still don't know shit about programming, but it's never the case that someone who rarely programs in C/C++ knows shit about programming, therefore the original statement still holds true.

Name: Anonymous 2011-04-10 5:36

>>1
Why should I program in non-Turing-complete proven-to-be-inferior languages? To make you happy?

Name: Anonymous 2011-04-10 5:40

>>2
non-Turing-complete
lies
proven-to-be-inferior languages
subjective opinion

Name: Anonymous 2011-04-10 5:42

>>3
lies
sizeof(void*) is a size_t, right?
subjective opinion
Not Turing-complete = strictly less powerful than Turing-complete languages. Even Brainfuck.

Name: Anonymous 2011-04-10 5:46

>>4

sizeof(void*) is in fact a size_t.

5.3.3 Sizeof [expr.sizeof]
6. The result of sizeof and sizeof... is a constant of type std::size_t. [ Note: std::size_t is defined in
the standard header <cstddef> (18.2). —end note ]

Not Turing-complete = strictly less powerful than Turing-complete languages. Even Brainfuck.

I don't think you understand what Turing completeness is. Both C and C++ are Turing complete.

Name: Anonymous 2011-04-10 5:49

>>5
Both C and C++ are Turing complete.
You just said that sizeof(void*) is a size_t. You're contradicting yourself now?

Name: Anonymous 2011-04-10 5:50

>>4
0/10 on your troll. If C or C++ weren't Turing complete, it would be impossible to implement a Turing complete language or compiler for such a language in C/C++. Seeing as how even the canonical Brainfuck implementation is written in C, it follows that C is also Turing complete.

Name: Anonymous 2011-04-10 5:53

>>6
What does sizeof(void*) being a size_t have anything to do with Turing completeness?

Name: Anonymous 2011-04-10 5:55

>>7
So, you're implying that not only C and C++ are Turing-complete, but that Brainfuck interpreters for computers are Turing-complete? You're saying that your computer is Turing-complete?
Where did you buy the infinite-sized storage, and a processor that can address it all?

Name: Anonymous 2011-04-10 5:57

>>8
>>9
{code sizeof(void*)} is a finite number.

Name: Anonymous 2011-04-10 5:57

>>10
*sizeof(void*)

Name: Anonymous 2011-04-10 5:58

>>9
My computer of course is not Turing complete. But C and C++ are Turing complete, as is Brainfuck.

If you're bitching about pointers having a fixed addressable limit, you obviously don't know fuck about file I/O, bank switching, virtual memory, NUMA etc. which are all valid Turing machine memory abstractions.

Thus, it holds that C/C++ are Turing complete.

Name: Anonymous 2011-04-10 6:02

>>12
My computer of course is not Turing complete.
Then your implementation of C and C++ are not Turing-complete.
you obviously don't know fuck about file I/O, bank switching, virtual memory, NUMA etc. which are all valid Turing machine memory abstractions.
Then your computer and implementation of C and C++ are Turing-complete.

Which statement is correct here?

Name: Anonymous 2011-04-10 6:05

>>13
You're putting words where I didn't put them because you're a dirty troll.

C and C++ as abstract programming languages are Turing complete.

No real-life von Neumann computer or register machine is Turing complete because no real-life computer has an infinite amount of memory.

Name: Anonymous 2011-04-10 6:07

Naturally, abstract types are often implemented in terms of type-class constrained types, i.e., an extraction functions from/to the abstract type to/from some concrete type.

Name: Anonymous 2011-04-10 6:09

>>14
Ok then, I'll with stop the ``C/C++ are not Turing-complete'' troll.

Why, in your opinion, should we use regularly C/C++?

Name: Anonymous 2011-04-10 6:09

I wonder if the universe is Turing complete, as in it has infinite size and mass, thus infinite computing potential?

Name: Anonymous 2011-04-10 6:12

>>17
Nope. The universe is finite in size.

Name: Anonymous 2011-04-10 6:16

>>16
Why, in your opinion, should we use regularly C/C++?
To counter the modern trend of software bloat and bloatware. I'm tired of running shit only to find it's a Java, .NET/Mono, Python, Scheme, Ocaml, etc. program and it eats up 1GB of memory and takes 30 seconds to run, for something that should be instantaneous and have a much smaller memory footprint.

Name: Anonymous 2011-04-10 6:21

>>18
Nope. The [u]observable[/u] universe is finite in size (13.4 billion light years in radius). The actual universe is known to be much bigger than that, in fact, it's at least some 50 billion light years in radius, because we can see that galaxies near the edge observable universe are traveling away at red-shifts that indicate that space is expanding faster than the speed of light. Furthermore, it's quite possible that that universe is much bigger than that, it's just that light hasn't had time to propagate from beyond the universe's event horizon.

Name: Anonymous 2011-04-10 6:23

Sorry, I meant:

``light hasn't had time to propagate from beyond our Hubble volume's event horizon.''

Name: Anonymous 2011-04-10 6:23

>>19
You know that if the kernel took care of garbage collection, it would ensure that pages in a process' small heap (assuming a generational GC) would never get swapped (that, most of the time, is the reason of the poor performance of GCed languages).
Lisp compilers are fairly good at optimizing, and their GCs are pretty fast.
You can't really say that Ocaml is slow, since its only purpose is to be a fast ``functional'' language.
Java is notoriously a slow memory hog, mono is a known failure, Python is Python, and there are too many Scheme compilers/interpreters to say ``Scheme is slow''.

If we were to microoptimize speed and memory footprint, why don't we just program in assembly?

Name: Anonymous 2011-04-10 6:26

>>20
Jewish evil mathematicians set theory infinity etc.

Name: Anonymous 2011-04-10 6:28

>>22
Because various assembly languages aren't hardware-agnostic abstractions. C and C++ manage complexity much better, although not as well as higher-level languages of course. They offer a suitable middle-ground.

Name: Anonymous 2011-04-10 6:33

>>20,21
Actually, now that I think about it, I can most definitely say for certain that our universe is not Turing complete. Even if it had infinite space and mass, and given infinite time, the rate of acceleration of expansion is such that no region of space in the universe will remain casually connected to every other space. Disconnected pockets of matter will have zero influence on other pockets--for all intents and purposes, an observer within a given pocket of mass will assume that their pocket is all their is in the universe and they will be correct to assume so.

Name: Anonymous 2011-04-10 6:34

>>24
Nothing prevents you from using assembler macros. You'll get the best of both worlds.

Name: Anonymous 2011-04-10 6:35

>25
casually
I meant ``causally.''

Name: Anonymous 2011-04-10 6:36

>>26
Macros don't solve the problem of offering portable abstractions like higher-level languages.

Name: Anonymous 2011-04-10 6:41

>>28
Are you sure? If your assembler provides macros like ``__has_mmx'', ``__has_sse'', you can compile to architecture-specific, fast code.
If it provides ``__WIN32'', ``__UNIX'', etc, you can compile platform-specific code.

Do you mean closures? Anonymous functions? Classes? They are not needed, they just make overhead.

Name: Anonymous 2011-04-10 6:44

>>29
Well, hardware specific ABIs, register management, etc. Macros don't handle that. You still have to implement all of your macros for each target platform. Furthermore, it assumes you're using the same assembler front-end for all of your target platforms, which isn't always possible.

Name: Anonymous 2011-04-10 6:49

>>30
Furthermore, it assumes you're using the same assembler front-end for all of your target platforms, which isn't always possible.
C/C++ code is hardly ever portable between architectures.

Name: Anonymous 2011-04-10 6:52

>>31
I beg to differ. C/C++ is largely portable, with only a small fraction needing to be rewritten, if properly separated and hidden behind an abstraction layer. It's much much less work than if you were to use assembly language. Orders of a magnitude difference in man-hours required.

Name: Anonymous 2011-04-10 6:57

>>32
If you care about abstraction and portability, you should use an high level programming language. We were talking about speed, but computers are fast enough to permit ````slower'''' languages (not as slow as you think) to be used without feeling the SLOW AS FUCK, except maybe for Ruby.
Abstraction and portability are the last adjectives I'd use to describe C++ and C.

Name: >>33 2011-04-10 7:02

If you really cared about ABSTRACTION, PORTABILITY (to a certain extent), CONTROL OVER MACHINE (retaining portability thanks to abstract code), SPEED and not assembly, however, you'd use FORTH instead of C/C++, which is a much better low-level language than them.

Name: Anonymous 2011-04-10 7:23

>>34
TOO BAD FORTH IS SIMPLE AS FUCK

Name: Anonymous 2011-04-10 7:30

>>35
Yes, that's why it's better.

Name: Anonymous 2011-04-10 8:23

>>19
To counter the modern trend of software bloat and bloatware. I'm tired of running shit only to find it's [...] Scheme

Yeah I hate when that happens to me too, Scheme is everywhere these days.

Name: Anonymous 2011-04-10 9:51

>>37
lol u just mad bcuz ur toy langugage is not liek scheme u mad? guess wat ur laguage is writen in? thats rite scheme lol u fail

Name: Anonymous 2011-04-10 10:21

http://img706.imageshack.us/img706/2189/1224707819435.jpg

Name: Anonymous 2013-03-18 18:58

[b][i]ALGOL[/i][/b]
Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -