# Tag Info

208

Simple solutions are better for long-term maintenance. And it's not always just about language familiarity. A complex line (or lines) takes time to figure out even if you're an expert in the given language. You open up a file and start reading: "ok, simple, simple, got it, yep, WTF?!" Your brain comes to a screeching halt and you now have to stop and ...

163

Basically we want things to behave sensibly. Consider the following problem: I am given a group of rectangles and I want to increase their area by 10%. So what I do is I set the length of the rectangle to 1.1 times what it was before. public void IncreaseRectangleSizeByTenPercent(IEnumerable<Rectangle> rectangles) { foreach(var rectangle in ...

102

KISS Principle Keep it simple, stupid. Clever solutions are great, but often the simplest straight forward solution is best. “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” Brian Kernighan

83

Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it. -- Alan Perlis

74

I don't think it's the use of abstractions per se that's objectionable. There are two other possible explanations. One is that abstractions are all leaky at one time or another. If you give the impression, correct or not, that you don't understand the underlying fundamentals, that might reflect poorly in an interview. The other possible explanation is ...

60

The very first words of TC++PL4: All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection. – David J. Wheeler (David Wheeler was my thesis advisor. The quote without the important last line is sometimes called "The first law of Computer Science.")

45

Use a dispatch table. This is a table containing pairs ("message part", pointer-to-function). The dispatcher then will look like this (in pseudo code): for each (row in dispatchTable) { if(message.toLowerCase().startsWith(row.messagePart)) { row.theFunction(message); break; } } (the equalsIgnoreCase can be handled as a ...

44

The reason for hiding the details isn't to keep the details hidden; it's to make it possible to modify the implementation without breaking dependent code. Imagine that you've got a list of objects, and each object has a Name property and other data. And a lot of times, you need to find an item in the list whose Name matches a certain string. The obvious ...

40

Eventually, I thought you will become a better programmer knowing this because you'll know what's happening rather than assuming that everything is magic. These are not contradictory things. I have no idea how to pave a road, but I know that it is not magic. But a month ago, I came across this book called Structure and Interpretation of Computer ...

38

The answer to "Can you define what a programming abstraction is more or less mathematically?" is "no." Abstraction is not a mathematical concept. It would be like asking someone to explain the color of a lemon mathematically. If you want a good definition though: abstraction is the process of moving from a specific idea to a more general one. For example, ...

31

ADT is to an interface (what it does) what a data structure is to a class (how it does it). A few examples: ADT: List DS: ArrayList, LinkedList... ADT: Map DS: HashMap, TreeMap... I guess you get the point.

31

I'd probably do something like this: public interface Command { boolean matches(String message); void execute(String channel, String sender, String login, String hostname, String message); } Then you can have every command implement this interface, and return true when it matches the message. List<Command> activeCommands = new ...

31

I know why abstraction is great, but doesn't that prevent you from learning how computers work? Certainly not. If you want to understand the abstractions at work, then study those abstractions. If you want to understand the low-level technical details of a real, physical, computer then study those details. If you want to understand both, study both. (In my ...

30

The best solution is not always the most clever solution. Sometimes simple solutions are equally good. In Software you always need to think in terms of maintainability. If a piece of code is too clever for someone who is going to maintain it, I would say that cleverness is not worth it.

30

I think you have some misconceptions about the history of computing. The first abstraction (in 1936) was, in fact, Alonzo Church's Lambda Calculus, which is the foundation for the concept of high-order functions and all of the functional languages that followed. It directly inspired Lisp (the second oldest high-level programming language, created in 1959), ...

29

Some .NET programmers, particularly those coming from either a classic VB/ASP or a C++ background, don't like new stuff like LINQ, MVC and Entity Framework. Based on what I've observed, the ex-VB'ers in this group are likely to still be using a data access layers and other code originally written 10+ years ago. They'll also use old buzzwords like "n-tier" ...

29

It seems to me that you misunderstand abstractions and code reuse. The whole software development industry is built on abstractions. Just because not using them, i.e. avoiding using frameworks, libraries and in general code which is not written in-house, would increase the cost you need to produce a piece of software by hundred, thousand, probably even more....

27

Which to listen to and how often? Never abstract until you must. In Java, for example, you must use interfaces. They're an abstraction. In Python you don't have interfaces, you have Duck Typing, and you don't need towering levels of abstraction. So you just don't. What is your strategy for this? Don't abstract until you've written it three ...

27

If all your objects are immutable, there is no problem. Every Square is also a Rectangle. All the properties of a Rectangle are also properties of a Square. The problem begins when you add the ability to modify the objects. Or really - when you start passing arguments to the object, not just reading property getters. There are modifications that you can do ...

26

To quote Brian Kernighan: “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

22

cleverness is a tool; by itself it is not harmful. It only becomes harmful in context where it is not necessary.

22

No, abstractions don't prevent you from understanding how things work. Abstractions allow you to understand why (to what end) things work the way they do. First off, let's make one thing clear: pretty much everything you've ever known is at a level of abstraction. Java is an abstraction, C++ is an abstraction, C is an abstraction, x86 is an abstraction, ...

21

I categorically disagree with most of the answers. This is my answer: Given two sets G and H, a Galois connection (alpha, beta) can be defined between them, and one can be said to be a concretization of the other; reverse the connection, and one is an abstraction of the other. The functions are a concretization function and an abstraction function. ...

21

A shim is typically something written specifically to maintain backwards compatibility. For example, if you have two versions of an API, version 1 and version 2, then rather than maintaining version 1 independently of version 2, you might write a shim that intercepts calls to version 1 of the API, translates the parameters to what version 2 requires, and ...

20

Frameworks can be tricky indeed. Problems can easily arise when a framework is too "opinionated", i.e. when it really prefers one particular style of application and all parts are geared towards supporting this particular style. For instance, if the framework completely abstracts the authentication process of a user by allowing you to just add one component,...

20

Yes, definitely. The thing is, no abstraction is perfect. All of the details of the layer that abstractions sit atop are there for a reason, and it can simplify a lot of things, but if that complexity wasn't necessary at some point, it probably wouldn't be there in the first place. And that means that at some point, every abstraction is going to leak in ...

20

Why is programming not like this? Why do you think that? Actually, programming is like that. Of course, you can't do that in assembler. Therefore we invented languages that can be more similiar to the human thoughts. Good programmers program alike examples you gave. But it is not as easy. First you have to understand, what the requirement is. This is hard ...

19

Ah, YAGNI. The most abused concept of programming. There's a difference between making your code generic and doing extra work. Should you spend extra time to make your code loosely coupled and easily adapted to do other things? Absolutely. Should you spend time implementing unneeded functionality? No. Should you spend time making your code work with ...

18

You write concrete code first. You write abstract code when you must because it simplifies concrete code. It easiest to start with concrete and find the abstractions after studying what's similar and different about the concrete.

18

The basic data is structured the same in pretty much any paradigm. You're going to have a Student, a Course, etc. whether it's an object, a struct, a record, or whatever. The difference with OOP isn't how the data is structured, it's how the functions are structured. I actually find functional programs much more closely match how I think about a problem. ...

Only top voted, non community-wiki answers of a minimum length are eligible