A Design for Death - <AUTHOR> https://www.1843magazine.com/people/a-design-for-death-meeting-the-bad-boy-of-the-euthanasia-movement <comment><USER2> Last week my grandmother had a stroke in her sleep--the most major of a series of strokes that she has endured for slightly over a year that have sent her slowly sinking into dementia. After several days in the hospital without having regained consciousness, her advance directive was enacted and her feeding tube removed. She's at home now in hospice care, surrounded by her husband and children. There's nothing left to do now but wait for death.

Of my two grandmothers, she's the lucky one. The other was T-boned while driving by a pickup blasting through a stop sign. Her body was shattered and her freedom and mobility irrevocably taken. She spent the last two years of her life sequestered away in a nursing home, her mind deteriorating, her few nearby children visiting once a week at most, her husband dead 15 years hence.

Death sucks. But the hell on Earth we force people to endure while waiting for it to arrive doesn't seem much preferable.

Have an advance directive, folks.

</comment><comment><USER3> I can't manage to read this. At one time, I likely would have taken the euthanasia option if it had been available to me.

My life remains a living hell in some ways, but mostly for financial/social reasons. My physical suffering is substantially less.

I can't begin to express both how very much I am for the right to die and how very much I know that, given an easy out, most people won't do the hard stuff. So something like this can easily go very bad places.

There was an American, I think also nicknamed Dr. Death, who was providing euthanasia (illegally). A lot of his patients/clients were chronically ill women who didn't want to be a burden on their family.

One woman in particular seemed like she wanted to die primarily because she had a shitty, unsupportive family, not because her medical issue was really so serious that suicide seemed like a reasonable choice.

Chronically ill or disabled men are much more likely to marry someone and let her physically take care of him, especially if they were able bodied at one time and have a decent income still. It doesn't even have to be a great income.

I read an article once about a study of children in some less developed country where boys were valued more than girls. Boys were fed slightly better. Boys were taken to the doctor slightly sooner -- like in the evening versus "Oh, let's give it a few hours and see how she feels come morning."

Although this was not a case of girls being horribly abused, it was just a case of boys being a little bit pampered, the difference in outcomes could be measured in mortality.

In a world where racism, classism, sexism, etc are still rampant, a death machine has all kinds of potential for horrifying unintended consequences. And those consequences are a sort that are hard to talk about without sounding like a loon or conspiracy theory nutter because the forces at play are fairly subtle and human psychology innately tends to handwave them off as not important.

<comment><USER4> It's a sentiment that I share and is echoed by many disabled people. We're made to feel like we have no place in society. At some point euthanasia ceases being a choice when everyday the feeling that you shouldn't be alive is being reinforced.

<comment><USER3> It's something I'm trying to do something about. I was homeless for years. I run a number of websites and am starting some Reddits to try to put out useful information.

Thank you for commenting. It means something to me.

</comment></comment></comment><comment><USER5> The taboo against euthanasia is mostly after the spread of abrahamic religions.

Throughout history of our world, there has always been ways to end one's own life, their loved ones and those of enemies in battle ..and during times of famine and pestilence.

The 'immortal soul' that has to meet the monotheistic maker changed everything because euthanasia means banishing saved souls to hell and hence becoming unsaved.

Edited to add: perhaps after spread of xianity. The Old Testament begins with a sacrifice after all. I am not terribly familiar with details re religions..correct me if I am wrong?

</comment><comment><USER6> The secular problem with this:

How do we make sure that people aren't forced into this?

<comment><USER7> I think it would be great if people were required to answer a questionnaire with even a psych evaluation in person for wanting to end life.

I don't think any person should ever be refused their request to die. I just think the information is valuable to obtain for going forward by designing society to be more favorable for people to want to live. Currently a lot of people with tremendous psychological pain are being forced to continue being in pain because people don't want to let them end their life. People with depression should be able to have free will over their own life.

<comment><USER8> > People with depression

Depression can usually be treated and results in less will to kill oneself. There is a good case to make that when you suffer from depression you are not yourself anymore.

<comment><USER9> By some estimates, a third of people who have depression have it in a treatment-resistant form: [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4518696/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4518696/) How much treatment would you require these patients to endure before granting them freedom?

<comment> S-E-P You're sense of "freedom" is kind of fucked.

Don't load questions like that, it's painfully annoying.

Anyway death is not freedom; what good is freedom when you aren't around to enjoy it? Foolish notion

<comment><USER10> I salute anyone with the conviction to plan and take their own life. What other sovereignty does another human have save over their own life?

Also your snark reveals some inherent metaphysical assumptions. They may or may not be wrong, but why assume we all hold them?

<comment> S-E-P My snark more comes from years of trudging through some pretty horrible experiences as well as a slew of mental problems.

I live with trauma that I deal with on a daily basis. Paranoia for days and a lot of pain.

I dont salute those who take there own lives; I've thought about taking mine for a decade before giving up on the idea. If you mean something to someone; don't take your life, it hurts them way more then it hurts you to go on living. You can't help anyone if you are dead; it's rather selfish.

Suicide is for assholes or cowards; I award no points, your life is precious, make it worth living.

<comment><USER9> Well, if you're going to be snarky about it, all I'll reply with is the famous Big Lebowski quote: " _Yeah, well, you know, that 's just, like, _your_ opinion, man._"

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Nitschke's other (previous, drug perfusion) death machine was on display in MONA in Hobart. its an otherwise pedestrian installation of a suitcase sized box, and a bag on a stand, next to a chaise longue. I found it very confronting. Normalized but somehow not normal.

He's a polarising figure. Saying something rational, but causing immense community disquiet when people come close to voting. (I believe he has the right of it, but successive State, Territory and Federal governments have shied away from the topic, the impact of the church on Australian polity is pretty big)

<comment><USER12> Dr. Nitschke is from my home town right here. He was so close to getting voluntary euthanasia laws enacted in the Northern Territory, but the government backed out in the end.

I remember watching him demonstrate V1 of his 'machine in a suitcase' that people could use to end their lives. It was controlled by a PC, and the interface that the patient would use to click the confirmation dialogs to begin the last things they would see in the world was written in..... <shudder> ... Microsoft Access.

<comment><USER13> Really old versions of Microsoft Access could use Clippy via VBA:

      Set Clippy = Application.Assistant.NewBalloon
      With Clippy
        .Heading = "Human Deletion"
        .Text = "It looks like you're trying to kill yourself"
        .Icon = msoIconAlertWarning
        .Button = msoButtonSetOK
        .Show
      End With

</comment></comment></comment><comment><USER14> > The front-runner in the one-way journey to Switzerland is a New Zealander > whom Nitschke has known for years. She's not terminally ill, but is becoming > increasingly disabled by macular degeneration – something she finds > intolerable after a lifetime of reading for pleasure.

I am not so sure society is ready to embrace commercial euthanasia for non- fatal, non-painful diseases. Should someone with age related deafness be offered euthanasia because they find not being able to listen to music intolerable. Or how about a former runner with hip and knee problems?

<comment><USER15> Why ought people not be able to request their own euthanasia? It seems like that's the ultimate form of self-determination. (I'm all for _reasonable_ controls around it to ensure that it's a properly considered decision and not done on a whim or in an acute bout of feeling poorly, but I don't think that it needs a societally acceptable explanation, just a consistent, considered choice by the patient.)

<comment><USER16> And from the article: "But I know what I don't want. I don't want to be stuffed full of tubes with doctors hovering over me, pleased with themselves for keeping my heart beating for another five minutes, eking out every last painful second. That, to me, is dystopia."

My feelings exactly.

</comment></comment></comment><comment> S-E-P The ends don't justify the means. Sometimes to live and suffer a fate worse than death is better to die.

Also I hate this idea the they're making death slick.

And the way the article is romanticizing a man who will assist you in, for many; a coward's way out.

This worries me greatly; have we so quickly forgotten the past?

</comment><comment><USER17> Needs to be combined with prompt cooling for cryopreservation.

</comment><comment><USER18> I am 100% for the uber for death. People are suffering due to lack of resources and lack of innovation in medical field. Haven is better than hell on earth.

</comment><comment><USER19> Off topic, but that double exposure feels out of place.

</comment><comment><USER20> I think it is of note that voluntary euthanasia is becoming a more important issue at the present time. Due to various medical advancements and improved analgesia and supportive care, suffering is less now than at any other time in history.

One possibility is the particular life experiences and trajectory of the boomers is driving the phenomenon. Or maybe it is just the growing number of elderly and increasingly infirm.</comment>


Pattern matching in Python - <AUTHOR> http://monkey.org/~marius/pattern-matching-in-python.html

<comment><USER2> While pattern matching is one of my favorite things about OCaml, I'm not sure this fits well in Python. A _big_ part of Python is trying to keep the language from being all things to all people and accumulating esoteric cruft, especially in the syntax. If I ran the zoo, I would have probably chosen a slightly different subset of features for Python, but I have a lot of respect for Guido's intent.

Also, doing anything by overloading arithmetic operators for a semantically unrelated purpose tends to be pretty disharmonious with the rest of the language. The only exception I can think of is Lua's LPEG (<http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html>), but that's a specific sub-language that tends to be clearly isolated to grammars; in practice, it's usually as distinct as using * within regular expression strings.

</comment><comment><USER3> Cool.

I wrote some pattern matching code myself for python a few months back just for fun. It was extremely unpythonic, but a fun exercise. For comparison, here's my code:

<http://github.com/paulgb/python-pattern-matching/tree/master>

</comment><comment><USER4> This adds a neat Prolog-angle to the whole language. Cant wait to see if someone actually makes a complete prolog-module out of this.

<comment><USER2> While I don't have direct experience with either of these (I just googled for "python prolog backtracking"), you could probably do just as well in idiomatic Python using generators:

      * http://codespeak.net/pypy/extradoc/paper/prolog-in-python.pdf
      * http://mail.python.org/pipermail/python-list/2005-October/348485.html

I think Peter Norvig has written about this, too.

</comment></comment><comment><USER5> That is terribly un-Pythonic, and a poor imitation to boot. Neat proof of concept though.</comment>


Sources: Google Is Close to Buying Meebo - <AUTHOR> http://allthingsd.com/20120511/sources-google-is-close-to-buying-meebo

<comment><USER2> Word on the street is that Google is working on a new messaging product, so this isn't altogether surprising. Meebo has an awesome iOS native app and web application, however the Android Meebo client has been abandonware for the longest time (last update November 30, 2009!): [https://play.google.com/store/apps/details?id=com.meebo&...](https://play.google.com/store/apps/details?id=com.meebo&hl=en)

I guess I find the fact that Google would be interested in making that kind of commitment very curious. Meebo has stated a number of times that a revamp of the Android client was imminent after I bugged them about why the Android client gets no attention or updates/bigfixes at all. Getting that to fruition would mean a workable cross platform messaging solution with some real scope.

<comment><USER3> I wonder how this relates to Meebo's pivot toward an information platfrom, versus Meebo Messenger. Surely it can't be worth $100 million to basically get what libpurple offers for free.</comment></comment>


A simple way of defeating the compiler backdoor attack - <AUTHOR> http://imgur.com/a/BWbnU#0

<comment><USER2> So what do you compile TCC with? It's written in C, so it needs a compiler.</comment>


Ask HN: Why are there so few apps being built with JSP? - <AUTHOR> It seems to me that lots of small to medium webapps are built either in php or in ruby on rails. I'm wondering why there seem to be only a small minority of webapps (at least not enterprise ones) being built using JSP technology. Most articles and posts I see on HN seem to be webapps built with other technologies but Java.
JSP web apps can be built quickly as well. Eg. you have the JSTL tag library, and orm frameworks such as MyBatis or Hibernate. And there are also other things for simplifying, decoupling and modularizing a webapp like the Tiles framework, Struts, Spring MVC frameworks etc.
Now, I know for a fact that there are some other advantages php or rails apps have, particularly the lower price of hosting and possibly smaller memory requirements, but I'm wondering if there are any other reasons that JSP/Servlets/Java based small webapps are such a small minority and why adoption seems to be rather low for small to medium web 2.0 apps. <comment><USER2> My opinion. It's partly because teams who do webapps tend to be small, young and agile. First, prejudices: they prefer new things (Java is old); they dislike the environment that is Java's home (big enterprise) and the practices and personalities types that go with it (perfectionistic, professional, conservative).

Second, real reasons: Java is verbose and statically typed, and therefore it takes more work to make changes - it is slower to develop in and less flexible/agile. These things really count when you want to try out an idea; and when you need to adapt it. There's also a community effect, where all those early adopters are working with Ruby/Python, that's the platform cool stuff gets developed for (eg. sinatra, github, haml).

Technically, it's possible to write a sinatra in Java (I have; using annotations for urls); but who would use it? I actually love Java myself, including its static typing, and use it in my startup. But when I've played with Ruby - even as a novice without knowing the tricks - I found it much quicker to develop in, and the code easier to understand because less cluttered. It's probably not as reliable; and the code doesn't run as fast; but these things just don't matter for prototypes and early versions.

<comment><USER3> What sort of easy changes are people making that verbosity and static typing would prevent? I get the heebiejeebies trying to imagine that...

<comment><USER4> Exactly - I often read "easy changes" as "I don't have to think about all the implications of this" which is never good.

Personally I find Java one of the easiest languages to make functionality changes in just because of the excellent refactoring tools that are available. People always claim to feel restricted by the language when they use Java. If they're using emacs or Textmate to edit it then sure, I can see that. Personally, whenever I'm writing something other than Java I feel desperately restricted by the tools - editors that don't have semantic knowledge of the program structure and just treat it all as text seem unbelievably primitive to me now after years of using IntelliJ.

<comment><USER5> Refactoring isn't a functionality change--functionality should stay exactly the same during refactoring; that's why unit testing makes refactoring easier.

 _Functionality_ changes require expressiveness, something Java lacks, due to its superfluous ceremony. Functionality changes require an ability to clearly see where and how things are done, and this is obscured by the extra noise of Java.

Java 5/6 went a fair ways to mitigating this... somewhat. And IDEs can help reduce extraneous noise (like IntelliJ's <~> for generics). But it's not eliminated, and it's not enough.

Java still has an impoverished model of abstraction and OO, it forces me to repeat myself _continually_ (and having an IDE do the grunt work of repetition doesn't help-- _nothing_ should have to do it), and that both slows me down, and obfuscates meaning.

The tooling is the only thing that makes Java even remotely palatable.

</comment></comment></comment></comment><comment><USER6> For me, it's purely emotional.

My last class at Uni 2 years ago was a survey of web dev technologies. We built sites using ASP.NET, Perl, PHP and JSP. Java and asp.net were tied for worst experience ever. Setup and configuration of the Java stack was 2/3rds of the project. And, that's after taking 2 years of Java in school. Setting up a Java stack on a Ubuntu or a Windows box was equally as painful for me at the time.

My experience at school as made me loathe to try anything Java related. And, while I love the idea of the jvm, I have a pretty visceral emotional reaction to anything java related. I know it's wrong, but I can't even bring myself to do the installation required to mess around with Clojure or Scala.

I get the same vibe from a number of young developers I come across at Hackers and Founders SV meetups that have recently graduated from school. Someone mentions Java at our meetups and everyone at the table groans.

Python and Ruby are essentially lingua franca here in Silicon Valley startup culture, with C and C++ mixed in for speed. I've settled on Python/Django for day to day dev work.

In my case, even though Clojure and Scala look really sexy. The thought of installing a jvm based development environment makes me break out into a cold sweat. If I'm going to play around with a "sexy" language to learn stuff I'm going to play with Haskell, Erlang, or O'Caml, just to avoid using the jvm.

<comment><USER7> What's the big deal with setting up a "JVM Environment"? Working with Scala for me involves the latest Scala distro and a copy of VIM. Is there something in particular that makes it so painful that I"m missing?

<comment><USER5> Yes--there's more to setting up a JEE stack then getting a JVM and a language running.

<comment><USER8> I sometimes do "yum install tomcat6; sudo rctomcat6 start; emacs foo.jsp" just to dink around with the odd corners of the servlet API (I'd do it in Eclipse if it weren't such a pig). You can just ignore a lot of the painful ceremony that JEE wants to inflict on you.

<comment><USER5> Sure, if you don't need it. The bulk of my JEE work is somewhat more complex than "dinking around with the odd corners of the servlet API".

</comment></comment></comment></comment></comment><comment><USER9> From what I've seen/heard, I think the lack of cheap hosting was one of the biggest things that kept Java from catching on as a preferred platform for the kinds of webapps that you see people building with PHP and/or RoR. That problem has, IMO, been mitigated somewhat by the emergence of cheap VPS providers... now hosting is hosting, and what you run on your server is entirely up to you. But by the time cheap VPS's became commonplace, it had become "cool" to hate Java. And, to be fair, there is a little more of a learning curve to get started with Java and most of the Java based webapp stacks, compared to, say, RoR or whatever.

Also, to be fair, other platforms have "caught up" to what were some of the early advantages of Java. For example, at one time I would have cited JMS and the easy accessibility of async messaging from Java as a big advantage. But now there are a bazillion messaging systems and most (if not all) of the major ones have easy to use client libraries in Perl, Python, Ruby, etc.

OTOH, Groovy/Grails brings a lot of the advantages of a RoR type framework to a JVM based ecosystem, as does Rails on JRuby, so more and more things are evolving to where the various platforms are approaching parity.

</comment><comment><USER10> I prefer scripting languages over a pure Java stack simply because I can reload the page and see what's happening with the new code. Yes, you can use JRebel, hook up a debugger and tweak settings to get some hot code replacement, but they've always failed me at one point or another, resulting in hours of fun. The compile-check-fix-compile cycle gets under my skin, especially when you're using frameworks and libraries that take a minute to bootstrap.

The JSTL is not a factor in speeding up development. A lot of people even prefer a Velocity or Freemarker template engine when they are using Java. And I've never worked with MyBatis but have done plenty of projects with Hibernate/JPA and let me tell you: I've often come at a point in a project where I was wondering how much time I had saved by not writing the easy SQL queries and how much time I had lost by trying to work around some random restriction in the Hibernate API. For all the "hate" Django's ORM gets, I've never run into the same obstacles.

With all that said, the Play! framework addresses a lot of these issues and is a lot more fun to work with.

<comment><USER11> You can do that with a JSP page, and Tomcat. You can use JSP very much like a scripting language (no need to hit a servlet, controller, etc), but obviously it can get a little messy to manage depending how large of app you write.

<comment><USER12> One big problem; if you keep most of the Java code on the servlet side and you throw an exception, the stack trace will give you the line number of the offending code.

OTOH, if you do all that heavy lifting in the JSP side, depending on your choice of server, you get a stack trace...either without a line number, or with a line number of the JSP which was compiled and turned into a Java program on the fly.

And we all know what machine-generated Java looks like, right? Like a big plate of pain with some extra pain on top. Good luck bug-hunting that one.

<comment><USER13> Not entirely true. On Tomcat 5 and 6, the resulting code is _really_ close to the original, plus lots of out.write().

If the logs show an exception on org.apache.jsp.mypage_jsp._jspService(mypage_jsp.java:NNNN), you can find the generated Java class on TOMCAT_HOME/work/Catalina/localhost/myapp and it's rather straightforward from there.

I do this on a daily basis to maintain a legacy app. Not sexy but, not hard either.

</comment></comment></comment></comment><comment><USER14> The biggest problem with Java webapp development, in my opinion, is its ridiculous obsession with XML. I can't count the number of hours I've wasted debugging obscure errors only to discover that I had a minor syntax error in my XML configuration files. In a framework like Rails, 90% of what I have to specify in those XML config files is assumed by default anyway, and almost all of the rest is done as Ruby code, which means I get actually intelligent errors when something is wrong.

Basically, it seems to me like Java web development uses XML as a dynamic programming language when they're trying to do something Java's not well- suited for. The issue is that XML has absolutely no type-checking at all, and so you end up with errors that make absolutely no sense when the only issues you have are simple typos.

The problem is even worse because you seem to end up having to specify the same information in so many different places, and having mistakes in just one of those will prevent anything from working.

I am sure there are ways around this, but the whole point is that if you're using a framework like Rails, you don't need to deal with _any_ of this. It all just works, and having wasted months of time on Java web dev, I want to deal with a system that _just works_ , not a system that requires ten or twenty kludgey three- and four-letter band-aids to get it to behave intelligently.

<comment><USER15> Try Wicket+Guice - no XML at all.

</comment></comment><comment><USER16> Although I use Rails for most web apps that I do now, there was a period from about 11 years ago to about 5 years ago that JSP was the sweet spot for me. I would put a lot of embedded Java in JSPs, and as an app matured, I migrated the code to custom tag libraries (easy to write once you have everything working in JSPs).

For me part of the lure of JSP apps was that I really liked Tomcat as a development and deployment platform. For apps that needed a lot of background processing, I started work threads in servlet init methods, and liked having everything in one JVM.

I had one app running without restart for several years until my customer's admins let the server run out of free disk space. I am not at all confident of a Rails app running for 3 to 4 years with no restarts.

To answer your question: I might still choose JSP for high volume web apps. For apps with a modest number of users, Rails makes more sense for me.

</comment><comment><USER17> Actually, there are far more apps being built on various Java stacks than the alternatives - it's just that the people using them collect a paycheck and go home at 5 rather than blogging about it. The heavyweight, large business and government market is almost exclusively Java

Also, lots of people judge Java frameworks based on monstrosities like J2EE, Struts or Spring. But there are several very nice, truly lightweight Java frameworks, and even more for alternative JVM languages. The Java stack often _does_ suck, but it doesn't _have_ to suck.

</comment><comment><USER18> I am a Java developer in my day to day work but I'll give a few reasons:

1\. The memory footprint of the JVM is significantly larger for a similar app vs. PHP. Also, it requires a lot of tricky JVM option tweaking to get it to work in anything less than about 512mb.

2\. The build environment is really heavy weight and complicated. Maven seemed crazy at first though working with it for a while finally got me used to it. It's still crazy complicated compared to rails/python.

3\. Lack of code reloading when you hit refresh. JavaRebel fixes this, for a price.

4\. Java code is really verbose. You have to become an expert at a lot of IDE features before you can get decent productivity. You absolutely cannot use a simple text editor or anything less than one of the big 3 IDEs (Eclipse, Net Beans, Intellij) and get anywhere.

The future is bright though for the JVM. I have started to work more with Scala/Lift lately and I am really blown away at how fast and powerful it is compared to traditional Java development.

<comment><USER19> 1\. It depends on your app, you can go ahead fine with 256 megs with no crazy jvm tweaks at all.

2\. It doesn't have to be complicated - it's the developers who make it so.

3\. it depends on your server and configuration. Every server supports class reloading and jsp recompiling.

4\. You don't have to - eclipse and netbeans are free and very powerful. Notepad for simple tweaks if you have to.

</comment></comment><comment><USER20> Just to set up one of the Java frameworks you list is already a lot of work and a lot of wrangling of XML.

Without frameworks, it is probably OK if you already have a working web.xml. I used to just copy my working web.xml and modify it. Good luck if you want to create a working web.xml from scratch, though. The specification for a proper web.xml is a PDF with several 100 pages (last time I looked, a couple of years ago), and to parse it you basically need a scanner for XML specification files in your brain.

That is only for creating the working web.xml. Specifications for JSP and JSTL are several hundred pages on top of that.

<comment><USER21> This is one of the specific reasons the Stripes Framework (<http://stripesframework.org/display/stripes/Home>) was created. The idea behind it is that most Java frameworks require too much configuration and the start-up time (to get rolling with development) isn't short.

Stripes looks to solve both of these problems while making it (actually) fun to do Java development. There's extremely little XML config setup.

There's not a single person I know that's familiar with Struts (1 or 2) and/or Spring MVC (or any other Java framework for that matter) that's tried Stripes, learned it in a day or two, and not really liked it.

Daoud also has a great book, "Stripes: ...and Java Web Development Is Fun Again" that's a great resource for starting out. In addition, the Stripes community is small enough that you can access the code contributors on a daily basis through IRC or the mail lists.

With Stripes-Reload and Stripersist, you can get a CRUD app up and running in under a few minutes--I think that's on par with RoR, isn't it?

IMHO, it's worth looking at.

<comment><USER19> it still needs web.xml, doesn't it?

</comment></comment></comment><comment><USER22> I can't speak for PHP but if you follow the usual Rails conventions for db structure, URL layouts, etc then it takes significantly less time to build (and maintain) a Rails site vs Java EE.

Simply collecting all of your Java libraries, frameworks, dependencies, etc and getting them running in your app server can take days. Minor changes like adding a db column can end up touching nearly every layer.

All these costs do have benefits. Java ORMs generate much more efficient queries than ActiveRecord, have more flexible querying, and better fit into existing schemas; JSP engines can render tens of thousands of pages per second; Java app servers are easily clustered; and much more. But most of that isn't something small or medium web apps use, so why pay the price?

<comment><USER23> It doesn't take me days to get a Java web app up and running. It takes me minutes. In days, my Java web app is done.

I'm a senior engineer who codes for pleasure, so maybe I'm faster than average --- but if it's taking you days to get your libraries together and minor db changes touch every layer, you're doing something wrong.

<comment><USER22> Recently I started working on a new project using Tapestry 5.1 in GlassFish 3. That particular combination requires replacing GF's StAX lib with a different implementation that Tapestry depends on. Then there's the usual issue of reconciling the 2-3 different logging frameworks that various components depend on, writing the (albeit minimal XML descriptors for the app, web app, EJB, configuring resources in the app server admin console, etc.

It's unlikely you can do all that in minutes, so you're probably talking about copying an existing app template.

Adding a db column requires modifying the entity itself, DTOs, form beans, and of course the relevant JSP/templates. With Rails conventions you'd only modify the pages.

<comment><USER23> Do you like Tapestry?

<comment><USER3> For what it's worth I had a nightmare of a time with it. Especially Tapestry 5.0, 5.1. The documentation is atrocious and out of date. Also, it could have been a novice mistake that resulted from days of all nighters in a row, but I had a critical bug that prevented me from delivering that, as a TA later discovered, was resulting from my form validation occurring once for each form element on the page rather than executing once for the entire form.

<comment><USER24> I've just moved over to rails. After 6 years of using poor APIs tapestry 5 was what finally tipped me over the edge. On the project we used it for we would actually allow 2 days to get a tapestry page working correctly. Howard (creator of tapestry) seems to believe that html and http were a mistake and that he's created the event based solution to hide it away. The result, helped along by the lack of docs, is that even with what would have been the simplest of tasks with html and http become an impossible hunt through his dodgy codebase. Far and away the most painful framework I've ever had the misfortune to use. Worst part was that is was me that was seduced by the seeming simplicity of it and chose it in the first place ;)

</comment></comment></comment></comment></comment></comment><comment><USER25> On the low end, I've always thought java has a significant disadvantage: memory footprint. In particular, this is compared to PHP/Perl/RoR/etc.

When you start your java app you pre-allocate all the memory you're going to need for the process' lifetime. This could be 512MB, this could be 2GB+, but it's never small. And this is unaffected by your initial traffic volume. It's the same for 0.001 hits/sec or 5 hits/sec.

On the other hand, if you drop a bunch of PHP scripts on a server, Apache only uses the memory it needs. Sure, you may have some pain scaling it later, but to get up and running you can get a cheap server and run your code.

Also, while I have your attention, have you ever tried installing an enterprise java webapp? It's not like you can pile a bunch of them into one JVM on a machine. I run confluence/jira/bamboo. Each has it's own requirements and basically need to run in their own tomcat servers tuned with their own settings. It's a huge PITA and eats up a ton of memory.

<comment><USER20> Actually I am afraid to host a RoR app on my server, which runs several Java apps. I think the server has only 256MB of RAM (it is old, but cheap), or maybe 512 - not a lot, in any case.

I am much more worried about memory consumption of RoR. Never really launched it in production, but wasn't it the case that you have to load balance between several Mongrels, each consuming > 100MB of RAM?

Java is just unpleasant to use - other than that, it is very fast and memory consumption is ok.

<comment><USER26> heroku.com

<comment><USER20> The "demo" version of heroku has only one process, I think, and 5MB storage. The first professional version is already quite expensive. I pay 10$/month for my server (split with a friend).

I host several projects on that one server (incubation...).

</comment></comment></comment></comment><comment><USER27> From my own experience of working with Java/JSP at work and PHP for side projects (I'm also learning Python), it comes down to developer productivity -- rapid application development, deployment speed and developer experience. For most small- to medium-size projects, you can achieve the same results in Java, PHP, Python, Ruby and even ASP, but the journey towards completion varies greatly across languages and tools.

IMHO deployment on the Java stack is not as fun. Time spent configuring Tomcat, Ant, and compiling code adds-up, especially for a basic web app or prototype. The Java stack also has a larger learning curve for beginners.

However, if you work on "enterprise" applications, especially ERP, finance and banking, Java is currently the lingua franca.

<comment><USER23> A good IDE can help most of the issues you mention. Eclipse is free and you can compile Java web apps in it without Ant. I've worked places whose deployments involved making a WAR file from Eclipse. Configuring Tomcat in Eclipse takes a few clicks to basically just point to where you have your Tomcat directory. Compiling from Eclipse requires you to click a green arrow icon.

</comment></comment><comment><USER28> IMHO the answer is here in this thread... which would you choose?

a) php b) rails c) Java + JSP/Servlets/JSTL/Tiles/Struts/Spring/JSF/Play/Wicket/GWT/Stripes/Tapestry/WebObjects

<comment><USER29> This is not really accurate.

When using java, you will not use JSP, JSTL, JSF, Play, Wicket, STripes, Tapestry, etc, all at the same _time_. Unless you are crazy.

The same way, in Ruby, you will not use ERB, Haml, Erector, Markaby, or the other (at least) 19 template engines out there ([http://www.hokstad.com/mini- reviews-of-19-ruby-template-engi...](http://www.hokstad.com/mini-reviews- of-19-ruby-template-engines.html))

But this comparison is not actually fair, because you mixxed template engines with frameworks. To be fair, you'd have to add Sinatra, Camping, Rails, Merb, Ramaze, Padrino and Hobo to the Ruby list, and CakePhp, Zend and Symfony (at least) to the Php list.

It is not which language has the most options of framework/template engines, but which has the best optins. JSP is one of the worst template engines on Java land, and this is why it is not used as much (well, there is also the fact that it has a very bad reputation, and JSF is considered its successor, but it is worse nonetheless).

<comment><USER19> I upvoted, however the statement "jsp is not used as much" is not true - it is used on 99.9% java web apps out there

</comment></comment></comment><comment><USER30> Try out Google App Engine's Java support and the Eclipse plug-in, and if you're after a Java framework check out GWT.

I love Python and work in it almost entirely now, but previously worked with Java (yes I know the joke about them being the same with the whitespace re- arranged).

GAE gets rid of most of the configuration and scaling pain. Plus it's free to get started. There are some limitations, but essentially it makes deploying Java web apps a snap.

<http://code.google.com/appengine/docs/java/overview.html>

<comment><USER31> GWT is the more heavy weight than JSP. Whole app takes 2 minutes to load in hosted mode. In my opinion if one has to choose Java then my ideal stack is: JSP, Spring, Hibernate, Java.

For personal projects: I am a Grails guy. I love it. Dynamic methods on Model classes, no need of DAO's per say, GSP tags are great.

I have also developed using Python and Django. And loved it. Grails gives me that only in Groovy/Java which is awesome!

My 2 cents.

</comment></comment><comment><USER32> I think Java and its plethora of frameworks makes new developers feel overwhelmed. Python clearly has Django, Ruby clearly has Rails, Java has... what? Struts? Spring? Tiles? Servlets? JSPs? Tag libraries? Where do you start?

To an outsider, it feels like there is a mountain of material to wade through before you can really get going with a Java webapp; for Python and Ruby, the perceived barrier to entry is much lower.

<comment><USER9> > Python clearly has Django,

To be fair, the picture on Python isn't totally clear either. You can choose from Django, Pylons (my preference, btw), Turbogears and possibly others... and you have the choice between SQLAlchemy and the Django ORM, etc. Picking Python definitely does not alleviate the need to make some evaluations and decisions.

</comment></comment><comment><USER33> It takes you 10 periods of time in JSP to do what you can do in PHP in 1 period of time.

<comment><USER19> example of code that takes 10 more lines of code to write in JSP than in PHP, please?

</comment></comment><comment><USER34> You're asking this question on a site that is "startup focused" which means they aren't going to have a team of 20 developers churning out java byte code...they're going to be using more modern, dynamic languages like Python and Ruby because the popular full-stack frameworks that are behind Python and Ruby are better suited to get ideas off the ground as opposed to the monolithic JEE stack.

</comment><comment><USER35> I used to write desktop apps and also do drivers and VxDs for Windows. One of the things I strongly disliked about that work is that you are working in an environment where there is a huge amount of infrastructure that you are intimately dependent upon and that is hidden from you.

Java brings that kind of thing to the server, and I want no part of it.

<comment><USER17> Just to be fair - if this is your criteria, Rails is worse than most Java stacks.

</comment></comment><comment><USER36> Because it is an abomination - it has less power than most of the other template frameworks available for Python and Ruby, and the tag libraries require mountains of XML if you want to write your own.

Now the basic servlet idea is pretty damn nice, and once you have your code written final deployment isn't that bad.

</comment><comment><USER37> -steep learning curve compared to rails, django, grails, etc \- lots of configuration (I mean a lot, no convention over configuration) \- application servers are not easy, tomcat can be a nightmare in term of rapid deployment/undeploy routines, just think about heroku on the other hand

<comment><USER19> grails is java, right? and if we are talking about "jsp" then jsp recompiling is a standard in any server out there

</comment></comment><comment><USER38> One can make a case that when a team of developers uses JSP in the context of the entire Java EE stack, it gets certain advantages that outweigh the overhead of developing and maintaining all of JEE's moving parts. My last experience with JEE was pretty horrific (portlets! Java Faces! madness!), so I am not eager to try this again, but at least an argument can be made in favor of JEE for certain applications.

If you take away the rest of the stack and are just using JSPs... why bother? I have found a certain comfort zone using Django and I'm not going to switch to a different framework or language just because it's _possible_ ; I would want to know why that alternative gives me a _significant advantage_ over what I'm doing now.

</comment><comment><USER39> Actually, you can code very nice lightweight apps using an embedded servlet container like Jetty, a JSP library, and an ORM (MyBatis or Hibernate). Which is kind of like the idea of a microframework.

I've used it for a demo I've made (some NLP stuff in Java that needed a web frontend, but where running it under Tomcat would have been like the tail wagging the dog) and it worked quite well.

I guess that all the people who want a microframework to get small things done efficiently have moved away from Java at this point, appalled by the whole J2EE circus. And once you have something as elaborate as the J2EE stack as it's meant to be, JSPs are not a good fit, because they don't enforce a separation between presentation and business logic.

</comment><comment><USER40> I find javadoc very ugly and annoying to look at. Dumb reason, I know but I can't get past it.

<comment><USER41> To be fair - neither ruby/rdoc and rails api documentation are much if any better in that regard. I like the ruby/rails ecosystem but the javadoc approach was IMHO really OK as well (I don't talk about some of the parts of the standard library / the API itself)

<comment><USER40> I dunno I find rdoc significantly better organized and easier to read.

Maybe it's the lack of a README concept that offers a high level intro to the library.

edit: maybe it's the font too. I have slogged through javadoc a few times when I've had to use java for something, but overall it's fairly high friction / annoying to learn an API via javadoc.

</comment></comment></comment><comment><USER42> Three reasons I can think of, in order of time to get things done:

1\. Availability, ease of use of Java based hosting provider

2\. Time from writing code to live deployments

3\. Lack of agile frameworks like rails, django or any other php framework (hot code reload etc.).

</comment><comment><USER43> I moved all my webapp development from java to python+django. What I observed is: \- I code webapps much faster now \- I produce a lot less lines of codes \- Testing is so much faster due to uncomparable faster deployment time on development server \- Templating engine is more clear \- Configuration is faster, everything in one file, no sucky XMLs! \- Python is easier to read and so fun to code

Ultimately I feel now that moving from PHP to Java was a step backward, and I feel like now I made a big step forward by moving to Django.

</comment><comment><USER11> I know that Fleaflicker which was posted here was a java based app. So they are out there, but I think more of them are from the 2000-2003 time frame. Has anyone here gone from the Java Stack to RoR? What would you recommend to anyone making that transition? I want to make my next project a "learn a new lang" web project. I fairly strong understanding of the Java MVC(Spring, Struts 1), and DB transactional frameworks(Spring JDBC, Hibernate) and wonder what I should be reading for a transition?

</comment><comment><USER44> Here's why (and I'm flammable):

Because it sucks. Seriously. I don't want another bloated framework like tiles, struts or even Spring MVC (and yes, I know it's the 'less bloated' framework).

You know what the best user interface is for Java apps? XML, JSON or Java. You know what the best framework is for a webapp? Me either, but it better fucking be html, css and javascript.

It's not rocket science. For fucks sake if I wanted a framework for my front end I'd use the native language.

</comment><comment><USER45> I can't speak for everyone but the reasoning behind my choice of php is 3 fold 1) Ease of set-up 2) I'm simply more comfortable with php 3) Better online resources / documentation

In the end it came down to picking a language I was comfortable in and could start moving forward the fastest with.

</comment><comment><USER46> If you want to see what Spring MVC brings to the table, checkout the following showcase:

[http://blog.springsource.com/2010/07/22/spring- mvc-3-showcas...](http://blog.springsource.com/2010/07/22/spring- mvc-3-showcase)

</comment><comment><USER47> A few major reasons:

\- The verbosity of Java wears on me very quickly.

\- I can't stand working in an IDE.

\- Documentation is abysmal.

\- I'm not familiar with the ecosystem (so I don't know what to use and when -- What's 'Struts'? What's 'Tiles'?) and there doesn't seem to be a place to learn.

<comment><AUTHOR> \- I can't stand working in an IDE.

Are you saying this because you mostly work with smaller web apps, or other reasons? For larger projects I find IDE's (especially Eclipse for JAVA indispensable).

<comment><USER47> I work mostly on large web apps but that doesn't have much to do with my dislike for IDE's.

The reason I don't like them is that I don't want 90% of what it gives me. My 'IDE' is 1 gvim per project and a terminal app with a couple tabs. I can't think of anything an IDE gives me that I don't a) want or b) already have.

<comment><USER19> That is pure denial, not a very professional approach

</comment></comment></comment></comment><comment><USER48> i do java at work, and ruby/python/php at home. for me, its simple.

java and its frameworks are too bureaucratic. getting things done requires too much. in an enterprise environment with lots of developers, this is good. in an agile, rapid development type of environment with a small handful of people, this is bad.

the closest thing that i've come across that made me want to consider java apps development is grails.

</comment><comment><USER49> My server is in java and I hate jsp's. I prefer rest with json and a thickish client. imho jsps muddy mvc design.

</comment><comment><USER50> Lack of easy and cheap hosting is one big reason for small to medium web apps. That is what i think.

</comment><comment><USER51> It's the competency barrier.

</comment><comment><USER3> I actually have come to enjoy java servers/services this summer at my internship, but there is no way in hell I'll ever do anything with JSP, ever.

<comment><AUTHOR> Could you expand some more? Why do you 'love' JSP so much after your internship?

<comment><USER3> No, I hate JSP. I enjoy writing servers and services in Java. I like the statically typed nature, I like the language constructs and I like the breadth of existing examples.</comment></comment></comment>


Adversarial AI – Robustifying Production AI Models - <AUTHOR> http://adversarial.co/ <comment><AUTHOR> Despite amazing advancements, and proliferation in modern technology, current machine learning models are extremely prone to small, unobservable, malicious attacks.

Adversarial AI will help secure your company's production model, using expertise from the latest in research and industry in adversarial training.

Subscribe / reach out if you're interested :)</comment>


Soluble corn fiber can help young women build bone and older women preserve bone - <AUTHOR> http://www.purdue.edu/newsroom/releases/2016/Q3/soluble-corn-fiber-can-help-young-women-build-bone,-and-older-women-preserve-bone.html <comment><USER2> I don't want to be unnecessarily cynical, but I do notice that this research about corn was funded by a company, Tate & Lyle, which provides corn-based ingredients:

[http://www.tateandlyle.com/ingredientsandservices/pages/rawm...](http://www.tateandlyle.com/ingredientsandservices/pages/rawmaterials.aspx)

Too bad that the researchers couldn't have found more neutral funders.

<comment><USER3> This is the kind of study I would like to see replicated by an independent lab.

</comment></comment><comment><USER4> When it comes down to it, journalists should never write articles about single health studies. In essence, none of them are valuable sources of information for the general public. Without replication and meta-analyses, they really should only get attention from the scientific community.

</comment><comment><USER5> That's pretty funny, I was just this morning looking up Quest bars on Amazon, and the comments were all furious that they had switched the fiber source in them to soluble corn fiber

(ex [https://www.amazon.com/review/R3B99075S9546R/ref=cm_cr_dp_cm...](https://www.amazon.com/review/R3B99075S9546R/ref=cm_cr_dp_cmt?ie=UTF8&ASIN=B014WS4S9E&channel=detail- glance&nodeID=3760901&store=hpc#wasThisHelpful))

Maybe a good change overall, although it clearly wasn't driven by this study.

<comment><USER6> Soluble corn fiber still needs more study, but then again their previous fiber source (isomalto-oligosaccharides) seems like it was worse given what evidence does exist.

</comment></comment><comment><USER7> There was a "what about the men" comment that appears to have disappeared before I could respond to it, but here's some useful info about calcium [https://ods.od.nih.gov/factsheets/Calcium- Consumer/](https://ods.od.nih.gov/factsheets/Calcium-Consumer/) in particular check out those RDAs.

<comment><USER8> Like most RDAs, they are almost comically low. Three cups of milk (one large glass...) would exceed the recommended amount , before eating anything else that might possibly contain calcium.

<comment><USER9> The actual dietary guidelines would fill the need worry leafy green vegetables. Milk is only a decent source because it is fortified.</comment></comment></comment>


Ask HN: Whats your favorite Sci-Fi short story? - <AUTHOR> <comment><USER2> The Last Question - Isaac Asimov

<comment><USER3> That was my first thought, but since you've posted it my runner up is "The Egg":

[http://www.galactanet.com/oneoff/theegg_mod.html](http://www.galactanet.com/oneoff/theegg_mod.html)

</comment></comment><comment> J-dawg They're made out of meat

[http://www.terrybisson.com/page6/page6.html](http://www.terrybisson.com/page6/page6.html)

</comment><comment><USER4> The truth of fact, the truth of feeling by Ted Chiang [https://subterraneanpress.com/magazine/fall_2013/the_truth_o...](https://subterraneanpress.com/magazine/fall_2013/the_truth_of_fact_the_truth_of_feeling_by_ted_chiang)

This story changed the way I saw writing with the way it portrays it as a tool that can be used or misused just like any other.

</comment><comment><USER5> I'm a huge fan of this format for sci-fi, so it's a hard choice. Probably "Goodnight Mr. James" by Clifford Simak.

Honorable mentions to:

"Microcosmic God" and "If all men were brothers would you let one marry your sister?" by Ted Sturgeon

"Bordered in Black" and "Neutron Star" by Larry Niven

"Blood Music" by Greg Bear

"Special Delivery" by George O. Smith

"The Gold at the Starbow's End" by Fredrick Pohl

</comment><comment><USER6> "The Feeling of Power", by Isaac Asimov. In this story, humans have forgotten how to do basic math, except for one man, who regards it as a hobby.

edit: [http://john.regehr.org/reading_list/power.html](http://john.regehr.org/reading_list/power.html)

</comment><comment><USER7> Not my favorite, but an underrated one: The Machine Stops by E. M. Forster.

Forster is better known for writing period romances like A Room with a View. The Machine Stops, written in 1909, deals with issues of isolation and alienation that come with advances in communication technology, and it sort of kind of predicts the internet.

</comment><comment><USER8> The Seventh Voyage from The Star Diaries by Stanislaw Lem [http://english.lem.pl/works/novels/the-star- diaries/154-the-...](http://english.lem.pl/works/novels/the-star- diaries/154-the-seventh-voyage)

</comment><comment><USER9> Fondly Fahrenheit by Alfred Bester: [http://www.editoreric.com/greatlit/books/Fondly- Fahrenheit.h...](http://www.editoreric.com/greatlit/books/Fondly- Fahrenheit.html)

</comment><comment><USER10> Three Worlds Collide - [http://lesswrong.com/lw/y4/three_worlds_collide_08/](http://lesswrong.com/lw/y4/three_worlds_collide_08/)

</comment><comment><AUTHOR> Just came across this nice reddit [https://www.reddit.com/r/shortscifistories/](https://www.reddit.com/r/shortscifistories/)

</comment><comment><USER11> The Crystal Spheres[0] by David Brin

[0][https://en.wikipedia.org/wiki/The_Crystal_Spheres](https://en.wikipedia.org/wiki/The_Crystal_Spheres)

</comment><comment><USER12> 'Understand' \- Ted Chiang (technically a novelette)

</comment><comment><USER13> March Hare Mission by Ford McCormack

</comment><comment><USER14> 'Flowers for Algernon'</comment>


Ask HN: Resource for Mathematics of Finance - <AUTHOR> Hello!
I'm looking for recommendations for a good resource on financial mathematics, maybe from first principles. Ideally, I'd like to understand more complex topics such as Monte Carlo simulations, expected value, Black-Shoales, etc.
My goal is not to be a quant but to be able to speak intelligently about the field. (I don't play baseball but I know what an ERA is, kind of thing).
Any help is appreciated.
Merry Christmas! <comment><USER2> Quantstart has a good list of books on the topic: [https://quantstart.com/articles/Quantitative-Finance- Reading...](https://quantstart.com/articles/Quantitative-Finance-Reading- List/) Similarly, Quantocray maintain a list of recommended books: [https://quantocracy.com/books/financial- math/](https://quantocracy.com/books/financial-math/)

<comment><AUTHOR> Thanks for the reply

</comment></comment><comment><USER3> The book I used in college was "Mathematics for Finance: An Introduction to Financial Engineering" by Marek Capinski and Tomasz Zastawniak.

You can easily find (legal) PDFs of it online.

I should say that a lot of people in my class really didn't like the book. Personally I thought it was fine.

<comment><AUTHOR> Thank you for the reply</comment></comment>


Show HN: VimFeed – collection of Vim-related newsfeeds - <AUTHOR> https://vimfeed.github.io <comment><AUTHOR> OP here.

I welcome feedback of all sorts, but especially suggestions for feeds to include, be they yours or not.

I'll try and swing by throughout the day to address any questions, concerns, and comments, too.</comment>


Google plans to dump CSS regions to make Blink fast - <AUTHOR> http://arstechnica.com/information-technology/2014/01/google-plans-to-dump-adobe-css-tech-to-make-blink-fast-not-rich/

<comment><USER2> This is now the second time I'm aware of Google essentially vetoing a technology in favor of performance (MathML being the first).

Seeing it happen twice now is a little disconcerting. It feels like Google is eschewing a responsibility it has to standards as one of the major browser vendors in favor of its own interests.

If CSS Regions are truly a problematic proposal, it should collectively be addressed now during the draft stage to either improve the standard or decide to abandon them.

</comment><comment><AUTHOR> Interesting move where Google can essentially veto a technology making it impractical to use it.</comment>


Ask HN: Running SAAS Out of the US and VAT Calculation for Clients in EU? - <AUTHOR>

If I have a SAAS product that runs out of the US but I have clients from the EU region, how do you handle VAT and things ? I mean for example, is the SAAS company responsible to charge/report VAT or is it the client that has to do on their end ?<p>Example: If I have a subscription product for $100/month, I charge the flat rate of $100. Do I need to figure out the VAT and then add on top of this $100 or will the client pay the VAT separately to their authorities in their country ? <comment><USER2> Hi codegeek, I'm not giving you any answer because I am neither a lawyer nor an exepert but the following link should give you the information you are looking for:

[http://ec.europa.eu/taxation_customs/taxation/vat/traders/e-...](http://ec.europa.eu/taxation_customs/taxation/vat/traders/e-commerce/article_1610_en.htm)</comment>


List of cryptography resources and links - <AUTHOR> https://github.com/sobolevn/awesome-cryptography
We are creating a list of the best cryptography resources. Join us and help us grow better!
We also have twitter: https://twitter.com/awe_crypto_bot <comment><USER2> [https://github.com/sobolevn/awesome- cryptography](https://github.com/sobolevn/awesome-cryptography) and

[https://twitter.com/awe_crypto_bot](https://twitter.com/awe_crypto_bot)

</comment><comment><USER3> [https://www.crypto101.io/](https://www.crypto101.io/)

<comment><AUTHOR> Already there: [https://github.com/sobolevn/awesome- cryptography#books](https://github.com/sobolevn/awesome-cryptography#books) Thanks for the suggestion.

</comment></comment><comment><USER4> Oooo please add Degree level courses with particular mention of ones that can be done from home.

Will bookmark, thanks for this

<comment><AUTHOR> Will do, thanks! [https://github.com/sobolevn/awesome- cryptography/issues/29](https://github.com/sobolevn/awesome- cryptography/issues/29)</comment></comment>


Ticketmaster schemes with scalpers so you pay more - <AUTHOR> http://www.latimes.com/business/hollywood/la-fi-ct-ticketmaster-scalpers-20180920-story.html <comment><USER2> Discussed at length two days ago:

[https://news.ycombinator.com/item?id=18025209](https://news.ycombinator.com/item?id=18025209)</comment>


Small introduction to tags in Go - <AUTHOR> https://machiel.me/using-tags-in-go/

<comment><USER2> This is what I like about Go. This "small introduction" is basically everything there is to know about struct tags.

Bonus, Gorethink tags [0] and how we use them at Lavaboom [1].

0: [https://github.com/dancannon/gorethink#encodingdecoding- stru...](https://github.com/dancannon/gorethink#encodingdecoding-structs)

1: [https://github.com/lavab/api/tree/master/models](https://github.com/lavab/api/tree/master/models)

</comment><comment><USER3> At GopherCon, Kyle Erf and Sam Helman gave a great talk about struct tags, how some people are currently using them.

SourceGraph did a write up that summarized it very nicely. [https://sourcegraph.com/blog/live/gophercon2015/123669868275](https://sourcegraph.com/blog/live/gophercon2015/123669868275)

<comment><USER4> the official GopherCon videos aren't posted yet, but you can find a recording of this talk here: [https://www.youtube.com/watch?v=JVc- dTyXDAs](https://www.youtube.com/watch?v=JVc-dTyXDAs)

</comment></comment><comment><USER5> Why is this "tag" system considered a good feature? It seems so arbitrary. It's used exclusively for reflective logic which should instead be done at compile-time via a macro system or a system like Template Haskell, which would generate instances like `ToJson`/`FromJson` for a given struct. As the article mentions, Go tags are similar to Java annotations: a mis-feature motivated by the absence of a macro system.

<comment><USER6> You're right that reflection and compile time code generation are somewhat "dual" in the sense that you can often implement a feature using one or the other.

But that doesn't mean everyone should make the same choice. Go doesn't have macros or templates. It would make the language much larger and many Go development tools would have to be modified to deal with the complexity. This is a minimal language tweak that was far easier to implement, and devtools that don't care about tags can ignore them.

</comment></comment><comment><USER7> tags are just strings. there is no spec tag whatsoever or syntax that can be validated at compile time.

A better solution would have been a proper annotation system that is part of the spec.

<comment><USER8> This is the one problem.

Spent a whole day trying to figure out why only the first tag in the struct was 'active':

      Name string `xml:"name", db:"name"`  //<--- XML works, DB doesn't

      Name string `db:"name", xml:"name"`  //<--- DB works, XML doesn't

The answer was, going from memory, I added a comma (,) between the tags. Should have been:

      Name string `xml:"name" db:"name"`

Stupid simple mistake, but _really_ hard to track down. There was no compiler error, the second tag failed silently, and the first tag worked, so it was really hard to find the bad code.

That along with my favorite: quote-wars. Many-a-time did I forget the quotes on the tag itself only to have it fail (without warning again...):

      Name string `xml:name db:"name"` //<--- DB works, XML doesn't

<comment><USER9> The `go vet` tool will find these issues. Not ideal, but it will catch tag strings that compile but incorrectly formatted.

[http://godoc.org/golang.org/x/tools/cmd/vet](http://godoc.org/golang.org/x/tools/cmd/vet)

</comment></comment></comment><comment><USER10> This should be handy for frameworks to do their own logic, but I would get very annoyed if I had to read code that was cluttered with tags.

<comment><USER11> Simplicity and minimalism are core values in Go, both in the language itself and the community and developers that use it, so clutter tends not to be a concern.

That aside, tags are currently in use in several ORM frameworks with a fair amount of success.

</comment></comment><comment><USER12> // VerifyPassword checks if password is valid and upgrades it if its encrypting scheme was outdated // Returns isValid, wasUpdated, error

func (a *Account) VerifyPassword(password string) (bool, bool, error) {

this is why we need sum types people

<comment><USER13> or just named return values

      func (a *Account) VerifyPassword(password string) (isValid, wasUpdated bool, err error) {</comment></comment>


JScrud: CRUD for JavaScript objects - <AUTHOR> https://github.com/mbildner/jscrud

<comment><USER2> Convince me: why do I want this?

<comment><USER3> Looks like it lets you use localStorage/sessionStorage in a useful way. Out of the box they're just key-value stores, but if you use this you could use them as a pseudo-db.

In terms of use cases, I was mocking up an angular app the other day and this would've been quite handy. I guess it's one step simpler than a SQLite DB.</comment></comment>


I cannot consistently write safe C/C++ code - <AUTHOR> http://robert.ocallahan.org/2017/07/confession-of-cc-programmer.html <comment><USER2> The worst thing about these kinds of articles is the troves of junior programmers that never touched systems programming with a stick before but will read this on hackernews today and sit in the office tomorrow lecturing seasoned coders how they´re dumb for not having seen the light and using an unsafe language.

This is how stupid cargo cult gets made, guys. It's easy to repeat some talking points that you found on the rust homepage or another internet forum, but doing that does not make you an enlightened programmer!

Do c/c++ for 10 years, like the author, and then you're qualified to comment about the topic. If you're new to this, try to put your time into actually learning about these topics and not just blindly repeating other peoples opinions. Please don't say things like "c/c++ is unsafe and should not be used" without understanding it first. And try to consider for a moment that a humongous part of the critical software in the world is written in it. It is the industry standard for all things embedded and low level. Consider that maybe the reason for that is not that everybody outside of hacker news is stupid.

The thing is, I'm not even saying the author is wrong (I don't think he is). I'm just saying that circulating these kinds of opinion posts here and then applauding each other for being such brilliant rust fanboys is not helpful.

<comment><USER3> Beginners will feel overconfident and some will even try to teach more experienced coders how to do things "right" regardless of these types of articles. We've all been there and we probably still are in some fashion. I don't see how that diminishes the value of TFA though.

Any kind of guidelines can be "abused" by taking it to the extreme without actually taking the time to consider if it actually makes sense.

Also while I do have significantly more than 10 years of experience in C I think it's silly to say that you can't criticize the language if you can't recite the K&R by heart. You don't need to know all the intricacies of C's aliasing rules to peruse the long list of CVEs caused by faulty memory handling.

The world of computing changed drastically over the past decades, for a given application maybe C or C++ was a great choice in the 90's, doesn't mean there's no better alternative now.

People telling everybody to ditch C like it never existed and rewrite everything in Rust or Go are silly and are probably the junior coders you're talking about who lack real world experience. Doesn't mean that the opposite reaction of "if it ain't completely broke don't fix it" is any more clever.

<comment><USER2> Well, I agree with you on practically everything you said.

Just for the record, I never intended to imply that somebody should not criticize their tools until they fully mastered them and I certainly don't claim to have done so. I just (tried to) say that I don't like it when others recite opinions from some blog post without even a basic understanding of the issues at hand as I find it leads to a very superficial discourse. I also didn't mean to imply that new projects should be done in C/C++ for the sake of historical reasons or something similar.

In fact, I actually recently started working on a new project, written in rust (!) in an industrial setting. Part of the reason for my original comment is that I found there was _a lot_ of cult in content related to rust, in their marketing material and on rust-related posts on HN. While I really like some parts of the language, this aspect of the rust community is really turning me off at the moment and I hope it will get better over time.

<comment><USER4> Let's say you're a fresh grad and looking at options for you future dev career:

Option 1. Spend the next 5 years learning the ins and outs of C++, where it can bite you, where it can go wrong, all the intricate edge cases, etc... and you'll come out a better C++ programmer. Hopefully after 5 years of hard concentration, you may be able to write safe code (I still haven't met a C++ programmer that hasn't been burned by segfaults _in production_ ).

Option 2. Spend a _single_ month learning Rust. Play with it for another month or even two just to be sure. Hopefully after the 3rd month, they'll be 100% certain that their code won't break because of errors that are above their pay grade.

I've done programming for over 12 years. x86 assembly and C for the earlier years. Then I realised that higher level languages gave me the power to code confidently without causing the errors that I was constantly seeing without explanation.

After many years of HLL I wanted to go back down to the metal... after everything that I knew, "C or C++, not even once".

Rust gives me the confidence to "compile once, run safe everywhere".

<comment><USER5> That assumes there will be no errors in the Rust compiler or runtime environment to deal with. If there are then those would definitely be above their pay grade.

<comment><USER4> I'd take a bug within LLVM over my own any day

</comment></comment></comment></comment></comment></comment><comment><USER3> I think this whole "competent coders don't make mistakes" is a testament to the immaturity of the software development world. Real men write in assembly, maybe C if they're a bit tired.

It would be like a construction worker saying "only noobs need a hard hat" or a surgeon refusing to wash their hands because they're careful never to touch anything contaminated. Or maybe simply refusing to wear your seatbelt because you're a good driver.

Guns don't kill people, people do but if your gun has the bad habit of firing randomly when you don't want it to I guess it's fair to blame the gun a little bit as well.

<comment><USER6> > or a surgeon refusing to wash their hands because they're careful never to > touch anything contaminated.

Fun fact, although perhaps this is specifically what you had in mind: This was pretty much the case until Ignaz Semmelweis [1] noticed that washing your hands caused patients to die less frequently. His suggestion was not well- received by the establishment:

> "Some doctors, for instance, were offended at the suggestion that they > should wash their hands, feeling that their social status as gentlemen was > inconsistent with the idea that their hands could be unclean."

I'd apologize for going off on a tangent if it wasn't such an accurate analogy.

[1]: [https://en.wikipedia.org/wiki/Ignaz_Semmelweis](https://en.wikipedia.org/wiki/Ignaz_Semmelweis)

<comment><USER7> I don't think it's inaccurate at all. Software development needs a scientific revolution equivalent to that of medicine, wherein every pattern and practice has to be backed up by evidence from a randomised, controlled trial.

I remember sitting in a "software quality" workshop organised by a coder at an old employer. He was enumerating various patterns and best practices, and yet I realised that nothing he was saying was backed up by any evidence beyond appeals to emotion and anecdotes. If he had been trying to sell me on a new religion or a health product, I would have rejected his arguments out of hand, so why should the standard be lower for software development?

<comment><USER8> > I'd apologize for going off on a tangent if it wasn't such an accurate > analogy.

> I don't think it's inaccurate at all.

 _an_ accurate - not _in_ accurate! :)

</comment></comment></comment></comment><comment><USER9> > I cannot consistently write safe C/C++ code. I'm not ashamed of that; I > don't know anyone else who can.

With respect, two mistaken beliefs:

1: Only a few programmers can write safe code.

2: One will naturally encounter such programmers in the course of a prestigious career working for a high-profile web browser company.

But mediocre programmers consistently write safe C/C++ code, every day. They do it in the context of aviation, automotive, etc. They do it as part of a much larger safety process, that is designed to be robust against faults at all levels, from design through development through manufacturing through end- user servicing. Software development is but one facet, and compliance to MISRA, ISO 26262, etc is only the start.

Get to know them, and see how safe C/C++ code is actually written!

<comment><USER10> That's a different kind of safe than the OP means. You mean "does not crash, produces the right results", he means "can'te be hacked".

A non-networked engine control unit is super hard to hack by simple virtue of being unreachable from the internet. I bet if you run a fuzzer against your perfectly safe aviation code you'd find lots and lots of security issues. But those issues aren't important.

<comment><USER11> > I bet if you run a fuzzer against your perfectly safe aviation code you'd > find lots and lots of security issues. But those issues aren't important.

As long as no one does something silly a decade from now when it comes to the networking on the plane/ship/factory.

<comment><USER12> The "Industrial Internet of Things" is currently a very hot buzzword. I fear the worst.

</comment></comment></comment></comment><comment><USER13> > I cannot consistently write safe C/C++ code. I'm not ashamed of that; I > don't know anyone else who can. I've heard maybe Daniel J. Bernstein can

For anyone that thinks this, you might be interested to find that DJB himself apparently thinks C, or at least the current state of C as implemented by the common compilers, is untenable for important, long lived software.[1] At least, that's how I interpreted his position. He was responded to as you would expect, unfortunately.

Credit where it's due. [2]

1: [https://groups.google.com/forum/#!msg/boring- crypto/48qa1kWi...](https://groups.google.com/forum/#!msg/boring- crypto/48qa1kWignU/o8GGp2K1DAAJ)

2: [https://news.ycombinator.com/item?id=14170585](https://news.ycombinator.com/item?id=14170585)

</comment><comment><USER14> > I cannot consistently write safe C/C++ code.

I'm not sure how to interpret what this means. What do "consistent" and "safe" mean? Is safety about not corrupting program data? Even when dealing with Python arrays, I can end up corrupting my arrays one way or another (off by one, race conditions, etc.). Is "consistent" about going days without a bug? Because I can't do that in _any_ language. If not, what do these mean? It'd be really nice to know what other languages he can write safe code in, so we can have something to compare to.

<comment><USER15> Of course every programming language is not perfect, including its library and related implementations.

In all of them is possible to introduce logical bugs.

The problem with C and its derived languages is that not only one has the logical bugs common to all programming languages, there are the memory corruption and UB introduced bugs to worry about as well.

While one can think as being super competent, make use of all tools to reduce such error cases, there are always situations where such errors get introduced due to fatigue, project pressure, continuous interrupts.

Additionally since most of us don't work alone, the actual code quality is an average of everyone that has ever worked on the code, and not everyone shares the same goals regarding quality of their work.

I share the feeling with the author, always tried to follow C and C++ best practices, when coding in C I adopted or evangelized tooling, safety standards or known books that lead to safer code.

Yet, like everyone else I had my share of memory corruption issues back on my C and C++ days.

One anecdote was trying to find out a memory leak that was bringing down a server in production, with the customer calling technical support every single day.

It took one week to track it down, and it wasn't something I would advise anyone to experiment.

<comment><USER16> The good thing about C is there is an amazing tool support that can make it as safe as any other language. The bad thing about C is that most developers don't know about (or don't use) all the tools.

<comment><USER17> They don't even use their compiler.. case in point: [https://news.ycombinator.com/item?id=14787072](https://news.ycombinator.com/item?id=14787072)

Of course they always just blame the language. Like the language needs to be responsible for the implementation and its proper use.

<comment><USER13> Any tool that requires special knowledge to use safely rather than _defaulting_ to safe operation and requiring special knowledge to use unsafely is poorly designed. If the design specification for that _class_ or tools encourages or requires that, it's a poor specification indeed.

</comment></comment></comment></comment></comment><comment><USER18> I've worked in "IT security" as a C programmer for about 10 years. I both agree and disagree with this article.

A competent C/C++ programmer will have a lot less of problems like buffer overflows and crap like that, I don't think a buffer overflow has been found in any code I've written during my 10 years as a C programmer.

I have still written code that has security issues though, most of them stem from poorly designed code and are not necessarily a language problem.

I'm not claiming to be a super human here, I've had my fair share of gotchas, like off by one errors and issues with pointer arithmetic when refactoring code and so on and we might actually reduce the time needed to verify that C code is safe if we change to another "safer" language, but I'm 100 % sure that you still have the issue with poorly designed code even with a "safe" language. And from my experience it's a lot harder to find those problems, since you need to understand how the code base works and how it fits together to find those issues.

<comment><USER13> This is a rebuttal against "use a safe language and _all_ your security problems go away entirely" but that is not generally the argument being advanced. The argument that is generally advanced is "use a safe language and _some_ of your security problems go away entirely".

Put another way, people are arguing for airbags to become much more common, and your rebuttal is "I've gotten into some accidents, and I've gotten hurt in ways an airbag would not have helped". That's entirely possible, but irrelevant to the argument at hand (unless you also state that you _never_ get into accidents where and airbag would help)..

Edit: Stating your position as a rebuttal may have been overstating it a bit. It's entirely possible you're just attempting to add information to the argument, in which case please read my comment as attempting to do the same.

<comment><USER18> I agree, but I still believe that one issue here is the lack of understanding of what the process around software development should be.

We would get rid of some issues if we used a safer language, but the real issue is that we don't find the issues, the attacker does instead. So people are finding the issues, but why are not the people writing the software finding them?

I believe that you should have a development team that make sure there are no issues to be found, no matter the language you are writing your application in. That means you run the same tests, no matter the language, so in the end it doesn't matter what language you write it in. And you chose a language that fits the problem, you don't make the language fit the problem.

So I think your analogy of an airbag is wrong in some sense. The issue isn't weather we have an airbag or not, the issue is that we don't test if we have an airbag and then go "Whoops, the airbag didn't deploy in the crash and somebody died".

We as programmers like to think of ourselves as engineers, but we don't treat the profession as engineers, we very often deploy code we know are not tested, we might even know it is buggy, you open yourself up to a lot of damage if you do that as a bridge builder (even though it has happened).

I'm tired and this turned into a rant, but I hope that my point comes across.

EDIT: I don't mean that we should write bug free code, I mean that we should strive for code without security issues. It can be done, I work at a place where we have written code for 15 years, not only C code, or more without any remote exploitable holes.

<comment><USER13> > We would get rid of some issues if we used a safer language, but the real > issue is that we don't find the issues, the attacker does instead. So people > are finding the issues, but why are not the people writing the software > finding them?

Attackers aren't finding all the issues. They are finding issues in the small subset of software they actually bother to examine. That programmers aren't finding the issues I think illustrates both the effort it takes to _always_ be correct as well as the different skills that are leveraged differently. It doesn't take a good C systems or application programmer to find a lot of the common C unsafety errors in question. It takes someone that knows the C memory model and has the knowledge of how to leverage that commonly. In some cases it takes someone applying new fuzzing techniques to expose certain edge cases more consistently that prior fuzzers did.

> That means you run the same tests, no matter the language, so in the end it > doesn't matter what language you write it in.

The important point you are assuming is that the language (or _current implementation_ of it) won't change out from under you in a way that makes that assumption invalid. See my other comment in this discussion regarding DJB, and the HN comment I link to for a good discussion about why that's so.

> And you chose a language that fits the problem, you don't make the language > fit the problem.

In what case when you have two languages roughly similar in capability but one allows errors the other doesn't is the one that allows the errors the better fit?

> So I think your analogy of an airbag is wrong in some sense. The issue isn't > weather we have an airbag or not, the issue is that we don't test if we have > an airbag and then go "Whoops, the airbag didn't deploy in the crash and > somebody died".

Then you're misunderstanding my analogy. The car isn't the program written, the car is the compiler. The route driven is the program. You may make an error on the drive, but let's let the car save us in those cases where it's obvious it can and should. Sure, making sure your coworkers check you've secured the pillows to the steering wheel before every trip works, but it should be obvious why that's sub-optimal in multiple dimensions.

> I work at a place where we have written code for 15 years, not only C code, > or more without any remote exploitable holes.

I congratulate you on your diligence (sincerely, it is an accomplishment to get to the level where you feel you can say this), but that's a strong assertion in at least one possible interpretation. Perhaps you meant no remotely exploitable holes _found_? The interesting question that immediately arises from that clarification is whether anyone has seriously looked? Companies that care about this hire pen testers. I hope yours does as well.

</comment></comment></comment></comment><comment><USER19> The more you know an a C++ programmer, the more you're aware of all the things that can bite you and all the things you need to do to make sure you don't get bitten. Writing code within that cognitive envelope is a tax that's often underestimated. After spending some time out of that world, I find it amazingly tedious to get back into it.

If you're not aware of many of the pitfalls, you might not even be aware of the envelope you should be aware of.

</comment><comment><USER20> Yet another subtle pro-Rust rant against C.

Programming is hard, and writing safe code requires knowledge, not just in C, but in every single language. Even in formal-validable languages you can make mistakes: may be you'll not make errors by using sprintf, but can make others because of using a more complex language.

<comment><USER21> Good risk management is about cost vs payoff analysis. To address the risk of car accident, first you stop juggling chainsaws while driving, then you start to wear seatbelts, and then you start thinking about how the remaining inevitable driving mistakes can be mitigated through technology or practices.

<comment><USER9> I guess using C is analogous is juggling chainsaws in your analogy. But is that actually less safe?

Consider a component _actually responsible_ for preventing car accidents, such as the anti-lock brake system. It will consist of input sensors, output signals, and an embedded computer running some code. All of these components have gone through an extensive qualification process. On the software side, the coding standard requires that all loops must be manifestly finite, no `continue`, no recursion, etc. This coding standard is enforced by the compiler, and the compiler itself must be certified, an extensive and difficult process on its own. Redundancy and review is applied at multiple levels, with tons of supporting tooling around requirements tracking and the like.

Do that, and prove it over many years, and you can juggle chainsaws safely - or ride an explosion under your feet across the country.

The key idea here is that things that have been proven safe, are safe. Using something unproven like Rust, it's nuts. Think about how big LLVM alone is! Rust doesn't have any of that, not the tooling, qualification, standards, or track record. It could be done, but you would need to pour tons of resources into it to bring Rust up to the level that C has in this space.

<comment><USER21> This sounds like a very specialized C subset with nonstandad compilers, tooling and highly restricted functionality. Why use C as the starting point for such a language, instead of a hereditarily safer language like Pascal, Ada, etc?

</comment></comment></comment></comment><comment><USER22> I wonder how can anyone even use computers these days, since C and C++ are so unsafe. My OS is written in C and C++, also my browser and my word processor, my shell and most of the applications that I daily use. The firmware in my phone, my set-up box and my car is also written in those two languages. Also all the major web servers are written in those to languages. Maybe Rust programmers are an exception, but I personally spend 99,99% of troubleshooting time (in any language) on fixing logical bugs that I make. It's hard to get excited about a language like Rust, when it seems that it's community is only interested in spreading FUD.

<comment><USER17> "So unsafe."

The thing is, we (C programmers) are a careful bunch and we like to treat everything as a potential security issue. Even if the likelihood of exploitation on a real world system is literally nil. People see these fixes and possibly associated security advisories, and they think it's all exploitable. Then one actually exploitable bug from some 15-year-old code gets publicized and the publicity spreads everywhere. Look, another exploitable bug! C is sooo friggin bad and every line is an RCE waiting to happen!

I think the safety issue is blown way out of proportion because of that.

It doesn't help that when people discuss UB, they assume the most adversarial compiler possible that literally does all it can to turn the UB into a big problem. And that literally everyone has to be using that compiler and that they may not use the compiler flags that turn off the bad behavior.

</comment></comment><comment><USER23> How about you start writing C++ and not C/C++ code?

The two languages are so different, it isn't fair to mention them as if they were the same.

<comment><USER24> The author worked on Firefox, a largely C++ codebase, so he _was_ writing C++.

I assume he feels that the problems he talks of are common to both languages, if different in magnitude.

</comment></comment><comment><USER25> I'd be interested in trying an online coding exercise like the one he mentioned. I've definitely fallen into the trap of thinking that my code was robust because it worked for my specific use case (and no one tried to break it). Now I feel much more skeptical that my code works at all.

</comment><comment><USER26> Safety, speed, language convenience.

Pick 2.

Safety is an issue everywhere you are programming something, good programmers just know how to mitigate it.

And to be really honest, you don't always need to use C++. Just use it where performance is needed, write good code, review it, etc, and when you need to go at a higher level, use python or any other scripting languages. C++ should be used to write libraries.

There are not so many softwares in the world that need to be entirely written in C++, and if they do, more time is spent writing and fixing such software.

"There are languages people complain about, and languages nobody use".

I don't dislike rust, but when I read its syntax, it doesn't seem simple enough to learn, read and write, the learning curve seems pretty steep, so it won't really do well with students.

</comment><comment><USER27> Isn't this the same as saying you can't consistently write bug-free code?

And isn't this sort of the holy grail of CS?

<comment><USER13> You are conflating "safe" with "bug-free", when safety has a specific meaning in this context, which is memory model safety. Safe code eliminates a _class_ of errors, and thus reduces the _possible_ bugs your program may exhibit.

At this point we can eliminate certain classes of bugs, and sometimes with no runtime cost. The usual example used is Rust, where extra information supplied in the source is used to ensure certain bugs are not possible at compile time. It requires some extra work, but I think likely quite a bit less than the more extreme coding standards used to produce safe C code, but those may cover a different or larger subset of bugs.

</comment></comment><comment><USER28> I really wish we would disconnect C and C++. They're different langauges used entirely differently by different people, and C++ gives C a bad rep.

<comment><USER29> C is more than capable of getting a bad rep on its own.

</comment></comment><comment><USER30> I don't know what the Dunning-Kruger effect is, but I can tell you for a fact I'm too smart for it to affect me.

</comment><comment><USER31> Nice post. There are still to many C/C++ wannabes who think C is an awesome language and their are awesome hardcore programmers. If they are challenged to code something, it's highly probable that flaws will come up.

<comment><USER32> _There are still to many C /C++ wannabes_

There are still too many people using the term C/C++ :] It never really was a thing, even in the beginning (I mean, just take e.g. destruction at scope exit: that alone makes it a very different language) and now even less with the new standards.

Anyway: a language can be considered awesome by people, despite it's flaws. Always has been, never will change, as there will probably never be languages without any flaws. (e.g. I think Python is awesome, others don't ever cease summing up it's flaws, I couldn't care less as it gets stuff done in particular situations). Just like it's inevitable every single programmer, including you, writes flawed code from time to time, challenged or not.

<comment><USER31> > as there will probably never be languages without any flaws

Yes, but we can try to develop better language. Rust is such a try. And that's good.

> Sure, but I don't belong to that fraction of programmers who think they > write flawless code or develop a cult with old, error prone languages such > as C.

The important thing is that we are not discussing about programmers making mistakes, but about a language which is old and which is making mistakes easy. C proofed in sufficient cases that it belongs to the museum.

<comment><USER32> _it belongs to the museum_

I agree that in C it's _way_ easier to make mistakes than in e.g. Rust, but I don't agree that (or whatever other reason) is proof that it belongs in a museum. Take microPython for instance: it's a relatively young project written in C, it allows running a pretty complete Python 3 implementation on a variety of microprocessors as well as on PC/mac/... Suppose we put C in a museum, what do we use instead to achieve the same functionality?

</comment></comment></comment></comment><comment><USER33> It makes me smile when someone starts off a complaint with something similar to "I've been programing in C++ for x decades. I have y qualifications that should impress you. I worked at z company which should impress you further. Yet, despite this, I cannot write safe C++ code".

The author's post, in particular, is excellent as it follows this token introduction with "I don't know anyone else who can write safe C++ code, either". This is further strengthened by "people I know to be skilled programmers (based on what, I don't know), have never professed that they can write safe C++ code, and therefore people who do, are obviously suffering from some psychological effect".

I mean, really? You can't do it, and your friends can't do it, so no one can do it? Even though there is a world of software out there that does exactly what you say can't be done? And further, anyone who says they can do it must be less-skilled and suffering for a form of illusory superiority complex? Get over yourself.

How ironic that he knows about the Dunning-Kruger effect, but fails to apply it to himself.

<comment><USER34> > Get over yourself

The guy is simply describing his personal experience. Why don't you describe your own personal experience instead of attacking him?</comment></comment>