Hi Ken, Thanks for your reply. I am pretty sure that in NetLogo Web is easier to get some points of my list... and it is wonderful that you have tried it!!, are there any documentation about your work?
All the best, Fernando Sancho Caparrini Dpt. Computer Science and Artificial Intelligence University of Seville http://www.cs.us.es/~fsancho/ El sáb., 18 abr. 2020 a las 5:16, Ken Kahn (<toont...@gmail.com>) escribió: > 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/CAB20aB90dAMUqWwKvBzkWjuxLT-iaHrrRytJ1j5Af1a3TQS5Qw%40mail.gmail.com.
