I like the literate component a lot, I can see why that would be a very big plus when you're building avionics software.
Bookmarked your thesis.
What was your reason for going for 'duck typed' and 'scripted' rather than strongly typed and compiled? (Which I would assume to be a whole lot more suited for the intended branch of industry, so that has me curious.)
At the surface of it this looks like a 'textual spreadsheet' with the lines replacing the cells of the sheet.
This 'spreadsheet' is then evaluated 'x' times per second to satisfy the hard real time requirements.
How do you stabilize the results from one 'tick' to the next? Do you keep a shadow copy that you work on with all the results posted to the next generation?
There is something funny about a person working for a small software outfit choosing a format for textfiles (for really good reasons) because Microsoft or Apple might not be around when the files need to be read. I get your reasoning and agree with it completely but you have to balance that against the chances of your own company not being around anymore either.
How much of the software of the original Boeing 747 is still in use today? I'd imagine there are no fuselages that have not been upgraded multiple times since the first 747's took flight. So the lifespan of the documentation is roughly the same as the lifespan of the software.
Are there any public sources out there?
Here are some of the oldest 747 airframes known to be still on active duty:
But that does not say much about the avionics in them.
Do you intend to release the source to solscript in order to profit from the 'many eyes' out there to reduce the number of bugs in the runtime? (Which can't be written in solscript, so effectively will have to be written in some unsafe language.)
I like that markdown trick a lot, that's applicable to just about every programming environment, see:
Haha, that's a lot of questions. Let me try to go over them.
I say SolScript is "duck typed" and "scripted", because that's how it feels to program SolScript. However, under the hood, SolScript is a statically typed, compiled language.
About the "spreadsheet" idea, that is exactly what the SolScript IDE (Solide) is going to be. There will be a spreadsheet mode, which displays the source code as a spreadsheet. The last chapter talks about Solide, if you want to know more. (The creation of Solide is going to be my job, and I've been watching Bret Victor videos, all day yesterday, for inspiration.)
We have no "deep copy" of the data. The data is simply mutated in place, for performance. The compiler knows in what order it has to update the datacells, so SolScript users don't notice any of this. If I say `b = a`, then `a` will be calculated before `b` uses it. (If you want the value of `a` before `a` is updated, you say `b = previous a`.)
The whole "plain text" argument is about the fact that companies can die. So can (UN)MANNED, of course. The difference is that plain text files will always be readable, in contrast to Word files. You don't need our software to read plain text documentation.
Releasing the source is not something we plan to do (for now). We are not against the idea, but right now we have other priorities. There will probably be a gratis version, even for commercial use. Only that version won't be certified.
Yes, SolScript is written in an "unsafe" language: C. This makes it extremely cross-platform. We can run on Linux, OS X, Windows, iOS, VxWorks... The coding standards of our C code are extremely strict. Avionics style.
And about Markdown, yes that could be applied to other programming languages. BUT SolScript integrates with Markdown on a whole new level. For example, sections in Markdown are the scopes or namespaces of a SolScript program. Markdown is built into SolScript, not tacked on.
Edit: Circular dependencies really make no sense, in a declarative programming language. Defining `a = b` and `b = a` has no clear meaning, so the compiler will throw an error. However, you can define things recursively using `previous`. For example: `a = b + 1 initially 0` and `b = previous a`. In this case, `b` is 0, 1, 2, 3... and `a` is 1, 2, 3, 4...
Much appreciated, thanks for all your answers, I've read a good chunk of your thesis by now (that's hard work :) ), good stuff.
> We have no "deep copy" of the data. The data is simply mutated in place, for performance. The compiler knows in what order it has to update the datacells, so SolScript users don't notice any of this. If I say `b = a`, then `a` will be calculated before `b` uses it. (If you want the value of `a` before `a` is updated, you say `b = previous a`.)
Ok. That may cause some trouble when there are long chains of circular dependencies but I'm sure you're aware of that and that you have a solution in place (assuming circular dependencies are even allowed).
Again, thank you for all the answers and much good luck with your project, I'll be following your progress, it's super interesting what you are doing.
> I say SolScript is "duck typed" and "scripted", because that's how it feels to program SolScript. However, under the hood, SolScript is a statically typed, compiled language.
Duck typing refers to the ability of making shit up at runtime, as in the ability for functions, classes or code to manifest at runtime and to respond to user queries based on runtime info. It doesn't refer to a lack of explicit types in your code, since in a static language types are still there and still have to be something concrete and solvable at compile-time. It doesn't even refer to structural typing, because again, the types themselves have to be solvable at compile time.
I'm a static languages fan and I've also worked a lot with dynamic languages. The ability to make shit up at runtime is much more than the ability to call a method on an object without being explicit about the interface used. This is not about succinctness as as it about programming style. With an expressive static language used to its strengths, as a developer you want to write code that is as close to provably correct as possible, so even if the static language used is very expressive, the style is oriented around modeling the problem domain with types. In a dynamic language on the other hand, the focus is on the raw data that needs to be manipulated and code is written to make shit up on the fly (i.e. method_missing, eval, classes manifested at runtime by means of meta-programming, etc...).
Hence my opinion that duck typing shouldn't be used outside the context of dynamic languages, because people might get the wrong idea about it.
SolScript really looks cool. I'm also writing something, it's a generic paper about FRP though. Gonna cite your paper :) Cool that you used duck-typing, although it's causing much more complexity, but it's great for Reactive Programming. Have a look at this paper, it might be of help for you http://lambda-the-ultimate.org/node/2438
My paper is in german, but I'll publish it on github and translate it (time given).
I've also got a hypothesis on how FRP can be abstracted into a domain model using AI and non-axiomatic reasoning. But I hope I don't run in a dead-end there though, it's just a theory :)
- avionics
- type inference
- duck typing
You like challenges don't you? ;)
I like the literate component a lot, I can see why that would be a very big plus when you're building avionics software.
Bookmarked your thesis.
What was your reason for going for 'duck typed' and 'scripted' rather than strongly typed and compiled? (Which I would assume to be a whole lot more suited for the intended branch of industry, so that has me curious.)
At the surface of it this looks like a 'textual spreadsheet' with the lines replacing the cells of the sheet.
This 'spreadsheet' is then evaluated 'x' times per second to satisfy the hard real time requirements.
How do you stabilize the results from one 'tick' to the next? Do you keep a shadow copy that you work on with all the results posted to the next generation?
There is something funny about a person working for a small software outfit choosing a format for textfiles (for really good reasons) because Microsoft or Apple might not be around when the files need to be read. I get your reasoning and agree with it completely but you have to balance that against the chances of your own company not being around anymore either.
How much of the software of the original Boeing 747 is still in use today? I'd imagine there are no fuselages that have not been upgraded multiple times since the first 747's took flight. So the lifespan of the documentation is roughly the same as the lifespan of the software.
Are there any public sources out there?
Here are some of the oldest 747 airframes known to be still on active duty:
http://www.airliners.net/aviation-forums/general_aviation/re...
But that does not say much about the avionics in them.
Do you intend to release the source to solscript in order to profit from the 'many eyes' out there to reduce the number of bugs in the runtime? (Which can't be written in solscript, so effectively will have to be written in some unsafe language.)
I like that markdown trick a lot, that's applicable to just about every programming environment, see:
http://michael-sokol.tumblr.com/post/13112309135/literate-pr...