Live data from Hacker News

Growing object-oriented software vs. what I would do

dpc.pw

81–90 of 99 posts

Re: Growing object-oriented software vs. what I would do

#81
post #69

Earlier quoted context omitted.

>Javascript values programming velocity, accessibility to new programmers and simplicity. You are joking aren't you?

No, I'm not. Or at least, not as I see it. How would you describe javascript's values, compared to other languages? This is a great chart / explanation of this kind of thinking from Bryan Cantrill: https://www.youtube.com/watch?v=2wZ1pCpJUIM

No integers. What's the difference between == and ===. Why do I need to learn two ways to declare a class. What module system should I use and why are they all different. Why isn't there much of a standard library. WTF is Grunt, NPM, etc. Just explain 'this' to me again. What is the distinction between null and undefined. What is the difference between for/of and for/in.

JavaScript is far from accessible to new users neither is it simple.

Re: Growing object-oriented software vs. what I would do

#82
post #57
post #56

Earlier quoted context omitted.

> In Java it would be a nest of SortComparator interfaces and SortAlgorithm implementors, which would act to hide the algorithm itself. That is odd because when I look at the Java style, DualPivotQuicksort [1], it seems that the language authors did not do that. This is so very strange! Their methods are long, complex, and highly documented. Maybe they must be really incompetent Java programmers? I mean, they did put…

The "enterprise" programming culture which has emerged around Java doesn't impinge on all java code. But it is still a real thing. The fact that openjdk authors can rise above it and write clean, reusable Java code is obviously good. The fact that there is something that needs to be risen above is unfortunate. I think the same about Javascript, though the specifics are different. I've been writing JS for years, but I…

A language's core values is not determined by a small, vocal, subculture of its ecosystem. In Java's case, it was set early on to be a "blue collar" language [1]. If programmers fail to follow the spirit of the language then it will be awkward.

"So, how does Java feel? Java feels playful and flexible. You can build things with it that are themselves flexible. Java feels deterministic. You feel like it’s going to do what you ask it to do. It feels fairly nonthreatening in that you can just try something and you’ll quickly get an error message if it’s crazy. It feels pretty rich. We tried hard to have a fairly large class library straight out of the box. By and large, it feels like you can just sit down and write code."

Please do not push the programming community towards a tribal, us vs them, hostile environment where one belittles their neighbor. We can have interesting, fun, insightful technical debates! There's no reason to devolve into bigotry to "win" an argument, it's a lot more fun to learn from each other and do cool, new things.

[1] https://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java...

Re: Growing object-oriented software vs. what I would do

#83
post #69

Earlier quoted context omitted.

No, I'm not. Or at least, not as I see it. How would you describe javascript's values, compared to other languages? This is a great chart / explanation of this kind of thinking from Bryan Cantrill: https://www.youtube.com/watch?v=2wZ1pCpJUIM

No integers. What's the difference between == and ===. Why do I need to learn two ways to declare a class. What module system should I use and why are they all different. Why isn't there much of a standard library. WTF is Grunt, NPM, etc. Just explain 'this' to me again. What is the distinction between null and undefined. What is the difference between for/of and for/in. JavaScript is far from accessible to new users…

I agree with most of your points. But the distinction between null and undefined is an important one. Its absence is a legitimate complaint about SQL.

Re: Growing object-oriented software vs. what I would do

#84
post #78

Earlier quoted context omitted.

> Doing this doesn't hurt. There's nothing stupid about it unless you coded everything in a way where it's NOT modular. It does. If I open up an arbitrary Ruby on Rails app for example, it is going to be easier to navigate for example a super fat model file than it is to navigate one that has been divided up into 10s of helpers and companion modules. There are similar scenarios in every other language. Extracting cod…

>Extracting code and moving it somewhere else can truly be a death by a thousand cuts. This is not what I mean by modularity. Let me be more specific. The code CAN be seperated and it can be recombined without a structural code rewrite. That is what I mean by modularity. Actually dividing code up and organizing it among different files is an opinionated organization scheme and NOT what I'm talking about. When you do…

Exactly, and what I'm saying is probably over 50% of the time people modularize code, they aren't actually modularizing it in the good sense you are talking about, but in the bad sense where they are just placating the linter without putting any thought into it and calling it "modularizing".

I'm all for modular code and interfaces, but linting rules like "functions must be a maximum of 15 lines long" are stupid and lead to stupid code. That's what my OP was about.

Re: Growing object-oriented software vs. what I would do

#85
post #82
post #57

Earlier quoted context omitted.

The "enterprise" programming culture which has emerged around Java doesn't impinge on all java code. But it is still a real thing. The fact that openjdk authors can rise above it and write clean, reusable Java code is obviously good. The fact that there is something that needs to be risen above is unfortunate. I think the same about Javascript, though the specifics are different. I've been writing JS for years, but I…

A language's core values is not determined by a small, vocal, subculture of its ecosystem. In Java's case, it was set early on to be a "blue collar" language [1]. If programmers fail to follow the spirit of the language then it will be awkward. "So, how does Java feel? Java feels playful and flexible. You can build things with it that are themselves flexible. Java feels deterministic. You feel like it’s going to do w…

I don’t see it as winning and losing. I see it as deciding where to stand and where to contribute in my technical life. How do you personally trade off velocity (code fast) vs correctness, completeness or performance? Javascript generally values velocity over generalisability. (“It’s better to implement something quickly and worry about adapting it to other problems later”) compared to most Java code. It’s not necessarily better and worse. It’s a question of fittedness with your own values and the values of your project.

If you consistently write code which fights the ecosystem your code is written inside of, it’s quite painful. Writing Lua without ever blocking is hard. Writing javascript with large, deep class hierarchies is awkward. I’ve seen people write pure functional Java, but if that’s what you’re into you should probably consider just using a different language.

And to name it, Java does not feel playful and flexible to me. Not compared to ruby, Haskell, python and javascript.

Re: Growing object-oriented software vs. what I would do

#86
post #53

Earlier quoted context omitted.

Right. The problem I've seen way too much is modularizing code too early in its lifecycle. This mistake seems to happen a lot by smart programmers who are inexperienced. The instinct seems to be that they want hinges in their code, so their code can adapt and be reusable between projects. But they don't actually know where the hinges should go, because they don't need them yet. So they just put hinges all over the pl…

> Right. The problem I've seen way too much is modularizing code too early in its lifecycle. This mistake seems to happen a lot by smart programmers who are inexperienced. I don't see this as bad. Modularization protects against an uncertain future. Most code that's modularized is only used once and this Looks bad only because you haven't seen the alternative of what could have happened if code wasn't modularized. No…

> Code is rarely rewritten until it's at a point where it's horrible than it takes a massive engineering effort to rewrite and even this rewrite could be wrong.

This is your problem, right here. Your instincts know when refractors and rewrites are appropriate. But if you live in a corporate culture where those things are never allowed to happen, of course you’re going to run into problems. Premature modularity is a poor man’s substitute for simple-then-refactor. It’s not a good process.

Re: Growing object-oriented software vs. what I would do

#87
post #69

Earlier quoted context omitted.

No, I'm not. Or at least, not as I see it. How would you describe javascript's values, compared to other languages? This is a great chart / explanation of this kind of thinking from Bryan Cantrill: https://www.youtube.com/watch?v=2wZ1pCpJUIM

No integers. What's the difference between == and ===. Why do I need to learn two ways to declare a class. What module system should I use and why are they all different. Why isn't there much of a standard library. WTF is Grunt, NPM, etc. Just explain 'this' to me again. What is the distinction between null and undefined. What is the difference between for/of and for/in. JavaScript is far from accessible to new users…

You're arguing that javascript doesn't succeed at being accessible to new programmers. I'm not arguing that. I'm saying that javascript nominally values about being accessible to new programmers. There are way more novice programmers using javascript than (almost?) any other language. This isn't an accident.

Re: Growing object-oriented software vs. what I would do

#88
post #61

Earlier quoted context omitted.

> If you can move your code and spread it around it is Modular by definition. For it to be truly modular, you also need to be able to use it in multiple contexts. I could take any random 5 lines of a complex function and pull it out into another function in another file, but that doesn't guarantee that this was a smart thing to do in that particular scenario. What I'm saying is there are tons of times when people do…

Right. If A and B are coupled so tightly that one cannot exist without the other, you don't really have two modules. You have one, AB. This is a common problem with improper application of the idea of modularity as well as OO concepts (in particular, breaking things into classes and thinking it creates a module). The latter is particularly pernicious in languages which don't have a clear separation between classes an…

Yes this. With I often think about questions like:

- Is this code useful in other contexts? Are there other contexts where I might want this? (Or someone else might want this?)

- Modules have a clear API boundary

- Modules can be described independently of the code which uses them

- Modules can (and should) have their own testing suite, independent of the test suite of the containing module

There's lots of examples; but you can kind of spot code like this in your projects. It has a property of being disentangled. "This just solves this one specific problem I have with strings / event emitters / random numbers / my database, separate from anything else I'm trying to do". "I kinda want to just document this code separate from the documentation of everything else". "I don't want to pull that whole library in, but can I just steal these 3 functions for this other project?"

Re: Growing object-oriented software vs. what I would do

#89
post #87

Earlier quoted context omitted.

No integers. What's the difference between == and ===. Why do I need to learn two ways to declare a class. What module system should I use and why are they all different. Why isn't there much of a standard library. WTF is Grunt, NPM, etc. Just explain 'this' to me again. What is the distinction between null and undefined. What is the difference between for/of and for/in. JavaScript is far from accessible to new users…

You're arguing that javascript doesn't succeed at being accessible to new programmers. I'm not arguing that. I'm saying that javascript nominally values about being accessible to new programmers. There are way more novice programmers using javascript than (almost?) any other language. This isn't an accident.

>This isn't an accident.

No, it's because it's effectively the only option in the browser. If you are going to write front end code then you will end up writing JavaScript in some form or another.

And being popular doesn't necessarily mean it is accessible nor simple. If it had been I doubt we would have seen Python becoming the dominant language in education.

Re: Growing object-oriented software vs. what I would do

#90
post #86

Earlier quoted context omitted.

> Right. The problem I've seen way too much is modularizing code too early in its lifecycle. This mistake seems to happen a lot by smart programmers who are inexperienced. I don't see this as bad. Modularization protects against an uncertain future. Most code that's modularized is only used once and this Looks bad only because you haven't seen the alternative of what could have happened if code wasn't modularized. No…

> Code is rarely rewritten until it's at a point where it's horrible than it takes a massive engineering effort to rewrite and even this rewrite could be wrong. This is your problem, right here. Your instincts know when refractors and rewrites are appropriate. But if you live in a corporate culture where those things are never allowed to happen, of course you’re going to run into problems. Premature modularity is a p…

>This is your problem, right here.

Nah. There's no problem here. This is the most common behavior in any place corporate or not. Humans resist change. However specifically for corporations, it is very very very rare for a company to allow a rewrite because of two reasons: First the company is often way to busy with creating features and solving problems then to do a code rewrite. Second it is in direct conflict with the bottom line. Business people don't see the necessity so there is huge resistance.

When a company allows a rewrite it's 99% of the time only to serve a new feature or fix a flaw that no longer can be ignored.

>Premature modularity is a poor man’s substitute for simple-then-refactor.

Do you have any evidence to back up your claim or is this just your opinion? Using words like "poor mans substitute" doesn't lend any credibility to your claim. For example I can say the opposite and we can go in circles forever: Writing unmodular code is a garbage technique only done by junior developers who can't abstract things and by a good number of senior developers who've never learned how to code properly in a modular way. These guys don't even understand the true meaning of a module.

See what I did there?

Post reply on HN