1. What language(s) are you most productive in?
2. What language(s) dislike you and why (but no ``GC IS SHITE'', that's not an argument and you know that)?
3. How many projects have you released as opensource yet?
Optional:
4. How would your language look like, if you would have to create one from scratch?
5. What is your favourite software license(s)?
And if you feel brave enough, post your github/gitorious/git.or.cz/bitbucket/or-other-public-source-hosting-service account!
Name:
Anonymous2011-10-08 5:27
What language(s) dislike you
Name:
Anonymous2011-10-08 5:29
Scheme. I've always been a Scheme fan.
I only dislike C++ because the standard is so massive. It's so complex that the only way to use it effectively is to specify a small section of the standard to use.
I don't start open source projects. I contribute public domain bug fixes to the project maintainers. I have contributed to well over 23 different projects.
Scheme.
Public domain.
Name:
Anonymous2011-10-08 5:29
1. Lua, Python, C, C++
2. Haskell, because:
+ it's made by mathematicians, and thus, suffers from something i like to call "functionalitytis", as in, too much of a good thing
+ learning haskell effectively requires you to abandon everything you ever learned about programming due to stupid, pointless alienated syntax
Python, because:
+ whitespace. seriously now, guido? why did it have to be goddamn whitespace?
3. 9
4. my ideal language would be a mixture of the syntax of C, the dynamic typedness of Javascript, the embeddability of Lua, the modularity of Python, and the versatility of Perl
5. MIT/X11, BSD License, Public Domain (or alternatively, unlicense) and beerware license
I'm not sure yet if I should post my github account :(
Name:
Anonymous2011-10-08 5:31
>>2
Should have read ``what languages do you dislike [...]''. sorry :(
2. C, C++, Java, and other low-level and/or poorly-done object-oriented programming things where your productivity and creativity is wasted on micromanaging your shit, aligning words and saving 150 CPU cycles, and/or a terrible, non-dynamic, obnoxious object system whose only purpose is to limit what you can do is shoved up your ass with 10 levels of inheritance (read: modern, widely accepted spaghetti code).
3. 1. I'm looking to fix this though. I do have a job where I extend and develop free software, but we don't release it.
4. Scheme with the Python object system, everything is an object and has a dict (or fakes to have one), etc.; syntax would be [url=http://srfi.schemers.org/srfi-49/srfi-49.html]SFRI 49[/url] which you can override by using brackets (no SFRI 49 inside brackets) plus comfortable property and dictionary access reader macros and nestable braces for strings as in Tcl.
<--- HOLY! FUCKING! SHIT! MY POST NUMBERS ARE THE SAME! CHECK MY DUBS YOU MOTHERFUCKING MOTHERFUCKERS! CHECK 'EM!!! DUBS DUBS DUBS!!! FUCK YEAH OVER 20LBS OF PUSSY AND CONJURING THE SPIRITS OF OUR FARTS WITH OUR ASSBURGER *AFRICAN ITALIAN DUBS! CHECK 'EM, DUBS
>>10,12
Work so that corporations can use this work and fuck you back and everyone else all over with their bullshit patents, DRM and trash < copyleft
Name:
Anonymous2011-10-08 13:09
1. C and Common Lisp.
2. Python because the language itself just plain sucks. Ruby because it's just a cheap Lisp. All the retarded languages for which some strings are equal to integers or booleans, notably PHP.
3. None.
4. Something like Erlang but with sensible syntax (e.g. Lisp-like or C-like) and optional GC.
5. BSD/MIT/X11/zlib/LGPL/WTFPL/etc., public domain.
Name:
Anonymous2011-10-08 13:09
1) Python
2) All GC languages (this includes Python which uses reference counting)
3) zero
GC is shit.
4) Python, but compiled and without GC (or reference counting)
5) http://sam.zoy.org/wtfpl/
(but no ``GC IS SHITE'', that's not an argument and you know that)?
GC is shit.
1. Common Lisp, C, x86 assembly. I like/am fine with some statically typed high-level ones as well (HASKAL, O'Caml, C#, some others), but I'm less productive in them.
2. Hard to say. I don't have any language I absolutely hate, but there are languages which I would rather not write my code in, if I can help it. C++ would be an example. Java and FIOC might be another. I just do with what I have if I really have to, but doesn't mean I like it. Now that I think more carefully, there are some non-general purpose languages (or very close to it) that I have a deep dislike of as I've been forced to write some code in them and the languages have been very badly designed and forced me to write some nasty repetitive and hacky code that I should have probably autogenerated by writing a compiler (but I didn't care enough to make one as it'd take longer than just writing the code in the first place).
3. Many small ones. No large projects released in that way, but some are being kept private for now.
4. That's a hard question. I like my Lisp, so general-purpose stuff would be Lispy. Non-general purpose? Whatever fits best and depending on the audience. Instruction set? Just standard assembly-like syntax (think Intel style).
5. Public domain, BSD/MIT/... I can see some reasons why someone would use LLGPL/LGPL/GPL/AGPL, but I have a hard time thinking I would ever use anything more strong than LLGPL (permits static linking of the library code), unless forced (by using code written in a stronger language).
Name:
Anonymous2011-10-08 14:39
1. C#, C++
2. HeroScript; It is an incredibly frustrating language w/ little documentation being used by the Game Engine that I am working on
3. None
Optional:
4. I am thinking x86 Assembly with C#-like classes
5. BSD and Public Domain
2. What language(s) dislike you and why (but no ``GC IS SHITE'', that's not an argument and you know that)?
Java, due to how strict it is. Things like not automatically casting doubles to ints are really annoying, and just make it frustrating to use.
3. How many projects have you released as opensource yet?
None unfortunately, although I've written a few user scripts. I'm working on something at the moment, but waiting to release it until it gets to the point where it might be useful to use.
Optional:
4. How would your language look like, if you would have to create one from scratch?
A language with the same semantics as a stack based language, but worked as post fix instead. It would pretty much be scheme without any parenthesis, although you could still specify arrays and hash tables, or other collections using brackets. I might allow for functions with delayed evaluation of arguments, but this wouldn't be the default behavior. I would use it as a shell I think. It would be fast to type but difficult to read I'm sure.
5. What is your favorite software license(s)?
The one that lets people use your stuff for anything whatsoever, but they can't claim to have invented it themselves and then sue you. If it was used in a proprietary product, it would be nice if they reported that they used your stuff.
1. Scheme, ML
2. C++, Java, Python
3. I made a few code dumps of obscure tools, real contributions to an established project and lots of random patches.
4. It would pretty much be Scheme.
5. GPLv3+
Name:
Anonymous2011-10-08 18:51
1. C#, javascript, Python
2. C++, syntax is verbose and semantics are crude and painful
3. 10ish
4. Readability of Python, composability of Haskell, Efficient as C, Not GC'd but given better type system to deal with the complexities and common errors associated with manual memory management, Abstracted from its platform via some form of low level bytecode format that could be compiled directly to platform optimized machine code, unlike the JVM bytecode or even LLVM IR which is shit, and more probably
5. public domain
not posting my github you scum
Name:
Anonymous2011-10-08 19:17
1. HTML (I like XML too)
2. javascript (its sooo complicated u know)
3. all of them, u just have to clik "view page source"
4. it would be kind of a mix between html and xml, wouldnt that be great?
5. i like the artistci licence
1. C, Perl
2. Python (has sh ite gc, hates HoP, backwards standard library (see string.join and friends)), Java (same reasons, terrible object model)
3. 3-10 depending on how you count them.
4. JS with decent syntax and standard library, or lightweight Perl 6, less dwimmy with no @ or % sigils (arrays hashes stored in $, no autoflattening except in hyperops.)
5. BSD-ish ones. GPL is useful sometimes too, but I feel the same way about RMS as he does about Jobs, and for mostly the same reasons. 6. vi
Name:
Anonymous2011-10-09 8:48
1. C
2. Anything not Assembly and without C-like syntax
3. 3
4. Pretty much C
5. GPL 3
Name:
Anonymous2011-10-09 12:44
>>28
100 PRINT "C"
200 PRINT "ANYTHING NOT ASSEMBLY AND WITHOUT C-LIKE SYNTAX"
300 PRINT "3": GOTO 300
400 PRINT "PRETTY MUCH C"
500 PRINT "GPL 3"
600 RUN
C
ANYTHING NOT ASSEMBLY AND WITHOUT C-LIKE SYNTAX
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
RUNTIME ERStack overfSegmentation faArgument list too lBad addrCore dumInvalid arguReservState not recovThe Game/polecat kebabs/
1. Scheme, Haskell.
2. Python, mostly because of Guido being Guido. No need to say more about it.
Clojure, mostly because of Hickey, and, although there are some nice and really nice ideas in it, it is poorly done, unlispy, and internally inconsistent (especially for a new language, the core libraries are terrible).
3. None.
4. Probably a cleaner Racket with a better integrated CLOS-like object system, and some of the good ideas from Clojure.
5. MIT, BSD, public domain, WTFPL, (L)LGPL.
Name:
Anonymous2011-10-09 17:23
1. C, Sepples, Unix shell script.
2.
Python: too much loose typed, inconsistently designed, extremely ugly and slow.
Lisp: extremely ugly, backwards-thinking, unproductive. Good only for very specific problems.
3. None, I don't believe in the Open Source business model. I don't beg for donations; I charge.
4. A straightforward language, strongly typed, mostly imperative. Not yet sure if object-driven, but probably not. No "preprocessors", but a powerful macro system (or a sane template-based typing) is also of much use. Not a single aspect, language-wise, directed to low-level issues or performance -- the compiler should do the right thing and don't cripple the program with para-syntax. The least amount of UBs as possible, detectable either with static analysis or well-placed runtime checks (or both).
5. Me as an user, GPL. Me as a developer, the most closed-source, profit-making, freedom-taking license possible.
Name:
Anonymous2011-10-09 17:33
1. perl and python
2. C++ and java, because only masochists would use them.
3. two.
4. I don't.
5. If it's not GPL, it's crap. Long live Stallman!
>>30 1. Scheme, Haskell.
Ah, so you must be the faggot. Pleased to meet you! Go get fucked.
Name:
Anonymous2011-10-10 1:46
>>31
I wish I can see your face when you realize that almost all side-effects and "imperative" code are actually optimization details that a compiler should be able to write.
Name:
Anonymous2011-10-10 1:56
1. See, Sepples, and See Pound.
2. Haskell, because I don't understand the philosophy behind completely functional languages.
3. Around 30 projects (and 5 large ones), but I never bothered to add any actual documentation.
4. Something like scheme without prefix notation and with serialization (compatibility with system-level programming), but with the various functionalities of C#'s LINQ.
5. I like the Boost software license.
>>34
I wish I could see your face if one day you managed to get out of your basement, looked out there and realized nobody gives a single fuck about whether writing non-imperatively is "superior", but prefer to write code which actually do something useful instead of masturbating to abstractions nobody care about.
Name:
Anonymous2011-10-10 2:51
Haskell
- Just like C++, Haskell is very hard to learn, and takes years to master. Things like Monads, Functors, Monoids, Higher-Order Types and a myriad of morphisms are hard to understand, especially without mathematical background. So most programmers probably don't have the ability or will to learn haskell. By all means, Haskell is not ‘simple’ or newbie friendly. Learning its syntax, its libraries, functional programming techniques won't bring you closer to understanding. The true path to understand Haskell lies through Monoid-Functor-Applicative-Arrow-Monad. And even if you mange to learn Haskell, programming it still hogs a lot of brain resources, which could have been put to something more useful, than just showing off about how clever you can be. "Zygohistomorphic prepromorphism: Zygo implements semi-mutual recursion like a zygomorphism. Para gives you access to your result à la paramorphism." -- HaskellWiki
- Haskel is slow and leaks memory. GHC's slow stop-the-world GC does not scale. A good understanding of evaluation order is very important for writing practical programs. People using Haskell often have no idea how evaluation affect the efficiency. It is no coincidence that Haskell programmers end up floundering around with space leaks that they do not understand. "The next Haskell will be strict." -- Simon Peyton-Jones
- Haskell's API lacks higher levels of abstraction, due to absence of variadic functions, optional arguments and keywords. Macros aren't possible either, due to overly complex syntax of Haskell. API documentation is very lacking for newbies: if you want to use regexes, you start at Text.Regex.Posix, seeing that =~ and =~~ are the high level API, and the hyperlinks for those functions go to Text.Regex.Posix.Wrap, where the main functions are not actually documented at all, so you look at the type signatures, trying to understand them and they are rather intimidating (class RegexOptions regex compOpt execOpt => RegexMaker regex compOpt execOpt source | regex -> compOpt execOpt, compOpt -> regex execOpt, execOpt -> regex compOpt where). They are using multi-parameter type classes and functional dependencies. The signature really wont give you any clue to how to actually use this API, which is a science in itself. Haskell is a language where memoization is a PhD-level topic.
- Haskell programming relies on mathematical modelling with type system (a version of mathematical Set Theory). If one does not use the type system for anything useful, it obviously will be nothing but a burden. Programs are limited by the expressiveness of the type system of the language - e.g. heterogeneous data structures aren't possible w/o reinventing explicit tagging. All that makes Haskell bad for prototyping and any new situation, due to need of having design document with all types beforehand, which changes often during prototyping. Any complex project have to reinvent dynamic typing. For instance, Grempa uses dynamic typing because the semantic action functions are put in an array indexing rule and production numbers (Ints) to functions, and they all have different types and so can not be put in an ordinary array expecting the same type for each element.
- The IDE options cannot be as good as those of dynamic programming languages, due to absence of run-time information and access to running program's state. Haskell's necrophilia forces you to work with "dead" code. Like other static languages, Haskell isn't well-known for its “reload on the fly” productivity. No eval or self-modifying code. Haskell code can't be changed without recompiling half-of application and restarting the process. GHCI - is the best Haskell's interactivity can get, and still wont allow you to change types during runtime. As said Simon Peyton-Jones, "In the end, any program must manipulate state. A program that has no side effects whatsoever is a kind of black box. All you can tell is that the box gets hotter."
- Type system and compile-time and link-time errors are distracting and make it harder to run and test your code. And type-checking isn't a substitute for testing. Type-checking is about correspondence to mathematical model, which has nothing to do with correctness - i.e. two numbers can be integers, but their quotient can still result into division by zero. Even though you may hear strong static-typing advocates say, “When your program type-checks, you’ll often find that it just works”, this is simply not true for large, intricate programs. Although type-checking may help you find model-related errors, it is not the same as testing. Thus, it is not a suitable substitute for testing.
- Absence of dynamic scope, implicit open recursion, late binding, and duck typing severely limits Haskell, since there are things that can't be done easily without these features: you can't implement dynamic scope in general (and be type-safe) without converting your entire program to use tagged values. So in this respect, Haskell is inferior to dynamic typing languages.
- Haskell makes it easy to write cryptic programs that no-one understands, not even yourself a few days later. Rich, baroque syntax, lazy evaluation and a tradition defining an operator for every function - all help obfuscation a lot. As a general rule, Haskell syntax is incredibly impenetrable: who in their right mind thought up the operators named .&., <|> and >>=? And, just like with Python, indentation based syntax makes Haskell unusable for CLI.
C++ is like C# but with *true* templates.
C++ is like Java with the ability to do systemlevel programming and without the slowiness.
C++ is like C but with RAII.
If you can learn C#, you can learn C++.
If you can learn C, you can learn C++.
If you can learn Java, you can learn C++.
Haskell is a functional language. C++ is a procedural object-oriented language. Comparing Haskell to C++ is like comparing a smelly, sticky turdball to a delicious, juicy, shiningly red apple.
It doesn't work like that.
You can compare OCaml to Haskell.
You can compare Erlang to Haskell.
You can compare MetaLua to Haskell.
And you can do this because these languages are functional.
But you can't compare a procedural language to a functional language.
Aside from that, Haskell doesn't have an intendation based syntax. The indentation is purely optional, since Haskell allows blocks with {}.
Now kindly take your OMGHAKSAL, and go back to /g/. Thank you.
Name:
Anonymous2011-10-10 3:50
>>39
But C++ has monads!
compM<ListM>()[ makePair[X,Y] | X<=list_with(1,2), guard[true],
Y<=list_with(3,4), guard[ (Y %divides% X) %equal% 3 ] ] ]
>>38
Haskell has The Optional Forced Indentation of Code, your last point is invalid.
Name:
Anonymous2011-10-10 4:03
>>18
4. I am thinking x86 Assembly with C#-like classes
I, see...
1. What language(s) are you most productive in?
C/C++ (C-like C++)
2. What language(s) dislike you and why?
I find java incredibly difficult to work in; even though it does everything for you, I just seem to be less productive.
Pretty much every 'high level language' that's intended for general software development goes here.
3. How many projects have you released as opensource yet?
Lol. Anything I spend my spare time on really, really silly little utility programs. And by released, I mean "here you can have the source if you want it."
Optional:
4. How would your language look like, if you would have to create one from scratch?
Look like C++, but I'd change the function pointer syntax because it's insane. I'd probably do something with the preprocessor, maybe do something with the headers, not sure.
5. What is your favourite software license(s)?
I don't know, I don't really 'relase' my spare-time work under a license, it doesn't really bother me if someone steals my dicking around and puts their name on it.
Name:
Anonymous2011-10-10 5:58
I used to be sympathetic to those people who complained about Python's forced indentation of code, and then I saw how they formatted their code normally. Forcing indentation is perhaps the best thing Python has done for readability, and I will cry myself to sleep if it ever leaves.
1. C++, Python, Javascript
2. Java, C# - verbosity, garbage collector, kiddies who learn Java/C# in their Intro to CS class and never bother to learn anything else for the next 4 years and get confused when trying to understand pointers, having the audacity to not show embarrassment, but indignation.
Perl - for there being over 9000 ways to do something.
3. None
4. Extremely strong typing, forced indentation, fixing C++'s overstretched syntax.
>>44 I used to be sympathetic to those people who complained about Python's forced indentation of code, and then I saw how they formatted their code normally. Forcing indentation is perhaps the best thing Python has done for readability, and I will cry myself to sleep if it ever leaves.
Typical pythonista. Crippling a language so that retards seem harmless isn't a good thing.
Name:
Anonymous2011-10-10 8:54
Removing a tab isn't normally fatal,but on Python it is.