|
|
|
|
Ist in Deutschland gescheitert, musste dann in der neuen Welt sein Glück suchen. Da, wo die Leute noch leichtgläubig und die Frauen wenig anspruchsvoll sind.
|
|
|
|
|
|
|
Alles in allem: Richtig gut Entscheidung
|
|
|
|
|
|
|
Servicedurchsage: Die Anzahl der in einem Schwulenforum angeführten Programmiersprachen und Frameworks, die man zu beherrschen vorgibt, hat nur einen unwesentlichen Effekt auf die Größe des eigenen E-Penis.
|
|
|
|
|
|
|
Das doch gelogen
|
|
|
|
|
|
|
Egal wie sehr der E-Penis wächst, ich werde jegliche Nutzung von PHP weiter verleugnen.
|
|
|
|
|
|
|
but...
laravel <3
|
|
|
|
|
|
|
Wegen PHP/Laravel hab ich mal einen Job gekündigt.
|
|
|
|
|
|
|
Wow, was soll ich als ABAP-Entwickler denn dann erst sagen.
|
|
|
|
|
|
|
Mit Composer und ab Version 7.1 ist PHP garnicht mehr so schlimm. Was mich immer zur Weißglut treibt, sind komische "magic arrays" wie ich sie nenne:
|
Code: |
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['pages']['backend'] = \TYPO3\CMS\Core\Cache\Backend\FileBackend::class;
|
|
Kann man so machen, ich finds furchtbar und damit ist php halt gefühlt leider auch mit zugeschissen.
Bin bei Reddit über einen netten Artikel gestolpert:
https://iism.org/article/developers-can-t-fix-bad-management-57
|
|
|
|
|
|
|
Wer schreibt denn solche verschachtelten Arrays?
Ein paar Frameworks erlauben, wenn es solche grausamen Konstukte braucht, eine Dot-Notation.
|
Code: |
$config->setItem('SYS.caching.cacheConfigurations.pages.backend', \TYPO3\CMS\Core\Cache\Backend\FileBackend::class); |
|
Das hat zwar im Kern immer noch doofe Ohren, ist aber ein bisschen lesbarer.
Manchmal geht dann auch
|
Code: |
$cacheConfig = $config->getItem('SYS.caching.cacheConfigurations');
$cacheConfig->setItem('pages.backend', \TYPO3\CMS\Core\Cache\Backend\FileBackend::class); |
|
Aber gerade Typo3 und Wordpress (oder Shopware, lol) halte ich für relativ schlechte Kandidaten um daran die Qualität einer Sprache zu bewerten.
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Fabsn am 10.06.2021 16:06]
|
|
|
|
|
|
Pythong:
Ich bekomme ein numpy array mit Funktionen, also
func_vec = np.array([func1, func2, func3])
Die Anzahl an enthaltenen Funktionen kann variieren.
Kann ich natuerlich so nicht aufrufen, hab also erst noch einen wrapper mit list comprehension
funcs = lambda x: np.array([func(x) for func in func_vec])
Das kommt mir... nicht so elegant vor?
|
|
|
|
|
|
|
| Zitat von Fabsn
.... (oder Shopware, lol) ...
| |
Na vielen dank, was denkst du mit was ich mich ab heute befassen darf.
Diese Monsterarrays in TYPO3 trifft man nicht so oft.
Jedenfalls sind sie mir bislang nicht negativ aufgefallen.
|
|
|
|
|
|
|
Abgesehen von der Syntax ($$$$$$$$$$) ist mir an PHP eigentlich nie etwas komisches aufgefallen. Arbeite aber de facto erst seit 2 Jahren damit und Laravel ist halt an sich so geil, dass man sich eigentlich ständig nur darüber freut, wie wenig Code man schreiben muss.
|
|
|
|
|
|
|
| Zitat von Irdorath
Pythong:
Ich bekomme ein numpy array mit Funktionen, also
func_vec = np.array([func1, func2, func3])
Die Anzahl an enthaltenen Funktionen kann variieren.
Kann ich natuerlich so nicht aufrufen, hab also erst noch einen wrapper mit list comprehension
funcs = lambda x: np.array([func(x) for func in func_vec])
Das kommt mir... nicht so elegant vor?
| |
| https://www.python.org/dev/peps/pep-0008/#programming-recommendations
Always use a def statement instead of an assignment statement that binds a lambda expression directly to an identifier:
# Correct:
def f(x): return 2*x
# Wrong:
f = lambda x: 2*x
The first form means that the name of the resulting function object is specifically 'f' instead of the generic '<lambda>'. This is more useful for tracebacks and string representations in general. The use of the assignment statement eliminates the sole benefit a lambda expression can offer over an explicit def statement (i.e. that it can be embedded inside a larger expression) | |
Ich würde das eher so schreiben:
import numpy as np
from typing import Any
func_vec = np.array([func1, func2, func3])
def apply_funcs(input_value: Any, func_vec: np.array):
return np.array([func(input_value) for func in func_vec])
Wieso kriegst du überhaupt ein np-Array mit Methoden? Das klingt nicht richtig
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von homer is alive am 10.06.2021 17:09]
|
|
|
|
|
|
Jungejunge, heute intensiver mit unserem Typescript-Code, dem Buildprozess und unserem Workflow auseinander gesetzt.
Ist das alles eine scheiße -.-
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von krak0s am 10.06.2021 17:30]
|
|
|
|
|
|
| Zitat von Ameisenfutter
Abgesehen von der Syntax ($$$$$$$$$$) ist mir an PHP eigentlich nie etwas komisches aufgefallen. Arbeite aber de facto erst seit 2 Jahren damit und Laravel ist halt an sich so geil, dass man sich eigentlich ständig nur darüber freut, wie wenig Code man schreiben muss.
| |
Der Süntaggs ist doch mittlerweile seit v7 und spätestens v8 sehr gut. Alles getyped, alles gehinted, Arrow-Functions, yields, annotations, bla bli blubb. Also da gibt's viel, viel schlimmere Sprachen wie z.B. Python. Also ich schreibe gerne PHP.
Aber Kotlin gefällt mir bis dato fast am besten von der Syntax her. Es ist (meistens) herrlich!
Auch TypeScript geht gut, aber insgesamt gefühlt etwas humpelnder als im Vergleich z.B. Kotlin.
Bez. so Config-Arrays geht doch mittlerweile eh fast alles in Richtung YAML. Habe ich am Anfang gehasst, finde ich aber mittlerweile echt ganz praktisch.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von derSenner am 10.06.2021 17:32]
|
|
|
|
|
|
| Zitat von X-Tender
| Zitat von Fabsn
.... (oder Shopware, lol) ...
| |
Na vielen dank, was denkst du mit was ich mich ab heute befassen darf.
| |
Ja erzähl mir mal was du davon hältst.
SW6 ist schon sehr komplex geworden und das Frontend ist so lala. Eigentlich müsste sich da mal jemand mit Ahnung hinsetzen und das komplette Frontend neu schreiben. Das Erweitern des Basisthemes geht, bringt aber extrem viel Overhead mit.
Und obwohl SW6 jetzt schon länger draußen ist, ist es immer noch so, dass die, die damit entwickeln, arbeiten und/oder es produktiv nutzen die Tester sind.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Fabsn am 10.06.2021 18:04]
|
|
|
|
|
|
| Zitat von Ameisenfutter
Wow, was soll ich als ABAP-Entwickler denn dann erst sagen.
| |
Du musst auf die inneren Werte schauen.
|
|
|
|
|
|
|
| Zitat von Fabsn
Ja erzähl mir mal was du davon hältst.
SW6 ist schon sehr komplex geworden und das Frontend ist so lala. Eigentlich müsste sich da mal jemand mit Ahnung hinsetzen und das komplette Frontend neu schreiben. Das Erweitern des Basisthemes geht, bringt aber extrem viel Overhead mit.
Und obwohl SW6 jetzt schon länger draußen ist, ist es immer noch so, dass die, die damit entwickeln, arbeiten und/oder es produktiv nutzen die Tester sind.
| |
Bis auf ein setup vis ddev und lesen der docu/guides bin ich noch nicht weiter hinaus gekommen. Aber ich weiß wenn ich in Zukunft nerven werde.
|
|
|
|
|
|
|
| Zitat von homer is alive
Wieso kriegst du überhaupt ein np-Array mit Methoden? Das klingt nicht richtig
| |
Ah danke, guter Hinweis mit dem object name.
Wieso das so ist.. da hat der Software Architekt in der Planung versagt.
Ich erzeuge halt an einer Stelle im Code die Funktionen func1, ..., funcn und brauche sie auch als individuelle Funktionen. Spaeter, brauche ich sie anderswo im Code wieder, bzw. werden sie als Argumente an eine grosse Funktion uebergeben. Damit das unabhaengig von n bleibt, uebergaebe ich sie halt als array eingetuetet. Innerhalb der grossen Funktion bin ich gerade am vektorisieren, und wuerde die kleinen Funktionen deswegen doch gerne gemeinsam auswerten koennen.
|
|
|
|
|
|
|
How about sowas? Bessere Namensgebung überlasse ich dir
|
Code: |
>>> def f1(x): return x
...
>>> def f2(x): return x+1
...
>>> def f3(x): return x**2
...
>>> def f(*fs):
... def _f(x): return [g(x) for g in fs]
... return _f
...
>>> bla = f(f1, f2, f3)
>>> bla(12)
[12, 13, 144]
|
|
|
|
|
|
|
|
|
| Zitat von derSenner
Bez. so Config-Arrays geht doch mittlerweile eh fast alles in Richtung YAML. Habe ich am Anfang gehasst, finde ich aber mittlerweile echt ganz praktisch.
| |
Ich hingegen flippe regelmaessig aus dank YAML. Diese Indentation zur Formatierung Scheisse kann sich grad getrost aus allem wegficken, ich hasse es.
Heute musste ich wieder Java Code schreiben nach 'ner Woche oder so nur Kotlin (beste) und das ist auch derbe stier, staendig verschrieben und Zeug vergessen, ach du lieber Himmel.
|
|
|
|
|
|
|
Kotlin halt sehr geil. Was will man machen? Yaml ok für so ca zwei Level of indentation. Danach eher Kacke.
|
|
|
|
|
|
|
Ja, naja. Aber was ist denn viel besser für Configs?
- JSON: An sich geil, aber keine Comments, deshalb useless.
- TOML: Auch nicht viel anders als YAML im Wahrheit.
- XML: Nein danke, wir haben nicht 1995.
- ini/.env: Klar, aber halt komplett ohne große Syntax-Richtlinien, von daher kann das auch schief gehen.
Was gäbe es denn sonst noch? Sprach-eigene Styles wie z.B. PHP Arrays oder so lasse ich nicht gelten.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von derSenner am 10.06.2021 18:57]
|
|
|
|
|
|
| Zitat von derSenner
Ja, naja. Aber was ist denn viel besser für Configs?
- JSON: An sich geil, aber keine Comments, deshalb useless.
| |
JA MANN WARUM KEINE COMMENTS JSON?
Das ist echt so eine unglaubliche Frechheit
|
|
|
|
|
|
|
11x Programmierern (so wie mir) ist das Werkzeug ja egal.
|
|
|
|
|
|
|
| Zitat von PutzFrau
| Zitat von derSenner
Ja, naja. Aber was ist denn viel besser für Configs?
- JSON: An sich geil, aber keine Comments, deshalb useless.
| |
JA MANN WARUM KEINE COMMENTS JSON?
Das ist echt so eine unglaubliche Frechheit
| |
Weils nicht für Zwecke gedacht ist, die Kommentare benötigen.
|
|
|
|
|
|
|
| Zitat von PutzFrau
| Zitat von derSenner
Ja, naja. Aber was ist denn viel besser für Configs?
- JSON: An sich geil, aber keine Comments, deshalb useless.
| |
JA MANN WARUM KEINE COMMENTS JSON?
Das ist echt so eine unglaubliche Frechheit
| |
|
Code: |
{
"Futz": "Prau",
"Kommentar": "Kommentar in JSON!"
}
|
|
Und dann "Kommentar" einfach nicht auswerten.
|
|
|
|
|
|
|
|
|
|
|
| Zitat von derSenner
Ja, naja. Aber was ist denn viel besser für Configs?
- JSON: An sich geil, aber keine Comments, deshalb useless.
- TOML: Auch nicht viel anders als YAML im Wahrheit.
- XML: Nein danke, wir haben nicht 1995.
- ini/.env: Klar, aber halt komplett ohne große Syntax-Richtlinien, von daher kann das auch schief gehen.
Was gäbe es denn sonst noch? Sprach-eigene Styles wie z.B. PHP Arrays oder so lasse ich nicht gelten.
| |
HOCON mal probiert?
|
|
|
|
|
|
Thema: Software-Entwicklung 0 ( new SammelThread() ) |