revvx

> Supposing you literally “just write code,” there’s a ceiling to how much impact you can have

I'm don't see why a single person can't have a ton of impact merely as a coder.

I mean, this whole website is dedicated to (mostly) discussing tech startups and how (mostly) software disrupts and help scale outdated business models. Isn't the software-making business model also ripe for that disruption, at least in a smaller scale?

Couldn't a single coder (or a small team) help an organization get some competitive advantage when it comes to tools. Or even programming languages? Why does ALL the innovation has to come from outside in our industry?

Fred Brooks talks about "The Toolsmith" it the "Surgical Team" chapter in Mythical Man-Month, and how "the tool-builder will often construct specialized utilities, catalogued procedures, macro libraries".

Facebook made React, Apple made Swift, Google has dozens of those. And the teams doing those tools aren't that huge. Why don't we try new things instead of letting good coders go away or making them stop coding?

A solution for that is promoting the best developers that don't want to manage into technical leadership roles. They can still create things and impact the team positively, and will not suffer with managerial tasks.

> if Willie Mays played for your baseball team would you promote him to manager?

I don't know who Willie Mays is (not in the US), but I'm pretty sure elite athletes get top notch salaries, a lot of times bigger than managers or coaches.

People shouldn't need hierarchy just to remain professional and follow someone else's lead.

> The CPU was spending 15-20% of its time every frame recreating the UI's vertex buffer.

Not saying it is easy, but it's possible to optimize and cache vertex buffers by using something similar to React's VDOM.

Games (normally) re-render the whole scene every frame.

ImGUI exposes that to their API users: you have to re-render and check for clicks on every frame. The code looks like React, (but not as optimized, it re-renders every frame!), and normally you have to keep state by yourself. Code example: [1].

Retained Mode is closer to the DOM, Cocoa or WPF: you create objects and there's an abstraction between the API and the renderer: they get re-rendered every frame for you. Componentes normally have events and state by themselves. Sometimes there's a visual editor too.

The main difference is the API. One is lower level than the other. In practice, the APIs aren't that different, except when it comes to event handling.

[1] - https://docs.unity3d.com/Manual/gui-Basics.html

Immer.js (a library to work on data structures, not a framework) uses a similar concept, using Proxies.

The gist of Immer is that your framework needs immutable structures, but you want to interact with them imperatively.

It's very interesting, and a reversal of the traditional "functional core, imperative shell" architecture.

https://github.com/immerjs/immer

It's not exactly a bad thing, it's just that you're using a hammer (class) when what you actually need is a screwdriver (struct/record).

Abusing getters/setters is breaking encapsulation (I said abusing, light use is ok). If you're just going to expose all the innards of the class, why start with a Class?

The whole point of object orientation to put data and behavior together. That's probably the only thing that both the C++/Java and the Smalltalk camp agrees on.

Separating data and the behavior into two different classes breaks that. You're effectively making two classes, each with "half of a responsibility". I can argue that this breaks SRP and the Demeter principle in one go.

Another thing: Abuse of getters/setters is often a symptom of procedural code disguised as OOP code. If you're not going to use what is probably the single biggest advantages of OOP, why use it at all?

-

Here's an answer that elaborates on this that I like:

https://softwareengineering.stackexchange.com/questions/2180...

I don't think it has anything to do with dynamic or static typing, but more to do with teams, libraries and program design.

I've had terrible experiences with complexity and verbosity in Ruby and Python codebases, which are dynamically typed. On the other hand, I worked with super expressive and simple to work codebases in C# and Haskell. And I had the opposite experience as well in other times.

It is absolutely possible to have the cake and eat it in this regard.

In fact I'd consider Haskell way more expressive than any dynamic language I ever worked with.

I agree with your points.

You can do great things without all that tooling if you're able to only target modern browsers (>90% of the market):

- https://www.npmjs.com/package/htm#example

- https://www.npmjs.com/package/preactz#example-app-with-unpkg

> what does late binding by you?

Some things that come to mind:

- Abstract classes/methods, and interfaces. This is implemented using vtables in C++.

- Ability to send messages asynchronously, or to other computers, without exposing the details of such things. You just call a method in another class and let your dispatcher handle it. There was a whole industry built around this concept in the 90s: CORBA, DCOM, SOAP. And Erlang, of course, in a different way.

- Ability to change the class/object during runtime. Like you can with Javascript and Lua, calling `object.method = `. Javascript was inspired by Self (a dialect of Smalltalk), so there's that lineage. Other languages like Python and Ruby allow it too.

- Ability to use the message passing mechanism to capture messages and answer them. Similar to Ruby's "method_missing" and ES6 Proxies in Javascript. This is super useful for DSLs and a great abstraction to work with. Check this out: http://npmjs.com/package/domz

Remember that you can have some of those things without dynamic typing (Objective-C).

Alan suggested "server-oriented programming" in Quora:

https://www.quora.com/What-is-Alan-Kays-definition-of-Object...

Alan Kay answered that himself! :)

https://www.quora.com/What-is-the-difference-between-Alan-Ka...

> I realize that I'm picking on Java, but Java is the biggest target when it comes with OOP as the industry understands it. I personally cannot stand having to create fifty files do to something like a database wrapper, and in Java that's effectively the only way to program.

I had this experience once in a Rails shop.

A simple database table mapped to a CRUD API endpoint would take from five to ten files. That amounted to about 500 lines, plus a lot of tests for each class.

I never really understood why programming became so verbose. In an ideal world I'd have a declarative API that mapped the table to the API for me automatically. In a realistic timeline I'd just use the traditional Rails approach and be happy. But the people working there preferred to use complicated patterns and a lot of boilerplate before they were needed, even though the project was perpetually late and riddled with bugs. I wish we could give a chance to simpler ways of solving problems.

I'm the one mentioning C++. To anyone familiar with both styles, Joe Armstrong is clearly not talking about Smalltalk-style OOP in his essay, he's talking about C++/Java/etc style. And later on he only praised Smalltalk-style OOP.

And sorry, by a "change in mindset in our industry regarding OOP" I mean that it became commonplace to criticize C++-style OOP. Not that everyone stopped programming in that style. Maybe there's a better way to phrase it?

In my experience, a sufficiently rich type system is extremely similar to TDD in this regard.

Both give you super fast feedback and a lot of issues can be solved before you finally launch your software for the first time. But neither will save you from bad design or misunderstanding your requirements.

In my experience, getter/setter abuse is always an attempt to use classes as a structs/records.

I wonder if we had different syntax for those cases we'd have less of them.

But then, again, it's very convenient to be able to add a method to a class that was previously a dumb struct.

IME the thing with getters and setters is that everyone is doing it (inertia) and that other options either suck (syntactically) or break the "everything is a class" constraint.

Ruby is far from being my favorite language, but I like how Structs "solve" the getter/setter problem in it:

    my_struct = Struct.new(:field_one, :field_two)

It doesn't clutter your code with multiple lines of boilerplate, and it returns a regular class for you to use, not breaking the "everything is a class" constraint.

Thanks for that. That resonates a lot with me. It makes me feel better realizing that I'm not alone in thinking that.

Recent writings by Joe Armstrong are also resonate with me the same way.

I don't think that's what happened.

Joe Armstrong was criticizing C++-style OOP when he wrote his critique.

After he learned more about Alan Kay's view on OOP, he decided that Erlang is closer to Alan Kay's OOP and he approves that specific flavor of OOP.

He didn't change his stance based on popularity. He changed his stance because in the 80s/90s the term "OOP" was synonymous with C++-style-OOP, but that changed in the 2000s thanks to 1) C++-style OOP criticism became commonplace in our industry (thanks to people like Joe Armstrong) and 2) an increase of popularity languages like Ruby and Objective-C (which are closer to Smalltalk) and even much-maligned concepts such as DCOM, SOA and CORBA.

> Isn't a method call a message, and the return value a message back?

It is!

In my view, the point that Alan Kay and Joe Armstrong are trying to make is that languages like C++/Java/C# etc have very limited message passing abilities.

Alan Kay uses the term "late binding". In Kay's opinion, "extreme late binding" is one of the most important aspects of his OOP [1], even more important than polymorphism. Extreme late binding basically means letting the object decide what it's gonna do with a message.

This is what languages like Objective-C and Ruby do: deciding what to do after a method is dispatched always happen during runtime. You can send a message that does not exist and have the class answer to it (method_missing in Ruby); you can send a message to an invalid object and it will respond with nil (Objective-C, IIRC); you can delegate everything but some messages to a third object; you can even send a message to a class running in other computer (CORBA, DCOM).

In C++, for example, the only kind of late binding that you have is abstract classes and vtables.

-

> Or is it that "true OO" must be asynchronous?

It doesn't have to be asynchronous, but in Alan Kay's world, the asynchronous part of messaging part should be handled by that "dispatcher", rather than putting extra code in the sender or the receiver.

I don't remember Alan Kay elaborating on it, but he discusses a bit about this "interstitial" part of OOP systems in [2]

-

[1] - https://en.wikipedia.org/wiki/Late_binding

[2] - http://wiki.c2.com/?AlanKayOnMessaging

React with class-components is very OOP.

Hooks are closer to functional programming, though (but were released only a couple months ago)

I think you're confusing procedural with functional. Modern Javascript has some support for functional idioms, but C is as far from functional programming as you get (nothing wrong with that, of course)

Similar thing happened to Wilko Johnson, guitar player in Dr. Feelgood and actor in Game of Thrones. But in the end he surprisingly ended up surviving his terminal cancer, thanks to his doctors.

https://en.wikipedia.org/wiki/Wilko_Johnson#Cancer

Helping organize small music concerts and festivals and recording local indie bands. Mostly friends or friends of friends.

I've been doing it since I was a teen, before I started programming, and the first significant amount of money I made was after I invested all my savings in a small festival I organized with my friends.

As for recording, it's been a fun ride because equipment go so much better and accessible since I started 15 years ago. For recording, having portable stuff is nice, but affording to pick studios because of the room instead of the equipment was a real game changer.

You can ALWAYS negotiate before you accept the offer.

"Yeah thanks, but that offer is not enough for me to leave my current job. I need at least X more. Let me know if you're interested."

(In fact, you can negotiate even AFTER you accept it!)

It is a verbal promise, not a contract. They just broke it.

They were unprofessional.

Yeah, the recruiter told me the whole hiring team thought I was bullshitting about my salary.

It was a problematic company from the get go. I was cold called and the recruiter was very insistent. Their engineers were very unprofessional during the technical interview and complained A LOT about technical debt left by past co-workers during the interview.

Now, when I tell recruiters my minimum salary I refer recruiters to Glassdoor, just in case they doubt me.

Regarding the "!! Select text -> type in correction -> people see change.", he was putting that in motion with his personal blog:

https://joearms.github.io/

> He told me...he could match that.

I think he was just honest.

In those cases, I'd answer with "Ok but I need X% more because of the commute and the hassle of changing jobs".

It was an HR recruiter that works for the company, not an independent recruiter.

I agree about the incompetence part, though. Terrible waste of time for everyone involved.

But that's exactly what I did? Sorry, I didn't phrase it right.

My non-negotiable requirement was 20% more than I was getting. I gave a hard number and they said "yeah we can give that" before the interview.

However the recruiter just assumed I was bluffing and went ahead with that colossal waste of time.