Wow this is a bizarre esolang.
It’s not an esolang. It has a long history of actual real production use.
Didn't Iverson win the Turing award for ALP?
Beating C with Dyalog APL
31–40 of 57 posts
Re: Beating C with Dyalog APL
#32Earlier quoted context omitted.
> that doesn't stop it being an esolang Actually it does: "An esoteric programming language (sometimes shortened to esolang) is a programming language designed to test the boundaries of computer programming language design, as a proof of concept, as software art, as a hacking interface to another language (particularly functional programming or procedural programming languages), or as a joke"
Right, and APL could not be further from the definition given that it started as a chalkboard notation for reasoning about array operations!
Right, and Lisp started as a notation in a paper with no intention of building a language. But nobody would call it an esolanguage.
How something started and what it became are orthogonal...
I'm pretty sure Jack the Ripper started as a cute baby too...
Re: Beating C with Dyalog APL
#33Earlier quoted context omitted.
Right, and APL could not be further from the definition given that it started as a chalkboard notation for reasoning about array operations!
Right, and Lisp started as a notation in a paper with no intention of building a language. But nobody would call it an esolanguage. How something started and what it became are orthogonal... I'm pretty sure Jack the Ripper started as a cute baby too...
> Lisp started as a notation in a paper with no intention of building a language
what?
Re: Beating C with Dyalog APL
#34C is a low bar. It has always been slower than Fortran. It has been slower than C++ ever since reasonable optimization was implemented. Anything not faster than C, today, is a slow language, practically by definition.
> It has been slower than C++ ever since reasonable optimization was implemented. Which compilers? Which platforms? Optimized for speed or space (because "faster" is only one dimension of optimization)? Many C / C++ compiler implementations share the same front ends, back ends and runtime libraries, so it's hard to see how the code generation for C would be much different than that of C++. (In fact, C++ will be harde…
There is no such thing as a C / C++ compiler implementation. There are C implementations, and C++ implementations that may share some components. They do not typically share optimizers, because optimization of C++ requires quite different characteristics of an optimizer than one for C -- although most of the C optimizations may be applied after the C++ ones have run.
If it is hard to see how C++ optimization would differ from C optimization, you simply aren't looking very hard.
There are many different toolchains, but with the toolchains that are commonly used, C++ programs are faster than C programs. More specifically: C++ programs are at least as fast as C programs, because a C program is a badly-coded C++ program that fails to use language constructs that would make it a better program.
Re: Beating C with Dyalog APL
#35Earlier quoted context omitted.
Right, and Lisp started as a notation in a paper with no intention of building a language. But nobody would call it an esolanguage. How something started and what it became are orthogonal... I'm pretty sure Jack the Ripper started as a cute baby too...
> Lisp started as a notation in a paper with no intention of building a language what?
Well, it has some element of truth. The S-expression notation we think of as “Lisp” originated as a contribution to recursive function theory rather than a practical programming language, even if earlier McCarthy was thinking of proceeding by adding IPL-V facilities to Fortran.
Re: Beating C with Dyalog APL
#36Earlier quoted context omitted.
Right, and Lisp started as a notation in a paper with no intention of building a language. But nobody would call it an esolanguage. How something started and what it became are orthogonal... I'm pretty sure Jack the Ripper started as a cute baby too...
> Lisp started as a notation in a paper with no intention of building a language what?
Yes. Originally it was a thought experiment. Just like mathematicians can imagine an idea and use a notation without creating a compiler.
Re: Beating C with Dyalog APL
#37Earlier quoted context omitted.
> Lisp started as a notation in a paper with no intention of building a language what?
Yes. Originally it was a thought experiment. Just like mathematicians can imagine an idea and use a notation without creating a compiler.
Sure not. McCarthy wanted to develop a list processing system for the IBM 704 in the mid 50s. He experimented with Fortran and added list processing primitives and then went on to design and implement a new language: Lisp
McCarthy early on proposed to write a compiler - actually this was one of the very very early papers:
J. McCarthy. Memo to P. M. Morse: A Proposal for a compiler. Memo CC-56, Computation Center, Massachusetts Institute of Technology, December 13, 1957, 19 pages.
http://www.softwarepreservation.org/projects/LISP/MIT/CC-56....
Re: Beating C with Dyalog APL
#38Earlier quoted context omitted.
> It has been slower than C++ ever since reasonable optimization was implemented. Which compilers? Which platforms? Optimized for speed or space (because "faster" is only one dimension of optimization)? Many C / C++ compiler implementations share the same front ends, back ends and runtime libraries, so it's hard to see how the code generation for C would be much different than that of C++. (In fact, C++ will be harde…
The one area where C++ can be a lot faster than C is in places where C uses a function pointer where C++ uses a function template. The standard example is sorting. Say you’re sorting an array of integers. Then, C’s sort has to (1) call the comparison function passed as an argument, whereas C++’s std::sort can inline the comparisons into a single instruction. (1) if the source of the function passed in is visible from…
s/The one area/One area/.
Another is where a better algorithm is available in a library than would be convenient to implement in custom form in C. C++ libraries get a lot more attention to optimization than C libraries because it pays back much more. For example, there are really excellent hash table libraries in C++ that would be unimplementable, as a reusable library, in C. C hash tables are typically hand-rolled in place.
Re: Beating C with Dyalog APL
#39Earlier quoted context omitted.
> It has been slower than C++ ever since reasonable optimization was implemented. Which compilers? Which platforms? Optimized for speed or space (because "faster" is only one dimension of optimization)? Many C / C++ compiler implementations share the same front ends, back ends and runtime libraries, so it's hard to see how the code generation for C would be much different than that of C++. (In fact, C++ will be harde…
The one area where C++ can be a lot faster than C is in places where C uses a function pointer where C++ uses a function template. The standard example is sorting. Say you’re sorting an array of integers. Then, C’s sort has to (1) call the comparison function passed as an argument, whereas C++’s std::sort can inline the comparisons into a single instruction. (1) if the source of the function passed in is visible from…
A C compiler can certainly also inline functions, as long as the definition is visible. Neither is there any guarantee that all C++ template instantiations will be inlined.
Re: Beating C with Dyalog APL
#40Earlier quoted context omitted.
The one area where C++ can be a lot faster than C is in places where C uses a function pointer where C++ uses a function template. The standard example is sorting. Say you’re sorting an array of integers. Then, C’s sort has to (1) call the comparison function passed as an argument, whereas C++’s std::sort can inline the comparisons into a single instruction. (1) if the source of the function passed in is visible from…
Right, inlines are hard to beat, and they are not part of the C standard (which is kind of mind boggling, I mean . . . honestly, what year is it?). Still, the benefit of inlines diminishes as the size of the inlined functions increases (you start paying penalties for extra cache lines full of code, and the percentage of time in function call overhead gets small in a hurry). The linker can get into the inlining game,…
What do you mean by "inlines are not part of the C standard"?
The standard talks about visible behaviour of programs, never the concrete implementation.