The thin client... The future of computing?

[rockytopva]

I would look for most computers to be of this size in the near future. They may even create a very small solid state hard drive with the capacity to store a lot of data.

 

[C-Man]

Unfortunately, they'll never be as powerful or as easy to work with as a full-size tower. Advancements in miniaturization are slowing down and will eventually stop in a few years, perhaps a decade, as it becomes physically impossible to make a transistor any smaller. Hardware will have to become larger and more power-hungry in order to keep the same advances in speed that are expected.

It won't be dramatically larger than it is now, at least not at first, but larger enough that thin clients like that will be slow and impractical by comparison to mainstream hardware.

 

[morse86]

Thin client historically means a "dumb terminal" used to connect to a mainframe. Everything is stored in the mainframe.

We tried this "cloud computing" in the 70s, it failed.


Anyways, we got really fast hardware now. The problem is, software is declining in performance because of programming fads.

 

[anavah]

Would you care to elaborate on what you mean by "programming fads"? I am interested

 

[morse86]

Would you care to elaborate on what you mean by "programming fads"? I am interested

Like:
Object-oriented programming
Agile programming
Separation of concerns
MVC (model, view, controller)


These are all programming fads designed to maintain "job security".

 

[Cute Tink]

We have thin clients at my work. They are pretty unreliable (though that has gotten better over the last year). They seem to have issues with peripherals connected to the USB for long periods of time (like a DVD drive). While I think they are a decent idea, I think it might need a little more work before it's truly a solid technology.

But that's my experience not working with them directly.

 

[RDKirk]

Unfortunately, they'll never be as powerful or as easy to work with as a full-size tower. Advancements in miniaturization are slowing down and will eventually stop in a few years, perhaps a decade, as it becomes physically impossible to make a transistor any smaller. Hardware will have to become larger and more power-hungry in order to keep the same advances in speed that are expected.

It won't be dramatically larger than it is now, at least not at first, but larger enough that thin clients like that will be slow and impractical by comparison to mainstream hardware.

I think you're misunderstanding "thin client." "Thin client" means the software resides elsewhere--on a much larger and more powerful platform--than the user's hardware. The thin client application on the client machine is nothing more than display directions and maybe locally resident user data.

"Web based" is even further removed, with nothing of the application on the client machine and possibly not even user data.

I haven't yet seen a thin client that was as efficient as its traditional "fat client" version.

 

[WalksWithChrist]

We used thin clients for our end-users as general workstations and as cash registers for some years. We switched back to PCs. The thin clients were really junky basically. Lots of connection issues; very easy to knock offline. And they performed horribly. Slow as heck.

 

[RDKirk]

We used thin clients for our end-users as general workstations and as cash registers for some years. We switched back to PCs. The thin clients were really junky basically. Lots of connection issues; very easy to knock offline. And they performed horribly. Slow as heck.

In a former job position, I was managing a help desk. When the company switched from our fat client support application to a thin client, we actually had to hire three people to maintain our service levels. During the transition, we did a test and determined that entering the same information, the thin client took 50% longer than the fat client for every record.

One major reason was because the fat client only made a network call when opening a record and then when saving it. The thin client had to make network calls for every field in the record, even opening dropdowns.

 

[WalksWithChrist]

In a former job position, I was managing a help desk. When the company switched from our fat client support application to a thin client, we actually had to hire three people to maintain our service levels. During the transition, we did a test and determined that entering the same information, the thin client took 50% longer than the fat client for every record.

One major reason was because the fat client only made a network call when opening a record and then when saving it. The thin client had to make network calls for every field in the record, even opening dropdowns.

It seems like they are just not engineered/designed that well. I feel like if a decent thin client was designed, it would perform just fine.
The ones we used were so slow for Internet, it was unbelievable.

 

[dysert]

"Thin clients" worked great in the 80s and 90s. You had a cluster of mainframes (or super-minis) serving up disks and peripherals to a bunch of dumb terminals. And the total cost of ownership was lower than having dozens (or more) of PCs networked together. It's nice to think that we might be seeing history repeating itself.

 

[All4Christ]

Like:
Object-oriented programming
Agile programming
Separation of concerns
MVC (model, view, controller)


These are all programming fads designed to maintain "job security".

I strongly disagree with this. There are some applications where mainframes and procedural coding have their place, but in many applications, efficiency is drastically increased through use of one or more of the four "fads" you mentioned. I'm curious as to why you feel that they are fads, your reasoning behind why you believe they are designed to increase job security, and what programming styles you believe are not 'fads'. Could you explain your reasoning?

In regards to the OP, the others are correct about the misuse of 'thin client' terminology as well as C-Man's response on the miniaturization of technology.

 

[morse86]

There is nothing OOP solved. The problems were already solved by procedural programming, except people kept making the same mistakes. OOP results in too much high level abstractions and increases complexity. Concepts like cohesion, coupling, tiers....it's part of computer science...not OOP. It's become a religion now.


Simply put, OOP prevents the programmer from being the programmer.

Let me give a simple example:

Procedural:
string[][] topics = database.getTopics();
foreach(string[] topic in topics) {}

OOP:
public class Forum {}
public class Topic : IPost {}
public interface IPost {}
public static class ForumHandler {}
public static class TopicHandler {}
public static PageViewHandler {}
public static class DisplayTopics {}

 

[Cute Tink]

There is nothing OOP solved. The problems were already solved by procedural programming, except people kept making the same mistakes. OOP results in too much high level abstractions and increases complexity. Concepts like cohesion, coupling, tiers....it's part of computer science...not OOP. It's become a religion now.

I noticed this when I learned OOP. In one sense, I do get it and it makes some things easier if you take it from one program to the next, but as a means of programming something simple, it's very much overkill.

 

[inlight12]

Welcome to the future:
Minority

Majority

 

[inlight12]

Like:
Object-oriented programming
Agile programming
Separation of concerns
MVC (model, view, controller)


These are all programming fads designed to maintain "job security".

Completely agree. I tried many times to determine what is the purpose of OOP, but I think there is none. Any advantages it brings are completely negated by its disadvantages.

 

[theFijian]

There is nothing OOP solved. The problems were already solved by procedural programming, except people kept making the same mistakes. OOP results in too much high level abstractions and increases complexity. Concepts like cohesion, coupling, tiers....it's part of computer science...not OOP. It's become a religion now.


Simply put, OOP prevents the programmer from being the programmer.

Let me give a simple example:

Procedural:
string[][] topics = database.getTopics();
foreach(string[] topic in topics) {}

OOP:
public class Forum {}
public class Topic : IPost {}
public interface IPost {}
public static class ForumHandler {}
public static class TopicHandler {}
public static PageViewHandler {}
public static class DisplayTopics {}

You've taken an extreme example in an attempt to prove your point, and I suspect you know that if writing say, an n-tier system with multiple interfaces that writing only procedural code would be nigh on impossible not to mention horrible to maintain and debug. In reality there's nothing to stop a programmer from writing those two lines of code of yours as opposed to the more verbose 7 lines. A good programmer isn't a slave to their methodology, but they know when to be pragmatic and employ different techniques when time or other priorities allow.

 

[theFijian]

Completely agree. I tried many times to determine what is the purpose of OOP, but I think there is none. Any advantages it brings are completely negated by its disadvantages.

Better readability, maintainability and reusability straight off the top of my head.

 

[dysert]

Better readability, maintainability and reusability straight off the top of my head.

I disagree. A programmer can make any language readable, maintainable, and reusable -- or not, depending on the skill of the programmer. I wrote FORTRAN for many years that was readable, maintainable, and reusable. Now I'm forced to use OOP, and decipher various layers of abstraction and side effects. Having done it both ways for *many* years, I know from experience that OOP is usually harder to read, harder to understand, and harder to maintain.

OOP practically forces a programmer into a mold. Languages are just tools that should support the programmer, not templates that a programmer has to fit into.

 

[All4Christ]

I disagree. A programmer can make any language readable, maintainable, and reusable -- or not, depending on the skill of the programmer. I wrote FORTRAN for many years that was readable, maintainable, and reusable. Now I'm forced to use OOP, and decipher various layers of abstraction and side effects. Having done it both ways for *many* years, I know from experience that OOP is usually harder to read, harder to understand, and harder to maintain.

OOP practically forces a programmer into a mold. Languages are just tools that should support the programmer, not templates that a programmer has to fit into.

The key thing to remember is that programming is not a one size fits all. I've seen some cases where OOP is helpful in it's full implementation, others where is my is helpful to use in moderation. Other programs, I can understand reasoning for not using OOP. That said, reusability is a must in my opinion across the board.

One example where I definitely would use OOP would be JAVA with Spring and Hibernate. The annotation capabilities in a large application greatly enhance the efficiency, as well as coding for the database through the POJOs in JAVA. Using the interfaces is extremely helpful. That said, I am selective for the extent of OOP concepts that I use. Also, it is very helpful for test driven development.

I've also developed for years with both procedural and OOP. The most important thing to remember is that programming is not one size fits all. Flexibility in the tools and concepts you use is critical. Many factors determine what is most efficient for the particular application being developed.