Comment by stcredzero | Hacker News Reader

Comment by stcredzero | Hacker News Reader

You don't need both modules and files. Decades of Smalltalk development experience backs this up.

Files should be an implementation detail. It should be just one back-end option out of many for persisting code.

There needs to be some way of conceptualizing a set of code. The programmer needs to perform operations on sets of code. (Merging, diffs, patches, etc...) Programmers need to store code and share it with other programmers. Files are good at doing all of these things, but none of these have anything to do with some special inherent quality only files possess.

Smalltalkers have been operating on the level of granularity of individual methods for quite awhile. It brings a lot of nice flexibility.

I would suggest that Namespaces have enough overlapping functionality with other "set of code" type entities, that they can just subsume the role of those other entities. The Java community has shown that it's workable for every project to have its own namespace. Namespaces also resolve a lot of name collision problems that keep cropping up. (Isn't that dandy?)

EDIT: The entire set of libraries for a variety of programming languages is readily available. It would be a cool project to re-granulize the commonly used library corpus for a particular programming language at the level of individual functions. There would be a lot of small-granularity dependency information that wouldn't be available but some of it could be inferred. Statically typed languages could have more of it inferred than dynamically typed languages, but there could still be a lot for the latter.

Plain text files are a communication protocol.

Files allow you to give code to your friends without extraordinary means, to use generalized programs like git and grep, and to post a copy up on the web.

Files also mean that your IDE doesn't have to try to be an OS. (Still can if it wants to, hello Emacs.)

Plain text files are a communication protocol.

That's just plain wrong. They are something you can send over communication protocols. They are a very useful tool for sharing, transmitting, and storing information. I'm fine with files as all of those things. When files subsume conceptual territory -- this is when there's inertia.

It would be like people insisting that novels can only exist in the form of bound rectangular slabs of dead tree. Once you free concepts from implementation details, new flexibility is enabled.

Files allow you to give code to your friends without extraordinary means, to use generalized programs like git and grep, and to post a copy up on the web.

Yes, but to fulfill these functions, they do not have to stake out conceptual territory, like becoming the granularity at which your version control system must operate. Again, decades of Smalltalk development shows that you can use files to give code to friends, use programs like git (Monticello is git for Smalltalk) and grep, and post copies on the web. Smalltalkers do all of the above without files subsuming more conceptual function than just being files -- a particular means of storing and sharing information.

So what plain-text source encodings are is a serialization format. Now that's interesting, because running with that thought, what if there were multiple equivalent serializations for the same program? What if one were more convenient than another for certain transformations? Would that let us build better tools?

At some level, and in some domains, this already exists: the multiple serializations of RDF (N3, Turtle, RDF/XML, etc) plus OWL is very loosely equivalent to Prolog. There are very popular domain-specific non-textual programming environments too – the three obvious ones are Excel, LabVIEW and Max/MSP.

There's got to be something in that for someone.

So what plain-text source encodings are is a serialization format.

Thank you! Well put! Actually, source code is just a human-readable serialization format. There's a lot to be done with that idea as well.

Isn't a lot of this the whole Lisp thing again? (The human-readable serialization format for Lisp is, as I understand it, damn close to being an ASCII serialization of the AST for Lisp, hence...)

Well, yes and no. Lisp is an ASCII serialization of the Lisp AST. This isn't true for most other languages. There is no reason why source for most languages couldn't be serialized as a combination of the AST and the stream of lexical tokens. This would have a few interesting advantages. For example, everyone could have the source formatting of their preference.

EDIT: Another example -- someone could implement a language homomorphic with Python without significant whitespace and curly brackets.

Even for lisp, you would have to define an extended syntax for it and modify the parser to additionally read and store whitespaces, comments and newlines. This way you will be able to serialize your source to plaintext without loosing the original format. Non text sourcecode also allows for way smarter tooling, tree diffs on the AST, graphical repls and improved rendering of sourcecode.

Even for lisp, you would have to define an extended syntax for it and modify the parser to additionally read and store whitespaces, comments and newlines.

Note I said AST + stream of lexical tokens. If you store the whitespace and comments as tokens, such information can be preserved, including formatting hints.

Minor pedantry: Most variants of Lisp are not precisely a serialization of the AST. The read engine and macro engines have to pass over the code before it is truly an AST. For Common Lisp I believe technically either can be invoked at any time, but I am not a Common Lisp language lawyer.

I took the "flat" approach in the Loom server code (see https://loom.cc/source). Formerly I used all the object-oriented module techniques, but finally I scrapped all that for direct calls to functions in a flat name space. I found it more flexible and easier to understand, and it didn't force me to think about artificial boundaries. This makes the Perl code similar to my C code. I don't even use many static functions in C, preferring everything to have a unique name.

I also wrote a functional language interpreter in C. The language is called Fexl (see http://fexl.com/code/). The C code obviously uses a uniquely named flat function space. However, the Fexl language itself has far more flexibility, since you can easily create functions within functions.

For example you can easily do things like this:

  \test_print =
  (
      \test1 = ...
      \test2 = ...
      ...
  )

  \test_read =
  (
      \test1 = ...
      \test2 = ...
      ...
  )

In that case you're not at all worried about the names test1 and test2 conflicting with anything else. It's very lightweight, just like the Fibonacci example shown on this thread.

If you really want to "export" functions declared inside a scope, you can do it like this:

  \handy_module =
  (
      ...
      \fun1 = ...
      \fun2 = ...

      \return return fun1 fun2
  )

Then to grab the functions you say:

  handy_module \fun1 \fun2 ... (now use fun1 and fun2)

You can change the names too, like this:

  handy_module \f1 \f2 ... (now use f1 and f2)

There's no extra magic in the language, you're just applying the module to a handler which grabs the exported functions.

> You don't need both modules and files. Decades of Smalltalk development experience backs this up.

While decades of elisp development shows us that without modules, nobody will want to use your language to write programs spanning more than one file. =\

Yes, you definitely need modules. But I think there are better ways of using modules than we have been.

Reply on news.ycombinator.com