[HN Gopher] Features of a dream programming language
___________________________________________________________________
Features of a dream programming language
Author : redbar0n
Score : 48 points
Date : 2021-12-28 19:27 UTC (1 days ago)
(HTM) web link (dev.to)
(TXT) w3m dump (dev.to)
| innocentoldguy wrote:
| 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 wrote:
| 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/IfUn...
| Supermancho wrote:
| 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 wrote:
| 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.
| zackmorris wrote:
| 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.
| animal_spirits wrote:
| 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.
| riffraff wrote:
| > 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.
| earleybird wrote:
| 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
| umvi wrote:
| 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 wrote:
| There's QBE (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.
| innocentoldguy wrote:
| 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.
| lordnacho wrote:
| The thing that does everything often doesn't do anything well.
| qsort wrote:
| 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.
| hypertele-Xii wrote:
| On the other hand you might find something new you can do with
| it that you couldn't before.
| 999900000999 wrote:
| >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.
| forrestthewoods wrote:
| Indentation makes copy/paste bugs too hard. It's difficult to
| copy/paste when the source and destination are at different
| indentation levels.
|
| I strongly prefer braces. But I also increasingly languages
| with a standard style and formatter. Go and Rust both do this
| well.
| boardwaalk wrote:
| Selecting and hitting tab or shift-tab (or <, > in Vim) to
| adjust the indent level isn't all that difficult.
| kjeetgill wrote:
| > Indentation makes copy/paste bugs too hard.
|
| I love Python's indentation based blocks (in Python) but this
| is the biggest issue I've had with it. That and maybe
| occasionally when word wrapping.
|
| I think Python's general terseness mitigates most of the
| reasons I might miss blocks in C or Java.
| geewee wrote:
| I don't mind indented code when writing or reading code.
| However I think indentation often becomes a pain when copying
| code from e.g. StackOverflow - the indentation is never quite
| right.
| pjerem wrote:
| > copying code from e.g. StackOverflow
|
| Are people really doing this copy from SO thing ? I always
| thought it was just a meme.
| ianbicking wrote:
| Later on the author wants an autoformatter as part of the core
| language tooling, ala gofmt. I think with autoformatting the
| code ends up as readable as Python... the code can still be
| unreadable, but not because of misleading indentation! (Well, I
| still am offended by the vertical inefficiency of K&R style
| bracing, but presumably the language wouldn't copy that
| style...)
| awild wrote:
| The problem is that when auto formatters completely wreck with
| the semantics of your code because of a missing or misplaced
| character. It has actually happened often and drives me nuts
| every time.
|
| I prefer to write code the way I want/need then apply a
| formatter to unify my code with that of myself and colleagues.
| Akronymus wrote:
| I like indentation in certain languages. Like f#. Because for
| me, the combination of dynamic typing, statement based and
| significant whitespace is just bad.
| k__ wrote:
| As far as I know, ML-like languages use a saner approach to
| semicolon/brace-less syntax than Python.
| hinkley wrote:
| If Python had left the tab character out of the grammar, we
| wouldn't still be having this argument _checks notes_ thirty
| years later.
|
| Vi and emacs had ways to do soft tabs. It's not like it was an
| editor problem.
| wallscratch wrote:
| I like how python's indentation scheme makes code look nearer,
| but I find it scary in the following case:
|
| for i in range(0, m): for j in range(0, n):
| doInner() doOuter()
|
| A single tab here in the 4th line produces syntactically
| correct but logically incorrect code. I find this scary.
|
| I guess it would be easy to just write your own preprocessor
| that requires curly braces everywhere and removes them for the
| python interpreter, but eh.
| qsort wrote:
| Yeah, I don't like Python's approach in re syntax either.
|
| In addition to your example, it backfires for things like
| multiline formulas (need to add parentheses or escapes) or
| lambdas.
|
| Braces (or even 'end' like ruby) would be much more
| practical.
| Jcowell wrote:
| Won't there be an indentation error on line 3?
| dan-robertson wrote:
| Also you need white space diffs to be turned on to spot this
| change in code review, and this is particularly bad if
| indentation changed for another reason.
| ummonk wrote:
| Autoformatters are a thing
| allknowingfrog wrote:
| "Python that compiles" is not too far off from describing Nim.
| https://nim-lang.org/
| Avshalom wrote:
| Python forces you to write indented code, that's basically
| nothing to do with readability.
| 999900000999 wrote:
| 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
| dnautics wrote:
| Am I wrong in remembering that python indentation a choice
| made loosely, "to force noob programmers to write well-
| organized, legible code"?
| dkarl wrote:
| I think GvR observed that beginning programmers often got
| confused when the indentation of their code didn't
| correspond to the syntactic nesting implied by brackets,
| etc. They found the indentation to be more salient and
| easier to interpret, so he designed the language to cater
| to that.
| dnautics wrote:
| Thanks for confirming. Sorry for the crudeness.
| ianbicking wrote:
| 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).
| stickfigure wrote:
| I'm surprisingly happy with IntelliJ / Java's behavior. Java is
| all positional parameters, but anytime the arguments aren't
| obvious, IntelliJ shows the parameter name with subtle syntax
| highlighting. It feels like the best of both worlds.
|
| Completely random example, notice the 'limit':
|
| https://monosnap.com/file/FU6QjZ6Y4b7CNmBBBZoUQlpO8YTXsR
| rwmj wrote:
| 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://dev.realworldocaml.org/variables-and-functions.html
| dan-robertson wrote:
| (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.)
| cdrini wrote:
| 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!
| _se wrote:
| 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 wrote:
| Works fine for me with Brave on Android. DEV is open source, so
| maybe report a bug?
___________________________________________________________________
(page generated 2021-12-29 23:00 UTC)