undefined | Better HN

0 pointsAlexanderDhoore11y ago0 comments

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...

0 comments

jacquesm11y ago

> Haha, that's a lot of questions.

Well, you post your thesis, I dig in :)

> Let me try to go over them.

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.

shailesh11y ago

SolScript looks fantastic.

Considering Avionics domain, using Coq or ATS to prove the correctness of SolScript compiler will help boost confidence.

bad_user11y ago

> 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.

j / k navigate · click thread line to collapse