I'll let others comment on your good list of enhancements. Regarding 3) Create GUI versions of models without code access or interface > modification. A distributable interface that can call .nlogo files that > removes all the editor part and that works in the background with > NetLogo.jar would suffice . Even, perhaps you could think about the > possibility of including the intermediate compilation that the tool makes > prior to execution, and give options if this closed and distributable > version has access to the Command Center , agent inspection windows, etc ... > 5) Add the option the world to be full-interface-window/fullscreen . Many > times, you can and want to control the entire model using the keyboard and > mouse. Perhaps you could add the option of a floating or auto-hide bar to > give access to specific widgets during the execution of the model. It is a > movement to make NetLogo a complete programming language, using agent > modelling as a general programming paradigm.
I've had students who did this in NetLogo Web - they simply exported the HTML and then removed a few elements. Once one knows which element ids to remove this can be done in less than a minute. Or some JavaScript can be pasted into the page to do this automatically and more flexibly. I would guess it would be easy to implement an export to HTML feature that optionally did this. This isn't a general solution since extensions and a few features are missing from NetLogo Web. On Sat, 18 Apr 2020 at 01:23, Fernando Sancho <fsanchocaparr...@gmail.com> wrote: > I start this mail with a long motivation about why to write this > wishlist... if you want you can go directly to the list going down... > > I do not hide my predilection for NetLogo. So much so, that I use it > regularly to develop courses (Math and CS university degree) that are > normally given in supposedly more interesting languages (Java and > Python?). Some of these courses have aimed to show the fundamentals of > systems modeling (where NetLogo fits like a glove); others teach basic > programming to first-time students; and others, show the fundamentals of AI > as a tool to solve problems mechanically and as generally as possible > (where NetLogo is much less frequent). > > But this choice makes me pay with an expensive coin, because every year I > make the effort to justify in front of the students (as loaded with > prejudices as the rest of humans) the use of a language that "nobody else > uses" and that "they will not return to use or ask them in any company", > and every year the ripe apples show that it is only a matter of time that > at the end of the course they have understood some of the most important > reasons why the choice has not been so wrong or random. > > The more advanced use I prepare is about the course of Artificial > Intelligence (http://www.cs.us.es/~fsancho/?p=inteligencia-artificial, > sorry, in spanish) where I have prepared a big library in NetLogo to tackle > with the several topics in it. In general, the characteristics of a course > like this and the needs I have are: > > 1) Broad in content, perhaps not so much in depth as in width, so it is > not enough for me that it has a very good library to make neural networks > and that everyone uses (even if they don't even know how it works). I do > not want everything to be done, but that it can be done in a reasonable > time with basic knowledge. > > 2) You must be able to implement solutions that go from the classic search > for states, to the current machine learning (the generic one, I can't think > of getting into Deep Learning in an introductory course to AI), going > through optimization, multi-agent systems, logic, planning , satisfaction > of restrictions, Monte Carlo methods, ... > > 3) We can hardly dedicate a couple of weeks of the course to know the ins > and outs of the language to use (each day dedicated to "programming" is a > lost day of AI). > > 4) It should provide a fast development environment, easy to install, and > available on various operating systems. It can not occupy 2 Gb and it has > to be Open Source. > > 5) You should bring many examples to guide the student if necessary. > > 6) It must provide mechanisms to approach prototypes of final solutions, > with a graphical interface and away from the typical environment in which > we execute code as if it were an algorithmic class ... because the course > is mainly evaluated through the creation of complete projects (automatic > players, data analysis, process optimization, etc.) in which visualizing > behaviors and decisions is essential. > > 7) It must be flexible enough to accommodate the creation and modification > of new methods and algorithms. Maybe because of me, but every year previous > solutions are modified and new algorithms are introduced to provide > alternative forms of solution, so the course is not closed in content, only > in objectives, and this task is often done in real time, according to the > needs and interests observed in the group that same year. > > 8) It must give an approach to programming that allows playing with > functional approaches (although it is not intended to be purist) and with > approaches with agents, as befits AI. > > Yes, NetLogo allows me to work with these restrictions and at the same > time give good enough results for students to learn the fundamentals of AI. > But I have some wishes (some fundamentals, others not so much) that make us > lose less elegant, or simpler solutions every year. > > --------------------- > || The Wishlist || > --------------------- > > Here I try to highlight those things that I have missed in more than one > situation. It is possible that some of them are easy to include in later > versions of the language (it would be perfect), others may have made more > sense through the system of extensions that the language has, perhaps there > are many that are needs for me but not for the majority of NetLogo users, > and surely there are some (I hope the least) that require changes that are > too deep to be undertaken by the maintenance and development team. Perhaps > some of them can be studied, even if it is for a possible version 7.0 of > the language. > > In any case, it does seem important to me to emphasize that the following > wish list is not seen as a reproach to the work done by the language > developers, because this list arises precisely from the interest of further > promoting a development platform that has been demonstrated for years an > innovation and capabilities that exceed the initial basic educational > objectives (most of the needs that I frame appear in the field of research, > where I have also used NetLogo for research projects, and others in higher > education, because I use it in subjects of university level). > > I apologize if some things are impossible, or the answer would be "and why > don't you do it?", I have tried some things, but my programming knowledge > has not allowed me (it seems that I have always moved out of the > environment of Java / Scala ), and I always end up thinking about how to > make a NetLogo clone in other languages, and it seems to me nonsense to end > up doing a job that already exists and it is far better than I can create > in years. > > To try to better group the wishes, I have divided them into three blocks, > although some of them may seem repetitive and it is true that they would > affect more than one block: > > 1) Environment : those that affect the programming environment that > NetLogo also provides. > > 2) Language : those that affect NetLogo as a programming language. > > 3) Extensions : those that can affect any of the two previous blocks, but > that can perhaps be solved by means of suitable extensions and not > modifying the core of the language. Here I would like to note that perhaps > an extension system was needed to handle the environment (perhaps call them > plugins, as I once thought was discussed in previous proposals), and > simplify the extension creation API for both the language and the > environment. > > Environment > ------------------ > 1) Remap some editor keys, because they don't work on non-English laptops > (or give the user the option to decide how to map them). For example, on > Spanish laptops it is impossible to modify the zoom of the application > using the keyboard. > > 2) Change the visual aspect to make it more professional. The current > version is comfortable, it is practical, but it carries a visual aspect of > more than 20 years that begins to weigh on it and that makes it > unattractive in a first approach in university and academic settings. > Ideally, it would even be easy to customize the visual aspect of the tool, > both at the application level and at the widget level. The effort recently > made in the editor improvements is greatly appreciated, but perhaps it is > time to think about a programming environment based on other available open > projects (like atom, or the like). Perhaps with proper access to NetLogo > Headless information we can do tests. > > 3) Create GUI versions of models without code access or interface > modification. A distributable interface that can call .nlogo files that > removes all the editor part and that works in the background with > NetLogo.jar would suffice . Even, perhaps you could think about the > possibility of including the intermediate compilation that the tool makes > prior to execution, and give options if this closed and distributable > version has access to the Command Center , agent inspection windows, etc ... > > 4) Functions for creating detachable widget windows. For example, of > plots. Although something similar can be done with extensions oriented > towards tabs, it would be more interesting and powerful if it is integrated > in the tool itself natively and allows the creation of independent windows. > > 5) Add the option the world to be full-interface-window/fullscreen . Many > times, you can and want to control the entire model using the keyboard and > mouse. Perhaps you could add the option of a floating or auto-hide bar to > give access to specific widgets during the execution of the model. It is a > movement to make NetLogo a complete programming language, using agent > modelling as a general programming paradigm. > > 6) Convert the Command Center into a widget. In this way, you can decide > if you want to be present or not. > > 7) Add interface tabs. Similar to what some extension already does, but > integrated into the platform natively. > > 8) Add specific widgets. At least, one for rich text and one for > displaying tabular information. Perhaps it would be enough to have one that > supports Markdown and add an extension with instructions to handle Markdown > comfortably (after all, something similar is already integrated through the > Info tab). > > 9) Allow code and interface tabs at the same time. Perhaps it would be > best if the tabs were detachable. Something similar is already done in > NetLogo Web. Many times you want to modify the program and see the result > in the model, and it is quite uncomfortable to change the tab, losing the > complete display of one of them. > > 10) Make the world one more control, that can be added or removed (hidden) > from the interface. Even the possibility of having more than one world > (something similar has already been done with an extension at the patch > level). Think about how it is decided in which world what information is > represented. > > 11) Fully manipulate the interface by code (as some extension does). > > 12) Add an option to inspect an entire family (displayed as a table of > individuals with properties in columns). Offer interaction options through > this table, and also ways to sort it by the values of the various > properties. You could even allow a little box in which to filter the > displayed agents by means of a constraint (the command accepts anything > that could be evaluated as an agentset), something like this is already > done in agent inspection. > > 13) Add sprite shapes. There was an extension going in this direction. > Which implies adding bitmaps as agent shapes. These types of improvements, > along with previous ones, would allow NetLogo to be enhanced for a > different way of programming games, for example. > > 14) Enhance the OpenGL part for 3D again. It seems to have been a bit > outdated and is a very powerful option. > > Language > -------------- > > 1) Function (apply f [x1 ... xn]) = (f x1 ... xn). In order to have a much > more faithful approach to the functional paradigm, where a good role is > already being done. > > 2) When anonymous procedures are assigned to a variable to become normal > procedures, the name of the variable becomes the name of the procedure in > the namespace. This is something that could be done in old Logo's and it > was very comfortable and natural, and it can be done in other languages > that include lambda functions. > > 3) Fix some functions to make the system more consistent. For example: > "towards" should return the angle of turn considering the turtle's > orientation, not as if it were always facing north (patches should be > considered with a fixed heading north). Instructions like "link a b" should > work receiving a and b as turtles, not their who IDs. In other words, > orient the instructions to the agents, which should be the fundamental data > structure of the language (together with the functions if they are > converted into 1st class elements). > > 4) Allow the creation of on-fly agent properties. Although it can be > expensive and inadvisable, and is only used on certain occasions (for > example, in the setup of a model), it is very interesting to be able to > define properties depending on the configuration of the model. Although it > can be simulated with a property that is a table, it is not the same. > > 5) Add a record type data structure. Perhaps it would suffice to add an > abstract agent type, which does not have a graphical representation, with > the ability to define properties at runtime, but perhaps it would be more > expensive, especially if later you want to enter several records as > properties of other agents. Anyway, abstract agents could be interesting > for providing general solutions to programming with agents. > > 6) Add the notation "." for agent and table/record properties: for > example, turtle.xcor. The "[prop] of agentset" notation would be left to > get property lists (even if it's from one only agent, which would then give > a unit list). > > 7) Give the possibility of working in a world without patches (even if it > is limited). > > 8) Make the world size representation window independent. So that you can > see a section of the world and zoom. > > 9) Add other topologies to the world. Both at the level of the geometric > structure of the patch (hexagonal, triangular), and in the neighborhood > relationships (spherical, ...). > > 10) Introduce the concept of class of agents (at least, by families), so > that some procedures are specific to each class. For example, all agents > would derive from the abstract, and links can be made between any 2 > abstracts (or derivatives). > > 11) Introduce reflections (procedures defined for each family that are > automatically executed in each step of the simulation). We have to think > about how they are arranged in time in each iteration, and how they would > work continuously. > > 12) Allow links between any types of agents ... including patches. After > all, links reflect relationships, so links are interesting to them. > > 13) Allow more than one link from the same family between two agents. It > is the user who that controls whether there is another or not. > > 14) Allow relational agents of any arity (2 = usual links). Think about > how they would be represented. Think about whether order affects. > > 15) Enrich the instructions that manipulate the mouse. For example, > control the mouse button that is pressed, add the selection of links (the > environment allows it, the language should allow it too). > > Extensions > --------------- > > 1) Add import of native libraries (made in NetLogo) unlike extensions made > in Java / Scala : import [...] / extensions [...] / include [...] . The > difference between a library and an nls is that the first one encapsulates > the content and only leaves some functions / structures visible (and may be > precompiled), while the `nls` file is just a reordering of the code. > > 2) Add a widget that allows to contain / deploy other widgets (container > type). > > 3) Add an advanced graphical extension that allows to manipulate the > drawing layer with greater freedom and flexibility (similar to the one > existed for v5). Actually, this would put it as part of the core of the > language, a greater capacity in the drawing layer. > > 4) Connect NetLogo and Julia? > > 5) Connect NetLogo and Javascript? (perhaps with an electron environment?) > > 6) Add map, filter, foreach for structures like: table, string. In > general, if a structure can be worked in a functional way, it should have > all the functions apparatus to deal with it. Although sometimes the need to > define iterators for foreach might arise, it could work with the natural > iterator. > > I hope the reading wasn't too boring. I would like to know your opinion > about this list, add new options, nuance another one, and perhaps eliminate > those considered impossible. Those of you who maintain the system are the > ones who can give a more appropriate idea of these types of options. I hope > that the opinion of an active user may be of interest to you. > > -- > You received this message because you are subscribed to the Google Groups > "netlogo-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to netlogo-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/netlogo-devel/073a2f14-a4d2-4d40-8333-81c9bd5922e2%40googlegroups.com > <https://groups.google.com/d/msgid/netlogo-devel/073a2f14-a4d2-4d40-8333-81c9bd5922e2%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "netlogo-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to netlogo-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/netlogo-devel/CAFybx9mB4armok82Mqd6A_d16iBm-9rRYFNBqnGPFsL12Fo-ag%40mail.gmail.com.
