[HN Gopher] Building apps in minutes, not months
___________________________________________________________________
Building apps in minutes, not months
Author : stevekrouse
Score : 306 points
Date : 2021-09-17 15:46 UTC (7 hours ago)
(HTM) web link (alexanderobenauer.com)
(TXT) w3m dump (alexanderobenauer.com)
| [deleted]
| lmilcin wrote:
| Let me share a small fun story (of making an application in an
| hour, not months).
|
| At one large insurance company in my role as an architect I have
| tried to convince people we need Elasticsearch to speed up free-
| form queries to our database containing information about
| hundreds of millions of people and their contracts. That database
| was Oracle and so not really amenable to completely arbitrary
| queries.
|
| I was immediately shot down that the project will take huge
| amount of time and effort to complete and so is completely off
| the table.
|
| So I came up with fun plan. I set up an hour-long meeting which
| was supposed to be my last chance to pitch the project.
|
| Rather than present slides and extol virtues of Elasticsearch, I
| decided to _WRITE THE APPLICATION DURING THE MEETING, FROM
| SCRATCH_.
|
| And that's what I did. I came to the meeting, set my laptop,
| connected projector, put some music on, and I wrote the entire
| service from scratch and had time to spare to present how it
| works.
|
| I cheated a little bit, of course. That 1h meeting was well
| rehearsed. I spent entire week preparing, finding better ways to
| do stuff and retrying entire process dozens of times.
|
| I used JHipster to generate 90% of the service and the rest was
| just tiny bit of well thought glue code.
|
| Unfortunately, this did not sit well with couple of people whom I
| made complete mockery of. I had to leave soon after.
| digitalsin wrote:
| I like this story.
| ste-up wrote:
| I actually built the exact same app [1] in React. It took me
| longer than minutes but definitely less than months. I am
| interested in seeing the follow up videos for more complex
| applications.
|
| (My feature set does not include storing on a server. It
| purposefully only stores on local storage. It also does not allow
| rearranging the lists or items - which again was a design
| decision. It does allow you to delete lists which Alexander's app
| doesn't.)
|
| [1] https://easylists.app
| fouc wrote:
| >These Lab Notes document my research in progress. My research
| area is in the future of personal computing.
|
| This is a classic web log. What blogs really should be about.
| boomskats wrote:
| Yeah - the claims in the title are a little contentious (at
| least on first glance), but the Lab Notes section of the site
| is a gem.
|
| And it's a _beautiful_ site. Really. It might just be a netlify
| theme or whatever, but I'm really enjoying reading it.
| lewisjoe wrote:
| A simple trick I use to validate any full-stack framework is "Can
| I build an ERP system with this framework" ?
|
| It's not perfect, but ERP systems have everything that modern
| apps do
|
| #1 authentication
|
| #2 role based authorizations
|
| #3 Data entry forms
|
| #4 Pages to show information from data
|
| #5 Reports
|
| How well does this one fit to that benchmark?
| MK_Dev wrote:
| What are your top frameworks that satisfy all of these
| (assuming developer productivity is a factor)?
| supermatt wrote:
| i think we have a different idea of "production ready". but its a
| cool utility for rapid prototyping, definitely. reminds me of
| xforms.
| vinaygaba wrote:
| Very cool. I feel like this is the early version of a
| "programmable Notion[1]" in some ways which is built on similar
| building blocks that are customizable.
|
| [1] https://notion.so/
| matchbok wrote:
| Pretty neat, but like all these very similar tools, they seem
| built around TODO apps. These are only suitable for PoC apps. If
| that's the case, is it more difficult to learn this new thing, or
| just prototype something in React? I'm guessing the former.
| seph-reed wrote:
| As nice as this looks, I've been working on something similar and
| immediately see tons of limitations.
|
| Things like:
|
| - batch editing: what if you don't want your edits to save
| immediately, but instead as a group?
|
| - item creation and joins: what if some fields create items that
| have ids that other fields require for update or their own
| creation?
|
| - discarding edits: what if you want to throw away your changes?
|
| - front-end auth: how do you verify that a field is editable
| before creating a text box for it?
|
| - front-end validation: how do you make custom field validators?
|
| - mid-edit derivative values: if you change something without yet
| saving it, will the other parts of the ui using that value also
| show updates?
|
| Solving all these issues has been a tough project. I started off
| wanting to be able to just pass a rowId, tablename, and
| columnname, but pretending things are that easy only works for
| very, very flat Databases. (no joins)
| cestith wrote:
| What if I need a dependency tree on my tasks? What if I need to
| share the list with others - does this attach data to a session
| cookie or something? What if I need to subtask an item. What if
| I need to time track the start to finish? What if I need to
| estimate that? What if I need a title and description for each
| task, and a way to associate blocking, duplicates, etc?
|
| A TODO list is one thing, but this isn't going to replace
| Mattermost or Jira tomorrow.
| sergioisidoro wrote:
| I've been noticing that a lot of work in web development is
| boilerplate. For me Django has made that almost magic, with
| Generic views, automatic form and view generation and almost self
| generating APIs. Add to that a lot of community resources and
| templates (like cookiecutter), and you get an almost fully ready
| app in a matter of hours. I'm sure that is also the case for
| Spring, Rails, or other "older" frameworks.
|
| I still haven't found tools that match those for SPA or PWA
| (React or other), and it seems that this is almost what the
| author is trying to go for.
| goingindi wrote:
| Could you elaborate on the cookiecutter template?
| nsomaru wrote:
| https://github.com/pydanny/cookiecutter-django
| npilk wrote:
| Just want to say that DatasetSortable is awesome - I once
| implemented the same functionality (saving the state of sortable
| checkboxes) and it was a nightmare.
| javajosh wrote:
| Building prototypes in minutes, apps in months.
| jbellizzi wrote:
| Anybody else bothered by the 105 uncommitted files?
| jawns wrote:
| I've been using the free, open-source React Admin
| https://marmelab.com/react-admin/ framework for this use case,
| and I really like how it works and how little code I need to
| write. I used it to quickly build an internal CMS, and it handles
| relational stuff well. For instance, if I have pieces of content,
| each of which can have multiple tags, it handles all the tag
| lookups using typical REST API calls. Also integrates well with
| our existing auth system (AWS Cognito).
|
| There are some other low-code tools that have similar premises
| and offer things like ETL tools. We evaluated one called Retool
| https://retool.com and it seemed pretty cool, but because it's a
| per-user pricing model, the costs can be pretty substantial when
| you have a lot of people using the tool.
| cpursley wrote:
| React Admin works really well with Hasura:
|
| https://github.com/hasura/ra-data-hasura
| gervwyk wrote:
| Check out https://github.com/lowdefy/lowdefy which is open-
| source.
|
| We created Lowdefy (co-founder here) to built web apps fast and
| it is really working well for us and our customers. We've
| already rolled out a few enterprise level apps in record time
| and the platform really scales well as apps evolve and get
| really complicated. Even developing apps as a team is a breeze
| since you are working with yaml / json which is easy to code
| review, copy, paste, find and replace.
|
| l
| arey_abhishek wrote:
| Since you mentioned Retool and react admin, take a look at
| Appsmith. It's an open source low code tool similar to Retool.
|
| https://github.com/appsmithorg/appsmith I'm a co-founder of the
| project and we started this because there was no open source
| project that made it easy to build highly custom admin panels
| and internal tools.
| topspin wrote:
| I've done three production apps with React Admin and its
| predecessor ng-admin. They do what they say on the tin.
| Integrating custom components with React Admin works well and
| is a tremendous affordance.
| jimbob45 wrote:
| This wouldn't work for apps with moderate depth but for simple
| surface-level stuff, this would work great. It always feels like
| stuff like this would solve many people's problems if only they
| knew they could use this instead of hiring six nerds to build
| their simple app. I'm still blown away by how many people don't
| realize stuff like this and Wix/Squarespace + AWS would fulfill
| their business needs for basically free.
| heavyarms wrote:
| I'm working on a project with a somewhat related concept
| (dynamically generated PWA built from configuration generated by
| a simple UI) and I can appreciate some of the complexities
| involved in building a a framework and composable component
| library.
|
| From what is shown in the video, I think the biggest limitation
| is that this approach would only work if the data model is stored
| in a document store. Each new "itemId" just becomes a property in
| a big JSON file and the framework knows what to update and how to
| update it because the "schema" is just controlled by the shape of
| the component tree and the type of component. That probably works
| for some use cases, but it's not something that scales IMO.
| stevenpetryk wrote:
| Seems pretty clear to me that this isn't designed to build
| scalable apps. And that's okay--it's still a very thought-
| provoking exploration into a different paradigm of persistence.
| gervwyk wrote:
| We went with the JSON / YAML approach and we are able to build
| some really complicated apps fast using Lowdefy - so it can
| scale, but only if you implement some sort of DSL to express
| logic.
|
| Check out https://github.com/lowdefy/lowdefy
| dukeofdoom wrote:
| Browsers should supported a rich set of UI components, optimized
| so that AI can compose interactions between them.
| gervwyk wrote:
| This would be great. Would save so much cost if there was a
| standard for component, for a lot of apps especially internal
| business applications, building and maintaining component libs
| just adds so much cost over and over. At some point the web
| should ask how many component libs is really necessary.
|
| We've been working on Lowdefy [1] which might be useful if you
| are looking to build apps by just focusing on the interaction /
| data binding of the application.
|
| [1] - https://github.com/lowdefy/lowdefy
| [deleted]
| chacham15 wrote:
| The components used here seem like theyre very specific to the
| needs of the application that was built. I have no idea how this
| type of framework would be used to build anything else.
|
| To be more specific, he has the "Source" and "Detail" elements,
| but theres no apparent way of what piece of data is being synced
| across them or how theyre connected. Therefore, if I wanted to
| change any of that, I'd be completely lost. Did anyone else
| understand how the data actually flows across these pieces?
| csomar wrote:
| I hate to be that guy but what the guy is doing is adding
| "complexity"; he did not create zero-cost patterns or
| abstractions that reduce 10 lines of code to 1 while allowing
| for fine-grained customization of any step.
|
| As someone who builds apps for a living, the 90% of the time is
| spent on the "last minute" customization and fighting the
| stack. This is why I pick widely used stacks. They might not be
| better but I have higher chances of finding someone else who
| had a similar issue.
|
| Also I'd never use something that hides what is pushing/pulling
| from the server let alone configure the database structure for
| me. That would be really fun as I already spend 1/2 my time
| debugging what went wrong and finding it. Working with a black
| box is not going to help in any of that.
|
| There is a reason why people steer to React/Redux. The world is
| not a Todo list app, and most of the time you need some
| creative work and you need something agnostic that can be
| programmed. Coupled with GraphQl, you can have a nice
| separation between your front and back ends and test them
| appropriately.
| MattGaiser wrote:
| > the 90% of the time is spent on the "last minute"
| customization and fighting the stack. This is why I pick
| widely used stacks
|
| I am currently on a project where the initial specs worked
| with Adobe Captivate. Then the spec exploded and we are
| making tortured attempts to make it still work with
| Captivate.
| aaronblohowiak wrote:
| they are linked through the "target" attribute which has a
| default value. since there is only one source and one
| destination in the demo, it can be omitted entirely. (5:03 in
| the video)
| cabalamat wrote:
| > Did anyone else understand how the data actually flows across
| these pieces?
|
| I'm guessing it goes into a database somewhere. But I'm not
| sure how, what the database's schema is, or how easy it would
| be to interact with it from an external program.
| oh-4-fucks-sake wrote:
| Exactly. Just wait until you have to auth with a 3rd party API,
| fetch the request async, do a transformation on the response,
| load it into a 3rd party UI grid, add custom styling to the
| grid, and then add sorting and filtering on top. And this isn't
| anything particularly exotic--it's a wash-rinse-'n'-repeat you
| find over and over in products--and it'd be a royal PITA to
| build it in a framework that's basically a thin layer on top of
| HTML.
| mattnewton wrote:
| I'm not sure how this id-based data syncing mechanism solves
| things like authentication, business logic, and testing that I
| usually spend the most time on. I need a concrete example maybe?
| cabalamat wrote:
| I suspect the framework has a way of handling users and logging
| on, as that's a common thing in most websites.
|
| Obviously the business logic differs for every different
| business, and i expect that would be harder to do.
| tiborsaas wrote:
| You still need to spend those months, but the prototype will be
| up real fast :)
|
| But the title is not wrong, a month consists of weeks, days and
| minutes :)
| tracyhenry wrote:
| It's not wrong, but it's clickbait.
| olah_1 wrote:
| Yeah two-way data binding isn't exactly new.
|
| What I would like to see more of is "no backend" type solutions
| that allow you to just write front ends that leverage existing
| auth, databases, etc
|
| eg. Sia, Gun, Dfinity, etc
| cabalamat wrote:
| > What I would like to see more of is "no backend" type
| solutions that allow you to just write front ends that
| leverage existing auth, databases, etc
|
| I did the opposite of that, since I see the data structures
| are the "real" thing and the layout of the web pages as
| merely froth on the top.
|
| My Frambozen[1] framework is all backend, in that you define
| your database schema, and then it builds parts or all of the
| front end (the web pages) for you. (It's written in Python
| and uses the MongoDB database).
|
| So for example, you might define a table like this:
| class Foo(MonDoc): name = StrField()
| description = TextAreaField(monospaced=True)
| aNumber = IntField(minValue=0, maxValue=100)
| minSpeed = FloatField(title="Minimum Speed, mph",
| minValue=0.0) maxSpeed =
| FloatField(title="Maximim Speed, mph", minValue=0.0)
| favouriteDrink = ChoiceField(choices=DRINK_CHOICES,
| showNull=True, allowNull=True) fruitsLiked =
| MultiChoiceField(choices=FRUIT_CHOICES,
| desc="tick all fruits this person likes")
| tickyBox = BoolField() aDate = DateField()
| lastSaved = DateTimeField(desc="when this foo was last
| saved", readOnly=True) aDateTime
| = DateTimeField(title="A Date and Time") anything
| = ObjectField(desc="can contain anything",
| default=["any", "thing"]) favouriteBook =
| FK(models.Book, allowNull=True, showNull=True)
|
| And then it can auto-generate a page to view / edit / create
| a single record in the table, and another page to listr all
| the records in the table.
|
| 1: https://github.com/cabalamat/frambozenapp
| xwowsersx wrote:
| your pseudocode there mixes DB fields with UI components.
| On the one hand, you have a FK field and, on the other, a
| TextAreaField with monospaced set to True. Is this a
| description of a table or a view...?
| cabalamat wrote:
| > your pseudocode there
|
| It isn't pseudocode, it's Python source code.
|
| > On the one hand, you have a FK field and, on the other,
| a TextAreaField with monospaced set to True. Is this a
| description of a table or a view...?
|
| Both!
|
| TextAreaField and StrField both define a string field in
| the database. The only difference between them is how
| they would appear rendered in HTML.
|
| In the code snippet I included, MonDoc is a Python class
| that encodes the schema for a MongoDB table (MongoDB
| calls them collections). But MonDoc is actually a
| subclass of another class, FormDoc, that encodes data for
| an HTML form.
|
| Using FormDoc, you can define the fields of your form,
| render it into HTML, validate results, etc.
|
| The reason I merged forms and table schemas into one
| concept was I've used so many systems that define forms,
| and so many systems that define tables and they're all
| very similar, and I don't like having to do cut-and-paste
| to transform a form definition into an almost-the-same
| table definition. I find it tedious and error prone.
|
| Does this reduce flexibility? It does a bit, by tying
| together forms and tables. But I think any rapid
| prototyping system is going to trade flexibility for
| speed of programming.
| olah_1 wrote:
| That works too. Pretty much the same result. More people
| are just familiar with HTML/JS I'd wager.
|
| How do you handle users and permissions?
| cabalamat wrote:
| There's a predefined table called User that holds user
| accounts: https://github.com/cabalamat/frambozenapp/blob/
| master/app/us...
|
| There are also predefined web pages for logging in and
| out, and listing users. A real aspp might want ot
| customise the pages: https://github.com/cabalamat/framboz
| enapp/blob/master/app/lo...
| dgdosen wrote:
| So, where's the Github link for Conductor Framework?
| IceDane wrote:
| Ugh, is it that time again?
|
| You can't just magically disappear the complexity that is
| inherent to building actual applications. Synchronizing data
| based on unique IDs isn't special. At best this is an interesting
| prototyping tool and at worst this is a huge red flag for your
| understanding of actual web development.
|
| Of course there is no source code, but we get to bear witness to
| the great development habits of this author: 105 changed files in
| his repo.
|
| Pony up some source code and actual details and then we can talk.
| Until then, as far as I'm concerned, you just demonstrated ready-
| made components that are talking to firebase or whatever.
| omgitsabird wrote:
| > Of course there is no source code, but we get to bear witness
| to the great development habits of this author: 105 changed
| files in his repo.
|
| Are you implying they are a sub-par developer because they
| haven't committed changes to 105 touched files? That doesn't
| seem like a great metric to judge someone by.
| cloogshicer wrote:
| Your negativity is detrimental to this thread. Please check
| your tone, this is not the quality people writing on HN should
| strive for.
| iio7 wrote:
| What are you talking about? His tone is fine as is the
| critical points he is making. He's right.
| cloogshicer wrote:
| I actually agree with most of the criticism they wrote but
| that's beside the point I was trying to make. This tone is
| not how you should talk to another human being.
| daneel_w wrote:
| Great. Now we can all build a shopping list or to-do list
| application in minutes.
| MisterBastahrd wrote:
| This is useful in the same way that throwing cards up in the air
| and hoping that a standing structure will emerge for a few of
| them is useful. Yes, it's faster and easier than building a card
| house by hand, but you lose most ability to manage business-
| complexity logic.
|
| Most senior devs can code something from scratch that will
| automagically create a crud form in a couple hours. The reason we
| don't do it is that it's not useful.
| dorianmariefr wrote:
| Went from 0 to App Store and Google Play in one month with a
| react-native app with a webview to a rails/stimulus/react app
| lanevorockz wrote:
| Sound interesting, I have been planning to do something like this
| for a while. In the end, app development is so standardised that
| I don't get why tooling is so terrible.
| Wronnay wrote:
| So not GitHub Repo with the framework?
|
| His blog is very interesting. Great ideas but the realized
| products are very similar to the competition...
| hermannj314 wrote:
| These tools are incredible and inspiring. Terse, intuitive and
| functional. Beautifully elegant code meant to optimize for time
| over flexibility.
|
| It is hard to put into words how pleasing it is see a balance
| struck between code and data and how constructing the right
| abstraction can make solving a specific set of problems
| incredibly simple through the right language of expression.
|
| I love when I solve a problem and the domain language offers me
| the expressiveness to solve it in a single line - even if the
| concept is complex, or that line fires off a hundred perfectly
| calibrated decisions under the covers - it tells me the universe,
| my problem domain, and my tools are in alignment.
| growt wrote:
| GPT3, is that you?
| hermannj314 wrote:
| Sorry, I am just a developer.
|
| I'm not sure if I am supposed to be insulted by that comment
| or not.
| abj wrote:
| I wonder if this is something GPT-3 would say. Am I GPT-3?
| hermannj314 wrote:
| This entire exchange made me think of Blade Runner. Maybe
| I am not even human after all. How would I know...
| ctenb wrote:
| Definitely not GPT3
| nottorp wrote:
| So... would 128 Gb ram be enough for one of these apps?
| AngeloAnolin wrote:
| While stuffs like these are laudable, it still merits a lot of
| consideration that for these to be impactful to companies /
| business / people that would adopt them, they need to have that
| domain expertise and knowledge of what needs to be built. Too
| many times, a lot of products are built trying to find a solution
| it was conceived for.
| parhamn wrote:
| Funny enough, I wrote a blog post yesterday titled "Todo: The
| hard parts"[1] where I started discussing how syncing the data
| planes of frontend apps are much more complex than they seem.
|
| This looks really cool. I like the idea behind the
| Source/Dataset/Detail components. I wonder how they work in
| practice. My first attempt at a component based rendering system
| (with render cbs and such) felt super clunky as soon as things
| got a tad complex.
|
| [1] https://synth.app/blog/todos-the-hard-parts-part-1
| WA wrote:
| Good read, because it's true. Yes, we can have more
| abstraction. They are called libraries and frameworks. React
| being one in the JS world so that nobody has to write
| document.querySelector all the time.
|
| But programming is about edge cases and thus, many, many rules
| how things should behave in every imaginable scenario.
| [deleted]
| peterthehacker wrote:
| Interesting and very mysterious.
|
| How does the data syncing work? Can the developer hook into
| changes to execute business logic? How are changes to the same
| data point from different users handled?
| nickthemagicman wrote:
| > You don't have to worry about piping data around your app,
| syncing, binding state to interface components, etc. You just
| construct your app.
|
| Apparently, you just construct your app.
| pftburger wrote:
| Generally from my measly experience developing apps, it's not
| coding them that takes the time
| gervwyk wrote:
| Kudos on this! Interesting approach. What variety of apps can be
| built with this? Do you plan to focus towards a specific category
| of apps?
|
| Shameless plug. We also built a platform - Lowdefy - to develop
| web apps in minutes / days by only writing yaml or JSON. So far
| we find that it really empowers any developer to develop a web
| app (Especially backend / data dev who not feel like learning CSS
| / react / webpack etc)
|
| Check it out https://github.com/lowdefy/lowdefy
| jack_riminton wrote:
| Cool, but I could do it in the same time with Rails
|
| If I did it with a Rails template such as JumpStart I'd also have
| a tonne of extra features such as user authentication, payments,
| styling etc. out of the bag
| goingindi wrote:
| Could you tell us more about jumpstart?
|
| Is it well supported,
|
| who provides it,
|
| are there similar templates that don't work as well and why?
| ollerac wrote:
| This is incredible work and very close to my heart because it's
| similar to a project I've been dedicating most of my personal
| time to for the past 4 years [0].
|
| It's amazing how much work you can skip when you treat the front-
| end of your app as a pretty interface for your database. I think
| a lot devs were inspired to go down this road by Meteor.js back
| in 2012 when it was released [1].
|
| I think a tool like this is the future of web development: create
| the interface and boom, you're app is already working. That kind
| of instant validation of your work is addictive.
|
| The problems arise when you want to change how data is processed
| behind the scenes before displaying it or after the user edits
| it. Or how it's connected to other users' data. But I think these
| issues can be solved either with reactive hooks or some of the
| innovations coming out of the GraphQL space.
|
| I think you can get pretty far with a system like this:
| * User accounts * Automatic data syncing *
| Collaboration * Deployment & hosting * Payments
| * Form submissions
|
| All of this is pretty trivial to get working out-of-the-box with
| very little effort from a dev. So no one has to reinvent the
| wheel.
|
| And these features, if done well, are all that 90% of businesses
| need to create value for their customers and become profitable.
|
| I'm really excited about this space. My email is in my profile if
| anyone wants to talk about it further.
|
| [0] https://remaketheweb.com/
|
| [1] https://www.meteor.com/
| foobarbecue wrote:
| +1 for referencing meteor. I'm still flummoxed every time I try
| a new web framework and it can't do what meteor did without
| mountains of boilerplate. I starred your repo and will give it
| a try soon.
| taylorwc wrote:
| I'm 100% convinced I would never have learned to code without
| Meteor... it made so many things simpler. You should check
| out wasp[0], which has a lot of philosophy in common.
| Disclosure: I am investor in the company behind the project.
|
| [0] https://wasp-lang.dev
| [deleted]
| gervwyk wrote:
| Just have to drop another +1 for meteor here. Saved us 1000s of
| hours and allowed us to roll out a very complex BI app with a
| very small team. Loved developing with meteor.
| midrus wrote:
| Or just use Django
| [deleted]
| system2 wrote:
| I wonder since when started calling basic pages apps.
| mcintyre1994 wrote:
| That's a great demo, I really like how you built up the layers as
| you went through it. It's really easy to see how you can keep
| composing and building up more and more impressive apps using
| these building blocks. My main question would be around
| authentication, you mention it both on the website and in the
| video but I'm not sure how you're solving that?
|
| Also how generic is your ID-based sync mechanism? Can you attach
| it to any react component and sync whatever it has in useState
| hooks? Or is there magic going on in the prebuilt components that
| you demoed?
| bilater wrote:
| I agree with the philosophy even if I'm not totally understanding
| how you are getting there. I talked about my process which has
| similar elements like reusing components to build fast here:
| https://www.hackyexperiments.com/process
| meetups323 wrote:
| This is a UI prototyping tool, and a potentially good one at
| that. It does not develop what a HN audience would call
| production ready applications. That being said, "Production
| Ready" as used by this author is _very_ different than what
| "production ready" as used by the HN audience means, a look at
| the end of the linked video where he claims a checklist with drag
| and drop support and cookie-derived sessions next to is
| "Production Ready" should sufficiently demonstrate that.
|
| And that's okay! It doesn't need to have replaced the entire Web
| Developer career field, it can just be a cool UI prototyping
| tool. But I might suggest to the author to reduce the scope of
| their claims a touch, as it would engender more positive
| discussion.
| bdcravens wrote:
| I suspect that many of the apps we all have deployed to
| production isn't what we would consider "production ready" when
| looking at someone else's app.
| kashkhan wrote:
| Who isn't looking forward to 99% of front end developers being
| out of jobs if apps can be built in minutes instead of months.
| myohmy wrote:
| Sharepoint will put my team out of business any day now /s
| eurasiantiger wrote:
| Yeah, not happening. Someone still needs to write the CSS.
| enahs-sf wrote:
| I think the day where Figma emits styled React components
| is closer than you think, but the jobs are safe for now.
| radus wrote:
| Definitely not looking forward to 99% of any group being out
| of jobs.
| [deleted]
| et1337 wrote:
| Is it just me, or is this ASP.NET ViewState from 15 years ago?
| benoror wrote:
| IMO there's no way around building real production apps starting
| from the UI. Design has to begin with data model. It's like
| building a House not from the foundations but from the facade.
| eurasiantiger wrote:
| Agreed. Design needs to be driven by the data model, and the
| data model needs to be driven by business entities. Any top-
| down approach is nonsensical, exactly as you describe.
| gervwyk wrote:
| Totally agree with this!
| troysk wrote:
| Ruby-on-Rails with some magical gems(devise, simpleform etc.) can
| do this even faster and probably better looking.
| brian_herman wrote:
| Are we going to see a version of Visual Basic being reconstructed
| with javascript soon?
| srcreigh wrote:
| What some people don't realize is the ubiquity of these types of
| custom-application-platform systems.
|
| Emacs is one of them. Linux is one of them. The web browser is
| another. VSCode and most IDEs are another. Rails. Flash. React.
| The C programming language. Of course, many unsuccessful ones too
| which I don't care to name...
|
| My point is that it's good to have competition in this space. Who
| knows at what point the world will be ready for another higher
| level of coding? Even if this system fails, how many failures
| does this author need to accumulate before they discover
| something that is good?
|
| To the author: I applaud your efforts. One question though - how
| can we try it out?
| Lapsa wrote:
| You should try Microsoft WebForms. Build apps in seconds!
| [deleted]
| georyb wrote:
| I wonder how it deals with any migrations? What if I decide to
| connect different components later? Or add a new attribute /
| column?
| ukd1 wrote:
| Came here to ask this; it's essential to have this, as likely
| you'll do something like was demo'd in the video - start with a
| single list, maybe move to multiple. Note, the items
| disappeared.
| echelon wrote:
| Between techniques like this, no-code, capable component
| libraries, and ML-driven synthesis, I could see a lot of easy
| application programming going away. Especially if the resulting
| output is literate, self-documenting, and easily amenable to
| later human editing.
|
| The harder subjects seem like the design of complex schemas and
| algorithms, complex UIs, scaling, and systems-level integration.
|
| Perhaps the easy/edge pieces will fall to automation, leaving the
| middle and low-level work to engineers and designers.
| goatlover wrote:
| Wordpress and Wix already exist, as do similar things for phone
| apps. But when you need to customize those and add new plugins,
| themes or features and tie them together, you still need
| developers. If anything those tools and platforms create more
| opportunities for plugin and theme authors. The whole
| automation thing in software is nothing new. It just scales up
| demand for ever more kinds of complicated software products
| people want to buuild.
| commandlinefan wrote:
| > I could see a lot of easy application programming going away
|
| In my experience, "easy applications" are already something you
| can just go buy cheap, or even download for free - other than
| for the learning experience, there's no point in coding one.
| qsort wrote:
| > Especially if the resulting output is literate, self-
| documenting, and easily amenable to later human editing.
|
| Big 'if' right there.
|
| I can see 'solved' problems being increasingly automated away
| (how many times do we need to write basic auth systems?), but
| in order to automate the entire pipeline you would need:
|
| - a specification language so detailed that it's basically a
| programming language
|
| - assumptions so strong they're liable to be subtly wrong
|
| ML can help, but we've all seen codex... we aren't there yet.
| gumby wrote:
| A "MySpace for Apps".
|
| Many would consider that a condemnation, and probably a well
| deserved one too.
|
| But I mean it in a positive sense: the democratization of
| development, the way DTP democratized printed expression (back
| when that was a thing).
|
| Also hopefully means programmers can spend their time on more
| interesting and value-adding effort rather than having to take
| the time to simply put a button on the screen.
|
| Of course the dream of rapid development goes back to FORTRAN.
| cabalamat wrote:
| > the democratization of development
|
| Like HyperCard, back in the day.
| gumby wrote:
| One of the few successful examples.
| tmpz22 wrote:
| "Writing books in minutes not months"
|
| Who else is excited to read it?
| 88913527 wrote:
| My critique is this tool seems like you'll hit walls as soon as
| the framework can't do exactly what you need. Oh, you need a
| sortable to-do list? Just use the "DatasetSortable" React
| component instead of the normal "Dataset". What if the framework
| doesn't have a say, filterable, dataset component? What if you
| need access control? What if you want to share your todo list
| with others? I don't realistically see how this grows beyond the
| trivial, unless the framework solved your concrete need.
| gmaster1440 wrote:
| There's an excellent talk by Rich Hickey (I believe it's this
| one[1]) where he points out an obsession with how quick something
| is to understand immediately and be productive in--he gives the
| example of building websites in a single day, and contrasts it to
| musicians learning and mastering instruments over much longer
| periods of time.
|
| While it's very intuitive to see the appeal in low barrier to
| entry, there's something to be said about tools that optimize for
| the long-term. Instruments aren't made for beginners, they're
| made for people who know how to play them.
|
| [1] https://www.youtube.com/watch?v=MCZ3YgeEUPg
| DoreenMichele wrote:
| I don't code. I would love to learn and may still someday and
| there's an app I would like to build.
|
| This article doesn't give me any idea where I would start. At
| all.
|
| I wish it did. I've looked around for quick and dirty ways to
| try to build the app I want to build. They never seem to do
| what I want them to do, the "in minutes" part fails to
| materialize for an outsider without a strong coding background,
| etc.
|
| I think there are some wonderful tools out there and it's
| always good to lower the barrier to entry so people with other
| strengths can do their thing, but I read ideas like this and
| think of a book I saw written by a professional clothing maker
| who was decrying the shortcomings of off-the-rack clothes and
| the punchline was to the effect of "Why would you wear that
| dreck? Life is so much better when you can easily make custom
| pants in minutes -- like I can because of my many years in the
| industry!"
|
| I didn't buy the book. My mom sews beautifully. I know
| something about making clothes and, no, you aren't going to
| replace off-the-rack clothes with teaching the whole world how
| to make custom clothes "in minutes" because that's so much
| better and easier.
| pdimitar wrote:
| Yes, you are very correct. The "build X in minutes"
| definitely assumes strong background because _you know what
| look for_. Without that you might as well give it blank
| stares for a year.
|
| But then again, I am not sure this article -- and presented
| technology -- is aimed at you. IMO it's more aimed at jaded
| programmers who are sick of hand-rolling the ever-almost-the-
| same 99% identical code for each project. Hopefully such
| tools can give them a less stressful time.
|
| For a programming beginner who would like to build something
| you'd be much better off looking at something like Airtable.
| PaulDavisThe1st wrote:
| Ditto for both power- and hand-tools used for most craft.
| eof wrote:
| Some instruments are made for beginners. I think the same
| correlations would be easy to find in software productivity.
|
| C++ :: Saxaphone Wix :: Recorder; or something
| RcouF1uZ4gsC wrote:
| > I think C++ is more like the French Horn
|
| Excerpts from https://houghtonhorns.com/why-is-the-french-
| horn-so-hard-to-...
|
| The French horn is widely considered to be the most difficult
| brass instrument to play.
|
| The modern-day double French horn is actually a combination
| of two horns (F, Bb) that share a common mouthpipe and bell.
|
| Because the partials (available notes in the harmonic series)
| are so close together in the third octave, the horn's most
| comfortable range, it is fairly easy to miss or "crack" a
| note. Conversely, the partials that occur in the trumpet's
| most comfortable range are comparatively more spread out,
| allowing for a bit better accuracy and more control.
|
| Another reason for the horn being difficult to play lies in
| the fact that it has the widest range of all the brass
| instruments: nearly as high as a trumpet and almost as low as
| a tuba. Additionally, the horn mouthpiece is small and deep,
| requiring fine muscle control and embouchure development. The
| mouthpipe is long and slender, creating more resistance for
| the player to overcome.
|
| Because the horn faces backwards-as opposed to the other wind
| instruments-the horn player must work extra hard to balance
| and blend with the other members of the wind instrument
| family.
| helgee wrote:
| The French horn is a holy instrument. Because if you blow
| into the mouthpiece, only God knows what will come out of
| the other end.
| [deleted]
| zwieback wrote:
| I know C++, played some sax in my youth and recorder as a
| child. If only I knew Wix, then I could connect the two dots
| in a 2D graph!
| hikerclimber1 wrote:
| everything is subjective. especially laws.
| f0e4c2f7 wrote:
| I'm going to watch that talk later it sounds interesting.
| Thanks for sharing.
|
| This may be addressed in the talk but my immediate reaction is
| that a truly mastercrafted tool should be both. I tend to agree
| that where you have to make choices lean towards long term
| (thats what I personally prefer at least). I think I've
| sometimes romanticized that attitude a little bit though and
| reveled in complexity for the sake of complexity.
|
| Ideally you're building stuff thats easy to learn but takes a
| lifetime to master (because of depth of the field, hopefully
| not because of the unnecessary complexity of the tool.)
| sva_ wrote:
| Wouldn't building a website be more equivalent to playing the
| instrument? Presuming one has learned how to build a website,
| like a musician learned to play an instrument.
| dv_dt wrote:
| Learning general website building technology is like learning
| to play an instrument, but being asked to build a given
| website is like being asked to give a performance. It might
| be a quick rendition or it might be a major performance on a
| stage (with one obviously being much more prep time than
| another).
| dcuthbertson wrote:
| Yes! We could consider JavaScript, HTML, and CSS as the set
| of instruments. Then by creating the Conductor framework
| the author has not only "practiced his instruments", but
| shown proficiency and created a nice performance.
|
| As for those who wish to use his framework, it's probably
| not enough to use it alone. It's mostly just another
| instrument that can be played solo, but to orchestrate some
| web apps, one will have to include the JavaScript, HTML,
| CSS and probably a few other "instruments".
|
| Apologies if I strained that analogy too much.
| sva_ wrote:
| Maybe a coder is more like an improvising Jazz musician.
| Would explain a few things.
| hamburga wrote:
| That's what the Rich Hickey talk is all about!
| HomeDeLaPot wrote:
| Also, do you know the song(s) already, and do you know how
| to play the particular instrument requested?
| dhosek wrote:
| That's a good aspect of the analogy. I can play pretty
| much anything with strings (not necessarily well, but I
| can play it), but being able to play a particular song on
| it is another thing.
|
| Likewise, the programming side of my work is generally
| pretty trivial (as is the case for probably 99% of most
| programming that happens in the world). It's the domain
| knowledge that makes things
| difficult/interesting/challenging.
| andkon wrote:
| Learning to play an instrument is usually about learning many
| many tiny discrete skills that build on one another and can
| be combined in creative ways to express what's most important
| and vital at that moment.
|
| You can play an instrument knowing just to pluck a single
| note. But it's a lot more fun to play if you know a ton of
| different skills: you can say so much more.
|
| I think the same holds true for coding. You can learn more
| skills all the time, all of which broaden the realm of what
| you can create when you sit down at a keyboard again (aka the
| playing the instrument part).
| [deleted]
| _peeley wrote:
| Another great Rich Hickey talk is _Simple Made Easy_ , very
| similar message. So many of these auto-project tools are very
| easy to use, but in no way simple to understand and end up
| adding complexity in the long-term.
|
| A good example is a tool like `create-react-app` (especially if
| you add TypeScript support). It's super easy to use and creates
| the project scaffold and enormous JS build system for you, but
| good luck trying to fix it if something breaks!
| stickfigure wrote:
| I generally agree with your thesis (especially WRT this
| article) but create-react-app is a terrible example. I
| converted a fairly large handrolled webpack project to CRA,
| and it actually _fixed_ a lot of broken things.
|
| For most single page apps, create-react-app occupies an
| abstraction level "sweet spot". Webpack is too low level and
| changes too quickly.
| 88913527 wrote:
| My actual experience with reporting the "something broke" in
| a large, popular OSS project was 18+ months until resolution.
| A crafty engineer thought it was a good idea to run their in-
| house optimization on third-party JS libraries to squeeze a
| few extra bytes out of the final bundle size (going above +
| beyond conventional methods like minification). Turns out
| that the overly aggressive optimization caused runtime
| exceptions, and they ended up cleaning up the feature.
|
| I've never had a good long-term experience with tools that
| try to be or solve everything for me, and today I avoid them.
| jackTheMan wrote:
| it was the same with GWT (google-web-toolkit) it looked nice
| and many jumped to the bandwagon. But when something didn't
| work as expected you had to know a lot about debugging
| javascript (the internal work of javascript) and guess about
| the generation logic from java and think backwards. After
| all, you had to know more (then simply js) for debugging! And
| of course if your boss wanted something custom..
| skinkestek wrote:
| I don't know what you do but I maintain 3 projects based on
| create-react-app and have done for 18 months. Together with a
| couple of senior guys and some younger devs (both guys and
| gals) I keep them updated, build new features, rewrite stuff
| to tsx (we got the projects handed down) and with one single
| exception I never even thought about the build system.
| aeturnum wrote:
| I don't think they were saying create-react-app is bad or
| unusually fragile. It's that there are problems in building
| increasingly complex 'quick start' setups with the goal of
| making them accessible to people with less experience.
|
| The less you know about how the internals work, the less
| you'll be able to intuit about what you can and can't
| change. For many people who just want to make "an app" this
| doesn't matter, but it also means that a lot of quick start
| setups optimize for particular approaches that are built on
| top of particular sub-sets of how apps are built. So people
| leave the experience knowing more about how a particular
| component library than they do about the language or the
| requirements of mobile, or whatever.
|
| Or, to put it another way: increased complexity also
| increases the difficulty of investigation and modification.
| Making it easier to get an app 'somewhere' can make it
| harder for someone to understand what the app does to get
| where it's going.
| tshaddox wrote:
| > It's super easy to use and creates the project scaffold and
| enormous JS build system for you, but good luck trying to fix
| it if something breaks!
|
| I've always found myself experiencing that same feeling, but
| I've come to realize that this is essentially impossible to
| avoid by definition. Any tool or system you're using that is
| built using abstractions must by definition have some
| limitations at the boundaries of those abstractions, and
| those limitations can only be circumvented by jumping across
| that boundary. The only real decisions you can make are
| _which tools to use for a particular job_.
| potatolicious wrote:
| This is a major beef I have with many modern frameworks -
| many confuse verbosity with simplicity or ease.
|
| Conceptual complexity is of enormous importance to the
| usability of a tool. I build APIs for a living and have often
| needed to push back vociferously over things that would make
| code terser, but the underlying mechanisms harder to
| understand.
|
| That said, I actually think codegens are often the right tool
| for the job - it removes a lot of boilerplate (at least from
| the developer needing to write it) but doesn't obfuscate
| underlying mechanisms - those are free for examination as
| needed.
|
| Of course, the devil's in the details - if the codegen'ed
| stuff is pure spaghetti that defeats this benefit.
|
| The worst, worst sin of all are frameworks that insert
| "magic" functionality. For example: name a thing in a special
| way and stuff will automagically happen to it? I can't think
| of a worse, more opaque way to design a system than rote
| memorization of incantation that reveal nothing about what's
| actually happening.
| yangikan wrote:
| I guess what would be useful is a "Visual Basic for the web".
| Back in the day, one could bring up pretty large applications
| quite quickly using Visual Basic and Delphi.
| TuringTest wrote:
| What would be useful is an "Excel for web apps". The
| spreadsheet runtime model is much better adapted to the way
| non-developers think than what VB6-style visual programming
| provides.
|
| Having code and actual application data allows people without
| programming experience to build data types and simple to
| average functions and debug errors in the business logic,
| whereas with classic code they can't get pass the parser to
| get their poorly written syntax understood by the compiler.
|
| Developers tend to think that writing simple code makes
| application development easy, but actually learning the
| syntax and runtime model of classic imperative code is
| usually the hardest part to newcomers.
|
| The functional-reactive execution of the spreadsheet together
| with the intermixing of data and code provides a simple
| mental model of instant evaluation and exploration, similar
| to the benefits a REPL provides to a seasoned developer,
| minus the syntax errors and deep nested structures.
|
| Notebook-style development environments like observablehq.org
| are _almost_ there (specially those with a spreadsheet-like
| semantics), though it still keeps too harsh a separation
| between the code environment and the "runtime values"
| environment - i.e. its cells are "too large" when compared to
| spreadsheet cells.
| wolpoli wrote:
| We kind of do with ASP.NET Blazor. It still isn't as simple
| as the VB back in the 90s through.
| madflame991 wrote:
| I come back to this article every now and then
| http://www.loper-os.org/?p=861
| suifbwish wrote:
| More importantly there are dumb as shit C level people out
| there reading this that are going to think there is something
| wrong with their developers because they don't make apps in a
| day/minutes/(fill in other dumb and obviously false timeframes
| for a production time allotment here)
| NoGravitas wrote:
| > "dumb as shit C level people"
|
| It is preferred, stylistically, to avoid redundancy in your
| writing style these days.
| true_religion wrote:
| People are okay with how long it takes to master computer
| programming (or science). If they weren't we wouldn't have 4
| year degrees for it.
|
| However unlike music, there are new tools being made constantly
| because the practice of programming feeds the same skills one
| needs to make tooling.
|
| If musicians had 10,000 instruments to choose from, each with
| some subtle gotcha that will only make itself known once you
| get in deep... then maybe they'd want instruments to be easy to
| play too.
|
| A good comparison is songwriting. Lots of artists like songs
| that are easy to play. Piano pieces that are complicated get
| put down for later, unless they are classical master pieces.
| Guitar songs that require too fast a rhythm don't get as much
| play time in anyone's jam session either.
| bob229 wrote:
| Terrible analogy. Building a website is not the same as
| learning how to build a website(or an instrument)
| iainmerrick wrote:
| The musical instrument analogy can be taken the other way,
| though.
|
| After you've spent years learning to sight read, you can play
| almost anything right away if you have the sheet music, even if
| you've never heard it before.
|
| Or after you've spent years learning to play by ear, you can
| play any tune you know from memory, or jam along to almost
| anything.
| splistud wrote:
| These are excellent points. But what if a musician is hired to
| compose a song that is to be played on a brand new instrument?
| Would the musician not want the instrument to be playable
| rudimentarily very quickly, so he can begin to demonstrate
| where he is going with the song, so as to get early feedback?
|
| While this is a tortured analogy (as a musician, I want no
| feedback until I'm done). I believe that wanting tools that
| optimize for the long-term, coupled with needing early feedback
| is precisely why many use certain technologies for demos, then
| build in other technologies.
|
| The faster the demo can be built the better. The earlier you
| get feedback on the UI the better. The earlier you show a demo,
| the sooner you find out what the user really needs as compared
| to what you've been told (and the sooner the user finds out
| what they don't need, despite what they thought).
| hardwaregeek wrote:
| Except...are most apps that creative? Let's face it, a lot of
| programming is boring variations of CRUD. Yes there's creative
| code and I'm sure Rich Hickey does a lot of it, but there's a
| lot of boring, banal code that we shouldn't be real precious
| about.
| dgb23 wrote:
| I make those. And yes, it's 90% boring in terms of tech. The
| exciting part is to make something that my users like to use,
| that fits them like a glove. And polish. Polish is hard and
| endless, there is always a tension between pragmatism and
| perfectionism.
|
| Those two parts demand the most seamless and direct
| expression, and continuous feedback. It's not quick, it's
| deliberate and diligent. That's what I value and aspire to.
| cies wrote:
| There's always challenges.
|
| Let's say we needs some forms. Nothing to fancy. Consider 2
| options: React+JS+Redox+formLib+... and Elm.
|
| It just some banal forms, I agree. But having to come back to
| it may months/years later I much rather see back the Elm
| situation.
|
| Typing helps a lot here. Small scope project too.
|
| Now it seems this "build in minutes" uses JS and PHP. Sorry,
| but both are terrible choices for long term maintainability.
| TillE wrote:
| The vast, vast majority of playing an instrument well is
| about deep technical skill, not creativity. That's what we're
| discussing here.
| abetusk wrote:
| Notice that the explosion of rap, hip-hop and punk were because
| the barrier to entry to music making through sampling and
| distribution was lowered. The 1980s and 1990s were replete with
| high profile artists that became famous by using the discarded
| drum machines and synthesizers of the time [0].
|
| Today, (I believe) most artists use synthesizers and DAWs to
| create full albums. Eletronica, rap and hip-hop are some of the
| most popular musical genres [1] [2]. It's not uncommon to see
| artists that are just one or two people, enabled by a
| professional grade studio on a PC.
|
| [0] https://www.theverge.com/2017/4/3/15162488/roland-
| tr-808-mus...
|
| [1] https://ucladatares.medium.com/visualizing-trends-and-
| patter...
|
| [2] https://www.r-bloggers.com/2017/12/clustering-music-
| genres-w...
| skrebbel wrote:
| I disagree that this is a good analogy, because you're
| referring to a financial barrier to entry and the GP is
| talking about effort, not money.
|
| Of the genres you mention, only punk could reasonably be
| considered a low barrier to entry genre in that some of the
| biggest punk bands were famous for hardly being able to play
| their instruments. But it's also the single genre missing
| from your "Today," paragraph, indicating that yes, indeed,
| making good hip hop or electronica is hard even with a
| fantastic computer with fantastic software.
| teebs wrote:
| As much as I love hip hop and electronica, and as difficult
| as it is to make excellent music in those genres, it really
| is very easy to make okay music. Have you ever used FL
| Studio (formerly known as FruityLoops)? I remember
| downloading it freshman year of high school and being able
| to make a catchy-but-derivative hip-hop beat in minutes.
| That's not enough to make a hit song, but I think luck is a
| bigger factor than effort for a lot of underground hits.
|
| Today, it's still how a lot of hip-hop and electronica gets
| made: https://en.wikipedia.org/wiki/FL_Studio#Notable_users
| filoleg wrote:
| >As much as I love hip hop and electronica, and as
| difficult as it is to make excellent music in those
| genres, it really is very easy to make okay music.
|
| Before finishing reading that sentence, i was ready to
| get upset, but the ending made it so that I perfectly
| agree with you.
|
| Modern music production experience allows for a fairly
| easy way to make ok music, but to make good or great
| music, it is still just as difficult (if not even moreso,
| albeit not for financial reasons anymore, unlike how it
| used to be in the past). Basically, easy to learn at a
| beginner level, still difficult to master. Which is imo
| the optimum, because some of the best competitive games
| ever are set up like this. E.g., learning the rules of
| chess is easy, mastering chess is an extremely long path.
|
| A bit off-tangent, but we also gotta understand that
| genres evolve from infancy to maturity as well. In terms
| of music production and composition, 80s/early 90s hip-
| hop was indeed fairly basic and primitive. Lyrics,
| similarly, were also focused mostly around the same
| cluster of topics related to living a tough life
| surrounded by crime and police brutality and such. But it
| was new, original, and covering bases that were not
| covered before in the same way.
|
| Hence why it started gaining traction and popularity. As
| genre matured and evolved, music production for it got
| much much more complex and involved, where the ceiling
| for "well produced hip-hop" has went up massively. Just
| compare any track from Kanye West's "My Beautiful Dark
| Twisted Fantasy" (2010) to some classic like NWA's
| "Straight Outta Compton" (1988). Both groundbreaking
| albums for their time, both still enjoyable, but there is
| no way to compare them in terms of music
| production/composition in a serious manner in 2021, as it
| is just night and day. The sheer complexity of MBDTF is
| something that set the new bar for the entire industry on
| its own. Lyrics on MBDTF are also touching topics that
| early hip-hop would never touch with a 10-foot pole back
| in the day.
|
| TL;DR: fully agreed, music production became much easier
| to enter and produce beginner level stuff, but the
| ceiling went up significantly as well (which is a good
| thing). What was groundbreaking level production in the
| late 80s/early 90s will get rotten eggs thrown at you in
| 2021. Which makes hip-hop music production (as well as
| most other genres that are evolving) just as difficult of
| an art to master these days, if not even more difficult,
| but only because the bar is set much higher. The actual
| availability, cost of equipment, learning material
| access, etc. has become insanely easier.
| [deleted]
| abetusk wrote:
| Synthesizers provide a wide array of different types of
| instrument in one housing (brass, strings, pads) in
| addition to effects and sequencers. This means a
| synthesizer can supplant what would have classically been
| one or many different people in a band. The same goes for
| drum machines.
|
| DAWs provide most of the benefits of synthesizers and drum
| machines with the additional benefit of being a production
| studio.
|
| You rightly point out the barrier to cost is being reduced
| but, in my opinion, this goes hand in hand with complexity.
| After all, I "could have just hired a band" to experiment,
| play around and bring my vision of music to life. Is
| putting a band in a computer for less than $300 "just a
| matter of reducing cost"? Encapsulating complexity is often
| synonymous with reducing cost.
|
| Any tool, even ones that are cheap and/or encapsulate
| complexity, require training to use well. The question is
| whether they can be used "professionally" with a modicum of
| training or whether they need a lifetime. A good artist can
| probably be proficient enough with a synthesizer, drum
| machine and/or DAW in a year or two before starting to
| create quality work. It takes a lifetime to become a
| professional at the piano or violin, often requiring
| exponential more work for increasingly marginal gains.
| dbattaglia wrote:
| I'm not sure I understand the point. While the economical
| barrier to entry for producing music is lower with
| electronics and computers, it still requires time and
| dedication to be proficient in it. Most DAWs and synthesizers
| reward practice and dedication the same way a guitar or
| Clojure does.
| TeMPOraL wrote:
| > _obsession with how quick something is to understand
| immediately and be productive in--he gives the example of
| building websites in a single day, and contrasts it to
| musicians learning and mastering instruments over much longer
| periods of time._
|
| That's an entirely orthogonal concern to what the article is
| about.
|
| I agree that obsessing over the "zero to proficiency" time the
| way we do nowadays is very much counterproductive, for the
| reasons you mentioned. But you also want to be quick for a
| different reason - to make the tool better for the already-
| proficient user.
|
| Rich also talked a lot about essential vs. accidental
| complexity. I don't know about you, but myself, the more I
| code, the more I feel 90%+ of my time spent on coding, and even
| a good chunk of the design/architecting time, is accidental
| complexity. This is not just a matter of bad APIs and
| overcomplicated design - the whole process of programming just
| _takes too fucking long_. The languages we use are not
| expressive enough, not succinct enough to capture our
| solutions. The tooling we use is not powerful enough to allow
| for an efficient exploration of the solution space.
|
| So the other day I was writing some glue between two
| incompatible systems. I had my data structures well designed, I
| know how all the operations mapped. I would be able to write
| you a precise description of everything in an hour. It still
| took me more than a week to code it up. All the classes,
| functions, modules, files, syntax issues, gluing different
| types of error handlers, baah. Midway, I figured I made a
| mistake in the design. I knew how to correct it in 30 seconds.
| It would take a single sentence to explain the problem and the
| solution. It still took me an hour to implement the fix,
| because I had to change type signatures, move some files
| around, and update half a dozen places because it turns out you
| can't just automatically make bulk modifications in languages
| that aren't Java or C#. And don't get me started on how much
| time it takes to figure out the structure of a subsystem in a
| legacy code base...
|
| Point being, even if you know your language and problem space
| inside out, even if you have decades of coding behind you, day-
| to-day coding _still takes way more work than it should_.
|
| To me, existing tooling feels conceptually too low-level.
| _Writing_ feels too low-level. One may counter that typing is
| mechanical, programming happens in the head - that 's true, but
| at least to me, typing (and especially editing) still has
| enough overhead that I _feel_ my brain slowing down. The
| feedback loop is too slow.
|
| What I'd currently love to have is code editing environment
| operating on high-level semantic concepts. One keychord to
| select a function and display all its callers and callees, in a
| graph. One keychord to select a parameter and display a diagram
| of how it flows through code. One key to start inserting a
| class. One key for adding, deleting or editing anything that
| isn't a name or comment. References, files, folder structures
| handled automatically. Etc. Because if testing a single design
| variation will take me 10 minutes instead of half a day, then I
| might be able to test a bunch of them instead of committing to
| first one that feels reasonable.
|
| </rant>
| spinningslate wrote:
| not sure I agree with your 'wants' at the end, but I _do_
| want to frame the earlier paragraphs. I feel that pain too.
| Fred Brooks thought we 'd largely have eliminated accidental
| complexity by now [0]. The "out of the tar pit" paper [1]
| tackles that and shows it's hard.
|
| But if anything, accidental complexity has got worse. Go back
| 30 years and a useful command-line tool could reasonably be
| coded in a single .c file, compiled in a single command, then
| run.
|
| Now: full-stack web apps are a lot more complex than command
| line tools. But, with contemporary tooling, the accidental
| complexity has scaled at least linearly, probably worse. Just
| setting up a front end dev environment is a lesson in
| complexity theory. And then there's manually crafting the UI-
| to-service messaging, k8s deployment templates, build
| pipeline, and all the other tasks that have nothing directly
| to do with the actual functional requirements.
|
| I don't know what the answer is. Per other posts in the
| thread, I don't think it comes from conflating "0 to expert
| in 12 hours!" with "productive tools for skilled and
| experienced users". Low/no code fits into the former category
| (and maybe has a place, I don't have an opinion there). I
| don't see much addressing the latter space.
|
| [0] https://en.wikipedia.org/wiki/No_Silver_Bullet [1]
| https://github.com/papers-we-love/papers-we-
| love/raw/master/...
| kitd wrote:
| _Just setting up a front end dev environment is a lesson in
| complexity theory_
|
| FWIW, because I've been out of web dev for a while and may
| need to get back into it, I came across this site today:
|
| https://modern-web.dev/
|
| I followed their example ts+preact+esbuild setup and was
| very pleasantly surprised by the ergonomics.
|
| I was expecting way worse.
| ryandrake wrote:
| To add to this, for the solution that takes you 30 seconds to
| articulate and 1 hour to code, let me guess---About 5 minutes
| of that hour is writing the business logic that solves the
| problem, and 55 minutes are things like: 1. Boilerplate:
| Headers and includes, function and variable declarations,
| comment blocks in the right place, class this, interface
| that; 2. Reformatting: casts, serialization, deserializating,
| data marshaling, transforming from one data structure to
| another; and 3. Refactoring: adding an argument to function X
| requires manual upstream changes in all 25 places that call
| function X, making data Y an enum instead of a bool requires
| identical changes in 50 other files. Crap like this is pure
| brain-off typing that takes the vast majority of the time you
| spend "coding."
|
| I'd love to see better tooling that automates the crap and
| lets us focus on the actual business logic and value add.
| TeMPOraL wrote:
| You're exactly correct. Like reading my mind. You've
| itemized the exact things that take 90%+ of any code I
| write. I didn't immediately notice it - it became apparent
| only when I realized I'm writing almost the same, tiny,
| simple business logic for the third time, and it _still_
| takes way too long than it should.
|
| > _serialization, deserializating_
|
| I shudder when I even see these words. In the past two
| years, they've been the bane of my existence! A significant
| chunk of my coding time was wasted on countless little XML
| and JSON serializers/deserializers, associated error
| handlers, error messages, type recasting, etc. This is 100%
| because of bad tooling. I'd consider automatic generators
| for these, but they're external things that don't integrate
| well - which comes with more devops and maintenance hassle
| downstream than the time they save. If I were doing Lisp at
| work, I could at least macro my way out of this pain, but
| alas.
|
| And the worst thing is, these things aren't _just_ "brain-
| off" time wasters. In recent months I've noticed I'm
| getting slowly but surely burned out by this. I can see
| myself slowing down halfway to finishing a feature or a
| bugfix, out of sheer mental exhaustion from dealing with
| bullshit.
| skydhash wrote:
| Relevant article: https://www.oreilly.com/radar/thinking-
| about-glue/
| TeMPOraL wrote:
| I'm not sure if I agree fully with its conclusion. I hope
| we'll figure better ways to eliminate glue code, or at
| least reduce it in size. Part of the problem is, it might
| be trivial to describe a data transformation between
| systems A and B in words, or even on a diagram, but it's
| still hell of a lot of work to put this in code. Again,
| accidental complexity abounds.
|
| But beyond the data transformation glue code they're
| talking about, there remains the problem of boilerplate
| and glue code required by the programming languages and
| build tooling being not ergonomic enough to deal with
| concepts we have in mind directly.
| fifilura wrote:
| This makes me smile and think back to the time I wrote
| business logic in pure SQL.
|
| How free from most of those things my days were.
|
| Just pure declarative logic. I have A and B, what is the
| shortest path to get to C?
|
| But eventually I got tired of that too and back to what you
| describe.
| Karrot_Kream wrote:
| Lol I ran into this just the other day. I've been trying to
| get a personal project finished before I head out on a trip
| in a few days, and due to lots of bad reasons (and I want to
| emphasize that these reasons are bad, not the language,
| partially because I made the choice while intoxicated) I
| chose Rust. The thing itself is just supposed to spawn a few
| other processes, check success statuses, and write some logs.
| I got caught choosing between accepting strings, PathBuf,
| Path, and AsRef<Path> for spawning subprocesses. I had to
| write my own error type, with `thiserror`'s help, in lieu of
| a stack trace to understand why my code was failing in
| portions. If I had done this in Python it would have taken a
| third of the time. Now obviously by choosing my types,
| ownership semantics, and data structures more carefully than
| Python's stdlib+runtime results in a much lower memory
| overhead and less CPU used, but I find myself constantly
| asking myself if it was really worth it (especially since I'm
| frustrated with my upcoming trip deadline). I'd love a world
| where I didn't need to make such a stark choice; where I
| could get the convenience of stack traces, errors, and fast
| iteration, without the performance hit that a heavily dynamic
| language like Python gives you.
|
| </another rant>
| pdimitar wrote:
| > _...the whole process of programming just takes too fucking
| long. The languages we use are not expressive enough, not
| succinct enough to capture our solutions. The tooling we use
| is not powerful enough to allow for an efficient exploration
| of the solution space._
|
| I lately started getting very sick of web dev (which I
| practice since 2009; way too long). This in turn made me
| scared for my future income but that's a different story. :D
|
| ...I completely agree that trivial shit takes way too long to
| create or update. Just today I complained on ElixirForum (not
| to the core team members of Phoenix, just in general) that
| nowhere in web dev do we have stuff like "make
| controller.param.add" (which will not just modify the
| controller but everything that depends on it) or "make
| controller.param.change_type" (which would generate / edit
| boilerplate for validation) or "make
| template.root.change_css_kit" (ha-ha, that one will only
| happen when AGI is invented!).
|
| I want a program that can modify programs, doing the text
| editing for me, structurally, not just regexes or even a bit
| semantic-more-like grouping of text (even that's not good
| enough). I won't reach for LISP even though I am fairly sure
| it being homoiconic will make this much easier, because no
| LISP runtime of any dialect offers transparent parallelism _a
| la_ Erlang /Elixir or the compile-time guarantees of Rust.
| But I do sometimes wish all languages were homoiconic
| regardless. :(
|
| Maybe I'll just gather some money and then just work on
| tooling that can do the above-described tasks.
|
| I won't fall into the trap of thinking that detailed UML
| diagrams can lead to 100% correct code generation (although I
| am tempted to this day!). But _there has to be a better way_
| than us wrangling characters on the screen manually all the
| time.
|
| And it's not even about typing. I enjoy typing.
|
| It's about the menial nature of many tasks. They just... kill
| you. They slowly drain all your creativity and dreams about
| the future and desire to change things for the better around
| you. One day you catch yourself just wishing the work week
| passed by quicker.
|
| We have to do something! But yeah, we're all slaves to the
| wage. I wish more of us were like @codinghorror; be rich
| enough to just one day ping a few buddies and say "hey guys,
| I am bored -- let's make a forum system" and boom, some years
| later you have Discourse that's being used more and more
| everywhere each day.
|
| I wish all of us could as casually work on stuff we love as
| Jeff Atwood did.
|
| <long-sigh-ends-here>
| fouric wrote:
| This "obsession with how quick something is to understand
| immediately and be productive in" is a good concept to have
| around, and it's something that's been tickling the back of my
| mind for a while.
|
| In particular, I believe that this effect is strongly present
| in the Cult of Text Processing - there's a large group of
| programmers who believe that Text Must Be The Answer because
| it's just so _easy_ to write `ls | grep` - never mind that each
| UNIX text-processing tool actually has its own bespoke input
| and output formats (it 's not actually plain text), and so
| anything nontrivial quickly becomes a fragile mess riddled with
| edge-cases and liberal use of sed/awk. What's even more
| interesting is that because of the perceived ease of immediate
| understanding, even those that have deep experience with this
| paradigm (and should understand how inefficient it actually is)
| still defend it.
|
| Although, I don't think that powerful tools necessarily have to
| have a high barrier to entry. For instance, maybe you could
| teach new programmers in Racket without type annotations, then
| introduce typed Racket as a way to allow them to much more
| easily learn static typing than adopting a whole new language?
| Such an approach might have made Rust easier to learn - just
| disable the borrow checker to learn an easier Rust, and then
| re-enable it gradually (starting with the easiest parts of your
| code and then moving to the more complex bits) to ease into
| what is usually the hardest bit for new Rust users.
|
| Tool- and language-developers should focus on making things
| that are _both_ easy to pick up (Python) _and_ scale well
| (Common Lisp /Rust).
| mpweiher wrote:
| > Text Must Be The Answer because it's just so easy to write
| `ls | grep`
|
| That's actually not quite it. What's so fantastic about the
| textual interface in Unix is that it is the same packaging[1]
| for both use _and_ reuse.
|
| This is highly unusual, usually packaging that is optimised
| for use is unsuitable for reuse (doesn't compose well) and
| packaging that is good for reuse is unsuitable for direct use
| (cumbersome/inconvenient).
|
| Using text to fill both roles comes with a _ton_ of
| compromises, as you rightly point out. It 's not really great
| at either function, but sorta/kinda gets by at both. But even
| with those compromises, pulling off the feat of having the
| same packaging for use and reuse is just incredibly powerful.
|
| There are other ways of achieving the same result, for
| example Naked Objects[2] bridges the gap by the programmer
| only providing the reuse packaging (an OO API) and the
| tooling then automatically generating direct-use packaging (a
| GUI).
|
| Other ways of bridging the gap that can learn from one or
| both of these approaches clearly seem possible.
|
| [1] https://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf
| /Pa...
|
| [2] https://en.wikipedia.org/wiki/Naked_objects
| janci wrote:
| Powershell cmdlets return objects that are suitable for
| reuse and also have their textual representation suitable
| for (human) use. I think the concept is beautiful, but the
| execution is awful.
| starfallg wrote:
| > That's actually not quite it. What's so fantastic about
| the textual interface in Unix is that it is the same
| packaging[1] for both use and reuse.
|
| That's the reason CLI tools are so powerful, and the reason
| why json and yaml aren't able to replace them. It's also
| the reason why human-friendly CLI syntax like Cisco IOS is
| better than programatic interfaces like the default syntax
| in Juniper JUNOS.
| gerdesj wrote:
| It may not be for you but if you are going to take the piss,
| please at least give an example that does not generate a
| syntax error: ls | grep
|
| grep needs input _and_ something to tell it what to do with
| the input.
|
| I think Cult is a little harsh but it is handy to simply
| chain stuff together to quickly get something done. Along
| with the nominal concept of it's all files you can get an
| awful lot done in a shell with minimal effort.
|
| Anything non trivial should get the full awk and sed
| treatment. The sort of system that has the GNU etc toolset
| available normally has python and perl available out of the
| box and probably php and a few more too - tools for the job.
| I also have something called pwsh that I dabble with - handy
| for fettling with VMware via Power CLI.
| cestith wrote:
| So it's a declarative display-oriented language with late binding
| embedded into HTML? It's... a web-native form of a FileMaker Pro
| app?
| foxbee wrote:
| Great post. This is a reality that a number of no-code and low-
| code tools bring to the table, including Budibase - an open
| source alt to retool, mendix, outsystems.
|
| If you are interested, check out the repo:
| https://github.com/Budibase/budibase
|
| It's used at Amazon, IBM, F1, Deloitte, NHS, and more.
|
| I'm the co-founder of the project and I hope you don't mind me
| posting - it felt relevant.
___________________________________________________________________
(page generated 2021-09-17 23:00 UTC)