Are you a programming language nerd? Are you interested in compilers and interpreters? Have you always liked them, but felt apprehensive about actually implementing one yourself?
A few years ago, I had the privilege of teaching a graduate course with Mario Wolczko at the University of California, Berkeley on programming languages and compilers. In the course, we teach you how to implement a non-trivial programming language, starting with a basic abstract syntax tree interpreter, and ending with a just-in-time compiler.
I just posted our course exercises to my website, which walks you through how to implement the programming language from scratch.
Cheers,
Patrick
P.S. And if you find that you enjoy this sort of thing, consider working with us at JITX (www.jitx.com) on automating circuit board design. We designed a programming language for making circuit boards!
Yeah, we know that A.I. is an overused term nowadays. But a lot of our techniques are taken straight out of AAAI proceedings. The problem is too hard to not take advantage of the latest techniques.
For advanced designs with lots of compliance requirements, our tool isn't yet able to fully-automatically compute the final design. For these designs, the tool does the parts it can and leaves the rest to be handled by an engineer.
We have an internal scoreboard that tracks how much of each job we successfully automate, and we steadily improve our algorithms to make progress on that.
That's a sensible concept. I like the scoreboard idea.
Are you able to share any of the compliance standards you have certified your boards to? Have any of these boards been certified for sale in a consumer product?
I ask because FCC Class B radiated emissions limits (for example) are tricky to meet, and the design requirements to get there are frequently not well understood.
Our tool can be configured to source parts from specific vendors, such as Digi-Key and Mouser, etc.
We plan to replace most of the needs for prototyping. But there is still about a 3-4 day turn to get your boards back from the fab.
If you have all the parts already lying around, and a breadboard handy, then you could get a breadboard design up faster than you could with our service.
We have Wyisywig tools internally for help during placing / inspecting the board shapes / verifying package footprints etc.
How does this differ from KiCAD though? Does it just automate steps you normally would do in there? Whats the purpose of exporting to kiCAD? Ive never used kicad
Good question. Jonathan and I both from a lisp background and are used to crafting DSLs out of s-expressions (which is what we normally do).
For JITX, we're using a language called Stanza, which provides decorated s-expressions out of the box. It's basically still just s-expressions, but it looks prettier.
From experience of having to add a full blown scripting language to two large domain-specific professional GUI applications in the 90's, and at the risk of upsetting the HN LISP crowd, you should go for something with a broader appeal/base than LISP and similar languages.
LISP and languages of the same ilk are extremely powerful and esthetically pleasing for CS-minded folks, but they are also and unfortunately rather off-putting for the wast majority of technical, non-CS folks (which IUUC is your target audience).
I'd go for Python, in spite of the lack of typing: easy to integrate, massive amount of libraries, very flexible.
An at the risk of committing blasphemy, I have to mention that the EDA folks seem to have a terrible addiction to TCL, which therefore makes it something you may want to consider.
My opinion of course, the best would be to poll your target audience.
Stanza is our implementation language. If you're interested, you can check out the website www.lbstanza.org. It looks pretty similar to Python, plus it also has types!
>An at the risk of committing blasphemy, I have to mention that the EDA folks seem to have a terrible addiction to TCL, which therefore makes it something you may want to consider.
Tcl is very, very Lispy, so perhaps a Lisp is not the worst idea.
Great job giving advice, I'm sure it will be very helpful to hear from some random internet user.
Also: this is awesome! I'm a software engineer now working with hardware and built a straw man of this for myself a little while back (a sequence of python functions that generate eaglescript commands to make a PCB), but obviously it didn't even do 0.001% as much.
I checked out your site, but didn't see a way to launch the tool. How can I get access? (I'm working on a side project involving a BLE watch based around the nRF52840).
The tool is still internal for now. We're operating as a design service today, and our own engineers use the tool to produce designs quicker than other human-powered competitors.
When we were teaching an electronics design course at Berkeley, we were lucky to have a couple of desktop mills handy.
When we coupled JitPCB with the mills, we could completely sidestep the need for breadboards completely, even during prototyping. We went from code to fabbed board in half an hour.
Optional typing is the general term for such type systems. "Gradual typing" was coined originally in a paper by Jeremy Siek and refers to a specific set of axioms that must be satisfied.
Thank you for the link though. I will see how the term is used colloquially nowadays.
The PL academic community here in New England seems to use the word in fairly broad sense. (Admittedly, type theory isn't my area, and they very well may use a different term when they actually write papers.)
There seems to be a lot of variance in what people mean by gradual/optional typing.
For example, Pyret (a language I work on) has both typed and untyped semantics. In both semantics, bindings can be optionally annotated with a type, and any Pyret program can be executed with dynamic type checking, or can be first statically type checked before executing (but doing so does not remove the dynamic checks). What should this be called? The practical effect is much the same: users can gradually add type annotations.
On the other hand, it's a far simpler approach than typed racket or reticulated python. We made the conscious decision only to include language features for which we had a static type-checking story for, wrote the compiler as if there was no static type checking, and then wrote a type inferencer/checker for the language which can be optionally enabled.
Ah I have skimmed through the webpage for Pyret before. It's nice to meet you. I have some questions for you about that that I'll ask you later.
What you're describing is, I believe, one particular strategy among many with the goal of allowing users to gradually add type annotations. The goal itself is not new, and is often called optional-typing. The two words "gradual typing" specifically is also one particular strategy for optional typing but is under the ownership of Jeremy since he coined it. Informally, people do seem to use the term in a looser way.
Since there's been interest in the D-expressions paper, I wanted to add that Jonathan Bachrach (the first author on the paper) is actually my Ph.D. advisor, and we just released a new programming language a few months ago called Stanza based on similar ideas. Stanza is a spiritual successor to Dylan of sorts: it has an optional type system, coroutines, a multimethod-based object system, programmatic macros, and an s-expression-based natural syntax. You can check it out at www.lbstanza.org.
The L.B.Stanza Programming Language now has support for 64-bit Windows systems.
Stanza is a new optionally-typed general purpose programming language from U.C. Berkeley. If you're interested, see our original posting at https://news.ycombinator.com/item?id=11717561.
Are you a programming language nerd? Are you interested in compilers and interpreters? Have you always liked them, but felt apprehensive about actually implementing one yourself?
A few years ago, I had the privilege of teaching a graduate course with Mario Wolczko at the University of California, Berkeley on programming languages and compilers. In the course, we teach you how to implement a non-trivial programming language, starting with a basic abstract syntax tree interpreter, and ending with a just-in-time compiler.
I just posted our course exercises to my website, which walks you through how to implement the programming language from scratch.
Cheers, Patrick
P.S. And if you find that you enjoy this sort of thing, consider working with us at JITX (www.jitx.com) on automating circuit board design. We designed a programming language for making circuit boards!