Building apps in minutes, not months(alexanderobenauer.com)
alexanderobenauer.com
Building apps in minutes, not months
https://alexanderobenauer.com/labnotes/001/
302 comments
I applaud the guts that it would have taken to do something like that. That one hour meeting uncovered so many issues with the company that everyone probably already knew but didn't want to talk about - bikeshedding; long, pointless meetings; incompetence and apathy; etc.
I sometimes dream of doing something like that when there's endless back and forth about the "right" way to do something (in my experience, no one is actually looking for the right way. It's all just politics and laziness which ends up in a subpar compromise).
How did you convince people to sit through the entire hour once they caught on to what you were doing?
I sometimes dream of doing something like that when there's endless back and forth about the "right" way to do something (in my experience, no one is actually looking for the right way. It's all just politics and laziness which ends up in a subpar compromise).
How did you convince people to sit through the entire hour once they caught on to what you were doing?
"Guts" sometimes means "Something's gotta give or I'm outta here anyway." Other comments here suggest that was likely the case.
Always be leery of emulating such actions. No matter how much detail they give, you will never know the full context and how well your situation compares to theirs.
Always be leery of emulating such actions. No matter how much detail they give, you will never know the full context and how well your situation compares to theirs.
That's why it's only a dream ;)
Hang on. Let's assume the story is false. Why would you want to discourage anyone from having the courage of their conviction that they could find a better way to do something their bosses say is impossible?
Someone with real conviction isn't going to be talked out of it by a two paragraph comment by a random internet stranger on HN.
You are reading way to much motive and way too much power into a casual observation about how so-called courage is sometimes anything but.
People who seem "brave" may not feel they are at all brave. They may feel fed up, resigned to their doom, disgusted, defeated, like arguing or cooperating with known liars is utterly pointless, like they are screwed anyway and nothing they do will ever fix it.
Sometimes it's nice to get closure and know you weren't imagining things, it really is as bad as you feared and you can stop wasting your time and energy on a situation that simply will never go anyplace acceptable no matter what you do.
You are reading way to much motive and way too much power into a casual observation about how so-called courage is sometimes anything but.
People who seem "brave" may not feel they are at all brave. They may feel fed up, resigned to their doom, disgusted, defeated, like arguing or cooperating with known liars is utterly pointless, like they are screwed anyway and nothing they do will ever fix it.
Sometimes it's nice to get closure and know you weren't imagining things, it really is as bad as you feared and you can stop wasting your time and energy on a situation that simply will never go anyplace acceptable no matter what you do.
This was in response to your prev post.
I'm glad you answered the question directly with your own opinion. (I don't know why people don't do that more often). I think that is a wise and well thought out piece of advice that should be expanded upon. I did want to get past the layers of what you were assuming this person had experienced or what you assumed naive readers would do if they copied it. One thing I've learned - a reason I used to be a bad writer, and a reason why social media doesn't work well - is that I tend to gloss over four or five assumptions about what the reader understands or knows, and jump straight to a conclusion that can come off as weird or out of step. It does help to pry open the thought process that led to a warning or a sweeping statement... often, the thought process is what people are most interested in.
On this issue, I've never worked anywhere I didn't either start with or quickly open a direct line to speak with the owner of a company. I consider it their right to know what's going on - and I never sought advancement or raises, and more often quit, but I do think there's something to be said for sticking your head up and taking the risk of having it cut off, to prove you're right about something. That derives from a different impulse than the need for popular acclaim, and it's usually dangerous.
I'm glad you answered the question directly with your own opinion. (I don't know why people don't do that more often). I think that is a wise and well thought out piece of advice that should be expanded upon. I did want to get past the layers of what you were assuming this person had experienced or what you assumed naive readers would do if they copied it. One thing I've learned - a reason I used to be a bad writer, and a reason why social media doesn't work well - is that I tend to gloss over four or five assumptions about what the reader understands or knows, and jump straight to a conclusion that can come off as weird or out of step. It does help to pry open the thought process that led to a warning or a sweeping statement... often, the thought process is what people are most interested in.
On this issue, I've never worked anywhere I didn't either start with or quickly open a direct line to speak with the owner of a company. I consider it their right to know what's going on - and I never sought advancement or raises, and more often quit, but I do think there's something to be said for sticking your head up and taking the risk of having it cut off, to prove you're right about something. That derives from a different impulse than the need for popular acclaim, and it's usually dangerous.
So... maybe I misunderstood your comment. Your advice was to be leery of such actions. Are you saying to be leery because you believe those actions arise from a place of despair more often than from trying to remedy a situation or to be successful?
What would you tell someone who is genuinely trying to communicate a message to their boss's boss, about how things are mismanaged or how they could be done better... assuming that person is not lashing out from despair but actually wants to help the company?
What would you tell someone who is genuinely trying to communicate a message to their boss's boss, about how things are mismanaged or how they could be done better... assuming that person is not lashing out from despair but actually wants to help the company?
[deleted]
Does this make you better off besides feeling great for an afternoon?
At best you put yourself into the middle of a political fight fought levels above your head.
Why put your job on the line for no reward? Who cares if their Oracle queries are slow?
At best you put yourself into the middle of a political fight fought levels above your head.
Why put your job on the line for no reward? Who cares if their Oracle queries are slow?
Because the op has pride in what he does. Because he cares more about getting it done than the political faffery.
That's a my take on it, anyway
That's a my take on it, anyway
Right, some people want to do a good job and also get recognized for it. Whereas other people want to use politics to prosper from the work and ideas of others. The latter type don't care whose idea it was, who implemented it and did all the work, as long as they the gamers get the credit and rewards for it.
That's just life right? Yes but the point is for the former type of people it is very frustrating to work with the latter type, because not only you have to do a great job, you also have to put in a lot effort to fight the politicians. It is often better to get the hell out of Dodge rather than stick around with the bandits.
That's just life right? Yes but the point is for the former type of people it is very frustrating to work with the latter type, because not only you have to do a great job, you also have to put in a lot effort to fight the politicians. It is often better to get the hell out of Dodge rather than stick around with the bandits.
But software engineering IS about politics as well! We always think that SE is only about tech and being right and smart... the reality is: one needs to be technically right AND play politics in order to achieve anything within a company. lmilcin was probably technically right, but he didn't play well the politics part of the equation. Result? He had to quit, and he company didn't get a better search solution.
Well said. A good piece of work is its own satisfaction, and a broken piece of code is misery for everyone. People who fix broken things just because they're broken and should be fixed are the lifeblood of any organization. Once they're displaced by people who don't know, understand, or care, the organization is basically a zombie.
> Because he cares more about getting it done than the political faffery.
I agree, 100%, but this sentence is also the problem with OP's approach. Like it or not, being effective as a software engineer isn't just about getting things done. First, you have to get the right thing done (sounds like OP has this covered, though).
But, perhaps even more importantly, if you want to actually have real impact, you need to make sure the things you've created actually get adopted in the organization. And, that's literally the definition of "political faffery."
There's a very real sense in which anything that involves more than 3 people is going to involve politics in some way, but that's not what I'm talking about here. I'm more referring to the definition in The Devil's Dictionary, by Ambrose Bierce, specifically the first part: "A strife of interests masquerading as a contest of principles. The conduct of public affairs for private advantage."
As a mid-level or senior-level engineer, if you've been at the company for a few months, you should have some relationships that you can use to navigate the political landscape. As a staff or principal engineer, it's practically your job to have these relationships. As a junior, you should be looking to your manager, or higher level engineers on your own team to help you, should you get involved in a political mess, but, the best thing to do is to loop in your manager ASAP and avoid politically sensitive issues to the extent that is practical.
But, the bottom line is really just about power and numbers. If you don't have the right person or people on your side, if you try to bypass or undermine those people, or, sometimes, if a lot of people are really against you, it does not matter how technically great your project/service/process/whatever is. It simply will not get adopted, because you threatened entrenched interests.
If you're unlucky, and either don't have sufficient political capital, or you managed to expend most of it during this whole affair, this is where ignoring politics can ultimately lead to a not completely voluntary trip out the door.
I've seen projects that were brilliantly managed politically, and I've seen ones that weren't. Brilliantly managed projects aren't generally going to be the ones you notice, unless you're specifically looking for them and watching the politics of the whole affair. These projects often just look like projects that are succeeding, to the superficial outside glance. Even if there are technical delays, the fact that there is political buy-in for the project means that if you're championing such a project, you won't suffer for having your name attached to it.
Projects that weren't well managed politically can tend to start off well, but turn into shit shows later. Best case scenario for a project that doesn't achieve buy-in is that it gets shelved in favor of another approach. Worst case, the project is radioactive, and that's where it can lead to an involuntary trip out the door.
TL;DR: You can't care about getting things done to the exclusion of politics if you want to have any actual impact within an organization. Politics can easily make or break the success of a project, and it can be hard to tell if you're stepping on a political landmine unless you know the terrain well.
I agree, 100%, but this sentence is also the problem with OP's approach. Like it or not, being effective as a software engineer isn't just about getting things done. First, you have to get the right thing done (sounds like OP has this covered, though).
But, perhaps even more importantly, if you want to actually have real impact, you need to make sure the things you've created actually get adopted in the organization. And, that's literally the definition of "political faffery."
There's a very real sense in which anything that involves more than 3 people is going to involve politics in some way, but that's not what I'm talking about here. I'm more referring to the definition in The Devil's Dictionary, by Ambrose Bierce, specifically the first part: "A strife of interests masquerading as a contest of principles. The conduct of public affairs for private advantage."
As a mid-level or senior-level engineer, if you've been at the company for a few months, you should have some relationships that you can use to navigate the political landscape. As a staff or principal engineer, it's practically your job to have these relationships. As a junior, you should be looking to your manager, or higher level engineers on your own team to help you, should you get involved in a political mess, but, the best thing to do is to loop in your manager ASAP and avoid politically sensitive issues to the extent that is practical.
But, the bottom line is really just about power and numbers. If you don't have the right person or people on your side, if you try to bypass or undermine those people, or, sometimes, if a lot of people are really against you, it does not matter how technically great your project/service/process/whatever is. It simply will not get adopted, because you threatened entrenched interests.
If you're unlucky, and either don't have sufficient political capital, or you managed to expend most of it during this whole affair, this is where ignoring politics can ultimately lead to a not completely voluntary trip out the door.
I've seen projects that were brilliantly managed politically, and I've seen ones that weren't. Brilliantly managed projects aren't generally going to be the ones you notice, unless you're specifically looking for them and watching the politics of the whole affair. These projects often just look like projects that are succeeding, to the superficial outside glance. Even if there are technical delays, the fact that there is political buy-in for the project means that if you're championing such a project, you won't suffer for having your name attached to it.
Projects that weren't well managed politically can tend to start off well, but turn into shit shows later. Best case scenario for a project that doesn't achieve buy-in is that it gets shelved in favor of another approach. Worst case, the project is radioactive, and that's where it can lead to an involuntary trip out the door.
TL;DR: You can't care about getting things done to the exclusion of politics if you want to have any actual impact within an organization. Politics can easily make or break the success of a project, and it can be hard to tell if you're stepping on a political landmine unless you know the terrain well.
Interesting story. I did something similar for a bespoke monitoring/helpdesk/knowledge base for a big client in energy trading.
However it took me an afternoon and I did get permission: I just installed Oracle text on the existing database and replaced the old search by tags with the Oracle text instance.
Typically in these large orgs, writing an app is only one of the first steps; they also need to be maintained, updated, monitored which might require extra budget, which typically nobody wants to pay for because "everything works".
If you ever end up in a similar situation, you could consider the environment as a part of the challenge before you figure out a solution.
Nevertheless, the 1 hour meeting is a hilarious story, although I personally would avoid burning bridges on the way out: it might hit you in the face in another context when you least expect it....
Typically in these large orgs, writing an app is only one of the first steps; they also need to be maintained, updated, monitored which might require extra budget, which typically nobody wants to pay for because "everything works".
If you ever end up in a similar situation, you could consider the environment as a part of the challenge before you figure out a solution.
Nevertheless, the 1 hour meeting is a hilarious story, although I personally would avoid burning bridges on the way out: it might hit you in the face in another context when you least expect it....
I like this, but somehow I wonder, was this the right thing to do? I would say it wasn't, because both parties lost: lmilcin had to quit, some colleagues felt ashamed (rightly or not), and at the end Elasticsearch wasn't taken into account as solution.
Now, my cynic side of me also wonders: perhaps Elasticsearch wasn't the answer and that's why the proposal was shot down? We'll never know. What I do know is this: software engineering is as much about humans as it is about tech, so even if you know you are (technically) right, don't forget to address the issue from a human perspective (i.e., convince your colleagues that your solution is right, but don't make fun of them by highlighting how one individual (you) can make the whole project "in just 1h").
Now, my cynic side of me also wonders: perhaps Elasticsearch wasn't the answer and that's why the proposal was shot down? We'll never know. What I do know is this: software engineering is as much about humans as it is about tech, so even if you know you are (technically) right, don't forget to address the issue from a human perspective (i.e., convince your colleagues that your solution is right, but don't make fun of them by highlighting how one individual (you) can make the whole project "in just 1h").
> both parties lost: lmilcin had to quit
I think lmilcin won when he got to quit :-)
Was the right thing, I think (based on the info available here). There's an opportunity cost in staying and wasting years of ones life at such a place
(Note that GP wrote: "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" -- that was the stated reason for refusing it)
I think lmilcin won when he got to quit :-)
Was the right thing, I think (based on the info available here). There's an opportunity cost in staying and wasting years of ones life at such a place
(Note that GP wrote: "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" -- that was the stated reason for refusing it)
Curious to know your motivation to do this instead of more tactful methods? Were you aware ahead of time how it could come off?
I kinda suspected how it will end up.
Honestly, I knew immediately when I joined that I made a huge mistake. My patience for bullshit is very short and I am extra infuriated by people who just don't care to do a good job or help the company (that is paying their salary) and are completely fine crippling their own project for some strange power games.
I knew that if I was going to do what they (management) wanted of me -- which was to sit quiet and do nothing, I would have to leave anyway.
So I decided to give it a shot and it did not work.
But it sure was fun to watch these people trying to gather some response before they had a chance to reach their back channels to solve the problem another way.
Honestly, I knew immediately when I joined that I made a huge mistake. My patience for bullshit is very short and I am extra infuriated by people who just don't care to do a good job or help the company (that is paying their salary) and are completely fine crippling their own project for some strange power games.
I knew that if I was going to do what they (management) wanted of me -- which was to sit quiet and do nothing, I would have to leave anyway.
So I decided to give it a shot and it did not work.
But it sure was fun to watch these people trying to gather some response before they had a chance to reach their back channels to solve the problem another way.
This is why being a solo dev kicks ass, and why it's incredibly painful for me to read the stories of people who care about doing a good job getting crushed by these managerial hierarchies.
First of all, a good CTO would probably fire the lot immediately. But secondly, there's this human dynamic - did you ever have to work on a chem project in high school with 3 randomly assigned classmates? Were you the one who made sure nothing exploded, and then found yourself writing the paper and sharing the grade with them? Sure. Because they knew you would pull the weight. And they would go on to be middle managers just as lazy and work-averse as they were as teenagers. They prey on us... the people who think hard enough to do better. I don't know why you'd ever want to join an organization like that, but it's good you found a booming way out of it.
First of all, a good CTO would probably fire the lot immediately. But secondly, there's this human dynamic - did you ever have to work on a chem project in high school with 3 randomly assigned classmates? Were you the one who made sure nothing exploded, and then found yourself writing the paper and sharing the grade with them? Sure. Because they knew you would pull the weight. And they would go on to be middle managers just as lazy and work-averse as they were as teenagers. They prey on us... the people who think hard enough to do better. I don't know why you'd ever want to join an organization like that, but it's good you found a booming way out of it.
I much agree with you. I'm curious, does this apply to pair-programming?
I tend to pair up with artists where I handle the code and they command the visuals. I find that highly effective and the conversations around UI drive both people to double down on their work. I haven't participated in paired coding but I'd think it would work in a similar way. Really the smaller the team, the more motivated everyone is to pull their weight, but I've even worked on 5-6-person teams where at least one person declared themselves the "marketing" person was living off the fat of the land.
I think the most productive teams have people with partly shared, partly complementing skill sets. The shared skill must be important communication enabler.
For example, in a development team the shared skill sets could be ability to code (so don't bother with Scrum Masters and Product Owners who can't appreciate coding).
But it does not have to be coding, I have also seen teams which were all proficient in financial markets and used it as their language.
The complementing could be:
- one with long beard who has lots of experience and knows how to and how not to do stuff, can debug the hell out of everything and acts as problem solver of last resort,
- one who knows how to make beautiful graphics and UIs,
- one who knows how to manage infrastructure efficiently and reliably and knows how to do all the tiny pesky things to make stuff happen,
- one who is good at understanding the product side and can be liaison between dev team and clients/management (assuming he understands to use "we" rather than "I"),
- one who is not afraid to dirty their hands and do the absolutely most mundane stuff that nobody else wants to touch with 10ft pole,
and so on.
I think this promotes ownership which is always a good way to get them motivated. On the other hand having people with exactly same skill set (for example due to constant hiring profile) tends to result in people who feel to be exchangeable cogs in the machine and less of ownership. At least this is my subjective feeling.
For example, in a development team the shared skill sets could be ability to code (so don't bother with Scrum Masters and Product Owners who can't appreciate coding).
But it does not have to be coding, I have also seen teams which were all proficient in financial markets and used it as their language.
The complementing could be:
- one with long beard who has lots of experience and knows how to and how not to do stuff, can debug the hell out of everything and acts as problem solver of last resort,
- one who knows how to make beautiful graphics and UIs,
- one who knows how to manage infrastructure efficiently and reliably and knows how to do all the tiny pesky things to make stuff happen,
- one who is good at understanding the product side and can be liaison between dev team and clients/management (assuming he understands to use "we" rather than "I"),
- one who is not afraid to dirty their hands and do the absolutely most mundane stuff that nobody else wants to touch with 10ft pole,
and so on.
I think this promotes ownership which is always a good way to get them motivated. On the other hand having people with exactly same skill set (for example due to constant hiring profile) tends to result in people who feel to be exchangeable cogs in the machine and less of ownership. At least this is my subjective feeling.
Thanks for sharing, I've been in a similar emotional position, it's a bunch of bad stories to come before the good one, if there is ever a good one. Sounds like there was!
Hope you were able to find a better fit!
Hope you were able to find a better fit!
I'm working in a company with 20+ years of the legacy code base. We have a custom search engine fully optimized for our purposes. Decades were spent writing this code. It supports all the newest Linux kernel technologies. The codebase is really good. But every year a new inter tries to show that open source solutions are more reliable and faster. They don't try to write code in 1 hr of course. They spend 10 days on average to show proof of concept that is really fast for benchmarking, but it fails when we try to load testing data. I don't know why people think that nobody checked other solutions before them.
The argument wasn't that ES is wrong choice, but that it will take too much effort to integrate and too long to do so.
Group of managers wanted to choose Oracle based technology for this that would further entrench their team and they argumented they can do it faster and cheaper than the development team.
They have already succeeded getting sizeable part of business logic implemented in PL/SQL supposedly to improve performance.
ES would make all their plans obsolete in a hurry.
Obviously, they were not interested in improving the product but in grabbing power, budget and control of the development process. Also they needed to score some points to show they accomplished something during calendar year.
Of course development team was also slow to deal with problems and overworked with other projects. This only fueled actions of database operations.
So my actions angered both managers of database operations as well as development teams.
Group of managers wanted to choose Oracle based technology for this that would further entrench their team and they argumented they can do it faster and cheaper than the development team.
They have already succeeded getting sizeable part of business logic implemented in PL/SQL supposedly to improve performance.
ES would make all their plans obsolete in a hurry.
Obviously, they were not interested in improving the product but in grabbing power, budget and control of the development process. Also they needed to score some points to show they accomplished something during calendar year.
Of course development team was also slow to deal with problems and overworked with other projects. This only fueled actions of database operations.
So my actions angered both managers of database operations as well as development teams.
> Group of managers wanted to choose Oracle based technology for this that would further entrench their team and they argumented they can do it faster and cheaper than the development team.
That's true. Most Open Source solutions don't work on huge workloads. You can read about Hadoop at Facebook or MySQL. They fully rewrote MySQL engine and partially Hadoop. Oracle solutions work well on huge workloads.
This company is not a software developer. The software department is just another team inside the company. The first goal of any non-software company is to reduce costs for IT infrastructure and development. It's not Google or Facebook where software development is a key factor of company capitalization.
> Obviously, they were not interested in improving the product but in grabbing power, budget and control of the development process. Also they needed to score some points to show they accomplished something during calendar year.
Or just do their job: provides a reliable service for storing data. The main goal of the DB/SysAdmin department is to show 99.99% uptime. The software department could not guarantee this uptime. Of course, if all these software developers are good SRE that's another situation. But I'm sure no one has experience of supporting huge systems for years.
> So my actions angered both managers of database operations as well as development teams.
If you really want to change something it will be better to make a virtual team from both departments and discuss all pitfalls from both teams. Maybe you are solving non-existent problem.
That's true. Most Open Source solutions don't work on huge workloads. You can read about Hadoop at Facebook or MySQL. They fully rewrote MySQL engine and partially Hadoop. Oracle solutions work well on huge workloads.
This company is not a software developer. The software department is just another team inside the company. The first goal of any non-software company is to reduce costs for IT infrastructure and development. It's not Google or Facebook where software development is a key factor of company capitalization.
> Obviously, they were not interested in improving the product but in grabbing power, budget and control of the development process. Also they needed to score some points to show they accomplished something during calendar year.
Or just do their job: provides a reliable service for storing data. The main goal of the DB/SysAdmin department is to show 99.99% uptime. The software department could not guarantee this uptime. Of course, if all these software developers are good SRE that's another situation. But I'm sure no one has experience of supporting huge systems for years.
> So my actions angered both managers of database operations as well as development teams.
If you really want to change something it will be better to make a virtual team from both departments and discuss all pitfalls from both teams. Maybe you are solving non-existent problem.
> That's true. Most Open Source solutions don't work on huge workloads. You can read about Hadoop at Facebook or MySQL. They fully rewrote MySQL engine and partially Hadoop. Oracle solutions work well on huge workloads.
Most “huge” workloads are not actually Facebook-huge.
Most “huge” workloads are not actually Facebook-huge.
Well done. And I'd counter the naysayers by asserting that this is the only right way to go over the top of entrenched laziness. If it cost you the job, so much the better, because you'll never run short of clients desperately seeking someone who can think outside the box the IT department creates with every response saying "sorry, that's just not possible."
I feel like I just read this somewhere... https://news.ycombinator.com/item?id=28564507
Specially with ElasticSearch there is a huge difference between the time needed to set it up and the time needed to index it, making sure you don't crash your production DB while doing so, maintaining the index as the tiniest incorrect index insertion can mess up the entire index, and finally making sure the nodes in production don't run out of memory or other resources without extensive and property monitoring in production this is a perfect recipe for downtime. So I see their point.
See the game theory on this says it wasn't worth it. Should have just laid low and continued to collect the pay checks while plotting your next move.
I'm willing to bet they're doing better in life now than if they had stayed.
I think what I've proposed is a short term micro-optimization where you can eek out a few more checks while you search for a place that supports your creative thinking
Totally agree: why stop the pay cheques coming in because of pride.
It might seem like an easy situation when nobody's demanding you do a good job, on the contrary, as was in this case you did a good job and got fired because of that.
But if you agree to their rules then you must play by their rules, politics, and if you then don't put your best effort into playing politics you may find yourself on the losing side soon.
But if you agree to their rules then you must play by their rules, politics, and if you then don't put your best effort into playing politics you may find yourself on the losing side soon.
Not sure I follow the logic, he got fired for trying. Simple solution is don't try, no?
Ultimately you will lose in either situation, but one solution prolongs the paychecks.
Ultimately you will lose in either situation, but one solution prolongs the paychecks.
The paychecks can of course be prolonged indefinitely, if you agree to play their game with their rules. And depending on your situation of course it is useful to prolong the paychecks. I'm not saying quit, but consider that there is a cost also associated with staying which is that you can not do your best but have to spend time and energy to learn to "play the game by their rules".
I'd rather collect thousands of dollars while I figure out how to crack the google hiring firewall then worry about the rent.
All you have to do is not push an agenda to improve things your way. Sounds easy..
Looking at this another way if that person wanted to get fired for no cause this might be a good way.
All you have to do is not push an agenda to improve things your way. Sounds easy..
Looking at this another way if that person wanted to get fired for no cause this might be a good way.
The true definition of less talking more doing. I salute you!
I LOVE jhipster for rapid prototyping, their tool is the best in class.
You indexed hundreds of millions of records in under an hour? Doubt.
I have obviously not indexed the records. I just made an application that would index new and modified records and indexing existing ones would have to be performed separately.
Also you need to realize it wouldn't be very wise to run your just written code directly on prod.
Also you need to realize it wouldn't be very wise to run your just written code directly on prod.
I could believe it — I’m pretty sure I’ve done it before using Postgres. Benchmarks appear to confirm this possibility —- 100 million towns indexed in about 35 mins using the standard b tree index, and 20 mins for BRIN on a laptop in 2019: https://blog.crunchydata.com/blog/postgresql-brin-indexes-bi...
Elasticsearch is famous for slow indexing. This is basically because it is trading off slow indexing for fast search later.
And data to be indexed was incredibly complex and rich. So every detail of every car you own, family member information, addresses, phone numbers, emails, identification documents, details of your contracts, and so on.
And data to be indexed was incredibly complex and rich. So every detail of every car you own, family member information, addresses, phone numbers, emails, identification documents, details of your contracts, and so on.
Neat! I’ve never used Elastic but might have a use for it un the near future. Do you recommend any resources?
If you insert in batches, elastic is quite fast. Also it shards and scales horizontally really well without the client having to know that.
My cluster of 6 instances could index ~20k large, complex docs per second while still serving production query traffic.
My cluster of 6 instances could index ~20k large, complex docs per second while still serving production query traffic.
I like this story.
They could have also just built the PoC app and presented it after the fact.
In my experience, managers aren't usually malicious, they're just risk-averse. They've seen good pitches turn into failed projects. A working PoC counts for a whole lot more than just a plan.
In my experience, managers aren't usually malicious, they're just risk-averse. They've seen good pitches turn into failed projects. A working PoC counts for a whole lot more than just a plan.
Hierarchies dont like to be turned upside down on the scale of competence. Managers hate when their managing cant be attributed to a success. The lesson here is if you do something out of band, if you want it to work, find a way to fake the participation of the powers at be.
This sucks, but it is the only option when you only improve one facet of something. If on the otherhand you could do the whole business then it is time for you to found.
This sucks, but it is the only option when you only improve one facet of something. If on the otherhand you could do the whole business then it is time for you to found.
You shouldn't. It's a terrible story in burning bridges, losing trust with leadership, and basically optimizing for being RIGHT over actually fixing any problems or enacting change.
If you find yourself considering doing anything of the sort, you should just quit. And you might say what's the difference - he ended up quitting anyway. Yeah, but he also did so by ruining his reputation with a bunch of people who you might say you don't care about their opinion, but they'll talk to other people whose opinion you DO Care about, and they won't tell a charitable version of this incident. They'll just say that you weren't a team player, that you don't know how to collaborate with others, and to not hire you.
What he should have done is spent a week writing a document to senior leadership preparing an executive overview explaining the process he would follow, tools to use, and a detailed breakdown of the estimate of building this system (by someone else mind you) - in a timeframe that he understood the leadership would accept as reasonable - but longer than 1 hour.
Then he should have presented the document to them.
If you find yourself considering doing anything of the sort, you should just quit. And you might say what's the difference - he ended up quitting anyway. Yeah, but he also did so by ruining his reputation with a bunch of people who you might say you don't care about their opinion, but they'll talk to other people whose opinion you DO Care about, and they won't tell a charitable version of this incident. They'll just say that you weren't a team player, that you don't know how to collaborate with others, and to not hire you.
What he should have done is spent a week writing a document to senior leadership preparing an executive overview explaining the process he would follow, tools to use, and a detailed breakdown of the estimate of building this system (by someone else mind you) - in a timeframe that he understood the leadership would accept as reasonable - but longer than 1 hour.
Then he should have presented the document to them.
> What he should have done is spent a week writing a document to senior leadership
Except this rarely works.
For starters, senior leadership also plays games only on higher level.
Second, they don't like wild cards they can't control. And even more, they don't like people who skip chain of command because they want to control the information that passes up from their organization.
And this particular company is extra political.
In my team, there were only people who worked there for more than 10 years or less than a year.
There is special type of person that feels well working there -- one that is fine doing nothing and playing cutthroat politics game. Everybody else quits right away.
It was my mistake for not learning this before I joined. I have now a protocol to look for that kind of thing.
Except this rarely works.
For starters, senior leadership also plays games only on higher level.
Second, they don't like wild cards they can't control. And even more, they don't like people who skip chain of command because they want to control the information that passes up from their organization.
And this particular company is extra political.
In my team, there were only people who worked there for more than 10 years or less than a year.
There is special type of person that feels well working there -- one that is fine doing nothing and playing cutthroat politics game. Everybody else quits right away.
It was my mistake for not learning this before I joined. I have now a protocol to look for that kind of thing.
What's the protocol?
Either it works or it doesn't. But the role of architect is working with leadership on their level, not being a super hyped-up developer. But cool story nonetheless.
I mean… OP said his stunt didn’t sit well with people and he had to leave soon after. So if you’re looking for an effective strategy, this ain’t it either.
Nope, gotta disagree.
Sure, the ppl you embarrass might talk. But they won't say much, and likely won't have a lot of credibility.
At least this shows a grounding in reality, has the only chance of success (a white paper /proposal was already shown to go nowhere), and supports the (likely few) other people who care about reality & getting things done - ir at least shows them the consequences so they can adjust their own path.
If you are good, in this economy, you'll be in demand. So don't play the coward's game - be bold, speak (& show) truth to power.
Sure, the ppl you embarrass might talk. But they won't say much, and likely won't have a lot of credibility.
At least this shows a grounding in reality, has the only chance of success (a white paper /proposal was already shown to go nowhere), and supports the (likely few) other people who care about reality & getting things done - ir at least shows them the consequences so they can adjust their own path.
If you are good, in this economy, you'll be in demand. So don't play the coward's game - be bold, speak (& show) truth to power.
On the contrary, it's a great story where the trickster creates wonderful things but is punished. Prometheus. Maui. Coyote. Rabbit. lmilcin.
Eh — that leadership is in title and name only.
Anyone who does this is not a dumbshit, those who get in their way probably are.
OP: would love to make your acquaintance, email is checked in profile.
Anyone who does this is not a dumbshit, those who get in their way probably are.
OP: would love to make your acquaintance, email is checked in profile.
Let people do as they please, not everybody has to live with that “team player” mentality you describe.
I’ll never understand this mentality.
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
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
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...
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...
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.
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.
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
Today, it's still how a lot of hip-hop and electronica gets made: https://en.wikipedia.org/wiki/FL_Studio#Notable_users
>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.
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.
The funny thing reading this post is that you can replace "music" with "software" and your point still holds.
Nowadays it's very easy to create OK software - with modern frameworks, tooling and templates we've enabled an army of "high performing beginners". For web software we can even deploy it with two clicks thanks to modern cloud providers.
However making something that is good or great, as ever, requires a huge amount of knowledge and experience. The kind you only get with years of practise and learning.
Nowadays it's very easy to create OK software - with modern frameworks, tooling and templates we've enabled an army of "high performing beginners". For web software we can even deploy it with two clicks thanks to modern cloud providers.
However making something that is good or great, as ever, requires a huge amount of knowledge and experience. The kind you only get with years of practise and learning.
[deleted]
I'm an amateur electronic musician myself. You're not wrong, but I've found the gap between okay and good extremely hard to cross.
I think the idea that getting good at making, say, trance with, say, FL Studio is somehow easier than learning to play, say, a guitar and making good, say, metal to be ridiculous.
You can get pretty far in FL Studio with a four-to-the-floor kick-hihat-clap beat and some synths, just like you can get pretty far with four power chords on a cheap Stratocaster. It won't be good though, not really.
I think the idea that getting good at making, say, trance with, say, FL Studio is somehow easier than learning to play, say, a guitar and making good, say, metal to be ridiculous.
You can get pretty far in FL Studio with a four-to-the-floor kick-hihat-clap beat and some synths, just like you can get pretty far with four power chords on a cheap Stratocaster. It won't be good though, not really.
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.
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.
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.
These artists didn't get good overnight either. Samplers and drum machines are very much instruments that take time to learn how to use 'properly'
You could say the same for the piano. For most musical instruments, the first months or years of study are spent just trying to get a good sound out of the thing and to be able to play all of the pitches in its range. Then keyboard instruments came along and suddenly anybody could produce a sound with zero effort at all, just by pressing a key.
However it still takes a long amount of time and a lot of practice to fully mesh your brain with the piano so that you can use it as if it was an appendage of your body. DAWs are no different, in fact a DAW is considerably harder to start using than a piano.
However it still takes a long amount of time and a lot of practice to fully mesh your brain with the piano so that you can use it as if it was an appendage of your body. DAWs are no different, in fact a DAW is considerably harder to start using than a piano.
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!
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!
> 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!
It's also really really huge. Where I work, we mostly use ASP.NET with a few JavaScript libraries. A team made a new thing in React. The node_modules weight 276 Mb for a 2 Mb app. npm audit says that there are 11 vulnerabilities, but the package.json was updated 2 weeks ago (and this is with npm install, not npm ci). There are in total 1000 libraries. 165 of them are looking for funding, which means they could easily be the target of a malicious agent (take the repo, publish something new on npm obfuscated, extract credentials). I see the value of modern development tools, but this is just insanity, and going way too fast.
I used to be a huge fan of lots of small libraries updating often, but now that I'm in an enterprise context, it's hard to say the same. I wonder how people deal with this.
It's also really really huge. Where I work, we mostly use ASP.NET with a few JavaScript libraries. A team made a new thing in React. The node_modules weight 276 Mb for a 2 Mb app. npm audit says that there are 11 vulnerabilities, but the package.json was updated 2 weeks ago (and this is with npm install, not npm ci). There are in total 1000 libraries. 165 of them are looking for funding, which means they could easily be the target of a malicious agent (take the repo, publish something new on npm obfuscated, extract credentials). I see the value of modern development tools, but this is just insanity, and going way too fast.
I used to be a huge fan of lots of small libraries updating often, but now that I'm in an enterprise context, it's hard to say the same. I wonder how people deal with this.
Yes that's the rational assessment.
The joke gets worse!
Wait till you have to support this system over the upgrade paths for those 1000 dependencies of varying pedigree and funding, and React has changed their one true way often which effects those libraries many of which jut deprecate and you have to find alternatives.
The joke gets worse!
Wait till you have to support this system over the upgrade paths for those 1000 dependencies of varying pedigree and funding, and React has changed their one true way often which effects those libraries many of which jut deprecate and you have to find alternatives.
> React has changed their one true way
Is there even such a thing? I know that there was class components and then function components and then hooks, but outside of that, the insistance on React being a library means that the ecosystem is very fragmented. There's CRA, there's Next, there's Gatsby. There are lots of different ways to do CSS. TypeScript? No TypeScript?
I wish there was a frontend framework focused on stability over time.
Is there even such a thing? I know that there was class components and then function components and then hooks, but outside of that, the insistance on React being a library means that the ecosystem is very fragmented. There's CRA, there's Next, there's Gatsby. There are lots of different ways to do CSS. TypeScript? No TypeScript?
I wish there was a frontend framework focused on stability over time.
[deleted]
> I wonder how people deal with this.
they don't, and just stick their head in the sand. I know i do!
they don't, and just stick their head in the sand. I know i do!
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.
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.
> 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.
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.
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.
For most single page apps, create-react-app occupies an abstraction level "sweet spot". Webpack is too low level and changes too quickly.
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..
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.
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.
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.
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.
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.
I couldn't get my head around that coming back into frontend dev after a break from it — was on a project where we had some bug in the build output that seems like it'd be trivial to fix in a plain Grunt/Gulp set-up but was told "oh we can't fix that, because it's coming from within create-react-app & I don't know if we're ready to eject yet. Once you do, you can't go back"
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).
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).
> 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
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
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.
> 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.
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.
> That's actually not quite it.
That might not be the UNIX environment's true strength, but it's the only one that any of its advocates discuss. I've seen hundreds of people defend the paradigm, and you're the first one who's mentioned "packaging for both use and reuse" - everyone else talks about "text as the universal interface" and "simple, composable commands".
Moreover, I don't think that this feature is unique to UNIX. In particular, Emacs Lisp functions can both be called from other elisp code and directly (and ergonomically) executed by the user (with plenty of features to enrich interactive execution) - and these functions can actually pass typed data between them, unlike shell commands.
This appears to be the same "packaging for use and reuse" that you mention - unless I'm misunderstanding what you're saying, which is very possible because I'm reading through the (exceptionally interesting) PDF that you kindly linked, and I don't understand what it's getting at (although it seems profound).
That might not be the UNIX environment's true strength, but it's the only one that any of its advocates discuss. I've seen hundreds of people defend the paradigm, and you're the first one who's mentioned "packaging for both use and reuse" - everyone else talks about "text as the universal interface" and "simple, composable commands".
Moreover, I don't think that this feature is unique to UNIX. In particular, Emacs Lisp functions can both be called from other elisp code and directly (and ergonomically) executed by the user (with plenty of features to enrich interactive execution) - and these functions can actually pass typed data between them, unlike shell commands.
This appears to be the same "packaging for use and reuse" that you mention - unless I'm misunderstanding what you're saying, which is very possible because I'm reading through the (exceptionally interesting) PDF that you kindly linked, and I don't understand what it's getting at (although it seems profound).
"text as the universal interface" is the thing that enables "packaging for both use and reuse", so it's not surprising that this is what they refer to.
> Moreover, I don't think that this feature is unique to UNIX.
It's not. It's not common though, and certainly Emacs Lisp code doesn't work at the OS level, it is trapped inside Emacs.
> Moreover, I don't think that this feature is unique to UNIX.
It's not. It's not common though, and certainly Emacs Lisp code doesn't work at the OS level, it is trapped inside Emacs.
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:
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.
ls | grep
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.
> 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
I mean this kindly, as a person who struggles to infer implied details in a lot of circumstances: I think the quoted code was intended as shorthand, e.g.
I mean this kindly, as a person who struggles to infer implied details in a lot of circumstances: I think the quoted code was intended as shorthand, e.g.
ls ... | grep ...That's exactly it. I've been running Linux as my desktop operating system for over a decade and know how to use grep - I just opted for shorthand (or may have underclocked some brain cells - I was in a hurry).
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.
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.
Yes, you are very correct. The "build X in minutes" definitely assumes strong background because you know what to 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.
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.
I do blogspot blogs and the interface is brilliant in terms of letting anyone of any skill level interact with it. They have precoded templates you can just click on. They have the option to "customize" where you can click on different colors or whatever without knowing any coding.
You can also use your own hex codes to change colors to exactly what you want. You can add custom CSS snippets safely without digging around in the code.
If you are a serious coder, you can access the code and edit. I do everything but that last because I know some HTML and CSS (and UX etc) but I don't have the programming experience to figure out how to go into the guts of the code.
I spent hours and hours learning my way around the blogspot interface. Yes, anyone can just click a template and swap out background photos or whatever but if you don't already have prior experience with their backend and some basic design knowledge and UX knowledge, good luck making it do what you want while looking good and yadda.
I spent some time thinking I could sell my skills as a blogspot expert but there doesn't seem to be a market for it. People with money and ambition and so forth don't use blogspot. People who use it don't pay for help with it. They do it themselves.
So I have some idea of how much background knowledge someone needs to have to "do X in minutes" though I'm not a serious coder. I'm the computer geek in some circles I hang in though I would never identify that way on HN, just like I don't generally try to tell HN that I'm some mathy person.
I am often the "mathy" person in other settings. Just not here.
Anyway, thanks to anyone who suggested some entry level options for me.
You can also use your own hex codes to change colors to exactly what you want. You can add custom CSS snippets safely without digging around in the code.
If you are a serious coder, you can access the code and edit. I do everything but that last because I know some HTML and CSS (and UX etc) but I don't have the programming experience to figure out how to go into the guts of the code.
I spent hours and hours learning my way around the blogspot interface. Yes, anyone can just click a template and swap out background photos or whatever but if you don't already have prior experience with their backend and some basic design knowledge and UX knowledge, good luck making it do what you want while looking good and yadda.
I spent some time thinking I could sell my skills as a blogspot expert but there doesn't seem to be a market for it. People with money and ambition and so forth don't use blogspot. People who use it don't pay for help with it. They do it themselves.
So I have some idea of how much background knowledge someone needs to have to "do X in minutes" though I'm not a serious coder. I'm the computer geek in some circles I hang in though I would never identify that way on HN, just like I don't generally try to tell HN that I'm some mathy person.
I am often the "mathy" person in other settings. Just not here.
Anyway, thanks to anyone who suggested some entry level options for me.
Aren't various boilerplates created for this which already route all the necessary libraries and tools like analytics, stripe etc?
Sure, there are. They do almost nothing about having to modify the generated code afterwards though. They are just a start; you don't have a command like "modify this validation to be this or that".
I am helping a few people getting started with web dev, and I have had good success using Svelte. It's not necessarily the best choice if you're trying to start a resume to get hired, but if you're trying to get comfortable with the foundations of all of the possibilities (javascript, html, css) it's a lot less intimidating. I think it will be a big player in the future, and you can make just about anything you want with it.
https://svelte.dev/tutorial/basics
In my case, I always have to do video tutorials to get started with a new stack. I use Academind ($20 a month) since their courses are comprehensive and still manage to split topics into shorter videos. When I get confused, I can usually find a good refresher on what I'm having trouble with. They have a course on Svelte specifically and 101 guides to all the technologies involved.
https://svelte.dev/tutorial/basics
In my case, I always have to do video tutorials to get started with a new stack. I use Academind ($20 a month) since their courses are comprehensive and still manage to split topics into shorter videos. When I get confused, I can usually find a good refresher on what I'm having trouble with. They have a course on Svelte specifically and 101 guides to all the technologies involved.
I wish Hickey wasn’t in the programming business and was just a full time philosopher. In a lot of ways his observations on social phenomena, his approach to abstract concepts, and his communication style in general is more interesting than clojure and datatomic (though these technologies are still great).
Obsession indeed. Everyone wants to be a master in five minutes. There’s this funny sort of paradox that arose out of the advent of digital technology where, because everything is nearly instantaneous, more people theoretically have more leisure time to plug 10+ years into mastering some hobby, but simultaneously, the instantaneousness and constant rush of digital distractions has lowered the tolerance for temporal investment (i.e. patience) in general, nullifying what would otherwise be a gain in leisure and expertise (e.g. masterclass, whose entire business model is predicated on the ridiculous premise that to be as successful as the stars only requires taking one course of their best tips and tricks and not, idk, thousands of hours of dedicated effort)
In my personal experience, I’ve found that most of the shortcuts aren’t actual shortcuts. Everything I know in the realm of computing I’ve taught myself, and, I have to say, I didn’t really progress until about 8 years in I finally buckled down and decided to read actual comp sci papers and really dwell on them and understand them, and by god use a pen and paper when necessary, rather than spend my time coding yet another example todo app from a tutorial on a website somewhere.
The fact that many resources around computing are free is both a blessing and a curse. It’s great because it allows people to learn on their own but bad since the crap always bubbles to the top.
Obsession indeed. Everyone wants to be a master in five minutes. There’s this funny sort of paradox that arose out of the advent of digital technology where, because everything is nearly instantaneous, more people theoretically have more leisure time to plug 10+ years into mastering some hobby, but simultaneously, the instantaneousness and constant rush of digital distractions has lowered the tolerance for temporal investment (i.e. patience) in general, nullifying what would otherwise be a gain in leisure and expertise (e.g. masterclass, whose entire business model is predicated on the ridiculous premise that to be as successful as the stars only requires taking one course of their best tips and tricks and not, idk, thousands of hours of dedicated effort)
In my personal experience, I’ve found that most of the shortcuts aren’t actual shortcuts. Everything I know in the realm of computing I’ve taught myself, and, I have to say, I didn’t really progress until about 8 years in I finally buckled down and decided to read actual comp sci papers and really dwell on them and understand them, and by god use a pen and paper when necessary, rather than spend my time coding yet another example todo app from a tutorial on a website somewhere.
The fact that many resources around computing are free is both a blessing and a curse. It’s great because it allows people to learn on their own but bad since the crap always bubbles to the top.
Which papers or educational resources do you recommend?
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.
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.
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.
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).
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]
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).
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.
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.
Also, do you know the song(s) already, and do you know how to play the particular instrument requested?
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.
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.
Yes. Almost every single app framework has a shiny hello-world-todo-app pitcher that takes 5 minutes to write.
Still, every time, two weeks later when writing your real app, you'll inevitably hit that nasty reactive-router-fluxcapacitor-synchronization dead end inherent limitation (or bug) in the framework, which is world famous and has had an open issue on github for 2 years, where the only workaround is to do things in a much worse way instead, inflicting more pain than the benefit given by the framework.
What I'm trying to say is that when choosing a framework, i don't want to see a hello world as example. I want to know how well it will scale for future development.
Still, every time, two weeks later when writing your real app, you'll inevitably hit that nasty reactive-router-fluxcapacitor-synchronization dead end inherent limitation (or bug) in the framework, which is world famous and has had an open issue on github for 2 years, where the only workaround is to do things in a much worse way instead, inflicting more pain than the benefit given by the framework.
What I'm trying to say is that when choosing a framework, i don't want to see a hello world as example. I want to know how well it will scale for future development.
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.
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.
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.
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.
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.
The vast, vast majority of playing an instrument well is about deep technical skill, not creativity. That's what we're discussing here.
In my experience, 99% of every app is CRUD. Then there's the 1% that is your differentiation that takes six months to build.
To the instrument analogy it's like Beethoven's 5th. Almost anyone can play the beginning on the piano with a few minutes of fooling around (dun dun dun da....). But to actually play the entire thing well will take years of practice because it's the other parts that are hard to get right and must be correct to work.
To the instrument analogy it's like Beethoven's 5th. Almost anyone can play the beginning on the piano with a few minutes of fooling around (dun dun dun da....). But to actually play the entire thing well will take years of practice because it's the other parts that are hard to get right and must be correct to work.
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.
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.
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.
That's some food for thought. My issue with programming courses is they ask you to memorize the commands then use them; most programming is about creating the logic then QA'ing with some data. Excel is data-first and becomes more like a game, trying different approaches with a clear picture of the end in mind. It's easier to persevere.
Quite true, and too often developers are not aware of how important data-first is for their own work in the exploratory part of programming.
Programmers have powerful interactive shells and debug environments, yet most courses center the teaching and communication of how a program works around the concepts in the finished product (a working program), more than how you arrive piecewise to the full solution by iterating small parts of the concepts in the domain problem and finding the correct parts of code to handle them.
Programmers have powerful interactive shells and debug environments, yet most courses center the teaching and communication of how a program works around the concepts in the finished product (a working program), more than how you arrive piecewise to the full solution by iterating small parts of the concepts in the domain problem and finding the correct parts of code to handle them.
We kind of do with ASP.NET Blazor. It still isn't as simple as the VB back in the 90s through.
Check out https://anvil.works. Feels like VB6 for the web, but all in Python.
I come back to this article every now and then http://www.loper-os.org/?p=861
> 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>
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>
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.
I'd love to see better tooling that automates the crap and lets us focus on the actual business logic and value add.
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.
> 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.
Relevant article: https://www.oreilly.com/radar/thinking-about-glue/
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.
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.
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.
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.
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>
</another rant>
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/...
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/...
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.
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.
> ...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>
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>
[deleted]
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).
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).
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.
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.
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.)
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.)
Ditto for both power- and hand-tools used for most craft.
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)
> "dumb as shit C level people"
It is preferred, stylistically, to avoid redundancy in your writing style these days.
It is preferred, stylistically, to avoid redundancy in your writing style these days.
Good catch
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
C++ :: Saxaphone Wix :: Recorder; or something
> 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.
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.
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]
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!
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.
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.
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.
Honestly if you frame it that way, the framework is very well done. OP, if you can read this, this is the way to market your product.
From the developer perspective, I would not call this production ready also
From the developer perspective, I would not call this production ready also
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.
Definitely not looking forward to 99% of any group being out of jobs.
[deleted]
Yeah, not happening. Someone still needs to write the CSS.
I think the day where Figma emits styled React components is closer than you think, but the jobs are safe for now.
And what about when you need to glue an external library into a page, or pivot a feature.
I've seen design generating frontend as a promised holy grail, and it's still not there. The further away your design is from the person who actually builds the product, the longer and slower the turn around time is for the inevitable pivot or adjustment.
It's all 'perfect world' scenarios.
Creating a CMS? Sure. Web app that connects to x,y,z services and crunches a,b,c datasets? Not a chance.
Try Plasmic.
I'm familiar with backend stacks but can't write a lick of CSS. This tool helped me build some small webapps.
I am in no way associated with them. Just a happy user.
I'm familiar with backend stacks but can't write a lick of CSS. This tool helped me build some small webapps.
I am in no way associated with them. Just a happy user.
Sharepoint will put my team out of business any day now /s
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?
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?
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.
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.
> 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.
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.
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.
> 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.
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.
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)
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.
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.
> 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.
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.
Your negativity is detrimental to this thread. Please check your tone, this is not the quality people writing on HN should strive for.
What are you talking about? His tone is fine as is the critical points he is making. He's right.
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.
Tone policing is also how truth and justice are buried in the name of fitting in.
Hyperbole. This is a thread about a web framework, not truth and justice. The negative tone used is totally inappropriate to a conversation about web frameworks. On HN, people generally try to be civil to people they disagree with, and this should especially be true when they are disagreeing about things that ultimately don't matter.
[deleted]
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:
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/
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
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/
+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.
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
[0] https://wasp-lang.dev
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.
[deleted]
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?
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?
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?
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 :)
But the title is not wrong, a month consists of weeks, days and minutes :)
It's not wrong, but it's clickbait.
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.
Obviously the business logic differs for every different business, and i expect that would be harder to do.
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
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
> 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:
1: https://github.com/cabalamat/frambozenapp
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)
1: https://github.com/cabalamat/frambozenapp
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...?
> 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.
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.
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?
How do you handle users and permissions?
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/frambozenapp/blob/master/app/lo...
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/frambozenapp/blob/master/app/lo...
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.
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.
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.
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.
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
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
I used a cookie cutter project with react-admin and fastapi but I was kind of bummed with how much packages were pulled in and how slow builds were. I figure I need to go in there and figure out all the stuff I don’t need, but after that I realized it would be hard to get buy-in with the others on my team.
Still, I believe something like this is a good future for internal apps.
Still, I believe something like this is a good future for internal apps.
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.
React Admin works really well with Hasura:
https://github.com/hasura/ra-data-hasura
https://github.com/hasura/ra-data-hasura
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.
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.
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.
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
Check out https://github.com/lowdefy/lowdefy
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/
[1] https://notion.so/
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.
[deleted]
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)
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)
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.
A TODO list is one thing, but this isn't going to replace Mattermost or Jira tomorrow.
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.
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.
Totally agree with this!
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.
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.
Could you elaborate on the cookiecutter template?
Is it just me, or is this ASP.NET ViewState from 15 years ago?
No you’re right. This guy is blowing gas
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
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
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?
Is it well supported,
who provides it,
are there similar templates that don’t work as well and why?
https://jumpstartrails.com/
There are a few other Rails template frameworks but I think this is the most popular. It basically has a lot of the boilerplate stuff that you need to do for setting up a SaaS product. Of course because it’s rails a lot of the stuff is supplied in gems
There are a few other Rails template frameworks but I think this is the most popular. It basically has a lot of the boilerplate stuff that you need to do for setting up a SaaS product. Of course because it’s rails a lot of the stuff is supplied in gems
Over $700/year if you want to develop more than one website seems a bit too much to me.
Works out pretty well if you think of it in dev time spent imo
There’s something in the number of comments here along the lines of either:
a) I’ve been working o a similar thing…
b) Look at this other more mature project that solves the same problem…
There’s nothing wrong with a modern take on an old problem, but a naive take on an old problem that doesn’t either learn from issues with past attempts or offer anything novel…
This is a hard problem; How do you scale with easy quick prototyping and robustness for production quality.
Projects like unreal that solve this well are few and far between, and usually marked for “version 5” or “version 7”, where they’ve gotten past the early stumbling blocks of bad decisions and leaning too heavily towards no-code and complexity.
This is a cute side project; maybe it has something novel to offer (I don’t see it, but perhaps), but it’s very naive, and it’s … a fair way off from something anyone else probably has a use for.
a) I’ve been working o a similar thing…
b) Look at this other more mature project that solves the same problem…
There’s nothing wrong with a modern take on an old problem, but a naive take on an old problem that doesn’t either learn from issues with past attempts or offer anything novel…
This is a hard problem; How do you scale with easy quick prototyping and robustness for production quality.
Projects like unreal that solve this well are few and far between, and usually marked for “version 5” or “version 7”, where they’ve gotten past the early stumbling blocks of bad decisions and leaning too heavily towards no-code and complexity.
This is a cute side project; maybe it has something novel to offer (I don’t see it, but perhaps), but it’s very naive, and it’s … a fair way off from something anyone else probably has a use for.
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?
EDIT: I can also mention Arc, PG's custom Lisp dialect for building web applications including this very site.
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?
EDIT: I can also mention Arc, PG's custom Lisp dialect for building web applications including this very site.
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.
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?
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?
What are your top frameworks that satisfy all of these (assuming developer productivity is a factor)?
This is an excellent framework to validate a low-code/ full-stack frameworks as ERPs are complex beasts. I would like to also add( especially for opensource low-code frameworks ):
#6 Can it generate pdf and excel reports
#7 Does it support scheduled jobs/tasks
#8 Can you choose to execute logic in the backend ( this does not seem to be the case for retool etc which only support frontend js )
#9 Can I extend with my own js, css and backend libraries
#10 Is it horizontally scalable and stateless
#11 Drag and drop ui builder that is not hard-coded to a single css framework and that generates code that can be modified.
I have not yet found any low-code framework that fits into these benchmarks
#6 Can it generate pdf and excel reports
#7 Does it support scheduled jobs/tasks
#8 Can you choose to execute logic in the backend ( this does not seem to be the case for retool etc which only support frontend js )
#9 Can I extend with my own js, css and backend libraries
#10 Is it horizontally scalable and stateless
#11 Drag and drop ui builder that is not hard-coded to a single css framework and that generates code that can be modified.
I have not yet found any low-code framework that fits into these benchmarks
Check Dronahq.com it does most of the things you highlighted
1) frontend app building (responsive) 2) backend logic builder with automation and BPM 3) pdf gen 4) add your own js, build your own controls
Disclaimer - I work at DronHQ
1) frontend app building (responsive) 2) backend logic builder with automation and BPM 3) pdf gen 4) add your own js, build your own controls
Disclaimer - I work at DronHQ
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
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
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.
But programming is about edge cases and thus, many, many rules how things should behave in every imaginable scenario.
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
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
Ruby-on-Rails with some magical gems(devise, simpleform etc.) can do this even faster and probably better looking.
This is a valid use case and it's the reason tools like Blitz [0] exist in the first place.
Plumbing UI, Forms, API and db is pretty much the same for a lot of MVPs and anything that can get you to a faster prototype is welcome. The difference between what the author shows and Blitz is that the latter is similar to Rails in the sense that it scales to a proper 'Production App' rather than a quick prototype.
[0] https://blitzjs.com/
Plumbing UI, Forms, API and db is pretty much the same for a lot of MVPs and anything that can get you to a faster prototype is welcome. The difference between what the author shows and Blitz is that the latter is similar to Rails in the sense that it scales to a proper 'Production App' rather than a quick prototype.
[0] https://blitzjs.com/
>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.
This is a classic web log. What blogs really should be about.
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.
And it's a _beautiful_ site. Really. It might just be a netlify theme or whatever, but I'm really enjoying reading it.
I wonder how it deals with any migrations? What if I decide to connect different components later? Or add a new attribute / column?
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.
I have implemented a much more flexible URAD tool, completed a large scale project with it and then used it in other projects.
The huge amount of possibilities in software development will usually beat the tool and eventually what helped you get a fast start, ends up dragging you behind.
1-The way we store data can be completely different from the way we present it to user
2-In only a tiny fraction of apps each user can only see their own data
3-When load (data volume/request per second, etc) increases, we often need fine control over the entire product
4-Change management can be tricky, especially when if changes shape of data store
For all these reasons, I don't expect these extreme rapid tools to gain huge success. More modest claims, like retool's (A great internal data administration tool) are more realistic.
Eventually, I think that extremely flexible and extremely rapid tools will emerge, but my expectation is that they need great vision, great execution, and when trade-offs need to be made, it's better to err on the side of flexibility rather than super fast demos.
The huge amount of possibilities in software development will usually beat the tool and eventually what helped you get a fast start, ends up dragging you behind.
1-The way we store data can be completely different from the way we present it to user
2-In only a tiny fraction of apps each user can only see their own data
3-When load (data volume/request per second, etc) increases, we often need fine control over the entire product
4-Change management can be tricky, especially when if changes shape of data store
For all these reasons, I don't expect these extreme rapid tools to gain huge success. More modest claims, like retool's (A great internal data administration tool) are more realistic.
Eventually, I think that extremely flexible and extremely rapid tools will emerge, but my expectation is that they need great vision, great execution, and when trade-offs need to be made, it's better to err on the side of flexibility rather than super fast demos.
This looks like an amazing tool for prototyping or a hackathon, but I struggle to see how I might use it to deploy to "production" as is mentioned in the post. What stuck out to me was that any time we made a somewhat-large change to the UI, all of our previously "saved" data just disappeared. It feels like alot of the magic of the syncing to the db is relying on the ID's derived from specifics of the UI fields. I've found that even with full control of the framework, data migrations like these can be tricky -- I would be interested in seeing some more detail on this in the demo. Otherwise the set of things I could see myself using this for is very limited and certainly does not reach "production-ready", unless I intend never to touch the code again.
[deleted]
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.
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.
GPT3, is that you?
Sorry, I am just a developer.
I'm not sure if I am supposed to be insulted by that comment or not.
I'm not sure if I am supposed to be insulted by that comment or not.
I wonder if this is something GPT-3 would say. Am I GPT-3?
This entire exchange made me think of Blade Runner. Maybe I am not even human after all. How would I know...
Sorry, it wasn't my intention to insult you!
Just one more question: Suppose you're in the desert and you see a tortoise turned on its back. What do you do?
Definitely not GPT3
Great. Now we can all build a shopping list or to-do list application in minutes.
[deleted]
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
(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
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.
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.
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.
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.
> 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.
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.
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.
> 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.
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.
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?
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?
> 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.
Apparently, you just construct your app.
I meant how the implementation works behind the scenes.
Like what’s the persistence layer? How are changes subscribed to and persisted? ACID transactions? ect.
Looks like we’ll have to wait and see what the author publishes later.
Like what’s the persistence layer? How are changes subscribed to and persisted? ACID transactions? ect.
Looks like we’ll have to wait and see what the author publishes later.
An idea very similar to what we have developed some years ago. A much older version of it is still publicly available however not maintained (moved to private repo, more on this in a second):
https://github.com/intelix/reactiveservices
some runnable examples are here: https://github.com/intelix/reactiveservices-examples
And the screenshot is the early version of the real app built on it
Conceptually it's the same to what described in conductor, however you are in full control how the data is synced, how and to what you subscribe etc.
It was built, first of all, for the application in forex trading, so there are some "specific" features, such as optimised binary stream with delta-only updates, priority on the data streams, demand-based backpressure, subscription based on the visibility of the data, very low latency, cross-dc clusters and many more.
How it works is described (in rather over-simplified way) on the github page. There's a choice of scala or java on the back end, and react on the client side. Websocket only. Like I mentioned, the currently exposed source code is not maintained and based on the very old version of react (there are still mixins in the example) and libs, and has some vulnerabilities.
The latest version of the framework is maintained in the private repo, and we have built a number of solutions on it over the years, and not only in the forex space. It is well suited for most Single-page apps.
Latest version uses latest react features, hooks based, and the server side has seen significant changes as well.
Why we decided to keep it private? We thought world already have enough web frameworks, and since, we thought, our framework and approach was such a niche, we just kept using it for our clients and our own projects. But since then we have been surprised how easily it could be applied to other fields, and yet there's still nothing like this is available. GraphQL with subscriptions probably is the closes, but not good enough.
Is there any interest in something like this in the community? If so, we can definitely make large parts of the framework, which is now 6yo, public.
And the screenshot is the early version of the real app built on it
Conceptually it's the same to what described in conductor, however you are in full control how the data is synced, how and to what you subscribe etc.
It was built, first of all, for the application in forex trading, so there are some "specific" features, such as optimised binary stream with delta-only updates, priority on the data streams, demand-based backpressure, subscription based on the visibility of the data, very low latency, cross-dc clusters and many more.
How it works is described (in rather over-simplified way) on the github page. There's a choice of scala or java on the back end, and react on the client side. Websocket only. Like I mentioned, the currently exposed source code is not maintained and based on the very old version of react (there are still mixins in the example) and libs, and has some vulnerabilities.
The latest version of the framework is maintained in the private repo, and we have built a number of solutions on it over the years, and not only in the forex space. It is well suited for most Single-page apps.
Latest version uses latest react features, hooks based, and the server side has seen significant changes as well.
Why we decided to keep it private? We thought world already have enough web frameworks, and since, we thought, our framework and approach was such a niche, we just kept using it for our clients and our own projects. But since then we have been surprised how easily it could be applied to other fields, and yet there's still nothing like this is available. GraphQL with subscriptions probably is the closes, but not good enough.
Is there any interest in something like this in the community? If so, we can definitely make large parts of the framework, which is now 6yo, public.
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.
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.
This reminds me a lot of https://lamdera.com/, though more React and less Elm. Lamdera has the added benefit that changes are deployed in real time instead of having to reload, including in production. This means the user doesn't get those annoying popups saying something like "there are new features, refresh your page".
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?
FileMaker flies under the radar and most people haven't even heard of it. It seems like it was neglected over the years as well. They also took some strategic directions that weakened the utility such as lack of interoperability, but it seems like they've improved.
The only reason I even know it exists is because I was brought in to one company to try to untangle a mess of business logic and UIs that had accumulated into an insane mountain of technical debt.
That said, I do appreciate what it is trying to do and the power it gives users. There are a lot of niche products trying to "reinvent" aspects of FileMaker, but no real general replacement exists that I'm aware of.
The only reason I even know it exists is because I was brought in to one company to try to untangle a mess of business logic and UIs that had accumulated into an insane mountain of technical debt.
That said, I do appreciate what it is trying to do and the power it gives users. There are a lot of niche products trying to "reinvent" aspects of FileMaker, but no real general replacement exists that I'm aware of.
I've worked places where the main app driving the business office was written in A5 or FileMaker Pro. One was an ISP that ran ISP management from some ISV and it charged us per maximum active subscriptions. I forget the name.
I made a decent chunk of my living for a time taking custom small business apps in QuickBasic or similar systems and plugging them into a graphical interface. My method was sometimes more complex, but often it was translating to OOBasic and using Open Office forms for the interface. One could get auto-saved updates white a database breaking it, and even trigger an update in the UI if someone changed data in the DB from another connection.
It's not surprising someone else thought of such a system. It's just surprising they don't acknowledge any awareness of existing solutions. Our industry is often blind to its own history which is fairly said since we're the ones who facilitate massive data storage and archival.
I made a decent chunk of my living for a time taking custom small business apps in QuickBasic or similar systems and plugging them into a graphical interface. My method was sometimes more complex, but often it was translating to OOBasic and using Open Office forms for the interface. One could get auto-saved updates white a database breaking it, and even trigger an update in the UI if someone changed data in the DB from another connection.
It's not surprising someone else thought of such a system. It's just surprising they don't acknowledge any awareness of existing solutions. Our industry is often blind to its own history which is fairly said since we're the ones who facilitate massive data storage and archival.
i think we have a different idea of "production ready". but its a cool utility for rapid prototyping, definitely. reminds me of xforms.
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
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.
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
Nothing new. I have used code generators most of my career to automate things. They are a massive productivity booster. But I also learned that each code generator needs to be tailored to the project or class of projects you are working on to be useful.
Generally from my measly experience developing apps, it’s not coding them that takes the time
The thing is that building an app or building a product is not really about “building” it. So the months you spend are not about creating CRUD interfaces, but about planning and all the small things, all the details you need to figure out.
I would like to know more about how this works on the internals, mainly in terms of security. Of course, if the author says to me that is only for prototyping I'll say nothing :)
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.
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.
So, where's the Github link for Conductor Framework?
“Writing books in minutes not months”
Who else is excited to read it?
Who else is excited to read it?
Or just use Django
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.
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.
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.
Browsers should supported a rich set of UI components, optimized so that AI can compose interactions between them.
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
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
Are we going to see a version of Visual Basic being reconstructed with javascript soon?
So... would 128 Gb ram be enough for one of these apps?
I wonder since when started calling basic pages apps.
Anybody else bothered by the 105 uncommitted files?
Building prototypes in minutes, apps in months.
[deleted]
[deleted]
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.