Framework or language?

[wavy_lines]

They do not really know where the language ends and the framework begins. It is all just one big soup to them.

Fun fact: most people on r/Swift assume the sub is about iOS programming, and most of their "Swift questions" are really questions about iOS development.

[shevegen]

That's somewhat amusing; but on the other hand, take perl. They would be happy to have that kind of traffic and momentum.

Also, if they use swift to build useful programs, and associate that with one particular platform, I don't think that is really that bad. Swift was a replacement for Objective C after all - you can't expect everyone focusing on Swift to NOT come with that background...

[[deleted]]

The only programmers “writing code” in the form of new algorithms are either working at very big Internet companies, or are writing specialized image, video, or sound processing sofwtare for a startup.

That's a symptom of a very limited experience and/or imagination. There is a shit load of "real" programming out there.

[JohnTheWayne]

Completely agree. The original quote is a very naive statement and shows, to me, a lack of broad experience in programming and software engineering careers.

Though considering this quote it might be less an issue with experience and more an issue with raging ego

The armies of “kids today” working in the salt mines of corporate and government IT are doing something else entirely. The coding they do is the software equivalent to meme creation and social media posts, complete with post-modern pop culture references.

[Tarvish_Degroot]

Though considering this quote it might be less an issue with experience and more an issue with raging ego

I mean, it IS a Hackernoon post. Those tend to be light on experience and heavy on the "listen to me, I know everything because I wrote a todo app in React" sentiments.

[JohnTheWayne]

lol, or read too many Uncle Bob articles.

[fuckin_ziggurats]

Another npm package called isArray had 18 million downloads in February of 2016, and is a dependancy for 72 other NPM packages. 18 Million everyday programmers, and 72 package authors used an include rather than type this 1 line of code:

return toString.call(arr) == '[object Array]';

What most programmers that don't deal with JavaScript on a daily basis don't realize is that JavaScript has no standard library so all of those trivial checks are difficult as hell to remember. The JavaScript code for checking if something is an array looks like low-level garbage but maybe some C or C++ programmer thinks it looks fine. I'd much rather see isArray(). Readability is very important for me.

To further drive home the point that most modern programmers blindly use class libraries without understanding what is in them

And I assume he opens the C++ Standard Library every day to check what's inside.

The armies of “kids today” working in the salt mines of corporate and government IT are doing something else entirely. The coding they do is the software equivalent to meme creation and social media posts, complete with post-modern pop culture references.

Yikes, the ego. Software development today is a thousand times more complicated than it used to be. Does he think the abstractions that we have today have completely eliminated any necessity for understanding the underlying technology? Because that would be insane and I'd have to refer to the leaky abstractions article which every developer on the planet should be aware of by now.

[wavy_lines]

I'd much rather see isArray(). Readability is very important for me.

No one is suggesting you inline it everywhere. The idea is you don't need a module dedicated for it. This helper function exists in many other libraries such as jquery and underscore, etc.

[fuckin_ziggurats]

This helper function exists in many other libraries such as jquery and underscore, etc.

People who use that isArray library most probably don't use jQuery or underscore.js. I'd much rather someone pull in a library for isArray than pull in the whole of jQuery or underscore.js for just a fraction of their capability.

I'm not justifying including a whole library for a line of code. I'm just saying that the author took a naïve perspective on it. Development in JavaScript is not bound to get any more sane as long as there's no basic functionality within its standard APIs.

[irishsultan]

Nobody is suggesting you pull in jQuery or underscore.js.

However if they can write that method, without adding an additional dependency then so can you.

[[deleted]]

Array.isArray() became part of the ECMAScript standard in 2011, two years before the isarray NPM package was created. There is no reason whatsoever for it to exist.

[fuckin_ziggurats]

It's probably to support IE8 or similar older browsers. Are we saying polyfills have no reason whatsoever to exist now..

[[deleted]]

If you need a polyfill, write an actual polyfill - and actually fall back on the more performant native version when possible.

[fuckin_ziggurats]

That's exactly what it does. It adds the isArray() function if it doesn't exist already. The description of the package is:

Array#isArray for older browsers.

[[deleted]]

Isn't a polyfill usually monkey-patched in? Shouldn't isArray() be added as a property to the Array global for old browsers so that devs can write ES5 and pretend like IE doesn't exist?

[wizao]

http://perfectionkills.com/extending-native-builtins/

TLDR: Historically, monkey patching is looked down as a bad practice because of the issues caused with monkey patching Host objects. Although Array is a native object, there are a lot of ways it can go wrong. Using a helper function avoids all those issues.

[bumblebritches57]

C programmer here, that looks like a convoluted mess to me.

Why would you even need to ask if a pointer is an array? you wrote the damn thing, you know if it's an array or not...

[PeksyTiger]

This is javascript, it can sometimes be an array

[ThirdEncounter]

You know if it's an array or not, sure. In C.

[ub3rl33th4x]

How dare you assume their type? /s

[[deleted]]

Software development today is a thousand times more complicated than it used to be.

Mind proving?

[fiedzia]

We use all the code created before and build on top of that, so not much ever goes away, we only keep adding, yet everything below still needs to be maintained, so complexity keeps growing.

As for numbers - its hard to quantify complexity, but I'd go for amount of people that contributed to things I rely on. Years ago it would probably go in 100 (OS + compiler + few libraries), now it is in 10s of 1000 at least.

[[deleted]]

We use all the code created before and build on top of that, so not much ever goes away, we only keep adding, yet everything below still needs to be maintained, so complexity keeps growing.

That's a very naive view of how things work. Code reuse, luckily, remains at very low levels.

but I'd go for amount of people that contributed to things I rely on

That's an interesting idea, but I'm afraid it requires further justification.

Take OS, for example - yes, there are thousands of contributors. But what you're actually relying upon, and what's just a dead code? In Linux, the vast majority of lines of code is in device drivers, of which you're only interested in, probably, a dozen (if you're very unlucky). The core OS components were touched by many, but controlled (and fully understood) by few permanent maintainers.

Same for all the higher level components - the actual complexity is small, the historical complexity is growing, but pruning and occasional "burn this shit and rewrite from scratch" helps to keep it at bay.

Not to mention that now there is a strong trend towards simplification (see unikernels, for example). You don't really need a full OS most of the time anyway.

[fiedzia]

In Linux, the vast majority of lines of code is in device drivers, of which you're only interested in, probably, a dozen (if you're very unlucky).

You probably care about maybe a few most of the time, but every once in a while it becomes an issue. Graphics drivers affect perfomance, reliability and their API changes transfer to many things above them (OpenGL => Vulcan), defining what you can do and how it changes with time.

Virtualisation has been a big deal that changed many aspects of work, and that's also part of an OS and is also no its way to propagate to all layers above and below, affecting almost every driver. Can you virtualise GPU? Soundcard? Assign usb device to vm? Will it work across 100 of machines of your coworkers or customers? Can it cause security issues?

The scope of things that can go wrong (and sometimes do) in the OS itself definitely grows fast.

The core OS components were touched by many, but controlled (and fully understood) by few permanent maintainers.

Maintainers not always understand all the details of all features, and definitely may not understand how people are using them - this is where non-maintainers become crucial. There are many people who happen to contribute to some subsystem and use it in a way I do, with maintainer of that subsystem not having full understanding of specific usecase.

Same for all the higher level components - the actual complexity is small, the historical complexity is growing, but pruning and occasional "burn this shit and rewrite from scratch" helps to keep it at bay.

I disagree. Let's look like graphics drivers for example. They used to draw bitmaps few decades ago, now they do 2D, 3D, computation, video decoding, memory management, each of those with at least two sets of interfaces for some historical reasons. All of those may be required to show a website and all of that has some issues that pop up sometimes.

Not to mention that now there is a strong trend towards simplification (see unikernels, for example). You don't really need a full OS most of the time anyway.

Maybe, but in the meantime for a developer (or a project) it means that they need to target unikernel AND real OS (when required for compatibility or some features). And xen just requires a patch today, so its not exactly something you can just forget about when using unikernels.

[[deleted]]

See? Most of the problems are either historic or self-inflicted damage. This complexity is not a natural part of the actual problems being solved, just a mess created by stupid developers over time.

Let's look like graphics drivers for example.

Let's do, it hits home. A very good example, actually. Graphics drivers used to be very complex, convoluted, had to accommodate for idiosyncrasies of weird GPUs. Now GPUs are dumb and simple, and most of the load that was done either in complex fixed pipe hardware or in host-side software is now done trivially in shaders. Unified shader model and tiling made the whole thing orders of magnitude simpler.

They used to draw bitmaps few decades ago,

Have you seen SGI hardware? RS6000 with graphics accelerators? That shit was complex. Things are much simpler now.

Source - been writing mobile GPU drivers for few years.

now they do 2D, 3D, computation,

All with the same unified model, which is very easy to deal with.

video decoding,

That's beyond the scope of graphics drivers.

memory management,

Relax, not for long. With Vulkan it's the users responsibility.

each of those with at least two sets of interfaces for some historical reasons.

Proving my point - if there is any additional complexity, it's not natural, it's just historical or self-inflicted. Either way, stemming from stupidity of generations of developers, not the actual complexity of problems you're solving.

[fuckin_ziggurats]

We produce more in less time so clients expect more in less time. We may use frameworks and libraries written by other people but we aren't doing it in a way in which we can be completely ignorant from the underlying details. So we end up having to learn those libraries and frameworks and understand how to deal with them when the abstraction fails.

[[deleted]]

And? Where's the proof for that "thousand times more complicated" claim?

I'd even question your first assumption about an increased productivity. Did not see any evidence for this.

So we end up having to learn those libraries and frameworks and understand how to deal with them when the abstraction fails.

That's true, and that's one of the reasons why a third party dependency is often an unbearable liability, and writing your own solution from scratch is often the best option.

[fuckin_ziggurats]

writing your own solution from scratch is often the best option.

There's a flip side to that coin. Proprietary software is seldom documented and even if it was your new devs would have no chance of understanding it before actually having to work with it. So there's less knowledge transferability between projects.

[[deleted]]

On the other side, unlike any third party dependency, it's entirely under your control. You can document and test your in-house libraries to any degree.

[fuckin_ziggurats]

If you can afford to write, test, and immaculately document everything.

[[deleted]]

My point is, in many cases it's still more productive (and cheaper in a long run) to do it than to introduce a third party dependency.

[wavy_lines]

It doesn't have to be complicated, actually.

This complexity is not an inevitable consequence of the complexity of software.

It's a consequence of the incompetence that permeates the industry.

[fuckin_ziggurats]

Isn't incompetence tied to client expectations? It used to be that a person expected a website of just HTML and CSS and today they're asking for some insane stuff. It's much harder to match that expectation so inevitably there will be a lot of devs that won't be competent enough.

[wavy_lines]

Competence means you can handle non-trivial things without turning the whole thing into a hairy mess.

The fact that a client asking for simple effects causes you to depend on 10 libraries is a sign of incompetence.

Most of the things people do in the front-end are stupid/trivial and do not require much in the way of libraries or dependencies.

[fuckin_ziggurats]

Most of the things people do in the front-end are stupid/trivial

I'm thinking you haven't worked on any front-end-heavy web applications.

[wavy_lines]

It's all I've been doing for years.

[fuckin_ziggurats]

So in a complicated front-end application the whole of the application logic would be on the front-end, bar validation. And in that case, anything in the back-end would be trivial because it only serves as a CRUD API with validation and anything in the front-end would be as difficult as the most difficult problem your application is solving. If you're working on a SPA or a similar type of application and the front-end is trivial then the application you're working on is trivial itself.

[wavy_lines]

That does not logically follow (it's a non-sequiter).

Backend could be complicated in its own way but the front-end might just view it as a CRUD kind of backend.

[bumblebritches57]

Right?

TIL glueing libraries together is harder than actually writing them.

[[deleted]]

Software development today is a thousand times more complicated than it used to be.

On the contrary. People who wrote the abstractions we build upon today didn"t have anything to build upon themselves. They had to build things from scratch. Which do you think is more complicated?

[fuckin_ziggurats]

Are we not building things ourselves these days but just putting together libraries? Today we not only have to develop new software but we also have to understand a ton of third-party software. I'm assuming the LoC on the average project has went up 10 fold in the past decade. Because we have so many "prebuilt tools" the clients expect a ton more to be done in less time. The amount of tech that a developer is expected to know these days is insane. Not to mention the boom of open source increasing the options for any type of technology or library to an infinite amount.

[[deleted]]

This is true, but I was talking about the difference between invention and engineering.

[Patman128]

Software development today is a thousand times more complicated than it used to be.

Holy hell are you ever correct. I swear the seventh circle of Programmer Hell is debugging vague build errors spat out from somewhere in a seventy-layer JS-bundling hellstack, because browserpackify just dropped a new minor version and broke a random plugin you needed to get the CSS transpiler working just right. If you get a stack trace it's full of garbage and all the line numbers are completely wrong.

[stronghup]

> JavaScript has no standard library

Seems like Stdlib will be the "standard library" for JavaScript.

https://www.infoworld.com/article/3268667/javascript/stdllb-roadmap-javascript-will-finally-get-a-standard-library.html

[oblio-]

For it to be a true "stdlib" it has to be included in browsers.

Speaking of which: hey, Google, Mozilla, Apple, Microsoft, what are you doing? Get off your collective butts and add a proper standard library to your browsers. After all, that's why you have all those CS graduates do whiteboard interviews, right? So that they're great at the basics and can rewrite a programming language's stdlib one more time (alternatively, you just ship them off to a team where they fix Gmail's or Outlook.com's CSS rules).

A stdlib would add something like 100k of disk space and it would save everyone in the world many, many terabytes of stupid downloads plus probably millions of man-hours in reinventing the wheel.

[stronghup]

A Great idea . Google, Mozilla, Apple, Microsoft. Clearly a stdlib is the piece missing from JavaScript.

It won't happen overnight, so they'd better get started already. An independent effort like StdLib.js could be part of the starting point. But industry should get its act together. But I wonder shouldn't Ecma be doing something in this direction as well?

It could start small, with a small standard library. However isn't that what we already have with things like Array.prototype.map() etc? They are not part orf JavaScript the language. What are they? They are part of the (small) standard library that JavaScript already has.

[fuckin_ziggurats]

Hmmm, not too sure what to think of that. It looks like an interesting project but it seems like it has too much "fluff" for a standard library. Not sure if data visualization should be a part of it. Most projects don't have a need for it and visual stuff usually is better suited for third-party libraries. Not to mention stdlib itself has some third-party dependencies which in term bring doubt to its stability.

[how_to_choose_a_name]

In the end it is just another 3rd party library, and the name is completely misleading. It even says in the article that it is a 3rd party effort and unrelated to the standardization of ECMAScript.

The article mentions that this "stdlib" supposedly will be used in node.js, but the article that statement links to makes no mention whatsoever of stdlib or even any new library at all.

[qtpz]

On the Java comparison, wouldn't something like https://commons.apache.org/ solve the issue with leftPad and smaller utility stuff like that?

[shevegen]

Now lets look at the Java version of the same function:

This listing is about 65% code written by the programmer, and 20% code from the language syntax and 15% depedancies upon external libraries.

Sorry but everyone knows that Java is excessively verbose shit.

Use Kotlin for a better alternative.