other approaches to software engineering

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

other approaches to software engineering

ouverson
This post was updated on .
I can appreciate (at some level) the virtual machine "write once, run everywhere" approach to software engineering.

I'm curious about are the other approaches to software engineering.

I suppose a proper answer would take the form of a book or 2 (or 20!)

I'm only looking to get a handle on high-level architectural approaches.

Reply | Threaded
Open this post in threaded view
|

Re: other approaches to software engineering

WBahn
Administrator
The notion of the virtual machine isn't just "write once, run everywhere". In fact, as the VM is done in this project, it is not done in that sense.

The "write once, run everywhere" notion is more applicable to languages like Java, .NET, and Python where your code is compiled to the VM language and then it is run on a piece of software that implements the VM on your machine. Then you can take that exact same file with the compiled code and run it on some other completely different machine as long as that machine has a piece of software on it that implements the VM on that machine.

The VM in this project is not that way. It is an purely abstract construct that serves as a bridge between the compiler and the end code. Most traditional high level languages use this construct in their compilers. With this approach, if you wanted to run your Jack program on another machine, you would have to recompile it using a compiler that targets that machine's architecture.

As for software engineering, that generally applies to code development practices at a much higher level and is generally independent of any of the specifics of the programming language or hardware architecture involved. The emphasis is generally on writing testable and maintainable code, particularly in the case of large software projects involving teams of people. In most cases, the performance of the code is de-emphasized, largely because modern systems are so fast and capable that this is not an issue (note that this is certainly not universal, but it is increasingly the case).
Reply | Threaded
Open this post in threaded view
|

Re: other approaches to software engineering

Lozminda
To add: the VM on this course "is similar" to LLVM

If I've understood correctly here many languages are translated to LLVM and then that's assembled. (I'm sure I'll be corrected if I'm wrong, which i maybe)

There's been some talk for functional languages (eg Haskel) of trying to design "functional hardware" as the C style + OOP family of languages (which is many, I include python, java, javascript) is suited to the von neumann architecture, basically what we've been learning, where as functional programming languages are doing "a lot behind the scenes" to get that functionality on hardware that isn't really suited to that style.

I'll lleave that above paragraph in, because I'm happy to show off my mistakes (well not happy) turns out I'm talking a load of twoddle:
This Post
And this one too

Some ramblings there, most of which may or may not be true, so largely useless !
Reply | Threaded
Open this post in threaded view
|

Re: other approaches to software engineering

ouverson
In reply to this post by WBahn
In projects 6-12 ("Software hierarchy",) there are 4 steps from Human Thought to Machine Language:

Step 1: Application or System Design: Human Thought -> High-Level Language (.jack files)
Step 2: Compiler: High-Level Language -> Virtual Machine (.vm files)
Step 3: VM Translator: Virtual Machine -> Assembly Language (.asm files)
Step 4: Assembler: Assembly Language -> Machine Language (.hack files that run on the Hack Hardware Platform)

What would the "Software hierarchy" look like if we used Python instead of Jack to write our high-level program; and we run the program on let's say a new MacBook and/or a Dell laptop running the latest version of Windows?
Reply | Threaded
Open this post in threaded view
|

Re: other approaches to software engineering

WBahn
Administrator
It would look pretty much identical. The only difference is that Steps 2 and 3 wouldn't be done by the compiler, but rather by the actual interpreter that evaluates and executes the Python program at run time. In a language like Java, the difference would be that Step 3 was done at run time by the JVM program that would execute the byte code (Java's VM code) generated by the compiler.
Reply | Threaded
Open this post in threaded view
|

Re: other approaches to software engineering

ouverson
Thank you for the explanation.

That leaves Step 4.

You stated that the interpreter "evaluates and executes the Python program at run time". Does this mean that the interpreter takes the python source code and produces machine code that runs on the target hardware platform?
Reply | Threaded
Open this post in threaded view
|

Re: other approaches to software engineering

WBahn
Administrator
Yes. And the same for the JVM. I should have included that.

Also, note that the use of any kind of VM is not absolutely required. But I'm pretty sure it is almost universal -- humans just don't do too well working at large steps in an abstraction hierarchy. We do good when we take little steps.
Reply | Threaded
Open this post in threaded view
|

Re: other approaches to software engineering

ouverson
Thank you for the confirmation!