tag:blogger.com,1999:blog-3016981170905406325.post377717575860095593..comments2024-03-22T05:35:31.155-07:00Comments on language agnostic: OmegaInaimathihttp://www.blogger.com/profile/14277727122990903016noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-3016981170905406325.post-25600983945947243312020-02-07T05:22:00.815-08:002020-02-07T05:22:00.815-08:00เกมออนไลน์ แจกเครดิตฟรี slot online คลิกเลย
https:...เกมออนไลน์ <b>แจกเครดิตฟรี</b> slot online คลิกเลย<br /><a href="https://www.live22easy.com/" rel="nofollow">https://www.live22easy.com/</a>mhoodanghttps://www.blogger.com/profile/17177920175795055074noreply@blogger.comtag:blogger.com,1999:blog-3016981170905406325.post-51300451977553467152011-02-11T09:57:51.792-08:002011-02-11T09:57:51.792-08:00@mb - I'm sorry, I must have missed the part o...@mb - I'm sorry, I must have missed the part of my article where I claim that it's impossible to write good software in C/C++, and the one that claims that C/C++ are marginal languages, and the one that claims Lisp/Haskell hackers are smarter than C/C++ hackers. <br /><br />Can you please point them out to me?Inaimathihttps://www.blogger.com/profile/14277727122990903016noreply@blogger.comtag:blogger.com,1999:blog-3016981170905406325.post-37411361611172013322011-02-11T04:33:56.369-08:002011-02-11T04:33:56.369-08:00The world runs on C/C++. The OS you are using righ...The world runs on C/C++. The OS you are using right now, the control software for your car and the compilers/interpreters that make it possible for you to use less practical languages are all programmed in C/C++. Not LISP. Not Haskell. I always find it amusing when people argue that it is impossible to write good software in C/C++ when in fact the world runs on software written in those exact languages. And I also find it ironic that, despite the often repeated claims that (1) LISP/Haskell/functional programmers are somehow cleverer than the rest and (2) the languages are much more productive, I look around and LISP/Haskell has had virtually zero impact on the world outside of the language geek community. Another way to put it is that there is absolute, unquestionable empirical proof that C/C++ has what it takes to run the software the world relies on. Because it does. There is no such empirical proof of LISP or Haskell. So everything claimed about LISP or Haskell or any other language is just that: a claim or wishful thinking not backed up by empirical evidence. Show me a real practical OS or JVM written in LISP or Haskell and you will get my attention. Look...I love programming languages and have programmed in many functional languages including LISP, Haskell and Clojure. And by the way I write functional language compilers for a living. But I still prefer C/C++. Why? Because it is the foundation of everything else. The solid rock holding up the ivory towers of language purists.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3016981170905406325.post-71325044208602052222010-12-30T15:57:32.388-08:002010-12-30T15:57:32.388-08:00@Zak - True. The thought had crossed my mind (base...@Zak - True. The thought had crossed my mind (based on the things some of my associates have to say about it) that Clojure would make a decent example of Lisp being influenced by other languages (though from what I've heard, it seems to be closer to a Scheme than a CL), but I don't have enough experience to discuss it semi-meaningfully. It's on my to-do list along with another three languages I've been meaning to jump into.Inaimathihttps://www.blogger.com/profile/14277727122990903016noreply@blogger.comtag:blogger.com,1999:blog-3016981170905406325.post-5906538483286926632010-12-29T18:17:00.763-08:002010-12-29T18:17:00.763-08:00Clojure is a nice example of a Lisp dialect that h...Clojure is a nice example of a Lisp dialect that has clearly been influenced by Haskell. Its lazy sequences are especially noteworthy in this respect. It also eliminates the separate namespace for functions, makes function composition a little easier than in CL and pervasive destructuring and pattern matching. It's worth taking a look at as an example of what such a combination could look like even if you don't end up using it.<br /><br />I want to be clear that I'm not claiming that Clojure is Omega, or even Alpha. I really wish it had CL's method combination (it does have multimethods) and a way to locally or globally cause a function that was not originally generic to be treated that way.Unknownhttps://www.blogger.com/profile/03332537222647784056noreply@blogger.comtag:blogger.com,1999:blog-3016981170905406325.post-43748305813625727132010-12-29T00:06:37.088-08:002010-12-29T00:06:37.088-08:00@Kartik - Sounds interesting.
@Craig - Pardon the...@Kartik - Sounds interesting.<br /><br />@Craig - Pardon the delay; your comment was flagged as spam for some reason.<br /><br />The macros issue is dealt with throughout Lisp literature. Typically, the answer to your comment is that a macro is complex, but macroless code that achieves the same thing would probably be more complex. It's accepted that the trade-off is less readability for more maintainability and terseness (incidentally, this is why I refused to put specific weights on the criteria of "power"; as a Lisp user, I probably value readability lower than I should, and maintainability/flexibility higher than is good for me). I'm not sure what else to say other than that I think it's a worthy trade.<br /><br />I'm having trouble parsing your third paragraph; both procedural and object-oriented programming is possible in Lisp. I'm using "readability" to mean more-or-less "How likely is an expert [language] programmer to understand a typical [language] codebase at first reading?", so that bit makes sense, but can you please clarify what you mean by "approachable"? I ask because it sounds suspiciously like "how close is it to C syntax?", which is a fine criteria for a popular language, but I was discussing power.<br /><br />The future is pretty hazy; I don't know that it'll fall onto the side of Haskell, and even if it does, it likely won't be because of the type inference. I haven't seen evidence that a mandatory strong type system (inferred or explicit) is axiomatically a good thing. There are plenty of assertions to this effect, but I've yet to read a follow-up defending those assertions, or even a breakdown of the trade-offs that doesn't devolve into religious warfare.Inaimathihttps://www.blogger.com/profile/14277727122990903016noreply@blogger.comtag:blogger.com,1999:blog-3016981170905406325.post-40285627243319876062010-12-28T19:34:55.964-08:002010-12-28T19:34:55.964-08:00I think the problem is that the main contenders fo...I think the problem is that the main contenders for Alpha and Omega have different mixes of expressiveness, terseness, maintainability, readability, flexibility, etc. So one language might be better in a situation where readability is more important, but another language might be better when you need maintainability more.<br /><br />I think the main problem with Lisp is actually the macros. Everyone has a different set of macros, making their Lisp code different than everyone else's. So it takes longer to get up to speed on the "variant" of Lips+macros being used. To my mind, the macros also typically make the code too terse, with a lot of "concept" within a few lines.<br /><br />On the other hand, I see a progression of main-line languages (Java, Perl, Python, Ruby, Scala) towards Lisp, or at least functional programming constructs. I think this is good. But the reason folks don't go all the way to Lisp is that languages like Ruby are more readable and more approachable. Or more precisely, the ability to think and code in procedural and object-oriented constructs is often useful.<br /><br />I think the future of languages lies more on the Haskell side than Lisp, due to the type inference and more advanced concepts. But I also think that it's even harder to learn than Lisp. So I think that some combination of Lisp and Haskell, along with a more readable syntax and other paradigms, will likely end up as Omega. I'm also keeping my eye on Reia and Factor.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3016981170905406325.post-18394806458526549302010-12-28T19:14:59.644-08:002010-12-28T19:14:59.644-08:00Just a plug: I've been working on an arc-like ...Just a plug: I've been working on an arc-like interpreter (http://github.com/akkartik/wart) that provides pervasive destructuring and keyword args for any function argument. (Arc provides pervasive destructuring.) A couple of random insights from this process:<br /><br />a) When rest args are present, they take priority over optional args. Requiring keywords for optional args seems like a good idea when there's a macro body, for example.<br /><br />b) Generic functions dispatch on the type of the *last* arg. That seems like the best fit for lisp's existing functions.Kartik Agaramhttps://www.blogger.com/profile/06281692669037537503noreply@blogger.comtag:blogger.com,1999:blog-3016981170905406325.post-82339465194183220992010-12-28T18:45:13.206-08:002010-12-28T18:45:13.206-08:00I'm not sure.
To be fair here, accurately an...I'm not sure. <br /><br />To be fair here, accurately answering your question would involve considering every possible programming situation, then figuring out whether (and if so, by what amount) it could be simplified with a macro, THEN figuring out whether the percentage and magnitude of "yes"es justifies breaking the type system. I doubt anyone (including those who would like to gloss over the lack of macros with "well, we don't REALLY need them") has that much time on their hands.<br /><br />A priori, it seems you get many of the advantages of defmacro by being fully functional, fully lazy and compiled, but I'm not sure you get all of them, and I don't think you can replicate reader macros the same way.Inaimathihttps://www.blogger.com/profile/14277727122990903016noreply@blogger.comtag:blogger.com,1999:blog-3016981170905406325.post-71354686139798435282010-12-28T16:22:00.736-08:002010-12-28T16:22:00.736-08:00Does Haskell actually need Macros though?
http://...Does Haskell actually need Macros though? <br />http://neilmitchell.blogspot.com/2007/01/does-haskell-need-macros.htmlmlhaufehttps://www.blogger.com/profile/07964865381194929027noreply@blogger.com