My first impressions - continued


Hi, Mad Scientists,
This is the continuation of my first post about Skookum IDE first impressions.
I’ve had little more time to play with SkookumScript itself past a couple of days and I would like to leave some thoughts about it while my memory is fresh.
Sorry about the random orders.

  1. REPL: I have used REPLs from many languages, mostly from Lisp, the father of all REPL. Skookum REPL is not really a REPL, rather, it’s a scratch pad. A REPL in traditional sense, you get result instantly by typing “Enter” Most of the other languages that support REPL also support scratch pad, meaning that you can execute snifit of codes directly from the source also. This is what I would like to see.

    1. a. Call the current REPL a Scratchpad and support a real REPL
      b. A real REPL should remember states so that executing !foo := “bar” will remember foo variable later on. States are important as REPL often used for experimenting stuff and Scratch pad is more testing larger building blocks
      c. Allow executing snifit of code from the code editor. Right now, code editor doesn’t respond to F4
      d. Typing F4 is rather annoying to execute snifit of code after a while. How about changing to CTRL-Enter?
      e. Support temp variable to store last results automatically. I used use !, !!, !!! to store last three results respectively but we can find some other appropriate variable names. These temp variable can help quickly interact with REPL result during the development, piping previous result back into the next statement and it is very useful technique. I wish Sk supports functional programming more naturally so that we can directly pipe result into the next.
  2. Syntax: I’ve looked at SK while ago and to be honest, it was one of the biggest turn-off. It looked a bit ugly and I still don’t quite get it why intentionally making it look different other language is a good thing. I’m still struggling to learn SK and I rather not switch gears. If there are only C++ and Sk in the world, it is ok but there are several more and I’m not really that interested in learning new syntax. Instead of reinventing, we can improve upon the good common conventions. Besides, SK has relatively rudimentary syntax and I thought it would require quite a bit of time until it gets mature and I wanted to wait until it gets widely accepted back then. It could make some others to think that, “yeah I won’t jump in the bandwagon until others do” This could be very religious topic but if you think there are still some room for change, I would like to throw-in my two-cents.

  3. a. Please get rid of []. I think SK took compact-syntax path and I think we can make it even more compact and I believe it will make it more clean by not using []. Each member function has it’s own body and it always start and end with []. I think we can get rid of it to reduce the clutter. We can follow F# or Python convention(indentation for code blocks) And use () for grouping/precedence-ordering. To be honest, I’m not a fan of indentation-block but in case of Sk, I think it will make sense. One other side-benefit is that you can use [] for something else that’s more useful.
    b. Please keep UE name as is. I don’t know why you are changing the original name to lowercase and underscore in between. It is rather difficult to tell if it came from UE or SK own. I know you wanted to use [ instead of { to save pressing shift key but inserting underscores everywhere doesn’t seem make much sense. It not only make the function name long but confuses me. But I think having Sk naming convention for SK defined names will have a benefit to tell apart from UE names to make the distinction easier, but please keep the original name the same.

  4. IDE; I think I covered some issues in the previous post but I would really like better intellisense and parameter tooltip as soon as it can. It’s still quite difficult to code without good editor support. Yeah, I know, developing a good editor will take a long time, and perhaps making SK VS plugin would be faster in the short-term. VS already has good support for adding new languages and we might have to add a new one. Just a thought. Anyway, here are some additional wish-list

  5. a. Configurable hotkeys. The first thing I wanted to change is F4 and assign hot-key to go to REPL windows. For programmers, editor that you can do everything without using mouse(or to a minimum) is the huge productivity booster.
    b. Inspector window. It’s like the “Details View” from UE Editor. I could type “Inspect object” in the REPL and it will show the details of the object in a GUI.
    c. Color-coded overlays: Right now, SK and UE method/members are mixed and it’s hard to tell what’s what. It’s mostly from UE but later on, it will become very difficult to manage them. User assignable color to overlays would help when browsing the codes. As a reference, you can probably get some inspiration from the following video about color-coding, organizing hierarchical views. We can probably highlight Blueprintable methods and so on.
    d. “Favorite Classes” tab. There is “Classes” tab but the list is too big and I’m mostly interested in handful of classes at one time. I would be nice to have another tab to keep “Favorite Classes” to navigate around the classes that I’m interested.
    e. Visual visit history (or bookmark): You often jump around many classes and members and spend needless time trying to go back where you were before. I know there is go-back but it works in linear fashion. I used to use this plugin for Unity and it’s quite useful. It keeps track of your edit history and you can move around the edit history quite easily non-linearly and visually. This is bit different from bookmark because it automatically creates bookmarks when you move around the code. You can also use it as traditional bookmark by locking certain visit history, and therefore it’s superset of bookmark. I wish I had this in VisualStudio too.!/content/26181

I know it’s quite handful but I really wish Sk does succeed. Even though it will take quite some time, there are some low-hanging fruit we can benefit right away.
I’m especially interested in knowing your thoughts about syntax because, if we agree that it’s a good thing that we change it sooner than later.

Thank you very much for your outstanding product and please keep the good work.


Skookum Syntax - is there a room for improvement?
Custom colored sections and highlighting
Live++ and SkookumScript