winterkoninkje: shadowcrane (clean) (Default)

As some of you may know, I've been considering the design of a new programming language lately. (And for those who haven't yet heard me talking about it, I will... at great lengths... whether you want me to or not.) This has been one of the things which has kept me busy and away from blogging of late. I'm not sure how much I should ramble on about it here though.

In working through my thoughts on the language, I'm writing an essay in three parts which mainly aims to justify why I'm doing this. (Before the abundance of circumlocutions becomes overwhelming, let us call this new language "Eng".) The first part is basically a laundry list of little features or attributes that Eng — or any language — would need to thrive against the current competitors. The second covers what I deem the fundamental Laws of Language Design, and these perhaps are the crux of the piece; certainly they are the part of the essay which is most liable to be useful outside of organizing my thoughts on Eng. And the third section of the essay is intended to introduce some ideas I have which would make this new language special. But there's a problem.

See, the problem is that many of these nifty new ideas I have are profound. Perhaps not earth-shattering, but certainly interesting enough to warrant each getting an essay of their own to fully delve into explaining what they are, let alone their significance. Just to mention them in brief without exploring at least the first layer of ramifications they introduce would do them a disservice. But if I were to expound upon them, I'd end up with at least three more essays[1], at which point it's starting to look like I'm writing a book.

Granted, this is one of the things I'm considering for my masters thesis, but if I were to expand the essay into a thesis, it would need to be a lot more focused and tied to my research and experimentation. I.e. it would become more of a manual of how the language is designed, geared towards those who are interested in implementation details, rather than an off-the-cuff analysis of why the current slew of Mid-Level Languages is insufficient and how one might go about creating a new MLL to replace them all. Though, depending on the advisor, there may yet be merit in a thesis which has that as well.

I know many of you are not particularly CS inclined, though a handful are. I guess I'm curious how many of you would actually be interested in hearing me blather on about Eng? At least it's a more accessible discussion to the layman than my second potential thesis topic of implementing Optimality Theory using analogy-making as a Complex Adaptive System.

[1] The first would be on "lexical aliasing", an interesting abstraction which solves numerous seemingly-unrelated problems and which, taken to it's logical extreme, reinvents most aspects of functional programming. The second would be on the irony of creating an inherently parallel MLL since there's a conflict between what a natively parallel language should do syntactically and what a MLL should. And the third would be on "tensors" (working name), which are a generalization of scalars, arrays/vectors, 2D-arrays/matrices, etc up to arbitrary dimensions. These too are mostly a fallout of native parallelism (of the synchronous variety), but helpful because they merge what are often dealt with as separate entities and also allow scientific-level programming without introducing additional constructs.

Date: 2006-03-18 07:41 am (UTC)From: [identity profile]
This is me, raising my hand.

Date: 2006-03-18 06:36 pm (UTC)From: [identity profile]
Oh yeah, those books, before I forget again...

The first is "Discrete Structures, Logic, and Computability" by Jim Hein (2002, 2nd ed, Jones & Bartlett, ISBN 0-7637-1843-2). This book covers the theoretical side of CS from set theory, to logic, to (some) graph theory, to languages (in the mathematical sense, i.e. regexes and the like), and even some on computability and automated reasoning. For the topics it is by far the best written I've seen. Apparently Jim used this book to teach some highschoolers in a crash course and at the end of the day they still remembered what they learned. It also has a section in the front that gives course suggestions for different topics and course lengths. There's an accompanying labbook, but unless you have access to Maple and Prolog, it won't be too helpful.

For more of the hardware side of things, "Computer Systems: A Programmer's Perspective" by Bryant & O'Hallaron (2003, Prentice Hall, ISBN 0-13-034074-X) is pretty good. It covers topics like how C structures it's memory, and how negatives and real numbers are dealt with in binary, up through the internal structure of cpus, and virtual memory. Also covers library linking, exceptional control flow, measuring execution time and optimization, system i/o, signals, etc. They also give some course suggestions based on topic, though not based on timeframe/depth.

Those two books'll cover about the first two years of a BS. If you're interested in learning more about algorithms and complexity, there's a book by Levitin which is pretty good. It covers all the basic algorithms from a different perspective than most and also goes over a number of interesting data structures (B-trees, heaps,...). It doesn't have the enormous depth of other books like CLRS, but I'd say it's the best place to start before getting distracted by math.

I haven't run into any really good books on languages and compilers yet, though a fair chunk of the theory is just the practical/application side of the language and finite automata stuff you'll get in Hein's book. I'm not sure what other branches you might be interested in exploring. I'm going to be heading in the direction of languages and AI (the neural nets and complex adaptive systems variety more than master systems) so I'll let you know if I come across any really good books on those topics.

June 2017

18192021 222324


Page generated 21 Sep 2017 02:02 pm
Powered by Dreamwidth Studios