You know who sucks at developing APIs?

Facebook.

I mean, how are so high paid guys with so great ideas manage to come up with apis THAT shitty?

Let's have a look. They took MVC and invented flux. It was so complicated that there were so many overhyped articles that stated "Flux is just X", "Flux is just Y", and exactly when Redux comes to the stage, flux is forgotten. Nobody uses it anymore.

They took declarative cursors and created Relay, but again, Apollo GraphQL comes and relay just goes away. When i tried just to get started with relay, it seemed so complicated that i just closed the tab. I mean, i get the idea, it's simple yet brilliant, but the api...

Immutable.js. Shitload of fuck. Explain WHY should i mess with shit like getIn(path: Iterable<string | number>): any and class List<T> { push(value: T): this }? Clojurescript offers Om, the React wrapper that works about three times faster! How is it even possible? Clojure's immutable data structures! They're even opensourced as standalone library, Mori js, and api is great! Just use it! Why reinvent the wheel?

It seems like when i just need to develop a simple react app, i should configure webpack (huge fuckload of work by itself) to get hot reload, modern es and jsx to work, then add redux, redux-saga, redux-thunk, react-redux and immutable.js, and if i just want my simple component to communicate with state, i need to define a component, a container, fucking mapStateToProps and mapDispatchToProps, and that's all just for "hello world" to pop out. And make sure you didn't forget to type that this.handler = this.handler.bind(this) for every handler function. Or use ev closure fucked up hack that requires just a bit more webpack tweaks. We haven't even started to communicate to the server! Fuck!

I bet there is savage ass overengineer sitting there at facebook, and he of course knows everything about how good api should look, and he also has huge ass ego and he just allowed to ban everything that he doesn't like. And he just bans everything with good simple api because it "isn't flexible enough".

"React is heavier than preact because we offer isomorphic multiple rendering targets", oh, how hard want i to slap your face, you fuckface. You know what i offered your mom and she agreed?

They even created create-react-app, but state management is still up to you. And react-boierplate is just too complicated.

When i need web app, i type "lein new re-frame", then "lein dev", and boom, live reload server started. No config. Every action is just (dispatch) away, works from any component. State subscription? (subscribe). Isolated side-effects? (reg-fx). Organize files as you want. File size? Around 30k, maybe 60 if you use some clojure libs.

If you don't care about massive market support, just use hyperapp. It's way simpler.

Dear developers, PLEASE, don't forget about api. Take it serious, it's very important. You may even design api first, and only then implement the actual logic. That's even better.

And facebook, sincerelly,

Fuck you.

Just before you, my fellow system programmer, scroll past this, let me say this:

🍬 The web is actiually simple. 🍬

Both HTML and CSS is declarative. It's all easy when you understand the concepts, learn how to be idiomatic and quit trying to do that imperative bullshit in languages that aren't imperative.

HTML is simple. You know the boilerplate: doctype, head, body, that's all. Just mark it up and do NOT look at it before you end, mark it up as it were article or something. The appearance is up to css.

CSS is simple. You may even forget bem or rscss, you're already a skilled software developer. Use common sense and your code-splitting and naming skills you gained reading The Code Complete or doing software development for years.

Forget mockups. Forget absolute positioning, forget setting width and height in pixels. Go to awwwards, find some inspiration. Draw some buttons and fields on paper with your good old pencil. Then go and write some css. Feel free to steal some shadows and transitions from codepen.

Read about 8-pixel grid system. Let every element push away from others by setting something like margin: 16px; and whoops! You've just got fully responsive and got great vertical rhythm without even using media queries!

Oh my god, do NEVER set width and height explicitly! Type something like button { width: 120px; } and bang! The entire web page is broken. Quit that shit. Let it resize as it should. It will resize itself to fit its contents.

HTML is by default ready for your template engine. That's how you receive data from server — as server-side rendered, plain old HTML page. On the other hand, the form element is the most axiomatic and simple way to send the data to server. That's how you send it — as plain old GET or POST that every webserver can handle.

All of there are true:
1. It's easy to get great 100% responsiveness without media queries.
2. It's easy to align items in row, it's just one line of css. Maybe two, if you still want elements to wrap, but want to use flexbox:
.parent {
display: flex;
flex-wrap: wrap;
}
3. HTML and CSS are fast by default.
4. You don't need mockups to achieve great visual experience. Mockups is imperative, web is declarative.
5. You may not even need JavaScript to make great website.

Go on, ask me a question about web! I'll ready to answer everything.

Dev: We need a better name than “Data” for this class. It’s used for displaying a set of tiles with certain coordinates so maybe TileMap would be a bit more declarative?

Manager: No I don’t like that. Data is perfectly fine, this class is for managing data so it’s perfectly declarative you just need to get better at reading code. If you have to change it then DataObject or DataObjectClass might be a bit more specific.

Dev: …

I’m tired of all these profane “frontend developers” who do nothing but get cheap internet points by shitting on web technologies.

Bitch, NPM is just a package manager. That’s what it is. Anyone who ever used a package manager already knows how to use NPM.

Here on devrant, there at your workplace, people hear nothing but bitching when you open your mouth. You always need a “solid task description” and “best practices”. You always need somebody else to do your job for you. Frontend is the area where you have to constantly switch between heavy, performance-oriented coding, UX and graphic design while remaining in a dynamic environment that is called “web”, no wonder why you can’t do that. Instead of bitching, you could just present your own solution you designed with just a little bit of product-oriented thinking. But noooo, you fucking bother designers whenever you’re not sure about “how many pixels is that padding”.

You can only be barely productive (and only with a frozen spec) but can never take the lead just once.

In the 80s your kind of approaches were doubted, by the 90s they were dead. In 2020s they’re straight up laughable.

And don’t get me started on CSS. You have to be an absolute buffoon of a developer to not know how to use a DECLARATIVE tool that don’t even require real structural thinking.

No wonder why you praise php. You throw shit all over the place and tell everybody that you’re a “sociopath” and you don’t need that “stupid frontend” and “stupid users”. But you know what? Any real backend or embedded dev would’ve laughed at your face.

Because backend developers are respected.

You’re not.

the more time I spend in this industry, the more I come to realize that it's a very blurry line between PROGRAMMING and CONFIGURING.

How much programming do you do these days, really? Isn't it just configuring your frameworks and libraries and engines to do what they do in the way you want?

Does it still make you programmers...?

And then what are these .conf files for your application? A declarative configuration for your... imperative configuration...?

I once knew a guy who claimed that:

* Declarative languages were these where you declare variables before you use them.

* C is a functional language because every subroutine was returning something (even void).

Should you use declarative or imperative paradigm? :D #programmingParadigms

css quick maffs

so, you want to make a css gradient from a certain color into transparent. The logical way would be doing it like this:

linear-gradient(#112233, transparent)

however, this will cause a blurred black stripe to appear in safari. This is due to safari-specific algorithms (that also make it the quickest browser, especially on arm-powered macs).

stackoverflow and other boubas will suggest doing this:

linear-gradient(#112233, rgba(255, 255, 255, 0))

this is better, but instead of a black stripe, a half-transparent white stripe will appear.

To finally make this gradient render consistently across different browsers, do this:

linear-gradient(#112233, #11223300)

Now, you're only changing alpha. See, CSS is a declarative language, so you should be telling it EXACTLY what you want to achieve. You don't want to change one color into another (in that case, "#112233" into "transparent", yes, they are distinct colors that are totally different. CSS doesn't treat "transparent" in some special way like we do) but to only change the alpha channel of #112233.

Feel free to use rgba notation if you want to support older browsers:

linear-gradient(rgba(11, 12, 13, 1), rgba(11, 12, 13, 0))

aight bye

I don't advocate low code solutions. But what Microsoft is doing with Power Fx is legit pretty cool.

If anything it would expose people to learn about proper development since the formulas can grow bigger than standard small Excel formulas while simultaneously exposing them to a declarative and functional style of coding. According to what I am seeing, and y'all correct me if I am wrong, but this seems to be made to let pro devs jump in and help with more complex code while at the same time exposing it to non devs in an easy way.

I kinda dig this one

If you're subscribed to me only because of my jokes, feel free to ignore this rant. You won't miss anything.

If not, bear with me.

I was wrong about almost everything I can remember. Preaching so-called “conceptual thinking”, I invented a fantasy world of random anecdotes, which turned into a completely false worldview that shaped my reality. I bashed magical thinking, yet succumbed to it. What I believed to be true was just as magical, wrapped into what sounded like science. In the Dunning-Krueger scheme, I was right there on Peak Stupid.

Random hear-say, stupid concepts I invented, random “knowledge” I picked from YouTube videos, all that was rotting inside my head, one anecdote contradicting another. Ultimately, I think this was the reason of my constant anxiety and pointless, never-ending thought process in background.

If you learned anything factual from me and didn't fact-check it, please forget that immediately. The list includes but is not limited to everything on brain structure, everything on philosophy, almost everything on engineering and architecture, almost everything on systems theory and programming meta stuff (declarative, imperative, etc.)

I admit bashing unit tests. The only reason was me disliking writing them in uni. I wrote like three test cases, disliked it, and the rest was history. Everything else was a rationalization on top. If I was right about something, I was just lucky.

I'm not a CSS prodigy. I know stuff that earns me money and impresses my colleagues, but my knowledge is just one step above basics, in one thousand steps ladder.

My apologize to everyone I told that functional programming is declarative.

It's actually imperative. Thank you @AndSoWeCode for figuring that out. I spent the whole day thinking about it.

Lisp is imperative. It's just different way to define the exact data transformations, and that's quite imperative.

On the other hand, HTML, CSS, config files and markup languages are declarative.

But writing the imperative program which is configured with declarative configs seems like great idea. Consider Apache web server and others.

Sharing a first look at a prototype Web Components library I am working on for "fun"

TL;DR left side is pivot (grouped) table, right side is declarative code for it (Everything except the custom formatting is done declaratively, but has the option to be imperative as well).

====

TL;DR (Too long, did read):

I'm challenging myself to be creative with the cool new things that browsers offer us. Lani so far has a focus on extreme extensibility, abstraction from dependencies, and optional declarative style.

It's also going to be a micro CSS framework, but that's taking the back-seat.

I wanted to highlight my design here with this table, and the code that is written to produce this result.

First, you can see that the <lani-table> element is reading template, data, and layout information from its child elements. Besides the custom highlighting code (Yellow background in the "Tags" column, and green gradient in the "Score" column), everything can be done without opening even a single script tag.

The <lani-data-source> element is rather special. It's an abstraction of any data source, and you, as a developer can add custom data sources and hook up the handlers to your whim (the element itself uses the "type" attribute to choose a handler. In this case, the handler is "download" which simply sends a fetch request to the server once and downloads the result to memory).

Templates are stored in an html file, not string literals (Which I think really fucks the code) and loaded async, then cached into an object (so that the network tab doesn't get crowded, even if we can count on the HTTP cache). This also has the benefit of allowing me to parse the HTML templates once and then caching the parsed result in memory, so templates are never re-parsed from string no matter how many custom elements are created.

Everything is "compiled" into a single, minified .js file that you include on your page.

I know it's nothing extraordinary, but for something that doesn't need to be compiled, transpiled, packaged, shipped, and kissed goodnight, I think it's a really nice design and I hope to continue work on it and improve it over time

Functional-Declarative languages should only be esoteric ones. They are interesting for research and a mathematical toy, but they should not be used for programming languages used in the real world.

I currently try to write OpenSCAD code that places a list of modules, with information given from an array, with varying sizes next to each other. And is so hard and cumbersome. Whoever had the idea to cripple OpenSCAD by not having variables was stupid or sadistic.

The actual CPU run instructions, one after the other, there is no good reason to not allow some imperative elements in a programming language.

I gave a very small overview of the flutter sdk a whiiiile ago and I have been thinking about going back to it. Currently considering between 2 courses on udemy that are at a discount price. I love the idea of dart as a language and prefer declarative ui building over xml shittyness. I was an Android/ios development for 2 years and hated every minute of it, but really love the idea of building mobile apps.

What are your thoughts and considerations on this? Should I jump right in or just leave it asside? What are your success stories with flutter and what did you use to learn the framework besides the docs? How easy are things like state management and persistent storage with flutter compared to android and ios?

I will eventually make my own decission by building sample projects, but hearing from the community would be great.

I keep getting contacted on Facebook Messenger by "null", and receiving "message" from my friends. How can a social network suck so much? And how can a company spend so much money on declarative programmers without the rest of their teams picking up on such basic techniques as making invalid state unrepresentable?

I really dislike micromanagement. I don't want to dictate details. I don't like hierarchies where my direct reports obey me.

The only thing that obeys me is my hands, with them, I write the exact code I want. I don't hire another pair of hands. I hire another brain.

When you see your direct reports as professionals, you can give declarative tasks: "make a pretty website footer", "make that page load quicker". If you leave implementation details for your direct reports to decide, this doesn't mean they'll fuck up. They are professionals too, and if you personally interviewed them, you better believe they can handle it.

I'm so god damn sick of unattended upgrades and OS updates. I've switched from Ubuntu to NixOS for a few months now already and it's the greatest thing I've ever done, because it's declarative, it's rational and it's fast. Unfortunately today I had to switch back to Ubuntu for the day, because I don't have my main laptop with me and now I remember why I hate this OS. This piece of shit garbage keeps running unattended upgrades updates when I'm doing busy work. Like I'm writing my Jenkinsfiles and sitting in work meetings and then suddenly a fucking unattended upgrade eats 100% CPU and turns my friendly laptop into a jet turbine :(((

React, it's declarative way of doing things, and the functional programming methodology it prefers.

Realized how much I've moved on from for-loops and class/object instance to maps, filters and immutability/observers when I worked on a Laravel project after so long and found myself forced to do things in the, erm, "PHP" way, despite spending my initial year and a half of programming working exclusively in PHP.

Sure, there's Class Components and imperative techniques in React but I had blissfully settled into using the flexible nature of doing things enabled by both native JS and React, with hooks, Lodash/Ramda and (almost fanatically) pure functions

Trees -> declarative programming

Loops -> functional programming

Sequences -> imperative programming

Graphs -> dynamic programming

Good mapping, yeah or no?

Didn't see any rant about Apple's new declarative UI framework: SwiftUI. Looks a lot like Flutter, but I'm still new in flutter so I'm not sure that way of creating UI, why is it better that way? Or it is just like Oranges and Apples, choose what fits your needs?

As I started learning React, I found the allure of declarative style of programming appealing. I try to avoid maintaining multiple state variables for data that can be derived from the base state itself that's stored in the redux store. It works wonders when I have to change something; as I just need to make changes to one function in the utils folder and that change is implemented across the whole app, rather than change the instances everywhere as was the case when I initially started working on this project after the previous dev left.

But I see myself redefining a lot of computed values everywhere, and if I just try to define them in the root component, I'll end up with a huge list of props being passed to a couple of components. Shifting it to the utils folder helps a bit, but then I find myself defining even the simplest of array filtering methods to the utils folder.

Is this need to define computed values everywhere a trade-off that you need to accept when you write declarative code, or is there a workaround/solution I am missing? As of now, the code-base is much better than how it used to be when they had a literal Java dev work on React with their knowledge of Java patterns being used in a framework that is the polar opposite of OOP, but I still feel like there's room for improvement in this duplication of computed values.

So fun fact! The Rust macro error

"Macro expansion ignores <token> and everything after it"

does NOT mean that macro expansion on general ignores this token. What it DOES mean is that the macro expanded to something, then the parser was invoked, and the parser stopped consuming tokens at the specified point.

In normal human speak, this means
"This token is invalid in its context after macro expansion. Refer to the generated code for concrete error."

I spent hours moving intermediate results into macro parameters because I thought the error meant that your macro cannot expand to the second half of a comma-separated list or whatever, until I got the same message about '(' which is very obviously permitted macro output and doesn't even really make sense given that it's not a token.

I recently refactored a form with complex client side interactivity for one of my clients replacing jquery with vuejs in the process and I'm absolutely baffled by how easier it is to reason about everything when you think of the UI as a function of the state. Only devs who have done both imperative and declarative DOM manipulation at some point in their life can understand the joy of doing this. And all of this can be done with just a simple script tag without having to bring in complex build process that has plagued the Javascript ecosystem.

Okay. Here's the ONLY two scenarios where automated testing is justified:
- An outsourcing company who is given the task of bug elimination in legacy code with a really short timeframe. Then yes, writing tests is like waging war on bugs, securing more and more land inch after inch.
- A company located in an area where hiring ten junior developers is cheaper than hiring one principal developer. Then yes, the business advantage is very real.

That's it. That's the only two scenarios where automated testing is justified. Other such scenarios doesn't exist.

Why? Because any robust testing system (not just "adding some tests here and there") is a _declarative_ one. On top of already being declarative (opposed to the imperative environment where the actual code exists), if you go further and implement TDD, your tests suddenly begins to describe your domain area, turning into a declarative DSL.

Such transformations are inevitable. You can't catch bugs in the first place if your tests are ignorant of entities your code is working with.

That being said, any TDD-driven project consists of two things:
- Imperative code that implements business logic
- Declarative DSL made of automated tests that also describes the same business logic

Can't you see that this system is _wet_? The tests set alone in a TDD-driven project are enough to trivially derive the actual, complete code from it.

It's almost like it's easier to just write in a declarative language in the first place, in the same way tests are written in TDD project, and scrap the imperative part altogether.

In imperative languages, absence of errors can be mathematically guaranteed. In imperative languages, the best performance (e.g. the lowest algorithmic complexity) can also be mathematically guaranteed. There is a perfectly real point after which Haskell rips C apart in terms of performance, and that point happens earlier on than you think.

If you transitioned from a junior who doesn't get why tests are needed to a competent engineer who sees value in TDD, that's amazing. But like with any professional development, it's better to remember that it's always possible to go further. After the two milestones I described, the third exists — the complete shift into the declarative world.

For a human brain, it's natural to blindly and aggressively reject whatever information leads to the need of exiting the comfort zone. Hence the usual shitstorm that happens every time I say something about automated testing. I understand you, and more than that, I forgive you.

The only advice I would allow myself to give you is just for fun, on a weekend, open a tutorial to a language you never tried before, and spend 20 minutes messing around with it. Maybe you'll laugh at me, but that's the exact way I got from earning $200 to earning $3500 back when I was hired as a CTO for the first time.

Good luck!

While programming is imperative (how to x) rather than declarative (x = y) (mathematics), it deceives me from the idea that I won't have to touch a lot of math.

To my dismay, I now realize that in order for the imperative process to be correct, I have to do immense amounts of declarative thinking (algorithms, proofs,..). That which is written has to work.

Since its summer I started a new project and decided to make a Linux app. I started to learn Gtk and when it comes to language there was bunch of options. The most supported one was C but I don't prefer C on GUI apps because of you don't have classes and other things related to OOP(I know there are workarounds for OOP in C but I don't prefer). Then there was Python. Python is great for little sized projects and writing Python is full of pleasure. However when things getting bigger, a language that is more verbose and more declarative is my preference. So I found Vala language. Its syntax is very close to C# and that was a good thing for me since I like C# syntax. Their documentation was also good enough so I started to use it and I enjoyed so much. I have found the language that has good and scalable syntax and furthermore, enjoying to write. But I see Vala is not so popular language besides there is no exact replacement for this language on open source community. I heard that it has a lot of bugs itself and that was the main reason of it but I think this language deserves to be more popular.

In Alpro soy milk range, the original one is often overlooked. There are ridiculously tasty soy vanilla, soy almond and professional coconut. But being THAT sensitive I can always distinguish like yea, here’s the soy and here’s the coconut purée. This always prevented me from focusing on just soy and how complex it really is.

So I tried the original soy milk and yes, the purest form was hidden in plain sight all this time. It’s just soy, pure soy, like a pokimane subreddit meetup. I love it.

It’s a moment of a purist finding a pure thing. This is the IDEA of soy milk, like Prolog is the idea of a declarative language.

Wanted to discuss about this AMP framework by Google. I have developed with it for my company and have been having mixed feelings about it.

On one end, it gives you the power of Google cache, declarative layout and all.
But still, it seems to be too restrictive and filled with bizarre rules that often could have been avoided if they just made guidelines for normal "web pages" to be better and not yet another framework to build "AMP pages".

One more (and probably the biggest) thing. AMP is Open Source... But can it be really considered Open if the biggest player in its development is a single corporation?