PHP Sucks, But It Doesn't Matter - <AUTHOR> http://www.codinghorror.com/blog/2008/05/php-sucks-but-it-doesnt-matter.html <comment><USER6> Note that this is a response to:

EDIT: refer [https://twitter.com/#!/codinghorror/status/18957165652253491...](https://twitter.com/#!/codinghorror/status/189571656522534913) \- Jeff's 4 year old response is still valid.

[http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad- de...](http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/)

Jeff gets it right - the language is poorly designed, but it hasn't stopped PHP powering many of the biggest most important sites on the internet today. Banging on about the language's flaws [again] is not very interesting. What would be fascinating would be an attempt to understand why PHP remains so dominant _despite_ the well-known flaws.

Seriously - <http://stackoverflow.com/questions/tagged/php> throws up so many pearls of WTF that you wonder how PHP could possibly be so important. And yet!

Time to stop the PHP bashing. It's like comp.lang.js complaining about the flaws of jQuery (and, indeed, any JS library) and expounding the many and various reasons you should never use a third party library. The reality is: when the keyboard meets the road, stuff has to get done, and these are the tools that seem to work.

<comment><USER7> This is the wrong way to think about it. Just because people can hop on one leg across the finish line doesn't mean that's a smart way to run a race.

Ask yourself this: would the Instagram team have been as successful had they chosen PHP? I think not.

Javascript is different because we're stuck with it for historical reasons but there are so many better choices on the back end that there is absolutely _no excuse_ to start new work in PHP. Similar negligence would be considered unprofessional in any other engineering discipline.

<comment><USER8> _Ask yourself this: would the Instagram team have been as successful had they chosen PHP?_

They absolutely would.

Building an actual application is a hard problem; a lot harder than the kinks of individual programming languages. Whichever tools you choose it is never going to be an easy ride.

Anyone who has written, deployed or maintained a large scale application of the sort listed there knows this.

It's the step after ranting about how bad X language is.

<comment><USER7> _Building an actual application is a hard problem._

It is. Which is why you can't afford to have the challenges of building something non-trivial compounded by the frustration of working in a broken language. If you're just slapping together another spaghetti CRUD app maybe you don't suffer enough to care.

I wonder if people in other engineering disciplines defend broken practices so irrationally. I suspect they don't have the luxury.

<comment><USER8> PHP has its frustrations. It's not outright broken.

But my point was that all other programming languages suffer their own "broken" problems. I managed a team working in Ruby not long ago; they had no end of gripes and frustrations.

The key point is that compared to the challenge of building a complex application, those "difficulties" are trivial. And once you are at that stage, anyway, you're so used to the way your chosen language works it doesn't matter.

These are not constraints on what the language can achieve or do and simply require knowing about them so that you don't paint yourself into a corner.

Because application design is a hard problem it doesn't matter, given a relatively skilled team, what language is chosen.

This is identical in other engineering disciplines; a friend of mine works in motor design (electrical motor) and is constantly griping about nuances in the tools and equipment. Same issues.

<comment><USER7> Recognizing that all languages have their problems is one thing. Arguing that all languages are essentially equivalent in the larger sense is another.

Sorry I just don't buy it. Tools aren't the only factor but they do matter.

</comment></comment></comment></comment></comment></comment><comment><USER9> Things that don't matter:

      - <USER2>
      - <USER3>
      - Compiler
      - <USER4>
      - <USER5>
      - Testing process
      - Deployment process
      - Bug management systems

The thing that does matter:

      - Building something successful that people want

Frankly, I don't care what language you used to build it. I don't care what shoddy infrastructure supports it. I don't care what hacks you put into place to scale that infrastructure. You know why? Because your customers don't care. They just care that the thing you built works.

So just build something successful that people want. And do it however you want.

<comment><USER10> That's absolutely right. I've established that there's a market for digging trenches for subterranean cables, and my decision to use teaspoons instead of pneumatic drills and mechanical diggers has no bearing whatsoever on my venture's prospects.

<comment><USER11> That would be a very valid analogy if no other trenches had been dug with teaspoons, but a high percentage have, including some of the largest and most successful.

<comment><USER10> The analogy wasn't particularly about PHP, it was about tools.

It might be true that the choice of tool is irrelevant to an end user, investor or other person that's not capable of or interested in judging the tool's merits, but if you're actually trying to build something the choice of tool matters quite a lot. The fact ryannielson doesn't know or care what I do all day doesn't help me get stuff done.

Epilogue: The company I work for recently bought a Content Management System / web framework for half a million bucks, then spent another half a million bucks trying to make it work, then abandoned it in favour of the system we were running before. I think the decision to go with that tool was a poor one.

</comment></comment></comment></comment><comment><USER12> Many both pro and con PHP articles are missing the point about PHP. PHP is a great success in spite of its obvious shortcomings because it supports _iterative development_. (Saying that language choice is less important for a project than other factors doesn't explain anything - all other things being equal, a language with fewer traps and idiosyncrasies would be the better choice.)

The killer feature of PHP is that you can FTP to the server and start adding arbitrary code to a static html file by adding a single tag. Other frameworks _deliberately_ makes this more complicated with more overhead, because they want to promote a better architecture with separation of concerns and so on. Basically these frameworks have "encoded" the waterfall-method, because they assume you know from the start that you need a complex site. PHP supports iterative improvement from the simplest site (static HTML files on a server) to arbitrary complex code, without requiring major speedbumps where you have to rethink the whole app.

This also mirrors how many web developers have learnt to code - starts out with making html/css, then gradually learn php by inserting simple snippets of code to make banner rotate and so on. (The "right way" of course would be to take a pause for a few years to get a CS degree before adding the banner rotator.)

When an app grows beyond a certain level of complexity, changing to a better platform might improve quality, but then you have already made an investment in existing code.

<comment><USER13> Thank you! Iterative development is __key __.

Out of any language I've ever used, PHP has most allowed me to just get stuff done fast. It certainly isn't elegant, but it works. And even as you grow and scale up, as long as you constantly refactor at critical moments, you can avoid spaghetti code just fine.

</comment></comment><comment><USER14> As someone who has written PHP for years, I would say it's starting to matter. The inability for PHP to adapt in a speedy fashion to new programming trends, the continuous implementation of features in a half-assed fashion (namespaces, anonymous functions, etc), and the unwillingness to even attempt to clean up the standard library have begun to marginalize PHP.

It's now easier and faster to get up and running with JavaScript or even Ruby, and these languages have more internal consistency than PHP, meaning that long-term they will see more skilled developers using them and thus will eventually have more and better libraries than PHP.

In addition, the JVM has reached a point where languages like Scala can compete, and apart from the initial cost, C#/.NET will actually _save you money_ in the long term.

So, in short, while PHP is just fine as a language and I use and abuse it every day, I have a feeling that we will be seeing its twilight sooner rather than later, unless something like HPHP takes center stage, breaks backwards compatibility, and shakes up the ecosystem enough to revitalize the language.

</comment><comment><USER15> >But the converse is also true: sufficiently talented coders >can write great applications in terrible languages, too. >It's a painful lesson, but an important one.

>Why fight it? I say learn to embrace it.

I'd say life is too short to write in terrible languages. Yes, PHP was once the language of choice and now that it glorious days are beginning to set, I don't think a little PHP bashing is too inappropriate.

Speaking of PHP popularity, are there any notable startups that launched recently (<1 year) that used PHP? Given the popularity of Rails, Django, Node etc. it feels completely dead. On that side note, let me get back to my Java Server Pages assignment in college (I'm not even kidding).

</comment><comment><USER16> PHP is the textbook example of worse is better. It shows two important things:

1\. The success of a programming language has nothing to do with elegance and everything to do with raw capability, ie. what does the language make dramatically easier.

2\. Technical warts will not prevent great things from being done in a language. It's certainly true that Haskell will not allow you write as broken a piece of software as PHP, but in many cases you _can_ write something just as elegant in PHP as you can in Haskell (laziness/pattern-matching/type- inference notwithstanding).

Now, personally I will do my best to ever write any PHP again, and if someone asks me my opinion I'll tell them that I believe using PHP exclusively will stunt your growth as a software craftsmen. But those are just opinions. I don't feel the need to go out and advocate _against_ PHP because the software communities where I devote my attention are doing just fine. If somebody likes PHP then more power to them, it certainly won't prevent them from doing great things.

</comment><comment><USER17> The article claims that YouTube is written in PHP. As someone who worked there, I can tell you it's not. YouTube is written mostly in Python plus some Go. Some of it is a mess, but that's beside the point.

<comment><USER18> This was actually the reason why I started learning Python for web development. I can't remember how long ago it was, but I had spent months/years burying myself in PHP and hoping to see the light... after having a short affair with rails, Python was the language that called out to me from... eh, usenet probably. It seemed so simple and pleasant, yet with the performance to be powering the 'Tube.

<comment><USER19> do i understand you correctly - you found it harder to learn PHP because its so unorganized and inconsistent ,

and found Python easier to understand and learn than PHP ...

anyone else here with similar experience ?

<comment><USER18> Absolutely. I feel like I wasted some of my most able years fiddling with code that was complete garbage (my fault) and not learning much of anything because I was constantly looking for explanations of, well, everything. Granted, I was young, foolish, and accepted what everyone was saying ("All you need for webdev is PHP... shhhh shhhh"). I didn't really 'get' programming due to all that. But Python was a breath of fresh air, and while I'm no expert I feel much better for it even while going through snippets of PHP.

Basically, I saw PHP as the pragmatic solution to programming for the web. Problem was I didn't really understand programming until Python showed me the light, and while I'm much happier now using and [still] learning C I found it to be an immense help.

</comment></comment></comment></comment><comment><USER20> Any critic of PHP who advocates other languages, like Ruby, Python or Java has to answer a question "Where are the apps?"

PHP has accomplished code reuse on the app level: applications like Wordpress and Drupal are world class and you just can't find installable web apps in other languages that have reached anywhere near the level of success. Occasionally you find an app in another language and generally it doesn't have the fit-and-finish that the successful PHP apps have.

Other languages, on the other hand, grow frameworks like cancer cells, and I wonder what disease they have that prevents these frameworks from being actually usable to build apps.

<comment><USER21> The only reason Wordpress and Drupal became successful is because PHP is present on basically every shared host you can find on the internet. They stayed successful by building a community of plugins and themes.

The actual internals of both are a complete mess, and trying to get them to do anything outside of trivial blog hosting and content management is a nightmare.

Just because you don't know of any Python/Ruby/Java "apps" doesn't mean they don't exist. Jenkins, Redmine, Trac, etc.

<comment><USER20> Note that all three examples of yours are software project management systems. That's a very narrow segment of the market.

You've also got to ask the question of why PHP is so widespread compared to the others.

</comment></comment></comment><comment><USER22> Like it or hate it, PHP stack is easy to start coding webpages if all you know is HTML.

PHP is an easy to enter arena. Memorizing APIs is easier than Computer Science. But PHP works fine with CS concepts. But it also offers a shit ton of commands that allow for both styles to mingle (often times, not nicely).

I'm sick of "your language sucks" arguments. There's good in all of them.

</comment><comment><USER23> I don't see why a couple of badly named functions can make a whole language crappy.

All those people bashing PHP suffer from some kind of superior complex. It's like bullies beating up the ugly nerdy kid that has glasses and pimples.

Or maybe it's just envy that something, that might not win the next language design contest can be so popular.

To all the PHP haters out there: hate away. I don't care. All the other PHP programmers making a living don't care. Mark Zuckerberg clearly doesn't care.

It's time to grow up, people.

</comment><comment><USER24> PHP is like English: a mutated fugly cockroach of a language that defies logical explanation, contains more exceptions to any syntax rule than the rule covers and yet its very ugliness is also its strength: you can always, always find someone who can work in it.

Don't underestimate how useful it is that _anyone_ can come along and hate your codebase just as much as you do in a very short period of time.

</comment><comment><USER25> After reading through the comments I have to leave my comment about PHP.

I have been developing in PHP, Java, and a little of C#, I also have done a few things with Python.

From my exprience it does not matter what language I'm using, it's just a matter of syntax and knowing the language.

My personal preference goes to PHP or Java, and while Python is nice I can't stand the whitespace thing, I like to be able to write my code without thinking about how it looks, only after its written I care about the look for later reading (in my case tell my IDE to make it pretty, by hand its boring but easy too).

While C# as a language is good for me, the msdn documentation sometimes seems rather lacking when compared to PHP or Java and in the case of Java the exceptions it thrown (btw if someone knows where there is a reference for the exceptions a method throws in C# please tell me, I can't find them in msdn).

Yes PHP has its frustrations and quirks, but it is possible to write well structured code for web applications and separating everything using MVC. Same applies to Java or C#, Python etc.

Don't like it? Stop caring about it.

</comment><comment><USER26> Sure, Facebook and Wikipedia are built on PHP, and they serve to very many happy users. But are the developers very happy? PHP works, but for most cases, there are better solutions, and we should strive for better. Just because some sites were successful in doing it doesn't mean 'PHP sucks' isn't a valid argument.

<comment><USER27> I'm fairly happy as a PHP developer. It pay's the bills... there are times when I am presented with a mess which makes me want to shoot myself in the face. However I am sure such messes can easily be created in other languages. PHP has a history of Spaghetti code and when I was learning it mashing mysql, php and html into the same file was 'the way to do it'.

Today though PHP development revolves much more about OOP frameworks like Symfony and a good application structure.

The thing that bugs me most is inconsistency in core functions. Is it functionname or function_name. Is it ($needle, $haystack) or ($haystack, $needle). However, it is a minor annoyance negated by a decent IDE.

</comment></comment><comment><USER28> "building a compelling application is far more important than choice of language." Amen.

</comment><comment><USER29> "If PHP sucks so profoundly, why is it powering so much of the internet?"

The same reason that Excel vba sucks so badly but is powering so much of internal company "applications."

A lot of these sites are first started by a small group of people, looking to get something working ASAP. They do what is easiest, setup LAMP and get hacking. At the time, it's the quickest way to getting something workable.

Inevitably, you end up with a similar situation as you do when your BA takes it upon himself to create an indespensible excel vba spreadsheet. The cost of redoing it in something better is hard to justify, because atleast the current application works. Even though you know it has reached a point where having it as a real application would probably be best since so much of your company relies on its information and analysis.

So here we are, stuck with a shitload of crap written in PHP and Excel VBA, but it doesn't matter. Because all that crap works, and that's the goal. Not maintainability, elegance, programming cred, etc.

</comment><comment><USER30> I've always thought that php was the script equivalent of c, in as much as it'll run anywhere and any library that's ever been written will probably have a version that works in it.

Perhaps those two factors alone outweigh all the others?

</comment><comment><USER31> It does matter when you have to work on an existing PHP project that makes throwing yourself off a bridge seem an attractive proposition.

Yeah, it's not _entirely_ the language that is to blame - the language didn't design and code the project after all - but its own design makes it too easy to create stuff that will really punish more seasoned developers later on.

That it powers some popular products or websites isn't entirely relevant, unless we're saying that Wordpress, Wikipedia, Facebook, etc. are popular _because_ they were written in PHP.

</comment><comment><USER32> The TIOBE index shows PHP's popularity began declining two years ago.

<http://www.tiobe.com/index.php/paperinfo/tpci/PHP.html>

<comment><USER33> Apparently Ruby peaked 3 years ago: <http://www.tiobe.com/index.php/paperinfo/tpci/Ruby.html>

And I don't know what to make of Python: <http://www.tiobe.com/index.php/paperinfo/tpci/Python.html>

</comment></comment><comment><USER34> What surprises me is that "they" can find talented programmers who are willing to code PHP.

<comment><USER35> They don't. They find a lot of "programmers" who can hammer out PHP.

The talented programmers who end up writing PHP don't do it because it was their first choice. It was probably their tenth. Or twentieth.

PHP is one of those tools that you can find a lot of people who know how to use it. Certainly not all of them are actually talented or even competent. But there's a _lot_ of them.

I think the article's conclusion is misguided.

</comment></comment><comment><USER36> When you say Wikipedia, Digg, Wordpress, Facebook, et all were all written in PHP, it doesn't mean a thing. All those use PHP simply because when they started PHP was the best thing available. Nowadays this is not a matter of "it gets the job done" anymore (e.g., Facebook paid $1b for a site that runs of Django).

</comment><comment><USER37> The religious wars over the interpretation of languages needs some serious self-reflection.

There is so much confusion between a language and a framework. Blindingly.

The religions of one language compare their experience, due to a framework, with another language without using a framework.

How does this make sense?

As a non day to day PHP developer:

\- The Web, as a platform is relatively a baby, compared to platforms like PCs, going back to mainframes.

\- I feel for too many devs, the relationship to production code that is more than a few years old seems foreign, especially to those who have joined the Web in the past 5 to 7 years.

\- Most languages used on the web, were not designed for the Web, first. Instead, most languages have a framework to extend a language to the Web.

On Languages:

\- Having seen sites built without a framework in many languages leads me to wonder: Why do we act horrified at old code? It seems reasonable that our old ways of thinking would improve, maybe even be expected for the level of intelligence on hn.

\- Most languages now a days have capable Web frameworks. Instead of focusing on advocating for the use of a framework, we keep the discussion at a much more surface level, like which language.

\- Language is merely syntax. Granted some languages are interpreted to be more eloquent/elegant/efficient than others. Yet the language we all speak, English is the most universal and in a way quite hacked up. Yet we don't take any upfront to bash fellow developers instead of supporting the use of frameworks today so in 5 years, the next batch of people who know lots don't look back and find less fault in todays perfection.

\- I'm at a loss to try and argue one language is the way. It isn't. Nor is one framework. But if your language of choice is not natively made for the Web, make sure you use a framework. Add a beginner it might be one kind, advanced developers can likely pick something else.

\- A mess can be made in every language. What's our point, really, when we can't see the forest while so obsessed with the trees?

On Code:

\- All code older than a year starts to become legacy.

\- I'm not sure if we really understand old code was often written with less foresight than we have today. It didn't make the tools obsolete, as much as old thinking obsolete.

\- There will be new things coming out all the time, few last. As much as it's fun to go on a language witch hunt, we have our own skeletons waiting for us as our projects live on longer and longer.

\- with the Web in it's infancy, is be surprised if 30% of developers have a relationship with 10 year old code at all let alone with code that still is in use on the Web. It's great that we can do things the new way, but we'll always have a growing history of code to maintain a relationship with.

\- PHP might suck along with a lot of other languages, but I hope we consider whether the lens we live we see ourselves thought couldn't use some improvement.

On Frameworks:

\- Every problem someone had with a language is more likely a problem with not having used a framework, instead of the language itself.

\- For those learning coding, learn it from someone who had good habits and thought processes, those are the things that are the most important to have as the language de jour makes it's rounds. Having the transferable skills of decently evolving application design between languages and frameworks will forever leaving.

From where I see it, most languages now have capable frameworks, and all languages have capable developers. Please stop the witch hunts. The amount of vile filth spread about others preferences compared to your preferences based on 10 year old experience and hearsay of a particular language to this developer, is akin to believing and propagating a nasty stereotype about a particular culture or nationality without learning for yourself. It's not that much different than being that ignant.

Developers, let's continue discussing, but more importantly educating and spreading the wisdom of good practices in all the communities we participate in so there's more of us.

Let's spend less time talking trash about others based in hearsay, interpretation and preferences in language, and instead build stuff people want, because we really can make the world a better place with software.

0.05

</comment><comment><USER38> If you think about it, there are two noticeable motives that put PHP where it is:

\- The language has been made and (poorly?) designed around the web. While PHP is a language itself, it usually has no purpose outside the web, while Python and Ruby do not address the same problems the same way.

\- Deployment is easy.

And yet, it seems all these articles fail at noticing these two simple things.

</comment><comment><USER39> Too much comp-sci attitude, too little coder attitude.

</comment><comment><USER40> If you showed me things like this in Ruby or Java I would go just as crazy.

Yes, PHP has its issues (so do all languages). But, if you are a good developer, you can write good code.

Many people writing PHP apps aren't good developers.

</comment><comment><USER41> YouTube is actually written mostly in Python.</comment>


Show HN: Full-text search for the August's who is hiring thread - <AUTHOR> https://hnjobs.lifeoverip.dev/ <comment><AUTHOR> Got tired of clicking "More" so I implemented full text search for August's who is hiring thread.

Suggestions for improvements welcome! Still needs some spit and polish.

<comment><USER2> Very nice! Suggestions: a bit more visual distinction between the entries, perhaps change the 1-pixel line to a 5 pixel? Would also be good to have the searched text (gently) highlighted ...

<comment><AUTHOR> Thanks for the feedback! I will take a crack at these UI improvements after I get out of work.

</comment></comment></comment><comment><USER3> Really neat. Its awesome that the search is auto. Feels like standard autocomplete feature on search engines. Well done!</comment>


The perpetuation of bonded labor in Pakistan - <AUTHOR> https://www.dw.com/en/life-of-slavery-the-perpetuation-of-bonded-labor-in-pakistan/a-51792298 <comment><USER2> Pakistan is the closest thing today to a medieval feudal society. Near no industry, and the upper class is mostly represented by landlords.

Bonded kiln labourers are one thing, but there are also a lot of bonded land labourers.

Were there any opportunity to make money with labour, things would've changed. See, now if those people were to run away, even then they would have little opportunities to make money elsewhere.

Country is knee deep in trade and financial sanctions around the world thanks to India (try sending a wire there from a Western nation, and you will be up for an amazing adventure.) That's not the only impediment to doing exports.

You have to add to this that the elites there a very conscious that if the industrialisation will "hit the fan" it will hit the fan on them. Some are working quite actively to lobby against industrialisation, and trying to sabotage it with passive-aggressive style resistance.

<comment><USER3> And they have nuclear bombs

<comment><USER4> That's a little overblown- they're kept disassembled and have PALs that the Americans know the code to

<comment><USER5> Wikipedia, which of course is not infallible, says that Pakistan rejected US offers to share PAL technology but is believed to have developed their own equivalent.

[https://en.wikipedia.org/wiki/Pakistan_and_weapons_of_mass_d...](https://en.wikipedia.org/wiki/Pakistan_and_weapons_of_mass_destruction#US_security_assistance)

</comment></comment></comment></comment><comment><USER6> This is a painful read, from the comfort of an armchair. The worst is that I even have no idea how an individual can help in such situations.

<comment><USER7> I just realised we just spent more on 5 days for a holiday rental over Christmas than this family received for selling 2 kidneys to try and escape their debt. It's crushing to read stories like these. Surely there must be some sort of structural reform possible to "the way the world works" to prevent this absurd imbalance.

<comment><USER8> >Surely there must be some sort of structural reform possible to "the way the world works" to prevent this absurd imbalance.

Yes, it's called redistributing wealth from those that have it, to those that don't. That means people that have large homes, yards, SUVs, vacations requiring flights, give them up, and pour their resources into lifting up those that don't have it. And not just money, but time and effort to educate the uneducated and impoverished, and blood to fight the oppressors.

It's not a realistic goal, hence it's "the way the world works". It does help one appreciate how lucky one is to be born in the right place at the right time.

<comment><USER9> The primary problem with this suggestion is that it ignores the actual problem. The barriers to the common man's prosperity in Pakistan are erected by the political elites in Pakistan. A world where you can meaningfully talk about employing redistribution is a world where you have already removed those elites and empowered the population against them: a world in which we're having a rather different argument.

<comment><USER8> Removing those elites is what I meant when I wrote "blood to fight the oppressors", aka war.

<comment><USER9> If we are advocating revolution, the next thing is for Pakistan to actually meaningfully industrialize, and gain sufficient wealth — redistributing what already exists only goes a short way. In the ideal case this involves the world economy, and probably looks like outside investment building factories, and the factories paying Pakistani people mediocre money while the new government builds institutions suitable for a modern economy — courts that respect the rule of law, laws that provide a balance between the needs of capital suppliers and labor, laws that promote meaningful competition instead of entrenching well-connected political elites, and a modern education system.

The likelier alternative is they eschew participation in the world economy, building things from scratch themselves, doing it badly, without a rule of law, with a bad education system, with heavy state involvement that provides power to well-connected political elites, and a populist attitude which ignores the needs of capital, promoting empty slogans about economic justice instead of committing to the hard work and sacrifice associated with actually achieving it. The net result will be depressed capital formation, with an economy tilted towards state-run sectors and large companies which are friendly with the new regime. Since capital is important for productivity, the economy will continue to stagnate, though presumably it will see some improvement (it'd be hard not to at this point).

</comment></comment></comment></comment></comment></comment><comment><USER10> Does this have a racial background like the lower castes in India?

As far as I am informed, Islam not only spread by sword in India but also because it overcame the caste system. I don't understand how people united in their rejection of castes are willing to maintain slavery.

Could it be that Pakistan has many former lower castes members and even after centuries of leaving the caste system behind them, they are unable to overcome their victimhood?

<comment><USER11> That is not correct. Caste system never existed in India, at least not in the same or anti-humane form as in Islam - like Sunni, Shia, Ahmediyas etc. Caste system was an invention of the British & magnified to exponential proportions.

<comment><USER4> Shia and Ahmadiyya are treated badly, but they are not castes (not yet anyway). All British did was freeze what they saw in place.

<comment><USER11> The British thought that India suffered from the same casteism as Christianity (& Abrahamic religions) in other places, so they tried their best to retrofit Indian society into that model. But they could find no evidence of casteism, so they were forced to artificially make up many "castes" & grouped people based on occupation etc. The people who could not be fitted into any castes were called a tribes, which are now known as scheduled tribes & castes. Otherwise there should have been just 4 castes according to every tenet of Hinduism. Unfortunately, Indians & the GOI have formalized that artificiality & that is the genesis of the caste system. Caste system is nothing but an invention of the British. Caste itself is a Portuguese word, nothing that correlates to Indian / Hinduism.

<comment><USER4> Pray tell, what casteism does Abrahamic religions suffer from? Sectarianism?</comment></comment></comment></comment></comment>


Open-Source Go Libraries - <AUTHOR> https://www.spacemonkey.com/blog/posts/go-open-source <comment><USER2> Adam Langley will disagree with me on this point, but if you were a client and put a choice of Golang crypto/tls and OpenSSL in front of me, I'd professionally recommend crypto/tls.

This doesn't come up that much, because most production-scale deployments terminate TLS at a cluster of load balancers, so you don't really get to choose which TLS library you use in prod. But if you have the option, I get warmer fuzzies from crypto/tls than from native bindings to the scariest library in cryptography.

This could change in a year or so when the forks settle out, but I hope not, because crypto/tls is a very nice piece of code.

<comment><AUTHOR> Totally. I'd love to see crypto/tls fixed. Until then, though, I'd rather not choose the option with known, existing attack vectors.

Too bad it took such a horrible bug to shake everyone into auditing these libraries.

Edit: fwiw, the hw acceleration is a pretty big deal for us. We have little ARM devices.

<comment><USER2> Are you working from the presumption that Golang crypto/tls admits practical side-channel attacks and OpenSSL doesn't? I would question that assumption. Again: if I had to make a recommendation between the two, then from a security perspective I'd lean crypto/tls.

Regardless, if I was stuck on hardware acceleration, I'd probably stick a reverse proxy in front of my Golang code before I incorporated an OpenSSL Golang binding.

<comment><AUTHOR> Having a separate process for SSL termination is of course completely doable, but was a little more challenging. We use client-side certificates for application level authentication logic, so we would have needed to side- channel the authentication information from our reverse proxy to our app. Again, completely, totally doable, was just harder for our transliteration project [1].

Good advice.

[1] [https://www-staging.spacemonkey.com/blog/posts/go-space- monk...](https://www-staging.spacemonkey.com/blog/posts/go-space-monkey)

</comment></comment></comment></comment><comment><USER3> > While Go has very deliberately not implemented class hierarchies, a quick > perusal of Go's net and os packages should indicate that sometimes error > hierarchies are useful.

I just want to point out - I would hesitate from drawing too many conclusions from "net" and "os" (the latter in particular). Not only is "os" some of the oldest Go code, but it is also designed to wrap conveniently around external interfaces that follow very different idioms.

Another example would be the constant declarations[0], which use ALL_CAPS - this is actually not idiomatic in Go, but it is used here (a) because it was done very early on, and (b) because it more closely matches the C libraries it interfaces with[1].

I need to take a closer look at this errors package before drawing an opinion about the rest of it, but this sentence caught my attention.

[0] [http://golang.org/pkg/os/#pkg-constants](http://golang.org/pkg/os/#pkg- constants)

[1] [https://github.com/golang/lint/issues/32](https://github.com/golang/lint/issues/32)

</comment><comment><USER4> In their errors library - [http://godoc.org/github.com/SpaceMonkeyGo/errors](http://godoc.org/github.com/SpaceMonkeyGo/errors) \- they write:

> It doesn't take long during Go development before you may find yourself > wondering where an error came from. In other languages, as soon as an error > is raised, a stack trace is captured and is displayed as part of the > language's error handling. Go error types are simply basic values, and no > such magic happens to tell you what line or what stack an error came from.

I was thinking the other day that Go's "if err != nil { return err }" is just the explicit version of what's done implicitly with exceptions, except the 'err' doesn't remember where it came from. This lack of information seems like a pretty big inconvenience. How do Go developers typically deal with this problem?

<comment><USER5> github.com/juju/errgo from Canonical is really great. 100% compatible with the error interface, allow you to get the source and the explanation of an error.

<comment><USER6> Thanks for pointing to this. I remember reading about it a while back, but when I needed a stack trace wrapper I couldn't remember the name. I ended up adding a function to an error library I maintain (github.com/surullabs/fault).

When I find some time I'll pull out my code and start using either errgo or the SpaceMonkey version.

</comment></comment></comment><comment><USER7> > Go TLS does not support hardware accelerated crypto.

Go uses AES-NI instructions on amd64 when available [http://tip.golang.org/src/pkg/crypto/aes/asm_amd64.s](http://tip.golang.org/src/pkg/crypto/aes/asm_amd64.s)

> Go TLS does not have wide support for backwards compatibility with less > secure and older protocol versions (a good thing, until you have no other > option).

LibreSSL people beg to differ about this "feature".

> Go TLS does not give much control over the certificate validation process, > which makes it difficult or impossible to add additional checks and > validations.

What exactly is this about?

> Oh, and Go TLS is vulnerable to timing attacks.

A mitigation is in WIP [https://codereview.appspot.com/94850043](https://codereview.appspot.com/94850043)

<comment><AUTHOR> AES-NI doesn't work on ARM, which is what we have.

>> Go TLS does not have wide support for backwards compatibility with less secure and older protocol versions (a good thing, until you have no other option).

> LibreSSL people beg to differ about this "feature".

Agreed agreed! Don't use old protocols!

>> Go TLS does not give much control over the certificate validation process, which makes it difficult or impossible to add additional checks and validations.

> What exactly is this about?

OpenSSL allows you to specify your own validation callback, to add additional checks to the certificate validation step. The only certificate validation option Go's TLS gives you is either InsecureSkipVerify or not.

>> Oh, and Go TLS is vulnerable to timing attacks.

> A mitigation is in WIP > [https://codereview.appspot.com/94850043](https://codereview.appspot.com/94850043)

awesome!

<comment><USER7> > AES-NI doesn't work on ARM, which is what we have.

I'm afraid this falls into scope of the low-priority issue 4299 then: [https://code.google.com/p/go/issues/detail?id=4299](https://code.google.com/p/go/issues/detail?id=4299)

> OpenSSL allows you to specify your own validation callback, to add > additional checks to the certificate validation step. The only certificate > validation option Go's TLS gives you is either InsecureSkipVerify or not.

I'm not sure about the necessity or the details of the particular use case, but if it is general enough, you can file an issue.

<comment><AUTHOR> Thanks for the pointer to #4299. Unfortunately, custom asm isn't going to be nearly as fast as what we're doing, but I left a comment to that affect.

As for adding options to Go TLS, it is worth filing an issue for sure. Go 1 compatibility guarantee (and resulting standard library interface freeze) definitely restricts options here, but yeah I'll look into it.

</comment></comment></comment></comment><comment><USER8> Nice set of libraries. I wonder if they looked at log4go before writing their own logger, and if so what drove them to do so.

<comment><USER9> is there an active fork of log4go? The original hasn't been updated in 2 years, with a couple serious issues which have been open at least as long.

I would also love a flexible logging package (that isn't glog ;).

<comment><USER10> I use seelog ([https://github.com/cihub/seelog](https://github.com/cihub/seelog)) and have been pretty happy with it.</comment></comment></comment>


Ask YC: Usability tools? - <AUTHOR>

Full-blown eyetracking studies are often too expensive for startups, aren't they? So what kind of UX tools are you using? What would you suggest to people who are on a budget? <comment><USER2> In Seattle, there's a group for startups that meets every month or two in a coffee shop to trade usability feedback. It's been described as "like speed dating" -- somebody tries with your website for 5-10 minutes, and then you rotate. In an hour or two, and for the price of a cup of coffee, you get in- person feedback from half a dozen people or more.

I tend to use such high-tech tools as a pencil and a pad of paper to take notes. (If I had $50 to spare I might try Silverback, but I really like my pencil.) I verbally encourage people to talk through what they're thinking and what they're trying to do. Eye-tracking sounds cool but hearing 4 people in a row say "the search box should be _here_!" is pretty darned effective.

</comment><comment><USER3> I would recommend www.useit.com combined with common sense and hallway usability testing.

</comment><comment><USER4> craigslist is a popular place to find users to test for cheap from what I've heard/read (once you find the tools)

Not tried them: [http://www.webcredible.co.uk/services/website- evaluation.sht...](http://www.webcredible.co.uk/services/website- evaluation.shtml)</comment>


Show HN: PYNAB, a read-only API for accessing YNAB data - <AUTHOR> http://github.com/aldanor/pynab.git

<comment><USER2> Nice!

Just added to [https://github.com/realpython/list-of-python-api- wrappers#yo...](https://github.com/realpython/list-of-python-api-wrappers#you- need-a-budget-ynab---personal-budgeting-software)

</comment><comment><USER3> Woah, as a hardcore YNAB user and python enthousiast, this is really cool!</comment>


Ask HN: What is the ideal developer experience in 2020? - <AUTHOR> Today software development looks pretty fragmented and complex depending on what angle you're coming at it from. I've spent the past decade building web apps, distributed systems, infrastructure and all sorts. My feeling is that as a developer there is still so much that stands in my way getting from some local piece of software to something that runs and scales in "production". I'm starting to rethink this from first principles and curious to know what others deem as the ideal developer experience for 2020.<p>Share your thoughts! <comment><USER2> I often consult other teams in my company on technical issues and architecture. Coming from this background I always wish the following would be covered:

\- The project should start up with one click or one command. It's fine if I need to configure credentials or something similar, but beyond that, your project should be so easy to start that your mom could do it. If the project requires me to locally install a database, configure ports, or anything of the like, that's a shining red flag that things are very wrong.

\- The underlying architecture and rationale should be documented and this document should be reasonably up to date. Whoever is the lead developer on the project should be responsible for this. Not all details need to be covered, but the main principles and the driving business requirements behind it need to be clearly stated and up to date. If there's no broad documentation, I consider the project to already be off the rails, not just heading that way.

\- There should be a concept of testing. You don't need to have tests yet, especially if you're still prototyping, but you need to have a very clear idea of what you will test, how, and how you'll get there.

\- Formatting isn't a discussion point. Whatever stylistic preferences there are are covered by linting and automatic formatting. If I clone the project, it should be reasonably hard for me to do things the wrong way and fairly easy to do them the right way.

\- Branch management, code review, etc. All of this falls in the same pot for me, no one should have the ability to push directly to master, all changes need to go through review, pass lint, tests, etc before they can be merged. Doesn't matter if you're the lead dev or a summer intern.

You'll notice that all of the above are procedural issues, not code specific issues. I firmly believe that by nailing the underlying process first, you make it easy to build good software and hard to build bad software.

<comment><USER3> > If the project requires me to locally install a database, configure ports, > or anything of the like, that's a shining red flag that things are very > wrong

I disagree here slightly. I think it's reasonable that a database setup _may_ be necessary, especially if abstraction layers (ie. ORMs) aren't being used for SQL, and SQLite is not your database of choice. Sure, you could set up _docker_ , but not every project adopts or even likes docker.

<comment><USER4> Perhaps the point here is that it shouldn't be necessary to separately configure a database from the command used to fire up the project. For example using Docker w/ docker-compose, a single command should be able to get most projects up and running with all of the required system dependencies included (database, etc).

</comment></comment></comment><comment><USER5> _there is still so much that stands in my way_

My experience is that technology has never stood in my way. It may be inconvenient, but I always find a way to work with it.

The thing that has always been in my way is other people. Always.

For me:

1\. A boss who has a clue. Who has actually built software deployed to production at least once. Who understands the customer's business. Who manages things and leads people, not the other way around. Who gives me my assignments, the resources I'll need, and leaves me alone.

2\. Project managers who know how to run projects.

3\. Business analysts who know how to conduct analysis.

4\. The decision to either go agile or not. No more sprints, stand-ups, scrum masters, product owners, retrospectives, etc, etc, etc, unless we do it completely and do it right.

5\. Anyone, anywhere who writes something, anything down. No more, "Don't you remember when Sue asked Michael and he got Fred to tell us in that skype?" (My answer is always, "No.")

6\. Any environment where I spend 90% of my time programming and 10% on overhead, not the other way around.

7\. Authority to go along with my responsibility. I'm tired hitting every deadline and forced to wait weeks (or months!) for Peer Review, Code Review, Design Review, Standards Review, User Acceptance Testing, Integration Testing, Quality Review (against what standard?), Steering Committee approval, Leadership approval, approval from God herself...

8\. A minimal acceptable competence level for my teammates, achieved by proper vetting (including tech interviews and tests). Software development is achieved as fast as the weakest link, not the strongest one.

9\. No meetings!!! If it isn't written down, it isn't. If it is written down, you probably don't need to meet.

I could go one all day, but I'm late for a meeting. :-(

<comment><USER6> You nailed it. 100% agree.

</comment></comment><comment><USER7> I don't know about you guys, but .NET Core (c#) and Visual Studio along with Blazor on the front end and deploying on Linux is pretty darn cool and highly productive. I haven't had much success getting as productive on Python, Golang, or Node. Blazor eats TypeScript for lunch. Sometimes people confuse complexity for productivity. You can't tell me installing 60,000 NPM packages just to have one dependency break is your idea of fun.

<comment><USER8> Are people really using Blazor in production? What does your build pipeline look like? What dependencies/frameworks are you using?

<comment><USER9> I'm no way expert in Blazor but I wrote small post of how I setup Blazor Web Assembly using Github actions to Digital Ocean - [https://www.integrated.ee/posts/dotnet-blazor-github- actions...](https://www.integrated.ee/posts/dotnet-blazor-github-actions/)

</comment></comment></comment><comment><USER10> * Editor support for every language you use:

Syntax highlighting. Look up documentation at callsite. Jump to definition. Run a test from the editor. Debug executables from within the editor. Fuzzy find file by name (for instance, typing "pluginfancymixi" should turn up something at "project/Plugins/third_party/username/project_name/fancy_mixin.language"). Third-party plugin support. Ability to have per-repo configurations

* Searching code:

Should be faster than grepping a bunch of directories. Supports wildcard searching. Bonus: tooling support for finding identifiers, callsites, usages, etc

* Development environment:

Any executable or test can run in one step (zero if possible). If possible, should be able to run multiple instances of your app at once. For example, I should be able to leave a webserver running so that my code reviewer can test it without pulling the branch

* Team environment:

Small PRs. Quick reviews. Tuned balance between senior and junior engineers. Should have enough senior engineers that they don't feel overwhelmed by the mentorship+training part of their job.

Edited: formatting

</comment><comment><USER11> For me personally, the most important aspect of the developer experience is that infrastructure is taken care of. If I need to solve infra problems, I'm not developing and not happy.

I currently work on a project where infra is a complete mess, but another developer on my team takes care of everything, including setting up our own clandestine k8 cluster to work around the unreasonable limitations of the system we're supposed to be working on. I love him. The downside is that we're not compliant with all the rules we're supposed to comply with, but there's no way for us to comply and still do anything, so I'm happy we're doing stuff.

In an ideal situation, an infra team would take care of all of this for us and ensure it's easy for us to be compliant while still getting stuff done.

Beyond that, the ideal would be a unix-based shell, my preferred IDE (IntelliJ), the ability to install the dev tools I need, proper version control, clear, concise descriptions of what to implement, my own input on what and how to implement, and access to stakeholders/end-users.

</comment><comment><USER12> For me what I've been moving closer towards and is almost my reality for projects I have full control over:

* Node.js on backend, using a thin db layer (not an orm) like sequelize. My newer projects also use TypeScript on back end and share models with front end with a lerna setup

* React.js with TypeScript (default create-react-app setup) on frontend; multiple smaller apps for each business unit/functional area; some limited sharing of UI components between these apps (turns out not that much needs to be shared really)

* Everything in a mono repo and edited in VS.Code

* Deploy by building apps, gzipping backend and frontend into one tarball, then either:

\- Ask my "release person" to copy it into the Windows server drive for test or production

\- Run my own "release script" that scp's it to my Digital Ocean droplet and tells pm2 to restart the production application

My projects email me when something crashes in the back end and I run sentry.io to see what's gone wrong in the front end.

Why I find this to be a great developer experience:

* Simplicity. One language, easy to share things like e.g. validation between FE and BE, minimal cognitive burden when context switching; small apps = simple code; simple release system means I can get new features or bug fixes to users extremely fast with minimal fuss

* No CI pipelines or DevOps time sinks: this is effective because I'm a single developer; I also work on projects where a solid CI pipeline and infra as code adds value, but these things can also slow you down too

=====

In other words, what I feel makes me effective is using a modern language and ecosystem, but deploy it with methods from 10-15 years ago. :)

<comment><USER13> This was engaging to read. Thanks for sharing. I'm curious how you handle down time when you are restarting your servers?

What happens if a client is interacting with the app at that very moment?

</comment></comment><comment><USER14> My Ideal developer experience is;

\- Should not need an IDE ::: The system should be able to be developed without depending on a particular IDE or set of proprietary build tools.

\- CLI tool-chain ::: The system should be able to be built and deployed using CLI tools, preferably open-source.

\- Versioned deploys and Rollback ::: Each deployment should be versioned and rolling back should be fairly trivial (when things break this needs to be easy).

\- Modular development ::: pieces of the system should be able to be developed individually without compiling/building the entire project.

\- Poly Repositories ::: I've found mono-repos make every bit of code _highly- coupled_. CI tools like github actions, makes poly-repos much easier to manage and improve separation of concerns, dependency management and modularity of components.

\- Feature based folder structure ::: Grouping source files by feature, rather than by file type.

\- Design components for testing ::: Testing should be considered during development of components, then integration of testing later is much easier (decouple database logic, dependency inversion etc.).

\- Encapsulation of libraries ::: I personally prefer that most external libraries are encapsulated within wrapper classes, in order to insulate them from directly touching different parts of the system (ideally)

\- Cross-platform should be trivial ::: Web-based applications easily achieve this, but so do many scripting languages etc. If building for different platforms is unreliable/impossible than that's not ideal.

These things vary in importance from person to person, but they're important to me.

</comment><comment><USER15> I am a very occasional programmer. I maintain several different projects for my business; sometimes not working on them for six months or a year.

I've learned to actively loathe getting started on a new feature for one of my sites. The typical process starts by trying to make a simple change to the codebase, only to learn that some tool needs updating (who knows why), but only after digging around for half an hour trying to figure out why something simple doesn't work. I then try to update the tool, but the update doesn't work, because something else has changed on my dev machine, making the update incompatible. After trying to update everything for a couple of hours, I sometimes manage to get the development environment working again, at which time I actually start coding. Sometimes I just give up and try again in a couple of months.

In the good old days, I would just open a code editor and edit a PHP file, then upload via FTP.

If only it were that simple now. My ideal developer experience would be to simply be able to open my computer and start coding – even if I hadn't worked on a project in a few years.

<comment><USER16> Something like Github Codespaces[1] but self-hosted would be interesting. I'm sure you can cobble something together now but it would be nice not to have to deal with the infrastructure (i.e. containers, remote hosts, VPCs, whatever).

[1] [https://github.com/features/codespaces](https://github.com/features/codespaces)

</comment></comment><comment><USER17> Careful what you wish for development in the 70's, 80's and the beginning of the 90's was fragmented and we had a wealth of systems and languages to dive into and explore. Then Windows dominated the desktop, Linux ate the server world and Java went on to dominate most non-system level software development. It went from a great time to be a developer to an extremely mundane task. Today we have captured some of that back, but it is not like it was. Fragmentation also means choices and choices to explore.

</comment><comment><USER18> For me, PHP is still ideal developer experience, even after a decade of working with it.

The language has evolved tastefully without breaking away from the past in drastic(pythonic) ways. Frameworks like Laravel still continue to evolve in a rapid pace than its contemporaries in other languages, bringing in support for every new advancement like webpack, OAuth, etc.

Text editor support is also rapidly accelerating with LSP as a part of the core runtime. PHPStorm is still a beast of an IDE. Composer is in many ways an ideal package manager, a cross between the ease of bundler and local package scoping of npm.

The runtime evolves at a rapid pace, with performance improvements in every release and the upcoming JIT.

Most importantly, the development and deployment story of PHP is still easy as ever. Unlike other modern stacks that require arcane version manager, virtual environments, docker layers, etc, the LAMP stack is still the one script environment creator that requires nothing more than a working Linux distro. The WAMP one click installer still works on Windows without any Subsystems.

</comment><comment><USER19> I contribute to an open source project written in C# that was previously windows-only. When dotnet core came out, I led the effort to port the project to Linux, using Emacs and omnisharp-roslyn which offers intellisense-style code completion via company-mode.

Emacs+C#+omnisharp is pretty darn close to my ideal development experience. My Emacs config is not particularly long nor particularly involved, and in fact one could replicate my C# setup with less than 10 lines of config code.

Highly recommend.

<comment><USER20> would you share a gist to you emacs config ? maybe even a medium article about your setup ?.....

</comment></comment><comment><USER21> I really like my current technology stack which combines stable technology (Java, Spring, Postgres) with some modern cloud-native touches like Spring Boot, Docker and Kubernetes.

Basically any new project (unless requirements show that it needs something else but 90% is OK) starts out as a Java or Kotlin Spring Boot project with a Postgres database. This is super easy to setup locally, provides most things out of the box and the Java/Maven ecosystem has stable libraries for everything else.

When it's time to deploy this I package the project as a Docker container, write a Kubernetes yml config and I'm good to go on most cloud providers.

I focus mostly on making sure there is as little difference as possible between me clicking "Run" in the IDE, and the packaged project running in Docker. Usually the only differences are ENV variables for configuring database and other dependant services.

</comment><comment><USER22> Most answers are about backend/infra etc but i'm going with client side apps and especially Flutter(Dart) + Android Studio. In 30 minutes, tops you have a production-ready environment to develop mobile (and soon web) apps.

\- flutter doctor: checks your Flutter installation and shows missing platform dependencies, if any.

\- Dart is a very nice statically typed language with a decent standard library.

\- Flutter has A LOT of prebuild components for almost everything you need and makes it easy for you to build your own by composing existing ones.

\- Built-in code formatting tool (dartfmt) and testing framework

\- flutter.dev has everything you need to know in one place.

\- pub.dev is a central place for all packages. dartdoc generates beautiful API reference pages for all packages on pub.dev and you can use it on your own packages as well.

\- It works on all devices, all android 4.1.x or newer and iPhone.

I think it's the best tool if you want quickly build a nice looking user interface.

</comment><comment><USER23> Project requirements that have a clear definition of done and do not change every other day.

<comment><USER24> Or... Projects requirements that have a clear definition of outcome and change ever other day based on data.

<comment><USER25> Or... any project requirements that are clear.

<comment><USER26> Or ... project requirements.

Yes, it still happens.

Management: we need a program to do X.

Me: OK, gimme specifics.

Management: To the bike shed!

</comment></comment></comment></comment><comment><USER27> Ideal experience:

1\. I write code in an editor, it auto lints and formats to standards of project.

2\. On save, whatever is needed to build and test is automatically run.

3\. After repeat 1-2 and ready, commit code and create pull request.

4\. On commit, integration tests run and one-off environment to smoke test is created.

5\. On accepted review and merged, auto deploy to production or next release.

</comment><comment><USER28> This is a really great question, thanks for starting this discussion!

Based on my experiences, here are some ideas regarding a hypothetical ideal developer environment - some technical, some cultural:

\- A supportive and responsive team who help each other to get valuable features developed, deployed and maintained

\- Thoughtfully-written test coverage that allows for code evolution, while providing reassurance that changes are correct

\- Local, test and production environments where deployed code behaves identically or near-identically

\- Languages and API documentation that are accessible, expressive and composable while remaining straightforward to reason about

\- Development, deployment and operational tools that lend themselves well to automation so that frustrating and error-prone manual tasks can be reduced

\- Rapid notifications regarding problems encountered by users -- ideally only occuring infrequently, thanks to high code quality, and implemented in a user- privacy-preserving way (to avoid developer anxiety regarding imagined or real lack of organizational respect for users)

\- Code review (for various social and educational reasons, as well as improvement of code quality)

\- Human product feedback, in terms of quality assurance and also genuine user feedback

\- A high-motivation and low-pressurization work setting -- with a sense that the delivered software is genuinely providing a net benefit and is able to anticipate and respond to harms and ideally prevent them in future

\- The time and team approval to investigate bugs and contribute the discovered fixes upstream outside the organization

It also strikes me while writing this that software may be considered easier and/or more comfortable than other careers.

While it's good to strive to find further improvements, it's worth pushing for other employers (and perhaps industries?) to do the same.

</comment><comment><USER29> It has been a long time since I've done any _web_ development, but I've done almost everything else, and I've converged on preferring C# in Visual Studio. Why?

\- typechecked, but the types get out of the way; "var" and intellisense fill them in for you. It also shows you what types the function arguments should be and autosuggests objects of those types

\- functional when you want, but not when you don't: LINQ et al, interlinkage with F# if you want to get really functional, now immutable record types. Lambdas.

\- wordy enough that you can see context, but Intellisense means not having to type it out

\- smart refactoring (paid-for Resharper)

\- debugger when you need it: run test case. Wait to hit exception or breakpoint on failed assertion. Inspect values. It's often immediately obvious where the problem was.

\- CPU and memory profilers readily available and well integrated.

\- standardised on Nunit with Nsubstitute for testing: bit wordy, but with a bit of thought we're now hitting 100% line coverage on wholly new code.

\- portable ish binaries with Mono

\- package management system is mature. (Wart: packages are at the "project" rather than "solution" level in VS, so you need to do extra work to ensure they're all the same version)

The only real downside is the build system (MSBuild) is pretty poor, badly documented, and not easy to use for other things than C#.

For the future? "Software components" have never quite delivered. Package management is clearly the frontier here.

Language interoperability is another: it's _still_ astonishingly hard to combine languages within a single software artefact unless they're C and C++ or similar things that produce platform-native binaries. Proliferation of language runtimes makes this worse, not better. On the other hand, the two frontrunner runtimes of C# and Java both have problematic owners.

<comment><USER30> > Language interoperability is another: it's still astonishingly hard to > combine languages within a single software artefact unless they're C and C++ > or similar things that produce platform-native binaries.

Earlier, you mentioned F#. How easy is it to combine C# and F#?

<comment><USER31> Both languages run on the CLR, compiling to the same set of bytecode. The enables cross-language interop - one of the original promises of .NET. By targeting the Common Language Specification (CLS) they can communicate. The best way to get them to communicate is to use the CLSCompliant attribute, set to true, which generates warnings on non-compliant code so it can be fixed. Here's more detail:

[https://docs.microsoft.com/en-us/dotnet/standard/language- in...](https://docs.microsoft.com/en-us/dotnet/standard/language-independence- and-language-independent-components)

That details the C# point of view (a little VB too) and here's an SO post on how to add the CLSCompliant attribute to F#:

[https://stackoverflow.com/questions/21028833/writing-cls- com...](https://stackoverflow.com/questions/21028833/writing-cls-compliant- code-in-f)

I remember these concepts being very important in the early days of .NET because companies had heavy investments in legacy code, including COM, C, C++, other .NET languages (various forms of interop) and needed integration and/or upgrade migration paths. Language interop came into play because some companies thought (not taking an opinion here) it might be a good idea for developers to use the language of their choice.

</comment></comment></comment><comment><USER32> We just started from scratch a new project in February, pulling out lots of experience between to fairly veteran developers and trying to put together a "reasonable best practice modern stack", so to speak.

I fundamentally couldn't agree more that it's a shitshow right now. Everything could be better. Namely:

\- Typescript + monorepos is a total pain in the ass

\- react-native-web is the way to write apps if you want to go cross platform, but there's a ton of sharp edges and no great UI library to write components more cleanly

\- Still no great, obvious state management system for frontend

\- We've been gluing together a setup for Kubernetes, docker compose (locally), and CI/CD on GitHub. It's a ton of code even while keeping it simple. Too much to list here. We're using Rio for some of it, which starts to get some of the DX better

\- Hasura and graphql and then on the frontend the biggest upgrade I've had in years is gqless ([https://gqless.dev](https://gqless.dev)). It's a bit early, needs a lot of work, but fully typed queries are just incredible

\- Just endless amounts of cross browser issues, polyfills necessary for various browsers

\- Obviously tons of time spent getting webpack to play along.

\- Getting your tests to work just like they would in the browser took us quite a lot of iteration, we use a wide variety of testing tools that took time to figure out

Honestly, it's all bad. The bright spots are Chrome dev tools, React Refresh, gqless, Hasura, and our UI kit which is building on react native but adds components ala SwiftUI (VStack, HStack, etc) that then statically extract to css at compile time.

I do like the thinking behind "Rome" which basically wants to pull everything together and vertically integrate. I'd almost go further and just white label a whole stack just like ours. Including CI/CD, monorepo, etc. If we could pause in 6 months or so and just extract everything we've built into that, it'd be a great template.

<comment><USER33> I wonder if such a project could be funded by companies that use similar stacks. Like Kickstarter, with stretch goals to add tooling that is less important like CI/CD.

</comment></comment><comment><USER34> Because it is hard and always will be. The same with drawing an owl, draw big circle, draw small circle on top of that ... then draw the rest of fucking owl.

There is so much more detail on each layer of a system that there is no way you can just write piece of code and put it to production.

Ideal situation would be if developer can just write code hand it over to test people to check then to ops people who can scale it and secure it. But we all know how it ends up. So even more ideal would be when you write code upload it to the cloud and it just works. But we know it going to cost loads of money.

If there is no silver bullet, try to carve out a little niche for yourself where you mastered own tools and stick to i.

</comment><comment><USER35> Not ideal. But I am using more "cloud native" tooling. Cloud Shell, Cloud Build, Cloud Run on GCP. Spinnaker mapped to the production managed kubernetes cluster. Automation. Speed. Ease. Instant revision control. I think you give up a modicum of control for the convenience. But the cognitive load is gone. You are free to concentrate on app design. Cloud native is becoming standard. And for that reason its worth exploring. There is a nice developer-conscious feature in GCP where you can configure a cluster manually using the platform's web interface. But it also emits the CLI and REST API code snippet for your own reference ;)

</comment><comment><USER6> > ... there is still so much that stands in my way ...

I keep reading this on HN and I am surprised every time. It is so much easier nowadays to develop software than it used to be. Back when I started out there was no HN, no Stack Overflow, no online software developer community that I had access to. I had to learn everything from books and often had nobody to ask. It is _so_ much easier nowadays. I honestly would love to understand what it is that makes it feel hard? Does anybody have a good insight as to why?

</comment><comment><USER6> The ideal developer experience for me has nothing to do with technology. The technology matters very little compared with the people you work with. I am equally productive in C++, Typescript/React, Haskell, whatever. It doesn't matter. What matters is having a great boss, great people working with you, and a project that has real positive impact.

</comment><comment><USER36> My latest side project I've been doing on glitch.com using node.js, React Hooks, and theme-ui.

I miss my Vim bindings, and I wasted a little bit of time trying to get HMR to work with parcel, but other than that it really feels like the tools mostly just get out of the way and let me build my idea, and when I'm done coding I think I'll be happy to just leave it on glitch. (I paid for "boosted apps").

</comment><comment><USER37> Agreed the typical environment is horrible. Seems to be the best way is to try to work on something really high level or low level. IE use some framework like RoR to solve business problems, or a low level library to do something interesting. It feels like everyone should be doing front end, back end, k8s, ML at the same time but its just asking to fail.

<comment><USER38> There's a time and place for a full-stack developer like you mention, but I feel like there's an expectation that they should also be a hyperproductive 10X developer then.

I've seen and worked with people that have that ability, but in practice you see that they're going too fast and miss things like documentation, testing, or even basic architecture.

I mean yeah great that you could knock out some microservices, but they're undocumented nodejs services with a postgres database that communicate with each other using REST / JSON and there's nothing in the way of tracing or logging or status monitoring yet. Why not start with a monolith first in a sane language?

But by the time that question had come up, the guy already moved on to something better paying, lol.

</comment></comment><comment><USER39> "Rethinking from first principles" and "reinventing the wheel" are pretty easy to conflate. Proceed with caution.

My recommendation is to choose boring technologies that are widely deployed so that people will have to support them for decades to come. If there isn't a mature, well-supported option in a space, it's better to roll your own than to spend a bunch of time learning a technology and writing code, and then have to relearn and rewrite in 2 years when that technology is no longer supported. The bigger and more complex something is, the more you should let it get boring before you commit to it.

Here's what I'm using:

* Django

* Django REST Framework

* Celery

* React/React DOM

* ImmerJS

* Postgres

* Redis

* Nginx

For the most part, if it's not on this list, I try not to use it. There are other libraries I'm using, but nothing I would recommend.

There are a lot of things I _hate_ about Django. But it's a boring technology and that outweighs the other concerns. It works and I have no doubts that it will continue to work well.

The one thing on this list that's not a "boring" technology is ImmerJS. This is not a complex technology, so I'm a bit less worried about adding it to my stack. And it allows me to avoid the global state that Redux or similar tools force you into[1]. If a better solution emerges, I don't think switching from Immer will be very difficult, and if Immer loses support, I don't think there will be much difficulty in continuing to use it.

[1] Yes, I understand how reducers work. If you don't understand that reducers are a way of pulling out one part of global state, you do not understand how reducers work. Sure, reducers make using global state less painful, but introducing complex tools to deal with problems created by your other complex tools is not a good strategy.

<comment><USER30> Most people who rethink for first principles actually reinvent the wheel. Once in a while, someone doesn't, and they change the world. It's worth the exercise, even if the odds of success are rather low.

<comment><USER39> In the context of the question being asked, I don't think this makes sense. You're not going to change the world by switching to some new framework.

</comment></comment></comment><comment><USER40> Look at Symbolics Genera and be sad nothing similar exists today, 30 years later.

</comment><comment><USER41> \- There should be only one way to build, test and deploy the project. It should be as simple as possible. \- Every environment should be as close to the production environment as possible. The local and staging data should closely match production data. \- Easy mistakes should be prevented by automation. Commit hooks, linters and other tools should maintain quality at a low cost.

Generally, it's all about reducing friction and preventing human error where it's cheap to do so.

</comment><comment><USER42> While it is "fragmented" nowadays, many one of these branches are larger than the mainstream 10-15 years back, especially when it comes to learning resources and tooling. There has never been a better moment to learn or do programming than now IMHO.

In the same way, something hacked together by your average developer now is a lot more stable than some "production" run 10-15 years ago, even if it's just because of the quality of the infrastructure that exists.

<comment><USER43> I was aspiring to skill up my JavaScript this year and after a few hundred hours have ended up pretty demoralised, realising that the amount of learning required to be a good JS dev in 2020 (at least where I am working atm) seems enormous, and to be frank I'm too old to be wanting to put in evenings and weekends merely to remain competitive. As a consequence I suspect I may well seek to switch back into support, presales or consultancy, all of which I've done in previous roles, and which seem to be somewhat less competitive than straight dev but still rewarding and reasonably remunerated. Overall my feeling is that unless you're pretty rockstar-ish the cost/benefit of being a dev just simply doesn't pay off in 2020, at least here in the UK.

</comment></comment><comment><USER44> Applies to any development environment: A fast development environment with a _properly_ configured anti-malware solution (so not a malware solution that scans on every file _access_ and a slow one at that: Symantec Endpoint Protection). Obviously a fast computer which does not clock the CPU down under load.

</comment><comment><USER45> IMHO the ideal workflow for me is: write -> test -> install.

Nothing more than that.

Perhaps the complexity increase when we start giving funny names for simple things, opinions, personal preferences...

Countless hours can be wasted arguing what "deploy" is, what an "artifact" is, "container", etc.

Boring is better.

</comment><comment><USER46> The problem is competition, innovation, and low cost of replication. Without these it would be so much easier.

You see as soon as you make it easy to do X, everyone does X, X becomes cheap, there is no business in making X anymore, you need to do complicated thing Y.

</comment><comment><USER47> I found it useful to match dev OS with prod OS... for example, if prod is running Debian-based distro, write code in Debian-based distro. Also encountered a lot of horror stories upgrading macOS to Catalina... that is lost productivity.

</comment><comment><USER48> Ruby on Rails running Capistrano on a Linux VPS, provisioned using Ansible or Chef.

</comment><comment><USER49> Agree with another who said it's always the people that end up being a problem and not tech. Unfortunately a lot of tech geared towards fixing the problem ends up creating more of this because there is a new team that has to be created to add the new tech solution to the mix. Given that, I'd like a devx stack that lets a developer go as vertical as possible without involving other people. Once you decide to add a feature, you should be able to go all the way to deployment (and iterating) without involving anybody else.

My ideal devx stack(some parts exist but some don't)

1\. Heroku like deployments everywhere in a Unix like standard fashion. If the standard exists, I'd not worry about vendor lock-in and can choose the right provider for my scale/cost etc. I'll also be able to have the same workflows for private DCs , dev setups etc without running huge bills.

2\. Heroku CI/flow/pipeline, again standardized so I'm not stuck with one vendor.

3\. GitHub + VsCode (or vi or emacs or pycharm) delivered as an offline first service. With templating capabilities so you can onboard new team members with a click.

3\. Expo.io like capabilities across platforms. I get it that it's already available for iOS, Android and web. But what if I have a native app? What about a server I wrote in c/c++? Docker probably. But the updates are still not handled for me automatically.

4\. As a historically backend person, I find it hard to believe it took this long for the front end world to get to the component framework. I'd like to be able to create frontend pages by just pointing to an openAPI crud spec. I want to be able to add special buttons or forms in one line (no more) by just specifying a non-crud openAPI spec. We are almost there but not quite.

5\. Since Saas is the future, All user management, subscription, engagement tracking, support, Customer pipeline etc should be a few line setups.

So I'd get up one day having dreamt of a new feature, walk to my home office in pajamas, code up the backend, _specify_ how to expose it in the frontend, add a few test cases and click submit. It goes through testing locally, in staging, to production, gets distributed a set of people, and sends me some data on how good the dream can be by the time I finish my coffee. If I am happy I click "roll out " And the entire world benefits from my dream.

Some companies have painstakingly built this stack. One man shows can actually do this fairly easily but mainly because the User base is small. But nothing that works for medium sized companies.

Too much to ask?

</comment><comment><USER50> The things that make up my ideal developer experience are actually non- technical and can by summed up as "a sense of urgency but without cutting corners".

</comment><comment><USER51> You have to be able prototype fast and that's nodejs + react . For better performance and still fast dev cycle it could be golang. Golang also for anything related to kubernetes

rust, c++ For some high performance Python might be good to know just because so many DS things are written in those languages. Scala/java/c# for something robust but verbose e.g. fintech It's really depends on industry.

<comment><USER52> I like React, but this is the first time I've heard it described as a fast- prototyping framework.

I believe the Rails guys would be optimizing the SEO and conducting A/B tests by the time I finished deciding whether or not to use a state library.

</comment></comment><comment><USER53> [https://lad.js.org](https://lad.js.org)

</comment><comment> rv-de Having a roof over your head.

</comment><comment><USER54> Project install should be one command. That's probably going to mean a script. Local setup options should be handled by either taking a config (with an example provided) or interactively. This doesn't count the commands to download the archive/clone the repo/etc, but that should be one step anyway.

Building, both artifacts and tests, should be single commands. That might mean you need to write a script that does the "cd into a directory, cmake .., make, make install" dance, but it should be handled.

Dependencies should work, should not conflict with system dependencies, and should be fetched if not already present. Hi Python!

Good IDE support: IntelliJ has some great features, I'd like to use their stuff. But some people want to use other IDEs or editors. Maintain project files for common ones.

Self-contained PRs. Keeping PRs small is all well and good, but having PR A depend on PR B and C and D getting merged in the right order makes review much harder than if they were all just stuck in one.

Must work on Linux, Windows and Mac, at least. Preferably also some BSDs.

Documentation, with all of the following: An introduction saying what your project does, tutorials on how to do intended tasks, how-to guides on solving detailed issues, explanations with examples of how things are used, and a comprehensive reference of what can be done. Divio has a good article[1] about this, though it misses the need for an introduction while providing one itself.

Strong types, with good type inference. Dynamic typing is nice for scripts, but not for full-on programming.

Good safety around memory issues. GC or Rust-style ownership based will depend on application, of course.

Interoperability with different languages. Especially an issue is building multi-language projects.

As an embedded dev, the hardware should be debuggable. Provide a damn JTAG or SWD port. Provide a GDB server or OpenOCD plugin. Provide test points, and a dev board with a damn schematic!

Have your datasheet actually describe the function of the chip and how to communicate with it. LTC (now owned by Analog Devices) datasheets tend to be great examples, try to be like LTC/AD. For example, see the LTC4015 datasheet[2]. It provides example application circuits, clear pin configurations, detailed typical performance info, a nice detailed block diagram, I2C protocol info (because that's chip specific), functional descriptive text, equations to calculate the needed supporting component values, operational state flow charts, detailed component selection procedures, PCB layout considerations, a full register map, and a recommended solder pad layout. Too many datasheets lack too much of this info.

[1] [https://documentation.divio.com/](https://documentation.divio.com/) [2] [https://www.analog.com/media/en/technical- documentation/data...](https://www.analog.com/media/en/technical- documentation/data-sheets/4015fb.pdf)</comment>


Alpine Linux 3.4.4 released - <AUTHOR> https://alpinelinux.org/posts/Alpine-3.4.4-released.html <comment><USER2> Originally learned about Alpine as a base image for Docker, but now I pretty much use Alpine for all "Raspberry Pi and Friends" projects.

Since it runs entirely out of ram by default, it solves a lot of issues with having to "safe shutdown" these computers.

My only complaint is that it's difficult to "pre-bake" the Raspberry Pi images, through something like CI.

</comment><comment><USER3> I tried Alpine as my desktop around 4 months ago, but the documentation felt very insufficient. Just to install Firefox I had to change my repository URLs, and this wasn't mentioned anywhere, I only found out when I searched for the Firefox package to see where it is- "testing".

Furthermore the built-in Lynx does not have HTTPS support, so you cannot read "How to get regular stuff working"[0] before magically switching to the testing repository and installing Firefox. Not to mention that article is essential if you want to compile Lynx with HTTPS enabled. (the gcc pkg is not dependent on build-base and just doing apk install gcc won't result in a working gcc)

Having said that, the choices of OpenRC over systemd, busybox ash over [insert bloated shell here] and musl-libc over glibc are remarkable. Also xorg-base- install(or something like that) and similar scripts are very useful and definitely helped me get going.

0: [https://wiki.alpinelinux.org/wiki/How_to_get_regular_stuff_w...](https://wiki.alpinelinux.org/wiki/How_to_get_regular_stuff_working)

<comment><USER4> Static Linux also chooses musl: [https://news.ycombinator.com/item?id=12588854](https://news.ycombinator.com/item?id=12588854)

And choosing the Almquist shell is not _that_ remarkable, when one realizes that Ubuntu and Debian both did.

<comment><USER3> Well I did not know dash is debian almquist shell, thanks.

However the Wikipedia page says the standard login shell is still bash for Debian and Ubuntu, while Alpine uses ash all around.

</comment></comment></comment><comment><USER5> If they were based on runit, or at least made it easy to switch to that... I would install right now.

<comment><USER4> Then you might be interested in [http://www.mail- firstname.lastname@example.com/msg...](http://www.mail- firstname.lastname@example.com/msg01127.html) and surrounding discussion.

<comment><USER5> Ah - thx for that.</comment></comment></comment>


Why Is Building Affordable Housing So Expensive? - <AUTHOR> https://www.citylab.com/housing/2017/04/why-is-affordable-housing-so-expensive/523707/?utm_source=SFTwitter <comment><USER2> 800k isn't affordable housing by definition.</comment>


TripAdvisor issues warning after part of email database is stolen  - <AUTHOR> http://www.tnooz.com/2011/03/24/news/tripadvisor-issues-warning-after-part-of-email-database-is-stolen/

<comment><AUTHOR> This article references a HN comment[1] that suggests that all TripAdvisor developers have root access to all servers

[1] <http://news.ycombinator.com/item?id=1620324></comment>


Can I self-learn by reading all books in Bachelor/Master degree syllabus? - <AUTHOR> Can I self-learn by reading all books in Bachelor/Master degree syllabus? <comment><USER2> Yes. However, oft recommended books are classics from the ancient times and in them days people weren't in the habit of writing directly to the students (for the most part). Learning from stuffy old books builds character, but robs you of your time.

Instead, pick a subject. Say, abstract algebra. Input this query into the search field on Amazon. It's spits out 100 or so pages of book titles (each page probably has 10 or so books - haven't checked). That right there is a treasure trove. Methodically check through each book. Each book will, in turn, have even more books in the suggestions area. Clicking on any of them will lead down the endless rabbit hole. Going back to the search field and slightly tweaking the search query to, say, "group theory" or "sylow theorems" will result in yet another wildly different list of titles. This shit grows combinatorially :) Along the way you'll come across spectacular books you weren't even searching for (say, textbooks on stats, category theory or measure theory or algorithms). Don't forget to search by date and other parameters, too, as there is a constant churn of new titles. This will introduce you to a ton of phenomenal stuff that never get any mention anywhere (you'll mostly hear about tired old cliche titles). Check out the interesting titles on libgen.

Other sites where you can learn about old, current and upcoming books of interest are Cambridge Press, Springer, MIT Press, MAA etc.

I had to write this in a hurry and forgot a ton of what I was going to say not to mention most of what I typed up above is probably hard to parse as I didn't edit this whole thing. The bottom line: do not depend on the classics. You can always do better and you'll save a lot of time.</comment>


What Are Your Odds of Becoming a Millionaire? - <AUTHOR> http://www.bloomberg.com/features/2016-millionaire-odds/ <comment><USER2> I thought about brokers like real estate, insurance etc. if you live in a high end neighborhood and have family that lives and has connections there you have a lot better income just because your personal network would have larger numbers for commission.</comment>


Ask HN: How do you avoid screen fatigue? - <AUTHOR> I am a developer clocking in 10-11 hours a day (9-7). I take a 1.5 hour lunch break at noon for the gym and then another 15 min break around 4:30, yet I code for the rest of the time (or at least sit in front of the screen). I avoid simple carbs, choose whole foods, and drink a lot of water - enough to make me go to the bathroom every 1.5 hrs or so (nice way to force me to stand up and walk). I also get around 7-8:30hrs of sleep a night to avoid zombying around, and drink max one shot of espresso always before noon. I am in my late 20s.
I find that, at the end of nearly 90% of days, my eyes hurt a lot (I have 20/20 vision thank the gnu gods), I have pounding headaches, and my mood plummets, making me an unpleasant fella.
None of my colleagues have the same problem, or at least they tell me they don't. They take less breaks, don't exercise, and eat oreos and twixes for breakfast, lunch, and dinner, on top of three or so cans of diet coke daily (of course, not everyone does this, but some do and still none have this problem).
Evidently, this makes me upset. Have you experienced the same and been able to improve the situation? If so, how? <comment><USER2> Everytime i sit down at a computer and stare at a screen I wear blue light blocking glasses. I experimented with different intensities of the yellow and found a subtle one to fit me the best. This reduced eye strain by a lot.

What could also be a factor is bad posture, sitting down allday could tighten up the area around through your neck which could cause headaches. I suggest stretching out everyday for 20 minutes to ease that.</comment>


Matt Wynne: Half-Arsed Agile - <AUTHOR> http://blog.mattwynne.net/2013/08/12/half-arsed-agile/

<comment><USER2> I call bullshit. This reminds me of a story of Richard Feynman, where he was arguing with the painter who claimed that he can create yellow by mixing white and red. Feynman of course disagreed, and at the end the painter admitted, that indeed, "a little bit" of yellow is needed.

Either Agile is more productive on it's own, or it just doesn't work. This is just making excuses. The technological gimmicks like continuous integration, TDD and other things the author suggest should be tested independently of Agile.

</comment><comment><USER3> Half-Arsed Server Capacity

<comment><AUTHOR> Yikes! :) Working on it...

<comment><USER3> No worries, I was just being the worst kind of my grumpy German self. Ignore me. :)</comment></comment></comment>


The Arc Challenge by Jim Weirich - <AUTHOR> http://www.onestepback.org/index.cgi/Tech/Ruby/ArcChallenge.red <comment><USER2> Yes, you can create an environment in every language to help you write very short web-apps. I still dont get the point Paul wants to make with his Arc example. Your Ruby solution looks a lot more readable to me. Also my PHP solution, which is here: <http://news.ycombinator.com/item?id=108625>

Maybe Paul wants to elaborate, what from his point of view the advantages of his ARC example are?

</comment><comment><USER3> I'm pretty sure both Wee and IOWA, two Ruby Web frameworks (and each about 5 years old) can do this out of the box.

(Wee was more a prof-of-concept. IOWA is still under active development)

</comment><comment><USER4> The Arc version doesn't depend on continuations. All you need for this is closures.

<comment><USER5> We are not interested in implementation details but abstractions I think. It's like to do a session-cookie based implementation and say that we don't need closures at all, just imperative programming with cookies.

it's very strange you are continuing to argue against 100000 people. Just you didn't picked the right example to show your point.

A dialect of Lisp that's coincise has his space in this world without challanges, if developers will like it eventually it will get some kind of user base. I don't think languages are adopted because of challenges in the real world, nor that this challenges can really show that the language is worth something: it will be automagically clear once a language adds some abstraction that is truly novel and useful, like it happened for garbage collection, for functional programming, OOP, closures and so on.

Not only this, a language can even gain success even being almost feature- equivalent with others just because the designer had a better taste, like it happened to Ruby.</comment></comment>


Load Balancer Written in Dart - <AUTHOR> https://github.com/angel-dart/multiserver <comment><AUTHOR> Just to clear any potential confusion: this load balancer is specifically for Dart applications. Integrating it with other platforms is a bit more complex, while not necessary impossible.</comment>


Ask HN: Is it too late for a late 30s person to start learning coding - <AUTHOR> I am in my late 30s , i learnt basic C programming in school some 15 years back , means i picked up some basic programming concepts. I work in Software product company in a managerial/coordination role. I did make a few failed attempts to start with Python on Coursera , but could never finish the course due to work commitments .
In each attempt I manage to reach the basic classes(loops,while,functions etc) and lost from there, i am not able to cross that level and go to intermediate topics. What is the best way to cross that level and move to intermediate concepts?
If my objective is to learn coding+other basics so that i could build[1] and maintain my ideas[2] , how should i go about and what should i learn?
[1]- A quick Proof of Concept and deploy a working model to demo [2]- Ideas meaning some Webapps/SaaS app <comment><USER2> Try looking at bottlepy for a really simple webapp framework in python. Maybe learning a framework in Python will make it easier to consolidate how Python all fits together. It's not too late though! It just takes time to pick up the rhythm.

The first book I used to learn (that made me feel confident about how to put programs together) when I started Python was Dive Into Python (there's a new one about Python 3, it's probably where to start nowadays). It was written for people with some programming experience but I managed to piece together a broad understanding without much previous programming exposure.

Programming is just another way of learning to build up a logical description of something. It's like writing an executable proof. Give it a shot!

</comment><comment><USER3> It's not too late, certainly not because of your age. It rather depends on your personal life and free time (family, time constraints, etc.). My advice is to go for it when you can spare at least 2 hours per day and you actually enjoy it.

</comment><comment><USER4> Get a project. Having a concrete and useful task at hand is the number one motivator to find out about the features of any given programming system and stay using them. Begin simple. Keep it simple. Good luck. :-)

</comment><comment><USER5> It's never to late. Buy a book, or follow an online class. Do the exercises. Programming is not easy, you need to be persistent if you want to make progress.</comment>