|
| crazygringo wrote:
| This is a really excellent topic to bring up -- the fact that
| glue code grows essentially quadratically.
|
| Has it been a topic of exploration much in computer science? Any
| literature?
|
| After all, sometimes it feels like _most_ of the programming you
| wind up doing is glue code.
|
| On the one hand, it feels like the kind of thing that there
| should be better tools for at least writing it _declaratively_ ,
| and let the computer turn it into code.
|
| But on the other hand, it feels like a lot of that already _is_
| taken care of. E.g. CSS is essentially declarative glue code for
| what would otherwise be a huge number of painting and layout
| lines of code.
|
| And most of the glue code I myself wind up writing winds up being
| written specifically to handle various constraints around memory,
| disk space, etc -- e.g. how to import a protobuf that changes
| every 30 seconds and convert it to 10,000 rows in a live database
| in a way that's performant -- and so isn't as amenable to
| something simple.
|
| But I do still wonder if there's more opportunity here for more
| declarative coding when it comes to "glue".
| squiggleblaz wrote:
| > After all, sometimes it feels like most of the programming
| you wind up doing is glue code.
|
| This, except in spades.
|
| > But on the other hand, it feels like a lot of that already is
| taken care of. E.g. CSS is essentially declarative glue code
| for what would otherwise be a huge number of painting and
| layout lines of code.
|
| Every gui environment seems to have something like that.
| Whether it's as primitive as Win32 or as advanced as Android,
| you still program by putting widgets with properties in places.
| None of these really allow you to program the edges.
|
| > And most of the glue code I myself wind up writing winds up
| being written specifically to handle various constraints around
| memory, disk space, etc -- e.g. how to import a protobuf that
| changes every 30 seconds and convert it to 10,000 rows in a
| live database in a way that's performant -- and so isn't as
| amenable to something simple.
|
| If the glue that I wrote served that purpose, I'd be happy. If
| you're programming to meet a business requirement, it's not
| really glue: and performing fast enough is a business
| requirement.
|
| I can handle the Win32 glue, and work around it, because I know
| it's there to make it easy to adapt code that was designed to
| work on computers with single digit megabytes of RAM.
|
| If I write an Android program, the whole thing feels like
| writing glue, and the result is as chunky as an Android program
| always is. There's like one line of code to implement a
| requirement surrounded by dozens of lines of code to fulfil the
| ever changing requirements of the API. The best way of actually
| focusing on the requirements is by writing even more lines of
| Rx glue to turn the whole thing inside out, but the Rx glue
| isn't particularly concise either or well documented. The whole
| thing feels like I'm fighting against the people at Google, who
| give me an API that is neither efficient nor effective, nor
| some compromise of the two.
|
| I do think these reactive style libraries and functional
| abstractions help to factor out some of the glue, if you don't
| have to write it all yourself. And when I can write a page in
| an FRP style, I can squint and imagine, with a bit more work,
| the business rules could be expressed in a declarative/markup
| language and even automatically drawn as a (state machine)
| diagram. In principle, with such a markup, you could write the
| glue for each platform and compile it to a native Swift iOS app
| or a Kotlin jvm Android app or JS app (using some library,
| perhaps Rx, as part of the target). (Naturally, you wouldn't
| have something that was truly write once. Platform specific
| logic and processes should still be captured in the business
| logic, when they aren't mere formalities. But it still gets the
| complexity way down.)
|
| I think it's in that direction we should go. Just like we can
| declaratively specify a REST API in Swagger and compile it to a
| target language and library, we should declarative specify the
| business logic of our program and compile it to a target
| language and library, instead of trying to specify our logic in
| terms of the APIs provided by some GUI service provider. The
| declarative language should be third party, so that it is
| genuinely adaptable to multiple platforms.
| bcrosby95 wrote:
| Glue code is massive because most popular languages are bad at
| taking data that is mostly like what you need and transforming it
| into exactly what you need.
|
| Then developers lean into this badness and build a whole taxonomy
| system on top of it because at that point, that's the safe thing
| to do.
| canary1 wrote:
| Great idea, I wish there were a little more on possible ways to
| implement it though.
| fouric wrote:
| I posted this to Lobste.rs when this story hit there and I'll
| post it again here:
|
| > The pipe is one-character glue: "|".
|
| I think that this is mistaken. Pipe makes it easy to connect the
| output of one program to the input of another, but that is not
| the same as "gluing" them - you have to do text processing to
| actually extract the fields of data out of the output from one
| command and convert it into the right format for input to
| another.
|
| This is why you see tr, cut, sed, awk, perl, grep, and more
| throughout any non-trivial shell script (and even in many trivial
| ones) - because very, very few programs actually speak "plain
| text" (that is, fully unstructured text), and instead speak an
| ad-hoc, poorly-documented, implementation-specific, brittle semi-
| structured-text language which is usually different than the
| other programs you want them to talk to. Those text-processing
| programs are the Unix glue code.
|
| The explicit naming of "glue code" is brilliant and important -
| but the Unix model, if anything, increases the amount of glue
| code, not deceases it. (and not only because of the foolish
| design decision to make everything "plain" text - the "do one
| thing" philosophy means that you have to use more
| commands/programs (which are equivalent to functions in a
| program) to implement a given set of features, which increases
| the amount of glue code you have to use - gives you a larger n,
| which is really undesirable if your glue code scales as n^2)
| squiggleblaz wrote:
| I don't think that's right. If you compare bash:
| ls | sort
|
| with some pseudocode: stdin_ls <-
| empty_read_stream() stdout_ls <- init_write_stream()
| stdin_sort <- init_read_stream() stdout_sort <-
| init_write_stream() plug_stream(stdout_ls,
| stdin_sort) stream_sink(stdout_sort,
| function_that_processes_lines) handle_ls <-
| start_proc("ls", stdin_ls, stdout_ls) handle_sort <-
| start_proc("sort", stdin_sort, stdout_sort)
| wait_for_both(handle_ls, handle_sort)
|
| it seems that "|" is definitely gluing things together.
|
| It's true that it doesn't do everything you want. But it's
| truly glue. It's crazy to imply that there's only one level of
| glue.
|
| You identify other glue: if you want to sort by something that
| isn't the whole line, you need to write a bunch of glue. But
| that doesn't mean this isn't glue.
|
| > the foolish design decision to make everything "plain" text
|
| I don't think you can call it foolish and be taken seriously.
| You can disagree about whether it was the right design
| decision, but it was neither the first nor the last system to
| transfer unstructured data and rely on external programs to
| interpret them. It seems to have paid off too - systems
| descended from this design are widespread. You might not like
| paying the tradeoff, but a lot of people find it productive.
|
| Powershell has some improvements on top of the Unix model
| because it saw the benefits of the Unix model and the costs of
| it. In either case, the gui world has nothing like the
| productivity of either system.
| awolf wrote:
| One patten I've seen to address this is to define a "plugin
| architecture" where disparate components are integrated into the
| main system via fixed "sockets". The sockets themselves are
| generic as is the glue code that attaches plugin and socket.
|
| This does create a lot of boiler plate, but that boiler plate is
| predictable and uninteresting, and a good candidate for code
| generation.
| bruce343434 wrote:
| So it's kind of like oop code with traits and interfaces?
| rocqua wrote:
| Isomorphisms.
|
| They let us think about things very easily, and express ideas
| very cleanly. When I Think about a system, I treat isomorphic
| things as almost exactly the same.
|
| But when actually writing code, I need to fully spell out the
| isomorphism. That is glue code.So the code becomes my clear
| ideas, with awkward glue in between.
|
| My dream is a compiler that knows these isomorphisms, and
| automatically implements them with decent (perhaps guided by me)
| optimization.
|
| This way, the idea in my head and the code in my editor start
| looking like eachother a whole lot more.
| danielheath wrote:
| I believe the activefacts project is within a year or two of
| having this ability (the hard research is done, but not the
| legwork to connect it to everything else).
|
| Specifically, it should be able to automatically convert
| between any representation of any subset of the facts in a
| model.
| ______- wrote:
| It's worth researching the demoscene[0] and how demos that looked
| _very complex_ were made with as few lines of code as possible.
| Every byte was accounted for and nothing went to waste.
|
| This is a common thing in games and Super Mario even re-used the
| cloud sprite for the bushes[1]
|
| Now we have to deal with gargantuan Electron apps that hog your
| PC's resources for housing what essentially is a lightweight
| webapp.
|
| [0] https://en.wikipedia.org/wiki/Demoscene
|
| [1] https://www.todayifoundout.com/index.php/2010/01/the-
| clouds-...
___________________________________________________________________
(page generated 2021-06-12 23:00 UTC) |