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?

This is an example of parallel system that i like: http://librestats.com/2012/10/16/r-at-12000-cores/ . i haven't done anything near this scale, although, that would be a goal to aim for. Although, i am not entirely certain if the above link answers your specific query, because the cores in the link are not housed in what would be considered a single computer. Anton is a super computer unlike the libmpi based solutions that I linked to here. Additional links: mpi: http://www.mpi-forum.org/docs/ http://r-pbd.org/ Hope this helps.

edit: typos, clarity etc.

I was about to refute your argument by proposing creating a union type. Here is a relevant reference: https://realworldocaml.org/v1/en/html/functors.html

(This idiom is a bit of a historical error. It would be better if compare returned a variant with three cases for less than, greater than, and equal. But it's a well-established idiom at this point, and unlikely to change.)

Eiffel is similar to ocaml : http://www.infor.uva.es/~felix/referencia_smart_eiffel/libra...

Does anyone know the advantages of the above signature over the Haskell alternative? Because this seems to be more obvious and easier to read. So there are more than one language guilty of using a ternary operator for compare.

Haskell does define the appropriate constructors, rightly so: https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-O...

data Ordering :: *

Constructors LT EQ GT

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 would recommend Michael Snoyman's book on yesod (http://www.yesodweb.com/) to get a practical understanding specially from a crud perspective. I found this book to be very helpful: http://chimera.labs.oreilly.com/books/1230000000929/pr01.htm...

For me, using yesod has been quite a revelation. All of the errors in db operations get caught during my cabal build. This link https://github.com/yesodweb/yesod/wiki/ghci is something i used to test my db code all within the repl cycle after setting some pg env variables. All in all, its way smoother than many other environments i have worked with.

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.

I first started using ocaml (f# actually and then re-wrote it in ocaml) for writing a simple interpreter to generate java code from mysql schema tables to deal with hibernate boiler plates etc. The code was much succinct than a comparable parser written in say antlr. That was my first introduction to typesafety helping me move forward. Specially, when coming back to the code, the compiler will scream at you for either not handling all the patterns that matched or adding new ones that didnt exist yet and needed to be changed. I went away from OCAML towards Haskell because a coworker convinced me to switch: also haskell seems to have a better support for multicore architectures. Of course, my applications are more web/networking apps, crud, websites etc. So i could have gone either way. The one difference i find when programming with Haskell as opposed to ocaml is that in ocaml, my instinct would be to write a little interpreter(or a quasi quoter). In Haskell, I still think that template haskell is a necessary evil, therefore, do it only when I really know what I am doing. I found this link to be quite helpful: http://pleac.sourceforge.net/pleac_ocaml/

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.

Elm was my first choice for a different side project. I went away because then elm did not have, or it was my lack of knowledge,support for crud widgets. I miss the elm signal approach in haxe for one thing. Here is the link to my repo so things are a bit concrete https://github.com/asm-products/ccar-websockets.git . Warning: this is still work in progress and there are way too many issues before I can even release this. The elm repo is here: https://github.com/dservgun/elm_projects .

Edit: added some repos to set a context. The original comment about 4th attempt hit home as the latest repo is my 4th(I am going to quickly lose count) attempt to achieve at a model that might work/scale. There are still some issues that I would like to solve: whether to use code generators or not. Code gens will save me some typing, but I found myself tweaking printfs or equivalents to fit it into a narrow model.

Edit II: Elm, iirc, is being supported by prezi that also happens to be using haxe quite actively. So I felt a bit more reassured about using haxe.

I will have to take a look if fponticelli: https://twitter.com/jdegoes/status/471319014614892544 , thinks it is. My app is not a pure web app, it has some client components such as excel plugins that need to talk to the server. I was therefore looking for something that I can port to other targets with some support from the language, which is where imo haxe/nekovm seem to shine. Yes, there may be some parts missing from haxe, though, it seemed to work ok for my needs and if its good for salesforce or tivo, I thought I may not be a trailblazer afterall.

Yesod is awesome I can't see myself going back to less typesafe database schema tools. The choice I made seemed like a safer path, perhaps not ideal.

The application that I am trying to put together is a realtime websockets application. Therefore, I am using yesod/websockets for the server. For the client, I chose haxe simply because of the targets available making it simpler to write plugins.

On one of my irc chats or somewhere, I did hear good things about haste, though it is primarily a javascript library, therefore I plan to evaluate it later.

About the client: it is a single page app to prevent any page refreshes and I am a bit sold on the frp (using promHx). I guess I should have elaborated a bit more about this in my earlier comment, because my choices are not indicative of anything amiss in yesod.

I have been using this site for (yesod 1.4) [http://www.yesodweb.com/book/introduction] and I found the documentation current. Is there something that doesn't compile?

For my side project, I use yesod/websockets for the server and haxe for the client. I feel ok with that choice instead using hpaste. Though eventually I would like to see a complete haskell stack. @Lewissham: about the fourth attempt, it just so happens that this was my third attempt at getting something that was right for me as well as maintaining the typesafety. I do realize that code is still not as seamless as I would like. It still lets me understand the overall roadmap that the code needs to take to be usable/maintainable etc.