Closed snv closed 11 years ago
Dunbaratu
commented
11 years ago I've always thought that the two design goals of:
1 - Make it look all primitive and low tech and like something from an 80's home computer.. and 2 - Make it simple for people who don't normally program.
are 100% opposed goals at odds with each other. Programming in the 80's wasn't made simpler by the primitive nature of the computers. It was made harder by it.
weissel
commented
11 years ago Dunbaratu, I think you're not quite right. Programming a "modern computer" (in the GUI style) means not only knowing the language, but also the libraries, the GUI interfaces and so on and so on. (Or restricting yourself to a limited language/library that 'does it all' in some way for you.) Restricting the knowledge to a small number of commands --- similar as the current first iteration of the tech tree --- makes the language much easier to handle, you can know everything here. How about knowing everything about every and any Java library? :-)
Sure, there are a lot of things you can't do, but a) kOS is a domain specific language, not a generalist language ("like python, lua, ruby, c# or whatever") --- it has one use only: control vessels in the KSP universe (plane, rover, rocket). b) the complicated concepts are in orbital mechanics and physics, not in the language. (If you want to change that, you're at MechJeb.)
In fact, the language extremely simplifies steering by allowing a "lock steering to
So, yes, it's simple by being very limited to one domain, it's back to cycle counting (at least on my machine under Linux) --- though what constitutes a command taking a cycle varies widely from conventional software: a set seems to be identical no matter if it's 'set x to 0' or 'set x to <complicated formula with cube roots, multiplications and many terms>' --- it's back to limiting your program to a small size, it's back to print (and the advanced print ... at (x,y) --- and no, you probably can't use a routine to finetune the length of the print outside the simple round to an integer & co --- too many cycles wasted!).
Hell, we got advanced stuff like subroutines now! Now we only need Lisp-like or Scheme-like macros (no, not C-type text substitution "macros" which aren't worth the name) --- they are period, 'fexpr' being in Lisp 1.5 (which means 1962) and then we can build any control structure ...
Dunbaratu
commented
11 years ago Weissel, we're talking at cross purposes. You're talking about the side topic of what things are implemented in the library but this issue isn't about that. It's about the language. Its not about whether or not you have to write the pid controller yourself to lock the steering or whether it's handed to you already working in the underlying 'hardware' of the computer.. It's about what the syntax looks like for the language. it's about requiring short variable names because long names run afoul of the 10k limit. It's about saying "set x to 2" instead of "x= 2". It's about does the language have for loops or not. The complexity of what the library does for you and how much of it you need to memorize is not an inherent complexity of the syntax of the language itself.
For example, right now KOS script has only one kind of way to loop, and it isn't shared in common with any other language.. That does not make things simpler. At all. And the handling of the syntax doesn't seem to be properly recursive, meaning the same thing that worked over here doesn't work over there like it should, and some things can be nested and other things can't. If the design goal is to make things primitive on purpose these problems make sense. If the design goal is to make it easy for the new programmer, they don't.
Your talk about how complex the libraries are really doesn't talk about the same thing.
weissel
commented
11 years ago Dunbaratu, maybe we are talking at cross purposes. I mentioned libraries only for 2 reasons:
And yes, it's EXACTLY about you having to write a PID controller, to e.g. control your height and sinkrate instead using http://kerbalspaceport.com/vertvelctrl/ ! Or using the automatic landing of MechJeb. (You can simply calculate the thrust needed instead of using a PID. And yes, the cycle time of a kOS PID loop makes that a bit complicated to work well under all circumstances!)
You don't need short variable names unless you write really large programs that do everything. If you write such programs I am sure you can manage a search-and-replace of the source to the 'executable', also stripping superfluous white space (like indentation) and comments, while you're at it. And if you need more space, slap on another computer, or use a less code needing algorithm.
'x=2' is confusing to a non-programmer and extra work for the interpreter. Is 'if (x=2) ...' assigning 2 to x or is it testing the equality of x and 2? Using 'x == 2' is only marginally better, people wise, as that is not an easy to see difference for the untrained eye.
We do have a loop command. 'until'. You can do anything you can do with a for loop with it. And since we're mostly waiting for something to happen --- reach apoapsis, falling below 1000m (then open parachute), a fuel tank or asphargus stage draining empty, etc. --- until is way more natural.
Your claim that 'until' is unique in languages is strange, I use 2 languages daily that have just such an until loop. A short check yields:
Note: "do until" here means "do until (condition) {body}", not "do {body} until (condition)".
And yes, the language is certainly Kerbal (and not a carbon copy of anybody's favourite language), not finished and has bugs. That's what bug reports are for, so write one when "the same thing that worked over here doesn't work over there like it should". That's nothing new.
And I guess that the neophyte programmer, having had little if any exposure to other languages will see 'until' quite natural and not say "B... B... But that's different from the language I know".
Of course, if we had macros, it'd be easy for you to implement any loop you want using the until loop we have.
weissel
commented
11 years ago Args. Markup ate my '<body>' and '<condition>'. Wrote that differently. (updated the comment).
Basically it's about the difference between
do { stage. wait 0.2. } until (maxthrust > 0). which will always stage at least once and
until (maxthrust > 0) { stage. wait 0.2.}. which will not stage if maxthrust is already bigger than zero, even when some languages write that as do until (maxthrust > 0) { stage. wait 0.2. }.
Nivekk
commented
11 years ago @Dunbaratu: There is a third design goal as well:
Honestly, I don't feel like my efforts are wasted, because building my own language has been a ton of fun. And stumbling around in the dark making lots of mistakes and learning from them is part of that fun.
Yes I could have simply implemented say, Javascript into this thing and just created KSP bindings, but it wouldn't really be the same project I had in mind because Kerbals have never heard of Javascript. They also have no knowledge that their universe resides inside somebody's C:\ drive, which has libs on it they can make use of.
Again, not that that kind of mod would be wrong, but my intent was to make an in-universe mod that makes sense inside the context of the game. Somebody else can implement their KSP-Python scripting environment and more power to them.
Dunbaratu
commented
11 years ago I never claimed we don't have loops. Nor did I claim you can't re-work any sort of loop to turn it into the one kind of loop we do have. That's a reply to a strawman of what I said. I said we don't have for loops and I meant it.
I still haven't seen anything that convinces me that I was wrong that the two goals I mentioned are inherently contradictory and trying to satisfy the both of them together is inevitably going to always be a case of making a compromise balance between them, it being impossible to fully satisfy one without hindering the other.
@Nivekk - I agree with your idea that there's nothing wrong with inventing a new language for this. I come from the Unix world where we do it constantly, and people writing their own new tool often write their own language for how you're supposed to configure it. But inventing brand new code to handle the parsing, on the other hand, is sort of odd. And that's where a LOT of the bugs have come from was the decision to do that instead of using a parser generator tool that you feed a grammar definition into.
JoCRaM
commented
10 years ago I once looked at lex and yacc.
I walked away quickly,
I hope i'm not raining on your parade (also hope i'm using this expression right), but i think designing your own language is a wasted effort.
I love your gamification: the terminal and the volumes/archives system. I only wish i could use a "mature" language, like python, lua, ruby, c# or whatever, including maybe loading/using of libs.
Designing a good scripting language is difficult and you seem to be using the add-as-we-go-along method, where i think your valuable effort would be better spend in offering an interface for an already existing toolset/world.
I understand, rather expect, that this might go into a completely different direction than what you have in mind, so this is merely just a humble suggestion.