tag:blogger.com,1999:blog-5400765672405463592.post4208997895537764708..comments2024-03-28T06:33:03.563+00:00Comments on So, you want to write software?: Life Without ObjectsChris Turner (he/him)http://www.blogger.com/profile/09141108967081921802noreply@blogger.comBlogger51125tag:blogger.com,1999:blog-5400765672405463592.post-33934515142620895792022-03-04T23:21:56.446+00:002022-03-04T23:21:56.446+00:00Harrah's Joliet Casino & Hotel - JetBlue V...Harrah's Joliet Casino & Hotel - JetBlue Vacations<br />Harrah's Joliet <a href="https://www.mapyro.com/%ec%b2%ad%ec%a3%bc%ec%b6%9c%ec%9e%a5%ec%95%88%eb%a7%88%ea%b0%80%ec%9d%b4%eb%93%9c.html" rel="nofollow">청주 출장샵</a> Casino & <a href="https://www.mapyro.com/%eb%b6%80%ec%82%b0%ea%b4%91%ec%97%ad%ec%b6%9c%ec%9e%a5%eb%a7%88%ec%82%ac%ec%a7%80%ec%9d%b8%ea%b8%b0-%ec%88%9c%ec%9c%84.html" rel="nofollow">부산광역 출장샵</a> Hotel features luxurious hotel <a href="https://drmcd.com/%ed%8f%ac%ed%95%ad%ec%97%90-%eb%8c%80%ed%95%9c-%ec%9a%b0%ec%88%98%ed%95%9c%ec%b6%9c%ec%9e%a5%ec%95%88%eb%a7%88%eb%a6%ac%eb%b7%b0.html" rel="nofollow">포항 출장마사지</a> rooms <a href="https://www.mapyro.com/%ed%83%9c%eb%b0%b1%ec%97%90-%eb%8c%80%ed%95%9c-%ec%9a%b0%ec%88%98%ed%95%9c%ec%b6%9c%ec%9e%a5%eb%a7%88%ec%82%ac%ec%a7%80%eb%a6%ac%eb%b7%b0.html" rel="nofollow">태백 출장샵</a> and suites, sensuous spa treatments, delectable dining and exciting <a href="https://www.jtmhub.com/%eb%ac%b8%ea%b2%bd%ec%b6%9c%ec%9e%a5%ec%83%b5.html" rel="nofollow">문경 출장안마</a> casino gaming.ubrigynsyaccarinohttps://www.blogger.com/profile/06699019383891683695noreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-88018408043447654862014-06-26T20:51:34.130+01:002014-06-26T20:51:34.130+01:00I have 20+ years of OO with C++ then Java, J2EE et...I have 20+ years of OO with C++ then Java, J2EE etc so yes I have seen distasteful amounts of complexity and layering frameworks which bloat memory usage and distract from the users problem but no I dont want to live without objects.<br />OO Analysis and Design and Use Cases are definitely helpful for all stakeholders. GOF Design Patterns help to make solutions communicable as they provide shared language and concepts.<br />When your OO design needs to be implemented, then an OO language provides the most direct mapping. The strongly typed procedural sequential and synchronous nature of Java is sometimes a pain but a few classes (TreeSet, FutureTask,PriorityBlockingQueue) and design patterns (Whiteboard) can usually make it tolerable to overcome. I am investigating other languages such as Scala and computing models such as ROC (NetKernel) and deployment modules (OSGI)Anonymoushttps://www.blogger.com/profile/12869304419168175041noreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-69231663296421123592013-02-28T16:42:23.116+00:002013-02-28T16:42:23.116+00:00I already know that the government is supposed to ...I already know that the government is supposed to have evidence of a crime BEFORE indictment or arrest. <br />They are not supposed to count on squeezing a defendant that pled guilty into making some shit up against another defendant, <br />which would be the result of this <br /><br /><br /><a href="http://www.sexlifeandhannah.com/" rel="nofollow">books</a><br /><a href="http://www.sexlifeandhannah.com/" rel="nofollow">chick lit</a><br /><a href="http://www.sexlifeandhannah.com/" rel="nofollow">romance novels</a><br /><a href="http://www.sexlifeandhannah.com/" rel="nofollow">life</a><br /><a href="http://www.sexlifeandhannah.com/" rel="nofollow">romance</a>Anonymoushttps://www.blogger.com/profile/15900391746882849659noreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-18748750162078435532012-10-06T11:38:09.345+01:002012-10-06T11:38:09.345+01:00I recently released the availability calendar sour...I recently released the availability calendar source, but thought it would be useful to release the bulk email credential script I made for the client. <br /><br />Bulk email softwarehttp://emailmarketing.comm100.com/bulk-email.aspxnoreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-66358378551077701942012-08-30T19:52:27.688+01:002012-08-30T19:52:27.688+01:00After reading this comment, I was shocked for a wh...After reading this comment, I was shocked for a while whether I forgot how trait works since I'm still new. As luck would have it, noted in my reference and comment, trait is a beautiful feature for debugging purpose and make code compact.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-6546490589340739982012-06-21T05:32:50.455+01:002012-06-21T05:32:50.455+01:00Like all the info... Thanks you share it.
Churc...Like all the info... Thanks you share it.<br /><br /><br /><a href="http://www.abcfastdirectory.com" rel="nofollow"> Church Software </a>Waseemhttps://www.blogger.com/profile/13616982150624710742noreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-56374410281974673912012-06-21T05:32:12.042+01:002012-06-21T05:32:12.042+01:00Like all the info... Thanks you share it.Like all the info... Thanks you share it.Waseemhttps://www.blogger.com/profile/13616982150624710742noreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-26947587735856559552012-05-27T10:04:45.301+01:002012-05-27T10:04:45.301+01:00the disadvantage of the article is that it is poss...the disadvantage of the article is that it is possible to be understood by those only who already experienced the described troubles and made the same conclusion.<br /><br />best regards,<br />silly-sadAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-71607373846345282202012-05-27T05:55:58.783+01:002012-05-27T05:55:58.783+01:00same thoughts can be found at existentialtype.word...same thoughts can be found at existentialtype.wordpress.comAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-35172283609818500172012-05-26T15:59:20.356+01:002012-05-26T15:59:20.356+01:00Certainly not every good program is object-oriente...Certainly not every good program is object-oriented, and not every object-oriented program is good.<br /><br />Bjarne Stroustrupxkhttps://www.blogger.com/profile/02624245527220121446noreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-90639086935773282092012-05-24T15:43:12.317+01:002012-05-24T15:43:12.317+01:00This comment has been removed by the author.charlespetalshttps://www.blogger.com/profile/00903904404219917359noreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-29333854532053453662012-05-10T18:16:53.559+01:002012-05-10T18:16:53.559+01:00I am feeling that things have been a interruption ...I am feeling that things have been a interruption away from developing brief, well arranged and recyclable software.<br /><br /><a href="http://www.creativementor.com.au/photoshop-training-course.html" rel="nofollow">photoshop courses sydney</a>dawidtailorhttps://www.blogger.com/profile/02849201240047221885noreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-28799028151010565602012-05-10T16:36:28.836+01:002012-05-10T16:36:28.836+01:00Hi,
very interesting points.
Just some question...Hi,<br /><br />very interesting points. <br /><br />Just some questions that came to my mind:<br /><br />As you've said there is no common understanding how to use patterns, inheritance, polymorphism and the like. Additionally the unexperienced developer will always do pretty nasty things, correct.<br /><br />1. Do you think it is easier to start with functional languages than with the others? I don't think there is less complexity on functional languages. I also don't have an idea how to build complex UI without having predefined controls that can be inherited from. But as in JS (e.g. Extjs) I really like the approach of mixins. That does make things easier and reduces a lot of the boilerplate code that just has to be written.<br /><br />2. Moving from procedural languages (assembler) to oop (c#) to "more" functional (f#, js) it all has its benefits and drawbacks. E.g. moving around functions that use functions that work on functions is not more transparent than having predefined patterns that are somehow visible - or at least understandable architecture that fits the tasks not the predefined best practices. What you think about that?<br /><br />hiro.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-72377549658890883222012-05-10T11:54:52.186+01:002012-05-10T11:54:52.186+01:00Just a thought: isn't this just the old "...Just a thought: isn't this just the old "if all you have is a hammer, then all problems will look like a nail" discussion again ?<br /><br />I don't mean to underestimate your ideas here - exactly the opposite! I think you have some good points, especially about mutable states and macro re-usability.<br /><br />But then again the way you express your ideas does sound a bit on the radical side (and I want to be clear on this: the WAY seems radical, not your ideas). So you get many replies of the "hey - so true!" or "hey - all crap!" kind. Radical replies.<br /><br />I think the fact that in the last few years, like you and others here point out too, functional programming concepts have re-emerged and have been included in many mainstream (and traditionally imperative) programming languages, is just an expression of your same ideas and concerns.<br /><br />The point once again, IMHO, is simple: use the right tool (technology) for the right job. Of course OOP is not helping you much with business logic. And of course it's great for UI frameworks and other similar cases. It all just stands to reason.<br /><br />What you say about patterns is just the perfect example: patterns are good, but only when applied to the right cases and in the right way.<br /><br />Nice post. Maybe just a bit radical-sounding, as I said. :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-80911209484058178842012-05-08T03:25:15.698+01:002012-05-08T03:25:15.698+01:00I'm a bit shocked at the amount of push back y...I'm a bit shocked at the amount of push back you're getting on this blog post - but it does seem that daring to say maybe "traditional" OOP is not the best solution gets some people pretty wound up...<br /><br />I learned plain ol' procedural coding and functional programming pretty much side-by-side in the early 80's. I liked SASL and Miranda - but they were niche languages and my day job was writing C. Then in the early 90's, I moved to C++ - and I liked Haskell, but it also remained a niche language. I was on the ANSI C++ Standards committee for most of the 90's. In the late 90's, I moved to Java, still wishing functional programming was more mainstream but doing my best to be a good little OOP worker bee since that was the common wisdom. I had hoped that generic programming and collections in the C++ Standard Template Library would gain more traction, especially with generics coming to Java, but that also seemed a niche style of development...<br /><br />I remember when design patterns exploded onto the scene. I'd been programming commercially for a decade before the Gang of Four book appeared. I used to attend the Object Technology conferences back in the 90's. Everyone was trying to find better ways to do things and there were lots of new ideas buzzing around (the Oxford Programming Research Group spent quite a bit of effort looking at how to blend this "new" OOP approach with the previous best practices in the functional world, for example).<br /><br />Over time, that seemed to settle down and everyone just followed the OOP tablets of stone, churning out ever more complex systems, with more and more abstraction and The Nouns took over, almost obliterating Verbs in the representations of all our models.<br /><br />In the last decade, I moved from a serial monoglot to a true polyglot, mixing and matching multiple languages on projects. Increasingly a functional approach became more and more feasible in mainstream languages. Over the last four years, working with Groovy, then Scala and then Clojure, I've been able to adopt functional programming more and more in my applications and it really has simplified a lot of things. I find I reuse more code - small functions are easier to reuse than classes; I find I can do more with my data - maps and vectors and more amenable to general data analysis and transformation techniques than data hidden inside classes; and I find I can make larger changes more easily in response to new / changing requirements - the lack of side-effects and a more generic approach to data helps keep code more loosely coupled.<br /><br />OOP was definitely an improvement over raw procedural thinking but in a world of increased concurrency, the mutable state associated with the traditional OOP approach is becoming more of a liability and we need something different if we're to continue tackling ever more complex systems in any sane way. Functional programming - once considered so niche and specialized - just happens to fit well with that concurrency-laden world and, as we can see, it's certainly not a _new_ idea. It's just been waiting for its time.<br /><br />I think we'll see more hybrid approaches, OOP where it still makes sense (and GUI-building seems to be a good fit, as well as for modeling systems that truly require shared mutable state) combined with a functional approach to data at large that frees us up to think about the business logic being implemented without getting bogged down in the housekeeping associated with encapsulated mutable state.<br /><br />Great to see blog posts like this and I hope the "haters" will, over time, come to see some of the benefits of the "new" functional programming approach :)Anonymoushttps://www.blogger.com/profile/15391602120540580436noreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-47674106175445070652012-05-07T19:38:47.750+01:002012-05-07T19:38:47.750+01:00Dunno, I'm with the others saying that the pro...Dunno, I'm with the others saying that the problem isn't caused by OOP, but by the people using it.<br />I have limited knowledge about functional programming, although I'm gonna work on this in the upcoming future, but I've worked on a lot of different projects, using several languages, several approaches and methodologies, and feel correct OOP is a clear step in the right direction for me.<br />For example, I've recently had to rewrite an old VB6 app, at first I kept most of its procedural style, it worked flawlessly, way better than before, however, since more changes were needed, I refactored all code to use OOP, there was a certain part of the application that has always been badly thought that has been somewhat a pain to use proper OOP, but in the end performance and memory usage have barely changed, the app is more scalable, flexible, the code is clearer and more concise, etc. In summary, what OOP promises.<br />Of course, I've seen horrors caused by OOP misuses, for example, I know of certain application currently being sold, and constantly updated, that has tons of projects, all highly coupled, which highly depends of certain files when it shouldn't, compiling it takes half an hour, etc.<br />I agree that mutable states cause pain, but also, I wouldn't want to program certain things without it.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-42173050307468187732012-05-07T01:02:37.042+01:002012-05-07T01:02:37.042+01:00It's unfortunate that most OOP languages don&#...It's unfortunate that most OOP languages don't have constructs that separate modules from objects and classes. In Python I find that a module frequently provides just what I need without writing a class. Jack Diederich's PyCon US 2012 presentation "Stop Writing Classes" addresses this point.Doug Warnernoreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-54778918938568243382012-05-03T07:33:57.846+01:002012-05-03T07:33:57.846+01:00Very interesting points you guys make! However, it...Very interesting points you guys make! However, it seems to me that most of them have more to do with 'poor design' than failure in OOP methodologies. Recently had my 'textbook' OOP programming style come under scrutiny by an older developer - one who sits in a dark room coding with a text editor, and I must say its been difficult for me to explain 'why' we should be using OOP. Having said that, they also don't understand relational databases nor the structure that exist naturally between data entities. Anyway, as a result I found myself simplifying my applications & more specifically the 'abstracted model' i use to program against inside the application. Shallow inheritance & static classes of functionality that can manipulate objects are mostly the order of the day at the moment. Its OK to use all the principles we have at our disposal but not just using them for the sake of it, its more a case of 'is it really necessary' for what we are trying to accomplish at the time of going to press? Have worked on many projects where we tried to get the full 'generic' implementation going in order to maximise code re-use and in hindsight i must say, any modifications mostly required some form of coding exercise anyway. There is a happy medium but finding it is the real craft, possibly made easier with experience.zaphhttps://www.blogger.com/profile/00123014022914772231noreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-79315729113949902652012-05-03T05:35:30.011+01:002012-05-03T05:35:30.011+01:00Maybe you could subtitle this post - Or, Towards a...Maybe you could subtitle this post - Or, Towards a Life Without Complexity - because I think that you and the other comments touch on a deeper issue: How increasing and unnecessary complexity has polluted software development.<br /><br />I started coding in C/UNIX in the 90's. If you were lucky you had computer with a few MB of RAM and a few 10s of MHz CPU. We didn't write large complex code, because you couldn't run it if you tried.<br /><br />Instead we built synergistic ecosystems of small responsive apps communicating via messaging. We wrote code as simple as possible, but not simpler (to quote Einstein).<br /><br />And it worked; we had electrical utilities running multiuser billing systems for 1000s of customers on computers with less power than an iPhone.<br /><br />As you ably describe in your post, something has gone wrong in the past two decades. Somehow complexity has crept in, seemingly for complexity's sake. I'm as guilty as anyone; I've built a whole generation of systems swarming with SOAP web services that only send a few bytes of actual payload. Layers of interfaces and classes to save a simple data structure to a table. ASP.NET webforms that abstract away and bear no relation to the HTML sent to the browser. Years debugging monolithic systems with layer upon layer of code implementing whatever pattern/framework trendy at the time. 3GLs, 4GLs, OOP, now FP.<br /><br />But for the average-Joe enterprise programmer (like me) has any of this really improved what is actually important (and why we get paid)? Ie: timely, cost-effective and responsive systems that meet users' needs and are adaptive to change, that don't cost an arm and a leg to run and maintain? That the poor sucker that inherits your code in a few years doesn't have to spend weeks with a debugger just to find out what it does?<br /><br />Fortunately over the last several years we have seen a push-back against this creeping complexity, leading to rise of the various opinionated development frameworks (eg Grails, Rails) and 'pragmatic' languages such as Groovy, Ruby, and now Scala.<br /><br />KISS. Just like we used to, but seem to have forgotten. Focus on what the client wants - reliable software they can use without needing a degree, delivered as quickly as possible, to last only as long as they need it. We don't need to write software as though it must stand the sands of time. I've been coding for 20 years, and I have never seen a system last unchanged/unscathed for more than a couple of years. <br /><br />The people paying you don't care that you have abstracted away layers of code, 'just in case' you might one day move away from SQL to NoSQL. They don't care if you are using a share nothing, massively concurrent. functional, DSL-enhanced, platform-agnostic framework. <br /><br />They care that the screen they enter data on is simple, obvious, and fast. And that the data magically comes back next time they search for it, super fast. And if things change fast, that you can quickly code another system that keeps on helping them make or save money.<br /><br />Pick an opinionated development framework. One that whoever has to maintain your code in 5 years time can pick up and run with in a few days. Make sure that the language is pragmatic, not dogmatic, and allows you to express the problem at hand in code naturally with DSLs, closures, maps. Build ecosystems of applications that exchange data through simply, preferably via a message broker or REST/JSON apis.<br /> <br />My 2 bobs worth: It doesn't matter if you stick with OOP (it's never going away) or launch into FP (shows promise) or sit on the fence (probably the best bet). Just make sure that what ever you do, Keep It Simple Stupid. Those who come after you will thank you.Tim Pedersenhttps://www.blogger.com/profile/00755162813136186774noreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-24953848907014628622012-05-03T04:17:18.582+01:002012-05-03T04:17:18.582+01:00OO is a analysis method, it can cut a big one into...OO is a analysis method, it can cut a big one into fragment ones, another article: Tell Above, and Ask Below - Hybridizing OO and Functional Design(http://michaelfeathers.typepad.com/michael_feathers_blog/2012/03/tell-above-and-ask-below-hybridizing-oo-and-functional-design.html) maybe help you.<br /><br />all pains in OO practice all are from "OO language" that is not true OO, in ture OO, Objects interact with each other by async messages/events, I can do it in Java with jdon framework, if you are interesting in it.Jdonhttps://www.blogger.com/profile/16139202239505391219noreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-28586782327682503292012-05-03T02:58:19.043+01:002012-05-03T02:58:19.043+01:00There is a lot more there to discuss and I will be...There is a lot more there to discuss and I will be delivering a lot of this content as a presentation (Performance Java for Android: Tricks for the Troubles") at AnDevCon III in a couple of weeks. <br /><br />I must admit since I had an existing medium sized SDK / runtime framework level codebase ~150k SLOC the jump to implicit composition and rewriting each of the core SDK / runtime areas has been staggering. It took me almost 1.5 years mostly full time+ to rework my efforts in this direction before everything compiled and ran again; a very incremental restructuring from the core to the periphery. I might mention that the runtime and SDK layers are now composed of 700+ independent IDE projects with minimal dependencies between them.<br /><br />For handling state I have embraced extensible enums, well, extensively and the solution I came up with for storing unrelated state is the ExtEnumSet / Map which is an extension of the EnumSet/Map collections. Extensible enums also made decoupling state between IDE modules / separate components possible to a level I never achieved before.<br /><br />Re Chris T:<br />"However, my experience with Swing and being involved early on with what then went on to become Apache Wicket still makes me feel that it might be nicer to build a UI toolkit around aggregation and composition, but I don't have any real evidence to support this feeling."<br /><br />This is one of the things I have done for Android not only with the View / graphics2D API, but along with the rest of the Activity lifecycle and many fundamental SDK areas for Android dev. Of course the same techniques apply for any other graphics API; OpenGL / ES, JavaFX, Java2D, etc. I can tell you it works well and I am very excited to release my efforts imminently. I hope you don't mind me mentioning this effort: TyphonRT. <br /><br />I suppose might also mention that Scala is next on my list to explore once I finish reworking my efforts at the Java runtime and SDK layers. I posit and have a feeling that applying the direction I have taken with Java dev will work quite well with integrating Java w/ Scala without inheritance. <br /><br />Anyway.. cheers everyone... I'm glad to see independent confirmation / discussion of directions I too have embraced whole hog.MichaelEGRhttps://www.blogger.com/profile/02130116004495834444noreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-45465592935544971532012-05-03T02:57:11.267+01:002012-05-03T02:57:11.267+01:00I enjoyed reading this post and all the comments i...I enjoyed reading this post and all the comments immensely. :) I too have been doing 15+ years of OO Java mostly focused on the client side w/ a real time & game dev focus and am well on my way to moving on from the classical approach. However, I found one last niche to exploit before jumping the shark to a more pure or even mixed (Scala) functional approach. I have a long running framework started in '03 to accomplish client oriented tasks and it has evolved greatly since conception. While modularity always has been the main concern things kicked off in the traditional OOP fashion relying heavily on inheritance / explicit composition and overused OO patterns re singleton. I was able to get away with this for quite some time. The first real breaking of the seams came from my entity system for game dev. In creating a generalized entity system applicable to any game the nastiness of the blob anti-pattern attacked in earnest in addition to a fracturing of storing state necessitating pushing various state sub areas into explicitly composed implementations. The final breaking point where I made the full plunge to move away from inheritance as the de-facto organizational pattern came when I finished the initial port of my efforts to Android (finished April '09 / Android 1.1). As jmarranz noted the Android Java SDK is "brutally based on implementation inheritance". It was clear to me in the transition from Android 1.0 to 1.1 that this was the case and it isn't going to be pretty or IMHO end well for modularity and targeting the larger ecosystem. This is very evident today and I can't say the Android team has taken a judicious approach to API development (it seems like anything goes really); the last straw was drawn and a new way was necessary. As things go though I can't jump to a pure functional approach due to existing code base to the client side / real time app / game dev applications which as things go just aren't as efficient with immutable data structures on the desktop let alone Android. <br /><br />The key insight that I came across is a focus on implicit composition. The explicit variant being an object containing another object member variable. The implicit form being a lightweight container (IE component manager / IComponentManager) where one can store and retrieve aggregated components. The goal is no longer to encapsulate data and logic in one object, but to concretely split implementation between data and system / logic oriented components. There has been a bit of discussion on this approach for becoming known as the entity system architecture, but I generalized the approach for use any any context including the generalized entity system. A quick example is:<br /><br />entity.getAs(DATA, Position.class); <br /><br />DATA is a statically included import for IData.class. Data components certainly can also be publicly scoped so one can do this: entity.getAs(DATA, Position.class).x; <br /><br />You can store anything in a component manager and add data / system components dynamically. One can also define any other component type too as necessary.MichaelEGRhttps://www.blogger.com/profile/02130116004495834444noreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-23424620035680948922012-05-02T22:10:09.406+01:002012-05-02T22:10:09.406+01:00Interesting point. Scala traits are indeed a power...Interesting point. Scala traits are indeed a powerful concept. However, with great power comes great responsibility ;-)<br /><br />The observation I would observe is that abstracting into one or two traits and then mixing them in works just fine. Adding more and it starts to get more complex. Then you get to the point of starting to have dependencies between traits. Scala supports this through self types. You then get to something known in Scala circles as the 'cake pattern', where many inter-dependent traits are inherited into a component. If you don't take great care, this soon becomes a horrible tangled mess (the bakery of doom as some people call it!).<br /><br />Personally I tend to use traits more as a way of grouping a set of related functions. When all these functions need some state that is not used elsewhere then I tend to encapsulate it in the trait. Where there is state or data that is shared across multiple traits then I tend to treat that as a more functional data construct and pass that to/return it from those functions rather than encapsulate it in an object fashion. This approach is working out well for me so far, but I'm still experimenting lots to find the exact blend that works well - and this may be different depending on the project or what the trait is actually doing. The jury is still out.Chris Turner (he/him)https://www.blogger.com/profile/09141108967081921802noreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-35812345901700425402012-05-02T22:01:48.795+01:002012-05-02T22:01:48.795+01:00I think that's largely what I said. Back at th...I think that's largely what I said. Back at the beginning we used inheritance, interfaces, statics and the like with abandon. Gradually our relationship to objects have changed and we have moved away from these concepts. I'm fine with that.<br /><br />My observation was that as we move in this direction there becomes a much greater similarity to non-object approaches like functional programming or lisps. So, perhaps there is a different approach that works well, or as Scala has done, some hybrid approach that attempts to blend the different approaches together.<br /><br />I don't think I was advocating throwing out any babies, just opening minds to other possibilities that come in to play given out current thinking on how objects can be used.Chris Turner (he/him)https://www.blogger.com/profile/09141108967081921802noreply@blogger.comtag:blogger.com,1999:blog-5400765672405463592.post-28881573559182932742012-05-02T21:57:07.154+01:002012-05-02T21:57:07.154+01:00Thanks for the comments Robert. I completely get w...Thanks for the comments Robert. I completely get where you are coming from. I've had some great successes with immutible state, but I can see that there is a mismatch between these and the underlying hardware.<br /><br />However, my observation over many years of development is that there is a real lacking in ability in many programmers to write good quality mutable code that works in concurrent environments. I've probably spent weeks of my career to-date debugging these sort of issues where state is not what it was expected to be or has become inconsistent. Writing good quality concurrency code is really hard, adding mutability makes it harder. <br /><br />Therefore, my feeling is that we should be looking to specialists in this area of coding to provide the libraries that can then be used by non-specialist developers to build solutions that scale and function efficiently in concurrent environments. Look as something like the Akka framework and you will see what I mean.<br /><br />As devs we are never going to get fully away from having to deal with concurrency and change of state, but anything we can use to help get it right must be beneficial.Chris Turner (he/him)https://www.blogger.com/profile/09141108967081921802noreply@blogger.com