Immutable Data Collections for Javascript - <AUTHOR> https://github.com/facebook/immutable-js <comment><USER2> Hey, I'm the author of this library. It's definitely inspired by mori (and clojure and Haskell) and the reason I ended up building something different was to present a more JavaScript friendly API (and academically, to learn about HAMT). I've built this over the last couple weeks, and we are not using it internally yet - but I wanted to ensure development of it happened in public.

<comment><USER3> A question: how influential has Swanodette's work with ClojureScript/Om in relation to React been to the direction that you (yourself and Facebook) are taking the evolution of React and its supporting libraries in?

From what I've seen, I'm guessing: quite a bit, but I'm not sure that I've noticed it being mentioned. In particular, I'm guessing that the performance characteristics of Om might be especially inspiring.

Edit: Oh, and good work on the library! It's great to see efforts to make the case of immutability within the world of JS.

<comment><USER4> I contribute to React. I'm definitely a big fan of ClojureScript and I borrow ideas from it when I can. I currently have a few crazy ideas that are direct results of looking into the Clojure (or Haskell) ecosystem and finding that they've solved my problems, but better. In general, some of the problems we face, at language/library/ecosystem level, might simply not exist in these languages. It's a shame they're not more popular.

Regarding popularity, I feel that sometimes the web development community can be ironically dogmatic, considering that it's a free and open platform (see: HN/Reddit's initial reaction to React). Looking back, I still find it incredible that React actually gained so much traction when it defies so many of the pre-established "best practices". I think lots of people, including me, are learning more and more to take a step back before dismissing an idea.

So if you were one of those that dismissed Clojure/ClojureScript because "parentheses in front of my function call?", "snake case isn't for me", or "it's too different from idiomatic js" (I hope this one isn't too much of a strawman here), then I urge you to give it another try. Learning React doesn't have to be the only time you open your mind to new ideas and reconsider best practices.

<comment><USER5> Would you mind espousing a bit on what problems we currently face that might not exist in functional languages like Clojure/Haskell?

Also, I just started getting into ClojureScript in order to learn Om. I would love to know your thoughts on why it's worth it to learn Clojure/Haskell.

<comment><USER4> I don't want to go further into a language/library/ecosystem war here. Glad to talk more about it on #reactjs though =).

</comment></comment></comment></comment></comment><comment><USER6> There is also Mori[1], a JavaScript API for using ClojureScript's persistent data structures:

      [1] http://swannodette.github.io/mori/

<comment><USER7> Mori also provides clojure like functionality for the new collections greatly simplifying how you would use them - if you don't use Clojure you might think of the additional functions as an underscore for immutable collections.

I don't see a reason to use any other immutable js lib when Mori exists.

<comment><USER8> Mori's a bit impractical for use in the browser due to its size.

<comment><USER9> I'm not seeing how a 32 KB download is impractical in browser use do to size (assuming the above statement about 32KB is true). Is there something else to it?

<comment><USER8> I didn't see any such statement above. From 176K to 37K (that's what I got on my console anyway) is impressive.

</comment></comment></comment></comment></comment><comment><USER10> Bit confused (ignorant actually) here. Can someone give a 'real world' example of the benefits of immutabile objects in js?

<comment><USER11> The first time I understood why immutable objects are important was in this podcast with ClojureScript and Mori author David Nolan: [http://podcasts.thoughtbot.com/giantrobots/93](http://podcasts.thoughtbot.com/giantrobots/93)

What I thought was the key point was this:

Let's say you have a regular JS array. There is a reference to it in memory and it has a certain value. Now you change an element in that array. You've just mutated it. In JS, the reference in memory doesn't change, but now the value of what it's pointing to has. So in order to know if the value has changed, you need to do a comparison on every element on that array, which is expensive.

Now let's say you have a immutable array (such as from the Immutable FB library or Mori). If you change an element in that array, you get a new array and a new array reference in memory. In other words, if you check that the reference in memory is the same, you are guaranteed that the value is the same (in this case, the array). So checking for equality is fast and cheap because you are only checking the reference, not each value in the array.

One way this is important in React is that now if your component state (or entire app state) is represented by an immutable data structure, you can just check for reference equality in the shouldComponentUpdate() method when deciding to re-render that component. If the reference is equal, you are guaranteed that the data backing that component hasn't changed and you can return false, telling React not to re-render.

What's surprising is that people have made these data structures also very memory efficient. You can see David Nolan talking about how they work and memory comparisons here: [https://www.youtube.com/watch?v=mS264h8KGwk](https://www.youtube.com/watch?v=mS264h8KGwk)

<comment><USER12> Note that you can have cheap equality detection by using e.g. flags or revision counters and so on (but there are limits due to JavaScript's nature..). The problem is that JavaScript currently doesn't support this properly out of the box, but Object.observe is coming in the next standard.

I personally like the safety benefits of immutability. You can give objects to functions and not worry about the functions changing the object. The only way to guarantee that otherwise is to clone the object, but that takes quite a bit of performance.

<comment><USER13> Isn't this library probably cloning?

<comment><USER14> If you watch the linked video above you will see how clever persistent data structures mean that nothing is ever cloned or copied.

<comment><USER15> Good to know. I never got into immutable collections because I presumed they would result in things being allocated all the time (and that that would be expensive).

</comment></comment></comment></comment></comment></comment><comment><USER16> The original npm package "immutable" was [https://github.com/hughfdjackson/immutable](https://github.com/hughfdjackson/immutable) (npm install email@example.com)

Did Facebook buy the npm name from hughfdjackson, did he give it to them, or did NPM switch ownership?

<comment><USER17> There's an acknowledgement in the README.

[https://github.com/facebook/immutable- js/blob/fdc4005fe30286...](https://github.com/facebook/immutable- js/blob/fdc4005fe302866626ab94e060bc06b8381a94be/README.md)

</comment></comment><comment><USER18> Sounds like more of the pieces of React/Flux are being opensourced. :-)

Interesting to see references to TypeScript. Is it prevalent at FB?

<comment><USER19> This isn't used internally by Facebook at this point. The author mentioned this after your post. [https://news.ycombinator.com/item?id=8108741](https://news.ycombinator.com/item?id=8108741)

<comment><USER18> Thanks!

But even if it is not being used yet - do we know if Facebook uses Typescript (or some extension of it)?

</comment></comment></comment><comment><USER20> If anyone is interested in functional collections for Common Lisp or Java, have a look at FSet: [http://www.ergy.com/FSet.html](http://www.ergy.com/FSet.html)

</comment><comment><USER21> So you can use the Clojurescript/Om/Reagent/React model without Clojurescript, nice for people who don't want or can't jump into Clojurescript right now.

</comment><comment><USER22> I wish the README would tell us a little bit more about how to use it in conjunction with React. Especially the logic for shouldComponentUpdate() would be interesting.

<comment><USER23> From my understanding, it makes shouldComponentUpdate() very simple:

return nextProps.value !== this.props.value;

If the object is different, it has changed.

<comment><USER22> Yes, that's how for I've got, too. But then you have a problem if your React component has multiple attributes. Suddenly your check beckomes much larger:

      return (nextProps.attr1 !== this.props.attr1 ||
              nextProps.attr2 !== this.props.attr2 ||
              nextProps.attr3 !== this.props.attr3 ||
              nextProps.attr4 !== this.props.attr4);

Which would result in a lot of boilerplate code if you had to do this for every single attribute in every component in your application. It would be much simpler to just do this check:

      return nextProps !== this.props;

But that's impossible if you're using JSX, because the JSX compiler automatically inserts a normal JavaScript object into your code, instead of an immutable object from this library.

So from my point of view this immutable-js library and JSX seem incompatible, which is kind of weird since Facebook apparently uses JSX internally for their React code.

<comment><USER24> PureRenderMixin[1] is doing this without having you to enumerate all the props

[1] [http://facebook.github.io/react/docs/pure-render- mixin.html](http://facebook.github.io/react/docs/pure-render-mixin.html)

</comment></comment></comment></comment><comment><USER25> I don't understand this whole immutable thing... Why not just avoid changing the data once created? Why do you need a library?

<comment><USER26> Not good enough. When the time comes that you do need to add something, then what? Clone it? In languages that allow you to freeze a collection, adding something to a frozen collection is often a O(n) operation. Most of the collections in this library provide operations that grow collections in (almost) constant time.

<comment><USER25> > Clone it?

Yes, isn't that enough?

<comment><USER27> Let's say you want to create a set by recursing along a million long sequence, collecting the unique values. This would be done with an operation called `reduce`.

The time and storage complexity of that would be exponential if each step you had to clone a copy of the output list. With a persistent data structure, as much of the structure as possible is re-used.

And a list is the simplest possible structure. What about a tree?

Using `reduce` is, I would say, in the top 5 techniques used in functional programming. And it would be severely hobbled without efficient persistent immutable structures.

</comment></comment></comment></comment><comment><USER28> I have to admit, I find it odd that we name immutable data structures based on what they don't do instead of what they do.

Of course, what they do is _efficient persistence_. You want a snapshot of the data? You want a non-volatile reference? You've already got one! _That 's_ the feature. They should be called persistent data structures.

<comment><USER29> You can have an efficiently persistent data structure that isn't immutable.

For example, a rope that reorganizes internal nodes to maximize structure sharing.

</comment></comment><comment><USER30> React's documentation also discuss their immutability helpers [1]. This new library looks like a better way of implementing this though. Will the documentation be amended to discuss use of immutable-js?

[1] [http://facebook.github.io/react/docs/update.html](http://facebook.github.io/react/docs/update.html)

<comment><USER24> React immutability helpers pros:

\- Work on regular JavaScript Object and Array so it's easy to get started and integrate to your app

\- You don't need to wrap objects inside of Immutable to use it and you can use `obj.key` and `arr[0]` syntax for accessing them instead of `obj.get('key')` and `arr.get(0)`

cons:

\- There are no safe-guards if you mutate the objects and it'll likely break your app in subtle ways. This kind of discipline is very hard to get in big projects

\- You are stuck with primitive data structures (instead of map hash trie), so it's not going to be as performant and memory efficient.

</comment></comment><comment><USER31> Also relevant (and not included in this collection) is the following functional red-black tree implementation:

[https://github.com/mikolalysenko/functional-red-black- tree](https://github.com/mikolalysenko/functional-red-black-tree)

</comment><comment><USER32> Can someone give me a good example of where immutable data structures are better than mutable ones. I know that you are more likely to mess up and have side effects with mutable data structures, but so far all I have heard is theory.

<comment><USER33> The big win is they enable lazy evaluation: you can defer the evaluation of an expression until it's needed, or discard the result and compute it again later, or cache the result of an expression and not need to re-evaluate, a flexibility which can be useful in many situations.

You also get undo/redo stacks basically for free, since you simply maintain references to the previous n immutable states.

As Om demonstrates, they also make possible significant optimizations of code that takes various view of the same underlying data, like rendering routines.

</comment></comment><comment><USER34> What's the use of immutable data collections if you have to constantly revert to mutable arrays to render anything? Any gain from the persistent collection is lost in wasteful Array creating (Poor gc)

</comment><comment><USER12> Hmm, it seems to be written in TypeScript, but the source is only provided in JavaScript.

<comment><USER2> I actually started by writing it in TS and later moved to just a TS declaration file and a raw JS source. This means it can be used smoothly in both environments (similar to using a definitelytyped resource).

<comment><USER35> What made you go back to plain javascript?</comment></comment></comment>


Ask HN: Security audits. Worth it? Who's good? - <AUTHOR> Hi all,
I'm beginning a project which will create a web based software as a service.  I've little experience in web security and I'm considering budgeting for a web security audit to find security issues in the finished product.  The product itself doesn't need to handle payments or store personal information, although we will need to have account control and accept subscription payments somehow.
Those who have some experience here: is getting a security audit worth it in this case?  And is there anyone you'd recommend for this?
Thanks. <comment><USER2> If you want something good, it might be a good idea to not choose someone "your investor knows" and would like you to work with, unless those security people are well known. Investors potentially have other investments going on, which you might not know about.

</comment><comment><USER3> I am not a security expert but I always start with OWASP Top 10 for bare minimum:

[https://owasp.org/www-project-top-ten/](https://owasp.org/www-project-top- ten/)

Go through each item and test your application for vulnerabilities against those.

<comment><AUTHOR> Thanks, this looks like a good place to start.

</comment></comment><comment><USER4> Yes, generally a security audit is worth it. I am bias as I am a security engineer and have pentested multiple companies during my career.

Theres a cost saving by designing things up front say for GDPR or handling credit cards safely that is worth investing in. Sometimes, a threat modeling session alone could save you time and money in the long term. It's harder to change things when you've built a product, have customers relying on it.

In terms of the actual product, you will have users, they will need to login/logout/reset passwords. Ensure proper authorization and authentication.

How are you handling logs, secrets, 3PP. Do you handle customer input, do you reflect it onto the page, store it in the database? Do you allow them to do HTTP requests? How do you prevent SSRF.

How are you protecting your code? Laptops? Do you have antivirus? Do you patch your infra?

These are the questions you don't really think about, however they can have real consequences if you don't.

In terms of who I'd recommend, you get what you pay for. Generally, I'd look for a small shop in your local area and vet them.

Yearly pentests are a +, and if you do go through an Acquisition or someone trying to whitelabel your product they will want the reports.

If you don't have any revenue yet, do check out OWASP top 10. Run scoutsuite on your AWS/Azure/GCP. Enforce MFA where you can, Github/AWS/Gdrive/O365. Setup SSO right away and just use that to login to all your infra and services. Will save you so much headache down the line. Make sure you keep your logs application and service logs. Try to aggregate them somewhere.

<comment><USER5> This, all this ^ (seriously)

I'm an Application Security Champion so I know what I'm talking about (sarcasm).

<comment><USER5> Whys this downvoted? I am seconding this information. Is it my self- deprecating comment about being an ASC?

</comment></comment></comment><comment><USER6> we just went through one and it was one of the security as a service. It was around $18k.

So expect to pay around that and a lot more for how in depth you want them to go.

<comment><AUTHOR> Youch, that's out of our price range for sure. Was that an upfront advertised cost or did you end up getting strung along to it?

<comment><USER7> Not OP, in general you need to count a minimum of 1K USD per manday unless you go with automated services which might or might not actually give you what you need.

</comment></comment></comment><comment><USER8> Another option you can look at are bug bounty programs such as bugcrowd or hackerone.</comment>


1985 Version of Biff Tannen in 'Back to the Future Part II' Based on D. Trump - <AUTHOR> https://www.slashfilm.com/in-back-to-the-future-part-ii-biff-tannen-is-donald-trump/ <comment><AUTHOR> This aged badly:

However, no matter how anyone hates Trump opening his mouth in the political arena and getting any traction as a real presidential candidate, the comparison feels a little harsh. After all, while Trump may be arrogant and insulting about a lot of things, it would take a lot for him to turn the United States into a dystopian wasteland like alternate 1985 Hill Valley.</comment>


Is It Time for Swift? - <AUTHOR> https://realm.io/news/ben-sandofsky-time-for-swift/ <comment><USER2> Pretty happy the Firefox for iOS team made the decision to go fully Swift about 14 months ago :-) Almost 60,000 lines later, no regrets. It is awesome.

<comment> shawn-butler > git clone [https://github.com/mozilla/firefox- > ios.git](https://github.com/mozilla/firefox-ios.git) FireFox-ios

> cloc FireFox-ios/

1068 text files. 928 unique files. 303 files ignored.

C 1 files 10606 blank 51150 comment 94618 code

Swift 332 files 9660 blank 5808 comment 43474 code

EDIT: I give up trying to format the output correctly

<comment><USER3> The single .c file, I'm guessing is: [https://github.com/mozilla/firefox- ios/blob/master/ThirdPart...](https://github.com/mozilla/firefox- ios/blob/master/ThirdParty/sqlcipher/sqlite3.c)

It appears to be the source for sqlite3, all concatenated together, which is why it's absurdly long.

And it's third party, so its not really their code, but of course the tooling can't tell that.

<comment><USER4> I haven't checked, but chances are it is the SQLite amalgamation or a tweaked version of it. [https://www.sqlite.org/amalgamation.html](https://www.sqlite.org/amalgamation.html):

 _" The standard makefiles for SQLite have a target for building an object we call the "amalgamation". The amalgamation is a single C code file, named "sqlite3.c", that contains all C code for the core SQLite library and the FTS3, FTS5, RTREE, DBSTAT, JSON1, and RBU extensions. This file contains about 184K lines of code (113K if you omit blank lines and comments) and is over 6.4 megabytes in size"_.

</comment></comment></comment></comment><comment><USER5> I knew there was some churn in the Swift language but didn't think it was going to continue. I'm not using Swift now but will likely hold off a bit longer as a result. I did think they nailed the open source launch. Swift on the server is an exciting prospect, more competition is always good. While I'm not a Swift dev yet (I don't have a Mac thus mainly interested in the libre crossplatform launch), I've been keeping my eye on it with Swift Weekly.

I think 2016-2017 could well be the year(s) of Swift's ascension.

<comment><USER6> Have been using Swift since late 2014 (having used ObjC for many years prior to that).

Even with the occasional churn (eg move to 2.0 or 2.1), the sheer gain in productivity due to brevity, type checking, cleaner closures, and various other language features, easily outweighs any costs. I find myself being able to do more with less code, and cleaner code. It's cognitively way easier to build bigger abstractions.

We do have a few legacy bits that makes no business reason to port at this point, but Swift-to-legacy interop works well, too.

I would say the biggest step that made things usable was introduction of incremental builds in 1.2.

<comment><USER7> > the sheer gain in productivity due to brevity, type checking, cleaner > closures, and various other language features, easily outweighs any costs.

Serious question: do you have a metric you are using to measure that, or is it just kind of a "gut feeling?"

</comment></comment></comment><comment><USER8> Swift is a neat language but unfortunately doesn't fix the extremely verbose and archaic-feeling NextStep libraries that make Objective-C a pain to read or write:

let bar = foo.stringByReplacingOccurrencesOfString(" ", withString: "", options: .LiteralSearch, range: nil)

Compare to any other language, say Python:

bar = foo.replace(" ", "")

<comment><USER9> I know exactly what the first one does, without knowledge of the underlying API. I have no idea what the second one does. Does it replace occurrences of the first parameter with the second one, or vice versa? I assume it returns a copy of the string? What do I need to do to perform a case insensitive search? etc.

<comment><USER10> Do you also pronounce every abbreviation? Do you say "International Business Machines" instead of "IBM"? How about "Répondez s'il vous plaît" vs "RSVP". "As soon as possible" or "ASAP". Ever use a contraction? How about a keyboard shortcut?

I certainly agree it's potentially more readable at first. I'm not yet convinced, without actual data, that anyone, given a month or so experience with a given and common API wouldn't be more productive with shorter names up to a point. I would be good to get that data. Maybe I'd be better off with

        a = Math.numberFromAddtionOf2Numbers(c, d)
        e = Math.numberFromDivisionOf2Numbers(numerator: b, denominator, c);

vs

        a = c + b;
        e = b / c;

which is best

        s = str.stringByReplacingOccurrencesOfString(" ", withString: "", options: .LiteralSearch, range: nil)
        s = str.replace(" ", "");
        s = str.r(" ", "");

<comment><USER11> I'd do

        s = str.replacing(" ", with: " ")

which seems to go along well with the "sorted" and "appending" mentioned in the new API design guidelines:

[https://swift.org/documentation/api-design-guidelines/#be- gr...](https://swift.org/documentation/api-design-guidelines/#be-grammatical)

This is a bit more verbose if you need to chain a lot of replacements... but chances are you shouldn't be doing that in the first place! Instead there should be a version that takes a dictionary, like

        str.replacing(["<": "<", "&": "&"])

This is better because most of the time you don't actually want characters produced by earlier replacements to match later ones, and it can be faster for large strings.

</comment></comment></comment></comment><comment><USER12> How many iOS Objective C books have been written in the past 18 months? I count at least 3 dozen Swift books:

[http://www.h4labs.com/dev/ios/books](http://www.h4labs.com/dev/ios/books)

At some point soon if you want to find recent examples for iOS 8 and 9, they'll all be in Swift. iOS 10 will be announced in 4 months. Books, blogs, and perhaps all of Apple's examples, will be in Swift.

<comment><USER13> Sadly though, a lot of the books either are or will be out of date as more updates come to Swift and break existing code.

I've been working on and off with Swift since the beginning, it has a lot of great characteristics, but updates breaking code isn't something most developers have time to worry about.

<comment><USER14> It's tough. I had a book out in 2014 and it's just been re-released as a second edition in 2016 (Swift Essentials) with fixes for all the changes introduced since the initial release. And you can't run the fix-its on a book :-)

One thing that has helped with the new openness of Swift's evolution is that I included several upcoming warnings, such as the demise of the ++ and -- operators and the 'standard' for loop.

There will have to be a phase change in the future when Swift moves from a "move fast and break things" to a "stable evolution". It has been suggested that this will begin with Swift 3 (when a stable ABI is introduced) but I suspect it will be Swift 4 or 5 when stability is really nailed down.

</comment></comment></comment><comment><USER15> I'm not an iOS developer but for the native modules that I developed for Cordova or React Native, Swift is definitely a much better and cleaner language to develop it.

</comment><comment><USER16> One of the most compelling reasons to start using Swift is to make your project more attractive to job applicants.

</comment><comment><USER17> Something to think about from end user Joe, here: A quick search seemed to indicate that Swift support (officially) began in iOS 7. Great, that's the version I'm on. If anything coming down the pipe for Swift depends on a later version, I'm not on board. I'm not going anywhere. A lot of users, myself included, have been burned when a version upgrade runs like a dog on old hardware...but unfortunately, I'm not going to spring for a new iPad every year, much to the chagrin of Apple. It'd be interesting to see how App Store success correlates with how many versions you can support.

<comment><USER18> Apple already thought of this and tbe Swift runtime + libraries are embedded inside every app that uses Swift. No worries :).

<comment><USER17> No worries, indeed. Good to know!

</comment></comment></comment><comment><USER19> It will be time for Swift when they stop making backwards-incompatible changes to the syntax and I can be sure my code from today will still compile tomorrow when I download the latest version of Xcode.

<comment><USER20> The alternative is to either stifle improvements, or to bloat the language. And we all know what that looks like _looks at C++_

I personally am happy they're making backwards-incompatible changes, and I hope they always continue doing that. I'm happy to maintain my software in return of working with an elegant, cutting-edge, small, logical language.

<comment><USER21> You don't need breaking changes to get many benefits of a language like swift - for example rust has had very little breakage since hitting 1.0.

<comment><USER22> Thanks for bringing rust into the discussion - they handle language standardization/evolution very effectively, in my opinion. "Experimental" features _are_ added to the language, but they are all effectively #define- gated for at least one release before being concretized (it's done more pragmatically than a literal #define of course, given that rust doesn't have any concept of #defines).

This makes sense in my opinion because it gives an opportunity to evaluate proposed language changes under real-world use-cases before making it official, and people must _explicitly_ opt into the possibility of their code not working with future releases, thus fully knowing and accepting the risks.

</comment></comment></comment></comment><comment><USER23> Why is he talking as though using objects is out, and using value types is the only valid path with Swift?

Especially during a transition phase, which we are inescapably in right now, wouldn't it be pragmatic to continue using objects when needed, even if the eventual goal is to end up transitioning to protocol oriented programming?

In other words we don't need to conflate Swift with POP, which I think is what he's doing when he talks about the purported problems of NSNotificationCenter.

</comment><comment><USER24> I'm so desperate to find a good programming environment on the server side, that i thought this talk was about using swift for the server side...

<comment><USER25> Kotlin looks somewhat like Swift (or Swift like Kotlin, depending on your perspective) and you get all the tools and libraries that have been built up over the years for server side programming on the JVM.

<comment><USER24> Deploying on the jvm isn't what i would call a sane environment, i'm looking for something more go like (aka build copy, done).

Plus kotlin doesn't seem to have a very stable web framework for now, and clojure isn't enough strongly typed for my taste.

All those things i'm looking for makes me really hope in swift on the server...

But thank you a lot anyway for making suggestions.

<comment><USER25> "Not sane"? You can literally unzip a JVM and then run "java -jar myapp.jar", how is that too complicated for modern day sysadmins?

But if you want a single copyable deployment then look at the javapackager tool in Java 8. It will take a unified JAR (which any build tool can produce) and create a .deb/.rpm/.tar.gz with a bundled JRE inside such that you can install it and then run your app in the usual UNIX way (by name). You wouldn't even know it's Java under the hood.

Kotlin doesn't need any web frameworks because it's 100% interoperable with Java, so you'd just use any of those like Play Framework, Ninja framework, Spring Boot, etc.

<comment><USER24> I'll have a look at the javapackager tool, thanks. For now the only jvm web framework i've used and found elegant enough is play, but since it's coded in scala, i don't feel like using another non-java language on top ( i already felt like using java for play was like using a second class citizen). Not that it won't work, but it has all the chances of creating weird code patterns and edge cases, and feel non natural at all.

</comment></comment></comment></comment></comment><comment><USER26> Reference counting seems really backwards and it hurts performance. Odd feature to have in a modern language

</comment><comment><USER27> > Syntax Doesn't Move the Needle; It's All About Tradeoffs

That section is gold.

</comment><comment><USER28> I still prefer objective-c most of the time. RIP :-(

</comment><comment><USER29> here is one of my pain points of using swift.

I need to convert Int to In32 and CFloat to CGFloat a lot.

I wonder why there are so many basic types, and why can't they be simply converted to other types.

<comment><USER30> Int is a 64-bit data type and Int32 is 32-bits. The compiler refuses to infer that you want to lose data. Converting the other way, the compiler refuses to infer that you want to bloat your data.

CGFloat, depending on the runtime, may either be a Float or a Double, so explicitly converting to and from it is required.

Rather than create a byzantine set of rules about whether it is "safe" to convert from one type to another, Swift wisely requires that all type conversions be explicit.

</comment></comment><comment><USER31> Should one wait for Swift 3? The API/syntax changes are a concern. Code breaking changes aren't that great. Also last time I checked Swift still requires a 64bit iOS device.

<comment><USER32> Not sure where you got that 64bit thing from. I wrote an app using Swift and it runs fine on my 32bit iPhone 5.

</comment></comment><comment><USER33> This is starting to sound a lot like Android developers still asking if they should use Android Studio or Eclipse...

<comment><USER34> It's totally different. Google officially stopped development and support for ADT in Eclipse. But Apple is still supporting Objective-C and most Apple's apps are written in Objective-C.

<comment><USER35> Apple is supporting Objective-C out of necessity (both for themselves and others). It's still very clear where the future of iOS development lies, and how few disadvantages there are.

That they continue to support Objective-C has little to do with whether or not you should be using it. You should, clearly.

</comment></comment></comment><comment><USER36> lol. "use an 'objective' approach to adopting swift". nothing like a well placed pun.

</comment><comment><USER37> What bother me the most about Swift, is it essentially a C# clone, actually worse, because C# has more features. It is a travesty that Apple chose to design yet another shit language when there are so many other alternatives. And now, like with Go, everybody is jumping on the band wagon because its Apple.

Sigh.

<comment><USER38> Swift borrows some ideas from C#, along with Kotlin, ObjC, and others. It's also radically different from C#:

1\. Swift collections and strings are value types, but in C# they are reference types

2\. Swift strings are mutable, C# strings are not

3\. C# by default allows reference types to be nil, Swift does not

4\. Swift performs overflow checking by default, C# does not

5\. Swift is reference counted, C# is GCed

6\. Swift's inouts are very different from C#'s ref. For example, Swift's inouts support properties

7\. Swift's error handling is quite different from C#'s exceptions, both in syntax and implementation

8\. Swift's enums act as algebraic data types, C# has nothing like this

9\. Swift's switch statements are much more flexible than C#, because of where clauses

and more.

These are some radical departures! The differences between Swift and C# are much greater than the differences between C# and Java.

<comment><USER26> That sounds really trivial to me. You've described less difference between Swift and C# than exists between C# and Java and those latter languages are commonly thought to bew very similar.</comment></comment></comment>


Batsh – A language that compiles to Bash and Windows Batch - <AUTHOR> https://github.com/BYVoid/Batsh

<comment> jack-r-abbit This was posted a few months ago but it was pointing to the domain ([http://batsh.org/](http://batsh.org/)) not the github page.

A lengthy discussion took place: [https://news.ycombinator.com/item?id=8254532](https://news.ycombinator.com/item?id=8254532)</comment>


World's most powerful telephoto prime lens on eBay - <AUTHOR> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=180438980987&ru=http://shop.ebay.com:80/180438980987_W0QQ_fviZ1&_rdc=1

<comment><USER2> That is pretty crazy. I honestly never would have thought that something like that would have existed... Telescopes yes, this... no. Very cool!</comment>


Looking to the Past to Ban Legacy Admissions - <AUTHOR> http://www.insidehighered.com/news/2008/11/20/legacy

<comment><USER3> On October 25, 1854 sub ordinates of Russian General Pavel Liprandi looked on in horror as a mass of allied cavalry charged positions they had lately taken up in and around an area in the Crimea known as Balaklava. Initially, believing the cavalry men to be intoxicated, the Russian response to this threat was delayed several moments. Regaining their countenance, Russian commanders ordered the enemy cavalry charging towards them destroyed. Russian artillery subsequently opened fire, raining destruction on the enemy cavalry. Les Chasseurs d'Afrique, as shocked and surprised at the developing scene as the Russians, hurriedly organized themselves and rode to the assistance of their bumbling Anglo counterparts, providing cover for the retreating cavalry men.

At the end of it all, the attacking cavalry was devastated. Less than half of the allied cavalry men committed to the initial attack made it back to their lines. Of this number was their commander, a man by the name of James Thomas Brudenell. He returned, and considered himself to have given it 'the old college try', went to his yacht, waiting in Balaklava harbor, and ate a champagne dinner.

This cavalry unit is known to history as the 'Light Brigade'. It was commanded by wealthy men who had purchased commissions that more capable, but less wealthy men could not afford.

We bear witness to the results of our modern day 'Charge of the Light Brigade' daily in our newspapers, on our favorite internet news sites, on our favorite blogs, and via Fox and CNN.

My point is that the current crises will necessitate some rather unpalatable structural changes for the United States. The abandonment of legacy admissions may be one of them.

<comment><USER4> IMHO the whole concept of legacy admissions (among other things) is distinctly un-American. The USA is all about hard work, perseverance, and talent. This is what has made America great, and it is _only_ through this that America can remain this way.

More and more American society resembles the old European oligarchies of old, the one the people fought so hard to free themselves from. Patents of nobility are gone, but the aristocrats remain all the same.

It saddens me - I've known so many people who had so much raw talent, but never got the help they needed to really excel. I know people who got poor grades in school who could hack circles around me. Yet here I am in college, surrounded by a bunch of pompous idiots who are only here because mommy and daddy could afford to send them to the best tutors, and boost their marks so far beyond what normal, but talented folks get.

Many of the most talented developers I know never got the chance to go to a prestigious school, or even study CS at a formal level. Yet the people around me by and large can't hack their way out of a wet paper bag. The talented, truly obsessive hackers don't get any help from society, but the career- seekers who aren't the least interested in the code they write are. There's no justice.

<comment><USER5> I'm of the belief that it doesn't really matter for the type of people you are talking about.

If these "lost" people are as talented and ambitious as you claim, they will have no problem succeeding at whatever field in which they choose to apply themselves. If they could "hack circles around [you]," then they will have no problem hacking one of the most peculiar and challenging systems of all, the steps needed to be successful in everyday society.

If they are that capable, then surely putting together a decent college application and getting into a good school or getting a great job would be piece of cake. You might have to bite the bullet and do things like create a resume and apply for jobs or take the SATs, gather the necessary papers, and submit your applications, but sooner or later smart, industrious people will realize that you don't get anywhere by complaining about your situation.

Talented, truly obsessive hackers don't need help from society, because they have the fortitude and resourcefulness to succeed on their own. You can't stop them from learning and working on hard problems. The "career-seekers" can take their safe, well-paid programming jobs at big companies and buy their cookie- cutter house in the suburbs next to all the other "career-seekers," with their white picket fence, 2.5 kids, and a dog. Good for them. But the kinds of hackers you are talking about would not be happy with that kind of lifestyle. They would probably want to be on the bleeding edge, to be a visionary or trendsetter rather than somebody who blindly walks along path paved before them. I believe that if you have a passion as strong as this, the rejection letters from jobs or colleges will lie and fade to ashes, forgotten as you blaze ahead into the life that you forge for yourself.

<comment><USER4> You would be right, but we've built a system that's stacked against the people I describe. The people I talk about can hack circles around me - but they never got high marks in school (family trouble, learning disability, etc.), and therefore never went to a prestigious college. _Many_ employers' hiring practices are obscenely stacked against coders with no degrees (or even degrees from a "crappier" college).

What you're describing is the precise problem with legacy admissions - <USER2> fact that we are judging a person's skill set via the college they went to, and controlling people's futures as a result of our artificial interference with what ought to be a true meritocracy.

If people _are_ objective, and looked at a person's hacking talent instead of whether or not they went to MIT, then I agree - these people can clearly carve a path for themselves despite not going to a prestigious school. But this is not the case.

For the record - the people I'm talking about _do_ work on some insanely cool projects despite the fact that they don't go to well-known colleges, or have degrees at all, but they constantly struggle to be taken seriously. When they walk into an interview (if they're lucky enough to get one) the fact that they come from some podunk college automatically tilts the playing field _far_ away from them.

To try to be objective - I don't think we can really correct people's perception that people from "good schools" perform better. So instead of fighting this false presumption, let's make sure we stack our college student body with truly qualified and talented people.

</comment></comment></comment></comment><comment><USER6> "As the number of applicants has soared in recent years, premier schools admit as few as 1 in 10 students, a far more selective rate compared with a generation ago. To make room for an academically borderline development case, a top college typically rejects _nine_ _other_ _applicants_ , many of whom might have greater intellectual potential."

[http://www.projo.com/education/content/projo_20060917_brown9...](http://www.projo.com/education/content/projo_20060917_brown917.327aa8d.html)

</comment><comment><USER7> No leg to stand on for private institutions. They are free to set whatever preferences they like. (And they all have them, especially for athletes at schools with sports dynasties, etc.)

<comment><USER8> All sorts of politically-popular restrictions have been applied to any institution that takes a single dollar of federal funding -- as project grants, student scholarships, or even student loans that have to be repaid. So there's hardly any fully 'private' institutions left which have the freedom you describe.

<comment><USER9> Bush's secretary of education is even an advocate of standardized tests for college students, like they have in high school. The federal government doesn't have the constitutional power to impose them, but it can withhold funds from institutions that don't make their students take the tests.

If the bureaucrats have their way, our colleges will one day rival our primary education in quality.</comment></comment></comment>


DreamHost DNS issues - <AUTHOR> https://www.dreamhoststatus.com/ <comment><USER2> They're saying it's a DDOS attack. Looks like it started right around the same time as their DOJ hearing this morning.

Update: There are reports that the DDOS is in reaction to DreamHost hosting PunishedStormer, the rebranded DailyStormer site.

[https://twitter.com/OpStandUpToCFAA/status/90077016627919667...](https://twitter.com/OpStandUpToCFAA/status/900770166279196672)

And the tail end of [https://www.dailydot.com/layer8/daily-stormer-punished- storm...](https://www.dailydot.com/layer8/daily-stormer-punished-stormer/)

<comment><USER3> They're refusing to hand over data to the FBI about visitors to a Trump- protest site, so if this is more than a co-incidence, then we're possibly looking at internet-savvy "Pro-Trump" folks. Since we know 4chan was a huge congregation point, I'd wager they're just a bunch of folks using LOIC to attack DH, or some DNS amplification attack.

Edit: Interestingly enough, this is going on even though the DOJ amended their request to be more focused (they claimed to not understand exactly what they were requesting, which is just as scary). So, DH will probably comply now, but the attack rages on. [http://fortune.com/2017/08/23/doj-dreamhost-anti- trump/](http://fortune.com/2017/08/23/doj-dreamhost-anti-trump/)

<comment><USER4> [https://www.reuters.com/article/us-usa-court-dreamhost- idUSK...](https://www.reuters.com/article/us-usa-court-dreamhost- idUSKCN1B41ZC)

The warrant has been approved.

<comment><USER5> Wierd. They'd supposedly dropped the request yesterday. [http://gizmodo.com/justice-department-drops-request-for- ip-a...](http://gizmodo.com/justice-department-drops-request-for-ip-addresses- of-1-1798325300)

<comment><USER6> The title to that article is misleading. They didn't drop the request, they changed it to limit the scope. If you read the changes, they are no longer requests HTTP request and response logs, but rather published content on the site and any transactions.

</comment></comment></comment></comment></comment><comment><USER7> Just have to say, dreamhost has had great uptime for such a cheap package, given the amount of features they provide.

Given this is not at all a result of their own error, I think they're doing a great job with reliability. By comparison (and it's not much of a comparison) godaddy shared hosting goes down WEEKLY for spans of 5-10 minutes, and it's more expensive and has way fewer features.

</comment><comment><USER8> Well this finally gave me the bump to move my DNS away from Dreamhost, which I have been meaning to do for literally years, now to sit and wait for the new name servers to propagate.

<comment><USER9> Why? A ddos could be launched against any provider. I dont see this as a dh specific issue to move over.

<comment><USER10> Larger DNS providers are harder to DDoS and also tend to have more DDoS mitigation in place. This is not to say that it can never happen, but it's substantially less likely.

<comment><USER9> I dont think DH is really all that small. Comlared to aws and stuff maybe but I think they have pretty significant infrastructure.

What Dns providers are you thinking of? My guess would be something like cloudflare would be a good choice. Though Ive never looked into it tbh, I run my own dns.

<comment><USER10> I use AWS for most of my DNS. Also thinking of UltraDNS and Cloudflare. These are all massively larger than Dreamhost.

</comment></comment></comment></comment></comment><comment><USER11> Yup. All my clients' sites are down. I wonder what the internet-wide impact is. And I wonder if I can migrate DNS providers while it is down.

<comment><USER3> As long as you have the DNS data, yeah, you should be able to do so, unless DH is also your domain registrar.

<comment><USER12> Does their domain control panel not allow you to set custom nameservers?

edit: oh, that is probably also under DDoS, whoops

<comment><USER13> I can highly recommend keeping your DNS stuff separate from hosting. For 'critical' stuff I've been quite happy to use DNSimple for that, and regular mom-and-pop LAMP hosting for the actual site.

In some cases I pipe it through Digital Ocean, because it's nice to have everything in one place, but I've wondered if that might have some performance impact. Can anyone confirm/deny this? So, domain registrar -> Digital Ocean -> hosting.

</comment></comment></comment></comment><comment><USER14> If you agree with what they are doing (fighting the FBI demand), there is a donation page for the cause; [https://www.crowdjustice.com/case/dreamhost/](https://www.crowdjustice.com/case/dreamhost/)

</comment><comment><USER15> All my DH sites are up.

</comment><comment><USER16> TIL people actually use Dreamhost for important stuff.</comment>


Ask HN: What does it mean to think like a programmer? - <AUTHOR>

As a designer turned developer I've struggled with that definition because it seems to imply that you have to be born that way.<p>Can't programming just be learned? Is that a reference geared toward mathematical theory? <comment><USER2> [http://www.penny-arcade.com/patv/episode/so-you-want-to- be-a...](http://www.penny-arcade.com/patv/episode/so-you-want-to-be-a- developer-part-1)</comment>


Discussions of miscellaneous mathematical topics. - <AUTHOR> http://www.dpmms.cam.ac.uk/~wtg10/mathsindex.html <comment><USER2> The discussion about the existence of sqrt(2) made me wonder: is there any object in mathematics that we know exists, but have no way of calculating it? I.e.: no algorithm has been found, even given a Very Powerful Computer.

I miss mathematics.

</comment><comment><USER3> This is a duplicate post (sort of--the YC item below is a preamble to the link above):

<http://news.ycombinator.com/item?id=121956></comment>


Show HN: Slideshow background image search - <AUTHOR> https://chrome.google.com/webstore/detail/backgroundimage-search/olemhlpdoebkeehhjgifmemjdafeikld?hl=en

<comment><AUTHOR> Not sure how to let people know about this besides Show HN. I made a background image search extension to find images from the slide shows that try and keep their images out of your grasp. It was annoying me this morning so, yah.

The image on the crhome store is from Trulia. source code is here: [https://github.com/ibsusu/BackgroundImage- Search](https://github.com/ibsusu/BackgroundImage-Search)

Hopefully it's somewhat useful to others.</comment>


HTML5 and Web Video: Questions for the Industry from the Community - <AUTHOR> http://blogs.msdn.com/b/ie/archive/2011/02/02/html5-and-web-video-questions-for-the-industry-from-the-community.aspx

<comment><AUTHOR> Most interesting bit: _"Microsoft is willing to commit that we will never assert any patents on VP8 if Google will make a commitment to indemnify us and all other developers and customers who use VP8 in the future. We would only ask that we be able to use those patent rights if we are sued first by somebody else. If Google would prefer a patent pool approach, then we would also agree to join a patent pool for VP8 on reasonable licensing terms so long as Google joins the pool and is able to include all other major providers of playback software and devices."_

Could be an olive branch, or it could be a veiled threat (they seem to be implying that VP8, much like Linux, actually infringes Microsoft patents). Unfortunately the rest of it seems like political posturing, and Mr Hachamovitch has always been seemed a slippery character (going on his posts to that blog) so I'd have to assume this is a cunning rhetorical trap rather than a genuine offer until someone who knows better convinces me otherwise.

<comment><USER2> That bit was hilarious to me - Microsoft and Google joining up to form a patent pool with zero patents in it. If that's what it takes to get MS on board with WebM, why not?

Also, it's worth pointing out that "patent indemnification" is a stronger guarantee than MPEG-LA gives for H.264.

</comment></comment><comment><USER3> Shouldn't the title be (and I know it was just taken from the original) _HTML5 and Web Video: Questions for Google from Dean Hachamovitch, Corporate Vice President, Internet Explorer_ :-)

<comment><USER4> Too long, HN limits title length to 80 characters.

</comment></comment><comment><USER4> "Microsoft pays into MPEG-LA about twice as much as it receives back for rights to H.264."</comment>


PHP the Wrong Way - <AUTHOR> http://www.phpthewrongway.com/ <comment> V-2 Why learn frameworks when you can build everything from scratch and become a true carpenter ( _" building software using general purpose frameworks doesn't make you a coder or a programmer any more than putting together a pre-built house makes you a carpenter"_).

 _" These people [framework creators] seems to be infatuated by the though of having other people follow their "way of doing things", becoming some kind of PHP community leaders, and having other people use their latest "hip" Open Source tools..."_

How lame of these people.

The problem is, if I inherit an application created with a well-known framework, I'll have a much easier time figuring out what is what, and looking for answers when something goes awry.

On the other hand, if the codebase has been written from scratch by Greg, a real carpenter of a programmer, who is no longer with the company, then good luck. I'm at his mercy entirely.

I'll be having his "way of doing things" for dinner whether I want it or not, the only difference is that I won't have a community of other people in the same situation.

This aspect isn't addressed by the author at all, although he found just enough time to provide us with a psychological analysis of framework authors and their narcissist motivations :)

<comment><USER4> I wonder why this mentality only exists with web devs. Everywhere else, someone writing software is considered normal, not some scary problem. Nobody sees any other kind of application written by a previous programmer and cries "oh no! I am entirely at the mercy of this previous programmer! If only they had used one of the dozen competing frameworks this tragedy could have been avoided.". It is just normal. Perhaps the low barrier to entry and corresponding low average experience of web developers plays a part in this mentality.

<comment><USER5> Because the myriad ways _public_ people interact with your code through HTTP and routes starts to rival the complexity of getting crypto code right, with a lot of the same sorts of downsides (which is to say problems often lead to security issues, and very few people are capable of reasoning about _all_ the implications of the decisions made). I would suggest someone not roll their own framework (which is essentially creating a framework of their own at some level) for the same reasons I would suggest someone not roll their own crypto. The upside is relatively minuscule compared to the downsides, IMO.

> Nobody sees any other kind of application written by a previous programmer > and cries "oh no! I am entirely at the mercy of this previous programmer! If > only they had used one of the dozen competing frameworks this tragedy could > have been avoided.".

Yes, they do. If you came upon someone's custom HTTP client, I imagine your response would be something along those lines. If not lamenting that you're at their mercy, at least cursing them for imposing a requirement of some level of strength that you use what is _very likely_ to be a substandard implementation of what you can find freely available. So, you either replace it with something less likely to cause the odd problem later (and deal with all the testing to make sure you didn't introduce a bug, and you probably did) or deal with those odd problems ("what do you mean we aren't conforming to TLS correctly? Why haven't we seen this until now?").

<comment><USER4> > If you came upon someone's custom HTTP client, I imagine your response would > be something along those lines.

No, why would it? What HTTP client framework am I supposed to be wishing they used?

<comment><USER5> Maybe cURL? Some other one I don't know of (I know the ones in my preferred languages). Do we really need to also be responsible to dealing with already solved problems as well as the problems specific to our domain? Do we really want to _also_ deal with the not-fully-compliant HTTP client or making sure we support HTTP/2, or do we want to use widely accepted solutions for those so we can focus on the real problem at hand (which is usually not the intricacies of HTTP negotiation, or some other well understood and supplied need).

<comment><USER4> Curl isn't a framework.

>Do we really need to also be responsible to dealing with already solved problems as well as the problems specific to our domain?

No? What does that have to do with anything?

>Do we really want to also deal with the not-fully-compliant HTTP client or making sure we support HTTP/2, or do we want to use widely accepted solutions for those so we can focus on the real problem at hand (which is usually not the intricacies of HTTP negotiation, or some other well understood and supplied need).

Did you reply to the wrong comment by mistake or something? What does any of this have to do with me or what I said?

<comment><USER5> > Curl isn't a framework.

I wasn't under the impression we should be limiting this to frameworks. What's the difference between a framework and a library for the purpose of this discussion? I think they are functionally equivalent. I was clear to equate it to crypto originally, which doesn't really make sense when viewed as applying to frameworks only. We're a couple comments removed from that, I thought that wasn't in question. Same with an HTTP _client_. Frameworks don't event necessarily implement clients. I'm addressing NIH syndrome, and I don't think frameworks really deserve special consideration in any way.

> Did you reply to the wrong comment by mistake or something? What does any of > this have to do with me or what I said?

See above. And I've been sticking with the same examples since the first comment. Why is this all of a sudden not making sense?

<comment><USER4> >I wasn't under the impression we should be limiting this to frameworks

The discussion is entirely and solely about frameworks..

>What's the difference between a framework and a library for the purpose of this discussion?

Wikipedia exists.

>See above

Above what? Nothing you said above answers my question.

>And I've been sticking with the same examples since the first comment. Why is this all of a sudden not making sense?

Because it has absolutely nothing to do with anything I said, like I clearly stated.

<comment><USER5> _My point was_ frameworks are functionally no different than a large complex library, and as such, the same arguments apply.

That said, I'm not entirely happy with the way the tone of this conversation is heading, so I'll excuse myself now.

<comment><USER4> >My point was frameworks are functionally no different than a large complex library

You'll have to forgive me for not guessing that given that nothing in your post came anywhere close to even suggesting anything of the sort. I am limited to reading what you write, and can not read your mind.

Yes, frameworks are different from libraries. Boy, that was productive.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> >>> The wrong way: Always use a framework on top of PHP

I haven't been actively working with PHP for quite some time but... From what I've seen, I wish many people didn't take this advice (including the teenager me).

It's similar to ORM. Often, if you don't use one, you end up building one, a very poor one. Yes yes I know there are exceptions and all but, in general, that's truth. Same with frameworks. If you don't use one, you end up writing a poor one, unless all you need is a page that outputs a result of a single SQL query, or something equally trivial.

I've seen plenty of 10k+ LoC applications with home made frameworks, poorly replicating open source ones, just because.

>>> In the world of Python and Ruby building websites from the ground up is tiresome because neither Python nor Ruby was originally created to build websites. As a result general purpose frameworks such as Django and Ruby on Rails quickly became popular for building websites in these languages.

RoR, Django became popular because it's so simple to build basic CRUD apps, which most of the applications are. Most of the stuff is done for you. Can't say the same about plain PHP. The author largely ignores the reasons why the mentioned frameworks became popular.

Yes, you could make a well engineered solution from scratch. But chances are that you will not, time constraints being one of the reasons.

Sorry, couldn't read further than that.

<comment><USER7> > It's similar to ORM. Often, if you don't use one, you end up building one, a > very poor one.

Whereas, often, if you _do_ use one, you end up using one, a very poor one. Sometimes you can get away with that. Sometimes you get to spend a Friday morning root-causing and reverting a production defect in a highly visible application because the developers of the extremely popular ORM you inherited failed to mention in their documentation that a specific and entirely innocuous-looking schema option causes the ORM to produce a query containing a Cartesian join.

You can use an ORM. Or you can write SQL, work with arrays, and keep your code and data separate. None of that is terribly difficult, and you are responsible for the results no matter what you do. If you can't trust yourself not to get basic things right, you have problems at a level that no library will solve.

<comment><USER8> The code that uses arrays instead of objects is worse to support because you don't know what those arrays contain and cannot type-hint them. Functions that return arrays usually don't document their structure. And even if they do, the documentation might be outdated. So you either have to spend a lot of time tracing where do those arrays come from and where they go to or risk breaking something.

This approach works well only with tiny applications written by a single person. Once the app grows larger it will get hard to support.

ORM have their disadvantages but you have to learn them thoroughly including how they are made internally. They are not some magic tools that "just work". But in a large application you have to use objects and therefore ORM.

ORMs usually have some form of SQL-like syntax, for example Doctrine has DQL.

<comment><USER9> Doctrine 2 also often spends _10x_ the time on post-processing the data from the database as it does actually making the database calls itself (it's not fixable without dropping to straight SQL out of the ORM). Its query language is atrocious and unnecessary. Their ideas of joins and internals are absolutely horrific. The boilerplate is 1/3 of my app. But even if it was the perfect piece of code (it's exactly the opposite: total and utter shit), I'm not going to slow down all my DB queries 10x for _anything_ , not to mention the incredibly slow development speed of now having two query languages and a million wrong ways of making simple queries and no ways of making proper advanced queries. Everything with Doctrine takes many times longer than with straight SQL even after years of working with it. I have yet to find an ORM that doesn't have egregious failings like Doctrine 2. It is inherent in the stupid concept of ORMs that implementations fail. See: [http://solnic.eu/2015/09/18/ditch-your- orm.html](http://solnic.eu/2015/09/18/ditch-your-orm.html) [http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern](http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern) and most importantly, see benchmarks for ORMs like Doctrine and observe their destructive effects on programmer productivity.

<comment><USER8> I agree, Doctrine has performance problems. I did some microbenchmarks too. But you could try to optimize (or write your own custom) mapping code, or maybe you could load less entities or write a better ORM. Sometimes you have to use SQL queries too (when the result of a query cannot be mapped to entities).

The "SQL and arrays" approach is much worse and doesn't scale. Without ORM and classes you will get undocumented JSON trees (or arrays) passed around.

> [http://solnic.eu/2015/09/18/ditch-your- > orm.html](http://solnic.eu/2015/09/18/ditch-your-orm.html)

It seems to me that author wants to replace complex approach (OOP and ORM) with even more complex one. So instead of having one object representing an entity we can have ten objects representing the entity at different moments in time. So we have to find out which one is the latest. And we will need even more memory to keep them.

He writes:

> There is no User but it's very likely there is SignupUser.

And soon there will be LoginUser, GuestUser, ProfileEditUser, UserForReport and others. And a bunch of methods to convert between them.

I don't understand what is the problem with mutable entities. They are supposed to be mutable. I never had problems because of functions modifying arguments given to them.

I don't believe functional programming can be use instead of OOP. Can you represent a DOM tree, collection of GUI widgets, a graph of related database entitites, a form with validation rules with functional programming? You will just end up emulating classes and objects.

The author probably just likes the idealized concept and did not try to apply it to a real world application (but if anyone did it would be interesting to see the code).

I also took a look at Ruby Object Mapper he mentions in a post and don't really like it. It uses arrays (that are called ROM::Struct there) a lot and I don't see much functional programming there.

I also have read this article [http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern](http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern) and I partially disagree with the conclusion. Using key-value storage instead of a database is generally bad idea. It doesn't solve "N + 1 queries" problem, it doesn't provide foreign keys (and often transactions), and you have to write messy custom code instead of shorter and better readable SQL query (example: [https://www.kchodorow.com/blog/wp- content/uploads/2011/12/SQ...](https://www.kchodorow.com/blog/wp- content/uploads/2011/12/SQL-to-MongoDB2.jpg) ).

<comment><USER7> > And soon there will be LoginUser, GuestUser, ProfileEditUser, UserForReport > and others

You...really can't think in any paradigm other than object-oriented everything, can you? I mean I guess it works for you and that's great but _please stop you 're really scaring me now._

</comment></comment></comment></comment></comment></comment><comment><USER10> Is it me or is the author confused about the distinction between a library and a framework?

To me, a framework implies inversion of control: you don't call the framework's code; the framework's code calls _your_ code.

Granted, he skirts the issue with phrases like "A framework is a system that helps you build software, but at the same time it forces you to work within the limitations and restrictions of the framework itself", but this describes what a framework achieves, not what it _is_.

Call me pedantic, but this I find this indicative of poor understanding, and this article raises a number of red flags along these lines, such as this gem:

>PHP on the other hand was created from the beginning by Rasmus Lerdorf as a set of tools written in C that would enable you to easily and quickly develop dynamic HTML. As such PHP was, and still is, a framework in and of itself.

Uh... what?

Maybe I'm overstepping my bounds, but this article is furthering certain stereotypes about PHP-programmers.

<comment><USER11> I kind of get what he is saying but he is saying it very badly I believe Jeffrey Way the same things a lot better.

Yes you don't need a framework all the time you don't need to do OOP all the time or follow design patterns all the time but the cases in which you don't need to do that are edge cases that very few programmers run into.

Also if you think PHP is a framework then it must be the worst framework ever designed. Libraries exist precisely because they were required to smooth out the inconsistencies and insanities of the underlying language tools.

A framework is just a collection of libraries wove together with some sane default ways of doing things. Some even allow you take them apart and customize them but they give you a good starting point.

If the way the framework does things is not good for your requirements you can try another and only if you are absolutely certain none of them do the job should you roll your own because once you do the barrier to entry for someone new to the code base will be that much higher.

The only thing I do agree with is that security should be a consideration in the development process but here we get back to the fact that a tried and tested framework has already dealt with the most common security issues and as long as you don't do something stupid in your own code you should be OK.

<comment><USER10> I agree that OOP and frameworks aren't necessary _in principle_. I vehemently disagree with the notion that they aren't needed _in practice for PHP_.

I further contend that a PHP programmer advocating against the use of frameworks who doesn't show a clear understanding of what they actually are is not to be trusted. I even go out on a limb to claim that this is representative of the ills of the PHP community at large. That last part, I willingly concede, is debatable and ultimately beside the point :)

To return to the crux of the argument -- that frameworks are not necessary in principle -- I would like to add that this assumes a well-designed standard library. I don't use frameworks with Go, but I sure as hell use them with PHP because the latter is an absolute minefield.

That someone advocating pragmatism would miss this point is astounding. My jaw has dropped and shattered to the floor. How can you rail against principled approaches to software design (a strange position to take, independently of the current debate) only to get hung up on the theoretical feasibility of writing PHP without a framework?!

It's further bewildering that the author would advocate a _pragmatic_ approach to building software, yet neglect that frameworks offer a pragmatic solution to the security concerns that plague PHP. It's almost as if he doesn't understand the terms he's using!

</comment></comment></comment><comment><USER12> PHP is the very different from development in C# or Java. Anyone from those backgrounds pretty much automatically hates it. PHP will punish you hard for designs that would be fantastic in .NET or Java.

It's also very different than Perl or Python. It tries to be specific to the web and that makes a lot of oddities that the more general languages do not have.

OTOH you can make a fantastic design in PHP. It's just that there are very few people who know how to do that. Frankly, because it's not taught... anywhere.

So, yeah, as much as I've learned how to use PHP (through 11 painful years), it's really hard to figure out how to use correctly. It's possible.

The ideal PHP design (currently) is a hybrid between OOP and straight script that will look bizarre to anyone from, well, any other background. As others have mentioned you have to be very careful not to load too much into memory or you will come crashing down fast.

I still use it, because now I know how, but, ironically, I wouldn't recommend it. It's so very different from anything else that I don't know that the skills transfer well to other languages (other than straight-up problem solving).

</comment><comment><USER13> I just skimmed the website, and I am still not sure if it's meant seriously or if it's some kind of joke? Feels a bit contradictory eg. "dont use framework" vs "make software secure by default". Isn't a security one of the gains of using frameworks, beside other things? You would need to be a security expert to cover all potential security issues when writing something from a scratch.

<comment><USER14> You can also build horribly insecure applications with a framework. A framework does not absolve you from thinking, which seems to be the point the author is making.

There's a difference between frameworks and libraries and of course it is a good idea to use trusted crypto implementations and avoid NIH syndrome, but a large part of security is including it in the design process from the start.

You can't just assume "the framework will handle it", or "bcrypt is all I need" or "the opsec team will find all the problems".

It rather sounds like you're expecting the author to hand you a magic-bullet solution, which is rather the whole point of the article: there isn't one. You _do_ need to know what you're doing.

<comment><USER15> The jack of all trades is the master of none. Almost no generalist is going to be good enough to properly handle all security concerns. I like knowing my framework is constantly upgrading password handling, XSS attack prevention and things I haven't even heard of yet. The fact you _can_ build insecure things in a framework isn't an argument against it and why would someone who builds a horribly insecure app in a framework produce a better result without using one?

<comment><USER14> They probably wouldn't, but that's neither something I said, nor is it the article's premise.

However, a framework does increase the attack surface, which is something that should be taken into account. If you save 20 lines of code by adding a 100,000 line framework, you need to ask yourself which of those is most likely to contain a bug?

Plus, bugs in popular frameworks tend to get exploited in practise. Other bugs less so, because of the need to first _find_ the bug. The odds of that happening will increase if the bug is common and obvious, or you are a particularly high-value target. By using a framework you effectively increase your value as a target to the sum value of all projects using that framework. This becomes especially bad if the framework stops being maintained, because the value to an attacker isn't lost as quickly.

The above also applies to libraries, but libraries tend to be more focused and more stable than frameworks, since frameworks tend to "go stale" if not continually updated in a way that most libraries do not.

</comment></comment></comment></comment><comment><USER16> Paul Graham's quote in "Design Patterns" section actually says nothing or the opposite of what the author is trying to say - Paul says that when he's seeing in the code things (shapes <<of code>>) that repeat themselves, it's an indication to him that he's missing some macro definition that would build this shape for him so he doesn't need to repeat himself by manually creating it all the time - that he can reuse it (as macro).

How does it relate to design patterns? Does it say not to use them? Absolutely not. It says the opposite, if anything - to recognise patterns in your code. "Design patterns" is just an idea that if you see your patterns repeating themselves (some of your macros tend to be very similar in different projects) then you should give it a name. This way when you explain system to your colleagues it's easier to communicate.

</comment><comment><USER17> I generally agree with the view of keeping your application simple and not using big frameworks but after seeing so many PHP programmers write spaghetti and insecure code, I pretty much recommend frameworks now. You can say the problem is not with writing PHP without any framework but with the programmers, the problem lies with the low barrier for entry into PHP. Frameworks atleast teach you how to make your code modular and make your application secure (atleast sane defaults).

<comment><USER18> In my experience using a framework does not prevent spaghetti code.

<comment><USER17> If you want to write spaghetti code, you can write it whichever approach you take. It's more about making it difficult to shoot yourself in the foot.

<comment><USER19> Frameworks allow you to shoot yourself in the foot with a Tank.

<comment><USER20> Perfect example. You nailed it!

(Anyone close to familiar with tanks will know it will take quite some effort compared to any of the smaller alternatives ;-)

<comment><USER21> But you can easily get yourself crushed by a tank, and also "why oh WHY DID YOU DRIVE A _TANK_ TO PICK UP OUR KIDS FROM THE SCHOOL?!?"

<comment><USER20> Have my upvote.

Then again, most frameworks are more comparable to cars than tanks and people use cars all the time to pick up kids at school even if they could just walk.

Convenient you know and less chance of getting mistaken for a hipster :-]

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> So the author considers following PSR guidelines beyond 1 and 2 to be "the wrong way"?

PSR-4 is the currently accepted best practice for autoloading and while it "may [have] a direct effect upon how you code your software," it's the optimal approach for 99% of projects I've encountered.

Following community interoperability guidelines is what allows developers to move away from monolithic frameworks and compose projects based on the packages they need.

<comment><USER23> > currently accepted best practice for autoloading

According to who? FIG?

Are you aware that php has a built in auto loader that supports namespaces and is written in C?

> compose projects based on the packages they need.

Ah, the NPM/Composer golden brick road to development. Aka, the "I don't know what this is but I'm gonna lick it" approach to development, where you end up with 50 "micro-frameworks" or "utility libraries" each of which depends on a further 20 other libraries.

I have some issues with this site but it's right that the FIG is a joke, and anyone who claims its "best practice" is not paying attention.

<comment><USER22> > According to who? FIG?

According to the vast majority of authors of the most widely used and tested PHP libararies.

> Are you aware that php has a built in auto loader that supports namespaces > and is written in C?

You mean the autoloader builtins that composer uses under the hood already? This is better than a 1 line include how exactly?

> Ah, the NPM/Composer golden brick road to development. Aka, the "I don't > know what this is but I'm gonna lick it" approach to development

I don't understand what you're saying here, everyone should be writing their own libraries from scratch? It has always been up to the developer to vet the dependencies they choose to include in their project. That applies to every language ecosystem, not just Node.

<comment><USER23> > According to the vast majority of authors of the most widely used and tested > PHP libararies.

So, FIG.

"Group of developers say that groups' work is the best. News at 11."

> You mean the autoloader builtins that composer uses under the hood already?

No, spl_autoload is a working namespace aware autoloader. Composer uses a bunch of userland code.

> I don't understand what you're saying here, everyone should be writing their > own libraries from scratch?

Did I say that? I've seen, multiple times the negative consequences of the current fad to rely on 25 separate, single-purpose 3rd party Libs, all of which are basic functionality that a well thought out library would give you, but with the added "bonus" of each relying on 20 other libraries to do basic things.

> It has always been up to the developer to vet the dependencies they choose > to include in their project. That applies to every language ecosystem, not > just Node.

Do the vast majority of developers know that? Because the ones I've had the "pleasure" of working with, definitely don't.

</comment></comment></comment></comment><comment><USER24> I do not want to be mean, but I honestly feel there is no 'right way' in case of PHP. There are communities that care about 'doing it right' and there are some that want just to 'get the job done'. I prefer the former, PHP always seemed to prefer the latter.

<comment><USER25> This is a massive overgeneralisation of a humongous amount of people and man- hours of work. Why do you feel this? Do you have anything to back up this statement?

Anecdotally speaking, I'm a Senior Software Engineer working with Go and PHP.

We use Go when working on performance critical code, because for us that's where it excels.

We use PHP when we need simple interoperability with the legacy Magento site our company runs and for jobs like running a CSV importer or some other oft- visited-task. We both get the job done and care about doing it right. You can write some truly beautiful code in PHP if you have the correct level of patience, process and experience behind you.

<comment><USER26> 99% of people who get paid to write PHP do not have the requisite level of patience, process, or experience to write a fibonacci method let alone write "truly beautiful" PHP.

<comment><USER25> It's really easy to make up statistics on the spot with absolutely no source.

I very much doubt that people would be getting paid to write any code if they couldn't implement a single for loop in their primary programming language.

<comment><USER26> PHP was the first language I ever used professionally. The code I wrote - <USER3> code every single one of my colleagues wrote - was atrocious. We were paid bottom dollar ($30k in 2008) to write absolute shit code. The PHP community in my area was the same. All newbies, all paid barely more than a fast food manager, all writing code that could be taken down by a HS student with Fiddler.

I'm sure different experiences exist, but the majority of folks who I speak to have experiences that match mine very closely.

PHP is a ghetto.

<comment><USER27> PHP is so vast that it's a ghetto, the rich uptown area, a sprawling suburban middle class, and more.

I share some of your experiences - I'm disturbed by how easy it is for people without basic coding knowledge to make money "building php websites". But I also see and run in to a large number of people who can do fantastic PHP code (testable, documented, clean, modular, etc).

One thing I've noticed is that _most_ of the people who can do _good_ PHP code (at least in the sense that it's _not crappy_ ) have also worked in other languages/tech, either before or during their PHP work. I know the exceptions, but for the most part, someone's PHP code quality is higher if they've done more than just PHP.

<comment><USER28> > someone's PHP code quality is higher if they've done more than just PHP.

That's how most quality frameworks for PHP were born, by folks having used other languages.

That being said, I find Symfony3 to be very decent. I was surprised by the quality of its documentation.

</comment></comment></comment></comment></comment></comment></comment><comment><USER29> This is satirical right? Unless you're building something super trivial, a framework is the way to go. You end up reinventing the wheel anyway.

Here's a sober reason why to use a framework [http://symfony.com/why-use-a- framework](http://symfony.com/why-use-a-framework).

</comment><comment><USER30> The usage of that Paul Graham quote is hilarious. The author misses the point entirely! Graham uses the word pattern to describe a repeated piece of code that matches a pattern. And it's a sign of trouble: a violation of the DRY principle. Nothing to do with design patterns really. Are all the other quotes used as unsuitable, we don't know.

<comment><USER21> No, the author does not miss the point - though I assume he may not understand it fully. The quote is written in context of Lisp macro facilities, which let you DRY your code from a lot of things, _including GoF-style design patterns_. So e.g. if you see yourself using "Memento pattern" (or whatever) in many places in your code, writing the same kind of methods doing the same thing everywhere, you should consider writing a macro that'll do that for you instead. That is, if your language lets you do that. Design patterns really start where the language's ability to abstract ends.

<comment><USER30> No, I don't think so. That's not a critique towards design patterns. It's critique towards ANY CODE THAT IS REPEATED. If I use a certain design pattern once in my code, I didn't repeat anything. Macros don't remove the design pattern, they just allow me not to repeat myself.

<comment><USER21> You rarely use design patterns _only once_ in a project. And while this quote does not cover it, you can also use macros to better communicate that one-off design pattern instance - instead of identifying a pattern by noticing a set of familiar methods or a typical inheritance graph, the person reading your code can just see the the macro invocation and know he's dealing with a particular design pattern here.

Design patterns aren't bad per se, even if they imply some problems with language's capabilities to abstract - because they shift an abstraction from code to programmers' shared knowledge. The problem is with what I would call "design-pattern-driven development" \- attempting to fit your problem into the bunch of design patterns you know. It's unfortunately very common.

<comment><USER30> I don't think there's such a problem really. We all try to fit the problems we encounter in designing software into a bunch of knowledge that we know. That bunch might be a set of design patterns. There's nothing wrong with that. Sometimes they fit perfectly and sometimes they don't. Sometimes the software we produce is not perfect.

</comment></comment></comment></comment></comment><comment><USER31> The problem is that companies that don't use frameworks end up re-implementing their own as complexity grows, and of course usually do so extremely poorly. No matter what, for any non-trivial application, you DO need a framework - <USER3> choice is either to use an existing one or to implement your own. The big advantage of existing ones, in my view, is that they are well documented and everybody can learn them. That pretty much never happens with bespoke frameworks.

</comment><comment><USER32> This is awesome, thank you! PHP may have started out as a "set of tools", but it evolved into a complete language. Like any programming language, you can write sloppy code or elegant code in PHP - with or without a framework.

Languages are foundations on which frameworks and design patterns can be built to solve common problems. The trap that we fall into is trying to fit all of our problems into those common ones that frameworks and design patterns solve. This leaves potential edge cases that become bigger problems.

PHP can be has hacky or as elegant as you make it. The versatility of that makes it a great utility. It also makes it very approachable. This is a big contributor to why it runs a big part of the web.

</comment><comment><USER33> IMO one of the key missing points here that is not really considered, is that when you use a well documented and relatively mature framework, it greatly simplifies some of the non-programming related aspects of software development, particularly with regard to getting new developers up to speed, and ensuring that even your junior-most developers are able to contribute without having to become heavily acquainted with your specific implementation of authentication, file uploads, routing, etc.

</comment><comment><USER34> The entire argument could be reduced to: "be informed, and make good decisions" which is a very banal statement that could be applied to almost every endeavor in life. Because PHP makes it so easy to be productive without being informed you run the risk of unknowingly making bad decisions. There is an exhortation to use frameworks so that if you aren't informed you at least get the guide rails / hand-holding / best practices that the framework imposes on you.

</comment><comment><USER35> The article pretty much applies to any comparable language, really.

</comment><comment><USER36> This is why I don't use Cocoa to write iPhone apps, or Swift, but ARM assembly. True carpentry! Jesus was a carpenter too, and God spoke the machine code of the universe.

</comment><comment><USER37> If every project had unlimited budget and only quality developers, this site would be a little bible. The reality is much different - communities exist so we can stand on the shoulders of our peers :)

</comment><comment><USER38> Wait, is this satire or not? Does it advocate people don't use frameworks?

Loved the opening paragraph though

<comment><USER39> It's definitely not a satire. They are some valid points. It's not against using frameworks. I think it's more about finding the right solution for the problem.

<comment><USER38> What I take from is not to use PHP, which I do as it pays the bills, but why would anyone choose it for a new project baffles me. This article doesn't help it.

<comment><USER40> I love PHP. It feels like a complete toolbox to me, whereas other languages like Python or Ruby feel like I'm buying an entire Home Depot for every project. Sometimes you need the whole store. Most times I don't.

I think the OP has some good points about reconsidering the standard answers that everyone gives to questions when asked. There are no silver bullets in web, but many things sure are treated like them.

Maybe there are projects where PHP isn't right. There are probably tons. But that doesn't mean that it's always wrong. PHP is what got me into making web things in the first place. I loved (and still love) how utilitarian it can be.

But perhaps that's where I differ from most people. I see myself as someone that makes web stuff. Most seem to see themselves as app creators or system builders. And they probably are. Sure, I do that too when the time comes, but if most of the time I'm building a front-end to a CMS, I'm hardly "engineering" anything. I'm mostly just trying to make specific art for other people.

Anyway, I don't understand why PHP would immediately be ruled out from this article. It feels like the JavaScript of the server-side world to me. Use as little or as much as you want. You can do awful things with it, but also wonderful things.

<comment><USER38> Well I certainly agree with the right tool for the right job. And PHP has some roles. My point was more about the article, which would, imo, put programmers off PHP with its contrariness and smugness.

</comment></comment></comment></comment></comment><comment><USER41> So if I was starting a new project now, I shouldn't use a framework or any pattern too strictly, so.. what do I do? Following this logic will give me spaghetti code and reinvented wheels. If there are some basic patterns to follow they should be included here.

<comment><USER42> My feeling is I should just start coding with whatever I know and not bother getting involved in arguments about the underlying language. Time is money friend!

</comment></comment><comment><USER43> There is a grain of truth in what they're trying to say, but the conclusions are outright misguided.

My favorite is "The wrong way: Thinking of patterns when solving problems." \-- textbook reinventing the wheel / NIH.

<comment><USER44> I don't think it's saying exactly that. One should think up a solution first, then see if one needs patterns to fit that solution into the code base in language of choice. PHP certainly doesn't need all of Gang of Four recipes due to dynamicity and other factors.

</comment></comment><comment><USER45> I'm not a huge fan of OO, but this gets the history of OO soooo wrong. I mean, really, this has to be a joke.

</comment><comment><USER46> PHP is certainly a unique community, a very pragmatic bunch they are, but that's why we love em'

</comment><comment><USER47> PHP is really great. I'm not sure why so many people hate it so violently. It's useful and runs like 1/4th of the web.

<comment><USER48> You're thinking WordPress, which runs 25% of the web.

PHP runs a lot more. Over 80% according to w3techs.

<comment><USER47> My bad.

</comment></comment></comment><comment><USER37> This reads to me as a parent saying to a kid (me) "Well, you _could_ stick your hand in the fire, but.."

</comment><comment><USER49> It is near impossible to write "Modern" PHP and achieve good performance.

On every request, PHP reads and parses every file that is referenced somehow. It is in direct contradiction to the language constructs the PHP itself provides - especially Exceptions, Interfaces and Inheritance.

People want to use these features, because they help design better systems, where the concerns are separated, and features are plugins instead of hardcoded all over the place.

Unfortunately, the required files for a request can pile up quite quickly, to the point where bytecode cache does not help, serving multiple requests per PHP load does not help, prewarming cache for frontend such as Varnish does not help, memory usage is over the roof because of trashed heap memory.

So, to sum up, the author here is right: this is insanity, until PHP provides a module system that can handle PHP abstractions.

<comment><USER48> > So, to sum up, the author here is right: this is insanity, until PHP > provides a module system that can handle PHP abstractions.

I suspect you're being downvoted because we have this: [https://getcomposer.org](https://getcomposer.org) \+ [https://secure.php.net/manual/en/language.oop5.abstract.php](https://secure.php.net/manual/en/language.oop5.abstract.php)

<comment><USER49> I worked with PHP for 5 years and I am well aware of the composer; I am being downvoted because I said that author is right on some point.

</comment></comment></comment><comment><USER50> And that's how Laravel was born...

This website should be taken down. Wanna be back to the 2000's, are we?

</comment><comment><USER51> Between composer and symfony and php 7 I would say PHP is ahead of both ruby and python communities in terms of code quality, perfomance and ease of deployment.

There are some minor drawbacks in the core language, nothing compared to the python 2/3 split and all the virtualenv and packaging mess, and the sub-par arhitecture of rails (as far as i heard).

Mind you this is limited to web development, php does not shine in any other field.

People FTPing their code to a server or writing code in pure (probably sub- optimally designed) PHP beyond trivial scripts and web pages are not representative of the PHP community at all. At least not in europe.

</comment><comment><USER52> I didn't read it all but some people are do dogmatic about things it is stupid. I have dealt with plenty of co-workers who read some book and promptly beat everyone with it.

</comment><comment><USER53> PHP community had always been anti-frameworks and anti-libraries. I worked at company where use of third-party libraries was entirely forbidden on most projects. I think it's because:

\- Quality of PHP frameworks is low (at least it was last time I used it) \- PHP parses and evaluates whole libraries and framework code on each requests. There's proprietary commercial (lol!) software to enable at least caching of bytecode \- Packaging just does not work (Pear, now there's Composer, not tried it, seems that it works)

Overall, last time I used PHP i had sense of its community mostly being nihilistic and preferring cowboy programming. It's straight opposite to Java where you will be shamed for not using dependency injection and EJBs for page visits counter. In PHP world you are considered insane misfit if you're writing tests.

For some things advice to just code and don't use unnecessary libs is useful. Recently I had that php/cgi feeling when I worked on small microservice in clojure: no OOP, no MVC, no ORM, no templates, no separating each 10 lines of code to module, just take Ring request and return Ring response which are simple associative arrays. This was a refreshing feeling.

<comment><USER54> If you haven't used PHP since composer became a standard in projects, you don't know modern PHP.

<comment><USER40> "Modern PHP" being one of the trigger words in the OP.

That said, in terms of timeline, PHP has gotten better as a whole since then.

</comment></comment></comment><comment><USER55> I feel like this could have been a tweet not a website

</comment><comment><USER56> It's rather a shame that the author of this site has chosen to be anonymous; I should like to understand why they choose to reject a number of points generally considered best practice in software engineering, regardless of programming language: patterns; frameworks; library reuse; standards bodies etc.

This unfortunately sounds like the cry of a programmer who has worked on their own for years suddenly encountering the requirements of working with a team of coders.

</comment><comment><USER57> beat a dead horse, will ya

</comment><comment><USER9> _At over a dozen PHP jobs in over ten years, I 've never seen a real application without a framework be anything but fucking garbage._

Garbage. You know it's going to be garbage when some idiot tells you not to use a framework but is too fucking stupid to realize that if you don't use one, you have to write one yourself. Every single time. And PHP as a framework itself? Please. PHP is a horribly shitty framework itself for any app that's going to be more than a couple hundred lines of code. It's only with a proper framework on top that it becomes a proper web development platform (some may argue otherwise but their ignorance can be safely ignored). But I assume the author has never written anything more than a demo app, so yeah, if you're writing short scripts under 500 lines, don't use a framework. If you're writing real apps, don't listen to idiots like this author. This isn't PHP specific. There's nothing that makes PHP different from Ruby or Python. Appeals to PHP having been developed for the web are idiotic because while true, it's irrelevant due to the poor quality of PHP < 5 and especially PHP < 3\. Yes, it was specifically developed for the web _poorly_ and we've been fixing that ever since. If the author wants to use PHP 2 or 3 (or whatever the fuck they were called), that's one thing, but to pretend that coding in PHP 2/3 style is what makes proper apps these days is fucking insane.

</comment><comment><USER58> We don't have to reinvent the wheel everytime we create apps or any product using framework. Like imagine , When my every product needs login / register mechanism , i would look for something that is really fast, secure and may/may not have better approach of doing that.

So, framework are basically to speed up work in same elegant way the others are doing.</comment>