91–100 of 148 posts
I really appreciate the thing called "abstraction" not only in Software Designer but also in general, it often takes large amount of time to be an expert in the field before one can create/design an abstraction out of the problems.
Earlier quoted context omitted.
Are you listening, Java people?!
I've come to realize the problem with Java is not the programmers. Most of the strategies they want to use are legitimate improvements in flexibility, and in other languages they do make the source code smaller. Java is simply a poor vehicle. Java forces programmers to choose a point on the spectrum of "more flexibility" "smaller program size". In languages like Lisp, by contrast, the more generic a function is, the…
Suppose I have a thing I need to do, called X. I write a program to do X. Then later I need to do Y, and I realize that if I think of X as (A + B) and Y as (A + C), then if I re-organize to have one segment of code to do A, then wrap it so that B or C happen afterwards based on context (whether that be polymorphism or different scripts or procedural flow control, whatever the branching mechanism), then I've achieved abstracting A out into its own standalone piece, hopefully because A describes some independent process that makes sense to stand alone. Therefore, I've made it so that B and C's concerns can be separated from A's concerns, and X and Y are now just compositions of these nice linkable, re-usable pieces.
No matter what language you pick, if you want program X to do the same thing, the X-iness needs to still live somewhere. In Java that might look like going from two classes (X and Y) to three classes (A, X and Y). In lisp it might be three functions. I feel like in your example just now, you're comparing A from lisp to X in Java.
Please correct me if I'm wrong. I just feel like when you consider a program holistically, more genericness, and therefore more nuanced program description, always results in more text.
I agree that Java is more verbose than say, lisp or python. But I think that syntactic verbosity is really limited to a per-statement or per-block scope. I disagree that the language itself is responsible for verbosity in the higher-order composition of these pieces, weighted for, of course, how dynamic each language is. I hope you won't fault Java for not having the terseness of Ruby when Ruby doesn't have the performance or rigidity of Java.
I think you only really make order-of-magnitude leaps in reducing verbosity/excess abstraction by sliding up or down the dynamicness vs performance/safety spectrum. Tit-for-tat, I think an equivalent Ruby and Python program will be about the same size, and an equivalent Java and C# program will be about the same size.
The huge asterisk to all this is, of course, the humans actually writing the programs. Obviously a sufficiently motivated developer will be able to make an abstract mess out of any language.
An "illustrated guide" shouldn't mean shallow content without any practical advice decorated with semi relevant stock photos.
Earlier quoted context omitted.
A good thing is making those mistakes but never landing most of them into production. It will boost your progress immensely if you have somebody available to critique and guide you in the right direction. Making mistakes but learning only a month later when significant amount of time has been wasted in wrong things won't make you any smarter than figuring them out before-hand. Also you'll be a lot less confident afte…
> ...making those mistakes but never landing most of them into production. It will boost your progress immensely if you have somebody available to critique and guide... I mostly agree. But the consequences of what "landing a mistake in production" actually means depends on a lot on the environment and the project. Does it mean the deliverable has a hiccup and skids past the deadline a few days? Does it mean there's a…
Earlier quoted context omitted.
I agree with you. From my perspective (I'm a BA, non-developer), for sure I agree that every abstraction should be elegant. But how to define "elegant"? I probably need years and years of GOOD experience and code reading to get that point.
Elegant is one of the more complicated terms in software engineering. Depending on who is using the word, it can mean some combination of: efficiently designed, easily understood (regardless of complexity), surprisingly brilliant, fault tolerant in a clean manner, very insightful on a problem area, etc. Sometimes code is elegant relative to what has been in place, so going from highly complex to slightly complex migh…
I think your description of elegant is good. One more aspect of elegant is: doing all those things you list here in a manner idiomatic to the language and paradigm you're working in. So for example, regardless of how efficient or easily understood your solution is, if you're using loops and mutation in a functional language, it would rarely be considered "elegant" by experienced people working in that paradigm (that's not to say that loops and mutation aren't very occasionally a good idea in functional languages, but they'd still not be considered elegant).
What happened to avoid listical titles? > If the title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids."
Earlier quoted context omitted.
It is always hard to learn from people several levels ahead of you. What they do is amazing and impenetrable. What they say seems to make little sense. You lack too much of the common background. This is why, when I find myself in a situation like that, I try hard to understand the point. Why do these people do these strange things? What do they mean by saying these sentences that seem detached from the practice? Emp…
Don't spend too much time trying to decipher people who claim to be "levels ahead of you." If they actually understood the topic, they could easily explain it in a way that a novice can understand.
Earlier quoted context omitted.
Are you listening, Java people?!
I've come to realize the problem with Java is not the programmers. Most of the strategies they want to use are legitimate improvements in flexibility, and in other languages they do make the source code smaller. Java is simply a poor vehicle. Java forces programmers to choose a point on the spectrum of "more flexibility" "smaller program size". In languages like Lisp, by contrast, the more generic a function is, the…
Another problem is that Java lacks type aliases. If your data have a complicated type like List>>, you have to copy-paste this type everywhere, without a way to name it succinctly.
On top of that, Java lacks type inference, even the weakest syntactic form. This is why you often need to write a long declarations, so long that they exceed the space you may have saved by factoring out a small function. Lombok and the diamond operator somehow alleviate that, but not completely.
The lack of pattern matching, or named arguments, or null vs Optional vs Result, goes without saying.
This makes Java a very verbose language, even if the logic of your code is streamlined and economical. In many standard library APIs, it is not.
(Hence Kotlin, obviously, or Scala if you can tolerate the build times.)
Earlier quoted context omitted.
Don't spend too much time trying to decipher people who claim to be "levels ahead of you." If they actually understood the topic, they could easily explain it in a way that a novice can understand.
Some of the things that I know about would take months or years to explain to a novice in such a way that they would understand what I was talking about. Not by way of metaphor or by analogy, but to truly see things the way I'm seeing them when I give an explanation. We can try to meet halfway but the requisite knowledge may be lacking. In effect this is what I'm doing when I coach interns and juniors -- giving them…