Maybe it is that through my work I use a half dozen languages, where it is hard to remember each in detail.

I have also worked on a javascript project where there were no imports/requires and the build process created one file. So you had to inspect the confusing build script to even know what was what.

And especially how I can choose the best way to indicate the sources of names in my code:

   import time
   t = time.perf_counter()

   import time, my_module
   t1 = time.perf_counter()
   t2 = my_module.perf_counter()

   from time import perf_counter as std_counter
   from my_module import perf_counter as my_counter
   t1 = std_counter()
   t2 = my_counter()

   try:
       from my_module import perf_counter
   except ImportError:
       # Fall back to standard implementation
       from time import perf_counter
   t = perf_counter()

   # import time as m  
   import my_module as m
   t = m.perf_counter()

Yikes; you're renaming/aliasing global identifiers! Just no.

Build processes creating one file is the seven decade norm in computing.

Even if you literally don't catenate the .js files into one, they get loaded into one running image one way or another.

  long %s stringnicely breaks upwith indentation and all"

I think scala’s mkString (https://superruzafa.github.io/visual-scala-reference/mkStrin...) is the best solution, visually, for such things, but unfortunately, it would require hackers in the parser to do the concatenation at compile time, where possible.

Scala’s multiline strings look nice, too, if you want to insert newlines, except for the stripMargin thing (https://docs.scala-lang.org/overviews/scala-book/two-notes-a...)

  "foo" "bar"     // error
  "foo " "bar"    // OK
  "foo" " bar"    // OK
  "foo" "" "bar"  // OK: "" doesn't start with non-whitespace, since it's empty
  "foo" " " "bar" // OK

All we have to do is to implement a compiler warning which detects when the rule is violated.

Users who implement it have to fix situations like "foo" "bar" into "foo" "" "bar".

Probably the rules should be smarter. Some kind of tokenization concept could be at play so that gluing together two letters or digits is bad, or two punctuation tokens, but letter/number and punctuation is okay.

  "foo" "1"     // error? OK?
  "foo" "bar"   // error
  "foo" ".bar"  // OK
  "1." "2" ".3" // OK
 
  "1." ".2"     // error: punct-punct

The alternative is what exactly? Have the entire standard library exposed at once? Make all modules create non-conflicting names for exported objects, so that the json parse function has to be called json_parse and the csv parse function has to be called csv_parse?

Seems less than ideal to me.

If these things are classes in a plain old single-dispatch oop system, you can havec a json-parser and csv-parser which have parse methods.

There could be packages/namespaces. So csv:parse and json:parse. These packages are standard and so they just exist; nothing to import.

In Python, you cannot use anything without an import! The top-level modules (which serve as de facto namespaces) themselves are not visible.

Say there is a csv module with a parse. You cannot just do:

  csv.parse(...)

  import csv

I will not Go lang has the same feature carried forward from C. It helps a lot in the reading code side of the code lifecycle. And Go compiler makes you keep the imports up to date, which is good.

It lets you debug Python problems which the system created in the first place.

> If they have some weirdly screwed up paths with multiple pythons installed and multiple copies of the modules etc., same.

Doesn't happen in a sane language. Or, even not a sanely defined language/implementation.

I can easily have multiple different GCC copies (possibly for different processor targets) on the same machine. Each one knows where its own files are; an #include <stdio.h> compiled with your /path/to/arm-linux-eabi-gcc will positively not use your /usr/include/stdio.h, unless you explicitly do stupid things, like -I/usr/include on the command line.

[1]: https://github.com/gilch/hissp

It can be slightly inconvenient but doesn’t feel moronic to me. It means that except for the built-in functions, everything can be traced to either a definition or an import. Makes tracking code much easier.

  from python import def  # now you can def

   @"
  here strings in PS are fine for this purpose and 
   even allows whitespace anywhere            
    but because of the latter you can't indent it    
     with your other code   
 "@ -split "`r`n" | % {'<SOL>{0}<EOL>' -f $_ }
 <SOL>    here strings in PS are fine for this purpose and <EOL>
 <SOL>     even allows whitespace anywhere            <EOL>
 <SOL>      but because of the latter you can't indent it    <EOL>
 <SOL>       with your other code   <EOL>

https://unix.stackexchange.com/questions/76481/cant-indent-h...

And backslash doesn’t let you have the literal obey the proper indenting. Might as well use “””

I don't want to be finding definitions of things that the language provides in the code.

Languages that don't work this way have IDE's, editor plug-ins or other tools for easily finding the definitions of things that are in the language, without hunting for them through intermediate definition steps in the same file.

"I've spent all my life in and out of jails, so I expect bars on doors and windows ..."

If the language supports json, it should just do that.

  1> #J[1,2,3]
  #(1.0 2.0 3.0)
  2> (get-json "[1,2,3,{\"foo\":true}]")
  #(1.0 2.0 3.0 #H(() ("foo" t)))
  3> (put-json #(1.0 2.0 t))
  [1,2,true]t

    $ irb
    irb(main):001:0> { hello: "world" }.to_json
    NoMethodError (undefined method `to_json' for {:hello=>"world"}:Hash)

    irb(main):002:0> require 'json'
    irb(main):003:0> { hello: "world" }.to_json
    => "{\"hello\":\"world\"}"

If it was CLOS with multiple dispatch, it would be easier to swallow. Because it would look like:

   (to-json { hello: "world" })
   ;; error: no such function!

I regard the ability to add new methods to a class as good, but with a valid use case, like extending some third party piece with new methods in your own application. And the fact of not having to declare methods in a class definition, which is cumbersome. Just write a new method in that class's file, at the bottom, and there it is.

I ideally don't want that third-party piece itself to be divided into three pieces that I have to separately load to get all of the methods. Or worse, pieces from separate third parties that add methods to each other.

I copied a thing or two from Ruby in TXR Lisp. The object system as a derived hook, and that was inspired by something in Ruby:

  1> (defstruct foo ()
       (:function derived (super sub) (prinl `derived @super @sub`)))
  #<struct-type foo>
  2> (defstruct bar foo)
  "derived #<struct-type foo> #<struct-type bar>"
  #<struct-type bar>
  3> (defstruct xyzzy bar)
  "derived #<struct-type bar> #<struct-type xyzzy>"
  #<struct-type xyzzy>

It's an essential feature used in all sorts of everyday code.

C99 added printf conversion specifiers that are hidden behind macros, and idomatic usage of them relies on string catenation.

  uint32_t x = 0;

  printf("x = " PRIx32 "\n", x);

All sorts of C macrology relies on string catenation. Kernel print messages:

  printk(KERN_EMERG "%s: temperature sensor indicates fire!", dev->name);
                   ^ must not have comma here

Although I just had a (logging) use case in go where I missed cpp macros - wanted the log statement to get something from the file and just had to pass it in as another parameter.

If I have a uint32_t which needs printing I cast it to (unsigned long) and use %lu or %lx. This requires more typing in the argument list, but keeps the format string tidy. It's important for the format string to be tidy, because that's the reason of its existence: to clearly and concisely convey the shape of what is being printed.

That would be adding 2 pointers, and that's indeed illegal.

However, you can subtract them: “abc” - “def” . Now, the result is not a pointer any more, it's a ptrdiff_t (an integer type), so most compilers will warn if you try to assign that to a char *.

String catenation ("adding") by adjacency (no visible operator) is a thing; "add" doesn't imply that we are talking about a + operator:

  $ awk 'BEGIN { x = "abc-" 2 + 2 "-def"; print x}'
  abc-4-def

  execl("/bin/sh", "/bin/sh", "-c"
        "echo foo", (char *) NULL);

Initializers are another example:

  char *strArray[] = {
    "how", "now"
    "brown", "cow"
  };