19 ms·

Features of a dream programming language

145 points by redbar0n 5y ago

markc 5y ago
>REPL-driven-development, or interactive-programming. Inspired by Clojure. But without having to leave your IDE to code in a console/prompt/terminal. You don't have to leave the IDE to evaluate code in Clojure. It's common to spend most of your time in the IDE and only occasionally type at the REPL prompt.
- LandR 5y ago
  Yeah, i never type into my repl. I evaluate to the repl straight from ide with a keypress. I get the result showed inline too.
coldtea 5y ago
>Readability should not imply a one to one match with natural language (counter-inspired by SQL), SQL is not about a "one to one match with natural language". If you want to be counter-inspired on that front, be counter-inspired by Applescript.
- redbar0n 5y ago
  Word.
zmmmmm 5y ago
Fascinating to me that we still have tremendous creative ecosystem of new languages appearing and yet it still seems people are yearning for their "dream" language and unsatisfied with the options. Is it a fundamental truth that we can never have the perfect language?
lordnacho 5y ago
The thing that does everything often doesn't do anything well.
- hypertele-Xii 5y ago
  On the other hand you might find something new you can do with it that you couldn't before.
- qsort 5y ago
  But perhaps being a generalist is also a virtue. For some projects the "value over replacement language" is so low that you might as well just use what you already know.
- epolanski 5y ago
  Bingo. In defense of the author he stated it was a dream.
_se 5y ago
Could barely get through the first few paragraphs with that terrible layout. It mobile-optimized my laptop screen so that there were 4 words on each line. Gross.
- cglong 5y ago
  Works fine for me with Brave on Android. DEV is open source, so maybe report a bug?
999900000999 5y ago
>Not indentation based (counter-inspired by Python), since it is brittle. But also not require semicolons. Inspired by Ruby, and semi-colon-free JS. I actually love indentation, Python forces you to write readable code. Python that complies and is faster than C would be my dream language. I'd also like it to work directly with Unity and Flutter, replacing C# and Dart.
- Avshalom 5y ago
  Python forces you to write indented code, that's basically nothing to do with readability.
  - 999900000999 5y ago
    Hypothetically your on a team with a bunch of junior devs. Your doing a PR review, assuming this dev is sloppy, would you rather it be in C++ or Python ? I didn't like Python or Ruby at first, but now whenever I need to write a small tool, it's Python. Before Python I was using JavaScript, but I've fallen in love with how clean Python is
    - dragonwriter 5y ago
      > Your doing a PR review, assuming this dev is sloppy, would you rather it be in C++ or Python ? I'd rather it be in Python because I haven't touched C++ with any seriousness since the 1990s. But not because of formatting (in either case, I’d prefer a standardized code formatter be in use, which gets you a lot farther than Python’s whitespace sensitivities alone.)
      - 999900000999 5y ago
        When did you start as a developer, are you still an individual contributor or did you have to move into management? I really do want to program, until I retire because I really hate trying to manage people.
  - dnautics 5y ago
innocentoldguy 5y ago
I was just talking about this with a coworker. I think the hardest part about creating a dream programming language is that dreams are subjective and everyone dreams of different things. For example, I'd rather write code in a functional language than an OOP language, but others feel the other way around. Elixir is currently the closest language to my dreams, but my coworker hates working with it due to its functional nature. On the other hand, I'm not a big fan of Go (and would most likely choose Crystal over Go if I needed a compiled, single-binary something-or-other), but my coworker loves it. I'm just glad that there are so many high-quality languages to choose from nowadays, and good paying jobs to go with them. That wasn't the case when I started my career 30+ years ago.
- peterkos 5y ago
  I wish there was a nicer way to integrate multiple languages together. Like if you could somehow transpile perfectly (or pick a really neat abstraction w/o optimizations) that preserves a general implementation. Seems impossible but I wish there was a nice solution so people can use a variety of languages seamlessly without worrying about refactors and semantics. Almost like picking database views in Notion but for languages itself.
innocentoldguy 5y ago
I'd like to point out that while Ruby does support the puts("This was true.") if true syntax, that isn't how most people write if statements in Ruby, in my experience. Ruby also supports the common if true puts("This was true.") end format, which is how I typically see if statements formatted in Ruby code. I wish the article had made that clear.
- mlinksva 5y ago
  The article is clearly :) saying the former should not be supported at all. On your point, I'm not sure how influential rubocop is (I only use Ruby fairly casually, and try to take its suggestions) but for short conditionals, https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/IfUnlessModifier https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/IfUn...
- fouc 5y ago
  do_stuff(bar) if condition Foo.do_something unless qux.empty? This stuff is pretty common in ruby if it's short & clear.
- redbar0n 5y ago
  Good point. I agree. Most Ruby code uses `if <conditional> <expression> end`. Tried to rephrase it now so it gives the impression that `<expression> if <conditional>` is merely syntax that Ruby allows.
- fellellor 5y ago
  I think the convention is to only use the <expression><if…> for a guard statement. ie `return if condition true|false` which is perfectly readable. A lot of language angst seems based on specific syntax issues, for people migrating/visiting from other programming “cultures” rather than community evolved style issues.
umvi 5y ago
I think it would be cool if there were more options in the "programming language backends" space like LLVM. That way you could create custom programming languages that focus on the syntax/QoL features that fit your idea of a "dream" without having to worry about performance since it's uses a known highly optimized backend.
- turminal 5y ago
  There's QBE (https://c9x.me/compile https://c9x.me/compile). It's tiny compared to LLVM and only does the most impactful optimizations, but it's also much simpler to work with. A small but dedicated community of language builders has gathered around it.
  - andrewflnr 5y ago
    Also Cranelift, though I personally don't know a lot more about it than its name. IIRC it has some kind of graph-based IR.
- xigoi 5y ago
  I wish there was something like LLVM, but with a garbage collector, so you could prototype a language without having to worry about memory management.
  - Too 5y ago
    JVM and .NET allows multiple language front ends. Eg C# and VB.NET compiles to same IL, Intermediate Language.
- zmmmmm 5y ago
  JVM has done pretty well in that space over the years ... with the upside that you also get a huge library ecosystem for free which is less accessible with the LLVM approach.
cdrini 5y ago
This is a great summary of that state of the world of programming languages, 2021. It goes through a number of language features that have taken off, and which have moved the space forward over the past few years. I think a language that addressed all these points (even if "address" means consciously doesn't support), would be a very interesting language!
riffraff 5y ago
> Should always be able to be read top-to-bottom, left-to-right. No <expression> if <condititonal> like in Ruby. I believe that rules out operator precedence, which is customary to copy from math, for good reasons. Not all languages do (e.g. smalltalk) but I'm not sure it's what the author intended.
- naniwaduni 5y ago
  Something people often miss about operator precedence in math is that it very closely tracks implied grouping by spatial orientation of the operands in conventional notation. The "rules" are a formalization of an implied intuitive ordering of operations. This intuition is pretty well lost in programming language operator precedence tables.
- earleybird 5y ago
  There are the basic math precedences which language designers then extend with various others. To paraphrase Guy Steele[0] - with the exception of what you learnt in high school, precedence should be eliminated from languages. [0] any of his talks/papers on meta notation - sorry I don't have a link handy
  - redbar0n 5y ago
    maybe not even with the exception of what you learnt in high school…? It was ambivalent then, and people even struggle with remembering and applying PEMDAS years later.. wouldn’t it be better - for humans & computers alike - if application of algebra was completely uniform, chronological, and predictable?
- SomeHacker44 5y ago
  APL evaluates strictly in left to right order. It is very odd to me initially to have uniform precedence when dealing with math.
  - gnuvince 5y ago
    Isn't it the opposite?
ianbicking 5y ago
This one is kind of interesting: "Params: Function parameters must be named, but no need to repeat yourself, if the argument is named the same as the parameter (i.e. keyword arguments can be omitted). Inspired by JS object params, and Ruby." I've grown fairly fond of JS implicitly named object parameters, and I always liked Smalltalk's named(-ish) parameters, and this seems like an interesting compromise. I'm not actually sure how Ruby works in this case? I thought its parameters were fairly normal. Are there other languages that do this? But in the case of one-parameter functions this seems unnecessary, the function name often makes it clear exactly what the first parameter is. And if you are going to support Subject-Verb-Object phrasing (as suggested later) then the Subject is another implicit parameter that probably doesn't need naming. Maybe another approach is that all functions take one unnamed argument, and there are structs with named members for any case when that single argument needs to contain more than one value. Which starts to feel like JS/TypeScript. The static typing to support this in TypeScript feels really complex to me (it's unclear if the language described uses static types).
- rwmj 5y ago
  OCaml gets all of this right already. Labels are optional (which is IMO better than the article suggestion). You can abbreviate to only the label if the parameter variable is the same as the label. You can omit the label for labelled parameters if you want, they just become unnamed positional parameters. And of course the main thing is type safety to help you get parameters right in many cases. https://ocaml.org/manual/lablexamples.html https://ocaml.org/manual/lablexamples.html https://dev.realworldocaml.org/variables-and-functions.html https://dev.realworldocaml.org/variables-and-functions.html
  - dan-robertson 5y ago
    (For others, labels are optional in three senses: not all parameters need to be labelled, the compiler can emit a warning if a label is omitted but you may want this to be an error instead, and there are optional labelled arguments which may be omitted entirely in some cases. Labels are not optional in that the type system is unwilling to convert between labelled/unlabelled or optional/omitted/required parameters and the compiler mostly won’t add hidden coercions between these types) A common case where the trivial-value syntactic sugar fails looks like: foo ~some_descriptive_label:t.some_descriptive_label bar ~something:!something Or baz ~the_option:config.the_option (Why not just pass the config? Two reasons: it is nice to have the interface being explicit about what data is needed, and the function may come from a module that cannot depend on the definition of the config type.)
animal_spirits 5y ago
Sound's like Julia fit's a lot of this criteria. Unfortunately it is slow in it's JIT compilation. Hopefully it can continue in a positive direction.
- adgjlsfhk1 5y ago
  Have you tried it recently? 1.6 and 1.7 have been major improvements to compile speed.
  - animal_spirits 5y ago
    Nah, I haven't worked with it since 1.5 I think. I'm glad to hear its gotten faster!
    - adgjlsfhk1 5y ago
      the 2 big improvements are that precompile happens at package install time and in parallel. also the compiler has generally become significantly better optimized is there's still more work to do, but the difference compared to 1.5 is often around 3x
- MauranKilom 5y ago
  Sorry to bug you about it, but all three apostrophes in your post are wrong. "Sounds", "fits", and "its" would be correct.
  - animal_spirits 5y ago
    Hahaha I noticed that but it was too late to edit the comment.
Supermancho 5y ago
I love these kinds of discussions, but I'm also sure it will tire me out because the ideas are likely stated either too specifically or too succinctly. > Everything should be able to be encapsulated Not only should it be optional (default public), but it should be encapsulated with an escape syntax (similar to Python's underscore or Go's package level, backdoors). This is specifically good for testing. Note later, "no runtime reflection" either. > No need to keep things in human memory for more than about 20 lines of code at a time. If extending that, then there should be an conceptual model Not a language issue. This is what people think of when talking about a function. The problem is how functions have to physically be defined, which causes a lot of jumping around code to understand it. The expansion of function definitions inline, on demand, is a capability that only a LISP IDE has had, afaik. > Content-addressable code: names of functions are simply a uniquely identifiable hash of their contents. I've been a proponent of this since I started writing unit tests. There is no unit test to defend against "someone added a statement with a new side effect". > Since discipline doesn't scale. That's wrong, as a statement. Discipline is, generally, the only thing that scales and that's a Good Thing (tm). The examples given, were not directly related (a language adding more ways to do things) and are not compelling. > Perhaps the language should even restrict a function's scope only to what's sent in through its parameters. So no one can reference hidden inputs^ This kind of wish seems like silly idealism wrapped in ignorance of what smart people will do when a language restricts them too much. Statics are good to have and should be preferred for most operations (once you break functions into small functions, it's obvious), which is not the same thing. Shortly thereafter it goes off the rails completely with lots of strange views: > No magic / hidden control. Make Inversion of Control (IoC) hard/impossible(?). Also the cited reasoning for avoiding exceptions is not compelling, lumped in with specific Java functionality instead of a general reasoning about the pattern. The constant wish for immutability really isn't the panacea presented. The ability to remove items during iteration in Python is fantastic and preferred to swapping data into different structures to perform operations. Some wishes I would add (rather than a big diff of what I think are missteps) - No "new" keyword to create objects/instances. Object() creation should be trivially mockable. Inspired by Python. - Normalize "Helpers", which are a structure to hold static properties and methods. An IDE should be able to analyze a function and recommend it become a static function. - Comments should be separate from code, joined at IDE or joined via manual tooling. This would allow comments to span multiple lines/function and files. IDE could also alert when breaking changes are made. Pairs well with the Content-addressable code wish. ^This is an invitation to attach output buffers and input buffers (normally for UI) to transfer around information to static methods. I have read through this kind of code before.
fooblitzky 5y ago
For me, an interesting language development would be finding ways to make managing dependencies more... manageable. We've seen a rise in systems for packaging, distributing and consuming code written by others. However, still a significant part of maintaining systems is spending time on upgrading dependencies, updating application code as things are deprecated, responding to CVEs, etc. I think there's interesting research and ideas to find in this area, that could lead to a productivity boost. One example idea (I'm sure there are better ones) would be allowing simultaneous use of multiple versions of a library. E.g. This dependency I'm consuming uses CommonLibrary-1.2, and this other dependency uses CommonLibrary-2.4, but they can both get along just fine without having to find some combination both dependencies can agree on.
- Kuinox 5y ago
  > would be allowing simultaneous use of multiple versions of a library Thats called private dependency, and overusing it lead to the node_modules hell (because it was/is the default on npm). IMO, a way to reduce maintenance on updating dependencies, is having automated code modification that are ran when updating the dependency.
  - redbar0n 5y ago
    yes! although you don’t even have to modify the code per se if you have «content-addressable code». See other comments in this thread that expands on it.
- redbar0n 5y ago
  Definitely! See the article’s points on «forward- and backwards-compatibility» and «content adressable code». The latter has implications for library and package management. Someone expanded quite nicely on it elsewhere in this thread.
zackmorris 5y ago
I endorse this. I've known about the majority of these points since I learned Scheme in college back around 1995. My thoughts have solidified and remained mostly unchanged since around 2015 as I've watched web development eat itself. For example: PHP is one of the only languages that got pass-by-value right, other than maybe Clojure. It even passes arrays by value, using copy-on-write internally to only make copies of elements if they're changed. Unfortunately that triumph was forgotten when classes were added, passed by reference of course, putting the onus on the developer to get things right, just like every other mediocre language. Javascript got the poison pill of async, Ruby is Ruby, and I have so many disparaging things to say about mainstream frameworks that it's probably best I don't say anything at all. My only (minor) disagreement with the article is that I do want reflection, so probably need some kind of type info at runtime, ideally with low or no storage overhead. If that's a dealbreaker, at least make it available during development or have a way to transpile that into a formal implementation, maybe something like Lisp and C macros.
- girvo 5y ago
  PHP was one of the first languages that I learned, and used professionally for years. I agree with you RE. pass-by-value; even to this day I find it annoying in other languages that I need to remember their particular quirks around that.
- redbar0n 5y ago
  What would be the main motivation for reflection? I’d like to be convinced it is fundamentally necessary, or just worth it, given the potential for introducing footguns.
  - mind-blight 5y ago
    The main place I've seen these be useful is in ORMs. Metaprogramming allows you to decouple the business logic from the plumbing of query construction and memoizing, while maintaining syntax that most people are comfortable with. Django ORM did a really good job with this. JS Proxy classes also use reflection. Check out the immer library for an awesome example of how those can be used to make coffee drinker to read and reason about. Reflection should be used very rarely, but it's an amazing tool when it's the right tool
Animats 5y ago
Some of this is opinionated, and some is real. It's helpful to separate the two. We've learned some things over the years. * Null-terminated strings were a really bad idea. * Arrays of ambiguous size were a really bad idea. * Multiple inheritance just gets too confusing. * Immutability is very useful, but not everything can be immutable. * If thing A over here and thing B way over there have to agree, that has to be checked at compile time, or someday, someone will break that invariant during maintenance. * Concurrency has to be addressed at the language level, not the OS level. * Which thread owns what data is a big deal, both for safety and performance reasons, and languages need to address that. Some data may be shared, and that data needs to be identified. This becomes more important as we have more CPUs that sort of share memory. * The jury is still out on "async". Much of the motivation is web services holding open sessions with a huge number of clients. This is a special case but a big market. * Running code through a standard formatter regularly is a win. * Generics can get too complicated all too easily. * There are three big questions that cause memory corruption: Who owns it, who can delete it, and who locks it? C addresses none of those issues, GC languages address the second, and Rust (and Erlang?) address all three. Future languages must address all three. * Error handling has to be designed in.
- voxl 5y ago
  See plenty of opinion here too, like generics getting too complicated and error handling needing to be designed in. Vehemently disagree on both
  - Animats 5y ago
    generics getting too complicated There seems to be some agreement that C++ overdid it. Both Go and Rust have more limited generic systems. error handling needing to be designed in I'm not expressing an opinion on return values vs exceptions. But some kind of standard is needed or library error reporting is terrible.
    - formerly_proven 5y ago
      The biggest issue with C++ metaprogramming is not necessarily that it is that powerful (though I've concluded for me that C++ allows too much overloading of semantics by library authors and they seem to really like that) but that the metaprogramming "language" if you can call it that is just incredibly weird and like nothing else on Earth. There's this entire jargon that literally only exists for meta C++ and that should be kind of a huge red flag besides the entire thing being an accident. It's truly a "weird machine" in the truest sense of the word that somehow became an industry standard.
rndmind 5y ago
- AussieWog93 5y ago
  @dang please help us all!
xigoi 5y ago
I'm confused. Some of the points suggest that you want a powerful metaprogramming/macro system, while others are clearly against that. Otherwise, great article!
- redbar0n 5y ago
  True. That is indeed an implication, unless some other facility is available. The necessity of meta-programming, and if so, the extent of it, is one if the biggest uncertainties I have currently, which could be determined at this time, by input from someone more knowledgeable and more familiar with it. Some of the related points from the article: > Will likely need to be able to treat code-as-data. Might need compile-time macros. > Meta-programming: No first-class macros (runtime), since it is a too powerful footgun. But should have compile-time macros. Thanks for the compliment!
bruce343434 5y ago
This guy doesn't seem to know what he actually wants. He wants the language to be "extensible" by "library authors" (?) but then later on the argues that the language should be locked down, thus hard to misuse.
- trynumber9 5y ago
  Perhaps that's the point? So many features, one wonders if they are all compatible. >One or more of these requirements might be conflicting / mutually exclusive. Maybe. But maybe not?
- redbar0n 5y ago
  Thanks for pointing out the inconsistency. What I meant was that the language core should be very constrained around composition of a few core primitives (self-hosting), but that it could be modified or built upon by others. So that it could evolve in multiple avenues of exploration, and gain from the competition. Where it would be up to the community to decide whether they want to use the constrained version(s) (suitable for large scale complex environments), which I prefer, or the bring-your-own syntax version(s) (suitable for small scale playful experimentation and research) which would inevitably appear. Inspirations here would be Lisp, Clojure and Racket. What would be important is to facilitate simple language _merging_, due to all the divergence that would appear. Inspired by Git. So the community could easily find back together after a split (if their ideas and goals come back in alignment, and they have converged to an agrement on the features again).
chrismorgan 5y ago
> Should always be able to be read top-to-bottom, left-to-right. No <expression> if <condititonal> like in Ruby. > But it should borrow some similarities from natural language (like its popular Subject-Verb-Object structure) to make adoption easier (more at-hand/intuitive). (Quibble: natural language isn’t subject-verb-object, English is. Mostly. This is acknowledged later in the article.) Subject-verb-object and verb-object look good at first (thing.frobnicate(other) and frobnicate(thing)), but actually lead you down a path incompatible with reading top-to-bottom and left-to-right. I’ve been steadily leaning in the direction of thinking that it would be wiser to have reading order follow execution order, which often means object-verb, even though that’s not how English works. It starts with prefix keywords on statements: `return thing()` looks fine, but is actually deeply misleading: reading left to right, you’d expect it means you’re returning a value, but thing() might crash your program (abort, panic, exception, whatever). It gets worse: return was a statement or diverging expression, but then you use a prefix keyword on a converging expression, such as the popular `await thing`. (This point is not about await specifically, but that type of keyword, for which await is the most popular example.) Before long, you’ve got `(await (await fetch(url)).json()).field` and you’re wondering whether you should finish your transition to Lisp. And so you give up on your elegant fluent interfaces where this keyword is involved and start putting things in meaningless variables more often, unnecessarily exposing yourself to one of the two hard things in computer science. Rust went with a suffix keyword for await, thing.await, and it composes much better—`fetch(url).await.json().await.field`. I’m not sure where exactly the balance lies. Having control flow keywords at the start of the line is definitely good for grasping control flow at a glance; if you switch to suffix for them you do lose something. Suffix if/for/while all have such mild readability issues. Suffix return would, I think, be a good idea. (Rust’s ? error-propagation/early-return operator is suffix—though again, return is always diverging whereas ? is not, and suffix is more important for converging expressions; but also in Rust, its prefix return keyword not all that common due to the language’s expression orientation; if designing a fresh syntax for Rust, suffix break/continue/return would be very tempting.) Prefix unary operators are also a common source of ordering pain, especially negation in conditionals. `if !some.fluent().interface()` is often painful. Didja know that in Rust you can write `if some.fluent().interface().not()` so long as you import std::ops::Not? I’ve been tempted a couple of times. Conclusion: as usual, some design goals conflict and finding the right balance is hard.
bmitc 5y ago
This reminds me of some experiments that I have been having. I'm (slowly) learning what it means to implement languages through various sources, but one thing I've been testing and thinking about is designing a language from the top down. That is, basically creating a design for the language's syntax, semantics, environment, and libraries without concern how one would eventually implement it.
- quinnjh 5y ago
  Sounds rad :D Ive been in a similar position. Learning from the higher end of things but beginning to pick up some clisp. Ive been toying with the idea of quantum mechanics in relation to scale free architecture... wanting to read this book on quantum chemistry and group theory and eventually think from the bottom up, but in a way that could perhaps keep the "entanglements" to the priorities set on higher levels of the semantic stack... I might be a bit far out here but my goal is to eventually gather enough knowledgeable folks in a shared repository to at least begin a collection of discussions about what is desired. I started a github repo w a collective approach and the forum is open for app if youre interested in collaboration. The more of these "takes" that i can account for in designing a new lang the better, and as other commenters point out the disagreements that would arise in collective development i think thats where forks and merges can come in handy. Insteads of docs as code maybe more like code as docs? With atomicity and scalability? Am i just naive? Ill find out later. https://github.com/holarchyclub/discussions/discussions https://github.com/holarchyclub/discussions/discussions
forgotmypw17 5y ago
I can relate to this article... Perl checks most of these boxes for me.
travisgriggs 5y ago
> …when everything looks the same it is hard to tell things apart This is so true. And it happens on both sides of the complexity. In forth, it all looks the same because the basic philosophy is “here’s a molding machine, make your own lego.” You end up having to rebuild constantly to construct what was constructed what in what was constructed on what was constructed. In syntax heavy languages you end up with lots of contextual overloading so you have to parse the environs of a token to figure what it’s actually for (e.g. []’s in Swift, is it a subscript operator of various kinds, an array, or a dictionary??). I think there’s a sort of sweet spot of making enough generally usable and quickly recognizable pieces, but keeping the set in a bag of generally useful pieces. And to top it off, it’s nice when the elements have a sort of harmony/consistency.
bsder 5y ago
One thing that always strikes me is that a lot of the "function arguments" mess is because destructuring/deserializing is slow. If structuring/serializing were fast, a lot of the "data sharing" issues go out the window as you could copy everything. Your function arguments instead become "I want a named dict/hash/struct. It should have these named members with these types. Any missing members get these defaults. If any members are still missing, please complain."
toastal 5y ago
I'm never going to understand the 'mathmatical jargon' argument against Haskell (and similar). Yes, but this can be true in almost any language that allows abstractions. The math jargon is just a name for a concept and I'd prefer math and programming shared terminology where appropriate rather than coming up with an entirely separate vocabulary. Is Functor really works than Mappable? It's just a label for the abstraction and you'll have to learn the underlying concept regardless so you might as well share the same word.
- mmphosis 5y ago
  as my program might not use math or 'mathematical jargon' I would expect the tree shaker to eliminate all math as dead code but if my program happens to draw the sword of math beware! I am never going to understand Haskell, or should I say ∵⌷⊃○⌽⍉⌊⍟⊖∇⍫⍒∆
  - toastal 5y ago
    That's not a very Haskell thing to see that many Unicode operators. Are you thinking Agda or APL? At least in PureScript, all infix operators must have word name and is either a list of ASCII symbols or a single Unicode character. And even still, you see a massive amount of programmers abusing (and misusing) ligature fonts to make their code look more like math without embracing Unicode and the actual symbols. Why fight over composition operator being `.` or `<<` or `<<<` when you can use the one from math, `∘`? Using Vim, use the digraph `Ctrl+k` then `Ob` and now you have a `∘`.
    - smichel17 5y ago
      Haskell is, however, fond of custom `operators' (infix functions made of symbols). For example, take <$>. It's barely even shorter than fmap! And Haskell even has a special syntax if you want to make fmap infix. Is it really worth the characters to write a <$> b instead of (1 char longer) fmap a b or (3 chars longer) a `fmap` b I understand fmap, but <$> tripped me up for an embarrassingly long time when trying to read Haskell code. In any other language, I'd do a web search for the function I didn't understand, to learn more about it, but that doesn't work here because most search engines don't handle symbols well. You have to know to use Hoogle. But someone who's trying to teach themselves Haskell isn't just going to know that. Learning Haskell doesn't have to be harder than learning another language, but it does require inordinately more hand-holding. I'm sure I'm not the only one. This is something I would call an "inessential weirdness"[0] of Haskell. There is a whole host of others— <>, $, and >>= are some from the Prelude alone; it becomes especially tricky when people don't use explicit or qualified imports. [0]: A term I learned from this excellent talk, https://harihareswara.net/texts/inessential-weirdnesses-in-free-software-libreplanet-talk-2016/ https://harihareswara.net/texts/inessential-weirdnesses-in-f... which you can watch at https://media.libreplanet.org/u/libreplanet/m/inessential-weirdnesses-in-free-software/ https://media.libreplanet.org/u/libreplanet/m/inessential-we...
lanecwagner 5y ago
It says a lot that most of this is counter inspired by Ruby
- Toutouxc 5y ago
  Exactly six of these points are counter-inspired by Ruby, some of those very subjective ("No unless or other counter-intuitive-prone operators"), some duplicate (Ruby meta-programming used twice as a reason). The autor says they like Ruby but then use the most Ruby things as counter-examples.
  - redbar0n 5y ago
    True. The curse of familiarity. I love Ruby though, in its own right. Even though I dream of simpler and more predictable virtues.
tapas73 5y ago
I am sad that compilation speed is not on the list.
- redbar0n 5y ago
  > Compiled, but also interpreted and/or incrementally compiled (for dev mode). Inspired by C++ and JS. >Interpreted / incrementally compiled: So developer can write quick scripts and get fast feedback. Sacrifices runtime speed for compile-speed. Except it also needs quick startup/load time. >Compiled: For production. Sacrifices compile-speed for runtime speed. Compiles to a binary. Inspired by Deno. But compilation speed is not prioritised above all…: > Readability and reasonability as top priority. Reduce dev mind cycles > reduce CPU cycles. Human-oriented and DX-oriented. Willing to sacrifice some performance, but not much, …
ajuc 5y ago
My dream programming language is imperative with global variables when I add new code and transpiles into functional with minimal shared state when I'm done with changing stuff and just want to read what happens. The part of functional programming I hate the most is passing some new data through 10 levels of callstack to use it in a function that didn't needed it previously. It should be automated.
- megapoliss 5y ago
  > The part of functional programming I hate the most is passing some new data through 10 levels of callstack to use it in a function that didn't needed it previously. It should be automated. Probably, you may restructure your code, use curried functions, and you won't need to go through all 10 levels. Transition from imperative to functional programming may looks like untangling a ball of function calls, in order to get simple and clean design.
  - ajuc 5y ago
    I can structure the code cleanly, that's why I love functional programming. Althought I mostly use clojure not SML-like languages so I don't go overboard with currying. From my limited experience currying makes order of arguments matter A LOT, and then you have to refactor that often. My problem is that I'm mostly writing games in my free time (the only time when I'm allowed to use functional languages), and writing games is mostly about quick iteration and testing many small changes. So previously I had the code to handle collisions only take potentially colliding objects as inputs and outputs. Now I want to add particle effects when things collide. Pass that particle system and return particles from the function. Then I think - what if collisions cause the screen to "shake"? Again pass new data to the function. Then I decide it looks stupid and revert it. Then I think - what if police reacted to collisions if they are near the police station? Again - pass some new data there. I can do this, but it's a lot of refactoring. I'd prefer if I could just use a global variable and hit a button in IDE to refactor it to a nice functional code.
    - megapoliss 5y ago
tealpod 5y ago
prmph 5y ago
My dream language would be simply Typescript freed from the shackles of JavaScript (and thus simplified), with a sound type system, a standard library, decimals, runtime type checking, and compiling to machine code, WASM, and/or the .NET IL. A few more detailed features that would be good: - Higher-kinded types - Generic objects - Everything can be an expression, e.g., if and switch statements - Dependent types? In that case the language can be made type-only
- redbar0n 5y ago
  That’s attractive! To be fair, that dream is more likely a dream that is inevitable to come true at some point, given the enormous base of JS/TS developers it will immediately be able to draw from, given the lower/zero knowledge barrier for them to learn it.
- cies 5y ago
  Have you tried Haskell/Purescript/Elm or LISPs?
  - prmph 5y ago
    Don't like their (relatively) complex syntax and inferior tooling support. Elm also lacks generics. Lisp is out of the question, for obvious reasons. Haskell has difficulty with side effects.
Ericson2314 5y ago
The problem with this is this is that it assumes the programming language is the last world in the developer experience. I am certainly a language person, and you cannot get anywhere with a bad language, but merely having a good language is not enough. Working on github.com/obsidiansystems/obelisk/ we have very very many things we would like to work on, but not super much of it involves "adding new features" to Haskell. And yet the libraries are so richly layered e.g. the frontend feels more different from regular effectful code in Haskell, than regular effectful code in Haskell feels different from that in other languages. The one feature we would like in Haskell is arguably a "removing the weaknesses and restrictions that make additional features appear necessary" thing, which is something like https://github.com/conal/concat https://github.com/conal/concat and https://arxiv.org/abs/1007.2885 https://arxiv.org/abs/1007.2885. This would be a way to make some categorical DSL stuff less annoying to write because you have to make it point-free.
Toutouxc 5y ago
I feel like the author is maybe making subtler points than I'm able to understand, or something. At one place they're arguing against inversion on control and somewhere else they're praising Phoenix' Plugs, which are basically callbacks that take and return a connection. They say at the end that some of these requirements might be conflicting, but then what's there to learn from the article? Everyone can list their pet-peeves with most languages/frameworks they've ever touched.
- redbar0n 5y ago
  From my modest understanding of Plugs, they work like function calls, and in Phoenix you call them, so you can always follow the control-flow. As opposed to Rails’ where you write («magic») methods which you have to trust the framework will call at some point (IoC). I may be wrong, but that’s atleast what I meant. To your second point: On one hand the article serves as my own summary notes of what I’ve found desirable features (plus why), and maybe could serve as inspiration for a new language spec someday. Matz found it inspirational, at least: https://twitter.com/yukihiro_matz/status/1451548965019668489?s=21 https://twitter.com/yukihiro_matz/status/1451548965019668489... The article links to many tremendous talks and writings, from various thought-leaders and pioneers, after all. I’ve just collated the principles and features I have become convinced are valuable. On the other hand, since the context is language design, the purpose is to understand what features are generally considered good, so even a collection of favorite features or pet peeves can be a starting point for that, at least for shared discussion. The point is furthermore to find the good and avoid the bad, not gripe over all the peculiar cases of bad, of course. Many of the points also have a brief justification or further reference, that can also be helpful, and discussed (agreed to, or refuted). I don’t have all the answers, and teasing out which points are actually conflicting, either from my oversight/inconsistency, or from fundamental mutual exclusivity, is part of the discussion. A discussion that would especially benefit any whom the dream may resonnate with. So I am grateful that you are pointing out any flaws or inconsistencies as you see them.
tester756 5y ago
Sane and coherent NULL Handling Sane and coherent Error Handling Sane and coherent Generics (if I wrote code with int data and now I want to make it generic and it takes me 5h, then something is not expressive) Expressivness without sacrificing performance significantly (looking at C#'s LINQ vs for loops at hot paths, sadly.)
- runeks 5y ago
  > Sane and coherent NULL Handling In my opinion, you will never achieve this if you insist on NULL being defined by the language itself. Make NULL a library construct and let library authors compete on how to handle absent values.
  - tester756 5y ago
    >Make NULL a library construct and let library authors compete on how to handle absent values. What if they decide to take different approaches to it? then it's mess.
    - prmph 5y ago
      Not really. What's a mess is having a single value NULL that means very different things in different contexts. For example, an unknown value is different from a missing value is different from an error value is different from an elided value. If you need to return all these kinds of values from a function, how would you distinguish between them?
      - pdimitar 5y ago
        1. Don't have NULL at all 2. Have sum types 3. Have several useful kinds of them (like Option and Result) 4. Allow people to make their own to serve their specific scenario Basically Rust, Haskell, OCaml.
      - tester756 5y ago
        I agree, Coherent NULL handling imo means also Result<T> / Optional<T>

145 points by redbar0n 5y ago

>REPL-driven-development, or interactive-programming. Inspired by Clojure. But without having to leave your IDE to code in a console/prompt/terminal. You don't have to leave the IDE to evaluate code in Clojure. It's common to spend most of your time in the IDE and only occasionally type at the REPL prompt.

LandR 5y ago
Yeah, i never type into my repl. I evaluate to the repl straight from ide with a keypress. I get the result showed inline too.

coldtea 5y ago

>Readability should not imply a one to one match with natural language (counter-inspired by SQL), SQL is not about a "one to one match with natural language". If you want to be counter-inspired on that front, be counter-inspired by Applescript.

redbar0n 5y ago
Word.

zmmmmm 5y ago

Fascinating to me that we still have tremendous creative ecosystem of new languages appearing and yet it still seems people are yearning for their "dream" language and unsatisfied with the options. Is it a fundamental truth that we can never have the perfect language?

lordnacho 5y ago

The thing that does everything often doesn't do anything well.

hypertele-Xii 5y ago
On the other hand you might find something new you can do with it that you couldn't before.
qsort 5y ago
But perhaps being a generalist is also a virtue. For some projects the "value over replacement language" is so low that you might as well just use what you already know.
epolanski 5y ago
Bingo. In defense of the author he stated it was a dream.

_se 5y ago

Could barely get through the first few paragraphs with that terrible layout. It mobile-optimized my laptop screen so that there were 4 words on each line. Gross.

cglong 5y ago
Works fine for me with Brave on Android. DEV is open source, so maybe report a bug?

999900000999 5y ago

>Not indentation based (counter-inspired by Python), since it is brittle. But also not require semicolons. Inspired by Ruby, and semi-colon-free JS. I actually love indentation, Python forces you to write readable code. Python that complies and is faster than C would be my dream language. I'd also like it to work directly with Unity and Flutter, replacing C# and Dart.

Avshalom 5y ago
Python forces you to write indented code, that's basically nothing to do with readability.
- 999900000999 5y ago
  Hypothetically your on a team with a bunch of junior devs. Your doing a PR review, assuming this dev is sloppy, would you rather it be in C++ or Python ? I didn't like Python or Ruby at first, but now whenever I need to write a small tool, it's Python. Before Python I was using JavaScript, but I've fallen in love with how clean Python is
  - dragonwriter 5y ago
    > Your doing a PR review, assuming this dev is sloppy, would you rather it be in C++ or Python ? I'd rather it be in Python because I haven't touched C++ with any seriousness since the 1990s. But not because of formatting (in either case, I’d prefer a standardized code formatter be in use, which gets you a lot farther than Python’s whitespace sensitivities alone.)
    - 999900000999 5y ago
      When did you start as a developer, are you still an individual contributor or did you have to move into management? I really do want to program, until I retire because I really hate trying to manage people.
- dnautics 5y ago

innocentoldguy 5y ago

I was just talking about this with a coworker. I think the hardest part about creating a dream programming language is that dreams are subjective and everyone dreams of different things. For example, I'd rather write code in a functional language than an OOP language, but others feel the other way around. Elixir is currently the closest language to my dreams, but my coworker hates working with it due to its functional nature. On the other hand, I'm not a big fan of Go (and would most likely choose Crystal over Go if I needed a compiled, single-binary something-or-other), but my coworker loves it. I'm just glad that there are so many high-quality languages to choose from nowadays, and good paying jobs to go with them. That wasn't the case when I started my career 30+ years ago.

peterkos 5y ago
I wish there was a nicer way to integrate multiple languages together. Like if you could somehow transpile perfectly (or pick a really neat abstraction w/o optimizations) that preserves a general implementation. Seems impossible but I wish there was a nice solution so people can use a variety of languages seamlessly without worrying about refactors and semantics. Almost like picking database views in Notion but for languages itself.

innocentoldguy 5y ago

I'd like to point out that while Ruby does support the puts("This was true.") if true syntax, that isn't how most people write if statements in Ruby, in my experience. Ruby also supports the common if true puts("This was true.") end format, which is how I typically see if statements formatted in Ruby code. I wish the article had made that clear.

mlinksva 5y ago
The article is clearly :) saying the former should not be supported at all. On your point, I'm not sure how influential rubocop is (I only use Ruby fairly casually, and try to take its suggestions) but for short conditionals, https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/IfUnlessModifier https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/IfUn...
fouc 5y ago
do_stuff(bar) if condition Foo.do_something unless qux.empty? This stuff is pretty common in ruby if it's short & clear.
redbar0n 5y ago
Good point. I agree. Most Ruby code uses `if <conditional> <expression> end`. Tried to rephrase it now so it gives the impression that `<expression> if <conditional>` is merely syntax that Ruby allows.
fellellor 5y ago
I think the convention is to only use the <expression><if…> for a guard statement. ie `return if condition true|false` which is perfectly readable. A lot of language angst seems based on specific syntax issues, for people migrating/visiting from other programming “cultures” rather than community evolved style issues.

umvi 5y ago

I think it would be cool if there were more options in the "programming language backends" space like LLVM. That way you could create custom programming languages that focus on the syntax/QoL features that fit your idea of a "dream" without having to worry about performance since it's uses a known highly optimized backend.

turminal 5y ago
There's QBE (https://c9x.me/compile https://c9x.me/compile). It's tiny compared to LLVM and only does the most impactful optimizations, but it's also much simpler to work with. A small but dedicated community of language builders has gathered around it.
- andrewflnr 5y ago
  Also Cranelift, though I personally don't know a lot more about it than its name. IIRC it has some kind of graph-based IR.
xigoi 5y ago
I wish there was something like LLVM, but with a garbage collector, so you could prototype a language without having to worry about memory management.
- Too 5y ago
  JVM and .NET allows multiple language front ends. Eg C# and VB.NET compiles to same IL, Intermediate Language.
zmmmmm 5y ago
JVM has done pretty well in that space over the years ... with the upside that you also get a huge library ecosystem for free which is less accessible with the LLVM approach.

cdrini 5y ago

This is a great summary of that state of the world of programming languages, 2021. It goes through a number of language features that have taken off, and which have moved the space forward over the past few years. I think a language that addressed all these points (even if "address" means consciously doesn't support), would be a very interesting language!

riffraff 5y ago

> Should always be able to be read top-to-bottom, left-to-right. No <expression> if <condititonal> like in Ruby. I believe that rules out operator precedence, which is customary to copy from math, for good reasons. Not all languages do (e.g. smalltalk) but I'm not sure it's what the author intended.

naniwaduni 5y ago
Something people often miss about operator precedence in math is that it very closely tracks implied grouping by spatial orientation of the operands in conventional notation. The "rules" are a formalization of an implied intuitive ordering of operations. This intuition is pretty well lost in programming language operator precedence tables.
earleybird 5y ago
There are the basic math precedences which language designers then extend with various others. To paraphrase Guy Steele[0] - with the exception of what you learnt in high school, precedence should be eliminated from languages. [0] any of his talks/papers on meta notation - sorry I don't have a link handy
- redbar0n 5y ago
  maybe not even with the exception of what you learnt in high school…? It was ambivalent then, and people even struggle with remembering and applying PEMDAS years later.. wouldn’t it be better - for humans & computers alike - if application of algebra was completely uniform, chronological, and predictable?
SomeHacker44 5y ago
APL evaluates strictly in left to right order. It is very odd to me initially to have uniform precedence when dealing with math.
- gnuvince 5y ago
  Isn't it the opposite?

ianbicking 5y ago

This one is kind of interesting: "Params: Function parameters must be named, but no need to repeat yourself, if the argument is named the same as the parameter (i.e. keyword arguments can be omitted). Inspired by JS object params, and Ruby." I've grown fairly fond of JS implicitly named object parameters, and I always liked Smalltalk's named(-ish) parameters, and this seems like an interesting compromise. I'm not actually sure how Ruby works in this case? I thought its parameters were fairly normal. Are there other languages that do this? But in the case of one-parameter functions this seems unnecessary, the function name often makes it clear exactly what the first parameter is. And if you are going to support Subject-Verb-Object phrasing (as suggested later) then the Subject is another implicit parameter that probably doesn't need naming. Maybe another approach is that all functions take one unnamed argument, and there are structs with named members for any case when that single argument needs to contain more than one value. Which starts to feel like JS/TypeScript. The static typing to support this in TypeScript feels really complex to me (it's unclear if the language described uses static types).

rwmj 5y ago
OCaml gets all of this right already. Labels are optional (which is IMO better than the article suggestion). You can abbreviate to only the label if the parameter variable is the same as the label. You can omit the label for labelled parameters if you want, they just become unnamed positional parameters. And of course the main thing is type safety to help you get parameters right in many cases. https://ocaml.org/manual/lablexamples.html https://ocaml.org/manual/lablexamples.html https://dev.realworldocaml.org/variables-and-functions.html https://dev.realworldocaml.org/variables-and-functions.html
- dan-robertson 5y ago
  (For others, labels are optional in three senses: not all parameters need to be labelled, the compiler can emit a warning if a label is omitted but you may want this to be an error instead, and there are optional labelled arguments which may be omitted entirely in some cases. Labels are not optional in that the type system is unwilling to convert between labelled/unlabelled or optional/omitted/required parameters and the compiler mostly won’t add hidden coercions between these types) A common case where the trivial-value syntactic sugar fails looks like: foo ~some_descriptive_label:t.some_descriptive_label bar ~something:!something Or baz ~the_option:config.the_option (Why not just pass the config? Two reasons: it is nice to have the interface being explicit about what data is needed, and the function may come from a module that cannot depend on the definition of the config type.)

animal_spirits 5y ago

Sound's like Julia fit's a lot of this criteria. Unfortunately it is slow in it's JIT compilation. Hopefully it can continue in a positive direction.

adgjlsfhk1 5y ago
Have you tried it recently? 1.6 and 1.7 have been major improvements to compile speed.
- animal_spirits 5y ago
  Nah, I haven't worked with it since 1.5 I think. I'm glad to hear its gotten faster!
  - adgjlsfhk1 5y ago
    the 2 big improvements are that precompile happens at package install time and in parallel. also the compiler has generally become significantly better optimized is there's still more work to do, but the difference compared to 1.5 is often around 3x
MauranKilom 5y ago
Sorry to bug you about it, but all three apostrophes in your post are wrong. "Sounds", "fits", and "its" would be correct.
- animal_spirits 5y ago
  Hahaha I noticed that but it was too late to edit the comment.

Supermancho 5y ago

I love these kinds of discussions, but I'm also sure it will tire me out because the ideas are likely stated either too specifically or too succinctly. > Everything should be able to be encapsulated Not only should it be optional (default public), but it should be encapsulated with an escape syntax (similar to Python's underscore or Go's package level, backdoors). This is specifically good for testing. Note later, "no runtime reflection" either. > No need to keep things in human memory for more than about 20 lines of code at a time. If extending that, then there should be an conceptual model Not a language issue. This is what people think of when talking about a function. The problem is how functions have to physically be defined, which causes a lot of jumping around code to understand it. The expansion of function definitions inline, on demand, is a capability that only a LISP IDE has had, afaik. > Content-addressable code: names of functions are simply a uniquely identifiable hash of their contents. I've been a proponent of this since I started writing unit tests. There is no unit test to defend against "someone added a statement with a new side effect". > Since discipline doesn't scale. That's wrong, as a statement. Discipline is, generally, the only thing that scales and that's a Good Thing (tm). The examples given, were not directly related (a language adding more ways to do things) and are not compelling. > Perhaps the language should even restrict a function's scope only to what's sent in through its parameters. So no one can reference hidden inputs^ This kind of wish seems like silly idealism wrapped in ignorance of what smart people will do when a language restricts them too much. Statics are good to have and should be preferred for most operations (once you break functions into small functions, it's obvious), which is not the same thing. Shortly thereafter it goes off the rails completely with lots of strange views: > No magic / hidden control. Make Inversion of Control (IoC) hard/impossible(?). Also the cited reasoning for avoiding exceptions is not compelling, lumped in with specific Java functionality instead of a general reasoning about the pattern. The constant wish for immutability really isn't the panacea presented. The ability to remove items during iteration in Python is fantastic and preferred to swapping data into different structures to perform operations. Some wishes I would add (rather than a big diff of what I think are missteps) - No "new" keyword to create objects/instances. Object() creation should be trivially mockable. Inspired by Python. - Normalize "Helpers", which are a structure to hold static properties and methods. An IDE should be able to analyze a function and recommend it become a static function. - Comments should be separate from code, joined at IDE or joined via manual tooling. This would allow comments to span multiple lines/function and files. IDE could also alert when breaking changes are made. Pairs well with the Content-addressable code wish. ^This is an invitation to attach output buffers and input buffers (normally for UI) to transfer around information to static methods. I have read through this kind of code before.

fooblitzky 5y ago

For me, an interesting language development would be finding ways to make managing dependencies more... manageable. We've seen a rise in systems for packaging, distributing and consuming code written by others. However, still a significant part of maintaining systems is spending time on upgrading dependencies, updating application code as things are deprecated, responding to CVEs, etc. I think there's interesting research and ideas to find in this area, that could lead to a productivity boost. One example idea (I'm sure there are better ones) would be allowing simultaneous use of multiple versions of a library. E.g. This dependency I'm consuming uses CommonLibrary-1.2, and this other dependency uses CommonLibrary-2.4, but they can both get along just fine without having to find some combination both dependencies can agree on.

Kuinox 5y ago
> would be allowing simultaneous use of multiple versions of a library Thats called private dependency, and overusing it lead to the node_modules hell (because it was/is the default on npm). IMO, a way to reduce maintenance on updating dependencies, is having automated code modification that are ran when updating the dependency.
- redbar0n 5y ago
  yes! although you don’t even have to modify the code per se if you have «content-addressable code». See other comments in this thread that expands on it.
redbar0n 5y ago
Definitely! See the article’s points on «forward- and backwards-compatibility» and «content adressable code». The latter has implications for library and package management. Someone expanded quite nicely on it elsewhere in this thread.

zackmorris 5y ago

I endorse this. I've known about the majority of these points since I learned Scheme in college back around 1995. My thoughts have solidified and remained mostly unchanged since around 2015 as I've watched web development eat itself. For example: PHP is one of the only languages that got pass-by-value right, other than maybe Clojure. It even passes arrays by value, using copy-on-write internally to only make copies of elements if they're changed. Unfortunately that triumph was forgotten when classes were added, passed by reference of course, putting the onus on the developer to get things right, just like every other mediocre language. Javascript got the poison pill of async, Ruby is Ruby, and I have so many disparaging things to say about mainstream frameworks that it's probably best I don't say anything at all. My only (minor) disagreement with the article is that I do want reflection, so probably need some kind of type info at runtime, ideally with low or no storage overhead. If that's a dealbreaker, at least make it available during development or have a way to transpile that into a formal implementation, maybe something like Lisp and C macros.

girvo 5y ago
PHP was one of the first languages that I learned, and used professionally for years. I agree with you RE. pass-by-value; even to this day I find it annoying in other languages that I need to remember their particular quirks around that.
redbar0n 5y ago
What would be the main motivation for reflection? I’d like to be convinced it is fundamentally necessary, or just worth it, given the potential for introducing footguns.
- mind-blight 5y ago
  The main place I've seen these be useful is in ORMs. Metaprogramming allows you to decouple the business logic from the plumbing of query construction and memoizing, while maintaining syntax that most people are comfortable with. Django ORM did a really good job with this. JS Proxy classes also use reflection. Check out the immer library for an awesome example of how those can be used to make coffee drinker to read and reason about. Reflection should be used very rarely, but it's an amazing tool when it's the right tool

Animats 5y ago

Some of this is opinionated, and some is real. It's helpful to separate the two. We've learned some things over the years. * Null-terminated strings were a really bad idea. * Arrays of ambiguous size were a really bad idea. * Multiple inheritance just gets too confusing. * Immutability is very useful, but not everything can be immutable. * If thing A over here and thing B way over there have to agree, that has to be checked at compile time, or someday, someone will break that invariant during maintenance. * Concurrency has to be addressed at the language level, not the OS level. * Which thread owns what data is a big deal, both for safety and performance reasons, and languages need to address that. Some data may be shared, and that data needs to be identified. This becomes more important as we have more CPUs that sort of share memory. * The jury is still out on "async". Much of the motivation is web services holding open sessions with a huge number of clients. This is a special case but a big market. * Running code through a standard formatter regularly is a win. * Generics can get too complicated all too easily. * There are three big questions that cause memory corruption: Who owns it, who can delete it, and who locks it? C addresses none of those issues, GC languages address the second, and Rust (and Erlang?) address all three. Future languages must address all three. * Error handling has to be designed in.

voxl 5y ago
See plenty of opinion here too, like generics getting too complicated and error handling needing to be designed in. Vehemently disagree on both
- Animats 5y ago
  generics getting too complicated There seems to be some agreement that C++ overdid it. Both Go and Rust have more limited generic systems. error handling needing to be designed in I'm not expressing an opinion on return values vs exceptions. But some kind of standard is needed or library error reporting is terrible.
  - formerly_proven 5y ago
    The biggest issue with C++ metaprogramming is not necessarily that it is that powerful (though I've concluded for me that C++ allows too much overloading of semantics by library authors and they seem to really like that) but that the metaprogramming "language" if you can call it that is just incredibly weird and like nothing else on Earth. There's this entire jargon that literally only exists for meta C++ and that should be kind of a huge red flag besides the entire thing being an accident. It's truly a "weird machine" in the truest sense of the word that somehow became an industry standard.

rndmind 5y ago

AussieWog93 5y ago
@dang please help us all!

xigoi 5y ago

I'm confused. Some of the points suggest that you want a powerful metaprogramming/macro system, while others are clearly against that. Otherwise, great article!

redbar0n 5y ago
True. That is indeed an implication, unless some other facility is available. The necessity of meta-programming, and if so, the extent of it, is one if the biggest uncertainties I have currently, which could be determined at this time, by input from someone more knowledgeable and more familiar with it. Some of the related points from the article: > Will likely need to be able to treat code-as-data. Might need compile-time macros. > Meta-programming: No first-class macros (runtime), since it is a too powerful footgun. But should have compile-time macros. Thanks for the compliment!

bruce343434 5y ago

This guy doesn't seem to know what he actually wants. He wants the language to be "extensible" by "library authors" (?) but then later on the argues that the language should be locked down, thus hard to misuse.

trynumber9 5y ago
Perhaps that's the point? So many features, one wonders if they are all compatible. >One or more of these requirements might be conflicting / mutually exclusive. Maybe. But maybe not?
redbar0n 5y ago
Thanks for pointing out the inconsistency. What I meant was that the language core should be very constrained around composition of a few core primitives (self-hosting), but that it could be modified or built upon by others. So that it could evolve in multiple avenues of exploration, and gain from the competition. Where it would be up to the community to decide whether they want to use the constrained version(s) (suitable for large scale complex environments), which I prefer, or the bring-your-own syntax version(s) (suitable for small scale playful experimentation and research) which would inevitably appear. Inspirations here would be Lisp, Clojure and Racket. What would be important is to facilitate simple language _merging_, due to all the divergence that would appear. Inspired by Git. So the community could easily find back together after a split (if their ideas and goals come back in alignment, and they have converged to an agrement on the features again).

chrismorgan 5y ago

> Should always be able to be read top-to-bottom, left-to-right. No <expression> if <condititonal> like in Ruby. > But it should borrow some similarities from natural language (like its popular Subject-Verb-Object structure) to make adoption easier (more at-hand/intuitive). (Quibble: natural language isn’t subject-verb-object, English is. Mostly. This is acknowledged later in the article.) Subject-verb-object and verb-object look good at first (thing.frobnicate(other) and frobnicate(thing)), but actually lead you down a path incompatible with reading top-to-bottom and left-to-right. I’ve been steadily leaning in the direction of thinking that it would be wiser to have reading order follow execution order, which often means object-verb, even though that’s not how English works. It starts with prefix keywords on statements: `return thing()` looks fine, but is actually deeply misleading: reading left to right, you’d expect it means you’re returning a value, but thing() might crash your program (abort, panic, exception, whatever). It gets worse: return was a statement or diverging expression, but then you use a prefix keyword on a converging expression, such as the popular `await thing`. (This point is not about await specifically, but that type of keyword, for which await is the most popular example.) Before long, you’ve got `(await (await fetch(url)).json()).field` and you’re wondering whether you should finish your transition to Lisp. And so you give up on your elegant fluent interfaces where this keyword is involved and start putting things in meaningless variables more often, unnecessarily exposing yourself to one of the two hard things in computer science. Rust went with a suffix keyword for await, thing.await, and it composes much better—`fetch(url).await.json().await.field`. I’m not sure where exactly the balance lies. Having control flow keywords at the start of the line is definitely good for grasping control flow at a glance; if you switch to suffix for them you do lose something. Suffix if/for/while all have such mild readability issues. Suffix return would, I think, be a good idea. (Rust’s ? error-propagation/early-return operator is suffix—though again, return is always diverging whereas ? is not, and suffix is more important for converging expressions; but also in Rust, its prefix return keyword not all that common due to the language’s expression orientation; if designing a fresh syntax for Rust, suffix break/continue/return would be very tempting.) Prefix unary operators are also a common source of ordering pain, especially negation in conditionals. `if !some.fluent().interface()` is often painful. Didja know that in Rust you can write `if some.fluent().interface().not()` so long as you import std::ops::Not? I’ve been tempted a couple of times. Conclusion: as usual, some design goals conflict and finding the right balance is hard.

bmitc 5y ago

This reminds me of some experiments that I have been having. I'm (slowly) learning what it means to implement languages through various sources, but one thing I've been testing and thinking about is designing a language from the top down. That is, basically creating a design for the language's syntax, semantics, environment, and libraries without concern how one would eventually implement it.

quinnjh 5y ago
Sounds rad :D Ive been in a similar position. Learning from the higher end of things but beginning to pick up some clisp. Ive been toying with the idea of quantum mechanics in relation to scale free architecture... wanting to read this book on quantum chemistry and group theory and eventually think from the bottom up, but in a way that could perhaps keep the "entanglements" to the priorities set on higher levels of the semantic stack... I might be a bit far out here but my goal is to eventually gather enough knowledgeable folks in a shared repository to at least begin a collection of discussions about what is desired. I started a github repo w a collective approach and the forum is open for app if youre interested in collaboration. The more of these "takes" that i can account for in designing a new lang the better, and as other commenters point out the disagreements that would arise in collective development i think thats where forks and merges can come in handy. Insteads of docs as code maybe more like code as docs? With atomicity and scalability? Am i just naive? Ill find out later. https://github.com/holarchyclub/discussions/discussions https://github.com/holarchyclub/discussions/discussions

forgotmypw17 5y ago

I can relate to this article... Perl checks most of these boxes for me.

travisgriggs 5y ago

> …when everything looks the same it is hard to tell things apart This is so true. And it happens on both sides of the complexity. In forth, it all looks the same because the basic philosophy is “here’s a molding machine, make your own lego.” You end up having to rebuild constantly to construct what was constructed what in what was constructed on what was constructed. In syntax heavy languages you end up with lots of contextual overloading so you have to parse the environs of a token to figure what it’s actually for (e.g. []’s in Swift, is it a subscript operator of various kinds, an array, or a dictionary??). I think there’s a sort of sweet spot of making enough generally usable and quickly recognizable pieces, but keeping the set in a bag of generally useful pieces. And to top it off, it’s nice when the elements have a sort of harmony/consistency.

bsder 5y ago

One thing that always strikes me is that a lot of the "function arguments" mess is because destructuring/deserializing is slow. If structuring/serializing were fast, a lot of the "data sharing" issues go out the window as you could copy everything. Your function arguments instead become "I want a named dict/hash/struct. It should have these named members with these types. Any missing members get these defaults. If any members are still missing, please complain."

toastal 5y ago

I'm never going to understand the 'mathmatical jargon' argument against Haskell (and similar). Yes, but this can be true in almost any language that allows abstractions. The math jargon is just a name for a concept and I'd prefer math and programming shared terminology where appropriate rather than coming up with an entirely separate vocabulary. Is Functor really works than Mappable? It's just a label for the abstraction and you'll have to learn the underlying concept regardless so you might as well share the same word.

mmphosis 5y ago
as my program might not use math or 'mathematical jargon' I would expect the tree shaker to eliminate all math as dead code but if my program happens to draw the sword of math beware! I am never going to understand Haskell, or should I say ∵⌷⊃○⌽⍉⌊⍟⊖∇⍫⍒∆
- toastal 5y ago
  That's not a very Haskell thing to see that many Unicode operators. Are you thinking Agda or APL? At least in PureScript, all infix operators must have word name and is either a list of ASCII symbols or a single Unicode character. And even still, you see a massive amount of programmers abusing (and misusing) ligature fonts to make their code look more like math without embracing Unicode and the actual symbols. Why fight over composition operator being `.` or `<<` or `<<<` when you can use the one from math, `∘`? Using Vim, use the digraph `Ctrl+k` then `Ob` and now you have a `∘`.
  - smichel17 5y ago
    Haskell is, however, fond of custom `operators' (infix functions made of symbols). For example, take <$>. It's barely even shorter than fmap! And Haskell even has a special syntax if you want to make fmap infix. Is it really worth the characters to write a <$> b instead of (1 char longer) fmap a b or (3 chars longer) a `fmap` b I understand fmap, but <$> tripped me up for an embarrassingly long time when trying to read Haskell code. In any other language, I'd do a web search for the function I didn't understand, to learn more about it, but that doesn't work here because most search engines don't handle symbols well. You have to know to use Hoogle. But someone who's trying to teach themselves Haskell isn't just going to know that. Learning Haskell doesn't have to be harder than learning another language, but it does require inordinately more hand-holding. I'm sure I'm not the only one. This is something I would call an "inessential weirdness"[0] of Haskell. There is a whole host of others— <>, $, and >>= are some from the Prelude alone; it becomes especially tricky when people don't use explicit or qualified imports. [0]: A term I learned from this excellent talk, https://harihareswara.net/texts/inessential-weirdnesses-in-free-software-libreplanet-talk-2016/ https://harihareswara.net/texts/inessential-weirdnesses-in-f... which you can watch at https://media.libreplanet.org/u/libreplanet/m/inessential-weirdnesses-in-free-software/ https://media.libreplanet.org/u/libreplanet/m/inessential-we...

lanecwagner 5y ago

It says a lot that most of this is counter inspired by Ruby

Toutouxc 5y ago
Exactly six of these points are counter-inspired by Ruby, some of those very subjective ("No unless or other counter-intuitive-prone operators"), some duplicate (Ruby meta-programming used twice as a reason). The autor says they like Ruby but then use the most Ruby things as counter-examples.
- redbar0n 5y ago
  True. The curse of familiarity. I love Ruby though, in its own right. Even though I dream of simpler and more predictable virtues.

tapas73 5y ago

I am sad that compilation speed is not on the list.

redbar0n 5y ago
> Compiled, but also interpreted and/or incrementally compiled (for dev mode). Inspired by C++ and JS. >Interpreted / incrementally compiled: So developer can write quick scripts and get fast feedback. Sacrifices runtime speed for compile-speed. Except it also needs quick startup/load time. >Compiled: For production. Sacrifices compile-speed for runtime speed. Compiles to a binary. Inspired by Deno. But compilation speed is not prioritised above all…: > Readability and reasonability as top priority. Reduce dev mind cycles > reduce CPU cycles. Human-oriented and DX-oriented. Willing to sacrifice some performance, but not much, …

ajuc 5y ago

My dream programming language is imperative with global variables when I add new code and transpiles into functional with minimal shared state when I'm done with changing stuff and just want to read what happens. The part of functional programming I hate the most is passing some new data through 10 levels of callstack to use it in a function that didn't needed it previously. It should be automated.

megapoliss 5y ago
> The part of functional programming I hate the most is passing some new data through 10 levels of callstack to use it in a function that didn't needed it previously. It should be automated. Probably, you may restructure your code, use curried functions, and you won't need to go through all 10 levels. Transition from imperative to functional programming may looks like untangling a ball of function calls, in order to get simple and clean design.
- ajuc 5y ago
  I can structure the code cleanly, that's why I love functional programming. Althought I mostly use clojure not SML-like languages so I don't go overboard with currying. From my limited experience currying makes order of arguments matter A LOT, and then you have to refactor that often. My problem is that I'm mostly writing games in my free time (the only time when I'm allowed to use functional languages), and writing games is mostly about quick iteration and testing many small changes. So previously I had the code to handle collisions only take potentially colliding objects as inputs and outputs. Now I want to add particle effects when things collide. Pass that particle system and return particles from the function. Then I think - what if collisions cause the screen to "shake"? Again pass new data to the function. Then I decide it looks stupid and revert it. Then I think - what if police reacted to collisions if they are near the police station? Again - pass some new data there. I can do this, but it's a lot of refactoring. I'd prefer if I could just use a global variable and hit a button in IDE to refactor it to a nice functional code.
  - megapoliss 5y ago

tealpod 5y ago

prmph 5y ago

My dream language would be simply Typescript freed from the shackles of JavaScript (and thus simplified), with a sound type system, a standard library, decimals, runtime type checking, and compiling to machine code, WASM, and/or the .NET IL. A few more detailed features that would be good: - Higher-kinded types - Generic objects - Everything can be an expression, e.g., if and switch statements - Dependent types? In that case the language can be made type-only

redbar0n 5y ago
That’s attractive! To be fair, that dream is more likely a dream that is inevitable to come true at some point, given the enormous base of JS/TS developers it will immediately be able to draw from, given the lower/zero knowledge barrier for them to learn it.
cies 5y ago
Have you tried Haskell/Purescript/Elm or LISPs?
- prmph 5y ago
  Don't like their (relatively) complex syntax and inferior tooling support. Elm also lacks generics. Lisp is out of the question, for obvious reasons. Haskell has difficulty with side effects.

Ericson2314 5y ago

The problem with this is this is that it assumes the programming language is the last world in the developer experience. I am certainly a language person, and you cannot get anywhere with a bad language, but merely having a good language is not enough. Working on github.com/obsidiansystems/obelisk/ we have very very many things we would like to work on, but not super much of it involves "adding new features" to Haskell. And yet the libraries are so richly layered e.g. the frontend feels more different from regular effectful code in Haskell, than regular effectful code in Haskell feels different from that in other languages. The one feature we would like in Haskell is arguably a "removing the weaknesses and restrictions that make additional features appear necessary" thing, which is something like https://github.com/conal/concat https://github.com/conal/concat and https://arxiv.org/abs/1007.2885 https://arxiv.org/abs/1007.2885. This would be a way to make some categorical DSL stuff less annoying to write because you have to make it point-free.

Toutouxc 5y ago

I feel like the author is maybe making subtler points than I'm able to understand, or something. At one place they're arguing against inversion on control and somewhere else they're praising Phoenix' Plugs, which are basically callbacks that take and return a connection. They say at the end that some of these requirements might be conflicting, but then what's there to learn from the article? Everyone can list their pet-peeves with most languages/frameworks they've ever touched.

redbar0n 5y ago
From my modest understanding of Plugs, they work like function calls, and in Phoenix you call them, so you can always follow the control-flow. As opposed to Rails’ where you write («magic») methods which you have to trust the framework will call at some point (IoC). I may be wrong, but that’s atleast what I meant. To your second point: On one hand the article serves as my own summary notes of what I’ve found desirable features (plus why), and maybe could serve as inspiration for a new language spec someday. Matz found it inspirational, at least: https://twitter.com/yukihiro_matz/status/1451548965019668489?s=21 https://twitter.com/yukihiro_matz/status/1451548965019668489... The article links to many tremendous talks and writings, from various thought-leaders and pioneers, after all. I’ve just collated the principles and features I have become convinced are valuable. On the other hand, since the context is language design, the purpose is to understand what features are generally considered good, so even a collection of favorite features or pet peeves can be a starting point for that, at least for shared discussion. The point is furthermore to find the good and avoid the bad, not gripe over all the peculiar cases of bad, of course. Many of the points also have a brief justification or further reference, that can also be helpful, and discussed (agreed to, or refuted). I don’t have all the answers, and teasing out which points are actually conflicting, either from my oversight/inconsistency, or from fundamental mutual exclusivity, is part of the discussion. A discussion that would especially benefit any whom the dream may resonnate with. So I am grateful that you are pointing out any flaws or inconsistencies as you see them.

tester756 5y ago

Sane and coherent NULL Handling Sane and coherent Error Handling Sane and coherent Generics (if I wrote code with int data and now I want to make it generic and it takes me 5h, then something is not expressive) Expressivness without sacrificing performance significantly (looking at C#'s LINQ vs for loops at hot paths, sadly.)

runeks 5y ago
> Sane and coherent NULL Handling In my opinion, you will never achieve this if you insist on NULL being defined by the language itself. Make NULL a library construct and let library authors compete on how to handle absent values.
- tester756 5y ago
  >Make NULL a library construct and let library authors compete on how to handle absent values. What if they decide to take different approaches to it? then it's mess.
  - prmph 5y ago
    Not really. What's a mess is having a single value NULL that means very different things in different contexts. For example, an unknown value is different from a missing value is different from an error value is different from an elided value. If you need to return all these kinds of values from a function, how would you distinguish between them?
    - pdimitar 5y ago
      1. Don't have NULL at all 2. Have sum types 3. Have several useful kinds of them (like Option and Result) 4. Allow people to make their own to serve their specific scenario Basically Rust, Haskell, OCaml.
    - tester756 5y ago
      I agree, Coherent NULL handling imo means also Result<T> / Optional<T>