Adobe's ExtendScript toolkit is abyssmal. I find posts from 2008 referring to issues that have not changed even in CC2017. Do you think they are small issues I'm bitching about? I'll list 2. First, the toolkit only colours "var, return, for, foreach" and a bit more keywords and the strings, of course you can set up color schemes but those are limited and not colouring stuff. The second issue is auto-complete, it rarely kicks in and suggestions have 0 connection to what are you doing and are always the same. It doesn't recognize anything of what are you doing.

Probably in 2008 you had to program with the manual near you like writing assembler, now there's an improvement in 2017, they got a window named object browser or something like that that actually is a summarised portable manual that could've been easily transformed in auto-complete suggestions.

Adobe writes about this and I quote: "a complete integrated development environment". Although I will not write much scripts in it, I need to write a big one and thought about extracting that object data and putting it in a more capable javascript editor. LO and Behold what I discovered, the ExtendScript Toolkit that's supposed to edit Extended javascript and save it as jsx or jsxbin is almost completely (it has some dlls too) built using around 100 jsx files. It's the equivalent of building a js IDE to edit js.

Sorry for formatting, I'm on mobile, I tried.

GitHub has launched Codespaces : A feature that lets you code directly on the web {as a virtual Integrated Development Environment (IDE) on the cloud}.

According to the Github Blog: Earlier, to contribute to a project you would need to make a pull request and set up the environment on your local machine according to the requirements of a project. With Codespaces, you don't need to do that anymore. As soon as you click on the code button, the website sets up the environment in seconds.

In addition to Codespaces, GitHub is also launching Discussions : A forum-like feature that lives under your project that allows others to engage with you and other contributors.

Code scanning : With code scanning enabled, every git push is scanned for new potential security vulnerabilities, and results are displayed directly in your pull request.

#! usr/bin/rant

Our Entreprise CMS at work (obviously):
- inconsistent UI : check (misplaced buttons, some pages are more developed than others)
- slow: check (average 6 seconds of waiting, with cache)
- loading screen as page transitions covering the whole page, making it impossible to click somewhere else if mistaken, adding +3 seconds to loading : check
- time-based session, inlined in HTML and wildly disconnects you, making you lose all changes : check
- sometimes objects are inaccessible and can't do anything about it : check
- "delete" button next to "edit", delete is bigger and I have already clicked the delete button by accident : check
- can't have local development environment, need to work with integrated editor which has no helping features: check
- first TTFB: adds +2-6 seconds to loading time

TL;DR : a pleasant, developer-friendly, frustration- and rantless CMS to work with, reliable and fast.

Random thoughts on more out of the box tools/environments.

Subject: Pharo

Some time ago I had shown one of my coworkers about Pharo and he quickly got the main idea behind it but mentioned how he didn't like the idea of leaving behind his text editor to deal with source code.

Some time last week I showed the dude some cool 3d animations you can do with Pharo while simultaneously manipulating the code to change them in real time. Now that caught his attention particularly and he decided he wanted to know more about the language but in particular the benefits of fucking around with an image based environment rather than a file based.

Both of us reached the conclusion that image based makes file based dev enviroments seem quaint in comparison, but estimated that it was nothing more than a sentiment rather than a fact.

We then considered what could be the advantage/disadvantages of such environments but I couldn't come up with anything other than the system not having something like Vim or VS Code or whatever which people love, but that it makes up for it with some of the craziest IDE tools I had ever seen. Plugins in this case act like source code repos that you can download and activate into your workflow in what feels something similar to VS Code being extended via plugins written in JS, and since the GUI is maleable as it is(because everything is basically just subsets of morp h windows) then extending functionality becomes so intuitive that its funny

Whereas with Emacs(for example) you have to really grind your gears with Elisp or Vimscript in Vim etc etc, with Pharo your plugin system is basicall you just adding classes that will convert your OS looking IDE into something else.

Because of how light the vm machine is, portability is a non issue, and passing pharo programs arround is not like installing Java in which you need the JVM.

Source code versioning, very important, already integrated into every live environment and can be extended to do pushes through simple key bindings with no hassle.

I dunno, I just feel that the tool is too good to be true. I keep trying to push limits into it but thus far I have found: data visualization and image modeling to work fine, web development with Teapot to be a cakewalk and work fine, therr are even packages for Arduino development.

I think its biggest con would be the image based system, but would really need to look into how this is bad by any reason other than "aww man I want vim!" since apparently some psychos already made Emacs and VS code packages for interfacing with Pharo source trees.

Embedded is certainly out of the question for any real project since its garbage collected and not the most performant cookie in the jar.

For Data science I can see some future, seems just as intuitive and interesting as a Jupyter Notebook actually, but the process can't and will not be the same since I still don't know of a way to save playground snippets unless you literally create classes for it, in which case every model you build gets saved inside of an object, sounds possible but, strange since it is not a the most common workflow in jupyter.

Some of the environment is sometimes glitchy, but it does have continuos development and have not found many hassles.

There is a biased factor from my side: I seem to be wired to understand the syntax and simple object model better than in other languages. To me this feels natural as if I was just writing ideas rather than code, mostly because I feel that there really ain't much in terms of syntax, the language gets out of my way and the IDE feels like the most intuitive environment in the world to me. I can see why some people would find it REALLY weird of counterintuitive tho.

Guess I really am a simple dude.