It feels likely that once I realize the full implications of this, it will no longer seem desirable. But with my limited knowledge of type systems, I want this:

• Define a typed RMDB structure using objects.
• Create a typed SQL query using the above structure without any strings. It would make sure that I can not, e.g.:
  • Select fields that aren't among the joined tables
  • Join on an under-specified condition (e.g. not whole foreign key in join)
  • Compare incompatible data types
• Have this executed efficiently, perhaps as multiple queries.
• Finally, have the result object types be derived from the above.
  • Relations as a tree/graph of objects (not a table)
  • Field types derived from RMDB structure
  • Nullability based on join conditions
  • Not contain the fields which weren't retrieved

It seems like a stretch for the (few) type systems that I know. Using a full macro system would decrease clarity and IDE support. So I'm hoping there's some way to do these 'derived' types.

(So to be clear, I'm talking about features in a general programming language, not a DSL)

1. STRICT typecasting

2. Proper memory management double-checking during the COMPILE state to reduce if not eliminate the POSSIBILITY of memory leaks

3. An emphasis on length limited instead of null or other character termination of strings and other data to reduce if not eliminate the POSSIBILITY of memory overruns.

4. Verbose naming of library functions to avoid confusion for both beginners and advanced developers.

5. A reduction in the use of needlessly and pointlessly cryptic characters for simple operations. Joe forbid anyone have to type out words like "and" or "not"

6. ZERO distinction between binary and logical operations.

7. Access to operator flags from last mathematical operation

8. A compiler and language syntax designed from the ground up to prevent security risks.

9. Pre-declaration of variables at the functional or global scope so as to allow for better memory allocation methodology, without the 'risk' of typo's later in the code becoming new variables or hassles/headaches/idiocy of bracket level scope. Let's just say I'm NOT a fan of the new ECMAScript "let" dragging us back to practices more akin to 1970's TRS-80 Level 1 ROM BASIC

10. Proper CLEAR declaration of static values vs. immutable constants -- if for nothing else to aid in proper constant folding in the compile stage.

11. An object model with full and proper constructors and destructors, tracking of active object pointers for auto-release on exit in case a beginner cocks up (should throw a warning though).

12. An EASILY chainable entrance and exit model.

Oh wait, MOST of this already exists. It's called "ADA". Though Object Pascal will do in a pinch since it hits like two-thirds of these as well.

C is such an abortive bastard of a language, never understood how the blazes it took off, much less why so many languages are based on it given it often seems to by design encourage sloppy programming habits. Best part of C was likely left dripping down Ritchie's leg.

But again, I'm still not convinced this is an April Fools joke: gnu.org/fun/jokes/unix-hoax.html

I'd like to have a feature of Golang which is functions returning multiple values in JavaScript. Here's the code.

package main

import (
    "fmt"
)

func main() {
    str, bl, num := variadicFn("India")
    fmt.Println(str, bl, num)   // "Hello, India" true, 100
}

func variadicFn(what string) (string, bool, int) {
    return "Hello, " + what, true, 100
}