Why Codeless Software Is Doomed to Fail - <AUTHOR> https://architectofworlds.com/blog/why-codeless-software-doomed-fail/ <comment><USER3> The article doesn't get to the reason that it's doomed to fail. Software developers translate between what humans want and what computers can do. The second part — what computers can do — is a well understood domain that can be modeled beautifully, and tasks involving it can be automated trivially. The first part, what humans want, is a profoundly complex anti-inductive domain that every human in history has spent their whole lives trying to understand, failing to but scratch the surface. Tasks involving concepts in the domain of human desires can, too, be automated, but the technology needed to do so would be AI-complete. In other words, if we had a technology that could automate the work of software developers, the same technology, with relatively minor changes, could be applied to automate any human occupation, including those of the people who want to automate software development.

Until then, what we can do is build abstraction on top of abstraction over what computers can do. But that _is_ code. There's a lot of room to make application development easier, to make it require less knowledge. In a lot of cases there's no good reason it isn't easier already. But it can't really become _easy_ until the target stops moving; what computers can do changes too fast for people who want to build a good unified set of abstractions over it.

<comment><USER4> > The first part, what humans want, is a profoundly complex anti-inductive > domain that every human in history has spent their whole lives trying to > understand, failing to but scratch the surface.

Yes, this! It's the inquiry into the way the data flows, what the application should do, and how to handle edge cases that is difficult for a lot of business applications. To say nothing of getting various stakeholders to agree. Code isn't fluid, it's calcified business process. That calcification requires regimented thought that developers can bring to the table (others can too, but I've seen it far more often with developers).

That's not to say that there aren't more and more domains that will be codeless. As another commenter says, if you can stay in a box, a codeless solution like Wix or wordpress.com can solve your problems quite well. But as soon as you step out...

Another issue that is never brought up is lifecycle and change management. This is a complex topic that developers spend a lot of time thinking about. Some codeless solutions version control behind the scenes, but testing and regressions are not really part of what the end user thinks about. Again, this is a question of maintainability and scale. Small companies may not need the overhead. Until they grow and suddenly they do.

<comment><USER5> > Some codeless solutions version control behind the scenes, but testing and > regressions are not really part of what the end user thinks about. Again, > this is a question of maintainability and scale. Small companies may not > need the overhead. Until they grow and suddenly they do.

Please pardon my ignorance, as I've never worked in software development. Could you please explain what you mean by 'overhead', and also how a lack of testing/regressions in low-code programs would be a roadblock as the company or application scales?

As an aside, I love your analogy of code as "calcified business process". I've heard several low-code 'success stories' of business users without CS experience learning how to build apps, and they often comment that one of the most difficult things was learning to think in terms of the rigidity of code. Sometimes I ponder whether the true value of low-code platforms is simply that they teach non-coders how to think about business-level problems in terms of logical systems, rather than fluidly, which is how they experience them.

<comment><USER6> When a program becomes sufficiently complex, it's impossible to make changes to a program without the change affecting other parts of the program. Without tests, whether manual or automated, it's hard to know if a change has caused old bugs to reappear, or introduced new bugs.

What about adding a feature that changes a fundamental assumptions of the program? Eg since the very beginning, the product has only ever supported integration with Salesforce.com, so all of the system was programmed with that assumption in mind. Unfortunately, there's now a need to support other CRMs. As support for OtherCRM is added, how sure can you be that salesforce.com support still works 100% perfectly? And then let's also add support for 30 more CRMs because that's what the customers are using. If support isn't added for those 31 CRMs, then a (high-code) competitor could come along with a better product for cheaper.

Thus, making sure every change going into the program still works with every single one of those CRMs becomes a roadblock. Not insurmountable, but at some point, the roadblock becomes an albatross around the neck of the product, making it impossible to make any changes to the product.

Having tests (hopefully automated) will make sure that the product works with all the CRMs it claims to. But the overhead of writing tests takes a non-zero amount of time/resources, which (eventually) adds up.

<comment><USER5> Thank you, that helped me understand the point much more clearly. It sounds like a cogent example of 'technical debt'; I'm aware of several software products that have tried to expand their capabilities by purchasing others' source code and have eventually run into similar roadblocks.

</comment></comment></comment></comment></comment><comment><USER7> I've seen the exact scenario mentioned in the article play out, "the moment you need to create something in a domain that does not fit existing tools, you are already into the domain where you will eventually need programming done, and in that domain, you need a programming language, not a drawing tool."

I worked somewhere with a team of engineers who worked in LabView. They used LabView mainly for customized test equipment controllers and recorders and it worked well. They then branched into FPGAs for some straightforward dataflow signal processing and that also worked well. They then decided they were sick of how long it took software engineers to write device drivers for custom hardware and decided to do that in LabView with some tool that could generate C code from LabView. I got pulled into a meeting about it. I asked a couple important questions: how do you insert memory barriers and how can you write code that is ISR safe? It was clear the LabView folks had no idea about any of this. So I launched into a discussion about CPU architecture. They didn't really listen and everything was a hand wave, "LabView does that for you". It was clear they didn't want to hear my thoughts, so I let it go.

Fast forward 6 months and I get a frantic call from a manager if I had "bandwidth" to write a device driver in C for the same card where the LabView team was supposed to have written the driver.

<comment><USER8> Similar experience with a Q/A team using LabView. They had a tool they were comfortable with, and had inevitably created a fragile, horrid monster that looked like a plate of spaghetti. Their test framework was probably nice and intuitive for six months before rot set in, and then no one could understand it.

A new project rolled in that didn't meet the expectations of their tooling, and suddenly they had to start writing native code plugins and so forth, and they were totally at sea. They started demanding engineering resources and invasive changes to the product so their test environment could handle the thing with minimal modifications.

I remember telling one particularly obstinate contractor that we were colossally uninterested in writing drivers for their environment, and that he was either going to learn C or lose his contract. I didn't see him again, maybe his management chain told him not to come 'round the software group again, or maybe he learned C and saved the day for his team.

</comment></comment><comment><USER9> I gave up at:

"If this trend holds, and it seems like it does, pretty soon even a regular high school kid should be able to build the next Netflix using nothing more than an easy "click and drag" interface. This is the promise low-code platforms are built on."

I work for a low-code software platform company and at least as far as we're concerned, I cannot scream "NOT EVEN CLOSE" loudly enough.

We're for building _business applications at scale_. Not Netflix, or the next great TODO app startup for teams, or any of that. Not the same ballpark, not even the same sport.

We're for building your companys HR app. Or an app to help Legal. Or an app to help field CSRs do front-line support. Line-of-business apps.

Maybe some of them are promising this "drag and drop your way to netflix" thing. I know we aren't, nor are any of our competitors in the low-code space.

<comment><USER10> Netflix's interface isn't complicated. Surely some codeless platform is capable of something similar.

The technically hard part is the infrastructure to unicast millions of videos at a time, but that's now available from several cloud providers.

The _really_ hard part isn't technical, it's content. Disney might be able to build the next Netflix with a codeless interface to videos on the cloud, but a high school student wouldn't.

<comment><USER11> >but that's now available from several cloud providers.

It isn't available at a price that lets you stay in business.

<comment><USER12> Well, that depends on how much you can charge for your service. You can be super inefficient if your product is unique and has a big enough market, and that's precisely what these models are good for.

Once you've proven the idea, perhaps it's time to hire a team to optimize, but until then, you can focus on the rest of the business.

</comment></comment></comment></comment><comment><USER13> Reminds me of what people used to say about website builders such as dreamweaver, then about the "cloud", and more recently about "serverless".

Wix and squarespace are more than enough for many businesses' needs. AWS has blown through the roof. And more and more people discover what it feels like not to have to worry about hardware and VMs configuration.

ForestAdmin is also a nice case in point, supposing you have the proper stack.

Sure there will always some who need developers, and most "solutions" this far haven't been up to the task. But I definitely wouldn't bet that won't ever be more than enough for most people and use cases.

For this, extensibility (via integrations and proper established languages; definitely not some absurd and ill-conceived _" very friendly script language"_) will be key

<comment><USER14> I don't think the article is about "serverless" - it's more about various BPM, RPA and similar tools and technologies that tend to popup with snake oil type marketing every a couple of years.

Also serverless is arguable more complex for a business person/analyst to grasp than just telling a developer to create something they imagined.

<comment><USER13> Serverless is to sysadmins what codeless is to web developers (front and / or back).

Or serverless is to those same web developers what codeless is to business people.

Edit: also, this is an analogy

<comment><USER14> Yes, analogy is similar, the gap though is much larger (even though it's barely noticeable).

I guess eventually a new gen of Excel comes out that can write code without IF, FOR loops, and function calls, but until then it's safe to say anything writing those statements other than in code is pretty much snake oil.

<comment><USER15> The problem is that IF ELSE statement or even calling some functions is easy, however most people are shit scared of it.A person of very average intelligence can do it,but most people will never dare even to try,hence the popularity of all sorts of drag&drop. Another problem is that if one isn't a developer,it is close to impossible to estimate how difficult the task could be. For instance, querying 1000 records in the database is easy but doing the same for millions of records doesn't translate into "oh, let's just do it a few more times".

</comment></comment></comment></comment></comment><comment><USER16> As someone who works in a no-code platform company, my view confirmed by a look at our revenues is the author is way off. low-code no-code platforms are booming and will continue to for a long time. There are several reasons 1 - there is a huge backlog of business processes which can be made more efficient with apps 2 - there is deficiency in developers, but a surplus of knowledge workers 3 - IT departments are unable to solve all users app needs 4 - enterprises are mananaging far too many SaaS 'point solutions' 5- most importantly, ROI and TCO make low-code platforms very attractive. 6 - <USER2> ability to quickly customize business process applications is incredibly important. Low-code platforms provide this 7 - technologies like webhooks are making it easier for low-code app builders to create sophisticated apps tied to multiple cloud and on prem data sources and systems.

<comment><USER17> I am amazed, everything you said is completely true and yet you are totally wrong. Sure your company is doing really well right now. You might even cash out or leave before it goes downhill but it will go downhill.

Low-Code, No-Code is too immature to build a long term sustainable business. It will ebb and flow for decades to come. Always getting closer to solving this list of problems (and the problems are real) until one day we as a society learn to understand where the value boundaries are for digital products. I don't see that happening in the next 50 years.

</comment></comment><comment><USER18> Unity3D game engine is a proof by counterexample that you can be lowcode for creatives and analysts while allowing engineers to fluidly drop down levels of abstraction and control the code, without big rewrites.

<comment><USER19> I think there are quite a few examples of successful low code platforms.

Excel/sheets, wordpress, MS Access, moddable games, arguably even the web itself...

<comment><USER20> I definitely agree with you there, though for moddable games... my experience has been the opposite of low code.

Modding feels like fixing a plane in flight, except someone else built it, it has two nosecones and three wings, and there are twenty other mechanics, some of whom are running around adjusting the things you just tuned up, some of whom aren't actually mechanics, they just like wrenches.

It feels closer to programming anarchy than any open source project I've participated in, and it requires being very comfortable with writing nothing but hacks. Honestly I think it requires a level of cleverness that you should not need in a programming day job, because only masses of technical debt that have gone critical need that much cleverness.

For context, my modding experience comes from Stardew Valley, Rimworld, XCOM 2, and BattleTech.

</comment></comment></comment><comment><USER15> I work with Salesforce that actively pushes 'point and click' configuration to the naive CEOs while at the same time making billions from ever increasing development required to make all the stuff work. Codeless is fine for some genuine vanilla cases but anything beyond that requires code and will continue to do so in the foreseeable future.The only real thing that is changing software field is ever growing abstraction,which does simplify a lot of things.For instance, to create a simple CRUD web app nowadays is a relatively simple task compared to what it used to be 20 years ago. However,even with all the abstraction,the simplicity ends up when complex business problems show up.

<comment><USER21> Ugh just like seeing my current CEO. Guy is "configuration over development", but he will not see point where that configuration will become development. It will in year or two get so complicated that you will not be able to get any guy from the street. But extensive training for 6 months will be needed, just like hiring developer.

To get Salesforce you already need trained consultant to who you pay $$$ and yeah those CEOs don't see it. It is just, developers do some magic and are expensive. Where I don't understand what Salesforce consultant would do and he would also be expensive.

</comment></comment><comment><USER22> I make no-code ETL software for non-technical users ([https://easymorph.com](https://easymorph.com)) and I don't think the article is correct.

A _general-purpose_ low/no-code tool may be an utopia. But _task-specific_ low/no-code software can be very effective and successful. And yes, it does remove/reduce dependency on developers for non-technical people. For corporate users dealing with internal IT departments is frequently a big hassle. Which is by the way one of the reasons why cloud apps are becoming so popular - because they reduce dependency on in-house IT departments.

Although, for low/no-code software it's important to have a decent and reliable API to be able to integrate and interoperate with external apps and systems. With such API it doesn't really matter if the app was developed using a written code, or visual tool.

Second, have good logging/auditing capabilities.

Third, play nicely with security/administration - support LDAP, SSL, etc.

<comment><USER23> Nice product!

I agree, TFA's author doesn't seem to grasp that some tasks, with constrained inputs and outputs, might be better served with a well-designed visual tool. ETL (like Yahoo Pipes and your project) seems well-fitted.

Decades ago I built children's literacy software. I built the building blocks (sometimes visual sprites, sometimes behavior blocks), and the artists and educators took those building blocks and built a series of products. It worked nicely.

</comment></comment><comment><USER24> In my years in the industry I've noticed 2 things.

1) People is what makes coding hard. If the People involved (designers, execs, users) could fit themselves into the simple box of what more or less comes for "free" these days then they could do so many things via GUI. Look at cloudpipes, Zapier, If this then that, and segment.io. Each more or less integrate 100s (1000s?) of tools to eachother. People like to think their business needs are unique, but most of the time it's just JSON being piped from one bucket to another.

2) Lots of companies w/ engineers and a big tech budget are not what I'd classify as a "Tech company", instead they're more of a "Product company". I often use this distinction -- is the thing that makes this company valuable the fact that their tech is better than what others have ever done? This looks like 10-100x more capable in a certain aspect. For example Wix is not a tech company -- it creates a mundane thing in a slightly more accessible way. Compare that with something like Tesla -- they applied technology to the automotive space to create many multiples of more efficient transport to unlock a whole new paradigm in their domain. Most of these "product" companies should be using boring tech and adapting themselves to the tech's edges so they can rapidly and inexpensively build products.

</comment><comment><USER25> I worked in this domain for a couple of years at one of the most innovative players (www.triggre.com). These platforms fulfill a really important role - they allow a far larger class of people to automate their own day-to-day work.

They compete with Excel, MS Access and possibly WordPress. They're never going to replace actual software development because once the problem domain gets complex enough the person behind the wheel needs pretty much all of the skills of a good software engineer. They're also pretty much all closed platforms so only an idiot would use them to build a product. So they're stuck in the small-scale automation hook.

<comment><USER25> I should add that it's a really interesting domain to work in. There is just so much to achieve there and so many of the players are focusing on the wrong things that there are really big chances.

I still have regrets that I left because it was intellectually stimulating. It's just impossible* to work in a startup culture whilst being a _GOOD_ parent to young children.

* When you can't stay late when needed and your colleagues are picking up the slack it feels like sh!t and makes you feel like a massive shit; especially when said colleagues are amazing about it.

</comment></comment><comment><USER26> I think the whole concept is meh. Can you create visual builing blocks that are transformable to an AST? yeah, thats no problem for a given fixed set of blocks. Can vsual blocks be as communicative as written language/syntax for much more open set problem spaces? Yeah as long as you don't want to make that AST, or yeah as long as you hand code the AST map to grow the set manually, but at what point do these visual representations fail to convey clearly the topic?

There is a reason why you have textbooks in school and not a stack of photos. written language is much better suited to convey deep and complex information. Sometimes both together can convey a complex idea better than one in a silo, however without the text to convey what is trying to be shown in the image the complexities of the content in the image are severely limited.

Code is written language, and just happens to be various forms of specialized language we use to convey these open ended concepts. Visuals just can't be as communicative. So I firmly believe that visual blocks are relegated to small sets of problem space and not these open ended sets of problems.

<comment><USER27> > There is a reason why you have textbooks in school and not a stack of > photos. written language is much better suited to convey deep and complex > information.

There's also a reason why many of the best textbooks contain diagrams, images, charts and illustrations. Text is, in my own personal opinion, not the best way to convey deep and complex information _of all types_ and sometimes its not best _in isolation_. Also, some people can learn through pure text and other people are more visual and find it much easier to understand things when stated visually. Personally, I find I often think in boxes and lines (relationships between things, I guess) so need pen and paper at hand when I need to think through a complex programming issue before I can turn into into textual code.

> So I firmly believe that visual blocks are relegated to small sets of > problem space and not these open ended sets of problems.

Meh. I've written some open ended code in Max/MSP and I found it to be a really pleasant and productive experience. Sadly (at the time, at least), Max was too limited in features to really take it further (at the time it didn't have any support for data structures other than a few built in ones, I see that it now does, dunno if I just missed it or if its newer; also, no unit testing support was a big problem), but none of its limitations are limitations of visual languages, just of that particular implementation (which, to be fair, was never intended to be a general purpose language).

Some things really are better suited to text, of course (mathematical formulas certainly), but the best visual languages let you use text for those. And annotate things with text as you wish.

> visuals just can't be as communicative.

I guess I'm a visual thinker, because I completely disagree. Sure, visuals alone are bad at communicating, but its never an all or nothing either or thing. I often find complex issues with just text extremely difficult to get my head around, but a nice diagram can make it trivial. "A picture is worth a thousand words" and all that.

<comment><USER28> I'm with you that pure text can be limiting as a medium for thinking and communication, and that using a wider range of visual expression like diagrams and illustrations can dramatically enhance understanding.

No visual programming environment I've seen compares to the expressivity of writing code - but I also consider myself a visual thinker, and I believe there's still a lot of potential for imaginative rethinking of what it means to code. Text is just a subset of visual communication, and there's no reason why we need to limit ourselves to what can be typed - maybe we could include dynamic interactive symbols as new "words", or program by visually constructing diagrams that include code..

The sweetspot seems to me, visual languages that also let you use code.

<comment><USER27> The ideal would be a language which has a non-ambiguous mapping between both textual and visual, so that you can freely switch between them as you wish, but I've never seen such a thing that was satisfactory and haven't been able to come up with something myself. Having a visual AST or flowchart version of an otherwise textual language just doesn't do it for me.

Failing that, maybe a hybrid thing that lets me do mathematical code and pure algorithmic work textually, but to do all of the higher level architecture and coordination, asynchronous code and stream processing visually.

Personally, I really enjoyed my experience with Max/MSP, I found it quite liberating in many ways and much (but definitely not all) of it suited my way of thinking closely enough that I could bypass the pen-and-paper to figure out complex things. I also really liked not having to name things (until I wanted to, at least) which I found made experimenting with ideas, before they were solid enough to put names to things, was also quite interesting.

<comment><USER29> A "non ambiguous mapping", in the typical case, would be way too complex on the visual side, and way too trivial on the textual side. I.e. it would be used, by and large, either for unreadable spaghetti visuals or for high-level, almost trivial descriptions, the sorts which we routinely sketch on whiteboards anyway. Actually it's sort of nice to generate these sketches from code/textual syntax, but that's basically a sort of literate programming, and this is where its utility ends.

There _are_ visual syntaxes that are genuinely useful, but really as an aid to reasoning more than anything - so we're not that far from the "literate programming/documentation" case. I include the sorts of diagrams we routinely use, e.g. in category theory (commutative diagrams, string diagrams etc.) under those.

> but to do all of the higher level architecture and coordination, > asynchronous code and stream processing visually.

Thing is, you'll still want to _enter_ all that stuff as _text_ \- not by fiddling with a frickin' mouse. And the authoritative version of that code should be plain text as well - the system should be smart enough to cope with outside edits and do the visual formatting and layout itself if needed.

<comment><USER27> > the authoritative version of that code should be plain text as well

This is why I said the _ideal_ would be a non ambiguous mapping: so that the text and visual code is equal and you can convert between them as you please. Unfortunately, this dream is unlikely.

> Thing is, you'll still want to _enter_ all that stuff as text

Why, though? I'm a very keyboard-centric computer user. I use tiling window managers, keyboard-centric editors (vim & spacemacs) and generally have my setup such that I rarely need to use the mouse. But I don't see the value of needing this input to be through text. My experience with Max and Synthmaker showed me that using the mouse can be quick, easy and efficient. I spent a few months working with Max and having to use the mouse did not bother me as much as I thought it would. In fact, it didn't bother me at all.

I also dream of having this visual system on an ipad (because I'm wholly unsatisfied with the existing ipad programming tools, which are typically too text centric for a touchscreen) and would like to be able to use the touchscreen to draw my boxes and lines.

<comment><USER28> > a hybrid thing that lets me do mathematical code and pure algorithmic work > textually, but to do all of the higher level architecture and coordination, > asynchronous code and stream processing visually

I really like this description of a possible language / IDE, where textual code is the "canonical" representation of the program, with visual layers of interaction to manipulate higher abstractions.

At the bottom, I still think it would be an abstract syntax tree, with textual and visual "views" into the program. As I've got VS Code open in front of me, a few examples come to mind:

\- Minimap: a condensed visual overview and navigation of code structure

\- Color picker: hover on a color value in code, and select from a color wheel, adjust transparency, with preview

\- Type annotations: hover on a variable, function, class instance to see a tooltip showing their type definitions, reference link to source

These are all various ways to represent and interact with the same underlying code, and I imagine many more possibilities exist to extend the "visual programming" aspect.

A quick idea as an example, there could be a mode/view to see the entire program and its modules/dependency tree visually, move classes around, rename/refactor methods..

Whenever "codeless software" and similar topics come up, it always reminds me to re-study the work of Douglas Englebart, Ted Nelson, Alan Kay, Seymour Papert, Bret Victor [0].

[0] [http://worrydream.com/#!2/LadderOfAbstraction](http://worrydream.com/#!2/LadderOfAbstraction)

<comment><USER27> > I still think it would be an abstract syntax tree

I agree. What I meant with my comment was that the visual syntax shouldn't simply be a direct visual representation of the syntax tree, because if that's all it is, I'd rather just write in a Lisp with a graphical tree visualisation generator.

I definitely like the idea of having many possible views of the code, where a traditional textual language is just one of those.

> a few examples come to mind

That sounds quite similar to what LightTable attempted to achieve. Its nice and useful and I want to see more of it, but I don't think its far enough, at least for a discussion on visual languages ;)

> it always reminds me to re-study the work of Douglas Englebart, Ted Nelson, > Alan Kay, Seymour Papert, Bret Victor

Absolutely! They've been a major influence on my own line of thinking on the subject.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER30> A lot of "software" that is currently being developed are relatively simple CRUD applications. A developer shouldn't be required to create these kind of applications. (Most developers also don't enjoy creating these kind of applications, so that is a good match...)

For this category of software, there are increasingly better and modern platforms and frameworks without the need of writing any code such as Microsoft PowerApps, Mendix and SalesForce. That also explains the lately success of these companies.

<comment><USER31> I agree.

I think it's worth reading the sucsess stories of mendix/outsystems about using their low-code tool to build complex software , like hospital management systems or hospital analytics system, and than try to form an opinion.

[https://ryortho.com/breaking/kermit-using-mendix-helping- hos...](https://ryortho.com/breaking/kermit-using-mendix-helping-hospitals- save-millions/)

[https://www.outsystems.com/blog/introducing-sapphire- hospita...](https://www.outsystems.com/blog/introducing-sapphire-hospital- management-system.html)

</comment></comment><comment><USER32> > A little more than 12 years ago, building and hosting a website was a > serious undertaking, costing thousands, and requiring many experts.

Certainly not - any teenager could do it alone even more than twelve years ago. I remember using Notepad - before syntax highlighting was really a thing - to build a site in PHP and hosting it with Apache. The only cost was the domain registration fee.

<comment><USER33> You built a webpage not a website. A website is more than a collection it pages, it is interactions between the pages. It is about saving the shopping cart (what if the user opens several tabs and adds things in each tab). It is about updating the user on stock levels, which changes as other users order items - without giving away data on the other users who might not want the public to be able to guess what they ordered. It is about saving session state. It is about the user coming back the next day to check shipping.

Note that I don't write websites. I only have vague clues as to what issues real web site developers face. The above is a very incomplete overview of the type issues a website developer needs to figure out that don't apply to a webpage.

Today websites are common enough that people have figured out all the common issues and built tools. Now a website is easier because we know of solutions common problems and so you can just use the solution.

<comment><USER34> Plenty of solo amateur web developers, some of them teenagers, were doing this stuff alone 12+ years ago. I was one of them. I'm not saying my code was elegant or secure, but it tried to solve the problems you have described (maybe not working in multiple tabs, that wasn't popular at the time). You could develop sites with sessions and databases in PHP using Notepad, an FTP client, and a web host with a database management admin panel. I didn't find out about version control until years later.

</comment></comment></comment><comment><USER35> I disagree with codeless software being doomed to fail.

I've built lots of applications without code (and teach others how @ [https://www.makerpad.co/](https://www.makerpad.co/)) one being a mini Netflix 'clone', Airbnb 'clone' and Fiverr 'clone'.

They may not be able to withstand Netflix level of users and usage but why should every startup/business have to aim for that. It could service hundreds/thousands of users and turnover great revenue for those running it.

<comment><USER14> Few legitimate businesses want clones of other consumer tools.

<comment><USER35> no of course not. But many are built in the same way.

The only reason these tutorials are built as 'clones' is to show the features for others to tweak for their own.

<comment><USER14> I think that's the point of the article - the moment you try to "tweak" a clone/"codeless"/"softwareless" tool with customizations, you end up writing code, hiring developers, and eventually scrapping and rewriting the said clone.

</comment></comment></comment></comment><comment><USER36> I think the author is limiting his perspective to that of a software engineer.

No web developer is charmed by the limited capabilities of Wix, but it's good enough for the static website many (if not most) businesses are looking for. A CRUD app made by a low-code platform may be limited in its functionality, but it's often good enough for a typical business need. To say it's doomed to fail is an overstatement.

</comment><comment><USER37> > Every couple of years, the hope surfaces that a simple graphical interface > will replace teams of developers. Business people to quickly and easily > create beautiful expressions of their ideas and launch them into production > seamlessly. A handful of startups in every generation take up this > challenge, and they mostly fail.

well, I used to work in a company where a lot of software were written in Max/MSP ([https://1cyjknyddcx62agyb002-c74projects.s3.amazonaws.com/fi...](https://1cyjknyddcx62agyb002-c74projects.s3.amazonaws.com/files/2015/12/super- looper-patching-mode1.png)). Sure, it wasn't very maintainable, but it allowed one person to iterate very fast.

I've also used some CRUD apps which were entirely made in MS Access (D&D 3.5 eTools :) ).

<comment><USER38> Thanks for this great example. I love MaxMSP and I participate in NYU ITP Camp every year where I am amazed at how many creative problems I can solve using MaxMSP. You are right about these solutions not scaling as enterprise applications, but they are valuable within the right context and the ability to share sketches is also great for learning to go deeper. If you don't mind sharing, what's the company that uses MaxMSP in their workflow? I love finding these creative examples and am curious for added context.

</comment></comment><comment><USER39> I think there is natural threshold of inherent complexity of any problem to solve. Codeless or low code software can only go so far but never be successful beyond this threshold. It is the same point where the abstractions of the codeless software become leaky [1]. And, because codeless or low code means heavy abstractions, user will encounter this problem quite early already with simple problems.

[1] [https://www.joelonsoftware.com/2002/11/11/the-law-of- leaky-a...](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky- abstractions/)

</comment><comment><USER40> The author is considering the wrong context.

Services get more fine-grained every year, and composition of these services is where the money will be made in the future. AI might resolve some of the issues with finding the right services for the right use cases & even integrating them.

Custom, home-made services will be a conscious choice, and might be composed of other services that are publicly available or not. Everything else will use off-the-shelf services.

My .02€

<comment><USER41> I dunno, I see the pendulum swinging back again. Or it might just be my contrariness. But building anything decent out of stitching together various third-party services with the baling twine and duct-tape of HTTP... it's not going to end well, and I think people are realising this.

</comment></comment><comment><USER42> SquareSpace would like to have a word with you.

The truth is, this space just gets better every year. You can get more and more done with less and less. Sure, you still can't build arbitrary programs without at the very least a general-purpose programming language, but if you can constrain the solution space _just a little bit_ you'd be very surprised at just how far you can get without needing to break out a text editor.

</comment><comment><USER43> There are 3 kinds of tasks in society.

Tasks that are currently automated. Tasks that you can automate via input from automated tasks, but is currently done manually. Tasks which depends on other manual tasks.

Naive people tend to look at this and think "There are not a lot of tasks in the center there, soon we will have automated everything we could possibly automate!". But what actually happens is that every time someone automates something it opens up more things to be automated.

Example: Automated detection of location and good map API's allowed Uber to automate away basically all overhead from conventional taxi services. Of course since those things were automated for everyone it wasn't hard for conventional taxi services to start providing similar features, but that kind of automation wouldn't be possible without all the automation efforts done over the past decades.

</comment><comment><USER44> This article seems to be responding to the strawman argument that _all_ code will be replaced by visual tools. I don't think this is true, any more than that high level programming languages have replaced all uses of assembly language. At the end of the day, there are applications that care enough about performance that you need to hire someone who deeply understands the microarchitecture of your chip.

That said, Excel has largely replaced traditional text based languages in a significant set of domains, and I don't see any reason that pattern can't be repeated elsewhere. There was a time when summing a bunch of data required a "programmer" and today that is only true for unusually large datasets. You can certainly define Excel to be a programming language, but it doesn't feel that way to most of it's users.

</comment><comment><USER45> Back in the 90's some guy wrote a paper explaining that programming languages are in fact _design_ languages; whereas in most other kinds of engineering, drawings are the superior design tool, in programming, language works better. Empirically/experimentally speaking, you always end up with a more concise description when you describe a program in language. I suppose this is because programming derives heavily from the domains of formal logic and mathematics, which are also heavy on language rather than pictures, and maybe more specifically because you aren't usually modeling physical _things_. But the key thing is to recognize that you don't write programs, you write descriptions of programs - the compiler/interpreter is usually doing the rest.

</comment><comment><USER46> Vendors have been selling various iterations of the "non-technical people can draw diagrams on the screen and then run it" idea for decades.

There are 2 main problems with this idea: 1) it is still code, so you have to think like a coder 2) any non-trivial routine fills pages of "diagram" and is arguably harder to follow than the 20 lines of code that would have sufficed.

An example of (1): At a pretty big early 00's e-commerce site, we decided to let a couple managers implement some "promotions" (conditional discounts) using the commerce suite's drag-n-drop feature. Add an inkjet printer to your cart, get free photo paper. Great. But they forgot to add the reversal logic, so crafty customers quickly figured out how to get reams of free paper! Oops.

</comment><comment><USER47> I used Oracle ADF by force :S

I was consulting for companies using it as a main java framework for all their work. While you can write Java code, most of the time you don't because it gets generated (along with lots of XMLs) and you need special hardware, IDE, build server etc...

Needless to say, the end result was in each case junk, sometimes so big that dedicated oracle tech crew couldn't fix it in 6 months. Any time you are out of the ADF comfort zone (which is like 10 minutes after you tried CRUD) you don't know what to do or you have amazing performance problems (team was using huge dedicated server which could run easily 100+ services instead of the single one _badly_ ).

There is nothing as horrible as it is, its even framed as MVC framework. I would rather Scratch or Lolcat.

</comment><comment><USER27> > Every couple of years, the hope surfaces that a simple graphical interface > will replace teams of developers

Wait! Just because the code is graphical instead of textual, doesn't mean its "codeless" or that non-developers can use it effectively, in a way that the results are maintainable. For example, Max/MSP is used by musicians and artists, quite successfully (so.. not doomed to fail!), but much of the code they generate is a complete mess. This isn't the fault of Max/MSP the language as much as its that the users aren't programmers and therefore never learned to reason about problems in the programmer way or learn about software engineering best practices like... abstraction. Similarly bad textual code is also written by non-programmers, so this isn't just an issue with graphical tools.

You might argue that there's a difference between graphical code like in Max/MSP and purely model-based techniques that try to hide the code-ness even more, but I'm not qualified to comment on those tools because I've not used them.

> Why do people keep trying to breathe life into a solution that is so > obviously doomed to fail

I've personally had great success with Max/MSP and Synthmaker and plenty of people have had success with visual shader generation tools, Unreal Engine's Blueprints, SCADE Studio and whatnot, so I don't think its _" obviously"_ doomed at all.

</comment><comment><USER48> > The reality is that whenever you are building software with any level of > custom functionality, as in it does not come in the box, you are going to > need people who are comfortable writing code.

In other words, if you are making anything with real value that doesn't already exist, you are not going to be able to make it through some kind of WYSIWYG.

On the other hand, just like DSLs are sometimes appropriate, writing a _domain-specific_ WYSIWYG could be appropriate, especially if it's for internal use and not the product itself.

<comment><USER49> I developed a graphical drag and drop bioinformatics app for the biologists at the hospital I used to work at. I'm not sure if it was more efficient than a command line for a skilled practitioner, but it ended up working pretty well all things considered.

As long as what you're doing is not Turing complete, I think WYSIWYG has value.

</comment></comment><comment><USER17> Funny to read how something that will make millions or billions of dollars while creating tens of thousands of applications is a failure. Sure low-code isn't perfect and is being oversold by the people that benefit from it. What commercial software isn't oversold, overpromised, and underdelivered? Name just one if you can.

This has all happened before and will all happen again. Remember Visual Basic. It had all of the benefits and drawbacks of Low-Code. For some uses, it was great and exactly what was needed. For others, it was a horrible trainwreck.

That said, the author is right. It is true for any framework or tool, once you get outside what it does well, you are in for a world of hurt. He is also right in that none or almost none of the Low-Code tools of this generation will make it to the next. Anyone remember PowerBuilder? It was great for about 5 years and OK for about 5 more after that. It is long dead now. Same is true for Cold Fusion. What a great tool for about 5 years.

Every once in a while I still see VB apps out in the wild but I don't know a person that will admit to knowing anything about VB. about 10 years after this current Low-Code revolution dies, another will start. Each time we get a little closer to actually understanding what Low-Code is really good at and keeping it in that box. At this rate humanity will have a great handle on Low- Code in 2457.

</comment><comment><USER50> An anti-example is admin dashboard generation, with ability to customize some parts that requires customization.

Admin dashboard is an interesting problem. To me, to build an MVP means to quickly scaffold an Admin dashboard. Then you can iterate the domain model until it fits the requirements.

Sadly, not enough open source project which is successful to quickly craft a customizable admin dashboard.

Note: Codeless in this case means you configure the dashboard through a json file instead of canvas.

</comment><comment><USER29> Most machine-learning models and AI's are "codeless software" as well, in a very real sense (while the architectures/ _abstract_ models that specify their parameterizations and the format of their inputs and outputs may be a sort of code, the estimated/"learned" parameters themselves are not!) I generally assume that they too are doomed to fail, and for the very same reasons.

</comment><comment><USER51> Block diagram based "codeless" software might not be a one-solution fits all, but it's certainly effective in a number of domains. I'm currently making the transition from writing physical simulation code in Fortran, Python, and C++ to Simulink with great effect. And "codeless" Labview has long dominated equipment controllers in laboratory settings.

<comment><USER52> If you like Simulink, you will love Modelica. Steep learning curve, but it blew my mind once I understood it.

</comment></comment><comment><USER53> Coming at this from a slightly different angle - I'm working on a document generation service [1], and I have an integration with Bubble [2]. I actually have quite a few customers on Bubble who are using my service to fill out PDF documents.

"No-code" is a similar metaphor to "serverless" \- of course there's still servers, but you don't have to worry about managing or scaling them. Or more accurately, you pay a premium for someone else to manage and scale them. For "no-code" platforms, someone is still writing and maintaining all of the code. They just give you an API (or a visual UI) to link everything together.

It's actually pretty amazing what you can build with Bubble, and there are a huge number of plugins [3].

[1] [https://formapi.io](https://formapi.io)

[2] [https://bubble.is](https://bubble.is)

[3] [https://bubble.is/plugins](https://bubble.is/plugins)

</comment><comment><USER54> Ugh. I got on board in 1990, COBOL was still around and 4GLs too. Nowadays there are focused efforts to cater to 'citizen developers' with pared down scripts.

They all fail to live up to the hype. I think it's because you have to have a good general understanding of how things work to properly build (and initially test) software.

</comment><comment><USER55> I am under the impression that low code platforms thrive because you need less skilled people to work with them, and still are able to build your app/whatever.

Yes it's still better to have skilled engineers, but they're expensive and hard to find nowadays, and not every company is even capable of hiring them effectively.

</comment><comment><USER56> You can add a (2018):

<!-- <span class="meta">Posted by <a href="#">Start Bootstrap</a> on August 24, 2018</span> \-->

</comment><comment><USER57> In my first job as a grad I had to work with this absolutely wonderful software called Siebel CRM.

The whole idea behind it was just like the article described; a WYSIWYG in which business people could draw boxes and lines and code would be generated for it.

However it was never that simple, plus Oracle eventually acquired it and added even more fluff onto it.

Thankfully I was developing around the CRM and just had to draw some lines to represent an API being consumed.

I later found out that what I just mentioned is a fourth generation language (4GL) and there are many of them out there.

</comment><comment><USER58> Declarative configuration can work great if you understand the domain really well, you cover it, and it doesn't change very much or very fast or in fundamental ways that upend the problem.

</comment><comment><USER59> They are successful for programming signal processors. For example Digital Audio Workstations, Shader Graphs, and UDK's Kismet.

ETL looks like you could reduce it to signal processing problem. Likewise, general purpose web development looks like you can reduce it to an ETL problem.

So what's the problem, why do these graphical programming languages fail? Because the problems they try to solve are not actually reducible to signal processing.

</comment><comment><USER60> Code is simply the best UI we have for building software

</comment><comment><USER61> Super interesting article that has reflected some conversations at past workplaces with coworkers. I can't seem to find who actually wrote the article. The About and Contact pages are blank, and there's no attribution on the article. This is also the only post for the entire site. I can't find a date for when this was written. Is @wessej the author of the article?

</comment><comment><USER62> I think it's slightly more nuanced in that it's "codeless software that tries to replicate all the use cases functions of coded software" is doomed to fail.

Look at Zapier, while they do (now) have some options that let you build your own functions, etc. their bread and butter is replacing custom cross service integrations with a handful of clicks and some structured data.

</comment><comment><USER63> If you want to express what something looks like, draw a picture. If you want to express how something behaves, use words.

Graphical tools work great for creating static sites, because you mostly just care what they looks like. If you have complex behavior to describe, however, typing will always be easier than creating a massive flow chart.

</comment><comment><USER64> As a product manager part of me dreams the dream of software I can delivery to clients that doesn't involve long drawn out meetings and discussions with engineers on pros/cons of different approaches, hacks vs the right way etc. If anyone is based in UK, London and working on something in this field contact me.

</comment><comment><USER65> I always think of it like this:

We already try and make coding as fast and easy as possible. The software industry is not a racket that is hiding some magic tool. If we had a magic bullet that any end-user could use to build their software, we would all be using it already.

</comment><comment><USER66> There is a "shadow IT" project happening right now in my company where they are taking my database and dumping it into sales force so they can do low- code. The new CEO does not think we need expensive IT people. I have my popcorn.

</comment><comment><USER67> "Diagrams will replace code" = "Flowcharts will replace novels"

<comment><USER68> Is there actually a platform where I could read a flowchart or story-board version of a novel? I can think of quite a few novels where this would have made my reading experience much better.

<comment><USER69> twine gives you something similar. but i think you are looking for something else

<comment><USER68> Thanks, Twine looks cool. I've never heard of it before. It is kind of what I was thinking about - being able to read a story (in this case a branching one) by going over the diagram. Actually, thinking of it, Detroit: Become Human had a similar nice display of narrative choices.

</comment></comment></comment></comment><comment><USER70> I don't think we are too far off and AI will be the key. Sometimes I like to remember that anything a computer can do can be done by thousands of people in an office. Take a program you've worked on and think about how you would have implemented it with people instead of code, where each person is a function and the data gets passed on a piece of paper. The designed workflow would be easily described to people, and any exact processing would need to be demonstrated to the worker. The super fine details of processing are usually pretty easy to understand as well as the high level. It should just take some AI assisted translating to find the appropriate processing models for the high level requests, with the ability to learn by demonstration for the edge cases.

<comment><USER49> I mean, thousands of people are highly concurrent while computers are not, so I don't think the analogy really holds. If you had people as "functions" and organized them like a computer program, only maybe one person out of a thousand would be doing anything at one time.

<comment><USER70> It is a mental exercise to re-frame the problem. Sure it would be inefficient but the point is every stage could be done with reinforcement learning from a high level abstract design without every dealing with 'code'.

</comment></comment></comment><comment><USER71> A middle ground maybe is to define function parameter types and return types and write a bunch of tests, then have a fuzzer compiler generate the actual function code maybe with the help of machine learning.

<comment><USER72> How will you be able to trust such generated code? What if you forgot/mistyped one of your tests?

<comment><USER71> Same way you trust current compilers.

</comment></comment></comment><comment><USER73> >At first glance, the idea has merit. There are more than enough examples of tasks that used to be really hard, but today are simple. One such example is the task of building a website.

Well with money yes.

</comment><comment><USER74> I think the author is right, but I am trying anyway to make a low code system at yazz.com. Doomed to fail, but some projects are interesting to make!

</comment><comment><USER75> It is doomed to fail because logic can't be abstracted away, and that's the very foundation of programming and what makes it hard.

<comment><USER27> It can't be abstracted _away_ , but it can be abstracted and raised to a higher level. Not all logic can in all cases, of course, but you can certainly abstract many cases of domain-specific logic to something higher level that you might be able to represent in a low/no code system.

<comment><USER75> Higher level building blocks still need logic to assembled just the same. If they don't, they are just configuration. That's why in every one of these use cases of these "no-code" projects, they ended up hiring programmers to build it/keep it. And then the programmers spend the rest of their days cursing whoever built the system which ties their hands.

</comment></comment></comment><comment><USER76> Low-code feels like a deja vu. I call it throwable applications.

built quick to satisfy a short term need.

There is a space for those but it doesn't fit all.

<comment><USER77> Holy grails still do not exist. But for Some use cases old tools worked fine. A more balanced story on [https://nocomplexity.com/nocode- solutions/](https://nocomplexity.com/nocode-solutions/)

</comment></comment><comment><USER78> At some point we're going to run out of lollipops.

</comment><comment><USER79> My counterpoint is Excel.

</comment><comment><USER80> Excel

</comment><comment><USER81> Excel is a bad database?

I think OP was overly trying to be critical of popular things.

Wix is a website with database features, having a back end has purpose.

Using Excel as a traditional database is not what Excel does. Excel is often good enough at storing data that people use it like a database.

Anyway this seemed like a Pop Programming article. Lots of Python and coding love, bashing WYSIWYG and Microsoft products.

<comment><USER82> Half of financial industry runs on Excel.

The other half pretends they are not, while frantically trying to migrate from it with a various degree of success.</comment></comment>


Fresh work on the mathematics of bicycles in motion - <AUTHOR> http://www.nature.com/news/the-bicycle-problem-that-nearly-broke-mathematics-1.20281 <comment><USER3> Avid cyclist, but I have no idea what this is talking about:

"...the phenomenon of 'countersteering', whereby the rider can steer to the left only by first briefly torquing the handlebars to the right, allowing the bike to fall into a leftward lean."

Am I just doing this subconsciously?

<comment><USER4> Yes!

This PDF explains it very well, with illustrations, on the last page:

[http://bicycle.tudelft.nl/schwab/Bicycle/DO-07-3-2bicycles.p...](http://bicycle.tudelft.nl/schwab/Bicycle/DO-07-3-2bicycles.pdf)

"Practically nobody is conscious of the fact that they must steer briefly to the left ion order to make a right-hand turn. But this is not so strange, because the swerve is very small (approximately 3 degrees) and happens very quickly – 0.5 seconds. The wet tire tracks from cycling experiments reveal that we all do this. Apparently we learn this unconsciously when we learn to ride a bike."

<comment><USER5> It seems that they are saying you have to steer right in order to initiate a left lean. But how do they account for steering with no hands?

I can steer pretty well without hands. It seems as if I must be able to initiate the left lean without pushing the handlebars right.

So why couldn't I also do this when not riding without hands?

<comment><USER6> I can ride pretty well without hands as well. When I heard about counter- steering a long time back I paid closer attention to what I was doing while riding hands-free. Turns out that I was doing a weird little bodily flick motion in to get the wheel pointing to the opposite direction of the turn before I started leaning into the turn.

Pay attention to yourself next time you ride and you might be surprised.

<comment><USER7> Yep. If you try to just lean right immediately, the bike will just.... fall over, because the wheel stayed straight.

The momentum from the flick your body creates begins to turn the wheel a small amount, and the forward momentum of the bike in combination with the lean keeps the wheel turned right. By contrast, if you flicked the bike/wheel but did not lean, the wheel would simply straighten itself again.

Even for automobiles this stuff is very simple suspension + steering mechanics. Due to how their suspension & steering components are designed, and assuming they are aligned properly, a car will always follow the road. If the road leans + curves, so does their steering.

</comment></comment></comment></comment></comment><comment><USER8> > _...an ambitious effort that would investigate everything from the strength > of wheels..._

My master touched this. Used AI to find spoke patterns. [http://master.matsemann.com](http://master.matsemann.com)

> _There were untested geometries out there that could transform bike design._

Better hardware and simulations makes it easier to test thousands of these, possibly with the help of AI. I wonder if any drastically new designs will be found in the feature, or if time will show the current design is the best.

<comment><USER9> Thats an interesting pattern - but the issue is how would you true a wheel like that?

</comment></comment><comment><USER10> If nothing else I find it quite fascinating how some bikes are easier to ride without holding the handle bars than others. I can balance much better on my 1998 Specialized Stumpjumper mountain bike (comfortable for minutes without hands) than I can on my 1998 Cannondale R900 racing bike (max 5 seconds without hand).

But for my colleague - he finds it much easier to balance his racing bike.

As the article suggest - the hope is that this will provide better guidelines for building bikes that are more stable.

The balance on my mountain bike definitely saved me from two near crashes of a knock to my rear wheel by a u-turning car and being hit on the handle bars by a wing mirror.

<comment><USER11> Peter Sagan showing how well some people can ride with no hands: [https://streamable.com/2u94](https://streamable.com/2u94)

(From today's stage of the Tour de France)

<comment><USER12> And Ilnur Zakarin (also from today's stage) showing how others aren't as good! Starting at about 2:00 in: [http://www.dailymotion.com/video/x4l18sa_flamme- rouge-etape-...](http://www.dailymotion.com/video/x4l18sa_flamme-rouge- etape-17-berne-finhaut-emosson-tour-de-france-2016_sport)

<comment><USER13> To be fair to Zakarin, the finish is substantially steeper than the section Peter was on, and he had just spent the 30 minutes on the rivet to get the stage win.

</comment></comment></comment></comment><comment><USER14> what was the conclusion ? it's not gyroscopic effects because they still balance with counter-rotating wheels, it's not trail because they can still balance with negative trail. Is it some of each of these effects, if so how much ? What else is involved ?

<comment><USER15> According to TFA (and to this avid cyclist it makes sense) it is the combination of the two effects you mention and weight distribution. Novel bikes can be constructed that tweak one of these inputs into an unsuitable range and yet still balance, but I really doubt you could mess up all three and still have a bicycle.

</comment></comment><comment><USER16> OK - this is probably my ignorance talking, but why is it surprising that bike are balanced? The pedals are basically shoulder width and staggered, which is a very natural position for people to balance in as bipedal creatures? in addition, while the bike is moving, won't the inertia tend to keep things moving in the same direction?

This is all coupled by the fact that the rider is actively piloting and adjusting the bike to keep it under control at all times. The bike seems like it would balance to me because the control mechanisms are designed to keep things balanced easily.

<comment><USER17> Bikes balance themselves; they don't need a rider to do it for them. Watch [https://www.youtube.com/watch?v=oZAc5t2lkvo](https://www.youtube.com/watch?v=oZAc5t2lkvo)

<comment><USER18> I just want to note that this also happens on motorcycles. On a cold winter day my bike dumped me off as I lost traction at a stop light. It started to fall over, bumped its saddle bags, and before the tilt sensor could stall the engine it righted itself in second gear and idled its way through the intersection... with me literally running after it. It hit a curb and eventually stalled upright.

Second most embarassing thing the bike ever did to me.

<comment><USER19> Dare I ask what was the most embarrassing thing the bike did to you?...};-)

<comment><USER18> Oh that was at a stop light shortly after it started raining in a Texas winter. I'm fully layered and geared up with leathers and full rain suit - <USER2> can walk a bit like a robot and look 150 pounds heavier. So I pull up to the light and just before I fully stop, my Dyna just ... slides out from under me. It's rush hour, a busy intersection, and my bike just sorta falls over _in place_ while I'm sitting on it. Nothing you can do can stop it once it slowly starts properly tipping over, so it plonks onto the roll bars and bags (which are wide and leather, thank god). I scramble to haul it back upright on this oil slicked crowned lane, hop back on, and act like nothing at all happened.

</comment></comment></comment></comment></comment><comment><USER20> It might help if they program humanoid robots to ride bikes. The problem seems to be hard to analyze because there's a person on the bike, and the way the person moves with the bike is hard to track.

<comment><USER21> See Murata's Robots: [http://www.murata.com/en- us/about/mboymgirl](http://www.murata.com/en-us/about/mboymgirl)

<comment><USER20> That's cool, but the robot there needs a large gyro stabilizer disc to keep balance. Not exactly the way we do it.

</comment></comment></comment><comment><USER22> Regarding countersteering & bicycles (and motorcycles), I better understood the phenomenon by picturing a bar shoved horizontally through a basketball.

You can steer by either turning the basketball (horizontal plane) or leaning the basketball (vertical plane). In the case of a motorcycle at speed, the bike's effective turning radius is affected more by the lean than by how much the handle-bars are turned. The handle-bars are more about controlling the amount lean.

</comment><comment><USER23> We changed this title to something less baity than the original (et tu, Nature?). If someone suggests a better (more accurate and neutral) title, we can change it again.

<comment><USER24> Pretty soon all of human language will consist of phrases like, "You won't believe what happens when this one weird news aggregator changes a submission title!" Is there some way we can try to reverse this trend outside of HN?

</comment></comment><comment><USER25> How complex can it be? If you have a bare minimum background in basic physics and control theory, and a bicycle in your hands, the qualitative reasons for balance and stability will jump at you in under 10 minutes...

<comment><USER23> Please don't post unsubstantive dismissals of others' work to HN.

If you know more than the rest of us, it would be good to post an informative comment that teaches the reader something. If you don't want to do that, it's fine to post nothing.

<comment><USER25> If you feel that something is trivial and potentially wasting other people's time by means of wasting pixels, I think it's fine to speak up. (Explaining why something is trivial may not be that effective, in general).

I was clearly wrong in that many people disagreed and found this to be an interesting and nontrivial subject.</comment></comment></comment>


The iPhone SDK Will Be Late - <AUTHOR> http://www.businessweek.com/technology/ByteOfTheApple/blog/archives/2008/02/the_iphone_sdk.html <comment><USER2> Anybody waiting to get there hands on this? What are you using in the meantime?

This should be a very attractive market to target for a small startup. Apple will probably sell apps through itunes for 4.99 (or less), so you don't have to worry about sales or distribution (and marketing becomes easier too). And the huge "how do we charge people for this cool thing we made?" issue just completely disappears.

<comment><USER3> > This should be a very attractive market to target for a small startup.

Don't call it "a small startup". A "small startup" in Mac software terms is some guy, or two guys, or three guys ("indie developers") who apply for an LLC online and then publish the app. I'm pretty sure this will also apply to the iPhone.

A startup in the sense of YCombinator is overkill for this type of stuff. It's arguably necessary for a web app to be backed by seed funding, due to the large numbers of things that need to be kept track of and pulled off. It's definitely necessary for some app that relies on corporate deals to be a startup backed by funding. Why would indie developers working on an app waste time moving to Cambridge/Silicon Valley and doing demos to get bought out by Google / have excessive amounts of money get pumped into them by later stage investors? Sure, dinner with the other founders is nice, but is it all worth the resulting obligations (keep running the startup and doing nothing else, accept investments, get big or get bought out, etc..)

If there's something I'm missing, can someone weigh in on what the _point_ would be?

That said, I can't wait to get my hands on the SDK, and am using nothing else in the meantime. I want to get my foot in the door as soon as possible.

<comment><USER4> Well, I would argue that its possible that "small startup" could mean a wide range of things, not simply the kind of company Y Combinator tends to fund.

I would also argue that an iPhone app company is at least as likely to be a successful Y Combinator startup as just about anyone else they've funded.

It's a mistake to assume that since indie Mac software has traditionally been written by one guy with an LLC, that all iPhone software will be written that way. For one, the iPhone is a completely different market, much more akin to the iPod than the mac.

</comment></comment></comment><comment><USER5> I remember reading an article in Time about a shareware author who was grossing 600k a year from registrations for his software product. I forget which niche the product was in but the point here is, among the PocketInformant/WebIS big PDA apps there will be plenty of room for independent/small companies to thrive. Build a product that people will use, support it, and do well.</comment>


Escape from the Mayo Clinic: Teen accuses hospital of 'medical kidnapping' - <AUTHOR> https://www.cnn.com/2018/08/13/health/mayo-clinic-escape-1-eprise/index.html <comment><USER2> Anecdata: Have been there multiple times for treatment of a severely handicapped child. Found them to be the best run hospital I have ever visited by far, and I have more than one severely handicapped child. I see a lot of hospitals every year.

Not to say this didn't happen. The story seems surprisingly well reported and sourced. If it's true I hope the hammer falls on the people responsible. But anyone who has been on the business end of a journalist knows that accurate reportage is exceptionally rare.

</comment><comment><USER3> > Alyssa signed the form, but Plumbo declined to answer CNN's questions on the > record.

This is such an infuriatingly typical corporate sleazebag move: "We _can 't_ comment because of privacy reasons." Consent is provided. "Uhhhh actually still no comment."

A hyper-cautious approach _might_ hypothetically provide some marginal protection in the case of a lawsuit, but it sure makes you look like garbage to any independent reporter.

</comment><comment><USER4> I decided I can't say as much as I originally did, but I've observed first hand, in a close relative, how the Mayo Clinics misdiagnosed and mis-treated a problem for three years. It was only a chance conversation with a business associate, who had a family member who was expeditiously and effectively treated for the same class of problem, that resulted in my relative seeing their doctor and getting that effective treatment. Only, in three years, a lot of systemic and chronic damage had been done.

This treatment was, is the standard first course of treatment for my relative's circumstances and symptoms. It was perhaps unusual for Minnesota, but not some rare condition -- hardly.

The Mayo Clinics continue to have a stellar reputation. However, I've observed what I consider gross incompetence on their part, along with apparent closed- mindedness to... what? Effectively interrogating the case and actually researching what the rest of the world does about it?

I'm not free, on a personal level, to go into the details.

But I learned that you can trust _no place,_ based solely on their reputation.

And reputation seems to breed arrogance and dismissiveness that is counter- productive -- outright harmful.

</comment><comment><USER5> It wouldn't surprise me to learn that the parents had 'good' insurance and the Mayo saw a way to milk it to the lifetime maximum. Don't let 'em go until you milk 'em dry...

Disgusting behavior.</comment>


Apple promises fix 'very soon' for Macs with failed encryption - <AUTHOR> http://www.reuters.com/article/technologyNews/idUSBREA1L10220140222 <comment><USER2> It was completely irresponsible not to release the OS X fix at the same time as the ios fix. Apple also needs to setup a way to alert users when an update fixes an important security fix.

None of my ios devices asked to install the fix and I had to do a manual update check. This should not happen for major security issues.

<comment><USER3> Also, the ios over-the-air update refused to download over 3g even though it was only 10mb. I couldn't even manually update until I got back home much later :-/

(Last time I tethered to a friend's android phone!)

<comment><USER4> This is the stupidest limitation of iOS. Why I can't update or download big apps on 3G? I just don't get it.

<comment><USER5> Blame limitations to wireless air delivery on telcos. They have it at 100MB now limit but before it was 50MB and before that it was 20MB. They telcos prevented files/apps over that size from being transmitted over their wireless networks.

<comment><USER3> Yep, but Apple really should have increased the limit for updates to match the limit for app sizes. It's pretty ridiculous that you can download as many 99mb app installs and updates as you want, but be denied a 10mb critical security patch over 3g.

</comment></comment></comment></comment></comment><comment><USER6> It should be a given that Apple provides a fix for OS X as soon as possible. On the other hand, it is telling that Apple gave priority to iOS.

(Although priority is relative even for iOS. We have many iOS devices in the family and not a single one had asked to install the fix until yesterday evening. The fix, however, was available after a manually initiated update check.)

<comment><USER7> > On the other hand, it is telling that Apple gave priority to iOS.

Maybe not. It could just be that OSX has a higher testing effort. There is a bigger spread of versions across the OSX platform than iOS. And also Apple does have quite a few hardware specific builds of OSX they need to test.

Still completely unacceptable though.

<comment><USER8> I find this hard to believe. After using 10.8 and 10.9 over the last year, the sheer number of bugs is embarrassingly high. Every day, something was breaking for me. They have a serious QA problem i.e. they're either doing it wrong or not at all.

</comment></comment></comment><comment><USER9> C'mon Apple.. This is (as far as i understand) a one-liner fix! In opensource land this would be fixed and packag-manager-updatable in less then 24hrs. Probably less then 6.

The fact that it takes sooo long, and that the fix will be bundled in a blob with all sorts of other "fixes" gives me the feeling that one attack-vector cannot be closed until another is available. I got this feeling years back when a huge back-door-enabling was not closed for months until big fat service pack was issued that "fixed" it (amongst fixing a million+1 other things; probably opening the next attack-vector).

Call me paranoid.

<comment><USER10> Consider that this fix doesn't just remove the goto, it enables code that previously wasn't being run or tested. They need to verify that it works and doesn't segfault, otherwise important services (like the update system itself) could end up being broken. This includes testing on all Macs that can run Mavericks, which is a larger and more complex set of hardware then iOS.

<comment><USER11> I still don't see how that's an excuse. Better to break everyone's TLS connections than leave them vulnerable.

The risk isn't that high either, anyway.

<comment><USER12> I'm not 100% sure, but I think that the Mac update system actually uses this code - if it starts failing they can't send out any more signed updates to people. Far better to wait one or two days more to make sure that you're not about to break some of the more important functionality in the OS, I would think.

</comment></comment></comment></comment><comment><USER13> Wasn't the fix for this to delete a duplicated line of code? How is that a "very soon" fix and not a "yesterday" fix?

<comment><USER14> As metric10 mentioned, that even a one line change can cause failure somewhere else in the system and they have to be confident that the new code that is being executed that wasn't before actually works before release it out to the general public where it could cause more harm. The fix may be simple but the cascading effects from the fix need to be well understood before releasing.

</comment></comment><comment><USER15> So, how do we trust this update given a) we don't know for sure that the original bug was an honest mistake, and b) the encryption checking mechanism is blown so the update to fix the bug can be hijacked.

</comment><comment><USER16> The fallout from this will last for a while. Most normal people are not aware of these security issues and many of them rarely install updates.

<comment> k-mcgrady >> "many of them rarely install updates."

Not true, at least on iOS. iOS 7 is on over 80% of devices less than 6 months after launch.

<comment><USER17> But that remaining 20% or so still includes millions of devices and people who are affected.

<comment><USER18> Absolutely true, but compared to android this is a rather good percentage.

</comment></comment></comment></comment><comment><USER19> I was just reading through Adam Langley's description of the bug and this jumped out at me:

> The code will always jump to the end from that second goto, err will contain > a successful value because the SHA1 update operation was successful and so > the signature verification will never fail.

Wait, Apple still uses SHA1? Are they aware it's banned from use (by NIST, no less) starting with this year?

[http://www.zdnet.com/nist-makes-a-hash-of- sha-1-ban-70000259...](http://www.zdnet.com/nist-makes-a-hash-of- sha-1-ban-7000025980/)

Maybe they'd want to take this opportunity to fix that, too...

<comment><USER20> If a certificate uses SHA1, Apple (or any other vendor) can't help but use that for verification…

<comment><USER21> They can't refuse to use it? It seems to me that SHA1 should be depracated.

<comment><USER22> I don't think you understand what the code is doing.

This is _verifying_ certificates for HTTPS connections - not creating them. If they removed the SHA1 verification, you can no longer visit hundreds of millions of sites that haven't updated their certificates yet.

It's the people still using certificates with SHA1 hashes that need to upgrade.

<comment><USER21> But if browser makers decided not to support the hashes, the website owners would _have_ to upgrade. Why allow them to continue to use weak hashes?

<comment><USER23> Because there isn't an attack that affects them.

</comment></comment></comment></comment></comment></comment><comment><USER24> > "I believe that it's just a mistake and I feel very bad for whomever might > have slipped"

There has been such a rush from many places to cast this as a "mistake". We just don't know whether this was deliberate or a mistake, anything else is just an opinion. I don't see one explanation being less likely than the other, it's annoying to see one explanation being pushed more than the other.

<comment><USER25> Is it _possible_ that this bug was deliberately planted? Sure. Is it _equally likely_ that this bug was deliberately planted as it is that the bug was a mistake? I say no, Occam's razor being the main reason for making that distinction.

<comment><USER26> Occams's razor is a pithy statement, not a fact, not proven theory. Pithy statements don't make things more true than non-pithy statements.

<comment><USER27> [http://en.wikipedia.org/wiki/Solomonoff%27s_theory_of_induct...](http://en.wikipedia.org/wiki/Solomonoff%27s_theory_of_inductive_inference)

<comment><USER26> Not that a link to wikipedia is even a complete sentence but having the most huffman compressible answer doesn't make it the correct one.

From the wikipedia entry on Occam's Razor.

> In the scientific method, Occam's Razor is not considered an irrefutable > principle of logic or a scientific result.

</comment></comment></comment></comment></comment><comment><USER28> This one is going to cause serious damage to the credibility Apple have long been holding with many software developers. Most people seem to have tolerated the massive quality drop in OSX since Tiger (easily their peak version) but a bug as egregious as this which would easily have not happened with the slightest bit of preventative quality control? Absolutely disgraceful.

Until someone else makes a laptop OS that's even half as good as OSX we're all stuck with it.

<comment><USER29> _Most people seem to have tolerated the massive quality drop in OSX since Tiger (easily their peak version)_

I would say that Snow Leopard was their peak, even though it did follow Leopard.

</comment></comment><comment><USER30> Apple: We really are holier than thou.</comment>


How Many People Are In Space Right Now? - <AUTHOR> http://www.howmanypeopleareinspacerightnow.com/

<comment><USER2> Where are you collecting the data from? Will it be possible to provide the name of the people also?</comment>


Free online letter creator based on XeTeX - <AUTHOR> http://letterly.com/

<comment><USER2> An automatic LaTeXed letter creator sounds pretty good, but if I _have_ to enter a 5 line To and From address every time, I'm not going to use it.

<comment><AUTHOR> Do you have any tips to make the form a bit dynamic? [http://github.com/kaihendry/letterly](http://github.com/kaihendry/letterly)

<comment><USER3> Don't know about dynamic, but a visual improvement would be to add a few pixels (less than the apparent width of a space) between the labels and input boxes---too crowded. A second improvement would be to even out the count of serif versus sans serif. The whole point of XeLaTeX is fonts of course, so they and their selection (show sample) are important.</comment></comment></comment>


Human Interface: Backpack harness innovation - <AUTHOR> https://www.carryology.com/liking/industry/human-interface-a-guide-to-backpack-harness-innovation/ <comment><USER2> My father had a custom-fitted backpack made back around 1980, which he gave to me, and it's the best backpack I've ever used.

It goes against practically everything in the book about modern backpack design.

There's about zero customisability, you can adjust the length of the shoulder straps and hip strap and that's about it, but I'm a very similar build to my old man so it fits me almost perfectly.

It's an external aluminium framed pack, with a lot of hard canvas and leather. The shoulder straps are relatively narrow, and made of canvas, they look incredibly uncomfortable, but after I broke them in they were incredible, they moulded to fit me.

The external frame allows for really good back ventilation. The thing I dislike the most about modern backpacks is that I basically end up with a giant sponge on my back. The frame also serves a protective purpose, along with being made out of thick canvas, everything inside the pack stays safe, you could throw it of a cliff.

Of course, it's heavy, bulky, and if it doesn't fit you it's hell to wear. But for a 40 year old backpack it does incredibly well.

I think that the biggest difference between old outdoor equipment and new equipment is that the new stuff is all generic, one size fits all, and designed to be comfortable from the moment you walk out of the store. You can buy a new pack and boots, and go on a 5 day hike the next day without having to break in any of your equipment. Perfect for our fast food, turnkey culture. Older, and modern bespoke equipment made in the old way, will last you an entire lifetime, but it takes time to break it in and maintain it.

I've always found it interesting that at the point in history where humans were spending the most time in the wilderness, we had the least technically complicated equipment. When the Europeans were exploring and colonising the Americas they did so with nothing but timber, leather, canvas, and a bit of steel. Now we spend a couple of weekends a year in the bush, bringing a plethora of space-age technology just to try and survive: carbon fibre, nylon, and titanium gas cookers that boil water in 30 seconds.

I feel like people often become more reliant on technology, not less, when they go into the outdoors.

<comment><USER3> This seems like a myopic view, like you fell in love with a backpack and built a worldview around it. Modern backpacking gear is extremely light, resilient, and comfortable. You can get packs that ventilate your back. The canvas isn't really any protection at all from being thrown off a cliff, but a pack filled with soft stuff is. And the external frame is totally unnecessary if your pack weighs 20 total pounds because you have modern gear.

And then mix that in with a jab at disposable culture. You can take good care of a modern pack too, I've never had to replace a backpack because it broke.

Sorry to be disagreeable, I just think this comment doesn't reflect a common reality. I'm no gear head, someone else buys all my gear... but I appreciate modern gear.

<comment><USER4> Here's the difference I see: the gear the parent is carrying could last year in the wilderness, without reconnecting to civilization. Same goes for the Europeans colonizing the Americas. Your 20lbs of 'high end gear' lasts until it breaks, and then you're back to the store because you can't repair it.

I grew up camping, and I know how awesome the modern tech is. I also know that most people who use it can't go without it.

Can you repair your sleeping bag? When you drop your mosquito cooking stove 'off a cliff' and break the nozzle, can you fix it? Can you and your modern equipment thrive in the woods after your stove's fuel runs out?

<comment><USER3> Yes, I can and have repaired my sleeping bags. My pocket rocket stove is very sturdy and has a sturdy plastic case, and we've had it for 14+ years. And I think I'd be fine in the forest without a stove, but honestly if I ran out of food I might not last long... I'm not a survivalist.

FWIW, I'd also keep using a pack I liked. But the takeaway shouldn't be people should buy old fashioned backpacks... they mostly suck compared to modern packs.

</comment></comment></comment></comment><comment><USER5> One thing missing in this survey is the arrival of shoulder strap lift straps. If you go back to the 1970s, backpacks more or less uniformly had a shoulder strap that started at the top of your back, sat directly against the body and wrap up and over the shoulders. This transferred a significant amount of weight directly to the top of the shoulders.

At some point, people figured out that it made sense to run an adjustable strap from the very apex of the shoulder strap back to the pack "frame" (whatever that was), designed to generally run at about a 45 degree angle upwards. This massively reduces the load on the shoulders, and converts the shoulder straps more into balance/position elements than load bearing.

</comment><comment><USER6> Having walked over 4000 miles in a Deuter backpack that weighted on average about 33lbs/15kg, I would just add that while optimizing backpack fit is absolutely important, it is more important to constantly optimize how much weight you are carrying. The latter is way more an art than the former.

<comment><USER7> As a former AT thruhiker, I couldn't agree more. Though we definitely would have appreciated packs that were easier on the shoulders and gave less swampback. We had no frame ultralight packs and sort of molded the contents of the pack to fit our shorter torsos.

</comment></comment><comment><USER8> Most of the modern backpacks portrayed are heavy and designed for 45+lb loads (of which some of these packs will comprise 3+lbs).

Would have liked to see more ultralight representation because it serves as a good counterpoint to all the tech that though effective, adds weight.

Reducing weight has been the biggest advancement in ergonomics for me. A pack is an important part of that total and many of his examples - ladder back adjustment systems, contouring supported by robust plastic and foam, articulating ball joints - add to it.

You Ain't Gonna Need It - unless you don't apply that attitude and end up with a 75lb(!) bag.

<comment><USER9> Yup, it's a vicious cycle. You carry more, you need a bigger pack, you're slower, you need to carry more.

</comment></comment><comment><USER10> Fascinating - and just to show how utterly hopeless I am, I think that will be a great piece of evergreen SEO for their site.

As I read the conclusion I could not help think of the Red Dsarf episode where they travel back to 33AD :

"Bags! What did people do before they invented the bag then?"

"Drop things mostly sir"

<comment><USER11> "Bags? Where we going we don't need [dropping nonexistent glasses] bags."

[https://slate.com/news-and-politics/2010/08/the-art-and- scie...](https://slate.com/news-and-politics/2010/08/the-art-and-science-of- carrying-things-on-your-head.html)

</comment></comment><comment><USER12> Fascinating! The entire time I was absorbing why my Osprey women's backpack is so comfortable, so interesting to get the historical breakdown. Not sure about that floating backpack though..

<comment><USER13> Funny, to me the physics of that floating backpack immediately check out on an intuitive level: the less energy I put into making the backpack move, the less energy I'll expend.

<comment><USER14> My only worry would be that it swings, and builds up more movement than necessary. In the video at 0:46 the movements look pretty excessive.

<comment><USER15> I imagine one could dampen the motion by regulating the tension of the bungees? or maybe lock it entirely if you need to jump around for a while?

I think that kind of shock absorption and momentum conservation optimization over something that happens tens of times per minute (like steps or strides when running) would definitely make a difference.

</comment></comment></comment></comment><comment><USER16> A few more recent innovations in packs...

Aarn "bodypacks" use front bags to counterbalance the load on the back: [https://www.aarnpacks.com/](https://www.aarnpacks.com/)

NeoTrekk (formerly LuxuryLite) also offers a "front pack" for counterbalance that can be used with their pack. However, that is just one of the pack's many innovations, which include modular waterproof storage, quick-detach hip belt, camp chair conversion, attachable wheels, and more: [http://www.neotrekk.com/index.html#stackpack](http://www.neotrekk.com/index.html#stackpack)

The McHale Bypass Harness on McHale packs completely solves the inherent adjustment problems of the traditional load-lifter design used on most trekking packs. This innovation is not recent; its US patent has expired. Despite this, I do not know of any companies that have adopted it: [http://www.mchalepacks.com/sarc/04.htm](http://www.mchalepacks.com/sarc/04.htm)

</comment><comment><USER17> If you ask people who live and die by their 'backpacks' \- the military (they'd call them rucksacks in the US or bergens in the UK) - you'll find that they eschew all this fancy complexity and just use something with a very basic structure. You may get an internal metal or polymer frame, but that'll be about it. Keep it simple.

<comment><USER18> I do mountain biking and lots of hiking. For years I used an Osprey bag which was super light and had lots of features. Problems was that it was hard to clean, the fabric/zips were not strong enough and it was difficult to load.

Now I just use a backpack designed for a laptop. The material is easy to wipe clean. It is rectangular which makes it far easier to load stuff than the weird semi-cylinder shape. The material is string and the zips are much more meaty. And the flat rectangular back is very comfortable for me.

<comment><USER19> I had the same issue for a while and I just downsized to a really nice 'cheap' osprey Rook 65 which is just a big single main compartment and a top lid. It isn't really meant for huge weight but I can easily get 5 days of food and gear for alpine conditions.

</comment></comment></comment><comment><USER20> Surprised to see so few innovations for the sweaty back problem. Are the "trampoline" and plastic with holes really the only solutions in this space?

</comment><comment><USER21> I'm backpacking 8 days into the backcountry this Summer. I was fitted for my pack in 2009 and used it on a few trips, carrying up to 75 pounds for several days. Even with a fitted pack, my shoulders took a beating. I don't know whether upgrading packs will make much of a difference but need to act soon.

<comment><USER22> Yikes that's a heavy pack.

[https://www.rei.com/blog/camp/how-much-should-your-pack- weig...](https://www.rei.com/blog/camp/how-much-should-your-pack-weigh)

Almost all of the pack weight should be on your hips, not your shoulders.

Good luck preparing for your next trip.

<comment><USER21> I alternate the load from hip to shoulder when climbing elevation. I'll try not to this time..

</comment></comment></comment><comment><USER23> I always thought shoulder straps need more connection between them at chest level - would that make sense? I think it would even the load better.

<comment><USER24> My Kriega R30 backpack has that, its not that great for walking in my opinion but i can wear it all day on the motorcycle (that's what its made for), off the bike i usually have my pants and jacket and helmet hooked on the top of it so its very overweight.

[https://kriega.com/riderpacks/](https://kriega.com/riderpacks/)

<comment><USER23> Ah, so they do make them! Yes, that's what I meant, like those R35/R30 backpacks. Haven't seen that before, thanks for the link!

</comment></comment></comment><comment><USER25> All this innovations, adjustments and frames with joints add extra weight. Going ultralight might be far more beneficial.

<comment><USER2> Yes, but we also have the benefit of modern materials science.

You can make a backpack with a lot more parts/materials and still have it lighter than a backpack made 20 or 30 years ago.

Of course the downside is that you can't repair them when they break. You can't weld, glue, or sew broken parts any more, and good luck getting replacement parts or modifying your pack in any way.

Some of us like our creature comforts too. I could go ultra-lightweight, but I don't want to be eating nothing but beef jerky and snickers bars, and sleeping under a couple of square feet of tarp. I want to eat real food and sleep in a tent (actually I've always been a hut man).

<comment><USER26> You can tape it. Easier to do and to carry on the field.

</comment></comment></comment><comment><USER9> Despite all these fancy designs, I see a big trend towards simple packs. A main compartment, no lid to speak of and a small external pocket.

Pair that with the increasingly popular vest-style designs and we have a winner.

</comment><comment><USER27> Could use this research towards further improvement of steadycam systems</comment>


Ask HN: Mobile workstation class laptop without full number keypad included - <AUTHOR> I used to have a ThinkPad W530. It was a glorious machine. Its successor, the W540 has a full number pad on the right side of the keyboard. Because of this, the trackpad isn't centered, but skewed to the left.
This is a horrible design decision, in my opinion, and very common now.
I'd like to get a laptop that'll take 32GB of RAM (preferably 64GB)
The "P" series ThinkPads go to 64, but that number pad. UGH. <comment><USER2> "Workstation" is pretty ambiguous. Besides the numberpad, what performance bottle neck needs to be addressed that isn't addressed by current generation i7 processors, ssd, and 32gb of RAM?

Or by a used 530?</comment>


A World Map without countries with over 100M people - <AUTHOR> https://www.reddit.com/r/MapPorn/comments/cwigdv/a_world_map_without_countries_with_over_100/ <comment><USER2> Now where did I put that Infinity Gauntlet...

</comment><comment> peter-m80 World: The good parts</comment>


Ask HN: skills to look for in young iphone/ipad programmer? - <AUTHOR>

I'm looking to hire an iphone/ipad developer here in Colombia. I want someone young in university, not a full timer. I'll pay them a decent wage, lend them ipad/iphones, pay for their developer status etc.<p>I don't think it'll be easy to find someone with actual iphone/ipad experience, so my question is, what kind of development experience should I look for that means that this person can fairly easily learn/pick up ipad development? I can evaluate some level of technicality/programmerness, but not C++, for example. <comment><USER2> Give some simple algorithmic problems like "Given a tree in preorder, print it in postorder" or "Find longest increasing subsequence in a list of numbers" and ask the guy to code it in front of you. It will be easy to filter out guys who code regularly and will be able to learn iphone development. It will be nice if you can find someone to interview or evaluate the code written by the candidates.

<comment><USER3> _Give some simple algorithmic problems like "Given a tree in preorder, print it in postorder" or "Find longest increasing subsequence in a list of numbers"_

do you want a systems developer or someone who can produce a UI that will sell, the above recommendations tell you nothing about a developers ability to recognize aesthetics. You are not looking for a hard core developer you are looking for someone who has a good blend of developing and design. Lets face it a large portion of iPhone, Web, Flash apps are shallow on the front end as far as depth of logical complexity (put this picture here, submit this data to the server). Look for someone with good organization skills, a decent eye for design and some grounding in software development, don't look for Bill Joy, to develop an iPhone app you will be sorely disappointed.</comment></comment>