I am honestly pretty impressed. Actually, it left three impressions:
1. This guy is technically good (though it says nothing about how he'd cope in a team environment, how he works with clients etc). 2. This guy had 30 spare days, and I am extremely jealous of this. 3. This proves that office suites aren't rocket science.
So on top of the limited functionality mentioned it is going to be about 10 times heavier than anything written in C and 10 times slower. It will also breath fire and eat your children.
So you're saying it will be compatible with Microsoft Office, then?
Gerard Weinberg's book The Psychology of Computer Programming should be required reading.
The background to this story is that a late and over-budget software project is on the verge of being cancelled due to it being an over-complex solution. Yes, this happened even in the days of punched cards.
The hero came up with a simpler solution, and is presenting it to the members of the project team. The team lead reacts:
"And how long does your program take?" he asked--emphasizing the possessive.
"That varies with the input," was the reply, "but on average, about ten seconds per card."
"Aha," was the triumphant reply. "But my program takes only one second per card."
The members of the audience--who had, after all, all contributed to the one-second version--seemed relieved. But our hero, who was rather young and naive, was not put down by this remark. Instead, he calmly observed, "But your program doesn't work. If the program doesn't have to work, I can write one that takes one millisecond per card--and that's faster than our card reader."
A user-space process on a modern operating system is running on a virtual machine. The OS provides an abstraction of the underlying hardware. That's why you can write your code as if you have a CPU all to yourself, even though there are usually fewer physical CPUs than processes.
...and your program would be quicker if you implemented it in raw silicon, but it's more cost-effective to implement it on commodity hardware.
If you're on IA32 or x86-64, by the way, that commodity hardware provides the illusion of a CISC instruction set implemented by a RISC core. Turtles all the way down, I tell you.
The C language standard (we'll ignore the standard libraries) specifies a virtual machine. That machine is implemented on physical hardware by the combination of the compiler and some run-time support code. In the case of C, that amount of run-time support code is typically very small, and it basically only covers startup, shutdown and stubs for any virtual instructions which the CPU doesn't support natively.
(That last point, by the way is something that people who only use modern medium-to-high-end CPUs don't always appreciate. Today you almost always implement everything that C needs in the form of native instructions, but this isn't always the case and hasn't always been the case as anyone who needed to do a 32-bit division on a 80286 or an older SPARC can tell you.)
I don't know. All I remember from the expensive five-day training session is that you're supposed to sit at the same keyboard as someone else, and that you stop coding and genuflect when a Scrum Master enters the room.
I've been using Haskell for 20 years, and have written my own Hindley-Milner type inference systems. Believe me, I know this stuff.
What you may have missed is that I was talking in the context of a scripting layer for a larger system, which it seems clear from the writeup is an intended use for Dao. We're talking about Python or JavaScript rather than.NET or JVM.
Some reasonable assumptions of a scripting layer are:
Scripts are shipped as source code and compiled at load time.
Scripts are typically small compared to the system that they are scripting.
Script load time must be as fast as possible.
The memory footprint of the system as a whole must be as small as possible.
Most of the time will not be spent executing scripts, but executing libraries or application subsystems called by scripts.
In a typical scripting system, execution speed is important, but not as important as keeping the load time and memory footprint low. It's difficult to see how Hindley-Milner type inference would be the right tradeoff in such an environment, at least most of the time.
Incidentally, don't forget the memory used by type inference, which can often rival that of the size of the AST of the program. (It's a reliable rule of thumb that in intuitionistic logic, the size of the proof and the size of the theorem which it proves differ by about a constant factor, and under the Curry-Howard correspondence, program is to type as proof is to theorem.)
The memory cost is well worth paying in an optimising compiler, since you're going to pay it one way or another. After all, modern optimising compilers, use theorem provers to verify the preconditions for performing optimisations. But it's not necessarily a price you want to pay in a scripting layer.
There are plenty of examples of virtual machines where the instruction sets of the virtual machine and of the physical machine are identical, and VM instruction execution is handled by executing instructions on the physical machine. VMWare-like virtualisation is one example, but an even more common example is an application in a modern operating system. The OS provides the illusion that the application has a CPU all to itself, and a flat address space.
I can only assume you have not done any embedded coding.
Not very much, admittedly; only two years paid work on 8-bit microcontrollers. I'm sure you have more and wider professional experience in the area than I do.
However, I came from a background in compilers, so the source file of the "simple assembler that starts at the reset vector" that I had to write was named crt0.s.
Not every C program needs every part of the standard C runtime, but I'd wager that every C program in existence needs the stack (which is why I keep talking about it). So the key question you need to ask is: Who sets up the stack?
If it's the operating system (there are "linkable" operating systems, and operating systems which ), then the OS implements the runtime. If it's a piece of assembly code which then transfers control to C, then that is the runtime. If it's C code, then the runtime is (at least partly) implemented in C.
Of course, if your code doesn't use a stack, then you're extremely clever, but you're not talking about "most firmware".
Incidentally, I don't believe there is such a thing as "most firmware"; what's in a BIOS is very different from what's in a bluetooth mouse which is very different from what's in a pacemaker. Nonetheless, to a first approximation, every high-level language needs a stack. Asking who sets up the stack usually answers the question of where you'll find the runtime.
Unless the CPU transferred control directly to C code at boot time, without passing through any lower-level initialisation first, then it had a runtime.
But even that is no guarantee. Some implementations of C provide enough support for low-level hackery that they allow you (or the vendor) to write the runtime in C itself, including setting up the stack pointer. I've certainly done that before. It's possible, but it's rare.
It seems that way because on a typical platform the C virtual machine is a very thin layer on top of the operating system and CPU. Its implementation is almost all initialisation and shutdown, and even then there's usually very little to do.
If you don't believe me, I suggest you try it. Even if you don't use the standard entry point (avoiding the need to process argc/argc/envp) or exit point (avoiding the need for atexit), at the very least you'll need to set up a stack before you transfer control to C code for the first time. That is initialising a virtual machine.
Strict typing a la Algol requires you to write more code (in the form of type declarations). Strict typic a la ML requires someone to write more compiler, which isn't a problem if you're shipping compiled code, but in a typical scripting scenario it requires there to be more compiler in your runtime and (more importantly) slows load time.
Dynamic/optional typing requires you to write more tests (unless you want less robust code, of course), but tests typically don't impose a cost at run-time. If you only need a thin layer of scripting glue, then the tradeoff may be acceptable.
I agree that it's not "highly desirable" as a general rule, but I can see the use case.
Slashdot Mirror
I am honestly pretty impressed. Actually, it left three impressions:
1. This guy is technically good (though it says nothing about how he'd cope in a team environment, how he works with clients etc).
2. This guy had 30 spare days, and I am extremely jealous of this.
3. This proves that office suites aren't rocket science.
So you're saying it will be compatible with Microsoft Office, then?
Gerard Weinberg's book The Psychology of Computer Programming should be required reading.
The background to this story is that a late and over-budget software project is on the verge of being cancelled due to it being an over-complex solution. Yes, this happened even in the days of punched cards.
The hero came up with a simpler solution, and is presenting it to the members of the project team. The team lead reacts:
"And how long does your program take?" he asked--emphasizing the possessive.
"That varies with the input," was the reply, "but on average, about ten seconds per card."
"Aha," was the triumphant reply. "But my program takes only one second per card."
The members of the audience--who had, after all, all contributed to the one-second version--seemed relieved. But our hero, who was rather young and naive, was not put down by this remark. Instead, he calmly observed, "But your program doesn't work. If the program doesn't have to work, I can write one that takes one millisecond per card--and that's faster than our card reader."
A user-space process on a modern operating system is running on a virtual machine. The OS provides an abstraction of the underlying hardware. That's why you can write your code as if you have a CPU all to yourself, even though there are usually fewer physical CPUs than processes.
...and your program would be quicker if you implemented it in raw silicon, but it's more cost-effective to implement it on commodity hardware.
If you're on IA32 or x86-64, by the way, that commodity hardware provides the illusion of a CISC instruction set implemented by a RISC core. Turtles all the way down, I tell you.
I thought about mentioning that, but I realised that introducing the phrase "abstract machine" at this point may sound like a weasel term.
Nonetheless, since you brought it up, a virtual machine is a realised abstract machine.
I know how programming language theorists use the term. How marketeers use the term depends on what they're trying to sell you.
The C language standard (we'll ignore the standard libraries) specifies a virtual machine. That machine is implemented on physical hardware by the combination of the compiler and some run-time support code. In the case of C, that amount of run-time support code is typically very small, and it basically only covers startup, shutdown and stubs for any virtual instructions which the CPU doesn't support natively.
(That last point, by the way is something that people who only use modern medium-to-high-end CPUs don't always appreciate. Today you almost always implement everything that C needs in the form of native instructions, but this isn't always the case and hasn't always been the case as anyone who needed to do a 32-bit division on a 80286 or an older SPARC can tell you.)
I don't know. All I remember from the expensive five-day training session is that you're supposed to sit at the same keyboard as someone else, and that you stop coding and genuflect when a Scrum Master enters the room.
I've been using Haskell for 20 years, and have written my own Hindley-Milner type inference systems. Believe me, I know this stuff.
What you may have missed is that I was talking in the context of a scripting layer for a larger system, which it seems clear from the writeup is an intended use for Dao. We're talking about Python or JavaScript rather than .NET or JVM.
Some reasonable assumptions of a scripting layer are:
In a typical scripting system, execution speed is important, but not as important as keeping the load time and memory footprint low. It's difficult to see how Hindley-Milner type inference would be the right tradeoff in such an environment, at least most of the time.
Incidentally, don't forget the memory used by type inference, which can often rival that of the size of the AST of the program. (It's a reliable rule of thumb that in intuitionistic logic, the size of the proof and the size of the theorem which it proves differ by about a constant factor, and under the Curry-Howard correspondence, program is to type as proof is to theorem.)
The memory cost is well worth paying in an optimising compiler, since you're going to pay it one way or another. After all, modern optimising compilers, use theorem provers to verify the preconditions for performing optimisations. But it's not necessarily a price you want to pay in a scripting layer.
What you call "pedantic and niche", I call "more general". Each to their own, I guess.
There are plenty of examples of virtual machines where the instruction sets of the virtual machine and of the physical machine are identical, and VM instruction execution is handled by executing instructions on the physical machine. VMWare-like virtualisation is one example, but an even more common example is an application in a modern operating system. The OS provides the illusion that the application has a CPU all to itself, and a flat address space.
I suspect you might want O'Caml semantics with a more modern syntax.
I have no idea. I was speaking generally about why we need new languages even if they're never adopted for serious project.
Not very much, admittedly; only two years paid work on 8-bit microcontrollers. I'm sure you have more and wider professional experience in the area than I do.
However, I came from a background in compilers, so the source file of the "simple assembler that starts at the reset vector" that I had to write was named crt0.s.
Not every C program needs every part of the standard C runtime, but I'd wager that every C program in existence needs the stack (which is why I keep talking about it). So the key question you need to ask is: Who sets up the stack?
If it's the operating system (there are "linkable" operating systems, and operating systems which ), then the OS implements the runtime. If it's a piece of assembly code which then transfers control to C, then that is the runtime. If it's C code, then the runtime is (at least partly) implemented in C.
Of course, if your code doesn't use a stack, then you're extremely clever, but you're not talking about "most firmware".
Incidentally, I don't believe there is such a thing as "most firmware"; what's in a BIOS is very different from what's in a bluetooth mouse which is very different from what's in a pacemaker. Nonetheless, to a first approximation, every high-level language needs a stack. Asking who sets up the stack usually answers the question of where you'll find the runtime.
Unless the CPU transferred control directly to C code at boot time, without passing through any lower-level initialisation first, then it had a runtime.
But even that is no guarantee. Some implementations of C provide enough support for low-level hackery that they allow you (or the vendor) to write the runtime in C itself, including setting up the stack pointer. I've certainly done that before. It's possible, but it's rare.
It seems that way because on a typical platform the C virtual machine is a very thin layer on top of the operating system and CPU. Its implementation is almost all initialisation and shutdown, and even then there's usually very little to do.
If you don't believe me, I suggest you try it. Even if you don't use the standard entry point (avoiding the need to process argc/argc/envp) or exit point (avoiding the need for atexit), at the very least you'll need to set up a stack before you transfer control to C code for the first time. That is initialising a virtual machine.
That's called "agile".
Maybe.
Strict typing a la Algol requires you to write more code (in the form of type declarations). Strict typic a la ML requires someone to write more compiler, which isn't a problem if you're shipping compiled code, but in a typical scripting scenario it requires there to be more compiler in your runtime and (more importantly) slows load time.
Dynamic/optional typing requires you to write more tests (unless you want less robust code, of course), but tests typically don't impose a cost at run-time. If you only need a thin layer of scripting glue, then the tradeoff may be acceptable.
I agree that it's not "highly desirable" as a general rule, but I can see the use case.
I'm pretty sure that's what I said in slightly different words.
After all, it worked so well for Lars Ulrich.
Surely I'd die of insanity before my conscience kicked in. Besides, "bind shoggoth" requires an import.
No, libc is not C runtime; libc is the C standard library. The C runtime is crt.o (or crt1.o) on Unix-esque platforms, msvcrt.dll on Windows.
C is not interpreted, but it does run on a virtual machine. The C runtime is the implementation of that virtual machine.
Who are you quoting?