tag:blogger.com,1999:blog-2447174102813539049.post7827736697957440885..comments2024-03-28T22:55:13.453-07:00Comments on Room 101: Nail FilesGilad Brachahttp://www.blogger.com/profile/17934280339206214042noreply@blogger.comBlogger38125tag:blogger.com,1999:blog-2447174102813539049.post-92187617650362254292011-04-11T01:08:46.750-07:002011-04-11T01:08:46.750-07:00Gilad,
I agre to your article. But I don't re...Gilad,<br /><br />I agre to your article. But I don't really care if it is files or a database. The strange thing to me is that we take it for granted that volatile object memory and persistence have to be two separate things and that this distinction is natural.<br /><br />To me it is not. Whatever kind of object memory I choose I want all data to be just in there, kept with proper meta-data attached. This is the reason why I'm doing most of my work with gemstone. And I'm really interested in every LOOM architecture that will appear in the near future. Using filesystems is just one solution for the shortcomings of main memory in computers. The design that the act of persisting is a manual act remembers me of memory management. I want to have a garbage collector that manages my memory usage and I want to have something like LOOM that manages memory storage automatically. <br /><br />With the advent of SSDs being on the market we can get an impression that the gap between main memory and disk spindles can be made closer. If we imagine that there is no gap and every main memory is persisted at the same time who will argue about files? If there is no gap we don't have to deal with files and source code changes will be more like changesets than source code file diffs. What a wonderful world!Norbert Hartlhttps://www.blogger.com/profile/15761295807474363784noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-49180652367841650652010-03-08T09:26:08.395-08:002010-03-08T09:26:08.395-08:00@Tasos: The benefits of module declarations in the...@Tasos: The benefits of module declarations in the source are to the human readers of the code. By contrast, the "points" in slide 15 are about tools, not humans. A programming language should be designed for the benefit of the human programmers.<br /><br />Suggesting that there is a benefit that a module system can override what appears in the source makes no sense. That seems to be the basis for not supporting the module declarations. It also makes no sense to say that the system is "agnostic" to module declaration appearing in the source, if there is no source syntax for it and any source syntax could be overridden and not enforced at runtime. The logic is impeccable - because the current module specification ignores any module declaration in source, they might as well not be supported. But they should not be ignored in source.<br /><br />As for the disadvantages on slide 16: most of them don't seem to be disadvantages. "Makes easy case hard + hard case easy" could be considered a disadvantage, but adding module declarations to the sources actually makes the easy case easy too.Neal Gafterhttps://www.blogger.com/profile/08579466817032124881noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-68984271601468701842010-03-08T03:14:44.501-08:002010-03-08T03:14:44.501-08:00Slides 15 and 16 describe the issues around module...Slides 15 and 16 describe the issues around module membership in source: openjdk.java.net/projects/jigsaw/doc/ModulesAndJavac.pdf<br /><br />@Neal: What are your counter-arguments to the ones in the slides? Or the benefits/issues of an alternative approach?Unknownhttps://www.blogger.com/profile/18375001413949174146noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-66839036891437198002010-02-27T13:49:02.610-08:002010-02-27T13:49:02.610-08:00@Tasos: The package declaration says what package ...@Tasos: The package declaration says what package a source file is in, which is a completely different thing from what module it is in.<br /><br />While it is true that the host system determines what packages are visible, that is generally done on the basis of what source and class files you give the compiler. If a given source file is visible, its meaning is defined by the language specification. The host system does not determine which classes are in which packages - that is defined by the source.<br /><br />I would hope a similar mechanism would be used for modules as is used for packages (if the compiler is given the sources or class files etc, then they're visible), but the draft specs for modules has the host system determine not only visibility but also which module each source file (and class file!) belongs to, and therefore what the meaning of the source (and class) file is.Neal Gafterhttps://www.blogger.com/profile/08579466817032124881noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-73927152162308650342010-02-27T13:27:50.138-08:002010-02-27T13:27:50.138-08:00@Neal
Are you saying that javac can't use the ...@Neal<br />Are you saying that javac can't use the package declaration in the source files?<br />I remember listening to Alex Buckley on a JavaPosse interview state that the JLS doesn't define any mechanisms and leaves it to the "host system".<br />I have checked the JLS chapter on packages and I haven't found Alex's comment to be incorrect.<br />Am I misunderstanding you and we talk about different things?Unknownhttps://www.blogger.com/profile/18375001413949174146noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-67996009316705762342010-02-26T08:38:03.109-08:002010-02-26T08:38:03.109-08:00@Tasos javac can't use something appearing in ...@Tasos javac can't use something appearing in the syntax unless the Java Language Specification describes that as part of the Java language, and I think that would be a good thing. But that does not appear to be what's happening.Neal Gafterhttps://www.blogger.com/profile/08579466817032124881noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-51939320626390612142010-02-26T08:35:42.187-08:002010-02-26T08:35:42.187-08:00@Neil:
"But the compiler determines what modu...@Neil:<br />"But the compiler determines what module a Java source file belongs to not by something appearing in its syntax, but by its placement in the file system."<br />"I object to the layout in the file system being part of the language."<br /><br />My understanding is that this is a convention followed by javac and not part of the language.<br />Is this not the case?<br /><br />I assume the javac of JDK7 could just avoid such a file-location check and use "something appearing in [the] syntax".Unknownhttps://www.blogger.com/profile/18375001413949174146noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-47091742292417299112010-02-09T14:47:00.715-08:002010-02-09T14:47:00.715-08:00Neal:
"Java has, traditionally, been based o...Neal:<br /><br />"Java has, traditionally, been based on the principle that the sources rule"<br /><br />Your sense of humor is so refined. Binary compatibility (JLS 13) is based on the idea of running programs that correspond to no legal source whatsoever.Gilad Brachahttps://www.blogger.com/profile/17934280339206214042noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-4705389529359935642010-02-09T14:17:18.435-08:002010-02-09T14:17:18.435-08:00@Alex: It is too late to change .NET's handlin...@Alex: It is too late to change .NET's handling of source assemblies, so there is no point attempting to redesign them, no matter how much the redesign might improve on them. It isn't too late to change Java's handling of modules. You can assume that .NET's solution is worth emulating. In that case, the compiler would define an assembly as the set of sources being compiled at once, and produce a binary assembly (jam file, presumably) directly instead of producing .class files. Or you can avoid that assumption and reason from first principles. You don't appear to have done either.<br /><br />To add to that, one of the things that distinguishes the .NET software world from the Java software world is that Java has, traditionally, been based on the principle that the sources rule. There are a few exceptions - for example, *-imports don't explicitly name the things that they import, and you need to go to the target to see what you got. It is perfectly reasonable to develop Java code with emacs or vi. C#, on the other hand, was designed assuming that you write and read code with the assistance of tools. C#'s "using" directive is equivalent to Java's *-import. It is possible, but painful, to import names singly.<br /><br />Many decisions that differ between Java and C# reflect these differing principles. It isn't reasonable to blindly emulate features of C# that were designed based on different principles.Neal Gafterhttps://www.blogger.com/profile/08579466817032124881noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-36681533015079968182010-02-04T09:23:37.423-08:002010-02-04T09:23:37.423-08:00This harks me back to my 2002 presentation on data...This harks me back to my 2002 presentation on database as a backend storage for the CAD program dev I was involved in. The entire team saw it as heretical to move away from dwg and dxf to a DB table structure. I see strong reasons beyond the quoted ease, efficiency, speed, security to the extended capability of distributed per object locking and editability of complex drawings by multiple people synchronously.<br /><br />Just to extend this thought down to a simple application level capability.skrishnamacharihttps://www.blogger.com/profile/07232888998684221393noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-71545727910465948532010-02-02T16:41:49.653-08:002010-02-02T16:41:49.653-08:00@Neal: So .NET doesn't need a reason to keep a...@Neal: So .NET doesn't need a reason to keep assembly identification out of compilation units; but Java does need a reason to keep module identification out of compilation units? Something isn't right. I do not believe the constraints on .NET were different than those currently faced by Java. Perhaps you could expand on them?Alex Buckleyhttps://www.blogger.com/profile/12559932534649195508noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-28289650605717622542010-02-02T14:43:12.263-08:002010-02-02T14:43:12.263-08:00@Alex: one doesn't need a reason not to do som...@Alex: one doesn't need a reason not to do something. There was a great deal of history constraining the solutions available, which are different than the constraints on Java.Neal Gafterhttps://www.blogger.com/profile/08579466817032124881noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-52730133634322561602010-02-02T14:36:13.953-08:002010-02-02T14:36:13.953-08:00@Neal: One could. Yet they didn't. Why not?@Neal: One could. Yet they didn't. Why not?Alex Buckleyhttps://www.blogger.com/profile/12559932534649195508noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-18020492971951019122010-02-02T08:05:08.969-08:002010-02-02T08:05:08.969-08:00@AlexBuckley: Indeed, one could implement 'int...@AlexBuckley: Indeed, one could implement 'internal' accessibility in .NET by identifying the assembly in individual compilation units.Neal Gafterhttps://www.blogger.com/profile/08579466817032124881noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-61918168769851619502010-02-02T05:52:07.439-08:002010-02-02T05:52:07.439-08:00@martin: In HTML5, I bet many people will just use...@martin: In HTML5, I bet many people will just use strings like "this/path/name" to emulate the missing hierarchy, which is the best solution whenever one needs more than a handful of file^H^H^H^Hresources. ;-) The JavaFX 1.2 I/O API (javafx.io. Resource/Storage) is an interesting tradeoff: it does support hierarchical pathnames and even absolute pathnames (within the sandbox access restriction for applets/JAWS), but at the same time it's enough abstract/high-level to not depend on full-blown filesystem services (so it's portable to JavaME), still its Resource objects look like files (named things that can be read/written with the standard java.io APIs InputStream/OutputStream) so it doesn't suck as much as MIDP's RMS even though it's actually less-featured (no indexed-records layer atop the files). This (FX, not RMS) is the right model for ANY platform-level API: just give me simple, hierarchical files that are binary blobs; if I need anything better like a SQL or other kind of database, I can implement that using files as storage.Osvaldo Doederleinhttps://www.blogger.com/profile/05264918260779798314noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-4307709000251175702010-02-02T05:39:22.588-08:002010-02-02T05:39:22.588-08:00@Neal, @Alex: Indeed, the JLS leaves package organ...@Neal, @Alex: Indeed, the JLS leaves package organization as a host-specific decision and only mentions the package=directory model as an example. (It's even funny to read this ancient part of the JLS: the example uses "gls" as a root package/folder for classes from Guy Steele, etc... nobody uses this convention today for personal projects (well, unless there are TLDs like gls).)<br /><br />Even the restriction that public top-level types fit in a source file with identical name is only a recommendation ("MAY"). From my reading of JLS 7.6, it's fine to write a compiler that allows "public class A {...} public class B {...}" all in a single file named "C.osvaldo". (The ".java" extension is specifically documented not-mandatory.) The classfile format only enforces the filename==top-level-type restriction, and IMHO that's a mistake but for other reasons (efficiency of constant pool encodings etc.) The classfile's package==folder restriction is arguably just an implementation detail of classloaders, I could write a valid classloader that does not enforce this in any way. packaging/distribution formats like ZIP/JAR/Pack200 are mostly non-normative, only details like Manifests.<br /><br />OTOH, the tradition of the behavior of javac and all standard classloaders and other tools, is terribly strong. But we could change javac to relax these restrictions; this would break many pieces of the larger Java toolchain, but who cares? next month we'd have updates of most of the important stuff like Ant, etc.; new JDK releases always breaks many of these tools with a updated classfile format that requires new low-level parsers.Osvaldo Doederleinhttps://www.blogger.com/profile/05264918260779798314noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-61296323392341515002010-02-02T02:11:16.637-08:002010-02-02T02:11:16.637-08:00I think the success of the file system is due to i...I think the success of the file system is due to its conceptual simplicity and flexibility. See UNIX, everything is a file. Security is also rather easier than more complex in a file system: files have permissions attached, which is again a conceptually simple system.<br /><br />The APIs like in HTML5 that I have seen so far do not provide this flexibility, and they certainly don't provide any security. What keeps you from executing code that has been downloaded into some object store? HTML5 in particular doesn't even support hierarchies, objects are simply stored in a hash map.<br /><br />Regarding the "higher abstraction level" above simple byte streams - yes and no. The problem is IMHO that there is no single data model that fits all. Files have the flexibility of storing anything you want, and if you want a relational data model, you simply use sqlite and store that in a file.<br /><br />These newer APIs so far support tree structured data entries (no graphs!), but there is nothing supporting e.g. meaningful queries over these tree items, which is pretty bad. You don't even have the standard file system metadata.<br /><br />So, I think we are certainly not there yet. I don't know of a really convincing programming model for data storage. I think the storing trees thing is a step in the right direction, but without meaningful queries it's not really helping all that much.<br /><br />Though this is all of course unrelated to the question whether programming languages should express their compilation units as files, which clearly a bad idea.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-47845333001427438292010-02-01T22:56:24.713-08:002010-02-01T22:56:24.713-08:00@Neal: It is true that the Java programming langua...@Neal: It is true that the Java programming language does not associate a compilation unit with a module. The association is left up to the host system. File system layout may or may not factor into the host system's decision.<br /><br />The reason for this approach is that modules are not just access control for a group of packages, i.e. are not just "super packages". Modules' true utility comes from the visibility information present in what must be a central specification, e.g. an OSGi manifest. Visibility has always been up to the host system; witness "observability" in the JLS.<br /><br />The accessibility aspect of modules is secondary. It is possible to put module identification in individual Java compilation units, but it is not practical. If you work out a way to implement 'internal' accessibility in .NET without putting assembly information in individual compilation units, let us know!Alex Buckleyhttps://www.blogger.com/profile/12559932534649195508noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-7392319499941742322010-02-01T16:08:45.658-08:002010-02-01T16:08:45.658-08:00@Michael: No need for that lost URL; I can track e...@Michael: No need for that lost URL; I can track evidence e.g. to the Sankhya (Hindu metaphysic theory behind Yoga and other traditions). It contains elaborate, hierarchical descriptions of the cosmos and the human mind/body.Osvaldo Doederleinhttps://www.blogger.com/profile/05264918260779798314noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-15618621101903136742010-02-01T14:36:47.584-08:002010-02-01T14:36:47.584-08:00Osvaldo:
A concrete proposal is a bit more than t...Osvaldo:<br /><br />A concrete proposal is a bit more than these margins can contain :-). But some random related thoughts:<br /><br />a. Your suggestion may be fine.<br />b. Strongtalk is a Smalltalk w/o an image. Your program is preserved in both source and binary forms (admittedly a specific format) and recovering from crashes is a usually a snap.<br />c. Your IDE is welcome to spit out files on an ongoing basis as a backup. I just don't want to see them.<br />d. SCMs are a pain. Some level of customized connector is inevitable. U<br />e. Ultimately, I want the platform to be a generalized SCM and object database. This is what "objects as software services" advocates.Gilad Brachahttps://www.blogger.com/profile/17934280339206214042noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-78718551678256003712010-02-01T14:31:50.344-08:002010-02-01T14:31:50.344-08:00@Osvaldo: My suggestion is to avoid encoding progr...@Osvaldo: My suggestion is to avoid encoding programming language semantics in the layout of the files in the file system. I don't really care if you use the file system to store the bags of bits that are the source files. I object to the layout in the file system being part of the language.Neal Gafterhttps://www.blogger.com/profile/08579466817032124881noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-87804268455128729532010-02-01T14:26:38.671-08:002010-02-01T14:26:38.671-08:00@Osvaldo: this is not a coincidence, organizing th...@Osvaldo: this is not a coincidence, organizing things hierarchically is actually embedded in the human brain. Our social structures - governments, corporations, communities - are organized that way, it is just natural for humans. <br />Unfortunately I forgot to tag the URL so I can't find the source for that claim, sorry.Buddy Casinohttps://www.blogger.com/profile/03101816178913331505noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-90739955998081622542010-02-01T14:26:05.470-08:002010-02-01T14:26:05.470-08:00Mike:
There's more in your comment than I can...Mike:<br /><br />There's more in your comment than I can respond to, but, FWIW:<br /><br />a. File systems get corrupted too. <br />b. Once you could tinker with electronics; it's hard to get inside a chip. Same with automobile engines. No user serviceable parts. Fact of life.Gilad Brachahttps://www.blogger.com/profile/17934280339206214042noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-53835909318308264692010-02-01T14:12:09.762-08:002010-02-01T14:12:09.762-08:00Fred: I know the "RESTful URL" is just a...Fred: I know the "RESTful URL" is just a convention, but it's a very popular one. In fact this convention came from Ruby on Rails and it's being increasingly adopted by other web frameworks. Perhaps the focus is not human-readability, but rather, developers love for hierarchies... they surely make things easy to organize and find. The Tree is such a lovely, no-brainer general-purpose data structure, as any XML devotee will remember us. ;-)Osvaldo Doederleinhttps://www.blogger.com/profile/05264918260779798314noreply@blogger.comtag:blogger.com,1999:blog-2447174102813539049.post-10992514347296027592010-02-01T14:05:34.584-08:002010-02-01T14:05:34.584-08:00Gilad(+Neal): What is your concrete suggestion? I ...Gilad(+Neal): What is your concrete suggestion? I have used a bit of ST (and a lot of VA/Java), and the "image" has its own problems. It's brittle, fragile. An opaque, binary, typically proprietary and hideously complex blob. If it's corrupt, you can't fix it. If the IDE/VM has no connector to a specific SCM, you can't use that SCM (ENVY was great for its time, but was also lock-in). As Mike remembers wrt VisualAge, the image was a love/hate thing. Both options (files/images) being imperfect, in the and the victory went to the option that was more open, simple, interoperable and robust.<br /><br />Today, perhaps we could just stuff all code (and even objects? for ST-like experience of "live image") in a good embeddable/lightweight RDBMS, with a standard data dictionary for the core artifacts that many diverse tools must manipulate, and then extended tables for tool-specific features. This might be a best-of-both-world solution.Osvaldo Doederleinhttps://www.blogger.com/profile/05264918260779798314noreply@blogger.com