haxeny1

> hedge long bets with shorts I am curious, without sharing details obviously, have you actually been able to successfully pull it off or do you expect to see some hits due to changes in direction?

Typesystem is not the same as syntax? I dont believe raising ugliness in syntax as an issue. Of course, I do mention the ugliness in Haskell and that is in special cases where the overhead of boxing is significant. So, yeah, we could move on, but I think that is a specious argument. I guess one could really move on, till we start seeing Scala embrace Uniform Access Principle or Java embrace lambdas (implicitly or explicitly) to support generics. So, what it seems to me is that you are ok with a bad language design and accept the weakness of the language because it was delivered and also accept that like any working document there could be amendments and that is part of working in a programming language. Moreover, the principles of language design that I list were available as prior art, so it is not clear as to why Java language designers decided to at least not refer to it during design. Anyway, my intention was not to start a flame war? Note: Regarding : "why create ugliness in Java?" Any reason for an ad homenim attack? or was it a general rant? Since we are on hacker news I would like to give you the benefit of doubt :).

I liked the layout. The main take away for me was the <today> in Red. It may be a trivial feature,but with so many widgets pounding my eye, it was nice to zoom in to todays date. I can see master planners (in inventory world) sticking with this layout, though I am sure you guys must have already done your market research.

I was one of those folks who actually bought the personal license. Over years, SmallEiffel came along and improved the ecosystem. Of course, now Eiffel has a community/enterprise model. In any event, I do think that they were pricing them out of the market. Defense contractors, seem to like ada more. The feature that I miss from Eiffel is the Expanded (allocated on stack feature). Even haskell has some #untyped to deal with boxing primitives. I thought that Expanded was a stroke of genius: bringing specification to implementation without the middleman(aka heap).

I never understood the following : Eiffel had a better syntax, better support for core issues, Void type, design by contract, multiple-inheritance and an intermediate virtual machine for portability although the most common target was C code. To name a few. I was using Eiffel in a small side project just about when Java released their 1.1.4 (a version before the object serialization library, iirc). It was a sticking point for me. Add to that, to program in java before IBM Visual Age was released was to using vi/notepad(++?) editors. Coming from Smalltalk env that was a bit of a shock. Eiffel commercial IDE from ISE was way better and its clever use of pick event on the mouse's right click to drop to compile/run targets was actually easier on my fingers, which is a side show, but good quality products demonstrate quality at unexpected places.

I am still programming in java in my day job, knowing fully well that Java was not my top five language choices. Eiffel's type system was a bit more advanced than Java even way back in those days, so not only was I stuck without an ide till VA for Java showed up or VisuallJ++ I also had to accept weak inheritance and design by contract models. Performance of course was not even close to an Eiffel compiled C code, which was probably addressed in later versions of java.

My point being, that just as Eiffel was something that was better and set aside by a few leading development shops, there must have been other languages that could/should have received a fair share in language evaluation by programmers, I dont necessarily mean limiting to Ruby, Python for example, despite them being excellent tools, they may fall short in an enterprise ecosystem. What happened at least I seem to think instead is a sort of groupthink to start coding in Java because of rubbernecking. All in all, I think that things could have been better if people paused to understand the Java language model and fixed in java 1.2/3, or some earlier version so we didnt have to wait till Java 1.8 to get these features. /rant.

I would add

- Object Oriented Software Construction (2nd. Bertrand Meyer)

I would recommend Eiffel if you want to elevate OO design. The issue with the GOF book that I have is that there is a slant towards composition as opposed to inheritance. When done right inheritance does result in compact code. Multiple inheritance cannot be avoided (Scala proves this by trying to bring in traits). Repeated inheritance actually helps reduce the code size as one could inherit the same method twice to implement a doubly linked list from a single linked list.

Note: In functional paradigm (Haskell) composition over inheritance makes sense, though in object oriented languages choosing an approach that has a compositional bias can impose some constraints that could be avoided otherwise.

I am not sure if we could conclude that the demand is off. I believe that the traders who were controlling the inventories have finally closed their trades and walked away while they are ahead. Oil of course is a geopolitical commodity and a slide in prices usually helps developing countries that need oil to just keep the machinery running. Alternative sources are still not as accessible as one would like. All in all, I seem to think that this trend is not going to bode well for all the tax subsidies for solar panels in the US and will only delay discussions on climate change.

the article seems to suggest that the hackers had access to stolen data, Target comes to mind within the US. Did Target share the hacked data to the FBI so the feds can cross check with the data irs released and send the offending company the bill before we pick up the pieces. Can the federal government legally do it since the statute of liability has not expired yet? "Is there a lawyer in the house?"

If the hackers had access to data outside the US, then it may have to be us the taxpayers, unfortunately.

Smalltalk was a great start, though, that should not have been the benchmark for implementing object oriented languages. There are some valid concerns about oo that were imo missing in mainstream languages such as Java/C++: uniform access principle (scala provides for that, but scala is a different type system) pre-conditions/postconditions as part of core language rather than annotated comments. weaker/stronger pre-conditions/postconditions in derived classes : this makes the use of methods quite obvious and what features are being inherited from the parent class. selective exports of features (this is a less known feature but can save a developer many a times). Repeated inheritance/multiple inheritance implemented right (so diamond hierarchies should be handled without having to resort to any ambiguities). Genericity (templates that understood hierarchy: this was missed in C++ at least in 2001. I havent programmed in C++ since then) Covariance (this was a direct side effect of method inheritance and I found it to be useful).

Without these features and many other features (I borrow this list from Bertrand Meyer's OOSC, 2nd edition), language compilers tend to shift the burden from the compiler to the programmer to manage types etc. It is probably too late to go back to Eiffel, though, I still think that it even today is far ahead of most oo languages, so if folks feel strongly against oo, I can understand that to some extent.

I recall a small exercise,where I was modeling Matrix using integers to do some basic addition and multiplication in Eiffel. It worked the code compiled, tested, assertions validated etc. All good. But how about determinants (I forgot the exact computation that needed that). I was still programming in java at my work and had that sinking feeling of change code at few places to make things Float and (read them as objects instead of primitives etc..you know the drill). It turned out, that the Number hierarchy in Eiffel was quite refined, I changed the declaration at one place and everything worked as expected. This was a small exercise, though it clearly outlined the power of the language.

As an aside, there was another feature that ensured that floating point numbers weren't being allocated on a heap: it was a keyword : Expanded: implying no references are created for the expanded objects. This feature alone can save a ton when decoding objects from a network etc, without me, the developer, having to worry about boxing/unboxing and the subsequent performance implications.

So, yes, OO was/is a great paradigm, though it is the details of implementation that matter. When I used to attend job interviews and was faced with one of the canned questions: which is better Java or C++, I started to take the "fifth" because I could not in all honesty compare truly bad implementations of the oo paradigm. The only reason I started to briefly look up scala was because Martin Odersky used Eiffel as one of his references : Uniform Access Principle to implementing the Scala type system. But that is as far as I could go, because, after looking at OCAML, it hit me that oo and functional can't safely mix.

I can relate to that because it took me a while to using cabal repl actively as i code. Once i discovered cabal repl, I found that i could test my database (yesod) business logic during my normal development cycle. This was very re-assuring to me, coming from an oo, java background. Writing tests is nice, although having a small function to test a particular usecase while development is quite empowering. The only caveat, being, I seem to have to export my tests as part of the main module. There are ways to restructure it, say creating DBObject (export crud/management) DBObject.Internal (will all methods exported).

This is one place i miss the selective export of features that Eiffel provides. I am still not certain as to why other languages (except perhaps sather) completely ignored this seemingly simple syntactic feature that would have saved so many of us from creating parallel hierarchies as in java or artificial structures in haskell.

I am a cofounder of a small company that has a patented process for removing oil spills. We are not in the green yet but the only reason we could hold out against the big oil companies in the face of any attempt to take over our technology was the patent. Patents are not the best option, but for truly innovative approaches to problems an inventor has very few options.

The above patent in the OP is egregious, and I can't really support it.

To your point, innovation may happen, but the inventor may not get compensated along the way. Patents try to bridge the gap. They are not perfect, but they do seem to work, in my opinion.