Somehow I don't think hot chicks are crazy about programming languages or
their designers.
Err... well then, how about the fame and the fortune
Running on standard hardware, that's going to be challenging, when
programming in low-level anyway.
The class of applications where 42 will beat C is most programs that
use a lot of memory. If you use DataDraw (
http://datadraw.sf.net) to
program in C using a semi-OO style, your code typically speeds up
dramatically. It's because of better cache hit rates. If you have
typical objects in memory that are larger than a cache line, then on
an L2 cache miss, you typically load a whole line of crud you don't
need. DataDraw by default causes the cache line to be loaded with
like-properties from objects of the same type, with much higher chance
of being useful in most cases. Benchmarks have proved this out many
times.
A lot of programmers (I bet) don't even know what it means to compile to
hardware. You mean the same syntax can be used as a hardware description
language? Or that you can write any application and it can magically design
a dedicated circuit to run it instead of using a cpu?
I should be more specific here. Core 42 syntax will directly borrow a
lot from Verilog. There will be signals that communicate between
processes. It will seem very natural to HDL designers. This is the
main problem with compiling C into Verilog: there's no mechanism in C
to specify a lot about the hardware, so you have to provide extra
information as hacks in comments, and some things, like describing
pipelining, are downright frightful. I say forget that, it's time to
merge real HDL support into a good programming language.
By simply borrowing some of the best concepts from VHDL and Verilog,
42 will be both a software and hardware design language. As a side-
benefit, parallel programming is part of the language as in Intel
BLOCKs, and C++ CSP2. You can instantiate as many processes as you
like, and the event scheduler will assign them to a properly sized set
of threads, like Intel blocks. Processes communicating through
signals is similar to CSP2.
These seem contradictory aims. You want to encourage code reuse, but not
reuse of syntax?
Good point. The goal here isn't really to encourage every programmer
go write custom syntax extensions. That would confuse all his co-
workers. However, in even small teams at individual companies, there
are often specific coding challenges they face that aren't well
supported in any specific language. For example, should imaginary
numbers be supported directly with custom syntax? I think there are
hundreds of application specific areas where custom syntax would be
nice, and if doable in libraries, it doesn't hurt to support them.
If you haven't created a language before, I would say this project was a
little over-ambitious. But good luck. Especially with the hot chicks.
Thanks for the feedback. Writing any new language can be fun, but you
have to be a huge optimist. I'll keep out some hope for the hot
chicks.
I've written several compilers and interpreters, but most never got
much use. I really enjoy it, and I realize the odds of any new
language being useful to very many people is exceedingly low. My
first computer language I wrote with a friend in 1983 on an Apple-II
e, which was similar to Forth, but jsr-linked as they say. I also
wrote a Prolog interpreter which convinced me never to program in
Prolog, and a Scheme interpreter which was great fun until all our
users refused to learn Scheme and started asking me to write all their
code. The scheme interpreter had list rewriting rules that allowed
most of the pretty syntax to be defined in terms of a core Scheme
language. This greatly simplified the language while adding power. I
didn't invent that - it's fairly standard for Scheme, but still very
cool. I thought it'd be fun to try that text rewriting trick in a
higher-level language using interpreted lex/yacc rules.
In the last few years, I chimed in on the D language forum and offered
some ideas to help Walter with his language. He's done a great job,
and D is a language near the top of those that I like, but D has
terrible memory layout (similar to C++ and Java), and further trashes
speed with garbage collection and wastes memory using 64-bit
pointers. I'm a speed-freak, so I'm not satisfied. I came to realize
that we programmers have too divers needs to be satisfied with any
single language, which is one reason C has such staying power. With
user-extensions in libraries, I hope to cover a lot more. For
example, if you really want garbage collection, go ahead. Put it in a
library and keep that crap away from me. Not a fan of object-oriented
programming? Then don't import the class module.