Re: [dev] What is bad with Python
On Wed, Mar 12, 2014, at 15:04, FRIGN wrote: > Impressive, but better use > $ LD_TRACE_LOADED_OBJECTS=1 t > instead of > $ ldd t > next time to prevent arbitrary code-execution[1] in case you're dealing > with unknown binaries. I don't know if it was here and you or somewhere else or someone else, but someone said this before and I pointed out the problems with this argument. It's even worse in this case because you propose using LD_TRACE_LOADED_OBJECTS=1 t [which won't actually work, incidentally, without . in PATH] instead of LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.2 ./t - your proposed command doesn't actually prevent the exploit (it actually makes it easier, by making it possible to exploit with a mere statically-linked program rather than a fancy ELF interpreter trick) Also, wanting to do this with an unknown, untrusted executable is, in practice, _incredibly rare_. And since this is an executable he just built himself, it obviously doesn't apply here. The 'safe' command [which, remember, you got wrong] is onerously long for a suggestion that people should use every time. Maybe the best way forward is to make ldd default to the safe way and require user confirmation (with a warning) before the unsafe one.
Re: [dev] What is bad with Python
On Wed, 12 Mar 2014 21:49:54 +0100 q...@c9x.me wrote: > Maybe surprisingly, then: > > ~% cat > t.ml > let () = print_string "hello world\n" > ~% ocamlopt -o t t.ml > ~% strip t > ~% ls -lh t > -rwxr-xr-x 1 users 124K Mar 12 16:48 t > ~% ldd t > linux-vdso.so.1 (0x7fffbed7) > libm.so.6 => /usr/lib/libm.so.6 (0x7fae08f33000) > libdl.so.2 => /usr/lib/libdl.so.2 (0x7fae08d2f000) > libc.so.6 => /usr/lib/libc.so.6 (0x7fae08987000) > /lib64/ld-linux-x86-64.so.2 (0x7fae09234000) > ~% ./t > hello world > ~% Impressive, but better use $ LD_TRACE_LOADED_OBJECTS=1 t instead of $ ldd t next time to prevent arbitrary code-execution[1] in case you're dealing with unknown binaries. Cheers FRIGN [1]: http://www.catonmat.net/blog/ldd-arbitrary-code-execution/ -- FRIGN
Re: [dev] What is bad with Python
Hi all, On Wed, Mar 05, 2014 at 02:49:07PM +0100, Troels Henriksen wrote: > FRIGN writes: > > > Yes, that's a point. Go implements GC and other stuff in the binary, > > which blows its size up a lot. > > (I do not use Go myself, but in the Haskell world we have a similar > issue - my current project compiles to a statically linked 53MiB binary, > although this is admittedly with profiling support included.) Maybe surprisingly, then: ~% cat > t.ml let () = print_string "hello world\n" ~% ocamlopt -o t t.ml ~% strip t ~% ls -lh t -rwxr-xr-x 1 users 124K Mar 12 16:48 t ~% ldd t linux-vdso.so.1 (0x7fffbed7) libm.so.6 => /usr/lib/libm.so.6 (0x7fae08f33000) libdl.so.2 => /usr/lib/libdl.so.2 (0x7fae08d2f000) libc.so.6 => /usr/lib/libc.so.6 (0x7fae08987000) /lib64/ld-linux-x86-64.so.2 (0x7fae09234000) ~% ./t hello world ~% It does not suck too hard! Does it? - q
Re: [dev] What is bad with Python
Hi, 2014-03-05 16:58 GMT+01:00 FRIGN : >> C programs can also be run as scripts, but it doesn't make C a >> scripting language. > > Where did you pick that up? Several options are available for using C as a scripting language: http://stackoverflow.com/a/1513961/131264 > I agree on that point. Let's not get hung up at the definitions, but > return to a constructive discussion. Agreed. -- Sincerely, Alexander Rødseth
Re: [dev] What is bad with Python
On Wed, 5 Mar 2014 18:20:43 +0100 Alexander Rødseth wrote: > If you don't think the definition of a compiled language is that it > can be compiled down to native code, I would love to hear your > definition. Well, then any language would be a compiled language. The problem here is, that the language interpreter does certain things for certain expressions, thus compiling an interpreted language only involves knowing what the interpreter does and putting it into direct system calls. However, most interpreted languages haven't been designed to be compiled. Thus, the syntax may be very simple, but what is interpreted in the end tends to be very complex (take Java and Python as good examples for that). > Some even think that Java can be counted as a "compiled language", > even though it only compiles down to bytecode (until JIT-ed). Regular > Python also compiles down to byte code (.pyc/.pyo), so if you should > happen to think Java is a compiled language, surely you must think > that Python is a compiled language too. Java definitely is an interpreted language, because the computer needs a translator to understand what the hell is going on. If you compile Java, the resulting machine-code may run as expected, but is far from a cleanly written C-program because of the overhead and because of the fact Java hasn't been designed to be compiled, but interpreted. > C programs can also be run as scripts, but it doesn't make C a > scripting language. Where did you pick that up? > I think the compiled/scripting distinction is pretty meaningless. It's > more interesting to consider which languages are faster and if low > level code can be called or not (can you call C functions, could you > write an operating system?). Arguably, expressiveness and developer > productivity (however measured) might be even more important. I agree on that point. Let's not get hung up at the definitions, but return to a constructive discussion. Cheers FRIGN -- FRIGN
Re: [dev] What is bad with Python
Hi, 2014-03-05 15:41 GMT+01:00 FRIGN : > Well, you could also compile shell-scripts if you had the time to write > the proper interfaces. Does this make it a compiled language? Hell no! Yes, if shell-scripts are _compiled_ to native code, then it would make them _compiled_. > It still is a scripting language, even if you can compile it with some tweaks. If you don't think the definition of a compiled language is that it can be compiled down to native code, I would love to hear your definition. Some even think that Java can be counted as a "compiled language", even though it only compiles down to bytecode (until JIT-ed). Regular Python also compiles down to byte code (.pyc/.pyo), so if you should happen to think Java is a compiled language, surely you must think that Python is a compiled language too. C programs can also be run as scripts, but it doesn't make C a scripting language. I think the compiled/scripting distinction is pretty meaningless. It's more interesting to consider which languages are faster and if low level code can be called or not (can you call C functions, could you write an operating system?). Arguably, expressiveness and developer productivity (however measured) might be even more important. Awaiting your definition of a "compiled language". -- Sincerely, Alexander Rødseth
Re: [dev] What is bad with Python
On Wed, 5 Mar 2014 17:26:46 +0100 Alexander Rødseth wrote: > Nuitka compiles Python to C++. I never made any claims about speed and > think the two should not be conflated. > Python can now also be compiled, and should be counted as a compiled language. Well, you could also compile shell-scripts if you had the time to write the proper interfaces. Does this make it a compiled language? Hell no! It still is a scripting language, even if you can compile it with some tweaks. -- FRIGN
Re: [dev] What is bad with Python
Hi, 2014-03-05 15:05 GMT+01:00 FRIGN : > Benchmarks or it didn't happen. Nuitka compiles Python to C++. I never made any claims about speed and think the two should not be conflated. Python can now also be compiled, and should be counted as a compiled language. > Or just leave it to the developer? Sure, developers are free to write code with messy whitespace in other languages than Python, I just don't think it should be counted as a disadvantage, but a preference. -- Sincerely, Alexander Rødseth xyproto / TU
Re: [dev] What is bad with Python
On Wed, 5 Mar 2014 16:50:58 +0100 Alexander Rødseth wrote: > After Nuitka arrived (http://nuitka.net/), Python is also a "proper > compiled language" (if it wasn't already, because of Shedskin > http://code.google.com/p/shedskin/). Benchmarks or it didn't happen. Python-compilers aren't a new thing, and from what I have seen, they are horribly inefficient. If you design a language without compilers in mind, compiling this language will turn into a big mess. > C that has been written without regard to whitespace is horrible to > read. People should care about whitespace both for > whitespace-sensitive and for whitespace-insensitive languages. Or just leave it to the developer? Cheers FRIGN -- FRIGN
Re: [dev] What is bad with Python
Hi, 2014-03-03 23:25 GMT+01:00 koneu : > Isn't Python that white space sensitive crap people like to use instead > of proper compiled languages? After Nuitka arrived (http://nuitka.net/), Python is also a "proper compiled language" (if it wasn't already, because of Shedskin http://code.google.com/p/shedskin/). C that has been written without regard to whitespace is horrible to read. People should care about whitespace both for whitespace-sensitive and for whitespace-insensitive languages. -- Sincerely, Alexander Rødseth xyproto / TU
Re: [dev] What is bad with Python
Hey, As a new Python programmer, there are only a few things that have so far bothered me: * Python 2-3 transition (I ended up learning 2 "by accident", but easily learned 3 as they are quite similar) * Packaging/Module system (Maybe just because I haven't had enough experience with it...) * Python 3 is not as widely used : ( Other OSs have not yet ported it to their platform...(Haiku OS, 9front) and libraries are still using Python 2. All in all though I've been very pleased with the readability and elegance of Python code. Speed and resources don't matter to me when using Python. If they did, I would (and everyone else would agree) be using C. As Christoph said it is great for prototyping, and others would suggest even for production use. Regards, Lee On Wed, Mar 5, 2014 at 9:02 AM, pancake wrote: > The name. >
Re: [dev] What is bad with Python
The name.
Re: [dev] What is bad with Python
On Wed, 05 Mar 2014 14:49:07 +0100 Troels Henriksen wrote: > A solution to this is to implement the GC (and other runtime parts) as a > dynamic library. This code would also be shared in memory by all > running Go processes. Well, I tried that and it worked. The Hello-World-binary is around 19KB then. However, then the point of discussion, namely static binaries, is lost. > (I do not use Go myself, but in the Haskell world we have a similar > issue - my current project compiles to a statically linked 53MiB binary, > although this is admittedly with profiling support included.) 53M is a lot! Well, I think it's time for buying another external hard-drive for all your Haskell-binaries :P. Cheers FRIGN -- FRIGN
Re: [dev] What is bad with Python
FRIGN writes: > Yes, that's a point. Go implements GC and other stuff in the binary, > which blows its size up a lot. > However, if we take the Hello-World-program as the lowest common > denominator, we could calculate, that if we ported all basic tools in > sbase (currently 70) to the Go language, the compiled binaries would > need around 100MB-200MB _after_ stripping unnecessary stuff from it (as > explained earlier). A solution to this is to implement the GC (and other runtime parts) as a dynamic library. This code would also be shared in memory by all running Go processes. (I do not use Go myself, but in the Haskell world we have a similar issue - my current project compiles to a statically linked 53MiB binary, although this is admittedly with profiling support included.) -- \ Troels /\ Henriksen
Re: [dev] What is bad with Python
On Wed, 5 Mar 2014 00:16:13 -0800 Anthony Martin wrote: > People are working on this: Well, then let's see what time will bring us ;). Cheers FRIGN -- FRIGN
Re: [dev] What is bad with Python
On Wed, 5 Mar 2014 16:27:24 +0800 Chris Down wrote: > Storage space is really cheap. If there is some reason that it is > desirable for the binaries to be bigger as a tradeoff, I am all in > favour of it (of course, if the binary size can be reduced without much > complication, I'm also in favour of that, I just don't care an awful lot > in non-embedded scenarios, where I would almost certainly use C anyway). Well, I do care about storage-space, as I am using an SSD! > Also, "Hello World" is not really representative of a typical program. > Bear in mind that there are many things that you bear the cost of using > once, and not again. I agree the size seems large, but with drives > floating at around $0.5/MB, I care little about it for non-embedded > applications. Yes, that's a point. Go implements GC and other stuff in the binary, which blows its size up a lot. However, if we take the Hello-World-program as the lowest common denominator, we could calculate, that if we ported all basic tools in sbase (currently 70) to the Go language, the compiled binaries would need around 100MB-200MB _after_ stripping unnecessary stuff from it (as explained earlier). And don't get me started on the busybox-approach! This may be just 0.01% of a 1TB-drive, but it sure adds up on a 128G or even 64G SSD. > I appreciate that my needs/use cases are not necessarily representative > of others on this list. Yes, that's a fair assumption. -- FRIGN
Re: [dev] What is bad with Python
On Tue, Mar 4, 2014 at 10:34 PM, Szabolcs Nagy wrote: > * Silvan Jegen [2014-03-04 21:30:47 +0100]: >> On Tue, Mar 04, 2014 at 08:56:18PM +0100, Szabolcs Nagy wrote: >> > dont expect fast opengl access from go) and you cannot really >> > use it for quick scripting tasks >> >> Why should Go not be suited for quick scripting tasks? I use Go to parse >> text files, reformat them and/or sending them to restful services. It >> really works quite well. > > eg i have various awk, lua and sh scripts on my router > to do things, if there is some bug in them i can log in > to the router and fix them right there or try them on > another host I wouldn't use Go (nor Python) on stuff I can reasonably do with awk or sh either. For a little more involved stuff like processing JSON/XML files a language like Go fits the bill very nicely though. > i don't need a cross compiler toolchain for this or > complicated setup for deploying different binaries > to different systems True. You do need the interpreter though which you have to install for each architecture as well. Instead of the interpreter you could install the Go toolchain and you wouldn't have to worry about binary compatibility either. > (not to mention that a statically linked go executable > would not even fit on the target and the compiler would > pedantically complain about unused package imports or > other issues that does not matter in a single-use script) You are right in that forcing you to adhere to the engineering practice Go enforces can be annoying in one-off scripts. I do think however that this is a very minor issue since deleting an unused line of code is not really a lot of effort. As for binary size, it really is not an issue when you work on amd64 servers or desktop computers. On ARM it can be, I assume (though Go seems to work on the Raspberry Pi reasonably well). > for me scripting means that you can write one-liners to > a command prompt or edit a single text file with iterative > updates and don't need development tools to execute it I think I my definition of scripting differs somewhat from yours. I wouldn't write one-liners in either Python or Go for example (I would use awk, sed and shell). Iterative updates you get with Go as well since compilation is so fast. Actually, you can get more 'script-like' behaviour by just executing 'go run file.go' (running a go script that processes xml and has a compiled size of 2.6MB that way takes a little less than 1.1 seconds for building and executing which should be quick enough for iterative development). > maybe go has a better http library than other languages, > so you can easily automate such tasks, but that does not > make it a scripting language imo I see where you are coming from but Go fits my scripting use cases just fine. The fact that Go compiles to machine code while giving you a lot of conveniences that are prevalent in scripting languages (automatic memory management and type inference when wanted) blurs the line between scripting/non-scripting language in the best ways.
Re: [dev] What is bad with Python
FRIGN writes: > Well, what I noticed is the huge size of the compiled binaries. > 2.2M for a "Hello World"-program is an unreasonable demand. It's > possible to strip the size to around 1.2M by passing > -ldflags '-s -w' > to "go build". > This is quite inhibiting, but I'm glad to see this modern > language default to static linking. Storage space is really cheap. If there is some reason that it is desirable for the binaries to be bigger as a tradeoff, I am all in favour of it (of course, if the binary size can be reduced without much complication, I'm also in favour of that, I just don't care an awful lot in non-embedded scenarios, where I would almost certainly use C anyway). Also, "Hello World" is not really representative of a typical program. Bear in mind that there are many things that you bear the cost of using once, and not again. I agree the size seems large, but with drives floating at around $0.5/MB, I care little about it for non-embedded applications. I appreciate that my needs/use cases are not necessarily representative of others on this list. pgprzR0hPjBAe.pgp Description: PGP signature
Re: [dev] What is bad with Python
FRIGN once said: > Well, what I noticed is the huge size of the compiled binaries. > 2.2M for a "Hello World"-program is an unreasonable demand. It's > possible to strip the size to around 1.2M by passing > -ldflags '-s -w' > to "go build". > This is quite inhibiting, but I'm glad to see this modern > language default to static linking. People are working on this: https://code.google.com/p/go/issues/detail?id=6853 Anthony
Re: [dev] What is bad with Python
* Szabolcs Nagy 2014-03-04 20:57 > […] thanks you cared to explain --s.
Re: [dev] What is bad with Python
* Silvan Jegen [2014-03-04 21:30:47 +0100]: > On Tue, Mar 04, 2014 at 08:56:18PM +0100, Szabolcs Nagy wrote: > > dont expect fast opengl access from go) and you cannot really > > use it for quick scripting tasks > > Why should Go not be suited for quick scripting tasks? I use Go to parse > text files, reformat them and/or sending them to restful services. It > really works quite well. eg i have various awk, lua and sh scripts on my router to do things, if there is some bug in them i can log in to the router and fix them right there or try them on another host i don't need a cross compiler toolchain for this or complicated setup for deploying different binaries to different systems (not to mention that a statically linked go executable would not even fit on the target and the compiler would pedantically complain about unused package imports or other issues that does not matter in a single-use script) for me scripting means that you can write one-liners to a command prompt or edit a single text file with iterative updates and don't need development tools to execute it maybe go has a better http library than other languages, so you can easily automate such tasks, but that does not make it a scripting language imo
Re: [dev] What is bad with Python
On 03/04/2014 09:23 PM, Zack Breckenridge wrote: I would say these are both pretty good indictments against both languages. So what are some preferred alternatives? I like Squirrel[0] and Solid[1] alot. Both of them interact well with C. The Solid runtime is written in pure C, so it is the preferred of the two of course. (0) http://www.squirrel-lang.org/ (1) https://github.com/chameco/Solid/
Re: [dev] What is bad with Python
On Tue, Mar 04, 2014 at 08:56:18PM +0100, Szabolcs Nagy wrote: > * Silvan Jegen [2014-03-04 14:27:26 +0100]: > > On Tue, Mar 4, 2014 at 9:25 AM, FRIGN wrote: > > > A question to everyone on this list: What do you think about the > > > Go-language? > > > > I used Python for all my scripting needs before Golang hit version 1.0 > > i hear this a lot and don't quite understand > > you use python as a glue language (between dynamically > loadable extensions written in c and wrapped so one can > use them from python: the drawback here is that as usual > the heavy python runtime has unspecified interactions with > the c runtime eg. if you load a lib that starts threads and No, I do not use Python with C extensions. That was someone else. > then you call os.fork() from python) or for writting > scripts/single shot programs/prototypes (where the simple > syntax, dynamic types, repl etc helps) > > go is not very good for either of these: it cannot directly > interact with anything written in c (it has a hack (cgo) to > initialize the c runtime in a separate thread but that's > rather fragile and slower than a direct function call, eg. I remember reading about C function call overhead when calling them from Go but as I have written in my prior mail, I use Go for simple scripting tasks, not to call out to C code. > dont expect fast opengl access from go) and you cannot really > use it for quick scripting tasks Why should Go not be suited for quick scripting tasks? I use Go to parse text files, reformat them and/or sending them to restful services. It really works quite well. > go can be used when you interface with software across > network or process boundaries (it cannot interface with That's what I use it for. > existing libraries easily so they have to rewrite every > userspace lib in go, however it can interface with os > syscalls as long as the syscall abi is stable: it is not > on some systems such as openbsd) > > > It is not without its problems though: > > > > * There are no generics (it is not clear at the moment whether they > > i dont get this either > > you can do a lot of things without generics and > just generate code when that's what you need.. On the lines you cut out I mentioned that I do not really miss any generics for the cases I use Go for. The lack of generics is not an issue for me (not yet anyway). > > * The XML/JSON unmarshaling is cumbersome (I think I prefer the > > i dont think this is the bigest issue in go.. Well, it is for my use cases :-) > it has segmented stack and you cannot handle reliably if > a goroutine stackgrow fails to allocate (and it is slower > than just using huge stack in a 64bit address space), it has > userspace n:m task scheduling with it's known issues (no > preemptive scheduling etc) and a gc with potentially large > memory overhead and high latency so you cannot use it for > anything with hard-realtime constraints, it does not have fenv I think all these points are true for Python as well. Except that the CPython interpreter itself is severely concurrency-challenged: https://wiki.python.org/moin/GlobalInterpreterLock > access semantics or long doubles on hw that supports this, so > not really suitable for scientific computing (well barely > anything can do this other than c, fortran or asm) the math > library is not very high quality either and various builtin > packages are much less optimized than the ones available in c > (big, crypto, regex, image..), so often simple python scripts > can beat go in performance, heavy usage of go interfaces and > runtime type information can make things slow as well Math libraries (especially for linear algebra) come up as a topic quite often in the golang-nuts mailing list. There still does not seem to be a consensus about the best way to handle matrices in Go. Again, for my basic requirements those points do not matter however.
Re: [dev] What is bad with Python
On Tue, Mar 4, 2014 at 12:56 PM, Szabolcs Nagy wrote: > * Silvan Jegen [2014-03-04 14:27:26 +0100]: > the heavy python runtime has unspecified interactions ... > go is not very good for either of these: it cannot directly > interact with anything written in c (it has a hack (cgo) ... I would say these are both pretty good indictments against both languages. So what are some preferred alternatives next to C? Regards, Zack
Re: [dev] What is bad with Python
* Silvan Jegen [2014-03-04 14:27:26 +0100]: > On Tue, Mar 4, 2014 at 9:25 AM, FRIGN wrote: > > A question to everyone on this list: What do you think about the > > Go-language? > > I used Python for all my scripting needs before Golang hit version 1.0 i hear this a lot and don't quite understand you use python as a glue language (between dynamically loadable extensions written in c and wrapped so one can use them from python: the drawback here is that as usual the heavy python runtime has unspecified interactions with the c runtime eg. if you load a lib that starts threads and then you call os.fork() from python) or for writting scripts/single shot programs/prototypes (where the simple syntax, dynamic types, repl etc helps) go is not very good for either of these: it cannot directly interact with anything written in c (it has a hack (cgo) to initialize the c runtime in a separate thread but that's rather fragile and slower than a direct function call, eg. dont expect fast opengl access from go) and you cannot really use it for quick scripting tasks go can be used when you interface with software across network or process boundaries (it cannot interface with existing libraries easily so they have to rewrite every userspace lib in go, however it can interface with os syscalls as long as the syscall abi is stable: it is not on some systems such as openbsd) > It is not without its problems though: > > * There are no generics (it is not clear at the moment whether they i dont get this either you can do a lot of things without generics and just generate code when that's what you need.. > * The XML/JSON unmarshaling is cumbersome (I think I prefer the i dont think this is the bigest issue in go.. it has segmented stack and you cannot handle reliably if a goroutine stackgrow fails to allocate (and it is slower than just using huge stack in a 64bit address space), it has userspace n:m task scheduling with it's known issues (no preemptive scheduling etc) and a gc with potentially large memory overhead and high latency so you cannot use it for anything with hard-realtime constraints, it does not have fenv access semantics or long doubles on hw that supports this, so not really suitable for scientific computing (well barely anything can do this other than c, fortran or asm) the math library is not very high quality either and various builtin packages are much less optimized than the ones available in c (big, crypto, regex, image..), so often simple python scripts can beat go in performance, heavy usage of go interfaces and runtime type information can make things slow as well
Re: [dev] What is bad with Python
> I'm afraid to ask: what do you think about the Rust language? Personally, I mostly really like Go. But I would say one of my biggest problems with Go is (as far as I know) forced Garbage Collection. Depending on your point of view, that's either a strength or weakness of the language. From what I understand, Rust at least has optional GC, which is a plus for me. But I'm also aware that it has a bunch of other nice features I haven't looked into yet. So that's about all I can say. Go does seem like a great language for large (Google size) teams of programmers all working (mostly) in userspace to coordinate large distributed systems. Correct me if I'm wrong but I see the suckless community focused on average user software: phones/tablets/embedded, laptops, servers, maybe small clusters? Personally, I'm mostly interested in smaller scale since that's what I interact with most often and I like to think about scaling down rather than scaling up. Which brings me to: I'm afraid to ask: what do you think about Forth? - Zack
Re: [dev] What is bad with Python
On Tue, Mar 4, 2014 at 12:25 AM, FRIGN wrote: > A question to everyone on this list: What do you think about the > Go-language? I'm afraid to ask: what do you think about the Rust language?
Re: [dev] What is bad with Python
Hello, Strake wrote: > * Member selection is in some cases cumbersome, in which it would not > be in C, which is related to ¬(variant types) Can you explain more what you mean? yours, Bobby
Re: [dev] What is bad with Python
FRIGN wrote: > You can write beautiful and readable code in any language. [assuming that "you" means the reader in general, not S. Jegen in particular] False. I can't write such code in MATLAB, for example. > A question to everyone on this list: What do you think about the Go-language? I'm not a fan: • Case-sensitive exports seem wonky to me • Interfaces rather than variant types [but not interfaces per se] are weak • Member selection is in some cases cumbersome, in which it would not be in C, which is related to ¬(variant types) Mind, my experience is little, and this is merely what I found writing a λ-calculus interpreter in Go.
Re: [dev] What is bad with Python
* Silvan Jegen [2014-03-04 14:30]: * There are no generics (it is not clear at the moment whether they will be incorporated into the language in the future) but with my simple requirements I have not been missing them. They will be incorporated as soon as someone finds a good solution to this problem: http://research.swtch.com/generic I've written quite a bit of Go code, and the lack of generics has never been a problem to me. If you're really desperate, you can always go this route: https://github.com/BurntSushi/ty This takes away the compile-time type safety away, though, and moves it to the runtime. Cheers, Andreas
Re: [dev] What is bad with Python
On Tue, 4 Mar 2014 14:27:26 +0100 Silvan Jegen wrote: > I am quite sure I would find more issues with Golang if I would be > writing more substantial programs but until then I will be happily > coding more in it. Well, what I noticed is the huge size of the compiled binaries. 2.2M for a "Hello World"-program is an unreasonable demand. It's possible to strip the size to around 1.2M by passing -ldflags '-s -w' to "go build". This is quite inhibiting, but I'm glad to see this modern language default to static linking. Cheers FRIGN -- FRIGN
Re: [dev] What is bad with Python
On Tue, Mar 4, 2014 at 9:25 AM, FRIGN wrote: > A question to everyone on this list: What do you think about the > Go-language? I used Python for all my scripting needs before Golang hit version 1.0 (around two years ago). After giving it another look then, I have come to prefer it over Python. The static typing together with the superb tooling is very appealing to me (and all Go programs are statically compiled which will be a desirable feature for a lot of you). It is not without its problems though: * There are no generics (it is not clear at the moment whether they will be incorporated into the language in the future) but with my simple requirements I have not been missing them. * The XML/JSON unmarshaling is cumbersome (I think I prefer the Elementtree approach of Python) but maybe I am just misusing the standard library. At least you get type safety when using the Golang approach. I am quite sure I would find more issues with Golang if I would be writing more substantial programs but until then I will be happily coding more in it.
Re: [dev] What is bad with Python
I use python. But only less often. The last time I use it is when I tried processing txt files contents which includes string manipulations, regex matching, etc. On Tuesday, March 4, 2014 7:51 PM, psepheroth wrote: I use python. But only less often. The last time I use it is when I tried processing txt files contents which includes string manipulations, regex matching, etc. On Tuesday, March 4, 2014 7:33 PM, sin wrote: On Tue, Mar 04, 2014 at 09:25:26AM +0100, FRIGN wrote: > A question to everyone on this list: What do you think about the > Go-language? I have no experience with python, but I use golang a lot. Lua is also quite fun to code in.
Re: [dev] What is bad with Python
On Tue, Mar 04, 2014 at 09:25:26AM +0100, FRIGN wrote: > A question to everyone on this list: What do you think about the > Go-language? I have no experience with python, but I use golang a lot. Lua is also quite fun to code in.
Re: [dev] What is bad with Python
On Tue, 4 Mar 2014 11:05:54 +0100 Manolo Martínez wrote: >But I haven't experienced any maleficency yet :) I probably haven't chosen the right words for it. I referred maleficency to the breaking of language-conventions, because you handle those special types. Quite similar to what you can see writing code with GTK and all its derived types. A question to everyone on this list: What do you think about the Go-language? Cheers FRIGN -- FRIGN
Re: [dev] What is bad with Python
On 03/04/14 at 08:37am, FRIGN wrote: > No wonder, given Numpy and Scipy are mostly written in C and Fortran ;). That is true. As an aside, apparently Julia scientific ibraries are mostly written in Julia, which makes me wonder. > Moreover, from what I understand, you actually use special types > supplied by the Scipy packages instead of core-language-features, which > could also be maleficent. Yes, and everything is done through a special numpy.array object. But I haven't experienced any maleficency yet :) Manolo
Re: [dev] What is bad with Python
On Tue, 4 Mar 2014 10:18:02 +0100 Manolo Martínez wrote: > I am not a programmer, but I write code in scientific modelling. Python > + Numpy + Scipy (which, I understand, takes care of typing in a > reasonable manner) is plenty fast, and very readable (and writable). No wonder, given Numpy and Scipy are mostly written in C and Fortran ;). So basically, using Numpy and Scipy, you take the convenience of the Python syntax (*debatable*) and combine it with an interface to the background-libs written in fast, compiled languages. However, what we're discussing here is vanilla Python with the tools the normal user has available on his computer. I doubt a reasonable majority has Numpy and Scipy installed on its computers, but at least, it is one way to get along. Moreover, from what I understand, you actually use special types supplied by the Scipy packages instead of core-language-features, which could also be maleficent. -- FRIGN
Re: [dev] What is bad with Python
On 03/04/14 at 07:49am, FRIGN wrote: > On Tue, 4 Mar 2014 09:14:05 +0100 > Silvan Jegen wrote: > > My biggest gripe with the language is the absence of static type > > checking at compile time. > In some cases, Python is up to 50% slower than well-written C, but to > be fair, it does the memory-management for you ;). I am not a programmer, but I write code in scientific modelling. Python + Numpy + Scipy (which, I understand, takes care of typing in a reasonable manner) is plenty fast, and very readable (and writable). Manolo
Re: [dev] What is bad with Python
On Tue, 4 Mar 2014 09:14:05 +0100 Silvan Jegen wrote: > I have been using Python for a few years and never had any version > management issues. I assume this was because I use it for simple > scripting where mostly the standard library was needed which is > actually an argument for the "batteries included" approach. Well, I was using Python for years in environments like Blender and often encountered those bloody version-issues when stumbling upon useful scripts for both the Game Engine and my system in general. Scavenging code is a PITA, writing it yourself is probably not. The issue with only using a certain subset of a language has often been discussed. > I can't really talk about the implementation itself but the language > is very expressive and tends to be easy to read as well. So I would > say the language does a good job of making the more complex > functionality available for when (if?) you need it while not > sacrificing any readability. Take my portage-example for software where this isn't the case. You can write beautiful and readable code in any language. Python may encourage this, but you might as well just learn it in the first place instead of being forced to do it. > My biggest gripe with the language is the absence of static type > checking at compile time. I would not recommend Python to anyone > wanting to write a non-trivial robust program. For simple scripting > and (algorithm) prototyping it is fine (but slow, I hear). > And there is the whole global interpreter lock mess of course... Too few people realize how bloated Python-scripts are. I'd like to encourage everyone to try out a Python->C compiler and see what it spits out even for the most trivial program. This may not be the most scientific approach, but it gives an impression on what an interpreted language tends to consume. In some cases, Python is up to 50% slower than well-written C, but to be fair, it does the memory-management for you ;). > In my opinion Go(lang) makes Python obsolete in almost all respects. Yes, Go is a fine language (and compiled). Cheers FRIGN -- FRIGN
Re: [dev] What is bad with Python
On Tue, Mar 4, 2014 at 4:59 AM, Zack Breckenridge wrote: > All language issues aside, I think one of the things (that others have > touched on here but I'd like to reiterate) that makes something > suckless is fewer dependencies and less version management. > > Due to Python's "batteries included" philosophy and the large amount > of 3rd party libraries often used, most code over 30-40 lines tends to > bring with it a lot of dependency and version management issues (pip, > python2 vs python3, virtualenv, etc) that one might not have using a > different language. The more you have to install, the more moving > parts your code has, and the more it tends toward suckage over time. I have been using Python for a few years and never had any version management issues. I assume this was because I use it for simple scripting where mostly the standard library was needed which is actually an argument for the "batteries included" approach. > [...] > Also, part of what I interpret as the "suckless philosophy" is > simplicity in implementation as well as in usage. Python is simple to > *use* (by some standards) but simple at the expense of a lot of hidden > underlying complexity. Compare for example, the implementation of > CPython versus say, Lua. I can't really talk about the implementation itself but the language is very expressive and tends to be easy to read as well. So I would say the language does a good job of making the more complex functionality available for when (if?) you need it while not sacrificing any readability. My biggest gripe with the language is the absence of static type checking at compile time. I would not recommend Python to anyone wanting to write a non-trivial robust program. For simple scripting and (algorithm) prototyping it is fine (but slow, I hear). And there is the whole global interpreter lock mess of course... In my opinion Go(lang) makes Python obsolete in almost all respects. Cheers, Silvan
Re: [dev] What is bad with Python
All language issues aside, I think one of the things (that others have touched on here but I'd like to reiterate) that makes something suckless is fewer dependencies and less version management. Due to Python's "batteries included" philosophy and the large amount of 3rd party libraries often used, most code over 30-40 lines tends to bring with it a lot of dependency and version management issues (pip, python2 vs python3, virtualenv, etc) that one might not have using a different language. The more you have to install, the more moving parts your code has, and the more it tends toward suckage over time. You'll often hear people talk of AWK and Perl not because of language issues but because they're likely to be installed on almost any UNIX or UNIX-like operating system by default. Also, part of what I interpret as the "suckless philosophy" is simplicity in implementation as well as in usage. Python is simple to *use* (by some standards) but simple at the expense of a lot of hidden underlying complexity. Compare for example, the implementation of CPython versus say, Lua. Anyway, just my $.02. Regards, Zack
Re: [dev] What is bad with Python?
> On 03/03/2014 11:21 PM, Szymon Olewniczak wrote: > > [a whole load of quoting] Mind trimming your quotes? On Mon, Mar 03, 2014 at 11:25:18PM +0100, koneu wrote: > Isn't Python that white space sensitive crap How does that have any bearing on sucklessness? It's a separate argument. Practically, whitespace sensitivity doesn't necessarily have much negative impact, would have been nice to force upon certain people, and, at least in Python, has rules flexible enough that it's quite nice. > people like to use instead of proper compiled languages? So shell sucks then? Anyhow, you can make your own mostly conformant implementation that compiles rather than interprets or JITs if you like. Not everything needs to be compiled, as nice as it would be sometimes. Regards, Alex Pilon pgpxzD0qgmTB1.pgp Description: PGP signature
Re: [dev] What is bad with Python
Quoth FRIGN: > I recently thought about porting portage (written in Python) to C and > read into its source code. > Calling it a mess is a compliment, given there are almost no comments > and lots of deprecated functions. > Portage is not only an example for quite unmaintainable code, but also > for a program which as obviously been deployed with the wrong > programming language. > A core package-manager shouldn't depend on python, it should be > statically linked and _fast_. Quite a few years ago, back when I was using gentoo on a low powered computer, portage was just too memory hungry to run, so I switched to paludis. I think it's C++, so I have no idea if it's sensible under the covers, but it was far more reasonable in terms of resource usage, at least. I quite liked gentoo's ebuild system too. I keep meaning to look at the BSD ports system, which is similar, but never quite get around to it.
Re: [dev] What is bad with Python
On Mon, Mar 03, 2014 at 11:21:02PM +0100, Szymon Olewniczak wrote: > […] I must admit that I've found Python much less harmful that I had > previously considered it to be. Do you care about the language or a particular implementation? For the latter, packaging sucks, it has libraries to deal with real-world suck, it runs on sucky OSes. Python 2 is inferior language-wise vis-à-vis Python 3. > […] the code is readable and what is very important it simplify many > things. Do people on this list seriously consider using a language with inferior namespacing, a primitive error model, lack of sometimes useful purely functional constructs, certain data structures not in the standard library, a very primitive type system, weak typing, tedious and error-prone string manipulation, etc for performance-insensitive general purpose programming? I'm not advocating Python for memory, size, or execution time-sensitive code, where absolute control is important, or when you want low dependencies. > In addition it has many great libraries so why do not use Python at > least as a prototype language. Should we care about *prototype* languages in the context of suckless? > Mayby it's multi-paradigm aproach is the problem but what alternatives > to python do you see? How is that a flaw? Dogmatism is a disease. It's one of the reasons why Java sucks, and C makes me write more boilerplate. > awk? Do you really want to use awk for things that aren't its specialty? It's a great language in its own right, not a general-purpose language, in spite of its Turing completeness. > And at last what do you thing about Ruby which is quite similar to the > python in many aspects? Ruby has more powerful lambdas (“blocks” as they call them), has more shorthand (not that I consider that that great actually), etc. Anyhow, do you care about the implementation or the language itself? Regards, Alex Pilon pgp8Qo07tLqvw.pgp Description: PGP signature
Re: [dev] What is bad with Python
On Tue, 4 Mar 2014 00:06:19 +0100 v4hn wrote: > In the end, there a lot of people who learnt to write unmaintainable code. > I seriously prefer perl-programmers who know what they're doing. Which brings us back to stali: I recently thought about porting portage (written in Python) to C and read into its source code. Calling it a mess is a compliment, given there are almost no comments and lots of deprecated functions. Portage is not only an example for quite unmaintainable code, but also for a program which as obviously been deployed with the wrong programming language. A core package-manager shouldn't depend on python, it should be statically linked and _fast_. -- FRIGN
Re: [dev] What is bad with Python
On Mon, Mar 03, 2014 at 09:35:18PM +0100, FRIGN wrote: > On Mon, 3 Mar 2014 23:21:02 +0100 > Szymon Olewniczak wrote: > > (...) and I must admit that I've found Python much less > > harmful that I had previously considered it to be. > > I agree on this one. The language designers did a good job. That depends on your perspective. Python, _in my opinion_ much more than C code, should not be written by beginners, but on the other hand is one of the most attractive languages for newbies. The language is way _too_ flexible and makes people believe they know how to code just because they know a couple of more or less sensible concepts like lambda, list comprehension, *iterator, iterator*int, ... I observe _really strong_ hammer->nail effects quite regularly... In the end, there a lot of people who learnt to write unmaintainable code. I seriously prefer perl-programmers who know what they're doing. v4hn pgpKZS70fuuW0.pgp Description: PGP signature
Re: [dev] What is bad with Python
On 03/03/2014 11:21 PM, Szymon Olewniczak wrote: Hi, I've recently had a presentation(during local Linux User Group meeting) about some basic ideas Unix philosophy and suckless projects. This has led my attention once to the topic of programming languages and I must admit that I've found Python much less harmful that I had previously considered it to be. And when I can point out why does Perl, PHP, JS sucks, python is another way round. Python has precise design, the code is readable and what is very important it simplify many things. In addition it has many great libraries so why do not use Python at least as a prototype language. Mayby it's multi-paradigm aproach is the problem but what alternatives to python do you see? awk? Limbo? And at last what do you thing about Ruby which is quite similar to the python in many aspects? BR, Szymon Isn't Python that white space sensitive crap people like to use instead of proper compiled languages?
Re: [dev] What is bad with Python
Greetings. On Mon, 03 Mar 2014 23:31:43 +0100 Szymon Olewniczak wrote: > Hi, > I've recently had a presentation(during local Linux User Group meeting) > about some basic ideas Unix philosophy and suckless projects. This has led > my attention once to the topic of programming languages and I must admit > that I've found Python much less harmful that I had previously > considered it to be. And when I can point out why does Perl, PHP, JS > sucks, python is another way round. Python has precise design, the code > is readable and what is very important it simplify many things. In > addition it has many great libraries so why > do not use Python at least as a prototype language. Mayby it's > multi-paradigm aproach is the problem but what alternatives to python do you > see? > awk? Limbo? And at last what do you thing about Ruby which is quite > similar to the python in many aspects? I am using Python to prototype. But prototypes have to become real ap‐ plications by rewriting them in C. Ruby is for hipsters. Sincerely, Christoph Lohmann
Re: [dev] What is bad with Python
On Mon, 3 Mar 2014 23:21:02 +0100 Szymon Olewniczak wrote: > (...) and I must admit that I've found Python much less > harmful that I had previously considered it to be. I agree on this one. The language designers did a good job. The only _big_ problem I have with it is the fact it's not compiled (and if, then it's _horrible_). Moreover, setting up a python-environment is not trivial and managing multiple versions of it has only been solved well by the Gentoo folks. Python has its uses, but due to it's dependency on so many non-trivial stuff, it just doesn't work out for me. Cheers FRIGN -- FRIGN
[dev] What is bad with Python
Hi, I've recently had a presentation(during local Linux User Group meeting) about some basic ideas Unix philosophy and suckless projects. This has led my attention once to the topic of programming languages and I must admit that I've found Python much less harmful that I had previously considered it to be. And when I can point out why does Perl, PHP, JS sucks, python is another way round. Python has precise design, the code is readable and what is very important it simplify many things. In addition it has many great libraries so why do not use Python at least as a prototype language. Mayby it's multi-paradigm aproach is the problem but what alternatives to python do you see? awk? Limbo? And at last what do you thing about Ruby which is quite similar to the python in many aspects? BR, Szymon
