I don't get it ... javascript *is* a complex, low-level language. .. it's certainly *much more* complex then C or C++ ... this discussion is not meant to be a language war, it's meant to be about "how can we actually accomplish this?"
-- Linas On Wed, Jun 30, 2021 at 11:50 PM Lansana Camara <[email protected]> wrote: > I don't see why you couldn't get all three with JavaScript. A web > application built in JavaScript (React) can be ported into Electron > <https://www.electronjs.org/>, which enables cross-platform desktop > applications. In other words: one language, one application, all platforms > and mobile devices. > > I've worked on some very sophisticated dashboards that were built for the > web, and I'm of the mindset that there is simply no need for complex low > level languages like C/C++ in the user interface domain, unless you're > dealing with low level embedded systems or something like that. But this > problem isn't in the space of embedded systems; it's in the space of > mobile/desktop applications. Thus, in my humble opinion, cross-platform > mobile/desktop applications are best left to modern user interface > technologies like JavaScript/TypeScript and the frontend ecosystem built > with it. > > On Wed, Jun 30, 2021 at 10:10 AM Linas Vepstas <[email protected]> > wrote: > >> >> >> On Tue, Jun 29, 2021 at 11:49 PM Lansana Camara <[email protected]> >> wrote: >> >>> Linas, >>> >>> Dashboards -- well, when I say dashboard, what I think of are things >>>> like the BIOS boot-up screen -- menus and lists and configurable parameters >>>> and you can navigate it with keyboard or mouse. My wifi router has a >>>> dashboard -- it's a web page, you can configure wifi settings in it. My >>>> (android) cell phone has one: it's the "settings" panel: you can change >>>> this or that setting, turn things on and off. >>>> >>> >>> >>> So I'm thinking the same thing but for generic data science with >>>> opencog. Take this file, copy it to that directory, start this script, >>>> look at diagnostic output, wait until the dataset is done, and when it's >>>> done, paint a green dot, and if it crashed, paint a red dot. That kind of >>>> stuff. Show me a graph of megabytes used so far, cause I have a datacap of >>>> 1 million atoms per month. JK.😂 >>> >>> >>> What you're asking for here is basically what they pay me the big bucks >>> in Silicon Valley to build on a 9-5 schedule 😂 >>> >> >> Sigh. It shouldn't be like that. I won't create a GUI mockup, for two >> reasons: first, this is something that artists and designers do, when >> trying to take an existing system to the next level. Right now, we don't >> have anything basic. Second, these kinds of things best evolve through >> regular use: you use it for a while, and if it stinks you stop using it, or >> you alter it so it works right. It's very hard to predict what that might >> be in advance. Also, processing steps evolve, flows change. The flow from >> last month might no longer apply this month. The process changes; the GUI >> needs to be malleable. >> >> Now, back in the day of desktop apps, there was this thing called a "gui >> designer". It allowed you to drag-n-drop menus, text-boxes, buttons, plots, >> charts, change their color, font size, stuff like that. You could hook them >> up to code that "did stuff": there was an editor, and you'd fill in the >> blank: on button-press, do this. On double-click, do that. If you never >> used one, you should try it. They're awesome! The one for Gnome/GTK is >> glade -- https://glade.gnome.org/ >> >> Is there something like this for React and/or Angular? >> >> I am confusing you and I am confusing myself, because I am talking about >> three different things. >> >> 1) An atomspace visualizer. This would be for complete beginners, and >> would be a web-javascript thing, so that we could stick it on a website, >> and allow people to dink with it, without having to install anything at >> all. Bonus: it runs on tablets. >> >> 2) A dashboard. I'm starting to think that maybe using Glade and GTK to >> build a desktop app is not a bad idea. The only thing wrong with that is >> it wouldn't run on cell phones and tablets. >> >> 3) A science exploration ... system/journal. Perhaps Jupyter is the best >> choice for this. The most deeply flawed problem with Jupyter is revision >> control. If you change one line of code in Jupyter, and do a diff, you get >> thousands of lines of code changed. That sucks: that makes using git >> completely useless. I'm told that there are some maybe-solutions for this, >> but I haven't really looked/tried. >> >> In some ideal world, a combination of all three would be best. I guess. >> >> -- linas >> >> >>> As previously stated, I really don't mind spinning up some boilerplate, >>> such that a new frontend developer familiar with React and other modern >>> technologies can get up and running with little hesitation. That would >>> literally take me a day or two or effort, tops. But it wouldn't really >>> include any functionality -- it'd just include the foundation to build >>> functionality on top of. >>> >>> If you want a full on production-ready dashboard/control panel >>> experience, with data visualization and data management...that is a >>> different level of responsibility. Even if it isn't built from scratch, >>> plugging your data into a pre-built system is not necessarily more trivial. >>> >>> As someone that doesn't have the full context of opencog/atomese that >>> you have, it would be much easier if you could draw up some wireframes (or >>> go to Upwork.com and hire a graphic designer to build some wireframes for >>> like a measly $100) of the screens you're imagining in your mind. Once I >>> see those screens, it will be much better for me in terms of figuring out >>> the scope of work required here, which I can then clearly communicate back >>> to you. >>> >>> On Tue, Jun 29, 2021 at 12:08 PM Linas Vepstas <[email protected]> >>> wrote: >>> >>>> Reslav, (and Micheal ... below) >>>> >>>> Thanks! That is a very nice summary. I'm not sure quite where that >>>> leaves me, except maybe back at square-one. I'd like to see some kind of >>>> cute graphical atomspace browser that beginners could run, and ... ideally, >>>> run the demos from the examples directory. >>>> >>>> Kind of unrelated to that is that I would like to have a data science >>>> dashboard. So, what Mike says about MOZI -- but I am not working on >>>> bioinformatics, I am working on learning. I have similar needs: I have >>>> datasets that need to be managed and loaded. I have data-mining jobs that >>>> run for hours (or longer). I have to start, stop, checkpoint things, make >>>> backups. Then when I'm done, I need to make charts and plots to see what >>>> happened. >>>> >>>> Currently, I do the above with a strange brew of README files, bash >>>> scripts, config files, gnuplot, and the LyX word processor. I have found >>>> that 99% of potential collaborators do not have the attention span to get >>>> to the end of a README file. You have to be super-duper motivated to read >>>> it, and follow the instructions. So I'm thinking that, vaguely, surely, >>>> there must be some way of converting that into some kind of interactive web >>>> pages that walk you through the steps. >>>> >>>> Again: MOZI has built something like this, but it is custom-tailored to >>>> bioinformatics. And so I can't use any of it. If it was general purpose, >>>> there would be the benefit of shared development: anything done by one >>>> project (e.g. learning) could be used in another project (e.g. >>>> bioinformatics). >>>> >>>> Dashboards -- well, when I say dashboard, what I think of are things >>>> like the BIOS boot-up screen -- menus and lists and configurable parameters >>>> and you can navigate it with keyboard or mouse. My wifi router has a >>>> dashboard -- it's a web page, you can configure wifi settings in it. My >>>> (android) cell phone has one: it's the "settings" panel: you can change >>>> this or that setting, turn things on and off. >>>> >>>> So I'm thinking the same thing but for generic data science with >>>> opencog. Take this file, copy it to that directory, start this script, >>>> look at diagnostic output, wait until the dataset is done, and when it's >>>> done, paint a green dot, and if it crashed, paint a red dot. That kind of >>>> stuff. Show me a graph of megabytes used so far, cause I have a datacap of >>>> 1 million atoms per month. JK.😂 >>>> >>>> Is there some kind of generic data science dashboard out there, that we >>>> could adapt and use for managing opencog systems? >>>> >>>> --linas >>>> >>>> >>>> On Tue, Jun 29, 2021 at 12:08 PM Reslav Hollos <[email protected]> >>>> wrote: >>>> >>>>> TypeScript is a language, a superset of JS that adds syntax for >>>>> optional types (which are extremely helpful). It can be used for React as >>>>> well and for any other JS project. >>>>> >>>>> Angular is a UI framework which is in my opinion over-engineered and >>>>> is built on top of bad practices like mutations (eg. two way data >>>>> binding). >>>>> Mutations are useful when performance is needed, but if not encapsulated >>>>> tend to be the cause of too many hidden bugs difficult to detect or even >>>>> fix. Newcomers I mentored had problems with Angular since it required too >>>>> much knowledge to contribute even a little. Another example is the >>>>> model-view-presenter structure which I've found to be hard to maintain on >>>>> large projects, it was confusing to too many people and allowed for >>>>> mistakes to happen very easily. Having such complexity at the very >>>>> beginning takes focus away from the application. >>>>> >>>>> React is a UI library which I believe got it right from the start, it >>>>> revolves around separation of concerns, app state propagates >>>>> hierarchically >>>>> downwards (unidirectional data flow) and changes are done with callbacks >>>>> instead of directly mutating (these are called controlled components). >>>>> Mutations can still be used, but are not used by default. React uses >>>>> virtual DOM and an algorithm called 'reconciliation' that determines when >>>>> and what to update in the DOM, since state changes generate new objects, >>>>> to >>>>> me it's simpler than Angular's Change Detection. All of which is debatable >>>>> but in React things have mostly worked out of the box for me, while in >>>>> Angular there were many times an extra step, a solution to a problem that >>>>> should not have existed in the first place and felt like a workaround. >>>>> React has JSX syntax that combines HTML and JS and recent updates added >>>>> 'hooks' syntax which even more simplifies the state management. >>>>> >>>>> In short I think that React based projects have bigger chances for >>>>> community contributions because of ease of use. >>>>> >>>>> About NPM, it can sometimes be tricky but I think it's manageable, it >>>>> shares some problems/solutions from many different package managers, like >>>>> mismatch of node version between dev environments, incorrect handling of >>>>> package-lock.json (a file that hardcodes all dependencies of dependencies >>>>> versions) or some library incompatibilities with another library which >>>>> solution is usually in github issues comments. I use NPM in all JS >>>>> projects. >>>>> >>>>> This is based on the experience I accumulated over the last 6 years. >>>>> >>>>> Reslav >>>>> >>>>> On Tue, Jun 29, 2021, 16:19 Linas Vepstas <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Jun 29, 2021 at 8:57 AM Reslav Hollos < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> I'm also interested in AtomSpace UI and have had very pleasant dev >>>>>>> experience with React (as well as TypeScript which I would recommend). >>>>>>> >>>>>> >>>>>> Well, the current code is in "Angular" -- and is TypeScript. How >>>>>> different is that? Are Angular and React two different versions of the >>>>>> same thing, or are they completely different? I can code in javascript >>>>>> just >>>>>> fine, but things like npm and etc. leave me stumped -- when there's a >>>>>> problem, I don't know how to debug it. >>>>>> >>>>>> --linas >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "opencog" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/opencog/CAHrUA34hy9RZBg897pPX-hwhkcf_%2BbHmE%2B4QRSsE60p%3DnjKb9Q%40mail.gmail.com >>>>>> <https://groups.google.com/d/msgid/opencog/CAHrUA34hy9RZBg897pPX-hwhkcf_%2BbHmE%2B4QRSsE60p%3DnjKb9Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "opencog" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/opencog/CANHDs8%3DrtH%3DUwMb5zwetbX9UPk3XiFnTnw2hy--aNmDqXkr3%3DA%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/opencog/CANHDs8%3DrtH%3DUwMb5zwetbX9UPk3XiFnTnw2hy--aNmDqXkr3%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> >>>> -- >>>> Patrick: Are they laughing at us? >>>> Sponge Bob: No, Patrick, they are laughing next to us. >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "opencog" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/opencog/CAHrUA34UVtF9vnOua5YOEVQuwZo_Z3PJkNZGVVYaC3H4yNUycg%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/opencog/CAHrUA34UVtF9vnOua5YOEVQuwZo_Z3PJkNZGVVYaC3H4yNUycg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "opencog" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/opencog/CAPPXERrZ5tpm5HD-nQxs09ykEUERzQ0hAcytrahzU_vE-UBhdg%40mail.gmail.com >>> <https://groups.google.com/d/msgid/opencog/CAPPXERrZ5tpm5HD-nQxs09ykEUERzQ0hAcytrahzU_vE-UBhdg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> Patrick: Are they laughing at us? >> Sponge Bob: No, Patrick, they are laughing next to us. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "opencog" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/opencog/CAHrUA37ba8zJnEodzavpSo3hF6b6nAt0Q2rmAvvZC93i%2BCLa_Q%40mail.gmail.com >> <https://groups.google.com/d/msgid/opencog/CAHrUA37ba8zJnEodzavpSo3hF6b6nAt0Q2rmAvvZC93i%2BCLa_Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "opencog" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/opencog/CAPPXERpJ1kXpzEZSj8ENMWQdutnu-N4Wa0oTBMpc%2B4x1Ph56Bg%40mail.gmail.com > <https://groups.google.com/d/msgid/opencog/CAPPXERpJ1kXpzEZSj8ENMWQdutnu-N4Wa0oTBMpc%2B4x1Ph56Bg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Patrick: Are they laughing at us? Sponge Bob: No, Patrick, they are laughing next to us. -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34cicZZpuDSPSFLg5d%2B8ToXFyqD-2ODQ-9wOxkHyvOFfg%40mail.gmail.com.
