[HN Gopher] What's next for language design? (2017)
___________________________________________________________________
What's next for language design? (2017)
Author : isaacimagine
Score : 64 points
Date : 2021-11-21 19:48 UTC (3 hours ago)
(HTM) web link (graydon2.dreamwidth.org)
(TXT) w3m dump (graydon2.dreamwidth.org)
| [deleted]
| mikewarot wrote:
| Mixing procedural and reactive code in the same program. Imagine
| if A := B worked in the normal pascal assignment sense, but A
| :<<: B caused A to be recalculated every time B changed, like a
| magical assignment operator.
|
| If you assigned something to the system clock, it would act like
| an interval timer, for example.
| bsiemon wrote:
| https://svelte.dev/ is an example of this idea.
| gameswithgo wrote:
| F# has had a few of these features for a long time
| matu3ba wrote:
| Unfortunately the author is not very explicit on the interesting
| formal stuff: 1.implicit and 2.explicit proof-carrying code and
| 3. verifying compilers with its cost (there are as of today
| exactly 2 general usable and fully verified compiler
| implementations: compcert and cakeml), 4. lowering languages to
| Isabelle or other interesting proof systems as compiler backends
| (or using codegen for source code and proof like what cogent
| does).
|
| The author appears also not to know formally proved and domain
| specific languages, which are "Effect systems" (they check if
| conditions are uphold) to generate C code. Generally life is a
| tradeoff and the same holds for showing semantically expressive
| properties (or one needs a proof system).
|
| Most languages rely on LLVM and its linker with linker speak,
| which are both not formally proven to be consistent and both have
| no model. The spec also does only describe basic hardware
| abstraction and without a formal model from CPU vendors this wont
| improve much.
| haolez wrote:
| I'd bet on a future language that makes it easy to program
| professionally on mobile devices.
|
| Yes, I know that for us "real" programmers this is dreadful, but
| it would make programming more accessible and this could have
| interesting network effects on our society.
|
| I'd imagine that this language would have some traces of visual
| programming (like Enso[0]) and the denseness of APL[1].
|
| [0] https://enso.org [1] https://aplwiki.com/wiki/Simple_examples
| grumpyprole wrote:
| I would add sructural types, for example anonymous (extensible)
| records and variants. Nominal types are overused in nearly all
| programming languages, even futuristic ones like Haskell. The
| default type definition should be a structural type, because it
| is easy to then simply name it if required.
|
| Every C or Java programmer writes a function definition in terms
| of a tuple of parameters, despite not having first class tuples.
| Functional programming languages can also return tuples, but
| where are the anonymous records? These would allow defining
| functions with named arguments essentially for free.
| yeputons wrote:
| TypeScript's types are structural, and I don't consider this to
| be a good thing. It's useful for JavaScript interop, yes, but
| just because two values have the same representation and method
| names does not mean they're interchangeable. Case in point:
| time units.
|
| So while there may be some use of structural subtyping, I don't
| think it's codebase-wide.
| grumpyprole wrote:
| Here's a counter example. I've seen numerous Java projects
| define a nominal predicate type, for example
| com.google.common.base.Predicate. None of these are
| interoperable without writing adapter code. ML and Haskell
| would essentially use a structural type: t
| -> bool
|
| Much simpler and easier to consume.
|
| How would you assign a nominal type to the result of a SQL
| query?
|
| So there are arguments on both sides. My point was that
| structural types can always easily be turned into a nominal
| type, but not the other way around. Therefore they should be
| the default.
| de_keyboard wrote:
| function types are structural in most nominally-typed
| languages I have used, perhaps a poor example?
| grumpyprole wrote:
| Are you sure? What language are you using?
|
| For example, although Java method definitions are
| essentially defined in terms of tuples, function classes
| and objects in Java are all entirely nominal.
| cageface wrote:
| After working in nominally typed languages for years I'm
| finding Typescript's approach to types very liberating. I
| think structural typing with the option of defining nominal
| types is a sweet spot in type ergonomics.
| munchler wrote:
| F# has anonymous records, which are great, but I definitely
| wouldn't want them to be the default.
| grumpyprole wrote:
| The F# ones are tacked-on and have awkward syntax, but
| otherwise, why not? As I said, anonymous records could permit
| named arguments for free, e.g. let foo {x,
| y} = x + y in foo {x=1, y=2}
|
| Foo above has a type: { x:int, y:int } ->
| int
|
| Again, a nominal type can always easily be created from a
| structural type.
| wruza wrote:
| This list, together with already mainstream features, turns a
| programmer's learning curve into an uncompromising cliff. It's
| clear that right now big software has to be formal to live longer
| and stay healthy, but for me it feels like we're losing something
| important on this way.
|
| Computers ought to be our helpers which could understand our
| plans and implement them properly. Instead we are burying
| ourselves and those who will come later in what is essentially a
| deep math. And our software doesn't even get faster or better, it
| just fits whatever performance:annoyance ratio is acceptable at
| the end of the day.
|
| I think, and this is more of an intuitive rather than an informed
| guess, that the current practical languages are still too low
| level and _that_ may be one of big reasons why software
| development is so complex. You probably feel it too, when you
| have to either A) go find, copy and fine-tune yet another
| boilerplate or a snippet, making it again too hairy to use as is
| next time, or B) use a standard solution which almost implemented
| another programming language on top of its configuration and
| isn't really much easier to use than if it were just a from-
| scratch code. Shovels get better, but we are still digging
| careers with them.
|
| And we had predecessors of a theoretical language which could be
| high-level enough to make programming great again. E.g. FoxPro
| with all its DOS restrictions was a platform where one could
| read, write, iterate, update data, never thinking how to map
| classes to tables or forms, or how to make it run. Or Delphi, in
| which most students could write client-server apps by dragging
| tables, queries, databases and forms right from a toolbar. The
| entry complexity skyrocketed since then or, more precisely,
| returned to "serious" levels of heavy C++ setups which only
| seasoned programmers by trade could manage without pulling hairs.
|
| I don't think that human[ity] will become any significantly
| smarter in the near future, and that, together with our all time
| high software demands, means that we will experience a disabling
| shortage of software developers until we fix our internalized
| tolerance to the increasing complexity.
| b3morales wrote:
| > Parametric mutability, permission / state polymorphism, ???
|
| > ... does the system of function types and effects scale to
| expressing polymorphism over the mutable-ness of a type ...
|
| That's a very thought-provoking handful of sentences. Anyone know
| of work on this question/area?
| stevenhuang wrote:
| Perhaps an example that immediately comes to mind is c++
| overloaded functions with mutable and immutable versions of the
| same base type (const ref, non const ref, rvalue reference).
| verdagon wrote:
| Some more things I see coming soon:
|
| * Decoupled allocation, to use any allocator with any existing
| code. Cone has some really cool things on the way here, where we
| can package up allocators into modules and others can import them
| and use them [0]. Odin is also trailblazing here, with its
| implicit allocator "context" parameter [1]. Zig does this in an
| explicit way in its standard library [2].
|
| * First-class isolated regions, where certain areas of memory
| cannot point to each other, but within a particular region we can
| freely mutably alias. Vale [3] and Verona [4] are doing some
| interesting experiments here.
|
| * Better static analysis, to close the gap between memory-managed
| languages and C. Lobster's algorithm is _very_ impressive here
| [5], and Vale is attempting an "automatic Rust" approach [6].
|
| * True "structured parallelism", where we can "freeze" all
| existing memory and freely access it in parallel from a loop's
| body. Pure functional languages might be able to do this, but it
| would be interesting in an imperative language. Rust can _almost_
| do this, but can only share things with Sync.
|
| * Blending the borrow checker with other paradigms. Cone is going
| all-in on this concept [7], and looks really promising. The
| pieces are also there in D and Vale, but we'll see!
|
| I also have some things on my wish list (full deterministic
| replayability!) but they aren't really on the horizon yet.
|
| (Disclaimer: I work on Vale, which aims to bring many of these
| features into the mainstream)
|
| [0]: https://cone.jondgoodwin.com/coneref/refregionglo.html
|
| [1]: https://odin-lang.org/docs/overview/#allocators
|
| [2]: https://ziglearn.org/chapter-2/
|
| [3]: https://vale.dev/blog/zero-cost-refs-regions
|
| [4]: https://www.microsoft.com/en-us/research/project/project-
| ver...
|
| [5]: https://aardappel.github.io/lobster/memory_management.html
|
| [6]: https://vale.dev/blog/hybrid-generational-memory
|
| [7]: https://cone.jondgoodwin.com/coneref/refperm.html
| c0balt wrote:
| I might also want to add that rust allows decoupled allocation
| rn. There are some popular allocators, like jemalloc, but also
| some project specific ones, especially for some custom OS no-
| std projects.
|
| Edit: See https://docs.rust-
| embedded.org/book/collections/index.html#u... for a through
| explanation
| moldavi wrote:
| Something about Odin I like is that you can have multiple
| allocators, and use a bump allocator for just a specific call
| (and its subcalls), and afterward free it all at once, and go
| back to normal heap allocation. It would be cool if Rust
| offered a built-in way to do that too.
| ksec wrote:
| Off topic question, how did you find out all these non-
| mainstream language that are doing interesting things and
| research? First time I heard of Cone and Vale.
|
| And I think your post deserve to be at the top. I wish I could
| super upvote.
___________________________________________________________________
(page generated 2021-11-21 23:00 UTC)