5 ms·

If you think about it, a decent stack is composed of languages. That's currently already often true, e.g. the use of IDL languages like protobuf/flatbuffers. So

If you think about it, a decent stack is composed of languages. That's currently already often true, e.g. the use of IDL languages like protobuf/flatbuffers. Some languages offer integrated idl like Kotlin (data classes). Another example is html, where the UI is described using a dsl to specify elements and CSS for layout & appearance. This fact caused me to think: should stack also not be made of other languages? Is there a place for a completely pure functional language? I mean, Haskell is nice, but get a bit awkward with I/O. Same for APL. C# has nicely integrated data querying, but from a distance is actually at least somewhat awkward. C# seems to be optimized for mutable domain objects; everything else can be nicely done but falls somewhat outside it's "identity". I would love to be able to express functions, functors and math using a terse math-y language. Whether that be APL or some sort of blend of Haskell and APL (Haspell? spelling pun intended), I don't care, but it would be great if we can have nice integrations of these languages in a full stack. Sort-of like how TypeScript and JavaScript have dialects to enable React syntax to express HTML within it. The same thought experiment can be applied to SQL. Can we have a data-querying language integrated right into, say, C# or Java?

opnitro 8y ago
The language Racket (https://racket-lang.org https://racket-lang.org) sort of approaches this. It allows you to quickly switch which compiler a given source file is actually sent into, the goal being that you solve each problem with sub-languages particularly suited to the task at hand. For instance, the webserver language has HTML build in as a primitive.
mattnewport 8y ago
C# kinda does have a data querying language built right in with LINQ query expressions, although they seem to have rather fallen out of favor.
- rjbwork 8y ago
  Indeed. But you can still write functional style data querying languages using LINQ extension methods. IMO, LINQ based DB querying is revolutionary in terms of the flexibility and capabilities it provides. For complex Relational DB querying it's pretty great. I tend to write raw SQL using Dapper these days, because hey, scalability and such, but for business apps and non-cloud apps, EF and other LINQ-based DB tools are great.
sshine 8y ago
The ML family (SML, Ocaml, F#) is also pretty good with the mixture of functional and imperative constructs. Having a part of the program known to be pure at compile-time, but another part effectful is something you see in the language F* (http://fstar-lang.org http://fstar-lang.org) - here you get monads, dependent types, a proof system, and the ML module system neatly packed into a general-purpose programming language. Not as widely popular as O'Caml, F# or Haskell, but both as practical as Ocaml and as researchy as Haskell. Also there's a free tutorial/book on the website.
- sharpercoder 8y ago
  The heart of my argument is mostly that integration in main languages should be pursued. F# can be mixed on assembly (project) level, but not on source level (like css in html or html in js/ts).
tabtab 8y ago
Re: The same thought experiment can be applied to SQL I am a fan of "Table Oriented Programming" and believe OOP forced an unfortunate shift from data-oriented programming to code-oriented programming. I hope the pendulum swings back. APL is intended for mostly scientific applications, but it has some nice lessons for other domains, and RDBMS may be a door into common data-oriented programming. I also believe that "Dynamic Relational" is needed to improve data-oriented mock-ups, experiments, and small-scale projects. The existing RDBMS are too "stiff" for some needs. We have dynamic programming languages, so why not for databases? Yes, there are some dynamic query languages, but they require throwing out SQL and starting from scratch, which cranks up the re-learning curve. Dynamic Relational only requires minor changes to SQL. (SQL ain't perfect, but so far a decent replacement has yet to gain traction. I'm personally a SMEQL fan.)

opnitro 8y ago

The language Racket (https://racket-lang.org https://racket-lang.org) sort of approaches this. It allows you to quickly switch which compiler a given source file is actually sent into, the goal being that you solve each problem with sub-languages particularly suited to the task at hand. For instance, the webserver language has HTML build in as a primitive.

mattnewport 8y ago

C# kinda does have a data querying language built right in with LINQ query expressions, although they seem to have rather fallen out of favor.

rjbwork 8y ago
Indeed. But you can still write functional style data querying languages using LINQ extension methods. IMO, LINQ based DB querying is revolutionary in terms of the flexibility and capabilities it provides. For complex Relational DB querying it's pretty great. I tend to write raw SQL using Dapper these days, because hey, scalability and such, but for business apps and non-cloud apps, EF and other LINQ-based DB tools are great.

sshine 8y ago

The ML family (SML, Ocaml, F#) is also pretty good with the mixture of functional and imperative constructs. Having a part of the program known to be pure at compile-time, but another part effectful is something you see in the language F* (http://fstar-lang.org http://fstar-lang.org) - here you get monads, dependent types, a proof system, and the ML module system neatly packed into a general-purpose programming language. Not as widely popular as O'Caml, F# or Haskell, but both as practical as Ocaml and as researchy as Haskell. Also there's a free tutorial/book on the website.

sharpercoder 8y ago
The heart of my argument is mostly that integration in main languages should be pursued. F# can be mixed on assembly (project) level, but not on source level (like css in html or html in js/ts).

tabtab 8y ago

Re: The same thought experiment can be applied to SQL I am a fan of "Table Oriented Programming" and believe OOP forced an unfortunate shift from data-oriented programming to code-oriented programming. I hope the pendulum swings back. APL is intended for mostly scientific applications, but it has some nice lessons for other domains, and RDBMS may be a door into common data-oriented programming. I also believe that "Dynamic Relational" is needed to improve data-oriented mock-ups, experiments, and small-scale projects. The existing RDBMS are too "stiff" for some needs. We have dynamic programming languages, so why not for databases? Yes, there are some dynamic query languages, but they require throwing out SQL and starting from scratch, which cranks up the re-learning curve. Dynamic Relational only requires minor changes to SQL. (SQL ain't perfect, but so far a decent replacement has yet to gain traction. I'm personally a SMEQL fan.)